[PATCH v4] PCI: Layerscape: Add Layerscape PCIe driver
Lian Minghuan-B31939
B31939 at freescale.com
Sun Oct 12 23:51:42 PDT 2014
Hi Arnd,
Sorry for delay in my reply.
Please see my comments inline.
On 2014年09月30日 17:18, Arnd Bergmann wrote:
> On Sunday 28 September 2014 15:08:27 Minghuan Lian wrote:
>> Add support for Freescale Layerscape PCIe controller. This driver
>> re-uses the designware core code.
>>
>> Signed-off-by: Minghuan Lian <Minghuan.Lian at freescale.com>
> I'm still not too happy about the MSI handling here. I think you
> really need to have a separate driver for the msi controller.
[Minghuan] LS1021 does not contains MSI controller.
SCFG contains only one register to implement MSI interrupt support.
And I reused pci-designware.c MSI API.
>> +/* SCFG MSI register */
>> +#define SCFG_SPIMSICR 0x40
>> +#define SCFG_SPIMSICLRCR 0x90
>> +
>> +#define MSI_LS1021A_ADDR 0x1570040
>> +#define MSI_LS1021A_DATA(pex_idx) (0xb3 + pex_idx)
> From what I can tell, the 'scfg' registers are mostly for MSI, and
> the MSI_LS1021A_ADDR that you have hardcoded here is actually part of
> the scfg area itself. You should never hardwire that in a PCI host
> driver.
>
> Please make a separate MSI driver instead and use the 'msi-parent'
> property.
[Minghuan] There is only one register in SCFG used for MSI.
I really do not want to write a separate MSI driver only for one
register and two MSI interrupts.
It is really not good to use hardcode MSI_LS1021A_ADDR.
I hope to change it when adding LS2085 PCI driver support.
SCFG contains some registers used for PCI link status, PCI error
interrupt and PCI PME support.
This is the first patch and will continue to improve.
>> +static u32 ls_pcie_get_msi_addr(struct pcie_port *pp)
>> +{
>> + return MSI_LS1021A_ADDR;
>> +}
>> +
>> +static u32 ls_pcie_get_msi_data(struct pcie_port *pp, int pos)
>> +{
>> + struct ls_pcie *pcie = to_ls_pcie(pp);
>> +
>> + return MSI_LS1021A_DATA(pcie->index);
>> +}
> Does this mean you can have only one device on this PCI host that
> uses MSI?
[Minghuan] Yes. LS1021A provides only one MSI interrupt for a PCI
controller NOT 32.
>> +static irqreturn_t ls_pcie_msi_irq_handler(int irq, void *data)
>> +{
>> + struct pcie_port *pp = data;
>> + struct ls_pcie *pcie = to_ls_pcie(pp);
>> + unsigned int msi_irq;
>> +
>> + /* clear the interrupt */
>> + regmap_write(pcie->scfg, SCFG_SPIMSICLRCR,
>> + MSI_LS1021A_DATA(pcie->index));
>> +
>> + msi_irq = irq_find_mapping(pp->irq_domain, 0);
>> + if (!msi_irq) {
>> + /*
>> + * that's weird who triggered this?
>> + * just clear it
>> + */
>> + dev_err(pcie->dev, "unexpected MSI\n");
>> + return IRQ_NONE;
>> + }
>> +
>> + generic_handle_irq(msi_irq);
>> + return IRQ_HANDLED;
>> +}
> Since you have only one addr/data value per host controller, does that mean
> that you can have only one device on this host that uses one interrupt?
>
> How do you ensure that the second user that tries to call pci_enable_msi
> gets an error? Is there only one internal device attached to the host?
[Minghuan] I used the following code to reserve 31 MSI interrupt.
static void ls1021a_pcie_msi_fixup(struct pcie_port *pp)
{
int i;
/*
* LS1021A has only one MSI interrupt
* Set all msi interrupts as used except the first one
*/
for (i = 1; i < MAX_MSI_IRQS; i++)
set_bit(i, pp->msi_irq_in_use);
}
>> + if (of_device_is_compatible(pcie->dev->of_node, "fsl,ls1021a-pcie")) {
>> + /*
>> + * LS1021A Workaround for internal TKT228622
>> + * to fix the INTx hang issue
>> + */
>> + val = ioread32(pcie->dbi + PCIE_STRFMR1);
>> + val &= 0xffff;
>> + iowrite32(val, pcie->dbi + PCIE_STRFMR1);
>> +
>> + ls1021a_pcie_msi_fixup(pp);
>> + }
>> +}
> "fsl,ls1021a-pcie" is the only one supported by this driver, so the
> check is useless.
[Minghuan] Ok. I will remove the 'if" and will re-add when adding LS2085
PCI driver.
> Arnd
More information about the linux-arm-kernel
mailing list