On Mon, Feb 28, 2011 at 9:33 PM, Tomi Valkeinen <tomi.valkei...@ti.com> wrote:
> On Mon, 2011-02-28 at 09:02 -0600, Semwal, Sumit wrote:
>> Provide a function in pdata to allow dss submodules to check if a given
>> clock is available on a platform as an optional clock.
>>
>> Signed-off-by: Senthilvadivu Guruswamy <svad...@ti.com>
>> (based on implementation from Senthil)
>>
>> Signed-off-by: Sumit Semwal <sumit.sem...@ti.com>
>> ---
>>  arch/arm/mach-omap2/display.c             |   20 ++++++++++++++++++++
>>  arch/arm/plat-omap/include/plat/display.h |    2 ++
>>  2 files changed, 22 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
>> index 5ab6a74..9f4f862 100644
>> --- a/arch/arm/mach-omap2/display.c
>> +++ b/arch/arm/mach-omap2/display.c
>> @@ -42,6 +42,25 @@ static struct omap_device_pm_latency omap_dss_latency[] = 
>> {
>>       },
>>  };
>>
>> +static bool opt_clock_available(const char *clk_role)
>> +{
>> +     int i;
>> +     struct omap_hwmod *oh;
>> +
>> +     /* opt_clks are always associated with dss hwmod */
>> +     oh = omap_hwmod_lookup("dss_core");
>> +     if (!oh) {
>> +             pr_err("Could not look up dss_core.\n");
>> +             return -ENODEV;
>
> The function returns a bool. Perhaps the lookup would be better done in
> omap_display_init(), and stored in a static variable.
Yes; I guess I should go with your earlier suggestion - of keeping
this 'oh' as part of pdata, and then use it here.
>
> Or if it's clear that this should never happen, BUG_ON(!oh);
Well, multiple people have 'frowned' upon using BUG_ON in dss -
especially because some people might still want their kernel to keep
working despite a display failure?

~Sumit.
>
>  Tomi
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to