* RE: [PATCH v2 2/4] fsl-dma: remove attribute DMA_INTERRUPT of dmaengine
From: Liu Qiang-B32616 @ 2012-07-12 2:33 UTC (permalink / raw)
To: Ira W. Snyder
Cc: Vinod Koul, davem@davemloft.net, linux-crypto@vger.kernel.org,
Dan Williams, linuxppc-dev@lists.ozlabs.org,
herbert@gondor.hengli.org.au
In-Reply-To: <20120711161713.GC17539@ovro.caltech.edu>
> -----Original Message-----
> From: Ira W. Snyder [mailto:iws@ovro.caltech.edu]
> Sent: Thursday, July 12, 2012 12:17 AM
> To: Liu Qiang-B32616
> Cc: linux-crypto@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Vinod
> Koul; herbert@gondor.hengli.com.au; Dan Williams; davem@davemloft.net
> Subject: Re: [PATCH v2 2/4] fsl-dma: remove attribute DMA_INTERRUPT of
> dmaengine
>=20
> On Wed, Jul 11, 2012 at 05:00:53PM +0800, Qiang Liu wrote:
> > Delete attribute DMA_INTERRUPT because fsl-dma doesn't support this
> function,
> > exception will be thrown if talitos is used to offload xor at the same
> time.
> >
>=20
> Both drivers/misc/carma/carma-fpga.c and
> drivers/misc/carma/carma-fpga-program.c expect the DMA_INTERRUPT
> property, though they do not use it. The mask is set for historical
> reasons. It is safe to delete the line "dma_cap_set(DMA_INTERRUPT,
> mask);"
> from both drivers.
>=20
> I don't know which other drivers may expect this feature to be present.
> These are only the ones which I maintain.
The only place is in async_tx api which the feature is used. But it does no=
t
work fine as expected of DMA_INTERRUPT. In fsl-dma, it will raise a program
error if source or destination address is zero.
>=20
> Other than that, you can add my:
> Acked-by: Ira W. Snyder <iws@ovro.caltech.edu>
Thanks.
>=20
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Li Yang <leoli@freescale.com>
> > Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
> > ---
> > drivers/dma/fsldma.c | 31 -------------------------------
> > 1 files changed, 0 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> > index 8f84761..4f2f212 100644
> > --- a/drivers/dma/fsldma.c
> > +++ b/drivers/dma/fsldma.c
> > @@ -543,35 +543,6 @@ static void fsl_dma_free_chan_resources(struct
> dma_chan *dchan)
> > }
> >
> > static struct dma_async_tx_descriptor *
> > -fsl_dma_prep_interrupt(struct dma_chan *dchan, unsigned long flags)
> > -{
> > - struct fsldma_chan *chan;
> > - struct fsl_desc_sw *new;
> > -
> > - if (!dchan)
> > - return NULL;
> > -
> > - chan =3D to_fsl_chan(dchan);
> > -
> > - new =3D fsl_dma_alloc_descriptor(chan);
> > - if (!new) {
> > - chan_err(chan, "%s\n", msg_ld_oom);
> > - return NULL;
> > - }
> > -
> > - new->async_tx.cookie =3D -EBUSY;
> > - new->async_tx.flags =3D flags;
> > -
> > - /* Insert the link descriptor to the LD ring */
> > - list_add_tail(&new->node, &new->tx_list);
> > -
> > - /* Set End-of-link to the last link descriptor of new list */
> > - set_ld_eol(chan, new);
> > -
> > - return &new->async_tx;
> > -}
> > -
> > -static struct dma_async_tx_descriptor *
> > fsl_dma_prep_memcpy(struct dma_chan *dchan,
> > dma_addr_t dma_dst, dma_addr_t dma_src,
> > size_t len, unsigned long flags)
> > @@ -1352,12 +1323,10 @@ static int __devinit fsldma_of_probe(struct
> platform_device *op)
> > fdev->irq =3D irq_of_parse_and_map(op->dev.of_node, 0);
> >
> > dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
> > - dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
> > dma_cap_set(DMA_SG, fdev->common.cap_mask);
> > dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
> > fdev->common.device_alloc_chan_resources =3D
> fsl_dma_alloc_chan_resources;
> > fdev->common.device_free_chan_resources =3D
> fsl_dma_free_chan_resources;
> > - fdev->common.device_prep_dma_interrupt =3D fsl_dma_prep_interrupt;
> > fdev->common.device_prep_dma_memcpy =3D fsl_dma_prep_memcpy;
> > fdev->common.device_prep_dma_sg =3D fsl_dma_prep_sg;
> > fdev->common.device_tx_status =3D fsl_tx_status;
> > --
> > 1.7.5.1
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: Create dts of each core in CAMP mode for P1021RDB-PC
From: Kumar Gala @ 2012-07-12 3:16 UTC (permalink / raw)
To: Timur Tabi
Cc: McClintock Matthew-B29882, Xu Jiucheng-B37781,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FFD9439.2010901@freescale.com>
On Jul 11, 2012, at 9:56 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>> No, I think we should have at least one or two examples of AMP dts in =
upstream.
>=20
> We have more than that:
>=20
> ./p2020rdb_camp_core1.dts
> ./p1020rdb-pc_camp_core1.dts
> ./mpc8572ds_camp_core1.dts
> ./p2020rdb_camp_core0.dts
> ./p1020rdb-pc_camp_core0.dts
> ./mpc8572ds_camp_core0.dts
> ./p1020rdb_camp_core1.dts
> ./p1020rdb_camp_core0.dts
>=20
I'd be ok if we want to drop the p1020rdb as that board has been =
replaced w/the p1020rdb-pc.
- k=
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: Create dts of each core in CAMP mode for P1021RDB-PC
From: Tabi Timur-B04825 @ 2012-07-12 3:53 UTC (permalink / raw)
To: Kumar Gala
Cc: McClintock Matthew-B29882, Xu Jiucheng-B37781,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <67BB61E8-A581-4863-A8B7-3A793E0225EE@kernel.crashing.org>
Kumar Gala wrote:
>> >
>> >./p2020rdb_camp_core1.dts
>> >./p1020rdb-pc_camp_core1.dts
>> >./mpc8572ds_camp_core1.dts
>> >./p2020rdb_camp_core0.dts
>> >./p1020rdb-pc_camp_core0.dts
>> >./mpc8572ds_camp_core0.dts
>> >./p1020rdb_camp_core1.dts
>> >./p1020rdb_camp_core0.dts
>> >
> I'd be ok if we want to drop the p1020rdb as that board has been replaced=
w/the p1020rdb-pc.
How about dropping the P2020RDB as well? Then we have only two examples:=20
MPC8572DS and P1020RDB-PC.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* linux-next: manual merge of the kvm-ppc tree with the powerpc tree
From: Stephen Rothwell @ 2012-07-12 3:57 UTC (permalink / raw)
To: Alexander Graf
Cc: Michael Neuling, linux-kernel, linux-next, Paul Mackerras,
Bharat Bhushan, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]
Hi Alexander,
Today's linux-next merge of the kvm-ppc tree got a conflict in
arch/powerpc/kvm/booke_interrupts.S between commit c75df6f96c59
("powerpc: Fix usage of register macros getting ready for %r0 change")
from the powerpc tree and commit fc372c0843b8 ("booke: Added crit/mc
exception handler for e500v2") from the kvm-ppc tree.
I fixed it up (see below - could do with checking) and can carry the fix
as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/powerpc/kvm/booke_interrupts.S
index 8fd4b2a,09456c4..0000000
--- a/arch/powerpc/kvm/booke_interrupts.S
+++ b/arch/powerpc/kvm/booke_interrupts.S
@@@ -52,16 -53,21 +52,21 @@@
(1<<BOOKE_INTERRUPT_PROGRAM) | \
(1<<BOOKE_INTERRUPT_DTLB_MISS))
- .macro KVM_HANDLER ivor_nr
+ .macro KVM_HANDLER ivor_nr scratch srr0
_GLOBAL(kvmppc_handler_\ivor_nr)
/* Get pointer to vcpu and record exit number. */
- mtspr SPRN_SPRG_WSCRATCH0, r4
+ mtspr \scratch , r4
mfspr r4, SPRN_SPRG_RVCPU
- stw r3, VCPU_GPR(r3)(r4)
- stw r5, VCPU_GPR(r5)(r4)
- stw r6, VCPU_GPR(r6)(r4)
++ stw r3, VCPU_GPR(R3)(r4)
+ stw r5, VCPU_GPR(R5)(r4)
+ stw r6, VCPU_GPR(R6)(r4)
+ mfspr r3, \scratch
mfctr r5
- lis r6, kvmppc_resume_host@h
- stw r3, VCPU_GPR(r4)(r4)
++ stw r3, VCPU_GPR(R4)(r4)
stw r5, VCPU_CTR(r4)
+ mfspr r3, \srr0
+ lis r6, kvmppc_resume_host@h
+ stw r3, VCPU_PC(r4)
li r5, \ivor_nr
ori r6, r6, kvmppc_resume_host@l
mtctr r6
@@@ -99,12 -104,11 +103,11 @@@ _GLOBAL(kvmppc_handler_len
* r5: KVM exit number
*/
_GLOBAL(kvmppc_resume_host)
- stw r3, VCPU_GPR(R3)(r4)
mfcr r3
stw r3, VCPU_CR(r4)
- stw r7, VCPU_GPR(r7)(r4)
- stw r8, VCPU_GPR(r8)(r4)
- stw r9, VCPU_GPR(r9)(r4)
+ stw r7, VCPU_GPR(R7)(r4)
+ stw r8, VCPU_GPR(R8)(r4)
+ stw r9, VCPU_GPR(R9)(r4)
li r6, 1
slw r6, r6, r5
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: Create dts of each core in CAMP mode for P1021RDB-PC
From: Kumar Gala @ 2012-07-12 4:05 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: McClintock Matthew-B29882, Xu Jiucheng-B37781,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FFE4A28.2020405@freescale.com>
On Jul 11, 2012, at 10:53 PM, Tabi Timur-B04825 wrote:
> Kumar Gala wrote:
>>>>=20
>>>> ./p2020rdb_camp_core1.dts
>>>> ./p1020rdb-pc_camp_core1.dts
>>>> ./mpc8572ds_camp_core1.dts
>>>> ./p2020rdb_camp_core0.dts
>>>> ./p1020rdb-pc_camp_core0.dts
>>>> ./mpc8572ds_camp_core0.dts
>>>> ./p1020rdb_camp_core1.dts
>>>> ./p1020rdb_camp_core0.dts
>>>>=20
>> I'd be ok if we want to drop the p1020rdb as that board has been =
replaced w/the p1020rdb-pc.
>=20
> How about dropping the P2020RDB as well? Then we have only two =
examples:=20
> MPC8572DS and P1020RDB-PC.
I'm ok with dropping P2020RDB as well.
- k=
^ permalink raw reply
* Re: [RFC PATCH v3 3/13] memory-hotplug : unify argument of firmware_map_add_early/hotplug
From: Yasuaki Ishimatsu @ 2012-07-12 4:52 UTC (permalink / raw)
To: Dave Hansen
Cc: len.brown, wency, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, rientjes, cl, linuxppc-dev, akpm,
liuj97
In-Reply-To: <4FFD9C08.2070502@linux.vnet.ibm.com>
Hi Dave,
2012/07/12 0:30, Dave Hansen wrote:
> On 07/09/2012 03:25 AM, Yasuaki Ishimatsu wrote:
>> @@ -642,7 +642,7 @@ int __ref add_memory(int nid, u64 start,
>> }
>>
>> /* create new memmap entry */
>> - firmware_map_add_hotplug(start, start + size, "System RAM");
>> + firmware_map_add_hotplug(start, start + size - 1, "System RAM");
>
> I know the firmware_map_*() calls use inclusive end addresses
> internally, but do we really need to expose them? Both of the callers
> you mentioned do:
>
> firmware_map_add_hotplug(start, start + size - 1, "System RAM");
>
> or
>
> firmware_map_add_early(entry->addr,
> entry->addr + entry->size - 1,
> e820_type_to_string(entry->type));
>
> So it seems a _bit_ silly to keep all of the callers doing this size-1
> thing. I also noted that the new caller that you added does the same
> thing. Could we just change the external calling convention to be
> exclusive?
Thank you for your comment.
Does the following patch include your comment? If O.K., I will separate
the patch from the series and send it for bug fix.
---
arch/x86/kernel/e820.c | 2 +-
drivers/firmware/memmap.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
Index: linux-next/arch/x86/kernel/e820.c
===================================================================
--- linux-next.orig/arch/x86/kernel/e820.c 2012-07-02 09:50:23.000000000 +0900
+++ linux-next/arch/x86/kernel/e820.c 2012-07-12 13:30:45.942318179 +0900
@@ -944,7 +944,7 @@
for (i = 0; i < e820_saved.nr_map; i++) {
struct e820entry *entry = &e820_saved.map[i];
firmware_map_add_early(entry->addr,
- entry->addr + entry->size - 1,
+ entry->addr + entry->size,
e820_type_to_string(entry->type));
}
}
Index: linux-next/drivers/firmware/memmap.c
===================================================================
--- linux-next.orig/drivers/firmware/memmap.c 2012-07-02 09:50:26.000000000 +0900
+++ linux-next/drivers/firmware/memmap.c 2012-07-12 13:40:53.823318481 +0900
@@ -98,7 +98,7 @@
/**
* firmware_map_add_entry() - Does the real work to add a firmware memmap entry.
* @start: Start of the memory range.
- * @end: End of the memory range (inclusive).
+ * @end: End of the memory range.
* @type: Type of the memory range.
* @entry: Pre-allocated (either kmalloc() or bootmem allocator), uninitialised
* entry.
@@ -113,7 +113,7 @@
BUG_ON(start > end);
entry->start = start;
- entry->end = end;
+ entry->end = end - 1;
entry->type = type;
INIT_LIST_HEAD(&entry->list);
kobject_init(&entry->kobj, &memmap_ktype);
@@ -148,7 +148,7 @@
* firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
* memory hotplug.
* @start: Start of the memory range.
- * @end: End of the memory range (inclusive).
+ * @end: End of the memory range.
* @type: Type of the memory range.
*
* Adds a firmware mapping entry. This function is for memory hotplug, it is
@@ -175,7 +175,7 @@
/**
* firmware_map_add_early() - Adds a firmware mapping entry.
* @start: Start of the memory range.
- * @end: End of the memory range (inclusive).
+ * @end: End of the memory range.
* @type: Type of the memory range.
*
* Adds a firmware mapping entry. This function uses the bootmem allocator
^ permalink raw reply
* Re: linux-next: manual merge of the kvm-ppc tree with the powerpc tree
From: Alexander Graf @ 2012-07-12 5:56 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Michael Neuling, linux-kernel, linux-next, Paul Mackerras,
Bharat Bhushan, linuxppc-dev
In-Reply-To: <20120712135735.7678a50ffb107e3094af27b8@canb.auug.org.au>
On 12.07.2012, at 05:57, Stephen Rothwell wrote:
> Hi Alexander,
>=20
> Today's linux-next merge of the kvm-ppc tree got a conflict in
> arch/powerpc/kvm/booke_interrupts.S between commit c75df6f96c59
> ("powerpc: Fix usage of register macros getting ready for %r0 change")
> from the powerpc tree and commit fc372c0843b8 ("booke: Added crit/mc
> exception handler for e500v2") from the kvm-ppc tree.
>=20
> I fixed it up (see below - could do with checking) and can carry the =
fix
> as necessary.
Hrm. Ben already warned me that this will happen, so I did a test merge =
a few days ago. Back then I also had to change 2 other bits that were =
not conflicting, to get to code to actually compile.
Could you please do an s/VCPU_GPR(r/VCPU_GPR/R/g in =
arch/powerpc/kvm/booke_interrupts.S? I'd check if you actually need it =
myself, but the tree doesn't seem to be pushed out yet :).
Alex
> --=20
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
>=20
> diff --cc arch/powerpc/kvm/booke_interrupts.S
> index 8fd4b2a,09456c4..0000000
> --- a/arch/powerpc/kvm/booke_interrupts.S
> +++ b/arch/powerpc/kvm/booke_interrupts.S
> @@@ -52,16 -53,21 +52,21 @@@
> (1<<BOOKE_INTERRUPT_PROGRAM) | \
> (1<<BOOKE_INTERRUPT_DTLB_MISS))
>=20
> - .macro KVM_HANDLER ivor_nr
> + .macro KVM_HANDLER ivor_nr scratch srr0
> _GLOBAL(kvmppc_handler_\ivor_nr)
> /* Get pointer to vcpu and record exit number. */
> - mtspr SPRN_SPRG_WSCRATCH0, r4
> + mtspr \scratch , r4
> mfspr r4, SPRN_SPRG_RVCPU
> - stw r3, VCPU_GPR(r3)(r4)
> - stw r5, VCPU_GPR(r5)(r4)
> - stw r6, VCPU_GPR(r6)(r4)
> ++ stw r3, VCPU_GPR(R3)(r4)
> + stw r5, VCPU_GPR(R5)(r4)
> + stw r6, VCPU_GPR(R6)(r4)
> + mfspr r3, \scratch
> mfctr r5
> - lis r6, kvmppc_resume_host@h
> - stw r3, VCPU_GPR(r4)(r4)
> ++ stw r3, VCPU_GPR(R4)(r4)
> stw r5, VCPU_CTR(r4)
> + mfspr r3, \srr0
> + lis r6, kvmppc_resume_host@h
> + stw r3, VCPU_PC(r4)
> li r5, \ivor_nr
> ori r6, r6, kvmppc_resume_host@l
> mtctr r6
> @@@ -99,12 -104,11 +103,11 @@@ _GLOBAL(kvmppc_handler_len
> * r5: KVM exit number
> */
> _GLOBAL(kvmppc_resume_host)
> - stw r3, VCPU_GPR(R3)(r4)
> mfcr r3
> stw r3, VCPU_CR(r4)
> - stw r7, VCPU_GPR(r7)(r4)
> - stw r8, VCPU_GPR(r8)(r4)
> - stw r9, VCPU_GPR(r9)(r4)
> + stw r7, VCPU_GPR(R7)(r4)
> + stw r8, VCPU_GPR(R8)(r4)
> + stw r9, VCPU_GPR(R9)(r4)
>=20
> li r6, 1
> slw r6, r6, r5
^ permalink raw reply
* Re: linux-next: manual merge of the kvm-ppc tree with the powerpc tree
From: Stephen Rothwell @ 2012-07-12 6:23 UTC (permalink / raw)
To: Alexander Graf
Cc: Michael Neuling, linux-kernel, linux-next, Paul Mackerras,
Bharat Bhushan, linuxppc-dev
In-Reply-To: <B6C6F6EC-BDD9-41DC-9677-4B7A4A52BDF0@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]
Hi Alex,
On Thu, 12 Jul 2012 07:56:46 +0200 Alexander Graf <agraf@suse.de> wrote:
>
> On 12.07.2012, at 05:57, Stephen Rothwell wrote:
>
> > Today's linux-next merge of the kvm-ppc tree got a conflict in
> > arch/powerpc/kvm/booke_interrupts.S between commit c75df6f96c59
> > ("powerpc: Fix usage of register macros getting ready for %r0 change")
> > from the powerpc tree and commit fc372c0843b8 ("booke: Added crit/mc
> > exception handler for e500v2") from the kvm-ppc tree.
> >
> > I fixed it up (see below - could do with checking) and can carry the fix
> > as necessary.
>
> Hrm. Ben already warned me that this will happen, so I did a test merge a few days ago. Back then I also had to change 2 other bits that were not conflicting, to get to code to actually compile.
>
> Could you please do an s/VCPU_GPR(r/VCPU_GPR/R/g in arch/powerpc/kvm/booke_interrupts.S? I'd check if you actually need it myself, but the tree doesn't seem to be pushed out yet :).
Thanks for the response. I checked and I think I got them all. The
tree should be available as soon as the kernel.org mirroring gets done.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] powerpc: remove rejected merge file from arch/powerpc/kernel in linux-next
From: Gerard Snitselaar @ 2012-07-12 7:05 UTC (permalink / raw)
To: linux-next; +Cc: linuxppc-dev, linux-kernel, stuart.yoder
Commit 9778b696 (powerpc: Use CURRENT_THREAD_INFO instead of open
coded assembly) got a rejected merge file iommu.c.rej committed with
it.
Signed-off-by: Gerard Snitselaar <dev@snitselaar.org>
---
arch/powerpc/kernel/iommu.c.rej | 22 ----------------------
1 file changed, 22 deletions(-)
delete mode 100644 arch/powerpc/kernel/iommu.c.rej
diff --git a/arch/powerpc/kernel/iommu.c.rej b/arch/powerpc/kernel/iommu.c.rej
deleted file mode 100644
index 9d10d34..0000000
--- a/arch/powerpc/kernel/iommu.c.rej
+++ /dev/null
@@ -1,22 +0,0 @@
---- arch/powerpc/kernel/iommu.c 2012-06-08 09:01:02.785709100 +1000
-+++ arch/powerpc/kernel/iommu.c 2012-06-08 09:01:07.489784856 +1000
-@@ -33,7 +33,9 @@
- #include <linux/bitmap.h>
- #include <linux/iommu-helper.h>
- #include <linux/crash_dump.h>
-+#include <linux/fault-inject.h>
- #include <asm/io.h>
-+#include <asm/vio.h>
- #include <asm/prom.h>
- #include <asm/iommu.h>
- #include <asm/pci-bridge.h>
-@@ -171,6 +261,9 @@
- return DMA_ERROR_CODE;
- }
-
-+ if (should_fail_iommu(dev))
-+ return DMA_ERROR_CODE;
-+
- if (handle && *handle)
- start = *handle;
- else
--
1.7.11.1.165.g299666c
^ permalink raw reply related
* RE: [PATCH v2 3/4] fsl-dma: change the release process of dma descriptor
From: Liu Qiang-B32616 @ 2012-07-12 7:12 UTC (permalink / raw)
To: Ira W. Snyder
Cc: herbert@gondor.apana.org.au, Vinod Koul,
linux-crypto@vger.kernel.org, Dan Williams,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20120711163058.GD17539@ovro.caltech.edu>
> -----Original Message-----
> From: Ira W. Snyder [mailto:iws@ovro.caltech.edu]
> Sent: Thursday, July 12, 2012 12:31 AM
> To: Liu Qiang-B32616
> Cc: linux-crypto@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Vinod
> Koul; herbert@gondor.hengli.com.au; Dan Williams; davem@davemloft.net
> Subject: Re: [PATCH v2 3/4] fsl-dma: change the release process of dma
> descriptor
>=20
> On Wed, Jul 11, 2012 at 05:01:25PM +0800, Qiang Liu wrote:
> > Modify the release process of dma descriptor for avoiding exception
> when
> > enable config NET_DMA, release dma descriptor from 1st to last second,
> the
> > last descriptor which is reserved in current descriptor register may
> not be
> > completed, race condition will be raised if free current descriptor.
> >
> > A race condition which is raised when use both of talitos and dmaengine
> to
> > offload xor is because napi scheduler (NET_DMA is enabled) will sync
> all
> > pending requests in dma channels, it affects the process of raid
> operations.
> > The descriptor is freed which is submitted just now, but async_tx must
> check
> > whether this depend tx descriptor is acked, there are poison contents
> in the
> > invalid address, then BUG_ON() is thrown, so this descriptor will be
> freed
> > in the next time.
> >
>=20
> This patch seems to be covering up a bug in the driver, rather than
> actually fixing it.
Yes, it's fine for fsl-dma itself, but it cannot work under complex conditi=
on.
For example, we enable NET_DMA and SEC xor offload, if NAPI task is waken u=
p to
synchronize pending requests when raid5 dma copy was submitted, the process=
order
of raid5 tx descriptor is not as our expected. Unfortunately, sometime we h=
ave
to check this dependent tx descriptor which has was already released.
>=20
> When it was written, it was expected that dma_do_tasklet() would run
> only when the controller was idle.
>=20
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Li Yang <leoli@freescale.com>
> > Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
> > ---
> > drivers/dma/fsldma.c | 15 ++++++++++++---
> > 1 files changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> > index 4f2f212..0ba3e40 100644
> > --- a/drivers/dma/fsldma.c
> > +++ b/drivers/dma/fsldma.c
> > @@ -1035,14 +1035,22 @@ static irqreturn_t fsldma_chan_irq(int irq,
> void *data)
> > static void dma_do_tasklet(unsigned long data)
> > {
> > struct fsldma_chan *chan =3D (struct fsldma_chan *)data;
> > - struct fsl_desc_sw *desc, *_desc;
> > + struct fsl_desc_sw *desc, *_desc, *prev =3D NULL;
> > LIST_HEAD(ld_cleanup);
> > unsigned long flags;
> > + dma_addr_t curr_phys =3D get_cdar(chan);
> >
> > chan_dbg(chan, "tasklet entry\n");
> >
> > spin_lock_irqsave(&chan->desc_lock, flags);
> >
> > + /* find the descriptor which is already completed */
> > + list_for_each_entry_safe(desc, _desc, &chan->ld_running, node) {
> > + if (prev && desc->async_tx.phys =3D=3D curr_phys)
> > + break;
> > + prev =3D desc;
> > + }
> > +
>=20
> If the DMA controller was still busy processing transactions, you should
> have gotten the printout "irq: controller not idle!" from
> fsldma_chan_irq() just before it scheduled the dma_do_tasklet() to run.
> If you did not get this printout, how was dma_do_tasklet() entered with
> the controller still busy? I don't understand how it can happen.
Hi ira, this issue should be not related to dma status. The last descriptor
is left as usb null descriptor, actually, this descriptor is used as usb nu=
ll
descriptor, at any case, I believe it has been already completed, but I
will released it in next chain, it doesn't affect the upper api to use the
data, and make sure async_tx api won't raise an exception=20
(BUG_ON(async_tx_test_ack(depend_tx)), this depend_tx is the desc->async_tx=
).
>=20
> If you test without your spin_lock_bh() and spin_unlock_bh() conversion
> patch, do you still hit the error?
The error still happened. spin_lock_bh() and spin_unlock_bh() are modified
after this patch.
>=20
> What happens if a user submits exactly one DMA transaction, and then
> leaves the system idle? The callback for the last descriptor in the
> chain will never get run, right? That's a bug.
It won't be happened if use fsl-dma, because the right order is=20
xor-copy-xor->callback, The callback which you concerned is implemented=20
in talitos driver, callback should be null in fsl-dma.
>=20
> > /* update the cookie if we have some descriptors to cleanup */
> > if (!list_empty(&chan->ld_running)) {
> > dma_cookie_t cookie;
> > @@ -1058,13 +1066,14 @@ static void dma_do_tasklet(unsigned long data)
> > * move the descriptors to a temporary list so we can drop the lock
> > * during the entire cleanup operation
> > */
> > - list_splice_tail_init(&chan->ld_running, &ld_cleanup);
> > + list_cut_position(&ld_cleanup, &chan->ld_running, &prev->node);
> >
> > /* the hardware is now idle and ready for more */
> > chan->idle =3D true;
> >
> > /*
> > - * Start any pending transactions automatically
> > + * Start any pending transactions automatically if current
> descriptor
> > + * list is completed
> > *
> > * In the ideal case, we keep the DMA controller busy while we go
> > * ahead and free the descriptors below.
> > --
> > 1.7.5.1
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* RE: [PATCH v2 3/4] fsl-dma: change the release process of dma descriptor
From: Liu Qiang-B32616 @ 2012-07-12 8:50 UTC (permalink / raw)
To: Liu Qiang-B32616, Ira W. Snyder
Cc: herbert@gondor.apana.org.au, Vinod Koul,
linux-crypto@vger.kernel.org, Dan Williams,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <BCB48C05FCE8BC4D9E61E841ECBE6DB70C0916@039-SN2MPN1-011.039d.mgd.msft.net>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+qiang.liu=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Liu Qian=
g-
> B32616
> Sent: Thursday, July 12, 2012 3:12 PM
> To: Ira W. Snyder
> Cc: herbert@gondor.apana.org.au; Vinod Koul; linux-crypto@vger.kernel.org=
;
> Dan Williams; linuxppc-dev@lists.ozlabs.org; davem@davemloft.net
> Subject: RE: [PATCH v2 3/4] fsl-dma: change the release process of dma
> descriptor
>=20
> > -----Original Message-----
> > From: Ira W. Snyder [mailto:iws@ovro.caltech.edu]
> > Sent: Thursday, July 12, 2012 12:31 AM
> > To: Liu Qiang-B32616
> > Cc: linux-crypto@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Vinod
> > Koul; herbert@gondor.hengli.com.au; Dan Williams; davem@davemloft.net
> > Subject: Re: [PATCH v2 3/4] fsl-dma: change the release process of dma
> > descriptor
> >
> > On Wed, Jul 11, 2012 at 05:01:25PM +0800, Qiang Liu wrote:
> > > Modify the release process of dma descriptor for avoiding exception
> > when
> > > enable config NET_DMA, release dma descriptor from 1st to last
> > > second,
> > the
> > > last descriptor which is reserved in current descriptor register may
> > not be
> > > completed, race condition will be raised if free current descriptor.
> > >
> > > A race condition which is raised when use both of talitos and
> > > dmaengine
> > to
> > > offload xor is because napi scheduler (NET_DMA is enabled) will sync
> > all
> > > pending requests in dma channels, it affects the process of raid
> > operations.
> > > The descriptor is freed which is submitted just now, but async_tx
> > > must
> > check
> > > whether this depend tx descriptor is acked, there are poison
> > > contents
> > in the
> > > invalid address, then BUG_ON() is thrown, so this descriptor will be
> > freed
> > > in the next time.
> > >
> >
> > This patch seems to be covering up a bug in the driver, rather than
> > actually fixing it.
> Yes, it's fine for fsl-dma itself, but it cannot work under complex
> condition.
> For example, we enable NET_DMA and SEC xor offload, if NAPI task is waken
> up to synchronize pending requests when raid5 dma copy was submitted, the
> process order of raid5 tx descriptor is not as our expected.
> Unfortunately, sometime we have to check this dependent tx descriptor
> which has was already released.
>=20
> >
> > When it was written, it was expected that dma_do_tasklet() would run
> > only when the controller was idle.
> >
> > > Cc: Dan Williams <dan.j.williams@intel.com>
> > > Cc: Vinod Koul <vinod.koul@intel.com>
> > > Cc: Li Yang <leoli@freescale.com>
> > > Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
> > > ---
> > > drivers/dma/fsldma.c | 15 ++++++++++++---
> > > 1 files changed, 12 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index
> > > 4f2f212..0ba3e40 100644
> > > --- a/drivers/dma/fsldma.c
> > > +++ b/drivers/dma/fsldma.c
> > > @@ -1035,14 +1035,22 @@ static irqreturn_t fsldma_chan_irq(int irq,
> > void *data)
> > > static void dma_do_tasklet(unsigned long data) {
> > > struct fsldma_chan *chan =3D (struct fsldma_chan *)data;
> > > - struct fsl_desc_sw *desc, *_desc;
> > > + struct fsl_desc_sw *desc, *_desc, *prev =3D NULL;
> > > LIST_HEAD(ld_cleanup);
> > > unsigned long flags;
> > > + dma_addr_t curr_phys =3D get_cdar(chan);
> > >
> > > chan_dbg(chan, "tasklet entry\n");
> > >
> > > spin_lock_irqsave(&chan->desc_lock, flags);
> > >
> > > + /* find the descriptor which is already completed */
> > > + list_for_each_entry_safe(desc, _desc, &chan->ld_running, node) {
> > > + if (prev && desc->async_tx.phys =3D=3D curr_phys)
> > > + break;
> > > + prev =3D desc;
> > > + }
> > > +
> >
> > If the DMA controller was still busy processing transactions, you
> > should have gotten the printout "irq: controller not idle!" from
> > fsldma_chan_irq() just before it scheduled the dma_do_tasklet() to run.
> > If you did not get this printout, how was dma_do_tasklet() entered
> > with the controller still busy? I don't understand how it can happen.
> Hi ira, this issue should be not related to dma status. The last
> descriptor is left as usb null descriptor, actually, this descriptor is
> used as usb null descriptor, at any case, I believe it has been already
> completed, but I will released it in next chain, it doesn't affect the
> upper api to use the data, and make sure async_tx api won't raise an
> exception (BUG_ON(async_tx_test_ack(depend_tx)), this depend_tx is the
> desc->async_tx).
I consider your concerns carefully, I think my implement is not a good/righ=
t
way.
First, there is possibility that happen to the callback is ignored.
Second, I missed some better ways which can resolve this issue, actually
async_tx api provide our methods to avoid this.
So, I agree with your concern. Thanks.
I will resolve your concerns in next version. Thanks again.
>=20
> >
> > If you test without your spin_lock_bh() and spin_unlock_bh()
> > conversion patch, do you still hit the error?
> The error still happened. spin_lock_bh() and spin_unlock_bh() are
> modified after this patch.
>=20
> >
> > What happens if a user submits exactly one DMA transaction, and then
> > leaves the system idle? The callback for the last descriptor in the
> > chain will never get run, right? That's a bug.
> It won't be happened if use fsl-dma, because the right order is
> xor-copy-xor->callback, The callback which you concerned is implemented
> in talitos driver, callback should be null in fsl-dma.
>=20
> >
> > > /* update the cookie if we have some descriptors to cleanup */
> > > if (!list_empty(&chan->ld_running)) {
> > > dma_cookie_t cookie;
> > > @@ -1058,13 +1066,14 @@ static void dma_do_tasklet(unsigned long data=
)
> > > * move the descriptors to a temporary list so we can drop the lock
> > > * during the entire cleanup operation
> > > */
> > > - list_splice_tail_init(&chan->ld_running, &ld_cleanup);
> > > + list_cut_position(&ld_cleanup, &chan->ld_running, &prev->node);
> > >
> > > /* the hardware is now idle and ready for more */
> > > chan->idle =3D true;
> > >
> > > /*
> > > - * Start any pending transactions automatically
> > > + * Start any pending transactions automatically if current
> > descriptor
> > > + * list is completed
> > > *
> > > * In the ideal case, we keep the DMA controller busy while we go
> > > * ahead and free the descriptors below.
> > > --
> > > 1.7.5.1
> > >
> > >
> > > _______________________________________________
> > > Linuxppc-dev mailing list
> > > Linuxppc-dev@lists.ozlabs.org
> > > https://lists.ozlabs.org/listinfo/linuxppc-dev
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* RE: [linuxppc-release] [PATCH v2 4/4] fsl-dma: use spin_lock_bh to instead of spin_lock_irqsave
From: Liu Qiang-B32616 @ 2012-07-12 9:07 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Li Yang-R58472, Vinod Koul, herbert@gondor.hengli.com.au,
linux-crypto@vger.kernel.org, Dan Williams,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <4FFD952D.8040201@freescale.com>
> -----Original Message-----
> From: Tabi Timur-B04825
> Sent: Wednesday, July 11, 2012 11:01 PM
> To: Liu Qiang-B32616
> Cc: linux-crypto@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Vinod
> Koul; herbert@gondor.hengli.com.au; Dan Williams; Li Yang-R58472;
> davem@davemloft.net
> Subject: Re: [linuxppc-release] [PATCH v2 4/4] fsl-dma: use spin_lock_bh
> to instead of spin_lock_irqsave
>=20
> Qiang Liu wrote:
> > Use spin_lock_bh to instead of spin_lock_irqsave for improving
> performance.
>=20
> Please provide some evidence that performance has improved, as well as an
> explanation why it's okay to use spin_lock_bh, and why it's faster.
I compared my test result before and after this patch, write performance ca=
n
improved by 15%. I will send the latest patches sooner because of Ira's con=
cern.
I will give a complete description about the improvement of spin_lock_bh().
About your question, spin_lock_bh is used in the case of bottom/half as its
name, there is no need to protect a running/pending list with spin_lock_irq=
save.
Thanks.
> --
> Timur Tabi
> Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] powerpc/sgmii: Add phy nodes in SGMII mode
From: Jia Hongtao @ 2012-07-12 9:36 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: b38951
In SGMII riser card different PHY chip are used with different external
IRQ from eTSEC. To support PHY link state auto detect in SGMII mode we
should add another group of PHY nodes for SGMII mode.
For MPC8572DS IRQ6 is used for PHY0~PHY1, IRQ7 is used for PHY2~PHY3.
For MPC8544DS and MPC8536DS IRQ6 is used for PHY0~PHY1.
For P2020DS IRQ5 is used for PHY1~PHY2.
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Jia Hongtao <B38951@freescale.com>
---
arch/powerpc/boot/dts/mpc8536ds.dtsi | 8 ++++++++
arch/powerpc/boot/dts/mpc8544ds.dtsi | 9 +++++++++
arch/powerpc/boot/dts/mpc8572ds.dtsi | 17 +++++++++++++++++
arch/powerpc/boot/dts/p2020ds.dtsi | 10 ++++++++++
4 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8536ds.dtsi b/arch/powerpc/boot/dts/mpc8536ds.dtsi
index cc46dbd..d304a2d 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dtsi
+++ b/arch/powerpc/boot/dts/mpc8536ds.dtsi
@@ -203,6 +203,14 @@
reg = <1>;
device_type = "ethernet-phy";
};
+ sgmii_phy0: sgmii-phy@0 {
+ interrupts = <6 1 0 0>;
+ reg = <0x1d>;
+ };
+ sgmii_phy1: sgmii-phy@1 {
+ interrupts = <6 1 0 0>;
+ reg = <0x1c>;
+ };
tbi0: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dtsi b/arch/powerpc/boot/dts/mpc8544ds.dtsi
index 270f64b..77ebc9f 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dtsi
+++ b/arch/powerpc/boot/dts/mpc8544ds.dtsi
@@ -51,6 +51,15 @@
device_type = "ethernet-phy";
};
+ sgmii_phy0: sgmii-phy@0 {
+ interrupts = <6 1 0 0>;
+ reg = <0x1c>;
+ };
+ sgmii_phy1: sgmii-phy@1 {
+ interrupts = <6 1 0 0>;
+ reg = <0x1d>;
+ };
+
tbi0: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
diff --git a/arch/powerpc/boot/dts/mpc8572ds.dtsi b/arch/powerpc/boot/dts/mpc8572ds.dtsi
index 1417894..357490b 100644
--- a/arch/powerpc/boot/dts/mpc8572ds.dtsi
+++ b/arch/powerpc/boot/dts/mpc8572ds.dtsi
@@ -169,6 +169,23 @@
reg = <0x3>;
};
+ sgmii_phy0: sgmii-phy@0 {
+ interrupts = <6 1 0 0>;
+ reg = <0x1c>;
+ };
+ sgmii_phy1: sgmii-phy@1 {
+ interrupts = <6 1 0 0>;
+ reg = <0x1d>;
+ };
+ sgmii_phy2: sgmii-phy@2 {
+ interrupts = <7 1 0 0>;
+ reg = <0x1e>;
+ };
+ sgmii_phy3: sgmii-phy@3 {
+ interrupts = <7 1 0 0>;
+ reg = <0x1f>;
+ };
+
tbi0: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
diff --git a/arch/powerpc/boot/dts/p2020ds.dtsi b/arch/powerpc/boot/dts/p2020ds.dtsi
index d3b939c..e699cf9 100644
--- a/arch/powerpc/boot/dts/p2020ds.dtsi
+++ b/arch/powerpc/boot/dts/p2020ds.dtsi
@@ -150,6 +150,16 @@
interrupts = <3 1 0 0>;
reg = <0x2>;
};
+
+ sgmii_phy1: sgmii-phy@1 {
+ interrupts = <5 1 0 0>;
+ reg = <0x1c>;
+ };
+ sgmii_phy2: sgmii-phy@2 {
+ interrupts = <5 1 0 0>;
+ reg = <0x1d>;
+ };
+
tbi0: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
--
1.7.5.1
^ permalink raw reply related
* [PATCH][upstream] PCI: Add PCI_DEV_FLAGS_USE_NON_MSI_INTX_IRQ to enable non MSI/INTx interrupt
From: Shengzhou Liu @ 2012-07-12 10:02 UTC (permalink / raw)
To: bhelgaas, linux-pci; +Cc: linuxppc-dev, Shengzhou Liu
On some platforms, in RC mode, root port has neither MSI/MSI-X nor INTx
interrupt generated, which are available only in EP mode on those platform.
In this case, we try to use other interrupt for port service driver to have
AER, Hot-plug, etc, services to work. (i.e. there is the shared error interrupt
on platform P1010/P3041/P4080 etc)
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
drivers/pci/pcie/portdrv_core.c | 10 ++++++++--
drivers/pci/quirks.c | 12 ++++++++++++
include/linux/pci.h | 5 +++++
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 75915b3..837ad15 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -212,8 +212,14 @@ static int init_service_irqs(struct pci_dev *dev, int *irqs, int mask)
if (!pcie_port_enable_msix(dev, irqs, mask))
return 0;
- /* We're not going to use MSI-X, so try MSI and fall back to INTx */
- if (!pci_enable_msi(dev) || dev->pin)
+ /*
+ * We're not going to use MSI-X, so try MSI and fall back to INTx.
+ * Eventually, if neither MSI/MSI-X nor INTx available, try other
+ * interrupt. (On some platforms, root port doesn't support generating
+ * MSI/MSI-X/INTx in RC mode)
+ */
+ if (!pci_enable_msi(dev) || dev->pin || ((dev->dev_flags &
+ PCI_DEV_FLAGS_USE_NON_MSI_INTX_IRQ) && dev->irq))
irq = dev->irq;
no_msi:
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 2a75216..df54e2f 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -2640,6 +2640,18 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0x1083,
quirk_msi_intx_disable_bug);
#endif /* CONFIG_PCI_MSI */
+/*
+ * Under some circumstances, root port has neither MSI/MSI-X nor INTx generated,
+ * so try other interrupt if supported.
+ */
+static void __devinit quirk_enable_non_msi_intx_interrupt(struct pci_dev *dev)
+{
+ dev->dev_flags |= PCI_DEV_FLAGS_USE_NON_MSI_INTX_IRQ;
+}
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
+ quirk_enable_non_msi_intx_interrupt);
+
/* Allow manual resource allocation for PCI hotplug bridges
* via pci=hpmemsize=nnM and pci=hpiosize=nnM parameters. For
* some PCI-PCI hotplug bridges, like PLX 6254 (former HINT HB6),
diff --git a/include/linux/pci.h b/include/linux/pci.h
index d8c379d..f051a66 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -176,6 +176,11 @@ enum pci_dev_flags {
PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
/* Provide indication device is assigned by a Virtual Machine Manager */
PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
+ /*
+ * Use other interrupt (i.e. system shared interrupt) when MSI/MSI-X
+ * and INTx are not supported in RC mode on some platforms.
+ */
+ PCI_DEV_FLAGS_USE_NON_MSI_INTX_IRQ = (__force pci_dev_flags_t) 8,
};
enum pci_irq_reroute_variant {
--
1.6.4
^ permalink raw reply related
* RE: [PATCH] powerpc/sgmii: Add phy nodes in SGMII mode
From: Jia Hongtao-B38951 @ 2012-07-12 10:28 UTC (permalink / raw)
To: Jia Hongtao-B38951, linuxppc-dev@lists.ozlabs.org,
galak@kernel.crashing.org
Cc: Li Yang-R58472
In-Reply-To: <1342085776-13289-1-git-send-email-B38951@freescale.com>
Note that this patch works with uboot update.
Please refer to:
http://patchwork.ozlabs.org/patch/170627/
-Hongtao.
> -----Original Message-----
> From: Jia Hongtao-B38951
> Sent: Thursday, July 12, 2012 5:36 PM
> To: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org
> Cc: Li Yang-R58472; Jia Hongtao-B38951
> Subject: [PATCH] powerpc/sgmii: Add phy nodes in SGMII mode
>=20
> In SGMII riser card different PHY chip are used with different external
> IRQ from eTSEC. To support PHY link state auto detect in SGMII mode we
> should add another group of PHY nodes for SGMII mode.
>=20
> For MPC8572DS IRQ6 is used for PHY0~PHY1, IRQ7 is used for PHY2~PHY3.
> For MPC8544DS and MPC8536DS IRQ6 is used for PHY0~PHY1.
> For P2020DS IRQ5 is used for PHY1~PHY2.
>=20
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8536ds.dtsi | 8 ++++++++
> arch/powerpc/boot/dts/mpc8544ds.dtsi | 9 +++++++++
> arch/powerpc/boot/dts/mpc8572ds.dtsi | 17 +++++++++++++++++
> arch/powerpc/boot/dts/p2020ds.dtsi | 10 ++++++++++
> 4 files changed, 44 insertions(+), 0 deletions(-)
>=20
^ permalink raw reply
* Re: [PATCH] powerpc: remove rejected merge file from arch/powerpc/kernel in linux-next
From: Benjamin Herrenschmidt @ 2012-07-12 11:23 UTC (permalink / raw)
To: Gerard Snitselaar; +Cc: linux-next, linuxppc-dev, linux-kernel, stuart.yoder
In-Reply-To: <1342076734-30996-1-git-send-email-dev@snitselaar.org>
On Thu, 2012-07-12 at 00:05 -0700, Gerard Snitselaar wrote:
> Commit 9778b696 (powerpc: Use CURRENT_THREAD_INFO instead of open
> coded assembly) got a rejected merge file iommu.c.rej committed with
> it.
Oops, that's me having too much coffee & using git citool ... I'll get
rid of it, thanks.
Cheers,
Ben.
> Signed-off-by: Gerard Snitselaar <dev@snitselaar.org>
> ---
> arch/powerpc/kernel/iommu.c.rej | 22 ----------------------
> 1 file changed, 22 deletions(-)
> delete mode 100644 arch/powerpc/kernel/iommu.c.rej
>
> diff --git a/arch/powerpc/kernel/iommu.c.rej b/arch/powerpc/kernel/iommu.c.rej
> deleted file mode 100644
> index 9d10d34..0000000
> --- a/arch/powerpc/kernel/iommu.c.rej
> +++ /dev/null
> @@ -1,22 +0,0 @@
> ---- arch/powerpc/kernel/iommu.c 2012-06-08 09:01:02.785709100 +1000
> -+++ arch/powerpc/kernel/iommu.c 2012-06-08 09:01:07.489784856 +1000
> -@@ -33,7 +33,9 @@
> - #include <linux/bitmap.h>
> - #include <linux/iommu-helper.h>
> - #include <linux/crash_dump.h>
> -+#include <linux/fault-inject.h>
> - #include <asm/io.h>
> -+#include <asm/vio.h>
> - #include <asm/prom.h>
> - #include <asm/iommu.h>
> - #include <asm/pci-bridge.h>
> -@@ -171,6 +261,9 @@
> - return DMA_ERROR_CODE;
> - }
> -
> -+ if (should_fail_iommu(dev))
> -+ return DMA_ERROR_CODE;
> -+
> - if (handle && *handle)
> - start = *handle;
> - else
^ permalink raw reply
* Re: [PATCH][upstream] PCI: Add PCI_DEV_FLAGS_USE_NON_MSI_INTX_IRQ to enable non MSI/INTx interrupt
From: Kumar Gala @ 2012-07-12 12:16 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: bhelgaas, linux-pci, linuxppc-dev
In-Reply-To: <1342087342-14748-1-git-send-email-Shengzhou.Liu@freescale.com>
On Jul 12, 2012, at 5:02 AM, Shengzhou Liu wrote:
> On some platforms, in RC mode, root port has neither MSI/MSI-X nor =
INTx
> interrupt generated, which are available only in EP mode on those =
platform.
> In this case, we try to use other interrupt for port service driver to =
have
> AER, Hot-plug, etc, services to work. (i.e. there is the shared error =
interrupt
> on platform P1010/P3041/P4080 etc)
>=20
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> ---
> drivers/pci/pcie/portdrv_core.c | 10 ++++++++--
> drivers/pci/quirks.c | 12 ++++++++++++
> include/linux/pci.h | 5 +++++
> 3 files changed, 25 insertions(+), 2 deletions(-)
>=20
> diff --git a/drivers/pci/pcie/portdrv_core.c =
b/drivers/pci/pcie/portdrv_core.c
> index 75915b3..837ad15 100644
> --- a/drivers/pci/pcie/portdrv_core.c
> +++ b/drivers/pci/pcie/portdrv_core.c
> @@ -212,8 +212,14 @@ static int init_service_irqs(struct pci_dev *dev, =
int *irqs, int mask)
> if (!pcie_port_enable_msix(dev, irqs, mask))
> return 0;
>=20
> - /* We're not going to use MSI-X, so try MSI and fall back to =
INTx */
> - if (!pci_enable_msi(dev) || dev->pin)
> + /*
> + * We're not going to use MSI-X, so try MSI and fall back to =
INTx.
> + * Eventually, if neither MSI/MSI-X nor INTx available, try =
other
> + * interrupt. (On some platforms, root port doesn't support =
generating
> + * MSI/MSI-X/INTx in RC mode)
> + */
> + if (!pci_enable_msi(dev) || dev->pin || ((dev->dev_flags &
> + PCI_DEV_FLAGS_USE_NON_MSI_INTX_IRQ) && =
dev->irq))
> irq =3D dev->irq;
>=20
> no_msi:
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 2a75216..df54e2f 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -2640,6 +2640,18 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, =
0x1083,
> quirk_msi_intx_disable_bug);
> #endif /* CONFIG_PCI_MSI */
>=20
> +/*
> + * Under some circumstances, root port has neither MSI/MSI-X nor INTx =
generated,
> + * so try other interrupt if supported.
> + */
> +static void __devinit quirk_enable_non_msi_intx_interrupt(struct =
pci_dev *dev)
> +{
> + dev->dev_flags |=3D PCI_DEV_FLAGS_USE_NON_MSI_INTX_IRQ;
> +}
> +
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
> + quirk_enable_non_msi_intx_interrupt);
> +
This should be in arch/powerpc not here. One reason is FSL has other =
PCIe implementations than exists on PPC that have this issue. (ie the =
i.MXs support PCIe).
I'd put the addition of the quirk in a second patch as well.
> /* Allow manual resource allocation for PCI hotplug bridges
> * via pci=3Dhpmemsize=3DnnM and pci=3Dhpiosize=3DnnM parameters. For
> * some PCI-PCI hotplug bridges, like PLX 6254 (former HINT HB6),
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index d8c379d..f051a66 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -176,6 +176,11 @@ enum pci_dev_flags {
> PCI_DEV_FLAGS_NO_D3 =3D (__force pci_dev_flags_t) 2,
> /* Provide indication device is assigned by a Virtual Machine =
Manager */
> PCI_DEV_FLAGS_ASSIGNED =3D (__force pci_dev_flags_t) 4,
> + /*
> + * Use other interrupt (i.e. system shared interrupt) when =
MSI/MSI-X
> + * and INTx are not supported in RC mode on some platforms.
> + */
> + PCI_DEV_FLAGS_USE_NON_MSI_INTX_IRQ =3D (__force pci_dev_flags_t) =
8,
> };
>=20
> enum pci_irq_reroute_variant {
> --=20
> 1.6.4
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc/sgmii: Add phy nodes in SGMII mode
From: Kumar Gala @ 2012-07-12 12:18 UTC (permalink / raw)
To: Jia Hongtao-B38951; +Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01A228F9@039-SN1MPN1-002.039d.mgd.msft.net>
On Jul 12, 2012, at 5:28 AM, Jia Hongtao-B38951 wrote:
> Note that this patch works with uboot update.
> Please refer to:
> http://patchwork.ozlabs.org/patch/170627/
>
> -Hongtao.
Will RGMII still work with this patch if I dont update u-boot?
I'm assuming yes.
- k
>
>> -----Original Message-----
>> From: Jia Hongtao-B38951
>> Sent: Thursday, July 12, 2012 5:36 PM
>> To: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org
>> Cc: Li Yang-R58472; Jia Hongtao-B38951
>> Subject: [PATCH] powerpc/sgmii: Add phy nodes in SGMII mode
>>
>> In SGMII riser card different PHY chip are used with different external
>> IRQ from eTSEC. To support PHY link state auto detect in SGMII mode we
>> should add another group of PHY nodes for SGMII mode.
>>
>> For MPC8572DS IRQ6 is used for PHY0~PHY1, IRQ7 is used for PHY2~PHY3.
>> For MPC8544DS and MPC8536DS IRQ6 is used for PHY0~PHY1.
>> For P2020DS IRQ5 is used for PHY1~PHY2.
>>
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
>> ---
>> arch/powerpc/boot/dts/mpc8536ds.dtsi | 8 ++++++++
>> arch/powerpc/boot/dts/mpc8544ds.dtsi | 9 +++++++++
>> arch/powerpc/boot/dts/mpc8572ds.dtsi | 17 +++++++++++++++++
>> arch/powerpc/boot/dts/p2020ds.dtsi | 10 ++++++++++
>> 4 files changed, 44 insertions(+), 0 deletions(-)
>>
>
^ permalink raw reply
* Re: [RFC PATCH v3 3/13] memory-hotplug : unify argument of firmware_map_add_early/hotplug
From: Dave Hansen @ 2012-07-12 13:40 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: len.brown, wency, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, rientjes, cl, linuxppc-dev, akpm,
liuj97
In-Reply-To: <4FFE5816.6070102@jp.fujitsu.com>
On 07/11/2012 09:52 PM, Yasuaki Ishimatsu wrote:
> Does the following patch include your comment? If O.K., I will separate
> the patch from the series and send it for bug fix.
Looks sane to me. It does now mean that the calling conventions for
some of the other firmware_map*() functions are different, but I think
that's OK since they're only used internally to memmap.c.
^ permalink raw reply
* Re: [PATCH] powerpc/sgmii: Add phy nodes in SGMII mode
From: Li Yang @ 2012-07-12 14:13 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472, Jia Hongtao-B38951
In-Reply-To: <56E7FB74-A29A-4658-9AC9-2C87A1A7ED3C@kernel.crashing.org>
On Thu, Jul 12, 2012 at 8:18 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jul 12, 2012, at 5:28 AM, Jia Hongtao-B38951 wrote:
>
>> Note that this patch works with uboot update.
>> Please refer to:
>> http://patchwork.ozlabs.org/patch/170627/
>>
>> -Hongtao.
>
> Will RGMII still work with this patch if I dont update u-boot?
>
> I'm assuming yes.
Yes. We just add new nodes without modifying the original PHY nodes.
Leo
^ permalink raw reply
* Re: [PATCH] powerpc/sgmii: Add phy nodes in SGMII mode
From: Kumar Gala @ 2012-07-12 15:08 UTC (permalink / raw)
To: Jia Hongtao; +Cc: linuxppc-dev
In-Reply-To: <1342085776-13289-1-git-send-email-B38951@freescale.com>
On Jul 12, 2012, at 4:36 AM, Jia Hongtao wrote:
> In SGMII riser card different PHY chip are used with different external
> IRQ from eTSEC. To support PHY link state auto detect in SGMII mode we
> should add another group of PHY nodes for SGMII mode.
>
> For MPC8572DS IRQ6 is used for PHY0~PHY1, IRQ7 is used for PHY2~PHY3.
> For MPC8544DS and MPC8536DS IRQ6 is used for PHY0~PHY1.
> For P2020DS IRQ5 is used for PHY1~PHY2.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8536ds.dtsi | 8 ++++++++
> arch/powerpc/boot/dts/mpc8544ds.dtsi | 9 +++++++++
> arch/powerpc/boot/dts/mpc8572ds.dtsi | 17 +++++++++++++++++
> arch/powerpc/boot/dts/p2020ds.dtsi | 10 ++++++++++
> 4 files changed, 44 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH][upstream] PCI: Add PCI_DEV_FLAGS_USE_NON_MSI_INTX_IRQ to enable non MSI/INTx interrupt
From: Scott Wood @ 2012-07-12 16:07 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: bhelgaas, linux-pci, linuxppc-dev
In-Reply-To: <1342087342-14748-1-git-send-email-Shengzhou.Liu@freescale.com>
On 07/12/2012 05:02 AM, Shengzhou Liu wrote:
> On some platforms, in RC mode, root port has neither MSI/MSI-X nor INTx
> interrupt generated, which are available only in EP mode on those platform.
> In this case, we try to use other interrupt for port service driver to have
> AER, Hot-plug, etc, services to work. (i.e. there is the shared error interrupt
> on platform P1010/P3041/P4080 etc)
>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> ---
> drivers/pci/pcie/portdrv_core.c | 10 ++++++++--
> drivers/pci/quirks.c | 12 ++++++++++++
> include/linux/pci.h | 5 +++++
> 3 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
> index 75915b3..837ad15 100644
> --- a/drivers/pci/pcie/portdrv_core.c
> +++ b/drivers/pci/pcie/portdrv_core.c
> @@ -212,8 +212,14 @@ static int init_service_irqs(struct pci_dev *dev, int *irqs, int mask)
> if (!pcie_port_enable_msix(dev, irqs, mask))
> return 0;
>
> - /* We're not going to use MSI-X, so try MSI and fall back to INTx */
> - if (!pci_enable_msi(dev) || dev->pin)
> + /*
> + * We're not going to use MSI-X, so try MSI and fall back to INTx.
> + * Eventually, if neither MSI/MSI-X nor INTx available, try other
> + * interrupt. (On some platforms, root port doesn't support generating
> + * MSI/MSI-X/INTx in RC mode)
> + */
> + if (!pci_enable_msi(dev) || dev->pin || ((dev->dev_flags &
> + PCI_DEV_FLAGS_USE_NON_MSI_INTX_IRQ) && dev->irq))
> irq = dev->irq;
I'd still like to hear someone say what specifically would go wrong if
we just did s/dev->pin/dev->irq/ (and even that much seems to be only
because the code is using a non-standard indicator of an invalid IRQ).
When would dev->irq contain a non-zero value that is not usable?
-Scott
^ permalink raw reply
* Re: [linuxppc-release] [PATCH v2 4/4] fsl-dma: use spin_lock_bh to instead of spin_lock_irqsave
From: Timur Tabi @ 2012-07-12 18:23 UTC (permalink / raw)
To: Liu Qiang-B32616
Cc: Li Yang-R58472, Vinod Koul, herbert@gondor.hengli.com.au,
linux-crypto@vger.kernel.org, Dan Williams,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <BCB48C05FCE8BC4D9E61E841ECBE6DB70C0987@039-SN2MPN1-011.039d.mgd.msft.net>
Liu Qiang-B32616 wrote:
> I compared my test result before and after this patch, write performance can
> improved by 15%. I will send the latest patches sooner because of Ira's concern.
> I will give a complete description about the improvement of spin_lock_bh().
>
> About your question, spin_lock_bh is used in the case of bottom/half as its
> name, there is no need to protect a running/pending list with spin_lock_irqsave.
Please respin the patch and include this information in the patch description.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [git pull] Please pull powerpc.git next branch
From: Kumar Gala @ 2012-07-12 22:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
The following changes since commit db9112173b185995b80f56e136bd2ae44e4e6366:
powerpc: Turn on BPF_JIT in ppc64_defconfig (2012-07-10 19:19:02 +1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git next
Christian Herzig (1):
powerpc/83xx: fix RGMII AC values workaround for km83xx
Gustavo Zacarias (1):
powerpc/p1010rdb: add EEPROMs to device tree
Holger Brunck (3):
powerpc/83xx: use for_each_node_by_name for km83xx.c
powerpc/83xx: update defconfig for kmeter1
powerpc/82xx: add SPI support for mgcoge
Jerry Huang (1):
powerpc/p1022ds: Add RTC support
Jia Hongtao (3):
powerpc/85xx: MPC8572DS - Fix eTSEC is not available on core1 of AMP boot
powerpc/85xx: MPC8572DS - Update the MSI interrupts into 4-cell format
powerpc/85xx: Add phy nodes in SGMII mode for MPC8536/44/72DS & P2020DS
Kim Phillips (1):
powerpc/fsl: Distribute interrupts on all CPUs by default
Kokoris, Ioannis (1):
powerpc/qe: set IReady in QE Microcode Upload
Liu Yu (1):
powerpc/e500: make load_up_spe a normal fuction
Matias Garcia (1):
powerpc/fsl/pci: Fix when quirk_fsl_pcie_header is freed up
Paul Gortmaker (1):
powerpc: remove Wind River SBC8560 support
Prabhakar Kushwaha (1):
powerpc/85xx: Add BSC9131 RDB Support
Scott Wood (3):
powerpc/fsl-pci: get PCI init out of board files
powerpc/mpc85xx_ds: convert to unified PCI init
powerpc/e500: add paravirt QEMU platform
Sebastian Andrzej Siewior (1):
Revert "powerpc/85xx: p2020rdb - move the NAND address."
Shaohui Xie (3):
powerpc/p2041rdb: add NAND node in device tree
powerpc/watchdog: replace CONFIG_FSL_BOOKE with CONFIG_PPC_FSL_BOOK3E
powerpc/watchdog: move booke watchdog param related code to setup-common.c
Shawn Guo (1):
powerpc: select PPC_CLOCK unconditionally for FSL_SOC
Shengzhou Liu (3):
powerpc/85xx: Enable MTD/NOR/NAND options by default in defconfig
powerpc/85xx: Update corenet32_smp_defconfig
powerpc/85xx: Update corenet64_smp_defconfig
Tang Yuantian (2):
powerpc/85xx: Add P1024rdb board support
powerpc/85xx: Add P1024rdb dts support
Timur Tabi (2):
powerpc/85xx: use the BRx registers to enable indirect mode on the P1022DS
Revert "powerpc/p3060qds: Add support for P3060QDS board"
Varun Sethi (1):
powerpc/mpic: Use the MPIC_LARGE_VECTORS flag for FSL MPIC.
Xu Jiucheng (1):
powerpc/85xx: Rename P1021RDB-PC device trees to be consistent
Zhicheng Fan (1):
powerpc/85xx: Add ucc uart support for p1025rdb
arch/powerpc/Kconfig | 2 +-
arch/powerpc/boot/Makefile | 1 -
arch/powerpc/boot/dts/bsc9131rdb.dts | 34 ++
arch/powerpc/boot/dts/bsc9131rdb.dtsi | 142 +++++++
arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi | 193 ++++++++++
.../dts/{p1021rdb.dts => fsl/bsc9131si-pre.dtsi} | 79 +---
arch/powerpc/boot/dts/fsl/p1021si-post.dtsi | 16 +-
arch/powerpc/boot/dts/fsl/p3060si-post.dtsi | 302 ---------------
arch/powerpc/boot/dts/mgcoge.dts | 23 ++
arch/powerpc/boot/dts/mpc8536ds.dtsi | 8 +
arch/powerpc/boot/dts/mpc8544ds.dtsi | 9 +
arch/powerpc/boot/dts/mpc8572ds.dtsi | 17 +
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts | 8 +-
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts | 11 +-
arch/powerpc/boot/dts/p1010rdb.dtsi | 12 +
.../boot/dts/{p1021rdb.dtsi => p1021rdb-pc.dtsi} | 2 +-
.../boot/dts/{p1021rdb.dts => p1021rdb-pc_32b.dts} | 4 +-
.../dts/{p1021rdb_36b.dts => p1021rdb-pc_36b.dts} | 4 +-
arch/powerpc/boot/dts/p1022ds.dtsi | 20 +-
.../boot/dts/{p1021rdb.dtsi => p1024rdb.dtsi} | 94 ++---
.../dts/{fsl/p3060si-pre.dtsi => p1024rdb_32b.dts} | 126 +++----
.../dts/{p1021rdb_36b.dts => p1024rdb_36b.dts} | 43 +--
arch/powerpc/boot/dts/p1025rdb.dtsi | 40 ++
arch/powerpc/boot/dts/p2020ds.dtsi | 10 +
arch/powerpc/boot/dts/p2020rdb.dts | 2 +-
arch/powerpc/boot/dts/p2041rdb.dts | 41 ++-
arch/powerpc/boot/dts/p3060qds.dts | 242 ------------
arch/powerpc/boot/dts/sbc8560.dts | 406 --------------------
arch/powerpc/configs/83xx/kmeter1_defconfig | 22 +-
arch/powerpc/configs/85xx/sbc8560_defconfig | 65 ----
arch/powerpc/configs/corenet32_smp_defconfig | 10 +-
arch/powerpc/configs/corenet64_smp_defconfig | 66 +++-
arch/powerpc/configs/mgcoge_defconfig | 12 +-
arch/powerpc/configs/mpc85xx_defconfig | 24 ++
arch/powerpc/configs/mpc85xx_smp_defconfig | 25 ++
arch/powerpc/include/asm/immap_qe.h | 4 +-
arch/powerpc/include/asm/qe.h | 1 +
arch/powerpc/kernel/head_fsl_booke.S | 23 +-
arch/powerpc/kernel/setup-common.c | 27 ++
arch/powerpc/kernel/setup_32.c | 24 --
arch/powerpc/platforms/82xx/km82xx.c | 5 +
arch/powerpc/platforms/83xx/km83xx.c | 100 ++++--
arch/powerpc/platforms/85xx/Kconfig | 43 ++-
arch/powerpc/platforms/85xx/Makefile | 4 +-
arch/powerpc/platforms/85xx/bsc913x_rdb.c | 67 ++++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 97 ++----
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 22 +
arch/powerpc/platforms/85xx/p1022_ds.c | 106 +++++-
arch/powerpc/platforms/85xx/p3060_qds.c | 77 ----
arch/powerpc/platforms/85xx/qemu_e500.c | 72 ++++
arch/powerpc/platforms/85xx/sbc8560.c | 254 ------------
arch/powerpc/platforms/Kconfig.cputype | 4 +
arch/powerpc/sysdev/fsl_pci.c | 73 ++++-
arch/powerpc/sysdev/fsl_pci.h | 8 +
arch/powerpc/sysdev/mpic.c | 2 +-
arch/powerpc/sysdev/qe_lib/qe.c | 3 +
drivers/watchdog/Kconfig | 8 +-
drivers/watchdog/booke_wdt.c | 4 +-
58 files changed, 1321 insertions(+), 1822 deletions(-)
create mode 100644 arch/powerpc/boot/dts/bsc9131rdb.dts
create mode 100644 arch/powerpc/boot/dts/bsc9131rdb.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi
copy arch/powerpc/boot/dts/{p1021rdb.dts => fsl/bsc9131si-pre.dtsi} (52%)
delete mode 100644 arch/powerpc/boot/dts/fsl/p3060si-post.dtsi
copy arch/powerpc/boot/dts/{p1021rdb.dtsi => p1021rdb-pc.dtsi} (99%)
rename arch/powerpc/boot/dts/{p1021rdb.dts => p1021rdb-pc_32b.dts} (97%)
copy arch/powerpc/boot/dts/{p1021rdb_36b.dts => p1021rdb-pc_36b.dts} (97%)
rename arch/powerpc/boot/dts/{p1021rdb.dtsi => p1024rdb.dtsi} (79%)
rename arch/powerpc/boot/dts/{fsl/p3060si-pre.dtsi => p1024rdb_32b.dts} (51%)
rename arch/powerpc/boot/dts/{p1021rdb_36b.dts => p1024rdb_36b.dts} (71%)
delete mode 100644 arch/powerpc/boot/dts/p3060qds.dts
delete mode 100644 arch/powerpc/boot/dts/sbc8560.dts
delete mode 100644 arch/powerpc/configs/85xx/sbc8560_defconfig
create mode 100644 arch/powerpc/platforms/85xx/bsc913x_rdb.c
delete mode 100644 arch/powerpc/platforms/85xx/p3060_qds.c
create mode 100644 arch/powerpc/platforms/85xx/qemu_e500.c
delete mode 100644 arch/powerpc/platforms/85xx/sbc8560.c
^ permalink raw reply
* Re: [PATCH v4] PPC: use CURRENT_THREAD_INFO instead of open coded assembly
From: Paul Mackerras @ 2012-07-12 22:45 UTC (permalink / raw)
To: Stuart Yoder; +Cc: linuxppc-dev, agraf, sfr
In-Reply-To: <1341499295-10795-1-git-send-email-stuart.yoder@freescale.com>
On Thu, Jul 05, 2012 at 09:41:35AM -0500, Stuart Yoder wrote:
> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> index ba3aeb4..bad42e3 100644
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -92,7 +92,7 @@ crit_transfer_to_handler:
> mfspr r8,SPRN_SPRG_THREAD
> lwz r0,KSP_LIMIT(r8)
> stw r0,SAVED_KSP_LIMIT(r11)
> - rlwimi r0,r1,0,0,(31-THREAD_SHIFT)
> + CURRENT_THREAD_INFO(r0, r1)
> stw r0,KSP_LIMIT(r8)
> /* fall through */
> #endif
> @@ -112,7 +112,7 @@ crit_transfer_to_handler:
> mfspr r8,SPRN_SPRG_THREAD
> lwz r0,KSP_LIMIT(r8)
> stw r0,saved_ksp_limit@l(0)
> - rlwimi r0,r1,0,0,(31-THREAD_SHIFT)
> + CURRENT_THREAD_INFO(r0, r1)
> stw r0,KSP_LIMIT(r8)
> /* fall through */
> #endif
Do you really mean to replace a rlwimi with a rlwinm? If so, is that
because the rlwinm is a bug fix, or is it because you know something
special about KSP_LIMIT(r8) which means that rlwinm and rlwimi are
equivalent here?
Paul.
^ 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