lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160804153408.GD4256@skynet.be>
Date:	Thu, 4 Aug 2016 17:34:08 +0200
From:	Luc Verhaegen <libv@...net.be>
To:	Noralf Trønnes <noralf@...nnes.org>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 0/2] drm: add SimpleDRM driver

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@...87000 {
> > >                 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