[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
Thierry Reding
thierry.reding at gmail.com
Tue Aug 26 07:41:26 PDT 2014
On Tue, Aug 26, 2014 at 02:33:57PM +0200, Luc Verhaegen wrote:
> On Tue, Aug 26, 2014 at 02:21:16PM +0200, Thierry Reding wrote:
> > On Tue, Aug 26, 2014 at 02:02:58PM +0200, Luc Verhaegen wrote:
> > > On Tue, Aug 26, 2014 at 09:52:49AM +0200, Thierry Reding wrote:
> > > > On Mon, Aug 25, 2014 at 05:09:00PM +0200, Luc Verhaegen wrote:
> > > > > On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> > > > > >
> > > > > > No. simplefb just wants to write to some memory that hardware has been
> > > > > > set up to scan out. The platform requires that the clocks be on.
> > > > >
> > > > > Simplefb also requires that the memory is there and is persistent. Fine
> > > > > for discrete graphics cards, fine for rpi where most things are hidden
> > > > > from the ARM core anyway, not so fine for anybody else.
> > > >
> > > > I don't understand. This patch series isn't changing anything about the
> > > > memory aspects of the driver yet it's working for you on sunxi, isn't
> > > > it? So it can't be all that broken.
> > > >
> > > > Thierry
> > >
> > > Oh, i had to go wrestle with UBoot options and reserve 8MB off the top,
> > > which the kernel never gets told about. A nice throwback to x86 IGP
> > > bioses, a past i had thought i had left behind forgood.
> >
> > Can you not use the reserved memory code (drivers/of/of_reserved_mem.c
> > in the kernel)? I think that's the generally accepted way to do this
> > with DT.
> >
> > Thierry
>
> It was mentioned to me, and I probably could do that, but this seemed
> even more DT wrangling from within u-boot, and it didn't seem finished
> yet. Plus, all of this already was way more wrangling than i bargained
> for, especially with the promise of "simple"-fb. Then there is the
> really awkward way in which one gets to define clocks outside of a
> dts/compiler (you've seen the code, right?), i really did not feel like
> repeating something like that.
It could most probably be turned into fairly generic and reusable code
so that others can use it. And it would give you a way of recovering
those 8 MiB of memory that you'd otherwise loose.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/b66e355c/attachment-0001.sig>
More information about the linux-arm-kernel
mailing list