subject:"Re\: graphic drivers and simplefb"

On Thu, Apr 05, 2018 at 10:10:57AM -0300, Jared McNeill wrote:
> [...]
> 
> The serial port will only attach as console if you have chosen it to be the
> console (stdout-path). I want to solve this problem the right way, not
> relying on device attach order, because device order hacks become
> unmanageable when you are dealing with multiple SoC families, shared
> drivers, and GENERIC kernels.

if we want a kernel that supports multiple SoC families that's probably
true.

> 
> We need a solution that covers these use cases:
> 
>  - Console is UART (may or may not have display capabilities)
>  - Console is FB (laptop, tablet, etc where UART is difficult to access)
>  - Console device can be either UART or FB (like a dev board, where we
>support both with WSDISPLAY_MULTICONS)
> 
> Currently the armv7.img/arm64.img configs use 'console=fb' to get correct
> behavior in these 3 cases. This setup has been working well so far, but
> there is definite room for improvement. I just want to make sure that the
> existing functionality doesn't get broken.

The problem is that 'console=fb' relies on the fact that u-boot did
set up a /chosen/framebuffer node. But in my case it doesn't because
it doens't support my graphic setup. But, in my case, I could change
stdout-path in my device tree, and implement 'console=serial0' in bootargs
to reset it to serial port at boot time.

If I want to start with serial console and then switch to graphics,
I can change my kernel config to have the serial port probed sooner, for the
time being.

Would that be OK with you ?

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: graphic drivers and simplefb


On Thu, 5 Apr 2018, Manuel Bouyer wrote:


For simplefb I have everything I need..


OK, so in this case you'd want to have simplefb be the console,
until a more complete graphic driver attaches and take over
(much like we do with vga vs drm drivers in the x86 world).


Yeah maybe we should focus on that instead.


Boards exist where serial console is difficult or impossible to access. Lets
come up with a solution that satisfies all cases..


Sure. In this case I guess stdout-path will not be set to the serial port
though, so it should not use the serial port at all. I don't think we have
anything to change for this.

What I'm talking about is: stdout-path is set to the serial port, but
we have console=fb in the bootargs. In this case I think we could use
the serial port as console util the graphic driver (be it simplefb or
something else) is attached, at which point it will attach as console and
replay the dmesg buffer.

For this we need either to have the serial port attach before the
graphic drivers, or have a way to reset the console status of the serial
port when needed.


The serial port will only attach as console if you have chosen it to be 
the console (stdout-path). I want to solve this problem the right way, not 
relying on device attach order, because device order hacks become 
unmanageable when you are dealing with multiple SoC families, shared 
drivers, and GENERIC kernels.


We need a solution that covers these use cases:

 - Console is UART (may or may not have display capabilities)
 - Console is FB (laptop, tablet, etc where UART is difficult to access)
 - Console device can be either UART or FB (like a dev board, where we
   support both with WSDISPLAY_MULTICONS)

Currently the armv7.img/arm64.img configs use 'console=fb' to get correct 
behavior in these 3 cases. This setup has been working well so far, but 
there is definite room for improvement. I just want to make sure that the 
existing functionality doesn't get broken.


Cheers,
Jared

Re: graphic drivers and simplefb

On Thu, Apr 05, 2018 at 08:08:13AM -0300, Jared McNeill wrote:
> On Thu, 5 Apr 2018, Manuel Bouyer wrote:
> 
> > On Thu, Apr 05, 2018 at 07:40:35AM -0300, Jared McNeill wrote:
> > > On Thu, 5 Apr 2018, Manuel Bouyer wrote:
> > > 
> > > > Does it really do that ?
> > > > Reading the sources nothing is displayed until simplefb_attach() is 
> > > > called.
> > > > simplefb_console_consinit() calls genfb_cnattach() but it does nothing.
> > > > The dmesg buffer is replayed when genfb attaches with the console flag.
> > > 
> > > Doh, you're right. I'll have to fix that :)
> > 
> > but that's not easy. You'd need not only simplefb but also the
> > raster stuff to be set up. I'm not sure we want to go that far
> > in the early stages of the kenrel boot.
> > Things are even worse when we have to set up a full graphic pipeline.
> > You may even need interrupts ...
> 
> For simplefb I have everything I need..

