From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver to work on both Zynq and Microblaze
Date: Thu, 28 Jan 2016 14:49:45 +0000 [thread overview]
Message-ID: <20160128144944.GA12690@red-moon> (raw)
In-Reply-To: <3706176.5tvYx0gSBz@wuerfel>
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
next prev parent reply other threads:[~2016-01-28 14:49 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-12 17:36 [PATCH V2 0/5] PCIe Xilinx generic driver for Microblaze and Bharat Kumar Gogada
2016-01-12 17:36 ` [PATCH V2 1/5] PCI: xilinx: Removing xilinx_pcie_parse_and_add_res function Bharat Kumar Gogada
2016-01-12 17:36 ` [PATCH V2 2/5] PCI: xilinx: Removing struct hw_irq structure Bharat Kumar Gogada
2016-01-12 22:23 ` Arnd Bergmann
2016-01-27 14:27 ` Bharat Kumar Gogada
2016-01-12 17:36 ` [PATCH V2 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver to work on both Zynq and Microblaze Bharat Kumar Gogada
2016-01-12 22:27 ` Arnd Bergmann
2016-01-26 9:59 ` Michal Simek
2016-01-26 12:11 ` Arnd Bergmann
2016-01-26 15:21 ` Michal Simek
2016-01-27 14:41 ` Bharat Kumar Gogada
2016-01-27 14:33 ` Bharat Kumar Gogada
2016-01-27 15:14 ` Arnd Bergmann
2016-01-28 13:20 ` Bharat Kumar Gogada
2016-01-28 13:49 ` Arnd Bergmann
2016-01-28 14:18 ` Bharat Kumar Gogada
2016-01-28 14:23 ` Arnd Bergmann
2016-01-28 14:49 ` Lorenzo Pieralisi [this message]
2016-01-12 17:36 ` [PATCH V2 4/5] PCI: xilinx: Updating Zynq PCI binding documentation with Microblaze node Bharat Kumar Gogada
2016-01-15 2:33 ` Rob Herring
2016-01-12 17:36 ` [PATCH V2 5/5] Microblaze: Modifying microblaze PCI subsytem to support generic Xilinx AXI PCIe Host Bridge IP driver Bharat Kumar Gogada
2016-02-03 15:40 ` Bharat Kumar Gogada
2016-02-03 15:59 ` Bjorn Helgaas
2016-02-03 16:08 ` Bharat Kumar Gogada
2016-02-03 16:32 ` Bjorn Helgaas
2016-02-03 16:38 ` Bjorn Helgaas
2016-02-04 5:49 ` Bharat Kumar Gogada
2016-02-04 14:51 ` Bjorn Helgaas
2016-02-04 14:56 ` Bharat Kumar Gogada
2016-01-12 22:29 ` [PATCH V2 0/5] PCIe Xilinx generic driver for Microblaze and Arnd Bergmann
2016-01-27 14:35 ` Bharat Kumar Gogada
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160128144944.GA12690@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).