[PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra

[Thierry Reding]

On Thu, Sep 27, 2012 at 04:37:41PM -0700, Simon Glass wrote:
> Hi Stephen,
> 
> On Thu, Sep 27, 2012 at 4:21 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> > On 09/27/2012 02:27 PM, Simon Glass wrote:
> >> On Thu, Sep 27, 2012 at 8:49 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> >>> On 09/27/2012 07:58 AM, Simon Glass wrote:
> > ...
> >>>> Really this is just a way of getting U-Boot and Linux to agree on the
> >>>> address, by having U-Boot know the address that the kernel will happen
> >>>> to use. It isn't very robust, but we have found it useful as a means
> >>>> of avoiding problems in this area.
> >>>
> >>> Right, but again, why can't the display driver simply read the address
> >>> out of the register; why is there a need to duplicate the data?
> >>>
> >>> I guess one possibility is that the register only gives the base address
> >>> and not the size/mode of the allocated surface, but I don't recall if
> >>> this proposed binding did that either?
> >>
> >> So here is my explanation:
> >>
> >> 1. U-Boot would normally put the display right near the top of memory.
> >> Instead, it figures out where the kernel will put it (somehow this
> >> seems to often be at a fixed address) and uses that address.
> >>
> >> 2. That means that U-Boot will now have the display exactly where the
> >> kernel wants it.
> >
> > Oh, the DT property is telling U-Boot where to put the surface so that
> > when the kernel determines where to put it, it'll already be there?
> >
> > That seems completely backwards. It's also extremely fragile; what if
> > the kernel suddenly starts allocating at some other random address,
> > which stops matching what U-Boot expects?
> 
> The screen will flicker, or may fill up with junk as the kernel boots.
> We did have that happen once when the driver changed.
> 
> >
> > Far better would be for U-Boot to put the surface wherever it wants,
> > then manipulate the DT that's passed to the kernel to:
> >
> > a) Add a /memreserve/ so that memory doesn't get re-used for anything
> > else during boot.
> >
> > b) Add a property to the display node indicating which memreserve
> > represents the frame-buffer location.
> 
> Yes, I believe the Tegra video driver we used (and I take your point
> that it doesn't exist upstream so there is no point in discussing it
> :-) always had to use the same frame buffer address. The memory was
> statically allocated. Certainly this could be encoded in the fdt.
> 
> >
> > When the kernel boots, it can:
> >
> > * Copy the content from the U-Boot-allocated buffer to whatever display
> > buffer the kernel allocated before writing the new address to the HW.
> >
> > * Undo the memory reservation triggered by the /memreserve/ to allow the
> > memory to be re-used.
> >
> >> So what do you think? Should we remove this entirely, or is it a useful hack?
> >
> > Yes, I think in its current form, it isn't useful.
> 
> Thanks for the thorough response. Let's remove it, particularly as
> there isn't even a kernel driver upstream yet.

We've been discussing some of these issues for quite some time and came
to the conclusion that the Tegra DRM driver should not be using static
allocations like the previous drivers did. One of the reasons is that
the amount of carveout memory needs to be fixed at boot time, which
isn't going to suit a wide range of devices well. Another, perhaps more
important reason is that starting with Tegra30 that's no longer
necessary because of the SMMU.

So in the end it wouldn't be possible to reliably determine the memory
area where the kernel will put the framebuffer. If we want a flicker-
free boot then we need to go with something more elaborate like what
Stephen suggested.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20120928/59f50688/attachment.sig>