* 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
* 5020 SATA fix
From: Benjamin Herrenschmidt @ 2012-02-17 0:29 UTC (permalink / raw)
To: Xulei; +Cc: linuxppc-dev
Hi Lei !
In your SDK kernel I see this commit:
92c0ce1e599e788ffc0908739db9bd5e0dbdad69
sata_fsl: Add the workaround for SATA-A005 erratum on P2040/P3041/P5020
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 ?
Any objection to me just sending it upstream ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Benjamin Herrenschmidt @ 2012-02-17 0:02 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <1329433132.2892.30.camel@pasglop>
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.
^ permalink raw reply
* Re: [PATCH v5 00/27] irq_domain generalization and rework
From: Russell King - ARM Linux @ 2012-02-16 23:26 UTC (permalink / raw)
To: Andrew Morton
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120216145219.0f1c1b98.akpm@linux-foundation.org>
On Thu, Feb 16, 2012 at 02:52:19PM -0800, Andrew Morton wrote:
> On Thu, 16 Feb 2012 02:09:01 -0700
> Grant Likely <grant.likely@secretlab.ca> wrote:
> > This series generalizes the "irq_host" infrastructure from powerpc
> > so that it can be used by all architectures and renames it to "irq_domain".
>
> drivers/mfd/twl-core.c is fairly horked on i386 allmodconfig:
>
> drivers/mfd/twl-core.c: In function 'twl_probe':
> drivers/mfd/twl-core.c:1218: error: implicit declaration of function 'irq_alloc_descs'
> drivers/mfd/twl-core.c:1226: error: implicit declaration of function 'irq_domain_add_legacy'
> drivers/mfd/twl-core.c:1227: error: 'irq_domain_simple_ops' undeclared (first use in this function)
> drivers/mfd/twl-core.c:1227: error: (Each undeclared identifier is reported only once
> drivers/mfd/twl-core.c:1227: error: for each function it appears in.)
>
> This is today's linux-next so it has rmk's "ARM: omap: fix broken
> twl-core dependencies and ifdefs" in there, which looks like it
> attempts to repair this stuff.
Yes, you're the third to report this breakage.
Grant's response on Tuesday over this was:
| This is irq_domain related. It's related to an API change. I'm
| tracking to get it solved, either by moving the twl commit into the
| irqdomain branch or by deferring the api change to v3.5.
|
| I've also got a patch that converts x86 over to the new api, but I
| don't have sufficient review to put it into the irqdomain tree yet.
> btw, Russell, regarding this comment in include/linux/irq.h:
>
> /*
> * Please do not include this file in generic code. There is currently
> * no requirement for any architecture to implement anything held
> * within this file.
> *
> * Thanks. --rmk
> */
>
> A quick grep indicates that we've lost this battle ;) Is the comments
> still true? Should we stop discouraging inclusion of linux/irq.h?
> Does anyone even know that it's discouraged ;)
It's still true for any platform which hasn't been converted to genirq,
as such a platform would not have asm/hw_irq.h. That said, since
genirq, it's now necessary for any driver which contains interrupt
controller code like GPIO drivers. So I suspect the comment should now
be lost, even though it's not really a replacement for asm/irq.h.
^ permalink raw reply
* Re: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Benjamin Herrenschmidt @ 2012-02-16 22:58 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <1329386540-12341-1-git-send-email-Shengzhou.Liu@freescale.com>
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:
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
/soc@ffe000000/usb@210000: Invalid 'dr_mode' property, fallback to host mode
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 44, io mem 0xffe210000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2
fsl-ehci fsl-ehci.1: irq 45, io mem 0xffe211000
fsl-ehci fsl-ehci.1: USB 2.0 started, EHCI 1.00
.../...
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
<remove device, re-plug it>
usb 1-1: new full-speed USB device number 3 using fsl-ehci
hub 1-0:1.0: unable to enumerate USB device on port 1
<remove again, re-plug it>
usb 1-1: new full-speed USB device number 4 using fsl-ehci
usb 1-1: device descriptor read/64, error -110
The blurb about "invalid dr_mode property" makes me think there's some
kind of disagreement between the device-tree coming with the machine and
what upstream expects. Basically the DT doesn't contain a dr_mode
property at all (which should be fine, host mode is what I want, but I
suspect some stuff aren't being configured properly by u-boot either...)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 00/27] irq_domain generalization and rework
From: Andrew Morton @ 2012-02-16 22:52 UTC (permalink / raw)
To: Grant Likely
Cc: Russell King, devicetree-discuss, linux-kernel, Milton Miller,
Rob Herring, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1329383368-12122-1-git-send-email-grant.likely@secretlab.ca>
On Thu, 16 Feb 2012 02:09:01 -0700
Grant Likely <grant.likely@secretlab.ca> wrote:
>
> This series generalizes the "irq_host" infrastructure from powerpc
> so that it can be used by all architectures and renames it to "irq_domain".
drivers/mfd/twl-core.c is fairly horked on i386 allmodconfig:
drivers/mfd/twl-core.c: In function 'twl_probe':
drivers/mfd/twl-core.c:1218: error: implicit declaration of function 'irq_alloc_descs'
drivers/mfd/twl-core.c:1226: error: implicit declaration of function 'irq_domain_add_legacy'
drivers/mfd/twl-core.c:1227: error: 'irq_domain_simple_ops' undeclared (first use in this function)
drivers/mfd/twl-core.c:1227: error: (Each undeclared identifier is reported only once
drivers/mfd/twl-core.c:1227: error: for each function it appears in.)
This is today's linux-next so it has rmk's "ARM: omap: fix broken
twl-core dependencies and ifdefs" in there, which looks like it
attempts to repair this stuff.
It's looking for things which are in both linux/irq.h and in
linux/irqdomain.h.
btw, Russell, regarding this comment in include/linux/irq.h:
/*
* Please do not include this file in generic code. There is currently
* no requirement for any architecture to implement anything held
* within this file.
*
* Thanks. --rmk
*/
A quick grep indicates that we've lost this battle ;) Is the comments
still true? Should we stop discouraging inclusion of linux/irq.h?
Does anyone even know that it's discouraged ;)
^ permalink raw reply
* Re: [PATCH 1/2 v4] powerpc/85xx: Add p1025rdb platform support
From: Tabi Timur-B04825 @ 2012-02-16 21:07 UTC (permalink / raw)
To: Fan Zhicheng-B32736; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1329206783-12190-1-git-send-email-B32736@freescale.com>
On Tue, Feb 14, 2012 at 2:06 AM, Zhicheng Fan <B32736@freescale.com> wrote:
> From: Zhicheng Fan <b32736@freescale.com>
>
> Signed-off-by: Zhicheng Fan <b32736@freescale.com>
> ---
Acked-by: Timur Tabi <timur@freescale.com>
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH 2/2 v4] powerpc/dts: Add dts for p1025rdb board
From: Tabi Timur-B04825 @ 2012-02-16 21:06 UTC (permalink / raw)
To: Fan Zhicheng-B32736; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1329206783-12190-2-git-send-email-B32736@freescale.com>
On Tue, Feb 14, 2012 at 2:06 AM, Zhicheng Fan <B32736@freescale.com> wrote:
> From: Zhicheng Fan <b32736@freescale.com>
>
> P1025RDB Overview
> ------------------
> 1Gbyte DDR3 SDRAM
> 32 Mbyte NAND flash
> 16Mbyte NOR flash
> 16 Mbyte SPI flash
> SD connector to interface with the SD memory card
> Real-time clock on I2C bus
>
> PCIe:
> - x1 PCIe slot
> - x1 mini-PCIe slot
>
> 10/100/1000 BaseT Ethernet ports:
> - eTSEC1, RGMII: one 10/100/1000 port using AtherosTM AR8021
> - eTSEC2, SGMII: one 10/100/1000 port using VitesseTM VSC8221
> - eTSEC3, RGMII: one 10/100/1000 port using AtherosTM AR8021
>
> USB 2.0 port:
> - Two USB2.0 Type A receptacles
> - One USB2.0 signal to Mini PCIe slot
>
> Dual RJ45 UART ports:
> - DUART interface: supports two UARTs up to 115200 bps for console displa=
y
>
> Signed-off-by: Zhicheng Fan <b32736@freescale.com>
> ---
Acked-by: Timur Tabi <timur@freescale.com>
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH 1/2 v5] powerpc/85xx: Add Quicc Engine support for p1025rdb
From: Tabi Timur-B04825 @ 2012-02-16 21:05 UTC (permalink / raw)
To: Fan Zhicheng-B32736; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1329289091-26231-1-git-send-email-B32736@freescale.com>
On Wed, Feb 15, 2012 at 12:58 AM, Zhicheng Fan <B32736@freescale.com> wrote=
:
> From: Zhicheng Fan <b32736@freescale.com>
>
> Signed-off-by: Zhicheng Fan <b32736@freescale.com>
> ---
Acked-by: Timur Tabi <timur@freescale.com>
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: tlb flushing on Power
From: Benjamin Herrenschmidt @ 2012-02-16 20:31 UTC (permalink / raw)
To: Seth Jennings; +Cc: Robert Jennings, linuxppc-dev, Nitin Gupta, Dave Hansen
In-Reply-To: <4F3D38D3.4020903@linux.vnet.ibm.com>
On Thu, 2012-02-16 at 11:11 -0600, Seth Jennings wrote:
> Just wanted to bump you again about this. You mentioned that if I wanted to
> do a cpu-local flush of a single tlb entry, that there would have to be a new
> hook. Is that right?
>
> I've been looking through the powerpc arch and I thought that I might have
> found the power analog to __flush_tlb_one() for x86 in local_flush_tlb_page()
> with a NULL vma argument. This doesn't seem to work though, as indicated
> by a crash when I tried it. After looking in tlbflush.h again, it seems
> that local_flush_tlb_page() is a no-op when CONFIG_PPC_STD_MMU_64 is set,
> as are almost ALL of the tlb flushing functions... which makes no sense to
> me.
>
> Any help you (or anyone) can give me would be greatly appreciated.
On ppc64 with hash-table MMU, we handle the flushes very differently.
PTEs that are modified are added to a list at the time of the
modification and either flushed immediately if no lazy tlb batching is
in progress or flushed when leaving the lazy tlb op.
This is to avoid a problem where we might otherwise, under some
circumstances, create a new TLB which can be hashed in to the hash table
before the previous one has been flushed out. That would lead to a dup
in the hash table which is architecturally illegal.
This happens via the call to hpte_need_flush() in pte_update().
Unfortunately, it will always consider all kernel mappings as global,
so the per-cpu "optimization" won't be usable in this case, at least
not until we add some kind of additional argument to that function.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Timur Tabi @ 2012-02-16 19:48 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: Dan Williams, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20120216194655.GD9262@ovro.caltech.edu>
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.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Ira W. Snyder @ 2012-02-16 19:46 UTC (permalink / raw)
To: Timur Tabi; +Cc: Dan Williams, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F3D5A28.4010905@freescale.com>
On Thu, Feb 16, 2012 at 01:34:00PM -0600, Timur Tabi wrote:
> Ira W. Snyder wrote:
> > This leads me to believe that this occurs mostly (but not always)
> > concurrent with the end-of-chain interrupt.
>
> Have you tested this on an 85xx platform?
>
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 noticed something odd. You're modifying fsldma_chan_irq(), which is for
> DMA controllers that have per-channel IRQs. 83xx devices don't have
> per-channel IRQs -- all channels on one controller have the same IRQ.
> Looking at the device tree, I see that the IRQs are listed in the channel
> nodes *and* in the controller node. I don't see how we ever use the
> per-controller ISR.
>
fsldma_ctrl_irq() (the per-controller irq handler) just calls through to
fsldma_chan_irq() (the per-channel irq handler).
> I wonder if the shared IRQ is the part of the cause of the interrupts
> you're seeing.
>
My device tree is slightly modified to remove the per-controller
interrupts and interrupt-parent properties. Each individual channel has
identical interrupts and interrupt-parent properties specified.
Someone here suggested that I do that, several years ago. It has been
too long, and I do not remember who. I can reverse it, and use the
per-controller IRQ instead.
> >
> > In the last month, the "unhandled sr" error has occurred on 92 out of
> > 120 boards in production use. The statistics are included below. On some
> > boards, it is much more frequent than on others. All boards have roughly
> > the same workload.
> >
> > Another interesting tidbit from my logs: this only occurs on DMA channel
> > 2 (the are numbered starting at 0, it is the 3rd channel). Here is an
> > example log message:
>
> What happens if you never register that channel? That is, remove this
> node from the device tree:
>
> dma-channel@100 {
> compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
> reg = <0x100 0x80>;
> cell-index = <2>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> };
>
I can try that. I hunch the problem will move, as the carma-fpga driver
(see drivers/misc/carma/carma-fpga.c) will claim the 4th channel
instead.
Ira
^ permalink raw reply
* Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Timur Tabi @ 2012-02-16 19:34 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: Dan Williams, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20120216190040.GA9262@ovro.caltech.edu>
Ira W. Snyder wrote:
> This leads me to believe that this occurs mostly (but not always)
> concurrent with the end-of-chain interrupt.
Have you tested this on an 85xx platform?
I noticed something odd. You're modifying fsldma_chan_irq(), which is for
DMA controllers that have per-channel IRQs. 83xx devices don't have
per-channel IRQs -- all channels on one controller have the same IRQ.
Looking at the device tree, I see that the IRQs are listed in the channel
nodes *and* in the controller node. I don't see how we ever use the
per-controller ISR.
I wonder if the shared IRQ is the part of the cause of the interrupts
you're seeing.
>
> In the last month, the "unhandled sr" error has occurred on 92 out of
> 120 boards in production use. The statistics are included below. On some
> boards, it is much more frequent than on others. All boards have roughly
> the same workload.
>
> Another interesting tidbit from my logs: this only occurs on DMA channel
> 2 (the are numbered starting at 0, it is the 3rd channel). Here is an
> example log message:
What happens if you never register that channel? That is, remove this
node from the device tree:
dma-channel@100 {
compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
reg = <0x100 0x80>;
cell-index = <2>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
};
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Ira W. Snyder @ 2012-02-16 19:00 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: Dan Williams, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOZdJXVccE0GqZU2PvAz3RTh+X9ZYZr-9YufxS+mYWJkhSOGEQ@mail.gmail.com>
On Thu, Feb 16, 2012 at 05:50:47PM +0000, Tabi Timur-B04825 wrote:
> On Thu, Jan 26, 2012 at 2:58 PM, Ira W. Snyder <iws@ovro.caltech.edu> wrote:
> > The mpc8349ea has been observed to generate spurious end of segments
> > interrupts despite the fact that they are not enabled by this driver.
> > Check for them and ignore them to avoid a kernel error message.
>
> When this happens, are there any other status bits set? It seems
> weird that there are spurious interrupts from an internal block,
> especially since it's the same block on all 83xx parts.
>
> I wonder if the EOSI bit just happens to be set when the interrupt
> occurs for some other reason.
>
I'm not sure. The fsldma irq handler only prints bits it did not handle.
There are several other bits in the driver which should never be seen,
but they are handled by the irq handler anyway. This is just a remnant
from the original Freescale code.
I have a set of 15 test boards that I can use to figure out which other
bits are set when this happens, if it is important.
I put a variation of this patch (missing the "skip tasklet if not idle"
logic) into my production boards roughly a month ago. I've gotten the
"controller not idle" error message 748 times, as compared to the
"unhandled sr 0x00000002" message 3449 times.
This leads me to believe that this occurs mostly (but not always)
concurrent with the end-of-chain interrupt.
In the last month, the "unhandled sr" error has occurred on 92 out of
120 boards in production use. The statistics are included below. On some
boards, it is much more frequent than on others. All boards have roughly
the same workload.
Another interesting tidbit from my logs: this only occurs on DMA channel
2 (the are numbered starting at 0, it is the 3rd channel). Here is an
example log message:
[3484053.821689] of:fsl-elo-dma e00082a8.dma: chan2: irq: unhandled sr 0x00000002
Thanks,
Ira
15 serial-number-5
1 serial-number-16
8 serial-number-18
16 serial-number-19
3 serial-number-20
21 serial-number-21
1 serial-number-24
1 serial-number-26
3 serial-number-27
2 serial-number-28
16 serial-number-29
4 serial-number-30
1 serial-number-31
4 serial-number-32
5 serial-number-33
1 serial-number-34
6 serial-number-35
18 serial-number-36
1 serial-number-39
1 serial-number-40
2 serial-number-41
10 serial-number-42
11 serial-number-43
32 serial-number-45
6 serial-number-46
4 serial-number-47
1 serial-number-49
6 serial-number-50
2 serial-number-51
4 serial-number-53
1 serial-number-55
1 serial-number-57
15 serial-number-58
1 serial-number-60
1 serial-number-62
1 serial-number-66
8 serial-number-67
2 serial-number-75
1 serial-number-76
11 serial-number-79
4 serial-number-80
8 serial-number-81
1 serial-number-82
11 serial-number-84
2 serial-number-92
20 serial-number-93
30 serial-number-94
19 serial-number-95
32 serial-number-96
73 serial-number-97
18 serial-number-99
57 serial-number-100
41 serial-number-101
28 serial-number-102
8 serial-number-103
132 serial-number-107
60 serial-number-108
55 serial-number-109
97 serial-number-110
18 serial-number-111
45 serial-number-113
6 serial-number-114
123 serial-number-115
27 serial-number-117
29 serial-number-118
12 serial-number-119
47 serial-number-120
74 serial-number-121
8 serial-number-124
128 serial-number-125
326 serial-number-128
84 serial-number-129
36 serial-number-130
2 serial-number-131
75 serial-number-133
64 serial-number-135
686 serial-number-137
97 serial-number-139
28 serial-number-140
82 serial-number-141
36 serial-number-144
31 serial-number-145
47 serial-number-147
60 serial-number-150
22 serial-number-152
36 serial-number-154
57 serial-number-156
68 serial-number-158
54 serial-number-159
37 serial-number-160
46 serial-number-161
14 serial-number-162
^ permalink raw reply
* Re: [PATCH v5 08/27] irq_domain: Move irq_domain code from powerpc to kernel/irq
From: Cousson, Benoit @ 2012-02-16 17:52 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <4F3D3F21.3060905@ti.com>
OK, forget about it, I've just seen your email on that and pulled your
latest update.
Regards,
Benoit
On 2/16/2012 6:38 PM, Cousson, Benoit wrote:
> Hi Grant,
>
> It looks like there is a small regression in that update, it cannot
> build due to a missing semi-colon.
>
> On 2/16/2012 10:09 AM, Grant Likely wrote:
>> +/**
>> + * irq_find_mapping() - Find a linux irq from an hw irq number.
>> + * @host: domain owning this hardware interrupt
>> + * @hwirq: hardware irq number in that host space
>> + *
>> + * This is a slow path, for use by generic code. It's expected that an
>> + * irq controller implementation directly calls the appropriate low
>> level
>> + * mapping function.
>> + */
>> +unsigned int irq_find_mapping(struct irq_domain *host,
>> + irq_hw_number_t hwirq)
>> +{
>> + unsigned int i;
>> + unsigned int hint = hwirq % irq_virq_count;
>> +
>> + /* Look for default host if nececssary */
>> + if (host == NULL)
>> + host = irq_default_host;
>> + if (host == NULL)
>> + return NO_IRQ;
>> +
>> + /* legacy -> bail early */
>> + if (host->revmap_type == IRQ_DOMAIN_MAP_LEGACY)
>> + return hwirq;
>> +
>> + /* Slow path does a linear search of the map */
>> + if (hint == 0)
>> + hint = 1;
>> + i = hint;
>> + do {
>> + struct irq_data *data = irq_get_irq_data(i);
>> + if (data&& (data->domain == host)&& (data->hwirq == hwirq))
>> + return i;
>> + i++;
>> + if (i>= irq_virq_count)
>> + i = 1
>
> The ";" is missing.
>
> Regards,
> Benoit
^ permalink raw reply
* Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Tabi Timur-B04825 @ 2012-02-16 17:50 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: Dan Williams, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1327611520-18256-1-git-send-email-iws@ovro.caltech.edu>
On Thu, Jan 26, 2012 at 2:58 PM, Ira W. Snyder <iws@ovro.caltech.edu> wrote=
:
> The mpc8349ea has been observed to generate spurious end of segments
> interrupts despite the fact that they are not enabled by this driver.
> Check for them and ignore them to avoid a kernel error message.
When this happens, are there any other status bits set? It seems
weird that there are spurious interrupts from an internal block,
especially since it's the same block on all 83xx parts.
I wonder if the EOSI bit just happens to be set when the interrupt
occurs for some other reason.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH v4 3/3] KVM: PPC: epapr: install ev_idle hcall for e500 guest
From: Alexander Graf @ 2012-02-16 17:39 UTC (permalink / raw)
To: Scott Wood
Cc: <linuxppc-dev@ozlabs.org>, Liu Yu,
<kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>,
<B07421@freescale.com>
In-Reply-To: <4F3D3E89.3050301@freescale.com>
On 16.02.2012, at 18:36, Scott Wood wrote:
> On 02/16/2012 11:30 AM, Alexander Graf wrote:
>>=20
>> On 16.02.2012, at 18:28, Scott Wood wrote:
>>=20
>>> On 02/16/2012 11:18 AM, Alexander Graf wrote:
>>>> Hrm. But we can clobber ctr, right? So how about we make the =
generic version do a bctr and then just do a small C wrapper that takes =
lr, moves it to ctr and branches to the generic one?
>>>=20
>>> If it's just for this, I would say don't mess with the normal hcall =
path
>>> for the sake of idle. If using CTR would let us get away without
>>> creating a stack frame in call sites, maybe that would be =
worthwhile,
>>> depending on what sort of hcalls we end up having.
>>>=20
>>>> Then we don't have to replicate the hypercall code all over again =
for every invocation.
>>>=20
>>> We shouldn't need to do it for every invocation. Idle is special =
due to
>>> the TLF_NAPPING hack.
>>=20
>> Famous last words. If it's the only case, duplication should be ok. =
Let's hope there are no others.
>=20
> Actually, we can't use CTR -- it's volatile in the ePAPR hypercall =
ABI.
Ugh. Alrighty, let's duplicate the hc code then.
Alex
^ permalink raw reply
* Re: [PATCH v5 08/27] irq_domain: Move irq_domain code from powerpc to kernel/irq
From: Cousson, Benoit @ 2012-02-16 17:38 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1329383368-12122-9-git-send-email-grant.likely@secretlab.ca>
Hi Grant,
It looks like there is a small regression in that update, it cannot
build due to a missing semi-colon.
On 2/16/2012 10:09 AM, Grant Likely wrote:
> +/**
> + * irq_find_mapping() - Find a linux irq from an hw irq number.
> + * @host: domain owning this hardware interrupt
> + * @hwirq: hardware irq number in that host space
> + *
> + * This is a slow path, for use by generic code. It's expected that an
> + * irq controller implementation directly calls the appropriate low level
> + * mapping function.
> + */
> +unsigned int irq_find_mapping(struct irq_domain *host,
> + irq_hw_number_t hwirq)
> +{
> + unsigned int i;
> + unsigned int hint = hwirq % irq_virq_count;
> +
> + /* Look for default host if nececssary */
> + if (host == NULL)
> + host = irq_default_host;
> + if (host == NULL)
> + return NO_IRQ;
> +
> + /* legacy -> bail early */
> + if (host->revmap_type == IRQ_DOMAIN_MAP_LEGACY)
> + return hwirq;
> +
> + /* Slow path does a linear search of the map */
> + if (hint == 0)
> + hint = 1;
> + i = hint;
> + do {
> + struct irq_data *data = irq_get_irq_data(i);
> + if (data&& (data->domain == host)&& (data->hwirq == hwirq))
> + return i;
> + i++;
> + if (i>= irq_virq_count)
> + i = 1
The ";" is missing.
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH v4 3/3] KVM: PPC: epapr: install ev_idle hcall for e500 guest
From: Scott Wood @ 2012-02-16 17:36 UTC (permalink / raw)
To: Alexander Graf
Cc: <linuxppc-dev@ozlabs.org>, Liu Yu,
<kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>,
<B07421@freescale.com>
In-Reply-To: <144AF998-6DEE-453A-872A-B148ACA2B7B8@suse.de>
On 02/16/2012 11:30 AM, Alexander Graf wrote:
>
> On 16.02.2012, at 18:28, Scott Wood wrote:
>
>> On 02/16/2012 11:18 AM, Alexander Graf wrote:
>>> Hrm. But we can clobber ctr, right? So how about we make the generic version do a bctr and then just do a small C wrapper that takes lr, moves it to ctr and branches to the generic one?
>>
>> If it's just for this, I would say don't mess with the normal hcall path
>> for the sake of idle. If using CTR would let us get away without
>> creating a stack frame in call sites, maybe that would be worthwhile,
>> depending on what sort of hcalls we end up having.
>>
>>> Then we don't have to replicate the hypercall code all over again for every invocation.
>>
>> We shouldn't need to do it for every invocation. Idle is special due to
>> the TLF_NAPPING hack.
>
> Famous last words. If it's the only case, duplication should be ok. Let's hope there are no others.
Actually, we can't use CTR -- it's volatile in the ePAPR hypercall ABI.
-Scott
^ permalink raw reply
* Re: [PATCH v4 3/3] KVM: PPC: epapr: install ev_idle hcall for e500 guest
From: Alexander Graf @ 2012-02-16 17:30 UTC (permalink / raw)
To: Scott Wood
Cc: <linuxppc-dev@ozlabs.org>, Liu Yu,
<kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>,
<B07421@freescale.com>
In-Reply-To: <4F3D3CBA.2060201@freescale.com>
On 16.02.2012, at 18:28, Scott Wood wrote:
> On 02/16/2012 11:18 AM, Alexander Graf wrote:
>>=20
>> On 16.02.2012, at 17:58, Scott Wood wrote:
>>=20
>>> On 02/16/2012 04:24 AM, Alexander Graf wrote:
>>>> On 16.02.2012, at 10:26, Liu Yu <yu.liu@freescale.com> wrote:
>>>>> +_GLOBAL(epapr_ev_idle)
>>>>> +epapr_ev_idle:
>>>>> + rlwinm r3,r1,0,0,31-THREAD_SHIFT /* current thread_info =
*/
>>>>> + lwz r4,TI_LOCAL_FLAGS(r3) /* set napping bit */
>>>>> + ori r4,r4,_TLF_NAPPING /* so when we take an exception =
*/
>>>>> + stw r4,TI_LOCAL_FLAGS(r3) /* it will return to our =
caller */
>>>>> +
>>>>> + wrteei 1
>>>>> +
>>>>> +idle_loop:
>>>>> + LOAD_REG_IMMEDIATE(r11, HC_VENDOR_EPAPR | HC_EV_IDLE)
>>>>> +
>>>>> +.global epapr_ev_idle_start
>>>>> +epapr_ev_idle_start:
>>>>> + li r3, -1
>>>>> + nop
>>>>> + nop
>>>>> + nop
>>>>=20
>>>> Can't you just bl into epapr_hypercall_start? You don't even have =
to save the old lr. because we never return anyways :)
>>>=20
>>> The interrupt will branch to LR, so no, we can't trash it or put it
>>> anywhere else.
>>=20
>> Hrm. But we can clobber ctr, right? So how about we make the generic =
version do a bctr and then just do a small C wrapper that takes lr, =
moves it to ctr and branches to the generic one?
>=20
> If it's just for this, I would say don't mess with the normal hcall =
path
> for the sake of idle. If using CTR would let us get away without
> creating a stack frame in call sites, maybe that would be worthwhile,
> depending on what sort of hcalls we end up having.
>=20
>> Then we don't have to replicate the hypercall code all over again for =
every invocation.
>=20
> We shouldn't need to do it for every invocation. Idle is special due =
to
> the TLF_NAPPING hack.
Famous last words. If it's the only case, duplication should be ok. =
Let's hope there are no others.
Alex
^ permalink raw reply
* Re: [PATCH v4 3/3] KVM: PPC: epapr: install ev_idle hcall for e500 guest
From: Scott Wood @ 2012-02-16 17:28 UTC (permalink / raw)
To: Alexander Graf
Cc: <linuxppc-dev@ozlabs.org>, Liu Yu,
<kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>,
<B07421@freescale.com>
In-Reply-To: <9A00D501-8965-478F-8356-6199F5572600@suse.de>
On 02/16/2012 11:18 AM, Alexander Graf wrote:
>
> On 16.02.2012, at 17:58, Scott Wood wrote:
>
>> On 02/16/2012 04:24 AM, Alexander Graf wrote:
>>> On 16.02.2012, at 10:26, Liu Yu <yu.liu@freescale.com> wrote:
>>>> +_GLOBAL(epapr_ev_idle)
>>>> +epapr_ev_idle:
>>>> + rlwinm r3,r1,0,0,31-THREAD_SHIFT /* current thread_info */
>>>> + lwz r4,TI_LOCAL_FLAGS(r3) /* set napping bit */
>>>> + ori r4,r4,_TLF_NAPPING /* so when we take an exception */
>>>> + stw r4,TI_LOCAL_FLAGS(r3) /* it will return to our caller */
>>>> +
>>>> + wrteei 1
>>>> +
>>>> +idle_loop:
>>>> + LOAD_REG_IMMEDIATE(r11, HC_VENDOR_EPAPR | HC_EV_IDLE)
>>>> +
>>>> +.global epapr_ev_idle_start
>>>> +epapr_ev_idle_start:
>>>> + li r3, -1
>>>> + nop
>>>> + nop
>>>> + nop
>>>
>>> Can't you just bl into epapr_hypercall_start? You don't even have to save the old lr. because we never return anyways :)
>>
>> The interrupt will branch to LR, so no, we can't trash it or put it
>> anywhere else.
>
> Hrm. But we can clobber ctr, right? So how about we make the generic version do a bctr and then just do a small C wrapper that takes lr, moves it to ctr and branches to the generic one?
If it's just for this, I would say don't mess with the normal hcall path
for the sake of idle. If using CTR would let us get away without
creating a stack frame in call sites, maybe that would be worthwhile,
depending on what sort of hcalls we end up having.
> Then we don't have to replicate the hypercall code all over again for every invocation.
We shouldn't need to do it for every invocation. Idle is special due to
the TLF_NAPPING hack.
-Scott
^ permalink raw reply
* [PATCH 2/2] [v2] powerpc/fsl: add PAMUBYPENR register definition to fsl_guts.h
From: Timur Tabi @ 2012-02-16 17:21 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <1329412870-16716-1-git-send-email-timur@freescale.com>
Add a defintion of register PAMUBYPENR (offset 0x604) to the global
utilities structure.
PAMUBYPENR is the PAMU bypass enable register. It contains control
bits for enabling bypass mode on each PAMU.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/include/asm/fsl_guts.h | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_guts.h b/arch/powerpc/include/asm/fsl_guts.h
index a880377..23e483d 100644
--- a/arch/powerpc/include/asm/fsl_guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -69,7 +69,9 @@ struct ccsr_guts {
u8 res0c4[0x224 - 0xc4];
__be32 iodelay1; /* 0x.0224 - IO delay control register 1 */
__be32 iodelay2; /* 0x.0228 - IO delay control register 2 */
- u8 res22c[0x800 - 0x22c];
+ u8 res22c[0x604 - 0x22c];
+ __be32 pamubypenr; /* 0x.0604 - PAMU bypass enable register */
+ u8 res608[0x800 - 0x608];
__be32 clkdvdr; /* 0x.0800 - Clock Divide Register */
u8 res804[0x900 - 0x804];
__be32 ircr; /* 0x.0900 - Infrared Control Register */
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/2] powerpc/8xxx: remove 85xx/86xx restrictions from fsl_guts.h
From: Timur Tabi @ 2012-02-16 17:21 UTC (permalink / raw)
To: galak, linuxppc-dev
Remove the check for CONFIG_PPC_85xx and CONFIG_PPC_86xx from fsl_guts.h.
The check was originally intended to allow the same header file to
be used on 85xx and 86xx systems, even though the Global Utilities
register could be different. It turns out that they're not actually
different, and so the check is not necessary. In addition, neither
macro is defined for 64-bit e5500 kernels, so that causes a build
break.
To maintain backwards compatibility, we also define macros for
ccsr_guts_85xx and ccsr_guts_86xx. This eliminates the need to
change all the files that #include fsl_guts.h. Those files will
be updated at a later time, and then the macros can be deleted.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/include/asm/fsl_guts.h | 26 +++++++-------------------
1 files changed, 7 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_guts.h b/arch/powerpc/include/asm/fsl_guts.h
index bebd124..a880377 100644
--- a/arch/powerpc/include/asm/fsl_guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -16,15 +16,6 @@
#define __ASM_POWERPC_FSL_GUTS_H__
#ifdef __KERNEL__
-/*
- * These #ifdefs are safe because it's not possible to build a kernel that
- * runs on e500 and e600 cores.
- */
-
-#if !defined(CONFIG_PPC_85xx) && !defined(CONFIG_PPC_86xx)
-#error Only 85xx and 86xx SOCs are supported
-#endif
-
/**
* Global Utility Registers.
*
@@ -36,11 +27,7 @@
* different names. In these cases, one name is chosen to avoid extraneous
* #ifdefs.
*/
-#ifdef CONFIG_PPC_85xx
-struct ccsr_guts_85xx {
-#else
-struct ccsr_guts_86xx {
-#endif
+struct ccsr_guts {
__be32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
__be32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
__be32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and Control Register */
@@ -77,11 +64,8 @@ struct ccsr_guts_86xx {
u8 res0a8[0xb0 - 0xa8];
__be32 rstcr; /* 0x.00b0 - Reset Control Register */
u8 res0b4[0xc0 - 0xb4];
-#ifdef CONFIG_PPC_85xx
- __be32 iovselsr; /* 0x.00c0 - I/O voltage select status register */
-#else
- __be32 elbcvselcr; /* 0x.00c0 - eLBC Voltage Select Ctrl Reg */
-#endif
+ __be32 iovselsr; /* 0x.00c0 - I/O voltage select status register
+ Called 'elbcvselcr' on 86xx SOCs */
u8 res0c4[0x224 - 0xc4];
__be32 iodelay1; /* 0x.0224 - IO delay control register 1 */
__be32 iodelay2; /* 0x.0228 - IO delay control register 2 */
@@ -114,6 +98,10 @@ struct ccsr_guts_86xx {
__be32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
} __attribute__ ((packed));
+/* For backwards-compatibility */
+#define ccsr_guts_85xx ccsr_guts
+#define ccsr_guts_86xx ccsr_guts
+
#ifdef CONFIG_PPC_86xx
#define CCSR_GUTS_DMACR_DEV_SSI 0 /* DMA controller/channel set to SSI */
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH v4 3/3] KVM: PPC: epapr: install ev_idle hcall for e500 guest
From: Alexander Graf @ 2012-02-16 17:18 UTC (permalink / raw)
To: Scott Wood
Cc: <linuxppc-dev@ozlabs.org>, Liu Yu,
<kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>,
<B07421@freescale.com>
In-Reply-To: <4F3D359E.6030209@freescale.com>
On 16.02.2012, at 17:58, Scott Wood wrote:
> On 02/16/2012 04:24 AM, Alexander Graf wrote:
>> On 16.02.2012, at 10:26, Liu Yu <yu.liu@freescale.com> wrote:
>>> +_GLOBAL(epapr_ev_idle)
>>> +epapr_ev_idle:
>>> + rlwinm r3,r1,0,0,31-THREAD_SHIFT /* current thread_info =
*/
>>> + lwz r4,TI_LOCAL_FLAGS(r3) /* set napping bit */
>>> + ori r4,r4,_TLF_NAPPING /* so when we take an exception */
>>> + stw r4,TI_LOCAL_FLAGS(r3) /* it will return to our caller =
*/
>>> +
>>> + wrteei 1
>>> +
>>> +idle_loop:
>>> + LOAD_REG_IMMEDIATE(r11, HC_VENDOR_EPAPR | HC_EV_IDLE)
>>> +
>>> +.global epapr_ev_idle_start
>>> +epapr_ev_idle_start:
>>> + li r3, -1
>>> + nop
>>> + nop
>>> + nop
>>=20
>> Can't you just bl into epapr_hypercall_start? You don't even have to =
save the old lr. because we never return anyways :)
>=20
> The interrupt will branch to LR, so no, we can't trash it or put it
> anywhere else.
Hrm. But we can clobber ctr, right? So how about we make the generic =
version do a bctr and then just do a small C wrapper that takes lr, =
moves it to ctr and branches to the generic one?
Then we don't have to replicate the hypercall code all over again for =
every invocation.
Alex
^ permalink raw reply
* Re: tlb flushing on Power
From: Seth Jennings @ 2012-02-16 17:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Robert Jennings, linuxppc-dev, Nitin Gupta, Dave Hansen
In-Reply-To: <4F356C7E.3070608@linux.vnet.ibm.com>
On 02/10/2012 01:14 PM, Seth Jennings wrote:
> On 02/08/2012 03:04 PM, Benjamin Herrenschmidt wrote:
>>
>>> You can look at https://lkml.org/lkml/2012/1/9/389 in zsmalloc-main.c,
>>> zs_[un]map_object() functions for the currently uses of set_pte() and
>>> __flush_tlb_one().
>>>
>>>> set_pte() is long gone on all archs really (or if it's still there it's
>>>> not meant to be used as is), use set_pte_at().
>>>
>>> Problem with set_pte_at() for us is that we don't have an mm_struct to pass
>>> because the mapping is not for a userspace process but for the kernel itself.
>>
>> Then use init_mm
>
> Thanks, that's what I was looking for.
>
>>> However, I do think this is the portable function we need to be using. Just
>>> need to figure out what to pass in for the mm_struct param.
>>>
>>>> __flush_tlb_one() doesn't mean anything as an arch independent
>>>> functionality. We have a local_flush_tlb_page() that -might- do what you
>>>> want but why in hell is that patch not using proper existing
>>>> interfaces ?
>>>
>>> flush_tlb_page() is the portable function we should be using. However,
>>> again, it requires a vma_area_struct. I'm not sure what we should be
>>> passing there.
>>
>> Do you need this to be CPU local flush or global ? In the later,
>> flush_tlb_kernel_range() is the right API.
>>
>> If you want per-cpu, we'll have to add a new arch hook.
>
> We have interrupts disabled, due to the get_cpu_var() on the percpu variable
> zs_map_area in zs_map_object(), while the allocation is mapped. So a CPU local
> would be what we need.
Hey Ben,
Just wanted to bump you again about this. You mentioned that if I wanted to
do a cpu-local flush of a single tlb entry, that there would have to be a new
hook. Is that right?
I've been looking through the powerpc arch and I thought that I might have
found the power analog to __flush_tlb_one() for x86 in local_flush_tlb_page()
with a NULL vma argument. This doesn't seem to work though, as indicated
by a crash when I tried it. After looking in tlbflush.h again, it seems
that local_flush_tlb_page() is a no-op when CONFIG_PPC_STD_MMU_64 is set,
as are almost ALL of the tlb flushing functions... which makes no sense to
me.
Any help you (or anyone) can give me would be greatly appreciated.
--
Seth
^ 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