PCI enumeration and IRQ_CONNECT ?


Marcus Shawcroft <marcus.shawcroft@...>
 

Hi,

A question has come up in one of the config_info refactor patches
about the relationship between PCI enumeration and IRQ_CONNECT.... (
https://gerrit.zephyrproject.org/r/#/c/5427/2 )

Can anyone shed some light on how PCI enumeration and IRQ_CONNECT
interact in the DW GPIO, I2C and SPI drivers?

Specifically, the initialization of these drivers appears to be that:
- PCI enumeration populates driver_data->pci_dev via a call to pci_bus_scan()
- irq_num is pulled out of the pci_dev structure and stored in the
driver context.
- irq_enable() is called to enable the irq_num
- IRQ_CONNECT() is called to connect a hardwired (static) IRQ number
(e.g CONFIG_INTEL_PORT_0_IRQ) to the interrupt service routine.

Hence we have an statically configured interrupt number passed to
IRQ_CONNECT() and an irq_num returned from PCI enumeration, and no
obvious connection between the two.

How does the isr get connected to the interrupt from pci enumeration?

Cheers
/Marcus


Liu, Baohong
 

-----Original Message-----
From: Marcus Shawcroft [mailto:marcus.shawcroft(a)gmail.com]
Sent: Wednesday, October 12, 2016 2:59 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] PCI enumeration and IRQ_CONNECT ?

Hi,