OK, so in this case you'd want to have simplefb be the console,
until a more complete graphic driver attaches and take over
(much like we do with vga vs drm drivers in the x86 world).

> 
> > > 
> > > > Actually FDT_CONSOLE doens't prevent the serial port from taking over 
> > > > the
> > > > console if the stdout-path says so - and even if the command line says
> > > > otherwise.
> > > 
> > > Looks like we're missing a call to com_is_console in sunxi_com. This 
> > > should
> > > be fixed too..
> > 
> > I've been wondering about it too. But anyway, something, somewhere, it DTRT.
> > I have 3 serial ports active in my platform, and only com0 is console.
> > And if I change stdout-path (like my patch does, or in the fdt) then
> > com0 is not console any more.
> 
> This is because we call comcnattach (via FDT_CONSOLE) only for the one
> specified by stdout-path, and com.c:com_attach_subr only attaches console to
> that one.

OK that's what I missed. I only looked at the is_console boolean.

> 
> > > > Actually it works with simplefb because /chosen/framebuffer is probed 
> > > > and
> > > > attaches after com0 (and it's not an ordering kludge: it's just luck).
> > > > As sunxidep is attached before com0, com0 has the last word.
> > > 
> > > Not behavior I want to rely on :/
> > 
> > Note that this is also how allwniner works: com0 is console,
> > until a graphic driver attaches. In allwinner serial ports are attached
> > before graphics.
> > And I'd like to keep this behavior, it's very usefull for debugging.
> 
> Boards exist where serial console is difficult or impossible to access. Lets
> come up with a solution that satisfies all cases..

Sure. In this case I guess stdout-path will not be set to the serial port
though, so it should not use the serial port at all. I don't think we have
anything to change for this.

What I'm talking about is: stdout-path is set to the serial port, but
we have console=fb in the bootargs. In this case I think we could use
the serial port as console util the graphic driver (be it simplefb or
something else) is attached, at which point it will attach as console and
replay the dmesg buffer.

For this we need either to have the serial port attach before the
graphic drivers, or have a way to reset the console status of the serial
port when needed.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: graphic drivers and simplefb


On Thu, 5 Apr 2018, Manuel Bouyer wrote:


On Thu, Apr 05, 2018 at 07:40:35AM -0300, Jared McNeill wrote:

On Thu, 5 Apr 2018, Manuel Bouyer wrote:


Does it really do that ?
Reading the sources nothing is displayed until simplefb_attach() is called.
simplefb_console_consinit() calls genfb_cnattach() but it does nothing.
The dmesg buffer is replayed when genfb attaches with the console flag.


Doh, you're right. I'll have to fix that :)


but that's not easy. You'd need not only simplefb but also the
raster stuff to be set up. I'm not sure we want to go that far
in the early stages of the kenrel boot.
Things are even worse when we have to set up a full graphic pipeline.
You may even need interrupts ...


For simplefb I have everything I need..




Actually FDT_CONSOLE doens't prevent the serial port from taking over the
console if the stdout-path says so - and even if the command line says
otherwise.


Looks like we're missing a call to com_is_console in sunxi_com. This should
be fixed too..


I've been wondering about it too. But anyway, something, somewhere, it DTRT.
I have 3 serial ports active in my platform, and only com0 is console.
And if I change stdout-path (like my patch does, or in the fdt) then
com0 is not console any more.


This is because we call comcnattach (via FDT_CONSOLE) only for the one 
specified by stdout-path, and com.c:com_attach_subr only attaches console 
to that one.



Actually it works with simplefb because /chosen/framebuffer is probed and
attaches after com0 (and it's not an ordering kludge: it's just luck).
As sunxidep is attached before com0, com0 has the last word.


Not behavior I want to rely on :/


Note that this is also how allwniner works: com0 is console,
until a graphic driver attaches. In allwinner serial ports are attached
before graphics.
And I'd like to keep this behavior, it's very usefull for debugging.


Boards exist where serial console is difficult or impossible to access. 
Lets come up with a solution that satisfies all cases..

Re: graphic drivers and simplefb

On Thu, Apr 05, 2018 at 07:40:35AM -0300, Jared McNeill wrote:
> On Thu, 5 Apr 2018, Manuel Bouyer wrote:
> 
> > Does it really do that ?
> > Reading the sources nothing is displayed until simplefb_attach() is called.
> > simplefb_console_consinit() calls genfb_cnattach() but it does nothing.
> > The dmesg buffer is replayed when genfb attaches with the console flag.
> 
> Doh, you're right. I'll have to fix that :)

