On Thu, Aug 04, 2016 at 05:08:43PM +0200, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 04:15:25PM +0200, Luc Verhaegen wrote:
> > On Thu, Aug 04, 2016 at 04:03:18PM +0200, Noralf Trønnes wrote:
> > >
> > > I have tested simpledrm on a Raspberry Pi B+ with U-boot setting up the
> > > framebuffer and producing this node:
> > >
> > > framebuffer at 1e887000 {
> > > compatible = "simple-framebuffer";
> > > reg = <0x1e887000 0x36c600>;
> > > format = "r5g6b5";
> > > width = <1824>;
> > > height = <984>;
> > > stride = <3648>;
> > > status = "okay";
> > > };
> > >
> > > I have only tested with fbcon and modetest (XR24,RG16).
> >
> > Please do not make the same mistake as simplefb in making this purely a
> > rpifb. Know that you will need some power and clock management for
> > properly free devices that do not depend on a binary only RTOS which
> > does _everything_ behind our backs.
> >
> > Cfr this useless, endless and ridiculous discussion:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/279071.html
>
> simpledrm isn't a real driver, but only meant to be used to drive the
> firmware framebuffer in early boot until a real driver takes over. It's a
> replacement really for all the various uefi/vesa/whatever fbdev drivers.
> Full reliance on the firmware very much intended.
> -Daniel
In the sunxi case, that firmware was u-boot, and the clocks were
properly declared and then also properly disabled, which meant the
display block got disabled.
Is simpledrm only an intermediate solution until the real driver is
loaded? What stops it from providing a rudimentary display driver for
the whole uptime of the machine? What stops the kernel from disabling
the clocks while the supposed real driver is not fully loaded yet?
Do we really want to recreate a 400+ email thread again, or are we
capable of learning from the past?
Luc Verhaegen.