[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [SLOF] [PATCH v4] board-qemu: add private hcall to inform
From: |
Segher Boessenkool |
Subject: |
Re: [Qemu-ppc] [SLOF] [PATCH v4] board-qemu: add private hcall to inform host on "phandle" update |
Date: |
Wed, 4 Oct 2017 08:17:12 -0500 |
User-agent: |
Mutt/1.4.2.3i |
On Tue, Oct 03, 2017 at 11:21:34AM +1100, David Gibson wrote:
> > All cells (and all phandles) are 64 bits on a 64-bit OF. This is what
> > a 64-bit OF _is_, fundamentally: it uses 64-bit cells. Cells are the
> > fundamental data type: for example stack entries are cells.
> >
> > The things in the device tree are 32 bits. A few places in the Open
> > Firmware specification unfortunately call those "cells" as well.
>
> Right. Unfortunate as it may be, that's the main sense in which
> "cell" is now being used.
Not in the OF world (or Forth world, even). Culture clash :-)
> > With the status quo (32-bit phandles in the device tree, so the client
> > uses 32-bit phandles as well) we can still use phandles with a non-zero
> > upper 32 bits in OF, using one of various translation schemes. I was
> > worried that the translation via FDT would prevent that, force OF to
> > always use only memory in the low 4GB. I now think that not much changes,
> > and in practice we will always use low 4GB addresses for OF's memory
> > anyway. The recommendation in 1275.6 (the 64-bit extension) is similar.
>
> So, I'm still a bit unclear on this. Ok, so in a 64-bit OF phandles
> are 64-bit internally. What happens when they get encoded out into
> the device tree though (e.g. in 'interrupt-parent' or whatever)?
> 2) Do they get (somehow) translated down into 32-bit quantities?
This. And translating 32-bit ihandles and phandles back into "real"
ones can get complex. But it looks like we won't have to go there :-)
Segher