Re: NetBSD on A20-OLinuXino-MICRO

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, May 29, 2018 at 12:54:18AM +0300, Valery Ushakov wrote:
> On Fri, May 25, 2018 at 04:19:25 +0300, Valery Ushakov wrote:
> 
> > http://dmesgd.nycbug.org/index.cgi?do=view&id=3624 and also attached.
> [...]
> > I had to disable
> > 
> >   sunxidebe
> >   sunxitcon
> >   sunxihdmi
> >   connector
> >   panel
> >   sunxidep
> > 
> > in the kernel config to get the display working.
> 
> Booting stock SUNXI kernel I get for those:
> 
> sunxidebe0 at fdt1: Display Engine Backend (display-backend@1e60000)
> sunxidebe1 at fdt1: Display Engine Backend (display-backend@1e40000)
> sunxihdmi0 at fdt1: HDMI 1.3
> sunxitcon0 at fdt1: LCD/TV timing controller (lcd-controller@1c0c000)
> sunxitcon0 port 0 endpoint 0 connected to sunxidebe0 port 1 endpoint 0
> sunxitcon0: tcon unit 0
> sunxidebe0: debe unit 0
> sunxitcon0 port 0 endpoint 1 connected to sunxidebe1 port 1 endpoint 0
> sunxidebe1: debe unit 1
> sunxitcon0 port 1 endpoint 1 connected to sunxihdmi0 port 0 endpoint 0
> sunxitcon1 at fdt1: LCD/TV timing controller (lcd-controller@1c0d000)
> sunxitcon1 port 0 endpoint 0 connected to sunxidebe0 port 1 endpoint 1
> sunxitcon1: tcon unit 1
> sunxitcon1 port 0 endpoint 1 connected to sunxidebe1 port 1 endpoint 1
> sunxitcon1 port 1 endpoint 1 connected to sunxihdmi0 port 0 endpoint 1
> connector0 at fdt0: HDMI connector
> connector0 port 0 endpoint 0 connected to sunxihdmi0 port 1 endpoint 0
> sunxidep0 at fdt0: can't activate pipeline 0
> sunxidep0: can't activate pipeline 1
> genfb0 at fdt3: Simple Framebuffer (1280x1024 32-bpp @ 0x7fb00000)
> genfb0: framebuffer at 0x7fb00000, size 1280x1024, depth 32, stride 5120
> wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation)
> 
> Anything I can do to help to debug this?

I see what's happening. With the default device tree the allwinner,pipelines
properties points to the display frontend devices, and we don't have drivers
for that. In this case it fallback to the simple framebuffer driver.
But, the drivers for the other parts of the pipeline do reset the hardware
in their attach function (and disable clocks).

I could delay the reset to sunxi_dep_attach() and do it only for pipelines
we activate, but in this case this means that if a pipeline element is
explicitely not present in the device tree, but has been activated by the
firmware then it will stay active, draving power.

I'm not sure about the solution at this point, I will have to think more about
it ...

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--