All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gabriele Paoloni <gabriele.paoloni@huawei.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Guohanjun (Hanjun Guo)" <guohanjun@huawei.com>,
	"Wangzhou (B)" <wangzhou1@hisilicon.com>,
	"liudongdong (C)" <liudongdong3@huawei.com>,
	Linuxarm <linuxarm@huawei.com>, qiujiang <qiujiang@huawei.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"Lorenzo.Pieralisi@arm.com" <Lorenzo.Pieralisi@arm.com>,
	"tn@semihalf.com" <tn@semihalf.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xuwei (O)" <xuwei5@hisilicon.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"jcm@redhat.com" <jcm@redhat.com>,
	zhangjukuo <zhangjukuo@huawei.com>,
	"Liguozhu (Kenneth)" <liguozhu@hisilicon.com>
Subject: RE: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06 controllers driver to preapare for ACPI
Date: Mon, 8 Feb 2016 16:51:19 +0000	[thread overview]
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECAD249@lhreml503-mbs> (raw)
In-Reply-To: <3113837.YSNyDAf4HQ@wuerfel>

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: 08 February 2016 16:33
> To: Gabriele Paoloni
> Cc: linux-arm-kernel@lists.infradead.org; Guohanjun (Hanjun Guo);
> Wangzhou (B); liudongdong (C); Linuxarm; qiujiang; bhelgaas@google.com;
> Lorenzo.Pieralisi@arm.com; tn@semihalf.com; linux-pci@vger.kernel.org;
> linux-kernel@vger.kernel.org; xuwei (O); linux-acpi@vger.kernel.org;
> jcm@redhat.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:06:54 Gabriele Paoloni wrote:
> > >
> > > On Monday 08 February 2016 12:41:02 Gabriele Paoloni wrote:
> > > > +
> > > > +/* HipXX PCIe host only supports 32-bit config access */
> > > > +int hisi_pcie_common_cfg_read(void __iomem *reg_base, int where,
> int
> > > size,
> > > > +                         u32 *val)
> > > > +{
> > > > +   u32 reg;
> > > > +   u32 reg_val;
> > > > +   void *walker = &reg_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...

Thanks 

Gab

> 
> 	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: gabriele.paoloni@huawei.com (Gabriele Paoloni)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06 controllers driver to preapare for ACPI
Date: Mon, 8 Feb 2016 16:51:19 +0000	[thread overview]
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECAD249@lhreml503-mbs> (raw)
In-Reply-To: <3113837.YSNyDAf4HQ@wuerfel>

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 08 February 2016 16:33
> To: Gabriele Paoloni
> Cc: linux-arm-kernel at lists.infradead.org; Guohanjun (Hanjun Guo);
> Wangzhou (B); liudongdong (C); Linuxarm; qiujiang; bhelgaas at google.com;
> Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-pci at vger.kernel.org;
> linux-kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> jcm at redhat.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:06:54 Gabriele Paoloni wrote:
> > >
> > > On Monday 08 February 2016 12:41:02 Gabriele Paoloni wrote:
> > > > +
> > > > +/* HipXX PCIe host only supports 32-bit config access */
> > > > +int hisi_pcie_common_cfg_read(void __iomem *reg_base, int where,
> int
> > > size,
> > > > +                         u32 *val)
> > > > +{
> > > > +   u32 reg;
> > > > +   u32 reg_val;
> > > > +   void *walker = &reg_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...

Thanks 

Gab

> 
> 	Arnd

  reply	other threads:[~2016-02-08 16:51 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-08 12:41 [RFC PATCH v2 0/3] Add ACPI support for HiSilicon PCIe Host Controllers Gabriele Paoloni
2016-02-08 12:41 ` Gabriele Paoloni
2016-02-08 12:41 ` Gabriele Paoloni
2016-02-08 12:41 ` [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06 controllers driver to preapare for ACPI Gabriele Paoloni
2016-02-08 12:41   ` Gabriele Paoloni
2016-02-08 12:41   ` Gabriele Paoloni
2016-02-08 13:50   ` Arnd Bergmann
2016-02-08 13:50     ` Arnd Bergmann
2016-02-08 16:06     ` Gabriele Paoloni
2016-02-08 16:06       ` Gabriele Paoloni
2016-02-08 16:06       ` Gabriele Paoloni
2016-02-08 16:32       ` Arnd Bergmann
2016-02-08 16:32         ` Arnd Bergmann
2016-02-08 16:32         ` Arnd Bergmann
2016-02-08 16:51         ` Gabriele Paoloni [this message]
2016-02-08 16:51           ` Gabriele Paoloni
2016-02-08 16:51           ` Gabriele Paoloni
2016-02-09 16:27           ` Arnd Bergmann
2016-02-09 16:27             ` Arnd Bergmann
2016-02-09 16:27             ` Arnd Bergmann
2016-02-09 16:52             ` Gabriele Paoloni
2016-02-09 16:52               ` Gabriele Paoloni
2016-02-09 16:52               ` Gabriele Paoloni
2016-02-08 12:41 ` [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host controller ECAM compliant Gabriele Paoloni
2016-02-08 12:41   ` Gabriele Paoloni
2016-02-08 12:41   ` Gabriele Paoloni
2016-02-08 13:48   ` Arnd Bergmann
2016-02-08 13:48     ` Arnd Bergmann
2016-02-08 15:55     ` Gabriele Paoloni
2016-02-08 15:55       ` Gabriele Paoloni
2016-02-08 15:55       ` Gabriele Paoloni
2016-02-08 16:29       ` Arnd Bergmann
2016-02-08 16:29         ` Arnd Bergmann
2016-02-08 16:29         ` Arnd Bergmann
2016-02-08 16:29         ` Arnd Bergmann
2016-02-08 17:21         ` Gabriele Paoloni
2016-02-08 17:21           ` Gabriele Paoloni
2016-02-08 17:21           ` Gabriele Paoloni
2016-02-09 15:32           ` Arnd Bergmann
2016-02-09 15:32             ` Arnd Bergmann
2016-02-09 15:56             ` Gabriele Paoloni
2016-02-09 15:56               ` Gabriele Paoloni
2016-02-09 15:56               ` Gabriele Paoloni
2016-02-08 12:41 ` [RFC PATCH v2 3/3] PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers Gabriele Paoloni
2016-02-08 12:41   ` Gabriele Paoloni
2016-02-08 12:41   ` Gabriele Paoloni
2016-08-31 11:48 [RFC PATCH V2 0/3] Add ACPI support for Hisilicon PCIe Host Controller Dongdong Liu
2016-08-31 11:48 ` [RFC PATCH V2 1/3] PCI: hisi: re-architect Hip05/Hip06 controllers driver to preapare for ACPI Dongdong Liu
2016-08-31 11:48   ` Dongdong Liu
2016-08-31 11:45   ` Arnd Bergmann
2016-09-01  2:05     ` Dongdong Liu
2016-09-01  2:05       ` Dongdong Liu
2016-09-01  7:41       ` Arnd Bergmann
2016-09-01  7:41         ` Arnd Bergmann
2016-09-01 12:44         ` Dongdong Liu
2016-09-01 12:44           ` Dongdong Liu
2016-09-01 14:02           ` Arnd Bergmann
2016-09-01 14:02             ` Arnd Bergmann
2016-09-02  2:02             ` Dongdong Liu
2016-09-02  2:02               ` Dongdong Liu
2016-09-20  9:45             ` Gabriele Paoloni
2016-09-20  9:45               ` Gabriele Paoloni
2016-09-20  9:45               ` Gabriele Paoloni
2016-09-20 13:22               ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EE11001F9E5DDD47B7634E2F8A612F2E1ECAD249@lhreml503-mbs \
    --to=gabriele.paoloni@huawei.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=guohanjun@huawei.com \
    --cc=jcm@redhat.com \
    --cc=liguozhu@hisilicon.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=liudongdong3@huawei.com \
    --cc=qiujiang@huawei.com \
    --cc=tn@semihalf.com \
    --cc=wangzhou1@hisilicon.com \
    --cc=xuwei5@hisilicon.com \
    --cc=zhangjukuo@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.