* Re: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Benjamin Herrenschmidt @ 2012-02-17 0:40 UTC (permalink / raw)
To: Qiang Liu; +Cc: linux-ide, jgarzik, linuxppc-dev, linux-kernel
In-Reply-To: <1329284944-17943-1-git-send-email-qiang.liu@freescale.com>
On Wed, 2012-02-15 at 13:49 +0800, Qiang Liu wrote:
]
> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
> index 0120b0d..d6577b9 100644
> --- a/drivers/ata/sata_fsl.c
> +++ b/drivers/ata/sata_fsl.c
> @@ -6,7 +6,7 @@
> * Author: Ashish Kalra <ashish.kalra@freescale.com>
> * Li Yang <leoli@freescale.com>
> *
> - * Copyright (c) 2006-2007, 2011 Freescale Semiconductor, Inc.
> + * Copyright (c) 2006-2007, 2011-2012 Freescale Semiconductor, Inc.
> *
> * This program is free software; you can redistribute it and/or modify it
> * under the terms of the GNU General Public License as published by the
> @@ -26,6 +26,15 @@
> #include <asm/io.h>
> #include <linux/of_platform.h>
>
> +static unsigned int intr_coalescing_count;
> +module_param(intr_coalescing_count, int, S_IRUGO);
> +MODULE_PARM_DESC(intr_coalescing_count,
> + "INT coalescing count threshold (1..31)");
> +
> +static unsigned int intr_coalescing_ticks;
> +module_param(intr_coalescing_ticks, int, S_IRUGO);
> +MODULE_PARM_DESC(intr_coalescing_ticks,
> + "INT coalescing timer threshold in AHB ticks");
You don't seem to provide very useful defaults... for example,
intr_coalescing_count starts at 0 which isn't even in range
(the code fixes that up but still...).
I tried a debian install on the p5020ds here and I find SATA to be
extremely slow, generating millions of interrupts. I think the defaults
should be a lot more aggressive at coalescing.
Cheers,
Ben.
> /* Controller information */
> enum {
> SATA_FSL_QUEUE_DEPTH = 16,
> @@ -83,6 +92,16 @@ enum {
> };
>
> /*
> + * Interrupt Coalescing Control Register bitdefs */
> +enum {
> + ICC_MIN_INT_COUNT_THRESHOLD = 1,
> + ICC_MAX_INT_COUNT_THRESHOLD = ((1 << 5) - 1),
> + ICC_MIN_INT_TICKS_THRESHOLD = 0,
> + ICC_MAX_INT_TICKS_THRESHOLD = ((1 << 19) - 1),
> + ICC_SAFE_INT_TICKS = 1,
> +};
> +
> +/*
> * Host Controller command register set - per port
> */
> enum {
> @@ -263,8 +282,65 @@ struct sata_fsl_host_priv {
> void __iomem *csr_base;
> int irq;
> int data_snoop;
> + struct device_attribute intr_coalescing;
> };
>
> +static void fsl_sata_set_irq_coalescing(struct ata_host *host,
> + unsigned int count, unsigned int ticks)
> +{
> + struct sata_fsl_host_priv *host_priv = host->private_data;
> + void __iomem *hcr_base = host_priv->hcr_base;
> +
> + if (count > ICC_MAX_INT_COUNT_THRESHOLD)
> + count = ICC_MAX_INT_COUNT_THRESHOLD;
> + else if (count < ICC_MIN_INT_COUNT_THRESHOLD)
> + count = ICC_MIN_INT_COUNT_THRESHOLD;
> +
> + if (ticks > ICC_MAX_INT_TICKS_THRESHOLD)
> + ticks = ICC_MAX_INT_TICKS_THRESHOLD;
> + else if ((ICC_MIN_INT_TICKS_THRESHOLD == ticks) &&
> + (count > ICC_MIN_INT_COUNT_THRESHOLD))
> + ticks = ICC_SAFE_INT_TICKS;
> +
> + spin_lock(&host->lock);
> + iowrite32((count << 24 | ticks), hcr_base + ICC);
> +
> + intr_coalescing_count = count;
> + intr_coalescing_ticks = ticks;
> + spin_unlock(&host->lock);
> +
> + DPRINTK("intrrupt coalescing, count = 0x%x, ticks = %x\n",
> + intr_coalescing_count, intr_coalescing_ticks);
> + DPRINTK("ICC register status: (hcr base: 0x%x) = 0x%x\n",
> + hcr_base, ioread32(hcr_base + ICC));
> +}
> +
> +static ssize_t fsl_sata_intr_coalescing_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d %d\n",
> + intr_coalescing_count, intr_coalescing_ticks);
> +}
> +
> +static ssize_t fsl_sata_intr_coalescing_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + unsigned int coalescing_count, coalescing_ticks;
> +
> + if (sscanf(buf, "%d%d",
> + &coalescing_count,
> + &coalescing_ticks) != 2) {
> + printk(KERN_ERR "fsl-sata: wrong parameter format.\n");
> + return -EINVAL;
> + }
> +
> + fsl_sata_set_irq_coalescing(dev_get_drvdata(dev),
> + coalescing_count, coalescing_ticks);
> +
> + return strlen(buf);
> +}
> +
> static inline unsigned int sata_fsl_tag(unsigned int tag,
> void __iomem *hcr_base)
> {
> @@ -346,10 +422,10 @@ static unsigned int sata_fsl_fill_sg(struct ata_queued_cmd *qc, void *cmd_desc,
> (unsigned long long)sg_addr, sg_len);
>
> /* warn if each s/g element is not dword aligned */
> - if (sg_addr & 0x03)
> + if (unlikely(sg_addr & 0x03))
> ata_port_err(qc->ap, "s/g addr unaligned : 0x%llx\n",
> (unsigned long long)sg_addr);
> - if (sg_len & 0x03)
> + if (unlikely(sg_len & 0x03))
> ata_port_err(qc->ap, "s/g len unaligned : 0x%x\n",
> sg_len);
>
> @@ -1245,6 +1321,13 @@ static int sata_fsl_init_controller(struct ata_host *host)
> iowrite32(0x00000FFFF, hcr_base + CE);
> iowrite32(0x00000FFFF, hcr_base + DE);
>
> + /*
> + * reset the number of command complete bits which will cause the
> + * interrupt to be signaled
> + */
> + fsl_sata_set_irq_coalescing(host, intr_coalescing_count,
> + intr_coalescing_ticks);
> +
> /*
> * host controller will be brought on-line, during xx_port_start()
> * callback, that should also initiate the OOB, COMINIT sequence
> @@ -1309,7 +1392,7 @@ static int sata_fsl_probe(struct platform_device *ofdev)
> void __iomem *csr_base = NULL;
> struct sata_fsl_host_priv *host_priv = NULL;
> int irq;
> - struct ata_host *host;
> + struct ata_host *host = NULL;
> u32 temp;
>
> struct ata_port_info pi = sata_fsl_port_info[0];
> @@ -1356,6 +1439,10 @@ static int sata_fsl_probe(struct platform_device *ofdev)
>
> /* allocate host structure */
> host = ata_host_alloc_pinfo(&ofdev->dev, ppi, SATA_FSL_MAX_PORTS);
> + if (!host) {
> + retval = -ENOMEM;
> + goto error_exit_with_cleanup;
> + }
>
> /* host->iomap is not used currently */
> host->private_data = host_priv;
> @@ -1373,10 +1460,24 @@ static int sata_fsl_probe(struct platform_device *ofdev)
>
> dev_set_drvdata(&ofdev->dev, host);
>
> + host_priv->intr_coalescing.show = fsl_sata_intr_coalescing_show;
> + host_priv->intr_coalescing.store = fsl_sata_intr_coalescing_store;
> + sysfs_attr_init(&host_priv->intr_coalescing.attr);
> + host_priv->intr_coalescing.attr.name = "intr_coalescing";
> + host_priv->intr_coalescing.attr.mode = S_IRUGO | S_IWUSR;
> + retval = device_create_file(host->dev, &host_priv->intr_coalescing);
> + if (retval)
> + goto error_exit_with_cleanup;
> +
> return 0;
>
> error_exit_with_cleanup:
>
> + if (host) {
> + dev_set_drvdata(&ofdev->dev, NULL);
> + ata_host_detach(host);
> + }
> +
> if (hcr_base)
> iounmap(hcr_base);
> if (host_priv)
> @@ -1390,6 +1491,8 @@ static int sata_fsl_remove(struct platform_device *ofdev)
> struct ata_host *host = dev_get_drvdata(&ofdev->dev);
> struct sata_fsl_host_priv *host_priv = host->private_data;
>
> + device_remove_file(&ofdev->dev, &host_priv->intr_coalescing);
> +
> ata_host_detach(host);
>
> dev_set_drvdata(&ofdev->dev, NULL);
> --
> 1.6.4
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Ira W. Snyder @ 2012-02-17 0:57 UTC (permalink / raw)
To: Timur Tabi; +Cc: Dan Williams, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F3D5D84.2040609@freescale.com>
On Thu, Feb 16, 2012 at 01:48:20PM -0600, Timur Tabi wrote:
> Ira W. Snyder wrote:
>
> > No. I don't have the ability to connect my P2020 up to an FPGA to
> > recreate the DMA workload that causes this on my 8349EA. I can run the
> > dmatest module, if you'd like.
>
> I just want to make sure your patch doesn't break 85xx.
>
I tried both with and without this patch on my P2020 COM Express board.
With both kernels, the board locks up after 20 minutes or so, no
messages to the serial console.
I wouldn't be surprised if there are some memory problems with this
board. In any case, I don't have any reason to believe that this patch
causes any trouble: the board dies without it.
However, the patch doesn't break DMA on 85xx. If I unload the dmatest
module after 10 minutes or so, it claims to have passed many thousands
of tests without problems.
My 8349EA test boards (15 of them) have been running their normal DMA
workload plus dmatest on the unused 4th channel, all without errors, for
several hours. ~2.5 million successful tests per board, as I write this.
Ira
^ permalink raw reply
* Re: 5020 SATA fix
From: Kumar Gala @ 2012-02-17 1:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Xulei, linuxppc-dev
In-Reply-To: <1329438578.2892.34.camel@pasglop>
On Feb 16, 2012, at 6:29 PM, Benjamin Herrenschmidt wrote:
> Hi Lei !
>=20
> In your SDK kernel I see this commit:
>=20
> 92c0ce1e599e788ffc0908739db9bd5e0dbdad69
> sata_fsl: Add the workaround for SATA-A005 erratum on =
P2040/P3041/P5020
>=20
> Without this commit, SATA doesn't work on the p5020ds board that FSL
> just sent me. I see this was committed in June last year, any reason =
why
> this is not upstream yet ?
>=20
> Any objection to me just sending it upstream ?
>=20
> Cheers,
> Ben.
>=20
In general we've avoided sending erratum fixes for non-production =
silicon upstream.
- k
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Kumar Gala @ 2012-02-17 1:27 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1329394210-1014-1-git-send-email-leoli@freescale.com>
On Feb 16, 2012, at 6:10 AM, Li Yang wrote:
> Fix the problem that large physical address support cannot be
> disabled when some platforms which only provides 36-bit support
> are selected. According to the philosophy of kernel config
> enabling a platform support doesn't mean the kernel is only
> running on that platform. Remove the auto selection of PHYS_64BIT
> option for these platforms. They will need to use a 36bit default
> config that selects PHYS_64BIT explicitly.
>=20
> The reason why we need to keep PHYS_64BIT option configurable is
> that enabling it cause negative performance impact on various
> aspects like TLB miss and physical address manipulating. We should
> not enable it unless really needed, e.g. use large memory of 4GB
> or bigger.
>=20
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/platforms/85xx/Kconfig | 6 ------
> 1 files changed, 0 insertions(+), 6 deletions(-)
Nak, this isn't correct.
For some of these platforms like P2041RDB, P3041DS, P3060QDS, P4080DS, & =
P5020DS only a 36-bit physical address map is supported by u-boot and =
the device tree. This was a decision that was made to NOT support =
32-bit address map for these boards and accept the performance =
implication of it to reduce the # of builds, etc.
Additionally, outside of maybe P2041RDB I believe the majority of these =
boards ship with 4G of DDR (but that off the top of my head) and thus =
require the 36-bit / PHYS_64BIT support to be enabled.
- k
^ permalink raw reply
* RE: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Liu Qiang-B32616 @ 2012-02-17 1:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-ide@vger.kernel.org, jgarzik@pobox.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1329439216.2892.36.camel@pasglop>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBIZXJyZW5zY2ht
aWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnXQ0KPiBTZW50OiBGcmlkYXksIEZl
YnJ1YXJ5IDE3LCAyMDEyIDg6NDAgQU0NCj4gVG86IExpdSBRaWFuZy1CMzI2MTYNCj4gQ2M6IGpn
YXJ6aWtAcG9ib3guY29tOyBsaW51eC1pZGVAdmdlci5rZXJuZWwub3JnOyBsaW51eHBwYy0NCj4g
ZGV2QGxpc3RzLm96bGFicy5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcNCj4gU3Vi
amVjdDogUmU6IFtQQVRDSCBWMiBSRVNFTkRdIGZzbC1zYXRhOiBJL08gbG9hZCBiYWxhbmNpbmcN
Cj4gDQo+IE9uIFdlZCwgMjAxMi0wMi0xNSBhdCAxMzo0OSArMDgwMCwgUWlhbmcgTGl1IHdyb3Rl
Og0KPiBdDQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvYXRhL3NhdGFfZnNsLmMgYi9kcml2ZXJz
L2F0YS9zYXRhX2ZzbC5jIGluZGV4DQo+ID4gMDEyMGIwZC4uZDY1NzdiOSAxMDA2NDQNCj4gPiAt
LS0gYS9kcml2ZXJzL2F0YS9zYXRhX2ZzbC5jDQo+ID4gKysrIGIvZHJpdmVycy9hdGEvc2F0YV9m
c2wuYw0KPiA+IEBAIC02LDcgKzYsNyBAQA0KPiA+ICAgKiBBdXRob3I6IEFzaGlzaCBLYWxyYSA8
YXNoaXNoLmthbHJhQGZyZWVzY2FsZS5jb20+DQo+ID4gICAqIExpIFlhbmcgPGxlb2xpQGZyZWVz
Y2FsZS5jb20+DQo+ID4gICAqDQo+ID4gLSAqIENvcHlyaWdodCAoYykgMjAwNi0yMDA3LCAyMDEx
IEZyZWVzY2FsZSBTZW1pY29uZHVjdG9yLCBJbmMuDQo+ID4gKyAqIENvcHlyaWdodCAoYykgMjAw
Ni0yMDA3LCAyMDExLTIwMTIgRnJlZXNjYWxlIFNlbWljb25kdWN0b3IsIEluYy4NCj4gPiAgICoN
Cj4gPiAgICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmli
dXRlICBpdCBhbmQvb3INCj4gbW9kaWZ5IGl0DQo+ID4gICAqIHVuZGVyICB0aGUgdGVybXMgb2Yg
IHRoZSBHTlUgR2VuZXJhbCAgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkDQo+ID4gYnkgdGhl
IEBAIC0yNiw2ICsyNiwxNSBAQCAgI2luY2x1ZGUgPGFzbS9pby5oPiAgI2luY2x1ZGUNCj4gPiA8
bGludXgvb2ZfcGxhdGZvcm0uaD4NCj4gPg0KPiA+ICtzdGF0aWMgdW5zaWduZWQgaW50IGludHJf
Y29hbGVzY2luZ19jb3VudDsNCj4gPiArbW9kdWxlX3BhcmFtKGludHJfY29hbGVzY2luZ19jb3Vu
dCwgaW50LCBTX0lSVUdPKTsNCj4gPiArTU9EVUxFX1BBUk1fREVTQyhpbnRyX2NvYWxlc2Npbmdf
Y291bnQsDQo+ID4gKwkJCQkgIklOVCBjb2FsZXNjaW5nIGNvdW50IHRocmVzaG9sZCAoMS4uMzEp
Iik7DQo+ID4gKw0KPiA+ICtzdGF0aWMgdW5zaWduZWQgaW50IGludHJfY29hbGVzY2luZ190aWNr
czsNCj4gPiArbW9kdWxlX3BhcmFtKGludHJfY29hbGVzY2luZ190aWNrcywgaW50LCBTX0lSVUdP
KTsNCj4gPiArTU9EVUxFX1BBUk1fREVTQyhpbnRyX2NvYWxlc2NpbmdfdGlja3MsDQo+ID4gKwkJ
CQkgIklOVCBjb2FsZXNjaW5nIHRpbWVyIHRocmVzaG9sZCBpbiBBSEIgdGlja3MiKTsNCj4gDQo+
IFlvdSBkb24ndCBzZWVtIHRvIHByb3ZpZGUgdmVyeSB1c2VmdWwgZGVmYXVsdHMuLi4gZm9yIGV4
YW1wbGUsDQo+IGludHJfY29hbGVzY2luZ19jb3VudCBzdGFydHMgYXQgMCB3aGljaCBpc24ndCBl
dmVuIGluIHJhbmdlICh0aGUgY29kZQ0KPiBmaXhlcyB0aGF0IHVwIGJ1dCBzdGlsbC4uLikuDQo+
IA0KPiBJIHRyaWVkIGEgZGViaWFuIGluc3RhbGwgb24gdGhlIHA1MDIwZHMgaGVyZSBhbmQgSSBm
aW5kIFNBVEEgdG8gYmUNCj4gZXh0cmVtZWx5IHNsb3csIGdlbmVyYXRpbmcgbWlsbGlvbnMgb2Yg
aW50ZXJydXB0cy4gSSB0aGluayB0aGUgZGVmYXVsdHMNCj4gc2hvdWxkIGJlIGEgbG90IG1vcmUg
YWdncmVzc2l2ZSBhdCBjb2FsZXNjaW5nLg0KDQpIZWxsbyBCZW4sDQoNClRoZSBkZWZhdWx0IHdp
bGwgYmUgc2V0IGluIGEgY29tbW9uIGludGVyZmFjZSBmc2xfc2F0YV9zZXRfaXJxX2NvYWxlc2Np
bmcgd2hlbg0KaW5pdGlhbGl6ZSB0aGUgY29udHJvbGxlci4gVGhpcyBpbnRlcmZhY2Ugd2lsbCBj
aGVjayB0aGUgcmFuZ2Ugb2YgaW50ciBjb3VudA0KYW5kIHRpY2tzIGFuZCBtYWtlIHN1cmUgdGhl
IHZhbHVlcyBhcmUgcmVhc29uYWJseS4NCg0KSXQncyBoYXJkIHRvIGZpbmQgYSBhZ2dyZXNzaXZl
IHZhbHVlIHRvIGFkYXB0IGFsbCBzY2VuYXJpb3MsIHNvIEkgdXNlIGVjaG8gdG8gYWRqdXN0DQp0
aGUgdmFsdWUuIEkgcmVtZW1iZXIgUDUwMjAgaGF2ZSBzb21lIHBlcmZvcm1hbmNlIGlzc3VlLCBJ
IHdpbGwgY2hlY2sgaXQuDQpCVFcsIHdoaWNoIGZpbGVzeXN0ZW0gZG8geW91IHVzZT8gRXh0MiBp
cyBsb3dlciB0aGFuIGV4dDQgYmVjYXVzZSBtZXRhZGF0YSBpcyANCmNvbnRpbnVvdXNseSB3cm90
ZSB0byBkaXNrLiBZb3UgY2FuIHRyeSBleHQ0IG9yIHhmcy4NCg0KVGhhbmtzLg0KDQo+IA0KPiBD
aGVlcnMsDQo+IEJlbi4NCj4gDQo+ID4gIC8qIENvbnRyb2xsZXIgaW5mb3JtYXRpb24gKi8NCj4g
PiAgZW51bSB7DQo+ID4gIAlTQVRBX0ZTTF9RVUVVRV9ERVBUSAk9IDE2LA0KPiA+IEBAIC04Myw2
ICs5MiwxNiBAQCBlbnVtIHsNCj4gPiAgfTsNCj4gPg0KPiA+ICAvKg0KPiA+ICsgKiBJbnRlcnJ1
cHQgQ29hbGVzY2luZyBDb250cm9sIFJlZ2lzdGVyIGJpdGRlZnMgICovIGVudW0gew0KPiA+ICsJ
SUNDX01JTl9JTlRfQ09VTlRfVEhSRVNIT0xECT0gMSwNCj4gPiArCUlDQ19NQVhfSU5UX0NPVU5U
X1RIUkVTSE9MRAk9ICgoMSA8PCA1KSAtIDEpLA0KPiA+ICsJSUNDX01JTl9JTlRfVElDS1NfVEhS
RVNIT0xECT0gMCwNCj4gPiArCUlDQ19NQVhfSU5UX1RJQ0tTX1RIUkVTSE9MRAk9ICgoMSA8PCAx
OSkgLSAxKSwNCj4gPiArCUlDQ19TQUZFX0lOVF9USUNLUwkJPSAxLA0KPiA+ICt9Ow0KPiA+ICsN
Cj4gPiArLyoNCj4gPiAgKiBIb3N0IENvbnRyb2xsZXIgY29tbWFuZCByZWdpc3RlciBzZXQgLSBw
ZXIgcG9ydCAgKi8gIGVudW0geyBAQA0KPiA+IC0yNjMsOCArMjgyLDY1IEBAIHN0cnVjdCBzYXRh
X2ZzbF9ob3N0X3ByaXYgew0KPiA+ICAJdm9pZCBfX2lvbWVtICpjc3JfYmFzZTsNCj4gPiAgCWlu
dCBpcnE7DQo+ID4gIAlpbnQgZGF0YV9zbm9vcDsNCj4gPiArCXN0cnVjdCBkZXZpY2VfYXR0cmli
dXRlIGludHJfY29hbGVzY2luZzsNCj4gPiAgfTsNCj4gPg0KPiA+ICtzdGF0aWMgdm9pZCBmc2xf
c2F0YV9zZXRfaXJxX2NvYWxlc2Npbmcoc3RydWN0IGF0YV9ob3N0ICpob3N0LA0KPiA+ICsJCXVu
c2lnbmVkIGludCBjb3VudCwgdW5zaWduZWQgaW50IHRpY2tzKSB7DQo+ID4gKwlzdHJ1Y3Qgc2F0
YV9mc2xfaG9zdF9wcml2ICpob3N0X3ByaXYgPSBob3N0LT5wcml2YXRlX2RhdGE7DQo+ID4gKwl2
b2lkIF9faW9tZW0gKmhjcl9iYXNlID0gaG9zdF9wcml2LT5oY3JfYmFzZTsNCj4gPiArDQo+ID4g
KwlpZiAoY291bnQgPiBJQ0NfTUFYX0lOVF9DT1VOVF9USFJFU0hPTEQpDQo+ID4gKwkJY291bnQg
PSBJQ0NfTUFYX0lOVF9DT1VOVF9USFJFU0hPTEQ7DQo+ID4gKwllbHNlIGlmIChjb3VudCA8IElD
Q19NSU5fSU5UX0NPVU5UX1RIUkVTSE9MRCkNCj4gPiArCQljb3VudCA9IElDQ19NSU5fSU5UX0NP
VU5UX1RIUkVTSE9MRDsNCj4gPiArDQo+ID4gKwlpZiAodGlja3MgPiBJQ0NfTUFYX0lOVF9USUNL
U19USFJFU0hPTEQpDQo+ID4gKwkJdGlja3MgPSBJQ0NfTUFYX0lOVF9USUNLU19USFJFU0hPTEQ7
DQo+ID4gKwllbHNlIGlmICgoSUNDX01JTl9JTlRfVElDS1NfVEhSRVNIT0xEID09IHRpY2tzKSAm
Jg0KPiA+ICsJCQkoY291bnQgPiBJQ0NfTUlOX0lOVF9DT1VOVF9USFJFU0hPTEQpKQ0KPiA+ICsJ
CXRpY2tzID0gSUNDX1NBRkVfSU5UX1RJQ0tTOw0KPiA+ICsNCj4gPiArCXNwaW5fbG9jaygmaG9z
dC0+bG9jayk7DQo+ID4gKwlpb3dyaXRlMzIoKGNvdW50IDw8IDI0IHwgdGlja3MpLCBoY3JfYmFz
ZSArIElDQyk7DQo+ID4gKw0KPiA+ICsJaW50cl9jb2FsZXNjaW5nX2NvdW50ID0gY291bnQ7DQo+
ID4gKwlpbnRyX2NvYWxlc2NpbmdfdGlja3MgPSB0aWNrczsNCj4gPiArCXNwaW5fdW5sb2NrKCZo
b3N0LT5sb2NrKTsNCj4gPiArDQo+ID4gKwlEUFJJTlRLKCJpbnRycnVwdCBjb2FsZXNjaW5nLCBj
b3VudCA9IDB4JXgsIHRpY2tzID0gJXhcbiIsDQo+ID4gKwkJCWludHJfY29hbGVzY2luZ19jb3Vu
dCwgaW50cl9jb2FsZXNjaW5nX3RpY2tzKTsNCj4gPiArCURQUklOVEsoIklDQyByZWdpc3RlciBz
dGF0dXM6IChoY3IgYmFzZTogMHgleCkgPSAweCV4XG4iLA0KPiA+ICsJCQloY3JfYmFzZSwgaW9y
ZWFkMzIoaGNyX2Jhc2UgKyBJQ0MpKTsgfQ0KPiA+ICsNCj4gPiArc3RhdGljIHNzaXplX3QgZnNs
X3NhdGFfaW50cl9jb2FsZXNjaW5nX3Nob3coc3RydWN0IGRldmljZSAqZGV2LA0KPiA+ICsJCXN0
cnVjdCBkZXZpY2VfYXR0cmlidXRlICphdHRyLCBjaGFyICpidWYpIHsNCj4gPiArCXJldHVybiBz
cHJpbnRmKGJ1ZiwgIiVkCSVkXG4iLA0KPiA+ICsJCQlpbnRyX2NvYWxlc2NpbmdfY291bnQsIGlu
dHJfY29hbGVzY2luZ190aWNrcyk7IH0NCj4gPiArDQo+ID4gK3N0YXRpYyBzc2l6ZV90IGZzbF9z
YXRhX2ludHJfY29hbGVzY2luZ19zdG9yZShzdHJ1Y3QgZGV2aWNlICpkZXYsDQo+ID4gKwkJc3Ry
dWN0IGRldmljZV9hdHRyaWJ1dGUgKmF0dHIsDQo+ID4gKwkJY29uc3QgY2hhciAqYnVmLCBzaXpl
X3QgY291bnQpDQo+ID4gK3sNCj4gPiArCXVuc2lnbmVkIGludCBjb2FsZXNjaW5nX2NvdW50LAlj
b2FsZXNjaW5nX3RpY2tzOw0KPiA+ICsNCj4gPiArCWlmIChzc2NhbmYoYnVmLCAiJWQlZCIsDQo+
ID4gKwkJCQkmY29hbGVzY2luZ19jb3VudCwNCj4gPiArCQkJCSZjb2FsZXNjaW5nX3RpY2tzKSAh
PSAyKSB7DQo+ID4gKwkJcHJpbnRrKEtFUk5fRVJSICJmc2wtc2F0YTogd3JvbmcgcGFyYW1ldGVy
IGZvcm1hdC5cbiIpOw0KPiA+ICsJCXJldHVybiAtRUlOVkFMOw0KPiA+ICsJfQ0KPiA+ICsNCj4g
PiArCWZzbF9zYXRhX3NldF9pcnFfY29hbGVzY2luZyhkZXZfZ2V0X2RydmRhdGEoZGV2KSwNCj4g
PiArCQkJY29hbGVzY2luZ19jb3VudCwgY29hbGVzY2luZ190aWNrcyk7DQo+ID4gKw0KPiA+ICsJ
cmV0dXJuIHN0cmxlbihidWYpOw0KPiA+ICt9DQo+ID4gKw0KPiA+ICBzdGF0aWMgaW5saW5lIHVu
c2lnbmVkIGludCBzYXRhX2ZzbF90YWcodW5zaWduZWQgaW50IHRhZywNCj4gPiAgCQkJCQl2b2lk
IF9faW9tZW0gKmhjcl9iYXNlKQ0KPiA+ICB7DQo+ID4gQEAgLTM0NiwxMCArNDIyLDEwIEBAIHN0
YXRpYyB1bnNpZ25lZCBpbnQgc2F0YV9mc2xfZmlsbF9zZyhzdHJ1Y3QNCj4gYXRhX3F1ZXVlZF9j
bWQgKnFjLCB2b2lkICpjbWRfZGVzYywNCj4gPiAgCQkJKHVuc2lnbmVkIGxvbmcgbG9uZylzZ19h
ZGRyLCBzZ19sZW4pOw0KPiA+DQo+ID4gIAkJLyogd2FybiBpZiBlYWNoIHMvZyBlbGVtZW50IGlz
IG5vdCBkd29yZCBhbGlnbmVkICovDQo+ID4gLQkJaWYgKHNnX2FkZHIgJiAweDAzKQ0KPiA+ICsJ
CWlmICh1bmxpa2VseShzZ19hZGRyICYgMHgwMykpDQo+ID4gIAkJCWF0YV9wb3J0X2VycihxYy0+
YXAsICJzL2cgYWRkciB1bmFsaWduZWQgOiAweCVsbHhcbiIsDQo+ID4gIAkJCQkgICAgICh1bnNp
Z25lZCBsb25nIGxvbmcpc2dfYWRkcik7DQo+ID4gLQkJaWYgKHNnX2xlbiAmIDB4MDMpDQo+ID4g
KwkJaWYgKHVubGlrZWx5KHNnX2xlbiAmIDB4MDMpKQ0KPiA+ICAJCQlhdGFfcG9ydF9lcnIocWMt
PmFwLCAicy9nIGxlbiB1bmFsaWduZWQgOiAweCV4XG4iLA0KPiA+ICAJCQkJICAgICBzZ19sZW4p
Ow0KPiA+DQo+ID4gQEAgLTEyNDUsNiArMTMyMSwxMyBAQCBzdGF0aWMgaW50IHNhdGFfZnNsX2lu
aXRfY29udHJvbGxlcihzdHJ1Y3QNCj4gYXRhX2hvc3QgKmhvc3QpDQo+ID4gIAlpb3dyaXRlMzIo
MHgwMDAwMEZGRkYsIGhjcl9iYXNlICsgQ0UpOw0KPiA+ICAJaW93cml0ZTMyKDB4MDAwMDBGRkZG
LCBoY3JfYmFzZSArIERFKTsNCj4gPg0KPiA+ICsgCS8qDQo+ID4gKwkgKiByZXNldCB0aGUgbnVt
YmVyIG9mIGNvbW1hbmQgY29tcGxldGUgYml0cyB3aGljaCB3aWxsIGNhdXNlIHRoZQ0KPiA+ICsJ
ICogaW50ZXJydXB0IHRvIGJlIHNpZ25hbGVkDQo+ID4gKwkgKi8NCj4gPiArCWZzbF9zYXRhX3Nl
dF9pcnFfY29hbGVzY2luZyhob3N0LCBpbnRyX2NvYWxlc2NpbmdfY291bnQsDQo+ID4gKwkJCWlu
dHJfY29hbGVzY2luZ190aWNrcyk7DQo+ID4gKw0KPiA+ICAJLyoNCj4gPiAgCSAqIGhvc3QgY29u
dHJvbGxlciB3aWxsIGJlIGJyb3VnaHQgb24tbGluZSwgZHVyaW5nIHh4X3BvcnRfc3RhcnQoKQ0K
PiA+ICAJICogY2FsbGJhY2ssIHRoYXQgc2hvdWxkIGFsc28gaW5pdGlhdGUgdGhlIE9PQiwgQ09N
SU5JVCBzZXF1ZW5jZSBAQA0KPiA+IC0xMzA5LDcgKzEzOTIsNyBAQCBzdGF0aWMgaW50IHNhdGFf
ZnNsX3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UNCj4gKm9mZGV2KQ0KPiA+ICAJdm9pZCBf
X2lvbWVtICpjc3JfYmFzZSA9IE5VTEw7DQo+ID4gIAlzdHJ1Y3Qgc2F0YV9mc2xfaG9zdF9wcml2
ICpob3N0X3ByaXYgPSBOVUxMOw0KPiA+ICAJaW50IGlycTsNCj4gPiAtCXN0cnVjdCBhdGFfaG9z
dCAqaG9zdDsNCj4gPiArCXN0cnVjdCBhdGFfaG9zdCAqaG9zdCA9IE5VTEw7DQo+ID4gIAl1MzIg
dGVtcDsNCj4gPg0KPiA+ICAJc3RydWN0IGF0YV9wb3J0X2luZm8gcGkgPSBzYXRhX2ZzbF9wb3J0
X2luZm9bMF07IEBAIC0xMzU2LDYNCj4gKzE0MzksMTANCj4gPiBAQCBzdGF0aWMgaW50IHNhdGFf
ZnNsX3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKm9mZGV2KQ0KPiA+DQo+ID4gIAkvKiBh
bGxvY2F0ZSBob3N0IHN0cnVjdHVyZSAqLw0KPiA+ICAJaG9zdCA9IGF0YV9ob3N0X2FsbG9jX3Bp
bmZvKCZvZmRldi0+ZGV2LCBwcGksIFNBVEFfRlNMX01BWF9QT1JUUyk7DQo+ID4gKwlpZiAoIWhv
c3QpIHsNCj4gPiArCQlyZXR2YWwgPSAtRU5PTUVNOw0KPiA+ICsJCWdvdG8gZXJyb3JfZXhpdF93
aXRoX2NsZWFudXA7DQo+ID4gKwl9DQo+ID4NCj4gPiAgCS8qIGhvc3QtPmlvbWFwIGlzIG5vdCB1
c2VkIGN1cnJlbnRseSAqLw0KPiA+ICAJaG9zdC0+cHJpdmF0ZV9kYXRhID0gaG9zdF9wcml2Ow0K
PiA+IEBAIC0xMzczLDEwICsxNDYwLDI0IEBAIHN0YXRpYyBpbnQgc2F0YV9mc2xfcHJvYmUoc3Ry
dWN0DQo+ID4gcGxhdGZvcm1fZGV2aWNlICpvZmRldikNCj4gPg0KPiA+ICAJZGV2X3NldF9kcnZk
YXRhKCZvZmRldi0+ZGV2LCBob3N0KTsNCj4gPg0KPiA+ICsJaG9zdF9wcml2LT5pbnRyX2NvYWxl
c2Npbmcuc2hvdyA9IGZzbF9zYXRhX2ludHJfY29hbGVzY2luZ19zaG93Ow0KPiA+ICsJaG9zdF9w
cml2LT5pbnRyX2NvYWxlc2Npbmcuc3RvcmUgPSBmc2xfc2F0YV9pbnRyX2NvYWxlc2Npbmdfc3Rv
cmU7DQo+ID4gKwlzeXNmc19hdHRyX2luaXQoJmhvc3RfcHJpdi0+aW50cl9jb2FsZXNjaW5nLmF0
dHIpOw0KPiA+ICsJaG9zdF9wcml2LT5pbnRyX2NvYWxlc2NpbmcuYXR0ci5uYW1lID0gImludHJf
Y29hbGVzY2luZyI7DQo+ID4gKwlob3N0X3ByaXYtPmludHJfY29hbGVzY2luZy5hdHRyLm1vZGUg
PSBTX0lSVUdPIHwgU19JV1VTUjsNCj4gPiArCXJldHZhbCA9IGRldmljZV9jcmVhdGVfZmlsZSho
b3N0LT5kZXYsICZob3N0X3ByaXYtPmludHJfY29hbGVzY2luZyk7DQo+ID4gKwlpZiAocmV0dmFs
KQ0KPiA+ICsJCWdvdG8gZXJyb3JfZXhpdF93aXRoX2NsZWFudXA7DQo+ID4gKw0KPiA+ICAJcmV0
dXJuIDA7DQo+ID4NCj4gPiAgZXJyb3JfZXhpdF93aXRoX2NsZWFudXA6DQo+ID4NCj4gPiArCWlm
IChob3N0KSB7DQo+ID4gKwkJZGV2X3NldF9kcnZkYXRhKCZvZmRldi0+ZGV2LCBOVUxMKTsNCj4g
PiArCQlhdGFfaG9zdF9kZXRhY2goaG9zdCk7DQo+ID4gKwl9DQo+ID4gKw0KPiA+ICAJaWYgKGhj
cl9iYXNlKQ0KPiA+ICAJCWlvdW5tYXAoaGNyX2Jhc2UpOw0KPiA+ICAJaWYgKGhvc3RfcHJpdikN
Cj4gPiBAQCAtMTM5MCw2ICsxNDkxLDggQEAgc3RhdGljIGludCBzYXRhX2ZzbF9yZW1vdmUoc3Ry
dWN0IHBsYXRmb3JtX2RldmljZQ0KPiAqb2ZkZXYpDQo+ID4gIAlzdHJ1Y3QgYXRhX2hvc3QgKmhv
c3QgPSBkZXZfZ2V0X2RydmRhdGEoJm9mZGV2LT5kZXYpOw0KPiA+ICAJc3RydWN0IHNhdGFfZnNs
X2hvc3RfcHJpdiAqaG9zdF9wcml2ID0gaG9zdC0+cHJpdmF0ZV9kYXRhOw0KPiA+DQo+ID4gKwlk
ZXZpY2VfcmVtb3ZlX2ZpbGUoJm9mZGV2LT5kZXYsICZob3N0X3ByaXYtPmludHJfY29hbGVzY2lu
Zyk7DQo+ID4gKw0KPiA+ICAJYXRhX2hvc3RfZGV0YWNoKGhvc3QpOw0KPiA+DQo+ID4gIAlkZXZf
c2V0X2RydmRhdGEoJm9mZGV2LT5kZXYsIE5VTEwpOw0KPiA+IC0tDQo+ID4gMS42LjQNCj4gPg0K
PiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4gPiBMaW51eHBwYy1kZXYgbWFpbGluZyBsaXN0DQo+ID4gTGludXhwcGMtZGV2QGxpc3RzLm96
bGFicy5vcmcNCj4gPiBodHRwczovL2xpc3RzLm96bGFicy5vcmcvbGlzdGluZm8vbGludXhwcGMt
ZGV2DQo+IA0KPiANCg0K
^ permalink raw reply
* RE: [PATCH v4 2/3] KVM: PPC: epapr: Add idle hcall support for host
From: Liu Yu-B13201 @ 2012-02-17 2:13 UTC (permalink / raw)
To: Alexander Graf
Cc: <linuxppc-dev@ozlabs.org>, <kvm@vger.kernel.org>,
<kvm-ppc@vger.kernel.org>, Wood Scott-B07421
In-Reply-To: <F0023B33-6AF3-4805-B50E-2ED285F8B1B0@suse.de>
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Thursday, February 16, 2012 6:20 PM
> To: Liu Yu-B13201
> Cc: <kvm-ppc@vger.kernel.org>; <kvm@vger.kernel.org>; <linuxppc-
> dev@ozlabs.org>; Wood Scott-B07421; Liu Yu-B13201
> Subject: Re: [PATCH v4 2/3] KVM: PPC: epapr: Add idle hcall support for
> host
>=20
>=20
>=20
> On 16.02.2012, at 10:26, Liu Yu <yu.liu@freescale.com> wrote:
>=20
> > And add a new flag definition in kvm_ppc_pvinfo to indicate whether
> > host support EV_IDLE hcall.
> >
> > Signed-off-by: Liu Yu <yu.liu@freescale.com>
> > ---
> > v4:
> > no change
> >
> > arch/powerpc/include/asm/kvm_para.h | 14 ++++++++++++--
> > arch/powerpc/kvm/powerpc.c | 8 ++++++++
> > include/linux/kvm.h | 2 ++
> > 3 files changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/kvm_para.h
> > b/arch/powerpc/include/asm/kvm_para.h
> > index 7b754e7..81a34c9 100644
> > --- a/arch/powerpc/include/asm/kvm_para.h
> > +++ b/arch/powerpc/include/asm/kvm_para.h
> > @@ -75,9 +75,19 @@ struct kvm_vcpu_arch_shared { };
> >
> > #define KVM_SC_MAGIC_R0 0x4b564d21 /* "KVM!" */
> > -#define HC_VENDOR_KVM (42 << 16)
> > +
> > +#include <asm/epapr_hcalls.h>
> > +
> > +/* ePAPR Hypercall Vendor ID */
> > +#define HC_VENDOR_EPAPR (EV_EPAPR_VENDOR_ID << 16)
> > +#define HC_VENDOR_KVM (EV_KVM_VENDOR_ID << 16)
> > +
> > +/* ePAPR Hypercall Token */
> > +#define HC_EV_IDLE EV_IDLE
> > +
> > +/* ePAPR Hypercall Return Codes */
> > #define HC_EV_SUCCESS 0
> > -#define HC_EV_UNIMPLEMENTED 12
> > +#define HC_EV_UNIMPLEMENTED EV_UNIMPLEMENTED
> >
> > #define KVM_FEATURE_MAGIC_PAGE 1
> >
> > diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> > index 0e21d15..03ebd5d 100644
> > --- a/arch/powerpc/kvm/powerpc.c
> > +++ b/arch/powerpc/kvm/powerpc.c
> > @@ -81,6 +81,10 @@ int kvmppc_kvm_pv(struct kvm_vcpu *vcpu)
> >
> > /* Second return value is in r4 */
> > break;
> > + case HC_VENDOR_EPAPR | HC_EV_IDLE:
> > + r =3D HC_EV_SUCCESS;
> > + kvm_vcpu_block(vcpu);
> > + break;
> > default:
> > r =3D HC_EV_UNIMPLEMENTED;
> > break;
> > @@ -746,6 +750,10 @@ static int kvm_vm_ioctl_get_pvinfo(struct
> kvm_ppc_pvinfo *pvinfo)
> > pvinfo->hcall[2] =3D inst_sc;
> > pvinfo->hcall[3] =3D inst_nop;
> >
> > +#ifdef CONFIG_BOOKE
> > + pvinfo->flags |=3D KVM_PPC_PVINFO_FLAGS_EV_IDLE; #endif
> > +
> > return 0;
> > }>=20
>
> Why limit it to booke? The less ifdefs our code has, the better :)
The code here tells userspace that kvm support ev_idle.
But I'm not sure if the ev_idle code works for other platforms.
So I think we should keep the ifdef until other platform test the code :)
Thanks,
Yu
^ permalink raw reply
* Re: [PATCH v4 2/3] KVM: PPC: epapr: Add idle hcall support for host
From: Alexander Graf @ 2012-02-17 2:20 UTC (permalink / raw)
To: Liu Yu-B13201
Cc: <linuxppc-dev@ozlabs.org>, <kvm@vger.kernel.org>,
<kvm-ppc@vger.kernel.org>, Wood Scott-B07421
In-Reply-To: <4CA99838F21AB847ACC344051E2317090571EB39@039-SN2MPN1-022.039d.mgd.msft.net>
On 17.02.2012, at 03:13, Liu Yu-B13201 wrote:
>=20
>=20
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Thursday, February 16, 2012 6:20 PM
>> To: Liu Yu-B13201
>> Cc: <kvm-ppc@vger.kernel.org>; <kvm@vger.kernel.org>; <linuxppc-
>> dev@ozlabs.org>; Wood Scott-B07421; Liu Yu-B13201
>> Subject: Re: [PATCH v4 2/3] KVM: PPC: epapr: Add idle hcall support =
for
>> host
>>=20
>>=20
>>=20
>> On 16.02.2012, at 10:26, Liu Yu <yu.liu@freescale.com> wrote:
>>=20
>>> And add a new flag definition in kvm_ppc_pvinfo to indicate whether
>>> host support EV_IDLE hcall.
>>>=20
>>> Signed-off-by: Liu Yu <yu.liu@freescale.com>
>>> ---
>>> v4:
>>> no change
>>>=20
>>> arch/powerpc/include/asm/kvm_para.h | 14 ++++++++++++--
>>> arch/powerpc/kvm/powerpc.c | 8 ++++++++
>>> include/linux/kvm.h | 2 ++
>>> 3 files changed, 22 insertions(+), 2 deletions(-)
>>>=20
>>> diff --git a/arch/powerpc/include/asm/kvm_para.h
>>> b/arch/powerpc/include/asm/kvm_para.h
>>> index 7b754e7..81a34c9 100644
>>> --- a/arch/powerpc/include/asm/kvm_para.h
>>> +++ b/arch/powerpc/include/asm/kvm_para.h
>>> @@ -75,9 +75,19 @@ struct kvm_vcpu_arch_shared { };
>>>=20
>>> #define KVM_SC_MAGIC_R0 0x4b564d21 /* "KVM!" */
>>> -#define HC_VENDOR_KVM (42 << 16)
>>> +
>>> +#include <asm/epapr_hcalls.h>
>>> +
>>> +/* ePAPR Hypercall Vendor ID */
>>> +#define HC_VENDOR_EPAPR (EV_EPAPR_VENDOR_ID << 16)
>>> +#define HC_VENDOR_KVM (EV_KVM_VENDOR_ID << 16)
>>> +
>>> +/* ePAPR Hypercall Token */
>>> +#define HC_EV_IDLE EV_IDLE
>>> +
>>> +/* ePAPR Hypercall Return Codes */
>>> #define HC_EV_SUCCESS 0
>>> -#define HC_EV_UNIMPLEMENTED 12
>>> +#define HC_EV_UNIMPLEMENTED EV_UNIMPLEMENTED
>>>=20
>>> #define KVM_FEATURE_MAGIC_PAGE 1
>>>=20
>>> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>>> index 0e21d15..03ebd5d 100644
>>> --- a/arch/powerpc/kvm/powerpc.c
>>> +++ b/arch/powerpc/kvm/powerpc.c
>>> @@ -81,6 +81,10 @@ int kvmppc_kvm_pv(struct kvm_vcpu *vcpu)
>>>=20
>>> /* Second return value is in r4 */
>>> break;
>>> + case HC_VENDOR_EPAPR | HC_EV_IDLE:
>>> + r =3D HC_EV_SUCCESS;
>>> + kvm_vcpu_block(vcpu);
>>> + break;
>>> default:
>>> r =3D HC_EV_UNIMPLEMENTED;
>>> break;
>>> @@ -746,6 +750,10 @@ static int kvm_vm_ioctl_get_pvinfo(struct
>> kvm_ppc_pvinfo *pvinfo)
>>> pvinfo->hcall[2] =3D inst_sc;
>>> pvinfo->hcall[3] =3D inst_nop;
>>>=20
>>> +#ifdef CONFIG_BOOKE
>>> + pvinfo->flags |=3D KVM_PPC_PVINFO_FLAGS_EV_IDLE; #endif
>>> +
>>> return 0;
>>> }>=20
>>=20
>> Why limit it to booke? The less ifdefs our code has, the better :)
>=20
> The code here tells userspace that kvm support ev_idle.
> But I'm not sure if the ev_idle code works for other platforms.
>=20
> So I think we should keep the ifdef until other platform test the code =
:)
But the implementation is in generic code and is not #ifdef'ed, so a =
guest could still call it just fine. It looks simple enough to work =
without major testing on different platforms, so I'd say just expose it =
and be done :)
Alex
^ permalink raw reply
* RE: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Liu Shengzhou-B36685 @ 2012-02-17 2:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1329436955.2892.32.camel@pasglop>
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbmphbWluIEhlcnJlbnNj
aG1pZHQgW21haWx0bzpiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmddDQo+IFNlbnQ6IEZyaWRheSwg
RmVicnVhcnkgMTcsIDIwMTIgODowMyBBTQ0KPiBUbzogTGl1IFNoZW5nemhvdS1CMzY2ODUNCj4g
Q2M6IGxpbnV4LXVzYkB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMu
b3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIHBvd2VycGMvdXNiOiBmaXggYnVnIG9mIGtlcm5l
bCBoYW5nIHdoZW4NCj4gaW5pdGlhbGl6aW5nIHVzYg0KPiANCj4gT24gRnJpLCAyMDEyLTAyLTE3
IGF0IDA5OjU4ICsxMTAwLCBCZW5qYW1pbiBIZXJyZW5zY2htaWR0IHdyb3RlOg0KPiA+IE9uIFRo
dSwgMjAxMi0wMi0xNiBhdCAxODowMiArMDgwMCwgU2hlbmd6aG91IExpdSB3cm90ZToNCj4gPiA+
IElmIFVTQiBVVE1JIFBIWSBpcyBub3QgZW5hYmxlLCB3cml0aW5nIHRvIHBvcnRzYyByZWdpc3Rl
ciB3aWxsIGxlYWQNCj4gPiA+IHRvIGtlcm5lbCBoYW5nIGR1cmluZyBib290IHVwLg0KPiA+ID4N
Cj4gPiA+IFNpZ25lZC1vZmYtYnk6IFNoZW5nemhvdSBMaXUgPFNoZW5nemhvdS5MaXVAZnJlZXNj
YWxlLmNvbT4NCj4gPiA+IC0tLQ0KPiA+ID4gQXBwbHkgZm9yIG1hc3RlciBicmFuY2ggb2YNCj4g
PiA+IGdpdDovL2dpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC90b3J2YWxk
cy9saW51eC0NCj4gMi42LmdpdA0KPiA+ID4gVGVzdGVkIG9uIFA1MDIwRFMsIHRoZSBpc3N1ZSB3
YXMgcmVwb3J0ZWQgYnkgQmVuamFtaW4gSGVycmVuc2NobWlkdC4NCj4gPg0KPiA+IFRoaXMgZml4
ZXMgdGhlIGhhbmcsIGJ1dCBzYWRseSBkb2Vzbid0IG1ha2UgVVNCIHdvcmsuIEkgbm93IGdldDoN
Cj4gDQo+ICAuLi4vLi4uDQo+IA0KPiBPaywgZm91bmQgdGhlIHByb2JsZW0uDQo+IA0KPiBGaXJz
dCwgdGhlIFNESyBrZXJuZWwgaGFkIGEgZGVsYXkgYWZ0ZXIgc2V0dGluZyB0aGF0IGJpdCwgSSBh
ZGRlZCB0aGF0DQo+IGJhY2sgaW4uIFRoaXMgaXMgbm90IHdoYXQgZml4ZWQgaXQgYnV0IGl0IGxv
b2tzIGxpa2UgdGhlIHJpZ2h0IHRoaW5nIHRvDQo+IGRvLCB0aG91Z2ggcGxlYXNlLCB1c2UgbXNs
ZWVwIHJhdGhlciB0aGFuIHVkZWxheSBoZXJlIGlmIHBvc3NpYmxlIChub3QNCj4gaW4gYXRvbWlj
IGNvbnRleHQpLg0KPiANCj4gVGhlbiwgdGhlIHJlYWwgY3VscHJpdCBpcyAoQ0MnaW5nIEt1bWFy
IGFuZCBTY290dCB0byBmaWd1cmUgb3V0IHdoeSkNCj4gdGhpcyBzdGF0ZW1lbnQ6DQo+IA0KPiAj
aWYgZGVmaW5lZChDT05GSUdfUFBDMzIpICYmICFkZWZpbmVkKENPTkZJR19OT1RfQ09IRVJFTlRf
Q0FDSEUpDQo+IAkvKg0KPiAJICogVHVybiBvbiBjYWNoZSBzbm9vcGluZyBoYXJkd2FyZSwgc2lu
Y2Ugc29tZSBQb3dlclBDIHBsYXRmb3Jtcw0KPiAJICogd2hvbGx5IHJlbHkgb24gaGFyZHdhcmUg
dG8gZGVhbCB3aXRoIGNhY2hlIGNvaGVyZW50DQo+IAkgKi8NCj4gDQo+IAkvKiBTZXR1cCBTbm9v
cGluZyBmb3IgYWxsIHRoZSA0R0Igc3BhY2UgKi8NCj4gCS8qIFNOT09QMSBzdGFydHMgZnJvbSAw
eDAsIHNpemUgMkcgKi8NCj4gCW91dF9iZTMyKG5vbl9laGNpICsgRlNMX1NPQ19VU0JfU05PT1Ax
LCAweDAgfCBTTk9PUF9TSVpFXzJHQik7DQo+IAkvKiBTTk9PUDIgc3RhcnRzIGZyb20gMHg4MDAw
MDAwMCwgc2l6ZSAyRyAqLw0KPiAJb3V0X2JlMzIobm9uX2VoY2kgKyBGU0xfU09DX1VTQl9TTk9P
UDIsIDB4ODAwMDAwMDAgfA0KPiBTTk9PUF9TSVpFXzJHQik7ICNlbmRpZg0KPiANCj4gSSdtIGJ1
aWxkaW5nIGEgNjQtYml0IGtlcm5lbCBzbyB0aGlzIGlzbid0IGNvbXBpbGVkIGFuZCBpdCBsb29r
cyBsaWtlDQo+IHRoZSBFSENJIGlzIHRodXMgbm90IHNub29waW5nLg0KPiANCj4gQnkgcmVtb3Zp
bmcgdGhlIGRlZmluZWQoQ09ORklHX1BQQzMyKSBwYXJ0IG9mIHRoZSBzdGF0ZW1lbnQsIG15IHBy
b2JsZW0NCj4gZ29lcyBhd2F5Lg0KPiANCj4gQ2hlZXJzLA0KPiBCZW4uDQo+IA0KPiANCg0KW1No
ZW5nemhvdV0gSSB0ZXN0ZWQgdGhlIHBhdGNoIHdpdGggMzJiaXQgUDUwMjBEUywgVVNCIHdvcmtl
ZCB3ZWxsLiBOb3QgdGVzdGVkIHdpdGggNjQtYml0IGtlcm5lbC4NCkdsYWQgdG8geW91IGhhZCBm
b3VuZCB0aGUgcHJvYmxlbSBpbiBjYXNlIG9mIDY0LWJpdCwgdGhhbmtzIQ0K
^ permalink raw reply
* [PATCH 1/2] powerpc: document the FSL MPIC message register binding
From: Jia Hongtao @ 2012-02-17 2:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: meador_inge, b38951
This binding documents how the message register blocks found in some FSL
MPIC implementations shall be represented in a device tree.
Signed-off-by: Meador Inge <meador_inge@mentor.com>
Signed-off-by: Jia Hongtao <B38951@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
.../devicetree/bindings/powerpc/fsl/mpic-msgr.txt | 62 ++++++++++++++++++++
1 files changed, 62 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
new file mode 100644
index 0000000..b4ae70e
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
@@ -0,0 +1,62 @@
+* FSL MPIC Message Registers
+
+This binding specifies what properties must be available in the device tree
+representation of the message register blocks found in some FSL MPIC
+implementations.
+
+Required properties:
+
+ - compatible: Specifies the compatibility list for the message register
+ block. The type shall be <string> and the value shall be of the form
+ "fsl,mpic-v<version>-msgr", where <version> is the version number of
+ the MPIC containing the message registers.
+
+ - reg: Specifies the base physical address(s) and size(s) of the
+ message register block's addressable register space. The type shall be
+ <prop-encoded-array>.
+
+ - interrupts: Specifies a list of interrupt source and level-sense pairs.
+ The type shall be <prop-encoded-array>. The length shall be equal to
+ the number of registers that are available for receiving interrupts.
+
+Optional properties:
+
+ - mpic-msgr-receive-mask: Specifies what registers in the containing block
+ are allowed to receive interrupts. The value is a bit mask where a set
+ bit at bit 'n' indicates that message register 'n' can receive interrupts.
+ The type shall be <prop-encoded-array>. If not present, then all of
+ the message registers in the block are available.
+
+Aliases:
+
+ An alias should be created for every message register block. They are not
+ required, though. However, a particular implementation of this binding
+ may require aliases to be present. Aliases are of the form
+ 'mpic-msgr-block<n>', where <n> is an integer specifying the block's number.
+ Numbers shall start at 0.
+
+Example:
+
+ aliases {
+ mpic-msgr-block0 = &mpic_msgr_block0;
+ mpic-msgr-block1 = &mpic_msgr_block1;
+ };
+
+ mpic_msgr_block0: mpic-msgr-block@41400 {
+ compatible = "fsl,mpic-v3.1-msgr";
+ reg = <0x41400 0x200>;
+ // Message registers 0 and 2 in this block can receive interrupts on
+ // sources 0xb0 and 0xb2, respectively.
+ interrupts = <0xb0 2 0xb2 2>;
+ mpic-msgr-receive-mask = <0x5>;
+ };
+
+ mpic_msgr_block1: mpic-msgr-block@42400 {
+ compatible = "fsl,mpic-v3.1-msgr";
+ reg = <0x42400 0x200>;
+ // Message registers 0 and 2 in this block can receive interrupts on
+ // sources 0xb4 and 0xb6, respectively.
+ interrupts = <0xb4 2 0xb6 2>;
+ mpic-msgr-receive-mask = <0x5>;
+ };
+
--
1.7.5.1
^ permalink raw reply related
* [PATCH 2/2] powerpc: add support for MPIC message register API
From: Jia Hongtao @ 2012-02-17 2:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: meador_inge, b38951
In-Reply-To: <1329446943-9732-1-git-send-email-B38951@freescale.com>
Some MPIC implementations contain one or more blocks of message registers
that are used to send messages between cores via IPIs. A simple API has
been added to access (get/put, read, write, etc ...) these message registers.
The available message registers are initially discovered via nodes in the
device tree. A separate commit contains a binding for the message register
nodes.
Signed-off-by: Meador Inge <meador_inge@mentor.com>
Signed-off-by: Jia Hongtao <B38951@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
This patch is an update for : http://patchwork.ozlabs.org/patch/98075/
Meador Inge addressed the following points from Ben's feedback:
* Drop the 'mpic_msgr.msr' field.
* Drop the 'mpic_msgr.mer' field in favor of address arithmetic off of 'mpic_msgr.addr'.
* Document the API.
* Disable MPIC register in 'mpic_msgr_put'.
* Put locking in 'mpic_msgr_disable'.
* s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL/g.
* Make 'mpic_msgr_write' and 'mpic_msgr_read' 'static inline'.
I just fixed the checkpatch errors and addressed the following item:
* In 'mpic_msgr_set_destination' have a wrapper that goes from Linux
CPU number to HW CPU number.
arch/powerpc/include/asm/mpic_msgr.h | 132 ++++++++++++++++
arch/powerpc/platforms/Kconfig | 8 +
arch/powerpc/sysdev/Makefile | 2 +
arch/powerpc/sysdev/mpic_msgr.c | 282 ++++++++++++++++++++++++++++++++++
4 files changed, 424 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/mpic_msgr.h
create mode 100644 arch/powerpc/sysdev/mpic_msgr.c
diff --git a/arch/powerpc/include/asm/mpic_msgr.h b/arch/powerpc/include/asm/mpic_msgr.h
new file mode 100644
index 0000000..3ec37dc
--- /dev/null
+++ b/arch/powerpc/include/asm/mpic_msgr.h
@@ -0,0 +1,132 @@
+/*
+ * Copyright 2011-2012, Meador Inge, Mentor Graphics Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ */
+
+#ifndef _ASM_MPIC_MSGR_H
+#define _ASM_MPIC_MSGR_H
+
+#include <linux/types.h>
+#include <linux/spinlock.h>
+
+struct mpic_msgr {
+ u32 __iomem *base;
+ u32 __iomem *mer;
+ int irq;
+ unsigned char in_use;
+ raw_spinlock_t lock;
+ int num;
+};
+
+/* Get a message register
+ *
+ * @reg_num: the MPIC message register to get
+ *
+ * A pointer to the message register is returned. If
+ * the message register asked for is already in use, then
+ * EBUSY is returned. If the number given is not associated
+ * with an actual message register, then ENODEV is returned.
+ * Successfully getting the register marks it as in use.
+ */
+extern struct mpic_msgr *mpic_msgr_get(unsigned int reg_num);
+
+/* Relinquish a message register
+ *
+ * @msgr: the message register to return
+ *
+ * Disables the given message register and marks it as free.
+ * After this call has completed successully the message
+ * register is available to be acquired by a call to
+ * mpic_msgr_get.
+ */
+extern void mpic_msgr_put(struct mpic_msgr *msgr);
+
+/* Enable a message register
+ *
+ * @msgr: the message register to enable
+ *
+ * The given message register is enabled for sending
+ * messages.
+ */
+extern void mpic_msgr_enable(struct mpic_msgr *msgr);
+
+/* Disable a message register
+ *
+ * @msgr: the message register to disable
+ *
+ * The given message register is disabled for sending
+ * messages.
+ */
+extern void mpic_msgr_disable(struct mpic_msgr *msgr);
+
+/* Write a message to a message register
+ *
+ * @msgr: the message register to write to
+ * @message: the message to write
+ *
+ * The given 32-bit message is written to the given message
+ * register. Writing to an enabled message registers fires
+ * an interrupt.
+ */
+static inline void mpic_msgr_write(struct mpic_msgr *msgr, u32 message)
+{
+ out_be32(msgr->base, message);
+}
+
+/* Read a message from a message register
+ *
+ * @msgr: the message register to read from
+ *
+ * Returns the 32-bit value currently in the given message register.
+ * Upon reading the register any interrupts for that register are
+ * cleared.
+ */
+static inline u32 mpic_msgr_read(struct mpic_msgr *msgr)
+{
+ return in_be32(msgr->base);
+}
+
+/* Clear a message register
+ *
+ * @msgr: the message register to clear
+ *
+ * Clears any interrupts associated with the given message register.
+ */
+static inline void mpic_msgr_clear(struct mpic_msgr *msgr)
+{
+ (void) mpic_msgr_read(msgr);
+}
+
+/* Set the destination CPU for the message register
+ *
+ * @msgr: the message register whose destination is to be set
+ * @cpu_num: the Linux CPU number to bind the message register to
+ *
+ * Note that the CPU number given is the CPU number used by the kernel
+ * and *not* the actual hardware CPU number.
+ */
+static inline void mpic_msgr_set_destination(struct mpic_msgr *msgr,
+ u32 cpu_num)
+{
+ out_be32(msgr->base, 1 << get_hard_smp_processor_id(cpu_num));
+}
+
+/* Get the IRQ number for the message register
+ * @msgr: the message register whose IRQ is to be returned
+ *
+ * Returns the IRQ number associated with the given message register.
+ * NO_IRQ is returned if this message register is not capable of
+ * receiving interrupts. What message register can and cannot receive
+ * interrupts is specified in the device tree for the system.
+ */
+static inline int mpic_msgr_get_irq(struct mpic_msgr *msgr)
+{
+ return msgr->irq;
+}
+
+#endif
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index eb294a6..fc4f5580 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -87,6 +87,14 @@ config MPIC_WEIRD
bool
default n
+config MPIC_MSGR
+ bool "MPIC message register support"
+ depends on MPIC
+ default n
+ help
+ Enables support for the MPIC message registers. These
+ registers are used for inter-processor communication.
+
config PPC_I8259
bool
default n
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 5e37b47..1951dc7 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -4,6 +4,8 @@ ccflags-$(CONFIG_PPC64) := -mno-minimal-toc
mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
+mpic-msgr-obj-$(CONFIG_MPIC_MSGR) += mpic_msgr.o
+obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y) $(mpic-msgr-obj-y)
obj-$(CONFIG_PPC_EPAPR_HV_PIC) += ehv_pic.o
fsl-msi-obj-$(CONFIG_PCI_MSI) += fsl_msi.o
obj-$(CONFIG_PPC_MSI_BITMAP) += msi_bitmap.o
diff --git a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
new file mode 100644
index 0000000..6e7fa38
--- /dev/null
+++ b/arch/powerpc/sysdev/mpic_msgr.c
@@ -0,0 +1,282 @@
+/*
+ * Copyright 2011-2012, Meador Inge, Mentor Graphics Corporation.
+ *
+ * Some ideas based on un-pushed work done by Vivek Mahajan, Jason Jin, and
+ * Mingkai Hu from Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ */
+
+#include <linux/list.h>
+#include <linux/of_platform.h>
+#include <linux/errno.h>
+#include <asm/prom.h>
+#include <asm/hw_irq.h>
+#include <asm/ppc-pci.h>
+#include <asm/mpic_msgr.h>
+
+#define MPIC_MSGR_REGISTERS_PER_BLOCK 4
+#define MPIC_MSGR_STRIDE 0x10
+#define MPIC_MSGR_MER_OFFSET 0x100
+#define MSGR_INUSE 0
+#define MSGR_FREE 1
+
+static struct mpic_msgr **mpic_msgrs;
+static unsigned int mpic_msgr_count;
+
+static inline void _mpic_msgr_mer_write(struct mpic_msgr *msgr, u32 value)
+{
+ out_be32(msgr->mer, value);
+}
+
+static inline u32 _mpic_msgr_mer_read(struct mpic_msgr *msgr)
+{
+ return in_be32(msgr->mer);
+}
+
+static inline void _mpic_msgr_disable(struct mpic_msgr *msgr)
+{
+ u32 mer = _mpic_msgr_mer_read(msgr);
+
+ _mpic_msgr_mer_write(msgr, mer & ~(1 << msgr->num));
+}
+
+struct mpic_msgr *mpic_msgr_get(unsigned int reg_num)
+{
+ unsigned long flags;
+ struct mpic_msgr *msgr;
+
+ /* Assume busy until proven otherwise. */
+ msgr = ERR_PTR(-EBUSY);
+
+ if (reg_num >= mpic_msgr_count)
+ return ERR_PTR(-ENODEV);
+
+ raw_spin_lock_irqsave(&msgr->lock, flags);
+ if (mpic_msgrs[reg_num]->in_use == MSGR_FREE) {
+ msgr = mpic_msgrs[reg_num];
+ msgr->in_use = MSGR_INUSE;
+ }
+ raw_spin_unlock_irqrestore(&msgr->lock, flags);
+
+ return msgr;
+}
+EXPORT_SYMBOL_GPL(mpic_msgr_get);
+
+void mpic_msgr_put(struct mpic_msgr *msgr)
+{
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(&msgr->lock, flags);
+ msgr->in_use = MSGR_FREE;
+ _mpic_msgr_disable(msgr);
+ raw_spin_unlock_irqrestore(&msgr->lock, flags);
+}
+EXPORT_SYMBOL_GPL(mpic_msgr_put);
+
+void mpic_msgr_enable(struct mpic_msgr *msgr)
+{
+ unsigned long flags;
+ u32 mer;
+
+ raw_spin_lock_irqsave(&msgr->lock, flags);
+ mer = _mpic_msgr_mer_read(msgr);
+ _mpic_msgr_mer_write(msgr, mer | (1 << msgr->num));
+ raw_spin_unlock_irqrestore(&msgr->lock, flags);
+}
+EXPORT_SYMBOL_GPL(mpic_msgr_enable);
+
+void mpic_msgr_disable(struct mpic_msgr *msgr)
+{
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(&msgr->lock, flags);
+ _mpic_msgr_disable(msgr);
+ raw_spin_unlock_irqrestore(&msgr->lock, flags);
+}
+EXPORT_SYMBOL_GPL(mpic_msgr_disable);
+
+/* The following three functions are used to compute the order and number of
+ * the message register blocks. They are clearly very inefficent. However,
+ * they are called *only* a few times during device initialization.
+ */
+static unsigned int mpic_msgr_number_of_blocks(void)
+{
+ unsigned int count;
+ struct device_node *aliases;
+
+ count = 0;
+ aliases = of_find_node_by_name(NULL, "aliases");
+
+ if (aliases) {
+ char buf[32];
+
+ for (;;) {
+ snprintf(buf, sizeof(buf), "mpic-msgr-block%d", count);
+ if (!of_find_property(aliases, buf, NULL))
+ break;
+
+ count += 1;
+ }
+ }
+
+ return count;
+}
+
+static unsigned int mpic_msgr_number_of_registers(void)
+{
+ return mpic_msgr_number_of_blocks() * MPIC_MSGR_REGISTERS_PER_BLOCK;
+}
+
+static int mpic_msgr_block_number(struct device_node *node)
+{
+ struct device_node *aliases;
+ unsigned int index, number_of_blocks;
+ char buf[64];
+
+ number_of_blocks = mpic_msgr_number_of_blocks();
+ aliases = of_find_node_by_name(NULL, "aliases");
+ if (!aliases)
+ return -1;
+
+ for (index = 0; index < number_of_blocks; ++index) {
+ struct property *prop;
+
+ snprintf(buf, sizeof(buf), "mpic-msgr-block%d", index);
+ prop = of_find_property(aliases, buf, NULL);
+ if (node == of_find_node_by_path(prop->value))
+ break;
+ }
+
+ return index == number_of_blocks ? -1 : index;
+}
+
+/* The probe function for a single message register block.
+ */
+static __devinit int mpic_msgr_probe(struct platform_device *dev)
+{
+ void __iomem *msgr_block_addr;
+ int block_number;
+ struct resource rsrc;
+ unsigned int i;
+ unsigned int irq_index;
+ struct device_node *np = dev->dev.of_node;
+ unsigned int receive_mask;
+ const unsigned int *prop;
+
+ if (!np) {
+ dev_err(&dev->dev, "Device OF-Node is NULL");
+ return -EFAULT;
+ }
+
+ /* Allocate the message register array upon the first device
+ * registered.
+ */
+ if (!mpic_msgrs) {
+ mpic_msgr_count = mpic_msgr_number_of_registers();
+ dev_info(&dev->dev, "Found %d message registers\n",
+ mpic_msgr_count);
+
+ mpic_msgrs = kzalloc(sizeof(struct mpic_msgr) * mpic_msgr_count,
+ GFP_KERNEL);
+ if (!mpic_msgrs) {
+ dev_err(&dev->dev,
+ "No memory for message register blocks\n");
+ return -ENOMEM;
+ }
+ }
+ dev_info(&dev->dev, "Of-device full name %s\n", np->full_name);
+
+ /* IO map the message register block. */
+ of_address_to_resource(np, 0, &rsrc);
+ msgr_block_addr = ioremap(rsrc.start, rsrc.end - rsrc.start);
+ if (!msgr_block_addr) {
+ dev_err(&dev->dev, "Failed to iomap MPIC message registers");
+ return -EFAULT;
+ }
+
+ /* Ensure the block has a defined order. */
+ block_number = mpic_msgr_block_number(np);
+ if (block_number < 0) {
+ dev_err(&dev->dev,
+ "Failed to find message register block alias\n");
+ return -ENODEV;
+ }
+ dev_info(&dev->dev, "Setting up message register block %d\n",
+ block_number);
+
+ /* Grab the receive mask which specifies what registers can receive
+ * interrupts.
+ */
+ prop = of_get_property(np, "mpic-msgr-receive-mask", NULL);
+ receive_mask = (prop) ? *prop : 0xF;
+
+ /* Build up the appropriate message register data structures. */
+ for (i = 0, irq_index = 0; i < MPIC_MSGR_REGISTERS_PER_BLOCK; ++i) {
+ struct mpic_msgr *msgr;
+ unsigned int reg_number;
+
+ msgr = kzalloc(sizeof(struct mpic_msgr), GFP_KERNEL);
+ if (!msgr) {
+ dev_err(&dev->dev, "No memory for message register\n");
+ return -ENOMEM;
+ }
+
+ reg_number = block_number * MPIC_MSGR_REGISTERS_PER_BLOCK + i;
+ msgr->base = msgr_block_addr + i * MPIC_MSGR_STRIDE;
+ msgr->mer = msgr->base + MPIC_MSGR_MER_OFFSET;
+ msgr->in_use = MSGR_FREE;
+ msgr->num = i;
+ raw_spin_lock_init(&msgr->lock);
+
+ if (receive_mask & (1 << i)) {
+ struct resource irq;
+
+ if (of_irq_to_resource(np, irq_index, &irq) == NO_IRQ) {
+ dev_err(&dev->dev,
+ "Missing interrupt specifier");
+ kfree(msgr);
+ return -EFAULT;
+ }
+ msgr->irq = irq.start;
+ irq_index += 1;
+ } else {
+ msgr->irq = NO_IRQ;
+ }
+
+ mpic_msgrs[reg_number] = msgr;
+ mpic_msgr_disable(msgr);
+ dev_info(&dev->dev, "Register %d initialized: irq %d\n",
+ reg_number, msgr->irq);
+
+ }
+
+ return 0;
+}
+
+static const struct of_device_id mpic_msgr_ids[] = {
+ {
+ .compatible = "fsl,mpic-v3.1-msgr",
+ .data = NULL,
+ },
+ {}
+};
+
+static struct platform_driver mpic_msgr_driver = {
+ .driver = {
+ .name = "mpic-msgr",
+ .owner = THIS_MODULE,
+ .of_match_table = mpic_msgr_ids,
+ },
+ .probe = mpic_msgr_probe,
+};
+
+static __init int mpic_msgr_init(void)
+{
+ return platform_driver_register(&mpic_msgr_driver);
+}
+subsys_initcall(mpic_msgr_init);
--
1.7.5.1
^ permalink raw reply related
* RE: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Li Yang-R58472 @ 2012-02-17 3:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Liu Qiang-B32616
Cc: linux-ide@vger.kernel.org, jgarzik@pobox.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1329439216.2892.36.camel@pasglop>
>I tried a debian install on the p5020ds here and I find SATA to be
>extremely slow, generating millions of interrupts. I think the defaults
>should be a lot more aggressive at coalescing.
The P5020 has a hardware problem with SATA, making it generate more interru=
pts than it should. A new revision of the silicon will fix it.
- Leo
^ permalink raw reply
* RE: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Benjamin Herrenschmidt @ 2012-02-17 3:17 UTC (permalink / raw)
To: Liu Qiang-B32616
Cc: linux-ide@vger.kernel.org, jgarzik@pobox.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <BCB48C05FCE8BC4D9E61E841ECBE6DB702B97D@039-SN2MPN1-013.039d.mgd.msft.net>
On Fri, 2012-02-17 at 01:54 +0000, Liu Qiang-B32616 wrote:
> The default will be set in a common interface fsl_sata_set_irq_coalescing when
> initialize the controller. This interface will check the range of intr count
> and ticks and make sure the values are reasonably.
Allright, but the current defaults are basically no coalescing right ?
> It's hard to find a aggressive value to adapt all scenarios, so I use echo to adjust
> the value. I remember P5020 have some performance issue, I will check it.
> BTW, which filesystem do you use? Ext2 is lower than ext4 because metadata is
> continuously wrote to disk. You can try ext4 or xfs.
ext3 at the moment, I plan to switch to ext4 when I finish that fsck
pass which is taking hours... I am not aware of the 5020 performance
issues, is this something documented and/or fixable ?
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Benjamin Herrenschmidt @ 2012-02-17 3:18 UTC (permalink / raw)
To: Li Yang-R58472
Cc: Liu Qiang-B32616, jgarzik@pobox.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-ide@vger.kernel.org
In-Reply-To: <94F013E7935FF44C83EBE7784D62AD3F0574273C@039-SN2MPN1-023.039d.mgd.msft.net>
On Fri, 2012-02-17 at 03:09 +0000, Li Yang-R58472 wrote:
> >I tried a debian install on the p5020ds here and I find SATA to be
> >extremely slow, generating millions of interrupts. I think the
> defaults
> >should be a lot more aggressive at coalescing.
>
> The P5020 has a hardware problem with SATA, making it generate more
> interrupts than it should. A new revision of the silicon will fix it.
Ok cool. With a bit of luck you guys can send me a new silicon when it's
available then :-) (The one in the board you got me seems to be in a
socket).
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Pan Jiafei-B37022 @ 2012-02-17 3:20 UTC (permalink / raw)
To: Liu Shengzhou-B36685, Benjamin Herrenschmidt
Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3F453DDFF675A64A89321A1F3528102170A6FF@039-SN1MPN1-004.039d.mgd.msft.net>
FYI, I once fixed this issue when backport P5020 BSP for WR Linux, The foll=
owing is the patch which I have submitted to linuxbj-internal.
From: linuxbj-internal-bounces@linux.freescale.net [mailto:linuxbj-internal=
-bounces@linux.freescale.net] On Behalf Of Pan Jiafei-B37022
Sent: Friday, December 16, 2011 12:49 PM
To: linuxbj-internal@linux.freescale.net
Cc: Pan Jiafei-B37022
Subject: [Linuxbj-internal] [PATCH] USB: ehci-fsl: Turn on cache snooping o=
n MPC8xxx
If a MPC8xxx was being used, 'have_sysif_regs' should be set and
it should setup cache snooping for all the 4GB space on both PPC32
and PPC64.
Signed-off-by: Pan Jiafei <Jiafei.Pan@freescale.com>
---
drivers/usb/host/ehci-fsl.c | 23 ++++++++++-------------
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 90534cc..ee14fa7 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -260,21 +260,18 @@ static void ehci_fsl_usb_setup(struct ehci_hcd *ehci)
if (pdata->have_sysif_regs) {
temp =3D in_be32(non_ehci + FSL_SOC_USB_CTRL);
out_be32(non_ehci + FSL_SOC_USB_CTRL, temp | 0x00000004);
- out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0000001b);
- }
-#if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
- /*
- * Turn on cache snooping hardware, since some PowerPC platforms
- * wholly rely on hardware to deal with cache coherent
- */
+ /*
+ * Turn on cache snooping hardware, since some PowerPC platforms
+ * wholly rely on hardware to deal with cache coherent
+ */
- /* Setup Snooping for all the 4GB space */
- /* SNOOP1 starts from 0x0, size 2G */
- out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
- /* SNOOP2 starts from 0x80000000, size 2G */
- out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
-#endif
+ /* Setup Snooping for all the 4GB space */
+ /* SNOOP1 starts from 0x0, size 2G */
+ out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
+ /* SNOOP2 starts from 0x80000000, size 2G */
+ out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_=
2GB);
+ }
if ((pdata->operating_mode =3D=3D FSL_USB2_DR_HOST) ||
(pdata->operating_mode =3D=3D FSL_USB2_DR_OTG))
--=20
1.7.5.1
> -----Original Message-----
> From: linuxppc-dev-bounces+jiafei.pan=3Dfreescale.com@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+jiafei.pan=3Dfreescale.com@lists.ozlabs.org]
> On Behalf Of Liu Shengzhou-B36685
> Sent: Friday, February 17, 2012 10:33 AM
> To: Benjamin Herrenschmidt
> Cc: linux-usb@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH] powerpc/usb: fix bug of kernel hang when
> initializing usb
>=20
>=20
> > -----Original Message-----
> > From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> > Sent: Friday, February 17, 2012 8:03 AM
> > To: Liu Shengzhou-B36685
> > Cc: linux-usb@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH] powerpc/usb: fix bug of kernel hang when
> > initializing usb
> >
> > On Fri, 2012-02-17 at 09:58 +1100, Benjamin Herrenschmidt wrote:
> > > On Thu, 2012-02-16 at 18:02 +0800, Shengzhou Liu wrote:
> > > > If USB UTMI PHY is not enable, writing to portsc register will
> > > > lead to kernel hang during boot up.
> > > >
> > > > Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> > > > ---
> > > > Apply for master branch of
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-
> > 2.6.git
> > > > Tested on P5020DS, the issue was reported by Benjamin Herrenschmidt=
.
> > >
> > > This fixes the hang, but sadly doesn't make USB work. I now get:
> >
> > .../...
> >
> > Ok, found the problem.
> >
> > First, the SDK kernel had a delay after setting that bit, I added that
> > back in. This is not what fixed it but it looks like the right thing
> > to do, though please, use msleep rather than udelay here if possible
> > (not in atomic context).
> >
> > Then, the real culprit is (CC'ing Kumar and Scott to figure out why)
> > this statement:
> >
> > #if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
> > /*
> > * Turn on cache snooping hardware, since some PowerPC platforms
> > * wholly rely on hardware to deal with cache coherent
> > */
> >
> > /* Setup Snooping for all the 4GB space */
> > /* SNOOP1 starts from 0x0, size 2G */
> > out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
> > /* SNOOP2 starts from 0x80000000, size 2G */
> > out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 |
> SNOOP_SIZE_2GB);
> > #endif
> >
> > I'm building a 64-bit kernel so this isn't compiled and it looks like
> > the EHCI is thus not snooping.
> >
> > By removing the defined(CONFIG_PPC32) part of the statement, my
> > problem goes away.
> >
> > Cheers,
> > Ben.
> >
> >
>=20
> [Shengzhou] I tested the patch with 32bit P5020DS, USB worked well. Not
> tested with 64-bit kernel.
> Glad to you had found the problem in case of 64-bit, thanks!
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply related
* RE: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Liu Qiang-B32616 @ 2012-02-17 3:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-ide@vger.kernel.org, jgarzik@pobox.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1329448660.2892.42.camel@pasglop>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBIZXJyZW5zY2ht
aWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnXQ0KPiBTZW50OiBGcmlkYXksIEZl
YnJ1YXJ5IDE3LCAyMDEyIDExOjE4IEFNDQo+IFRvOiBMaXUgUWlhbmctQjMyNjE2DQo+IENjOiBq
Z2FyemlrQHBvYm94LmNvbTsgbGludXgtaWRlQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtDQo+
IGRldkBsaXN0cy5vemxhYnMub3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnDQo+IFN1
YmplY3Q6IFJFOiBbUEFUQ0ggVjIgUkVTRU5EXSBmc2wtc2F0YTogSS9PIGxvYWQgYmFsYW5jaW5n
DQo+IA0KPiBPbiBGcmksIDIwMTItMDItMTcgYXQgMDE6NTQgKzAwMDAsIExpdSBRaWFuZy1CMzI2
MTYgd3JvdGU6DQo+ID4gVGhlIGRlZmF1bHQgd2lsbCBiZSBzZXQgaW4gYSBjb21tb24gaW50ZXJm
YWNlDQo+ID4gZnNsX3NhdGFfc2V0X2lycV9jb2FsZXNjaW5nIHdoZW4gaW5pdGlhbGl6ZSB0aGUg
Y29udHJvbGxlci4gVGhpcw0KPiA+IGludGVyZmFjZSB3aWxsIGNoZWNrIHRoZSByYW5nZSBvZiBp
bnRyIGNvdW50IGFuZCB0aWNrcyBhbmQgbWFrZSBzdXJlDQo+IHRoZSB2YWx1ZXMgYXJlIHJlYXNv
bmFibHkuDQo+IA0KPiBBbGxyaWdodCwgYnV0IHRoZSBjdXJyZW50IGRlZmF1bHRzIGFyZSBiYXNp
Y2FsbHkgbm8gY29hbGVzY2luZyByaWdodCA/DQo+IA0KPiA+IEl0J3MgaGFyZCB0byBmaW5kIGEg
YWdncmVzc2l2ZSB2YWx1ZSB0byBhZGFwdCBhbGwgc2NlbmFyaW9zLCBzbyBJIHVzZQ0KPiA+IGVj
aG8gdG8gYWRqdXN0IHRoZSB2YWx1ZS4gSSByZW1lbWJlciBQNTAyMCBoYXZlIHNvbWUgcGVyZm9y
bWFuY2UgaXNzdWUsDQo+IEkgd2lsbCBjaGVjayBpdC4NCj4gPiBCVFcsIHdoaWNoIGZpbGVzeXN0
ZW0gZG8geW91IHVzZT8gRXh0MiBpcyBsb3dlciB0aGFuIGV4dDQgYmVjYXVzZQ0KPiA+IG1ldGFk
YXRhIGlzIGNvbnRpbnVvdXNseSB3cm90ZSB0byBkaXNrLiBZb3UgY2FuIHRyeSBleHQ0IG9yIHhm
cy4NCj4gDQo+IGV4dDMgYXQgdGhlIG1vbWVudCwgSSBwbGFuIHRvIHN3aXRjaCB0byBleHQ0IHdo
ZW4gSSBmaW5pc2ggdGhhdCBmc2NrIHBhc3MNCj4gd2hpY2ggaXMgdGFraW5nIGhvdXJzLi4uIEkg
YW0gbm90IGF3YXJlIG9mIHRoZSA1MDIwIHBlcmZvcm1hbmNlIGlzc3VlcywNCj4gaXMgdGhpcyBz
b21ldGhpbmcgZG9jdW1lbnRlZCBhbmQvb3IgZml4YWJsZSA/DQo+IA0KDQpNeSBwYXRjaCBtYXkg
bm90IG1lZXQgeW91ciByZXF1aXJlbWVudDooDQpGb3IgeW91ciBwZXJmb3JtYW5jZSByZXF1aXJl
bWVudCwgSSBzdWdnZXN0IHVzZSBleHQ0IGZpbGVzeXN0ZW0gYW5kIFNTRC4NCg0KVGhhbmtzLg0K
DQo+IENoZWVycywNCj4gQmVuLg0KPiANCj4gDQoNCg==
^ permalink raw reply
* RE: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Benjamin Herrenschmidt @ 2012-02-17 3:42 UTC (permalink / raw)
To: Pan Jiafei-B37022
Cc: Liu Shengzhou-B36685, linux-usb@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F9F958A64F25C4DA463F3D6931E533140828E@039-SN1MPN1-003.039d.mgd.msft.net>
On Fri, 2012-02-17 at 03:20 +0000, Pan Jiafei-B37022 wrote:
> FYI, I once fixed this issue when backport P5020 BSP for WR Linux, The
> following is the patch which I have submitted to linuxbj-internal.
Should I just apply this to upstream ?
Cheers,
Ben.
> From: linuxbj-internal-bounces@linux.freescale.net [mailto:linuxbj-internal-bounces@linux.freescale.net] On Behalf Of Pan Jiafei-B37022
> Sent: Friday, December 16, 2011 12:49 PM
> To: linuxbj-internal@linux.freescale.net
> Cc: Pan Jiafei-B37022
> Subject: [Linuxbj-internal] [PATCH] USB: ehci-fsl: Turn on cache snooping on MPC8xxx
>
> If a MPC8xxx was being used, 'have_sysif_regs' should be set and
> it should setup cache snooping for all the 4GB space on both PPC32
> and PPC64.
>
> Signed-off-by: Pan Jiafei <Jiafei.Pan@freescale.com>
> ---
> drivers/usb/host/ehci-fsl.c | 23 ++++++++++-------------
> 1 files changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
> index 90534cc..ee14fa7 100644
> --- a/drivers/usb/host/ehci-fsl.c
> +++ b/drivers/usb/host/ehci-fsl.c
> @@ -260,21 +260,18 @@ static void ehci_fsl_usb_setup(struct ehci_hcd *ehci)
> if (pdata->have_sysif_regs) {
> temp = in_be32(non_ehci + FSL_SOC_USB_CTRL);
> out_be32(non_ehci + FSL_SOC_USB_CTRL, temp | 0x00000004);
> - out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0000001b);
> - }
>
> -#if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
> - /*
> - * Turn on cache snooping hardware, since some PowerPC platforms
> - * wholly rely on hardware to deal with cache coherent
> - */
> + /*
> + * Turn on cache snooping hardware, since some PowerPC platforms
> + * wholly rely on hardware to deal with cache coherent
> + */
>
> - /* Setup Snooping for all the 4GB space */
> - /* SNOOP1 starts from 0x0, size 2G */
> - out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
> - /* SNOOP2 starts from 0x80000000, size 2G */
> - out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
> -#endif
> + /* Setup Snooping for all the 4GB space */
> + /* SNOOP1 starts from 0x0, size 2G */
> + out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
> + /* SNOOP2 starts from 0x80000000, size 2G */
> + out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
> + }
>
> if ((pdata->operating_mode == FSL_USB2_DR_HOST) ||
> (pdata->operating_mode == FSL_USB2_DR_OTG))
^ permalink raw reply
* RE: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Pan Jiafei-B37022 @ 2012-02-17 3:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Liu Shengzhou-B36685, linux-usb@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1329450178.2892.50.camel@pasglop>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gU2VudDogRnJpZGF5
LCBGZWJydWFyeSAxNywgMjAxMiAxMTo0MyBBTQ0KPiBUbzogUGFuIEppYWZlaS1CMzcwMjINCj4g
Q2M6IExpdSBTaGVuZ3pob3UtQjM2Njg1OyBsaW51eC11c2JAdmdlci5rZXJuZWwub3JnOyBsaW51
eHBwYy0NCj4gZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUkU6IFtQQVRDSF0gcG93
ZXJwYy91c2I6IGZpeCBidWcgb2Yga2VybmVsIGhhbmcgd2hlbg0KPiBpbml0aWFsaXppbmcgdXNi
DQo+IA0KPiBPbiBGcmksIDIwMTItMDItMTcgYXQgMDM6MjAgKzAwMDAsIFBhbiBKaWFmZWktQjM3
MDIyIHdyb3RlOg0KPiA+IEZZSSwgSSBvbmNlIGZpeGVkIHRoaXMgaXNzdWUgd2hlbiBiYWNrcG9y
dCBQNTAyMCBCU1AgZm9yIFdSIExpbnV4LCBUaGUNCj4gPiBmb2xsb3dpbmcgaXMgdGhlIHBhdGNo
IHdoaWNoIEkgaGF2ZSBzdWJtaXR0ZWQgdG8gbGludXhiai1pbnRlcm5hbC4NCj4gDQo+IFNob3Vs
ZCBJIGp1c3QgYXBwbHkgdGhpcyB0byB1cHN0cmVhbSA/DQo+IA0KPiBDaGVlcnMsDQo+IEJlbi4N
Cj4gDQpbUGFuIEppYWZlaS1CMzcwMjJdIA0KRmVlbCBmcmVlIHRvIGFwcGx5IHRoaXMgdG8gdXBz
dHJlYW0sIHRoYW5rcw0KDQpCZXN0IFJlZ2FyZHMuDQpKaWFmZWkNCg0KPiA+IEZyb206IGxpbnV4
YmotaW50ZXJuYWwtYm91bmNlc0BsaW51eC5mcmVlc2NhbGUubmV0DQo+ID4gW21haWx0bzpsaW51
eGJqLWludGVybmFsLWJvdW5jZXNAbGludXguZnJlZXNjYWxlLm5ldF0gT24gQmVoYWxmIE9mIFBh
bg0KPiA+IEppYWZlaS1CMzcwMjINCj4gPiBTZW50OiBGcmlkYXksIERlY2VtYmVyIDE2LCAyMDEx
IDEyOjQ5IFBNDQo+ID4gVG86IGxpbnV4YmotaW50ZXJuYWxAbGludXguZnJlZXNjYWxlLm5ldA0K
PiA+IENjOiBQYW4gSmlhZmVpLUIzNzAyMg0KPiA+IFN1YmplY3Q6IFtMaW51eGJqLWludGVybmFs
XSBbUEFUQ0hdIFVTQjogZWhjaS1mc2w6IFR1cm4gb24gY2FjaGUNCj4gPiBzbm9vcGluZyBvbiBN
UEM4eHh4DQo+ID4NCj4gPiBJZiBhIE1QQzh4eHggd2FzIGJlaW5nIHVzZWQsICdoYXZlX3N5c2lm
X3JlZ3MnIHNob3VsZCBiZSBzZXQgYW5kIGl0DQo+ID4gc2hvdWxkIHNldHVwIGNhY2hlIHNub29w
aW5nIGZvciBhbGwgdGhlIDRHQiBzcGFjZSBvbiBib3RoIFBQQzMyIGFuZA0KPiA+IFBQQzY0Lg0K
PiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogUGFuIEppYWZlaSA8SmlhZmVpLlBhbkBmcmVlc2NhbGUu
Y29tPg0KPiA+IC0tLQ0KPiA+IGRyaXZlcnMvdXNiL2hvc3QvZWhjaS1mc2wuYyB8ICAgMjMgKysr
KysrKysrKy0tLS0tLS0tLS0tLS0NCj4gPiAxIGZpbGVzIGNoYW5nZWQsIDEwIGluc2VydGlvbnMo
KyksIDEzIGRlbGV0aW9ucygtKQ0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvdXNiL2hv
c3QvZWhjaS1mc2wuYyBiL2RyaXZlcnMvdXNiL2hvc3QvZWhjaS1mc2wuYw0KPiA+IGluZGV4IDkw
NTM0Y2MuLmVlMTRmYTcgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVycy91c2IvaG9zdC9laGNpLWZz
bC5jDQo+ID4gKysrIGIvZHJpdmVycy91c2IvaG9zdC9laGNpLWZzbC5jDQo+ID4gQEAgLTI2MCwy
MSArMjYwLDE4IEBAIHN0YXRpYyB2b2lkIGVoY2lfZnNsX3VzYl9zZXR1cChzdHJ1Y3QgZWhjaV9o
Y2QNCj4gKmVoY2kpDQo+ID4gICAgIGlmIChwZGF0YS0+aGF2ZV9zeXNpZl9yZWdzKSB7DQo+ID4g
ICAgICAgICAgIHRlbXAgPSBpbl9iZTMyKG5vbl9laGNpICsgRlNMX1NPQ19VU0JfQ1RSTCk7DQo+
ID4gICAgICAgICAgIG91dF9iZTMyKG5vbl9laGNpICsgRlNMX1NPQ19VU0JfQ1RSTCwgdGVtcCB8
IDB4MDAwMDAwMDQpOw0KPiA+IC0gICAgICAgICAgb3V0X2JlMzIobm9uX2VoY2kgKyBGU0xfU09D
X1VTQl9TTk9PUDEsIDB4MDAwMDAwMWIpOw0KPiA+IC0gICAgfQ0KPiA+DQo+ID4gLSNpZiBkZWZp
bmVkKENPTkZJR19QUEMzMikgJiYgIWRlZmluZWQoQ09ORklHX05PVF9DT0hFUkVOVF9DQUNIRSkN
Cj4gPiAtICAgIC8qDQo+ID4gLSAgICAqIFR1cm4gb24gY2FjaGUgc25vb3BpbmcgaGFyZHdhcmUs
IHNpbmNlIHNvbWUgUG93ZXJQQyBwbGF0Zm9ybXMNCj4gPiAtICAgICogd2hvbGx5IHJlbHkgb24g
aGFyZHdhcmUgdG8gZGVhbCB3aXRoIGNhY2hlIGNvaGVyZW50DQo+ID4gLSAgICAqLw0KPiA+ICsg
ICAgICAgICAgLyoNCj4gPiArICAgICAgICAgICogVHVybiBvbiBjYWNoZSBzbm9vcGluZyBoYXJk
d2FyZSwgc2luY2Ugc29tZSBQb3dlclBDDQo+IHBsYXRmb3Jtcw0KPiA+ICsgICAgICAgICAgKiB3
aG9sbHkgcmVseSBvbiBoYXJkd2FyZSB0byBkZWFsIHdpdGggY2FjaGUgY29oZXJlbnQNCj4gPiAr
ICAgICAgICAgICovDQo+ID4NCj4gPiAtICAgIC8qIFNldHVwIFNub29waW5nIGZvciBhbGwgdGhl
IDRHQiBzcGFjZSAqLw0KPiA+IC0gICAgLyogU05PT1AxIHN0YXJ0cyBmcm9tIDB4MCwgc2l6ZSAy
RyAqLw0KPiA+IC0gICAgb3V0X2JlMzIobm9uX2VoY2kgKyBGU0xfU09DX1VTQl9TTk9PUDEsIDB4
MCB8IFNOT09QX1NJWkVfMkdCKTsNCj4gPiAtICAgIC8qIFNOT09QMiBzdGFydHMgZnJvbSAweDgw
MDAwMDAwLCBzaXplIDJHICovDQo+ID4gLSAgICBvdXRfYmUzMihub25fZWhjaSArIEZTTF9TT0Nf
VVNCX1NOT09QMiwgMHg4MDAwMDAwMCB8DQo+IFNOT09QX1NJWkVfMkdCKTsNCj4gPiAtI2VuZGlm
DQo+ID4gKyAgICAgICAgICAvKiBTZXR1cCBTbm9vcGluZyBmb3IgYWxsIHRoZSA0R0Igc3BhY2Ug
Ki8NCj4gPiArICAgICAgICAgIC8qIFNOT09QMSBzdGFydHMgZnJvbSAweDAsIHNpemUgMkcgKi8N
Cj4gPiArICAgICAgICAgIG91dF9iZTMyKG5vbl9laGNpICsgRlNMX1NPQ19VU0JfU05PT1AxLCAw
eDAgfA0KPiBTTk9PUF9TSVpFXzJHQik7DQo+ID4gKyAgICAgICAgICAvKiBTTk9PUDIgc3RhcnRz
IGZyb20gMHg4MDAwMDAwMCwgc2l6ZSAyRyAqLw0KPiA+ICsgICAgICAgICAgb3V0X2JlMzIobm9u
X2VoY2kgKyBGU0xfU09DX1VTQl9TTk9PUDIsIDB4ODAwMDAwMDAgfA0KPiBTTk9PUF9TSVpFXzJH
Qik7DQo+ID4gKyAgICB9DQo+ID4NCj4gPiAgICAgIGlmICgocGRhdGEtPm9wZXJhdGluZ19tb2Rl
ID09IEZTTF9VU0IyX0RSX0hPU1QpIHx8DQo+ID4gICAgICAgICAgICAgICAgKHBkYXRhLT5vcGVy
YXRpbmdfbW9kZSA9PSBGU0xfVVNCMl9EUl9PVEcpKQ0KPiANCj4gDQoNCg==
^ permalink raw reply
* RE: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Pan Jiafei-B37022 @ 2012-02-17 3:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Liu Shengzhou-B36685, linux-usb@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1329450178.2892.50.camel@pasglop>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBIZXJyZW5zY2ht
aWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnXQ0KPiBTZW50OiBGcmlkYXksIEZl
YnJ1YXJ5IDE3LCAyMDEyIDExOjQzIEFNDQo+IFRvOiBQYW4gSmlhZmVpLUIzNzAyMg0KPiBDYzog
TGl1IFNoZW5nemhvdS1CMzY2ODU7IGxpbnV4LXVzYkB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBj
LQ0KPiBkZXZAbGlzdHMub3psYWJzLm9yZw0KPiBTdWJqZWN0OiBSRTogW1BBVENIXSBwb3dlcnBj
L3VzYjogZml4IGJ1ZyBvZiBrZXJuZWwgaGFuZyB3aGVuDQo+IGluaXRpYWxpemluZyB1c2INCj4g
DQo+IE9uIEZyaSwgMjAxMi0wMi0xNyBhdCAwMzoyMCArMDAwMCwgUGFuIEppYWZlaS1CMzcwMjIg
d3JvdGU6DQo+ID4gRllJLCBJIG9uY2UgZml4ZWQgdGhpcyBpc3N1ZSB3aGVuIGJhY2twb3J0IFA1
MDIwIEJTUCBmb3IgV1IgTGludXgsIFRoZQ0KPiA+IGZvbGxvd2luZyBpcyB0aGUgcGF0Y2ggd2hp
Y2ggSSBoYXZlIHN1Ym1pdHRlZCB0byBsaW51eGJqLWludGVybmFsLg0KPiANCj4gU2hvdWxkIEkg
anVzdCBhcHBseSB0aGlzIHRvIHVwc3RyZWFtID8NCj4gDQo+IENoZWVycywNCj4gQmVuLg0KPiAN
CltQYW4gSmlhZmVpLUIzNzAyMl0gDQpPaywgdGhhbmtzLCBJIHdpbGwgcmVzZW5kIHRoZSBwYXRj
aCBmb3JtYWxseSENCg0KQmVzdCBSZWdhcmRzLg0KSmlhZmVpLg0KDQo+ID4gRnJvbTogbGludXhi
ai1pbnRlcm5hbC1ib3VuY2VzQGxpbnV4LmZyZWVzY2FsZS5uZXQNCj4gPiBbbWFpbHRvOmxpbnV4
YmotaW50ZXJuYWwtYm91bmNlc0BsaW51eC5mcmVlc2NhbGUubmV0XSBPbiBCZWhhbGYgT2YgUGFu
DQo+ID4gSmlhZmVpLUIzNzAyMg0KPiA+IFNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMTYsIDIwMTEg
MTI6NDkgUE0NCj4gPiBUbzogbGludXhiai1pbnRlcm5hbEBsaW51eC5mcmVlc2NhbGUubmV0DQo+
ID4gQ2M6IFBhbiBKaWFmZWktQjM3MDIyDQo+ID4gU3ViamVjdDogW0xpbnV4YmotaW50ZXJuYWxd
IFtQQVRDSF0gVVNCOiBlaGNpLWZzbDogVHVybiBvbiBjYWNoZQ0KPiA+IHNub29waW5nIG9uIE1Q
Qzh4eHgNCj4gPg0KPiA+IElmIGEgTVBDOHh4eCB3YXMgYmVpbmcgdXNlZCwgJ2hhdmVfc3lzaWZf
cmVncycgc2hvdWxkIGJlIHNldCBhbmQgaXQNCj4gPiBzaG91bGQgc2V0dXAgY2FjaGUgc25vb3Bp
bmcgZm9yIGFsbCB0aGUgNEdCIHNwYWNlIG9uIGJvdGggUFBDMzIgYW5kDQo+ID4gUFBDNjQuDQo+
ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBQYW4gSmlhZmVpIDxKaWFmZWkuUGFuQGZyZWVzY2FsZS5j
b20+DQo+ID4gLS0tDQo+ID4gZHJpdmVycy91c2IvaG9zdC9laGNpLWZzbC5jIHwgICAyMyArKysr
KysrKysrLS0tLS0tLS0tLS0tLQ0KPiA+IDEgZmlsZXMgY2hhbmdlZCwgMTAgaW5zZXJ0aW9ucygr
KSwgMTMgZGVsZXRpb25zKC0pDQo+ID4NCj4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy91c2IvaG9z
dC9laGNpLWZzbC5jIGIvZHJpdmVycy91c2IvaG9zdC9laGNpLWZzbC5jDQo+ID4gaW5kZXggOTA1
MzRjYy4uZWUxNGZhNyAxMDA2NDQNCj4gPiAtLS0gYS9kcml2ZXJzL3VzYi9ob3N0L2VoY2ktZnNs
LmMNCj4gPiArKysgYi9kcml2ZXJzL3VzYi9ob3N0L2VoY2ktZnNsLmMNCj4gPiBAQCAtMjYwLDIx
ICsyNjAsMTggQEAgc3RhdGljIHZvaWQgZWhjaV9mc2xfdXNiX3NldHVwKHN0cnVjdCBlaGNpX2hj
ZA0KPiAqZWhjaSkNCj4gPiAgICAgaWYgKHBkYXRhLT5oYXZlX3N5c2lmX3JlZ3MpIHsNCj4gPiAg
ICAgICAgICAgdGVtcCA9IGluX2JlMzIobm9uX2VoY2kgKyBGU0xfU09DX1VTQl9DVFJMKTsNCj4g
PiAgICAgICAgICAgb3V0X2JlMzIobm9uX2VoY2kgKyBGU0xfU09DX1VTQl9DVFJMLCB0ZW1wIHwg
MHgwMDAwMDAwNCk7DQo+ID4gLSAgICAgICAgICBvdXRfYmUzMihub25fZWhjaSArIEZTTF9TT0Nf
VVNCX1NOT09QMSwgMHgwMDAwMDAxYik7DQo+ID4gLSAgICB9DQo+ID4NCj4gPiAtI2lmIGRlZmlu
ZWQoQ09ORklHX1BQQzMyKSAmJiAhZGVmaW5lZChDT05GSUdfTk9UX0NPSEVSRU5UX0NBQ0hFKQ0K
PiA+IC0gICAgLyoNCj4gPiAtICAgICogVHVybiBvbiBjYWNoZSBzbm9vcGluZyBoYXJkd2FyZSwg
c2luY2Ugc29tZSBQb3dlclBDIHBsYXRmb3Jtcw0KPiA+IC0gICAgKiB3aG9sbHkgcmVseSBvbiBo
YXJkd2FyZSB0byBkZWFsIHdpdGggY2FjaGUgY29oZXJlbnQNCj4gPiAtICAgICovDQo+ID4gKyAg
ICAgICAgICAvKg0KPiA+ICsgICAgICAgICAgKiBUdXJuIG9uIGNhY2hlIHNub29waW5nIGhhcmR3
YXJlLCBzaW5jZSBzb21lIFBvd2VyUEMNCj4gcGxhdGZvcm1zDQo+ID4gKyAgICAgICAgICAqIHdo
b2xseSByZWx5IG9uIGhhcmR3YXJlIHRvIGRlYWwgd2l0aCBjYWNoZSBjb2hlcmVudA0KPiA+ICsg
ICAgICAgICAgKi8NCj4gPg0KPiA+IC0gICAgLyogU2V0dXAgU25vb3BpbmcgZm9yIGFsbCB0aGUg
NEdCIHNwYWNlICovDQo+ID4gLSAgICAvKiBTTk9PUDEgc3RhcnRzIGZyb20gMHgwLCBzaXplIDJH
ICovDQo+ID4gLSAgICBvdXRfYmUzMihub25fZWhjaSArIEZTTF9TT0NfVVNCX1NOT09QMSwgMHgw
IHwgU05PT1BfU0laRV8yR0IpOw0KPiA+IC0gICAgLyogU05PT1AyIHN0YXJ0cyBmcm9tIDB4ODAw
MDAwMDAsIHNpemUgMkcgKi8NCj4gPiAtICAgIG91dF9iZTMyKG5vbl9laGNpICsgRlNMX1NPQ19V
U0JfU05PT1AyLCAweDgwMDAwMDAwIHwNCj4gU05PT1BfU0laRV8yR0IpOw0KPiA+IC0jZW5kaWYN
Cj4gPiArICAgICAgICAgIC8qIFNldHVwIFNub29waW5nIGZvciBhbGwgdGhlIDRHQiBzcGFjZSAq
Lw0KPiA+ICsgICAgICAgICAgLyogU05PT1AxIHN0YXJ0cyBmcm9tIDB4MCwgc2l6ZSAyRyAqLw0K
PiA+ICsgICAgICAgICAgb3V0X2JlMzIobm9uX2VoY2kgKyBGU0xfU09DX1VTQl9TTk9PUDEsIDB4
MCB8DQo+IFNOT09QX1NJWkVfMkdCKTsNCj4gPiArICAgICAgICAgIC8qIFNOT09QMiBzdGFydHMg
ZnJvbSAweDgwMDAwMDAwLCBzaXplIDJHICovDQo+ID4gKyAgICAgICAgICBvdXRfYmUzMihub25f
ZWhjaSArIEZTTF9TT0NfVVNCX1NOT09QMiwgMHg4MDAwMDAwMCB8DQo+IFNOT09QX1NJWkVfMkdC
KTsNCj4gPiArICAgIH0NCj4gPg0KPiA+ICAgICAgaWYgKChwZGF0YS0+b3BlcmF0aW5nX21vZGUg
PT0gRlNMX1VTQjJfRFJfSE9TVCkgfHwNCj4gPiAgICAgICAgICAgICAgICAocGRhdGEtPm9wZXJh
dGluZ19tb2RlID09IEZTTF9VU0IyX0RSX09URykpDQo+IA0KPiANCg0K
^ permalink raw reply
* RE: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Li Yang-R58472 @ 2012-02-17 4:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <EDB74FED-002D-4F94-B134-995BFB4C0A6B@kernel.crashing.org>
>Subject: Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents
>PHYS_64BIT from configurable
>
>
>On Feb 16, 2012, at 6:10 AM, Li Yang wrote:
>
>> Fix the problem that large physical address support cannot be disabled
>> when some platforms which only provides 36-bit support are selected.
>> According to the philosophy of kernel config enabling a platform
>> support doesn't mean the kernel is only running on that platform.
>> Remove the auto selection of PHYS_64BIT option for these platforms.
>> They will need to use a 36bit default config that selects PHYS_64BIT
>> explicitly.
>>
>> The reason why we need to keep PHYS_64BIT option configurable is that
>> enabling it cause negative performance impact on various aspects like
>> TLB miss and physical address manipulating. We should not enable it
>> unless really needed, e.g. use large memory of 4GB or bigger.
>>
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> ---
>> arch/powerpc/platforms/85xx/Kconfig | 6 ------
>> 1 files changed, 0 insertions(+), 6 deletions(-)
>
>Nak, this isn't correct.
>
>For some of these platforms like P2041RDB, P3041DS, P3060QDS, P4080DS, &
>P5020DS only a 36-bit physical address map is supported by u-boot and the
>device tree. This was a decision that was made to NOT support 32-bit
>address map for these boards and accept the performance implication of it
>to reduce the # of builds, etc.
Ok. Although personally I don't think # of builds matters that much.
>
>Additionally, outside of maybe P2041RDB I believe the majority of these
>boards ship with 4G of DDR (but that off the top of my head) and thus
>require the 36-bit / PHYS_64BIT support to be enabled.
I know that current support of DPAA boards requires 36-bit. But I don't th=
ink they need to select the PHYS_64BIT option directly and make it not conf=
igurable. It's conflicting with the logic that enabling a platform support=
doesn't mean the kernel is only running on that platform. Btw: what's you=
r recommendations on solving this?
- Leo
^ permalink raw reply
* linux-next: build failure after merge of the final tree (akpm tree related)
From: Stephen Rothwell @ 2012-02-17 5:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-next, ppc-dev, linux-kernel, H. Peter Anvin
[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]
Hi Andrew,
After merging the final tree, today's linux-next build (powerpc
allnoconfig) failed like this:
In file included from include/linux/posix_types.h:47:0,
from include/linux/types.h:17,
from include/linux/page-flags.h:8,
from kernel/bounds.c:9:
arch/powerpc/include/asm/posix_types.h:15:14: error: conflicting types for '__kernel_size_t'
arch/powerpc/include/asm/posix_types.h:14:22: note: previous declaration of '__kernel_size_t' was here
In file included from include/linux/page-flags.h:8:0,
from kernel/bounds.c:9:
include/linux/types.h:68:1: error: unknown type name '__kernel_ssize_t'
Caused by commit a9dbe86e5995 ("powerpc: use generic posix_types.h").
This think was pointed out a couple of days ago, so maybe Andrew needs a
newer version of the patch.
I added this fix patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 17 Feb 2012 16:25:48 +1100
Subject: [PATCH] powerpc: use generic posix_types.h fix
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/include/asm/posix_types.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/posix_types.h b/arch/powerpc/include/asm/posix_types.h
index 1fbe027f..f139325 100644
--- a/arch/powerpc/include/asm/posix_types.h
+++ b/arch/powerpc/include/asm/posix_types.h
@@ -12,7 +12,7 @@ typedef unsigned long __kernel_old_dev_t;
#define __kernel_old_dev_t __kernel_old_dev_t
#else
typedef unsigned int __kernel_size_t;
-typedef int __kernel_size_t;
+typedef int __kernel_ssize_t;
typedef long __kernel_ptrdiff_t;
#define __kernel_size_t __kernel_size_t
--
1.7.9
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [PATCH v1 0/4][makedumpfile] vmalloc translation support for PPC32
From: Suzuki K. Poulose @ 2012-02-17 5:55 UTC (permalink / raw)
To: Atsushi Kumagai; +Cc: linux ppc dev, kexec
In-Reply-To: <20120217093220.0c2993a1.kumagai-atsushi@mxc.nes.nec.co.jp>
On 02/17/2012 06:02 AM, Atsushi Kumagai wrote:
> Hi, Suzuki
>
> On Thu, 16 Feb 2012 09:05:17 +0530
> "Suzuki K. Poulose"<suzuki@in.ibm.com> wrote:
>
>> The series introduces an infrastructure to define platform specific
>> bits for page translation for PPC and PPC44x support for vmalloc
>> translation.
>>
>> This is similar to what we have implemented for Crash-utility.
>>
>> The patches are based makedumpfile-1.4.2 + PPC32 support patches
>> which is queued in for 1.4.3.
>>
>> ---
>>
>> Suzuki K. Poulose (4):
>> [makedumpfile][ppc] PPC44x page translation definitions
>> [makedumpfile][ppc] Define platform descriptors for page translation
>> [makedumpfile][ppc] Generic vmalloc translation support
>> [makedumpfile] Add read_string routine
>>
>>
>> arch/ppc.c | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>> makedumpfile.c | 14 +++++++
>> makedumpfile.h | 21 +++++++++++
>> 3 files changed, 139 insertions(+), 4 deletions(-)
>>
>> --
>> Suzuki Poulose
>
> Could you tell me what kind of data is stored in vmalloc region in PPC ?
> I want to estimate importance of your patches for makedumpfile.
I know at least the modules are loaded in the vmalloc'd region. I have
Cc'ed linux-ppc dev. We should be able to get enough info from the experts here.
Josh / Kumar / Others,
Could you please let us know your thoughts ?
Thanks
Suzuki
^ permalink raw reply
* [PATCH] USB: ehci-fsl: Turn on cache snooping on MPC8xxx
From: Pan Jiafei @ 2012-02-17 5:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-usb, Pan Jiafei
If a MPC8xxx was being used, 'have_sysif_regs' should be set and
it should setup cache snooping for all the 4GB space on both PPC32
and PPC64.
Signed-off-by: Pan Jiafei <Jiafei.Pan@freescale.com>
---
drivers/usb/host/ehci-fsl.c | 23 ++++++++++-------------
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index c26a82e..8327d3e 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -252,21 +252,18 @@ static int ehci_fsl_usb_setup(struct ehci_hcd *ehci)
if (pdata->have_sysif_regs) {
temp = in_be32(non_ehci + FSL_SOC_USB_CTRL);
out_be32(non_ehci + FSL_SOC_USB_CTRL, temp | 0x00000004);
- out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0000001b);
- }
-#if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
- /*
- * Turn on cache snooping hardware, since some PowerPC platforms
- * wholly rely on hardware to deal with cache coherent
- */
+ /*
+ * Turn on cache snooping hardware, since some PowerPC platforms
+ * wholly rely on hardware to deal with cache coherent
+ */
- /* Setup Snooping for all the 4GB space */
- /* SNOOP1 starts from 0x0, size 2G */
- out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
- /* SNOOP2 starts from 0x80000000, size 2G */
- out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
-#endif
+ /* Setup Snooping for all the 4GB space */
+ /* SNOOP1 starts from 0x0, size 2G */
+ out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
+ /* SNOOP2 starts from 0x80000000, size 2G */
+ out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
+ }
if ((pdata->operating_mode == FSL_USB2_DR_HOST) ||
(pdata->operating_mode == FSL_USB2_DR_OTG))
--
1.7.5.1
^ permalink raw reply related
* Re: linux-next: build failure after merge of the final tree (akpm tree related)
From: Benjamin Herrenschmidt @ 2012-02-17 6:07 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next, ppc-dev, linux-kernel, H. Peter Anvin
In-Reply-To: <20120217163057.8af53b853b36365b7fff203c@canb.auug.org.au>
On Fri, 2012-02-17 at 16:30 +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the final tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
>
> In file included from include/linux/posix_types.h:47:0,
> from include/linux/types.h:17,
> from include/linux/page-flags.h:8,
> from kernel/bounds.c:9:
> arch/powerpc/include/asm/posix_types.h:15:14: error: conflicting types for '__kernel_size_t'
> arch/powerpc/include/asm/posix_types.h:14:22: note: previous declaration of '__kernel_size_t' was here
> In file included from include/linux/page-flags.h:8:0,
> from kernel/bounds.c:9:
> include/linux/types.h:68:1: error: unknown type name '__kernel_ssize_t'
>
> Caused by commit a9dbe86e5995 ("powerpc: use generic posix_types.h").
>
> This think was pointed out a couple of days ago, so maybe Andrew needs a
> newer version of the patch.
Yes, I pointed that out to Peter a while back, maybe it got lost ...
Cheers,
Ben.
> I added this fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 17 Feb 2012 16:25:48 +1100
> Subject: [PATCH] powerpc: use generic posix_types.h fix
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/powerpc/include/asm/posix_types.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/posix_types.h b/arch/powerpc/include/asm/posix_types.h
> index 1fbe027f..f139325 100644
> --- a/arch/powerpc/include/asm/posix_types.h
> +++ b/arch/powerpc/include/asm/posix_types.h
> @@ -12,7 +12,7 @@ typedef unsigned long __kernel_old_dev_t;
> #define __kernel_old_dev_t __kernel_old_dev_t
> #else
> typedef unsigned int __kernel_size_t;
> -typedef int __kernel_size_t;
> +typedef int __kernel_ssize_t;
> typedef long __kernel_ptrdiff_t;
> #define __kernel_size_t __kernel_size_t
>
> --
> 1.7.9
>
^ permalink raw reply
* Re: [PATCH] USB: ehci-fsl: Turn on cache snooping on MPC8xxx
From: Li Yang @ 2012-02-17 6:56 UTC (permalink / raw)
To: Pan Jiafei; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <1329458236-4619-1-git-send-email-Jiafei.Pan@freescale.com>
On Fri, Feb 17, 2012 at 1:57 PM, Pan Jiafei <Jiafei.Pan@freescale.com> wrot=
e:
> If a MPC8xxx was being used, 'have_sysif_regs' should be set and
> it should setup cache snooping for all the 4GB space on both PPC32
> and PPC64.
>
> Signed-off-by: Pan Jiafei <Jiafei.Pan@freescale.com>
Hi Jiafei,
You should have sent this patch upstream earlier. I remember you
asked about it a few months ago. :)
Acked-by: Li Yang <leoli@freescale.com>
> ---
> =C2=A0drivers/usb/host/ehci-fsl.c | =C2=A0 23 ++++++++++-------------
> =C2=A01 files changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
> index c26a82e..8327d3e 100644
> --- a/drivers/usb/host/ehci-fsl.c
> +++ b/drivers/usb/host/ehci-fsl.c
> @@ -252,21 +252,18 @@ static int ehci_fsl_usb_setup(struct ehci_hcd *ehci=
)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (pdata->have_sysif_regs) {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0temp =3D in_be32(n=
on_ehci + FSL_SOC_USB_CTRL);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0out_be32(non_ehci =
+ FSL_SOC_USB_CTRL, temp | 0x00000004);
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + FS=
L_SOC_USB_SNOOP1, 0x0000001b);
> - =C2=A0 =C2=A0 =C2=A0 }
>
> -#if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
> - =C2=A0 =C2=A0 =C2=A0 /*
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0* Turn on cache snooping hardware, since som=
e PowerPC platforms
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0* wholly rely on hardware to deal with cache=
coherent
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /*
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * Turn on cache snoopi=
ng hardware, since some PowerPC platforms
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * wholly rely on hardw=
are to deal with cache coherent
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 */
>
> - =C2=A0 =C2=A0 =C2=A0 /* Setup Snooping for all the 4GB space */
> - =C2=A0 =C2=A0 =C2=A0 /* SNOOP1 starts from 0x0, size 2G */
> - =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOO=
P_SIZE_2GB);
> - =C2=A0 =C2=A0 =C2=A0 /* SNOOP2 starts from 0x80000000, size 2G */
> - =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000=
| SNOOP_SIZE_2GB);
> -#endif
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Setup Snooping for =
all the 4GB space */
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* SNOOP1 starts from =
0x0, size 2G */
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + FS=
L_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* SNOOP2 starts from =
0x80000000, size 2G */
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 out_be32(non_ehci + FS=
L_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
> + =C2=A0 =C2=A0 =C2=A0 }
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0if ((pdata->operating_mode =3D=3D FSL_USB2_DR_=
HOST) ||
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(pdata->operating_mode =3D=3D FSL_USB2_DR_OTG))
> --
> 1.7.5.1
^ permalink raw reply
* [PATCH 1/2] powerpc/44x: Add new compatible value for EMAC node of APM821XX dts file.
From: Duc Dang @ 2012-02-17 8:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras
Cc: Duc Dang, linuxppc-dev, linux-kernel
This compatible value will be used to distinguish some special
features of APM821XX EMAC: no half duplex mode support, configuring
jumbo frame.
Signed-off-by: Duc Dang <dhdang@apm.com>
---
arch/powerpc/boot/dts/bluestone.dts | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/bluestone.dts b/arch/powerpc/boot/dts/bluestone.dts
index 2a56a0d..74876f7 100644
--- a/arch/powerpc/boot/dts/bluestone.dts
+++ b/arch/powerpc/boot/dts/bluestone.dts
@@ -222,7 +222,7 @@
EMAC0: ethernet@ef600c00 {
device_type = "network";
- compatible = "ibm,emac4sync";
+ compatible = "ibm,emac-apm821xx", "ibm,emac4sync";
interrupt-parent = <&EMAC0>;
interrupts = <0x0 0x1>;
#interrupt-cells = <1>;
--
1.7.5.4
^ permalink raw reply related
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