* Re: [PATCH v2 14/22] MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
From: Thierry Reding @ 2014-09-25 7:36 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, sparclinux,
linux-arch, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <1411614872-4009-15-git-send-email-wangyijing@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 834 bytes --]
On Thu, Sep 25, 2014 at 11:14:24AM +0800, Yijing Wang wrote:
> Use MSI chip framework instead of arch MSI functions to configure
> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Nit: s/irq/IRQ/ in the above.
> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
> ---
> arch/mips/pci/msi-xlp.c | 14 ++++++++++++--
> 1 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/mips/pci/msi-xlp.c b/arch/mips/pci/msi-xlp.c
> index e469dc7..6b791ef 100644
> --- a/arch/mips/pci/msi-xlp.c
> +++ b/arch/mips/pci/msi-xlp.c
> @@ -245,7 +245,7 @@ static struct irq_chip xlp_msix_chip = {
> .irq_unmask = unmask_msi_irq,
> };
>
> -void arch_teardown_msi_irq(unsigned int irq)
> +void xlp_teardown_msi_irq(unsigned int irq)
Should this not be static now as well?
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 15/22] MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
From: Thierry Reding @ 2014-09-25 7:37 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, sparclinux,
linux-arch, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <1411614872-4009-16-git-send-email-wangyijing@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]
On Thu, Sep 25, 2014 at 11:14:25AM +0800, Yijing Wang wrote:
[...]
> diff --git a/arch/mips/pci/pci-xlr.c b/arch/mips/pci/pci-xlr.c
[...]
> @@ -214,11 +214,11 @@ static int get_irq_vector(const struct pci_dev *dev)
> }
>
> #ifdef CONFIG_PCI_MSI
> -void arch_teardown_msi_irq(unsigned int irq)
> +void xlr_teardown_msi_irq(unsigned int irq)
> {
> }
>
> -int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
> +int xlr_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
Can both of these now be static?
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 17/22] s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
From: Thierry Reding @ 2014-09-25 7:38 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, sparclinux,
linux-arch, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <1411614872-4009-18-git-send-email-wangyijing@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 381 bytes --]
On Thu, Sep 25, 2014 at 11:14:27AM +0800, Yijing Wang wrote:
[...]
> diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
[...]
> @@ -358,7 +358,7 @@ static void zpci_irq_handler(struct airq_struct *airq)
> }
> }
>
> -int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
> +int zpci_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
static?
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Thierry Reding @ 2014-09-25 7:42 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, sparclinux,
linux-arch, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <1411614872-4009-1-git-send-email-wangyijing@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]
On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
>
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!
Apart from the comments to the individual patches I very much like where
this is going. Thanks for taking care of this.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v4 01/10] tools/perf: support parsing parameterized events
From: Jiri Olsa @ 2014-09-25 8:58 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: ak, Michael Ellerman, peterz, linux-kernel, eranian, dev,
Arnaldo Carvalho de Melo, Paul Mackerras, linuxppc-dev,
Anshuman Khandual
In-Reply-To: <1411586844-21381-2-git-send-email-sukadev@linux.vnet.ibm.com>
On Wed, Sep 24, 2014 at 12:27:15PM -0700, Sukadev Bhattiprolu wrote:
> From: Cody P Schafer <cody@linux.vnet.ibm.com>
>
> Enable event specification like:
>
> pmu/event_name,param1=0x1,param2=0x4/
>
> Assuming that
>
> /sys/bus/event_source/devices/pmu/events/event_name
>
> Contains something like
>
> param2=foo,bar=1,param1=baz
hum, so what happened to the '?' ... AFAIU from out last discussion,
you wanted to mark terms which are mandatory and user must provide
values for them.. and I thought the decision was to have following
alias record:
$ cat /sys/bus/event_source/devices/pmu/events/event_name
param2=?,bar=1,param1=?
while perf would scream if any of param1/2 wasnt filled like for:
pmu/event_name,param1=0x1/
thanks,
jirka
^ permalink raw reply
* Re: [PATCH v2 01/22] PCI/MSI: Clean up struct msi_chip argument
From: Thomas Gleixner @ 2014-09-25 10:20 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, sparclinux,
Yijing Wang, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
linux-arm-kernel, Thomas Petazzoni, Xinwei Hu, Tony Luck,
Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu, David Vrabel,
Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <20140925071536.GG12423@ulmo>
On Thu, 25 Sep 2014, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:11AM +0800, Yijing Wang wrote:
> > Msi_chip functions setup_irq/teardown_irq rarely use msi_chip
> > argument.
>
> That's not true. Out of the four drivers that you modify two use the
> parameter. And the two that don't probably should be using it too.
>
> 50% is not "rarely". =)
>
> > We can look up msi_chip pointer by the device pointer
> > or irq number, so clean up msi_chip argument.
>
> I don't like this particular change. The idea was to keep the API object
> oriented so that drivers wouldn't have to know where to get the MSI chip
> from. It also makes it more resilient against code reorganizations since
> the core code is the only place that needs to know where to get the chip
> from.
Right. We have the same thing in the irq_chip callbacks. All of them
take "struct irq_data", because it's already available in the core
code and it gives easy access to all information (chip, chipdata ...)
which is necessary for the callback implementations.
Thanks,
tglx
^ permalink raw reply
* RE: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
From: Jingchang Lu @ 2014-09-25 9:47 UTC (permalink / raw)
To: mturquette@linaro.org, Scott Wood
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Jingchang Lu
In-Reply-To: <1411454806-8214-1-git-send-email-jingchang.lu@freescale.com>
SGksIFNjb3R0IGFuZCBNaWtlLA0KICANCiAgQ291bGQgeW91IHBsZWFzZSBoZWxwIHJldmlldyB0
aGlzIHBhdGNoIGFuZCBnaXZlIGFuIEFDSyBpZiBvay4gVGhhbmtzLg0KDQpCZXN0IFJlZ2FyZHMs
DQpKaW5nY2hhbmcNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogSmluZ2No
YW5nIEx1IFttYWlsdG86amluZ2NoYW5nLmx1QGZyZWVzY2FsZS5jb21dDQo+U2VudDogVHVlc2Rh
eSwgU2VwdGVtYmVyIDIzLCAyMDE0IDI6NDcgUE0NCj5UbzogbXR1cnF1ZXR0ZUBsaW5hcm8ub3Jn
DQo+Q2M6IFdvb2QgU2NvdHQtQjA3NDIxOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsg
bGludXgtDQo+a2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGludXgtYXJtLWtlcm5lbEBsaXN0cy5p
bmZyYWRlYWQub3JnOyBMdQ0KPkppbmdjaGFuZy1CMzUwODMNCj5TdWJqZWN0OiBbUEFUQ0h2NF0g
Y2xrOiBwcGMtY29yZW5ldDogcmVuYW1lIHRvIHBwYy1xb3JpcSBhbmQgYWRkDQo+Q0xLX09GX0RF
Q0xBUkUgc3VwcG9ydA0KPg0KPlRoZSBJUCBpcyBzaGFyZWQgYnkgUFBDIGFuZCBBUk0sIHRoaXMg
cmVuYW1lcyBpdCB0byBxb3JpcSBmb3IgYmV0dGVyDQo+cmVwcmVzZW50aW9uLCBhbmQgdGhpcyBh
bHNvIGFkZHMgdGhlIENMS19PRl9ERUNMQVJFIHN1cHBvcnQgZm9yIGJlaW5nDQo+aW5pdGlhbGl6
ZWQgYnkgb2ZfY2xrX2luaXQoKSBvbiBBUk0uDQo+DQo+U2lnbmVkLW9mZi1ieTogSmluZ2NoYW5n
IEx1IDxqaW5nY2hhbmcubHVAZnJlZXNjYWxlLmNvbT4NCj4tLS0NCj5jaGFuZ2VzIGluIHY0Og0K
PiByZW1vdmUgImNvcmVuZXQiIGxpdGVyYWxzIG9taXR0ZWQgaW4gdjMgcmVtb3ZlLg0KPg0KPmNo
YW5nZXMgaW4gdjM6DQo+IGdlbmVyYXRlIHRoZSBwYXRjaCB3aXRoIC1NIC1DIG9wdGlvbg0KPg0K
PmNoYW5nZXMgaW4gdjI6DQo+IHJlbmFtZSB0aGUgZHJpdmVyIG5hbWUgdG8gcHBjLXFvcmlxLmMg
Zm9yIHNoYXJlZCBvbiBQUEMgYW5kIEFSTS4NCj4NCj4gZHJpdmVycy9jbGsvS2NvbmZpZyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8ICA5ICsrKysrLS0tLQ0KPiBkcml2ZXJzL2Nsay9NYWtl
ZmlsZSAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDIgKy0NCj4gZHJpdmVycy9jbGsve2Ns
ay1wcGMtY29yZW5ldC5jID0+IGNsay1xb3JpcS5jfSB8IDI3ICsrKysrKysrKysrKysrKy0tLS0t
LQ0KPi0tLS0tDQo+IDMgZmlsZXMgY2hhbmdlZCwgMjIgaW5zZXJ0aW9ucygrKSwgMTYgZGVsZXRp
b25zKC0pICByZW5hbWUNCj5kcml2ZXJzL2Nsay97Y2xrLXBwYy1jb3JlbmV0LmMgPT4gY2xrLXFv
cmlxLmN9ICg4OSUpDQo+DQo+ZGlmZiAtLWdpdCBhL2RyaXZlcnMvY2xrL0tjb25maWcgYi9kcml2
ZXJzL2Nsay9LY29uZmlnIGluZGV4DQo+ODUxMzFhZS4uZjVmNzZjYiAxMDA2NDQNCj4tLS0gYS9k
cml2ZXJzL2Nsay9LY29uZmlnDQo+KysrIGIvZHJpdmVycy9jbGsvS2NvbmZpZw0KPkBAIC05Miwx
MiArOTIsMTMgQEAgY29uZmlnIENPTU1PTl9DTEtfQVhJX0NMS0dFTg0KPiAJICBTdXBwb3J0IGZv
ciB0aGUgQW5hbG9nIERldmljZXMgYXhpLWNsa2dlbiBwY29yZSBjbG9jayBnZW5lcmF0b3INCj5m
b3IgWGlsaW54DQo+IAkgIEZQR0FzLiBJdCBpcyBjb21tb25seSB1c2VkIGluIEFuYWxvZyBEZXZp
Y2VzJyByZWZlcmVuY2UgZGVzaWducy4NCj4NCj4tY29uZmlnIENMS19QUENfQ09SRU5FVA0KPi0J
Ym9vbCAiQ2xvY2sgZHJpdmVyIGZvciBQb3dlclBDIGNvcmVuZXQgcGxhdGZvcm1zIg0KPi0JZGVw
ZW5kcyBvbiBQUENfRTUwME1DICYmIE9GDQo+K2NvbmZpZyBDTEtfUU9SSVENCj4rCWJvb2wgIkNs
b2NrIGRyaXZlciBmb3IgUG93ZXJQQyBjb3JlbmV0IGFuZCBjb21wYXRpYmxlIEFSTS1iYXNlZA0K
PnBsYXRmb3JtcyINCj4rCWRlcGVuZHMgb24gKFBQQ19FNTAwTUMgfHwgQVJNKSAmJiBPRg0KPiAJ
LS0taGVscC0tLQ0KPiAJICBUaGlzIGFkZHMgdGhlIGNsb2NrIGRyaXZlciBzdXBwb3J0IGZvciBG
cmVlc2NhbGUgUG93ZXJQQyBjb3JlbmV0DQo+LQkgIHBsYXRmb3JtcyB1c2luZyBjb21tb24gY2xv
Y2sgZnJhbWV3b3JrLg0KPisJICBwbGF0Zm9ybXMgYW5kIGNvbXBhdGlibGUgRnJlZXNjYWxlIEFS
TSBiYXNlZCBwbGF0Zm9ybXMgdXNpbmcNCj5jb21tb24NCj4rCSAgY2xvY2sgZnJhbWV3b3JrLg0K
Pg0KPiBjb25maWcgQ09NTU9OX0NMS19YR0VORQ0KPiAJYm9vbCAiQ2xvY2sgZHJpdmVyIGZvciBB
UE0gWEdlbmUgU29DIg0KPmRpZmYgLS1naXQgYS9kcml2ZXJzL2Nsay9NYWtlZmlsZSBiL2RyaXZl
cnMvY2xrL01ha2VmaWxlIGluZGV4DQo+MjdjNTQyYi4uMjBmNDJlOSAxMDA2NDQNCj4tLS0gYS9k
cml2ZXJzL2Nsay9NYWtlZmlsZQ0KPisrKyBiL2RyaXZlcnMvY2xrL01ha2VmaWxlDQo+QEAgLTI5
LDcgKzI5LDcgQEAgb2JqLSQoQ09ORklHX0FSQ0hfTU9YQVJUKQkJKz0gY2xrLW1veGFydC5vDQo+
IG9iai0kKENPTkZJR19BUkNIX05PTUFESUspCQkrPSBjbGstbm9tYWRpay5vDQo+IG9iai0kKENP
TkZJR19BUkNIX05TUElSRSkJCSs9IGNsay1uc3BpcmUubw0KPiBvYmotJChDT05GSUdfQ09NTU9O
X0NMS19QQUxNQVMpCQkrPSBjbGstcGFsbWFzLm8NCj4tb2JqLSQoQ09ORklHX0NMS19QUENfQ09S
RU5FVCkJCSs9IGNsay1wcGMtY29yZW5ldC5vDQo+K29iai0kKENPTkZJR19DTEtfUU9SSVEpCQkJ
Kz0gY2xrLXFvcmlxLm8NCj4gb2JqLSQoQ09ORklHX0NPTU1PTl9DTEtfUzJNUFMxMSkJKz0gY2xr
LXMybXBzMTEubw0KPiBvYmotJChDT05GSUdfQ09NTU9OX0NMS19TSTUzNTEpCQkrPSBjbGstc2k1
MzUxLm8NCj4gb2JqLSQoQ09ORklHX0NPTU1PTl9DTEtfU0k1NzApCQkrPSBjbGstc2k1NzAubw0K
PmRpZmYgLS1naXQgYS9kcml2ZXJzL2Nsay9jbGstcHBjLWNvcmVuZXQuYyBiL2RyaXZlcnMvY2xr
L2Nsay1xb3JpcS5jDQo+c2ltaWxhcml0eSBpbmRleCA4OSUgcmVuYW1lIGZyb20gZHJpdmVycy9j
bGsvY2xrLXBwYy1jb3JlbmV0LmMgcmVuYW1lIHRvDQo+ZHJpdmVycy9jbGsvY2xrLXFvcmlxLmMg
aW5kZXggOGU1OGVkZi4uY2JhOGFiZSAxMDA2NDQNCj4tLS0gYS9kcml2ZXJzL2Nsay9jbGstcHBj
LWNvcmVuZXQuYw0KPisrKyBiL2RyaXZlcnMvY2xrL2Nsay1xb3JpcS5jDQo+QEAgLTE1NSw3ICsx
NTUsNyBAQCBzdGF0aWMgdm9pZCBfX2luaXQgY29yZV9wbGxfaW5pdChzdHJ1Y3QgZGV2aWNlX25v
ZGUNCj4qbnApDQo+DQo+IAliYXNlID0gb2ZfaW9tYXAobnAsIDApOw0KPiAJaWYgKCFiYXNlKSB7
DQo+LQkJcHJfZXJyKCJjbGstcHBjOiBpb21hcCBlcnJvclxuIik7DQo+KwkJcHJfZXJyKCJjbGst
cW9yaXE6IGlvbWFwIGVycm9yXG4iKTsNCj4gCQlyZXR1cm47DQo+IAl9DQo+DQo+QEAgLTI1Miw3
ICsyNTIsNyBAQCBzdGF0aWMgdm9pZCBfX2luaXQgc3lzY2xrX2luaXQoc3RydWN0IGRldmljZV9u
b2RlDQo+Km5vZGUpDQo+IAl1MzIgcmF0ZTsNCj4NCj4gCWlmICghbnApIHsNCj4tCQlwcl9lcnIo
InBwYy1jbGs6IGNvdWxkIG5vdCBnZXQgcGFyZW50IG5vZGVcbiIpOw0KPisJCXByX2VycigicW9y
aXEtY2xrOiBjb3VsZCBub3QgZ2V0IHBhcmVudCBub2RlXG4iKTsNCj4gCQlyZXR1cm47DQo+IAl9
DQo+DQo+QEAgLTI3OCwzMCArMjc4LDM1IEBAIHN0YXRpYyBjb25zdCBzdHJ1Y3Qgb2ZfZGV2aWNl
X2lkIGNsa19tYXRjaFtdDQo+X19pbml0Y29uc3QgPSB7DQo+IAl7fQ0KPiB9Ow0KPg0KPi1zdGF0
aWMgaW50IF9faW5pdCBwcGNfY29yZW5ldF9jbGtfcHJvYmUoc3RydWN0IHBsYXRmb3JtX2Rldmlj
ZSAqcGRldikNCj4rc3RhdGljIGludCBfX2luaXQgcW9yaXFfY2xrX3Byb2JlKHN0cnVjdCBwbGF0
Zm9ybV9kZXZpY2UgKnBkZXYpDQo+IHsNCj4gCW9mX2Nsa19pbml0KGNsa19tYXRjaCk7DQo+DQo+
IAlyZXR1cm4gMDsNCj4gfQ0KPg0KPi1zdGF0aWMgY29uc3Qgc3RydWN0IG9mX2RldmljZV9pZCBw
cGNfY2xrX2lkc1tdIF9faW5pdGNvbnN0ID0gew0KPitzdGF0aWMgY29uc3Qgc3RydWN0IG9mX2Rl
dmljZV9pZCBxb3JpcV9jbGtfaWRzW10gX19pbml0Y29uc3QgPSB7DQo+IAl7IC5jb21wYXRpYmxl
ID0gImZzbCxxb3JpcS1jbG9ja2dlbi0xLjAiLCB9LA0KPiAJeyAuY29tcGF0aWJsZSA9ICJmc2ws
cW9yaXEtY2xvY2tnZW4tMi4wIiwgfSwNCj4gCXt9DQo+IH07DQo+DQo+LXN0YXRpYyBzdHJ1Y3Qg
cGxhdGZvcm1fZHJpdmVyIHBwY19jb3JlbmV0X2Nsa19kcml2ZXIgX19pbml0ZGF0YSA9IHsNCj4r
c3RhdGljIHN0cnVjdCBwbGF0Zm9ybV9kcml2ZXIgcW9yaXFfY2xrX2RyaXZlciBfX2luaXRkYXRh
ID0gew0KPiAJLmRyaXZlciA9IHsNCj4tCQkubmFtZSA9ICJwcGNfY29yZW5ldF9jbG9jayIsDQo+
KwkJLm5hbWUgPSAicW9yaXFfY2xvY2siLA0KPiAJCS5vd25lciA9IFRISVNfTU9EVUxFLA0KPi0J
CS5vZl9tYXRjaF90YWJsZSA9IHBwY19jbGtfaWRzLA0KPisJCS5vZl9tYXRjaF90YWJsZSA9IHFv
cmlxX2Nsa19pZHMsDQo+IAl9LA0KPi0JLnByb2JlID0gcHBjX2NvcmVuZXRfY2xrX3Byb2JlLA0K
PisJLnByb2JlID0gcW9yaXFfY2xrX3Byb2JlLA0KPiB9Ow0KPg0KPi1zdGF0aWMgaW50IF9faW5p
dCBwcGNfY29yZW5ldF9jbGtfaW5pdCh2b2lkKQ0KPitzdGF0aWMgaW50IF9faW5pdCBxb3JpcV9j
bGtfaW5pdCh2b2lkKQ0KPiB7DQo+LQlyZXR1cm4gcGxhdGZvcm1fZHJpdmVyX3JlZ2lzdGVyKCZw
cGNfY29yZW5ldF9jbGtfZHJpdmVyKTsNCj4rCXJldHVybiBwbGF0Zm9ybV9kcml2ZXJfcmVnaXN0
ZXIoJnFvcmlxX2Nsa19kcml2ZXIpOw0KPiB9DQo+LXN1YnN5c19pbml0Y2FsbChwcGNfY29yZW5l
dF9jbGtfaW5pdCk7DQo+K3N1YnN5c19pbml0Y2FsbChxb3JpcV9jbGtfaW5pdCk7DQo+Kw0KPitD
TEtfT0ZfREVDTEFSRShxb3JpcV9jb3JlX3BsbF92MSwgImZzbCxxb3JpcS1jb3JlLXBsbC0xLjAi
LA0KPitjb3JlX3BsbF9pbml0KTsgQ0xLX09GX0RFQ0xBUkUocW9yaXFfY29yZV9wbGxfdjIsDQo+
KyJmc2wscW9yaXEtY29yZS1wbGwtMi4wIiwgY29yZV9wbGxfaW5pdCk7DQo+K0NMS19PRl9ERUNM
QVJFKHFvcmlxX2NvcmVfbXV4X3YxLCAiZnNsLHFvcmlxLWNvcmUtbXV4LTEuMCIsDQo+K2NvcmVf
bXV4X2luaXQpOyBDTEtfT0ZfREVDTEFSRShxb3JpcV9jb3JlX211eF92MiwNCj4rImZzbCxxb3Jp
cS1jb3JlLW11eC0yLjAiLCBjb3JlX211eF9pbml0KTsNCj4tLQ0KPjEuOC4wDQoNCg==
^ permalink raw reply
* Re: [PATCH v2 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
From: Thomas Gleixner @ 2014-09-25 10:38 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
linux-arm-kernel, Thomas Petazzoni, Xinwei Hu, Tony Luck,
Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu, David Vrabel,
Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <1411614872-4009-7-git-send-email-wangyijing@huawei.com>
On Thu, 25 Sep 2014, Yijing Wang wrote:
> Introduce weak arch_find_msi_chip() to find the match msi_chip.
> Currently, MSI chip associates pci bus to msi_chip. Because in
> ARM platform, there may be more than one MSI controller in system.
> Associate pci bus to msi_chip help pci device to find the match
> msi_chip and setup MSI/MSI-X irq correctly. But in other platform,
> like in x86. we only need one MSI chip, because all device use
> the same MSI address/data and irq etc. So it's no need to associate
> pci bus to MSI chip, just use a arch function, arch_find_msi_chip()
> to return the MSI chip for simplicity. The default weak
> arch_find_msi_chip() used in ARM platform, find the MSI chip
> by pci bus.
This is really backwards. On one hand you try to get rid of the weak
arch functions zoo and then you invent new ones for no good
reason. Why can't x86 store the chip in the pci bus?
Looking deeper, I'm questioning the whole notion of different
msi_chips. Are this really different MSI controllers with a different
feature set or are this defacto multiple instances of the same
controller which just need a different data set?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
From: Laurentiu Tudor @ 2014-09-25 12:55 UTC (permalink / raw)
To: Jingchang Lu, mturquette
Cc: scottwood, linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <1411454806-8214-1-git-send-email-jingchang.lu@freescale.com>
Hi Jingchang,
On 09/23/2014 09:46 AM, Jingchang Lu wrote:
> The IP is shared by PPC and ARM, this renames it to qoriq for better
> represention, and this also adds the CLK_OF_DECLARE support for being
> initialized by of_clk_init() on ARM.
>
I think you need to also update drivers/cpufreq/Kconfig.powerpc
to use the renamed config option.
---
Best Regards, Laurentiu
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Konrad Rzeszutek Wilk @ 2014-09-25 14:23 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Chris Metcalf, Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Thomas Petazzoni, Xinwei Hu, Tony Luck, Sergei Shtylyov,
linux-kernel, Ralf Baechle, iommu, David Vrabel, Wuyun,
linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <1411614872-4009-1-git-send-email-wangyijing@huawei.com>
On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
Is there a git tree for these patches?
>
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!
>
> v1->v2:
> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
>
> RFC->v1:
> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
> of #ifdef to fix MSI bug in xen running in x86.
> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
> Drop use struct device as the msi_chip argument, we will do that
> later in another patchset.
>
> Yijing Wang (22):
> PCI/MSI: Clean up struct msi_chip argument
> PCI/MSI: Remove useless bus->msi assignment
> MSI: Remove the redundant irq_set_chip_data()
> x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
> s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
> PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
> PCI/MSI: Refactor struct msi_chip to make it become more common
> x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
> x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
> Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
> x86/MSI: Remove unused MSI weak arch functions
> MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
> MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
> MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
> MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
> Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
> s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
> arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
> IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
> Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
> tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
> PCI/MSI: Clean up unused MSI arch functions
>
> arch/arm/mach-iop13xx/include/mach/pci.h | 2 +
> arch/arm/mach-iop13xx/iq81340mc.c | 1 +
> arch/arm/mach-iop13xx/iq81340sc.c | 1 +
> arch/arm/mach-iop13xx/msi.c | 9 ++-
> arch/arm/mach-iop13xx/pci.c | 6 ++
> arch/ia64/kernel/msi_ia64.c | 18 ++++-
> arch/mips/pci/msi-octeon.c | 35 ++++++----
> arch/mips/pci/msi-xlp.c | 18 ++++--
> arch/mips/pci/pci-xlr.c | 15 ++++-
> arch/powerpc/kernel/msi.c | 14 +++-
> arch/s390/pci/pci.c | 18 ++++-
> arch/sparc/kernel/pci.c | 14 +++-
> arch/tile/kernel/pci_gx.c | 14 +++-
> arch/x86/include/asm/apic.h | 4 +
> arch/x86/include/asm/pci.h | 4 +-
> arch/x86/include/asm/x86_init.h | 7 --
> arch/x86/kernel/apic/io_apic.c | 16 ++++-
> arch/x86/kernel/x86_init.c | 34 ---------
> arch/x86/pci/xen.c | 60 +++++++++-------
> drivers/iommu/irq_remapping.c | 9 ++-
> drivers/irqchip/irq-armada-370-xp.c | 8 +--
> drivers/pci/host/pci-tegra.c | 8 ++-
> drivers/pci/host/pcie-designware.c | 4 +-
> drivers/pci/host/pcie-rcar.c | 8 ++-
> drivers/pci/msi.c | 114 ++++++++++++++----------------
> drivers/pci/probe.c | 1 -
> include/linux/msi.h | 26 ++-----
> 27 files changed, 266 insertions(+), 202 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v2 04/22] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
From: Konrad Rzeszutek Wilk @ 2014-09-25 14:33 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Chris Metcalf, Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Thomas Petazzoni, Xinwei Hu, Tony Luck, Sergei Shtylyov,
linux-kernel, Ralf Baechle, iommu, David Vrabel, Wuyun,
linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <1411614872-4009-5-git-send-email-wangyijing@huawei.com>
On Thu, Sep 25, 2014 at 11:14:14AM +0800, Yijing Wang wrote:
> Commit 0e4ccb150 added two __weak arch functions arch_msix_mask_irq()
> and arch_msi_mask_irq() to fix a bug found when running xen in x86.
> Introduced these two funcntions make MSI code complex. And mask/unmask
"These two functions made the MSI code more complex."
> is the irq actions related to interrupt controller, should not use
> weak arch functions to override mask/unmask interfaces. This patch
I am bit baffled of what you are saying.
> reverted commit 0e4ccb150 and export struct irq_chip msi_chip, modify
> msi_chip->irq_mask/irq_unmask() in xen init functions to fix this
> bug for simplicity. Also this is preparation for using struct
> msi_chip instead of weak arch MSI functions in all platforms.
> Keep default_msi_mask_irq() and default_msix_mask_irq() in
> linux/msi.h to make s390 MSI code compile happy, they wiil be removed
s/wiil/will.
> in the later patch.
>
> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
I don't even remember testing it - I guess I did the earlier version.
So a couple of questions since I've totally forgotten about this:
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 50f67a3..5f8f3af 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -162,7 +162,7 @@ static inline __attribute_const__ u32 msi_mask(unsigned x)
> * reliably as devices without an INTx disable bit will then generate a
> * level IRQ which will never be cleared.
> */
> -u32 default_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
> +u32 __msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
> {
> u32 mask_bits = desc->masked;
>
> @@ -176,14 +176,9 @@ u32 default_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
> return mask_bits;
> }
>
> -__weak u32 arch_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
> -{
> - return default_msi_mask_irq(desc, mask, flag);
> -}
> -
> static void msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
> {
> - desc->masked = arch_msi_mask_irq(desc, mask, flag);
> + desc->masked = __msi_mask_irq(desc, mask, flag);
> }
>
> /*
> @@ -193,7 +188,7 @@ static void msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
> * file. This saves a few milliseconds when initialising devices with lots
> * of MSI-X interrupts.
> */
> -u32 default_msix_mask_irq(struct msi_desc *desc, u32 flag)
> +u32 __msix_mask_irq(struct msi_desc *desc, u32 flag)
> {
> u32 mask_bits = desc->masked;
> unsigned offset = desc->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE +
> @@ -206,14 +201,9 @@ u32 default_msix_mask_irq(struct msi_desc *desc, u32 flag)
> return mask_bits;
> }
>
> -__weak u32 arch_msix_mask_irq(struct msi_desc *desc, u32 flag)
> -{
> - return default_msix_mask_irq(desc, flag);
> -}
> -
> static void msix_mask_irq(struct msi_desc *desc, u32 flag)
> {
> - desc->masked = arch_msix_mask_irq(desc, flag);
> + desc->masked = __msix_mask_irq(desc, flag);
> }
>
> static void msi_set_mask_bit(struct irq_data *data, u32 flag)
> @@ -852,7 +842,7 @@ void pci_msi_shutdown(struct pci_dev *dev)
> /* Return the device with MSI unmasked as initial states */
> mask = msi_mask(desc->msi_attrib.multi_cap);
> /* Keep cached state to be restored */
> - arch_msi_mask_irq(desc, mask, ~mask);
> + __msi_mask_irq(desc, mask, ~mask);
If I am reading this right, it will call the old 'default_msi_mask_irq'
which is exactly what we don't want to do under Xen. We want to call
the NOP code.
>
> /* Restore dev->irq to its default pin-assertion irq */
> dev->irq = desc->msi_attrib.default_irq;
> @@ -950,7 +940,7 @@ void pci_msix_shutdown(struct pci_dev *dev)
> /* Return the device with MSI-X masked as initial states */
> list_for_each_entry(entry, &dev->msi_list, list) {
> /* Keep cached states to be restored */
> - arch_msix_mask_irq(entry, 1);
> + __msix_mask_irq(entry, 1);
Ditto here.
Looking more at this code I have to retract my Reviewed-by and Tested-by
on the whole series.
Is it possible to get a git tree for this please?
> }
>
> msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0);
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index 45ef8cb..cc46a62 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -19,6 +19,8 @@ void read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
> void get_cached_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
> void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
> void write_msi_msg(unsigned int irq, struct msi_msg *msg);
> +u32 __msix_mask_irq(struct msi_desc *desc, u32 flag);
> +u32 __msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag);
>
> struct msi_desc {
> struct {
> @@ -59,8 +61,8 @@ void arch_restore_msi_irqs(struct pci_dev *dev);
>
> void default_teardown_msi_irqs(struct pci_dev *dev);
> void default_restore_msi_irqs(struct pci_dev *dev);
> -u32 default_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag);
> -u32 default_msix_mask_irq(struct msi_desc *desc, u32 flag);
> +#define default_msi_mask_irq __msi_mask_irq
> +#define default_msix_mask_irq __msix_mask_irq
>
> struct msi_chip {
> struct module *owner;
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Liviu Dudau @ 2014-09-25 14:48 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, sparclinux,
Yijing Wang, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <20140925074235.GN12423@ulmo>
On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > This series is based Bjorn's pci/msi branch
> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> >
> > Currently, there are a lot of weak arch functions in MSI code.
> > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > This series use MSI chip framework to refactor MSI code across all platforms
> > to eliminate weak arch functions. Then all MSI irqs will be managed in a
> > unified framework. Because this series changed a lot of ARCH MSI code,
> > so tests in the platforms which MSI code modified are warmly welcomed!
>
> Apart from the comments to the individual patches I very much like where
> this is going. Thanks for taking care of this.
>
> Thierry
I am actually in disagreement with you, Thierry. I don't like the general direction
of the patches, or at least I don't like the fact that we don't have a portable
way of setting up the msi_chip without having to rely on weak architectural hooks.
I'm surprised no one considers the case of a platform having more than one host
bridge and possibly more than one MSI unit. With the current proposed patchset I
can't see how that would work.
What I would like to see is a way of creating the pci_host_bridge structure outside
the pci_create_root_bus(). That would then allow us to pass this sort of platform
details like associated msi_chip into the host bridge and the child busses will
have an easy way of finding the information needed by finding the root bus and then
the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
everyone and the drivers can remove their kludges that try to work around the
current limitations.
Best regards,
Liviu
---------------------
.oooO
( )
\ ( Oooo.
\_) ( )
) /
(_/
One small step
for me ...
^ permalink raw reply
* Re: bit fields && data tearing
From: Pavel Machek @ 2014-09-25 16:12 UTC (permalink / raw)
To: Peter Hurley
Cc: Jakub Jelinek, linux-arch@vger.kernel.org,
linux-arm@vger.kernel.org, Tony Luck, linux-ia64@vger.kernel.org,
One Thousand Gnomes, Oleg Nesterov, linux-kernel@vger.kernel.org,
James Bottomley, David Laight, Paul Mackerras, Mikael Pettersson,
H. Peter Anvin, 'paulmck@linux.vnet.ibm.com',
linuxppc-dev@lists.ozlabs.org, Miroslav Franc, Richard Henderson
In-Reply-To: <5409E20C.3050004@hurleysoftware.com>
On Fri 2014-09-05 12:17:16, Peter Hurley wrote:
> On 09/05/2014 08:37 AM, David Laight wrote:
> > From: Peter Hurley
> >> On 09/05/2014 04:30 AM, David Laight wrote:
> >>> I've seen gcc generate 32bit accesses for 16bit structure members on arm.
> >>> It does this because of the more limited range of the offsets for the 16bit access.
> >>> OTOH I don't know if it ever did this for writes - so it may be moot.
> >>
> >> Can you recall the particulars, like what ARM config or what code?
> >>
> >> I tried an overly-simple test to see if gcc would bump up to the word load for
> >> the 12-bit offset mode, but it stuck with register offset rather than immediate
> >> offset. [I used the compiler options for allmodconfig and a 4.8 cross-compiler.]
> >>
> >> Maybe the test doesn't generate enough register pressure on the compiler?
> >
> > Dunno, I would have been using a much older version of the compiler.
> > It is possible that it doesn't do it any more.
> > It might only have done it for loads.
> >
> > The compiler used to use misaligned 32bit loads for structure
> > members on large 4n+2 byte boundaries as well.
> > I'm pretty sure it doesn't do that either.
> >
> > There have been a lot of compiler versions since I was compiling
> > anything for arm.
>
> Yeah, it seems gcc for ARM no longer uses the larger operand size as a
> substitute for 12-bit immediate offset addressing mode, even for reads.
>
> While this test:
>
> struct x {
> short b[12];
> };
>
> short load_b(struct x *p) {
> return p->b[8];
> }
>
> generates the 8-bit immediate offset form,
>
> short load_b(struct x *p) {
> 0: e1d001f0 ldrsh r0, [r0, #16]
> 4: e12fff1e bx lr
>
>
> pushing the offset out past 256:
>
> struct x {
> long unused[64];
> short b[12];
> };
>
> short load_b(struct x *p) {
> return p->b[8];
> }
>
> generates the register offset addressing mode instead of 12-bit immediate:
>
> short load_b(struct x *p) {
> 0: e3a03e11 mov r3, #272 ; 0x110
> 4: e19000f3 ldrsh r0, [r0, r3]
> 8: e12fff1e bx lr
If we rely on new gcc features for correctness, does minimum compiler version need to be updated?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Thierry Reding @ 2014-09-25 16:49 UTC (permalink / raw)
To: Liviu Dudau
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, sparclinux,
Yijing Wang, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <20140925144855.GB31157@bart.dudau.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2674 bytes --]
On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > This series is based Bjorn's pci/msi branch
> > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > >
> > > Currently, there are a lot of weak arch functions in MSI code.
> > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > This series use MSI chip framework to refactor MSI code across all platforms
> > > to eliminate weak arch functions. Then all MSI irqs will be managed in a
> > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > so tests in the platforms which MSI code modified are warmly welcomed!
> >
> > Apart from the comments to the individual patches I very much like where
> > this is going. Thanks for taking care of this.
> >
> > Thierry
>
> I am actually in disagreement with you, Thierry. I don't like the general direction
> of the patches, or at least I don't like the fact that we don't have a portable
> way of setting up the msi_chip without having to rely on weak architectural hooks.
Oh, good. That's actually one of the things I said I wasn't happy with
either. =)
> I'm surprised no one considers the case of a platform having more than one host
> bridge and possibly more than one MSI unit. With the current proposed patchset I
> can't see how that would work.
The PCI core can already deal with that. An MSI chip can be set per bus
and the weak pcibios_add_bus() can be used to set that. Often it might
not even be necessary to do it via pcibios_add_bus() if you create the
root bus directly, since you can attach the MSI chip at that time.
> What I would like to see is a way of creating the pci_host_bridge structure outside
> the pci_create_root_bus(). That would then allow us to pass this sort of platform
> details like associated msi_chip into the host bridge and the child busses will
> have an easy way of finding the information needed by finding the root bus and then
> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
> everyone and the drivers can remove their kludges that try to work around the
> current limitations.
I think both issues are orthogonal. Last time I checked a lot of work
was still necessary to unify host bridges enough so that it could be
shared across architectures. But perhaps some of that work has
happened in the meantime.
But like I said, when you create the root bus, you can easily attach the
MSI chip to it.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Liviu Dudau @ 2014-09-25 17:16 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, sparclinux,
Yijing Wang, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <20140925164937.GB30382@ulmo>
On Thu, Sep 25, 2014 at 06:49:38PM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> > On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > > This series is based Bjorn's pci/msi branch
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > > >
> > > > Currently, there are a lot of weak arch functions in MSI code.
> > > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > > This series use MSI chip framework to refactor MSI code across all platforms
> > > > to eliminate weak arch functions. Then all MSI irqs will be managed in a
> > > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > > so tests in the platforms which MSI code modified are warmly welcomed!
> > >
> > > Apart from the comments to the individual patches I very much like where
> > > this is going. Thanks for taking care of this.
> > >
> > > Thierry
> >
> > I am actually in disagreement with you, Thierry. I don't like the general direction
> > of the patches, or at least I don't like the fact that we don't have a portable
> > way of setting up the msi_chip without having to rely on weak architectural hooks.
>
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)
>
> > I'm surprised no one considers the case of a platform having more than one host
> > bridge and possibly more than one MSI unit. With the current proposed patchset I
> > can't see how that would work.
>
> The PCI core can already deal with that. An MSI chip can be set per bus
> and the weak pcibios_add_bus() can be used to set that. Often it might
> not even be necessary to do it via pcibios_add_bus() if you create the
> root bus directly, since you can attach the MSI chip at that time.
But I'm thinking that we need to move away from pcibios_add_bus() interface to do
something that should be generic. You don't need to be called for every bus when all
you want is just the root bus in order to add the MSI chip. Also, from looking at
the current patchset, a lot of architectures would set the MSI chip to a global
variable, which means you don't have an option to choose the MSI chip based on the
bus.
>
> > What I would like to see is a way of creating the pci_host_bridge structure outside
> > the pci_create_root_bus(). That would then allow us to pass this sort of platform
> > details like associated msi_chip into the host bridge and the child busses will
> > have an easy way of finding the information needed by finding the root bus and then
> > the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
> > everyone and the drivers can remove their kludges that try to work around the
> > current limitations.
>
> I think both issues are orthogonal. Last time I checked a lot of work
> was still necessary to unify host bridges enough so that it could be
> shared across architectures. But perhaps some of that work has
> happened in the meantime.
Breaking out the host bridge creation from root bus creation is not difficult, just not
agree upon. That would be the first step in making the generic host brige structure
useful for sharing, specially if used as a sort of "parent" structure that you can
wrap with your actual host bridge structure.
>
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.
Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
and add their own needed modifications. Which makes it hard to fix bugs and prevents code
reuse.
Best regards,
Liviu
>
> Thierry
--
-------------------
.oooO
( )
\ ( Oooo.
\_) ( )
) /
(_/
One small step
for me ...
^ permalink raw reply
* Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
From: Scott Wood @ 2014-09-25 20:08 UTC (permalink / raw)
To: Lu Jingchang-B35083
Cc: linuxppc-dev@lists.ozlabs.org, mturquette@linaro.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <d4a375f40b544cf1ae78ac82dc20569c@BL2PR03MB467.namprd03.prod.outlook.com>
Well, like I said, I'd rather see the CLK_OF_DECLARE stuff be made to
work on PPC rather than have the driver carry around two binding
methods.
-Scott
On Thu, 2014-09-25 at 04:47 -0500, Lu Jingchang-B35083 wrote:
> Hi, Scott and Mike,
>
> Could you please help review this patch and give an ACK if ok. Thanks.
>
> Best Regards,
> Jingchang
>
> >-----Original Message-----
> >From: Jingchang Lu [mailto:jingchang.lu@freescale.com]
> >Sent: Tuesday, September 23, 2014 2:47 PM
> >To: mturquette@linaro.org
> >Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; linux-
> >kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; Lu
> >Jingchang-B35083
> >Subject: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add
> >CLK_OF_DECLARE support
> >
> >The IP is shared by PPC and ARM, this renames it to qoriq for better
> >represention, and this also adds the CLK_OF_DECLARE support for being
> >initialized by of_clk_init() on ARM.
> >
> >Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com>
> >---
> >changes in v4:
> > remove "corenet" literals omitted in v3 remove.
> >
> >changes in v3:
> > generate the patch with -M -C option
> >
> >changes in v2:
> > rename the driver name to ppc-qoriq.c for shared on PPC and ARM.
> >
> > drivers/clk/Kconfig | 9 +++++----
> > drivers/clk/Makefile | 2 +-
> > drivers/clk/{clk-ppc-corenet.c => clk-qoriq.c} | 27 +++++++++++++++------
> >-----
> > 3 files changed, 22 insertions(+), 16 deletions(-) rename
> >drivers/clk/{clk-ppc-corenet.c => clk-qoriq.c} (89%)
> >
> >diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index
> >85131ae..f5f76cb 100644
> >--- a/drivers/clk/Kconfig
> >+++ b/drivers/clk/Kconfig
> >@@ -92,12 +92,13 @@ config COMMON_CLK_AXI_CLKGEN
> > Support for the Analog Devices axi-clkgen pcore clock generator
> >for Xilinx
> > FPGAs. It is commonly used in Analog Devices' reference designs.
> >
> >-config CLK_PPC_CORENET
> >- bool "Clock driver for PowerPC corenet platforms"
> >- depends on PPC_E500MC && OF
> >+config CLK_QORIQ
> >+ bool "Clock driver for PowerPC corenet and compatible ARM-based
> >platforms"
> >+ depends on (PPC_E500MC || ARM) && OF
> > ---help---
> > This adds the clock driver support for Freescale PowerPC corenet
> >- platforms using common clock framework.
> >+ platforms and compatible Freescale ARM based platforms using
> >common
> >+ clock framework.
> >
> > config COMMON_CLK_XGENE
> > bool "Clock driver for APM XGene SoC"
> >diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index
> >27c542b..20f42e9 100644
> >--- a/drivers/clk/Makefile
> >+++ b/drivers/clk/Makefile
> >@@ -29,7 +29,7 @@ obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
> > obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
> > obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
> > obj-$(CONFIG_COMMON_CLK_PALMAS) += clk-palmas.o
> >-obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
> >+obj-$(CONFIG_CLK_QORIQ) += clk-qoriq.o
> > obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
> > obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
> > obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
> >diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-qoriq.c
> >similarity index 89% rename from drivers/clk/clk-ppc-corenet.c rename to
> >drivers/clk/clk-qoriq.c index 8e58edf..cba8abe 100644
> >--- a/drivers/clk/clk-ppc-corenet.c
> >+++ b/drivers/clk/clk-qoriq.c
> >@@ -155,7 +155,7 @@ static void __init core_pll_init(struct device_node
> >*np)
> >
> > base = of_iomap(np, 0);
> > if (!base) {
> >- pr_err("clk-ppc: iomap error\n");
> >+ pr_err("clk-qoriq: iomap error\n");
> > return;
> > }
> >
> >@@ -252,7 +252,7 @@ static void __init sysclk_init(struct device_node
> >*node)
> > u32 rate;
> >
> > if (!np) {
> >- pr_err("ppc-clk: could not get parent node\n");
> >+ pr_err("qoriq-clk: could not get parent node\n");
> > return;
> > }
> >
> >@@ -278,30 +278,35 @@ static const struct of_device_id clk_match[]
> >__initconst = {
> > {}
> > };
> >
> >-static int __init ppc_corenet_clk_probe(struct platform_device *pdev)
> >+static int __init qoriq_clk_probe(struct platform_device *pdev)
> > {
> > of_clk_init(clk_match);
> >
> > return 0;
> > }
> >
> >-static const struct of_device_id ppc_clk_ids[] __initconst = {
> >+static const struct of_device_id qoriq_clk_ids[] __initconst = {
> > { .compatible = "fsl,qoriq-clockgen-1.0", },
> > { .compatible = "fsl,qoriq-clockgen-2.0", },
> > {}
> > };
> >
> >-static struct platform_driver ppc_corenet_clk_driver __initdata = {
> >+static struct platform_driver qoriq_clk_driver __initdata = {
> > .driver = {
> >- .name = "ppc_corenet_clock",
> >+ .name = "qoriq_clock",
> > .owner = THIS_MODULE,
> >- .of_match_table = ppc_clk_ids,
> >+ .of_match_table = qoriq_clk_ids,
> > },
> >- .probe = ppc_corenet_clk_probe,
> >+ .probe = qoriq_clk_probe,
> > };
> >
> >-static int __init ppc_corenet_clk_init(void)
> >+static int __init qoriq_clk_init(void)
> > {
> >- return platform_driver_register(&ppc_corenet_clk_driver);
> >+ return platform_driver_register(&qoriq_clk_driver);
> > }
> >-subsys_initcall(ppc_corenet_clk_init);
> >+subsys_initcall(qoriq_clk_init);
> >+
> >+CLK_OF_DECLARE(qoriq_core_pll_v1, "fsl,qoriq-core-pll-1.0",
> >+core_pll_init); CLK_OF_DECLARE(qoriq_core_pll_v2,
> >+"fsl,qoriq-core-pll-2.0", core_pll_init);
> >+CLK_OF_DECLARE(qoriq_core_mux_v1, "fsl,qoriq-core-mux-1.0",
> >+core_mux_init); CLK_OF_DECLARE(qoriq_core_mux_v2,
> >+"fsl,qoriq-core-mux-2.0", core_mux_init);
> >--
> >1.8.0
>
^ permalink raw reply
* Re: [PATCH 2/3] qe_common: add qe common functions to qe_common.c
From: Scott Wood @ 2014-09-25 20:41 UTC (permalink / raw)
To: Zhao Qiang; +Cc: B07421, R63061, linuxppc-dev, linux-kernel
In-Reply-To: <1411613237-2271-1-git-send-email-B45475@freescale.com>
On Thu, 2014-09-25 at 10:47 +0800, Zhao Qiang wrote:
> qe need to call some common functions, move them into
> public directory, add a new file drivers/soc/qe/qe_common.c
> for them.
>
> Signed-off-by: Zhao Qiang <B45475@freescale.com>
> ---
> drivers/soc/qe/Makefile | 2 +-
> drivers/soc/qe/qe_common.c | 185 +++++++++++++++++++++++++++++++++++++++++++++
> include/linux/fsl/qe.h | 52 +++++++++++--
> 3 files changed, 230 insertions(+), 9 deletions(-)
> create mode 100644 drivers/soc/qe/qe_common.c
I see code being copied, not moved.
Where is patch 1/3?
-Scott
^ permalink raw reply
* Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
From: Mike Turquette @ 2014-09-25 21:39 UTC (permalink / raw)
To: Jingchang Lu
Cc: scottwood, linuxppc-dev, linux-kernel, linux-arm-kernel,
Jingchang Lu
In-Reply-To: <1411454806-8214-1-git-send-email-jingchang.lu@freescale.com>
Quoting Jingchang Lu (2014-09-22 23:46:46)
> The IP is shared by PPC and ARM, this renames it to qoriq for better
> represention, and this also adds the CLK_OF_DECLARE support for being
> initialized by of_clk_init() on ARM.
> =
> Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com>
> ---
> changes in v4:
> remove "corenet" literals omitted in v3 remove.
> =
> changes in v3:
> generate the patch with -M -C option
> =
> changes in v2:
> rename the driver name to ppc-qoriq.c for shared on PPC and ARM.
> =
> drivers/clk/Kconfig | 9 +++++----
> drivers/clk/Makefile | 2 +-
> drivers/clk/{clk-ppc-corenet.c =3D> clk-qoriq.c} | 27 +++++++++++++++---=
--------
> 3 files changed, 22 insertions(+), 16 deletions(-)
> rename drivers/clk/{clk-ppc-corenet.c =3D> clk-qoriq.c} (89%)
> =
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 85131ae..f5f76cb 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -92,12 +92,13 @@ config COMMON_CLK_AXI_CLKGEN
> Support for the Analog Devices axi-clkgen pcore clock generator=
for Xilinx
> FPGAs. It is commonly used in Analog Devices' reference designs.
> =
> -config CLK_PPC_CORENET
> - bool "Clock driver for PowerPC corenet platforms"
> - depends on PPC_E500MC && OF
> +config CLK_QORIQ
> + bool "Clock driver for PowerPC corenet and compatible ARM-based p=
latforms"
> + depends on (PPC_E500MC || ARM) && OF
> ---help---
> This adds the clock driver support for Freescale PowerPC corenet
> - platforms using common clock framework.
> + platforms and compatible Freescale ARM based platforms using co=
mmon
> + clock framework.
> =
> config COMMON_CLK_XGENE
> bool "Clock driver for APM XGene SoC"
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 27c542b..20f42e9 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -29,7 +29,7 @@ obj-$(CONFIG_ARCH_MOXART) +=3D clk-moxart.o
> obj-$(CONFIG_ARCH_NOMADIK) +=3D clk-nomadik.o
> obj-$(CONFIG_ARCH_NSPIRE) +=3D clk-nspire.o
> obj-$(CONFIG_COMMON_CLK_PALMAS) +=3D clk-palmas.o
> -obj-$(CONFIG_CLK_PPC_CORENET) +=3D clk-ppc-corenet.o
> +obj-$(CONFIG_CLK_QORIQ) +=3D clk-qoriq.o
> obj-$(CONFIG_COMMON_CLK_S2MPS11) +=3D clk-s2mps11.o
> obj-$(CONFIG_COMMON_CLK_SI5351) +=3D clk-si5351.o
> obj-$(CONFIG_COMMON_CLK_SI570) +=3D clk-si570.o
> diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-qoriq.c
> similarity index 89%
> rename from drivers/clk/clk-ppc-corenet.c
> rename to drivers/clk/clk-qoriq.c
> index 8e58edf..cba8abe 100644
> --- a/drivers/clk/clk-ppc-corenet.c
> +++ b/drivers/clk/clk-qoriq.c
> @@ -155,7 +155,7 @@ static void __init core_pll_init(struct device_node *=
np)
> =
> base =3D of_iomap(np, 0);
> if (!base) {
> - pr_err("clk-ppc: iomap error\n");
> + pr_err("clk-qoriq: iomap error\n");
> return;
> }
> =
> @@ -252,7 +252,7 @@ static void __init sysclk_init(struct device_node *no=
de)
> u32 rate;
> =
> if (!np) {
> - pr_err("ppc-clk: could not get parent node\n");
> + pr_err("qoriq-clk: could not get parent node\n");
> return;
> }
> =
> @@ -278,30 +278,35 @@ static const struct of_device_id clk_match[] __init=
const =3D {
> {}
> };
> =
> -static int __init ppc_corenet_clk_probe(struct platform_device *pdev)
> +static int __init qoriq_clk_probe(struct platform_device *pdev)
> {
> of_clk_init(clk_match);
> =
> return 0;
> }
> =
> -static const struct of_device_id ppc_clk_ids[] __initconst =3D {
> +static const struct of_device_id qoriq_clk_ids[] __initconst =3D {
> { .compatible =3D "fsl,qoriq-clockgen-1.0", },
> { .compatible =3D "fsl,qoriq-clockgen-2.0", },
> {}
> };
> =
> -static struct platform_driver ppc_corenet_clk_driver __initdata =3D {
> +static struct platform_driver qoriq_clk_driver __initdata =3D {
> .driver =3D {
> - .name =3D "ppc_corenet_clock",
> + .name =3D "qoriq_clock",
> .owner =3D THIS_MODULE,
> - .of_match_table =3D ppc_clk_ids,
> + .of_match_table =3D qoriq_clk_ids,
> },
> - .probe =3D ppc_corenet_clk_probe,
> + .probe =3D qoriq_clk_probe,
> };
> =
> -static int __init ppc_corenet_clk_init(void)
> +static int __init qoriq_clk_init(void)
> {
> - return platform_driver_register(&ppc_corenet_clk_driver);
> + return platform_driver_register(&qoriq_clk_driver);
> }
> -subsys_initcall(ppc_corenet_clk_init);
> +subsys_initcall(qoriq_clk_init);
> +
> +CLK_OF_DECLARE(qoriq_core_pll_v1, "fsl,qoriq-core-pll-1.0", core_pll_ini=
t);
> +CLK_OF_DECLARE(qoriq_core_pll_v2, "fsl,qoriq-core-pll-2.0", core_pll_ini=
t);
> +CLK_OF_DECLARE(qoriq_core_mux_v1, "fsl,qoriq-core-mux-1.0", core_mux_ini=
t);
> +CLK_OF_DECLARE(qoriq_core_mux_v2, "fsl,qoriq-core-mux-2.0", core_mux_ini=
t);
Is there binding documentation for these compatibles?
Regards,
Mike
> -- =
> 1.8.0
>=20
^ permalink raw reply
* Re: [PATCH v2] powerpc/powernv: Override dma_get_required_mask()
From: Benjamin Herrenschmidt @ 2014-09-25 21:51 UTC (permalink / raw)
To: Gavin Shan; +Cc: linuxppc-dev
In-Reply-To: <1411629879-20270-1-git-send-email-gwshan@linux.vnet.ibm.com>
On Thu, 2014-09-25 at 17:24 +1000, Gavin Shan wrote:
> When using bypass window on IODA2, the incorrect DMA operations
> "dma_iommu_ops" is used by devices. The device driver calls
> dma_get_required_mask() to determine using 32-bits or 64-bits
> bypass DMA window. Unfortunately, the returned DMA mask always
> forces the driver to use 32-bits DMA window. The problem was
> reported on the device as follows:
I would write the above comment a bit differently:
The dma_get_required_mask() function is used by some drivers to
query the platform about what DMA mask is needed to cover all of memory.
This is a bit of a strange semantic when we have to chose between iommu
translation or bypass, but essentially what it means is "what DMA mask
will give best performances".
Currently, our iommu backend always returns a 32-bit mask here, we don't
do anything special to it when we have bypass available. This causes
some drivers to chose a 32-bit mask, thus losing the ability to use the
bypass window, thinking this is more efficient.
This patch adds an override of that function in order to, instead,
return a 64-bit mask whenever a bypass window is available in order for
drivers to prefer this configuration.
... or something along those lines.
> 0004:03:00.0 0107: 1000:0087 (rev 05)
> 0004:03:00.0 Serial Attached SCSI controller: LSI Logic / Symbios \
> Logic SAS2308 PCI-Express Fusion-MPT SAS-2 (rev 05)
>
> The patch fixes above issue by overriding dma_get_required_mask(),
> which returns mask corresponding to bypass window base. Otherwise,
> "dma_iommu_ops::get_required_mask" will be called to return mask
> corresponding to 32-bits DMA window.
>
> Reported-by: Murali N. Iyer <mniyer@us.ibm.com>
> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/dma-mapping.h | 1 +
> arch/powerpc/kernel/dma.c | 14 ++++++++++----
> arch/powerpc/platforms/powernv/pci-ioda.c | 23 +++++++++++++++++++++++
> arch/powerpc/platforms/powernv/pci.c | 11 +++++++++++
> arch/powerpc/platforms/powernv/pci.h | 2 ++
> arch/powerpc/platforms/powernv/powernv.h | 6 ++++++
> arch/powerpc/platforms/powernv/setup.c | 9 +++++++++
> 7 files changed, 62 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
> index 150866b..894d538 100644
> --- a/arch/powerpc/include/asm/dma-mapping.h
> +++ b/arch/powerpc/include/asm/dma-mapping.h
> @@ -135,6 +135,7 @@ static inline int dma_supported(struct device *dev, u64 mask)
>
> extern int dma_set_mask(struct device *dev, u64 dma_mask);
> extern int __dma_set_mask(struct device *dev, u64 dma_mask);
> +extern u64 __dma_get_required_mask(struct device *dev);
>
> #define dma_alloc_coherent(d,s,h,f) dma_alloc_attrs(d,s,h,f,NULL)
>
> diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
> index ee78f6e..210ff9d 100644
> --- a/arch/powerpc/kernel/dma.c
> +++ b/arch/powerpc/kernel/dma.c
> @@ -202,6 +202,7 @@ int __dma_set_mask(struct device *dev, u64 dma_mask)
> *dev->dma_mask = dma_mask;
> return 0;
> }
> +
> int dma_set_mask(struct device *dev, u64 dma_mask)
> {
> if (ppc_md.dma_set_mask)
> @@ -210,13 +211,10 @@ int dma_set_mask(struct device *dev, u64 dma_mask)
> }
> EXPORT_SYMBOL(dma_set_mask);
>
> -u64 dma_get_required_mask(struct device *dev)
> +u64 __dma_get_required_mask(struct device *dev)
> {
> struct dma_map_ops *dma_ops = get_dma_ops(dev);
>
> - if (ppc_md.dma_get_required_mask)
> - return ppc_md.dma_get_required_mask(dev);
> -
> if (unlikely(dma_ops == NULL))
> return 0;
>
> @@ -225,6 +223,14 @@ u64 dma_get_required_mask(struct device *dev)
>
> return DMA_BIT_MASK(8 * sizeof(dma_addr_t));
> }
> +
> +u64 dma_get_required_mask(struct device *dev)
> +{
> + if (ppc_md.dma_get_required_mask)
> + return ppc_md.dma_get_required_mask(dev);
> +
> + return __dma_get_required_mask(dev);
> +}
> EXPORT_SYMBOL_GPL(dma_get_required_mask);
>
> static int __init dma_init(void)
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 36b1a7a..380ebc9 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -890,6 +890,28 @@ static int pnv_pci_ioda_dma_set_mask(struct pnv_phb *phb,
> return 0;
> }
>
> +static u64 pnv_pci_ioda_dma_get_required_mask(struct pnv_phb *phb,
> + struct pci_dev *pdev)
> +{
> + struct pci_dn *pdn = pci_get_pdn(pdev);
> + struct pnv_ioda_pe *pe;
> + u64 end, mask;
> +
> + if (WARN_ON(!pdn || pdn->pe_number == IODA_INVALID_PE))
> + return 0;
> +
> + pe = &phb->ioda.pe_array[pdn->pe_number];
> + if (!pe->tce_bypass_enabled)
> + return __dma_get_required_mask(&pdev->dev);
> +
> +
> + end = pe->tce_bypass_base + memblock_end_of_DRAM();
> + mask = 1ULL << (fls64(end) - 1);
> + mask += mask - 1;
> +
> + return mask;
> +}
> +
> static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe,
> struct pci_bus *bus,
> bool add_to_iommu_group)
> @@ -1782,6 +1804,7 @@ void __init pnv_pci_init_ioda_phb(struct device_node *np,
> /* Setup TCEs */
> phb->dma_dev_setup = pnv_pci_ioda_dma_dev_setup;
> phb->dma_set_mask = pnv_pci_ioda_dma_set_mask;
> + phb->dma_get_required_mask = pnv_pci_ioda_dma_get_required_mask;
>
> /* Setup shutdown function for kexec */
> phb->shutdown = pnv_pci_ioda_shutdown;
> diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
> index b854b57..e9f509b 100644
> --- a/arch/powerpc/platforms/powernv/pci.c
> +++ b/arch/powerpc/platforms/powernv/pci.c
> @@ -761,6 +761,17 @@ int pnv_pci_dma_set_mask(struct pci_dev *pdev, u64 dma_mask)
> return __dma_set_mask(&pdev->dev, dma_mask);
> }
>
> +u64 pnv_pci_dma_get_required_mask(struct pci_dev *pdev)
> +{
> + struct pci_controller *hose = pci_bus_to_host(pdev->bus);
> + struct pnv_phb *phb = hose->private_data;
> +
> + if (phb && phb->dma_get_required_mask)
> + return phb->dma_get_required_mask(phb, pdev);
> +
> + return __dma_get_required_mask(&pdev->dev);
> +}
> +
> void pnv_pci_shutdown(void)
> {
> struct pci_controller *hose;
> diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
> index b54af34..aa95fcb 100644
> --- a/arch/powerpc/platforms/powernv/pci.h
> +++ b/arch/powerpc/platforms/powernv/pci.h
> @@ -124,6 +124,8 @@ struct pnv_phb {
> void (*dma_dev_setup)(struct pnv_phb *phb, struct pci_dev *pdev);
> int (*dma_set_mask)(struct pnv_phb *phb, struct pci_dev *pdev,
> u64 dma_mask);
> + u64 (*dma_get_required_mask)(struct pnv_phb *phb,
> + struct pci_dev *pdev);
> void (*fixup_phb)(struct pci_controller *hose);
> u32 (*bdfn_to_pe)(struct pnv_phb *phb, struct pci_bus *bus, u32 devfn);
> void (*shutdown)(struct pnv_phb *phb);
> diff --git a/arch/powerpc/platforms/powernv/powernv.h b/arch/powerpc/platforms/powernv/powernv.h
> index 75501bf..6c8e2d1 100644
> --- a/arch/powerpc/platforms/powernv/powernv.h
> +++ b/arch/powerpc/platforms/powernv/powernv.h
> @@ -13,6 +13,7 @@ struct pci_dev;
> extern void pnv_pci_init(void);
> extern void pnv_pci_shutdown(void);
> extern int pnv_pci_dma_set_mask(struct pci_dev *pdev, u64 dma_mask);
> +extern u64 pnv_pci_dma_get_required_mask(struct pci_dev *pdev);
> #else
> static inline void pnv_pci_init(void) { }
> static inline void pnv_pci_shutdown(void) { }
> @@ -21,6 +22,11 @@ static inline int pnv_pci_dma_set_mask(struct pci_dev *pdev, u64 dma_mask)
> {
> return -ENODEV;
> }
> +
> +static inline u64 pnv_pci_dma_get_required_mask(struct pci_dev *pdev)
> +{
> + return 0;
> +}
> #endif
>
> extern void pnv_lpc_init(void);
> diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
> index 5a0e2dc..0cb3a07 100644
> --- a/arch/powerpc/platforms/powernv/setup.c
> +++ b/arch/powerpc/platforms/powernv/setup.c
> @@ -173,6 +173,14 @@ static int pnv_dma_set_mask(struct device *dev, u64 dma_mask)
> return __dma_set_mask(dev, dma_mask);
> }
>
> +static u64 pnv_dma_get_required_mask(struct device *dev)
> +{
> + if (dev_is_pci(dev))
> + return pnv_pci_dma_get_required_mask(to_pci_dev(dev));
> +
> + return __dma_get_required_mask(dev);
> +}
> +
> static void pnv_shutdown(void)
> {
> /* Let the PCI code clear up IODA tables */
> @@ -335,6 +343,7 @@ define_machine(powernv) {
> .power_save = power7_idle,
> .calibrate_decr = generic_calibrate_decr,
> .dma_set_mask = pnv_dma_set_mask,
> + .dma_get_required_mask = pnv_dma_get_required_mask,
> #ifdef CONFIG_KEXEC
> .kexec_cpu_down = pnv_kexec_cpu_down,
> #endif
^ permalink raw reply
* Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
From: Scott Wood @ 2014-09-25 22:04 UTC (permalink / raw)
To: Mike Turquette; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel, Jingchang Lu
In-Reply-To: <20140925213959.19023.80648@quantum>
On Thu, 2014-09-25 at 14:39 -0700, Mike Turquette wrote:
> Quoting Jingchang Lu (2014-09-22 23:46:46)
> > +CLK_OF_DECLARE(qoriq_core_pll_v1, "fsl,qoriq-core-pll-1.0", core_pll_init);
> > +CLK_OF_DECLARE(qoriq_core_pll_v2, "fsl,qoriq-core-pll-2.0", core_pll_init);
> > +CLK_OF_DECLARE(qoriq_core_mux_v1, "fsl,qoriq-core-mux-1.0", core_mux_init);
> > +CLK_OF_DECLARE(qoriq_core_mux_v2, "fsl,qoriq-core-mux-2.0", core_mux_init);
>
> Is there binding documentation for these compatibles?
Documentation/devicetree/bindings/clock/qoriq-clock.txt
-Scott
^ permalink raw reply
* Re: [PATCH v2 1/3] drivers/of: add of_changeset_apply_locked
From: Tyrel Datwyler @ 2014-09-25 22:35 UTC (permalink / raw)
To: Cyril Bur, linuxppc-dev
In-Reply-To: <1411627290-20302-2-git-send-email-cyril.bur@au1.ibm.com>
On 09/24/2014 11:41 PM, Cyril Bur wrote:
> Due to the requirement of of_changesets that of_changeset_apply be called
> holding the of_mutex and that the of_mutex cannot be accessed nicely outside
> the of code, added a wrapper which grabs the lock and called
> of_changeset_apply.
>
> Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
> ---
> drivers/of/dynamic.c | 11 +++++++++++
> include/linux/of.h | 1 +
> 2 files changed, 12 insertions(+)
This patch needs to go through Grant Likely and the device tree list.
When unsure scripts/get_maintainer.pl can help point the way.
-Tyrel
>
> diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
> index 54fecc4..cbff2a2 100644
> --- a/drivers/of/dynamic.c
> +++ b/drivers/of/dynamic.c
> @@ -542,6 +542,17 @@ void of_changeset_destroy(struct of_changeset *ocs)
> __of_changeset_entry_destroy(ce);
> }
>
> +int of_changeset_apply_locked(struct of_changeset *ocs)
> +{
> + int ret;
> +
> + mutex_lock(&of_mutex);
> + ret = of_changeset_apply(ocs);
> + mutex_unlock(&of_mutex);
> +
> + return ret;
> +}
> +
> /**
> * of_changeset_apply - Applies a changeset
> *
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 6c4363b..f5c48fa 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -827,6 +827,7 @@ struct of_changeset {
> extern void of_changeset_init(struct of_changeset *ocs);
> extern void of_changeset_destroy(struct of_changeset *ocs);
> extern int of_changeset_apply(struct of_changeset *ocs);
> +extern int of_changeset_apply_locked(struct of_changeset *ocs);
> extern int of_changeset_revert(struct of_changeset *ocs);
> extern int of_changeset_action(struct of_changeset *ocs,
> unsigned long action, struct device_node *np,
>
^ permalink raw reply
* Re: [PATCH v2 2/3] powerpc/pseries: create rtas buffer accessor
From: Tyrel Datwyler @ 2014-09-25 22:47 UTC (permalink / raw)
To: Cyril Bur, linuxppc-dev, Michael Ellerman
In-Reply-To: <1411627290-20302-3-git-send-email-cyril.bur@au1.ibm.com>
On 09/24/2014 11:41 PM, Cyril Bur wrote:
> Added simple accessor functions for rtas in memory buffers which performs
> accesses of appropriate type and performs endian conversions.
>
> Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
> ---
> arch/powerpc/platforms/pseries/Makefile | 4 +-
> arch/powerpc/platforms/pseries/pseries.h | 41 +++++++++
> arch/powerpc/platforms/pseries/rtas_buffer.c | 126 +++++++++++++++++++++++++++
> 3 files changed, 170 insertions(+), 1 deletion(-)
> create mode 100644 arch/powerpc/platforms/pseries/rtas_buffer.c
Maybe Michael has an opinion here, but seems to me since this is all
RTAS related it would make sense for this code to belong in
kernel/rtas.c and include/asm/rtas.h.
-Tyrel
>
> diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
> index 0348079..7eb7c46 100644
> --- a/arch/powerpc/platforms/pseries/Makefile
> +++ b/arch/powerpc/platforms/pseries/Makefile
> @@ -3,7 +3,9 @@ ccflags-$(CONFIG_PPC_PSERIES_DEBUG) += -DDEBUG
>
> obj-y := lpar.o hvCall.o nvram.o reconfig.o \
> setup.o iommu.o event_sources.o ras.o \
> - firmware.o power.o dlpar.o mobility.o rng.o
> + firmware.o power.o dlpar.o mobility.o \
> + rng.o rtas_buffer.o
> +
> obj-$(CONFIG_SMP) += smp.o
> obj-$(CONFIG_SCANLOG) += scanlog.o
> obj-$(CONFIG_EEH) += eeh_pseries.o
> diff --git a/arch/powerpc/platforms/pseries/pseries.h b/arch/powerpc/platforms/pseries/pseries.h
> index 361add6..f24e352 100644
> --- a/arch/powerpc/platforms/pseries/pseries.h
> +++ b/arch/powerpc/platforms/pseries/pseries.h
> @@ -66,4 +66,45 @@ int pseries_root_bridge_prepare(struct pci_host_bridge *bridge);
>
> unsigned long pseries_memory_block_size(void);
>
> +/* Manipulation of the in memory data returned from an RTAS call */
> +
> +/* Data pointed to by ptr is in big endian */
> +struct rtas_buffer {
> + void *ptr;
> + int len;
> + int pos;
> +};
> +
> +/* Buffer is already zeroed */
> +int make_rtas_buf(struct rtas_buffer *b, size_t size);
> +void free_rtas_buf(struct rtas_buffer *b);
> +
> +/* Return pointer to the buffer being used */
> +void *get_rtas_buf(struct rtas_buffer *b);
> +
> +/* Checks if the buffer exists and the read position is less than the length*/
> +bool check_rtas_buf(struct rtas_buffer *b);
> +size_t get_rtas_buf_size(struct rtas_buffer *b);
> +
> +/* Advance the internal position of the buffer by size bytes */
> +bool advance_rtas_buf(struct rtas_buffer *b, size_t size);
> +
> +/* Put a value val into the buffer at position pos. Function expect val in cpu
> + * endian. Returns true if the write to the buffer was successful.
> + */
> +bool put_rtas_buf_32(struct rtas_buffer *b, u32 val, int pos);
> +
> +/* Grab the byte at the current position of the buffer without incrementing
> + * the internal position of the buffer */
> +bool peek_rtas_buf(struct rtas_buffer *b, u8 *c);
> +
> +/* Accessor functions return true if access succeeded and value is written to
> + * val in cpu endian. Automatically advances its reference into the buffer by
> + * the requested amount.
> + */
> +bool get_rtas_buf_32(struct rtas_buffer *b, u32 *val);
> +bool get_rtas_buf_64(struct rtas_buffer *b, u64 *val);
> +bool get_rtas_buf_mem(struct rtas_buffer *b, void **p, size_t len);
> +bool get_rtas_buf_str(struct rtas_buffer *b, char **s);
> +
> #endif /* _PSERIES_PSERIES_H */
> diff --git a/arch/powerpc/platforms/pseries/rtas_buffer.c b/arch/powerpc/platforms/pseries/rtas_buffer.c
> new file mode 100644
> index 0000000..f06b73c
> --- /dev/null
> +++ b/arch/powerpc/platforms/pseries/rtas_buffer.c
> @@ -0,0 +1,126 @@
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +
> +#include "pseries.h"
> +
> +
> +int make_rtas_buf(struct rtas_buffer *b, size_t sz)
> +{
> + b->ptr = kzalloc(sz, GFP_KERNEL);
> + b->len = sz;
> + b->pos = 0;
> + return (!b->ptr) ? -ENOMEM : 0;
> +}
> +
> +void free_rtas_buf(struct rtas_buffer *b)
> +{
> + kfree(b->ptr);
> +}
> +
> +void *get_rtas_buf(struct rtas_buffer *b)
> +{
> + return (b) ? b->ptr : NULL;
> +}
> +
> +size_t get_rtas_buf_size(struct rtas_buffer *b)
> +{
> + return (b) ? b->len : 0;
> +}
> +
> +bool check_rtas_buf(struct rtas_buffer *b)
> +{
> + return (b && b->ptr && b->pos < b->len);
> +}
> +
> +static inline void *buf_pos(struct rtas_buffer *b)
> +{
> + return (b && b->ptr) ? b->ptr + b->pos : NULL;
> +}
> +
> +bool peek_rtas_buf(struct rtas_buffer *b, u8 *c)
> +{
> + if (!b || !c || b->pos >= b->len)
> + return false;
> +
> + *c = *(u8 *)buf_pos(b);
> +
> + return true;
> +}
> +
> +bool put_rtas_buf_32(struct rtas_buffer *b, u32 val, int pos)
> +{
> + if (!b || b->pos >= b->len)
> + return false;
> +
> + *((__be32 *)buf_pos(b)) = cpu_to_be32(val);
> +
> + return true;
> +}
> +
> +bool get_rtas_buf_32(struct rtas_buffer *b, u32 *val)
> +{
> + if (!b || !val || b->len - b->pos < sizeof(u32))
> + return false;
> +
> + *val = be32_to_cpu(*((__be32 *)buf_pos(b)));
> + b->pos += sizeof(u32);
> + return true;
> +}
> +
> +bool get_rtas_buf_64(struct rtas_buffer *b, u64 *val)
> +{
> + if (!b || !val || b->len - b->pos < sizeof(u64))
> + return false;
> +
> + *val = be64_to_cpu(*((__be64 *)buf_pos(b)));
> + b->pos += sizeof(u64);
> + return true;
> +}
> +
> +bool get_rtas_buf_str(struct rtas_buffer *b, char **s)
> +{
> + int i;
> + if (!b || !s)
> + return false;
> +
> + /* Get length of string */
> + i = b->pos;
> + while (i < b->len) {
> + if (*(char *)(b->ptr + i) == '\0') {
> + *s = (char *)buf_pos(b);
> + if (!*s)
> + return false;
> +
> + b->pos = i + 1;
> + return true;
> + }
> + i++;
> + }
> +
> + return false;
> +}
> +
> +bool get_rtas_buf_mem(struct rtas_buffer *b, void **p, size_t len)
> +{
> + if (!b || !p || b->len - b->pos < len)
> + return false;
> +
> + *p = buf_pos(b);
> + if (!*p)
> + return false;
> +
> + b->pos += len;
> +
> + return true;
> +}
> +
> +bool advance_rtas_buf(struct rtas_buffer *b, size_t len)
> +{
> + if (!b || b->len - b->pos < len)
> + return false;
> +
> + b->pos += len;
> +
> + return true;
> +}
> +
>
^ permalink raw reply
* Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
From: Mike Turquette @ 2014-09-25 22:54 UTC (permalink / raw)
To: Scott Wood, Lu Jingchang-B35083
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1411675680.13320.201.camel@snotra.buserror.net>
Quoting Scott Wood (2014-09-25 13:08:00)
> Well, like I said, I'd rather see the CLK_OF_DECLARE stuff be made to
> work on PPC rather than have the driver carry around two binding
> methods.
I guess that is an existing problem, and not related directly to this
patch? This patch is essentially just renames (though the V1.0/V2.0
stuff seems weird).
Regards,
Mike
> =
> -Scott
> =
> On Thu, 2014-09-25 at 04:47 -0500, Lu Jingchang-B35083 wrote:
> > Hi, Scott and Mike,
> > =
> > Could you please help review this patch and give an ACK if ok. Thanks.
> > =
> > Best Regards,
> > Jingchang
> > =
> > >-----Original Message-----
> > >From: Jingchang Lu [mailto:jingchang.lu@freescale.com]
> > >Sent: Tuesday, September 23, 2014 2:47 PM
> > >To: mturquette@linaro.org
> > >Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; linux-
> > >kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; Lu
> > >Jingchang-B35083
> > >Subject: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add
> > >CLK_OF_DECLARE support
> > >
> > >The IP is shared by PPC and ARM, this renames it to qoriq for better
> > >represention, and this also adds the CLK_OF_DECLARE support for being
> > >initialized by of_clk_init() on ARM.
> > >
> > >Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com>
> > >---
> > >changes in v4:
> > > remove "corenet" literals omitted in v3 remove.
> > >
> > >changes in v3:
> > > generate the patch with -M -C option
> > >
> > >changes in v2:
> > > rename the driver name to ppc-qoriq.c for shared on PPC and ARM.
> > >
> > > drivers/clk/Kconfig | 9 +++++----
> > > drivers/clk/Makefile | 2 +-
> > > drivers/clk/{clk-ppc-corenet.c =3D> clk-qoriq.c} | 27 +++++++++++++++=
------
> > >-----
> > > 3 files changed, 22 insertions(+), 16 deletions(-) rename
> > >drivers/clk/{clk-ppc-corenet.c =3D> clk-qoriq.c} (89%)
> > >
> > >diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index
> > >85131ae..f5f76cb 100644
> > >--- a/drivers/clk/Kconfig
> > >+++ b/drivers/clk/Kconfig
> > >@@ -92,12 +92,13 @@ config COMMON_CLK_AXI_CLKGEN
> > > Support for the Analog Devices axi-clkgen pcore clock generator
> > >for Xilinx
> > > FPGAs. It is commonly used in Analog Devices' reference designs.
> > >
> > >-config CLK_PPC_CORENET
> > >- bool "Clock driver for PowerPC corenet platforms"
> > >- depends on PPC_E500MC && OF
> > >+config CLK_QORIQ
> > >+ bool "Clock driver for PowerPC corenet and compatible ARM-based
> > >platforms"
> > >+ depends on (PPC_E500MC || ARM) && OF
> > > ---help---
> > > This adds the clock driver support for Freescale PowerPC corenet
> > >- platforms using common clock framework.
> > >+ platforms and compatible Freescale ARM based platforms using
> > >common
> > >+ clock framework.
> > >
> > > config COMMON_CLK_XGENE
> > > bool "Clock driver for APM XGene SoC"
> > >diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index
> > >27c542b..20f42e9 100644
> > >--- a/drivers/clk/Makefile
> > >+++ b/drivers/clk/Makefile
> > >@@ -29,7 +29,7 @@ obj-$(CONFIG_ARCH_MOXART) +=3D clk-moxart.o
> > > obj-$(CONFIG_ARCH_NOMADIK) +=3D clk-nomadik.o
> > > obj-$(CONFIG_ARCH_NSPIRE) +=3D clk-nspire.o
> > > obj-$(CONFIG_COMMON_CLK_PALMAS) +=3D clk-palmas.o
> > >-obj-$(CONFIG_CLK_PPC_CORENET) +=3D clk-ppc-corenet.o
> > >+obj-$(CONFIG_CLK_QORIQ) +=3D clk-qoriq.o
> > > obj-$(CONFIG_COMMON_CLK_S2MPS11) +=3D clk-s2mps11.o
> > > obj-$(CONFIG_COMMON_CLK_SI5351) +=3D clk-si5351.o
> > > obj-$(CONFIG_COMMON_CLK_SI570) +=3D clk-si570.o
> > >diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-qoriq.c
> > >similarity index 89% rename from drivers/clk/clk-ppc-corenet.c rename =
to
> > >drivers/clk/clk-qoriq.c index 8e58edf..cba8abe 100644
> > >--- a/drivers/clk/clk-ppc-corenet.c
> > >+++ b/drivers/clk/clk-qoriq.c
> > >@@ -155,7 +155,7 @@ static void __init core_pll_init(struct device_node
> > >*np)
> > >
> > > base =3D of_iomap(np, 0);
> > > if (!base) {
> > >- pr_err("clk-ppc: iomap error\n");
> > >+ pr_err("clk-qoriq: iomap error\n");
> > > return;
> > > }
> > >
> > >@@ -252,7 +252,7 @@ static void __init sysclk_init(struct device_node
> > >*node)
> > > u32 rate;
> > >
> > > if (!np) {
> > >- pr_err("ppc-clk: could not get parent node\n");
> > >+ pr_err("qoriq-clk: could not get parent node\n");
> > > return;
> > > }
> > >
> > >@@ -278,30 +278,35 @@ static const struct of_device_id clk_match[]
> > >__initconst =3D {
> > > {}
> > > };
> > >
> > >-static int __init ppc_corenet_clk_probe(struct platform_device *pdev)
> > >+static int __init qoriq_clk_probe(struct platform_device *pdev)
> > > {
> > > of_clk_init(clk_match);
> > >
> > > return 0;
> > > }
> > >
> > >-static const struct of_device_id ppc_clk_ids[] __initconst =3D {
> > >+static const struct of_device_id qoriq_clk_ids[] __initconst =3D {
> > > { .compatible =3D "fsl,qoriq-clockgen-1.0", },
> > > { .compatible =3D "fsl,qoriq-clockgen-2.0", },
> > > {}
> > > };
> > >
> > >-static struct platform_driver ppc_corenet_clk_driver __initdata =3D {
> > >+static struct platform_driver qoriq_clk_driver __initdata =3D {
> > > .driver =3D {
> > >- .name =3D "ppc_corenet_clock",
> > >+ .name =3D "qoriq_clock",
> > > .owner =3D THIS_MODULE,
> > >- .of_match_table =3D ppc_clk_ids,
> > >+ .of_match_table =3D qoriq_clk_ids,
> > > },
> > >- .probe =3D ppc_corenet_clk_probe,
> > >+ .probe =3D qoriq_clk_probe,
> > > };
> > >
> > >-static int __init ppc_corenet_clk_init(void)
> > >+static int __init qoriq_clk_init(void)
> > > {
> > >- return platform_driver_register(&ppc_corenet_clk_driver);
> > >+ return platform_driver_register(&qoriq_clk_driver);
> > > }
> > >-subsys_initcall(ppc_corenet_clk_init);
> > >+subsys_initcall(qoriq_clk_init);
> > >+
> > >+CLK_OF_DECLARE(qoriq_core_pll_v1, "fsl,qoriq-core-pll-1.0",
> > >+core_pll_init); CLK_OF_DECLARE(qoriq_core_pll_v2,
> > >+"fsl,qoriq-core-pll-2.0", core_pll_init);
> > >+CLK_OF_DECLARE(qoriq_core_mux_v1, "fsl,qoriq-core-mux-1.0",
> > >+core_mux_init); CLK_OF_DECLARE(qoriq_core_mux_v2,
> > >+"fsl,qoriq-core-mux-2.0", core_mux_init);
> > >--
> > >1.8.0
> > =
> =
>=20
^ permalink raw reply
* Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
From: Scott Wood @ 2014-09-25 22:56 UTC (permalink / raw)
To: Mike Turquette
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Lu Jingchang-B35083
In-Reply-To: <20140925225406.19023.25065@quantum>
On Thu, 2014-09-25 at 15:54 -0700, Mike Turquette wrote:
> Quoting Scott Wood (2014-09-25 13:08:00)
> > Well, like I said, I'd rather see the CLK_OF_DECLARE stuff be made to
> > work on PPC rather than have the driver carry around two binding
> > methods.
>
> I guess that is an existing problem, and not related directly to this
> patch? This patch is essentially just renames (though the V1.0/V2.0
> stuff seems weird).
This patch is adding CLK_OF_DECLARE.
-Scott
^ permalink raw reply
* Re: [PATCH v2] powerpc/powernv: Override dma_get_required_mask()
From: Gavin Shan @ 2014-09-25 23:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1411681916.4285.17.camel@pasglop>
On Fri, Sep 26, 2014 at 07:51:56AM +1000, Benjamin Herrenschmidt wrote:
>On Thu, 2014-09-25 at 17:24 +1000, Gavin Shan wrote:
>> When using bypass window on IODA2, the incorrect DMA operations
>> "dma_iommu_ops" is used by devices. The device driver calls
>> dma_get_required_mask() to determine using 32-bits or 64-bits
>> bypass DMA window. Unfortunately, the returned DMA mask always
>> forces the driver to use 32-bits DMA window. The problem was
>> reported on the device as follows:
>
>I would write the above comment a bit differently:
>
>The dma_get_required_mask() function is used by some drivers to
>query the platform about what DMA mask is needed to cover all of memory.
>This is a bit of a strange semantic when we have to chose between iommu
>translation or bypass, but essentially what it means is "what DMA mask
>will give best performances".
>
>Currently, our iommu backend always returns a 32-bit mask here, we don't
>do anything special to it when we have bypass available. This causes
>some drivers to chose a 32-bit mask, thus losing the ability to use the
>bypass window, thinking this is more efficient.
>
>This patch adds an override of that function in order to, instead,
>return a 64-bit mask whenever a bypass window is available in order for
>drivers to prefer this configuration.
>
> ... or something along those lines.
>
Thanks, Ben. I'll fold your comments into next revision.
Thanks,
Gavin
>> 0004:03:00.0 0107: 1000:0087 (rev 05)
>> 0004:03:00.0 Serial Attached SCSI controller: LSI Logic / Symbios \
>> Logic SAS2308 PCI-Express Fusion-MPT SAS-2 (rev 05)
>>
>> The patch fixes above issue by overriding dma_get_required_mask(),
>> which returns mask corresponding to bypass window base. Otherwise,
>> "dma_iommu_ops::get_required_mask" will be called to return mask
>> corresponding to 32-bits DMA window.
>>
>> Reported-by: Murali N. Iyer <mniyer@us.ibm.com>
>> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/include/asm/dma-mapping.h | 1 +
>> arch/powerpc/kernel/dma.c | 14 ++++++++++----
>> arch/powerpc/platforms/powernv/pci-ioda.c | 23 +++++++++++++++++++++++
>> arch/powerpc/platforms/powernv/pci.c | 11 +++++++++++
>> arch/powerpc/platforms/powernv/pci.h | 2 ++
>> arch/powerpc/platforms/powernv/powernv.h | 6 ++++++
>> arch/powerpc/platforms/powernv/setup.c | 9 +++++++++
>> 7 files changed, 62 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
>> index 150866b..894d538 100644
>> --- a/arch/powerpc/include/asm/dma-mapping.h
>> +++ b/arch/powerpc/include/asm/dma-mapping.h
>> @@ -135,6 +135,7 @@ static inline int dma_supported(struct device *dev, u64 mask)
>>
>> extern int dma_set_mask(struct device *dev, u64 dma_mask);
>> extern int __dma_set_mask(struct device *dev, u64 dma_mask);
>> +extern u64 __dma_get_required_mask(struct device *dev);
>>
>> #define dma_alloc_coherent(d,s,h,f) dma_alloc_attrs(d,s,h,f,NULL)
>>
>> diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
>> index ee78f6e..210ff9d 100644
>> --- a/arch/powerpc/kernel/dma.c
>> +++ b/arch/powerpc/kernel/dma.c
>> @@ -202,6 +202,7 @@ int __dma_set_mask(struct device *dev, u64 dma_mask)
>> *dev->dma_mask = dma_mask;
>> return 0;
>> }
>> +
>> int dma_set_mask(struct device *dev, u64 dma_mask)
>> {
>> if (ppc_md.dma_set_mask)
>> @@ -210,13 +211,10 @@ int dma_set_mask(struct device *dev, u64 dma_mask)
>> }
>> EXPORT_SYMBOL(dma_set_mask);
>>
>> -u64 dma_get_required_mask(struct device *dev)
>> +u64 __dma_get_required_mask(struct device *dev)
>> {
>> struct dma_map_ops *dma_ops = get_dma_ops(dev);
>>
>> - if (ppc_md.dma_get_required_mask)
>> - return ppc_md.dma_get_required_mask(dev);
>> -
>> if (unlikely(dma_ops == NULL))
>> return 0;
>>
>> @@ -225,6 +223,14 @@ u64 dma_get_required_mask(struct device *dev)
>>
>> return DMA_BIT_MASK(8 * sizeof(dma_addr_t));
>> }
>> +
>> +u64 dma_get_required_mask(struct device *dev)
>> +{
>> + if (ppc_md.dma_get_required_mask)
>> + return ppc_md.dma_get_required_mask(dev);
>> +
>> + return __dma_get_required_mask(dev);
>> +}
>> EXPORT_SYMBOL_GPL(dma_get_required_mask);
>>
>> static int __init dma_init(void)
>> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
>> index 36b1a7a..380ebc9 100644
>> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
>> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>> @@ -890,6 +890,28 @@ static int pnv_pci_ioda_dma_set_mask(struct pnv_phb *phb,
>> return 0;
>> }
>>
>> +static u64 pnv_pci_ioda_dma_get_required_mask(struct pnv_phb *phb,
>> + struct pci_dev *pdev)
>> +{
>> + struct pci_dn *pdn = pci_get_pdn(pdev);
>> + struct pnv_ioda_pe *pe;
>> + u64 end, mask;
>> +
>> + if (WARN_ON(!pdn || pdn->pe_number == IODA_INVALID_PE))
>> + return 0;
>> +
>> + pe = &phb->ioda.pe_array[pdn->pe_number];
>> + if (!pe->tce_bypass_enabled)
>> + return __dma_get_required_mask(&pdev->dev);
>> +
>> +
>> + end = pe->tce_bypass_base + memblock_end_of_DRAM();
>> + mask = 1ULL << (fls64(end) - 1);
>> + mask += mask - 1;
>> +
>> + return mask;
>> +}
>> +
>> static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe,
>> struct pci_bus *bus,
>> bool add_to_iommu_group)
>> @@ -1782,6 +1804,7 @@ void __init pnv_pci_init_ioda_phb(struct device_node *np,
>> /* Setup TCEs */
>> phb->dma_dev_setup = pnv_pci_ioda_dma_dev_setup;
>> phb->dma_set_mask = pnv_pci_ioda_dma_set_mask;
>> + phb->dma_get_required_mask = pnv_pci_ioda_dma_get_required_mask;
>>
>> /* Setup shutdown function for kexec */
>> phb->shutdown = pnv_pci_ioda_shutdown;
>> diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
>> index b854b57..e9f509b 100644
>> --- a/arch/powerpc/platforms/powernv/pci.c
>> +++ b/arch/powerpc/platforms/powernv/pci.c
>> @@ -761,6 +761,17 @@ int pnv_pci_dma_set_mask(struct pci_dev *pdev, u64 dma_mask)
>> return __dma_set_mask(&pdev->dev, dma_mask);
>> }
>>
>> +u64 pnv_pci_dma_get_required_mask(struct pci_dev *pdev)
>> +{
>> + struct pci_controller *hose = pci_bus_to_host(pdev->bus);
>> + struct pnv_phb *phb = hose->private_data;
>> +
>> + if (phb && phb->dma_get_required_mask)
>> + return phb->dma_get_required_mask(phb, pdev);
>> +
>> + return __dma_get_required_mask(&pdev->dev);
>> +}
>> +
>> void pnv_pci_shutdown(void)
>> {
>> struct pci_controller *hose;
>> diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
>> index b54af34..aa95fcb 100644
>> --- a/arch/powerpc/platforms/powernv/pci.h
>> +++ b/arch/powerpc/platforms/powernv/pci.h
>> @@ -124,6 +124,8 @@ struct pnv_phb {
>> void (*dma_dev_setup)(struct pnv_phb *phb, struct pci_dev *pdev);
>> int (*dma_set_mask)(struct pnv_phb *phb, struct pci_dev *pdev,
>> u64 dma_mask);
>> + u64 (*dma_get_required_mask)(struct pnv_phb *phb,
>> + struct pci_dev *pdev);
>> void (*fixup_phb)(struct pci_controller *hose);
>> u32 (*bdfn_to_pe)(struct pnv_phb *phb, struct pci_bus *bus, u32 devfn);
>> void (*shutdown)(struct pnv_phb *phb);
>> diff --git a/arch/powerpc/platforms/powernv/powernv.h b/arch/powerpc/platforms/powernv/powernv.h
>> index 75501bf..6c8e2d1 100644
>> --- a/arch/powerpc/platforms/powernv/powernv.h
>> +++ b/arch/powerpc/platforms/powernv/powernv.h
>> @@ -13,6 +13,7 @@ struct pci_dev;
>> extern void pnv_pci_init(void);
>> extern void pnv_pci_shutdown(void);
>> extern int pnv_pci_dma_set_mask(struct pci_dev *pdev, u64 dma_mask);
>> +extern u64 pnv_pci_dma_get_required_mask(struct pci_dev *pdev);
>> #else
>> static inline void pnv_pci_init(void) { }
>> static inline void pnv_pci_shutdown(void) { }
>> @@ -21,6 +22,11 @@ static inline int pnv_pci_dma_set_mask(struct pci_dev *pdev, u64 dma_mask)
>> {
>> return -ENODEV;
>> }
>> +
>> +static inline u64 pnv_pci_dma_get_required_mask(struct pci_dev *pdev)
>> +{
>> + return 0;
>> +}
>> #endif
>>
>> extern void pnv_lpc_init(void);
>> diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
>> index 5a0e2dc..0cb3a07 100644
>> --- a/arch/powerpc/platforms/powernv/setup.c
>> +++ b/arch/powerpc/platforms/powernv/setup.c
>> @@ -173,6 +173,14 @@ static int pnv_dma_set_mask(struct device *dev, u64 dma_mask)
>> return __dma_set_mask(dev, dma_mask);
>> }
>>
>> +static u64 pnv_dma_get_required_mask(struct device *dev)
>> +{
>> + if (dev_is_pci(dev))
>> + return pnv_pci_dma_get_required_mask(to_pci_dev(dev));
>> +
>> + return __dma_get_required_mask(dev);
>> +}
>> +
>> static void pnv_shutdown(void)
>> {
>> /* Let the PCI code clear up IODA tables */
>> @@ -335,6 +343,7 @@ define_machine(powernv) {
>> .power_save = power7_idle,
>> .calibrate_decr = generic_calibrate_decr,
>> .dma_set_mask = pnv_dma_set_mask,
>> + .dma_get_required_mask = pnv_dma_get_required_mask,
>> #ifdef CONFIG_KEXEC
>> .kexec_cpu_down = pnv_kexec_cpu_down,
>> #endif
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox