* Re: [PATCH] mlx4_en: fix transmit of packages when blue frame is enabled
From: Eli Cohen @ 2011-10-05 8:15 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: Eli Cohen, netdev@vger.kernel.org, linuxppc-dev, Yevgeny Petrilin
In-Reply-To: <20111004202620.GA3455@oc1711230544.ibm.com>
On Tue, Oct 04, 2011 at 05:26:20PM -0300, Thadeu Lima de Souza Cascardo wrote:
I believe we have an endianess problem here. The source buffer is in
big endian - in x86 archs, it will rich the pci device unswapped since
both x86 and pci are little endian. In ppc, it wil be swapped by the
chipset so it will reach the device in little endian which is wrong.
So, in mlx4_bf_copy, you could loop over the buffer and swap32 the all
the dwords before the call to __iowrite64_copy. Of course which should
fix this in an arch independent manner. Let me know this works for
you.
> On Tue, Oct 04, 2011 at 08:02:12AM +0200, Benjamin Herrenschmidt wrote:
> > On Mon, 2011-10-03 at 17:53 -0300, Thadeu Lima de Souza Cascardo wrote:
> >
> > .../...
> >
> > > > Can you also send me the output of ethtool -i?
> > > > It seems that there is a problem with write combining on Power processors, we will check this issue.
> > > >
> > > > Yevgeny
> > >
> > > Hello, Yevgeny.
> > >
> > > You will find the output of ethtool -i below.
> > >
> > > I am copying Ben and powerpc list, in case this is an issue with Power
> > > processors. They can provide us some more insight into this.
> >
> > May I get some background please ? :-)
> >
> > I'm not aware of a specific issue with write combining but I'd need to
> > know more about what you are doing and the code to do it to comment on
> > whether it should work or not.
> >
> > Cheers,
> > Ben.
> >
> >
>
> Hello, Ben.
>
> Sorry for that. I am testing mlx4_en driver on a POWER. Yevgeny has
> added blue frame support, that does not require writing to the device
> memory to indicate a new packet (the doorbell register as it is called).
>
> Well, the ring is getting full with no interrupt or packets transmitted.
> I simply added a write to the doorbell register and it works for me.
> Yevgeny says this is not the right fix, claiming there is a problem with
> write combining on POWER. The code uses memory barriers, so I don't know
> why there is any problem.
>
> I am posting the code here to show better what the situation is.
> Yevgeny can tell more about the device and the driver.
>
> The code below is the driver as of now, including a diff with what I
> changed and had resulted OK for me. Before the blue frame support, the
> only code executed was the else part. I can't tell much what the device
> should be seeing and doing after the blue frame part of the code is
> executed. But it does send the packet if I write to the doorbell
> register.
>
> Yevgeny, can you tell us what the device should be doing and why you
> think this is a problem on POWER? Is it possible that this is simply a
> problem with the firmware version?
>
> Thanks,
> Cascardo.
>
> ---
> if (ring->bf_enabled && desc_size <= MAX_BF && !bounce &&
> !vlan_tag) {
> *(u32 *) (&tx_desc->ctrl.vlan_tag) |=
> ring->doorbell_qpn;
> op_own |= htonl((bf_index & 0xffff) << 8);
> /* Ensure new descirptor hits memory
> * before setting ownership of this descriptor to HW */
> wmb();
> tx_desc->ctrl.owner_opcode = op_own;
>
> wmb();
>
> mlx4_bf_copy(ring->bf.reg + ring->bf.offset, (unsigned
> long *) &tx_desc->ctrl,
> desc_size);
>
> wmb();
>
> ring->bf.offset ^= ring->bf.buf_size;
> } else {
> /* Ensure new descirptor hits memory
> * before setting ownership of this descriptor to HW */
> wmb();
> tx_desc->ctrl.owner_opcode = op_own;
> - wmb();
> - writel(ring->doorbell_qpn, ring->bf.uar->map +
> MLX4_SEND_DOORBELL);
> }
>
> + wmb();
> + writel(ring->doorbell_qpn, ring->bf.uar->map +
> MLX4_SEND_DOORBELL);
> +
> ---
^ permalink raw reply
* RE: [RFC PATCH 2/2 -mm] RapidIO: TSI721 Add DMA Engine support
From: Bounine, Alexandre @ 2011-10-05 2:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: Vinod Koul, linuxppc-dev, linux-kernel
In-Reply-To: <20111004185718.a5806a7e.akpm00@gmail.com>
Andrew Morton wrote:
>=20
> > > No, it can be used all over the place:
> drivers/net/irda/w83977af_ir.c,
> > > drivers/scsi/bnx2fc/bnx2fc_tgt.c,
> > > drivers/net/wireless/rt2x00/rt2x00pci.c,
> > > drivers/crypto/amcc/crypto4xx_core.c and many nmore.
> >
> > In this case I will happily use dma_zalloc_coherent() as soon as
> > it is available
>=20
> geeze, which of us is more lazy?
>=20
> Here we go...
>=20
I have an excuse - I am on vacation. Back to the office in almost two
weeks.
WebMail is the only tool for me right now ;)=20
^ permalink raw reply
* Re: [RFC PATCH 2/2 -mm] RapidIO: TSI721 Add DMA Engine support
From: Andrew Morton @ 2011-10-05 1:57 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: Vinod Koul, linuxppc-dev, linux-kernel
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E552022D6319@CORPEXCH1.na.ads.idt.com>
On Tue, 4 Oct 2011 18:38:09 -0700 "Bounine, Alexandre" <Alexandre.Bounine@idt.com> wrote:
> > No, it can be used all over the place: drivers/net/irda/w83977af_ir.c,
> > drivers/scsi/bnx2fc/bnx2fc_tgt.c,
> > drivers/net/wireless/rt2x00/rt2x00pci.c,
> > drivers/crypto/amcc/crypto4xx_core.c and many nmore.
>
> In this case I will happily use dma_zalloc_coherent() as soon as
> it is available
geeze, which of us is more lazy?
Here we go...
From: Andrew Morton <akpm@linux-foundation.org>
Subject: include/linux/dma-mapping.h: add dma_zalloc_coherent()
Lots of driver code does a dma_alloc_coherent() and then zeroes out the
memory with a memset. Make it easy for them.
Cc: Alexandre Bounine <alexandre.bounine@idt.com>
From: Andrew Morton <akpm@linux-foundation.org>
Subject: include-linux-dma-mappingh-add-dma_zalloc_coherent
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/DMA-API.txt | 7 +++++++
include/linux/dma-mapping.h | 10 ++++++++++
2 files changed, 17 insertions(+)
diff -puN include/linux/dma-mapping.h~include-linux-dma-mappingh-add-dma_zalloc_coherent include/linux/dma-mapping.h
--- a/include/linux/dma-mapping.h~include-linux-dma-mappingh-add-dma_zalloc_coherent
+++ a/include/linux/dma-mapping.h
@@ -1,6 +1,7 @@
#ifndef _LINUX_DMA_MAPPING_H
#define _LINUX_DMA_MAPPING_H
+#include <linux/string.h>
#include <linux/device.h>
#include <linux/err.h>
#include <linux/dma-attrs.h>
@@ -117,6 +118,15 @@ static inline int dma_set_seg_boundary(s
return -EIO;
}
+static inline void *dma_zalloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag)
+{
+ void *ret = dma_alloc_coherent(dev, size, dma_handle, flag);
+ if (ret)
+ memset(ret, 0, size);
+ return ret;
+}
+
#ifdef CONFIG_HAS_DMA
static inline int dma_get_cache_alignment(void)
{
diff -puN Documentation/DMA-API.txt~include-linux-dma-mappingh-add-dma_zalloc_coherent Documentation/DMA-API.txt
--- a/Documentation/DMA-API.txt~include-linux-dma-mappingh-add-dma_zalloc_coherent
+++ a/Documentation/DMA-API.txt
@@ -50,6 +50,13 @@ specify the GFP_ flags (see kmalloc) for
implementation may choose to ignore flags that affect the location of
the returned memory, like GFP_DMA).
+void *
+dma_zalloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag)
+
+Wraps dma_alloc_coherent() and also zeroes the returned memory if the
+allocation attempt succeeded.
+
void
dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
dma_addr_t dma_handle)
_
^ permalink raw reply
* RE: [RFC PATCH 2/2 -mm] RapidIO: TSI721 Add DMA Engine support
From: Bounine, Alexandre @ 2011-10-05 1:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: Vinod Koul, linuxppc-dev, linux-kernel
In-Reply-To: <20111004144353.18087914.akpm00@gmail.com>
Andrew Morton wrote:
>=20
> On Mon, 3 Oct 2011 10:53:45 -0700
> "Bounine, Alexandre" <Alexandre.Bounine@idt.com> wrote:
>=20
> > > > + memset(bd_ptr, 0, bd_num * sizeof(struct
tsi721_dma_desc));
> > > > +
> > > > + dev_dbg(dev, "DMA descriptors @ %p (phys =3D %llx)\n",
> > > > + bd_ptr, (unsigned long long)bd_phys);
> > > > +
> > > > + /* Allocate space for descriptor status FIFO */
> > > > + sts_size =3D (bd_num >=3D TSI721_DMA_MINSTSSZ) ?
> > > > + bd_num :
TSI721_DMA_MINSTSSZ;
> > > > + sts_size =3D roundup_pow_of_two(sts_size);
> > > > + sts_ptr =3D dma_alloc_coherent(dev,
> > > > + sts_size * sizeof(struct
> > tsi721_dma_sts),
> > > > + &sts_phys, GFP_KERNEL);
> > > > + if (!sts_ptr) {
> > > > + /* Free space allocated for DMA descriptors */
> > > > + dma_free_coherent(dev,
> > > > + bd_num * sizeof(struct
> > tsi721_dma_desc),
> > > > + bd_ptr, bd_phys);
> > > > + chan->bd_base =3D NULL;
> > > > + return -ENOMEM;
> > > > + }
> > > > +
> > > > + chan->sts_phys =3D sts_phys;
> > > > + chan->sts_base =3D sts_ptr;
> > > > + chan->sts_size =3D sts_size;
> > > > +
> > > > + memset(sts_ptr, 0, sts_size);
> > >
> > > You meant
> >
> > I really need it here. That status block tracks progress by keeping
> > non-zero addresses of processed descriptors.
>=20
> Confused. Are you saying that the use of "sts_size" there was
> intentional?
Sorry, somehow I mistakenly linked this comment to dma_zalloc_coherent()
because of use of memset.
Yes, it should be "sts_size * sizeof(struct tsi721_dma_sts)" as
allocated.
> > >
> > > --- a/drivers/rapidio/devices/tsi721.c~rapidio-tsi721-add-dma-
> engine-
> > > support-fix
> > > +++ a/drivers/rapidio/devices/tsi721.c
> > > @@ -1006,7 +1006,7 @@ static int tsi721_bdma_maint_init(struct
> > > priv->mdma.sts_base =3D sts_ptr;
> > > priv->mdma.sts_size =3D sts_size;
> > >
> > > - memset(sts_ptr, 0, sts_size);
> > > + memset(sts_ptr, 0, sts_size * sizeof(struct tsi721_dma_sts));
> > >
> > > dev_dbg(&priv->pdev->dev,
> > > "desc status FIFO @ %p (phys =3D %llx) size=3D0x%x\n",
> > >
> > > However that's at least two instances where you wanted a
> > > dma_zalloc_coherent(). How's about we give ourselves one?
> >
> > Does this mean that I am on hook for it as a "most frequent user"?
>=20
> No, it can be used all over the place: drivers/net/irda/w83977af_ir.c,
> drivers/scsi/bnx2fc/bnx2fc_tgt.c,
> drivers/net/wireless/rt2x00/rt2x00pci.c,
> drivers/crypto/amcc/crypto4xx_core.c and many nmore.
In this case I will happily use dma_zalloc_coherent() as soon as
it is available
^ permalink raw reply
* Re: [RFC PATCH 2/2 -mm] RapidIO: TSI721 Add DMA Engine support
From: Andrew Morton @ 2011-10-04 21:43 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: Vinod Koul, linux-kernel, linuxppc-dev
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E55202291E8D@CORPEXCH1.na.ads.idt.com>
On Mon, 3 Oct 2011 10:53:45 -0700
"Bounine, Alexandre" <Alexandre.Bounine@idt.com> wrote:
> > > + memset(bd_ptr, 0, bd_num * sizeof(struct tsi721_dma_desc));
> > > +
> > > + dev_dbg(dev, "DMA descriptors @ %p (phys = %llx)\n",
> > > + bd_ptr, (unsigned long long)bd_phys);
> > > +
> > > + /* Allocate space for descriptor status FIFO */
> > > + sts_size = (bd_num >= TSI721_DMA_MINSTSSZ) ?
> > > + bd_num : TSI721_DMA_MINSTSSZ;
> > > + sts_size = roundup_pow_of_two(sts_size);
> > > + sts_ptr = dma_alloc_coherent(dev,
> > > + sts_size * sizeof(struct
> tsi721_dma_sts),
> > > + &sts_phys, GFP_KERNEL);
> > > + if (!sts_ptr) {
> > > + /* Free space allocated for DMA descriptors */
> > > + dma_free_coherent(dev,
> > > + bd_num * sizeof(struct
> tsi721_dma_desc),
> > > + bd_ptr, bd_phys);
> > > + chan->bd_base = NULL;
> > > + return -ENOMEM;
> > > + }
> > > +
> > > + chan->sts_phys = sts_phys;
> > > + chan->sts_base = sts_ptr;
> > > + chan->sts_size = sts_size;
> > > +
> > > + memset(sts_ptr, 0, sts_size);
> >
> > You meant
>
> I really need it here. That status block tracks progress by keeping
> non-zero addresses of processed descriptors.
Confused. Are you saying that the use of "sts_size" there was
intentional?
> >
> > --- a/drivers/rapidio/devices/tsi721.c~rapidio-tsi721-add-dma-engine-
> > support-fix
> > +++ a/drivers/rapidio/devices/tsi721.c
> > @@ -1006,7 +1006,7 @@ static int tsi721_bdma_maint_init(struct
> > priv->mdma.sts_base = sts_ptr;
> > priv->mdma.sts_size = sts_size;
> >
> > - memset(sts_ptr, 0, sts_size);
> > + memset(sts_ptr, 0, sts_size * sizeof(struct tsi721_dma_sts));
> >
> > dev_dbg(&priv->pdev->dev,
> > "desc status FIFO @ %p (phys = %llx) size=0x%x\n",
> >
> > However that's at least two instances where you wanted a
> > dma_zalloc_coherent(). How's about we give ourselves one?
>
> Does this mean that I am on hook for it as a "most frequent user"?
No, it can be used all over the place: drivers/net/irda/w83977af_ir.c,
drivers/scsi/bnx2fc/bnx2fc_tgt.c,
drivers/net/wireless/rt2x00/rt2x00pci.c,
drivers/crypto/amcc/crypto4xx_core.c and many nmore.
^ permalink raw reply
* Re: [PATCH 49/55] video: irq: Remove IRQF_DISABLED
From: Florian Tobias Schandinat @ 2011-10-04 20:20 UTC (permalink / raw)
To: Yong Zhang
Cc: linux-fbdev, Paul Gortmaker, Laurent Pinchart, Daniel Walker,
linux-arch, Kukjin Kim, Tomi Valkeinen, Archit Taneja,
David Brown, Anatolij Gustschin, cbe-oss-dev, Wan ZongShun,
linux-arm-msm, Ben Dooks, tglx, linux-omap, linux-arm-kernel,
Geoff Levand, Jiri Kosina, linux-kernel, Bryan Huntsman,
Andrew Morton, linuxppc-dev
In-Reply-To: <1316681962-8217-50-git-send-email-yong.zhang0@gmail.com>
On 09/22/2011 08:59 AM, Yong Zhang wrote:
> Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
> We run all interrupt handlers with interrupts disabled
> and we even check and yell when an interrupt handler
> returns with interrupts enabled (see commit [b738a50a:
> genirq: Warn when handler enables interrupts]).
>
> So now this flag is a NOOP and can be removed.
>
> Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
> Acked-by: David Brown <davidb@codeaurora.org>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/au1200fb.c | 2 +-
> drivers/video/bf54x-lq043fb.c | 2 +-
> drivers/video/bfin-lq035q1-fb.c | 2 +-
> drivers/video/bfin-t350mcqb-fb.c | 2 +-
> drivers/video/bfin_adv7393fb.c | 2 +-
> drivers/video/mb862xx/mb862xxfbdrv.c | 4 ++--
> drivers/video/msm/mddi.c | 2 +-
> drivers/video/msm/mdp.c | 2 +-
> drivers/video/nuc900fb.c | 2 +-
> drivers/video/omap2/displays/panel-taal.c | 2 +-
> drivers/video/ps3fb.c | 2 +-
> drivers/video/pxa3xx-gcu.c | 2 +-
> drivers/video/pxafb.c | 2 +-
> drivers/video/s3c2410fb.c | 2 +-
> drivers/video/sa1100fb.c | 3 +--
> drivers/video/sh_mobile_lcdcfb.c | 2 +-
> drivers/video/tmiofb.c | 2 +-
> drivers/video/vt8500lcdfb.c | 2 +-
> 18 files changed, 19 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/video/au1200fb.c b/drivers/video/au1200fb.c
> index a19a40e..7200559 100644
> --- a/drivers/video/au1200fb.c
> +++ b/drivers/video/au1200fb.c
> @@ -1673,7 +1673,7 @@ static int __devinit au1200fb_drv_probe(struct platform_device *dev)
> /* Now hook interrupt too */
> irq = platform_get_irq(dev, 0);
> ret = request_irq(irq, au1200fb_handle_irq,
> - IRQF_DISABLED | IRQF_SHARED, "lcd", (void *)dev);
> + IRQF_SHARED, "lcd", (void *)dev);
> if (ret) {
> print_err("fail to request interrupt line %d (err: %d)",
> irq, ret);
> diff --git a/drivers/video/bf54x-lq043fb.c b/drivers/video/bf54x-lq043fb.c
> index 2464b91..56720fb 100644
> --- a/drivers/video/bf54x-lq043fb.c
> +++ b/drivers/video/bf54x-lq043fb.c
> @@ -633,7 +633,7 @@ static int __devinit bfin_bf54x_probe(struct platform_device *pdev)
> goto out7;
> }
>
> - if (request_irq(info->irq, bfin_bf54x_irq_error, IRQF_DISABLED,
> + if (request_irq(info->irq, bfin_bf54x_irq_error, 0,
> "PPI ERROR", info) < 0) {
> printk(KERN_ERR DRIVER_NAME
> ": unable to request PPI ERROR IRQ\n");
> diff --git a/drivers/video/bfin-lq035q1-fb.c b/drivers/video/bfin-lq035q1-fb.c
> index 23b6c4b..c633068 100644
> --- a/drivers/video/bfin-lq035q1-fb.c
> +++ b/drivers/video/bfin-lq035q1-fb.c
> @@ -695,7 +695,7 @@ static int __devinit bfin_lq035q1_probe(struct platform_device *pdev)
> goto out7;
> }
>
> - ret = request_irq(info->irq, bfin_lq035q1_irq_error, IRQF_DISABLED,
> + ret = request_irq(info->irq, bfin_lq035q1_irq_error, 0,
> DRIVER_NAME" PPI ERROR", info);
> if (ret < 0) {
> dev_err(&pdev->dev, "unable to request PPI ERROR IRQ\n");
> diff --git a/drivers/video/bfin-t350mcqb-fb.c b/drivers/video/bfin-t350mcqb-fb.c
> index d8de29f..d5e1267 100644
> --- a/drivers/video/bfin-t350mcqb-fb.c
> +++ b/drivers/video/bfin-t350mcqb-fb.c
> @@ -529,7 +529,7 @@ static int __devinit bfin_t350mcqb_probe(struct platform_device *pdev)
> goto out7;
> }
>
> - ret = request_irq(info->irq, bfin_t350mcqb_irq_error, IRQF_DISABLED,
> + ret = request_irq(info->irq, bfin_t350mcqb_irq_error, 0,
> "PPI ERROR", info);
> if (ret < 0) {
> printk(KERN_ERR DRIVER_NAME
> diff --git a/drivers/video/bfin_adv7393fb.c b/drivers/video/bfin_adv7393fb.c
> index 8486f54..811dd7f 100644
> --- a/drivers/video/bfin_adv7393fb.c
> +++ b/drivers/video/bfin_adv7393fb.c
> @@ -481,7 +481,7 @@ static int __devinit bfin_adv7393_fb_probe(struct i2c_client *client,
> goto out_4;
> }
>
> - if (request_irq(IRQ_PPI_ERROR, ppi_irq_error, IRQF_DISABLED,
> + if (request_irq(IRQ_PPI_ERROR, ppi_irq_error, 0,
> "PPI ERROR", fbdev) < 0) {
> dev_err(&client->dev, "unable to request PPI ERROR IRQ\n");
> ret = -EFAULT;
> diff --git a/drivers/video/mb862xx/mb862xxfbdrv.c b/drivers/video/mb862xx/mb862xxfbdrv.c
> index 12a634a..11a7a33 100644
> --- a/drivers/video/mb862xx/mb862xxfbdrv.c
> +++ b/drivers/video/mb862xx/mb862xxfbdrv.c
> @@ -738,7 +738,7 @@ static int __devinit of_platform_mb862xx_probe(struct platform_device *ofdev)
> if (mb862xx_gdc_init(par))
> goto io_unmap;
>
> - if (request_irq(par->irq, mb862xx_intr, IRQF_DISABLED,
> + if (request_irq(par->irq, mb862xx_intr, 0,
> DRV_NAME, (void *)par)) {
> dev_err(dev, "Cannot request irq\n");
> goto io_unmap;
> @@ -1074,7 +1074,7 @@ static int __devinit mb862xx_pci_probe(struct pci_dev *pdev,
> if (mb862xx_pci_gdc_init(par))
> goto io_unmap;
>
> - if (request_irq(par->irq, mb862xx_intr, IRQF_DISABLED | IRQF_SHARED,
> + if (request_irq(par->irq, mb862xx_intr, IRQF_SHARED,
> DRV_NAME, (void *)par)) {
> dev_err(dev, "Cannot request irq\n");
> goto io_unmap;
> diff --git a/drivers/video/msm/mddi.c b/drivers/video/msm/mddi.c
> index 178b072..4527cbf 100644
> --- a/drivers/video/msm/mddi.c
> +++ b/drivers/video/msm/mddi.c
> @@ -715,7 +715,7 @@ static int __devinit mddi_probe(struct platform_device *pdev)
>
> mddi->int_enable = 0;
> mddi_writel(mddi->int_enable, INTEN);
> - ret = request_irq(mddi->irq, mddi_isr, IRQF_DISABLED, "mddi",
> + ret = request_irq(mddi->irq, mddi_isr, 0, "mddi",
> &mddi->client_data);
> if (ret) {
> printk(KERN_ERR "mddi: failed to request enable irq!\n");
> diff --git a/drivers/video/msm/mdp.c b/drivers/video/msm/mdp.c
> index 2750ed2..cb2ddf1 100644
> --- a/drivers/video/msm/mdp.c
> +++ b/drivers/video/msm/mdp.c
> @@ -426,7 +426,7 @@ int mdp_probe(struct platform_device *pdev)
> goto error_get_clk;
> }
>
> - ret = request_irq(mdp->irq, mdp_isr, IRQF_DISABLED, "msm_mdp", mdp);
> + ret = request_irq(mdp->irq, mdp_isr, 0, "msm_mdp", mdp);
> if (ret)
> goto error_request_irq;
> disable_irq(mdp->irq);
> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
> index 37dd850..d1fbbd8 100644
> --- a/drivers/video/nuc900fb.c
> +++ b/drivers/video/nuc900fb.c
> @@ -587,7 +587,7 @@ static int __devinit nuc900fb_probe(struct platform_device *pdev)
> fbinfo->flags = FBINFO_FLAG_DEFAULT;
> fbinfo->pseudo_palette = &fbi->pseudo_pal;
>
> - ret = request_irq(irq, nuc900fb_irqhandler, IRQF_DISABLED,
> + ret = request_irq(irq, nuc900fb_irqhandler, 0,
> pdev->name, fbinfo);
> if (ret) {
> dev_err(&pdev->dev, "cannot register irq handler %d -err %d\n",
> diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c
> index 7f91002..80c3f6a 100644
> --- a/drivers/video/omap2/displays/panel-taal.c
> +++ b/drivers/video/omap2/displays/panel-taal.c
> @@ -1034,7 +1034,7 @@ static int taal_probe(struct omap_dss_device *dssdev)
> gpio_direction_input(gpio);
>
> r = request_irq(gpio_to_irq(gpio), taal_te_isr,
> - IRQF_DISABLED | IRQF_TRIGGER_RISING,
> + IRQF_TRIGGER_RISING,
> "taal vsync", dssdev);
>
> if (r) {
> diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
> index 65560a1..213fbbc 100644
> --- a/drivers/video/ps3fb.c
> +++ b/drivers/video/ps3fb.c
> @@ -1082,7 +1082,7 @@ static int __devinit ps3fb_probe(struct ps3_system_bus_device *dev)
> }
>
> retval = request_irq(ps3fb.irq_no, ps3fb_vsync_interrupt,
> - IRQF_DISABLED, DEVICE_NAME, &dev->core);
> + 0, DEVICE_NAME, &dev->core);
> if (retval) {
> dev_err(&dev->core, "%s: request_irq failed %d\n", __func__,
> retval);
> diff --git a/drivers/video/pxa3xx-gcu.c b/drivers/video/pxa3xx-gcu.c
> index d8de557..1ed8b36 100644
> --- a/drivers/video/pxa3xx-gcu.c
> +++ b/drivers/video/pxa3xx-gcu.c
> @@ -676,7 +676,7 @@ pxa3xx_gcu_probe(struct platform_device *dev)
> }
>
> ret = request_irq(irq, pxa3xx_gcu_handle_irq,
> - IRQF_DISABLED, DRV_NAME, priv);
> + 0, DRV_NAME, priv);
> if (ret) {
> dev_err(&dev->dev, "request_irq failed\n");
> ret = -EBUSY;
> diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
> index 0f4e8c9..e89778f 100644
> --- a/drivers/video/pxafb.c
> +++ b/drivers/video/pxafb.c
> @@ -2191,7 +2191,7 @@ static int __devinit pxafb_probe(struct platform_device *dev)
> goto failed_free_mem;
> }
>
> - ret = request_irq(irq, pxafb_handle_irq, IRQF_DISABLED, "LCD", fbi);
> + ret = request_irq(irq, pxafb_handle_irq, 0, "LCD", fbi);
> if (ret) {
> dev_err(&dev->dev, "request_irq failed: %d\n", ret);
> ret = -EBUSY;
> diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
> index 798144a..ee4c0df 100644
> --- a/drivers/video/s3c2410fb.c
> +++ b/drivers/video/s3c2410fb.c
> @@ -910,7 +910,7 @@ static int __devinit s3c24xxfb_probe(struct platform_device *pdev,
> for (i = 0; i < 256; i++)
> info->palette_buffer[i] = PALETTE_BUFF_CLEAR;
>
> - ret = request_irq(irq, s3c2410fb_irq, IRQF_DISABLED, pdev->name, info);
> + ret = request_irq(irq, s3c2410fb_irq, 0, pdev->name, info);
> if (ret) {
> dev_err(&pdev->dev, "cannot get irq %d - err %d\n", irq, ret);
> ret = -EBUSY;
> diff --git a/drivers/video/sa1100fb.c b/drivers/video/sa1100fb.c
> index e8b76d6..98d55d0 100644
> --- a/drivers/video/sa1100fb.c
> +++ b/drivers/video/sa1100fb.c
> @@ -1457,8 +1457,7 @@ static int __devinit sa1100fb_probe(struct platform_device *pdev)
> if (ret)
> goto failed;
>
> - ret = request_irq(irq, sa1100fb_handle_irq, IRQF_DISABLED,
> - "LCD", fbi);
> + ret = request_irq(irq, sa1100fb_handle_irq, 0, "LCD", fbi);
> if (ret) {
> printk(KERN_ERR "sa1100fb: request_irq failed: %d\n", ret);
> goto failed;
> diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
> index 4636f9d..facffc2 100644
> --- a/drivers/video/sh_mobile_lcdcfb.c
> +++ b/drivers/video/sh_mobile_lcdcfb.c
> @@ -1577,7 +1577,7 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, priv);
>
> - error = request_irq(i, sh_mobile_lcdc_irq, IRQF_DISABLED,
> + error = request_irq(i, sh_mobile_lcdc_irq, 0,
> dev_name(&pdev->dev), priv);
> if (error) {
> dev_err(&pdev->dev, "unable to request irq\n");
> diff --git a/drivers/video/tmiofb.c b/drivers/video/tmiofb.c
> index cd1c4dc..8e4a446 100644
> --- a/drivers/video/tmiofb.c
> +++ b/drivers/video/tmiofb.c
> @@ -744,7 +744,7 @@ static int __devinit tmiofb_probe(struct platform_device *dev)
> goto err_ioremap_vram;
> }
>
> - retval = request_irq(irq, &tmiofb_irq, IRQF_DISABLED,
> + retval = request_irq(irq, &tmiofb_irq, 0,
> dev_name(&dev->dev), info);
>
> if (retval)
> diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
> index c13c246..777c21d 100644
> --- a/drivers/video/vt8500lcdfb.c
> +++ b/drivers/video/vt8500lcdfb.c
> @@ -355,7 +355,7 @@ static int __devinit vt8500lcd_probe(struct platform_device *pdev)
> goto failed_free_palette;
> }
>
> - ret = request_irq(irq, vt8500lcd_handle_irq, IRQF_DISABLED, "LCD", fbi);
> + ret = request_irq(irq, vt8500lcd_handle_irq, 0, "LCD", fbi);
> if (ret) {
> dev_err(&pdev->dev, "request_irq failed: %d\n", ret);
> ret = -EBUSY;
^ permalink raw reply
* Re: [PATCH] mlx4_en: fix transmit of packages when blue frame is enabled
From: Thadeu Lima de Souza Cascardo @ 2011-10-04 20:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: netdev@vger.kernel.org, Eli Cohen, eli@dev.mellanox.co.il,
linuxppc-dev, Yevgeny Petrilin
In-Reply-To: <1317708132.29415.213.camel@pasglop>
On Tue, Oct 04, 2011 at 08:02:12AM +0200, Benjamin Herrenschmidt wrote:
> On Mon, 2011-10-03 at 17:53 -0300, Thadeu Lima de Souza Cascardo wrote:
>
> .../...
>
> > > Can you also send me the output of ethtool -i?
> > > It seems that there is a problem with write combining on Power processors, we will check this issue.
> > >
> > > Yevgeny
> >
> > Hello, Yevgeny.
> >
> > You will find the output of ethtool -i below.
> >
> > I am copying Ben and powerpc list, in case this is an issue with Power
> > processors. They can provide us some more insight into this.
>
> May I get some background please ? :-)
>
> I'm not aware of a specific issue with write combining but I'd need to
> know more about what you are doing and the code to do it to comment on
> whether it should work or not.
>
> Cheers,
> Ben.
>
>
Hello, Ben.
Sorry for that. I am testing mlx4_en driver on a POWER. Yevgeny has
added blue frame support, that does not require writing to the device
memory to indicate a new packet (the doorbell register as it is called).
Well, the ring is getting full with no interrupt or packets transmitted.
I simply added a write to the doorbell register and it works for me.
Yevgeny says this is not the right fix, claiming there is a problem with
write combining on POWER. The code uses memory barriers, so I don't know
why there is any problem.
I am posting the code here to show better what the situation is.
Yevgeny can tell more about the device and the driver.
The code below is the driver as of now, including a diff with what I
changed and had resulted OK for me. Before the blue frame support, the
only code executed was the else part. I can't tell much what the device
should be seeing and doing after the blue frame part of the code is
executed. But it does send the packet if I write to the doorbell
register.
Yevgeny, can you tell us what the device should be doing and why you
think this is a problem on POWER? Is it possible that this is simply a
problem with the firmware version?
Thanks,
Cascardo.
---
if (ring->bf_enabled && desc_size <= MAX_BF && !bounce &&
!vlan_tag) {
*(u32 *) (&tx_desc->ctrl.vlan_tag) |=
ring->doorbell_qpn;
op_own |= htonl((bf_index & 0xffff) << 8);
/* Ensure new descirptor hits memory
* before setting ownership of this descriptor to HW */
wmb();
tx_desc->ctrl.owner_opcode = op_own;
wmb();
mlx4_bf_copy(ring->bf.reg + ring->bf.offset, (unsigned
long *) &tx_desc->ctrl,
desc_size);
wmb();
ring->bf.offset ^= ring->bf.buf_size;
} else {
/* Ensure new descirptor hits memory
* before setting ownership of this descriptor to HW */
wmb();
tx_desc->ctrl.owner_opcode = op_own;
- wmb();
- writel(ring->doorbell_qpn, ring->bf.uar->map +
MLX4_SEND_DOORBELL);
}
+ wmb();
+ writel(ring->doorbell_qpn, ring->bf.uar->map +
MLX4_SEND_DOORBELL);
+
---
^ permalink raw reply
* Re: Request_irq fails for IRQ2
From: Scott Wood @ 2011-10-04 15:30 UTC (permalink / raw)
To: smitha.vanga; +Cc: linuxppc-dev
In-Reply-To: <40631E9A2581F14BA60888C87A76A1FE014773@HYD-MKD-MBX4.wipro.com>
On 10/04/2011 06:21 AM, smitha.vanga@wipro.com wrote:
> Hi Scott,
>
> I am able to register the IRQ now once I add the call irq_set_default_host in cpm2_pic.
> But when I call enable_irq the code throws the below warning and gives exception in enable irq at
> spin_unlock_irqrestore(&desc->lock, flags); in enable_irq.
>
>
> printk(KERN_WARNING "Unbalanced enable for IRQ %d\n", irq);
The IRQ is automatically enabled when you request it. Only call
enable_irq() if you previously called disable_irq().
-Scott
^ permalink raw reply
* Re: [PATCH] memory hotplug: Correct page reservation checking
From: Nathan Fontenot @ 2011-10-04 14:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: Greg KH, linuxppc-dev, linux-kernel
In-Reply-To: <20111003175022.50cbef7f.akpm00@gmail.com>
On 10/03/2011 07:50 PM, Andrew Morton wrote:
> On Mon, 26 Sep 2011 10:22:33 -0500
> Nathan Fontenot <nfont@austin.ibm.com> wrote:
>
>> The check to ensure that pages of recently added memory sections are correctly
>> marked as reserved before trying to online the memory is broken. The request
>> to online the memory fails with the following:
>>
>> kernel: section number XXX page number 256 not reserved, was it already online?
>>
>> This updates the page reservation checking to check the pages of each memory
>> section of the memory block being onlined individually.
>
> Why was this only noticed now? Is there something unusual about the
> way in which you're using it, or has nobody ever used this code, or...?
>
As far as I know it is only the powerpc/pseries code that uses the feature that
allows memory blocks in sysfs to span multiple memory sections. We do this
because on pseries memory add/remove is done on a per LMB basis and we can have
machine where an LMB spans multiple memory sections.
This was just noticed due to a lack of testing between the 2.6.38/39 kernels where
this feature originally went in and the current mainline kernel.
-Nathan
^ permalink raw reply
* RE: Request_irq fails for IRQ2
From: smitha.vanga @ 2011-10-04 13:55 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
In-Reply-To: <4E89EFB2.6060704@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]
Hi Scoot,
When I try to use a atomic varaible in my ISR I see a kernel crash . with mesage BUG: scheduling while atomic:
Below is the code :
My ISR
irqreturn_t cpld_irq_handler(int irq, void * dev_id, struct pt_regs *regs)
{
wake_up(&cpld_intr_wait);
atomic_inc(&cpld_intr_data); /* incrementing this will indicate the poll() that the interrupt is occured */
return 0;
}
DRIVER_INIT
static int __init gpio_init(void)
{
int ret = 0;
int virq;
atomic_set(&cpld_intr_data, 0); /* initialize the Interrupt indicator */
init_waitqueue_head(&cpld_intr_wait); /* Initialize the wait queue */
virq = irq_create_mapping(NULL, CPLD1_INTERRUPT);
if ((ret = request_irq(virq,cpld_irq_handler, 0, GPIO_CHAR_PATH, NULL))!=0)
{
printk(KERN_ERR "gpio_init: Could not grab IRQ line for CPLD ret = %d\n",ret);
goto err1;
}
if((s_nGPIOMajor = register_chrdev(MPC8247_DEVICE_MAJOR_NUM, GPIO_CHAR_PATH, &gpio_fops))<0)
{
GPIO_DBG2("GPIO_DRIVER : unable to get major %d\n", s_nGPIOMajor);
return s_nGPIOMajor;
}else{
GPIO_DBG2("GPIO_DRIVER : major = %x\n", s_nGPIOMajor );
}
return 0;
}
Regards,
Smitha
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
[-- Attachment #2: Type: text/html, Size: 4372 bytes --]
^ permalink raw reply
* RE: Request_irq fails for IRQ2
From: smitha.vanga @ 2011-10-04 11:21 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
In-Reply-To: <4E89EFB2.6060704@freescale.com>
Hi Scott,
I am able to register the IRQ now once I add the call irq_set_default_host i=
n cpm2_pic.
But when I call enable_irq the code throws the below warning and gives excep=
tion in enable irq at
spin_unlock_irqrestore(&desc->lock, flags); in enable_irq.
printk(KERN_WARNING "Unbalanced enable for IRQ %d\n", irq);
Regards,
Smitha
Please do not print this email unless it is absolutely necessary. =0A=
=0A=
The information contained in this electronic message and any attachments to=
this message are intended for the exclusive use of the addressee(s) and may=
contain proprietary, confidential or privileged information. If you are not=
the intended recipient, you should not disseminate, distribute or copy this=
e-mail. Please notify the sender immediately and destroy all copies of this=
message and any attachments. =0A=
=0A=
WARNING: Computer viruses can be transmitted via email. The recipient should=
check this email and any attachments for the presence of viruses. The compa=
ny accepts no liability for any damage caused by any virus transmitted by th=
is email. =0A=
=0A=
www.wipro.com
^ permalink raw reply
* ping: [PATCH] GXT4000P and GXT6500P support
From: nello martuscielli @ 2011-10-04 11:56 UTC (permalink / raw)
To: linuxppc-dev, linux-fbdev-devel; +Cc: Nico Macrionitisl
ping for: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072678.html
This patch adds support for GXT4000P and GXT6500P cards found on some
IBM pSeries machines.
GXT4000P/6000P and GXT4500P/6500P couples are identical from
software's point of view and are based on the same Raster Engine
(RC1000), except for a different reference clock for the PLL.
GXT6x00P models are equipped with an additional Geometry Engine
(GT1000) but this driver doesn't use it.
I see that even after 2 years, this patch still hasn't been added to
the official Linux kernel.
You will appreciate how little code this took to save everybody with a
GXT6500P card some trouble.
cheers,
Nello
--
CRUX PPC user on IBM POWER4+
^ permalink raw reply
* Re: [PATCH] libata: Convert LED disk trigger from IDE to libata
From: nello martuscielli @ 2011-10-04 11:35 UTC (permalink / raw)
To: Jörg Sommer; +Cc: Nico Macrionitis, linuxppc-dev
Hi Jorg,
you submitted the patch slightly modified by Acrux (from CruxPPC) [1]
Anyway this patch is widely used by any ibook/powerbook owners with
great satisfaction.
I also use this patch from Jan 2011 and i'd like to see it upstreamed.
Btw, guess you should add:
Signed-off-by: Joseph Jezak <josejx@gentoo.org>
Acked-by: Nico Macrionitis <acrux@cruxppc.org>
cheers,
Nello
[1] http://forums.gentoo.org/viewtopic-p-6550023.html#6550023
^ permalink raw reply
* Re: Request_irq fails for IRQ2
From: Vijay Nikam @ 2011-10-04 9:25 UTC (permalink / raw)
To: smitha.vanga; +Cc: scottwood, linuxppc-dev
In-Reply-To: <40631E9A2581F14BA60888C87A76A1FE0145F8@HYD-MKD-MBX4.wipro.com>
Smitha,
Do you have the entry of this device node in your DTS file?
if yes, then is the device is getting registered properly?
If you are writing platform driver then you can use 'platform_get_irq'
it returns the irq number,
which you can pass in the 'request_irq'. If it is a simple character
driver then to determine the
virtual irq number you can use 'ioremap', in this call you can pass
the HW IRQ number e.g. 20
and then pass in the 'request_irq'.
But in both cases you have to have this device node in your device
tree and should be registered,
otherwise it should be returning error and no virtual irq will be allocated=
.
As per your return value it seems the device node is not getting
registered, perhaps the entry is
missing in DTS file. Try with just ioremap and see if virtual irq is
returned properly.
Kind Regards,
Vijay Nikam
On Mon, Oct 3, 2011 at 7:57 PM, <smitha.vanga@wipro.com> wrote:
>
> Hi Scott,
>
> I try to request an IRQ (IRQ2 and IRQ3 which are ineterrupt no 20 and 21 =
in
> mpc8247)in my driver . The
> Call fails in setup_irq in Manage.c at /kernel/irq.
>
> Setup _irq returns -ENOSYS
>
> if (desc->irq_data.chip =3D=3D &no_irq_chip)
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return -ENOSYS;
>
>
> I found that I need to pass the virtual interrupt number instead of hardw=
are
> interrupt number.
> So I added below piece of code
>
> Below is the call to request irq in my driver.
>
> virq =3D irq_create_mapping(NULL, CPLD1_INTERRUPT);
>
>
>
>
> =A0=A0 if ((ret =3D request_irq(virq,cpld_irq_handler, 0, GPIO_CHAR_PATH,
> NULL))!=3D0)
> =A0=A0 {
> =A0=A0=A0=A0=A0 printk(KERN_ERR "gpio_init: Could not grab IRQ line for C=
PLD ret =3D
> %d\n",ret);
> =A0=A0=A0=A0=A0=A0=A0 =A0 goto err1;
> =A0=A0 }
>
>
> Now it fails in irq_create_mapping=A0=A0 with NO_IRQ error.
>
> if (controller =3D=3D NULL)
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 host =3D irq_default_host;
> else
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 host =3D irq_find_host(cont=
roller);
> if (host =3D=3D NULL) {
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 printk(KERN_WARNING "irq: n=
o irq host found for %s !\n",
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0 controll=
er->full_name);
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return NO_IRQ;
> =A0=A0=A0=A0=A0=A0=A0 }
>
>
> I just don't know what I should pass for host , also when I pass NULL for
> host . I see the default host is NULL..
> Could you please help me. My project delivery is near , I need=A0 help so=
on.
>
>
> Regards,
> Smitha
>
>
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments =
to
> this message are intended for the exclusive use of the addressee(s) and m=
ay
> contain proprietary, confidential or privileged information. If you are n=
ot
> the intended recipient, you should not disseminate, distribute or copy th=
is
> e-mail. Please notify the sender immediately and destroy all copies of th=
is
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient sho=
uld
> check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus transmitt=
ed
> by this email.
>
> www.wipro.com
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] PSeries: Cancel RTAS event scan before firmware flash
From: Subrata Modak @ 2011-10-04 7:54 UTC (permalink / raw)
To: Ravi K Nittala
Cc: Anton Blanchard, naveedaus, Michael Neuling, Pavaman, suzuki,
ranittal, Vishu, linuxppc-dev, Divya Vikas
In-Reply-To: <20111004074932.27428.81900.stgit@localhost6.localdomain6>
Also,
On Tue, 2011-10-04 at 13:19 +0530, Ravi K Nittala wrote:
> The RTAS firmware flash update is conducted using an RTAS call that is
> serialized by lock_rtas() which uses spin_lock. While the flash is in
> progress, rtasd performs scan for any RTAS events that are generated by
> the system. rtasd keeps scanning for the RTAS events generated on the
> machine. This is performed via workqueue mechanism. The rtas_event_scan()
> also uses an RTAS call to scan the events, eventually trying to acquire
> the spin_lock before issuing the request.
>
> The flash update takes a while to complete and during this time, any other
> RTAS call has to wait. In this case, rtas_event_scan() waits for a long time
> on the spin_lock resulting in a soft lockup.
>
> Fix: Just before the flash update is performed, the queued rtas_event_scan()
> work item is cancelled from the work queue so that there is no other RTAS
> call issued while the flash is in progress. After the flash completes, the
> system reboots and the rtas_event_scan() is rescheduled.
>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Ravi Nittala <ravi.nittala@in.ibm.com>
Reported-by: Divya Vikas <divya.vikas@in.ibm.com>
Regards--
Subrata
>
> ---
> arch/powerpc/include/asm/rtas.h | 6 ++++++
> arch/powerpc/kernel/rtas_flash.c | 6 ++++++
> arch/powerpc/kernel/rtasd.c | 7 +++++++
> 3 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
> index 58625d1..754723b 100644
> --- a/arch/powerpc/include/asm/rtas.h
> +++ b/arch/powerpc/include/asm/rtas.h
> @@ -245,6 +245,12 @@ extern int early_init_dt_scan_rtas(unsigned long node,
>
> extern void pSeries_log_error(char *buf, unsigned int err_type, int fatal);
>
> +#ifdef CONFIG_PPC_RTAS_DAEMON
> +extern void rtas_cancel_event_scan(void);
> +#else
> +static inline void rtas_cancel_event_scan(void) { }
> +#endif
> +
> /* Error types logged. */
> #define ERR_FLAG_ALREADY_LOGGED 0x0
> #define ERR_FLAG_BOOT 0x1 /* log was pulled from NVRAM on boot */
> diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
> index e037c74..4174b4b 100644
> --- a/arch/powerpc/kernel/rtas_flash.c
> +++ b/arch/powerpc/kernel/rtas_flash.c
> @@ -568,6 +568,12 @@ static void rtas_flash_firmware(int reboot_type)
> }
>
> /*
> + * Just before starting the firmware flash, cancel the event scan work
> + * to avoid any soft lockup issues.
> + */
> + rtas_cancel_event_scan();
> +
> + /*
> * NOTE: the "first" block must be under 4GB, so we create
> * an entry with no data blocks in the reserved buffer in
> * the kernel data segment.
> diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
> index 481ef06..1045ff4 100644
> --- a/arch/powerpc/kernel/rtasd.c
> +++ b/arch/powerpc/kernel/rtasd.c
> @@ -472,6 +472,13 @@ static void start_event_scan(void)
> &event_scan_work, event_scan_delay);
> }
>
> +/* Cancel the rtas event scan work */
> +void rtas_cancel_event_scan(void)
> +{
> + cancel_delayed_work_sync(&event_scan_work);
> +}
> +EXPORT_SYMBOL_GPL(rtas_cancel_event_scan);
> +
> static int __init rtas_init(void)
> {
> struct proc_dir_entry *entry;
>
^ permalink raw reply
* [PATCH] PSeries: Cancel RTAS event scan before firmware flash
From: Ravi K Nittala @ 2011-10-04 7:49 UTC (permalink / raw)
To: benh
Cc: Anton Blanchard, Subrata Modak, Michael Neuling, suzuki, ranittal,
linuxppc-dev, Divya Vikas
The RTAS firmware flash update is conducted using an RTAS call that is
serialized by lock_rtas() which uses spin_lock. While the flash is in
progress, rtasd performs scan for any RTAS events that are generated by
the system. rtasd keeps scanning for the RTAS events generated on the
machine. This is performed via workqueue mechanism. The rtas_event_scan()
also uses an RTAS call to scan the events, eventually trying to acquire
the spin_lock before issuing the request.
The flash update takes a while to complete and during this time, any other
RTAS call has to wait. In this case, rtas_event_scan() waits for a long time
on the spin_lock resulting in a soft lockup.
Fix: Just before the flash update is performed, the queued rtas_event_scan()
work item is cancelled from the work queue so that there is no other RTAS
call issued while the flash is in progress. After the flash completes, the
system reboots and the rtas_event_scan() is rescheduled.
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Ravi Nittala <ravi.nittala@in.ibm.com>
---
arch/powerpc/include/asm/rtas.h | 6 ++++++
arch/powerpc/kernel/rtas_flash.c | 6 ++++++
arch/powerpc/kernel/rtasd.c | 7 +++++++
3 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 58625d1..754723b 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -245,6 +245,12 @@ extern int early_init_dt_scan_rtas(unsigned long node,
extern void pSeries_log_error(char *buf, unsigned int err_type, int fatal);
+#ifdef CONFIG_PPC_RTAS_DAEMON
+extern void rtas_cancel_event_scan(void);
+#else
+static inline void rtas_cancel_event_scan(void) { }
+#endif
+
/* Error types logged. */
#define ERR_FLAG_ALREADY_LOGGED 0x0
#define ERR_FLAG_BOOT 0x1 /* log was pulled from NVRAM on boot */
diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index e037c74..4174b4b 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -568,6 +568,12 @@ static void rtas_flash_firmware(int reboot_type)
}
/*
+ * Just before starting the firmware flash, cancel the event scan work
+ * to avoid any soft lockup issues.
+ */
+ rtas_cancel_event_scan();
+
+ /*
* NOTE: the "first" block must be under 4GB, so we create
* an entry with no data blocks in the reserved buffer in
* the kernel data segment.
diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
index 481ef06..1045ff4 100644
--- a/arch/powerpc/kernel/rtasd.c
+++ b/arch/powerpc/kernel/rtasd.c
@@ -472,6 +472,13 @@ static void start_event_scan(void)
&event_scan_work, event_scan_delay);
}
+/* Cancel the rtas event scan work */
+void rtas_cancel_event_scan(void)
+{
+ cancel_delayed_work_sync(&event_scan_work);
+}
+EXPORT_SYMBOL_GPL(rtas_cancel_event_scan);
+
static int __init rtas_init(void)
{
struct proc_dir_entry *entry;
^ permalink raw reply related
* RE: Request_irq fails for IRQ2
From: smitha.vanga @ 2011-10-04 6:15 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
In-Reply-To: <4E89EFB2.6060704@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]
Hi Scott,
Thank you. But I am not very clear where exactly I need to call the irq_set_default_host().
And also for the second fix I did not understand or to make cpm2_pic_host non-static (in which case you should pass that).
in th previous mail what exactlyy you mean.
Thanks & Regards,
Smitha
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
[-- Attachment #2: Type: text/html, Size: 1791 bytes --]
^ permalink raw reply
* Re: [PATCH] mlx4_en: fix transmit of packages when blue frame is enabled
From: Benjamin Herrenschmidt @ 2011-10-04 6:02 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: netdev@vger.kernel.org, Eli Cohen, eli@dev.mellanox.co.il,
linuxppc-dev, Yevgeny Petrilin
In-Reply-To: <20111003205358.GB3596@oc1711230544.ibm.com>
On Mon, 2011-10-03 at 17:53 -0300, Thadeu Lima de Souza Cascardo wrote:
.../...
> > Can you also send me the output of ethtool -i?
> > It seems that there is a problem with write combining on Power processors, we will check this issue.
> >
> > Yevgeny
>
> Hello, Yevgeny.
>
> You will find the output of ethtool -i below.
>
> I am copying Ben and powerpc list, in case this is an issue with Power
> processors. They can provide us some more insight into this.
May I get some background please ? :-)
I'm not aware of a specific issue with write combining but I'd need to
know more about what you are doing and the code to do it to comment on
whether it should work or not.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] memory hotplug: Correct page reservation checking
From: Andrew Morton @ 2011-10-04 0:50 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: Greg KH, linuxppc-dev, linux-kernel
In-Reply-To: <4E8098B9.1080702@austin.ibm.com>
On Mon, 26 Sep 2011 10:22:33 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> The check to ensure that pages of recently added memory sections are correctly
> marked as reserved before trying to online the memory is broken. The request
> to online the memory fails with the following:
>
> kernel: section number XXX page number 256 not reserved, was it already online?
>
> This updates the page reservation checking to check the pages of each memory
> section of the memory block being onlined individually.
Why was this only noticed now? Is there something unusual about the
way in which you're using it, or has nobody ever used this code, or...?
^ permalink raw reply
* Re: [PATCH] mlx4_en: fix transmit of packages when blue frame is enabled
From: Thadeu Lima de Souza Cascardo @ 2011-10-03 20:53 UTC (permalink / raw)
To: Yevgeny Petrilin
Cc: netdev@vger.kernel.org, eli@dev.mellanox.co.il, linuxppc-dev,
Eli Cohen
In-Reply-To: <953B660C027164448AE903364AC447D2235DAA9D@MTLDAG02.mtl.com>
On Mon, Oct 03, 2011 at 02:56:08PM +0000, Yevgeny Petrilin wrote:
> > Hello, Yevgeny.
> >
> > We use a MT26448 (lspci -v output bellow) on a POWER7. Any other
> > information, tests or debug patches you want me to try, just tell me.
> >
> > I expected this was really not the proper fix, but thought it would be
> > better to send it than just guess. Any clues what the problem might be?
> > Perhaps, we would have to disable blue frame for this particular device?
> >
> > Regards,
> > Cascardo.
> >
> > ---
> > lspci output
> > 0006:01:00.0 Ethernet controller: Mellanox Technologies MT26448 [ConnectX EN 10GigE, PCIe 2.0 5GT/s] (rev b0)
> > ---
> > lspci -v output
> > 0006:01:00.0 0200: 15b3:6750 (rev b0)
> > Subsystem: 1014:0416
> > Flags: bus master, fast devsel, latency 0, IRQ 31
> > Memory at 3da47be00000 (64-bit, non-prefetchable) [size=1M]
> > Memory at 3da47c000000 (64-bit, prefetchable) [size=32M]
> > Expansion ROM at 3da47bf00000 [disabled] [size=1M]
> > Capabilities: [40] Power Management version 3
> > Capabilities: [48] Vital Product Data
> > Capabilities: [9c] MSI-X: Enable+ Count=128 Masked-
> > Capabilities: [60] Express Endpoint, MSI 00
> > Capabilities: [100] Alternative Routing-ID Interpretation (ARI)
> > Capabilities: [148] Device Serial Number 00-02-c9-03-00-0f-50-be
> > Kernel driver in use: mlx4_core
> > Kernel modules: mlx4_en, mlx4_core
> > ---
>
> Cascardo,
>
> Can you also send me the output of ethtool -i?
> It seems that there is a problem with write combining on Power processors, we will check this issue.
>
> Yevgeny
Hello, Yevgeny.
You will find the output of ethtool -i below.
I am copying Ben and powerpc list, in case this is an issue with Power
processors. They can provide us some more insight into this.
Thanks,
Cascardo.
---
# ethtool -i eth10
driver: mlx4_en
version: 1.5.4.1 (March 2011)
firmware-version: 2.9.4130
bus-info: 0006:01:00.0
^ permalink raw reply
* Re: [PATCH v2] powerpc: book3e: WSP: Add Chroma as a new WSP/PowerEN platform.
From: Scott Wood @ 2011-10-03 18:02 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <1317349675-18661-1-git-send-email-jimix@pobox.com>
On 09/29/2011 09:27 PM, Jimi Xenidis wrote:
> diff --git a/arch/powerpc/platforms/wsp/Kconfig b/arch/powerpc/platforms/wsp/Kconfig
> index ea2811c..a3eef8e 100644
> --- a/arch/powerpc/platforms/wsp/Kconfig
> +++ b/arch/powerpc/platforms/wsp/Kconfig
> @@ -1,6 +1,7 @@
> config PPC_WSP
> bool
> select PPC_A2
> + select GENERIC_TBSYNC
> select PPC_ICSWX
> select PPC_SCOM
> select PPC_XICS
> @@ -8,14 +9,20 @@ config PPC_WSP
> select PCI
> select PPC_IO_WORKAROUNDS if PCI
> select PPC_INDIRECT_PIO if PCI
> + select PPC_WSP_COPRO
> default n
>
> menu "WSP platform selection"
> depends on PPC_BOOK3E_64
>
> config PPC_PSR2
> - bool "PSR-2 platform"
> - select GENERIC_TBSYNC
> + bool "PowerEN System Reference Platform 2"
> + select EPAPR_BOOT
> + select PPC_WSP
> + default y
> +
> +config PPC_CHROMA
> + bool "PowerEN PCIe Chroma Card"
> select EPAPR_BOOT
> select PPC_WSP
> default y
This is an existing problem with PSR2, but please don't hide "default y"
in a menu (at least make it a menuconfig). As is, it's not obvious from
looking at the toplevel platforms menu that these platforms are enabled
at all.
Further, PPC_WSP doesn't build on non-SMP (undefined references to
boot_cpuid and get_hard_smp_processor_id in ics.c), but the platforms
that select it don't depend on SMP.
-Scott
^ permalink raw reply
* RE: [RFC PATCH 2/2 -mm] RapidIO: TSI721 Add DMA Engine support
From: Bounine, Alexandre @ 2011-10-03 17:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: Vinod Koul, linux-kernel, linuxppc-dev
In-Reply-To: <20110930151544.31875132.akpm00@gmail.com>
Andrew Morton wroye:
>=20
> On Fri, 30 Sep 2011 17:38:35 -0400
> Alexandre Bounine <alexandre.bounine@idt.com> wrote:
>=20
> > Adds support for DMA Engine API.
> >
> > Includes following changes:
> > - Modifies BDMA register offset definitions to support per-channel
> handling
> > - Separates BDMA channel reserved for RIO Maintenance requests
> > - Adds DMA Engine callback routines
> >
> > ...
> >
> > 5 files changed, 1029 insertions(+), 90 deletions(-)
>=20
> hm, what a lot of code.
This is mostly new stuff for that driver.
>=20
> > +config TSI721_DMA
> > + bool "IDT Tsi721 RapidIO DMA support"
> > + depends on RAPIDIO_TSI721
> > + default "n"
> > + select RAPIDIO_DMA_ENGINE
> > + help
> > + Enable DMA support for IDT Tsi721 PCIe-to-SRIO controller.
>=20
> Do we really need to offer this decision to the user? If possible it
> would be better to always enable the feature where that makes sense.
> Better code coverage, less maintenance effort, more effective testing
> effort, possibly cleaner code.
Agree. Influence of dmaengine here ;)
But we still need RAPIDIO_DMA_ENGINE option to control DMA
configuration for devices that are RIO targets only.=20
>=20
> >
> > ...
> >
> > +static int tsi721_bdma_ch_init(struct tsi721_bdma_chan *chan)
> > +{
> > + struct tsi721_dma_desc *bd_ptr;
> > + struct device *dev =3D chan->dchan.device->dev;
> > + u64 *sts_ptr;
> > + dma_addr_t bd_phys;
> > + dma_addr_t sts_phys;
> > + int sts_size;
> > + int bd_num =3D chan->bd_num;
> > +
> > + dev_dbg(dev, "Init Block DMA Engine, CH%d\n", chan->id);
> > +
> > + /* Allocate space for DMA descriptors */
> > + bd_ptr =3D dma_alloc_coherent(dev,
> > + bd_num * sizeof(struct tsi721_dma_desc),
> > + &bd_phys, GFP_KERNEL);
> > + if (!bd_ptr)
> > + return -ENOMEM;
> > +
> > + chan->bd_phys =3D bd_phys;
> > + chan->bd_base =3D bd_ptr;
> > +
> > + memset(bd_ptr, 0, bd_num * sizeof(struct tsi721_dma_desc));
> > +
> > + dev_dbg(dev, "DMA descriptors @ %p (phys =3D %llx)\n",
> > + bd_ptr, (unsigned long long)bd_phys);
> > +
> > + /* Allocate space for descriptor status FIFO */
> > + sts_size =3D (bd_num >=3D TSI721_DMA_MINSTSSZ) ?
> > + bd_num : TSI721_DMA_MINSTSSZ;
> > + sts_size =3D roundup_pow_of_two(sts_size);
> > + sts_ptr =3D dma_alloc_coherent(dev,
> > + sts_size * sizeof(struct
tsi721_dma_sts),
> > + &sts_phys, GFP_KERNEL);
> > + if (!sts_ptr) {
> > + /* Free space allocated for DMA descriptors */
> > + dma_free_coherent(dev,
> > + bd_num * sizeof(struct
tsi721_dma_desc),
> > + bd_ptr, bd_phys);
> > + chan->bd_base =3D NULL;
> > + return -ENOMEM;
> > + }
> > +
> > + chan->sts_phys =3D sts_phys;
> > + chan->sts_base =3D sts_ptr;
> > + chan->sts_size =3D sts_size;
> > +
> > + memset(sts_ptr, 0, sts_size);
>=20
> You meant
I really need it here. That status block tracks progress by keeping
non-zero addresses of processed descriptors.
=20
>=20
> --- a/drivers/rapidio/devices/tsi721.c~rapidio-tsi721-add-dma-engine-
> support-fix
> +++ a/drivers/rapidio/devices/tsi721.c
> @@ -1006,7 +1006,7 @@ static int tsi721_bdma_maint_init(struct
> priv->mdma.sts_base =3D sts_ptr;
> priv->mdma.sts_size =3D sts_size;
>=20
> - memset(sts_ptr, 0, sts_size);
> + memset(sts_ptr, 0, sts_size * sizeof(struct tsi721_dma_sts));
>=20
> dev_dbg(&priv->pdev->dev,
> "desc status FIFO @ %p (phys =3D %llx) size=3D0x%x\n",
>=20
> However that's at least two instances where you wanted a
> dma_zalloc_coherent(). How's about we give ourselves one?
Does this mean that I am on hook for it as a "most frequent user"?
>=20
>=20
> > + dev_dbg(dev,
> > + "desc status FIFO @ %p (phys =3D %llx) size=3D0x%x\n",
> > + sts_ptr, (unsigned long long)sts_phys, sts_size);
> > +
> > + /* Initialize DMA descriptors ring */
> > + bd_ptr[bd_num - 1].type_id =3D cpu_to_le32(DTYPE3 << 29);
> > + bd_ptr[bd_num - 1].next_lo =3D cpu_to_le32((u64)bd_phys &
> > +
TSI721_DMAC_DPTRL_MASK);
> > + bd_ptr[bd_num - 1].next_hi =3D cpu_to_le32((u64)bd_phys >> 32);
> > +
> > + /* Setup DMA descriptor pointers */
> > + iowrite32(((u64)bd_phys >> 32),
> > + chan->regs + TSI721_DMAC_DPTRH);
> > + iowrite32(((u64)bd_phys & TSI721_DMAC_DPTRL_MASK),
> > + chan->regs + TSI721_DMAC_DPTRL);
> > +
> > + /* Setup descriptor status FIFO */
> > + iowrite32(((u64)sts_phys >> 32),
> > + chan->regs + TSI721_DMAC_DSBH);
> > + iowrite32(((u64)sts_phys & TSI721_DMAC_DSBL_MASK),
> > + chan->regs + TSI721_DMAC_DSBL);
> > + iowrite32(TSI721_DMAC_DSSZ_SIZE(sts_size),
> > + chan->regs + TSI721_DMAC_DSSZ);
> > +
> > + /* Clear interrupt bits */
> > + iowrite32(TSI721_DMAC_INT_ALL,
> > + chan->regs + TSI721_DMAC_INT);
> > +
> > + ioread32(chan->regs + TSI721_DMAC_INT);
> > +
> > + /* Toggle DMA channel initialization */
> > + iowrite32(TSI721_DMAC_CTL_INIT, chan->regs + TSI721_DMAC_CTL);
> > + ioread32(chan->regs + TSI721_DMAC_CTL);
> > + chan->wr_count =3D chan->wr_count_next =3D 0;
> > + chan->sts_rdptr =3D 0;
> > + udelay(10);
> > +
> > + return 0;
> > +}
> > +
> >
> > ...
> >
> > +{
> > + /* Disable BDMA channel interrupts */
> > + iowrite32(0, chan->regs + TSI721_DMAC_INTE);
> > +
> > + tasklet_schedule(&chan->tasklet);
>=20
> I'm not seeing any tasklet_disable()s on the shutdown/rmmod paths. Is
> there anything here which prevents shutdown races against a
> still-pending tasklet?
Marked for review.
>=20
> > +}
> > +
> >
> > ...
> >
> > +static
> > +int tsi721_fill_desc(struct tsi721_bdma_chan *chan, struct
> tsi721_tx_desc *desc,
> > + struct scatterlist *sg, enum dma_rtype rtype, u32 sys_size)
> > +{
> > + struct tsi721_dma_desc *bd_ptr =3D desc->hw_desc;
> > + u64 rio_addr;
> > +
> > + if (sg_dma_len(sg) > TSI721_DMAD_BCOUNT1 + 1) {
> > + dev_err(chan->dchan.device->dev, "SG element is too
> large\n");
> > + return -EINVAL;
> > + }
> > +
> > + dev_dbg(chan->dchan.device->dev,
> > + "desc: 0x%llx, addr: 0x%llx len: 0x%x\n",
> > + (u64)desc->txd.phys, (unsigned long
> long)sg_dma_address(sg),
> > + sg_dma_len(sg));
> > +
> > + dev_dbg(chan->dchan.device->dev, "bd_ptr =3D %p did=3D%d
> raddr=3D0x%llx\n",
> > + bd_ptr, desc->destid, desc->rio_addr);
> > +
> > + /* Initialize DMA descriptor */
> > + bd_ptr->type_id =3D cpu_to_le32((DTYPE1 << 29) |
> > + (rtype << 19) | desc->destid);
> > + if (desc->interrupt)
> > + bd_ptr->type_id |=3D cpu_to_le32(TSI721_DMAD_IOF);
> > + bd_ptr->bcount =3D cpu_to_le32(((desc->rio_addr & 0x3) << 30) |
> > + (sys_size << 26) |
sg_dma_len(sg));
> > + rio_addr =3D (desc->rio_addr >> 2) |
> > + ((u64)(desc->rio_addr_u & 0x3) << 62);
> > + bd_ptr->raddr_lo =3D cpu_to_le32(rio_addr & 0xffffffff);
> > + bd_ptr->raddr_hi =3D cpu_to_le32(rio_addr >> 32);
> > + bd_ptr->t1.bufptr_lo =3D cpu_to_le32(
> > + (u64)sg_dma_address(sg) &
0xffffffff);
> > + bd_ptr->t1.bufptr_hi =3D cpu_to_le32((u64)sg_dma_address(sg) >>
> 32);
> > + bd_ptr->t1.s_dist =3D 0;
> > + bd_ptr->t1.s_size =3D 0;
> > +
> > + mb();
>=20
> Mystery barrier needs a comment explaining why it's here, please.
This
> is almost always the case with barriers.
Marked for review.
>=20
> > + return 0;
> > +}
> > +
> >
> > ...
> >
> > +static int tsi721_alloc_chan_resources(struct dma_chan *dchan)
> > +{
> > + struct tsi721_bdma_chan *chan =3D to_tsi721_chan(dchan);
> > + struct tsi721_device *priv =3D to_tsi721(dchan->device);
> > + struct tsi721_tx_desc *desc =3D NULL;
> > + LIST_HEAD(tmp_list);
> > + int i;
> > + int rc;
> > +
> > + if (chan->bd_base)
> > + return chan->bd_num - 1;
> > +
> > + /* Initialize BDMA channel */
> > + if (tsi721_bdma_ch_init(chan)) {
> > + dev_err(dchan->device->dev, "Unable to initialize data
DMA"
> > + " channel %d, aborting\n", chan->id);
> > + return -ENOMEM;
> > + }
> > +
> > + /* Allocate matching number of logical descriptors */
> > + desc =3D kzalloc((chan->bd_num - 1) * sizeof(struct
> tsi721_tx_desc),
> > + GFP_KERNEL);
>=20
> kcalloc() would be a better fit here.
Agree. Would look more clear.
>=20
> > + if (!desc) {
> > + dev_err(dchan->device->dev,
> > + "Failed to allocate logical descriptors\n");
> > + rc =3D -ENOMEM;
> > + goto err_out;
> > + }
> > +
> > + chan->tx_desc =3D desc;
> > +
> > + for (i =3D 0; i < chan->bd_num - 1; i++) {
> > + dma_async_tx_descriptor_init(&desc[i].txd, dchan);
> > + desc[i].txd.tx_submit =3D tsi721_tx_submit;
> > + desc[i].txd.flags =3D DMA_CTRL_ACK;
> > + INIT_LIST_HEAD(&desc[i].tx_list);
> > + list_add_tail(&desc[i].desc_node, &tmp_list);
> > + }
> > +
> > + spin_lock_bh(&chan->lock);
> > + list_splice(&tmp_list, &chan->free_list);
> > + chan->completed_cookie =3D dchan->cookie =3D 1;
> > + spin_unlock_bh(&chan->lock);
> > +
> > +#ifdef CONFIG_PCI_MSI
> > + if (priv->flags & TSI721_USING_MSIX) {
> > + /* Request interrupt service if we are in MSI-X mode */
> > + rc =3D request_irq(
> > + priv->msix[TSI721_VECT_DMA0_DONE +
chan->id].vector,
> > + tsi721_bdma_msix, 0,
> > + priv->msix[TSI721_VECT_DMA0_DONE + chan-
> >id].irq_name,
> > + (void *)chan);
> > +
> > + if (rc) {
> > + dev_dbg(dchan->device->dev,
> > + "Unable to allocate MSI-X interrupt for
"
> > + "BDMA%d-DONE\n", chan->id);
> > + goto err_out;
> > + }
> > +
> > + rc =3D request_irq(priv->msix[TSI721_VECT_DMA0_INT +
> > + chan->id].vector,
> > + tsi721_bdma_msix, 0,
> > + priv->msix[TSI721_VECT_DMA0_INT +
chan->id].irq_name,
> > + (void *)chan);
> > +
> > + if (rc) {
> > + dev_dbg(dchan->device->dev,
> > + "Unable to allocate MSI-X interrupt for
"
> > + "BDMA%d-INT\n", chan->id);
> > + free_irq(
> > + priv->msix[TSI721_VECT_DMA0_DONE +
> > + chan->id].vector,
> > + (void *)chan);
> > + rc =3D -EIO;
> > + goto err_out;
> > + }
> > + }
> > +#endif /* CONFIG_PCI_MSI */
> > +
> > + tsi721_bdma_interrupt_enable(chan, 1);
> > +
> > + return chan->bd_num - 1;
> > +
> > +err_out:
> > + kfree(desc);
> > + tsi721_bdma_ch_free(chan);
> > + return rc;
> > +}
> > +
> >
> > ...
> >
> > +static
> > +enum dma_status tsi721_tx_status(struct dma_chan *dchan,
> dma_cookie_t cookie,
> > + struct dma_tx_state *txstate)
> > +{
> > + struct tsi721_bdma_chan *bdma_chan =3D to_tsi721_chan(dchan);
> > + dma_cookie_t last_used;
> > + dma_cookie_t last_completed;
> > + int ret;
> > +
> > + spin_lock_irq(&bdma_chan->lock);
> > + last_completed =3D bdma_chan->completed_cookie;
> > + last_used =3D dchan->cookie;
> > + spin_unlock_irq(&bdma_chan->lock);
> > +
> > + ret =3D dma_async_is_complete(cookie, last_completed, last_used);
> > +
> > + dma_set_tx_state(txstate, last_completed, last_used, 0);
> > +
> > + dev_dbg(dchan->device->dev,
> > + "%s: exit, ret: %d, last_completed: %d, last_used:
%d\n",
> > + __func__, ret, last_completed, last_used);
> > +
> > + return ret;
> > +}
> > +
> > +static void tsi721_issue_pending(struct dma_chan *dchan)
> > +{
> > + struct tsi721_bdma_chan *chan =3D to_tsi721_chan(dchan);
> > +
> > + dev_dbg(dchan->device->dev, "%s: Entry\n", __func__);
> > +
> > + if (tsi721_dma_is_idle(chan)) {
> > + spin_lock_bh(&chan->lock);
> > + tsi721_advance_work(chan);
> > + spin_unlock_bh(&chan->lock);
> > + } else
> > + dev_dbg(dchan->device->dev,
> > + "%s: DMA channel still busy\n", __func__);
> > +}
>=20
> I really don't like that a "struct tsi721_bdma_chan *" is called
"chan"
> in come places and "bdma_chan" in others. "bdma_chan" is better.
>=20
Agree. "bdma_chan" gives more device-specific meaning.
Opposite comment that I have heard was that this driver uses "dma" too
much.
Will unify to "bdma_chan".
> The code takes that lock with spin_lock_bh() in some places and
> spin_lock_irq() in others. I trust there's some method to it all ;)
> Has
> it been carefully tested with lockdep enabled?
Ooops. Another prove that global replace does not work.
Cleared spin_lock_irqsave() well though ;)
lockdep is enabled on my test machine and it did not complain in
this case. I am using a test adopted from one in dmaengine and it
calls both routines that have spin_lock_irq().=20
>=20
> >
> > ...
> >
Thank you,
Alex.
^ permalink raw reply
* [PATCH] libata: Convert LED disk trigger from IDE to libata
From: Jörg Sommer @ 2011-10-03 16:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev, linux-kernel, linux-ide,
Richard Purdie, David S. Miller, Jeff Garzik, Paul Mackerras
Cc: Jörg Sommer
This patch converts the trigger for the LED at the front of Apple's
iBooks to libata. It's merely a replacement of the string ide by disk.
The patch is taken from http://dev.gentoo.org/~josejx/ata.patch. I've
asked Joseph Jezak if he intends to send this patch upstream, but as he
did not reply I'll do so.
---
arch/powerpc/configs/pmac32_defconfig | 2 +-
arch/powerpc/configs/ppc6xx_defconfig | 2 +-
drivers/ata/libata-core.c | 4 ++
drivers/ide/ide-disk.c | 2 +-
drivers/leds/Kconfig | 10 +++---
drivers/leds/Makefile | 2 +-
drivers/leds/ledtrig-disk.c | 64 +++++++++++++++++++++++++++++++++
drivers/leds/ledtrig-ide-disk.c | 64 ---------------------------------
drivers/macintosh/Kconfig | 11 +++---
drivers/macintosh/via-pmu-led.c | 4 +-
include/linux/leds.h | 6 ++--
11 files changed, 87 insertions(+), 84 deletions(-)
create mode 100644 drivers/leds/ledtrig-disk.c
delete mode 100644 drivers/leds/ledtrig-ide-disk.c
diff --git a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig
index f8b394a..cff5d4e 100644
--- a/arch/powerpc/configs/pmac32_defconfig
+++ b/arch/powerpc/configs/pmac32_defconfig
@@ -180,7 +180,7 @@ CONFIG_ADB=y
CONFIG_ADB_CUDA=y
CONFIG_ADB_PMU=y
CONFIG_ADB_PMU_LED=y
-CONFIG_ADB_PMU_LED_IDE=y
+CONFIG_ADB_PMU_LED_DISK=y
CONFIG_PMAC_APM_EMU=m
CONFIG_PMAC_MEDIABAY=y
CONFIG_PMAC_BACKLIGHT=y
diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig
index 04360f9..c56464d 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -471,7 +471,7 @@ CONFIG_ADB=y
CONFIG_ADB_CUDA=y
CONFIG_ADB_PMU=y
CONFIG_ADB_PMU_LED=y
-CONFIG_ADB_PMU_LED_IDE=y
+CONFIG_ADB_PMU_LED_DISK=y
CONFIG_PMAC_APM_EMU=y
CONFIG_PMAC_MEDIABAY=y
CONFIG_PMAC_BACKLIGHT=y
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4a3a5ae..d37e3a2 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -66,6 +66,7 @@
#include <asm/byteorder.h>
#include <linux/cdrom.h>
#include <linux/ratelimit.h>
+#include <linux/leds.h>
#include "libata.h"
#include "libata-transport.h"
@@ -4823,6 +4824,9 @@ void ata_qc_complete(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc->ap;
+ /* Trigger the LED (if available) */
+ ledtrig_disk_activity();
+
/* XXX: New EH and old EH use different mechanisms to
* synchronize EH with regular execution path.
*
diff --git a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
index 2747980..cb25bd6 100644
--- a/drivers/ide/ide-disk.c
+++ b/drivers/ide/ide-disk.c
@@ -186,7 +186,7 @@ static ide_startstop_t ide_do_rw_disk(ide_drive_t *drive, struct request *rq,
BUG_ON(drive->dev_flags & IDE_DFLAG_BLOCKED);
BUG_ON(rq->cmd_type != REQ_TYPE_FS);
- ledtrig_ide_activity();
+ ledtrig_disk_activity();
pr_debug("%s: %sing: block=%llu, sectors=%u, buffer=0x%08lx\n",
drive->name, rq_data_dir(rq) == READ ? "read" : "writ",
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index b591e72..1934d8a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -404,12 +404,12 @@ config LEDS_TRIGGER_TIMER
If unsure, say Y.
-config LEDS_TRIGGER_IDE_DISK
- bool "LED IDE Disk Trigger"
- depends on IDE_GD_ATA
- depends on LEDS_TRIGGERS
+config LEDS_TRIGGER_DISK
+ bool "LED Disk Trigger"
+ depends on IDE_GD_ATA || ATA
+ depends on LEDS_TRIGGERS
help
- This allows LEDs to be controlled by IDE disk activity.
+ This allows LEDs to be controlled by disk activity.
If unsure, say Y.
config LEDS_TRIGGER_HEARTBEAT
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index bbfd2e3..350cc89 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -49,7 +49,7 @@ obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
# LED Triggers
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
-obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK) += ledtrig-ide-disk.o
+obj-$(CONFIG_LEDS_TRIGGER_DISK) += ledtrig-disk.o
obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
obj-$(CONFIG_LEDS_TRIGGER_BACKLIGHT) += ledtrig-backlight.o
obj-$(CONFIG_LEDS_TRIGGER_GPIO) += ledtrig-gpio.o
diff --git a/drivers/leds/ledtrig-disk.c b/drivers/leds/ledtrig-disk.c
new file mode 100644
index 0000000..0ebb2eb
--- /dev/null
+++ b/drivers/leds/ledtrig-disk.c
@@ -0,0 +1,64 @@
+/*
+ * LED Disk Activity Trigger
+ *
+ * Copyright 2006 Openedhand Ltd.
+ *
+ * Author: Richard Purdie <rpurdie@openedhand.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/jiffies.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/timer.h>
+#include <linux/leds.h>
+
+static void ledtrig_disk_timerfunc(unsigned long data);
+
+DEFINE_LED_TRIGGER(ledtrig_disk);
+static DEFINE_TIMER(ledtrig_disk_timer, ledtrig_disk_timerfunc, 0, 0);
+static int disk_activity;
+static int disk_lastactivity;
+
+void ledtrig_disk_activity(void)
+{
+ disk_activity++;
+ if (!timer_pending(&ledtrig_disk_timer))
+ mod_timer(&ledtrig_disk_timer, jiffies + msecs_to_jiffies(10));
+}
+EXPORT_SYMBOL(ledtrig_disk_activity);
+
+static void ledtrig_disk_timerfunc(unsigned long data)
+{
+ if (disk_lastactivity != disk_activity) {
+ disk_lastactivity = disk_activity;
+ /* INT_MAX will set each LED to its maximum brightness */
+ led_trigger_event(ledtrig_disk, INT_MAX);
+ mod_timer(&ledtrig_disk_timer, jiffies + msecs_to_jiffies(10));
+ } else {
+ led_trigger_event(ledtrig_disk, LED_OFF);
+ }
+}
+
+static int __init ledtrig_disk_init(void)
+{
+ led_trigger_register_simple("disk-activity", &ledtrig_disk);
+ return 0;
+}
+
+static void __exit ledtrig_disk_exit(void)
+{
+ led_trigger_unregister_simple(ledtrig_disk);
+}
+
+module_init(ledtrig_disk_init);
+module_exit(ledtrig_disk_exit);
+
+MODULE_AUTHOR("Richard Purdie <rpurdie@openedhand.com>");
+MODULE_DESCRIPTION("LED Disk Activity Trigger");
+MODULE_LICENSE("GPL");
diff --git a/drivers/leds/ledtrig-ide-disk.c b/drivers/leds/ledtrig-ide-disk.c
deleted file mode 100644
index ec099fc..0000000
--- a/drivers/leds/ledtrig-ide-disk.c
+++ /dev/null
@@ -1,64 +0,0 @@
-/*
- * LED IDE-Disk Activity Trigger
- *
- * Copyright 2006 Openedhand Ltd.
- *
- * Author: Richard Purdie <rpurdie@openedhand.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#include <linux/module.h>
-#include <linux/jiffies.h>
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/timer.h>
-#include <linux/leds.h>
-
-static void ledtrig_ide_timerfunc(unsigned long data);
-
-DEFINE_LED_TRIGGER(ledtrig_ide);
-static DEFINE_TIMER(ledtrig_ide_timer, ledtrig_ide_timerfunc, 0, 0);
-static int ide_activity;
-static int ide_lastactivity;
-
-void ledtrig_ide_activity(void)
-{
- ide_activity++;
- if (!timer_pending(&ledtrig_ide_timer))
- mod_timer(&ledtrig_ide_timer, jiffies + msecs_to_jiffies(10));
-}
-EXPORT_SYMBOL(ledtrig_ide_activity);
-
-static void ledtrig_ide_timerfunc(unsigned long data)
-{
- if (ide_lastactivity != ide_activity) {
- ide_lastactivity = ide_activity;
- /* INT_MAX will set each LED to its maximum brightness */
- led_trigger_event(ledtrig_ide, INT_MAX);
- mod_timer(&ledtrig_ide_timer, jiffies + msecs_to_jiffies(10));
- } else {
- led_trigger_event(ledtrig_ide, LED_OFF);
- }
-}
-
-static int __init ledtrig_ide_init(void)
-{
- led_trigger_register_simple("ide-disk", &ledtrig_ide);
- return 0;
-}
-
-static void __exit ledtrig_ide_exit(void)
-{
- led_trigger_unregister_simple(ledtrig_ide);
-}
-
-module_init(ledtrig_ide_init);
-module_exit(ledtrig_ide_exit);
-
-MODULE_AUTHOR("Richard Purdie <rpurdie@openedhand.com>");
-MODULE_DESCRIPTION("LED IDE Disk Activity Trigger");
-MODULE_LICENSE("GPL");
diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index fa51af1..aeb7b2a 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -96,17 +96,16 @@ config ADB_PMU_LED
Support the front LED on Power/iBooks as a generic LED that can
be triggered by any of the supported triggers. To get the
behaviour of the old CONFIG_BLK_DEV_IDE_PMAC_BLINK, select this
- and the ide-disk LED trigger and configure appropriately through
- sysfs.
+ and the disk LED trigger and configure appropriately through sysfs.
-config ADB_PMU_LED_IDE
- bool "Use front LED as IDE LED by default"
+config ADB_PMU_LED_DISK
+ bool "Use front LED as a disk LED by default"
depends on ADB_PMU_LED
depends on LEDS_CLASS
select LEDS_TRIGGERS
- select LEDS_TRIGGER_IDE_DISK
+ select LEDS_TRIGGER_DISK
help
- This option makes the front LED default to the IDE trigger
+ This option makes the front LED default to the disk trigger
so that it blinks on IDE activity.
config PMAC_SMU
diff --git a/drivers/macintosh/via-pmu-led.c b/drivers/macintosh/via-pmu-led.c
index 19c3718..ae067ab 100644
--- a/drivers/macintosh/via-pmu-led.c
+++ b/drivers/macintosh/via-pmu-led.c
@@ -73,8 +73,8 @@ static void pmu_led_set(struct led_classdev *led_cdev,
static struct led_classdev pmu_led = {
.name = "pmu-led::front",
-#ifdef CONFIG_ADB_PMU_LED_IDE
- .default_trigger = "ide-disk",
+#ifdef CONFIG_ADB_PMU_LED_DISK
+ .default_trigger = "disk-activity",
#endif
.brightness_set = pmu_led_set,
};
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 5884def..3413358 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -161,10 +161,10 @@ extern void led_trigger_blink(struct led_trigger *trigger,
#endif
/* Trigger specific functions */
-#ifdef CONFIG_LEDS_TRIGGER_IDE_DISK
-extern void ledtrig_ide_activity(void);
+#ifdef CONFIG_LEDS_TRIGGER_DISK
+extern void ledtrig_disk_activity(void);
#else
-#define ledtrig_ide_activity() do {} while(0)
+#define ledtrig_disk_activity() do {} while(0)
#endif
/*
--
1.7.6.3
^ permalink raw reply related
* Re: Request_irq fails for IRQ2
From: Scott Wood @ 2011-10-03 17:24 UTC (permalink / raw)
To: smitha.vanga; +Cc: linuxppc-dev
In-Reply-To: <40631E9A2581F14BA60888C87A76A1FE0145F8@HYD-MKD-MBX4.wipro.com>
On 10/03/2011 09:27 AM, smitha.vanga@wipro.com wrote:
> I just don't know what I should pass for host , also when I pass NULL
> for host . I see the default host is NULL..
> Could you please help me. My project delivery is near , I need help soon.
Ideally you should just use the device tree to describe this device,
then you wouldn't have to deal with finding the pointer to the controller.
Otherwise, modify the cpm2_pic driver to either call
irq_set_default_host() (in which case NULL should work) or to make
cpm2_pic_host non-static (in which case you should pass that).
-Scott
^ permalink raw reply
* RE: [RFC PATCH 1/2] RapidIO: Add DMA Engine support for RIO data transfers
From: Bounine, Alexandre @ 2011-10-03 16:52 UTC (permalink / raw)
To: Vinod Koul, Dan; +Cc: linux-kernel, akpm, linuxppc-dev
In-Reply-To: <1317492077.1573.1839.camel@vkoul-udesk3>
Vmlub2QgS291bCB3cm90ZToNCj4gDQo+IE9uIEZyaSwgMjAxMS0wOS0zMCBhdCAxNzozOCAtMDQw
MCwgQWxleGFuZHJlIEJvdW5pbmUgd3JvdGU6DQo+IFBsZWFzZSBDQyAqbWFpbnRhaW5lcnMqIG9u
IHlvdXIgcGF0Y2hlcywgZ2V0X21haW50YWluZXJzLnBsIHdpbGwgdGVsbA0KPiB5b3Ugd2hvLiBB
ZGRpbmcgRGFuIGhlcmUNCg0KQmFzZWQgb24gaHR0cHM6Ly9sa21sLm9yZy9sa21sLzIwMTEvMi8x
NC82NyBhbmQgdXNlIG9mIERNQV9TTEFWRSBpbiB0aGlzDQpwYXRjaCBJIGRlY2lkZWQgdGhhdCB5
b3UgYXJlIHRoZSBiZXN0IG1hdGNoIGFtb25nIHR3byBhbmQgdGhlcmUgaXMgbm8gcmVhc29uDQp0
byBkaXN0dXJiIERhbiA7KSANCg0KPiA+IEFkZHMgRE1BIEVuZ2luZSBmcmFtZXdvcmsgc3VwcG9y
dCBpbnRvIFJhcGlkSU8gc3Vic3lzdGVtLg0KPiA+IFVzZXMgRE1BIEVuZ2luZSBETUFfU0xBVkUg
aW50ZXJmYWNlIHRvIGdlbmVyYXRlIGRhdGEgdHJhbnNmZXJzIHRvL2Zyb20gcmVtb3RlDQo+ID4g
UmFwaWRJTyB0YXJnZXQgZGV2aWNlcy4gVXNlcyBzY2F0dGVybGlzdCB0byBkZXNjcmliZSBsb2Nh
bCBkYXRhIGJ1ZmZlciBhbmQNCj4gPiBkbWFfY2hhbi5wcml2YXRlIG1lbWJlciB0byBwYXNzIHRh
cmdldCBzcGVjaWZpYyBpbmZvcm1hdGlvbi4gU3VwcG9ydHMgZmxhdA0KPiA+IGRhdGEgYnVmZmVy
IG9ubHkgZm9yIGEgcmVtb3RlIHNpZGUuDQo+IFRoZSB3YXkgZG1hZW5naW5lIHdvcmtzIHRvZGF5
IGlzIHRoYXQgaXQgZG9lc24ndCBrbm93IGFueXRoaW5nIGFib3V0DQo+IGNsaWVudCBzdWJzeXN0
ZW0uIEJ1dCB0aGlzIGJyaW5ncyBpbiBhIHN1YnN5c3RlbSBkZXRhaWxzIHRvIGRtYWVuZ2luZQ0K
PiB3aGljaCBJIGRvbid0IGFncmVlIHdpdGggeWV0Lg0KPiBXaHkgY2FuJ3Qgd2UgYWJzdHJhY3Qg
dGhpcyBvdXQ/Pw0KDQpUaGUgb25seSB0aGluZyB0aGF0IGJyaW5ncyBzdWJzeXN0ZW0ga25vd2xl
ZGdlIGludG8gZG1hZW5naW5lIGlzIERNQV9SQVBJRElPIGZsYWcuDQpJIGFtIGFjdHVhbGx5IG9u
IHRoZSBmZW5jZSBhYm91dCB0aGlzLiBGcm9tIFJhcGlkSU8gc2lkZSBwb2ludCBvZiB2aWV3IEkg
ZG8gbm90DQpuZWVkIHRoYXQgZmxhZyBhdCBhbGwuDQpSYXBpZElPIHVzZXMgYSBmaWx0ZXIgcm91
dGluZSB0aGF0IGlzIHN1ZmZpY2llbnQgdG8gaWRlbnRpZnkgZG1hZW5naW5lIGNoYW5uZWxzDQph
c3NvY2lhdGVkIHdpdGggc3BlY2lmaWMgUmFwaWRJTyBtcG9ydC4gVXNlIG9mIERNQV9TTEFWRSBm
bGFnIGlzIHNhZmUgaGVyZS4NClVzZSBvZiBwcml2YXRlIG1lbWJlciBvZiBkbWFfY2hhbiBpcyAi
cHJpdmF0ZSIgYnVzaW5lc3Mgb2YgUmFwaWRJTyBhbmQgZG9lcw0Kbm90IGJyZWFrIGFueXRoaW5n
LiANCg0KTXkgY29uY2VybiBoZXJlIGlzIHRoYXQgb3RoZXIgc3Vic3lzdGVtcyBtYXkgdXNlL3Jl
cXVlc3QgRE1BX1NMQVZFIGNoYW5uZWwocykgYXMgd2VsbA0KYW5kIHdyb25nZnVsbHkgYWNxdWly
ZSBvbmUgdGhhdCBiZWxvbmdzIHRvIFJhcGlkSU8uIEluIHRoaXMgY2FzZSBzZXBhcmF0aW9uIHdp
dGggYW5vdGhlcg0KZmxhZyBtYXkgaGF2ZSBhIHNlbnNlIC0gaXQgaXMgcG9zc2libGUgdG8gaGF2
ZSBhIHN5c3RlbSB0aGF0IHVzZXMgUmFwaWRJTw0KYW5kIG90aGVyICJ0cmFkaXRpb25hbCIgRE1B
IHNsYXZlIGNoYW5uZWwuDQoNClRoaXMgaXMgd2h5IEkgcHV0IHRoYXQgcHJvcG9zZWQgaW50ZXJm
YWNlIGZvciBkaXNjdXNzaW9uIGluc3RlYWQgb2Yga2VlcGluZyBldmVyeXRoaW5nDQppbnNpZGUg
b2YgUmFwaWRJTy4NCklmIHlvdSB0aGluayB0aGF0IHNpdHVhdGlvbiBhYm92ZSB3aWxsIG5vdCBo
YXBwZW4gSSB3aWxsIGJlIGhhcHB5IHRvIHJlbW92ZQ0KdGhhdCBzdWJzeXN0ZW0ga25vd2xlZGdl
IGZyb20gZG1hZW5naW5lIGZpbGVzLg0KDQpNeSBtb3N0IHJlY2VudCB0ZXN0IGltcGxlbWVudGF0
aW9uIHJ1bnMgd2l0aG91dCBETUFfUkFQSURJTyBmbGFnIHRob3VnaC4NCg0KPiANCj4gQWZ0ZXIg
Z29pbmcgdGhydSB0aGUgcGF0Y2gsIEkgZG8gbm90IGJlbGlldmUgdGhhdCB0aGlzIHRoaXMgaXMg
Y2FzZSBvZg0KPiBTTEFWRSB0cmFuc2ZlcnMsIERhbiBjYW4geW91IHBsZWFzZSB0YWtlIGEgbG9v
ayBhdCB0aGlzIHBhdGNoDQoNCkkgYWdyZWUsIHRoaXMgaXMgbm90IGEgY2FzZSBvZiAicHVyZSIg
c2xhdmUgdHJhbnNmZXJzIGJ1dCBleGlzdGluZyBETUFfU0xBVkUNCmludGVyZmFjZSBmaXRzIHdl
bGwgaW50byB0aGUgUmFwaWRJTyBvcGVyYXRpb25zLg0KDQpGaXJzdCwgd2UgaGF2ZSBvbmx5IG9u
ZSBtZW1vcnkgbWFwcGVkIGxvY2F0aW9uIG9uIHRoZSBob3N0IHNpZGUuIFdlIHRyYW5zZmVyDQpk
YXRhIHRvL2Zyb20gbG9jYXRpb24gdGhhdCBpcyBub3QgbWFwcGVkIGludG8gbWVtb3J5IG9uIHRo
ZSBzYW1lIHNpZGUuICANCg0KU2Vjb25kLCBoYXZpbmcgYWJpbGl0eSB0byBwYXNzIHByaXZhdGUg
dGFyZ2V0IGluZm9ybWF0aW9uIGFsbG93cyBtZSB0byBwYXNzDQppbmZvcm1hdGlvbiBhYm91dCBy
ZW1vdGUgdGFyZ2V0IGRldmljZSBvbiBwZXItdHJhbnNmZXIgYmFzaXMuDQoNCj4gDQo+IA0KPiA+
IFNpZ25lZC1vZmYtYnk6IEFsZXhhbmRyZSBCb3VuaW5lIDxhbGV4YW5kcmUuYm91bmluZUBpZHQu
Y29tPg0KPiA+IENjOiBWaW5vZCBLb3VsIDx2aW5vZC5rb3VsQGludGVsLmNvbT4NCj4gPiBDYzog
S3VtYXIgR2FsYSA8Z2FsYWtAa2VybmVsLmNyYXNoaW5nLm9yZz4NCj4gPiBDYzogTWF0dCBQb3J0
ZXIgPG1wb3J0ZXJAa2VybmVsLmNyYXNoaW5nLm9yZz4NCj4gPiBDYzogTGkgWWFuZyA8bGVvbGlA
ZnJlZXNjYWxlLmNvbT4NCj4gPiAtLS0NCj4gPiAgZHJpdmVycy9kbWEvZG1hZW5naW5lLmMgICB8
ICAgIDQgKysNCi4uLiBza2lwIC4uLg0KPiA+ICsjaWZkZWYgQ09ORklHX1JBUElESU9fRE1BX0VO
R0lORQ0KPiA+ICsNCj4gPiArI2luY2x1ZGUgPGxpbnV4L2RtYWVuZ2luZS5oPg0KPiA+ICsNCi4u
LiBza2lwIC4uLg0KPiA+ICsgKi8NCj4gPiArc3RydWN0IGRtYV9hc3luY190eF9kZXNjcmlwdG9y
ICpyaW9fZG1hX3ByZXBfc2xhdmVfc2coc3RydWN0IHJpb19kZXYgKnJkZXYsDQo+ID4gKwlzdHJ1
Y3QgZG1hX2NoYW4gKmRjaGFuLCBzdHJ1Y3QgcmlvX2RtYV9kYXRhICpkYXRhLA0KPiA+ICsJZW51
bSBkbWFfZGF0YV9kaXJlY3Rpb24gZGlyZWN0aW9uLCB1bnNpZ25lZCBsb25nIGZsYWdzKQ0KPiA+
ICt7DQo+ID4gKwlzdHJ1Y3QgZG1hX2FzeW5jX3R4X2Rlc2NyaXB0b3IgKnR4ZCA9IE5VTEw7DQo+
ID4gKwlzdHJ1Y3QgcmlvX2RtYV9leHQgcmlvX2V4dDsNCj4gPiArDQo+ID4gKwlyaW9fZXh0LmRl
c3RpZCA9IHJkZXYtPmRlc3RpZDsNCj4gPiArCXJpb19leHQucmlvX2FkZHJfdSA9IGRhdGEtPnJp
b19hZGRyX3U7DQo+ID4gKwlyaW9fZXh0LnJpb19hZGRyID0gZGF0YS0+cmlvX2FkZHI7DQo+ID4g
KwlyaW9fZXh0LndyX3R5cGUgPSBkYXRhLT53cl90eXBlOw0KPiA+ICsJZGNoYW4tPnByaXZhdGUg
PSAmcmlvX2V4dDsNCj4gPiArDQo+ID4gKwl0eGQgPSBkY2hhbi0+ZGV2aWNlLT5kZXZpY2VfcHJl
cF9zbGF2ZV9zZyhkY2hhbiwgZGF0YS0+c2csIGRhdGEtDQo+ID5zZ19sZW4sDQo+ID4gKwkJCQkJ
CSAgZGlyZWN0aW9uLCBmbGFncyk7DQo+ID4gKw0KPiA+ICsJcmV0dXJuIHR4ZDsNCj4gPiArfQ0K
PiA+ICtFWFBPUlRfU1lNQk9MX0dQTChyaW9fZG1hX3ByZXBfc2xhdmVfc2cpOw0KPiBZb3Ugc2hv
dWxkIG1vdmUgdGhlIHJkZXYgYW5kIGRhdGEgdG8gZG1hX3NsYXZlX2NvbmZpZywgdGhhdCB3YXkg
eW91DQo+IHNob3VsZCBiZSBhYmxlIHRvIHVzZSB0aGUgZXhpc3RpbmcgX3ByZXBfc2xhdmVfc2cg
ZnVuY3Rpb24uDQogDQpSYXBpZElPIG5ldHdvcmsgdXN1YWxseSBoYXMgbW9yZSB0aGFuIG9uZSBk
ZXZpY2UgYXR0YWNoZWQgdG8gaXQgYW5kDQpzaW5nbGUgRE1BIGNoYW5uZWwgbWF5IHNlcnZpY2Ug
ZGF0YSB0cmFuc2ZlcnMgdG8vZnJvbSBzZXZlcmFsIGRldmljZXMuDQpJbiB0aGlzIGNhc2UgZGV2
aWNlIGluZm9ybWF0aW9uIHNob3VsZCBiZSBwYXNzZWQgb24gcGVyLXRyYW5zZmVyIGJhc2lzLg0K
DQo+ID4gKw0KPiA+ICsjZW5kaWYgLyogQ09ORklHX1JBUElESU9fRE1BX0VOR0lORSAqLw0KPiA+
ICsNCi4uLiBza2lwIC4uLg0KPiA+ICsgKg0KPiA+ICsgKiBOb3RlOiBSYXBpZElPIHNwZWNpZmlj
YXRpb24gZGVmaW5lcyB3cml0ZSAoTldSSVRFKSBhbmQNCj4gPiArICogd3JpdGUtd2l0aC1yZXNw
b25zZSAoTldSSVRFX1IpIGRhdGEgdHJhbnNmZXIgb3BlcmF0aW9ucy4NCj4gPiArICogRXhpc3Rp
bmcgRE1BIGNvbnRyb2xsZXJzIHRoYXQgc2VydmljZSBSYXBpZElPIG1heSB1c2Ugb25lIG9mIHRo
ZXNlIG9wZXJhdGlvbnMNCj4gPiArICogZm9yIGVudGlyZSBkYXRhIHRyYW5zZmVyIG9yIHRoZWly
IGNvbWJpbmF0aW9uIHdpdGggb25seSB0aGUgbGFzdCBkYXRhIHBhY2tldA0KPiA+ICsgKiByZXF1
aXJlcyByZXNwb25zZS4NCj4gPiArICovDQo+ID4gK2VudW0gcmlvX3dyaXRlX3R5cGUgew0KPiA+
ICsJUkRXX0RFRkFVTFQsCQkvKiBkZWZhdWx0IG1ldGhvZCB1c2VkIGJ5IERNQSBkcml2ZXIgKi8N
Cj4gPiArCVJEV19BTExfTldSSVRFLAkJLyogYWxsIHBhY2tldHMgdXNlIE5XUklURSAqLw0KPiA+
ICsJUkRXX0FMTF9OV1JJVEVfUiwJLyogYWxsIHBhY2tldHMgdXNlIE5XUklURV9SICovDQo+ID4g
KwlSRFdfTEFTVF9OV1JJVEVfUiwJLyogbGFzdCBwYWNrZXQgdXNlcyBOV1JJVEVfUiwgYWxsIG90
aGVyIC0gTldSSVRFICovDQo+ID4gK307DQo+IFdoeSBub3QgdXNlIHRoZSBjdXJyZW50IG1lY2hh
bmlzbSBvZiBzcGVjaWZ5aW5nIGNhbGxiYWNrIG9yIEFDSyBmbGFncw0KPiBpZiB5b3Ugd2FudCBh
IHJlc3BvbnNlIG9yIG5vdC4NCg0KVGhhdCByZXNwb25zZSBpcyBoYW5kbGVkIGJ5IFJhcGlkSU8g
aGFyZHdhcmUgYW5kIGVuc3VyZXMgcmVsaWFibGUNCnBhY2tldCBkZWxpdmVyeSB3aGVuIHJlc3Bv
bnNlIGlzIHVzZWQuIFVzZXIgbWF5IG5vdCBuZWVkIGNhbGxiYWNrIG9yIEFDSw0KZm9yIGhpcyBv
cGVyYXRpb24gKGluIHRlcm1zIG9mIGRtYWVuZ2luZSkgYnV0IGVycm9yIGhhbmRsaW5nIHdpbGwg
YmUgaW5pdGlhdGVkDQppZiB0aGVyZSBpcyBubyByZXNwb25zZSBmcm9tIHRoZSB0YXJnZXQgZGV2
aWNlLiANCiANCj4gDQo+ID4gKw0KPiA+ICtzdHJ1Y3QgcmlvX2RtYV9leHQgew0KPiA+ICsJdTE2
IGRlc3RpZDsNCj4gPiArCXU2NCByaW9fYWRkcjsJLyogbG93IDY0LWJpdHMgb2YgNjYtYml0IFJh
cGlkSU8gYWRkcmVzcyAqLw0KPiA+ICsJdTggIHJpb19hZGRyX3U7ICAvKiB1cHBlciAyLWJpdHMg
b2YgNjYtYml0IFJhcGlkSU8gYWRkcmVzcyAqLw0KPiA+ICsJZW51bSByaW9fd3JpdGVfdHlwZSB3
cl90eXBlOyAvKiBwcmVmZXJyZWQgUklPIHdyaXRlIG9wZXJhdGlvbiB0eXBlICovDQo+ID4gK307
DQo+IHdpbGwgdGhpcyBhZGRyZXNzIHRyYW5zbGF0ZWQgdG8gYSBkbWFfYWRkcl90IG9yIG5vdD8N
Cg0KTm8uIFRoaXMgaXMgYSBSYXBpZElPIHNwZWNpZmljIGFkZHJlc3Mgb24gdGhlIHJlbW90ZSBk
ZXZpY2UuDQoNCj4gPiArDQo+ID4gK3N0cnVjdCByaW9fZG1hX2RhdGEgew0KPiA+ICsJLyogTG9j
YWwgZGF0YSAoYXMgc2NhdHRlcmxpc3QpICovDQo+ID4gKwlzdHJ1Y3Qgc2NhdHRlcmxpc3QJKnNn
OwkvKiBJL08gc2NhdHRlciBsaXN0ICovDQo+ID4gKwl1bnNpZ25lZCBpbnQJCXNnX2xlbjsJLyog
c2l6ZSBvZiBzY2F0dGVyIGxpc3QgKi8NCj4gPiArCS8qIFJlbW90ZSBkZXZpY2UgYWRkcmVzcyAo
ZmxhdCBidWZmZXIpICovDQouLi4uIHNraXAgLi4uDQo+ID4gICAqIHJpb19uYW1lIC0gR2V0IHRo
ZSB1bmlxdWUgUklPIGRldmljZSBpZGVudGlmaWVyDQo+ID4gICAqIEByZGV2OiBSSU8gZGV2aWNl
DQo+IA0KPiANCj4gLS0NCj4gflZpbm9kDQoNClJlZ2FyZHMsDQoNCkFsZXguDQoNCg==
^ 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