Has anyone verified PCI driver on yocto 3.14.28-1.0.1 branch?

[banyeer]

Hi,

The hardware we are using is imx6qsabreauto, and previously we can run our device driver successfully on 3.10.17 branch.

Recently we try to update the linux from 3.10.17 to 3.14.28, and the branch we try to use is following,

repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-3.14.28-1.0.1_patch

MACHINE=imx6qsabreauto source fsl-setup-release.sh –b build-x11 –e x11

When we try to load the device driver on 3.14.28, we found request_irq is failed when module_init.

I tried to compare the log between 3.10.17 and 3.14.28,  and found the irq number for PCI device is difference.

[3.10.17]

pci 0000:00:00.0: fixup irq: got 155
pci 0000:00:00.0: assigning IRQ 155
pci 0000:01:00.0: fixup irq: got 155
pci 0000:01:00.0: assigning IRQ 155
[3.14.28]
pci 0000:00:00.0: fixup irq: got 20
pci 0000:00:00.0: assigning IRQ 20
pci 0000:01:00.0: fixup irq: got 20

pci 0000:01:00.0: assigning IRQ 20

later in 3.14.28, when the device driver try to request_irq of 20, it returns failure.

My question is that does anyone has verified the PCI driver on 3.14.28 branch?

Thanks,

Banyeer

[Yuri]

  Another possible issue :  in “/drivers/pci/host/pci-imx6.c”, function

static int imx6_pcie_wait_for_link(struct pcie_port *pp), contains udelay(100).

The delay time should be longer then udelay(100). For the device which did

not work, maybe need more time between imx6_pcie_reset_phy and next-time link-up try.

Have a great day,
Yuri

[banyeer]

Thanks Yuri. I'll try it later.

Thanks,

Banyeer

[madisox]

I ran into this also after upgrading to 3.14.28, and tracked the problem down to the device tree entry for the interrupt controller in arch/arm/boot/dts/imx6qdl.dtsi.  Removing the lines for '#address-cells' and '#size-cells' fixed it:

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi

index 732f2d2..e0cd2b1 100644

--- a/arch/arm/boot/dts/imx6qdl.dtsi

+++ b/arch/arm/boot/dts/imx6qdl.dtsi

@@ -48,8 +48,6 @@

        intc: interrupt-controller@00a01000 {

                compatible = "arm,cortex-a9-gic";

                #interrupt-cells = <3>;

-               #address-cells = <1>;

-               #size-cells = <1>;

                interrupt-controller;

                reg = <0x00a01000 0x1000>,

                      <0x00a00100 0x100>;

Those lines mess up the creation of the IRQ mapping table.

[banyeer]

Thanks madisox. After your patch is applied, the IRQ num is now 155, the same value as 3.10.17 branch. request_irq is successful, and the driver can go a little far. But there's still some problem. I'm not sure if there's anything wrong with the device tree. I'll continue to debug it.

Thanks,

Banyeer

[banyeer]

Further investigation shows that though IRQ number is right,  there's still no interrupt. It seems that there's still something wrong with the device tree.

Thanks,

Banyeer

[madisox]

Do you happen to have CONFIG_PCI_MSI set in your kernel configuration?  I found I had to disable MSI support  to get PCI working properly on my board.  Fortunately, I didn't need it.

[gansm255]

Hi,

I disabled PCI_MSI in kernel config using bitbake. But, after building, flashing to sdcard and booting in smarc_samx6i target PCI_MSI is found to be set when i used zcat /proc/config.gz | grep PCI_MSI. The problem i face is i get No wireless extensions when i issue iwconfig. i am unable to scan nearby wireless access points. my kernel is yocto 3.14.28 and target it kontron smarc_samx6i board. Please help me. it appears .config file i changed using bitbake is not built in to image. in which file the .config file is located, in which make file the .config file is picked for building image using what macro.

thanks and regards,

murugan

[banyeer]

I disabled CONFIG_PCI_MSI, and PCI works fine now. It's quite strange that the option is set in 3.10.17 branch and the driver also works fine. But in 3.14.28, this option should be disabled, or else there's no interrupt received by the driver. Thanks very much for your help!

[madisox]

I thought it was strange, too.  Glad to know I'm not the only one that hit these problems - took long enough for me to figure them out!

[pjdowner]

Thanks madisox, I've just run into the same issues trying to get a custom PCIe card to work. The changes to the device tree helped to get our card recognised and loaded, but as mentioned we needed to disable MSI to get interrupts to work.

Can someone from Freescale comment on why these changes to the device tree are necessary and whether or not there will be an official fix for future kernels? Whilst kernel 3.10.17 worked perfectly there seems to be a lot of issues with 3.14.28 in regards to PCIe.