OMAP: DSS2: Overlay Manager LCD2 support in DISPC
Subsystems (3)
v4 cover OMAP: DSS2: Overlay Manager LCD2 support in DISPC
This patch series which incorporates changes in DSS2 to enable omap_dss_device instances to use the new Overlay Manager LCD2 in DISPC.
On OMAP4, we have a new DISPC channel for Overlay Manager LCD2. This channel's video port is a source port for RFBI, DSI2 and DPI. The Primary channel's video port is connected to RFBI and DSI1.
There is a set of regsiters for LCD2 channel similar to the existing LCD channel, like DISPC_CONTROL2, DISPC_DIVISOR2, DISPC_CONFIG2 and so on.
In order to decide which LCD Overlay Manager to configure(LCD/LCD2), there is a need for the omap_dss_device instances to tell the interface drivers(DSI, DPI, RFBI etc) which LCD channel they want to connect to, so that the corresponding registers get configured. Therefore, a new enum omap_channel member is introduced to omap_dss_device.
This design was made keeping in mind the possible addition of more Overlay Managers in future OMAPs, this code is also backward compatible with OMAP3 as omap_dss_device instances in OMAP3 will stick only with OMAP_DSS_CHANNEL_LCD.
This will apply over current lo-dss2 branch and the following:
Premultiplied alpha support:
https://patchwork.kernel.org/patch/301872/
https://patchwork.kernel.org/patch/301882/
and,
DSS2: Fix: Read correct bit in dispc_enable_alpha_blending():
https://patchwork.kernel.org/patch/308152/
Archit Taneja (2):
OMAP: DSS2: Add dss_features for omap4 and overlay manager related
features
OMAP: DSS2: Use dss_features to handle DISPC bits removed on OMAP4
Sumit Semwal (5):
OMAP: DSS2: Represent DISPC register defines with channel as
parameter
OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter
OMAP: DSS2: Change remaining Dispc functions for new 'channel'
argument
OMAP: DSS2: LCD2 Channel Changes for DISPC
OMAP: DSS2: Add new Overlay Manager
arch/arm/plat-omap/include/plat/display.h | 7 + drivers/video/omap2/dss/dispc.c | 573 +++++++++++++++++++---------- drivers/video/omap2/dss/dpi.c | 33 +- drivers/video/omap2/dss/dsi.c | 21 +- drivers/video/omap2/dss/dss.h | 36 +- drivers/video/omap2/dss/dss_features.c | 43 ++- drivers/video/omap2/dss/dss_features.h | 7 +- drivers/video/omap2/dss/manager.c | 73 +++-- drivers/video/omap2/dss/overlay.c | 14 +- drivers/video/omap2/dss/rfbi.c | 19 +- drivers/video/omap2/dss/sdi.c | 22 +- 11 files changed, 559 insertions(+), 289 deletions(-)
--
Version 4:
- Broken into smaller patches in order to build in between patches.
- Some basic cleanup
Version 3:
- Patches are reworked over dss2 features framework. Number of patches are reduced.
Version 2:
- The DISPC_BASE macro now isn't changed for OMAP4, a future hwmod patch will take care of this dynamically.
- Supported_displays member of manager is now assigned correctly for OMAP2.
- DISPC Registers common to LCD and LCD2 channels are not defined separately, now there is a parameter which differentiates between the 2 channels.
- Secondary LCD manager is now named as lcd2 instead of 2lcd, the patch given in the link below allows DSS2 interpret this correctly. Version 1:
http://www.mail-archive.com/[email protected]/msg31458.html
PATCH v4 1/7 OMAP: DSS2: Add dss_features for omap4 and overlay manager related features
Add support for LCD2 manager through introducing a new has_feature, Initialize a dss_features struct for omap4.
--- drivers/video/omap2/dss/dss_features.c | 43 ++++++++++++++++++++++++++++++- drivers/video/omap2/dss/dss_features.h | 7 ++++- 2 files changed, 47 insertions(+), 3 deletions(-)
drivers/video/omap2/dss/dss_features.c +41 -2
@@ -82,6 +82,18 @@ static const enum omap_display_type omap3_dss_supported_displays[] = { OMAP_DISPLAY_TYPE_VENC, }; +static const enum omap_display_type omap4_dss_supported_displays[] = { +/* OMAP_DSS_CHANNEL_LCD */ +OMAP_DISPLAY_TYPE_DBI |OMAP_DISPLAY_TYPE_DSI , + +/* OMAP_DSS_CHANNEL_DIGIT */ +OMAP_DISPLAY_TYPE_VENC , + +/* OMAP_DSS_CHANNEL_LCD2 */ +OMAP_DISPLAY_TYPE_DPI |OMAP_DISPLAY_TYPE_DBI | +OMAP_DISPLAY_TYPE_DSI , +}; +static const enum omap_color_mode omap2_dss_supported_color_modes[] = {/* OMAP_DSS_GFX */ OMAP_DSS_COLOR_CLUT1 | OMAP_DSS_COLOR_CLUT2 |
@@ -127,6 +139,10 @@ static struct omap_dss_features omap2_dss_features = { .reg_fields = omap2_dss_reg_fields, .num_reg_fields = ARRAY_SIZE(omap2_dss_reg_fields), + .has_feature = +FEAT_LCDENABLEPOL |FEAT_LCDENABLESIGNAL | + FEAT_PCKFREEENABLE | FEAT_FUNCGATED, + .num_mgrs = 2, .num_ovls = 3, .supported_displays = omap2_dss_supported_displays,
@@ -138,7 +154,10 @@ static struct omap_dss_features omap3430_dss_features = { .reg_fields = omap3_dss_reg_fields, .num_reg_fields = ARRAY_SIZE(omap3_dss_reg_fields), - .has_feature = FEAT_GLOBAL_ALPHA, + .has_feature = +FEAT_GLOBAL_ALPHA |FEAT_LCDENABLEPOL | +FEAT_LCDENABLESIGNAL |FEAT_PCKFREEENABLE | + FEAT_FUNCGATED, .num_mgrs = 2, .num_ovls = 3,
@@ -150,7 +169,10 @@ static struct omap_dss_features omap3630_dss_features = { .reg_fields = omap3_dss_reg_fields, .num_reg_fields = ARRAY_SIZE(omap3_dss_reg_fields), - .has_feature = FEAT_GLOBAL_ALPHA | FEAT_PRE_MULT_ALPHA, + .has_feature = +FEAT_GLOBAL_ALPHA |FEAT_LCDENABLEPOL | +FEAT_LCDENABLESIGNAL |FEAT_PCKFREEENABLE | + FEAT_PRE_MULT_ALPHA | FEAT_FUNCGATED, .num_mgrs = 2, .num_ovls = 3,
@@ -158,6 +180,21 @@ static struct omap_dss_features omap3630_dss_features = { .supported_color_modes = omap3_dss_supported_color_modes, }; +/* OMAP4 DSS Features */ +static struct omap_dss_features omap4_dss_features = { + .reg_fields = omap3_dss_reg_fields, + .num_reg_fields =ARRAY_SIZE (omap3_dss_reg_fields), + + .has_feature = +FEAT_GLOBAL_ALPHA |FEAT_PRE_MULT_ALPHA | +FEAT_MGR_LCD2 , + + .num_mgrs =3 , + .num_ovls =3 , + .supported_displays = omap4_dss_supported_displays, + .supported_color_modes = omap3_dss_supported_color_modes, +}; +/* Functions returning values related to a DSS feature */ int dss_feat_get_num_mgrs (void ) {
@@ -202,4 +239,6 @@ void dss_features_init(void) omap_current_dss_features = &omap3630_dss_features; else if (cpu_is_omap34xx()) omap_current_dss_features = &omap3430_dss_features; + else + omap_current_dss_features = &omap4_dss_features; }
drivers/video/omap2/dss/dss_features.h +6 -1
@@ -20,7 +20,7 @@#ifndef __OMAP2_DSS_FEATURES_H#define __OMAP2_DSS_FEATURES_H -#define MAX_DSS_MANAGERS 2 +#define MAX_DSS_MANAGERS 3#define MAX_DSS_OVERLAYS 3/* DSS has feature id */
@@ -28,6 +28,11 @@ enum dss_feat_id {FEAT_GLOBAL_ALPHA =1 <<0 ,FEAT_GLOBAL_ALPHA_VID1 =1 <<1 ,FEAT_PRE_MULT_ALPHA =1 <<2 , +FEAT_LCDENABLEPOL =1 <<3 , +FEAT_LCDENABLESIGNAL =1 <<4 , +FEAT_PCKFREEENABLE =1 <<5 , +FEAT_FUNCGATED =1 <<6 , + FEAT_MGR_LCD2 = 1 << 7, };/* DSS register field id */
Signature · 1 line
1.7.0.4
PATCH v4 2/7 OMAP: DSS2: Represent DISPC register defines with channel as parameter
In reply to Archit TanejaFrom: Sumit Semwal <[email protected]>
Introduce new enum members for LCD2 Channel and corresponding Overlay Manager.
Represent some of the DISPC register defines with channel as a parameter to differentiate between LCD, DIGIT and LCD2 channels. Replace the existing reads/writes to these registers in this new way.
--- arch/arm/plat-omap/include/plat/display.h | 2 + drivers/video/omap2/dss/dispc.c | 255 ++++++++++++++--------------- 2 files changed, 128 insertions(+), 129 deletions(-)
arch/arm/plat-omap/include/plat/display.h +2 -0
@@ -64,6 +64,7 @@ enum omap_plane {enum omap_channel {OMAP_DSS_CHANNEL_LCD =0 ,OMAP_DSS_CHANNEL_DIGIT =1 , +OMAP_DSS_CHANNEL_LCD2 =2 , };enum omap_color_mode {
@@ -142,6 +143,7 @@ enum omap_dss_display_state {enum omap_dss_overlay_managers {OMAP_DSS_OVL_MGR_LCD ,OMAP_DSS_OVL_MGR_TV , +OMAP_DSS_OVL_MGR_LCD2 , };enum omap_dss_rotation_type {
drivers/video/omap2/dss/dispc.c +126 -129
577 lines not on this page · raw message
Signature · 1 line
1.7.0.4
Re: [PATCH v4 2/7] OMAP: DSS2: Represent DISPC register defines with channel as parameter
Hi,
Quoted 11 lines · ext Archit Taneja
From: Sumit Semwal <[email protected]>
Introduce new enum members for LCD2 Channel and corresponding Overlay Manager.
Represent some of the DISPC register defines with channel as a parameter to differentiate between LCD, DIGIT and LCD2 channels. Replace the existing reads/writes to these registers in this new way.
Signed-off-by Sumit Semwal <[email protected]>Signed-off-by Mukund Mittal <[email protected]>Signed-off-by Samreen <[email protected]>
<snip>
drivers/video/omap2/dss/dispc.c static void dispc_enable_digit_out(bool enable) · line 1855
Quoted 12 lines
drivers/video/omap2/dss/dispc.c +2
-2@@ -1843,9 +1847,9 @@ static void dispc_enable_digit_out(bool enable)bool dispc_is_channel_enabled (enum omap_channel channel) {if (channel ==OMAP_DSS_CHANNEL_LCD ) -return !!REG_GET (DISPC_CONTROL ,0 ,0 ); +return !!REG_GET (DISPC_CONTROL (channel),0 ,0 );else if (channel ==OMAP_DSS_CHANNEL_DIGIT ) -return !!REG_GET (DISPC_CONTROL ,1 ,1 ); +return !!REG_GET (DISPC_CONTROL (channel),1 ,1 );else BUG (); }
I don't think this is good.
Looking at the code here, it looks like we're accessing different DISPC_CONTROL registers for LCD and DIGIT out. But we're not.
For some registers it's good to have DISPC_XXX(ch) style, when the registers are accessed identically for different channels. Then you can just modify the same bits in DISPC_REG(ch) register, and you don't have to mind what the channel actually is.
But this is not the case in the function above.
The DISPC_CONTROL(ch) is defined as:DISPC_REG(ch != 2 ? 0x0040 : 0x0238)
I don't think this is actually right. DISPC_CONTROL is not a register defined per channel. The register at 0x40 contains bits for both channels 0 and 1. Perhaps leave DISPC_CONTROL as it was, and add DISPC_CONTROL2, because the registers are not used similarly for all channels. Or you can come up with some other solution, but using channel as argument for the macro doesn't look right.
The same comments apply to other functions using DISPC_CONTROL(channel). (And possibly to some other registers which are similar).
Tomi
RE: [PATCH v4 2/7] OMAP: DSS2: Represent DISPC register defines with channel as parameter
Hi,
Quoted 46 lines · Tomi Valkeinen
Hi,
Quoted 12 lines · ext Archit Taneja
From: Sumit Semwal <[email protected]>
Introduce new enum members for LCD2 Channel and corresponding Overlay Manager.
Represent some of the DISPC register defines with channel as a parameter to differentiate between LCD, DIGIT and LCD2 channels. Replace the existing reads/writes to these registers in this new way.
Signed-off-by Sumit Semwal <[email protected]>Signed-off-by Mukund Mittal <[email protected]>Signed-off-by Samreen <[email protected]><snip>
Review static void
Quoted 1 line
(quoted diff) +0
-0@@ -1843,9 +1847,9 @@ static void
dispc_enable_digit_out(bool enable)drivers/video/omap2/dss/dispc.c static void dispc_enable_digit_out(bool enable) · line 1855
Quoted 9 lines
drivers/video/omap2/dss/dispc.c +2
-2bool dispc_is_channel_enabled (enum omap_channel channel) {if (channel ==OMAP_DSS_CHANNEL_LCD ) -return !!REG_GET (DISPC_CONTROL ,0 ,0 ); +return !!REG_GET (DISPC_CONTROL (channel),0 ,0 );else if (channel ==OMAP_DSS_CHANNEL_DIGIT ) -return !!REG_GET (DISPC_CONTROL ,1 ,1 ); +return !!REG_GET (DISPC_CONTROL (channel),1 ,1 );else BUG (); }I don't think this is good.
Looking at the code here, it looks like we're accessing different
DISPC_CONTROLregisters for LCD and DIGIT out. But we're not.For some registers it's good to have
DISPC_XXX(ch)style,
when the registers are accessed identically for different channels. Then you can just modify the same bits inDISPC_REG(ch)register, and you don't have to mind what the channel actually is.But this is not the case in the function above.
The
DISPC_CONTROL(ch)is defined as:DISPC_REG(ch != 2 ? 0x0040 : 0x0238)
Quoted 7 lines
I don't think this is actually right.
DISPC_CONTROLis not a register defined per channel. The register at0x40contains
bits for both channels 0 and 1. Perhaps leaveDISPC_CONTROL
as it was, and addDISPC_CONTROL2, because the registers are
not used similarly for all channels. Or you can come up with
some other solution, but using channel as argument for the macro doesn't look right.
Yes, this holds for DISPC_CONTROL and DISPC_CONFIG registers, I didn't think it would be wrong if 2 channels point to the same register field.
But apart from that, there are some bits in these registers which are not specific to any channel and doing something like this would be misleading,
For setting fifiomerge:REG_FLD_MOD(DISPC_CONFIG(OMAP_DSS_CHANNEL_LCD), enable ? 1 : 0, 14, 14);
Since the above bit is not specific to LCD channel.
I'll keep these 2 registers the way they are.
Thanks,
Archit
PATCH v4 3/7 OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter
In reply to Archit TanejaFrom: Sumit Semwal <[email protected]>
A new member 'channel' is introduced in omap_dss_device structure to determine which channel the panel uses. The dispc functions used by interface drivers (dsi, sdi etc) will use this member to differentiate between the 2 channels.
The following dispc functions are changed to incorporate channel as an argument:
-dispc_enable_fifohandcheck() -dispc_set_lcd_size() -dispc_set_parallel_interface_mode() -dispc_set_tft_data_lines() -dispc_set_lcd_display_type() -dispc_set_lcd_timings()
The calls to these functions from the interface drivers have been changed to incorporate the new channel argument.
--- arch/arm/plat-omap/include/plat/display.h | 1 + drivers/video/omap2/dss/dispc.c | 49 ++++++++++++++++------------- drivers/video/omap2/dss/dpi.c | 11 +++--- drivers/video/omap2/dss/dsi.c | 13 ++++--- drivers/video/omap2/dss/dss.h | 19 ++++++----- drivers/video/omap2/dss/rfbi.c | 19 ++++++----- drivers/video/omap2/dss/sdi.c | 14 +++++--- 7 files changed, 70 insertions(+), 56 deletions(-)
arch/arm/plat-omap/include/plat/display.h +1 -0
@@ -434,6 +434,7 @@ struct omap_dss_device {struct omap_overlay_manager *manager;enum omap_dss_display_state state; +enum omap_channel channel;/* platform specific */ int (*platform_enable)(struct omap_dss_device *dssdev);
drivers/video/omap2/dss/dispc.c +27 -22
125 lines not on this page · raw message
drivers/video/omap2/dss/dpi.c +6 -5
@@ -132,7 +132,7 @@ static int dpi_set_mode(struct omap_dss_device *dssdev) t->pixel_clock = pck; } -dispc_set_lcd_timings (t); +dispc_set_lcd_timings (dssdev->channel, t); err0:dss_clk_disable (DSS_CLK_ICK |DSS_CLK_FCK1 );
@@ -145,10 +145,11 @@ static int dpi_basic_init(struct omap_dss_device *dssdev) is_tft = (dssdev->panel.config &OMAP_DSS_LCD_TFT ) !=0 ; -dispc_set_parallel_interface_mode (OMAP_DSS_PARALLELMODE_BYPASS ); -dispc_set_lcd_display_type (is_tft ?OMAP_DSS_LCD_DISPLAY_TFT : -OMAP_DSS_LCD_DISPLAY_STN ); -dispc_set_tft_data_lines (dssdev->phy.dpi.data_lines); +dispc_set_parallel_interface_mode (dssdev->channel, +OMAP_DSS_PARALLELMODE_BYPASS ); +dispc_set_lcd_display_type (dssdev->channel, is_tft ? +OMAP_DSS_LCD_DISPLAY_TFT :OMAP_DSS_LCD_DISPLAY_STN ); +dispc_set_tft_data_lines (dssdev->channel, dssdev->phy.dpi.data_lines);return 0 ; }
drivers/video/omap2/dss/dsi.c +7 -6
@@ -2888,7 +2888,7 @@ int omap_dsi_prepare_update(struct omap_dss_device *dssdev,if (dssdev->manager->caps &OMAP_DSS_OVL_MGR_CAP_DISPC ) {dss_setup_partial_planes (dssdev, x, y, w, h, enlarge_update_area); -dispc_set_lcd_size (*w, *h); +dispc_set_lcd_size (dssdev->channel, *w, *h); }return 0 ;
@@ -2947,12 +2947,13 @@ static int dsi_display_init_dispc(struct omap_dss_device *dssdev)return r; } -dispc_set_lcd_display_type (OMAP_DSS_LCD_DISPLAY_TFT ); +dispc_set_lcd_display_type (dssdev->channel,OMAP_DSS_LCD_DISPLAY_TFT ); -dispc_set_parallel_interface_mode (OMAP_DSS_PARALLELMODE_DSI ); -dispc_enable_fifohandcheck (1 ); +dispc_set_parallel_interface_mode (dssdev->channel, +OMAP_DSS_PARALLELMODE_DSI ); +dispc_enable_fifohandcheck (dssdev->channel,1 ); -dispc_set_tft_data_lines (dssdev->ctrl.pixel_size); +dispc_set_tft_data_lines (dssdev->channel, dssdev->ctrl.pixel_size); {struct omap_video_timings timings = {
@@ -2964,7 +2965,7 @@ static int dsi_display_init_dispc(struct omap_dss_device *dssdev) .vbp = 0, }; -dispc_set_lcd_timings (&timings); +dispc_set_lcd_timings (dssdev->channel, &timings); }return 0 ;
drivers/video/omap2/dss/dss.h +11 -8
@@ -333,9 +333,9 @@ void dispc_disable_sidle(void);void dispc_lcd_enable_signal_polarity (bool act_high);void dispc_lcd_enable_signal (bool enable);void dispc_pck_free_enable (bool enable); -void dispc_enable_fifohandcheck (bool enable); +void dispc_enable_fifohandcheck (enum omap_channel channel,bool enable); -void dispc_set_lcd_size (u16 width,u16 height); +void dispc_set_lcd_size (enum omap_channel channel,u16 width,u16 height);void dispc_set_digit_size (u16 width,u16 height);u32 dispc_get_plane_fifo_size (enum omap_plane plane);void dispc_setup_plane_fifo (enum omap_plane plane,u32 low,u32 high);
@@ -369,9 +369,11 @@ bool dispc_is_channel_enabled(enum omap_channel channel);int dispc_enable_plane (enum omap_plane plane,bool enable);void dispc_enable_replication (enum omap_plane plane,bool enable); -void dispc_set_parallel_interface_mode (enum omap_parallel_interface_mode mode); -void dispc_set_tft_data_lines (u8 data_lines); -void dispc_set_lcd_display_type (enum omap_lcd_display_type type); +void dispc_set_parallel_interface_mode (enum omap_channel channel, +enum omap_parallel_interface_mode mode); +void dispc_set_tft_data_lines (enum omap_channel channel,u8 data_lines); +void dispc_set_lcd_display_type (enum omap_channel channel, +enum omap_lcd_display_type type);void dispc_set_loadmode (enum omap_dss_load_mode mode);void dispc_set_default_color (enum omap_channel channel,u32 color);
@@ -388,7 +390,8 @@ bool dispc_trans_key_enabled(enum omap_channel ch);bool dispc_alpha_blending_enabled (enum omap_channel ch);bool dispc_lcd_timings_ok (struct omap_video_timings *timings); -void dispc_set_lcd_timings (struct omap_video_timings *timings); +void dispc_set_lcd_timings (enum omap_channel channel, +struct omap_video_timings *timings);unsigned long dispc_fclk_rate (void );unsigned long dispc_lclk_rate (void );unsigned long dispc_pclk_rate (void );
@@ -425,8 +428,8 @@ void rfbi_dump_regs(struct seq_file *s);int rfbi_configure (int rfbi_module,int bpp,int lines);void rfbi_enable_rfbi (bool enable); -void rfbi_transfer_area (u16 width,u16 height, -void (callback )(void *data),void *data); +void rfbi_transfer_area (enum omap_channel channel,u16 width, +u16 height,void (callback )(void *data),void *data);void rfbi_set_timings (int rfbi_module,struct rfbi_timings *t);unsigned long rfbi_get_max_tx_rate (void );int rfbi_init_display (struct omap_dss_device *display);
drivers/video/omap2/dss/rfbi.c +10 -9
@@ -301,8 +301,8 @@ void omap_rfbi_write_pixels(const void __iomem *buf, int scr_width, }EXPORT_SYMBOL (omap_rfbi_write_pixels); -void rfbi_transfer_area (u16 width,u16 height, -void (callback )(void *data),void *data) +void rfbi_transfer_area (enum omap_channel channel,u16 width, +u16 height,void (*callback)(void *data),void *data) {u32 l;
@@ -311,9 +311,9 @@ void rfbi_transfer_area(u16 width, u16 height,DSSDBG ("rfbi_transfer_area %dx%d\n" , width, height); -dispc_set_lcd_size (width, height); +dispc_set_lcd_size (channel, width, height); -dispc_enable_channel (OMAP_DSS_CHANNEL_LCD , true); +dispc_enable_channel (channel, true); rfbi.framedone_callback = callback; rfbi.framedone_callback_data = data;
@@ -887,7 +887,7 @@ int omap_rfbi_prepare_update(struct omap_dss_device *dssdev,if (dssdev->manager->caps &OMAP_DSS_OVL_MGR_CAP_DISPC ) {dss_setup_partial_planes (dssdev, x, y, w, h, true); -dispc_set_lcd_size (*w, *h); +dispc_set_lcd_size (dssdev->channel, *w, *h); }return 0 ;
@@ -899,7 +899,7 @@ int omap_rfbi_update(struct omap_dss_device *dssdev, void (*callback)(void *), void *data) {if (dssdev->manager->caps &OMAP_DSS_OVL_MGR_CAP_DISPC ) { -rfbi_transfer_area (w, h, callback, data); +rfbi_transfer_area (dssdev->channel, w, h, callback, data); }else {struct omap_overlay *ovl;void __iomem *addr;
@@ -1018,11 +1018,12 @@ int omapdss_rfbi_display_enable(struct omap_dss_device *dssdev) goto err1; } -dispc_set_lcd_display_type (OMAP_DSS_LCD_DISPLAY_TFT ); +dispc_set_lcd_display_type (dssdev->channel,OMAP_DSS_LCD_DISPLAY_TFT ); -dispc_set_parallel_interface_mode (OMAP_DSS_PARALLELMODE_RFBI ); +dispc_set_parallel_interface_mode (dssdev->channel, +OMAP_DSS_PARALLELMODE_RFBI ); -dispc_set_tft_data_lines (dssdev->ctrl.pixel_size); +dispc_set_tft_data_lines (dssdev->channel, dssdev->ctrl.pixel_size); rfbi_configure(dssdev->phy.rfbi.channel, dssdev->ctrl.pixel_size,
drivers/video/omap2/dss/sdi.c +8 -6
@@ -35,12 +35,14 @@ static struct {struct regulator *vdds_sdi_reg; } sdi; -static void sdi_basic_init (void ) +static void sdi_basic_init (enum omap_channel channel) + { -dispc_set_parallel_interface_mode (OMAP_DSS_PARALLELMODE_BYPASS ); +dispc_set_parallel_interface_mode (channel, +OMAP_DSS_PARALLELMODE_BYPASS ); -dispc_set_lcd_display_type (OMAP_DSS_LCD_DISPLAY_TFT ); -dispc_set_tft_data_lines (24 ); +dispc_set_lcd_display_type (channel,OMAP_DSS_LCD_DISPLAY_TFT ); +dispc_set_tft_data_lines (channel,24 );dispc_lcd_enable_signal_polarity (1 ); }
@@ -68,7 +70,7 @@ int omapdss_sdi_display_enable(struct omap_dss_device *dssdev)if (!sdi.skip_init)dss_clk_enable (DSS_CLK_ICK |DSS_CLK_FCK1 ); -sdi_basic_init (); +sdi_basic_init (dssdev->channel);/* 15.5.9.1.2 */ dssdev->panel.config |=OMAP_DSS_LCD_RF |OMAP_DSS_LCD_ONOFF ;
@@ -102,7 +104,7 @@ int omapdss_sdi_display_enable(struct omap_dss_device *dssdev) } -dispc_set_lcd_timings (t); +dispc_set_lcd_timings (dssdev->channel, t); r =dss_set_clock_div (&dss_cinfo);if (r)
Signature · 1 line
1.7.0.4
Re: [PATCH v4 3/7] OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter
Hi,
Quoted 35 lines · ext Archit Taneja
From: Sumit Semwal <[email protected]>
A new member 'channel' is introduced in
omap_dss_devicestructure to determine which channel the panel uses. The dispc functions used by interface drivers (dsi, sdi etc) will use this member to differentiate between the 2 channels.The following dispc functions are changed to incorporate channel as an argument:
-dispc_enable_fifohandcheck() -dispc_set_lcd_size() -dispc_set_parallel_interface_mode() -dispc_set_tft_data_lines() -dispc_set_lcd_display_type() -dispc_set_lcd_timings()The calls to these functions from the interface drivers have been changed to incorporate the new channel argument.
Signed-off-by Sumit Semwal <[email protected]>Signed-off-by Mukund Mittal <[email protected]>Signed-off-by Samreen <[email protected]>--- arch/arm/plat-omap/include/plat/display.h | 1 + drivers/video/omap2/dss/dispc.c | 49 ++++++++++++++++------------- drivers/video/omap2/dss/dpi.c | 11 +++--- drivers/video/omap2/dss/dsi.c | 13 ++++--- drivers/video/omap2/dss/dss.h | 19 ++++++----- drivers/video/omap2/dss/rfbi.c | 19 ++++++----- drivers/video/omap2/dss/sdi.c | 14 +++++--- 7 files changed, 70 insertions(+), 56 deletions(-)arch/arm/plat-omap/include/plat/display.h +0
-0
arch/arm/plat-omap/include/plat/display.h struct omap_dss_device { · line 437
Quoted 4 lines
arch/arm/plat-omap/include/plat/display.h +1
-0@@ -434,6 +434,7 @@ struct omap_dss_device {struct omap_overlay_manager *manager;enum omap_dss_display_state state; +enum omap_channel channel;
Isn't this the same as dssdev->manager->id?
Yes, this channel stuff is a bit confusing, even the enum "omap_channel" is badly named (should at least have "dss" in it). But omap_overlay_manager should represent the output pipe, so I don't think there's need for channel field in dss_device.
I think in many places we could even pass omap_overlay_manager pointer around, instead of omap_channel. However, for low level dispc functions it's perhaps cleaner to pass the channel ID though.
Tomi
RE: [PATCH v4 3/7] OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter
Hi,
Quoted 2 lines · Tomi Valkeinen
Hi,
[snip]
Quoted 13 lines
arch/arm/plat-omap/include/plat/display.h struct omap_dss_device { · line 437
Quoted 10 lines
arch/arm/plat-omap/include/plat/display.h +1
-0@@ -434,6 +434,7 @@ struct omap_dss_device {struct omap_overlay_manager *manager;enum omap_dss_display_state state; +enum omap_channel channel;Isn't this the same as
dssdev->manager->id?
Quoted 4 lines
Yes, this channel stuff is a bit confusing, even the enum "
omap_channel" is badly named (should at least have "dss" in it). Butomap_overlay_managershould represent the output pipe, so I don't think there's need for channel field indss_device.
The panel somehow needs to tell which manager it is connected to. We went with with the way of declaring a new member 'channel' and setting that parameter up in the board file.
The current way to relate the manager and device is done by checking the dssdev->type in dss_recheck_connections() and then calling set_device()
This is not sufficient any more since two of the managers can support similar types of displays.
So in the channel approach the following happens:
-mgr->id's are initialized at bootup. -devices and managers are connected using 'channel'. -mgr->id automatically becomes equal to channel.
Can we set something like dssdev->manager->id in the board file itself?
Archit
Quoted 7 lines
I think in many places we could even pass
omap_overlay_managerpointer around, instead ofomap_channel. However, for low level dispc functions it's perhaps cleaner to pass the channel ID though.Tomi
RE: [PATCH v4 3/7] OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter
Quoted 42 lines · Archit
Hi,
Quoted 2 lines · Tomi Valkeinen
Hi,
[snip]
Quoted 13 lines
arch/arm/plat-omap/include/plat/display.h struct omap_dss_device { · line 437
Quoted 10 lines
arch/arm/plat-omap/include/plat/display.h +1
-0@@ -434,6 +434,7 @@ struct omap_dss_device {struct omap_overlay_manager *manager;enum omap_dss_display_state state; +enum omap_channel channel;Isn't this the same as
dssdev->manager->id?Quoted 4 lines
Yes, this channel stuff is a bit confusing, even the enum "
omap_channel" is badly named (should at least have "dss" in it). Butomap_overlay_managershould represent the output pipe, so I don't think there's need for channel field indss_device.The panel somehow needs to tell which manager it is connected to. We went with with the way of declaring a new member 'channel' and setting that parameter up in the board file.
The current way to relate the manager and device is done by checking the
dssdev->typeindss_recheck_connections()and then callingset_device()This is not sufficient any more since two of the managers can support similar types of displays.
So in the channel approach the following happens:
(quoted diff) +0
-3-mgr->id's are initialized at bootup. -devices and managers are connected using 'channel'. -mgr->id automatically becomes equal to channel.
Quoted 1 line
Can we set something like
dssdev->manager->idin the board file itself?
Right, now I see.
The dss_recheck_connections() felt like a hack when I wrote it =). Clearly we need some way to define in the board file which panel connects to which manager.
Perhaps move the channel-field up, just below "enum omap_display_type type". The lines in the beginning of omap_dss_device are things which define the interface etc, and later there are miscallaneous dynamic things. And this belongs to the former.
Now, if we have the channel defined in this way in the omap_dss_device, I'm wondering if:
1) the manager pointer is needed at all, as the channel tells which manager it is?
2) if we keep the manager pointer (as a helper shortcut), should the code use generally use dssdev->channel or dssdev->manager->id?
3) having this channel field requires a change to every board file, because the channel has to be defined?
And answering to myself, I guess the manager pointer is needed, because DSS2 supports (at least in theory) multiple panels in the same interface (not at the same time, of course). This means that we could have to panels, with the same interface and channel, but only one would be in use. So the one in use should have manager pointing to the correct manager, and the other would have manager NULL.
And thus perhaps using dssdev->channel only for connecting the right manager to right panel, and using dssdev->manager->id for other uses would be the best? The values would of course be the same, but at least we'd get a crash if somehow an unconnected display is being used for configuration.
Does this make sense?
Tomi
RE: [PATCH v4 3/7] OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter
Hi,
Quoted 43 lines · Tomi Valkeinen
Quoted 42 lines · Archit
Hi,
Quoted 2 lines · Tomi Valkeinen
Hi,
[snip]
Quoted 13 lines
arch/arm/plat-omap/include/plat/display.h struct omap_dss_device { · line 437
Quoted 10 lines
arch/arm/plat-omap/include/plat/display.h +1
-0@@ -434,6 +434,7 @@ struct omap_dss_device {struct omap_overlay_manager *manager;enum omap_dss_display_state state; +enum omap_channel channel;Isn't this the same as
dssdev->manager->id?Quoted 4 lines
Yes, this channel stuff is a bit confusing, even the enum "
omap_channel" is badly named (should at least have "dss" in it). Butomap_overlay_managershould represent the output pipe, so I don't think there's need for channel field indss_device.The panel somehow needs to tell which manager it is connected to. We went with with the way of declaring a new member 'channel' and setting that parameter up in the board file.
The current way to relate the manager and device is done by checking the
dssdev->typeindss_recheck_connections()and then callingset_device()This is not sufficient any more since two of the managers can support similar types of displays.
So in the channel approach the following happens:
(quoted diff) +0
-3-mgr->id's are initialized at bootup. -devices and managers are connected using 'channel'. -mgr->id automatically becomes equal to channel.
Quoted 8 lines
Quoted 1 line
Can we set something like
dssdev->manager->idin the board file itself?Right, now I see.
The
dss_recheck_connections()felt like a hack when I wrote it =). Clearly we need some way to define in the board file which panel connects to which manager.
It wasn't needed probably for OMAP3 since all non-venc panels connect to LCD and venc to VENC type.
Now that I think of it, what channel would we mention if the panel is used in dsi l4 update mode or dma mode? It should have no manager at all.
Quoted 11 lines
Perhaps move the channel-field up, just below "enum
omap_display_typetype". The lines in the beginning ofomap_dss_deviceare things which define the interface etc, and later there are miscallaneous dynamic things. And this belongs to the former.Now, if we have the channel defined in this way in the
omap_dss_device, I'm wondering if:
1) the manager pointer is needed at all, as the channel tells which manager it is? 2) if we keep the manager pointer (as a helper shortcut), should the code use generally usedssdev->channelordssdev->manager->id?
I think manager->id makes more sense considering your logic below.
Quoted 3 lines
3) having this channel field requires a change to every board file, because the channel has to be defined?
Yes, that is something that has to be done for all 'DIGIT' panels across all boards.
Quoted 9 lines
And answering to myself, I guess the manager pointer is needed, because
DSS2 supports (at least in theory) multiple panels in the same interface (not at the same time, of course). This means that we could have to panels, with the same interface and channel, but only one would be in use. So the one in use should have manager pointing to the correct manager, and the other would have manager NULL.
Yes, passing dssdev->channel would make things worse if 2 panels are connected to same interface.
Quoted 6 lines
And thus perhaps using
dssdev->channelonly for connecting the right manager to right panel, and usingdssdev->manager->idfor other uses would be the best? The values would of course be the same, but at least we'd get a crash if somehow an unconnected display is being used for configuration.
Even in the current kernel on 3430sdp, the board file adds sharp_ls, venc and generic panels If I boot up with venc as default display, mgr0 has dvi as its display and mgr1 has tv. So if I try to enable sharp_ls panel I get a crash when we first try to access dssdev->manager in dpi_display_enable(). We should have a way to prevent enabling a panel if it isn't connected to a manager. We should also have a way to allow a panel to have no channel at all (something like OMAP_DSS_CHANNEL_NONE) if we are using something like dsi l4 update.
I won't add this extra channel now though, we need to think of a better way later.
Quoted 1 line
Does this make sense?
Yes, it does, I'll make these changes, and more if you can think of any.
Archit
RE: [PATCH v4 3/7] OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter
Hi,
Quoted 111 lines · Tomi Valkeinen
Hi,
Quoted 43 lines · Tomi Valkeinen
Quoted 42 lines · Archit
Hi,
Quoted 2 lines · Tomi Valkeinen
Hi,
[snip]
Quoted 13 lines
arch/arm/plat-omap/include/plat/display.h struct omap_dss_device { · line 437
Quoted 10 lines
arch/arm/plat-omap/include/plat/display.h +1
-0@@ -434,6 +434,7 @@ struct omap_dss_device {struct omap_overlay_manager *manager;enum omap_dss_display_state state; +enum omap_channel channel;Isn't this the same as
dssdev->manager->id?Quoted 4 lines
Yes, this channel stuff is a bit confusing, even the enum "
omap_channel" is badly named (should at least have "dss" in it). Butomap_overlay_managershould represent the output pipe, so I don't think there's need for channel field indss_device.The panel somehow needs to tell which manager it is connected to. We went with with the way of declaring a new member 'channel' and setting that parameter up in the board file.
The current way to relate the manager and device is done by checking the
dssdev->typeindss_recheck_connections()and then callingset_device()This is not sufficient any more since two of the managers can support similar types of displays.
So in the channel approach the following happens:
(quoted diff) +0
-3-mgr->id's are initialized at bootup. -devices and managers are connected using 'channel'. -mgr->id automatically becomes equal to channel.Quoted 8 lines
Quoted 1 line
Can we set something like
dssdev->manager->idin the board file itself?Right, now I see.
The
dss_recheck_connections()felt like a hack when I wrote it =). Clearly we need some way to define in the board file which panel connects to which manager.It wasn't needed probably for OMAP3 since all non-venc panels connect to LCD and venc to VENC type.
Now that I think of it, what channel would we mention if the panel is used in dsi l4 update mode or dma mode? It should have no manager at all.
Quoted 10 lines
Perhaps move the channel-field up, just below "enum
omap_display_typetype". The lines in the beginning ofomap_dss_deviceare things which define the interface etc, and later there are miscallaneous dynamic things. And this belongs to the former.Now, if we have the channel defined in this way in the
omap_dss_device, I'm wondering if:
1) the manager pointer is needed at all, as the channel tells which manager it is? 2) if we keep the manager pointer (as a helper shortcut), should the code use generally use
dssdev->channelordssdev->manager->id?I think
manager->idmakes more sense considering your logic below.Quoted 3 lines
3) having this channel field requires a change to every board file, because the channel has to be defined?
Yes, that is something that has to be done for all 'DIGIT' panels across all boards.
Quoted 7 lines
And answering to myself, I guess the manager pointer is needed, because DSS2 supports (at least in theory) multiple panels in the same interface (not at the same time, of course). This means that we could have to panels, with the same interface and channel, but only one would be in use. So the one in use should have manager pointing to the correct manager, and the other would have manager NULL.
Yes, passing
dssdev->channelwould make things worse if 2 panels are connected to same interface.Quoted 6 lines
And thus perhaps using
dssdev->channelonly for connecting the right manager to right panel, and usingdssdev->manager->idfor other uses would be the best? The values would of course be the same, but at least we'd get a crash if somehow an unconnected display is being used for configuration.Even in the current kernel on 3430sdp, the board file adds
sharp_ls, venc and generic panels If I boot up with venc as default display, mgr0 has dvi as its display and mgr1 has tv. So if I try to enablesharp_lspanel I get a crash when we first try to accessdssdev->managerindpi_display_enable(). We should have a way to prevent enabling a panel if it isn't connected to a manager. We should also have a way to allow a panel to have no channel at all (something likeOMAP_DSS_CHANNEL_NONE) if we are using something like dsi l4 update.
Quoted 3 lines
I won't add this extra channel now though, we need to think of a better way later.
Also, do you think when a display unsets a manager and sets a new manager the channel should be changed? Or should it purely be a one time thing for choosing the correct manager and not use it anywhere else?
Thanks,
Archit
Quoted 10 lines
Quoted 1 line
Does this make sense?
Yes, it does, I'll make these changes, and more if you can think of any.
Archit--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at
http://vger.kernel.org/majordomo-info.html
PATCH v4 4/7 OMAP: DSS2: Change remaining Dispc functions for new 'channel' argument
In reply to Archit TanejaFrom: Sumit Semwal <[email protected]>
The following dispc functions are changed to incorporate channel as an argument:
-dispc_lclk_rate() -dispc_pclk_rate() -dispc_set_pol_freq() -dispc_set_clock_div() -dispc_get_clock_div()
--- drivers/video/omap2/dss/dispc.c | 62 ++++++++++++++++++++++----------------- drivers/video/omap2/dss/dpi.c | 22 +++++++------ drivers/video/omap2/dss/dsi.c | 8 ++-- drivers/video/omap2/dss/dss.h | 13 +++++--- drivers/video/omap2/dss/sdi.c | 8 ++-- 5 files changed, 63 insertions(+), 50 deletions(-)
drivers/video/omap2/dss/dispc.c +35 -27
@@ -1442,12 +1442,13 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror, } } -static unsigned long calc_fclk_five_taps (u16 width,u16 height, -u16 out_width,u16 out_height,enum omap_color_mode color_mode) +static unsigned long calc_fclk_five_taps (enum omap_channel channel,u16 width, +u16 height,u16 out_width,u16 out_height, +enum omap_color_mode color_mode) {u32 fclk =0 ;/* FIXME venc pclk? */ -u64 tmp, pclk =dispc_pclk_rate (); +u64 tmp, pclk =dispc_pclk_rate (channel);if (height > out_height) {/* FIXME get real display PPL */
@@ -1479,8 +1480,8 @@ static unsigned long calc_fclk_five_taps(u16 width, u16 height,return fclk; } -static unsigned long calc_fclk (u16 width,u16 height, -u16 out_width,u16 out_height) +static unsigned long calc_fclk (enum omap_channel channel,u16 width, +u16 height,u16 out_width,u16 out_height) {unsigned int hf, vf;
@@ -1504,7 +1505,7 @@ static unsigned long calc_fclk(u16 width, u16 height, vf =1 ;/* FIXME venc pclk? */ -return dispc_pclk_rate () * vf * hf; +return dispc_pclk_rate (channel) * vf * hf; }void dispc_set_channel_out (enum omap_plane plane,enum omap_channel channel_out)
@@ -1623,7 +1624,7 @@ static int _dispc_setup_plane(enum omap_plane plane, five_taps = height > out_height *2 ;if (!five_taps) { - fclk =calc_fclk (width, height, + fclk =calc_fclk (OMAP_DSS_CHANNEL_LCD , width, height, out_width, out_height);/* Try 5-tap filter if 3-tap fclk is too high */
@@ -1638,8 +1639,9 @@ static int _dispc_setup_plane(enum omap_plane plane, }if (five_taps) - fclk =calc_fclk_five_taps (width, height, - out_width, out_height, color_mode); + fclk =calc_fclk_five_taps (OMAP_DSS_CHANNEL_LCD , width, + height, out_width, out_height, + color_mode);DSSDBG ("required fclk rate = %lu Hz\n" , fclk);DSSDBG ("current fclk rate = %lu Hz\n" ,dispc_fclk_rate ());
@@ -2200,13 +2202,14 @@ void dispc_set_lcd_timings(enum omap_channel channel,DSSDBG ("hsync %luHz, vsync %luHz\n" , ht, vt); } -static void dispc_set_lcd_divisor (u16 lck_div,u16 pck_div) +static void dispc_set_lcd_divisor (enum omap_channel channel,u16 lck_div, +u16 pck_div) {BUG_ON (lck_div <1 );BUG_ON (pck_div <2 );enable_clocks (1 ); -dispc_write_reg (DISPC_DIVISOR (OMAP_DSS_CHANNEL_LCD ), +dispc_write_reg (DISPC_DIVISOR (channel),FLD_VAL (lck_div,23 ,16 ) |FLD_VAL (pck_div,7 ,0 ));enable_clocks (0 ); }
@@ -2234,13 +2237,13 @@ unsigned long dispc_fclk_rate(void)return r; } -unsigned long dispc_lclk_rate (void ) +unsigned long dispc_lclk_rate (enum omap_channel channel) {int lcd;unsigned long r;u32 l; - l =dispc_read_reg (DISPC_DIVISOR (OMAP_DSS_CHANNEL_LCD )); + l =dispc_read_reg (DISPC_DIVISOR (channel)); lcd =FLD_GET (l,23 ,16 );
@@ -2249,13 +2252,13 @@ unsigned long dispc_lclk_rate(void)return r / lcd; } -unsigned long dispc_pclk_rate (void ) +unsigned long dispc_pclk_rate (enum omap_channel channel) {int lcd, pcd;unsigned long r;u32 l; - l =dispc_read_reg (DISPC_DIVISOR (OMAP_DSS_CHANNEL_LCD )); + l =dispc_read_reg (DISPC_DIVISOR (channel)); lcd =FLD_GET (l,23 ,16 ); pcd =FLD_GET (l,7 ,0 );
@@ -2280,8 +2283,10 @@ void dispc_dump_clocks(struct seq_file *s) "dss1_alwon_fclk" : "dsi1_pll_fclk"); seq_printf(s,"fck\t\t%-16lu\n" ,dispc_fclk_rate ()); -seq_printf (s,"lck\t\t%-16lulck div\t%u\n" ,dispc_lclk_rate (), lcd); -seq_printf (s,"pck\t\t%-16lupck div\t%u\n" ,dispc_pclk_rate (), pcd); +seq_printf (s,"lck\t\t%-16lulck div\t%u\n" , +dispc_lclk_rate (OMAP_DSS_CHANNEL_LCD ), lcd); +seq_printf (s,"pck\t\t%-16lupck div\t%u\n" , +dispc_pclk_rate (OMAP_DSS_CHANNEL_LCD ), pcd);enable_clocks (0 ); }
@@ -2473,8 +2478,8 @@ void dispc_dump_regs(struct seq_file *s)#undef DUMPREG } -static void _dispc_set_pol_freq (bool onoff,bool rf,bool ieo,bool ipc, -bool ihs,bool ivs,u8 acbi,u8 acb) +static void _dispc_set_pol_freq (enum omap_channel channel,bool onoff,bool rf, +bool ieo,bool ipc,bool ihs,bool ivs,u8 acbi,u8 acb) {u32 l =0 ;
@@ -2491,13 +2496,14 @@ static void _dispc_set_pol_freq(bool onoff, bool rf, bool ieo, bool ipc, l |=FLD_VAL (acb,7 ,0 );enable_clocks (1 ); -dispc_write_reg (DISPC_POL_FREQ (OMAP_DSS_CHANNEL_LCD ), l); +dispc_write_reg (DISPC_POL_FREQ (channel), l);enable_clocks (0 ); } -void dispc_set_pol_freq (enum omap_panel_config config,u8 acbi,u8 acb) +void dispc_set_pol_freq (enum omap_channel channel, +enum omap_panel_config config,u8 acbi,u8 acb) { - _dispc_set_pol_freq((config & OMAP_DSS_LCD_ONOFF) != 0, + _dispc_set_pol_freq(channel, (config & OMAP_DSS_LCD_ONOFF) != 0, (config & OMAP_DSS_LCD_RF) != 0, (config & OMAP_DSS_LCD_IEO) != 0, (config & OMAP_DSS_LCD_IPC) != 0,
@@ -2566,24 +2572,26 @@ int dispc_calc_clock_rates(unsigned long dispc_fclk_rate,return 0 ; } -int dispc_set_clock_div (struct dispc_clock_info *cinfo) +int dispc_set_clock_div (enum omap_channel channel, +struct dispc_clock_info *cinfo) {DSSDBG ("lck = %lu (%u)\n" , cinfo->lck, cinfo->lck_div);DSSDBG ("pck = %lu (%u)\n" , cinfo->pck, cinfo->pck_div); -dispc_set_lcd_divisor (cinfo->lck_div, cinfo->pck_div); +dispc_set_lcd_divisor (channel, cinfo->lck_div, cinfo->pck_div);return 0 ; } -int dispc_get_clock_div (struct dispc_clock_info *cinfo) +int dispc_get_clock_div (enum omap_channel channel, +struct dispc_clock_info *cinfo) {unsigned long fck; fck =dispc_fclk_rate (); - cinfo->lck_div =REG_GET (DISPC_DIVISOR (OMAP_DSS_CHANNEL_LCD ),23 ,16 ); - cinfo->pck_div =REG_GET (DISPC_DIVISOR (OMAP_DSS_CHANNEL_LCD ),7 ,0 ); + cinfo->lck_div =REG_GET (DISPC_DIVISOR (channel),23 ,16 ); + cinfo->pck_div =REG_GET (DISPC_DIVISOR (channel),7 ,0 ); cinfo->lck = fck / cinfo->lck_div; cinfo->pck = cinfo->lck / cinfo->pck_div;
drivers/video/omap2/dss/dpi.c +12 -10
@@ -40,8 +40,9 @@ static struct { } dpi;#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL -static int dpi_set_dsi_clk (bool is_tft,unsigned long pck_req, -unsigned long *fck,int *lck_div,int *pck_div) +static int dpi_set_dsi_clk (enum omap_channel channel,bool is_tft, +unsigned long pck_req,unsigned long *fck,int *lck_div, +int *pck_div) {struct dsi_clock_info dsi_cinfo;struct dispc_clock_info dispc_cinfo;
@@ -58,7 +59,7 @@ static int dpi_set_dsi_clk(bool is_tft, unsigned long pck_req,dss_select_dispc_clk_source (DSS_SRC_DSI1_PLL_FCLK ); - r =dispc_set_clock_div (&dispc_cinfo); + r =dispc_set_clock_div (channel, &dispc_cinfo);if (r)return r;
@@ -69,8 +70,9 @@ static int dpi_set_dsi_clk(bool is_tft, unsigned long pck_req, return 0; }#else -static int dpi_set_dispc_clk (bool is_tft,unsigned long pck_req, -unsigned long *fck,int *lck_div,int *pck_div) +static int dpi_set_dispc_clk (enum omap_channel channel,bool is_tft, +unsigned long pck_req,unsigned long *fck,int *lck_div, +int *pck_div) {struct dss_clock_info dss_cinfo;struct dispc_clock_info dispc_cinfo;
@@ -84,7 +86,7 @@ static int dpi_set_dispc_clk(bool is_tft, unsigned long pck_req,if (r)return r; - r =dispc_set_clock_div (&dispc_cinfo); + r =dispc_set_clock_div (channel, &dispc_cinfo);if (r)return r;
@@ -107,16 +109,16 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)dss_clk_enable (DSS_CLK_ICK |DSS_CLK_FCK1 ); -dispc_set_pol_freq (dssdev->panel.config, dssdev->panel.acbi, - dssdev->panel.acb); +dispc_set_pol_freq (dssdev->channel, dssdev->panel.config, + dssdev->panel.acbi, dssdev->panel.acb); is_tft = (dssdev->panel.config &OMAP_DSS_LCD_TFT ) !=0 ;#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL - r =dpi_set_dsi_clk (is_tft, t->pixel_clock *1000 , + r =dpi_set_dsi_clk (dssdev->channel, is_tft, t->pixel_clock *1000 , &fck, &lck_div, &pck_div);#else - r =dpi_set_dispc_clk (is_tft, t->pixel_clock *1000 , + r =dpi_set_dispc_clk (dssdev->channel, is_tft, t->pixel_clock *1000 , &fck, &lck_div, &pck_div);#endif if (r)
drivers/video/omap2/dss/dsi.c +4 -4
@@ -812,7 +812,7 @@ static int dsi_calc_clock_rates(struct dsi_clock_info *cinfo)* with DSS2_FCK source also */ cinfo->highfreq =0 ; }else { - cinfo->clkin =dispc_pclk_rate (); + cinfo->clkin =dispc_pclk_rate (OMAP_DSS_CHANNEL_LCD );if (cinfo->clkin <32000000 ) cinfo->highfreq =0 ;
@@ -1206,8 +1206,8 @@ void dsi_dump_clocks(struct seq_file *s)seq_printf (s,"VP_CLK\t\t%lu\n" "VP_PCLK\t\t%lu\n" , -dispc_lclk_rate (), -dispc_pclk_rate ()); +dispc_lclk_rate (OMAP_DSS_CHANNEL_LCD ), +dispc_pclk_rate (OMAP_DSS_CHANNEL_LCD ));enable_clocks (0 ); }
@@ -3020,7 +3020,7 @@ static int dsi_configure_dispc_clocks(struct omap_dss_device *dssdev)return r; } - r =dispc_set_clock_div (&dispc_cinfo); + r =dispc_set_clock_div (dssdev->channel, &dispc_cinfo);if (r) {DSSERR ("Failed to set dispc clocks\n" );return r;
drivers/video/omap2/dss/dss.h +8 -5
@@ -393,15 +393,18 @@ bool dispc_lcd_timings_ok(struct omap_video_timings *timings);void dispc_set_lcd_timings (enum omap_channel channel,struct omap_video_timings *timings);unsigned long dispc_fclk_rate (void ); -unsigned long dispc_lclk_rate (void ); -unsigned long dispc_pclk_rate (void ); -void dispc_set_pol_freq (enum omap_panel_config config,u8 acbi,u8 acb); +unsigned long dispc_lclk_rate (enum omap_channel channel); +unsigned long dispc_pclk_rate (enum omap_channel channel); +void dispc_set_pol_freq (enum omap_channel channel, +enum omap_panel_config config,u8 acbi,u8 acb);void dispc_find_clk_divs (bool is_tft,unsigned long req_pck,unsigned long fck,struct dispc_clock_info *cinfo);int dispc_calc_clock_rates (unsigned long dispc_fclk_rate,struct dispc_clock_info *cinfo); -int dispc_set_clock_div (struct dispc_clock_info *cinfo); -int dispc_get_clock_div (struct dispc_clock_info *cinfo); +int dispc_set_clock_div (enum omap_channel channel, +struct dispc_clock_info *cinfo); +int dispc_get_clock_div (enum omap_channel channel, +struct dispc_clock_info *cinfo);/* VENC */
drivers/video/omap2/dss/sdi.c +4 -4
@@ -75,15 +75,15 @@ int omapdss_sdi_display_enable(struct omap_dss_device *dssdev)/* 15.5.9.1.2 */ dssdev->panel.config |=OMAP_DSS_LCD_RF |OMAP_DSS_LCD_ONOFF ; -dispc_set_pol_freq (dssdev->panel.config, dssdev->panel.acbi, - dssdev->panel.acb); +dispc_set_pol_freq (dssdev->channel, dssdev->panel.config, + dssdev->panel.acbi, dssdev->panel.acb);if (!sdi.skip_init) { r =dss_calc_clock_div (1 , t->pixel_clock *1000 , &dss_cinfo, &dispc_cinfo); }else { r =dss_get_clock_div (&dss_cinfo); - r =dispc_get_clock_div (&dispc_cinfo); + r =dispc_get_clock_div (dssdev->channel, &dispc_cinfo); }if (r)
@@ -110,7 +110,7 @@ int omapdss_sdi_display_enable(struct omap_dss_device *dssdev)if (r) goto err2; - r =dispc_set_clock_div (&dispc_cinfo); + r =dispc_set_clock_div (dssdev->channel, &dispc_cinfo);if (r) goto err2;
Signature · 1 line
1.7.0.4
PATCH v4 5/7 OMAP: DSS2: LCD2 Channel Changes for DISPC
In reply to Archit TanejaFrom: Sumit Semwal <[email protected]>
Modify DISPC functions to work with LCD2 as the DISPC Channel.
--- arch/arm/plat-omap/include/plat/display.h | 4 + drivers/video/omap2/dss/dispc.c | 216 +++++++++++++++++++++++++---- 2 files changed, 191 insertions(+), 29 deletions(-)
arch/arm/plat-omap/include/plat/display.h +4 -0
@@ -42,6 +42,10 @@#define DISPC_IRQ_SYNC_LOST (1 << 14)#define DISPC_IRQ_SYNC_LOST_DIGIT (1 << 15)#define DISPC_IRQ_WAKEUP (1 << 16) +#define DISPC_IRQ_SYNC_LOST2 (1 << 17) +#define DISPC_IRQ_VSYNC2 (1 << 18) +#define DISPC_IRQ_ACBIAS_COUNT_STAT2 (1 << 21) +#define DISPC_IRQ_FRAMEDONE2 (1 << 22)struct omap_dss_device ;struct omap_overlay_manager ;
drivers/video/omap2/dss/dispc.c +187 -29
444 lines not on this page · raw message
Signature · 1 line
1.7.0.4
PATCH v4 6/7 OMAP: DSS2: Use dss_features to handle DISPC bits removed on OMAP4
In reply to Archit TanejaDISPC_CONFIG bits LCDENABLEPOL, LCDENABLESIGNAL, PCKFREEENABLE and FUNCGATED have been removed from OMAP4, use dss_features to handle them correctly.
--- drivers/video/omap2/dss/dispc.c | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-)
drivers/video/omap2/dss/dispc.c +11 -1
@@ -1942,6 +1942,9 @@ void dispc_enable_channel(enum omap_channel channel, bool enable)void dispc_lcd_enable_signal_polarity (bool act_high) { +if (!dss_has_feature (FEAT_LCDENABLEPOL )) +return ; +enable_clocks (1 );REG_FLD_MOD (DISPC_CONTROL (OMAP_DSS_CHANNEL_LCD ), act_high ?1 :0 ,29 ,29 );
@@ -1950,6 +1953,9 @@ void dispc_lcd_enable_signal_polarity(bool act_high)void dispc_lcd_enable_signal (bool enable) { +if (!dss_has_feature (FEAT_LCDENABLESIGNAL )) +return ; +enable_clocks (1 );REG_FLD_MOD (DISPC_CONTROL (OMAP_DSS_CHANNEL_LCD ), enable ?1 :0 ,28 ,28 );
@@ -1958,6 +1964,9 @@ void dispc_lcd_enable_signal(bool enable)void dispc_pck_free_enable (bool enable) { +if (!dss_has_feature (FEAT_PCKFREEENABLE )) +return ; +enable_clocks (1 );REG_FLD_MOD (DISPC_CONTROL (OMAP_DSS_CHANNEL_LCD ), enable ?1 :0 ,27 ,27 );
@@ -3246,7 +3255,8 @@ static void _omap_dispc_initial_config(void)dispc_write_reg (DISPC_SYSCONFIG , l);/* FUNCGATED */ -REG_FLD_MOD (DISPC_CONFIG (OMAP_DSS_CHANNEL_LCD ),1 ,9 ,9 ); +if (dss_has_feature (FEAT_FUNCGATED )) +REG_FLD_MOD (DISPC_CONFIG (OMAP_DSS_CHANNEL_LCD ),1 ,9 ,9 );/* L3 firewall setting: enable access to OCM RAM */ /* XXX this should be somewhere in plat-omap */
Signature · 1 line
1.7.0.4
PATCH v4 7/7 OMAP: DSS2: Add new Overlay Manager
In reply to Archit TanejaFrom: Sumit Semwal <[email protected]>
Add new Overlay Manager in manager.c, make changes needed for LCD2 channel.
--- drivers/video/omap2/dss/dispc.c | 21 +++++------ drivers/video/omap2/dss/dss.h | 4 +- drivers/video/omap2/dss/manager.c | 73 +++++++++++++++++++++++-------------- drivers/video/omap2/dss/overlay.c | 14 ++++++- 4 files changed, 70 insertions(+), 42 deletions(-)
drivers/video/omap2/dss/dispc.c +10 -11
@@ -1592,8 +1592,8 @@ static int _dispc_setup_plane(enum omap_plane plane,bool ilace, enum omap_dss_rotation_type rotation_type, u8 rotation, int mirror, - u8 global_alpha, - u8 pre_mult_alpha) + u8 global_alpha, u8 pre_mult_alpha, + enum omap_channel channel) { const int maxdownscale = cpu_is_omap34xx() ? 4 : 2;bool five_taps =0 ;
@@ -1692,8 +1692,8 @@ static int _dispc_setup_plane(enum omap_plane plane, five_taps = height > out_height *2 ;if (!five_taps) { - fclk =calc_fclk (OMAP_DSS_CHANNEL_LCD , width, height, - out_width, out_height); + fclk =calc_fclk (channel, width, height, out_width, + out_height);/* Try 5-tap filter if 3-tap fclk is too high */ if (cpu_is_omap34xx() && height > out_height &&
@@ -1707,9 +1707,8 @@ static int _dispc_setup_plane(enum omap_plane plane, }if (five_taps) - fclk =calc_fclk_five_taps (OMAP_DSS_CHANNEL_LCD , width, - height, out_width, out_height, - color_mode); + fclk =calc_fclk_five_taps (channel, width, height, + out_width, out_height, color_mode);DSSDBG ("required fclk rate = %lu Hz\n" , fclk);DSSDBG ("current fclk rate = %lu Hz\n" ,dispc_fclk_rate ());
@@ -3331,17 +3330,17 @@ int dispc_setup_plane(enum omap_plane plane,bool ilace, enum omap_dss_rotation_type rotation_type, u8 rotation, bool mirror, u8 global_alpha, - u8 pre_mult_alpha) + u8 pre_mult_alpha, enum omap_channel channel) { int r = 0;DSSDBG ("dispc_setup_plane %d, pa %x, sw %d, %d,%d, %dx%d -> " -"%dx%d, ilace %d, cmode %x, rot %d, mir %d\n" , +"%dx%d, ilace %d, cmode %x, rot %d, mir %d chan %d\n" , plane, paddr, screen_width, pos_x, pos_y, width, height, out_width, out_height, ilace, color_mode, - rotation, mirror); + rotation, mirror, channel);enable_clocks (1 );
@@ -3354,7 +3353,7 @@ int dispc_setup_plane(enum omap_plane plane, rotation_type, rotation, mirror, global_alpha, - pre_mult_alpha); + pre_mult_alpha, channel);enable_clocks (0 );
drivers/video/omap2/dss/dss.h +2 -2
@@ -359,8 +359,8 @@ int dispc_setup_plane(enum omap_plane plane,bool ilace, enum omap_dss_rotation_type rotation_type, u8 rotation, bool mirror, - u8 global_alpha, - u8 pre_mult_alpha); + u8 global_alpha, u8 pre_mult_alpha, + enum omap_channel channel);bool dispc_go_busy (enum omap_channel channel);void dispc_go (enum omap_channel channel);
drivers/video/omap2/dss/manager.c +46 -27
157 lines not on this page · raw message
drivers/video/omap2/dss/overlay.c +12 -2
@@ -664,12 +664,22 @@ void dss_recheck_connections(struct omap_dss_device *dssdev, bool force)int i;struct omap_overlay_manager *lcd_mgr;struct omap_overlay_manager *tv_mgr; +struct omap_overlay_manager *lcd2_mgr =NULL ;struct omap_overlay_manager *mgr =NULL ; lcd_mgr =omap_dss_get_overlay_manager (OMAP_DSS_OVL_MGR_LCD ); tv_mgr =omap_dss_get_overlay_manager (OMAP_DSS_OVL_MGR_TV ); - -if (dssdev->type !=OMAP_DISPLAY_TYPE_VENC ) { +if (dss_has_feature (FEAT_MGR_LCD2 )) + lcd2_mgr =omap_dss_get_overlay_manager (OMAP_DSS_OVL_MGR_LCD2 ); + +if (dssdev->channel ==OMAP_DSS_CHANNEL_LCD2 ) { +if (!lcd2_mgr->device || force) { +if (lcd2_mgr->device) + lcd2_mgr->unset_device (lcd2_mgr); + lcd2_mgr->set_device (lcd2_mgr, dssdev); + mgr = lcd2_mgr; + } + }else if (dssdev->type !=OMAP_DISPLAY_TYPE_VENC ) {if (!lcd_mgr->device || force) {if (lcd_mgr->device) lcd_mgr->unset_device (lcd_mgr);
Signature · 1 line
1.7.0.4