linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chandrabhanu Mahapatra <cmahapatra@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 1/4] OMAPDSS: Cleanup implementation of LCD channels
Date: Thu, 28 Jun 2012 11:31:05 +0000	[thread overview]
Message-ID: <4FEC3DA9.9010405@ti.com> (raw)
In-Reply-To: <1340880649.5037.39.camel@deskari>

On Thursday 28 June 2012 04:20 PM, Tomi Valkeinen wrote:
> On Thu, 2012-06-28 at 15:10 +0530, Chandrabhanu Mahapatra wrote:
>> The current implementation of LCD channels and managers consists of a number of
>> if-else construct which has been replaced by a simpler interface. A constant
>> structure mgr_desc has been created in Display Controller (DISPC) module. The
>> mgr_desc contains for each channel its name, irqs and  is initialized one time
>> with all registers and their corresponding fields to be written to enable
>> various features of Display Subsystem. This structure is later used by various
>> functions of DISPC which simplifies the further implementation of LCD channels
>> and its corresponding managers.
>>
>> Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
>> ---
>>  drivers/video/omap2/dss/dispc.c   |  233 +++++++++++++++++--------------------
>>  drivers/video/omap2/dss/dsi.c     |    6 +-
>>  drivers/video/omap2/dss/dss.h     |    6 +
>>  drivers/video/omap2/dss/manager.c |   12 +--
>>  4 files changed, 121 insertions(+), 136 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
>> index 4749ac3..6c16b81 100644
>> --- a/drivers/video/omap2/dss/dispc.c
>> +++ b/drivers/video/omap2/dss/dispc.c
>> @@ -57,6 +57,8 @@
>>  
>>  #define DISPC_MAX_NR_ISRS		8
>>  
>> +#define DISPC_MGR_FLD_MAX		9
> You could have this in the enum mgr_ref_fields, as a last entry. Then
> it'll automatically have the value 9, and will adjust automatically when
> we add new fields. And actually "MAX" is not quite right. MAX would be
> 8, as that's the maximum value for the vields. "NUM" is perhaps more
> correct.
Its really a clever idea to have it as the last field of enum
mgr_ref_fields. To make it distinct from other fields I can add a
comment on top of it saying its for count of above fields or I am fine
with names as DISPC_MGR_FLD_COUNT / NUM.
>  
>> +
>>  struct omap_dispc_isr_data {
>>  	omap_dispc_isr_t	isr;
>>  	void			*arg;
>> @@ -119,6 +121,78 @@ enum omap_color_component {
>>  	DISPC_COLOR_COMPONENT_UV		= 1 << 1,
>>  };
>>  
>> +enum mgr_reg_fields {
>> +	DISPC_MGR_FLD_ENABLE,
>> +	DISPC_MGR_FLD_STNTFT,
>> +	DISPC_MGR_FLD_GO,
>> +	DISPC_MGR_FLD_TFTDATALINES,
>> +	DISPC_MGR_FLD_STALLMODE,
>> +	DISPC_MGR_FLD_TCKENABLE,
>> +	DISPC_MGR_FLD_TCKSELECTION,
>> +	DISPC_MGR_FLD_CPR,
>> +	DISPC_MGR_FLD_FIFOHANDCHECK,
>> +};
>> +
>> +static const struct {
>> +	const char *name;
>> +	u32 vsync_irq;
>> +	u32 framedone_irq;
>> +	u32 sync_lost_irq;
>> +	struct reg_field reg_desc[DISPC_MGR_FLD_MAX];
>> +} mgr_desc[] = {
>> +	[OMAP_DSS_CHANNEL_LCD] = {
>> +		.name		= "LCD",
>> +		.vsync_irq	= DISPC_IRQ_VSYNC,
>> +		.framedone_irq	= DISPC_IRQ_FRAMEDONE,
>> +		.sync_lost_irq	= DISPC_IRQ_SYNC_LOST,
>> +		.reg_desc	= {
>> +			[DISPC_MGR_FLD_ENABLE]		= { DISPC_CONTROL,  0,  0 },
>> +			[DISPC_MGR_FLD_STNTFT]		= { DISPC_CONTROL,  3,  3 },
>> +			[DISPC_MGR_FLD_GO]		= { DISPC_CONTROL,  5,  5 },
>> +			[DISPC_MGR_FLD_TFTDATALINES]	= { DISPC_CONTROL,  9,  8 },
>> +			[DISPC_MGR_FLD_STALLMODE]	= { DISPC_CONTROL, 11, 11 },
>> +			[DISPC_MGR_FLD_TCKENABLE]	= { DISPC_CONFIG,  10, 10 },
>> +			[DISPC_MGR_FLD_TCKSELECTION]	= { DISPC_CONFIG,  11, 11 },
>> +			[DISPC_MGR_FLD_CPR]		= { DISPC_CONFIG,  15, 15 },
>> +			[DISPC_MGR_FLD_FIFOHANDCHECK]	= { DISPC_CONFIG,  16, 16 },
>> +		},
>> +	},
>> +	[OMAP_DSS_CHANNEL_DIGIT] = {
>> +		.name		= "DIGIT",
>> +		.vsync_irq	= DISPC_IRQ_EVSYNC_ODD | DISPC_IRQ_EVSYNC_EVEN,
>> +		.framedone_irq	= DISPC_IRQ_FRAMEDONETV,
> There's a problem with this one. FRAMEDONETV is a new thing, appeared in
> omap4. So for this we need a system to select the data depending on the
> DSS version.
>
> I suggest you remove the framedone_irq entry for now, and keep the old
> code to handle the framedone irq. Let's add it later when we can handle
> the differences between omap versions.
>
> Or actually, looking at the code, perhaps you can keep the framedone_irq
> field, but set it to 0 for DIGIT mgr. This would keep the functionality
> the same as it is now, because there's only one place in dispc.c where
> we use FRAMEDONETV, and your patch doesn't touch it. In other places we
> presume that TV out does not have FRAMEDONE interrupt (i.e. the irq
> number is 0).
The purpose of FRAMEDONETV IRQ as seen from dispc_mgr_enable_digit_out()
looks as to interrupt when active frame related to HDMI is done and so
DISPC is disabled. I think I misinterpreted  and used it here. Can
please explain the exact purpose of DISPC_IRQ_FRAMEDONETV?
>> +		.sync_lost_irq	= DISPC_IRQ_SYNC_LOST_DIGIT,
>> +		.reg_desc	= {
>> +			[DISPC_MGR_FLD_ENABLE]		= { DISPC_CONTROL,  1,  1 },
>> +			[DISPC_MGR_FLD_STNTFT]		= { },
>> +			[DISPC_MGR_FLD_GO]		= { DISPC_CONTROL,  6,  6 },
>> +			[DISPC_MGR_FLD_TFTDATALINES]	= { },
>> +			[DISPC_MGR_FLD_STALLMODE]	= { },
>> +			[DISPC_MGR_FLD_TCKENABLE]	= { DISPC_CONFIG,  12, 12 },
>> +			[DISPC_MGR_FLD_TCKSELECTION]	= { DISPC_CONFIG,  13, 13 },
>> +			[DISPC_MGR_FLD_CPR]		= { },
>> +			[DISPC_MGR_FLD_FIFOHANDCHECK]	= { DISPC_CONFIG,  16, 16 },
>> +		},
>> +	},
>> +	[OMAP_DSS_CHANNEL_LCD2] = {
>> +		.name		= "LCD2",
>> +		.vsync_irq	= DISPC_IRQ_VSYNC2,
>> +		.framedone_irq	= DISPC_IRQ_FRAMEDONE2,
>> +		.sync_lost_irq	= DISPC_IRQ_SYNC_LOST2,
>> +		.reg_desc	= {
>> +			[DISPC_MGR_FLD_ENABLE]		= { DISPC_CONTROL2,  0,  0 },
>> +			[DISPC_MGR_FLD_STNTFT]		= { DISPC_CONTROL2,  3,  3 },
>> +			[DISPC_MGR_FLD_GO]		= { DISPC_CONTROL2,  5,  5 },
>> +			[DISPC_MGR_FLD_TFTDATALINES]	= { DISPC_CONTROL2,  9,  8 },
>> +			[DISPC_MGR_FLD_STALLMODE]	= { DISPC_CONTROL2, 11, 11 },
>> +			[DISPC_MGR_FLD_TCKENABLE]	= { DISPC_CONFIG2,  10, 10 },
>> +			[DISPC_MGR_FLD_TCKSELECTION]	= { DISPC_CONFIG2,  11, 11 },
>> +			[DISPC_MGR_FLD_CPR]		= { DISPC_CONFIG2,  15, 15 },
>> +			[DISPC_MGR_FLD_FIFOHANDCHECK]	= { DISPC_CONFIG2,  16, 16 },
>> +		},
>> +	},
>> +};
>> +
>>  static void _omap_dispc_set_irqs(void);
>>  
>>  static inline void dispc_write_reg(const u16 idx, u32 val)
>> @@ -131,6 +205,19 @@ static inline u32 dispc_read_reg(const u16 idx)
>>  	return __raw_readl(dispc.base + idx);
>>  }
>>  
>> +static u32 mgr_fld_read(enum omap_channel channel, enum mgr_reg_fields regfld)
>> +{
>> +	const struct reg_field rfld = mgr_desc[channel].reg_desc[regfld];
>> +	return FLD_GET(dispc_read_reg(rfld.reg), rfld.high, rfld.low);
> This could use REG_GET(), instead of FLD_GET(dispc_read_reg(...))
ok.
>
>> +}
>> +
>> +static void mgr_fld_write(enum omap_channel channel,
>> +					enum mgr_reg_fields regfld, int val) {
>> +	const struct reg_field rfld = mgr_desc[channel].reg_desc[regfld];
>> +	dispc_write_reg(rfld.reg, FLD_MOD(dispc_read_reg(rfld.reg), val,
>> +				rfld.high, rfld.low));
>> +}
> And this one could use REG_FLD_MOD().
>
> Otherwise, looks good.
>
>  Tomi
>
ok.

-- 
Chandrabhanu Mahapatra
Texas Instruments India Pvt. Ltd.


  reply	other threads:[~2012-06-28 11:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-28  9:52 [PATCH 0/4] Add LCD3 channel support Chandrabhanu Mahapatra
2012-06-28  9:52 ` [PATCH 1/4] OMAPDSS: Cleanup implementation of LCD channels Chandrabhanu Mahapatra
2012-06-28 10:50   ` Tomi Valkeinen
2012-06-28 11:31     ` Chandrabhanu Mahapatra [this message]
2012-06-28 11:27       ` Tomi Valkeinen
2012-06-28 13:14   ` Chandrabhanu Mahapatra
2012-06-28  9:52 ` [PATCH 2/4] OMAPDSS: Add support for LCD3 channel Chandrabhanu Mahapatra
2012-06-28  9:53 ` [PATCH 3/4] OMAPDSS: Add LCD3 overlay manager and Clock and IRQ support Chandrabhanu Mahapatra
2012-06-28  9:53 ` [PATCH 4/4] OMAPDSS: Add dump and debug support for LCD3 Chandrabhanu Mahapatra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FEC3DA9.9010405@ti.com \
    --to=cmahapatra@ti.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tomi.valkeinen@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).