A question has come up in one of the config_info refactor patches about the
relationship between PCI enumeration and IRQ_CONNECT.... (
https://gerrit.zephyrproject.org/r/#/c/5427/2 )

Can anyone shed some light on how PCI enumeration and IRQ_CONNECT
interact in the DW GPIO, I2C and SPI drivers?

Specifically, the initialization of these drivers appears to be that:
- PCI enumeration populates driver_data->pci_dev via a call to pci_bus_scan()
- irq_num is pulled out of the pci_dev structure and stored in the driver
context.
- irq_enable() is called to enable the irq_num
- IRQ_CONNECT() is called to connect a hardwired (static) IRQ number (e.g
CONFIG_INTEL_PORT_0_IRQ) to the interrupt service routine.

Hence we have an statically configured interrupt number passed to
IRQ_CONNECT() and an irq_num returned from PCI enumeration, and no
obvious connection between the two.

How does the isr get connected to the interrupt from pci enumeration?
IRQ_CONNECT is solely for compilation time. IRQ_CONNECT_DYNAMIC was for run time, but, it was removed weeks ago.


Cheers
/Marcus


Boie, Andrew P
 

On Wed, 2016-10-12 at 10:59 +0100, Marcus Shawcroft wrote:
Hi,

A question has come up in one of the config_info refactor patches
about the relationship between PCI enumeration and IRQ_CONNECT.... (
https://gerrit.zephyrproject.org/r/#/c/5427/2 )

Can anyone shed some light on how PCI enumeration and IRQ_CONNECT
interact in the DW GPIO, I2C and SPI drivers?

Specifically, the initialization of these drivers appears to be that:
- PCI enumeration populates driver_data->pci_dev via a call to pci_bus_scan()
- irq_num is pulled out of the pci_dev structure and stored in the
driver context.
- irq_enable() is called to enable the  irq_num
- IRQ_CONNECT() is called to connect a hardwired (static) IRQ number
(e.g CONFIG_INTEL_PORT_0_IRQ) to the interrupt service routine.

Hence we have an statically configured interrupt number passed to
IRQ_CONNECT() and an irq_num returned from PCI enumeration, and no
obvious connection between the two.
This might be some cruft that should be fixed. Even on a PCI board like Galileo,
the IRQ lines are fixed in HW so IRQ_CONNECT() uses (and can only use due to the
way it is implemented) defined constants.

In other words, the irq_num pulled out of PCI enumeration doesn't need to be
used/stored and we should just use the defined constant everywhere. Unless
something pathological is going on they should be the same value.

Andrew


Dmitriy Korovkin
 

On Sun, 16 Oct 2016, Boie, Andrew P wrote:

On Wed, 2016-10-12 at 10:59 +0100, Marcus Shawcroft wrote:
Hi,

A question has come up in one of the config_info refactor patches
about the relationship between PCI enumeration and IRQ_CONNECT.... (
https://gerrit.zephyrproject.org/r/#/c/5427/2 )

Can anyone shed some light on how PCI enumeration and IRQ_CONNECT
interact in the DW GPIO, I2C and SPI drivers?

Specifically, the initialization of these drivers appears to be that:
- PCI enumeration populates driver_data->pci_dev via a call to pci_bus_scan()
- irq_num is pulled out of the pci_dev structure and stored in the
driver context.
- irq_enable() is called to enable the  irq_num
- IRQ_CONNECT() is called to connect a hardwired (static) IRQ number
(e.g CONFIG_INTEL_PORT_0_IRQ) to the interrupt service routine.

Hence we have an statically configured interrupt number passed to
IRQ_CONNECT() and an irq_num returned from PCI enumeration, and no
obvious connection between the two.
This might be some cruft that should be fixed. Even on a PCI board like Galileo,
the IRQ lines are fixed in HW so IRQ_CONNECT() uses (and can only use due to the
way it is implemented) defined constants.

In other words, the irq_num pulled out of PCI enumeration doesn't need to be
used/stored and we should just use the defined constant everywhere. Unless
something pathological is going on they should be the same value.
And by "something pathological" you mean insertion of an external card.
PCI_ENUMERATION is enabled for Galileo exactly for this reason.
/Dmitriy

Andrew


Boie, Andrew P
 

On Mon, 2016-10-17 at 11:05 -0400, Dmitriy Korovkin wrote:
 
In other words, the irq_num pulled out of PCI enumeration doesn't need to be
used/stored and we should just use the defined constant everywhere. Unless
something pathological is going on they should be the same value.
And by "something pathological" you mean insertion of an external card.
PCI_ENUMERATION is enabled for Galileo exactly for this reason.
/Dmitriy
Yes but this is not typical of the sort of boards we are targeting.
Galileo is a board that can run Linux. It is not an interesting target for
Zephyr. It is being used for Zephyr for reasons which are largely historical or
due to convenience/availability at the time the bring-up is done. The sort of
MCUs that a lightweight OS like Zephyr targets are not going to have hot-
pluggable PCI busses.

Andrew


Dmitriy Korovkin
 

On Mon, 17 Oct 2016, Boie, Andrew P wrote:

On Mon, 2016-10-17 at 11:05 -0400, Dmitriy Korovkin wrote:

In other words, the irq_num pulled out of PCI enumeration doesn't need to be
used/stored and we should just use the defined constant everywhere. Unless
something pathological is going on they should be the same value.
And by "something pathological" you mean insertion of an external card.
PCI_ENUMERATION is enabled for Galileo exactly for this reason.
/Dmitriy
Yes but this is not typical of the sort of boards we are targeting.
Galileo is a board that can run Linux. It is not an interesting target for
Zephyr. It is being used for Zephyr for reasons which are largely historical or
due to convenience/availability at the time the bring-up is done. The sort of
MCUs that a lightweight OS like Zephyr targets are not going to have hot-
pluggable PCI busses.
Then it comes to a question if Zephyr OS should drop the Galileo bards
support.
/Dmitriy

Andrew


Boie, Andrew P
 

On Mon, 2016-10-17 at 11:41 -0400, Dmitriy Korovkin wrote:
 
Yes but this is not typical of the sort of boards we are targeting.
Galileo is a board that can run Linux. It is not an interesting target for
Zephyr. It is being used for Zephyr for reasons which are largely historical
or
due to convenience/availability at the time the bring-up is done. The sort
of
MCUs that a lightweight OS like Zephyr targets are not going to have hot-
pluggable PCI busses.
Then it comes to a question if Zephyr OS should drop the Galileo bards 
support.
/Dmitriy
I've raised this with Anas a few times. He can comment here, but my
understanding is that there are still a bunch of people still doing work or
demoing things with Galileo since they were cheap and easy to get ahold of. I
would like to see Galileo removed from the tree as well.

Andrew


Dmitriy Korovkin
 

On Mon, 17 Oct 2016, Boie, Andrew P wrote:

On Mon, 2016-10-17 at 11:41 -0400, Dmitriy Korovkin wrote:

Yes but this is not typical of the sort of boards we are targeting.
Galileo is a board that can run Linux. It is not an interesting target for
Zephyr. It is being used for Zephyr for reasons which are largely historical
or
due to convenience/availability at the time the bring-up is done. The sort
of
MCUs that a lightweight OS like Zephyr targets are not going to have hot-
pluggable PCI busses.
Then it comes to a question if Zephyr OS should drop the Galileo bards
support.
/Dmitriy
I've raised this with Anas a few times. He can comment here, but my
understanding is that there are still a bunch of people still doing work or
demoing things with Galileo since they were cheap and easy to get ahold of. I
would like to see Galileo removed from the tree as well.

Andrew
Then we need to deal with it's specifics. At one time I tried to configure
IRQs through PCI legacy module, and it helped, but just partially.

/Dmitriy.


Boie, Andrew P
 

On Mon, 2016-10-17 at 11:48 -0400, Dmitriy Korovkin wrote:
 
Then we need to deal with it's specifics. At one time I tried to configure 
IRQs through PCI legacy module, and it helped, but just partially.
 
What is the specific problem you are seeing?
Are you dealing with interrupts whose properties aren't known at compile time?
Are you saying we need to put dynamic IRQs back in the kernel just to deal with
Galileo? That's not gonna happen..

Andrew