[U-Boot] [PATCH RESEND 7/9] video: Allow board hook before video init

[Simon Glass]

Hi Maxime,

On 6 December 2016 at 12:39, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> On Wed, Nov 23, 2016 at 07:21:07PM -0700, Simon Glass wrote:
>> Hi Maxime,
>>
>> On 22 November 2016 at 05:41, Maxime Ripard
>> <maxime.ripard at free-electrons.com> wrote:
>> > Hi Simon,
>> >
>> > On Mon, Nov 14, 2016 at 01:44:45PM -0700, Simon Glass wrote:
>> >> Hi Maxime,
>> >>
>> >> On 14 November 2016 at 13:24, Maxime Ripard
>> >> <maxime.ripard at free-electrons.com> wrote:
>> >> > Hi Simon,
>> >> >
>> >> > On Fri, Nov 11, 2016 at 09:17:28AM -0700, Simon Glass wrote:
>> >> >> Hi Maxime,
>> >> >>
>> >> >> On 8 November 2016 at 03:19, Maxime Ripard
>> >> >> <maxime.ripard at free-electrons.com> wrote:
>> >> >> > Some boards might need to some additional setup right before initialising
>> >> >> > the video console.
>> >> >> >
>> >> >> > Add some hook to allow that.
>> >> >>
>> >> >> Instead of this, can you use driver model (UCLASS_VIDEO)?
>> >> >
>> >> > I don't really know the device model that well, hence 'm not really
>> >> > sure how would that help. Can a board register a hook to be called
>> >> > before a driver is probed?
>> >>
>> >> My suggest would be that the driver can do whatever is required. What
>> >> is the board-specific code actually wanting to do?
>> >
>> > We need to adjust the video-mode environment variable that is going to
>> > be used in the driver's initialisation. We're doing that by
>> > identifying which daughter board is attached, and then setting that
>> > value according to the display output we want to use.
>> >
>> > So we need some hook that would run between the environment
>> > initialisation and the video driver's init.
>>
>> As an example of how you might pass platform data to the video driver,
>> see board_init() in gurnard.c.
>
> That's very useful, thanks!
>
> Can you also postpone the probe of one driver, or at least defer a
> driver's probe until some other is done?

Well a device is not probed until it is used (or at least that is how
it is supposed to work).

So perhaps you can probe the device in the driver that needs it? For
example, if video probe needs GPIOs you can probe the GPIOs
automatically (e.g. if you use something like gpio_request_by_name()
in your video probe()).

>
> The way we identify the daughter boards also rely on some driver in
> the device model (a 1-Wire EEPROM, connected on a GPIO, both of them
> also being part of the device model), so we need to defer the video
> driver probe until both of them have been probed and accessed.
>

Regards,
Simon