Re: [PATCH 3/3] mpc52xx/wdt: WDT uses GPT api

[Grant Likely]

On Thu, Nov 12, 2009 at 2:36 PM, Wim Van Sebroeck  wrote:
> Hi All,
>
>>> Can the WDT functionality just be merged entirely into
>>> arch/powerpc/platforms/52xx/mpc52xx_gpt.c, eliminating the need for
>>> this file entirely?  I think I'd rather have all the GPT "built in"
>>> behaviour handled by a single driver.
>>
>> I also thought about it, as it has IMHO the cleaner code, and it would have 
>> the extra benefit that the gpt-wdt api doesn't need to be public.
>>
>> However, the reasons I hesitated to do so are:
>> - I don't want to remove a file someone else wrote (even it doesn't work);
>> - WDT code is shifted from drivers/watchdog to arch/powerpc/platforms/52xx 
>> which might not be the "logical" place from the directory layout's pov;
>> - a file living in arch/powerpc/platforms/52xx depends upon config options 
>> set from drivers/watchdog/Kconfig which may be confusing.
>>
>> You see these are more political/cosmetical questions, so I would prefer to 
>> leave the decision to the maintainers (i.e. you and Wim).  Preparing a fully 
>> merged driver is actually a matter of minutes!
>
> My opinion: it is harder to maintain the watchdog code if it is being moved 
> away from drivers/watchdog.
> I need to check the code before I comment any further on this, but my first 
> thought is: why don't you do it with platform resources like other devices 
> are doing? This way you can keep the platform code under arch and the 
> watchdog itself under drivers/watchdog/. You can look at the following 
> drivers as an example: adx_wdt.c ar7_wdt.c at32ap700x_wdt.c coh901327_wdt.c 
> davinci_wdt.c mpcore_wdt.c mv64x60_wdt.c nuc900_wdt.c omap_wdt.c 
> pnx4008_wdt.c rc32434_wdt.c s3c2410_wdt.c txx9wdt.c .

In actual fact, it is a single device with multiple functions, some of
which can be used at the same time.  The driver for the device
determines what the device instance supports and registers the
appropriate interfaces.  There is a GPIO controller, a PWM controller,
a general purpose timer, and the watchdog.  Because of the
multifunction nature of the device, there are subtle interactions
between the functions that the driver needs to maintain.  I don't want
to export functions from the driver which will only be used by a
watchdog instance.  I also don't want the added code and complexity of
a secondary probe path.  It is simpler and less code to roll all the
behaviour up into the one driver single driver that gets probed once.

>From the maintenance perspective, having the main driver in
arch/powerpc and the watchdog bit in drivers/watchdog doesn't really
help much anyway because anything that changes the internal driver API
(between the core and watchdog bits) will require cross-maintainer
changes.  ie. do changes go through my tree because they touch
arch/powerpc, or do they go through yours because they touch
drivers/watchdog?  I'd much rather all the internal details be
contained within a single driver.

Besides, there is already precedence for very arch-specific drivers
living under arch/*/.  find ./arch -name *gpio*

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: OOPS on MPC8548 board when writing RAID5 array

[hank peng]

2009/11/13 Dan Williams :
> Hi Hank,
>
> Thanks for testing.
>
> On Tue, Nov 10, 2009 at 4:44 AM, hank peng  wrote:
>> CPU is MPC8548, kernel version is 2.6.31.5,CONFIG_FSL_DMA and
>> CONFIG_ASYNC_TX_DMA options are all enabled.
>> #mdadm -C /dev/md0 --assume-clean -l5 -n3 /dev/sd{a,b,c}
>> #dd if=/dev/zero of=/dev/md0 bs=1M count=1000
>> Oops: Exception in kernel mode, sig: 5 [#1]
>> MPC85xx CDS
>> Modules linked in:
>> NIP: c01c45d8 LR: c01c4d48 CTR: 
>> REGS: c2dd5c80 TRAP: 0700   Not tainted  (2.6.31.5)
>> MSR: 00029000   CR: 22004028  XER: 
>> TASK = e820a580[3804] 'md0_raid5' THREAD: c2dd4000
>> GPR00: 0001 c2dd5d30 e820a580 c2fb1088 0001  0002 
>> 1000
>> GPR08: 0001 c0485a20  ef8092f8 22002024  c2d67870 
>> c0282d2c
>> GPR16: 1000 e8355c00 c2eff964   0019 0140 
>> c2dd5e00
>> GPR24: c2dd5dfc 0001 c2dd5dc0 c099c420  c2d67838 0002 
>> c2dd5d58
>> NIP [c01c45d8] async_tx_quiesce+0x28/0x74
> [..]
>> I checked the kernel source code, and find that this OOPS was caused
>> by the following BUG_ON code:
>> It is in crypto/async_tx/async_tx.c:
>> void async_tx_quiesce(struct dma_async_tx_descriptor **tx)
>> {
>>        if (*tx) {
>>                /* if ack is already set then we cannot be sure
>>                 * we are referring to the correct operation
>>                 */
>>                BUG_ON(async_tx_test_ack(*tx));
>>   /* OOPS occured */
>
> Yes, this looks like a manifestation of the issue I brought up in my
> review of the driver [1].  The talitos_prep_dma_xor routine is always
> acknowledging its descriptors, which it should not because that is the
> responsibility of the client of the api.  When the raid code tries to
> attach a memcpy that depends on the xor it sees that it needs to
> switch to from talitos to fsldma (or software if fsldma is turned
> off).  Since talitos does not have the DMA_INTERRUPT capability to
> trigger the channel switch we need to perform a synchronous wait for
> the xor to complete before submitting the memcpy.  When the ack bit is
> not set the xor descriptor might be recycled by the dma device driver
> while we are waiting for it, hence the BUG_ON().
>
Thanks for reply, Dan.
Forgot to say, when this OOPS happened, I have not applied talitos XOR
patch. I only enabled async_xx api and FSL_DMA, so here
I think XOR was done by CPU and memcpy was done by DMA using async_xx api.
Another interseting thing I should say is that I have tried latest
stable kernel 2.6.31.6, this problem didn't exist. After I applied
talitos XOR patch, it was OK too. I checked the related souce codes
and it seems that there were no changes which make me feel very
confused.

I have been testing latest serials of kernels about XOR patch on
MPC8548 board and I hope Freescale guys also can give me help.

> --
> Dan
>
> See the final comment:
> [1]: http://marc.info/?l=linux-raid&m=125685641412112&w=2
>



-- 
The simplest is not all best but the best is surely the simplest!
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [powerpc] Next tree Nov 2 : kernel BUG at mm/mmap.c:2135!

[David Gibson]

On Fri, Nov 13, 2009 at 12:37:29PM +1100, David Gibson wrote:
> On Thu, Nov 12, 2009 at 04:46:40PM +0530, Sachin Sant wrote:
> > David Gibson wrote:
> > >On Wed, Nov 04, 2009 at 06:08:44PM +0530, Sachin Sant wrote:
> > >>Sachin Sant wrote:
> > >>>Today's next tree failed to boot on a POWER 6 box with :
> > >>>
> > >>>[ cut here ]
> > >>>kernel BUG at mm/mmap.c:2135!
> > >>>Oops: Exception in kernel mode, sig: 5 [#2]
> > >>>SMP NR_CPUS=1024 NUMA pSeries
> > >>Problem exists with today's next as well.
> > >>
> > >>Likely cause for this problem seems to the following commit.
> > >>If i revert this patch the machine boots fine.
> > >>
> > >>commit a0668cdc154e54bf0c85182e0535eea237d53146
> > >>powerpc/mm: Cleanup management of kmem_caches for pagetables
> > >
> > >Ugh.  Ok, it's not at all obvious how my patch could cause this bug.
> > >Can you send your .config?
> > >
> > Still present in today's next.
> 
> Sorry, I've been sidetracked by other issues and have only managed to
> look into this today.  My initial attempts to reproduce the bug with
> your config on both POWER6 and POWER5+ have failed though.
> 
> Is it possible to get the complete boot log from this system - not
> just the [cut here] section around the BUG()?  This should help to
> determine exactly when during boot the bug is being triggered.

Also, could you try booting the kernel with the patch below, which
should give a bit more information about the problem.

Index: working-2.6/mm/mmap.c
===
--- working-2.6.orig/mm/mmap.c  2009-11-13 13:08:29.0 +1100
+++ working-2.6/mm/mmap.c   2009-11-13 13:09:26.0 +1100
@@ -2136,6 +2136,8 @@ void exit_mmap(struct mm_struct *mm)
while (vma)
vma = remove_vma(vma);
 
+   if (nr_ptes != 0)
+   printk("exit_mmap(): mm %p nr_ptes %d\n", mm, mm->nr_ptes);
BUG_ON(mm->nr_ptes > (FIRST_USER_ADDRESS+PMD_SIZE-1)>>PMD_SHIFT);
 }
 


-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [powerpc] Next tree Nov 2 : kernel BUG at mm/mmap.c:2135!

[David Gibson]

