diff mbox

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

Message ID 7adfd1c9f64968e10fe639dae0b66b290100639b.1478600213.git-series.maxime.ripard@free-electrons.com
State Deferred
Delegated to: Tom Rini
Headers show

Commit Message

Maxime Ripard Nov. 8, 2016, 10:19 a.m. UTC
Some boards might need to some additional setup right before initialising
the video console.

Add some hook to allow that.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/video/cfb_console.c |  9 +++++++++
 1 file changed, 9 insertions(+), 0 deletions(-)

Comments

Simon Glass Nov. 11, 2016, 4:17 p.m. UTC | #1
Hi Maxime,

On 8 November 2016 at 03:19, Maxime Ripard
<maxime.ripard@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)?

>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  drivers/video/cfb_console.c |  9 +++++++++
>  1 file changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
> index c0b1b8dc17e2..724ae16c5a9b 100644
> --- a/drivers/video/cfb_console.c
> +++ b/drivers/video/cfb_console.c
> @@ -2119,6 +2119,11 @@ __weak int board_video_skip(void)
>         return 0;
>  }
>
> +__weak int board_video_pre_init(void)
> +{
> +       return 0;
> +}
> +
>  int drv_video_init(void)
>  {
>         struct stdio_dev console_dev;
> @@ -2129,6 +2134,10 @@ int drv_video_init(void)
>         if (board_video_skip())
>                 return 0;
>
> +       /* Allow the board to setup a few things */
> +       if (board_video_pre_init())
> +               return 0;
> +
>         /* Init video chip - returns with framebuffer cleared */
>         if (cfg_video_init() == -1)
>                 return 0;
> --
> git-series 0.8.11

Regards,
SImon
Maxime Ripard Nov. 14, 2016, 8:24 p.m. UTC | #2
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@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?

Thanks!
Maxime
Simon Glass Nov. 14, 2016, 8:44 p.m. UTC | #3
Hi Maxime,

On 14 November 2016 at 13:24, Maxime Ripard
<maxime.ripard@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@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?

Regards,
Simon
Maxime Ripard Nov. 22, 2016, 12:41 p.m. UTC | #4
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@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@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.

Maxime
Simon Glass Nov. 24, 2016, 2:21 a.m. UTC | #5
Hi Maxime,

On 22 November 2016 at 05:41, Maxime Ripard
<maxime.ripard@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@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@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.

Regards,
Simon
Maxime Ripard Dec. 6, 2016, 5:39 p.m. UTC | #6
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@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@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@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?

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.

Thanks!
Maxime
Simon Glass Dec. 8, 2016, 10:22 p.m. UTC | #7
Hi Maxime,

On 6 December 2016 at 12:39, Maxime Ripard
<maxime.ripard@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@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@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@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
diff mbox

Patch

diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index c0b1b8dc17e2..724ae16c5a9b 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -2119,6 +2119,11 @@  __weak int board_video_skip(void)
 	return 0;
 }
 
+__weak int board_video_pre_init(void)
+{
+	return 0;
+}
+
 int drv_video_init(void)
 {
 	struct stdio_dev console_dev;
@@ -2129,6 +2134,10 @@  int drv_video_init(void)
 	if (board_video_skip())
 		return 0;
 
+	/* Allow the board to setup a few things */
+	if (board_video_pre_init())
+		return 0;
+
 	/* Init video chip - returns with framebuffer cleared */
 	if (cfg_video_init() == -1)
 		return 0;