Message-ID: <20220406153610.1d479a05@fixe.home>
Date:   Wed, 6 Apr 2022 15:36:10 +0200
From:   Clément Léger <clement.leger@...tlin.com>
To:     Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc:     Rob Herring <robh@...nel.org>, Lizhi Hou <lizhi.hou@...inx.com>,
        Sonal Santan <sonal.santan@...inx.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Frank Rowand <frowand.list@...il.com>,
        Lars Povlsen <lars.povlsen@...rochip.com>,
        Steen Hegelund <Steen.Hegelund@...rochip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Allan Nielsen <allan.nielsen@...rochip.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        devicetree@...r.kernel.org,
        Stefano Stabellini <sstabellini@...nel.org>,
        Hans de Goede <hdegoede@...hat.com>,
        Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH v2 0/3] add fwnode support to reset subsystem

Le Wed, 6 Apr 2022 15:33:46 +0200,
Alexandre Belloni <alexandre.belloni@...tlin.com> a écrit :

> On 06/04/2022 08:19:16-0500, Rob Herring wrote:
> > > > > > I've told the Xilinx folks the same thing, but I would separate this
> > > > > > into 2 parts. First is just h/w work in a DT based system. Second is
> > > > > > creating a base tree an overlay can be applied to. The first part should
> > > > > > be pretty straightforward. We already have PCI bus bindings. The only
> > > > > > tricky part is getting address translation working from leaf device thru
> > > > > > the PCI bus to host bus, but support for that should all be in place
> > > > > > (given we support ISA buses off of PCI bus). The second part will
> > > > > > require generating PCI DT nodes at runtime. That may be needed for both
> > > > > > DT and ACPI systems as we don't always describe all the PCI hierarchy
> > > > > > in DT.    
> > > > >
> > > > > But then, if the driver generate the nodes, it will most probably
> > > > > have to describe the nodes by hardcoding them right ?    
> > > > 
> > > > No, the kernel already maintains its own tree of devices. You just
> > > > need to use that to generate the tree. That's really not much more
> > > > than nodes with a 'reg' property encoding the device and function
> > > > numbers.  
> > > 
> > > Just to clarified a point, my PCI device exposes multiple peripherals
> > > behind one single PCI function.  
> > 
> > Right. I would expect your PCI device DT node to have a 'simple-bus' 
> > child node with all those peripherals. And maybe there's other nodes 
> > like fixed-clocks, etc.
> >   
> > > To be sure I understood what you are suggesting, you propose to create
> > > a DT node from the PCI driver that has been probed dynamically
> > > matching this same PCI device with a 'reg' property. I also think
> > > this would requires to generate some 'pci-ranges' to remap the
> > > downstream devices that are described in the DTBO, finally, load the
> > > overlay to be apply under this newly created node. Is that right ?  
> > 
> > Right. You'll need to take the BAR address(es) for the device and stick 
> > those into 'ranges' to translate offsets to BAR+offset.
> >   
> 
> Last time I tried that, this was not working well because it means that
> the ranges property of the device depends on the host machine...
> 

Yes, but we can actually resolve that dynamically. The ranges property
that is inserted is inserted in the top node (the PCI device one).
Since this node will be created by "us" (the kernel/driver), we can
insert whatever we want. And most probably, we'll insert a specific BAR
remapping. The underlying nodes will then be loaded from the overlay
and merged in the top PCI device node (At least I guess ;)). These
nodes don't need any "machine dependent" addresses, only realtive
addresses from the top node.


-- 
Clément Léger,
Embedded Linux and Kernel engineer at Bootlin
https://bootlin.com

Powered by blists - more mailing lists