[PATCH] irqbalance, powerpc: add IRQs without settable SMP affinity to banned list

2010-09-21 Thread Michael Neuling 
On pseries powerpc, IPIs are registered with an IRQ number so
/proc/interrupts looks like this on a 2 core/2 thread machine:

   CPU0   CPU1   CPU2   CPU3
 16:316428232905141138794 983121   XICS Level   
 IPI
 18:2605674  0 304994  0   XICS Level   
 lan0
 30: 400057  0 169209  0   XICS Level   
 ibmvscsi
LOC: 133734  77250 106425  91951   Local timer interrupts
SPU:  0  0  0  0   Spurious interrupts
CNT:  0  0  0  0   Performance monitoring 
interrupts
MCE:  0  0  0  0   Machine check exceptions

Unfortunately this means irqbalance attempts to set the affinity of IPIs
which is not possible.  So in the above case, when irqbalance is in
performance mode due to heavy IPI, lan0 and ibmvscsi activity, it
sometimes attempts to put the IPIs on one core (CPU0&1) and lan0 and
ibmvscsi on the other core (CPU2&3).  This is suboptimal as we want lan0
and ibmvscsi to be on separate cores and IPIs to be ignored.

When irqblance attempts writes to the IPI smp_affinity (ie.
/proc/irq/16/smp_affinity in the above example) it fails but irqbalance
ignores currently ignores this.

This patch catches these write fails and in this case adds that IRQ
number to the banned IRQ list.  This will catch the above IPI case and
any other IRQ where the SMP affinity can't be set.

Tested on POWER6, POWER7 and x86.

Signed-off-by: Michael Neuling 

