On 2013-03-11 07:53, Archit Taneja wrote:
> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
>> The DISPC channel used for each output is currently passed in panel
>> platform data from the board files.
>>
>> To simplify this, and to make the panel drivers less dependent on OMAP,
>> this patch changes omapdss to resolve the channel independently. The
>> channel is resolved based on the OMAP version and, in case of DSI, the
>> DSI module id.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@xxxxxx>
>> ---
>> drivers/video/omap2/dss/dpi.c | 37 ++++++++++++++++++++++++++-----
>> drivers/video/omap2/dss/dsi.c | 48
>> ++++++++++++++++++++++++++++++++++++++++
>> drivers/video/omap2/dss/rfbi.c | 2 ++
>> drivers/video/omap2/dss/sdi.c | 2 ++
>> 4 files changed, 84 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dpi.c
>> b/drivers/video/omap2/dss/dpi.c
>> index e282456..3261644 100644
>> --- a/drivers/video/omap2/dss/dpi.c
>> +++ b/drivers/video/omap2/dss/dpi.c
>> @@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct
>> platform_device *dsidev)
>> return 0;
>> }
>>
>> +/*
>> + * Return a hardcoded channel for the DPI output. This should work for
>> + * current use cases, but this can be later expanded to either resolve
>> + * the channel in some more dynamic manner, or get the channel as a user
>> + * parameter.
>> + */
>> +static enum omap_channel dpi_get_channel(void)
>> +{
>> + switch (omapdss_get_version()) {
>> + case OMAPDSS_VER_OMAP24xx:
>> + case OMAPDSS_VER_OMAP34xx_ES1:
>> + case OMAPDSS_VER_OMAP34xx_ES3:
>> + case OMAPDSS_VER_OMAP3630:
>> + case OMAPDSS_VER_AM35xx:
>> + return OMAP_DSS_CHANNEL_LCD;
>> +
>> + case OMAPDSS_VER_OMAP4430_ES1:
>> + case OMAPDSS_VER_OMAP4430_ES2:
>> + case OMAPDSS_VER_OMAP4:
>> + return OMAP_DSS_CHANNEL_LCD2;
>> +
>> + case OMAPDSS_VER_OMAP5:
>> + return OMAP_DSS_CHANNEL_LCD2;
>> +
>> + default:
>> + DSSWARN("unsupported DSS version\n");
>> + return OMAP_DSS_CHANNEL_LCD;
>> + }
>> +}
>
> I had another comment for this patch. On OMAP5, it makes sense for us to
> not use LCD2 as the recommended channel. LCD2_CLK's only source is
> DSS_CLK from PRCM. So it's not a very flexible channel to use. We could
> use LCD3 (at the cost of not using DSI2).
Ok. Yes, this looks to be the case. I'll use LCD3 for DPI for now. In
the worst case we may need to pass some channel setup parameters via
omapdss DT data or platform data, but I'd really much like the driver to
be able to resolve the dispc channels by itself...
> We also need to fix dpi_get_dsidev() for OMAP5. Currently, it assumes
> that LCD2_CLK can be sourced from DSI2 PLL, we need to ensure DPI has a
> dsidev only if it's LCD1 or LCD3.
Right. I'll add if (OMAP5) there, and return DSI2 PLL for LCD3, and NULL
for LCD2.
Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
