On Tue, Mar 1, 2011 at 11:49 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
> On Mon, 2011-02-28 at 23:42 -0600, Semwal, Sumit wrote:
>> On Mon, Feb 28, 2011 at 9:33 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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 <svadivu@xxxxxx>
>> >> (based on implementation from Senthil)
>> >>
>> >> Signed-off-by: Sumit Semwal <sumit.semwal@xxxxxx>
>> >> ---
>> >> 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.
>
> I don't think it needs to be part of pdata. It's internal to this file,
> and if I'm not mistaken, omap_display_init() is called just once from
> the current board file. Thus the data could as well be stored in a
> static variable.
:) ok, that's correct; though we might need to make 'oh' part of pdata
based on our adaptation to the reset functionality - but that will
come later.
>
>> > 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?
>
> Yes, BUG is an easy, not good, way out =).
:) hmmm... should I just return 'false' and print out a warning?
>
> Tomi
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