Index: irqbalance/irqlist.c
===
--- irqbalance.orig/irqlist.c
+++ irqbalance/irqlist.c
@@ -67,7 +67,7 @@
DIR *dir;
struct dirent *entry;
char *c, *c2;
-   int nr , count = 0;
+   int nr , count = 0, can_set = 1;
char buf[PATH_MAX];
sprintf(buf, "/proc/irq/%i", number);
dir = opendir(buf);
@@ -80,7 +80,7 @@
size_t size = 0;
FILE *file;
sprintf(buf, "/proc/irq/%i/smp_affinity", number);
-   file = fopen(buf, "r");
+   file = fopen(buf, "r+");
if (!file)
continue;
if (getline(&line, &size, file)==0) {
@@ -89,7 +89,14 @@
continue;
}
cpumask_parse_user(line, strlen(line), irq->mask);
-   fclose(file);
+   /*
+* Check that we can write the affinity, if
+* not take it out of the list.
+*/
+   if (fwrite(line, strlen(line) - 1, 1, file) == 0)
+   can_set = 0;
+   if (fclose(file))
+   can_set = 0;
free(line);
} else if (strcmp(entry->d_name,"allowed_affinity")==0) {
char *line = NULL;
@@ -122,7 +129,7 @@
count++;
 
/* if there is no choice in the allowed mask, don't bother to balance */
-   if (count<2)
+   if ((count<2) || (can_set == 0))
 irq->balance_level = BALANCE_NONE;

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

Re: [U-Boot] cuImage and multi image?

2010-09-21 Thread Shawn Jin 
>> > > A follow up question. With this method, the total image size
>> > > (uncompressed) is limited to the 4MB (the link address of
>> the boot
>> > > wrapper)?
>> >
>> > No.
>>
>> Yes, unless you change the link address, or provide a
>> vmlinux_alloc callback (which currently only happens on true
>> OF, not cuImage).
>>
>> Unless you're talking about the "(uncompressed)"?  The limit
>> applies to the uncompressed boot image -- anything that the
>> bootwrapper itself is decompressing.  It does not apply to
>> any further uncompression of the ramdisk itself.
>>
>
> He should point the latter, "the total image size", including ramdisk.
> But the link address should be limited for the boot Image, not for the
> attached ramdisk.

Thanks for the clarification. Scott, so what are the things that the
bootwrapper is decompressing? The kernel for sure. And anything else?
I understand that the ramdisk image will be decompressed later when
trying to boot it.

I have a large ramdisk image. The size of the image itself (i.e. the
*.gz) is about 4MB. When the ramdisk was being decompressed in the
later stage. It had the following errors. It seems to me that the
ramdisk image somehow was corrupted. Did the script wrapper mess up
the image? Is there any known bug in the wrapper? My kernel is 2.6.33.
BTW the ramdisk image can be mounted properly if it's separated from
the kernel image.

RAMDISK: gzip image found at block 0
uncompression error
VFS: Mounted root (ext2 filesystem) readonly on device 1:0.
Freeing unused kernel memory: 104k init
EXT2-fs (ram0): error: ext2_check_page: bad entry in directory #336: :
rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
name_len=0
EXT2-fs (ram0): error: remounting filesystem read-only
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.
Call Trace:
[c7821f30] [c0006cd8] show_stack+0x40/0x168 (unreliable)
[c7821f70] [c001cefc] panic+0x8c/0x178
[c7821fc0] [c00026d4] init_post+0xe4/0xf4
[c7821fd0] [c01ee224] kernel_init+0x108/0x130
[c7821ff0] [c000dcc0] kernel_thread+0x4c/0x68
Rebooting in 180 seconds..

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

Re: [PATCH] fsldma: add support to 36-bit physical address

2010-09-21 Thread Kumar Gala 

On Sep 21, 2010, at 5:34 PM, Timur Tabi wrote:

> On Tue, Sep 21, 2010 at 5:17 PM, Scott Wood  wrote:
> 
>> It needs to be the actual device that is performing the DMA -- the
>> platform may need to do things such as IOMMU manipulation where
>> knowing the device matters.
> 
> Ok, this all makes sense.  So it appears that the patch is valid, at
> least in theory.  I would like to see some testing of it, but I
> realize that may be too difficult.  There's no easy way to force an
> allocation above 4GB.

I think the patch is pretty safe w/o testing.  However I agree we need a better 
solution to testing 36-bit addressing.

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

Re: [PATCH 1/2 v3]Update broken web addresses.

2010-09-21 Thread Justin P. Mattock 

On 09/21/2010 08:25 PM, Finn Thain wrote:


On Tue, 21 Sep 2010, Justin P. Mattock wrote:


Below is an update from the original, with changes to the broken web
addresses and removal of archive.org and moved to a seperate patch for
you guys to decide if you want to use this and/or just leave the old url
in and leave it at that..
Please dont apply this to anything just comments and fixes for now,


You can use [RFC] in the Subject line instead of [PATCH] to indicate this.



alright..




diff --git a/arch/m68k/mac/macboing.c b/arch/m68k/mac/macboing.c
index 8f06408..234d9ee 100644
--- a/arch/m68k/mac/macboing.c
+++ b/arch/m68k/mac/macboing.c
@@ -114,7 +114,8 @@ static void mac_init_asc( void )
 *   16-bit I/O functionality.  The PowerBook 500 
series computers
 *   support 16-bit stereo output, but only mono input."
 *
-*   
http://til.info.apple.com/techinfo.nsf/artnum/n16405
+*   Article number 16405:
+*   http://support.apple.com/kb/TA32601
 *
 * --David Kilzer
 */


"TIL article number 16405" would allow people to find the document by
number...



so putting this "TIL article number 16405" is correct instead of Article 
number 16405:





diff --git a/arch/m68k/q40/README b/arch/m68k/q40/README
index 6bdbf48..92806c0 100644
--- a/arch/m68k/q40/README
+++ b/arch/m68k/q40/README
@@ -3,7 +3,7 @@ Linux for the Q40

  You may try http://www.geocities.com/SiliconValley/Bay/2602/ for
  some up to date information. Booter and other tools will be also
-available from this place or ftp.uni-erlangen.de/linux/680x0/q40/
+available from this place or http://www.linux-m68k.org/mail.html
  and mirrors.

  Hints to documentation usually refer to the linux source tree in


No. We already discussed this change. Please refer back to my review of
the first version of the patch. You got it right in the second version
(that I also reviewed), but now you've gone back to the first version...

Finn



pretty bad.. I don't know what happened there..


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

Re: [PATCH 1/2 v3]Update broken web addresses.

2010-09-21 Thread Finn Thain 

On Tue, 21 Sep 2010, Justin P. Mattock wrote:

> Below is an update from the original, with changes to the broken web 
> addresses and removal of archive.org and moved to a seperate patch for 
> you guys to decide if you want to use this and/or just leave the old url 
> in and leave it at that..
> Please dont apply this to anything just comments and fixes for now,

You can use [RFC] in the Subject line instead of [PATCH] to indicate this.


> diff --git a/arch/m68k/mac/macboing.c b/arch/m68k/mac/macboing.c
> index 8f06408..234d9ee 100644
> --- a/arch/m68k/mac/macboing.c
> +++ b/arch/m68k/mac/macboing.c
> @@ -114,7 +114,8 @@ static void mac_init_asc( void )
>*   16-bit I/O functionality.  The PowerBook 500 
> series computers
>*   support 16-bit stereo output, but only mono input."
>*
> -  *   
> http://til.info.apple.com/techinfo.nsf/artnum/n16405
> +  *   Article number 16405:
> +  *   http://support.apple.com/kb/TA32601 
>*
>* --David Kilzer
>*/

"TIL article number 16405" would allow people to find the document by 
number...


> diff --git a/arch/m68k/q40/README b/arch/m68k/q40/README
> index 6bdbf48..92806c0 100644
> --- a/arch/m68k/q40/README
> +++ b/arch/m68k/q40/README
> @@ -3,7 +3,7 @@ Linux for the Q40
>  
>  You may try http://www.geocities.com/SiliconValley/Bay/2602/ for
>  some up to date information. Booter and other tools will be also
> -available from this place or ftp.uni-erlangen.de/linux/680x0/q40/
> +available from this place or http://www.linux-m68k.org/mail.html 
>  and mirrors.
>  
>  Hints to documentation usually refer to the linux source tree in

No. We already discussed this change. Please refer back to my review of 
the first version of the patch. You got it right in the second version 
(that I also reviewed), but now you've gone back to the first version...

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

[PATCH 2/2 v3]Update broken web addresses archive dot org only.

2010-09-21 Thread Justin P. Mattock 
Below is a patch consisting of only the broken web addresses using 
webarchive.org. 
Please have a look and let me know if you want to go on with using these and/or 
just 
leave the old links in there.
Note: the address needs to have an %2A added to it due to webarchive.org
using a "*" for it's searching capabilities.
Please dont apply this to anything, just comments and changes for now, then
at the right time I'll bunch everything into one patch.

Signed-off-by: Justin P. Mattock 
Cc: Finn Thain 

---
 arch/arm/mach-footbridge/Kconfig  |2 +-
 arch/arm/mach-omap1/Kconfig   |4 ++--
 arch/arm/mach-pxa/idp.c   |4 ++--
 arch/arm/mach-pxa/include/mach/idp.h  |4 ++--
 arch/arm/mach-sa1100/Kconfig  |2 +-
 arch/h8300/Kconfig.cpu|2 +-
 arch/h8300/README |3 ++-
 arch/ia64/include/asm/machvec_sn2.h   |2 +-
 arch/ia64/include/asm/numa.h  |2 +-
 arch/ia64/kernel/acpi.c   |2 +-
 arch/ia64/lib/idiv32.S|2 +-
 arch/ia64/lib/idiv64.S|2 +-
 arch/ia64/sn/kernel/setup.c   |2 +-
 arch/ia64/sn/kernel/sn2/timer_interrupt.c |2 +-
 arch/m68k/Kconfig |2 +-
 arch/m68k/mac/via.c   |5 ++---
 arch/m68k/q40/README  |4 ++--
 arch/sh/cchips/Kconfig|2 +-
 arch/um/os-Linux/start_up.c   |2 +-
 arch/x86/kernel/cpu/amd.c |2 +-
 arch/x86/kernel/cpu/cpufreq/powernow-k8.c |2 +-
 arch/x86/math-emu/README  |2 +-
 22 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/arch/arm/mach-footbridge/Kconfig b/arch/arm/mach-footbridge/Kconfig
index bdd2579..fa30857 100644
--- a/arch/arm/mach-footbridge/Kconfig
+++ b/arch/arm/mach-footbridge/Kconfig
@@ -29,7 +29,7 @@ config ARCH_PERSONAL_SERVER
  There are no product plans beyond the current research
  prototypes at this time.  Information is available at:
 
- 
+ 

 
  If you have any questions or comments about the  Compaq Personal
  Server, send e-mail to .
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index 5f64963..e3cf9f4 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -118,8 +118,8 @@ config MACH_OMAP_PALMZ71
depends on ARCH_OMAP1 && ARCH_OMAP15XX
help
 Support for the Palm Zire71 PDA. To boot the kernel,
-you'll need a PalmOS compatible bootloader; check out
-http://hackndev.com/palm/z71 for more information.
+you'll need a PalmOS compatible bootloader; For information
+http://web.archive.org/web/%2A/http://old.hackndev.com/palm/z71 
 Say Y here if you have such a PDA, say N otherwise.
 
 config MACH_OMAP_PALMTT
diff --git a/arch/arm/mach-pxa/idp.c b/arch/arm/mach-pxa/idp.c
index bc78c4d..b521a64 100644
--- a/arch/arm/mach-pxa/idp.c
+++ b/arch/arm/mach-pxa/idp.c
@@ -11,8 +11,8 @@
  *  Initial code
  *
  *  2005-02-15: Cliff Brake 
- *  
- *  Updated for 2.6 kernel
+ *  
+ *  Updated for 2.6 kernel
  *
  */
 
diff --git a/arch/arm/mach-pxa/include/mach/idp.h 
b/arch/arm/mach-pxa/include/mach/idp.h
index 5eff96f..d1a3d5d 100644
--- a/arch/arm/mach-pxa/include/mach/idp.h
+++ b/arch/arm/mach-pxa/include/mach/idp.h
@@ -11,8 +11,8 @@
  * Initial code
  *
  * 2005-02-15: Cliff Brake 
- *  
- * Changes for 2.6 kernel.
+ *  
+ *  Changes for 2.6 kernel.
  */
 
 
diff --git a/arch/arm/mach-sa1100/Kconfig b/arch/arm/mach-sa1100/Kconfig
index 5da8c35..11bc60f 100644
--- a/arch/arm/mach-sa1100/Kconfig
+++ b/arch/arm/mach-sa1100/Kconfig
@@ -108,7 +108,7 @@ config SA1100_HACKKIT
select CPU_FREQ_SA1100
help
  Say Y here to support the HackKit Core CPU Board
- ;
+ ;
 
 config SA1100_LART
bool "LART"
diff --git a/arch/h8300/Kconfig.cpu b/arch/h8300/Kconfig.cpu
index 8de966a..49d55ba 100644
--- a/arch/h8300/Kconfig.cpu
+++ b/arch/h8300/Kconfig.cpu
@@ -20,7 +20,7 @@ config H8300H_AKI3068NET
  
  AE-3068/69 Evaluation Board Support
  More Information.
- 
+

[PATCH 1/2 v3]Update broken web addresses.

2010-09-21 Thread Justin P. Mattock 
Below is an update from the original, with changes to the broken web addresses 
and removal of 
archive.org and moved to a seperate patch for you guys to decide if you want to 
use this and/or
just leave the old url in and leave it at that..
Please dont apply this to anything just comments and fixes for now,
then when the time is right, I can bunch everything all into one big patch.
 
Signed-off-by: Justin P. Mattock 
Cc: Maciej W. Rozycki 
Cc: Finn Thain 
Cc: Randy Dunlap 

---
 arch/arm/Kconfig |4 ++--
 arch/arm/common/icst.c   |2 +-
 arch/arm/include/asm/hardware/icst.h |2 +-
 arch/arm/mach-at91/Kconfig   |6 +++---
 arch/arm/mach-omap1/Kconfig  |2 +-
 arch/arm/mach-pxa/am200epd.c |2 +-
 arch/arm/mach-pxa/am300epd.c |2 +-
 arch/arm/mach-s3c2440/mach-at2440evb.c   |2 +-
 arch/arm/mach-sa1100/Kconfig |6 +++---
 arch/arm/mach-sa1100/cpu-sa1100.c|2 +-
 arch/arm/mm/Kconfig  |2 +-
 arch/arm/mm/proc-xscale.S|2 +-
 arch/arm/nwfpe/milieu.h  |4 ++--
 arch/arm/nwfpe/softfloat-macros  |4 ++--
 arch/arm/nwfpe/softfloat-specialize  |4 ++--
 arch/arm/nwfpe/softfloat.c   |4 ++--
 arch/arm/nwfpe/softfloat.h   |4 ++--
 arch/arm/plat-samsung/include/plat/adc.h |2 +-
 arch/avr32/Kconfig   |2 +-
 arch/h8300/Kconfig.cpu   |   12 ++--
 arch/h8300/README|6 +++---
 arch/m32r/Kconfig|2 +-
 arch/m68k/mac/macboing.c |3 ++-
 arch/m68k/q40/README |2 +-
 arch/mips/Kconfig|   12 
 arch/mips/math-emu/cp1emu.c  |1 -
 arch/mips/math-emu/dp_add.c  |1 -
 arch/mips/math-emu/dp_cmp.c  |1 -
 arch/mips/math-emu/dp_div.c  |1 -
 arch/mips/math-emu/dp_fint.c |1 -
 arch/mips/math-emu/dp_flong.c|1 -
 arch/mips/math-emu/dp_frexp.c|1 -
 arch/mips/math-emu/dp_fsp.c  |1 -
 arch/mips/math-emu/dp_logb.c |1 -
 arch/mips/math-emu/dp_modf.c |1 -
 arch/mips/math-emu/dp_mul.c  |1 -
 arch/mips/math-emu/dp_scalb.c|1 -
 arch/mips/math-emu/dp_simple.c   |1 -
 arch/mips/math-emu/dp_sqrt.c |1 -
 arch/mips/math-emu/dp_sub.c  |1 -
 arch/mips/math-emu/dp_tint.c |1 -
 arch/mips/math-emu/dp_tlong.c|1 -
 arch/mips/math-emu/ieee754.c |1 -
 arch/mips/math-emu/ieee754.h |1 -
 arch/mips/math-emu/ieee754d.c|1 -
 arch/mips/math-emu/ieee754dp.c   |1 -
 arch/mips/math-emu/ieee754dp.h   |1 -
 arch/mips/math-emu/ieee754int.h  |1 -
 arch/mips/math-emu/ieee754m.c|1 -
 arch/mips/math-emu/ieee754sp.c   |1 -
 arch/mips/math-emu/ieee754sp.h   |1 -
 arch/mips/math-emu/ieee754xcpt.c |1 -
 arch/mips/math-emu/sp_add.c  |1 -
 arch/mips/math-emu/sp_cmp.c  |1 -
 arch/mips/math-emu/sp_div.c  |1 -
 arch/mips/math-emu/sp_fdp.c  |1 -
 arch/mips/math-emu/sp_fint.c |1 -
 arch/mips/math-emu/sp_flong.c|1 -
 arch/mips/math-emu/sp_frexp.c|1 -
 arch/mips/math-emu/sp_logb.c |1 -
 arch/mips/math-emu/sp_modf.c |1 -
 arch/mips/math-emu/sp_mul.c  |1 -
 arch/mips/math-emu/sp_scalb.c|1 -
 arch/mips/math-emu/sp_simple.c   |1 -
 arch/mips/math-emu/sp_sqrt.c |1 -
 arch/mips/math-emu/sp_sub.c  |1 -
 arch/mips/math-emu/sp_tint.c |1 -
 arch/mips/math-emu/sp_tlong.c|1 -
 arch/powerpc/include/asm/hydra.h |2 +-
 arch/x86/kernel/apm_32.c |4 ++--
 arch/x86/kernel/microcode_core.c |2 +-
 arch/x86/kernel/microcode_intel.c|2 +-
 72 files changed, 55 insertions(+), 93 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 553b7cf..c562c68 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -647,7 +647,7 @@ config ARCH_S3C2410
select HAVE_S3C2410_I2C
help
  Samsung S3C2410X CPU based systems, such as the Simtec Electronics
- BAST (), the IPAQ 1940 or
+ BAST (), the IPAQ 1940 or
  the Samsung SMDK2410 development board (and derivatives).
 
  Note, the S3C2416 and the S3C2450 are so close that they even share
@@ -1162,7 +1162,7 @@ config SMP
 
  See also ,
   and the SMP-HOWTO available at
-

RE: Questions on interrupt vector assignment on MPC8641D

2010-09-21 Thread Chen, Tiejun 
> -Original Message-
> From: 
> linuxppc-dev-bounces+tiejun.chen=windriver@lists.ozlabs.or
> g 
> [mailto:linuxppc-dev-bounces+tiejun.chen=windriver@lists.o
> zlabs.org] On Behalf Of Scott Wood
> Sent: Wednesday, September 22, 2010 6:07 AM
> To: Anderson, Trevor
> Cc: david.hag...@gmail.com; linuxppc-dev@lists.ozlabs.org
> Subject: Re: Questions on interrupt vector assignment on MPC8641D
> 
> On Tue, 21 Sep 2010 17:37:15 -0400
> "Anderson, Trevor"  wrote:
> 
> > IRQ assignments for MPC8641D are "virtual",
> 
> This is true for powerpc in general.
> 
> > meaning "made up" and quite difficult to determine by 
> looking through code.
> > But I believe the plan goes something like this:
> > 
> >   IRQ
> > -
> > 0   No interrupt
> >   1 - 15External interrupts (only 1..12 would be used)
> >  16 - 127   Internal interrupts - see Table 9-2 of 
> 8641D ref man,
> > Add 15 to the numbers shown
> > 128 - 255   Yours, or your BSP's, to do with as you like
> > 256 - 511   Message Signaled Interrupts
> > 
> > If you look in the sample device trees for 8641 cards 
> you'll see that 
> > the interrupt values cited there for various devices match 
> the 16..127 
> > group above.
> 
> There are two different numberspaces involved here.
> 
> The MPIC interrupt numberspace in the device tree (which is 
> not virtual; it is a private numberspace to MPIC) is based on 
> the offset of the registers for that interrupt source. 
> External interrupts start at zero (which is valid), internal 
> at 16, and special things like MSIs at higher numbers (I 
> don't think it's quite 256).

Agreed. 

This should be depend on the given platform. For example 0xe0~0xe7 are
ranged for MSI on Freescale targets. And it can avoid easily to conflict
those used lower numbers when the special MSI interrupt numbers are
higher. 

Tiejun

> 
> The numberspace for virtual interrupts, which is what you 
> pass to request_irq(), is dynamically allocated.  You 
> shouldn't need to know anything about it other than that zero 
> is invalid, and you get the virtual IRQ from 
> irq_of_parse_and_map() or another such mapping function.
> 
> In neither case is there a range that is set aside for you 
> "to do with as you like".  If you have another interrupt 
> controller and need a block of virtual interrupts, register 
> the controller with
> irq_alloc_host() and you'll get a block assigned.
> 
> -Scott
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [U-Boot] cuImage and multi image?

2010-09-21 Thread Chen, Tiejun 
> -Original Message-
> From: 
> linuxppc-dev-bounces+tiejun.chen=windriver@lists.ozlabs.or
> g 
> [mailto:linuxppc-dev-bounces+tiejun.chen=windriver@lists.o
zlabs.org] On Behalf Of Scott Wood
> Sent: Wednesday, September 22, 2010 1:53 AM
> To: Chen, Tiejun
> Cc: ppcdev; uboot
> Subject: Re: [U-Boot] cuImage and multi image?
> 
> On Tue, 21 Sep 2010 03:03:22 +0200
> "Chen, Tiejun"  wrote:
> 
> > > -Original Message-
> > > From: Shawn Jin [mailto:shawnx...@gmail.com]
> > > Sent: Tuesday, September 21, 2010 1:53 AM
> > > To: Chen, Tiejun
> > > Cc: ppcdev; uboot
> > > Subject: Re: cuImage and multi image?
> > > 
> > > >> I have a cuImage kernel in order to support legacy 
> u-boot and a 
> > > >> ramdisk image. Kernel boots fine if these two images are
> > > separate and
> > > >> "bootm $kernel $ramdisk" is used. But I can not make it to
> > > work using
> > > >> a single multi image that contains the kernel and ramdisk
> > > images. Is
> > > >> it even technically possible to boot a multi-image with cuboot 
> > > >> wrapper?
> > > >
> > > > Try the following steps:
> > > > --
> > > > 1. cp  arch/powerpc/boot/ramdisk.image.gz
> > > > 2. make cuImage.initrd.
> > > >
> > > > You can get one Image, cuImage.initrd.,
> > > including kernel and ramdisk.
> > > 
> > > A follow up question. With this method, the total image size
> > > (uncompressed) is limited to the 4MB (the link address of 
> the boot 
> > > wrapper)?
> > 
> > No.
> 
> Yes, unless you change the link address, or provide a 
> vmlinux_alloc callback (which currently only happens on true 
> OF, not cuImage).
> 
> Unless you're talking about the "(uncompressed)"?  The limit 
> applies to the uncompressed boot image -- anything that the 
> bootwrapper itself is decompressing.  It does not apply to 
> any further uncompression of the ramdisk itself.
> 

He should point the latter, "the total image size", including ramdisk.
But the link address should be limited for the boot Image, not for the
attached ramdisk.

Tiejun

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

RE: Generating elf kernel ?

2010-09-21 Thread Chen, Tiejun 
> -Original Message-
> From: Scott Wood [mailto:scottw...@freescale.com] 
> Sent: Wednesday, September 22, 2010 1:00 AM
> To: Chen, Tiejun
> Cc: linuxppc-dev@lists.ozlabs.org; Guillaume Dargaud
> Subject: Re: Generating elf kernel ?
> 
> On Tue, 21 Sep 2010 03:00:40 +0200
> "Chen, Tiejun"  wrote:
> 
> > This should be depend on the hypervisor design 
> implementation. I think 
> > your option should be based on the Freescale hypervisor.
> 
> Again, I was giving an example, about ELF loading.  I was not 
> making any claims about what all hypervisors do. :-P
> 

When I'm free I'd like to track the Freescale hypervisor codes. 

Thanks
Tiejun

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

Re: [PATCH] fsldma: add support to 36-bit physical address

2010-09-21 Thread Timur Tabi 
On Tue, Sep 21, 2010 at 5:17 PM, Scott Wood  wrote:

> It needs to be the actual device that is performing the DMA -- the
> platform may need to do things such as IOMMU manipulation where
> knowing the device matters.

Ok, this all makes sense.  So it appears that the patch is valid, at
least in theory.  I would like to see some testing of it, but I
realize that may be too difficult.  There's no easy way to force an
allocation above 4GB.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] fsldma: add support to 36-bit physical address

