On Tue, Mar 26, 2019 at 4:35 PM Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote:
>
> Hi,
>
> On Mon, Mar 25, 2019 at 11:27:36AM -0500, Rob Herring wrote:
> > On Mon, Mar 25, 2019 at 8:54 AM Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote:
> > >
> > > The simple framebuffer is a binding that allows the bootloader to setup a
> > > framebuffer, describe it in the Device Tree for the OS to pick it up and
> > > use it as is.
> > >
> > > Replace the current binding by a schema to allow the validation tools to
> > > check those nodes.
> > >
> > > Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@xxxxxxxxxxx>
> > > Cc: Chen-Yu Tsai <wens@xxxxxxxx>
> > > Cc: Hans de Goede <hdegoede@xxxxxxxxxx>
> > > Cc: Maxime Jourdan <mjourdan@xxxxxxxxxxxx>
> > > Signed-off-by: Maxime Ripard <maxime.ripard@xxxxxxxxxxx>
> > >
> > > ---
> > >
> > > Rob,
> > >
> > > Even though the node itself is properly described, I still end up with some
> > > validation warnings when the chosen node is validated (basically
> > > complaining that ranges, and the framebuffer nodes shouldn't be here, since
> > > we haven't described them in the chosen schemas).
> >
> > Having 'ranges' is a bit strange because 'chosen' doesn't have an
> > address. We can add #address-cells, #size-cells and framebuffer child
> > node to the base chosen schema.
>
> Maybe that's just cargo cult, but both the amlogic and the sunxi DT
> have ranges in chosen. Shouldn't we need it so that the address is
> decoded properly?
I don't think so. If you have #{size,address}-cells then that should
be enough. Lack of ranges should just mean that any translation stops
at that level. But it is possible that the kernel code requires
translation to go all the way to the root for memory addresses. I
haven't checked.
Rob
