[PATCH v4] ARM: prima2: move to generic reset controller driver framework

[Barry Song]

2014/1/9 Arnd Bergmann <arnd at arndb.de>:
> On Thursday 09 January 2014, Barry Song wrote:
>> 2014/1/7 Arnd Bergmann <arnd at arndb.de>:
>> > On Tuesday 07 January 2014, Barry Song wrote:
>> >> > Can't this be a regular platform device? Drivers that get the reference to
>> >> > the reset controller should respect a -EPROBE_DEFER error message if they
>> >> > get initialized in the wrong order.
>> >>
>> >> Arnd, it is ok if prima2 is not a platform for automotive. here prima2
>> >> actually wants a "right" order for products.
>> >> for example, there are some local hacking to move camera for rearview
>> >> started earlier than other devices as this feature needs to be ready
>> >> as early as possible.
>> >> some earlier boot devices depend on reset module to be ready. so if we
>> >> move to regular platform driver for upstream, it still requires some
>> >> local hacking to move it earlier.
>> >
>> > I don't understand what you mean. It should be a matter of a few miliseconds
>> > at most to retry initialization, more likely in the microseconds. How big
>> > are the delays you are worried about?
>>
>> what i am worrried about is 100ms or more. device drivers need time to
>> initialize and that will take time, if some devices initialization
>> happen before the deferred probing, the deferred probing might be
>> delayed 100ms.
>> for example, we want camera begin to show rear-view in several
>> hundreds of ms, there are some local hacking to move i2c and camera
>> probe earlier than other devices.
>> that means actually there is requirement for right order of probing
>> but not defer probing sometimes.
>
> I see, this seems like a valid concern. I had not considered that other
> drivers might need more time for initialization. In general of course
> they should not, but I understand that hardware is not perfect and
> some drivers you don't own may have bugs that cause unnecessary delays.

the functionality of defer probing is really working. but embedded
systems with all kinds of hardware and various strange requirement
will want the "right" order.

>
> We have discussed probe ordering a lot of times on the mailing lists
> and also during the last kernel summit, but those discussions are usually
> focused on trying to correctly boot up a system, which is hard enough
> even without additional requirements like yours.
>
> Generally the hack that people use when things fail to work correctly
> is to hijack an earlier initcall level, e.g. subsys_initcall rather
> than using module_init. Please first see if that can solve your problem.
> If it doesn't help, please resubmit your current patch with a detailed
> description in the code on why you have to do it like this.

that is ok if it moves to subsys_initcall. some people might think
using subsys_initcall imports redundant function call for non-sirf
platform in multi-platform and machine-specific hook will not import
that :-)

>
>         Arnd

-barry