2010-09-21 Thread Scott Wood 
On Tue, 21 Sep 2010 17:08:54 -0500
Timur Tabi  wrote:

> On Tue, Sep 21, 2010 at 5:05 PM, Dan Malek  wrote:
> 
> > The DMA descriptors are accessed using DMA by the
> > controller itself.
> 
> Yes and no.  Technically, it is DMA, but it's not something that
> SWIOTLB could ever know about.  We just pass the physical address to
> the DMA controller, and it does a memory read to obtain the data.
> That's not the kind of DMA that SWIOTLB would deal with, I think.

SWIOTLB should see that the address is directly DMAable and do nothing,
but you don't want to skip the DMA API altogether.  You still need to
flush caches if DMA is noncoherent, etc.

> My question is, should dmaengine be using the same 'dev' that fsldma
> uses to allocate the DMA descriptors?  I wonder if the 'dev' should be
> allocated internally by dmaengine, or provided by the client drivers.

It needs to be the actual device that is performing the DMA -- the
platform may need to do things such as IOMMU manipulation where
knowing the device matters.

-Scott

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

Re: [PATCH] fsldma: add support to 36-bit physical address

2010-09-21 Thread Dan Malek 


On Sep 21, 2010, at 2:49 PM, Scott Wood wrote:



On Tue, 21 Sep 2010 16:43:12 -0500
Timur Tabi  wrote:


