On Mon, Sep 11, 2023 at 3:37 PM Andy Shevchenko
<[email protected]> wrote:
>
> On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:
> > This patch series introduces OF overlay support for PCI devices which
> > primarily addresses two use cases. First, it provides a data driven method
> > to describe hardware peripherals that are present in a PCI endpoint and
> > hence can be accessed by the PCI host. Second, it allows reuse of a OF
> > compatible driver -- often used in SoC platforms -- in a PCI host based
> > system.
> >
> > There are 2 series devices rely on this patch:
> >
> > 1) Xilinx Alveo Accelerator cards (FPGA based device)
>
> > 2) Microchip LAN9662 Ethernet Controller
>
> I believe you should Cc this to Andrew Lunn for the comments.
> IIRC something similar was tried to being solved for DSA (?)
> devices where SFP hotpluggable hardware can be attached or
> detached at run-time (sorry if I messes / mixing up things,
> I wrote this from my memory, might be completely wrong).
Could be similar in the sense that this problem exists on any
discoverable bus with non-discoverable devices downstream.
The LAN9662 case is that it's an SoC that can run Linux. Standard
stuff there. You have a DT and a bunch of drivers and SoC support in
the kernel. Now take that same SoC with the CPU cores disabled and
expose the whole (or part of) SoC via PCIe to Linux running on another
host. How to reuse all the drivers? Yes, you could define swnode
stuff, but then the PCI driver becomes a board file (or multiple). In
fact that's what they started doing at one point. It doesn't scale.
> > Please see: https://lore.kernel.org/lkml/[email protected]/
> >
> > Normally, the PCI core discovers PCI devices and their BARs using the
> > PCI enumeration process. However, the process does not provide a way to
> > discover the hardware peripherals that are present in a PCI device, and
> > which can be accessed through the PCI BARs. Also, the enumeration process
> > does not provide a way to associate MSI-X vectors of a PCI device with the
> > hardware peripherals that are present in the device. PCI device drivers
> > often use header files to describe the hardware peripherals and their
> > resources as there is no standard data driven way to do so. This patch
> > series proposes to use flattened device tree blob to describe the
> > peripherals in a data driven way. Based on previous discussion, using
> > device tree overlay is the best way to unflatten the blob and populate
> > platform devices. To use device tree overlay, there are three obvious
> > problems that need to be resolved.
> >
> > First, we need to create a base tree for non-DT system such as x86_64. A
> > patch series has been submitted for this:
> > https://lore.kernel.org/lkml/[email protected]/
> > https://lore.kernel.org/lkml/[email protected]/
>
> Can you point out to the ACPI excerpt(s) of the description of anything related
> to the device(s) in question?
I don't understand what you are asking for.
Rob
On Tue, Sep 12, 2023 at 02:12:04PM -0500, Rob Herring wrote:
> On Mon, Sep 11, 2023 at 3:37 PM Andy Shevchenko
> <[email protected]> wrote:
> > On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:
...
> > Can you point out to the ACPI excerpt(s) of the description of anything related
> > to the device(s) in question?
>
> I don't understand what you are asking for.
Through the email thread it was mentioned that this series was tested on the
ACPI enabled platform, Jonathan (IIRC) asked why do we need to have a shadow
DT for the something that ACPI already describes. That's why I'm trying to
understand if it's the case. and if so, how can we improve the approach.
--
With Best Regards,
Andy Shevchenko
Hi Andy,
On Wed, 13 Sep 2023 14:17:30 +0300
Andy Shevchenko <[email protected]> wrote:
> On Tue, Sep 12, 2023 at 02:12:04PM -0500, Rob Herring wrote:
> > On Mon, Sep 11, 2023 at 3:37 PM Andy Shevchenko
> > <[email protected]> wrote:
> > > On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:
>
> ...
>
> > > Can you point out to the ACPI excerpt(s) of the description of anything related
> > > to the device(s) in question?
> >
> > I don't understand what you are asking for.
>
> Through the email thread it was mentioned that this series was tested on the
> ACPI enabled platform, Jonathan (IIRC) asked why do we need to have a shadow
> DT for the something that ACPI already describes. That's why I'm trying to
> understand if it's the case. and if so, how can we improve the approach.
>
Patches from Frank Rowand series [1] are needed to create an of_root_node if a DT
was not provided by the firmware, bootloader, etc that run the kernel.
[1]: https://lore.kernel.org/lkml/[email protected]/
Current Lizhi's series creates nodes from the PCI host node during the PCI
enumeration. It creates PCI-PCI bridge and PCI device nodes.
I use these series on an ACPI system.
I need one more missing component: the node related to the PCI host bridge
This was the purpose of Clement's work. This work was not sent upstream yet and I
am working on it in order to have a full tree from the of_root to the PCI device
ie:
of_root <-- Frank Rowand series
+ of_host_pci_bridge <-- Clement's work
+ pci_bridge <-- Current Lizhi series
+ pci_bridge <-- Current Lizhi series
...
+ pci_dev <-- Current Lizhi series
Hope that this status helped.
Regards,
Hervé
--
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On Fri, Sep 15, 2023 at 07:30:08PM +0200, Herve Codina wrote:
> On Wed, 13 Sep 2023 14:17:30 +0300
> Andy Shevchenko <[email protected]> wrote:
> > On Tue, Sep 12, 2023 at 02:12:04PM -0500, Rob Herring wrote:
> > > On Mon, Sep 11, 2023 at 3:37 PM Andy Shevchenko
> > > <[email protected]> wrote:
> > > > On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:
...
> > > > Can you point out to the ACPI excerpt(s) of the description of anything related
> > > > to the device(s) in question?
> > >
> > > I don't understand what you are asking for.
> >
> > Through the email thread it was mentioned that this series was tested on the
> > ACPI enabled platform, Jonathan (IIRC) asked why do we need to have a shadow
> > DT for the something that ACPI already describes. That's why I'm trying to
> > understand if it's the case. and if so, how can we improve the approach.
>
> Patches from Frank Rowand series [1] are needed to create an of_root_node if a DT
> was not provided by the firmware, bootloader, etc that run the kernel.
>
> [1]: https://lore.kernel.org/lkml/[email protected]/
>
> Current Lizhi's series creates nodes from the PCI host node during the PCI
> enumeration. It creates PCI-PCI bridge and PCI device nodes.
>
> I use these series on an ACPI system.
>
> I need one more missing component: the node related to the PCI host bridge
> This was the purpose of Clement's work. This work was not sent upstream yet and I
> am working on it in order to have a full tree from the of_root to the PCI device
> ie:
> of_root <-- Frank Rowand series
> + of_host_pci_bridge <-- Clement's work
> + pci_bridge <-- Current Lizhi series
> + pci_bridge <-- Current Lizhi series
> ...
> + pci_dev <-- Current Lizhi series
>
> Hope that this status helped.
Thanks for the explanation! I suppose it's better to have three series combined
into one and being sent with a better cover letter to explain all this. Also it
might make sense (in my opinion) to Cc Jonathan (I did it here). Sorry, Jonathan,
if you are not wanting this.
--
With Best Regards,
Andy Shevchenko
On Mon, 18 Sep 2023 10:17:26 +0300
Andy Shevchenko <[email protected]> wrote:
> On Fri, Sep 15, 2023 at 07:30:08PM +0200, Herve Codina wrote:
> > On Wed, 13 Sep 2023 14:17:30 +0300
> > Andy Shevchenko <[email protected]> wrote:
> > > On Tue, Sep 12, 2023 at 02:12:04PM -0500, Rob Herring wrote:
> > > > On Mon, Sep 11, 2023 at 3:37 PM Andy Shevchenko
> > > > <[email protected]> wrote:
> > > > > On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:
>
> ...
>
> > > > > Can you point out to the ACPI excerpt(s) of the description of anything related
> > > > > to the device(s) in question?
> > > >
> > > > I don't understand what you are asking for.
> > >
> > > Through the email thread it was mentioned that this series was tested on the
> > > ACPI enabled platform, Jonathan (IIRC) asked why do we need to have a shadow
> > > DT for the something that ACPI already describes. That's why I'm trying to
> > > understand if it's the case. and if so, how can we improve the approach.
> >
> > Patches from Frank Rowand series [1] are needed to create an of_root_node if a DT
> > was not provided by the firmware, bootloader, etc that run the kernel.
> >
> > [1]: https://lore.kernel.org/lkml/[email protected]/
> >
> > Current Lizhi's series creates nodes from the PCI host node during the PCI
> > enumeration. It creates PCI-PCI bridge and PCI device nodes.
> >
> > I use these series on an ACPI system.
> >
> > I need one more missing component: the node related to the PCI host bridge
> > This was the purpose of Clement's work. This work was not sent upstream yet and I
> > am working on it in order to have a full tree from the of_root to the PCI device
> > ie:
> > of_root <-- Frank Rowand series
> > + of_host_pci_bridge <-- Clement's work
> > + pci_bridge <-- Current Lizhi series
> > + pci_bridge <-- Current Lizhi series
> > ...
> > + pci_dev <-- Current Lizhi series
> >
> > Hope that this status helped.
>
> Thanks for the explanation! I suppose it's better to have three series combined
> into one and being sent with a better cover letter to explain all this. Also it
> might make sense (in my opinion) to Cc Jonathan (I did it here). Sorry, Jonathan,
> if you are not wanting this.
>
I'm lurking anyway via linux-pci :)
Indeed very interested in this. I'm carrying a local copy of Clement's series but
more than happy if Herve gets that bit ready for upstream.
I think we are still some way from this all working for a non trivial PCI card
on an ACPI system though. Maybe I'm wrong and the rest will turn out to be easy!
Jonathan
On Mon, Sep 18, 2023 at 2:17 AM Andy Shevchenko
<[email protected]> wrote:
>
> On Fri, Sep 15, 2023 at 07:30:08PM +0200, Herve Codina wrote:
> > On Wed, 13 Sep 2023 14:17:30 +0300
> > Andy Shevchenko <[email protected]> wrote:
> > > On Tue, Sep 12, 2023 at 02:12:04PM -0500, Rob Herring wrote:
> > > > On Mon, Sep 11, 2023 at 3:37 PM Andy Shevchenko
> > > > <[email protected]> wrote:
> > > > > On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:
>
> ...
>
> > > > > Can you point out to the ACPI excerpt(s) of the description of anything related
> > > > > to the device(s) in question?
> > > >
> > > > I don't understand what you are asking for.
> > >
> > > Through the email thread it was mentioned that this series was tested on the
> > > ACPI enabled platform, Jonathan (IIRC) asked why do we need to have a shadow
> > > DT for the something that ACPI already describes. That's why I'm trying to
> > > understand if it's the case. and if so, how can we improve the approach.
> >
> > Patches from Frank Rowand series [1] are needed to create an of_root_node if a DT
> > was not provided by the firmware, bootloader, etc that run the kernel.
> >
> > [1]: https://lore.kernel.org/lkml/[email protected]/
> >
> > Current Lizhi's series creates nodes from the PCI host node during the PCI
> > enumeration. It creates PCI-PCI bridge and PCI device nodes.
> >
> > I use these series on an ACPI system.
> >
> > I need one more missing component: the node related to the PCI host bridge
> > This was the purpose of Clement's work. This work was not sent upstream yet and I
> > am working on it in order to have a full tree from the of_root to the PCI device
> > ie:
> > of_root <-- Frank Rowand series
> > + of_host_pci_bridge <-- Clement's work
> > + pci_bridge <-- Current Lizhi series
> > + pci_bridge <-- Current Lizhi series
> > ...
> > + pci_dev <-- Current Lizhi series
> >
> > Hope that this status helped.
>
> Thanks for the explanation! I suppose it's better to have three series combined
> into one and being sent with a better cover letter to explain all this.
You can go back (years now) and see that. I asked for this to be split
up into manageable chunks and not solve multiple problems at once. No
point in trying to do DT on top of ACPI if DT on top of DT doesn't
work first.
Rob
On Thu, 21 Sep 2023 07:20:46 -0500
Rob Herring <[email protected]> wrote:
> On Mon, Sep 18, 2023 at 2:17 AM Andy Shevchenko
> <[email protected]> wrote:
> >
> > On Fri, Sep 15, 2023 at 07:30:08PM +0200, Herve Codina wrote:
> > > On Wed, 13 Sep 2023 14:17:30 +0300
> > > Andy Shevchenko <[email protected]> wrote:
> > > > On Tue, Sep 12, 2023 at 02:12:04PM -0500, Rob Herring wrote:
> > > > > On Mon, Sep 11, 2023 at 3:37 PM Andy Shevchenko
> > > > > <[email protected]> wrote:
> > > > > > On Tue, Aug 15, 2023 at 10:19:55AM -0700, Lizhi Hou wrote:
> >
> > ...
> >
> > > > > > Can you point out to the ACPI excerpt(s) of the description of anything related
> > > > > > to the device(s) in question?
> > > > >
> > > > > I don't understand what you are asking for.
> > > >
> > > > Through the email thread it was mentioned that this series was tested on the
> > > > ACPI enabled platform, Jonathan (IIRC) asked why do we need to have a shadow
> > > > DT for the something that ACPI already describes. That's why I'm trying to
> > > > understand if it's the case. and if so, how can we improve the approach.
> > >
> > > Patches from Frank Rowand series [1] are needed to create an of_root_node if a DT
> > > was not provided by the firmware, bootloader, etc that run the kernel.
> > >
> > > [1]: https://lore.kernel.org/lkml/[email protected]/
> > >
> > > Current Lizhi's series creates nodes from the PCI host node during the PCI
> > > enumeration. It creates PCI-PCI bridge and PCI device nodes.
> > >
> > > I use these series on an ACPI system.
> > >
> > > I need one more missing component: the node related to the PCI host bridge
> > > This was the purpose of Clement's work. This work was not sent upstream yet and I
> > > am working on it in order to have a full tree from the of_root to the PCI device
> > > ie:
> > > of_root <-- Frank Rowand series
> > > + of_host_pci_bridge <-- Clement's work
> > > + pci_bridge <-- Current Lizhi series
> > > + pci_bridge <-- Current Lizhi series
> > > ...
> > > + pci_dev <-- Current Lizhi series
> > >
> > > Hope that this status helped.
> >
> > Thanks for the explanation! I suppose it's better to have three series combined
> > into one and being sent with a better cover letter to explain all this.
>
> You can go back (years now) and see that. I asked for this to be split
> up into manageable chunks and not solve multiple problems at once. No
> point in trying to do DT on top of ACPI if DT on top of DT doesn't
> work first.
I agree.
Hervé
>
> Rob
--
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com