but that's not easy. You'd need not only simplefb but also the
raster stuff to be set up. I'm not sure we want to go that far
in the early stages of the kenrel boot.
Things are even worse when we have to set up a full graphic pipeline.
You may even need interrupts ...

> 
> > Actually FDT_CONSOLE doens't prevent the serial port from taking over the
> > console if the stdout-path says so - and even if the command line says
> > otherwise.
> 
> Looks like we're missing a call to com_is_console in sunxi_com. This should
> be fixed too..

I've been wondering about it too. But anyway, something, somewhere, it DTRT.
I have 3 serial ports active in my platform, and only com0 is console.
And if I change stdout-path (like my patch does, or in the fdt) then
com0 is not console any more.

> > Actually it works with simplefb because /chosen/framebuffer is probed and
> > attaches after com0 (and it's not an ordering kludge: it's just luck).
> > As sunxidep is attached before com0, com0 has the last word.
> 
> Not behavior I want to rely on :/

Note that this is also how allwniner works: com0 is console,
until a graphic driver attaches. In allwinner serial ports are attached
before graphics.
And I'd like to keep this behavior, it's very usefull for debugging.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: graphic drivers and simplefb


On Thu, 5 Apr 2018, Manuel Bouyer wrote:


Does it really do that ?
Reading the sources nothing is displayed until simplefb_attach() is called.
simplefb_console_consinit() calls genfb_cnattach() but it does nothing.
The dmesg buffer is replayed when genfb attaches with the console flag.


Doh, you're right. I'll have to fix that :)


Actually FDT_CONSOLE doens't prevent the serial port from taking over the
console if the stdout-path says so - and even if the command line says
otherwise.


Looks like we're missing a call to com_is_console in sunxi_com. This 
should be fixed too..



Actually it works with simplefb because /chosen/framebuffer is probed and
attaches after com0 (and it's not an ordering kludge: it's just luck).
As sunxidep is attached before com0, com0 has the last word.


Not behavior I want to rely on :/

Cheers,
Jared

Re: graphic drivers and simplefb

On Thu, Apr 05, 2018 at 07:13:19AM -0300, Jared McNeill wrote:
> On Thu, 5 Apr 2018, Manuel Bouyer wrote:
> 
> > But still, being able to switch the console from the bootargs is convenient.
> > On the device I'm working with, the normal stdout-path would be the
> > graphic display, but when doing developement I switch to serial console.
> > It's much easier to switch using bootargs (which I can always do using the
> > serial console) than updating the device tree (especially as I can't easily
> > extract the sd card, I have to dissasemble the boards for that).
> 
> Totally agree, that's why the console=fb vs stdout-path logic is there in
> the first place.
> 
> > I think there's a simple way to get it working: leave stdout-path to the
> > serial port, and move sunxi_com to pass 4, so that it's probed before
> > sunxi_dep. This way the kernel starts with console on serial, and switches
> > to graphic if the command line says so when the graphic drivers are 
> > activated.
> 
> This would be a regression to the current simplefb setup, which gives early
> kernel output to the selected console device. I'd prefer to use FDT_CONSOLE
> here rather than relying on device attach ordering kludges.

Does it really do that ?
Reading the sources nothing is displayed until simplefb_attach() is called.
simplefb_console_consinit() calls genfb_cnattach() but it does nothing.
The dmesg buffer is replayed when genfb attaches with the console flag.

Actually FDT_CONSOLE doens't prevent the serial port from taking over the
console if the stdout-path says so - and even if the command line says
otherwise.
Actually it works with simplefb because /chosen/framebuffer is probed and
attaches after com0 (and it's not an ordering kludge: it's just luck).
As sunxidep is attached before com0, com0 has the last word.
Unless, of course, if you change stdout-path in the device tree early,
My patch to sunxi_platform_bootstrap() just does that for other
framebuffer drivers that the simple framebuffer.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: graphic drivers and simplefb


On Thu, 5 Apr 2018, Manuel Bouyer wrote:


