From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06 controllers driver to preapare for ACPI Date: Tue, 09 Feb 2016 17:27:05 +0100 Message-ID: <5968234.D2a3VCM72k@wuerfel> References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com> <3113837.YSNyDAf4HQ@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: In-Reply-To: Sender: linux-pci-owner@vger.kernel.org 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)" List-Id: linux-acpi@vger.kernel.org On Monday 08 February 2016 16:51:19 Gabriele Paoloni wrote: > > From: Arnd Bergmann [mailto:arnd@arndb.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? Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932949AbcBIQ2A (ORCPT ); Tue, 9 Feb 2016 11:28:00 -0500 Received: from mout.kundenserver.de ([212.227.126.133]:63373 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932640AbcBIQ15 (ORCPT ); Tue, 9 Feb 2016 11:27:57 -0500 From: Arnd Bergmann 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 Date: Tue, 09 Feb 2016 17:27:05 +0100 Message-ID: <5968234.D2a3VCM72k@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com> <3113837.YSNyDAf4HQ@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:fjAs0mVXXFpqXA2PxErNA5r5TEWIx+TfNFnUe9iFm/CKbInG/Xn HXGvAutEWkUTV9FX0NEnKZOfO2vnoLj6swNcQ22LXL8C3YKuAiMfHOJwHLzBsVuPKd4FjMe 3DvIBSnFM6ieWbhLi45gjqMSUK4LpNckmtrpj6b5aGC899Bluj7ufyMaLSfPDnCi5enZTSR 6od0KEUS+cLUyelJhLn0A== X-UI-Out-Filterresults: notjunk:1;V01:K0:zv3jT4LxqDQ=:+PciAx7NEh7BBpFfE8C5I5 g26Vrn0W/ydWXxQG7qrpCfTiCfaNxrQVUmR3GEZwrQFg+SR7hVs9gKJdbXu2dpHUmvyUJnowG uxeUISoOGkLc8Jh/skAkA6obzaKeLmGal84MlxD6TsIALhmif9UR4ZQqXyFpU6owkME4p3YWB 9wRAhslWRpUBRMnIOliUZ0loczesndRdmuUHMGFaRrIKxBrEddQbvhVA2iFMgO2DOQy66alM6 UkPSib4bEwI/34Z4XxH5TY1y6muN+lwmGQjjMXOeGXXGj3UxIpiGSc73BmCNIVW2Z/uwjqYk2 9OmaIMAy7HSYrUn/pWLsTWJjcr8nGxpIiLRrpnuYg/hXNTzUm898G1z2rHjHomaopmBEFhIkB 5v+aJ/2ETqiq76G1mqTfk7NEwA0XA88CWZ5Zth0DhAl1AZPZxsh8EtoywNCQipOdU+UNJCH1N VVJ/5+ZFUOcmHrlEZLgF9UNN18/0VtyZMuSJwgSA4tVAU84FeIsvB/7nxXmjVxvHJEXJoyuss 5JZwCtIp2wPpvVaZq+xRXqhPaolT7bY14IMM6q9YULQ/Zy4VG6Bd7hd1MdvXe7fZA/GHjOmCL 4UmsukJskWpYIPAnDTjKSbJ/jAcKwrAxJkvfFLuuxm9JBWIyt1yj2oSBzCNv5Eik/w85tJLDG Um1wgtdDIrtmwXXjV+I+1DaoXkHxcMs/dcBvDsMdhhpSVYtQ+KXrjcIAPv8SVglIWrzxvQ4i7 C3xJUo2tpFRZ/tiz Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 08 February 2016 16:51:19 Gabriele Paoloni wrote: > > From: Arnd Bergmann [mailto:arnd@arndb.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? Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Tue, 09 Feb 2016 17:27:05 +0100 Subject: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06 controllers driver to preapare for ACPI In-Reply-To: References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com> <3113837.YSNyDAf4HQ@wuerfel> Message-ID: <5968234.D2a3VCM72k@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Monday 08 February 2016 16:51:19 Gabriele Paoloni wrote: > > From: Arnd Bergmann [mailto:arnd at arndb.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? Arnd