On Thu, Nov 12, 2009 at 04:46:40PM +0530, Sachin Sant wrote:
> David Gibson wrote:
> >On Wed, Nov 04, 2009 at 06:08:44PM +0530, Sachin Sant wrote:
> >>Sachin Sant wrote:
> >>>Today's next tree failed to boot on a POWER 6 box with :
> >>>
> >>>[ cut here ]
> >>>kernel BUG at mm/mmap.c:2135!
> >>>Oops: Exception in kernel mode, sig: 5 [#2]
> >>>SMP NR_CPUS=1024 NUMA pSeries
> >>Problem exists with today's next as well.
> >>
> >>Likely cause for this problem seems to the following commit.
> >>If i revert this patch the machine boots fine.
> >>
> >>commit a0668cdc154e54bf0c85182e0535eea237d53146
> >>powerpc/mm: Cleanup management of kmem_caches for pagetables
> >
> >Ugh.  Ok, it's not at all obvious how my patch could cause this bug.
> >Can you send your .config?
> >
> Still present in today's next.

Sorry, I've been sidetracked by other issues and have only managed to
look into this today.  My initial attempts to reproduce the bug with
your config on both POWER6 and POWER5+ have failed though.

Is it possible to get the complete boot log from this system - not
just the [cut here] section around the BUG()?  This should help to
determine exactly when during boot the bug is being triggered.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: OOPS on MPC8548 board when writing RAID5 array

[Dan Williams]

Hi Hank,

Thanks for testing.

On Tue, Nov 10, 2009 at 4:44 AM, hank peng  wrote:
> CPU is MPC8548, kernel version is 2.6.31.5,CONFIG_FSL_DMA and
> CONFIG_ASYNC_TX_DMA options are all enabled.
> #mdadm -C /dev/md0 --assume-clean -l5 -n3 /dev/sd{a,b,c}
> #dd if=/dev/zero of=/dev/md0 bs=1M count=1000
> Oops: Exception in kernel mode, sig: 5 [#1]
> MPC85xx CDS
> Modules linked in:
> NIP: c01c45d8 LR: c01c4d48 CTR: 
> REGS: c2dd5c80 TRAP: 0700   Not tainted  (2.6.31.5)
> MSR: 00029000   CR: 22004028  XER: 
> TASK = e820a580[3804] 'md0_raid5' THREAD: c2dd4000
> GPR00: 0001 c2dd5d30 e820a580 c2fb1088 0001  0002 1000
> GPR08: 0001 c0485a20  ef8092f8 22002024  c2d67870 c0282d2c
> GPR16: 1000 e8355c00 c2eff964   0019 0140 c2dd5e00
> GPR24: c2dd5dfc 0001 c2dd5dc0 c099c420  c2d67838 0002 c2dd5d58
> NIP [c01c45d8] async_tx_quiesce+0x28/0x74
[..]
> I checked the kernel source code, and find that this OOPS was caused
> by the following BUG_ON code:
> It is in crypto/async_tx/async_tx.c:
> void async_tx_quiesce(struct dma_async_tx_descriptor **tx)
> {
>        if (*tx) {
>                /* if ack is already set then we cannot be sure
>                 * we are referring to the correct operation
>                 */
>                BUG_ON(async_tx_test_ack(*tx));
>   /* OOPS occured */

Yes, this looks like a manifestation of the issue I brought up in my
review of the driver [1].  The talitos_prep_dma_xor routine is always
acknowledging its descriptors, which it should not because that is the
responsibility of the client of the api.  When the raid code tries to
attach a memcpy that depends on the xor it sees that it needs to
switch to from talitos to fsldma (or software if fsldma is turned
off).  Since talitos does not have the DMA_INTERRUPT capability to
trigger the channel switch we need to perform a synchronous wait for
the xor to complete before submitting the memcpy.  When the ack bit is
not set the xor descriptor might be recycled by the dma device driver
while we are waiting for it, hence the BUG_ON().

--
Dan

See the final comment:
[1]: http://marc.info/?l=linux-raid&m=125685641412112&w=2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] mpc5200/gpt: tiny fix for gpt period limitation

[Grant Likely]

On Thu, Nov 12, 2009 at 2:44 PM, Wolfram Sang  wrote:
>> up patch 3.  BUT, you're on my shit list.  Patch 2 in your series
>
> Huh, are you in a bad mood today? IMHO he addressed some valid issues; and we
> all had to start somewhere regarding the workflow. I know that manually
> adapting patches is annoying, but this wording sounds quite strong...

Albrecht has been around for a bit now.  He does good work, responds
to comments, and in general shows good taste.  This particular case
was just a bit sloppy.  The patch was damaged on the mailing list and
it conflicted with his other patches.  I know he knows better.

Albrecht, I'm not actually mad at you, and I'm sorry for the harsh
working.  The patch series is good work.  I wouldn't have picked it up
if it was otherwise.  I'm just a little annoyed about something I know
you can handle better.  I don't bear any ill will.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: kexec for powerpc

[wilbur.chan]

2009/11/13 James Black 

> powerpc32 for processors like the freescale 82xx, 83xx machines.
>
> Thanks,
> JB
>
>

maybe 83xx kexec needs to add some dtb support
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: kexec for powerpc

[James Black]

powerpc32 for processors like the freescale 82xx, 83xx machines.

Thanks,
JB

On Thu, Nov 12, 2009 at 4:31 PM, Josh Boyer  wrote:
> On Thu, Nov 12, 2009 at 04:08:07PM -0700, James Black wrote:
>>Are there efforts in this area or is it already working for powerpc? I
>>cross compiled kexec and tried it on an old kernel with kexec support
>>compiled in.
>
> 'powerpc' is a bit too vague.  It works on lots of ppc64 machines already.
> What class of hardware are you talking about?
>
> josh
>



-- 
Jim Black
Senior Software Engineer
Aztek Networks, Inc.
2477 55th Street, Suite 202
Boulder, CO 80301
www.azteknetworks.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: kexec for powerpc

[Josh Boyer]

On Thu, Nov 12, 2009 at 04:08:07PM -0700, James Black wrote:
>Are there efforts in this area or is it already working for powerpc? I
>cross compiled kexec and tried it on an old kernel with kexec support
>compiled in.

'powerpc' is a bit too vague.  It works on lots of ppc64 machines already.
What class of hardware are you talking about?

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/8] 8xx: Misc fixes for buggy insn

[Joakim Tjernlund]

Scott Wood  wrote on 12/11/2009 22:57:59:
>
> Joakim Tjernlund wrote:
> > Scott Wood  wrote on 12/11/2009 20:45:59:
> >> One other concern with pinning on 8xx -- could it cause problems with
> >> uncached DMA mappings?  What happens if a speculative load pulls in a
> >> cache line in an area that's supposed to be uncached?
> >
> > hmm, why should this be a problem?
>
> Because then you would be accessing potentially stale DMA data -- and
> more generally, the architecture prohibits such mixing.
>
> > Pinning has been around as a config option
> > for a long time so any problems should have surfaced by now.
>
> It has existed as an option, which is going to get less test coverage
> than something that is always on.  Plus, it would not be a particularly
> common failure -- easy to blame one-off weirdness on something else.
>
> > Secondly, I was thinking that we could just make the ITLB pinning
> > mandatory and let the DTLB pinning be as is, configurable.
>
> That could work.  We could also limit the pool of memory
> dma_alloc_coherent() uses to not overlap with anything pinned.

And try using the remaing 3 ITLBs which are unused when pinning to
cover the module space. Probably not going to be perfect.

Anyhow, lets start simple and just do the pinned ITLB so the
new TLB code can be applied. Can you confirm this works for you?

>From 0c30d6c1ee45341fcfc5643bd2ba876e3c9a416e Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund 
Date: Fri, 13 Nov 2009 00:26:59 +0100
Subject: [PATCH] 8xx: Always pin kernel instruction TLB

---
 arch/powerpc/kernel/head_8xx.S |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index adc5a32..c7a4e60 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -767,7 +767,7 @@ start_here:
  */
 initial_mmu:
tlbia   /* Invalidate all TLB entries */
-#ifdef CONFIG_PIN_TLB
+#ifdef 1 /* CONFIG_PIN_TLB */
lis r8, mi_rs...@h
ori r8, r8, 0x1c00
 #else
--
1.6.4.4


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

kexec for powerpc

[James Black]

Are there efforts in this area or is it already working for powerpc? I
cross compiled kexec and tried it on an old kernel with kexec support
compiled in.

/var # ./kexec -t elf -l zImage.elf
get_memory_ranges(): Unsupported platform
Could not get memory layout

Any comments?

-- 
Jim Black
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Does Linux Kernel support QMC on MPC875 and MCC on MPC8270?

[Gao Ya'nan]

And are they in kernel source tree?

Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/8] 8xx: Misc fixes for buggy insn

[Scott Wood]

Joakim Tjernlund wrote:

Scott Wood  wrote on 12/11/2009 20:45:59:

One other concern with pinning on 8xx -- could it cause problems with
uncached DMA mappings?  What happens if a speculative load pulls in a
cache line in an area that's supposed to be uncached?


hmm, why should this be a problem?


Because then you would be accessing potentially stale DMA data -- and 
more generally, the architecture prohibits such mixing.



Pinning has been around as a config option
for a long time so any problems should have surfaced by now.


It has existed as an option, which is going to get less test coverage 
than something that is always on.  Plus, it would not be a particularly 
common failure -- easy to blame one-off weirdness on something else.



Secondly, I was thinking that we could just make the ITLB pinning
mandatory and let the DTLB pinning be as is, configurable.


That could work.  We could also limit the pool of memory 
dma_alloc_coherent() uses to not overlap with anything pinned.


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] mpc5200/gpt: tiny fix for gpt period limitation

[Wolfram Sang]

> up patch 3.  BUT, you're on my shit list.  Patch 2 in your series

Huh, are you in a bad mood today? IMHO he addressed some valid issues; and we
all had to start somewhere regarding the workflow. I know that manually
adapting patches is annoying, but this wording sounds quite strong...

-- 
Pengutronix e.K.   | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/  |


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/3] mpc52xx/wdt: WDT uses GPT api

[Wim Van Sebroeck]

Hi All,

>> Can the WDT functionality just be merged entirely into
>> arch/powerpc/platforms/52xx/mpc52xx_gpt.c, eliminating the need for
>> this file entirely?  I think I'd rather have all the GPT "built in"
>> behaviour handled by a single driver.
>
> I also thought about it, as it has IMHO the cleaner code, and it would have 
> the extra benefit that the gpt-wdt api doesn't need to be public.
>
> However, the reasons I hesitated to do so are:
> - I don't want to remove a file someone else wrote (even it doesn't work);
> - WDT code is shifted from drivers/watchdog to arch/powerpc/platforms/52xx 
> which might not be the "logical" place from the directory layout's pov;
> - a file living in arch/powerpc/platforms/52xx depends upon config options 
> set from drivers/watchdog/Kconfig which may be confusing.
>
> You see these are more political/cosmetical questions, so I would prefer to 
> leave the decision to the maintainers (i.e. you and Wim).  Preparing a fully 
> merged driver is actually a matter of minutes!

My opinion: it is harder to maintain the watchdog code if it is being moved 
away from drivers/watchdog.
I need to check the code before I comment any further on this, but my first 
thought is: why don't you do it with platform resources like other devices are 
doing? This way you can keep the platform code under arch and the watchdog 
itself under drivers/watchdog/. You can look at the following drivers as an 
example: adx_wdt.c ar7_wdt.c at32ap700x_wdt.c coh901327_wdt.c davinci_wdt.c 
mpcore_wdt.c mv64x60_wdt.c nuc900_wdt.c omap_wdt.c pnx4008_wdt.c rc32434_wdt.c 
s3c2410_wdt.c txx9wdt.c .

Kind regards,
Wim.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/8] 8xx: Misc fixes for buggy insn

[Joakim Tjernlund]

Scott Wood  wrote on 12/11/2009 20:45:59:
>
> Joakim Tjernlund wrote:
> > Scott Wood  wrote on 11/11/2009 16:26:53:
> >> On Wed, Nov 11, 2009 at 01:06:10AM +0100, Joakim Tjernlund wrote:
> >>> Scott Wood  wrote on 11/11/2009 00:21:18:
>  Where would you put the dcbi?  How do you regain control after that
>  cache line has been refilled, but before code flows back to the bad 
>  branch?
> >>> The dcbi would replace the current CPU15 tlbie.
> >> But that only works if you take an ITLB miss at the right time.
> >
> > Yeah, I misread the CPU15 errata so my ideas will not work.
> >
> > Anyhow, will you send a patch that make TLB pinning mandatory?
> > After that my series can go in.
>
> One other concern with pinning on 8xx -- could it cause problems with
> uncached DMA mappings?  What happens if a speculative load pulls in a
> cache line in an area that's supposed to be uncached?

hmm, why should this be a problem? Pinning has been around as a config option
for a long time so any problems should have surfaced by now.

Secondly, I was thinking that we could just make the ITLB pinning
mandatory and let the DTLB pinning be as is, configurable.

 Jocke

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] mpc5200/gpt: tiny fix for gpt period limitation

[Grant Likely]

On Wed, Nov 11, 2009 at 1:49 AM, Albrecht Dreß  wrote:
> This patch fixes a limitation of the 5200's period.
>
> Signed-off-by: Albrecht Dreß 

Okay, I've applied this and patches 1 & 2 from your series.  I'm
waiting for a reply from Wim to know whether or not I should also pick
up patch 3.  BUT, you're on my shit list.  Patch 2 in your series
conflicts with this patch.  I had to fix it up by hand.  This patch
should have been part of the series, or at least base the series on
this patch.  Take a look in my -test branch and make sure I fixed it
right.

g.

> ---
>
>  arch/powerpc/include/asm/mpc52xx.h        |    2 +-
>  arch/powerpc/platforms/52xx/mpc52xx_gpt.c |    6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mpc52xx.h 
> b/arch/powerpc/include/asm/mpc52xx.h
> index 707ab75..933fb8f 100644
> --- a/arch/powerpc/include/asm/mpc52xx.h
> +++ b/arch/powerpc/include/asm/mpc52xx.h
> @@ -279,7 +279,7 @@ extern void mpc52xx_restart(char *cmd);
>  /* mpc52xx_gpt.c */
>  struct mpc52xx_gpt_priv;
>  extern struct mpc52xx_gpt_priv *mpc52xx_gpt_from_irq(int irq);
> -extern int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, int period,
> +extern int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, u64 period,
>                             int continuous);
>  extern void mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt);
>
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c 
> b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> index 2c3fa13..77572ab 100644
> --- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> @@ -378,12 +378,12 @@ EXPORT_SYMBOL(mpc52xx_gpt_from_irq);
>  /**
>  * mpc52xx_gpt_start_timer - Set and enable the GPT timer
>  * @gpt: Pointer to gpt private data structure
> - * @period: period of timer
> + * @period: period of timer in ns; max. ~130s @ 33MHz IPB clock
>  * @continuous: set to 1 to make timer continuous free running
>  *
>  * An interrupt will be generated every time the timer fires
>  */
> -int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, int period,
> +int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, u64 period,
>                             int continuous)
>  {
>        u32 clear, set;
> @@ -400,7 +400,7 @@ int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, 
> int period,
>         * arithmatic is done here to preserve the precision until the value
>         * is scaled back down into the u32 range.  Period is in 'ns', bus
>         * frequency is in Hz. */
> -       clocks = (u64)period * (u64)gpt->ipb_freq;
> +       clocks = period * (u64)gpt->ipb_freq;
>        do_div(clocks, 10); /* Scale it down to ns range */
>
>        /* This device cannot handle a clock count greater than 32 bits */
>
>
> Jetzt NEU: Do it youself E-Cards bei Arcor.de!
> Stellen Sie Ihr eigenes Unikat zusammen und machen Sie dem Empfänger eine 
> ganz persönliche Freude!
> E-Card Marke Eigenbau: HIER KLICKEN: http://www.arcor.de/rd/footer.ecard
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv2 3/3] mpc52xx/wdt: remove obsolete old WDT implementation

[Wolfram Sang]

On Thu, Nov 12, 2009 at 09:36:42PM +0100, Albrecht Dreß wrote:
> Hi Wolfram:
>
> Am 12.11.09 20:56 schrieb(en) Wolfram Sang:
>> > Note: The file drivers/watchdog/mpc5200_wdt.c is now obsolete and should
>> > be removed.
>>
>> Ehrm, this is possible within a patch :)
>
> Ummm, I tried that (removed the file from git locally), but apparently I'm
> too dumb to find the proper options to get this into the diff (to my defence,
> I'm still using cvs/svn for my projects).  Can you give me a hint?

git rm file

You can even do this after you removed the file using rm already. 'git status'
gives you an overview about the current changes and how to add them to the
commit.

> Yes, you're right.  The config option should still be 'MPC5200_WDT', though,
> as otherwise all the default configs had to be touched - IMO, on the low
> level, this does no harm.  Thoughts?

I'd also leave the config name. But the help text should match the prompt :)

Regards,

   Wolfram

-- 
Pengutronix e.K.   | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/  |


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv2 3/3] mpc52xx/wdt: remove obsolete old WDT implementation

[Grant Likely]

On Thu, Nov 12, 2009 at 1:36 PM, Albrecht Dreß  wrote:
> Hi Wolfram:
>
> Am 12.11.09 20:56 schrieb(en) Wolfram Sang:
>>
>> > Note: The file drivers/watchdog/mpc5200_wdt.c is now obsolete and should
>> > be removed.
>>
>> Ehrm, this is possible within a patch :)
>
> Ummm, I tried that (removed the file from git locally), but apparently I'm
> too dumb to find the proper options to get this into the diff (to my
> defence, I'm still using cvs/svn for my projects).  Can you give me a hint?
>
>> >  config MPC5200_WDT
>> > -     tristate "MPC5200 Watchdog Timer"
>> > +     bool "MPC52xx Watchdog Timer"
>> >       depends on PPC_MPC52xx
>> > +     help
>> > +       Use General Purpose Timer (GPT) 0 on the MPC5200 as Watchdog.
>>
>> s/5200/52xx/ here too.
>
> Yes, you're right.  The config option should still be 'MPC5200_WDT', though,
> as otherwise all the default configs had to be touched - IMO, on the low
> level, this does no harm.  Thoughts?

I don't care.  Don't bother respinning just for this.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv2 3/3] mpc52xx/wdt: remove obsolete old WDT implementation

[Albrecht Dreß]

