On Mon, Jun 08, 2015 at 10:34:13PM +0100, Grant Likely wrote:
>On Mon, Jun 8, 2015 at 9:57 PM, Benjamin Herrenschmidt
> wrote:
>> On Sun, 2015-06-07 at 08:54 +0100, Grant Likely wrote:
>>> > IE. conceptually, what overlays do today is quite rooted around the idea
>>> > of having a fixed "base" DT a
On Mon, Jun 8, 2015 at 9:57 PM, Benjamin Herrenschmidt
wrote:
> On Sun, 2015-06-07 at 08:54 +0100, Grant Likely wrote:
>> > IE. conceptually, what overlays do today is quite rooted around the idea
>> > of having a fixed "base" DT and some pre-compiled DTB overlays that
>> > get added/removed. The
On Sun, 2015-06-07 at 08:54 +0100, Grant Likely wrote:
> > IE. conceptually, what overlays do today is quite rooted around the idea
> > of having a fixed "base" DT and some pre-compiled DTB overlays that
> > get added/removed. The design completely ignore the idea of a FW that
> > maintains a "live
Sorry for not weighing in earlier, I've had other work keeping me away.
My short answer: don't use overlays. They're not what you need. Generic
CONFIG_OF_DYNAMIC should be all that is required to make changes in your
use case.
Overlays are a specific api for being able to apply a set of changes i
On Fri, May 01, 2015 at 04:03:06PM +1000, Gavin Shan wrote:
>The requirement is raised when developing the PCI hotplug feature
>for PowerPC PowerNV platform, which runs on top of skiboot firmware.
>When plugging PCI adapter to one PCI slot, the firmware rescans the
>slot and build FDT (Flat Device
On Thu, 2015-05-14 at 14:02 +0300, Pantelis Antoniou wrote:
> Hi Ben,
>
> > On May 14, 2015, at 10:47 , Benjamin Herrenschmidt
> > wrote:
> >
>
> [snip]
>
> So I spend some time thinking about your use case and I think it boils down
> to this:
>
> I have a live tree in the firmware, I have m
Hi Ben,
> On May 14, 2015, at 10:47 , Benjamin Herrenschmidt
> wrote:
>
[snip]
So I spend some time thinking about your use case and I think it boils down
to this:
I have a live tree in the firmware, I have made changes and I need to reflect
those changes to the live tree in the kernel.
Sou
On Thu, 2015-05-14 at 10:34 +0300, Pantelis Antoniou wrote:
> >> What you describe is inserting a bunch of properties and nodes under
> >> a slot’s device node. Reverting the overlay removes them all just fine.
> >
> > Except that still doesn't work for boot time :-)
> >
> > So I would have to d
Hi Ben,
> On May 14, 2015, at 10:25 , Benjamin Herrenschmidt
> wrote:
>
> On Thu, 2015-05-14 at 10:19 +0300, Pantelis Antoniou wrote:
>
>>
>> You don’t want to know how sausages are made, but they are delicious :)
>
> ... most of the time :)
>
>>> But yeah generating the overlay doesn't nec
> So I would have to do a special case on unplug:
>
> if (slot->dt_is_overlay) /* set to false at boot */
> remove_subtree_myself();
> else
> undo_overlay(slot->overlay);
Of course I just inverted the polarity of the if () in the example :-)
But you get t
On Thu, 2015-05-14 at 10:19 +0300, Pantelis Antoniou wrote:
>
> You don’t want to know how sausages are made, but they are delicious :)
... most of the time :)
> > But yeah generating the overlay doesn't necessarily scare me, I can
> > generate a temp tree that is the overlay in which I "copy"
Hi Ben,
> On May 14, 2015, at 10:14 , Benjamin Herrenschmidt
> wrote:
>
> On Thu, 2015-05-14 at 10:04 +0300, Pantelis Antoniou wrote:
>
>> Hmm, since you just want to transmit a whole subtree things are a bit
>> simpler.
>>
>> You don’t need any of the fixups, and your target node is known.
>
On Thu, 2015-05-14 at 10:04 +0300, Pantelis Antoniou wrote:
> Hmm, since you just want to transmit a whole subtree things are a bit
> simpler.
>
> You don’t need any of the fixups, and your target node is known.
>
> So your overlay is simply:
>
> / {
> fragment@0 {
> target-
Hi Ben,
> On May 14, 2015, at 09:46 , Benjamin Herrenschmidt
> wrote:
>
> On Thu, 2015-05-14 at 09:23 +0300, Pantelis Antoniou wrote:
>
>>> A few things that I don't find in the overlay code (but maybe I haven't
>>> looked at it hard enough):
>>>
>>> - Can it remove nodes/properties ?
>>>
>>
On Thu, 2015-05-14 at 09:23 +0300, Pantelis Antoniou wrote:
> > A few things that I don't find in the overlay code (but maybe I haven't
> > looked at it hard enough):
> >
> > - Can it remove nodes/properties ?
> >
>
> Yes.
Ok, I've missed that when looking at the overlay code then, I'll have t
Hi Ben,
Sorry for taking this long to respond, but I am working on the same problem
right
now. I thought I might have something to show, but not yet :)
My PCI overlay case is different. In my case there is no firmware and there
is the blob is provided as an overlay.
The idea is that for a given
On Wed, 2015-05-13 at 19:18 -0500, Rob Herring wrote:
> I haven't decided really.
>
> The main thing with the current patch is I don't really like the added
> complexity to unflatten_dt_node. It is already a fairly complex
> function. Perhaps removing of "hybrid" as discussed will help?
I agree,
On Wed, May 13, 2015 at 6:35 PM, Benjamin Herrenschmidt
wrote:
> On Tue, 2015-05-05 at 07:14 +1000, Benjamin Herrenschmidt wrote:
>> So the "trivial" way to do it (and the way we have implemented the FW
>> side so far) is to have the FW simply "flatten" the subtree below the
>> slot and pass it to
On Tue, 2015-05-05 at 07:14 +1000, Benjamin Herrenschmidt wrote:
> So the "trivial" way to do it (and the way we have implemented the FW
> side so far) is to have the FW simply "flatten" the subtree below the
> slot and pass it to Linux, with the intent of expanding it back below
> the slot node.
>
Hi Ben,
> On May 2, 2015, at 01:57 , Benjamin Herrenschmidt
> wrote:
>
> On Fri, 2015-05-01 at 13:46 -0500, Rob Herring wrote:
>> On Fri, May 1, 2015 at 10:22 AM, Benjamin Herrenschmidt
>> wrote:
>>> On Fri, 2015-05-01 at 07:54 -0500, Rob Herring wrote:
>>>
The difference seems to be whe
On Mon, 2015-05-04 at 19:41 +0300, Pantelis Antoniou wrote:
>
> You get all of the corner cases handled for free. Perhaps it works for
> your case too.
>
> Perhaps you can educate me on what you need supported and we can make
> sure it’s included.
Which corner cases ?
IE, what I want is simply
On Mon, 2015-05-04 at 11:30 +1000, Gavin Shan wrote:
> Thanks, Ben. If we really need utilize overlay to support our case,
> we need some one to parse the input (device-tree changes) from
> firmware
> and create "overlay" device node and "target" node as I mentioned
> above.
> It's not simpler than
On Sat, May 02, 2015 at 12:48:26PM +1000, Benjamin Herrenschmidt wrote:
>On Sat, 2015-05-02 at 09:29 +1000, Benjamin Herrenschmidt wrote:
>
>> Looking a bit more at it, I don't quite see how I can attach a subtree
>> using that stuff.
>>
>> Instead, each node in the overlay seems to need extra nod
On Sat, May 02, 2015 at 09:29:36AM +1000, Benjamin Herrenschmidt wrote:
>On Sat, 2015-05-02 at 08:57 +1000, Benjamin Herrenschmidt wrote:
>
>> > Overlay = an FDT blob to graft into a live running system. Sounds like
>> > the same thing.
>> >
>> > > As for the details of Gavin implementation, I hav
On Fri, May 01, 2015 at 07:54:03AM -0500, Rob Herring wrote:
>+dt list
>
>On Fri, May 1, 2015 at 1:03 AM, Gavin Shan wrote:
>> The requirement is raised when developing the PCI hotplug feature
>> for PowerPC PowerNV platform, which runs on top of skiboot firmware.
>> When plugging PCI adapter to o
On Sat, 2015-05-02 at 09:29 +1000, Benjamin Herrenschmidt wrote:
> Looking a bit more at it, I don't quite see how I can attach a subtree
> using that stuff.
>
> Instead, each node in the overlay seems to need extra nodes and
> properties to refer to the original.
>
> So the FW would essentially
On Sat, 2015-05-02 at 08:57 +1000, Benjamin Herrenschmidt wrote:
> > Overlay = an FDT blob to graft into a live running system. Sounds like
> > the same thing.
> >
> > > As for the details of Gavin implementation, I haven't looked at it in
> > > details yet so there might be issues there, however
On Fri, 2015-05-01 at 13:46 -0500, Rob Herring wrote:
> On Fri, May 1, 2015 at 10:22 AM, Benjamin Herrenschmidt
> wrote:
> > On Fri, 2015-05-01 at 07:54 -0500, Rob Herring wrote:
> >
> >> The difference seems to be whether you allocate space or just point to
> >> the FDT for various strings/data.
On Fri, May 1, 2015 at 10:22 AM, Benjamin Herrenschmidt
wrote:
> On Fri, 2015-05-01 at 07:54 -0500, Rob Herring wrote:
>
>> The difference seems to be whether you allocate space or just point to
>> the FDT for various strings/data. Is that right?
>>
>> >* of_fdt_add_subtree() is the introduced
On Fri, 2015-05-01 at 07:54 -0500, Rob Herring wrote:
> The difference seems to be whether you allocate space or just point to
> the FDT for various strings/data. Is that right?
>
> >* of_fdt_add_subtree() is the introduced API to do the work.
>
> Have you looked at overlays and if so why do
+dt list
On Fri, May 1, 2015 at 1:03 AM, Gavin Shan wrote:
> The requirement is raised when developing the PCI hotplug feature
> for PowerPC PowerNV platform, which runs on top of skiboot firmware.
> When plugging PCI adapter to one PCI slot, the firmware rescans the
> slot and build FDT (Flat De
The requirement is raised when developing the PCI hotplug feature
for PowerPC PowerNV platform, which runs on top of skiboot firmware.
When plugging PCI adapter to one PCI slot, the firmware rescans the
slot and build FDT (Flat Device Tree) blob, which is sent to the
PowerNV PCI hotplug driver for
32 matches
Mail list logo