But still, being able to switch the console from the bootargs is convenient.
On the device I'm working with, the normal stdout-path would be the
graphic display, but when doing developement I switch to serial console.
It's much easier to switch using bootargs (which I can always do using the
serial console) than updating the device tree (especially as I can't easily
extract the sd card, I have to dissasemble the boards for that).


Totally agree, that's why the console=fb vs stdout-path logic is there in 
the first place.



I think there's a simple way to get it working: leave stdout-path to the
serial port, and move sunxi_com to pass 4, so that it's probed before
sunxi_dep. This way the kernel starts with console on serial, and switches
to graphic if the command line says so when the graphic drivers are activated.


This would be a regression to the current simplefb setup, which gives 
early kernel output to the selected console device. I'd prefer to use 
FDT_CONSOLE here rather than relying on device attach ordering kludges.


Cheers,
Jared

Re: graphic drivers and simplefb

On Wed, Apr 04, 2018 at 07:25:41PM -0300, Jared McNeill wrote:
> On Thu, 5 Apr 2018, Manuel Bouyer wrote:
> 
> > looking closer at it I can't see how this change would be a problem.
> > With this /chosen/stdout-path may point to a path that doens't
> > exists, or is not okay.
> > If it's not okay the driver will not attach because the fdt bus logic will
> > skip it.
> > It it doesn't exists, fdtbus_get_stdout_phandle() will return -1, which 
> > should
> > prevent of_match_compatible() from matching.
> > Did I miss something ?
> 
> The default stdout-path is usually defined in board specific .dts files:
> 
> https://nxr.netbsd.org/xref/src/sys/external/gpl2/dts/dist/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts#58

OK, if I read the sources properly u-boot will update linux,stdout-path
but will not touch stdout-path. So setting it in the dts should work.

But still, being able to switch the console from the bootargs is convenient.
On the device I'm working with, the normal stdout-path would be the
graphic display, but when doing developement I switch to serial console.
It's much easier to switch using bootargs (which I can always do using the
serial console) than updating the device tree (especially as I can't easily
extract the sd card, I have to dissasemble the boards for that).

I think there's a simple way to get it working: leave stdout-path to the
serial port, and move sunxi_com to pass 4, so that it's probed before
sunxi_dep. This way the kernel starts with console on serial, and switches
to graphic if the command line says so when the graphic drivers are activated.

I can do this in my kernel config file, but I think it would make sense to
do it in SUNXI instead.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: graphic drivers and simplefb


On Thu, 5 Apr 2018, Manuel Bouyer wrote:


looking closer at it I can't see how this change would be a problem.
With this /chosen/stdout-path may point to a path that doens't
exists, or is not okay.
If it's not okay the driver will not attach because the fdt bus logic will
skip it.
It it doesn't exists, fdtbus_get_stdout_phandle() will return -1, which should
prevent of_match_compatible() from matching.
Did I miss something ?


The default stdout-path is usually defined in board specific .dts files:

https://nxr.netbsd.org/xref/src/sys/external/gpl2/dts/dist/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts#58

Re: graphic drivers and simplefb