Hi Wolfram:

Am 12.11.09 20:56 schrieb(en) Wolfram Sang:

> Note: The file drivers/watchdog/mpc5200_wdt.c is now obsolete and should be 
removed.

Ehrm, this is possible within a patch :)


Ummm, I tried that (removed the file from git locally), but apparently I'm too 
dumb to find the proper options to get this into the diff (to my defence, I'm 
still using cvs/svn for my projects).  Can you give me a hint?


>  config MPC5200_WDT
> -  tristate "MPC5200 Watchdog Timer"
> +  bool "MPC52xx Watchdog Timer"
>depends on PPC_MPC52xx
> +  help
> +Use General Purpose Timer (GPT) 0 on the MPC5200 as Watchdog.

s/5200/52xx/ here too.


Yes, you're right.  The config option should still be 'MPC5200_WDT', though, as 
otherwise all the default configs had to be touched - IMO, on the low level, 
this does no harm.  Thoughts?

Cheers, Albrecht.


pgperL44f7Cq2.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv2 1/3] mpc52xx/wdt: OF property to enable the WDT on boot

[Albrecht Dreß]

Hi Grant!

Am 12.11.09 20:06 schrieb(en) Grant Likely:

> +The watchdog will respect the CONFIG_WATCHDOG_NOWAYOUT option.

I think it would be better to use a device tree property to enable up
NOWAYOUT.  The static config isn't multiplatform-friendly.  Thoughts?


I fully agree with you that this property would fit perfectly in the device tree.  However, if we now add it *only* for the 52xx, but not for other device tree-aware platforms, this might be somewhat confusing.  The good thing is that it wouldn't break  
anything for the 5200 as the old wdt driver didn't work anyway.


One *real* advantage of the compile-time option is that it actually removes the code which stops the wdt.  I'm not a real expert in that, but if we argue that the system is "safe" as required by IEC/EN 61508 part 3, it's probably beneficial if we can show  
that there *is* no code to stop the wdt, not a snipplet only disabled by a flag.


Just my €0.01, though - maybe more insight from the WDT gurus?

Cheers, Albrecht.


pgpA6VAeKAhq0.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv2 3/3] mpc52xx/wdt: remove obsolete old WDT implementation

[Wolfram Sang]

On Thu, Nov 12, 2009 at 07:45:20PM +0100, Albrecht Dreß wrote:
> Remove the old WDT implementation.
> 
> Signed-off-by: Albrecht Dreß 
> ---
> 
> Change against v1: WDT stuff now fully merged into the file
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c.
> 
> Note: The file drivers/watchdog/mpc5200_wdt.c is now obsolete and should be 
> removed.

Ehrm, this is possible within a patch :)

> 
>  drivers/watchdog/Kconfig  |4 +++-
>  drivers/watchdog/Makefile |1 -
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 3711b88..d958b76 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -861,8 +861,10 @@ config GEF_WDT
> Watchdog timer found in a number of GE Fanuc single board computers.
>  
>  config MPC5200_WDT
> - tristate "MPC5200 Watchdog Timer"
> + bool "MPC52xx Watchdog Timer"
>   depends on PPC_MPC52xx
> + help
> +   Use General Purpose Timer (GPT) 0 on the MPC5200 as Watchdog.

s/5200/52xx/ here too.

>  
>  config 8xxx_WDT
>   tristate "MPC8xxx Platform Watchdog Timer"
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 699199b..89c045d 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -118,7 +118,6 @@ obj-$(CONFIG_TXX9_WDT) += txx9wdt.o
>  
>  # POWERPC Architecture
>  obj-$(CONFIG_GEF_WDT) += gef_wdt.o
> -obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
>  obj-$(CONFIG_8xxx_WDT) += mpc8xxx_wdt.o
>  obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
>  obj-$(CONFIG_PIKA_WDT) += pika_wdt.o
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

-- 
Pengutronix e.K.   | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/  |


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/8] 8xx: Misc fixes for buggy insn

[Scott Wood]

Joakim Tjernlund wrote:

Scott Wood  wrote on 11/11/2009 16:26:53:

On Wed, Nov 11, 2009 at 01:06:10AM +0100, Joakim Tjernlund wrote:

Scott Wood  wrote on 11/11/2009 00:21:18:

Where would you put the dcbi?  How do you regain control after that
cache line has been refilled, but before code flows back to the bad branch?

The dcbi would replace the current CPU15 tlbie.

But that only works if you take an ITLB miss at the right time.


Yeah, I misread the CPU15 errata so my ideas will not work.

Anyhow, will you send a patch that make TLB pinning mandatory?
After that my series can go in.


One other concern with pinning on 8xx -- could it cause problems with 
uncached DMA mappings?  What happens if a speculative load pulls in a 
cache line in an area that's supposed to be uncached?


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv2 3/3] mpc52xx/wdt: remove obsolete old WDT implementation

[Grant Likely]

On Thu, Nov 12, 2009 at 11:45 AM, Albrecht Dreß  wrote:
> Remove the old WDT implementation.
>
> Signed-off-by: Albrecht Dreß 

Acked-by: Grant Likely 

Wim, I'm picking up the other 2 patches into my tree.  Do you want me
to push this patch through my tree, or do you want to pick it up?

g.

> ---
>
> Change against v1: WDT stuff now fully merged into the file
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c.
>
> Note: The file drivers/watchdog/mpc5200_wdt.c is now obsolete and should be 
> removed.
>
>  drivers/watchdog/Kconfig  |    4 +++-
>  drivers/watchdog/Makefile |    1 -
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 3711b88..d958b76 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -861,8 +861,10 @@ config GEF_WDT
>          Watchdog timer found in a number of GE Fanuc single board computers.
>
>  config MPC5200_WDT
> -       tristate "MPC5200 Watchdog Timer"
> +       bool "MPC52xx Watchdog Timer"
>        depends on PPC_MPC52xx
> +       help
> +         Use General Purpose Timer (GPT) 0 on the MPC5200 as Watchdog.
>
>  config 8xxx_WDT
>        tristate "MPC8xxx Platform Watchdog Timer"
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 699199b..89c045d 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -118,7 +118,6 @@ obj-$(CONFIG_TXX9_WDT) += txx9wdt.o
>
>  # POWERPC Architecture
>  obj-$(CONFIG_GEF_WDT) += gef_wdt.o
> -obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
>  obj-$(CONFIG_8xxx_WDT) += mpc8xxx_wdt.o
>  obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
>  obj-$(CONFIG_PIKA_WDT) += pika_wdt.o
>
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv2 2/3] mpc52xx/wdt: merge WDT code into the GPT driver

[Grant Likely]

On Thu, Nov 12, 2009 at 11:44 AM, Albrecht Dreß  wrote:
> Merge the WDT code into the GPT interface.
>
> Signed-off-by: Albrecht Dreß 

Looks good to me.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv2 1/3] mpc52xx/wdt: OF property to enable the WDT on boot

[Grant Likely]

On Thu, Nov 12, 2009 at 11:43 AM, Albrecht Dreß  wrote:
> Add the "fsl,wdt-on-boot" OF property as to reserve a GPT as WDT which may
> be a requirement in safety-related (e.g. ISO/EN 61508) applications.
>
> Signed-off-by: Albrecht Dreß 
>
> ---
>
> Change against v1: rename the new property.
>
>  Documentation/powerpc/dts-bindings/fsl/mpc5200.txt |   17 -
>  1 files changed, 16 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt 
> b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
> index 8447fd7..ddd5ee3 100644
> --- a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
> +++ b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
> @@ -103,7 +103,22 @@ fsl,mpc5200-gpt nodes
>  -
>  On the mpc5200 and 5200b, GPT0 has a watchdog timer function.  If the board
>  design supports the internal wdt, then the device node for GPT0 should
> -include the empty property 'fsl,has-wdt'.
> +include the empty property 'fsl,has-wdt'.  Note that this does not activate
> +the watchdog.  The timer will function as a GPT if the timer api is used, and
> +it will function as watchdog if the watchdog device is used.  The watchdog
> +mode has priority over the gpt mode, i.e. if the watchdog is activated, any
> +gpt api call to this timer will fail with -EBUSY.
> +
> +If you add the property
> +       fsl,wdt-on-boot = ;
> +GPT0 will be marked as in-use watchdog, i.e. blocking every gpt access to it.
> +If n>0, the watchdog is started with a timeout of n seconds.  If n=0, the
> +configuration of the watchdog is not touched.  This is useful in two cases:
> +- just mark GPT0 as watchdog, blocking gpt accesses, and configure it later;
> +- do not touch a configuration assigned by the boot loader which supervises
> +  the boot process itself.
> +
> +The watchdog will respect the CONFIG_WATCHDOG_NOWAYOUT option.

I think it would be better to use a device tree property to enable up
NOWAYOUT.  The static config isn't multiplatform-friendly.  Thoughts?

Otherwise, this looks good to me.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

problem with POSIX timers

[Logan.Ratner]

I'm on a project where I recently switched from BSD style timers
(setitimer/getitimer) to POSIX style timers
(timer_settime/timer_gettime) so I can use the timer_getoverrun
function.  This works fine, except that now on my embedded PPC platform
changing the system time with either settimeofday or clock_settime has
an effect on relative timers, which according to POSIX shouldn't happen.
The same code works fine on the x86 platforms I've tested on; I only see
the problem on my PPC machine.

 

I've also tried using CLOCK_MONOTONIC instead of CLOCK_REALTIME, but
that does not seem to be supported on my platform either.

 

I'm using:

 

An MPC8270 processor

A 2.6.17.6 kernel

librt ver. 2.3.5

libc ver. 2.3.5

g++ 4.0 targeting powerpc-linux

 

Is this a known problem?  Is there a patch or a later kernel that would
correct this problem?

Also, is this the right place to be asking this question, and if not
could anyone suggest a better forum?

 

Any help or advice would be greatly appreciated.

Thanks in advance,

 

Logan Ratner | Software Engineer | Rosemount Analytical

Emerson Process Management | 5650 Brittmoore Rd | Houston | TX | 77041 |
USA

T +1 713 839 9656 | F +1 713 827 3807

logan.rat...@emerson.com

 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCHv2 3/3] mpc52xx/wdt: remove obsolete old WDT implementation

[Albrecht Dreß]

Remove the old WDT implementation.

Signed-off-by: Albrecht Dreß 
---

Change against v1: WDT stuff now fully merged into the file
arch/powerpc/platforms/52xx/mpc52xx_gpt.c.

Note: The file drivers/watchdog/mpc5200_wdt.c is now obsolete and should be 
removed.

 drivers/watchdog/Kconfig  |4 +++-
 drivers/watchdog/Makefile |1 -
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 3711b88..d958b76 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -861,8 +861,10 @@ config GEF_WDT
  Watchdog timer found in a number of GE Fanuc single board computers.
 
 config MPC5200_WDT
-   tristate "MPC5200 Watchdog Timer"
+   bool "MPC52xx Watchdog Timer"
depends on PPC_MPC52xx
+   help
+ Use General Purpose Timer (GPT) 0 on the MPC5200 as Watchdog.
 
 config 8xxx_WDT
tristate "MPC8xxx Platform Watchdog Timer"
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 699199b..89c045d 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -118,7 +118,6 @@ obj-$(CONFIG_TXX9_WDT) += txx9wdt.o
 
 # POWERPC Architecture
 obj-$(CONFIG_GEF_WDT) += gef_wdt.o
-obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
 obj-$(CONFIG_8xxx_WDT) += mpc8xxx_wdt.o
 obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
 obj-$(CONFIG_PIKA_WDT) += pika_wdt.o

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCHv2 2/3] mpc52xx/wdt: merge WDT code into the GPT driver

[Albrecht Dreß]

Merge the WDT code into the GPT interface.

Signed-off-by: Albrecht Dreß 
---

Change against v1: fully merge the wdt api into this file.
Note: The patch does also include the tiny GPT api changes from
.

 arch/powerpc/include/asm/mpc52xx.h|5 +-
 arch/powerpc/platforms/52xx/mpc52xx_gpt.c |  328 +++--
 2 files changed, 312 insertions(+), 21 deletions(-)

diff --git a/arch/powerpc/include/asm/mpc52xx.h 
b/arch/powerpc/include/asm/mpc52xx.h
index 707ab75..b664ce7 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -279,9 +279,10 @@ extern void mpc52xx_restart(char *cmd);
 /* mpc52xx_gpt.c */
 struct mpc52xx_gpt_priv;
 extern struct mpc52xx_gpt_priv *mpc52xx_gpt_from_irq(int irq);
-extern int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, int period,
+extern int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, u64 period,
 int continuous);
-extern void mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt);
+extern u64 mpc52xx_gpt_timer_period(struct mpc52xx_gpt_priv *gpt);
+extern int mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt);

 /* mpc52xx_lpbfifo.c */
 #define MPC52XX_LPBFIFO_FLAG_READ  (0)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c 
b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index 2c3fa13..42caecf 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -16,8 +16,14 @@
  * output signals or measure input signals.
  *
  * This driver supports the GPIO and IRQ controller functions of the GPT
