On Thu, Jun 07, 2012 at 10:02:51AM +0200, Cousson, Benoit wrote: > On 6/7/2012 9:55 AM, Felipe Balbi wrote: > >On Thu, Jun 07, 2012 at 12:51:58AM -0700, Tony Lindgren wrote: > >>* Paul Walmsley<paul@xxxxxxxxx> [120607 00:44]: > >>>On Thu, 7 Jun 2012, Tony Lindgren wrote: > >>> > >>>>Here too I think driver like features like this should live in the > >>>>driver init for omap OHCI driver. In the likely case that FS OHCI is > >>>>not in use on the board, the OHCI glue can just reset it. > >>> > >>>What if the driver is not compiled into the kernel, but instead is built > >>>as a loadable module? > >> > >>You can still have a core piece of the driver that's always built in, such > >>as omap-ohci-common. But it should live under drivers, not in the bus level > >>code. Or you can insmod/rmmod it to reset things properly. > > > >that's such a hack... both solutions are quite hacky. The only problem > >here is because some bootloaders are leaving controller in an unknown > >state and I guess to be completely safe, resets should be done before > >any driver kicks in. > > > >But, driver will probably reset again the IP block during probe... > > Ideally it should be done only in the probe if needed. In the case of > the DSS, the bootloader can init it with a splash screen and we do > not want to blindly reset it and thus produce some ugly artifact on > the screen. > > In fact we should delay the reset to the very last moment and > potentially reset the IPs not under driver control later after a > couple of second for example. > It will avoid reseting every IP that will be handled properly by drivers. you could have a late_initcall() that will iterate over hwmods and reset the ones which aren't used. That would mean adding some extra code to omap_device_build_ss() which would set a flag on each hwmod, or something similar. -- balbi
Attachment:
signature.asc
Description: Digital signature
