On Fri, 2011-12-16 at 01:27 -0700, Paul Walmsley wrote: > On Fri, 16 Dec 2011, Tomi Valkeinen wrote: > > > But with DT we can't use func pointers in platform_data either, right? > > In the future, if someone wants to run a platform_data-less kernel, > they'll have to come up with a replacement mechanism for these. Several > replacements have been proposed internally, such as having an > omap_bus/omap_device for devices with OMAP-specific integration, but right > now there are more pressing crises to deal with... Ok. Benoit was telling me not to use pdata, so I thought it's a hard rule for DT. He didn't give me a clear alternative, though =). Ricardo, struct omap_dss_board_info already contains a few function pointers, for example get_context_loss_count. I think omap_hwmod_set_slave_idlemode can be handled the same way. Although I'm not sure should the function pointer be just "set_slave_idlemode", and thus just a direct way to call the hwmod func, or should it be something more use case specific, like, say "hdmi_audio_start/stop". I'm thinking it should be the latter. As far as I understand, the bug is not in the HDMI IP, but somewhere in the L3 side? And if so, it's not the HDMI driver's job to know how to fix the bug, but just to offer hooks so that the platform code can fix it. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