- * device.  Timer functions are not yet supported, nor is the watchdog
- * timer.
+ * device.  Timer functions are not yet supported.
+ *
+ * The timer gpt0 can be used as watchdog (wdt).  If the wdt mode is used,
+ * this prevents the use of any gpt0 gpt function (i.e. they will fail with
+ * -EBUSY).  Thus, the safety wdt function always has precedence over the gpt
+ * function.  If the kernel has been compiled with CONFIG_WATCHDOG_NOWAYOUT,
+ * this means that gpt0 is locked in wdt mode until the next reboot - this
+ * may be a requirement in safety applications.
  *
  * To use the GPIO function, the following two properties must be added
  * to the device tree node for the gpt device (typically in the .dts file
@@ -56,11 +62,14 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 

 MODULE_DESCRIPTION("Freescale MPC52xx gpt driver");
-MODULE_AUTHOR("Sascha Hauer, Grant Likely");
+MODULE_AUTHOR("Sascha Hauer, Grant Likely, Albrecht Dreß");
 MODULE_LICENSE("GPL");

 /**
@@ -70,6 +79,9 @@ MODULE_LICENSE("GPL");
  * @lock: spinlock to coordinate between different functions.
  * @of_gc: of_gpio_chip instance structure; used when GPIO is enabled
  * @irqhost: Pointer to irq_host instance; used when IRQ mode is supported
+ * @wdt_mode: only relevant for gpt0: bit 0 (MPC52xx_GPT_CAN_WDT) indicates
+ *   if the gpt may be used as wdt, bit 1 (MPC52xx_GPT_IS_WDT) indicates
+ *   if the timer is actively used as wdt which blocks gpt functions
  */
 struct mpc52xx_gpt_priv {
struct list_head list;  /* List of all GPT devices */
@@ -78,6 +90,7 @@ struct mpc52xx_gpt_priv {
spinlock_t lock;
struct irq_host *irqhost;
u32 ipb_freq;
+   u8 wdt_mode;

 #if defined(CONFIG_GPIOLIB)
struct of_gpio_chip of_gc;
@@ -101,14 +114,21 @@ DEFINE_MUTEX(mpc52xx_gpt_list_mutex);
 #define MPC52xx_GPT_MODE_CONTINUOUS(0x0400)
 #define MPC52xx_GPT_MODE_OPEN_DRAIN(0x0200)
 #define MPC52xx_GPT_MODE_IRQ_EN(0x0100)
+#define MPC52xx_GPT_MODE_WDT_EN(0x8000)

 #define MPC52xx_GPT_MODE_ICT_MASK  (0x03)
 #define MPC52xx_GPT_MODE_ICT_RISING(0x01)
 #define MPC52xx_GPT_MODE_ICT_FALLING   (0x02)
 #define MPC52xx_GPT_MODE_ICT_TOGGLE(0x03)

+#define MPC52xx_GPT_MODE_WDT_PING  (0xa5)
+
 #define MPC52xx_GPT_STATUS_IRQMASK (0x000f)

+#define MPC52xx_GPT_CAN_WDT(1 << 0)
+#define MPC52xx_GPT_IS_WDT (1 << 1)
+
+
 /* -
  * Cascaded interrupt controller hooks
  */
@@ -375,16 +395,8 @@ struct mpc52xx_gpt_priv *mpc52xx_gpt_from_irq(int irq)
 }
 EXPORT_SYMBOL(mpc52xx_gpt_from_irq);

-/**
- * mpc52xx_gpt_start_timer - Set and enable the GPT timer
- * @gpt: Pointer to gpt private data structure
- * @period: period of timer
- * @continuous: set to 1 to make timer continuous free running
- *
- * An interrupt will be generated every time the timer fires
- */
-int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, int period,
-int continuous)
+static int mpc52xx_gpt_do_start(struct mpc52xx_gpt_priv *gpt, u64 period,
+   int continuous, int as_wdt)
 {
u32 clear, set;
u64 clocks;
@@ -393,15 +40

[PATCHv2 1/3] mpc52xx/wdt: OF property to enable the WDT on boot

[Albrecht Dreß]

Add the "fsl,wdt-on-boot" OF property as to reserve a GPT as WDT which may
be a requirement in safety-related (e.g. ISO/EN 61508) applications.

Signed-off-by: Albrecht Dreß 

---

Change against v1: rename the new property.

 Documentation/powerpc/dts-bindings/fsl/mpc5200.txt |   17 -
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt 
b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
index 8447fd7..ddd5ee3 100644
--- a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
@@ -103,7 +103,22 @@ fsl,mpc5200-gpt nodes
 -
 On the mpc5200 and 5200b, GPT0 has a watchdog timer function.  If the board
 design supports the internal wdt, then the device node for GPT0 should
-include the empty property 'fsl,has-wdt'.
+include the empty property 'fsl,has-wdt'.  Note that this does not activate
+the watchdog.  The timer will function as a GPT if the timer api is used, and
+it will function as watchdog if the watchdog device is used.  The watchdog
+mode has priority over the gpt mode, i.e. if the watchdog is activated, any
+gpt api call to this timer will fail with -EBUSY.
+
+If you add the property
+   fsl,wdt-on-boot = ;
+GPT0 will be marked as in-use watchdog, i.e. blocking every gpt access to it.
+If n>0, the watchdog is started with a timeout of n seconds.  If n=0, the
+configuration of the watchdog is not touched.  This is useful in two cases:
+- just mark GPT0 as watchdog, blocking gpt accesses, and configure it later;
+- do not touch a configuration assigned by the boot loader which supervises
+  the boot process itself.
+
+The watchdog will respect the CONFIG_WATCHDOG_NOWAYOUT option.
 
 An mpc5200-gpt can be used as a single line GPIO controller.  To do so,
 add the following properties to the gpt node:

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCHv2 0/3] mpc52xx/wdt: re-enable the MPC5200 WDT

[Albrecht Dreß]

This set of patches merges the MPC5200 WDT into the GPT code, making it
functional again - currently, the MPC5200 GPT code blocks using the WDT.

Additionally, it defines a new OF property as to reserve and/or enable the
WDT during the boot process which may be a requirement for safety-related
(e.g. ISO/EN 61508) applications.

Note that all patches are against Grant Likely's "next" tree.

Compared to the first version of the patch, the basic change is a full merge
of the WDT code into the GPT implementation in arch/powerpc/platforms/52xx.
It makes the old WDT implementation file obsolete.  As a side effect, it is
not possible any more to build the 52xx WDT support as module which shouldn't
be a big issue, though.

Cheers, Albrecht.

---

 Documentation/powerpc/dts-bindings/fsl/mpc5200.txt |   17 +-
 arch/powerpc/include/asm/mpc52xx.h |5 +-
 arch/powerpc/platforms/52xx/mpc52xx_gpt.c  |  328 ++--
 drivers/watchdog/Kconfig   |4 +-
 drivers/watchdog/Makefile  |1 -
 5 files changed, 331 insertions(+), 24 deletions(-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/4] xilinx_spi: Split into of driver and generic part.

[Richard Röjfors]

On 11/12/09 6:17 PM, John Linn wrote:
>> Have you compile tested this?  platform_data is a void*, the
>> dereference will not work.  I know you don't have hardware; but
>> getting the needed cross compiler is easy.
> 
> Here's the fixes I did to make it compile. On to testing :)

Great! I tested this against a max7301 GPIO expander.

--Richard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 1/4] xilinx_spi: Split into of driver and generic part.

[John Linn]

> -Original Message-
> From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant 
> Likely
> Sent: Thursday, November 12, 2009 7:56 AM
> To: Richard Röjfors
> Cc: spi-devel-gene...@lists.sourceforge.net; linuxppc-...@ozlabs.org; Andrew 
> Morton;
> dbrown...@users.sourceforge.net; John Linn
> Subject: Re: [PATCH v2 1/4] xilinx_spi: Split into of driver and generic part.
> 
> On Thu, Nov 12, 2009 at 7:26 AM, Richard Röjfors
>  wrote:
> > This patch splits the xilinx_spi driver into a generic part and a
> > OF driver part.
> >
> > The reason for this is to later add in a platform driver as well.
> >
> > Signed-off-by: Richard Röjfors 
> > ---



> > +
> > +       if (!ofdev->dev.platform_data) {
> > +               ofdev->dev.platform_data =
> > +                       kzalloc(sizeof(struct xspi_platform_data), 
> > GFP_KERNEL);
> > +               if (!ofdev->dev.platform_data)
> > +                       return -ENOMEM;
> > +       }
> 
> Minor memory leak.  Anything alloced in the probe path should also be
> freed in the remove path.  It's not going to spiral out of control or
> anything, but it is important to be strict about such things.  Drop
> the outer if{} block here and kfree platform_data on remove.
> 
> > +
> > +       /* number of slave select bits is required */
> > +       prop = of_get_property(ofdev->node, "xlnx,num-ss-bits", &len);
> > +       if (!prop || len < sizeof(*prop)) {
> > +               dev_warn(&ofdev->dev, "no 'xlnx,num-ss-bits' property\n");
> > +               return -EINVAL;
> > +       }
> > +       ofdev->dev.platform_data->num_chipselect = *prop;
> 
> Have you compile tested this?  platform_data is a void*, the
> dereference will not work.  I know you don't have hardware; but
> getting the needed cross compiler is easy.

Here's the fixes I did to make it compile. On to testing :)

Thanks,
John

diff --git a/drivers/spi/xilinx_spi_of.c b/drivers/spi/xilinx_spi_of.c
index 13e1591..2dea9f3 100644
--- a/drivers/spi/xilinx_spi_of.c
+++ b/drivers/spi/xilinx_spi_of.c
@@ -39,6 +39,7 @@
 static int __init xilinx_spi_of_probe(struct of_device *ofdev,
const struct of_device_id *match)
 {
+   struct xspi_platform_data *pdata = ofdev->dev.platform_data;
struct resource r_irq_struct;
struct resource r_mem_struct;
struct spi_master *master;
@@ -74,8 +75,8 @@ static int __init xilinx_spi_of_probe(struct of_device *ofdev,
dev_warn(&ofdev->dev, "no 'xlnx,num-ss-bits' property\n");
return -EINVAL;
}
-   ofdev->dev.platform_data->num_chipselect = *prop;
-   ofdev->dev.platform_data->bits_per_word = 8;
+   pdata->num_chipselect = *prop;
+   pdata->bits_per_word = 8;
master = xilinx_spi_init(&ofdev->dev, r_mem, r_irq->start, -1);
if (!master)
return -ENODEV;

> 
> > +       master = xilinx_spi_init(&ofdev->dev, r_mem, r_irq->start, -1);
> > +       if (!master)
> > +               return -ENODEV;
> > +
> > +       dev_set_drvdata(&ofdev->dev, master);
> > +
> > +       /* Add any subnodes on the SPI bus */
> > +       of_register_spi_devices(master, ofdev->node);
> > +
> > +       return 0;
> > +}


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/4] xilinx_spi: Split into of driver and generic part.

[Richard Röjfors]

Hi,

There are some proposed updates from you which are inherited from the old code

I think it's better that you (xilinx?) take responsibility for that part, I
really don't want to maintain others' code which I even can't compile.

There was a type error I will fix.

Comments below...

//Richard


