Re: [RFC PATCH v5 16/19] memory-hotplug: free memmap of sparse-vmemmap
At 07/31/2012 08:22 PM, Gerald Schaefer Wrote: > On Fri, 27 Jul 2012 18:34:38 +0800 > Wen Congyang wrote: > >> From: Yasuaki Ishimatsu >> >> All pages of virtual mapping in removed memory cannot be freed, since >> some pages used as PGD/PUD includes not only removed memory but also >> other memory. So the patch checks whether page can be freed or not. >> >> How to check whether page can be freed or not? >> 1. When removing memory, the page structs of the revmoved memory are >> filled with 0FD. >> 2. All page structs are filled with 0xFD on PT/PMD, PT/PMD can be >> cleared. In this case, the page used as PT/PMD can be freed. >> >> Applying patch, __remove_section() of CONFIG_SPARSEMEM_VMEMMAP is >> integrated into one. So __remove_section() of >> CONFIG_SPARSEMEM_VMEMMAP is deleted. > > There should also be generic or dummy versions of the functions > vmemmap_free_bootmem(), vmemmap_kfree() and > register_page_bootmem_memmap(). It doesn't compile on other > archtitectures than x86 as it is now: > > mm/built-in.o: In function `sparse_remove_one_section': > (.text+0x49fa6): undefined reference to `vmemmap_free_bootmem' > mm/built-in.o: In function `sparse_remove_one_section': > (.text+0x49fcc): undefined reference to `vmemmap_kfree' > mm/built-in.o: In function `register_page_bootmem_info_node': > (.text+0x57c06): undefined reference to `register_page_bootmem_memmap' > mm/built-in.o: In function `sparse_add_one_section': > (.meminit.text+0x2506): undefined reference to `vmemmap_kfree' > mm/built-in.o: In function `sparse_add_one_section': > (.meminit.text+0x2528): undefined reference to `vmemmap_kfree' > make: *** [vmlinux] Error 1 > > Thanks for testing. I will fix it. Wen Congyang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 5/7] fsl-dma: fix support for async_tx API
> -Original Message-
> From: Ira W. Snyder [mailto:i...@ovro.caltech.edu]
> Sent: Wednesday, August 01, 2012 7:46 AM
> To: linux-cry...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org; Liu Qiang-B32616; Ira W. Snyder; Dan
> Williams; Vinod Koul; Li Yang-R58472; Liu Qiang-B32616
> Subject: [PATCH 5/7] fsl-dma: fix support for async_tx API
>
> From: "Ira W. Snyder"
>
> The current fsldma driver does not support the async_tx API. This is due
> to a bug: all descriptors are released when the hardware is finished
> with them. The async_tx API requires that the ACK bit is set by software
> before descriptors are freed.
>
> This bug is easiest to reproduce by enabling both CONFIG_NET_DMA and
> CONFIG_ASYNC_TX, and using the hardware offload support in MD RAID. The
> network stack will force operations on shared DMA channels, and will
> free descriptors which are being used by the MD RAID code.
>
> The BUG_ON(async_tx_test_ack(depend_tx)) test in async_tx_submit() will
> be hit, and panic the machine.
>
> TASK = ee1a94a0[1390] 'md0_raid5' THREAD: ecf4 CPU: 0
> GPR00: 0001 ecf41ca0 ee44/921a94a0 003f 0001 c00593e4
> 0001
> GPR08: a7a7a7a7 0001 045/92002 42028042 100a38d4
> ed576d98
> GPR16: ed5a11b0 2b162000 0200 046/92000 2d555000
> ed3015e8 c15a7aa0
> GPR24: c155fc40 ecb63220 ecf41d28 e47/92f640bb0
> ef640c30 ecf41ca0
> NIP [c02b048c] async_tx_submit+0x6c/0x2b4
> LR [c02b068c] async_tx_submit+0x26c/0x2b4
> Call Trace:
> [ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable)
> [ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c
> [ecf41d20] [c0421064] async_copy_data+0xa0/0x17c
> [ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10
> [ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8
> [ecf41e90] [c0429080] raid5d+0x3d4/0x5b4
> [ecf41f40] [c04329b8] md_thread+0x138/0x16c
> [ecf41f90] [c008277c] kthread+0x8c/0x90
> [ecf41ff0] [c0011630] kernel_thread+0x4c/0x68
>
> Cc: Dan Williams
> Cc: Vinod Koul
> Cc: Li Yang
> Cc: Qiang Liu
I have no idea where the log is from, if the log is from my patch, please note
it.
> Signed-off-by: Ira W. Snyder
> ---
> drivers/dma/fsldma.c | 156 +++-
> --
> drivers/dma/fsldma.h |1 +
> 2 files changed, 97 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index 80edc63..380c1b7 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -410,16 +410,15 @@ static void fsl_dma_free_descriptor(struct
> fsldma_chan *chan, struct fsl_desc_sw
> }
>
> /**
> - * fsldma_cleanup_descriptor - cleanup and free a single link descriptor
> + * fsldma_run_tx_complete_actions - run callback and unmap descriptor
> * @chan: Freescale DMA channel
> * @desc: descriptor to cleanup and free
> *
> * This function is used on a descriptor which has been executed by the
> DMA
> - * controller. It will run any callbacks, submit any dependencies, and
> then
> - * free the descriptor.
> + * controller. It will run the callback and unmap the descriptor, if
> requested.
> */
> -static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
> - struct fsl_desc_sw *desc)
> +static void fsldma_run_tx_complete_actions(struct fsldma_chan *chan,
> +struct fsl_desc_sw *desc)
> {
Ah.. I am the original author of this design. Especially some important
interfaces,
at least you should add my name or note the idea before you modify it?
> struct dma_async_tx_descriptor *txd = &desc->async_tx;
> struct device *dev = chan->common.device->dev;
> @@ -427,6 +426,10 @@ static void fsldma_cleanup_descriptor(struct
> fsldma_chan *chan,
> dma_addr_t dst = get_desc_dst(chan, desc);
> u32 len = get_desc_cnt(chan, desc);
>
> + /* Cookies with value zero are already cleaned up */
> + if (txd->cookie == 0)
> + return;
> +
> /* Run the link descriptor callback function */
> if (txd->callback) {
> #ifdef FSL_DMA_LD_DEBUG
> @@ -435,9 +438,6 @@ static void fsldma_cleanup_descriptor(struct
> fsldma_chan *chan,
> txd->callback(txd->callback_param);
> }
>
> - /* Run any dependencies */
> - dma_run_dependencies(txd);
> -
> /* Unmap the dst buffer, if requested */
> if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) {
> if (txd->flags & DMA_COMPL_DEST_UNMAP_SINGLE)
> @@ -454,7 +454,68 @@ static void fsldma_cleanup_descriptor(struct
> fsldma_chan *chan,
> dma_unmap_page(dev, src, len, DMA_TO_DEVICE);
> }
>
> - fsl_dma_free_descriptor(chan, desc);
> + /*
> + * A zeroed cookie indicates that cleanup actions have been
> + * run, but the descriptor has not yet been ACKed.
> + */
> + txd->cookie = 0;
> +}
> +
> +/**
> + * fsldma_cleanup_descriptors - cleanup and free link descriptors
> + *
Re: [RFC PATCH v5 12/19] memory-hotplug: introduce new function arch_remove_memory()
At 08/01/2012 10:44 AM, jencce zhou Wrote:
> 2012/7/27 Wen Congyang :
>> We don't call __add_pages() directly in the function add_memory()
>> because some other architecture related things need to be done
>> before or after calling __add_pages(). So we should introduce
>> a new function arch_remove_memory() to revert the things
>> done in arch_add_memory().
>>
>> Note: the function for s390 is not implemented(I don't know how to
>> implement it for s390).
>>
>> CC: David Rientjes
>> CC: Jiang Liu
>> CC: Len Brown
>> CC: Benjamin Herrenschmidt
>> CC: Paul Mackerras
>> CC: Christoph Lameter
>> Cc: Minchan Kim
>> CC: Andrew Morton
>> CC: KOSAKI Motohiro
>> CC: Yasuaki Ishimatsu
>> Signed-off-by: Wen Congyang
>> ---
>> arch/ia64/mm/init.c | 16
>> arch/powerpc/mm/mem.c| 14 +++
>> arch/s390/mm/init.c |8 ++
>> arch/sh/mm/init.c| 15 +++
>> arch/tile/mm/init.c |8 ++
>> arch/x86/include/asm/pgtable_types.h |1 +
>> arch/x86/mm/init_32.c| 10 ++
>> arch/x86/mm/init_64.c| 160
>> ++
>> arch/x86/mm/pageattr.c | 47 +-
>> include/linux/memory_hotplug.h |1 +
>> mm/memory_hotplug.c |1 +
>> 11 files changed, 259 insertions(+), 22 deletions(-)
>>
>> diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
>> index 0eab454..1e345ed 100644
>> --- a/arch/ia64/mm/init.c
>> +++ b/arch/ia64/mm/init.c
>> @@ -688,6 +688,22 @@ int arch_add_memory(int nid, u64 start, u64 size)
>>
>> return ret;
>> }
>> +
>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>> +int arch_remove_memory(u64 start, u64 size)
>> +{
>> + unsigned long start_pfn = start >> PAGE_SHIFT;
>> + unsigned long nr_pages = size >> PAGE_SHIFT;
>> + int ret;
>> +
>> + ret = __remove_pages(start_pfn, nr_pages);
>> + if (ret)
>> + pr_warn("%s: Problem encountered in __remove_pages() as"
>> + " ret=%d\n", __func__, ret);
>> +
>> + return ret;
>> +}
>> +#endif
>> #endif
>>
>
> in 3.5 ia64 implementation did not call __remove_pages at all. so why?
This function only reverts the things done in arch_add_memory(), and it will
be called when a memory device is removed.
When adding a memory device, __add_pages() is called in arch_add_memory(),
so call __remove_pages() in arch_remove_memory().
Thanks
Wen Congyang
>
>
>> /*
>> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
>> index baaafde..249cef4 100644
>> --- a/arch/powerpc/mm/mem.c
>> +++ b/arch/powerpc/mm/mem.c
>> @@ -133,6 +133,20 @@ int arch_add_memory(int nid, u64 start, u64 size)
>>
>> return __add_pages(nid, zone, start_pfn, nr_pages);
>> }
>> +
>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>> +int arch_remove_memory(u64 start, u64 size)
>> +{
>> + unsigned long start_pfn = start >> PAGE_SHIFT;
>> + unsigned long nr_pages = size >> PAGE_SHIFT;
>> +
>> + start = (unsigned long)__va(start);
>> + if (remove_section_mapping(start, start + size))
>> + return -EINVAL;
>> +
>> + return __remove_pages(start_pfn, nr_pages);
>> +}
>> +#endif
>> #endif /* CONFIG_MEMORY_HOTPLUG */
>>
>> /*
>> diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
>> index 6adbc08..ca4bc46 100644
>> --- a/arch/s390/mm/init.c
>> +++ b/arch/s390/mm/init.c
>> @@ -257,4 +257,12 @@ int arch_add_memory(int nid, u64 start, u64 size)
>> vmem_remove_mapping(start, size);
>> return rc;
>> }
>> +
>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>> +int arch_remove_memory(u64 start, u64 size)
>> +{
>> + /* TODO */
>> + return -EBUSY;
>> +}
>> +#endif
>> #endif /* CONFIG_MEMORY_HOTPLUG */
>> diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
>> index 82cc576..fc84491 100644
>> --- a/arch/sh/mm/init.c
>> +++ b/arch/sh/mm/init.c
>> @@ -558,4 +558,19 @@ int memory_add_physaddr_to_nid(u64 addr)
>> EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
>> #endif
>>
>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>> +int arch_remove_memory(u64 start, u64 size)
>> +{
>> + unsigned long start_pfn = start >> PAGE_SHIFT;
>> + unsigned long nr_pages = size >> PAGE_SHIFT;
>> + int ret;
>> +
>> + ret = __remove_pages(start_pfn, nr_pages);
>> + if (unlikely(ret))
>> + pr_warn("%s: Failed, __remove_pages() == %d\n", __func__,
>> + ret);
>> +
>> + return ret;
>> +}
>> +#endif
>> #endif /* CONFIG_MEMORY_HOTPLUG */
>> diff --git a/arch/tile/mm/init.c b/arch/tile/mm/init.c
>> index ef29d6c..2749515 100644
>> --- a/arch/tile/mm/init.c
>> +++ b/arch/tile/mm/init.c
>> @@ -935,6 +935,14 @@ int remove_memory(u64 start, u64 size)
>> {
>> return -EINVAL;
>> }
>> +
>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>> +int arch_remove_memory(u64 start, u64 size)
>> +{
>> + /* TODO */
>> + return -EBUSY;
>> +}
>> +#endif
>> #endif
>>
>
Re: [PATCH -V5 06/13] arch/powerpc: Increase the slice range to 64TB
On Mon, Jul 30, 2012 at 04:52:12PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> This patch makes the high psizes mask as an unsigned char array
> so that we can have more than 16TB. Currently we support upto
> 64TB
Comments below...
> diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/slb_low.S
> index b9ee79ce..c355af6 100644
> --- a/arch/powerpc/mm/slb_low.S
> +++ b/arch/powerpc/mm/slb_low.S
> @@ -108,17 +108,34 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_1T_SEGMENT)
>* between 4k and 64k standard page size
>*/
> #ifdef CONFIG_PPC_MM_SLICES
> + /* r10 have esid */
> cmpldi r10,16
> -
> - /* Get the slice index * 4 in r11 and matching slice size mask in r9 */
> - ld r9,PACALOWSLICESPSIZE(r13)
> - sldir11,r10,2
> + /* below SLICE_LOW_TOP */
> blt 5f
> - ld r9,PACAHIGHSLICEPSIZE(r13)
> - srdir11,r10,(SLICE_HIGH_SHIFT - SLICE_LOW_SHIFT - 2)
> - andi. r11,r11,0x3c
> -
> -5: /* Extract the psize and multiply to get an array offset */
> + /*
> + * Handle hpsizes,
> + * r9 is get_paca()->context.high_slices_psize[index], r11 is mask_index
> + * We use r10 here, later we restore it to esid.
> + * Can we use other register instead of r10 ?
Only r9, r10 and r11 are available here, and you're using them all.
Restoring r10 with one integer instruction is going to be quicker than
saving and restoring another register to/from memory.
> + */
> + srdir10,r10,(SLICE_HIGH_SHIFT - SLICE_LOW_SHIFT) /* index */
> + srdir11,r10,1 /* r11 is array index */
> + addir9,r11,PACAHIGHSLICEPSIZE
> + lbzxr9,r9,r13 /* r9 is hpsizes[r11] */
> + sldir11,r11,1
> + subfr11,r11,r10 /* mask_index = index - (array_index << 1) */
> + srdir10,r3,28 /* restore r10 with esid */
> + b 6f
How about (untested):
srdir11,r10,(SLICE_HIGH_SHIFT - SLICE_LOW_SHIFT + 1) /* index */
addir9,r11,PACAHIGHSLICEPSIZE
lbzxr9,r13,r9 /* r9 is hpsizes[r11] */
/* r11 = (r10 >> 12) & 1, i.e. grab lowest bit of 1T ESID */
rldicl r11,r10,(64 - (SLICE_HIGH_SHIFT - SLICE_LOW_SHIFT)),63
b 6f
Note that I swapped the RA and RB arguments for the lbzx. Our recent
processors process indexed mode instructions more quickly if the value
in RB is small.
> static struct slice_mask slice_mask_for_size(struct mm_struct *mm, int psize)
> {
> + unsigned char *hpsizes;
> + int index, mask_index;
> struct slice_mask ret = { 0, 0 };
> unsigned long i;
> - u64 psizes;
> + u64 lpsizes;
>
> - psizes = mm->context.low_slices_psize;
> + lpsizes = mm->context.low_slices_psize;
> for (i = 0; i < SLICE_NUM_LOW; i++)
> - if (((psizes >> (i * 4)) & 0xf) == psize)
> + if (((lpsizes >> (i * 4)) & 0xf) == psize)
> ret.low_slices |= 1u << i;
>
> - psizes = mm->context.high_slices_psize;
> - for (i = 0; i < SLICE_NUM_HIGH; i++)
> - if (((psizes >> (i * 4)) & 0xf) == psize)
> + hpsizes = mm->context.high_slices_psize;
> + for (i = 0; i < SLICE_NUM_HIGH; i++) {
> + mask_index = i & 0x1;
> + index = i >> 1;
> + if (((hpsizes[index] >> (mask_index * 4)) & 0xf) == psize)
> ret.high_slices |= 1u << i;
This needs to be 1ul not 1u, since we are creating a 64-bit mask.
> static void slice_convert(struct mm_struct *mm, struct slice_mask mask, int
> psize)
> {
> + int index, mask_index;
> /* Write the new slice psize bits */
> - u64 lpsizes, hpsizes;
> + unsigned char *hpsizes;
> + u64 lpsizes;
> unsigned long i, flags;
>
> slice_dbg("slice_convert(mm=%p, psize=%d)\n", mm, psize);
> @@ -201,14 +208,18 @@ static void slice_convert(struct mm_struct *mm, struct
> slice_mask mask, int psiz
> lpsizes = (lpsizes & ~(0xful << (i * 4))) |
> (((unsigned long)psize) << (i * 4));
>
> + /* Assign the value back */
> + mm->context.low_slices_psize = lpsizes;
> +
> hpsizes = mm->context.high_slices_psize;
> - for (i = 0; i < SLICE_NUM_HIGH; i++)
> + for (i = 0; i < SLICE_NUM_HIGH; i++) {
> + mask_index = i & 0x1;
> + index = i >> 1;
> if (mask.high_slices & (1u << i))
Again, 1ul now. Check all the other places where we manipulate a
slice mask to see if there are any other instances of 1u that need to
be changed.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V5 12/13] arch/powerpc: Replace open coded CONTEXT_BITS value
On Mon, Jul 30, 2012 at 04:52:18PM +0530, Aneesh Kumar K.V wrote: > From: "Aneesh Kumar K.V" > > To clarify the meaning for future readers, replace the open coded > 19 with CONTEXT_BITS > > Signed-off-by: Aneesh Kumar K.V > --- > arch/powerpc/mm/mmu_context_hash64.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/powerpc/mm/mmu_context_hash64.c > b/arch/powerpc/mm/mmu_context_hash64.c > index 40677aa..daa076c 100644 > --- a/arch/powerpc/mm/mmu_context_hash64.c > +++ b/arch/powerpc/mm/mmu_context_hash64.c > @@ -34,7 +34,7 @@ static DEFINE_IDA(mmu_context_ida); > * Each segment contains 2^28 bytes. Each context maps 2^44 bytes, > * so we can support 2^19-1 contexts (19 == 35 + 28 - 44). > */ > -#define MAX_CONTEXT ((1UL << 19) - 1) > +#define MAX_CONTEXT ((1UL << CONTEXT_BITS) - 1) This is a good thing to do, but you should also update the comment. Maybe you should put this patch before your number 10/13 and then change the comment in the same patch where you add the 64TB support. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V5 07/13] arch/powerpc: Make some of the PGTABLE_RANGE dependency explicit
On Mon, Jul 30, 2012 at 04:52:13PM +0530, Aneesh Kumar K.V wrote: > From: "Aneesh Kumar K.V" > > slice array size and slice mask size depend on PGTABLE_RANGE. We > can't directly include pgtable.h in these header because there is > a circular dependency. So add compile time check for these values. > > Signed-off-by: Aneesh Kumar K.V Reviewed-by: Paul Mackerras but you might like to change: > +#define SLICE_MASK_SIZE (PGTABLE_RANG >> 43) to have PGTABLE_RANGE rather than PGTABLE_RANG. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V5 03/13] arch/powerpc: Convert virtual address to vpn
On Mon, Jul 30, 2012 at 04:52:09PM +0530, Aneesh Kumar K.V wrote: > From: "Aneesh Kumar K.V" > > This patch convert different functions to take virtual page number > instead of virtual address. Virtual page number is virtual address > shifted right by VPN_SHIFT (12) bits. This enable us to have an > address range of upto 76 bits. Mostly looks good. I don't think it's necessary to add the BUILD_BUG_ON and BUG_ON conditions. I would think a comment next to the definition saying that VPN_SHIFT can be at most 12 would be sufficient. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V5 13/13] arch/powerpc: Update VSID allocation documentation
On Mon, Jul 30, 2012 at 04:52:19PM +0530, Aneesh Kumar K.V wrote: > From: "Aneesh Kumar K.V" > > This update the proto-VSID and VSID scramble related information > to be more generic by using names instead of current values. Comments below... > - * VSID allocation > + * VSID allocation (256MB segment) > * > - * We first generate a 36-bit "proto-VSID". For kernel addresses this > - * is equal to the ESID, for user addresses it is: > - * (context << 15) | (esid & 0x7fff) > + * We first generate a 38-bit "proto-VSID". For kernel addresses this > + * is equal to the ESID | 1 << 37, for user addresses it is: > + * (context << USER_ESID_BITS) | (esid & (1U << USER_ESID_BITS)) ^^ should be ((1U << USER_ESID_BITS) - 1) > * > - * The two forms are distinguishable because the top bit is 0 for user > - * addresses, whereas the top two bits are 1 for kernel addresses. > - * Proto-VSIDs with the top two bits equal to 0b10 are reserved for > - * now. > + * This splits the proto-VSID into the below range > + * 0 - (2^(CONTEXT_BITS + USER_ESID_BITS) - 1) : User proto-VSID range > + * 2^(CONTEXT_BITS + USER_ESID_BITS) - 2^(VSID_BITS) : Kernel proto-VSID > range Perhaps point out also that CONTEXT_BITS + USER_ESID_BITS == VSID_BITS - 1, that is, you have assigned half of the space to user processes and half to the kernel. > -/* > - * WARNING - If you change these you must make sure the asm > - * implementations in slb_allocate (slb_low.S), do_stab_bolted > - * (head.S) and ASM_VSID_SCRAMBLE (below) are changed accordingly. > - */ Are you absolutely sure that nothing in the assembly code would need to be changed if someone changed these definitions? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V5 11/13] arch/powerpc: properly isolate kernel and user proto-VSID
On Mon, Jul 30, 2012 at 04:52:17PM +0530, Aneesh Kumar K.V wrote: > From: "Aneesh Kumar K.V" > > The proto-VSID space is divided into two class > User: 0 to 2^(CONTEXT_BITS + USER_ESID_BITS) -1 > kernel: 2^(CONTEXT_BITS + USER_ESID_BITS) to 2^(VSID_BITS) - 1 > > With KERNEL_START at 0xc000, the proto vsid for > the kernel ends up with 0xc (36 bits). With 64TB > patchset we need to have kernel proto-VSID in the > [2^37 to 2^38 - 1] range due to the increased USER_ESID_BITS. This needs to be rolled in with the previous patch, otherwise you'll break bisection. > diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/slb_low.S > index db2cb3f..405d380 100644 > --- a/arch/powerpc/mm/slb_low.S > +++ b/arch/powerpc/mm/slb_low.S > @@ -57,8 +57,16 @@ _GLOBAL(slb_allocate_realmode) > _GLOBAL(slb_miss_kernel_load_linear) > li r11,0 > BEGIN_FTR_SECTION > + li r9,0x1 > + rldimi r10,r9,(CONTEXT_BITS + USER_ESID_BITS),0 > b slb_finish_load > END_MMU_FTR_SECTION_IFCLR(MMU_FTR_1T_SEGMENT) > + li r9,0x1 > + /* > + * shift 12 bits less here, slb_finish_load_1T will do > + * the necessary shits > + */ > + rldimi r10,r9,(CONTEXT_BITS + USER_ESID_BITS),0 > b slb_finish_load_1T Since you're actually doing exactly the same instructions in the 256M and 1T segment cases, why not do the li; rldimi before the BEGIN_FTR_SECTION? > @@ -86,8 +94,16 @@ _GLOBAL(slb_miss_kernel_load_vmemmap) > li r11,0 > 6: > BEGIN_FTR_SECTION > + li r9,0x1 > + rldimi r10,r9,(CONTEXT_BITS + USER_ESID_BITS),0 > b slb_finish_load > END_MMU_FTR_SECTION_IFCLR(MMU_FTR_1T_SEGMENT) > + li r9,0x1 > + /* > + * shift 12 bits less here, slb_finish_load_1T will do > + * the necessary shits > + */ > + rldimi r10,r9,(CONTEXT_BITS + USER_ESID_BITS),0 > b slb_finish_load_1T And similarly here. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V5 08/13] arch/powerpc: Use the rquired number of VSID bits in slbmte
On Mon, Jul 30, 2012 at 04:52:14PM +0530, Aneesh Kumar K.V wrote: > From: "Aneesh Kumar K.V" > > ASM_VSID_SCRAMBLE can leave non-zero bits in the high 28 bits of the result > for 256MB segment (40 bits for 1T segment). Properly mask them before using > the values in slbmte > > Signed-off-by: Aneesh Kumar K.V Reviewed-by: Paul Mackerras but change the subject line to say "required" not "rquired". ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 7/7] carma: remove unnecessary DMA_INTERRUPT capability
> -Original Message-
> From: Ira W. Snyder [mailto:i...@ovro.caltech.edu]
> Sent: Wednesday, August 01, 2012 7:46 AM
> To: linux-cry...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org; Liu Qiang-B32616; Ira W. Snyder
> Subject: [PATCH 7/7] carma: remove unnecessary DMA_INTERRUPT capability
>
> From: "Ira W. Snyder"
>
> These drivers set the DMA_INTERRUPT capability bit when requesting a DMA
> controller channel. This was historical, and is no longer needed.
>
> Recent changes to the drivers/dma/fsldma.c driver have removed support
> for this flag. This makes the carma drivers unable to find a DMA channel
> with the required capabilities.
>
> Signed-off-by: Ira W. Snyder
> ---
> drivers/misc/carma/carma-fpga-program.c |1 -
> drivers/misc/carma/carma-fpga.c |3 +--
> 2 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/misc/carma/carma-fpga-program.c
> b/drivers/misc/carma/carma-fpga-program.c
> index a2d25e4..eaddfe9 100644
> --- a/drivers/misc/carma/carma-fpga-program.c
> +++ b/drivers/misc/carma/carma-fpga-program.c
> @@ -978,7 +978,6 @@ static int fpga_of_probe(struct platform_device *op)
> dev_set_drvdata(priv->dev, priv);
> dma_cap_zero(mask);
> dma_cap_set(DMA_MEMCPY, mask);
> - dma_cap_set(DMA_INTERRUPT, mask);
> dma_cap_set(DMA_SLAVE, mask);
> dma_cap_set(DMA_SG, mask);
>
> diff --git a/drivers/misc/carma/carma-fpga.c b/drivers/misc/carma/carma-
> fpga.c index 8c279da..861b298 100644
> --- a/drivers/misc/carma/carma-fpga.c
> +++ b/drivers/misc/carma/carma-fpga.c
> @@ -666,7 +666,7 @@ static int data_submit_dma(struct fpga_device *priv,
> struct data_buf *buf)
> src = SYS_FPGA_BLOCK;
> tx = chan->device->device_prep_dma_memcpy(chan, dst, src,
> REG_BLOCK_SIZE,
> - DMA_PREP_INTERRUPT);
> + 0);
> if (!tx) {
> dev_err(priv->dev, "unable to prep SYS-FPGA DMA\n");
> return -ENOMEM;
> @@ -1333,7 +1333,6 @@ static int data_of_probe(struct platform_device *op)
>
> dma_cap_zero(mask);
> dma_cap_set(DMA_MEMCPY, mask);
> - dma_cap_set(DMA_INTERRUPT, mask);
> dma_cap_set(DMA_SLAVE, mask);
> dma_cap_set(DMA_SG, mask);
Hi Ira, attached link is the comments of Dan Williams to the original patch of
fsl-dma.
http://lkml.indiana.edu/hypermail/linux/kernel/0910.1/03836.html
> --
> 1.7.8.6
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/7] fsl-dma: fixes for Freescale DMA driver
Hi Ira, My comments inline. > -Original Message- > From: Ira W. Snyder [mailto:i...@ovro.caltech.edu] > Sent: Wednesday, August 01, 2012 7:46 AM > To: linux-cry...@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org; Liu Qiang-B32616; Ira W. Snyder > Subject: [PATCH 0/7] fsl-dma: fixes for Freescale DMA driver > > From: "Ira W. Snyder" > > Hello everyone, > > This is my alternative (simpler) attempt at solving the problems reported > by Qiang Liu with the async_tx API and MD RAID hardware offload support > when using the Freescale DMA driver. > > The bug is caused by this driver freeing descriptors before they have > been ACKed by software using the async_tx API. > > I don't like Qiang Liu's code to check where the hardware is in the > processing of the descriptor chain, and try to free a partial list of > descriptors. This was a source of bugs in this driver before I fixed them > several years ago. It's a bug which you think the whole list is completed when an interrupt is raised, there is a potential risk when an interrupt is raised by "Programmed Error". The "ld_running" is a s/w concept, we should not depend on it to judge the status of descriptors list. I know you don't like this process, but it's a safe and common process. You can refer to other dma drivers, like ioap-adma, mv-xor and ibm-ppc440x-adma. Said far point, usb also take this method to judge which descriptor is completed, I don't know which device can use a s/w list to free all descriptors, you can refer to the implement of dl_reverse_done_list(). If you find any problem in my patch, please point out, or you can give a link about the bug you mentioned many years ago. Thanks. > > Instead, the DMA controller raises an interrupt every time it has > completed a descriptor chain. This means it is ready for new descriptors: > no need to try and figure out where it is in the middle of a descriptor > chain. Attached again, The interrupt is only report the state of hardware, we cannot assume all descriptors are finished when an interrupt is raised. > > Qiang Liu: I do not have a hardware setup capable of using MD RAID. > Please test these patches to see if they fix the bug you reported. You > may use these patches as-is, or build upon them. I hope we can discuss it based on my patch. If you think my patch will involve some issue, please point out. I'm willing to fix it. Thanks. > > I have tested this using the drivers/dma/dmatest.c driver, as well as the > CARMA drivers. There are no regressions that I can find. > > [ 355.069679] dma0chan3-copy0: terminating after 10 tests, 0 > failures (status 0) [ 355.192278] dma0chan2-copy0: terminating after > 10 tests, 0 failures (status 0) > > Ira W. Snyder (5): > fsl-dma: minimize locking overhead > fsl-dma: add fsl_dma_free_descriptor() to reduce code duplication > fsl-dma: move functions to avoid forward declarations > fsl-dma: fix support for async_tx API > carma: remove unnecessary DMA_INTERRUPT capability > > Qiang Liu (2): > fsl-dma: remove attribute DMA_INTERRUPT of dmaengine > fsl-dma: fix a warning of unitialized cookie > > drivers/dma/fsldma.c| 318 +++-- > -- > drivers/dma/fsldma.h|1 + > drivers/misc/carma/carma-fpga-program.c |1 - > drivers/misc/carma/carma-fpga.c |3 +- > 4 files changed, 159 insertions(+), 164 deletions(-) > > -- > 1.7.8.6 > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v4 3/7] fsl-dma: change release process of dma descriptor for supporting async_tx
> -Original Message- > From: Ira W. Snyder [mailto:i...@ovro.caltech.edu] > Sent: Wednesday, August 01, 2012 6:14 AM > To: Liu Qiang-B32616 > Cc: linux-cry...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Phillips > Kim-R1AAHA; da...@davemloft.net; dan.j.willi...@gmail.com; Vinod Koul; Li > Yang-R58472; herb...@gondor.apana.org.au > Subject: Re: [PATCH v4 3/7] fsl-dma: change release process of dma > descriptor for supporting async_tx > > On Tue, Jul 31, 2012 at 04:09:28AM +, Liu Qiang-B32616 wrote: > > > -Original Message- > > > From: Ira W. Snyder [mailto:i...@ovro.caltech.edu] > > > Sent: Tuesday, July 31, 2012 5:10 AM > > > To: Liu Qiang-B32616 > > > Cc: linux-cry...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; > Phillips > > > Kim-R1AAHA; herb...@gondor.hengli.com.au; da...@davemloft.net; Dan > > > Williams; Vinod Koul; Li Yang-R58472 > > > Subject: Re: [PATCH v4 3/7] fsl-dma: change release process of dma > > > descriptor for supporting async_tx > > > > > > On Fri, Jul 27, 2012 at 05:16:09PM +0800, qiang@freescale.com > wrote: > > > > From: Qiang Liu > > > > > > > > Fix the potential risk when enable config NET_DMA and ASYNC_TX. > > > > Async_tx is lack of support in current release process of dma > > > descriptor, > > > > all descriptors will be released whatever is acked or no-acked by > > > async_tx, > > > > so there is a potential race condition when dma engine is uesd by > > > others > > > > clients (e.g. when enable NET_DMA to offload TCP). > > > > > > > > In our case, a race condition which is raised when use both of > talitos > > > > and dmaengine to offload xor is because napi scheduler will sync > all > > > > pending requests in dma channels, it affects the process of raid > > > operations > > > > due to ack_tx is not checked in fsl dma. The no-acked descriptor is > > > freed > > > > which is submitted just now, as a dependent tx, this freed > descriptor > > > trigger > > > > BUG_ON(async_tx_test_ack(depend_tx)) in async_tx_submit(). > > > > > > > > > > I'm preparing an alternative version of this patch that I think is > > > easier to understand (it is much shorter). I'll post it up here as > soon > > > as I finish testing. > > Can you give a simple description/idea about your patch? My patch is > for fix the > > problems when I build a raid environment with talitos offload xor. > > I think the new interface is clear enough and similar with the > implement of other dma devices. > > > > And do you have any comments about this patch? > > > > My patch will fix the same problem, in a simpler way. It will not > involve checking if the hardware is finished with a descriptor on > ld_running. > > > > > > > It would be nice to know how to easily reproduce this bug, without > > > needing to set up a RAID system. I don't have access to any such > > > hardware. A driver similar to drivers/dma/dmatest.c (using the > async_tx > > > API instead) would be wonderful. > > You can refer to raid5.c if you do not want to use hardware. Or you can > use > > you ram (or other storage devices) to build a raid env to test. > > Thanks. > > > > > > > > Thanks, > > > Ira > > > > > > > TASK = ee1a94a0[1390] 'md0_raid5' THREAD: ecf4 CPU: 0 > > > > GPR00: 0001 ecf41ca0 ee44/921a94a0 003f 0001 c00593e4 > > > 0001 > > > > GPR08: a7a7a7a7 0001 045/92002 42028042 100a38d4 > > > ed576d98 > > > > GPR16: ed5a11b0 2b162000 0200 046/92000 2d555000 > > > ed3015e8 c15a7aa0 > > > > GPR24: c155fc40 ecb63220 ecf41d28 e47/92f640bb0 > > > ef640c30 ecf41ca0 > > > > NIP [c02b048c] async_tx_submit+0x6c/0x2b4 > > > > LR [c02b068c] async_tx_submit+0x26c/0x2b4 > > > > Call Trace: > > > > [ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable) > > > > [ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c > > > > [ecf41d20] [c0421064] async_copy_data+0xa0/0x17c > > > > [ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10 > > > > [ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8 > > > > [ecf41e90] [c0429080] raid5d+0x3d4/0x5b4 > > > > [ecf41f40] [c04329b8] md_thread+0x138/0x16c > > > > [ecf41f90] [c008277c] kthread+0x8c/0x90 > > > > [ecf41ff0] [c0011630] kernel_thread+0x4c/0x68 > > > > > > > > Cc: Dan Williams > > > > Cc: Vinod Koul > > > > Cc: Li Yang > > > > Cc: Ira W. Snyder > > > > Signed-off-by: Qiang Liu > > > > --- > > > > drivers/dma/fsldma.c | 242 +++--- > > > > > > > > drivers/dma/fsldma.h |1 + > > > > 2 files changed, 172 insertions(+), 71 deletions(-) > > > > > > > > diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c > > > > index 4f2f212..87f52c0 100644 > > > > --- a/drivers/dma/fsldma.c > > > > +++ b/drivers/dma/fsldma.c > > > > @@ -400,6 +400,125 @@ out_splice: > > > > list_splice_tail_init(&desc->tx_list, &chan->ld_pending); > > > > } > > > > > > > > +static void fsldma_cleanup_descriptor(struct fsldma_chan *chan); > > > > +static void f
Re: [RFC PATCH v5 12/19] memory-hotplug: introduce new function arch_remove_memory()
2012/7/27 Wen Congyang :
> We don't call __add_pages() directly in the function add_memory()
> because some other architecture related things need to be done
> before or after calling __add_pages(). So we should introduce
> a new function arch_remove_memory() to revert the things
> done in arch_add_memory().
>
> Note: the function for s390 is not implemented(I don't know how to
> implement it for s390).
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Yasuaki Ishimatsu
> Signed-off-by: Wen Congyang
> ---
> arch/ia64/mm/init.c | 16
> arch/powerpc/mm/mem.c| 14 +++
> arch/s390/mm/init.c |8 ++
> arch/sh/mm/init.c| 15 +++
> arch/tile/mm/init.c |8 ++
> arch/x86/include/asm/pgtable_types.h |1 +
> arch/x86/mm/init_32.c| 10 ++
> arch/x86/mm/init_64.c| 160
> ++
> arch/x86/mm/pageattr.c | 47 +-
> include/linux/memory_hotplug.h |1 +
> mm/memory_hotplug.c |1 +
> 11 files changed, 259 insertions(+), 22 deletions(-)
>
> diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
> index 0eab454..1e345ed 100644
> --- a/arch/ia64/mm/init.c
> +++ b/arch/ia64/mm/init.c
> @@ -688,6 +688,22 @@ int arch_add_memory(int nid, u64 start, u64 size)
>
> return ret;
> }
> +
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +int arch_remove_memory(u64 start, u64 size)
> +{
> + unsigned long start_pfn = start >> PAGE_SHIFT;
> + unsigned long nr_pages = size >> PAGE_SHIFT;
> + int ret;
> +
> + ret = __remove_pages(start_pfn, nr_pages);
> + if (ret)
> + pr_warn("%s: Problem encountered in __remove_pages() as"
> + " ret=%d\n", __func__, ret);
> +
> + return ret;
> +}
> +#endif
> #endif
>
in 3.5 ia64 implementation did not call __remove_pages at all. so why?
> /*
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index baaafde..249cef4 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -133,6 +133,20 @@ int arch_add_memory(int nid, u64 start, u64 size)
>
> return __add_pages(nid, zone, start_pfn, nr_pages);
> }
> +
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +int arch_remove_memory(u64 start, u64 size)
> +{
> + unsigned long start_pfn = start >> PAGE_SHIFT;
> + unsigned long nr_pages = size >> PAGE_SHIFT;
> +
> + start = (unsigned long)__va(start);
> + if (remove_section_mapping(start, start + size))
> + return -EINVAL;
> +
> + return __remove_pages(start_pfn, nr_pages);
> +}
> +#endif
> #endif /* CONFIG_MEMORY_HOTPLUG */
>
> /*
> diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
> index 6adbc08..ca4bc46 100644
> --- a/arch/s390/mm/init.c
> +++ b/arch/s390/mm/init.c
> @@ -257,4 +257,12 @@ int arch_add_memory(int nid, u64 start, u64 size)
> vmem_remove_mapping(start, size);
> return rc;
> }
> +
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +int arch_remove_memory(u64 start, u64 size)
> +{
> + /* TODO */
> + return -EBUSY;
> +}
> +#endif
> #endif /* CONFIG_MEMORY_HOTPLUG */
> diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
> index 82cc576..fc84491 100644
> --- a/arch/sh/mm/init.c
> +++ b/arch/sh/mm/init.c
> @@ -558,4 +558,19 @@ int memory_add_physaddr_to_nid(u64 addr)
> EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
> #endif
>
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +int arch_remove_memory(u64 start, u64 size)
> +{
> + unsigned long start_pfn = start >> PAGE_SHIFT;
> + unsigned long nr_pages = size >> PAGE_SHIFT;
> + int ret;
> +
> + ret = __remove_pages(start_pfn, nr_pages);
> + if (unlikely(ret))
> + pr_warn("%s: Failed, __remove_pages() == %d\n", __func__,
> + ret);
> +
> + return ret;
> +}
> +#endif
> #endif /* CONFIG_MEMORY_HOTPLUG */
> diff --git a/arch/tile/mm/init.c b/arch/tile/mm/init.c
> index ef29d6c..2749515 100644
> --- a/arch/tile/mm/init.c
> +++ b/arch/tile/mm/init.c
> @@ -935,6 +935,14 @@ int remove_memory(u64 start, u64 size)
> {
> return -EINVAL;
> }
> +
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +int arch_remove_memory(u64 start, u64 size)
> +{
> + /* TODO */
> + return -EBUSY;
> +}
> +#endif
> #endif
>
> struct kmem_cache *pgd_cache;
> diff --git a/arch/x86/include/asm/pgtable_types.h
> b/arch/x86/include/asm/pgtable_types.h
> index 013286a..b725af2 100644
> --- a/arch/x86/include/asm/pgtable_types.h
> +++ b/arch/x86/include/asm/pgtable_types.h
> @@ -334,6 +334,7 @@ static inline void update_page_count(int level, unsigned
> long pages) { }
> * as a pte too.
> */
> extern pte_t *lookup_address(unsigned long address, unsigned int *level);
> +extern int __sp
RE: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code
> -Original Message- > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > Sent: Tuesday, July 31, 2012 9:38 PM > To: Li Yang-R58472 > Cc: Jia Hongtao-B38951; Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; > Li Yang-R58472 > Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie > initialization code > > > On Jul 31, 2012, at 2:21 AM, Li Yang wrote: > > > On Mon, Jul 30, 2012 at 10:46 PM, Kumar Gala > wrote: > >> > >> On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote: > >> > >>> > >>> > -Original Message- > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > Sent: Saturday, July 28, 2012 5:17 AM > To: Wood Scott-B07421 > Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood Scott- > B07421; > Li Yang-R58472 > Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie > initialization code > > > On Jul 27, 2012, at 3:24 PM, Scott Wood wrote: > > > On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote: > >> Hi kumar, > >> > >> I know "duplicate code from pci_process_bridge_OF_ranges()" is > >> hard to accept but "refactor the code to have a shared function" > >> is knotty. Actually this is the reason I didn't do the refactor. > > > > Maybe we should keep doing the init early? We could still have a > > platform device for the PM stuff, but some init would be done > before > probe. > > > > Another possibility is to try to handle swiotlb init later -- > possibly > > by reserving memory for it if the platform indicates it's a > possibility > > that it will be needed, then freeing the memory if it's not needed. > > > > -Scott > > I think the first option seems reasonable. Can we leave > fsl_pci_init() > as we now have it and just have the platform driver deal with PM > restore > via calling setup_pci_atmu() [probably need to update setup_pci_atmu > to > handle restore case, but seems like minor changes] > > - k > > >>> > >>> > >>> I think the second option is better if it's hard to decouple swiotlb > >>> determination from pci init. I believe the better architecture that > >>> PCI init in probe function of platform driver will bring us > considerable > >>> advantage. I really like to keep the completion of pci controller > >>> platform driver not only for PM support but also for pci init. > >>> > >>> -Hongtao. > >>> > >> > >> Shifting of swiotlb init has a lot more issues. Why do we need to do > the PCI init in probe? > > > > The ordering issues are introduced by swiotlb. And the ideal way is > > to solve the problem within swiotlb instead of changing PCI to > > workaround it. Take the implementation of x86 as reference it's > > possible to be addressed bu allocating first and free later approach. > > > > It is common sense that the initialization of a device is in the probe > > function of the driver of the device. And the change will provide > > better unification of PCI controller code. The PCI controller is > > generic enough not to be taken care of at the platform area. > > > > Leo > > Than lets look at going with that approach.. Be careful with impact on > other users of swiotlb on PPC, I believe one 44x board uses swiotlb. > > - k I will be careful with this approach. I have already noticed 44x. Thank you all the same. -Hongtao. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.5+: yaboot, Invalid memory access
On Mon, Jul 30, 2012 at 10:46:39PM -0700, Christian Kujau wrote: > Hi, > > when trying to upgrade from 3.5 (final) to today's git checkout from > Linus' tree, yaboot cannot boot and the following is printed: > > [...] > returning from prom_init > Invalid memory access at %SRR0: 00c62fd4 %SRR1: 3030 > > The whole message: http://nerdbynature.de/bits/3.5.0/yaboot/ > > The Yaboot version is 1.3.16 (from Debian/testing), I haven't tried 1.3.17 > yet, its changelog does not say anything about "newer kernel support" so > I'm not sure if this would help here. Well the "returning from prom_init" message is from the kernel so yaboot has done something. We'll work out if it was the right thing ;P I had a look at the URL you provided. 1) can you also upload you vmlinux so we can poke at it. 2) What is the dmseg.txt file there? If you're unable to boot 3.5 how did you get the dmesg? Yours Tony pgpzZ9nVBF0M8.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v5 12/19] memory-hotplug: introduce new function arch_remove_memory()
At 07/31/2012 08:40 PM, Gerald Schaefer Wrote: > On Mon, 30 Jul 2012 18:35:37 +0800 > Wen Congyang wrote: > >> At 07/30/2012 06:23 PM, Heiko Carstens Wrote: >>> On Fri, Jul 27, 2012 at 06:32:15PM +0800, Wen Congyang wrote: We don't call __add_pages() directly in the function add_memory() because some other architecture related things need to be done before or after calling __add_pages(). So we should introduce a new function arch_remove_memory() to revert the things done in arch_add_memory(). Note: the function for s390 is not implemented(I don't know how to implement it for s390). >>> >>> There is no hardware or firmware interface which could trigger a >>> hot memory remove on s390. So there is nothing that needs to be >>> implemented. >> >> Thanks for providing this information. >> >> According to this, arch_remove_memory() for s390 can just return >> -EBUSY. > > Yes, but there is a prototype mismatch for arch_remove_memory() on s390 > and also other architectures (u64 vs. unsigned long). > > arch/s390/mm/init.c:262: error: conflicting types for > ‘arch_remove_memory’ include/linux/memory_hotplug.h:88: error: previous > declaration of ‘arch_remove_memory’ was here > > In memory_hotplug.h you have: > extern int arch_remove_memory(unsigned long start, unsigned long size); > > On all archs other than x86 you have: > int arch_remove_memory(u64 start, u64 size) Thanks for pointing it out. I will fix it. Wen Congyang > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 7/7] carma: remove unnecessary DMA_INTERRUPT capability
From: "Ira W. Snyder"
These drivers set the DMA_INTERRUPT capability bit when requesting a DMA
controller channel. This was historical, and is no longer needed.
Recent changes to the drivers/dma/fsldma.c driver have removed support
for this flag. This makes the carma drivers unable to find a DMA channel
with the required capabilities.
Signed-off-by: Ira W. Snyder
---
drivers/misc/carma/carma-fpga-program.c |1 -
drivers/misc/carma/carma-fpga.c |3 +--
2 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/carma/carma-fpga-program.c
b/drivers/misc/carma/carma-fpga-program.c
index a2d25e4..eaddfe9 100644
--- a/drivers/misc/carma/carma-fpga-program.c
+++ b/drivers/misc/carma/carma-fpga-program.c
@@ -978,7 +978,6 @@ static int fpga_of_probe(struct platform_device *op)
dev_set_drvdata(priv->dev, priv);
dma_cap_zero(mask);
dma_cap_set(DMA_MEMCPY, mask);
- dma_cap_set(DMA_INTERRUPT, mask);
dma_cap_set(DMA_SLAVE, mask);
dma_cap_set(DMA_SG, mask);
diff --git a/drivers/misc/carma/carma-fpga.c b/drivers/misc/carma/carma-fpga.c
index 8c279da..861b298 100644
--- a/drivers/misc/carma/carma-fpga.c
+++ b/drivers/misc/carma/carma-fpga.c
@@ -666,7 +666,7 @@ static int data_submit_dma(struct fpga_device *priv, struct
data_buf *buf)
src = SYS_FPGA_BLOCK;
tx = chan->device->device_prep_dma_memcpy(chan, dst, src,
REG_BLOCK_SIZE,
- DMA_PREP_INTERRUPT);
+ 0);
if (!tx) {
dev_err(priv->dev, "unable to prep SYS-FPGA DMA\n");
return -ENOMEM;
@@ -1333,7 +1333,6 @@ static int data_of_probe(struct platform_device *op)
dma_cap_zero(mask);
dma_cap_set(DMA_MEMCPY, mask);
- dma_cap_set(DMA_INTERRUPT, mask);
dma_cap_set(DMA_SLAVE, mask);
dma_cap_set(DMA_SG, mask);
--
1.7.8.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 6/7] fsl-dma: fix a warning of unitialized cookie
From: Qiang Liu Fix a warning of unitialized value when compile with -Wuninitialized. Cc: Dan Williams Cc: Vinod Koul Cc: Li Yang Signed-off-by: Qiang Liu Cc: Kim Phillips --- drivers/dma/fsldma.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index 380c1b7..8588cf7 100644 --- a/drivers/dma/fsldma.c +++ b/drivers/dma/fsldma.c @@ -523,7 +523,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx) struct fsldma_chan *chan = to_fsl_chan(tx->chan); struct fsl_desc_sw *desc = tx_to_fsl_desc(tx); struct fsl_desc_sw *child; - dma_cookie_t cookie; + dma_cookie_t cookie = 0; spin_lock_irq(&chan->desc_lock); -- 1.7.8.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/7] fsl-dma: fix support for async_tx API
From: "Ira W. Snyder"
The current fsldma driver does not support the async_tx API. This is due
to a bug: all descriptors are released when the hardware is finished
with them. The async_tx API requires that the ACK bit is set by software
before descriptors are freed.
This bug is easiest to reproduce by enabling both CONFIG_NET_DMA and
CONFIG_ASYNC_TX, and using the hardware offload support in MD RAID. The
network stack will force operations on shared DMA channels, and will
free descriptors which are being used by the MD RAID code.
The BUG_ON(async_tx_test_ack(depend_tx)) test in async_tx_submit() will
be hit, and panic the machine.
TASK = ee1a94a0[1390] 'md0_raid5' THREAD: ecf4 CPU: 0
GPR00: 0001 ecf41ca0 ee44/921a94a0 003f 0001 c00593e4
0001
GPR08: a7a7a7a7 0001 045/92002 42028042 100a38d4 ed576d98
GPR16: ed5a11b0 2b162000 0200 046/92000 2d555000 ed3015e8
c15a7aa0
GPR24: c155fc40 ecb63220 ecf41d28 e47/92f640bb0 ef640c30
ecf41ca0
NIP [c02b048c] async_tx_submit+0x6c/0x2b4
LR [c02b068c] async_tx_submit+0x26c/0x2b4
Call Trace:
[ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable)
[ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c
[ecf41d20] [c0421064] async_copy_data+0xa0/0x17c
[ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10
[ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8
[ecf41e90] [c0429080] raid5d+0x3d4/0x5b4
[ecf41f40] [c04329b8] md_thread+0x138/0x16c
[ecf41f90] [c008277c] kthread+0x8c/0x90
[ecf41ff0] [c0011630] kernel_thread+0x4c/0x68
Cc: Dan Williams
Cc: Vinod Koul
Cc: Li Yang
Cc: Qiang Liu
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 156 +++---
drivers/dma/fsldma.h |1 +
2 files changed, 97 insertions(+), 60 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 80edc63..380c1b7 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -410,16 +410,15 @@ static void fsl_dma_free_descriptor(struct fsldma_chan
*chan, struct fsl_desc_sw
}
/**
- * fsldma_cleanup_descriptor - cleanup and free a single link descriptor
+ * fsldma_run_tx_complete_actions - run callback and unmap descriptor
* @chan: Freescale DMA channel
* @desc: descriptor to cleanup and free
*
* This function is used on a descriptor which has been executed by the DMA
- * controller. It will run any callbacks, submit any dependencies, and then
- * free the descriptor.
+ * controller. It will run the callback and unmap the descriptor, if requested.
*/
-static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
- struct fsl_desc_sw *desc)
+static void fsldma_run_tx_complete_actions(struct fsldma_chan *chan,
+ struct fsl_desc_sw *desc)
{
struct dma_async_tx_descriptor *txd = &desc->async_tx;
struct device *dev = chan->common.device->dev;
@@ -427,6 +426,10 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan
*chan,
dma_addr_t dst = get_desc_dst(chan, desc);
u32 len = get_desc_cnt(chan, desc);
+ /* Cookies with value zero are already cleaned up */
+ if (txd->cookie == 0)
+ return;
+
/* Run the link descriptor callback function */
if (txd->callback) {
#ifdef FSL_DMA_LD_DEBUG
@@ -435,9 +438,6 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan
*chan,
txd->callback(txd->callback_param);
}
- /* Run any dependencies */
- dma_run_dependencies(txd);
-
/* Unmap the dst buffer, if requested */
if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) {
if (txd->flags & DMA_COMPL_DEST_UNMAP_SINGLE)
@@ -454,7 +454,68 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan
*chan,
dma_unmap_page(dev, src, len, DMA_TO_DEVICE);
}
- fsl_dma_free_descriptor(chan, desc);
+ /*
+* A zeroed cookie indicates that cleanup actions have been
+* run, but the descriptor has not yet been ACKed.
+*/
+ txd->cookie = 0;
+}
+
+/**
+ * fsldma_cleanup_descriptors - cleanup and free link descriptors
+ * @chan: Freescale DMA channel
+ *
+ * This function is used to clean up all descriptors which have been executed
+ * by the DMA controller. It will run any callbacks, submit any dependencies,
+ * and free any descriptors which have been ACKed.
+ *
+ * LOCKING: must NOT hold chan->desc_lock
+ * CONTEXT: any
+ */
+static void fsldma_cleanup_descriptors(struct fsldma_chan *chan)
+{
+ struct fsl_desc_sw *desc, *_desc;
+ dma_cookie_t cookie = 0;
+ LIST_HEAD(ld_cleanup);
+ unsigned long flags;
+
+ /*
+* Move all descriptors onto a temporary list so that hardware
+* interrupts can be enabled during cleanup
+*/
+ spin_lock_irqsave(&chan->desc_lock, flags);
+ list_splice_tail_init(&chan->ld_completed,
[PATCH 4/7] fsl-dma: move functions to avoid forward declarations
From: "Ira W. Snyder"
This function will be modified in the next patch in the series. By
moving the function in a patch separate from the changes, it will make
review easier.
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 96 +-
1 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index c34a628..80edc63 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -409,6 +409,54 @@ static void fsl_dma_free_descriptor(struct fsldma_chan
*chan, struct fsl_desc_sw
dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
}
+/**
+ * fsldma_cleanup_descriptor - cleanup and free a single link descriptor
+ * @chan: Freescale DMA channel
+ * @desc: descriptor to cleanup and free
+ *
+ * This function is used on a descriptor which has been executed by the DMA
+ * controller. It will run any callbacks, submit any dependencies, and then
+ * free the descriptor.
+ */
+static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
+ struct fsl_desc_sw *desc)
+{
+ struct dma_async_tx_descriptor *txd = &desc->async_tx;
+ struct device *dev = chan->common.device->dev;
+ dma_addr_t src = get_desc_src(chan, desc);
+ dma_addr_t dst = get_desc_dst(chan, desc);
+ u32 len = get_desc_cnt(chan, desc);
+
+ /* Run the link descriptor callback function */
+ if (txd->callback) {
+#ifdef FSL_DMA_LD_DEBUG
+ chan_dbg(chan, "LD %p callback\n", desc);
+#endif
+ txd->callback(txd->callback_param);
+ }
+
+ /* Run any dependencies */
+ dma_run_dependencies(txd);
+
+ /* Unmap the dst buffer, if requested */
+ if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) {
+ if (txd->flags & DMA_COMPL_DEST_UNMAP_SINGLE)
+ dma_unmap_single(dev, dst, len, DMA_FROM_DEVICE);
+ else
+ dma_unmap_page(dev, dst, len, DMA_FROM_DEVICE);
+ }
+
+ /* Unmap the src buffer, if requested */
+ if (!(txd->flags & DMA_COMPL_SKIP_SRC_UNMAP)) {
+ if (txd->flags & DMA_COMPL_SRC_UNMAP_SINGLE)
+ dma_unmap_single(dev, src, len, DMA_TO_DEVICE);
+ else
+ dma_unmap_page(dev, src, len, DMA_TO_DEVICE);
+ }
+
+ fsl_dma_free_descriptor(chan, desc);
+}
+
static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
{
struct fsldma_chan *chan = to_fsl_chan(tx->chan);
@@ -807,54 +855,6 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
}
/**
- * fsldma_cleanup_descriptor - cleanup and free a single link descriptor
- * @chan: Freescale DMA channel
- * @desc: descriptor to cleanup and free
- *
- * This function is used on a descriptor which has been executed by the DMA
- * controller. It will run any callbacks, submit any dependencies, and then
- * free the descriptor.
- */
-static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
- struct fsl_desc_sw *desc)
-{
- struct dma_async_tx_descriptor *txd = &desc->async_tx;
- struct device *dev = chan->common.device->dev;
- dma_addr_t src = get_desc_src(chan, desc);
- dma_addr_t dst = get_desc_dst(chan, desc);
- u32 len = get_desc_cnt(chan, desc);
-
- /* Run the link descriptor callback function */
- if (txd->callback) {
-#ifdef FSL_DMA_LD_DEBUG
- chan_dbg(chan, "LD %p callback\n", desc);
-#endif
- txd->callback(txd->callback_param);
- }
-
- /* Run any dependencies */
- dma_run_dependencies(txd);
-
- /* Unmap the dst buffer, if requested */
- if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) {
- if (txd->flags & DMA_COMPL_DEST_UNMAP_SINGLE)
- dma_unmap_single(dev, dst, len, DMA_FROM_DEVICE);
- else
- dma_unmap_page(dev, dst, len, DMA_FROM_DEVICE);
- }
-
- /* Unmap the src buffer, if requested */
- if (!(txd->flags & DMA_COMPL_SKIP_SRC_UNMAP)) {
- if (txd->flags & DMA_COMPL_SRC_UNMAP_SINGLE)
- dma_unmap_single(dev, src, len, DMA_TO_DEVICE);
- else
- dma_unmap_page(dev, src, len, DMA_TO_DEVICE);
- }
-
- fsl_dma_free_descriptor(chan, desc);
-}
-
-/**
* fsl_chan_xfer_ld_queue - transfer any pending transactions
* @chan : Freescale DMA channel
*
--
1.7.8.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/7] fsl-dma: minimize locking overhead
From: "Ira W. Snyder"
The use of spin_lock_irqsave() was a stronger locking mechanism than was
actually needed in many cases.
As the current code is written, spin_lock_bh() everywhere is sufficient.
The next patch in this series will add some code to hardware interrupt
context. This patch is intended to minimize the differences in the next
patch and make review easier.
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 25 ++---
1 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 4f2f212..8f0505d 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -405,10 +405,9 @@ static dma_cookie_t fsl_dma_tx_submit(struct
dma_async_tx_descriptor *tx)
struct fsldma_chan *chan = to_fsl_chan(tx->chan);
struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
struct fsl_desc_sw *child;
- unsigned long flags;
dma_cookie_t cookie;
- spin_lock_irqsave(&chan->desc_lock, flags);
+ spin_lock_irq(&chan->desc_lock);
/*
* assign cookies to all of the software descriptors
@@ -421,7 +420,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct
dma_async_tx_descriptor *tx)
/* put this transaction onto the tail of the pending queue */
append_ld_queue(chan, desc);
- spin_unlock_irqrestore(&chan->desc_lock, flags);
+ spin_unlock_irq(&chan->desc_lock);
return cookie;
}
@@ -530,13 +529,12 @@ static void fsldma_free_desc_list_reverse(struct
fsldma_chan *chan,
static void fsl_dma_free_chan_resources(struct dma_chan *dchan)
{
struct fsldma_chan *chan = to_fsl_chan(dchan);
- unsigned long flags;
chan_dbg(chan, "free all channel resources\n");
- spin_lock_irqsave(&chan->desc_lock, flags);
+ spin_lock_irq(&chan->desc_lock);
fsldma_free_desc_list(chan, &chan->ld_pending);
fsldma_free_desc_list(chan, &chan->ld_running);
- spin_unlock_irqrestore(&chan->desc_lock, flags);
+ spin_unlock_irq(&chan->desc_lock);
dma_pool_destroy(chan->desc_pool);
chan->desc_pool = NULL;
@@ -755,7 +753,6 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
{
struct dma_slave_config *config;
struct fsldma_chan *chan;
- unsigned long flags;
int size;
if (!dchan)
@@ -765,7 +762,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
switch (cmd) {
case DMA_TERMINATE_ALL:
- spin_lock_irqsave(&chan->desc_lock, flags);
+ spin_lock_irq(&chan->desc_lock);
/* Halt the DMA engine */
dma_halt(chan);
@@ -775,7 +772,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
fsldma_free_desc_list(chan, &chan->ld_running);
chan->idle = true;
- spin_unlock_irqrestore(&chan->desc_lock, flags);
+ spin_unlock_irq(&chan->desc_lock);
return 0;
case DMA_SLAVE_CONFIG:
@@ -935,11 +932,10 @@ static void fsl_chan_xfer_ld_queue(struct fsldma_chan
*chan)
static void fsl_dma_memcpy_issue_pending(struct dma_chan *dchan)
{
struct fsldma_chan *chan = to_fsl_chan(dchan);
- unsigned long flags;
- spin_lock_irqsave(&chan->desc_lock, flags);
+ spin_lock_irq(&chan->desc_lock);
fsl_chan_xfer_ld_queue(chan);
- spin_unlock_irqrestore(&chan->desc_lock, flags);
+ spin_unlock_irq(&chan->desc_lock);
}
/**
@@ -952,11 +948,10 @@ static enum dma_status fsl_tx_status(struct dma_chan
*dchan,
{
struct fsldma_chan *chan = to_fsl_chan(dchan);
enum dma_status ret;
- unsigned long flags;
- spin_lock_irqsave(&chan->desc_lock, flags);
+ spin_lock_irq(&chan->desc_lock);
ret = dma_cookie_status(dchan, cookie, txstate);
- spin_unlock_irqrestore(&chan->desc_lock, flags);
+ spin_unlock_irq(&chan->desc_lock);
return ret;
}
--
1.7.8.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/7] fsl-dma: add fsl_dma_free_descriptor() to reduce code duplication
From: "Ira W. Snyder"
There are several places where descriptors are freed using identical
code. Put this code into a function to reduce code duplication.
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 32 ++--
1 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 8f0505d..c34a628 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -400,6 +400,15 @@ out_splice:
list_splice_tail_init(&desc->tx_list, &chan->ld_pending);
}
+static void fsl_dma_free_descriptor(struct fsldma_chan *chan, struct
fsl_desc_sw *desc)
+{
+ list_del(&desc->node);
+#ifdef FSL_DMA_LD_DEBUG
+ chan_dbg(chan, "LD %p free\n", desc);
+#endif
+ dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
+}
+
static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
{
struct fsldma_chan *chan = to_fsl_chan(tx->chan);
@@ -499,13 +508,8 @@ static void fsldma_free_desc_list(struct fsldma_chan *chan,
{
struct fsl_desc_sw *desc, *_desc;
- list_for_each_entry_safe(desc, _desc, list, node) {
- list_del(&desc->node);
-#ifdef FSL_DMA_LD_DEBUG
- chan_dbg(chan, "LD %p free\n", desc);
-#endif
- dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
- }
+ list_for_each_entry_safe(desc, _desc, list, node)
+ fsl_dma_free_descriptor(chan, desc);
}
static void fsldma_free_desc_list_reverse(struct fsldma_chan *chan,
@@ -513,13 +517,8 @@ static void fsldma_free_desc_list_reverse(struct
fsldma_chan *chan,
{
struct fsl_desc_sw *desc, *_desc;
- list_for_each_entry_safe_reverse(desc, _desc, list, node) {
- list_del(&desc->node);
-#ifdef FSL_DMA_LD_DEBUG
- chan_dbg(chan, "LD %p free\n", desc);
-#endif
- dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
- }
+ list_for_each_entry_safe_reverse(desc, _desc, list, node)
+ fsl_dma_free_descriptor(chan, desc);
}
/**
@@ -852,10 +851,7 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan
*chan,
dma_unmap_page(dev, src, len, DMA_TO_DEVICE);
}
-#ifdef FSL_DMA_LD_DEBUG
- chan_dbg(chan, "LD %p free\n", desc);
-#endif
- dma_pool_free(chan->desc_pool, desc, txd->phys);
+ fsl_dma_free_descriptor(chan, desc);
}
/**
--
1.7.8.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/7] fsl-dma: remove attribute DMA_INTERRUPT of dmaengine
From: Qiang Liu
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.
Cc: Dan Williams
Cc: Vinod Koul
Cc: Li Yang
Signed-off-by: Qiang Liu
Acked-by: Ira W. Snyder
---
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 = to_fsl_chan(dchan);
-
- new = fsl_dma_alloc_descriptor(chan);
- if (!new) {
- chan_err(chan, "%s\n", msg_ld_oom);
- return NULL;
- }
-
- new->async_tx.cookie = -EBUSY;
- new->async_tx.flags = 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 = 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 = fsl_dma_alloc_chan_resources;
fdev->common.device_free_chan_resources = fsl_dma_free_chan_resources;
- fdev->common.device_prep_dma_interrupt = fsl_dma_prep_interrupt;
fdev->common.device_prep_dma_memcpy = fsl_dma_prep_memcpy;
fdev->common.device_prep_dma_sg = fsl_dma_prep_sg;
fdev->common.device_tx_status = fsl_tx_status;
--
1.7.8.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/7] fsl-dma: fixes for Freescale DMA driver
From: "Ira W. Snyder" Hello everyone, This is my alternative (simpler) attempt at solving the problems reported by Qiang Liu with the async_tx API and MD RAID hardware offload support when using the Freescale DMA driver. The bug is caused by this driver freeing descriptors before they have been ACKed by software using the async_tx API. I don't like Qiang Liu's code to check where the hardware is in the processing of the descriptor chain, and try to free a partial list of descriptors. This was a source of bugs in this driver before I fixed them several years ago. Instead, the DMA controller raises an interrupt every time it has completed a descriptor chain. This means it is ready for new descriptors: no need to try and figure out where it is in the middle of a descriptor chain. Qiang Liu: I do not have a hardware setup capable of using MD RAID. Please test these patches to see if they fix the bug you reported. You may use these patches as-is, or build upon them. I have tested this using the drivers/dma/dmatest.c driver, as well as the CARMA drivers. There are no regressions that I can find. [ 355.069679] dma0chan3-copy0: terminating after 10 tests, 0 failures (status 0) [ 355.192278] dma0chan2-copy0: terminating after 10 tests, 0 failures (status 0) Ira W. Snyder (5): fsl-dma: minimize locking overhead fsl-dma: add fsl_dma_free_descriptor() to reduce code duplication fsl-dma: move functions to avoid forward declarations fsl-dma: fix support for async_tx API carma: remove unnecessary DMA_INTERRUPT capability Qiang Liu (2): fsl-dma: remove attribute DMA_INTERRUPT of dmaengine fsl-dma: fix a warning of unitialized cookie drivers/dma/fsldma.c| 318 +++ drivers/dma/fsldma.h|1 + drivers/misc/carma/carma-fpga-program.c |1 - drivers/misc/carma/carma-fpga.c |3 +- 4 files changed, 159 insertions(+), 164 deletions(-) -- 1.7.8.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 3/7] fsl-dma: change release process of dma descriptor for supporting async_tx
On Tue, Jul 31, 2012 at 04:09:28AM +, Liu Qiang-B32616 wrote:
> > -Original Message-
> > From: Ira W. Snyder [mailto:i...@ovro.caltech.edu]
> > Sent: Tuesday, July 31, 2012 5:10 AM
> > To: Liu Qiang-B32616
> > Cc: linux-cry...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Phillips
> > Kim-R1AAHA; herb...@gondor.hengli.com.au; da...@davemloft.net; Dan
> > Williams; Vinod Koul; Li Yang-R58472
> > Subject: Re: [PATCH v4 3/7] fsl-dma: change release process of dma
> > descriptor for supporting async_tx
> >
> > On Fri, Jul 27, 2012 at 05:16:09PM +0800, qiang@freescale.com wrote:
> > > From: Qiang Liu
> > >
> > > Fix the potential risk when enable config NET_DMA and ASYNC_TX.
> > > Async_tx is lack of support in current release process of dma
> > descriptor,
> > > all descriptors will be released whatever is acked or no-acked by
> > async_tx,
> > > so there is a potential race condition when dma engine is uesd by
> > others
> > > clients (e.g. when enable NET_DMA to offload TCP).
> > >
> > > In our case, a race condition which is raised when use both of talitos
> > > and dmaengine to offload xor is because napi scheduler will sync all
> > > pending requests in dma channels, it affects the process of raid
> > operations
> > > due to ack_tx is not checked in fsl dma. The no-acked descriptor is
> > freed
> > > which is submitted just now, as a dependent tx, this freed descriptor
> > trigger
> > > BUG_ON(async_tx_test_ack(depend_tx)) in async_tx_submit().
> > >
> >
> > I'm preparing an alternative version of this patch that I think is
> > easier to understand (it is much shorter). I'll post it up here as soon
> > as I finish testing.
> Can you give a simple description/idea about your patch? My patch is for fix
> the
> problems when I build a raid environment with talitos offload xor.
> I think the new interface is clear enough and similar with the implement of
> other dma devices.
>
> And do you have any comments about this patch?
>
My patch will fix the same problem, in a simpler way. It will not
involve checking if the hardware is finished with a descriptor on
ld_running.
> >
> > It would be nice to know how to easily reproduce this bug, without
> > needing to set up a RAID system. I don't have access to any such
> > hardware. A driver similar to drivers/dma/dmatest.c (using the async_tx
> > API instead) would be wonderful.
> You can refer to raid5.c if you do not want to use hardware. Or you can use
> you ram (or other storage devices) to build a raid env to test.
> Thanks.
>
> >
> > Thanks,
> > Ira
> >
> > > TASK = ee1a94a0[1390] 'md0_raid5' THREAD: ecf4 CPU: 0
> > > GPR00: 0001 ecf41ca0 ee44/921a94a0 003f 0001 c00593e4
> > 0001
> > > GPR08: a7a7a7a7 0001 045/92002 42028042 100a38d4
> > ed576d98
> > > GPR16: ed5a11b0 2b162000 0200 046/92000 2d555000
> > ed3015e8 c15a7aa0
> > > GPR24: c155fc40 ecb63220 ecf41d28 e47/92f640bb0
> > ef640c30 ecf41ca0
> > > NIP [c02b048c] async_tx_submit+0x6c/0x2b4
> > > LR [c02b068c] async_tx_submit+0x26c/0x2b4
> > > Call Trace:
> > > [ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable)
> > > [ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c
> > > [ecf41d20] [c0421064] async_copy_data+0xa0/0x17c
> > > [ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10
> > > [ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8
> > > [ecf41e90] [c0429080] raid5d+0x3d4/0x5b4
> > > [ecf41f40] [c04329b8] md_thread+0x138/0x16c
> > > [ecf41f90] [c008277c] kthread+0x8c/0x90
> > > [ecf41ff0] [c0011630] kernel_thread+0x4c/0x68
> > >
> > > Cc: Dan Williams
> > > Cc: Vinod Koul
> > > Cc: Li Yang
> > > Cc: Ira W. Snyder
> > > Signed-off-by: Qiang Liu
> > > ---
> > > drivers/dma/fsldma.c | 242 +++---
> >
> > > drivers/dma/fsldma.h |1 +
> > > 2 files changed, 172 insertions(+), 71 deletions(-)
> > >
> > > diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> > > index 4f2f212..87f52c0 100644
> > > --- a/drivers/dma/fsldma.c
> > > +++ b/drivers/dma/fsldma.c
> > > @@ -400,6 +400,125 @@ out_splice:
> > > list_splice_tail_init(&desc->tx_list, &chan->ld_pending);
> > > }
> > >
> > > +static void fsldma_cleanup_descriptor(struct fsldma_chan *chan);
> > > +static void fsl_chan_xfer_ld_queue(struct fsldma_chan *chan);
> > > +
You should have re-arranged the patches to avoid introducing these
forward declarations in this patch and then deleting them in the next
patch. I reversed the order in my patch series.
> > > +/**
> > > + * fsldma_clean_completed_descriptor - free all descriptors which
> > > + * has been completed and acked
> > > + * @chan: Freescale DMA channel
> > > + *
> > > + * This function is used on all completed and acked descriptors.
> > > + * All descriptors should only be freed in this function.
> > > + */
> > > +static int
> > > +fsldma_clean_completed_descriptor(struct fsldma_chan *chan)
> > > +{
> > > + struct fs
Re: [PATCH] scsi/ibmvscsi: add module alias for ibmvscsic
On Tue, Jul 31, 2012 at 11:20 AM, Brian King wrote: > On 07/30/2012 10:08 PM, Benjamin Herrenschmidt wrote: > > On Mon, 2012-07-30 at 21:06 +0200, Olaf Hering wrote: > >>> So while this would work, I do wonder however whether we could > >> instead > >>> fix it by simplifying the whole thing as follow since iSeries is now > >>> gone and so we don't need split backends anymore: > >>> > >>> scsi/ibmvscsi: Remove backend abstraction > >> > >> I cant that these things myself anymore. > > > > Brian, can somebody from your side own these ? > > I talked to Rob and he will be picking this up. Rob - can you submit > a patch to the maintainers file, adding yourself as the ibmvscsi > maintainer? > Submitted a patch for the MAINTAINERS file and I'll take a look at these patches to verify them as well. Thanks. --Rob Jennings ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] scsi/ibmvscsi: add module alias for ibmvscsic
On Tue, Jul 31, 2012 at 11:20 AM, Brian King wrote: > > On 07/30/2012 10:08 PM, Benjamin Herrenschmidt wrote: > > On Mon, 2012-07-30 at 21:06 +0200, Olaf Hering wrote: > >>> So while this would work, I do wonder however whether we could > >> instead > >>> fix it by simplifying the whole thing as follow since iSeries is now > >>> gone and so we don't need split backends anymore: > >>> > >>> scsi/ibmvscsi: Remove backend abstraction > >> > >> I cant that these things myself anymore. > > > > Brian, can somebody from your side own these ? > > I talked to Rob and he will be picking this up. Rob - can you submit > a patch to the maintainers file, adding yourself as the ibmvscsi > maintainer? I've submitted a patch for the MAINTAINERS file and I'll take a look at these patches to verify them as well. Thanks. --Rob Jennings ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Update g5_defconfig
23.07.2012 11:06, Benjamin Herrenschmidt пишет: On Mon, 2012-07-23 at 09:04 +0200, Andreas Schwab wrote: Benjamin Herrenschmidt writes: This updates the g5 defconfig to include nouveau instead of nvidiafb (which works much better nowadays, in fact the latter crashes on modern distros), Does it? Nvidiafb is super stable here, whereas nouveau has a lot of problems. nvidiafb crashes solid here when X gets involved. What do you mean by "lots of problems" ? I've been using nouveau for a long time now on my two quad g5's including 3D, gnome-shell etc... without anything more than a glitch or two on the edge of windows... Also can you remind me what machine model and what video card variant ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev nouveau doesn't work on my machine. There is a bug in Xorg project https://bugs.freedesktop.org/show_bug.cgi?id=21273 It need to make a workaround for correct initialization of video card. Unfortunately, I am not skilled enough for it. Nvidiafb worked fine for me, but I am not using it. Andrey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: mpic timer driver
On 07/31/2012 09:31 AM, Kumar Gala wrote: > > On Jul 31, 2012, at 2:58 AM, Wang Dongsheng-B40534 wrote: > >> >> >>> -Original Message- >>> From: Kumar Gala [mailto:ga...@kernel.crashing.org] >>> Sent: Friday, July 27, 2012 9:14 PM >>> To: Wang Dongsheng-B40534 >>> Cc: b...@kernel.crashing.org; pau...@samba.org; Wood Scott-B07421; >>> linuxppc-dev@lists.ozlabs.org >>> Subject: Re: [PATCH] powerpc/fsl: mpic timer driver >>> >>> >>> On Jul 27, 2012, at 1:20 AM, >>> wrote: >>> From: Wang Dongsheng Global timers A and B internal to the PIC. The two independent groups of global timer, group A and group B, are identical in their >>> functionality. The hardware timer generates an interrupt on every timer cycle. e.g Power management can use the hardware timer to wake up the machine. Signed-off-by: Wang Dongsheng Signed-off-by: Li Yang >>> >>> How much of this is FSL specific vs openpic? OpenPIC spec's timer >>> support (only a single group). >>> >> [Wang Dongsheng] Yes, OpenPIC only a single group timer. >> FSL: add more register, features and group. >> This patch only to support FSL chip. >> "mpic_timer.c" -> "fsl_mpic_timer.c" >> I will modify the description of the patch. how about? > > I'd rather we support both, can we not use the MPIC_FSL flag to deal with FSL > specific behavior? The device this driver binds against is "fsl,mpic-global-timer". We don't have a binding for ordinary OpenPIC timers, and inferring them from the basic OpenPIC node will cause AMP headaches. Let someone who cares about ordinary OpenPIC drivers add support. :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] scsi/ibmvscsi: add module alias for ibmvscsic
On 07/30/2012 10:08 PM, Benjamin Herrenschmidt wrote: > On Mon, 2012-07-30 at 21:06 +0200, Olaf Hering wrote: >>> So while this would work, I do wonder however whether we could >> instead >>> fix it by simplifying the whole thing as follow since iSeries is now >>> gone and so we don't need split backends anymore: >>> >>> scsi/ibmvscsi: Remove backend abstraction >> >> I cant that these things myself anymore. > > Brian, can somebody from your side own these ? I talked to Rob and he will be picking this up. Rob - can you submit a patch to the maintainers file, adding yourself as the ibmvscsi maintainer? Thanks, Brian -- Brian King Power Linux I/O IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] dma/fsldma: fix a compilation warnings
On Jul 31, 2012, at 9:48 AM, Liu Qiang-B32616 wrote: > Hi Kumar, > >> From: Linuxppc-dev >> [linuxppc-dev-bounces+qiang.liu=freescale@lists.ozlabs.org] on behalf of >> Kumar Gala [ga...@kernel.crashing.org] >> Sent: Tuesday, July 31, 2012 8:57 AM >> To: dan.j.willi...@intel.com >> Cc: vinod.k...@intel.com; linuxppc-...@ozlabs.org >> Subject: [PATCH] dma/fsldma: fix a compilation warnings > >> drivers/dma/fsldma.c: In function 'fsl_dma_tx_submit': >> drivers/dma/fsldma.c:409:15: warning: 'cookie' may be used uninitialized in >> this function >> >> Signed-off-by: Kumar Gala >> --- >> drivers/dma/fsldma.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c >> index 8f84761..6194eb7 100644 >> --- a/drivers/dma/fsldma.c >> +++ b/drivers/dma/fsldma.c >> @@ -406,7 +406,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct >> dma_async_tx_descriptor *tx) >> struct fsl_desc_sw *desc = tx_to_fsl_desc(tx); >> struct fsl_desc_sw *child; >> unsigned long flags; >> - dma_cookie_t cookie; >> + dma_cookie_t cookie = 0; > I have already submitted a patch to fix it. Please refer to: > https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-July/099819.html > > Thanks. Ah, good.. missed it ;) - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] dma/fsldma: fix a compilation warnings
Hi Kumar, > From: Linuxppc-dev > [linuxppc-dev-bounces+qiang.liu=freescale@lists.ozlabs.org] on behalf of > Kumar Gala [ga...@kernel.crashing.org] > Sent: Tuesday, July 31, 2012 8:57 AM > To: dan.j.willi...@intel.com > Cc: vinod.k...@intel.com; linuxppc-...@ozlabs.org > Subject: [PATCH] dma/fsldma: fix a compilation warnings > drivers/dma/fsldma.c: In function 'fsl_dma_tx_submit': > drivers/dma/fsldma.c:409:15: warning: 'cookie' may be used uninitialized in > this function > > Signed-off-by: Kumar Gala > --- > drivers/dma/fsldma.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c > index 8f84761..6194eb7 100644 > --- a/drivers/dma/fsldma.c > +++ b/drivers/dma/fsldma.c > @@ -406,7 +406,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct > dma_async_tx_descriptor *tx) >struct fsl_desc_sw *desc = tx_to_fsl_desc(tx); >struct fsl_desc_sw *child; > unsigned long flags; > - dma_cookie_t cookie; > + dma_cookie_t cookie = 0; I have already submitted a patch to fix it. Please refer to: https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-July/099819.html Thanks. > spin_lock_irqsave(&chan->desc_lock, flags); > > -- > 1.7.9.7 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3 v3] powerpc/mpic: FSL MPIC error interrupt support.
All SOC device error interrupts are muxed and delivered to the core as a single
MPIC error interrupt. Currently all the device drivers requiring access to
device
errors have to register for the MPIC error interrupt as a shared interrupt.
With this patch we add interrupt demuxing capability in the mpic driver,
allowing
device drivers to register for their individual error interrupts. This is
achieved
by handling error interrupts in a cascaded fashion.
MPIC error interrupt is handled by the "error_int_handler", which subsequently
demuxes
it using the EISR and delivers it to the respective drivers.
The error interrupt capability is dependent on the MPIC EIMR register, which was
introduced in FSL MPIC version 4.1 (P4080 rev2). So, error interrupt demuxing
capability
is dependent on the MPIC version and can be used for versions >= 4.1.
Signed-off-by: Varun Sethi
Signed-off-by: Bogdan Hamciuc
[In the initial version of the patch we were using handle_simple_irq
as the handler for cascaded error interrupts, this resulted
in issues in case of threaded isrs (with RT kernel). This issue was
debugged by Bogdan and decision was taken to use the handle_level_irq
handler]
---
arch/powerpc/include/asm/mpic.h| 13 +++
arch/powerpc/sysdev/Makefile |2 +-
arch/powerpc/sysdev/fsl_mpic_err.c | 152
arch/powerpc/sysdev/mpic.c | 41 ++-
arch/powerpc/sysdev/mpic.h | 22 +
5 files changed, 228 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/sysdev/fsl_mpic_err.c
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index e14d35d..5cc8000 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -118,6 +118,9 @@
#define MPIC_MAX_CPUS 32
#define MPIC_MAX_ISU 32
+#define MPIC_MAX_ERR 32
+#define MPIC_FSL_ERR_INT 16
+
/*
* Tsi108 implementation of MPIC has many differences from the original one
*/
@@ -270,6 +273,7 @@ struct mpic
struct irq_chip hc_ipi;
#endif
struct irq_chip hc_tm;
+ struct irq_chip hc_err;
const char *name;
/* Flags */
unsigned intflags;
@@ -283,6 +287,8 @@ struct mpic
/* vector numbers used for internal sources (ipi/timers) */
unsigned intipi_vecs[4];
unsigned inttimer_vecs[8];
+ /* vector numbers used for FSL MPIC error interrupts */
+ unsigned interr_int_vecs[MPIC_MAX_ERR];
/* Spurious vector to program into unused sources */
unsigned intspurious_vec;
@@ -306,6 +312,11 @@ struct mpic
struct mpic_reg_bankcpuregs[MPIC_MAX_CPUS];
struct mpic_reg_bankisus[MPIC_MAX_ISU];
+ /* ioremap'ed base for error interrupt registers */
+ u32 __iomem *err_regs;
+ /* error interrupt config */
+ u32 err_int_config_done;
+
/* Protected sources */
unsigned long *protected;
@@ -370,6 +381,8 @@ struct mpic
#define MPIC_NO_RESET 0x4000
/* Freescale MPIC (compatible includes "fsl,mpic") */
#define MPIC_FSL 0x8000
+/* Freescale MPIC supports EIMR (error interrupt mask register)*/
+#define MPIC_FSL_HAS_EIMR 0x0001
/* MPIC HW modification ID */
#define MPIC_REGSET_MASK 0xf000
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 1bd7ecb..a57600b 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_PPC_DCR_NATIVE) += dcr-low.o
obj-$(CONFIG_PPC_PMI) += pmi.o
obj-$(CONFIG_U3_DART) += dart_iommu.o
obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
-obj-$(CONFIG_FSL_SOC) += fsl_soc.o
+obj-$(CONFIG_FSL_SOC) += fsl_soc.o fsl_mpic_err.o
obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
obj-$(CONFIG_FSL_PMC) += fsl_pmc.o
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
diff --git a/arch/powerpc/sysdev/fsl_mpic_err.c
b/arch/powerpc/sysdev/fsl_mpic_err.c
new file mode 100644
index 000..1ebfa36
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_mpic_err.c
@@ -0,0 +1,152 @@
+/*
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ *
+ * Author: Varun Sethi
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "mpic.h"
+
+#define MPIC_ERR_INT_BASE 0x3900
+#define MPIC_ERR_INT_EISR 0x
+#define MPIC_ERR_INT_EIMR 0x0010
+
+static inline u32 mpic_fsl_err_read(u32 __iomem *base, unsigned int err_reg)
+{
+ return in_be32(base + (err_reg >> 2));
+}
+
+static inline void mpic_f
Re: [PATCH] powerpc/fsl: mpic timer driver
On Jul 31, 2012, at 2:58 AM, Wang Dongsheng-B40534 wrote: > > >> -Original Message- >> From: Kumar Gala [mailto:ga...@kernel.crashing.org] >> Sent: Friday, July 27, 2012 9:14 PM >> To: Wang Dongsheng-B40534 >> Cc: b...@kernel.crashing.org; pau...@samba.org; Wood Scott-B07421; >> linuxppc-dev@lists.ozlabs.org >> Subject: Re: [PATCH] powerpc/fsl: mpic timer driver >> >> >> On Jul 27, 2012, at 1:20 AM, >> wrote: >> >>> From: Wang Dongsheng >>> >>> Global timers A and B internal to the PIC. The two independent groups >>> of global timer, group A and group B, are identical in their >> functionality. >>> The hardware timer generates an interrupt on every timer cycle. >>> e.g >>> Power management can use the hardware timer to wake up the machine. >>> >>> Signed-off-by: Wang Dongsheng >>> Signed-off-by: Li Yang >> >> How much of this is FSL specific vs openpic? OpenPIC spec's timer >> support (only a single group). >> > [Wang Dongsheng] Yes, OpenPIC only a single group timer. > FSL: add more register, features and group. > This patch only to support FSL chip. > "mpic_timer.c" -> "fsl_mpic_timer.c" > I will modify the description of the patch. how about? I'd rather we support both, can we not use the MPIC_FSL flag to deal with FSL specific behavior? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 4/7] powerpc/85xx: add HOTPLUG_CPU support
On Jul 20, 2012, at 7:42 AM, Zhao Chenhui wrote: > Add support to disable and re-enable individual cores at runtime > on MPC85xx/QorIQ SMP machines. Currently support e500v1/e500v2 core. > > MPC85xx machines use ePAPR spin-table in boot page for CPU kick-off. > This patch uses the boot page from bootloader to boot core at runtime. > It supports 32-bit and 36-bit physical address. > > Signed-off-by: Li Yang > Signed-off-by: Jin Qing > Signed-off-by: Zhao Chenhui > --- > arch/powerpc/Kconfig |6 ++- > arch/powerpc/include/asm/cacheflush.h |2 + > arch/powerpc/include/asm/smp.h|1 + > arch/powerpc/kernel/head_fsl_booke.S | 28 ++ > arch/powerpc/platforms/85xx/smp.c | 90 - > 5 files changed, 112 insertions(+), 15 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 3/7] powerpc/85xx: implement hardware timebase sync
On Jul 20, 2012, at 7:42 AM, Zhao Chenhui wrote: > Do hardware timebase sync. Firstly, stop all timebases, and transfer > the timebase value of the boot core to the other core. Finally, > start all timebases. > > Only apply to dual-core chips, such as MPC8572, P2020, etc. > > Signed-off-by: Zhao Chenhui > Signed-off-by: Li Yang > --- > arch/powerpc/include/asm/fsl_guts.h |2 + > arch/powerpc/platforms/85xx/smp.c | 82 +++ > 2 files changed, 84 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 2/7] powerpc/smp: add generic_set_cpu_up() to set cpu_state as CPU_UP_PREPARE
On Jul 20, 2012, at 7:42 AM, Zhao Chenhui wrote: > In the case of cpu hotplug, the cpu_state should be set to CPU_UP_PREPARE > when kicking cpu. > Otherwise, the cpu_state is always CPU_DEAD after calling > generic_set_cpu_dead(), which > makes the delay in generic_cpu_die() not happen. > > Signed-off-by: Zhao Chenhui > --- > arch/powerpc/include/asm/smp.h |1 + > arch/powerpc/kernel/smp.c | 12 +++- > 2 files changed, 12 insertions(+), 1 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 1/7] powerpc/smp: use a struct epapr_spin_table to replace macros
On Jul 20, 2012, at 7:42 AM, Zhao Chenhui wrote: > Signed-off-by: Zhao Chenhui > --- > arch/powerpc/platforms/85xx/smp.c | 46 ++-- > 1 files changed, 23 insertions(+), 23 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/mpic: finish supporting timer group B on Freescale chips
On Jul 31, 2012, at 8:55 AM, Sethi Varun-B16395 wrote: > > >> -Original Message- >> From: Kumar Gala [mailto:ga...@kernel.crashing.org] >> Sent: Tuesday, July 31, 2012 7:20 PM >> To: Sethi Varun-B16395 >> Cc: Wood Scott-B07421 >> Subject: Re: [PATCH 1/3] powerpc/mpic: finish supporting timer group B on >> Freescale chips >> >> >> On Jul 9, 2012, at 3:45 AM, Varun Sethi wrote: >> >>> Previously, these interrupts would be mapped, but the offset >>> calculation was broken, and only the first group was initialized. >>> >>> Signed-off-by: Scott Wood >>> --- >>> arch/powerpc/include/asm/mpic.h |5 +++ >>> arch/powerpc/sysdev/mpic.c | 58 >> --- >>> 2 files changed, 47 insertions(+), 16 deletions(-) >> >> Varun, >> >> Can you reply with a Signed-off-by to the thread. >> > Signed-off-by: Varun Sethi thanks applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 7/7] powerpc/85xx: add support to JOG feature using cpufreq interface
On Jul 20, 2012, at 7:42 AM, Zhao Chenhui wrote:
> Some 85xx silicons like MPC8536 and P1022 have a JOG feature, which provides
> a dynamic mechanism to lower or raise the CPU core clock at runtime.
>
> This patch adds the support to change CPU frequency using the standard
> cpufreq interface. The ratio CORE to CCB can be 1:1(except MPC8536), 3:2,
> 2:1, 5:2, 3:1, 7:2 and 4:1.
>
> Two CPU cores on P1022 must not in the low power state during the frequency
> transition. The driver uses a atomic counter to meet the requirement.
>
> The jog mode frequency transition process on the MPC8536 is similar to
> the deep sleep process. The driver need save the CPU state and restore
> it after CPU warm reset.
>
> Note:
> * The I/O peripherals such as PCIe and eTSEC may lose packets during
> the jog mode frequency transition.
> * The driver doesn't support MPC8536 Rev 1.0 due to a JOG erratum.
> Subsequent revisions of MPC8536 have corrected the erratum.
>
> Signed-off-by: Dave Liu
> Signed-off-by: Li Yang
> Signed-off-by: Jerry Huang
> Signed-off-by: Zhao Chenhui
> CC: Scott Wood
> ---
> arch/powerpc/platforms/85xx/Makefile |1 +
> arch/powerpc/platforms/85xx/cpufreq-jog.c | 388 +
> arch/powerpc/platforms/Kconfig| 11 +
> arch/powerpc/sysdev/fsl_pmc.c |3 +
> arch/powerpc/sysdev/fsl_soc.h |2 +
> include/linux/cpu.h |4 +
> 6 files changed, 409 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/85xx/cpufreq-jog.c
[snip]
> diff --git a/include/linux/cpu.h b/include/linux/cpu.h
> index 2e9b9eb..c1ba260 100644
> --- a/include/linux/cpu.h
> +++ b/include/linux/cpu.h
> @@ -145,6 +145,8 @@ void notify_cpu_starting(unsigned int cpu);
> extern void cpu_maps_update_begin(void);
> extern void cpu_maps_update_done(void);
>
> +extern void cpu_hotplug_disable_before_freeze(void);
> +extern void cpu_hotplug_enable_after_thaw(void);
> #else /* CONFIG_SMP */
>
> #define cpu_notifier(fn, pri) do { (void)(fn); } while (0)
> @@ -166,6 +168,8 @@ static inline void cpu_maps_update_done(void)
> {
> }
>
> +static inline void cpu_hotplug_disable_before_freeze(void) {}
> +static inline void cpu_hotplug_enable_after_thaw(void) {}
> #endif /* CONFIG_SMP */
> extern struct bus_type cpu_subsys;
Can you pull this change into a separate patch. I want an ACK by Rafael J.
Wysocki on it.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 5/7] powerpc/85xx: add sleep and deep sleep support
On Jul 20, 2012, at 7:42 AM, Zhao Chenhui wrote:
> In sleep PM mode, the clocks of e500 core and unused IP blocks is
> turned off. IP blocks which are allowed to wake up the processor
> are still running.
>
> Some Freescale chips like MPC8536 and P1022 has deep sleep PM mode
> in addtion to the sleep PM mode.
>
> While in deep sleep PM mode, additionally, the power supply is
> removed from e500 core and most IP blocks. Only the blocks needed
> to wake up the chip out of deep sleep are ON.
>
> This patch supports 32-bit and 36-bit address space.
>
> The sleep mode is equal to the Standby state in Linux. The deep sleep
> mode is equal to the Suspend-to-RAM state of Linux Power Management.
>
> Command to enter sleep mode.
> echo standby > /sys/power/state
> Command to enter deep sleep mode.
> echo mem > /sys/power/state
>
> Signed-off-by: Dave Liu
> Signed-off-by: Li Yang
> Signed-off-by: Jin Qing
> Signed-off-by: Jerry Huang
> Cc: Scott Wood
> Signed-off-by: Zhao Chenhui
> ---
> arch/powerpc/Kconfig |2 +-
> arch/powerpc/include/asm/cacheflush.h |2 +
> arch/powerpc/kernel/Makefile |3 +
> arch/powerpc/kernel/l2cache_85xx.S| 56 +++
> arch/powerpc/platforms/85xx/Makefile |2 +-
> arch/powerpc/platforms/85xx/sleep.S | 621 +
> arch/powerpc/sysdev/fsl_pmc.c | 98 +-
> arch/powerpc/sysdev/fsl_soc.h |5 +
> 8 files changed, 769 insertions(+), 20 deletions(-)
> create mode 100644 arch/powerpc/kernel/l2cache_85xx.S
> create mode 100644 arch/powerpc/platforms/85xx/sleep.S
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index a7c6914..9d6de82 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -665,7 +665,7 @@ config FSL_PCI
> config FSL_PMC
> bool
> default y
> - depends on SUSPEND && (PPC_85xx || PPC_86xx)
> + depends on SUSPEND && (PPC_85xx || PPC_86xx) && !PPC_E500MC
> help
> Freescale MPC85xx/MPC86xx power management controller support
> (suspend/resume). For MPC83xx see platforms/83xx/suspend.c
> diff --git a/arch/powerpc/include/asm/cacheflush.h
> b/arch/powerpc/include/asm/cacheflush.h
> index b843e35..6c5f1c2 100644
> --- a/arch/powerpc/include/asm/cacheflush.h
> +++ b/arch/powerpc/include/asm/cacheflush.h
> @@ -58,6 +58,8 @@ extern void flush_inval_dcache_range(unsigned long start,
> unsigned long stop);
> extern void flush_dcache_phys_range(unsigned long start, unsigned long stop);
> #endif
>
> +extern void flush_dcache_L1(void);
> +
> #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
> do { \
> memcpy(dst, src, len); \
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index 83afacd..0ddef24 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -64,6 +64,9 @@ obj-$(CONFIG_FA_DUMP) += fadump.o
> ifeq ($(CONFIG_PPC32),y)
> obj-$(CONFIG_E500)+= idle_e500.o
> endif
> +ifneq ($(CONFIG_PPC_E500MC),y)
> +obj-$(CONFIG_PPC_85xx) += l2cache_85xx.o
> +endif
why do we need this, beyond reduce code size on an e500mc kernel build? If so
why isn't 85xx/sleep.S doing the same thing?
> obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6xx.o cpu_setup_6xx.o
> obj-$(CONFIG_TAU) += tau_6xx.o
> obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o
> diff --git a/arch/powerpc/kernel/l2cache_85xx.S
> b/arch/powerpc/kernel/l2cache_85xx.S
> new file mode 100644
> index 000..e920d69
> --- /dev/null
> +++ b/arch/powerpc/kernel/l2cache_85xx.S
> @@ -0,0 +1,56 @@
> +/*
> + * Copyright (C) 2009-2012 Freescale Semiconductor, Inc. All rights reserved.
> + * Scott Wood
> + * Dave Liu
> + * implement the L2 cache operations of e500 based L2 controller
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#define L2CTL_L2E0x8000
> +#define L2CTL_L2I0x4000
> +
> + .section .text
> +
> + /* r3 = virtual address of L2 controller, WIMG = 01xx */
> +_GLOBAL(flush_disable_L2)
> + /* It's a write-through cache, so only invalidation is needed. */
> + mbar
> + isync
> + lwz r4, 0(r3)
> + li r5, 1
> + rlwimi r4, r5, 30, L2CTL_L2E | L2CTL_L2I
> + stw r4, 0(r3)
> +
> + /* Wait for the invalidate to finish */
> +1: lwz r4, 0(r3)
> + andis. r4, r4, L2CTL_L2I@h
> + bne 1b
> + mbar
> +
> + blr
> +
> + /* r3 = virtual address of L2 controller, WIMG = 01xx */
> +_GLOBAL(invalidate_enable_L2)
> + mbar
> + isync
> + lwz r4, 0(r3)
> + li r5, 3
> + rlwimi r4, r5, 30, L2CTL_L2E | L2CTL_L2I
> + stw r4,
RE: [PATCH 1/3] powerpc/mpic: finish supporting timer group B on Freescale chips
> -Original Message- > From: Wood Scott-B07421 > Sent: Monday, July 09, 2012 11:12 PM > To: Kumar Gala > Cc: Sethi Varun-B16395; linuxppc-dev@lists.ozlabs.org > Subject: Re: [PATCH 1/3] powerpc/mpic: finish supporting timer group B on > Freescale chips > > On 07/09/2012 12:36 PM, Kumar Gala wrote: > > > > On Jul 9, 2012, at 11:43 AM, Scott Wood wrote: > > > >> On 07/09/2012 09:12 AM, Kumar Gala wrote: > >>> > >>> On Jul 9, 2012, at 3:45 AM, Varun Sethi wrote: > >>> > Previously, these interrupts would be mapped, but the offset > calculation was broken, and only the first group was initialized. > > Signed-off-by: Scott Wood > --- > arch/powerpc/include/asm/mpic.h |5 +++ > arch/powerpc/sysdev/mpic.c | 58 - > -- > 2 files changed, 47 insertions(+), 16 deletions(-) > >> Signed-off-by: Varun Sethi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] dma/fsldma: fix a compilation warnings
drivers/dma/fsldma.c: In function 'fsl_dma_tx_submit': drivers/dma/fsldma.c:409:15: warning: 'cookie' may be used uninitialized in this function Signed-off-by: Kumar Gala --- drivers/dma/fsldma.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index 8f84761..6194eb7 100644 --- a/drivers/dma/fsldma.c +++ b/drivers/dma/fsldma.c @@ -406,7 +406,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx) struct fsl_desc_sw *desc = tx_to_fsl_desc(tx); struct fsl_desc_sw *child; unsigned long flags; - dma_cookie_t cookie; + dma_cookie_t cookie = 0; spin_lock_irqsave(&chan->desc_lock, flags); -- 1.7.9.7 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code
On Jul 31, 2012, at 2:21 AM, Li Yang wrote: > On Mon, Jul 30, 2012 at 10:46 PM, Kumar Gala > wrote: >> >> On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote: >> >>> >>> -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Saturday, July 28, 2012 5:17 AM To: Wood Scott-B07421 Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472 Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code On Jul 27, 2012, at 3:24 PM, Scott Wood wrote: > On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote: >> Hi kumar, >> >> I know "duplicate code from pci_process_bridge_OF_ranges()" is >> hard to accept but "refactor the code to have a shared function" >> is knotty. Actually this is the reason I didn't do the refactor. > > Maybe we should keep doing the init early? We could still have a > platform device for the PM stuff, but some init would be done before probe. > > Another possibility is to try to handle swiotlb init later -- possibly > by reserving memory for it if the platform indicates it's a possibility > that it will be needed, then freeing the memory if it's not needed. > > -Scott I think the first option seems reasonable. Can we leave fsl_pci_init() as we now have it and just have the platform driver deal with PM restore via calling setup_pci_atmu() [probably need to update setup_pci_atmu to handle restore case, but seems like minor changes] - k >>> >>> >>> I think the second option is better if it's hard to decouple swiotlb >>> determination from pci init. I believe the better architecture that >>> PCI init in probe function of platform driver will bring us considerable >>> advantage. I really like to keep the completion of pci controller >>> platform driver not only for PM support but also for pci init. >>> >>> -Hongtao. >>> >> >> Shifting of swiotlb init has a lot more issues. Why do we need to do the >> PCI init in probe? > > The ordering issues are introduced by swiotlb. And the ideal way is > to solve the problem within swiotlb instead of changing PCI to > workaround it. Take the implementation of x86 as reference it's > possible to be addressed bu allocating first and free later approach. > > It is common sense that the initialization of a device is in the probe > function of the driver of the device. And the change will provide > better unification of PCI controller code. The PCI controller is > generic enough not to be taken care of at the platform area. > > Leo Than lets look at going with that approach.. Be careful with impact on other users of swiotlb on PPC, I believe one 44x board uses swiotlb. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/6] powerpc/fsl-pci: Add pci inbound/outbound PM support
On Jul 30, 2012, at 1:09 AM, Jia Hongtao-B38951 wrote: >> -Original Message- >> From: Kumar Gala [mailto:ga...@kernel.crashing.org] >> Sent: Friday, July 27, 2012 9:24 PM >> To: Jia Hongtao-B38951 >> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472 >> Subject: Re: [PATCH 5/6] powerpc/fsl-pci: Add pci inbound/outbound PM >> support >> >> >> On Jul 24, 2012, at 5:20 AM, Jia Hongtao wrote: >> >>> Power supply for PCI inbound/outbound window registers is off when >> system >>> go to deep-sleep state. We save the values of registers before suspend >>> and restore to registers after resume. >>> >>> Signed-off-by: Jiang Yutang >>> Signed-off-by: Jia Hongtao >>> Signed-off-by: Li Yang >>> --- >>> arch/powerpc/include/asm/pci-bridge.h |2 +- >>> arch/powerpc/sysdev/fsl_pci.c | 121 >> + >>> 2 files changed, 122 insertions(+), 1 deletions(-) >> >> Remind me why we need to save/restore PCI ATMUs, why not just re-parse >> the device tree to restore? >> >> - k > > Save/restore is the more efficient way. Latency of sleep/wakeup is one of > most important features in power management. > > -Hongtao. I don't think the time it takes to run through setup_pci_atmu() is that long compared to fsl_pci_resume(). Also, don't you need to setup PCICCSRBAR and do setup_pci_cmd() on resume? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v5 12/19] memory-hotplug: introduce new function arch_remove_memory()
On Mon, 30 Jul 2012 18:35:37 +0800 Wen Congyang wrote: > At 07/30/2012 06:23 PM, Heiko Carstens Wrote: > > On Fri, Jul 27, 2012 at 06:32:15PM +0800, Wen Congyang wrote: > >> We don't call __add_pages() directly in the function add_memory() > >> because some other architecture related things need to be done > >> before or after calling __add_pages(). So we should introduce > >> a new function arch_remove_memory() to revert the things > >> done in arch_add_memory(). > >> > >> Note: the function for s390 is not implemented(I don't know how to > >> implement it for s390). > > > > There is no hardware or firmware interface which could trigger a > > hot memory remove on s390. So there is nothing that needs to be > > implemented. > > Thanks for providing this information. > > According to this, arch_remove_memory() for s390 can just return > -EBUSY. Yes, but there is a prototype mismatch for arch_remove_memory() on s390 and also other architectures (u64 vs. unsigned long). arch/s390/mm/init.c:262: error: conflicting types for ‘arch_remove_memory’ include/linux/memory_hotplug.h:88: error: previous declaration of ‘arch_remove_memory’ was here In memory_hotplug.h you have: extern int arch_remove_memory(unsigned long start, unsigned long size); On all archs other than x86 you have: int arch_remove_memory(u64 start, u64 size) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v5 16/19] memory-hotplug: free memmap of sparse-vmemmap
On Fri, 27 Jul 2012 18:34:38 +0800 Wen Congyang wrote: > From: Yasuaki Ishimatsu > > All pages of virtual mapping in removed memory cannot be freed, since > some pages used as PGD/PUD includes not only removed memory but also > other memory. So the patch checks whether page can be freed or not. > > How to check whether page can be freed or not? > 1. When removing memory, the page structs of the revmoved memory are > filled with 0FD. > 2. All page structs are filled with 0xFD on PT/PMD, PT/PMD can be > cleared. In this case, the page used as PT/PMD can be freed. > > Applying patch, __remove_section() of CONFIG_SPARSEMEM_VMEMMAP is > integrated into one. So __remove_section() of > CONFIG_SPARSEMEM_VMEMMAP is deleted. There should also be generic or dummy versions of the functions vmemmap_free_bootmem(), vmemmap_kfree() and register_page_bootmem_memmap(). It doesn't compile on other archtitectures than x86 as it is now: mm/built-in.o: In function `sparse_remove_one_section': (.text+0x49fa6): undefined reference to `vmemmap_free_bootmem' mm/built-in.o: In function `sparse_remove_one_section': (.text+0x49fcc): undefined reference to `vmemmap_kfree' mm/built-in.o: In function `register_page_bootmem_info_node': (.text+0x57c06): undefined reference to `register_page_bootmem_memmap' mm/built-in.o: In function `sparse_add_one_section': (.meminit.text+0x2506): undefined reference to `vmemmap_kfree' mm/built-in.o: In function `sparse_add_one_section': (.meminit.text+0x2528): undefined reference to `vmemmap_kfree' make: *** [vmlinux] Error 1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Update g5_defconfig
It's even worse. Since ec9b3a9de6b2a8a08c5250b466db92adf82b8d65 (drm/nouveau/i2c: resume use of i2c-algo-bit, rather than custom stack) the system is just powered off in the middle of booting. Since nothing is calling pmu_request with PMU_SHUTDOWN it must be some kind of bit banging that causes the PMU to freak out. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/fsl: mpic timer driver
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Friday, July 27, 2012 9:14 PM
> To: Wang Dongsheng-B40534
> Cc: b...@kernel.crashing.org; pau...@samba.org; Wood Scott-B07421;
> linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] powerpc/fsl: mpic timer driver
>
>
> On Jul 27, 2012, at 1:20 AM,
> wrote:
>
> > From: Wang Dongsheng
> >
> > Global timers A and B internal to the PIC. The two independent groups
> > of global timer, group A and group B, are identical in their
> functionality.
> > The hardware timer generates an interrupt on every timer cycle.
> > e.g
> > Power management can use the hardware timer to wake up the machine.
> >
> > Signed-off-by: Wang Dongsheng
> > Signed-off-by: Li Yang
>
> How much of this is FSL specific vs openpic? OpenPIC spec's timer
> support (only a single group).
>
[Wang Dongsheng] Yes, OpenPIC only a single group timer.
FSL: add more register, features and group.
This patch only to support FSL chip.
"mpic_timer.c" -> "fsl_mpic_timer.c"
I will modify the description of the patch. how about?
> > +static int set_cascade_timer(struct group_priv *priv, u64 ticks,
> > + unsigned int num)
> > +{
> > + struct cascade_priv *casc_priv;
> > + u32 tmp;
> > + u32 tmp_ticks;
> > + u32 rem_ticks;
> > +
> > + /* set group tcr reg for cascade */
> > + casc_priv = priv->timer[num].cascade_handle;
> > + if (!casc_priv)
> > + return -EINVAL;
> > +
> > + tmp = casc_priv->tcr_value |
> > + (casc_priv->tcr_value << MPIC_TIMER_TCR_ROVR_OFFSET);
> > + setbits32(priv->group_tcr, tmp);
> > +
> > + tmp_ticks = div_u64_rem(ticks, MAX_TIME_CASCADE, &rem_ticks);
> > +
> > + out_be32(&priv->regs[num].gtccr, 0);
> > + out_be32(&priv->regs[num].gtbcr, tmp_ticks | MPIC_TIMER_STOP);
> > +
> > + out_be32(&priv->regs[num - 1].gtccr, 0);
> > + out_be32(&priv->regs[num - 1].gtbcr, rem_ticks);
> > +
> > + return 0;
> > +}
> > +
> > +struct mpic_timer *get_cascade_timer(u64 ticks) {
>
> should this be static?
>
[Wang Dongsheng] ok.
> > ___
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Kumar sent me a handful of Freescale related fixes and I added another regression fix to the pile. Cheers, Ben. PS. I -will- eventually learn about that signed tag business :-) The following changes since commit 1fad1e9a747687a7399bf58e87974f9b1bbcae06: Merge tag 'nfs-for-3.6-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs (2012-07-30 19:16:57 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to ad36cb0d1d3e2b7f161cd33932433f9349cade1e: powerpc/kvm/book3s_32: Fix MTMSR_EERI macro (2012-07-31 15:21:20 +1000) Alexander Graf (1): powerpc/kvm/book3s_32: Fix MTMSR_EERI macro Benjamin Herrenschmidt (1): Merge remote-tracking branch 'kumar/merge' into merge Claudiu Manoil (1): powerpc/85xx: Fix sram_offset parameter type Shaohui Xie (1): powerpc/85xx: P3041DS - change espi input-clock from 40MHz to 35MHz Tang Yuantian (1): powerpc/85xx: Fix pci base address error for p2020rdb-pc in dts Timur Tabi (2): powerpc/85xx: p1022ds: disable the NAND flash node if video is enabled powerpc/85xx: p1022ds: fix DIU/LBC switching with NAND enabled arch/powerpc/boot/dts/p2020rdb-pc_32b.dts |4 +- arch/powerpc/boot/dts/p2020rdb-pc_36b.dts |4 +- arch/powerpc/boot/dts/p3041ds.dts |2 +- arch/powerpc/kvm/book3s_rmhandlers.S |1 - arch/powerpc/platforms/85xx/p1022_ds.c| 122 +++-- arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h |4 +- arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 39 - 7 files changed, 121 insertions(+), 55 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code
On Mon, Jul 30, 2012 at 10:46 PM, Kumar Gala wrote: > > On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote: > >> >> >>> -Original Message- >>> From: Kumar Gala [mailto:ga...@kernel.crashing.org] >>> Sent: Saturday, July 28, 2012 5:17 AM >>> To: Wood Scott-B07421 >>> Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; >>> Li Yang-R58472 >>> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie >>> initialization code >>> >>> >>> On Jul 27, 2012, at 3:24 PM, Scott Wood wrote: >>> On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote: > Hi kumar, > > I know "duplicate code from pci_process_bridge_OF_ranges()" is > hard to accept but "refactor the code to have a shared function" > is knotty. Actually this is the reason I didn't do the refactor. Maybe we should keep doing the init early? We could still have a platform device for the PM stuff, but some init would be done before >>> probe. Another possibility is to try to handle swiotlb init later -- possibly by reserving memory for it if the platform indicates it's a possibility that it will be needed, then freeing the memory if it's not needed. -Scott >>> >>> I think the first option seems reasonable. Can we leave fsl_pci_init() >>> as we now have it and just have the platform driver deal with PM restore >>> via calling setup_pci_atmu() [probably need to update setup_pci_atmu to >>> handle restore case, but seems like minor changes] >>> >>> - k >>> >> >> >> I think the second option is better if it's hard to decouple swiotlb >> determination from pci init. I believe the better architecture that >> PCI init in probe function of platform driver will bring us considerable >> advantage. I really like to keep the completion of pci controller >> platform driver not only for PM support but also for pci init. >> >> -Hongtao. >> > > Shifting of swiotlb init has a lot more issues. Why do we need to do the PCI > init in probe? The ordering issues are introduced by swiotlb. And the ideal way is to solve the problem within swiotlb instead of changing PCI to workaround it. Take the implementation of x86 as reference it's possible to be addressed bu allocating first and free later approach. It is common sense that the initialization of a device is in the probe function of the driver of the device. And the change will provide better unification of PCI controller code. The PCI controller is generic enough not to be taken care of at the platform area. Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