Since we don't DMA the descriptors themselves, I just don't see how
this patch does anything.


Look in dmaengine.c, there are calls to dma_map_single() and
dma_map_page(), using what I assume is that same device pointer --
unless there's confusion between the channel and the controller.


The DMA descriptors are accessed using DMA by the
controller itself.  The APIs need to ensure proper coherency
between the CPU and the DMA controller for the
descriptor access.  The underlying implementation of the
API will depend upon the hardware capabilities that
ensure this coherency.

-- Dan

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

Re: [PATCH] fsldma: add support to 36-bit physical address

2010-09-21 Thread Timur Tabi 
On Tue, Sep 21, 2010 at 5:05 PM, Dan Malek  wrote:

> The DMA descriptors are accessed using DMA by the
> controller itself.

Yes and no.  Technically, it is DMA, but it's not something that
SWIOTLB could ever know about.  We just pass the physical address to
the DMA controller, and it does a memory read to obtain the data.
That's not the kind of DMA that SWIOTLB would deal with, I think.

> The APIs need to ensure proper coherency
> between the CPU and the DMA controller for the
> descriptor access.  The underlying implementation of the
> API will depend upon the hardware capabilities that
> ensure this coherency.

I think that's already covered.  The dma_set_mask() call is supposed
to only affect the dma_map_single() calls that dmaengine makes, as
Scott pointed out.

