[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8520D5D51A55D047800579B0941471982586607F@XAP-PVEXMBX01.xlnx.xilinx.com>
Date: Wed, 25 Nov 2015 05:40:49 +0000
From: Bharat Kumar Gogada <bharat.kumar.gogada@...inx.com>
To: Marc Zyngier <marc.zyngier@....com>
CC: "robh+dt@...nel.org" <robh+dt@...nel.org>,
"pawel.moll@....com" <pawel.moll@....com>,
"mark.rutland@....com" <mark.rutland@....com>,
"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
"galak@...eaurora.org" <galak@...eaurora.org>,
Michal Simek <michals@...inx.com>,
Soren Brinkmann <sorenb@...inx.com>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"arnd@...db.de" <arnd@...db.de>,
"tinamdar@....com" <tinamdar@....com>,
"treding@...dia.com" <treding@...dia.com>,
"rjui@...adcom.com" <rjui@...adcom.com>,
"Minghuan.Lian@...escale.com" <Minghuan.Lian@...escale.com>,
"m-karicheri2@...com" <m-karicheri2@...com>,
"hauke@...ke-m.de" <hauke@...ke-m.de>,
"dhdang@....com" <dhdang@....com>,
"sbranden@...adcom.com" <sbranden@...adcom.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
Ravikiran Gummaluri <rgummal@...inx.com>
Subject: RE: [PATCH v9] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL
PCIe Host Controller
> On Thu, 19 Nov 2015 11:05:23 +0530
> Bharat Kumar Gogada <bharat.kumar.gogada@...inx.com> wrote:
>
> > Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> >
> > Signed-off-by: Bharat Kumar Gogada <bharatku@...inx.com>
> > Signed-off-by: Ravi Kiran Gummaluri <rgummal@...inx.com>
> > Acked-by: Rob Herring <robh@...nel.org>
> > ---
> > +
> > +#define MSI_ADDRESS 0xDEED0000
>
> How did you pick this value? What if it intersect with some actual RAM?
> What if a device actually does DMA to that location?
>
> Wouldn't it make sense to actually pick a real *device* address (hint:
> your MSI controller itself) for this purpose, as the device will never DMA
> there?
>
>
We have already mentioned in previous patch discussion, we don't have any device address on our SOC for MSI, that's
the reason we are allocating a page for MSI in RAM. Since our memory write is consumed by bridge and doesn't write to memory, you suggested to use
some random address, so using some random address.
>
>
> > +
> > +static int nwl_irq_domain_alloc(struct irq_domain *domain, unsigned int
> virq,
> > + unsigned int nr_irqs, void *args) {
> > + struct nwl_pcie *pcie = domain->host_data;
> > + struct nwl_msi *msi = &pcie->msi;
> > + int bit;
> > + int i;
> > + int ret;
> > +
> > + mutex_lock(&msi->lock);
> > + if (nr_irqs > 1) {
> > + ret = nwl_check_hwirq(msi, nr_irqs);
> > + if (ret < 0) {
> > + mutex_unlock(&msi->lock);
> > + return ret;
> > + }
> > + } else {
> > + ret = find_first_zero_bit(msi->used, INT_PCI_MSI_NR);
> > + if (ret == INT_PCI_MSI_NR) {
> > + mutex_unlock(&msi->lock);
> > + return -ENOSPC;
> > + }
> > + }
>
> Let's be serious for a minute. What's wrong with
> bitmap_find_next_zero_area, for example?
Ok, will explore this API and do accordingly, and address in next patch.
>
> > +
> > + for (i = 0; i < nr_irqs; i++) {
> > + bit = ret + i;
> > + set_bit(bit, msi->used);
> > +
> > + irq_domain_set_info(domain, virq + i, bit, &nwl_irq_chip,
> > + domain->host_data, handle_simple_irq,
> > + NULL, NULL);
> > + }
> > + mutex_unlock(&msi->lock);
> > +
> > + return 0;
> > +}
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists