[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECAF48D@lhreml503-mbs>
Date: Tue, 9 Feb 2016 16:52:38 +0000
From: Gabriele Paoloni <gabriele.paoloni@...wei.com>
To: Arnd Bergmann <arnd@...db.de>
CC: "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"Guohanjun (Hanjun Guo)" <guohanjun@...wei.com>,
"Wangzhou (B)" <wangzhou1@...ilicon.com>,
"liudongdong (C)" <liudongdong3@...wei.com>,
Linuxarm <linuxarm@...wei.com>, qiujiang <qiujiang@...wei.com>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"Lorenzo.Pieralisi@....com" <Lorenzo.Pieralisi@....com>,
"tn@...ihalf.com" <tn@...ihalf.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"xuwei (O)" <xuwei5@...ilicon.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"jcm@...hat.com" <jcm@...hat.com>,
zhangjukuo <zhangjukuo@...wei.com>,
"Liguozhu (Kenneth)" <liguozhu@...ilicon.com>
Subject: RE: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06
controllers driver to preapare for ACPI
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@...db.de]
> Sent: 09 February 2016 16:27
> To: Gabriele Paoloni
> Cc: linux-arm-kernel@...ts.infradead.org; Guohanjun (Hanjun Guo);
> Wangzhou (B); liudongdong (C); Linuxarm; qiujiang; bhelgaas@...gle.com;
> Lorenzo.Pieralisi@....com; tn@...ihalf.com; linux-pci@...r.kernel.org;
> linux-kernel@...r.kernel.org; xuwei (O); linux-acpi@...r.kernel.org;
> jcm@...hat.com; zhangjukuo; Liguozhu (Kenneth)
> Subject: Re: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06
> controllers driver to preapare for ACPI
>
> On Monday 08 February 2016 16:51:19 Gabriele Paoloni wrote:
> > > From: Arnd Bergmann [mailto:arnd@...db.de]
> > > On Monday 08 February 2016 16:06:54 Gabriele Paoloni wrote:
> > > > > On Monday 08 February 2016 12:41:02 Gabriele Paoloni wrote:
> > > int
> > > > > size,
> > > > > > + u32 *val)
> > > > > > +{
> > > > > > + u32 reg;
> > > > > > + u32 reg_val;
> > > > > > + void *walker = ®_val;
> > > > > > +
> > > > > > + walker += (where & 0x3);
> > > > > > + reg = where & ~0x3;
> > > > > > + reg_val = readl(reg_base + reg);
> > > > > > +
> > > > > > + if (size == 1)
> > > > > > + *val = *(u8 __force *) walker;
> > > > > > + else if (size == 2)
> > > > > > + *val = *(u16 __force *) walker;
> > > > > > + else if (size == 4)
> > > > > > + *val = reg_val;
> > > > > > + else
> > > > > > + return PCIBIOS_BAD_REGISTER_NUMBER;
> > > > > > +
> > > > > > + return PCIBIOS_SUCCESSFUL;
> > > > > > +}
> > > > >
> > > > > Isn't this the same hack that Qualcomm are using?
> > > >
> > > > As far as I can see Qualcomm defines its own config access
> > > > mechanism only for RC config read and also it seems they're
> > > > having problems with reporting the device class...
> > > >
> > > >
> https://github.com/torvalds/linux/blob/master/drivers/pci/host/pcie-
> > > qcom.c#L474
> > > >
> > > > Our problem is that our HW can only perform 32b rd/wr accesses
> > > > So we can't use readw/readb/writew/writeb...
> > > >
> > > >
> > >
> > > Sorry, my mistake, I meant Cavium not Qualcomm.
> > > See https://lkml.org/lkml/2016/2/5/689 for the patches.
> >
> > Well, looking at it Cavium seems quite different,
> >
> > On read they need to trigger the retrieval of the
> > config space info writing to the lower 32b of a 64b register,
> > then they need to read data back on the upper 64b of the
> > same register and adjust the content to remove the garbage...
> >
> > We just use 32b accesses and adjust grab the appropriate
> > bytes depending on the read/write sizes...
>
> Hmm, I must have misremembered that too then, let me try once more ;-)
>
> The above appears to reimplement pci_generic_config_read32(). Can you
> just use that instead?
Nope I don't think so,
When we read the root complex config space we need to use a configuration
address space that is different from the one used to map the rest of the
hierarchy; I think this is something to do with Designware itself. It
is clear if you look at
http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L657
Here you can see that in calling "dw_pcie_wr_own_conf" Designware does not
pass "bus" and "devfn" that are actually required by pci_generic_config_read32()
to map the addr...
Many Thanks
Gab
>
> Arnd
Powered by blists - more mailing lists