My question is, should dmaengine be using the same 'dev' that fsldma
uses to allocate the DMA descriptors?  I wonder if the 'dev' should be
allocated internally by dmaengine, or provided by the client drivers.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Questions on interrupt vector assignment on MPC8641D

2010-09-21 Thread Scott Wood 
On Tue, 21 Sep 2010 17:37:15 -0400
"Anderson, Trevor"  wrote:

> IRQ assignments for MPC8641D are "virtual", 

This is true for powerpc in general.

> meaning "made up" and quite difficult to determine by looking through code.
> But I believe the plan goes something like this:
> 
>   IRQ
> -
> 0   No interrupt
>   1 - 15External interrupts (only 1..12 would be used)
>  16 - 127   Internal interrupts - see Table 9-2 of 8641D ref man,
> Add 15 to the numbers shown
> 128 - 255   Yours, or your BSP's, to do with as you like
> 256 - 511   Message Signaled Interrupts
> 
> If you look in the sample device trees for 8641 cards you'll see that
> the interrupt values cited there for various devices match the 16..127
> group above.

There are two different numberspaces involved here.

The MPIC interrupt numberspace in the device tree (which is not
virtual; it is a private numberspace to MPIC) is based on the offset of
the registers for that interrupt source. External interrupts start at
zero (which is valid), internal at 16, and special things like MSIs at
higher numbers (I don't think it's quite 256).

The numberspace for virtual interrupts, which is what you pass to
request_irq(), is dynamically allocated.  You shouldn't need to know
anything about it other than that zero is invalid, and you get the
virtual IRQ from irq_of_parse_and_map() or another such mapping
function.

In neither case is there a range that is set aside for you "to do with
as you like".  If you have another interrupt controller and need a
block of virtual interrupts, register the controller with
irq_alloc_host() and you'll get a block assigned.

-Scott

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

Re: [PATCH] fsldma: add support to 36-bit physical address

2010-09-21 Thread Timur Tabi 
On Tue, Sep 21, 2010 at 4:49 PM, Scott Wood  wrote:

> Look in dmaengine.c, there are calls to dma_map_single() and
> dma_map_page(), using what I assume is that same device pointer --
> unless there's confusion between the channel and the controller.

You're right.  I missed this line in the driver:

fdev->common.dev = &op->dev;

Also, the driver does something stupid.  Sometimes "chan->dev" refers
to dma_chan.chan, and sometimes it refers to fsldma_chan.chan.  I
could have sworn I saw a patch that fixes that, though.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] fsldma: add support to 36-bit physical address

2010-09-21 Thread Scott Wood 
On Tue, 21 Sep 2010 16:43:12 -0500
Timur Tabi  wrote:

> On Tue, Sep 21, 2010 at 4:34 PM, Scott Wood  wrote:
> 
> > This doesn't control allocation (it probably should with
> > dma_alloc_coherent, though I don't see it in the code), it controls
> > whether swiotlb will create a bounce buffer -- defeating the point of
> > using DMA to accelerate a memcpy.
> 
> But it would do that only for the 'dev' used in the dma_set_mask()
> call.  That dev is only used here:
> 
>   chan->desc_pool = dma_pool_create("fsl_dma_engine_desc_pool",
> chan->dev,
> sizeof(struct fsl_desc_sw),
> __alignof__(struct fsl_desc_sw), 0);
> 
> Since we don't DMA the descriptors themselves, I just don't see how
> this patch does anything.

Look in dmaengine.c, there are calls to dma_map_single() and
dma_map_page(), using what I assume is that same device pointer --
unless there's confusion between the channel and the controller.

-Scott

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

Re: [PATCH] fsldma: add support to 36-bit physical address

2010-09-21 Thread Timur Tabi 
On Tue, Sep 21, 2010 at 4:34 PM, Scott Wood  wrote:

> This doesn't control allocation (it probably should with
> dma_alloc_coherent, though I don't see it in the code), it controls
> whether swiotlb will create a bounce buffer -- defeating the point of
> using DMA to accelerate a memcpy.

But it would do that only for the 'dev' used in the dma_set_mask()
call.  That dev is only used here:

chan->desc_pool = dma_pool_create("fsl_dma_engine_desc_pool",
  chan->dev,
  sizeof(struct fsl_desc_sw),
  __alignof__(struct fsl_desc_sw), 0);

Since we don't DMA the descriptors themselves, I just don't see how
this patch does anything.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: Questions on interrupt vector assignment on MPC8641D

2010-09-21 Thread Anderson, Trevor 
IRQ assignments for MPC8641D are "virtual", meaning "made up" and quite 
difficult to determine by looking through code.
But I believe the plan goes something like this:

  IRQ
-
0   No interrupt
  1 - 15External interrupts (only 1..12 would be used)
 16 - 127   Internal interrupts - see Table 9-2 of 8641D ref man,
Add 15 to the numbers shown
128 - 255   Yours, or your BSP's, to do with as you like
256 - 511   Message Signaled Interrupts

If you look in the sample device trees for 8641 cards you'll see that
the interrupt values cited there for various devices match the 16..127
group above.



> -Original Message-
> From: linuxppc-dev-bounces+tanderson=curtisswright@lists.ozlabs.org 
> [mailto:linuxppc-dev-
> bounces+tanderson=curtisswright@lists.ozlabs.org] On Behalf Of 
> david.hag...@gmail.com
> Sent: Tuesday, September 21, 2010 7:12 AM
> To: linuxppc-dev@lists.ozlabs.org
> Subject: Questions on interrupt vector assignment on MPC8641D
>
> I'm new to developing on the PPC (most of my experience is on x86), and I
> have a couple of questions about mapping of interrupts on the PPC,
> specifically on the Freescale 8641D embedded CPU.
>
> 1) How does one allocate interrupt vectors for the embedded devices, such
> as the MPIC? All the kernel how-tos are really targeting the x86 and PCI,
> so I've been unable to find a good document on "that which is not an X86".
>
> 2) Are there any good guides to programming the PPC generally, and the
> MPC8641 specifically, that I can go read to answer my other questions?
>
> I'm trying to write a driver to map the 8641D's PCIe controllers *as
> endpoints* into something frobablbe from user space - to allow setting the
> BARs and outbound address translation units via sysfs files, and to allow
> mapping of inbound interrupts to sysfs "doorbell"-style files. If I can
> get it worked out I want to submit it back to the kernel for general
> distribution.
>
> If anybody has any insights, I'd greatly appreciate it if you'd copy my
> work email (david.hagood at aeroflex.com) as well (I am using my personal
> email as work insisted upon adding a one paragraph "wart" to all outbound
> email that isn't acceptable for a list like this.)
>
> Also, if anybody out there has experience with the 8641D PEX's in endpoint
> mode and wouldn't mind answering a couple of questions about programming
> the OWBARs, I'd be greatly obliged.
>
>
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

___
This e-mail and any files transmitted with it are proprietary and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have reason to believe that you have received this e-mail in error, please 
notify the sender and destroy this email and any attached files. Please note 
that any views or opinions presented in this e-mail are solely those of the 
author and do not necessarily represent those of the Curtiss-Wright Corporation 
or any of its subsidiaries.  Documents attached hereto may contain technology 
subject to government export regulations. Recipient is solely responsible for 
ensuring that any re-export, transfer or disclosure of this information is in 
accordance with applicable government export regulations.  The recipient should 
check this e-mail and any attachments for the presence of viruses. 
Curtiss-Wright Corporation and its subsidiaries accept no liability for any 
damage caused by any virus transmitted by this e-mail.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] fsldma: add support to 36-bit physical address

2010-09-21 Thread Scott Wood 
On Tue, 21 Sep 2010 16:24:10 -0500
Timur Tabi  wrote:

> On Tue, Sep 21, 2010 at 7:55 AM, Kumar Gala  wrote:
> >
> > On Sep 21, 2010, at 5:57 AM, Li Yang wrote:
> >
> >> Signed-off-by: Li Yang 
> >> ---
> >
> > We really should have a sentence about how or why this works to address 
> > 36-bit addressing.
> 
> For example, I would like to know which memory is going to be
> allocated above 4GB.  I don't know much about the kernel's async
> library, but my understanding is that fsldma does not allocate any of
> the memory buffers that it copies data to/from.

This doesn't control allocation (it probably should with
dma_alloc_coherent, though I don't see it in the code), it controls
whether swiotlb will create a bounce buffer -- defeating the point of
using DMA to accelerate a memcpy.

-Scott

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

Re: [PATCH] fsldma: add support to 36-bit physical address

2010-09-21 Thread Timur Tabi 
On Tue, Sep 21, 2010 at 7:55 AM, Kumar Gala  wrote:
>
> On Sep 21, 2010, at 5:57 AM, Li Yang wrote:
>
>> Signed-off-by: Li Yang 
>> ---
>
> We really should have a sentence about how or why this works to address 
> 36-bit addressing.

For example, I would like to know which memory is going to be
allocated above 4GB.  I don't know much about the kernel's async
library, but my understanding is that fsldma does not allocate any of
the memory buffers that it copies data to/from.  The only memory that
fsldma allocates is for the DMA descriptors, which are very small and
probably don't take up more than a couple pages.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.

2010-09-21 Thread Kyle Moffett 
On Fri, Aug 27, 2010 at 18:30, John Stultz  wrote:
> On one side, there is the view that the kernel should abstract and hide
> the hardware details to increase app portability. And the other is that
> the raw hardware details should be exposed, so the OS stays out of the
> way.
>
> Neither of these views are always right. Ideally we can come up with a
> abstracted way to provide the hardware data needed that's generic enough
> that applications don't have to be changed when moving between hardware
> or configurations.
>
> The posix clock id interface is frustrating because the flat static
> enumeration is really limiting.
>
> I wonder if a dynamic enumeration for posix clocks would be possibly a
> way to go?

Well how about something much more straightforward:

#define CLOCK_FD 0x8000
fd = open("/dev/clocks/some_clock_name", O_RDONLY);
clock_gettime(CLOCK_FD | fd, &ts);

This would provide all of the standard character-device semantics that
everyone is accustomed to, and furthermore you could allow non-root
users to manage specific clocks using just DAC permission bits.

You'd still probably need to add a clock_adjtimex() syscall, but it
could easily fail with EINVAL for software or per-thread clocks, but
that seems like it would nicely abstract the hardware without forcing
a numeric address space.

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

Re: [U-Boot] cuImage and multi image?

2010-09-21 Thread Scott Wood 
On Tue, 21 Sep 2010 03:03:22 +0200
"Chen, Tiejun"  wrote:

> > -Original Message-
> > From: Shawn Jin [mailto:shawnx...@gmail.com] 
> > Sent: Tuesday, September 21, 2010 1:53 AM
> > To: Chen, Tiejun
> > Cc: ppcdev; uboot
> > Subject: Re: cuImage and multi image?
> > 
> > >> I have a cuImage kernel in order to support legacy u-boot and a 
> > >> ramdisk image. Kernel boots fine if these two images are 
> > separate and 
> > >> "bootm $kernel $ramdisk" is used. But I can not make it to 
> > work using 
> > >> a single multi image that contains the kernel and ramdisk 
> > images. Is 
> > >> it even technically possible to boot a multi-image with cuboot 
> > >> wrapper?
> > >
> > > Try the following steps:
> > > --
> > > 1. cp  arch/powerpc/boot/ramdisk.image.gz
> > > 2. make cuImage.initrd.
> > >
> > > You can get one Image, cuImage.initrd., 
> > including kernel and ramdisk.
> > 
> > A follow up question. With this method, the total image size
> > (uncompressed) is limited to the 4MB (the link address of the 
> > boot wrapper)?
> 
> No.

Yes, unless you change the link address, or provide a vmlinux_alloc
callback (which currently only happens on true OF, not cuImage).

Unless you're talking about the "(uncompressed)"?  The limit applies to
the uncompressed boot image -- anything that the bootwrapper itself is
decompressing.  It does not apply to any further uncompression of the
ramdisk itself.

-Scott

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

Re: Generating elf kernel ?

2010-09-21 Thread Scott Wood 
On Tue, 21 Sep 2010 03:00:40 +0200
"Chen, Tiejun"  wrote:

> This should be depend on the hypervisor design implementation. I think
> your 
> option should be based on the Freescale hypervisor.

Again, I was giving an example, about ELF loading.  I was not making any
claims about what all hypervisors do. :-P

-Scott

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

RE: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c

2010-09-21 Thread Tirumala Marri 
> -Original Message-
> From: linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org] On
> Behalf Of Ilya Yanok
> Sent: Sunday, September 19, 2010 1:01 PM
> To: linuxppc-...@ozlabs.org
> Subject: Re: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
>
> Hi Tirumala,
>
> >  drivers/dma/ppc4xx/adma.c| 4370 +++-
> --
> >  drivers/dma/ppc4xx/adma.h|  116 +-
> >  drivers/dma/ppc4xx/ppc4xx-adma.h | 4020
> +++
>
> You've moved tons of code to the header file. Why?
>
> Regards, Ilya.
>
My intention is to keep the SoC specific code in the header files.
Something iop-dma is also doing.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.

2010-09-21 Thread Stephan Gatzka 

Hi Richard,