On Wed, Apr 04, 2018 at 07:16:30PM -0300, Jared McNeill wrote:
> > > 
> > > You'll want to add FDT_CONSOLE support to your DE driver as well.
> > 
> > For this I have a problem: allwinner,simple-framebuffer isn't specific
> > enough. At the time FDT_CONSOLE is called we don't know which variant of
> > debe we have, so we don't if we'll can handle it.
> > So I choose a way which allows fallback to simplefb when needed
> > (and actually it's needed on all but a10 and a20).
> 
> You could walk the OF tree looking for a compatible device. We could add a
> helper to ofw_subr.c for this.

I guess this should work.
I'll try this tomorow.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: graphic drivers and simplefb


On Wed, 4 Apr 2018, Manuel Bouyer wrote:


On Wed, Apr 04, 2018 at 06:45:12PM -0300, Jared McNeill wrote:

This will crash simplefb if the framebuffer is not configured. U-Boot will
set status to okay to signal to OS that simplefb handoff is available.


Doens't simplefb itself check the existence and status in the dtb ?
AFAIK I have simplefb in my kernel, but u-boot doesn't configure it,
yet I boot with console=fb and if works ...


Sorry I re-read the code and I was wrong about a crash. The idea here was 
to make console=fb fallback to the serial port (or whatever the default is 
in the devicetree) if the framebuffer is not available.


Not sure off the top of my head how to solve this cleanly for non-simplefb 
drivers, let me think about it...

Re: graphic drivers and simplefb

On Wed, Apr 04, 2018 at 06:56:19PM -0300, Jared McNeill wrote:
> There is a more specific compatible string on /chosen/framebuffer that you
> can match on ("allwinner,simple-framebuffer"). If your driver claims that
> node, you won't have to worry about handoff at all...

Yes I've seen it too. Indeed I could use it to prevent simplefb from attaching.
But see below

> 
> https://www.kernel.org/doc/Documentation/devicetree/bindings/display/simple-framebuffer-sunxi.txt
> 
> You'll want to add FDT_CONSOLE support to your DE driver as well.

For this I have a problem: allwinner,simple-framebuffer isn't specific
enough. At the time FDT_CONSOLE is called we don't know which variant of
debe we have, so we don't if we'll can handle it.
So I choose a way which allows fallback to simplefb when needed
(and actually it's needed on all but a10 and a20).

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: graphic drivers and simplefb

There is a more specific compatible string on /chosen/framebuffer that you
can match on ("allwinner,simple-framebuffer"). If your driver claims that
node, you won't have to worry about handoff at all...

https://www.kernel.org/doc/Documentation/devicetree/bindings/display/simple-framebuffer-sunxi.txt

You'll want to add FDT_CONSOLE support to your DE driver as well.

Cheers,
Jared

On Wed, 4 Apr 2018, Manuel Bouyer wrote:

Hello,
What's missing from the sunxi video drivers is console handling.
I got this working, but this needs some change to the simplefb driver.

the /chosen/framebuffer node is (if I understood is properly) set up by
the firmware/bootloader and will always exists if a framebuffer has been
set up. Or, we can't have a framebuffer in the firmware/bootloader without
a valid /chosen/framebuffer node (if I understood it properly).
Our simplefb driver will attach to it.
In addition, if this is going to be the OS's console, our simplefb
driver will match it very early.

Now if we attach and configure the display hardware in the OS, the
simplefb won't be functional as the display driver. Also, the
display drivers needs to know if they will be the console, and the simplefb
driver knows this.

So I propose to add 2 public functions to dev/fdt/simplefb.c, for use
by display drivers:
- int fdt_simplefb_get_console(void) which returns the phandle of
the /chosen/framebuffer node, if it has been selected as console.
The display driver may need more information from here
(like the content of allwinner,pipeline in my case).
- void fdt_simplefb_disable(void) which, once called, will prevent the
simplefb from matching.

The attached patch implements this, as well as console handling the
the sunxi drivers. In addition to 'console=fb', console=fb0 or fb1 is
supported to select a specific pipeline, which may not have been set up
by the bootloader.

For this to work, the display pipelines have to be fully configured before
simplefb could be matched. So I has to move
sunxidep* at fdt?
to pass 5.

I believe that with this, the display drivers could be enabled by default
in the sunxi kernel.

--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--

Re: graphic drivers and simplefb

On Wed, Apr 04, 2018 at 06:45:12PM -0300, Jared McNeill wrote:
> This will crash simplefb if the framebuffer is not configured. U-Boot will
> set status to okay to signal to OS that simplefb handoff is available.

Doens't simplefb itself check the existence and status in the dtb ?
AFAIK I have simplefb in my kernel, but u-boot doesn't configure it,
yet I boot with console=fb and if works ...

Without this I can't get console to framebuffer when u-boot doens't know
about it.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: graphic drivers and simplefb

This will crash simplefb if the framebuffer is not configured. U-Boot will 
set status to okay to signal to OS that simplefb handoff is available.


On Wed, 4 Apr 2018, Manuel Bouyer wrote:


On Wed, Apr 04, 2018 at 06:24:44PM +0200, Manuel Bouyer wrote:

Hello,
What's missing from the sunxi video drivers is console handling.
I got this working, but this needs some change to the simplefb driver.


I also need the attached change. Without it, if u-boot did use the serial
port and no framebuffer as console, the kernel's console will end up on the
serial port whatever the content of the bootargs is.

With this change the kernel may end up with no console at all if
bootargs has bee set wrongly, but then it's an operator mistake :)

--
Manuel Bouyer 
NetBSD: 26 ans d'experience feront toujours la difference
--

Re: graphic drivers and simplefb