Grant Likely wrote:
> On Thu, Nov 12, 2009 at 7:26 AM, Richard Röjfors
>  wrote:
>> This patch splits the xilinx_spi driver into a generic part and a
>> OF driver part.
>>
>> The reason for this is to later add in a platform driver as well.
>>
>> Signed-off-by: Richard Röjfors 
>> ---
>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>> index 4b6f7cb..e60b264 100644
>> --- a/drivers/spi/Kconfig
>> +++ b/drivers/spi/Kconfig
>> @@ -236,7 +236,7 @@ config SPI_TXX9
>>
>>  config SPI_XILINX
>>tristate "Xilinx SPI controller"
>> -   depends on (XILINX_VIRTEX || MICROBLAZE) && EXPERIMENTAL
>> +   depends on EXPERIMENTAL
>>select SPI_BITBANG
>>help
>>  This exposes the SPI controller IP from the Xilinx EDK.
>> @@ -244,6 +244,12 @@ config SPI_XILINX
>>  See the "OPB Serial Peripheral Interface (SPI) (v1.00e)"
>>  Product Specification document (DS464) for hardware details.
>>
>> +config SPI_XILINX_OF
>> +   tristate "Xilinx SPI controller OF device"
>> +   depends on SPI_XILINX && (XILINX_VIRTEX || MICROBLAZE)
>> +   help
>> + This is the OF driver for the SPI controller IP from the Xilinx 
>> EDK.
>> +
>>  #
>>  # Add new SPI master controllers in alphabetical order above this line
>>  #
>> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
>> index 21a1182..97dee8f 100644
>> --- a/drivers/spi/Makefile
>> +++ b/drivers/spi/Makefile
>> @@ -31,6 +31,7 @@ obj-$(CONFIG_SPI_S3C24XX_GPIO)+= 
>> spi_s3c24xx_gpio.o
>>  obj-$(CONFIG_SPI_S3C24XX)  += spi_s3c24xx.o
>>  obj-$(CONFIG_SPI_TXX9) += spi_txx9.o
>>  obj-$(CONFIG_SPI_XILINX)   += xilinx_spi.o
>> +obj-$(CONFIG_SPI_XILINX_OF)+= xilinx_spi_of.o
>>  obj-$(CONFIG_SPI_SH_SCI)   += spi_sh_sci.o
>>  obj-$(CONFIG_SPI_STMP3XXX) += spi_stmp.o
>>  #  ... add above this line ...
>> diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
>> index 46b8c5c..5761a4c 100644
>> --- a/drivers/spi/xilinx_spi.c
>> +++ b/drivers/spi/xilinx_spi.c
>> @@ -14,16 +14,14 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>> -
>> -#include 
>> -#include 
>> -#include 
>>
>>  #include 
>>  #include 
>>  #include 
>>
>> +#include "xilinx_spi.h"
>> +#include 
>> +
>>  #define XILINX_SPI_NAME "xilinx_spi"
>>
>>  /* Register definitions as per "OPB Serial Peripheral Interface (SPI) 
>> (v1.00e)
>> @@ -78,7 +76,7 @@ struct xilinx_spi {
>>/* bitbang has to be first */
>>struct spi_bitbang bitbang;
>>struct completion done;
>> -
>> +   struct resource mem; /* phys mem */
>>void __iomem*regs;  /* virt. address of the control registers */
>>
>>u32 irq;
>> @@ -283,40 +281,22 @@ static irqreturn_t xilinx_spi_irq(int irq, void 
>> *dev_id)
>>return IRQ_HANDLED;
>>  }
>>
>> -static int __init xilinx_spi_of_probe(struct of_device *ofdev,
>> -   const struct of_device_id *match)
>> +struct spi_master *xilinx_spi_init(struct device *dev, struct resource *mem,
>> +   u32 irq, s16 bus_num)
>>  {
>>struct spi_master *master;
>>struct xilinx_spi *xspi;
>> -   struct resource r_irq_struct;
>> -   struct resource r_mem_struct;
>> -
>> -   struct resource *r_irq = &r_irq_struct;
>> -   struct resource *r_mem = &r_mem_struct;
>> -   int rc = 0;
>> -   const u32 *prop;
>> -   int len;
>> -
>> -   /* Get resources(memory, IRQ) associated with the device */
>> -   master = spi_alloc_master(&ofdev->dev, sizeof(struct xilinx_spi));
>> +   struct xspi_platform_data *pdata = dev->platform_data;
>> +   int ret;
>>
>> -   if (master == NULL) {
>> -   return -ENOMEM;
>> -   }
>> -
>> -   dev_set_drvdata(&ofdev->dev, master);
>> -
>> -   rc = of_address_to_resource(ofdev->node, 0, r_mem);
>> -   if (rc) {
>> -   dev_warn(&ofdev->dev, "invalid address\n");
>> -   goto put_master;
>> +   if (!pdata) {
>> +   dev_err(dev, "No platform data attached\n");
>> +   return NULL;
>>}
>>
>> -   rc = of_irq_to_resource(ofdev->node, 0, r_irq);
>> -   if (rc == NO_IRQ) {
>> -   dev_warn(&ofdev->dev, "no IRQ found\n");
>> -   goto put_master;
>> -   }
>> +   master = spi_alloc_master(dev, sizeof(struct xilinx_spi));
>> +   if (!master)
>> +   return NULL;
>>
>>/* the spi->mode bits understood by this driver: */
>>master->mode_bits = SPI_CPOL | SPI_CPHA;
>> @@ -329,128 +309,67 @@ static int __init xilinx_spi_of_probe(struct 
>>

RE: Disable Caching for mmap() address

[Jonathan Haws]

> On Mon, 2009-11-09 at 16:21 -0700, Jonathan Haws wrote:
> > All,
> >
> > I would like to disable caching for an address that was returned
> from a call to mmap().  I am using this address for DMA operations
> in user space and want to make sure that the data cache is turned
> off for that buffer.
> >
> > The way this works is the driver simply takes an address I provide
> and begins a DMA operation to that location in RAM (I have ensured
> that this is a physical address I am passing already).  When the DMA
> is complete, an interrupt fires and the ISR gives a semaphore that
> the user space application is pending on (RT_SEM from Xenomai).  I
> have tried simply calling a cache invalidate routine in the ISR
> before I give the semaphore, but the kernel crashes when I try to
> call that routine - my guess it because the kernel does not have
> direct access to that location in memory (only my application does,
> according to the MMU).
> >
> > Anyway, all I want to do is make sure that the buffer is never
> stored in the cache and that I always fetch it from RAM.  How can I
> specify that using mmap() on the /dev/mem device, or is there a
> better way to accomplish this?
> 
> There is no "proper" way to do this, in large part because it's not
> always legal to map memory non-cached for various reasons I don't
> have time to explain right now...
> 
> You may be able to get it working though but using a specific driver
> with an mmap function that tweaks the attributes or using mmap
> of /dev/mem after opening it with O_SYNC (off the top of my mind)
> 
> But it's a bit fishy as the kernel has a cacheable mapping of most
> of memory and so you may end up with cache aliases...


Thanks for the response, Ben.  I am hoping that by passing a mem= argument to 
the kernel at boot time, the memory that I am setting aside for my DMA will be 
kept hidden from the kernel and the MMU.  I am then mapping that memory in user 
space with mmap() on /dev/mem and that descriptor is being opened with the 
O_SYNC flag.  I just wanted to make sure I was covering all my bases.

Thanks,

Jonathan



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 4/4] xilinx_spi: add a platform driver using the xilinx_spi common module.

[Grant Likely]

On Thu, Nov 12, 2009 at 7:28 AM, Richard Röjfors
 wrote:
> This patch adds in a platform device driver using the xilinx_spi common 
> module.
>
> Signed-off-by: Richard Röjfors 

Acked-by: Grant Likely 

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 2/4] xilinx_spi: Switch to iomem functions and support little endian.

[Grant Likely]

On Thu, Nov 12, 2009 at 7:26 AM, Richard Röjfors
 wrote:
> This patch changes the out_(be)(8|16|32) and in_(be)(8|16|32) calls to 32 
> bits ioread/iowrite.
>
> The read and write function are attached to the internal struct as callbacks, 
> callback
> is selected depending on endianess.
>
> This will also build on platforms not supporting the in/out calls for 
> instance x86.
>
> Signed-off-by: Richard Röjfors 

On brief review looks good to me.

Acked-by: Grant Likely 

> ---
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index e60b264..9667650 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -236,7 +236,7 @@ config SPI_TXX9
>
>  config SPI_XILINX
>        tristate "Xilinx SPI controller"
> -       depends on EXPERIMENTAL
> +       depends on HAS_IOMEM && EXPERIMENTAL
>        select SPI_BITBANG
>        help
>          This exposes the SPI controller IP from the Xilinx EDK.
> diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
> index 5761a4c..d0ca13a 100644
> --- a/drivers/spi/xilinx_spi.c
> +++ b/drivers/spi/xilinx_spi.c
> @@ -27,7 +27,7 @@
>  /* Register definitions as per "OPB Serial Peripheral Interface (SPI) 
> (v1.00e)
>  * Product Specification", DS464
>  */
> -#define XSPI_CR_OFFSET         0x62    /* 16-bit Control Register */
> +#define XSPI_CR_OFFSET         0x60    /* 16-bit Control Register */
>
>  #define XSPI_CR_ENABLE         0x02
>  #define XSPI_CR_MASTER_MODE    0x04
> @@ -39,7 +39,7 @@
>  #define XSPI_CR_MANUAL_SSELECT 0x80
>  #define XSPI_CR_TRANS_INHIBIT  0x100
>
> -#define XSPI_SR_OFFSET         0x67    /* 8-bit Status Register */
> +#define XSPI_SR_OFFSET         0x64    /* 8-bit Status Register */
>
>  #define XSPI_SR_RX_EMPTY_MASK  0x01    /* Receive FIFO is empty */
>  #define XSPI_SR_RX_FULL_MASK   0x02    /* Receive FIFO is full */
> @@ -47,8 +47,8 @@
>  #define XSPI_SR_TX_FULL_MASK   0x08    /* Transmit FIFO is full */
>  #define XSPI_SR_MODE_FAULT_MASK        0x10    /* Mode fault error */
>
> -#define XSPI_TXD_OFFSET                0x6b    /* 8-bit Data Transmit 
> Register */
> -#define XSPI_RXD_OFFSET                0x6f    /* 8-bit Data Receive 
> Register */
> +#define XSPI_TXD_OFFSET                0x68    /* 8-bit Data Transmit 
> Register */
> +#define XSPI_RXD_OFFSET                0x6c    /* 8-bit Data Receive 
> Register */
>
>  #define XSPI_SSR_OFFSET                0x70    /* 32-bit Slave Select 
> Register */
>
> @@ -86,25 +86,29 @@ struct xilinx_spi {
>        u8 *rx_ptr;             /* pointer in the Tx buffer */
>        const u8 *tx_ptr;       /* pointer in the Rx buffer */
>        int remaining_bytes;    /* the number of bytes left to transfer */
> +       unsigned int (*read_fn) (void __iomem *);
> +       void (*write_fn) (u32, void __iomem *);
>  };
>
> -static void xspi_init_hw(void __iomem *regs_base)
> +static void xspi_init_hw(struct xilinx_spi *xspi)
>  {
> +       void __iomem *regs_base = xspi->regs;
> +
>        /* Reset the SPI device */
> -       out_be32(regs_base + XIPIF_V123B_RESETR_OFFSET,
> -                XIPIF_V123B_RESET_MASK);
> +       xspi->write_fn(XIPIF_V123B_RESET_MASK,
> +               regs_base + XIPIF_V123B_RESETR_OFFSET);
>        /* Disable all the interrupts just in case */
> -       out_be32(regs_base + XIPIF_V123B_IIER_OFFSET, 0);
> +       xspi->write_fn(0, regs_base + XIPIF_V123B_IIER_OFFSET);
>        /* Enable the global IPIF interrupt */
> -       out_be32(regs_base + XIPIF_V123B_DGIER_OFFSET,
> -                XIPIF_V123B_GINTR_ENABLE);
> +       xspi->write_fn(XIPIF_V123B_GINTR_ENABLE,
> +               regs_base + XIPIF_V123B_DGIER_OFFSET);
>        /* Deselect the slave on the SPI bus */
> -       out_be32(regs_base + XSPI_SSR_OFFSET, 0x);
> +       xspi->write_fn(0x, regs_base + XSPI_SSR_OFFSET);
>        /* Disable the transmitter, enable Manual Slave Select Assertion,
>         * put SPI controller into master mode, and enable it */
> -       out_be16(regs_base + XSPI_CR_OFFSET,
> -                XSPI_CR_TRANS_INHIBIT | XSPI_CR_MANUAL_SSELECT
> -                | XSPI_CR_MASTER_MODE | XSPI_CR_ENABLE);
> +       xspi->write_fn(XSPI_CR_TRANS_INHIBIT | XSPI_CR_MANUAL_SSELECT |
> +               XSPI_CR_MASTER_MODE | XSPI_CR_ENABLE,
> +               regs_base + XSPI_CR_OFFSET);
>  }
>
>  static void xilinx_spi_chipselect(struct spi_device *spi, int is_on)
> @@ -113,16 +117,16 @@ static void xilinx_spi_chipselect(struct spi_device 
> *spi, int is_on)
>
>        if (is_on == BITBANG_CS_INACTIVE) {
>                /* Deselect the slave on the SPI bus */
> -               out_be32(xspi->regs + XSPI_SSR_OFFSET, 0x);
> +               xspi->write_fn(0x, xspi->regs + XSPI_SSR_OFFSET);
>        } else if (is_on == BITBANG_CS_ACTIVE) {
>                /* Set the SPI clock phase and polarity */
> -               u16 cr = in_be16(xspi->regs + XSPI_CR_OFFSET)
> +               u16 cr = xspi->read_fn(xspi->regs + XSPI_CR_OFFSET)
>                         & ~

Re: [PATCH v2 1/4] xilinx_spi: Split into of driver and generic part.

[Grant Likely]

On Thu, Nov 12, 2009 at 7:26 AM, Richard Röjfors
 wrote:
> This patch splits the xilinx_spi driver into a generic part and a
> OF driver part.
>
> The reason for this is to later add in a platform driver as well.
>
> Signed-off-by: Richard Röjfors 
> ---
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 4b6f7cb..e60b264 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -236,7 +236,7 @@ config SPI_TXX9
>
>  config SPI_XILINX
>        tristate "Xilinx SPI controller"
> -       depends on (XILINX_VIRTEX || MICROBLAZE) && EXPERIMENTAL
> +       depends on EXPERIMENTAL
>        select SPI_BITBANG
>        help
>          This exposes the SPI controller IP from the Xilinx EDK.
> @@ -244,6 +244,12 @@ config SPI_XILINX
>          See the "OPB Serial Peripheral Interface (SPI) (v1.00e)"
>          Product Specification document (DS464) for hardware details.
>
> +config SPI_XILINX_OF
> +       tristate "Xilinx SPI controller OF device"
> +       depends on SPI_XILINX && (XILINX_VIRTEX || MICROBLAZE)
> +       help
> +         This is the OF driver for the SPI controller IP from the Xilinx EDK.
> +
>  #
>  # Add new SPI master controllers in alphabetical order above this line
>  #
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 21a1182..97dee8f 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_SPI_S3C24XX_GPIO)                += 
> spi_s3c24xx_gpio.o
>  obj-$(CONFIG_SPI_S3C24XX)              += spi_s3c24xx.o
>  obj-$(CONFIG_SPI_TXX9)                 += spi_txx9.o
>  obj-$(CONFIG_SPI_XILINX)               += xilinx_spi.o
> +obj-$(CONFIG_SPI_XILINX_OF)            += xilinx_spi_of.o
>  obj-$(CONFIG_SPI_SH_SCI)               += spi_sh_sci.o
>  obj-$(CONFIG_SPI_STMP3XXX)             += spi_stmp.o
>  #      ... add above this line ...
> diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
> index 46b8c5c..5761a4c 100644
> --- a/drivers/spi/xilinx_spi.c
> +++ b/drivers/spi/xilinx_spi.c
> @@ -14,16 +14,14 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -
> -#include 
> -#include 
> -#include 
>
>  #include 
>  #include 
>  #include 
>
> +#include "xilinx_spi.h"
> +#include 
> +
>  #define XILINX_SPI_NAME "xilinx_spi"
>
>  /* Register definitions as per "OPB Serial Peripheral Interface (SPI) 
> (v1.00e)
> @@ -78,7 +76,7 @@ struct xilinx_spi {
>        /* bitbang has to be first */
>        struct spi_bitbang bitbang;
>        struct completion done;
> -
> +       struct resource mem; /* phys mem */
>        void __iomem    *regs;  /* virt. address of the control registers */
>
>        u32             irq;
> @@ -283,40 +281,22 @@ static irqreturn_t xilinx_spi_irq(int irq, void *dev_id)
>        return IRQ_HANDLED;
>  }
>
> -static int __init xilinx_spi_of_probe(struct of_device *ofdev,
> -                                       const struct of_device_id *match)
> +struct spi_master *xilinx_spi_init(struct device *dev, struct resource *mem,
> +       u32 irq, s16 bus_num)
>  {
>        struct spi_master *master;
>        struct xilinx_spi *xspi;
> -       struct resource r_irq_struct;
> -       struct resource r_mem_struct;
> -
> -       struct resource *r_irq = &r_irq_struct;
> -       struct resource *r_mem = &r_mem_struct;
> -       int rc = 0;
> -       const u32 *prop;
> -       int len;
> -
> -       /* Get resources(memory, IRQ) associated with the device */
> -       master = spi_alloc_master(&ofdev->dev, sizeof(struct xilinx_spi));
> +       struct xspi_platform_data *pdata = dev->platform_data;
> +       int ret;
>
> -       if (master == NULL) {
> -               return -ENOMEM;
> -       }
> -
> -       dev_set_drvdata(&ofdev->dev, master);
> -
> -       rc = of_address_to_resource(ofdev->node, 0, r_mem);
> -       if (rc) {
> -               dev_warn(&ofdev->dev, "invalid address\n");
> -               goto put_master;
> +       if (!pdata) {
> +               dev_err(dev, "No platform data attached\n");
> +               return NULL;
>        }
>
> -       rc = of_irq_to_resource(ofdev->node, 0, r_irq);
> -       if (rc == NO_IRQ) {
> -               dev_warn(&ofdev->dev, "no IRQ found\n");
> -               goto put_master;
> -       }
> +       master = spi_alloc_master(dev, sizeof(struct xilinx_spi));
> +       if (!master)
> +               return NULL;
>
>        /* the spi->mode bits understood by this driver: */
>        master->mode_bits = SPI_CPOL | SPI_CPHA;
> @@ -329,128 +309,67 @@ static int __init xilinx_spi_of_probe(struct of_device 
> *ofdev,
>        xspi->bitbang.master->setup = xilinx_spi_setup;
>        init_completion(&xspi->done);
>
> -       xspi->irq = r_irq->start;
> -
> -       if (!request_mem_region(r_mem->start,
> -                       r_mem->end - r_mem->start + 1, XILINX_SPI_NAME)) {
> -               rc = -ENXIO;
> -               dev_warn(&ofdev->dev, "memory request failure\n");
> +       if (!request_mem_region(mem->start, resource_size(mem),
> +              

[PATCH v2 4/4] xilinx_spi: add a platform driver using the xilinx_spi common module.

[Richard Röjfors]

This patch adds in a platform device driver using the xilinx_spi common module.

Signed-off-by: Richard Röjfors 
---
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b956284..d1f8ee3 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -252,6 +252,13 @@ config SPI_XILINX_OF
help
  This is the OF driver for the SPI controller IP from the Xilinx EDK.

+config SPI_XILINX_PLTFM
+   tristate "Xilinx SPI controller platform device"
+   depends on SPI_XILINX
+   help
+ This is the platform driver for the SPI controller IP
+ from the Xilinx EDK.
+
 #
 # Add new SPI master controllers in alphabetical order above this line
 #
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 97dee8f..d8b0e4c 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_SPI_S3C24XX) += spi_s3c24xx.o
 obj-$(CONFIG_SPI_TXX9) += spi_txx9.o
 obj-$(CONFIG_SPI_XILINX)   += xilinx_spi.o
 obj-$(CONFIG_SPI_XILINX_OF)+= xilinx_spi_of.o
+obj-$(CONFIG_SPI_XILINX_PLTFM) += xilinx_spi_pltfm.o
 obj-$(CONFIG_SPI_SH_SCI)   += spi_sh_sci.o
 obj-$(CONFIG_SPI_STMP3XXX) += spi_stmp.o
 #  ... add above this line ...
diff --git a/drivers/spi/xilinx_spi_pltfm.c b/drivers/spi/xilinx_spi_pltfm.c
new file mode 100644
index 000..24debac
--- /dev/null
+++ b/drivers/spi/xilinx_spi_pltfm.c
@@ -0,0 +1,102 @@
+/*
+ * Support for Xilinx SPI platform devices
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/* Supports:
+ * Xilinx SPI devices as platform devices
+ *
+ * Inspired by xilinx_spi.c, 2002-2007 (c) MontaVista Software, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "xilinx_spi.h"
+
+static int __devinit xilinx_spi_probe(struct platform_device *dev)
+{
+   struct xspi_platform_data *pdata;
+   struct resource *r;
+   int irq;
+   struct spi_master *master;
+   u8 i;
+
+   pdata = dev->dev.platform_data;
+   if (!pdata)
+   return -ENODEV;
+
+   r = platform_get_resource(dev, IORESOURCE_MEM, 0);
+   if (!r)
+   return -ENODEV;
+
+   irq = platform_get_irq(dev, 0);
+   if (irq < 0)
+   return -ENXIO;
+
+   master = xilinx_spi_init(&dev->dev, r, irq, dev->id);
+   if (!master)
+   return -ENODEV;
+
+   for (i = 0; i < pdata->num_devices; i++)
+   spi_new_device(master, pdata->devices + i);
+
+   platform_set_drvdata(dev, master);
+   return 0;
+}
+
+static int __devexit xilinx_spi_remove(struct platform_device *dev)
+{
+   xilinx_spi_deinit(platform_get_drvdata(dev));
+   platform_set_drvdata(dev, 0);
+
+   return 0;
+}
+
+/* work with hotplug and coldplug */
+MODULE_ALIAS("platform:" XILINX_SPI_NAME);
+
+static struct platform_driver xilinx_spi_driver = {
+   .probe  = xilinx_spi_probe,
+   .remove = __devexit_p(xilinx_spi_remove),
+   .driver = {
+   .name = XILINX_SPI_NAME,
+   .owner = THIS_MODULE,
+   },
+};
+
+static int __init xilinx_spi_pltfm_init(void)
+{
+   return platform_driver_register(&xilinx_spi_driver);
+}
+module_init(xilinx_spi_pltfm_init);
+
+static void __exit xilinx_spi_pltfm_exit(void)
+{
+   platform_driver_unregister(&xilinx_spi_driver);
+}
+module_exit(xilinx_spi_pltfm_exit);
+
+MODULE_AUTHOR("Mocean Laboratories ");
+MODULE_DESCRIPTION("Xilinx SPI platform driver");
+MODULE_LICENSE("GPL v2");
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 3/4] xilinx_spi: add support for the DS570 IP.

[Richard Röjfors]

This patch adds in support for the DS570 IP.

It's register compatible with the DS464, but adds support for 8/16/32 SPI.

The 8/16/32 support is added by attaching callbacks reading/writing the
proper amount of data. To indicate to the driver which amount of bits
to use a new field is introduced in the platform data struct.

Signed-off-by: Richard Röjfors 
---
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 9667650..b956284 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -235,7 +235,7 @@ config SPI_TXX9
  SPI driver for Toshiba TXx9 MIPS SoCs

 config SPI_XILINX
-   tristate "Xilinx SPI controller"
+   tristate "Xilinx SPI controller common module"
depends on HAS_IOMEM && EXPERIMENTAL
select SPI_BITBANG
help
@@ -244,6 +244,8 @@ config SPI_XILINX
  See the "OPB Serial Peripheral Interface (SPI) (v1.00e)"
  Product Specification document (DS464) for hardware details.

+ Or for the DS570, see "XPS Serial Peripheral Interface (SPI) (v2.00b)"
+
 config SPI_XILINX_OF
tristate "Xilinx SPI controller OF device"
depends on SPI_XILINX && (XILINX_VIRTEX || MICROBLAZE)
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index d0ca13a..8d30c8f 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -27,7 +27,7 @@
 /* Register definitions as per "OPB Serial Peripheral Interface (SPI) (v1.00e)
  * Product Specification", DS464
  */
-#define XSPI_CR_OFFSET 0x60/* 16-bit Control Register */
+#define XSPI_CR_OFFSET 0x60/* Control Register */

 #define XSPI_CR_ENABLE 0x02
 #define XSPI_CR_MASTER_MODE0x04
@@ -38,8 +38,9 @@
 #define XSPI_CR_RXFIFO_RESET   0x40
 #define XSPI_CR_MANUAL_SSELECT 0x80
 #define XSPI_CR_TRANS_INHIBIT  0x100
+#define XSPI_CR_LSB_FIRST  0x200

-#define XSPI_SR_OFFSET 0x64/* 8-bit Status Register */
+#define XSPI_SR_OFFSET 0x64/* Status Register */

 #define XSPI_SR_RX_EMPTY_MASK  0x01/* Receive FIFO is empty */
 #define XSPI_SR_RX_FULL_MASK   0x02/* Receive FIFO is full */
@@ -47,8 +48,8 @@
 #define XSPI_SR_TX_FULL_MASK   0x08/* Transmit FIFO is full */
 #define XSPI_SR_MODE_FAULT_MASK0x10/* Mode fault error */

-#define XSPI_TXD_OFFSET0x68/* 8-bit Data Transmit Register 
*/
-#define XSPI_RXD_OFFSET0x6c/* 8-bit Data Receive Register 
*/
+#define XSPI_TXD_OFFSET0x68/* Data Transmit Register */
+#define XSPI_RXD_OFFSET0x6c/* Data Receive Register */

 #define XSPI_SSR_OFFSET0x70/* 32-bit Slave Select Register 
*/

@@ -68,6 +69,7 @@
 #define XSPI_INTR_TX_UNDERRUN  0x08/* TxFIFO was underrun */
 #define XSPI_INTR_RX_FULL  0x10/* RxFIFO is full */
 #define XSPI_INTR_RX_OVERRUN   0x20/* RxFIFO was overrun */
+#define XSPI_INTR_TX_HALF_EMPTY0x40/* TxFIFO is half empty 
*/

 #define XIPIF_V123B_RESETR_OFFSET  0x40/* IPIF reset register */
 #define XIPIF_V123B_RESET_MASK 0x0a/* the value to write */
@@ -81,15 +83,61 @@ struct xilinx_spi {

u32 irq;

-   u32 speed_hz; /* SCK has a fixed frequency of speed_hz Hz */
-
u8 *rx_ptr; /* pointer in the Tx buffer */
const u8 *tx_ptr;   /* pointer in the Rx buffer */
int remaining_bytes;/* the number of bytes left to transfer */
+   u8 bits_per_word;
unsigned int (*read_fn) (void __iomem *);
void (*write_fn) (u32, void __iomem *);
+   void (*tx_fn) (struct xilinx_spi *);
+   void (*rx_fn) (struct xilinx_spi *);
 };

+static void xspi_tx8(struct xilinx_spi *xspi)
+{
+   xspi->write_fn(*xspi->tx_ptr, xspi->regs + XSPI_TXD_OFFSET);
+   xspi->tx_ptr++;
+}
+
+static void xspi_tx16(struct xilinx_spi *xspi)
+{
+   xspi->write_fn(*(u16 *)(xspi->tx_ptr), xspi->regs + XSPI_TXD_OFFSET);
+   xspi->tx_ptr += 2;
+}
+
+static void xspi_tx32(struct xilinx_spi *xspi)
+{
+   xspi->write_fn(*(u32 *)(xspi->tx_ptr), xspi->regs + XSPI_TXD_OFFSET);
+   xspi->tx_ptr += 4;
+}
+
+static void xspi_rx8(struct xilinx_spi *xspi)
+{
+   u32 data = xspi->read_fn(xspi->regs + XSPI_RXD_OFFSET);
+   if (xspi->rx_ptr) {
+   *xspi->rx_ptr = data & 0xff;
+   xspi->rx_ptr++;
+   }
+}
+
+static void xspi_rx16(struct xilinx_spi *xspi)
+{
+   u32 data = xspi->read_fn(xspi->regs + XSPI_RXD_OFFSET);
+   if (xspi->rx_ptr) {
+   *(u16 *)(xspi->rx_ptr) = data & 0x;
+   xspi->rx_ptr += 2;
+   }
+}
+
+static void xspi_rx32(struct xilinx_spi *xspi)
+{
+   u32 data = xspi->read_fn(xspi->regs + XSPI_RXD_OFFSET);
+   if (xspi->rx_ptr) {
+   *(u32 *)(xspi->rx_ptr) = data;
+   xspi->rx_ptr += 4;
+   }
+}
+
 static void xspi_init_hw(struct xilinx_spi *xspi)
 {
void __iomem *regs_bas

[PATCH v2 2/4] xilinx_spi: Switch to iomem functions and support little endian.

[Richard Röjfors]

This patch changes the out_(be)(8|16|32) and in_(be)(8|16|32) calls to 32 bits 
ioread/iowrite.

The read and write function are attached to the internal struct as callbacks, 
callback
is selected depending on endianess.

This will also build on platforms not supporting the in/out calls for instance 
x86.

Signed-off-by: Richard Röjfors 
---
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index e60b264..9667650 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -236,7 +236,7 @@ config SPI_TXX9

 config SPI_XILINX
tristate "Xilinx SPI controller"
-   depends on EXPERIMENTAL
+   depends on HAS_IOMEM && EXPERIMENTAL
select SPI_BITBANG
help
  This exposes the SPI controller IP from the Xilinx EDK.
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index 5761a4c..d0ca13a 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -27,7 +27,7 @@
 /* Register definitions as per "OPB Serial Peripheral Interface (SPI) (v1.00e)
  * Product Specification", DS464
  */
-#define XSPI_CR_OFFSET 0x62/* 16-bit Control Register */
+#define XSPI_CR_OFFSET 0x60/* 16-bit Control Register */

 #define XSPI_CR_ENABLE 0x02
 #define XSPI_CR_MASTER_MODE0x04
@@ -39,7 +39,7 @@
 #define XSPI_CR_MANUAL_SSELECT 0x80
 #define XSPI_CR_TRANS_INHIBIT  0x100

-#define XSPI_SR_OFFSET 0x67/* 8-bit Status Register */
+#define XSPI_SR_OFFSET 0x64/* 8-bit Status Register */

 #define XSPI_SR_RX_EMPTY_MASK  0x01/* Receive FIFO is empty */
 #define XSPI_SR_RX_FULL_MASK   0x02/* Receive FIFO is full */
@@ -47,8 +47,8 @@
 #define XSPI_SR_TX_FULL_MASK   0x08/* Transmit FIFO is full */
 #define XSPI_SR_MODE_FAULT_MASK0x10/* Mode fault error */

-#define XSPI_TXD_OFFSET0x6b/* 8-bit Data Transmit Register 
*/
-#define XSPI_RXD_OFFSET0x6f/* 8-bit Data Receive Register 
*/
+#define XSPI_TXD_OFFSET0x68/* 8-bit Data Transmit Register 
*/
+#define XSPI_RXD_OFFSET0x6c/* 8-bit Data Receive Register 
*/

 #define XSPI_SSR_OFFSET0x70/* 32-bit Slave Select Register 
*/

@@ -86,25 +86,29 @@ struct xilinx_spi {
u8 *rx_ptr; /* pointer in the Tx buffer */
const u8 *tx_ptr;   /* pointer in the Rx buffer */
int remaining_bytes;/* the number of bytes left to transfer */
+   unsigned int (*read_fn) (void __iomem *);
+   void (*write_fn) (u32, void __iomem *);
 };

-static void xspi_init_hw(void __iomem *regs_base)
+static void xspi_init_hw(struct xilinx_spi *xspi)
 {
+   void __iomem *regs_base = xspi->regs;
+
/* Reset the SPI device */
-   out_be32(regs_base + XIPIF_V123B_RESETR_OFFSET,
-XIPIF_V123B_RESET_MASK);
+   xspi->write_fn(XIPIF_V123B_RESET_MASK,
+   regs_base + XIPIF_V123B_RESETR_OFFSET);
/* Disable all the interrupts just in case */
-   out_be32(regs_base + XIPIF_V123B_IIER_OFFSET, 0);
+   xspi->write_fn(0, regs_base + XIPIF_V123B_IIER_OFFSET);
/* Enable the global IPIF interrupt */
-   out_be32(regs_base + XIPIF_V123B_DGIER_OFFSET,
-XIPIF_V123B_GINTR_ENABLE);
+   xspi->write_fn(XIPIF_V123B_GINTR_ENABLE,
+   regs_base + XIPIF_V123B_DGIER_OFFSET);
/* Deselect the slave on the SPI bus */
-   out_be32(regs_base + XSPI_SSR_OFFSET, 0x);
+   xspi->write_fn(0x, regs_base + XSPI_SSR_OFFSET);
/* Disable the transmitter, enable Manual Slave Select Assertion,
 * put SPI controller into master mode, and enable it */
-   out_be16(regs_base + XSPI_CR_OFFSET,
-XSPI_CR_TRANS_INHIBIT | XSPI_CR_MANUAL_SSELECT
-| XSPI_CR_MASTER_MODE | XSPI_CR_ENABLE);
+   xspi->write_fn(XSPI_CR_TRANS_INHIBIT | XSPI_CR_MANUAL_SSELECT |
+   XSPI_CR_MASTER_MODE | XSPI_CR_ENABLE,
+   regs_base + XSPI_CR_OFFSET);
 }

 static void xilinx_spi_chipselect(struct spi_device *spi, int is_on)
@@ -113,16 +117,16 @@ static void xilinx_spi_chipselect(struct spi_device *spi, 
int is_on)

if (is_on == BITBANG_CS_INACTIVE) {
/* Deselect the slave on the SPI bus */
-   out_be32(xspi->regs + XSPI_SSR_OFFSET, 0x);
+   xspi->write_fn(0x, xspi->regs + XSPI_SSR_OFFSET);
} else if (is_on == BITBANG_CS_ACTIVE) {
/* Set the SPI clock phase and polarity */
-   u16 cr = in_be16(xspi->regs + XSPI_CR_OFFSET)
+   u16 cr = xspi->read_fn(xspi->regs + XSPI_CR_OFFSET)
 & ~XSPI_CR_MODE_MASK;
if (spi->mode & SPI_CPHA)
cr |= XSPI_CR_CPHA;
if (spi->mode & SPI_CPOL)
cr |= XSPI_CR_CPOL;
-   out_be16(xspi->regs + XSPI_CR_OFFSET, cr);
+   xspi->write_fn(cr, xspi->regs + XSPI_CR_OFFSET);

  

[PATCH v2 1/4] xilinx_spi: Split into of driver and generic part.

[Richard Röjfors]

This patch splits the xilinx_spi driver into a generic part and a
OF driver part.

The reason for this is to later add in a platform driver as well.

Signed-off-by: Richard Röjfors 
---
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 4b6f7cb..e60b264 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -236,7 +236,7 @@ config SPI_TXX9

 config SPI_XILINX
tristate "Xilinx SPI controller"
-   depends on (XILINX_VIRTEX || MICROBLAZE) && EXPERIMENTAL
+   depends on EXPERIMENTAL
select SPI_BITBANG
help
  This exposes the SPI controller IP from the Xilinx EDK.
@@ -244,6 +244,12 @@ config SPI_XILINX
  See the "OPB Serial Peripheral Interface (SPI) (v1.00e)"
  Product Specification document (DS464) for hardware details.

+config SPI_XILINX_OF
+   tristate "Xilinx SPI controller OF device"
+   depends on SPI_XILINX && (XILINX_VIRTEX || MICROBLAZE)
+   help
+ This is the OF driver for the SPI controller IP from the Xilinx EDK.
+
 #
 # Add new SPI master controllers in alphabetical order above this line
 #
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 21a1182..97dee8f 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_SPI_S3C24XX_GPIO)+= 
spi_s3c24xx_gpio.o
 obj-$(CONFIG_SPI_S3C24XX)  += spi_s3c24xx.o
 obj-$(CONFIG_SPI_TXX9) += spi_txx9.o
 obj-$(CONFIG_SPI_XILINX)   += xilinx_spi.o
+obj-$(CONFIG_SPI_XILINX_OF)+= xilinx_spi_of.o
 obj-$(CONFIG_SPI_SH_SCI)   += spi_sh_sci.o
 obj-$(CONFIG_SPI_STMP3XXX) += spi_stmp.o
 #  ... add above this line ...
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index 46b8c5c..5761a4c 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -14,16 +14,14 @@
 #include 
 #include 
 #include 
-#include 
-
-#include 
-#include 
-#include 

 #include 
 #include 
 #include 

+#include "xilinx_spi.h"
+#include 
+
 #define XILINX_SPI_NAME "xilinx_spi"

 /* Register definitions as per "OPB Serial Peripheral Interface (SPI) (v1.00e)
@@ -78,7 +76,7 @@ struct xilinx_spi {
/* bitbang has to be first */
struct spi_bitbang bitbang;
struct completion done;
-
+   struct resource mem; /* phys mem */
void __iomem*regs;  /* virt. address of the control registers */

u32 irq;
@@ -283,40 +281,22 @@ static irqreturn_t xilinx_spi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
 }

-static int __init xilinx_spi_of_probe(struct of_device *ofdev,
-   const struct of_device_id *match)
+struct spi_master *xilinx_spi_init(struct device *dev, struct resource *mem,
+   u32 irq, s16 bus_num)
 {
struct spi_master *master;
struct xilinx_spi *xspi;
-   struct resource r_irq_struct;
-   struct resource r_mem_struct;
-
-   struct resource *r_irq = &r_irq_struct;
-   struct resource *r_mem = &r_mem_struct;
-   int rc = 0;
-   const u32 *prop;
-   int len;
-
-   /* Get resources(memory, IRQ) associated with the device */
-   master = spi_alloc_master(&ofdev->dev, sizeof(struct xilinx_spi));
+   struct xspi_platform_data *pdata = dev->platform_data;
+   int ret;

-   if (master == NULL) {
-   return -ENOMEM;
-   }
-
-   dev_set_drvdata(&ofdev->dev, master);
-
-   rc = of_address_to_resource(ofdev->node, 0, r_mem);
-   if (rc) {
-   dev_warn(&ofdev->dev, "invalid address\n");
-   goto put_master;
+   if (!pdata) {
+   dev_err(dev, "No platform data attached\n");
+   return NULL;
}

-   rc = of_irq_to_resource(ofdev->node, 0, r_irq);
-   if (rc == NO_IRQ) {
-   dev_warn(&ofdev->dev, "no IRQ found\n");
-   goto put_master;
-   }
+   master = spi_alloc_master(dev, sizeof(struct xilinx_spi));
+   if (!master)
+   return NULL;

/* the spi->mode bits understood by this driver: */
master->mode_bits = SPI_CPOL | SPI_CPHA;
@@ -329,128 +309,67 @@ static int __init xilinx_spi_of_probe(struct of_device 
*ofdev,
xspi->bitbang.master->setup = xilinx_spi_setup;
init_completion(&xspi->done);

-   xspi->irq = r_irq->start;
-
-   if (!request_mem_region(r_mem->start,
-   r_mem->end - r_mem->start + 1, XILINX_SPI_NAME)) {
-   rc = -ENXIO;
-   dev_warn(&ofdev->dev, "memory request failure\n");
+   if (!request_mem_region(mem->start, resource_size(mem),
+   XILINX_SPI_NAME))
goto put_master;
-   }

-   xspi->regs = ioremap(r_mem->start, r_mem->end - r_mem->start + 1);
+   xspi->regs = ioremap(mem->start, resource_size(mem));
if (xspi->regs == NULL) {
-   rc = -ENOMEM;
-   dev_warn(&ofdev->dev, "ioremap fai

[PATCH v2 0/4] xilinx_spi: Split into platform and of driver, support new IP, platform independence.

[Richard Röjfors]

Hi,

To follow is a series of patches against the xilinx_spi driver.

The patchset is against 2.6.32-rc6

The patchset addresses several problems in the current driver:
* It's PPC only (OF and uses PPC specific memory operations)
* Only supporting big endian writes
* Supports only 8bit SPI, support for DS570 (also 16 or 32 bit) is added.
* A platform driver is introduced for non OF capable architectures.

These patches were posted as one big patch up to 4 iterations, not splitted 
into 4.

This version, 2, is updated after review from Grant Likely and John Linn

--Richard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/5] powerpc/86xx: Enable NVRAM on GE Fanuc's SBC610

[Kumar Gala]

On Jul 2, 2009, at 11:12 AM, Martyn Welch wrote:


This patch enables the NVRAM found on the GE Fanuc SBC610

Signed-off-by: Martyn Welch 
---

arch/powerpc/boot/dts/gef_sbc610.dts   |6 ++
arch/powerpc/configs/86xx/gef_sbc610_defconfig |4 ++--
arch/powerpc/platforms/86xx/Kconfig|1 +
arch/powerpc/platforms/86xx/gef_sbc610.c   |5 +
4 files changed, 14 insertions(+), 2 deletions(-)


applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 4/5] powerpc/86xx: Support for NVRAM on GE Fanuc's SBC310

[Kumar Gala]

On Jul 2, 2009, at 11:12 AM, Martyn Welch wrote:


Add support for NVRAM on GE Fanuc's SBC310.

Signed-off-by: Martyn Welch 
---

arch/powerpc/boot/dts/gef_sbc310.dts   |6 ++
arch/powerpc/configs/86xx/gef_sbc310_defconfig |4 ++--
arch/powerpc/platforms/86xx/Kconfig|1 +
arch/powerpc/platforms/86xx/gef_sbc310.c   |5 +
4 files changed, 14 insertions(+), 2 deletions(-)


applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 5/5] powerpc/86xx: Support for NVRAM on GE Fanuc's PPC9A

[Kumar Gala]

On Jul 2, 2009, at 11:12 AM, Martyn Welch wrote:


Add support for NVRAM on GE Fanuc's PPC9A.

Signed-off-by: Martyn Welch 
---

arch/powerpc/boot/dts/gef_ppc9a.dts   |6 ++
arch/powerpc/configs/86xx/gef_ppc9a_defconfig |4 ++--
arch/powerpc/platforms/86xx/Kconfig   |1 +
arch/powerpc/platforms/86xx/gef_ppc9a.c   |5 +
4 files changed, 14 insertions(+), 2 deletions(-)


applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

[Mark Brown]

On Wed, Nov 11, 2009 at 06:13:25PM -0500, Jon Smirl wrote:

> I don't think it is that much more work for ALSA to provide an
> accessible field indicating the end of valid data. It's already
> tracking appl_ptr. Appl_ptr just needs to be translated into a
> physical DMA buffer address and we've been making mistakes doing that
> translation.

I'm sure if you provide reasonable patches they'll get applied; it
doesn't seem likely that anyone else will work on this.

> On Wed, Nov 11, 2009 at 4:57 PM, Grant Likely  
> wrote

> > But it still wouldn't help a bit when the same latency occurs in the
> > middle of playback.

> The deterministic solution of tracking the end of valid data ensures
> that under run will be silent instead of playing invalid data.

In the middle of playback a sudden silence period is very noticable -
applications that expect data loss generally have some means to try to
cover it up since sudden silence is so noticable to the human ear.  Mid
playback there's a bit more chance that random data from earlier in the
playback will be acceptable, and if the application has actually updated
the data but not got round to telling the driver about that yet then
even better.

I think you're getting too focused on the fact that there is a race
condition here since the consequences of race conditions are usually so
severe.  There's always going to be some hardware for which there's a
degree of racyness (free running hardware has its own set of issues
here) so the system design takes this into account.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [powerpc] Next tree Nov 2 : kernel BUG at mm/mmap.c:2135!

[Sachin Sant]

David Gibson wrote:

On Wed, Nov 04, 2009 at 06:08:44PM +0530, Sachin Sant wrote:
  

Sachin Sant wrote:


Today's next tree failed to boot on a POWER 6 box with :

[ cut here ]
kernel BUG at mm/mmap.c:2135!
Oops: Exception in kernel mode, sig: 5 [#2]
SMP NR_CPUS=1024 NUMA pSeries
  

Problem exists with today's next as well.

Likely cause for this problem seems to the following commit.
If i revert this patch the machine boots fine.

commit a0668cdc154e54bf0c85182e0535eea237d53146
powerpc/mm: Cleanup management of kmem_caches for pagetables



Ugh.  Ok, it's not at all obvious how my patch could cause this bug.
Can you send your .config?

  
Still present in today's next. 


Thanks
-Sachin


Modules linked in: ibmvscsic scsi_transport_srp scsi_tgt scsi_mod
NIP: c014e30c LR: c014e2f8 CTR: c014db88
REGS: c000db703620 TRAP: 0700   Tainted: G  D
(2.6.32-rc5-autotest-next-20091102)
MSR: 80029032   CR: 24022442  XER: 200c
TASK = c000db7f6fe0[76] 'init' THREAD: c000db70 CPU: 1
GPR00: 0001 c000db7038a0 c0b19900

GPR04: c000db406a40 000c c000fe10c370
c0bb2800
GPR08: db40  c000dfdc0e00
000c
GPR12: 44022442 c0bb2800 

GPR16: 0843 003c c000db703ea0
c000db569108
GPR20: c000db568908  c000db703d60

GPR24: 0001 00040100 c000fe503580
c000db1ac180
GPR28:  c0f812d0 c0a84f00

NIP [c014e30c] .exit_mmap+0x190/0x1b8
LR [c014e2f8] .exit_mmap+0x17c/0x1b8
Call Trace:
[c000db7038a0] [c014e2f8] .exit_mmap+0x17c/0x1b8 (unreliable)
[c000db703950] [c00916cc] .mmput+0x54/0x164
[c000db7039e0] [c00968d8] .exit_mm+0x17c/0x1a0
[c000db703a90] [c0098cb8] .do_exit+0x248/0x784
[c000db703b70] [c00992a8] .do_group_exit+0xb4/0xe8
[c000db703c00] [c00aca2c] .get_signal_to_deliver+0x3ec/0x478
[c000db703cf0] [c00134ac] .do_signal+0x6c/0x31c
[c000db703e30] [c0008b7c] do_work+0x24/0x28
Instruction dump:
7c8407b4 387d0018 4800ab11 6000 939d0008 7fe3fb78 4bfffdbd 7c7f1b79
4082fff4 e81b00e8 3120 7c090110 <0b00> 382100b0 e8010010 eb61ffd8
---[ end trace ec052ac77a8e7cb4 ]---
Fixing recursive fault but reboot is needed!

mm/mmap.c:2135 corresponds to :

BUG_ON(mm->nr_ptes > (FIRST_USER_ADDRESS+PMD_SIZE-1)>>PMD_SHIFT);

  


  



--

-
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
-

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: linux-next: rr tree build failure

[Stephen Rothwell]

Hi Ben,

On Thu, 12 Nov 2009 20:02:00 +1100 Benjamin Herrenschmidt 
 wrote:
>
> Thanks. Our EXPORTs are bogus (probably leftovers) it seems. I'll dbl
> check tomorrow but that looks like a patch I should pickup in powerpc
> -next anyways.

That was the idea, thanks.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/


pgp6FZSnXRDWw.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/8] 8xx: Misc fixes for buggy insn

[Joakim Tjernlund]

Scott Wood  wrote on 11/11/2009 16:26:53:
>
> On Wed, Nov 11, 2009 at 01:06:10AM +0100, Joakim Tjernlund wrote:
> > Scott Wood  wrote on 11/11/2009 00:21:18:
> > > Where would you put the dcbi?  How do you regain control after that
> > > cache line has been refilled, but before code flows back to the bad 
> > > branch?
> >
> > The dcbi would replace the current CPU15 tlbie.
>
> But that only works if you take an ITLB miss at the right time.

Yeah, I misread the CPU15 errata so my ideas will not work.

Anyhow, will you send a patch that make TLB pinning mandatory?
After that my series can go in.

Jocke

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

MTD subsystem Initialization

[thirumalai.p]

Hi Ben,
  When i try to boot my MPC8640D based target on 2.6.30 kernel. My
target is having 1GB of RAM and 256 MB of Flash memory. I am passing the
partition information using OF Tree. During MTD subsystem initialization,
the following error message is displayed. "vmap allocation for size
268435456 failed". i found that this is due to ioremap failure which is
happening during the time of MTD initializtion.

Even thoogh HIGH_MEM support was enabled on the kernel, this is failing. 

Any configurations that need to be modified for this. 

I am using ELDK-4.0 for compilation.

Thank you
T.

 CAUTION - Disclaimer *This email may contain 
confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention, distribution 
or disclosure by others is strictly prohibited. If you are not the intended 
recipient (or authorized to receive for the recipient), please contact the 
sender by reply email and delete all copies of this message. Also, email is 
susceptible to data corruption, interception, tampering, unauthorized amendment 
and viruses. We only send and receive emails on the basis that we are not 
liable for any such corruption, interception, tampering, amendment or viruses 
or any consequence thereof. 
*** End of Disclaimer ***DataPatterns ITS Group**

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Disable Caching for mmap() address

[Benjamin Herrenschmidt]

On Mon, 2009-11-09 at 16:21 -0700, Jonathan Haws wrote:
> All,
> 
> I would like to disable caching for an address that was returned from a call 
> to mmap().  I am using this address for DMA operations in user space and want 
> to make sure that the data cache is turned off for that buffer.
> 
> The way this works is the driver simply takes an address I provide and begins 
> a DMA operation to that location in RAM (I have ensured that this is a 
> physical address I am passing already).  When the DMA is complete, an 
> interrupt fires and the ISR gives a semaphore that the user space application 
> is pending on (RT_SEM from Xenomai).  I have tried simply calling a cache 
> invalidate routine in the ISR before I give the semaphore, but the kernel 
> crashes when I try to call that routine - my guess it because the kernel does 
> not have direct access to that location in memory (only my application does, 
> according to the MMU).
> 
> Anyway, all I want to do is make sure that the buffer is never stored in the 
> cache and that I always fetch it from RAM.  How can I specify that using 
> mmap() on the /dev/mem device, or is there a better way to accomplish this?

There is no "proper" way to do this, in large part because it's not
always legal to map memory non-cached for various reasons I don't
have time to explain right now...

You may be able to get it working though but using a specific driver
with an mmap function that tweaks the attributes or using mmap
of /dev/mem after opening it with O_SYNC (off the top of my mind)

But it's a bit fishy as the kernel has a cacheable mapping of most
of memory and so you may end up with cache aliases...

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: linux-next: rr tree build failure

[Benjamin Herrenschmidt]

On Thu, 2009-11-12 at 19:03 +1100, Stephen Rothwell wrote:
> Hi Rusty,
> 
> Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
> 
> .tmp_exports-asm.o: In function `__ksymtab_pci_alloc_consistent':
> (__ksymtab_sorted+0x2a30): undefined reference to `pci_alloc_consistent'
> .tmp_exports-asm.o: In function `__ksymtab_pci_free_consistent':
> (__ksymtab_sorted+0x2b70): undefined reference to `pci_free_consistent'
> 
> Caused by the powerpc architecture EXPORTing static inlines (for 32 bit
> builds) interacting with changes in the rr tree.
> 
> I have applied this patch for today:

Thanks. Our EXPORTs are bogus (probably leftovers) it seems. I'll dbl
check tomorrow but that looks like a patch I should pickup in powerpc
-next anyways.

Cheers,
Ben.

> From: Stephen Rothwell 
> Date: Thu, 12 Nov 2009 18:54:13 +1100
> Subject: [PATCH] powerpc: do not export pci_alloc/free_consistent
> 
> Since they are static inline functions.
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/powerpc/kernel/ppc_ksyms.c |2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
> index 07115d6..4254514 100644
> --- a/arch/powerpc/kernel/ppc_ksyms.c
> +++ b/arch/powerpc/kernel/ppc_ksyms.c
> @@ -96,8 +96,6 @@ EXPORT_SYMBOL(copy_4K_page);
>  EXPORT_SYMBOL(isa_io_base);
>  EXPORT_SYMBOL(isa_mem_base);
>  EXPORT_SYMBOL(pci_dram_offset);
> -EXPORT_SYMBOL(pci_alloc_consistent);
> -EXPORT_SYMBOL(pci_free_consistent);
>  #endif /* CONFIG_PCI */
>  
>  EXPORT_SYMBOL(start_thread);
> -- 
> 1.6.5.2
> 


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

High traffic from eth to cf-ata blocks other eth traffic

[Jan Husak]

I have ppc system with compactflash card connected by ata. On this system is
running process using raw socket to send and receive cyclic data each 4ms.
When I start another iptraffic - sshftp - to write to compact flash, after
certain time the IRQ-135 (mpc52xx_ata) of ata driver locks task irqs from
network card for cca 300ms. And my cyclic data transfer is broken. Any idea
how to solve this problem?

Thanks a lot for hint. Jan

Output from sched_switch trace here:

pniodhld-2516 [000] 1305.162746: 2516: 33:T ==> [000] 6: 33:R sirq-net-rx/0

sirq-net-rx/0-6 [000] 1305.162755: 6: 33:R + [000] 2516: 33:T pniodhld

sirq-net-rx/0-6 [000] 1305.162766: 6: 49:R ==> [000] 2516: 33:S pniodhld

pniodhld-2516 [000] 1305.162835: 2516: 33:D ==> [000] 6: 49:R sirq-net-rx/0

sirq-net-rx/0-6 [000] 1305.162923: 6: 49:D ==> [000] 99:115:R ata/0

ata/0-99 [000] 1305.163050: 99:115:D ==> [000] 2409:120:R sftp-server

sftp-server-2409 [000] 1305.163100: 2409:120:R + [000] 710: 49:D IRQ-135

sftp-server-2409 [000] 1305.163119: 2409:120:R ==> [000] 710: 49:R IRQ-135

IRQ-135-710 [000] 1305.163227: 710: 49:D + [000] 710: 49:D IRQ-135

IRQ-135-710 [000] 1305.163324: 710: 49:D ==> [000] 2409:120:R sftp-server

sftp-server-2409 [000] 1305.163344: 2409:120:R + [000] 710: 49:D IRQ-135

sftp-server-2409 [000] 1305.163355: 2409:120:R ==> [000] 710: 49:R IRQ-135

IRQ-135-710 [000] 1305.163448: 710: 49:D + [000] 710: 49:D IRQ-135

IRQ-135-710 [000] 1305.163543: 710: 49:D ==> [000] 2409:120:R sftp-server

sftp-server-2409 [000] 1305.163562: 2409:120:R + [000] 710: 49:D IRQ-135

sftp-server-2409 [000] 1305.163574: 2409:120:R ==> [000] 710: 49:R IRQ-135

IRQ-135-710 [000] 1305.163634: 710: 49:R + [000] 4: 49:D sirq-timer/0

IRQ-135-710 [000] 1305.163768: 710: 49:D + [000] 710: 49:D IRQ-135

IRQ-135-710 [000] 1305.163870: 710: 49:D ==> [000] 4: 49:R sirq-timer/0

sirq-timer/0-4 [000] 1305.163894: 4: 49:R + [000] 710: 49:D IRQ-135

sirq-timer/0-4 [000] 1305.163918: 4: 49:D ==> [000] 710: 49:R IRQ-135 

and another 500 similar lines till new net_rx irq task is scheduled
-- 
View this message in context: 
http://old.nabble.com/High-traffic-from-eth-to-cf-ata-blocks-other-eth-traffic-tp26315068p26315068.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

linux-next: rr tree build failure

[Stephen Rothwell]

Hi Rusty,

Today's linux-next build (powerpc ppc44x_defconfig) failed like this:

.tmp_exports-asm.o: In function `__ksymtab_pci_alloc_consistent':
(__ksymtab_sorted+0x2a30): undefined reference to `pci_alloc_consistent'
.tmp_exports-asm.o: In function `__ksymtab_pci_free_consistent':
(__ksymtab_sorted+0x2b70): undefined reference to `pci_free_consistent'

Caused by the powerpc architecture EXPORTing static inlines (for 32 bit
builds) interacting with changes in the rr tree.

I have applied this patch for today:

From: Stephen Rothwell 
Date: Thu, 12 Nov 2009 18:54:13 +1100
Subject: [PATCH] powerpc: do not export pci_alloc/free_consistent

Since they are static inline functions.

Signed-off-by: Stephen Rothwell 
---
 arch/powerpc/kernel/ppc_ksyms.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index 07115d6..4254514 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -96,8 +96,6 @@ EXPORT_SYMBOL(copy_4K_page);
 EXPORT_SYMBOL(isa_io_base);
 EXPORT_SYMBOL(isa_mem_base);
 EXPORT_SYMBOL(pci_dram_offset);
-EXPORT_SYMBOL(pci_alloc_consistent);
-EXPORT_SYMBOL(pci_free_consistent);
 #endif /* CONFIG_PCI */
 
 EXPORT_SYMBOL(start_thread);
-- 
1.6.5.2

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev