Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1320670 > unrolled thread

RE: [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver to work on both Zynq and Microblaze

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge  driver to  work on both  Zynq and Microblaze Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> - 2016-01-28 14:30 +0100
    Re: [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver to  work on both  Zynq and Microblaze Arnd Bergmann <arnd@arndb.de> - 2016-01-28 15:00 +0100
      Re: [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver to  work on both  Zynq and Microblaze Arnd Bergmann <arnd@arndb.de> - 2016-01-28 15:30 +0100
        Re: [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge  driver to  work on both  Zynq and Microblaze Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-01-28 15:50 +0100
      RE: [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge  driver to  work on both  Zynq and Microblaze Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> - 2016-01-28 15:30 +0100

#1320670 — RE: [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver to work on both Zynq and Microblaze

> Subject: Re: [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver
> to work on both Zynq and Microblaze
> 
> On Wednesday 27 January 2016 14:33:45 Bharat Kumar Gogada wrote:
> > > > @@ -705,7 +715,9 @@ static int xilinx_pcie_probe(struct
> > > > platform_device *pdev)  #endif
> > > >     pci_scan_child_bus(bus);
> > > >     pci_assign_unassigned_bus_resources(bus);
> > > > +#ifdef CONFIG_ARM
> > > >     pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
> > > > +#endif
> > > >     pci_bus_add_devices(bus);
> > > >     platform_set_drvdata(pdev, port);
> > >
> > > Here it looks like microblaze gets it right. I'm not sure why we
> > > still need the
> > > pci_fixup_irqs() on ARM, but my feeling is that this should be fixed
> > > in common code.
> > In arm pci_fixup_irqs is called by pci_common_init_dev
> (arch/arm/kernel/bios32.c), since this API is removed now, I was calling it
> separately.
> 
> But who calls it in microblaze? If it works without the extra call there, can we
> make it work the same way for ARM?
> 
In microblaze I have added pcibios_add_device call (similar to call in arch/arm64/kernel/pci.c ) in pci-common.c, which is being invoked by kernel core itself. May be we can add similar on arm and test out, but we might need some cleanup in arch/arm/kernel/bios32.c

Bharat

[toc] | [next] | [standalone]

#1320694 — Re: [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver to work on both Zynq and Microblaze

On Thursday 28 January 2016 13:20:56 Bharat Kumar Gogada wrote:
> > Subject: Re: [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver
> > to work on both Zynq and Microblaze
> > 
> > On Wednesday 27 January 2016 14:33:45 Bharat Kumar Gogada wrote:
> > > > > @@ -705,7 +715,9 @@ static int xilinx_pcie_probe(struct
> > > > > platform_device *pdev)  #endif
> > > > >     pci_scan_child_bus(bus);
> > > > >     pci_assign_unassigned_bus_resources(bus);
> > > > > +#ifdef CONFIG_ARM
> > > > >     pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
> > > > > +#endif
> > > > >     pci_bus_add_devices(bus);
> > > > >     platform_set_drvdata(pdev, port);
> > > >
> > > > Here it looks like microblaze gets it right. I'm not sure why we
> > > > still need the
> > > > pci_fixup_irqs() on ARM, but my feeling is that this should be fixed
> > > > in common code.
> > > In arm pci_fixup_irqs is called by pci_common_init_dev
> > (arch/arm/kernel/bios32.c), since this API is removed now, I was calling it
> > separately.
> > 
> > But who calls it in microblaze? If it works without the extra call there, can we
> > make it work the same way for ARM?
> > 
> In microblaze I have added pcibios_add_device call (similar to call in
> arch/arm64/kernel/pci.c ) in pci-common.c, which is being invoked by
> kernel core itself.

I see. In the upstream code you seem to do it in pcibios_setup_bus_devices(),
while arm64 and powerpc do it in pcibios_add_device().

> May be we can add similar on arm and test out, but
> we might need some cleanup in arch/arm/kernel/bios32.c

I think that would still just be a half-baked solution. This should
really be fully automatic. We could do it in the __weak
pcibios_add_device() for all architectures that don't override
it when the bus was probed from DT, or we could do it in
pci_read_irq().

	Arnd

[toc] | [prev] | [next] | [standalone]

#1320723 — Re: [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver to work on both Zynq and Microblaze

On Thursday 28 January 2016 14:18:15 Bharat Kumar Gogada wrote:
> > 
> > I see. In the upstream code you seem to do it in
> > pcibios_setup_bus_devices(), while arm64 and powerpc do it in
> > pcibios_add_device().
> > 
> No that function is not getting called with generic API's, its getting called with pcibios_init flow which is tightly bound with struct pci_controller microblaze specific structure. So I added pcibios_add_device in pci-common.c.

Ok

> > > May be we can add similar on arm and test out, but we might need some
> > > cleanup in arch/arm/kernel/bios32.c
> > 
> > I think that would still just be a half-baked solution. This should really be fully
> > automatic. We could do it in the __weak
> > pcibios_add_device() for all architectures that don't override it when the bus
> > was probed from DT, or we could do it in pci_read_irq().
> When will pci_read_irq() call get invoked ?

This is called early on when a device gets created in pci_setup_device(),
so platforms can still override the value later.

The idea here is that normally a BIOS stores the interrupt number in
the PCI_INTERRUPT_LINE config space byte, and we just read it from
there. Generally speaking though, for non-PC systems we tend to not
have a BIOS that writes these values to start with, and any values
stored in here have no meaning in combination with SPARSE_IRQ
and/or IRQ_DOMAINS because the bootloader or BIOS doesn't know
what IRQ number will refer to hardware IRQ line in Linux.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1320745

On Thu, Jan 28, 2016 at 03:23:37PM +0100, Arnd Bergmann wrote:
> On Thursday 28 January 2016 14:18:15 Bharat Kumar Gogada wrote:
> > > 
> > > I see. In the upstream code you seem to do it in
> > > pcibios_setup_bus_devices(), while arm64 and powerpc do it in
> > > pcibios_add_device().
> > > 
> > No that function is not getting called with generic API's, its getting called with pcibios_init flow which is tightly bound with struct pci_controller microblaze specific structure. So I added pcibios_add_device in pci-common.c.
> 
> Ok
> 
> > > > May be we can add similar on arm and test out, but we might need some
> > > > cleanup in arch/arm/kernel/bios32.c
> > > 
> > > I think that would still just be a half-baked solution. This should really be fully
> > > automatic. We could do it in the __weak
> > > pcibios_add_device() for all architectures that don't override it when the bus
> > > was probed from DT, or we could do it in pci_read_irq().
> > When will pci_read_irq() call get invoked ?
> 
> This is called early on when a device gets created in pci_setup_device(),
> so platforms can still override the value later.
> 
> The idea here is that normally a BIOS stores the interrupt number in
> the PCI_INTERRUPT_LINE config space byte, and we just read it from
> there. Generally speaking though, for non-PC systems we tend to not
> have a BIOS that writes these values to start with, and any values
> stored in here have no meaning in combination with SPARSE_IRQ
> and/or IRQ_DOMAINS because the bootloader or BIOS doesn't know
> what IRQ number will refer to hardware IRQ line in Linux.

I think the best way to handle this is through Matthew's series (below),
in the interim a callback in arch code would do, we will clean it up when
Matthew's series goes upstream, it should not take too long.

http://www.spinics.net/lists/linux-pci/msg45950.html

Thanks,
Lorenzo

[toc] | [prev] | [next] | [standalone]

#1320727

> Subject: Re: [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver
> to work on both Zynq and Microblaze
> 
> On Thursday 28 January 2016 13:20:56 Bharat Kumar Gogada wrote:
> > > Subject: Re: [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host
> > > Bridge driver to work on both Zynq and Microblaze
> > >
> > > On Wednesday 27 January 2016 14:33:45 Bharat Kumar Gogada wrote:
> > > > > > @@ -705,7 +715,9 @@ static int xilinx_pcie_probe(struct
> > > > > > platform_device *pdev)  #endif
> > > > > >     pci_scan_child_bus(bus);
> > > > > >     pci_assign_unassigned_bus_resources(bus);
> > > > > > +#ifdef CONFIG_ARM
> > > > > >     pci_fixup_irqs(pci_common_swizzle,
> > > > > > of_irq_parse_and_map_pci);
> > > > > > +#endif
> > > > > >     pci_bus_add_devices(bus);
> > > > > >     platform_set_drvdata(pdev, port);
> > > > >
> > > > > Here it looks like microblaze gets it right. I'm not sure why we
> > > > > still need the
> > > > > pci_fixup_irqs() on ARM, but my feeling is that this should be
> > > > > fixed in common code.
> > > > In arm pci_fixup_irqs is called by pci_common_init_dev
> > > (arch/arm/kernel/bios32.c), since this API is removed now, I was
> > > calling it separately.
> > >
> > > But who calls it in microblaze? If it works without the extra call
> > > there, can we make it work the same way for ARM?
> > >
> > In microblaze I have added pcibios_add_device call (similar to call in
> > arch/arm64/kernel/pci.c ) in pci-common.c, which is being invoked by
> > kernel core itself.
> 
> I see. In the upstream code you seem to do it in
> pcibios_setup_bus_devices(), while arm64 and powerpc do it in
> pcibios_add_device().
> 
No that function is not getting called with generic API's, its getting called with pcibios_init flow which is tightly bound with struct pci_controller microblaze specific structure. So I added pcibios_add_device in pci-common.c.

> > May be we can add similar on arm and test out, but we might need some
> > cleanup in arch/arm/kernel/bios32.c
> 
> I think that would still just be a half-baked solution. This should really be fully
> automatic. We could do it in the __weak
> pcibios_add_device() for all architectures that don't override it when the bus
> was probed from DT, or we could do it in pci_read_irq().
When will pci_read_irq() call get invoked ?

Bharat

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web