1. Character device
2. POSIX clock with dynamic ids

Please, just take your pick ;^)


Just to reopen this nearly dead but very interesting thread: I'm happy 
with every solution that has no impact on the accuracy of the PTP clock.


If I can choose, I would prefer the POSIX clock with dynamic ids solution.

Kind regards and thanks for your effort,

Stephan Gatzka



smime.p7s
Description: S/MIME Cryptographic Signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Questions on interrupt vector assignment on MPC8641D

2010-09-21 Thread david . hagood 
I'm new to developing on the PPC (most of my experience is on x86), and I
have a couple of questions about mapping of interrupts on the PPC,
specifically on the Freescale 8641D embedded CPU.

1) How does one allocate interrupt vectors for the embedded devices, such
as the MPIC? All the kernel how-tos are really targeting the x86 and PCI,
so I've been unable to find a good document on "that which is not an X86".

2) Are there any good guides to programming the PPC generally, and the
MPC8641 specifically, that I can go read to answer my other questions?

I'm trying to write a driver to map the 8641D's PCIe controllers *as
endpoints* into something frobablbe from user space - to allow setting the
BARs and outbound address translation units via sysfs files, and to allow
mapping of inbound interrupts to sysfs "doorbell"-style files. If I can
get it worked out I want to submit it back to the kernel for general
distribution.

If anybody has any insights, I'd greatly appreciate it if you'd copy my
work email (david.hagood at aeroflex.com) as well (I am using my personal
email as work insisted upon adding a one paragraph "wart" to all outbound
email that isn't acceptable for a list like this.)

Also, if anybody out there has experience with the 8641D PEX's in endpoint
mode and wouldn't mind answering a couple of questions about programming
the OWBARs, I'd be greatly obliged.



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

Re: [PATCH] fsldma: add support to 36-bit physical address

2010-09-21 Thread Kumar Gala 

On Sep 21, 2010, at 5:57 AM, Li Yang wrote:

> Signed-off-by: Li Yang 
> ---

We really should have a sentence about how or why this works to address 36-bit 
addressing.

> drivers/dma/fsldma.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index cea08be..9163552 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -1,7 +1,7 @@
> /*
>  * Freescale MPC85xx, MPC83xx DMA Engine support
>  *
> - * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
> + * Copyright (C) 2007-2009 Freescale Semiconductor, Inc. All rights reserved.
>  *
>  * Author:
>  *   Zhang Wei , Jul 2007
> @@ -1338,6 +1338,7 @@ static int __devinit fsldma_of_probe(struct 
> platform_device *op,
>   fdev->common.device_control = fsl_dma_device_control;
>   fdev->common.dev = &op->dev;
> 
> + dma_set_mask(&op->dev, DMA_BIT_MASK(36));
>   dev_set_drvdata(&op->dev, fdev);
> 
>   /*
> -- 
> 1.6.6-rc1.GIT
> 
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

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

Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it

2010-09-21 Thread Detlev Zundel 
Hi Scott,

> On Sat, 18 Sep 2010 14:22:12 -0400
> Josh Boyer  wrote:
>
>> Capitalizing?  The patch you posted that uses this symbol is for a GPL
>> driver so you gain or lose nothing by having this symbol be
>> EXPORT_SYMBOL_GPL.  Are you somehow advocating and getting some sort
>> of gain by allowing non-GPL modules?  If so, I find that unfortunate.
>> If not, then I guess I don't understand what you mean by capitalizing.
>
> One can dislike DRM (even a very weak form such as this) without having
> a particular desire to go outside the bounds of what it allows.
>
> I thought EXPORT_SYMBOL_GPL was originally meant to indicate the
> symbols whose use is likely to be indicitave of code that is, in some
> copyright-meaningful way, derived from GPL code?  

Google finds this, which coincides with what I remmber[1]:

  EXPORT_SYMBOL_GPL 
  
  Some kernel developers are unhappy with providing external interfaces to
  their code, only to see those interfaces being used by binary only
  modules. They view it as their work being appropriated. Whether you
  agree with that view or not is completely irrelevant, the person who
  owns the copyright decides how their work can be used.
  
  EXPORT_SYMBOL_GPL() allows for new interfaces to be marked as only
  available to modules with a GPL compatible license. This is independent
  of the kernel tainting, but obviously takes advantage of
  MODULE_LICENSE() strings.
  
  EXPORT_SYMBOL_GPL() may only be used for new exported symbols, Linus has
  spoken. I believe the phrase involved killer penguins with chainsaws for
  anybody who changed existing exported interfaces.

Cheers
  Detlev

[1] http://lkml.indiana.edu/hypermail/linux/kernel/0110.2/0369.html
  
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de

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

[PATCH] fsldma: add support to 36-bit physical address

2010-09-21 Thread Li Yang 
Signed-off-by: Li Yang 
---
 drivers/dma/fsldma.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index cea08be..9163552 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1,7 +1,7 @@
 /*
  * Freescale MPC85xx, MPC83xx DMA Engine support
  *
- * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ * Copyright (C) 2007-2009 Freescale Semiconductor, Inc. All rights reserved.
  *
  * Author:
  *   Zhang Wei , Jul 2007
@@ -1338,6 +1338,7 @@ static int __devinit fsldma_of_probe(struct 
platform_device *op,
fdev->common.device_control = fsl_dma_device_control;
fdev->common.dev = &op->dev;
 
+   dma_set_mask(&op->dev, DMA_BIT_MASK(36));
dev_set_drvdata(&op->dev, fdev);
 
/*
-- 
1.6.6-rc1.GIT


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

Dual ethernet attachment with single FEC

2010-09-21 Thread LEROY Christophe 

Hello,

I have a board with 2 PHYs attached to one FEC ethernet controler on 
powerpc.
I want to implement some kind of main-standby attachment to LAN by 
setting the ISOLATE bit on one on the two PHYs then monitoring the link 
status and switch to the other PHY when the link status goes down.


I see this behaviour is implemented in the sis900 driver, but it doesn't 
use the standard PHY layer as the Freescale FEC driver does.


What would be the most proper way to implement this functionality ?
* Modify FEC driver to manage that ?
* Implement a virtual PHY driver that would manage that ?
* Other solution ?

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