date:20091126

On Thu, 2009-11-26 at 09:17 +0100, Gabriel Paubert wrote:
 
  They should hopefully... as long as you don't rely on the reservation
  blowing as a result of a DMA write.
 
 Hmm, this really depends on whether the DMA transfers generate bus cycles
 that require coherency or not. Not the other way around. M=1 only forces
 bus cycles to be snooped by other processors (asserting the GBL signal
 on 603/604/750 busses).

You are absolutely right. Which makes it even more likely that
lwarx/stwcx. won't care unless the L2 cache plays tricks.

 The host bridge is free to systematically snoop processor accesses (to make 
 sure that data queued in the bridge and not yet written to memory is seen
 in the coherent memory domain even if, for example, interrupts propagate 
 so fast that DMA target addresses are accessed before it is written to RAM).
 
 On memory coherent systems, the host bridge has to assert the GBL signal,
 to force data to be written to memory (for most DMA accesses), or to  
 invalidate caches (for full line writes from devices). 

Cheers,
Ben.


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

Re: [PATCH] zlib: Optimize inffast when copying direct from output

On Thu, 2009-11-26 at 09:30 +0100, Joakim Tjernlund wrote:
  I'm not sure its going to work to use get_unaligned() like that on all
  archs .. it might be definitely something to discuss on some more
  appropriate mailing list.
 
 Oh, why not? Is that because I am using it wrongly or because xx_unaligned
 is impl. incorrectly on some archs? 

I'm just not sure it works in boot wrappers in case archs ... I suppose
it does but I haven't actually checked :-)

Cheers,
Ben.


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

Re: [PATCH] zlib: Optimize inffast when copying direct from output

2009-11-26 Thread Joakim Tjernlund

Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 26/11/2009 09:46:58:

 On Thu, 2009-11-26 at 09:30 +0100, Joakim Tjernlund wrote:
   I'm not sure its going to work to use get_unaligned() like that on all
   archs .. it might be definitely something to discuss on some more
   appropriate mailing list.
 
  Oh, why not? Is that because I am using it wrongly or because xx_unaligned
  is impl. incorrectly on some archs?

 I'm just not sure it works in boot wrappers in case archs ... I suppose
 it does but I haven't actually checked :-)

I am not aware of other boot wrappers than PowerPC and I believe ppc
should handle it as unaligned accesses aren't a problem there.

  Jocke

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

Re: [PATCH] Reserve memory for kdump kernel within RMO region

2009-11-26 Thread M. Mohan Kumar


On 11/26/2009 12:22 AM, Bernhard Walle wrote:

M. Mohan Kumar schrieb:

Reserve memory for kdump kernel within RMO region

When the kernel size exceeds 32MB(observed with some distros), memory
for kdump kernel can not be reserved as kdump kernel base is assumed to
be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled,
provide the feature to reserve the memory for kdump kernel anywhere in
the RMO region.




Hi Bernhard,


Correct me if I'm wrong, but: CONFIG_RELOCATABLE is for the kernel that
gets loaded as crashkernel, not for the kernel that loads the
crashkernel. So it would be perfectly fine that a kernel that has not
CONFIG_RELOCATABLE set would load another kernel that has
CONFIG_RELOCATABLE set on an address != 32 M.


No, with relocatable option, the same kernel is used as both production 
and kdump kernel. If the kernel is not relocatable, kdump kernel can be 
loaded *only at* 32MB. So if a kernel has RELOCATABLE option enabled and 
by chance if the production kernel size is beyond 32MB, current code 
will not load the kdump kernel at 32MB as current kernel overlaps with 
kdump kernel region. So if the kernel has RELOCATABLE option, we could 
reserve memory for kdump kernel within RMO region.




So it would be part of the command line to determine whether a fixed or
a variable address is used. The system configuration (or the admin)
knows both: if the kernel that should be loaded is relocatable (can be
detected with the x86 bzImage header or with the ELF type for vmlinux)
and it can also influence the boot command line.

To sum it up: I'm not against reserving it anywhere, I'm only against
making it dependent on CONFIG_RELOCATABLE which has another function.



Regards,
Bernhard


___
kexec mailing list
ke...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


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

Re: spi_mpc8xxx.c: chip select polarity problem

2009-11-26 Thread Anton Vorontsov

On Wed, Nov 25, 2009 at 03:11:57PM -0700, Grant Likely wrote:
 On Wed, Nov 25, 2009 at 1:41 PM, Torsten Fleischer
 to-fleisc...@t-online.de wrote:
  On Wen, Nov 25, 2009 at 01:33:57 Grant Likely wrote:
  Thanks.  However, there needs to be a proper description of what this
  patch does to go in the commit header.  Can you please write one?
 
  Thanks,
  g.
 
  [...]
 
  The initialization of the chip selects is removed from the probe() function 
  of
  the spi_mpc8xxx driver, because the driver doesn't know the polarity of the
  chip selects of the SPI devices at the time of its initialization.
 
  For this reason the initialization of the several chip selects is postponed
  to the point of time when the very first SPI transfer to the associated 
  device
  occurs.
 
 
  Signed-off-by: Torsten Fleischer to-fleisc...@t-online.de
 
 Ah.  I understand what you're doing now.   Hmmm.  This approach
 concerns me because it relies on firmware or platform code to get CS
 gpios set up properly before the driver is probed.

Yes, that was said at the very beginning of this thread.

  Firmware doesn't
 always get it right, and I prefer to avoid platform specific setups as
 much as possible.  Why can't the CS polarity be encoded into the
 device tree so the driver *does* have the polarity data at probe time?

We have the spi-cs-high property, but it duplicates compatible
property. 'compatible' is enough to tell whether some device has
cs-high or cs-low (device's driver knows that already).

The problem is that SPI bus master doesn't know all the devices,
so it can't extract that information from the compatible string.
To workaround that we can use 'spi-cs-high', but that's ugly
workaround.

SPI modes (0,1,2,3) is another matter, some devices can work in
several modes, so 'spi-cpol' and 'spi-cpha' are actually useful.

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 00/11] Yet another series of OF merge patches.

2009-11-26 Thread Wolfram Sang

On Tue, Nov 24, 2009 at 01:17:41AM -0700, Grant Likely wrote:
 Nothing much to say here other than mostly mechanical merging of OF
 support code.  Some of it remains a little ugly, but I'm taking the
 approach of merging the code first, and refactoring it second.
 
 I've pushed this series out to my test-devicetree branch on my git
 server if anyone wants to test.  That branch also includes the
 previous 2 patch series that I've sent out.
 
 git://git.secretlab.ca/git/linux-2.6 test-devicetree
 
 Compile tested on: ppc64, ppc32, microblaze, sparc64, sparc32.
 Boot tested on mpc5200 (ppc32) platform.

test-devicetree as of today also works fine on my phyCORE-MPC5200B-IO.

Tested-by: Wolfram Sang w.s...@pengutronix.de

-- 
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] PPC: Sync guest visible MMU state

2009-11-26 Thread Avi Kivity


On 11/26/2009 01:16 PM, Alexander Graf wrote:

Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.

This patch exports enough of the MMU segment state to userspace to make
debugging work and thus also includes the groundwork for migration.


  struct kvm_sregs {
-   __u32 pvr;
-   char pad[1020];
+   union {
+   struct {
+   __u32 pvr;
+   __u64 sdr1;
+   struct {
+   struct {
+   __u64 slbe;
+   __u64 slbv;
+   } slb[64];
+   } ppc64;
+   struct {
+   __u32 sr[16];
+   __u64 ibat[8];
+   __u64 dbat[8];
+   } ppc32;
+   };
+   __u8 pad[1024];
+   };
  };
   


Please avoid unnamed unions in user-visible headers - they're a gcc 
extension.


Yes, we have them elsewhere, but let's not add to the pile.



  struct kvm_fpu {
diff --git a/arch/powerpc/include/asm/kvm_asm.h 
b/arch/powerpc/include/asm/kvm_asm.h
index 19ddb35..af2abe7 100644
--- a/arch/powerpc/include/asm/kvm_asm.h
+++ b/arch/powerpc/include/asm/kvm_asm.h
@@ -87,6 +87,7 @@
  #define BOOK3S_IRQPRIO_MAX16

  #define BOOK3S_HFLAG_DCBZ32   0x1
+#define BOOK3S_HFLAG_SLB   0x2

  #define RESUME_FLAG_NV  (10)  /* Reload guest nonvolatile state? */
  #define RESUME_FLAG_HOST(11)  /* Resume host? */
diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
b/arch/powerpc/include/asm/kvm_book3s.h
index c601133..74b7369 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -46,6 +46,7 @@ struct kvmppc_sr {
  };

  struct kvmppc_bat {
+   u64 raw;
u32 bepi;
u32 bepi_mask;
bool vs;
@@ -113,6 +114,8 @@ extern struct kvmppc_pte *kvmppc_mmu_find_pte(struct 
kvm_vcpu *vcpu, u64 ea, boo
  extern int kvmppc_ld(struct kvm_vcpu *vcpu, ulong eaddr, int size, void *ptr, 
bool data);
  extern int kvmppc_st(struct kvm_vcpu *vcpu, ulong eaddr, int size, void *ptr);
  extern void kvmppc_book3s_queue_irqprio(struct kvm_vcpu *vcpu, unsigned int 
vec);
+extern void kvmppc_set_bat(struct kvm_vcpu *vcpu, struct kvmppc_bat *bat,
+  bool upper, u32 val);

  extern u32 kvmppc_trampoline_lowmem;
  extern u32 kvmppc_trampoline_enter;
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 42037d4..650ebf8 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -281,6 +281,7 @@ void kvmppc_core_deliver_interrupts(struct kvm_vcpu *vcpu)

  void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)
  {
+   vcpu-arch.hflags= ~BOOK3S_HFLAG_SLB;
vcpu-arch.pvr = pvr;
if ((pvr= 0x33)  (pvr  0x7033)) {
kvmppc_mmu_book3s_64_init(vcpu);
@@ -762,14 +763,60 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, 
struct kvm_regs *regs)
  int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
struct kvm_sregs *sregs)
  {
+   int i;
+
sregs-pvr = vcpu-arch.pvr;
+
+   sregs-sdr1 = to_book3s(vcpu)-sdr1;
+   if (vcpu-arch.hflags  BOOK3S_HFLAG_SLB) {
+   for (i = 0; i  64; i++) {
+   sregs-ppc64.slb[i].slbe = 
to_book3s(vcpu)-slb[i].orige | i;
+   sregs-ppc64.slb[i].slbv = 
to_book3s(vcpu)-slb[i].origv;
+   }
+   } else {
+   for (i = 0; i  16; i++) {
+   sregs-ppc32.sr[i] = to_book3s(vcpu)-sr[i].raw;
+   sregs-ppc32.sr[i] = to_book3s(vcpu)-sr[i].raw;
+   }
+   for (i = 0; i  8; i++) {
+   sregs-ppc32.ibat[i] = to_book3s(vcpu)-ibat[i].raw;
+   sregs-ppc32.dbat[i] = to_book3s(vcpu)-dbat[i].raw;
+   }
+   }
return 0;
  }

  int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
struct kvm_sregs *sregs)
  {
+   int i;
+
kvmppc_set_pvr(vcpu, sregs-pvr);
+
+   to_book3s(vcpu)-sdr1 = sregs-sdr1;
+   if (vcpu-arch.hflags  BOOK3S_HFLAG_SLB) {
+   for (i = 0; i  64; i++) {
+   vcpu-arch.mmu.slbmte(vcpu, sregs-ppc64.slb[i].slbv,
+   sregs-ppc64.slb[i].slbe);
+   }
+   } else {
+   for (i = 0; i  16; i++) {
+   vcpu-arch.mmu.mtsrin(vcpu, i, sregs-ppc32.sr[i]);
+   }
+   for (i = 0; i  8; i++) {
+

Re: [PATCH] PPC: Sync guest visible MMU state

2009-11-26 Thread Alexander Graf

Avi Kivity wrote:
 On 11/26/2009 01:16 PM, Alexander Graf wrote:
 Currently userspace has no chance to find out which virtual address
 space we're
 in and resolve addresses. While that is a big problem for migration,
 it's also
 unpleasent when debugging, as gdb and the monitor don't work on virtual
 addresses.

 This patch exports enough of the MMU segment state to userspace to make
 debugging work and thus also includes the groundwork for migration.


   struct kvm_sregs {
 -__u32 pvr;
 -char pad[1020];
 +union {
 +struct {
 +__u32 pvr;
 +__u64 sdr1;
 +struct {
 +struct {
 +__u64 slbe;
 +__u64 slbv;
 +} slb[64];
 +} ppc64;
 +struct {
 +__u32 sr[16];
 +__u64 ibat[8];
 +__u64 dbat[8];
 +} ppc32;
 +};
 +__u8 pad[1024];
 +};
   };


 Please avoid unnamed unions in user-visible headers - they're a gcc
 extension.

 Yes, we have them elsewhere, but let's not add to the pile.

I'm open to scalable suggestions that don't break existing userspace code.
If I name the union now, existing qemu code will break. If I align the
pad array manually I'll definitely mess up something.

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

Re: [PATCH] PPC: Sync guest visible MMU state

2009-11-26 Thread Avi Kivity


On 11/26/2009 02:46 PM, Alexander Graf wrote:



Please avoid unnamed unions in user-visible headers - they're a gcc
extension.

Yes, we have them elsewhere, but let's not add to the pile.
 

I'm open to scalable suggestions that don't break existing userspace code.
If I name the union now, existing qemu code will break. If I align the
pad array manually I'll definitely mess up something.
   


You can keep pvr out of the (named) union.

--
error compiling committee.c: too many arguments to function

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

Re: [PATCH] PPC: Sync guest visible MMU state

2009-11-26 Thread Alexander Graf

Avi Kivity wrote:
 On 11/26/2009 02:46 PM, Alexander Graf wrote:

 Please avoid unnamed unions in user-visible headers - they're a gcc
 extension.

 Yes, we have them elsewhere, but let's not add to the pile.
  
 I'm open to scalable suggestions that don't break existing userspace
 code.
 If I name the union now, existing qemu code will break. If I align the
 pad array manually I'll definitely mess up something.


 You can keep pvr out of the (named) union.


So we'd have

sregs.padded.ppc64.slb?

I don't see how that is an improvement.


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

Re: [PATCH] PPC: Sync guest visible MMU state

2009-11-26 Thread Avi Kivity


On 11/26/2009 03:16 PM, Alexander Graf wrote:



You can keep pvr out of the (named) union.
 


So we'd have

sregs.padded.ppc64.slb?

   


or sregs.u.ppc64.slb.


I don't see how that is an improvement.
   


Buildability takes precedence.

(an alternative is to drop the union, and add a BUILD_BUG_ON(sizeof...)).

--
error compiling committee.c: too many arguments to function

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

fsl diu, edid info and i2c platform data

2009-11-26 Thread Kári Davíðsson


Hi,

I am messing about with the fsl-diu-fb.c which handles the display on mpc512x 
platforms.
The display panels we are using provide EDID information and I would like to 
use that to setup
the display modes etc. The current fsl-diu-fb.c is hard coding display modes 
into the driver.

I have started this and it is working more or less but I appreciate all input 
from more knowledgeable people
about how to do this correctly with the aim that others could benefit.
I have the feeling I am not approaching this correctly.

One option I was looking into was to use platform data for the i2c edid driver, 
e.g. for the platform to provide
default fb_mode. But I have a big problem on how to attach the platform data to 
the i2cedid driver.
I tried few options and while I think using code like :

np = of_find_compatible_node( NULL, NULL, vesa,edid );
if( np )
{
struct i2c_client * tsc2007 = NULL;

//tsc2007 = of_find_i2c_device_by_node( np );
if( tsc2007 )
{
tsc2007-dev.platform_data = v39_edid_data;
put_device( tsc2007-dev );
}
of_node_put( np );
}

is the correct way to do it. The function of_find_i2c_device_by_node() hangs 
the kernel.

Attached is the patch as I have it now. It compiles and works on our custom 
mpc5121 board for two different LCD panels.

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

Re: [RFC PATCH 04/19] powerpc: wii: device tree

Benjamin Herrenschmidt wrote:
 On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
 
 +/memreserve/ 0x0180 0xe80;  /* memory hole (includes I/O area) */
 +/memreserve/ 0x1000 0x0004000;  /* DSP RAM */
 
 Weird layout... nothing you can do about I suppose.
 
 Out of curiosity, what is that DSP RAM ? Some actual DSP core somewhere
 in the IO chip setup to use memory from up there ?
 

Yes, there's a DSP used normally for audio purposes.

 I'll skip on some things that I'm sure others will have commented
 about :-)
 

Ok :)

 +/*
 + * The Nintendo Wii has two discontiguous RAM memory areas called
 + * MEM1 and MEM2.
 + * MEM1 starts at 0x and contains 24MB of 1T-SRAM.
 + * MEM2 starts at 0x1000 and contains 64MB of DDR2 RAM.
 + * Between both memory address ranges there is an address space
 + * where memory-mapped I/O registers are found.
 + *
 + * Currently, Linux 32-bit PowerPC does not support RAM in
 + * discontiguous memory address spaces. Thus, in order to use
 + * both RAM areas, we declare as RAM the range from the start of
 + * MEM1 to the end of useable MEM2 and exclude the needed parts
 + * with /memreserve/ statements, at the expense of wasting a bit
 + * of memory.
 + */
 +memory {
 +device_type = memory;
 +/* MEM1 + memory hole + MEM2 - firmware/buffers area */
 +reg = 0x 0x133e;
 +};
 
 So we do have a nasty hole here in the middle. How bad it is if you try
 to just have two ranges in there (ie as if it was discontiguous) ? We
 shouldn't be far from being able to do discontig mem actually, should be
 easy enough to fix. Tho I don't have (yet) the HW :-) (I'm tempted...)
 

My plan is to just put the two ranges on the device tree (to reflect the actual 
hardware) and coalesce them in the fixup function of the bootwrapper.
Then add the needed reservations and hacks to make that work (mmu_mapin_ram / 
ioremap).

 Same comment as other discussions about the framebuffer here.
 

Ok.

 +cpus {
 +#cpus = 1;
 +#address-cells = 1;
 +#size-cells = 0;
 +
 +PowerPC,broad...@0 {
 +device_type = cpu;
 +reg = 0;
 +clock-frequency = 72900; /* 729MHz */
 +bus-frequency = 24300; /* 243MHz core-to-bus 3x */
 +timebase-frequency = 6075; /* 243MHz / 4 */
 +i-cache-line-size = 32;
 +d-cache-line-size = 32;
 +i-cache-size = 32768;
 +d-cache-size = 32768;
 +};
 +};
 +
 +/* devices contained in the hollywood chipset */
 +soc {
 
 Call it hollywood
 

I like that too. Simple and effective.

 +#address-cells = 1;
 +#size-cells = 1;
 +#interrupt-cells = 1;
 +model = hollywood;
 +compatible = nintendo,hollywood;
 +clock-frequency = 24300; /* 243MHz */
 +ranges = 0x0c00 0x0c00 0x0001
 +  0x0d00 0x0d00 0x0001
 +  0x0d04 0x0d04 0x0005
 +  0x0d80 0x0d80 0x1000
 +  0x133e 0x133e 0x00c2;
 +
 +vi...@0c002000 {
 +compatible = nintendo,hollywood-video;
 +reg = 0x0c002000 0x100;
 +interrupts = 8;
 +interrupt-parent = PIC0;
 +};
 +
 +PIC0: p...@0c003000 {
 +#interrupt-cells = 1;
 +compatible = nintendo,flipper-pic;
 +reg = 0x0c003000 0x8;
 +interrupt-controller;
 +};
 +
 +resetswi...@0c003000 {
 +compatible = nintendo,hollywood-resetswitch;
 +reg = 0x0c003000 0x4;
 +interrupts = 1;
 +interrupt-parent = PIC0;
 +};
 +
 +au...@0c005000 {
 +compatible = nintendo,hollywood-audio;
 +reg = 0x0c005000 0x200 /* DSP */
 +   0x0d006c00 0x20;/* AI */
 +interrupts = 6;
 +interrupt-parent = PIC0;
 +};
 +
 +/* Team Twiizers' 'mini' firmware IPC */
 
 Out of curiosity, what are these ? :-)
 

Those are the guys behind most Wii hacking efforts.

 +m...@0d00 {
 +#address-cells = 1;
 +#size-cells = 1;
 +#interrupt-cells = 1;
 +compatible = twiizers,starlet-mini-ipc;
 +reg = 0x0d00 0x40  /* IPC */
 +   0x13fc 0x4; /* mini header pointer */
 +};
 +
 +ser...@0d006400 {
 +

Re: fsl diu, edid info and i2c platform data

2009-11-26 Thread Kári Davíðsson


Forgot the patch.


Kári Davíðsson wrote:

Hi,

I am messing about with the fsl-diu-fb.c which handles the display on mpc512x 
platforms.
The display panels we are using provide EDID information and I would like to 
use that to setup
the display modes etc. The current fsl-diu-fb.c is hard coding display modes 
into the driver.

I have started this and it is working more or less but I appreciate all input 
from more knowledgeable people
about how to do this correctly with the aim that others could benefit.
I have the feeling I am not approaching this correctly.

One option I was looking into was to use platform data for the i2c edid driver, 
e.g. for the platform to provide
default fb_mode. But I have a big problem on how to attach the platform data to 
the i2cedid driver.
I tried few options and while I think using code like :

 np = of_find_compatible_node( NULL, NULL, vesa,edid );
 if( np )
 {
 struct i2c_client * tsc2007 = NULL;

 //tsc2007 = of_find_i2c_device_by_node( np );
 if( tsc2007 )
 {
 tsc2007-dev.platform_data = v39_edid_data;
 put_device( tsc2007-dev );
 }
 of_node_put( np );
 }

is the correct way to do it. The function of_find_i2c_device_by_node() hangs 
the kernel.

Attached is the patch as I have it now. It compiles and works on our custom 
mpc5121 board for two different LCD panels.

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

diff --git a/arch/powerpc/boot/dts/v39.dts b/arch/powerpc/boot/dts/v39.dts
new file mode 100644
index 000..c5a5eec
--- /dev/null
+++ b/arch/powerpc/boot/dts/v39.dts
@@ -0,0 +1,285 @@
+/*
+ * V39 Device Tree Source
+ *
+ * Copyright 2009 Marel ehf.
+ * Copyright 2007,2008 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+	model = v39;
+	compatible = marel,v39;
+	#address-cells = 1;
+	#size-cells = 1;
+
+	cpus {
+		#address-cells = 1;
+		#size-cells = 0;
+
+		PowerPC,5...@0 {
+			device_type = cpu;
+			reg = 0;
+			d-cache-line-size = 0x20;	// 32 bytes
+			i-cache-line-size = 0x20;	// 32 bytes
+			d-cache-size = 0x8000;	// L1, 32K
+			i-cache-size = 0x8000;	// L1, 32K
+			timebase-frequency = 4950;// 49.5 MHz (csb/4)
+			bus-frequency = 19800;	// 198 MHz csb bus
+			clock-frequency = 39600;	// 396 MHz ppc core
+		};
+	};
+
+	memory {
+		device_type = memory;
+		reg = 0x 0x1000;	// 256MB at 0
+	};
+
+	m...@2000 {
+		compatible = fsl,mpc5121-mbx;
+		reg = 0x2000 0x4000;
+		interrupts = 66 0x8;
+		interrupt-parent =  ipic ;
+	};
+
+	s...@3000 {
+		compatible = fsl,mpc5121-sram;
+		reg = 0x3000 0x2;		// 128K at 0x3000
+	};
+
+	s...@8000 {
+		compatible = fsl,mpc5121-immr;
+		#address-cells = 1;
+		#size-cells = 1;
+		#interrupt-cells = 2;
+		ranges = 0x0 0x8000 0x40;
+		reg = 0x8000 0x40;
+		bus-frequency = 6600;	// 66 MHz ips bus
+
+
+		// IPIC
+		// interrupts cell = intr #, sense
+		// sense values match linux IORESOURCE_IRQ_* defines:
+		// sense == 8: Level, low assertion
+		// sense == 2: Edge, high-to-low change
+		//
+		ipic: interrupt-control...@c00 {
+			compatible = fsl,mpc5121-ipic, fsl,ipic;
+			interrupt-controller;
+			#address-cells = 0;
+			#interrupt-cells = 2;
+			reg = 0xc00 0x100;
+		};
+
+		r...@a00 {	// Real time clock
+			compatible = fsl,mpc5121-rtc;
+			reg = 0xa00 0x100;
+			interrupts = 79 0x8 80 0x8;
+			interrupt-parent =  ipic ;
+		};
+
+		cl...@f00 {	// Clock control
+			compatible = fsl,mpc5121-clock;
+			reg = 0xf00 0x100;
+		};
+
+/*
+		g...@1100 {
+			compatible = fsl,mpc5121-gpio;
+			reg = 0x1100 0x100;
+			interrupts = 78 0x8;
+			interrupt-parent =  ipic ;
+		};
+*/
+
+		ms...@1300 {
+			compatible = fsl,mpc5121-mscan;
+			cell-index = 0;
+			interrupts = 12 0x8;
+			interrupt-parent =  ipic ;
+			reg = 0x1300 0x80;
+			clock-ipb;
+		};
+
+		ms...@1380 {
+			compatible = fsl,mpc5121-mscan;
+			cell-index = 1;
+			interrupts = 13 0x8;
+			interrupt-parent =  ipic ;
+			reg = 0x1380 0x80;
+			clock-ipb;
+		};
+
+		edidbus: i...@1700 {
+			#address-cells = 1;
+			#size-cells = 0;
+			compatible = fsl,mpc5121-i2c, fsl-i2c;
+			cell-index = 0;
+			reg = 0x1700 0x20;
+			interrupts = 9 0x8;
+			interrupt-parent =  ipic ;
+			fsl5200-clocking;
+			edid: e...@50 {
+compatible = vesa,edid;
+reg = 0x50;
+			};
+		};
+
+		i...@1720 {
+			#address-cells = 1;
+			#size-cells = 0;
+			compatible = fsl,mpc5121-i2c, fsl-i2c;
+			cell-index = 1;
+			reg = 0x1720 0x20;
+			interrupts = 10 0x8;
+			interrupt-parent =  ipic ;
+			fsl5200-clocking;
+		};
+
+		i...@1740 {
+			#address-cells = 1;
+

Re: [RFC PATCH 04/19] powerpc: wii: device tree

Benjamin Herrenschmidt wrote:
 On Wed, 2009-11-25 at 18:49 +0100, Segher Boessenkool wrote:
 +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
 Like others have said already, don't do this.  If you need
 a workaround, put it in the platform code.

 +/memreserve/ 0x1000 0x0004000; /* DSP RAM */
 This address is fixed in the DSP hardware, right?  If not,
 you shouldn't do a reserve here.

 +   chosen {
 +   /* root filesystem on 2nd partition of SD card */
 +   bootargs = nobats root=/dev/mmcblk0p2 rootwait udbg-immortal;
 Question: why do you need/want nobats?
 
 Good point. I can't even guarantee that the kernel will work reliably
 with nobats :-) At least you really want the kernel .text to be fully
 covered by an IBAT.
 

It works with nobats.
I must say that all the patches posted (and the device drivers, which haven't 
been posted yet) are tested and working code.

 What does this clock freq mean?  Hollywood has lots of
 clocks, many of them configurable.  Bus frequency is in
 the cpu node already.  The binding doesn't say what this
 is either, since you didn't write a binding :-)

 Just remove it?
 
 BTW. If we want to play with clocks, maybe you should look at
 my proposed binding for clocks and implementing the clk API :-)
 
 +   ranges = 0x0c00 0x0c00 0x0001
 + 0x0d00 0x0d00 0x0001
 + 0x0d04 0x0d04 0x0005
 + 0x0d80 0x0d80 0x1000
 All of 0cXX and 0dXX actually.

 + 0x133e 0x133e 0x00c2;
 This is just part of MEM2, don't treat it special here.

 +   vi...@0c002000 {
 +   compatible = nintendo,hollywood-video;
 +   reg = 0x0c002000 0x100;
 +   interrupts = 8;
 +   interrupt-parent = PIC0;
 If you say interrupt-parent = .. in the root node, you can
 leave it out in most of the rest of the tree.  Using the Flipper
 PIC for this sounds like a good plan.
 
 Well, for the rest of the tree except stuff whose interrupt parent
 is PIC1. With two PICs I prefer being explicit.
 

Let it be specific then :)

 +   PIC0: p...@0c003000 {
 +   #interrupt-cells = 1;
 +   compatible = nintendo,flipper-pic;
 +   reg = 0x0c003000 0x8;
 This register block is bigger actually.  It's not only PIC,
 but some other bus stuff as well, dunno what to do here.
 
 Add nodes for the other things ?
 
 +   interrupt-controller;
 +   };
 +
 +   resetswi...@0c003000 {
 +   compatible = nintendo,hollywood-resetswitch;
 +   reg = 0x0c003000 0x4;
 That's the same address.  Don't do that.

 Create a flipper-processor-interface node for the whole 3000
 block (size 100)?  You can hang the PIC as a subnode under it,
 without a reg.
 
 Yeah.
 

Agreed.

 +   /* Team Twiizers' 'mini' firmware IPC */
 +   m...@0d00 {
 Although mini is awesome, it isn't hardware, and doesn't
 belong in the device tree.
 
 So what is at d000 ?
 

There you can find the hardware interface that supports the IPC mechanism.
It is made up of a pair of registers to pass data between the processors and a 
pair of control/flags registers.
The hardware can interrupt the PowerPC side when there is data available for it.

 +   ser...@0d006400 {
 +   compatible = nintendo,hollywood-serial;
 You might want to pick a more descriptive name for this,
 serial is usually understaood to mean RS232.  Which
 this isn't.
 
 What is it then ? You definitely want some other name if it's not
 classic rs232 style serial.
 

It is what Nintendo calls the Serial Interface (SI) which is a proprietary 
serial hardware to drive the gamepads (and a custom keyboard too, once 
available for an RPG game).

 Cheers,
 Ben.
 

Thanks,
Albert

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

Re: [RFC PATCH 04/19] powerpc: wii: device tree

Benjamin Herrenschmidt wrote:
 On Wed, 2009-11-25 at 19:34 +0100, Albert Herranz wrote:
 We need nobats (or a hack in the mmu_mapin_ram() code) because of the
 discontiguous ram problem.
 
 I would vote for a hack in mmu_mapin_ram() for now.
 

I'll cook that.

 Cheers,
 Ben.
 

Thanks,
Albert


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

Re: [RFC PATCH 06/19] powerpc: gamecube/wii: introduce GAMECUBE_COMMON

Benjamin Herrenschmidt wrote:
 On Tue, 2009-11-24 at 19:03 +0100, Albert Herranz wrote:
 Segher Boessenkool wrote:
 Add a config option GAMECUBE_COMMON to be used as a dependency for all
 options common to the Nintendo GameCube and Wii video game consoles.
 Maybe something like GAMECUBE_OR_WII instead?  COMMON is so
 common it's meaningless.

 I don't like either GAMECUBE_OR_WII.
 It looks as if it can be used to match options for the GAMECUBE _or_ WII. 
 But that's not the meaning of it.

 This option should be used only for options applicable to both the GAMECUBE 
 and WII, i.e. basically those options in the WII which where inherited 
 from the GAMECUBE to make it retro-compatible.

 If GAMECUBE_COMMON is unacceptable, maybe GAMECUBE_LEGACY or GAMECUBE_COMPAT?
 
 I don't have any strong opinion. Maybe NINTENDO_COMMON ?
 

We should avoid using NINTENDO just to refer to the Nintendo GameCube or Wii. 
They have other consoles too :)
There's even a port of Linux to the Nintendo DS...

I'd stick to GAMECUBE_COMMON or GAMECUBE_COMPAT.

 Cheers,
 Ben.
 

Thanks,
Albert

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

Re: [RFC PATCH 09/19] powerpc: gamecube/wii: udbg support for usbgecko

Benjamin Herrenschmidt wrote:
 On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
 Add support for using the USB Gecko adapter via the udbg facility on
 the Nintendo GameCube and Wii video game consoles.
 The USB Gecko is a 3rd party memory card interface adapter that provides
 a EXI (External Interface) to USB serial converter.
 
 The main issue here is that the gecko is supposed to be something you
 can plug or unplug no ? Is it hotswap or only at boot ? In the later
 case, maybe the node should be created by the boot wrapper when
 detecting the presence of the device. If it's hotplug, then we need
 something smarter...
 

The usbgecko is hotplugable and hotswappable.
But as this is mostly a developer feature, not normaly used by end users, I 
think that we can just let it be as it is: autodetect it on boot (now probing 
for it instead of using information from the device tree).
If you unplug it later it causes no errors, you just miss whatever data is sent 
to it.

 Cheers,
 Ben.
 

Thanks,
Albert


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

Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support

Benjamin Herrenschmidt wrote:
 On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
 
 +static void flipper_pic_mask_and_ack(unsigned int virq)
 +{
 +int irq = virq_to_hw(virq);
 +void __iomem *io_base = get_irq_chip_data(virq);
 +
 +clear_bit(irq, io_base + FLIPPER_IMR);
 +set_bit(irq, io_base + FLIPPER_ICR);
 +}
 
 Do not use clear_bit and set_bit on IOs. They will do lwarx/stwcx. which
 is really not what you want. You can use __clear_bit and __set_bit but
 it's still fishy. Those operate on unsigned long, so the size vary
 between 32 and 64 bit etc... not something you care that much about, but
 it's still the wrong tool for the job.
 
 Do those guys have more than 32 interrupts ? If not, just hand
 code the msak  shifts. If they do, then maybe stick with __clear_bit()
 and __set_bit() which are the non atomic variants.
 

There can be only 32 interrupt sources per pic.
I'll build a mask and check if just a simple write works too (it should IMHO), 
instead of a RWM.

 Cheers,
 Ben.
 

Thanks,
Albert

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

Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support

Benjamin Herrenschmidt wrote:
 On Sun, 2009-11-22 at 16:28 -0700, Grant Likely wrote:
 +unsigned int flipper_pic_get_irq(void)
 +{
 +   void __iomem *io_base = flipper_irq_host-host_data;
 +   int irq;
 +   u32 irq_status;
 +
 +   irq_status = in_be32(io_base + FLIPPER_ICR) 
 +in_be32(io_base + FLIPPER_IMR);
 +   if (irq_status == 0)
 +   return -1;  /* no more IRQs pending */
 NO_IRQ_IGNORE 
 
 Why no just 0 ? (aka NO_IRQ)
 

I didn't know about 0 (I thought that was another valid interrupt).
I was used to -1 to tell that no IRQs were pending (at least from the ARCH=ppc 
days) :)

 Or do you know you are getting lots of spurrious that you don't want to
 account ?
 

No, this is not the case here.

 Cheers,
 Ben.
 

Thanks,
Albert

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

Re: [RFC PATCH 14/19] powerpc: allow ioremap within reserved fake ram regions

Benjamin Herrenschmidt wrote:
 On Tue, 2009-11-24 at 18:09 +0100, Albert Herranz wrote:
 I could use ppc_md.ioremap to duplicate ioremap except for the ioremap
 ram check.
 But calling the stock ioremap without modifying it is not possible
 because it checks and bails out when ioremapping a region marked as
 ram (even if it's not real ram and it's memreserved).

 Is the list of memreserved areas preserved once the kernel is running?
 If it is preserved another option would be to unban ioremapping ram if
 memreserved.
 
 Yes, check lmb's they should still be around.
 

Good.
So adding a kconfig option to allow ioremapping memreserved memory marked as 
ram and adding a proper check (under that kconfig) to unban this case in 
ioremap would be an acceptable solution?

 Cheers,
 Ben.
 

Thanks,
Albert

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

Re: [RFC PATCH 16/19] powerpc: wii: hollywood interrupt controller support

Benjamin Herrenschmidt wrote:
 On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
 
 +static void hlwd_pic_mask_and_ack(unsigned int virq)
 +{
 +int irq = virq_to_hw(virq);
 +void __iomem *io_base = get_irq_chip_data(virq);
 +
 +clear_bit(irq, io_base + HW_BROADWAY_IMR);
 +set_bit(irq, io_base + HW_BROADWAY_ICR);
 +}
 
 Same comment as with flipper. BTW. It looks really similar, can't you
 use the same driver ?
 

I'll look at it. Surely, parts of it would be mergeable.

 Cheers,
 Ben.
 

Thanks,
Albert

 
 

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

Re: spi_mpc8xxx.c: chip select polarity problem

2009-11-26 Thread Torsten Fleischer

On Thu, Nov 26, 2009 at 13:12:04 Anton Vorontsov wrote:
[...]
  Ah.  I understand what you're doing now.   Hmmm.  This approach
  concerns me because it relies on firmware or platform code to get CS
  gpios set up properly before the driver is probed.
 
 Yes, that was said at the very beginning of this thread.
 
   Firmware doesn't
  always get it right, and I prefer to avoid platform specific setups as
  much as possible.  Why can't the CS polarity be encoded into the
  device tree so the driver *does* have the polarity data at probe time?
 
 We have the spi-cs-high property, but it duplicates compatible
 property. 'compatible' is enough to tell whether some device has
 cs-high or cs-low (device's driver knows that already).
 
 The problem is that SPI bus master doesn't know all the devices,
 so it can't extract that information from the compatible string.
 To workaround that we can use 'spi-cs-high', but that's ugly
 workaround.
 
 SPI modes (0,1,2,3) is another matter, some devices can work in
 several modes, so 'spi-cpol' and 'spi-cpha' are actually useful.
 
To get a sane initial state the needed GPIOs can be set to be inputs during 
the driver's initialization.
This requires pull-up/pull-down resistors connected to the chip select 
lines. I think we can assume that they exist, because the GPIOs are all inputs 
after the controller's hardware reset and the resistors are needed to have a 
well-defined voltage level on the chip select lines. Normally the level is set 
so that the devices are disabled.

Therefore, it doesn't matter if the firmware sets the GPIOs wrong.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: spi_mpc8xxx.c: chip select polarity problem

On Thu, Nov 26, 2009 at 5:12 AM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
 On Wed, Nov 25, 2009 at 03:11:57PM -0700, Grant Likely wrote:
 On Wed, Nov 25, 2009 at 1:41 PM, Torsten Fleischer
 to-fleisc...@t-online.de wrote:
  On Wen, Nov 25, 2009 at 01:33:57 Grant Likely wrote:
  Thanks.  However, there needs to be a proper description of what this
  patch does to go in the commit header.  Can you please write one?
 
  Thanks,
  g.
 
  [...]
 
  The initialization of the chip selects is removed from the probe() 
  function of
  the spi_mpc8xxx driver, because the driver doesn't know the polarity of the
  chip selects of the SPI devices at the time of its initialization.
 
  For this reason the initialization of the several chip selects is postponed
  to the point of time when the very first SPI transfer to the associated 
  device
  occurs.
 
 
  Signed-off-by: Torsten Fleischer to-fleisc...@t-online.de

 Ah.  I understand what you're doing now.   Hmmm.  This approach
 concerns me because it relies on firmware or platform code to get CS
 gpios set up properly before the driver is probed.

 Yes, that was said at the very beginning of this thread.

I also came in part way through as I wasn't an SPI maintainer when
this thread started.  :-)

  Firmware doesn't
 always get it right, and I prefer to avoid platform specific setups as
 much as possible.  Why can't the CS polarity be encoded into the
 device tree so the driver *does* have the polarity data at probe time?

 We have the spi-cs-high property, but it duplicates compatible
 property. 'compatible' is enough to tell whether some device has
 cs-high or cs-low (device's driver knows that already).

But the device's driver isn't controlling the CS line, the SPI bus
driver is.  Besides, there is no guarantee that all drivers will
actualy be loaded before something starts using SPI.  The bus driver
*must* know what the active state of each CS line is before activating
any devices.

The spi bus binding is deficient in this case.  A property (can be
optional) need to be added to the spi bus node to explicitly state the
CS polarities.  It's not entirely sane to look for a spi-cs-high'
property in the spi device nodes because the SPI bus may not be fully
populated (ie. if a device happens to be sitting on the bus, but isn't
in the device tree yet).  Before any SPI transactions go out, it is
the responsibility of the bus driver to ensure all CS lines are in the
correct state.

 The problem is that SPI bus master doesn't know all the devices,
 so it can't extract that information from the compatible string.
 To workaround that we can use 'spi-cs-high', but that's ugly
 workaround.

It doesn't need to know about the devices, but is must know how all of
its CS lines behave.  So it isn't an really an ugly workaround, but I
do think the binding is insufficient for the SPI bus driver (see
below)

 SPI modes (0,1,2,3) is another matter, some devices can work in
 several modes, so 'spi-cpol' and 'spi-cpha' are actually useful.

yes.  spi-cpol and spi-cpha are actually properties of the device, and
belong in the spi device node, not the spi bus node.

The spi-cs-high property is defined in
Documentation/powerpc/dts-bindings/spi-bus.txt, but it definitely was
a mistake for the reasons I described above.  It does work in some
cases, but a property at the bus node would be better.  The driver can
still fallback to looking for spi-cs-high properties in child nodes.

Currently the spi-cs-high property is parsed in the
of_register_spi_devices() function, but the CS polarity needs to be
known before registering devices.  It needs to be factored out into
another utility function callable by spi bus drivers so that it can
get polarity data at probe time.

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: spi_mpc8xxx.c: chip select polarity problem

On Thu, Nov 26, 2009 at 10:27 AM, Torsten Fleischer
to-fleisc...@t-online.de wrote:
 On Thu, Nov 26, 2009 at 13:12:04 Anton Vorontsov wrote:
 [...]
  Ah.  I understand what you're doing now.   Hmmm.  This approach
  concerns me because it relies on firmware or platform code to get CS
  gpios set up properly before the driver is probed.

 Yes, that was said at the very beginning of this thread.

   Firmware doesn't
  always get it right, and I prefer to avoid platform specific setups as
  much as possible.  Why can't the CS polarity be encoded into the
  device tree so the driver *does* have the polarity data at probe time?

 We have the spi-cs-high property, but it duplicates compatible
 property. 'compatible' is enough to tell whether some device has
 cs-high or cs-low (device's driver knows that already).

 The problem is that SPI bus master doesn't know all the devices,
 so it can't extract that information from the compatible string.
 To workaround that we can use 'spi-cs-high', but that's ugly
 workaround.

 SPI modes (0,1,2,3) is another matter, some devices can work in
 several modes, so 'spi-cpol' and 'spi-cpha' are actually useful.

 To get a sane initial state the needed GPIOs can be set to be inputs during
 the driver's initialization.
 This requires pull-up/pull-down resistors connected to the chip select
 lines. I think we can assume that they exist, because the GPIOs are all inputs
 after the controller's hardware reset and the resistors are needed to have a
 well-defined voltage level on the chip select lines. Normally the level is set
 so that the devices are disabled.

 Therefore, it doesn't matter if the firmware sets the GPIOs wrong.

No, that's just shifting responsibility from firmware to hardware.
There is just as much broken hardware out there as broken firmware.
The assumption cannot be made that the initial state of the pin is the
inactive state of the CS line.  Plus, some GPIO pins are output only
and the inital state cannot be read.

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: spi_mpc8xxx.c: chip select polarity problem

2009-11-26 Thread Anton Vorontsov

On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote:
[...]
 The spi-cs-high property is defined in
 Documentation/powerpc/dts-bindings/spi-bus.txt, but it definitely was
 a mistake

Yup.

 Currently the spi-cs-high property is parsed in the
 of_register_spi_devices() function, but the CS polarity needs to be
 known before registering devices.  It needs to be factored out into
 another utility function callable by spi bus drivers so that it can
 get polarity data at probe time.

Untill we have this, Torsten's patch is a real improvement, and
works for non-broken hw/fw.

So I think it should be applied.

Thanks,

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: spi_mpc8xxx.c: chip select polarity problem

On Thu, Nov 26, 2009 at 11:41 AM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
 On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote:
 [...]
 The spi-cs-high property is defined in
 Documentation/powerpc/dts-bindings/spi-bus.txt, but it definitely was
 a mistake

 Yup.

 Currently the spi-cs-high property is parsed in the
 of_register_spi_devices() function, but the CS polarity needs to be
 known before registering devices.  It needs to be factored out into
 another utility function callable by spi bus drivers so that it can
 get polarity data at probe time.

 Untill we have this, Torsten's patch is a real improvement, and
 works for non-broken hw/fw.

 So I think it should be applied.

I disagree since it only band-aids the problem and uglifies the driver
in the process.  In the immediate term the driver needs to be changed
to read the spi-cs-high property out of the child nodes before
registering the devices.  I'm not going to apply this patch.

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: spi_mpc8xxx.c: chip select polarity problem

2009-11-26 Thread Anton Vorontsov

On Thu, Nov 26, 2009 at 11:50:05AM -0700, Grant Likely wrote:
 On Thu, Nov 26, 2009 at 11:41 AM, Anton Vorontsov
 avoront...@ru.mvista.com wrote:
  On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote:
  [...]
  The spi-cs-high property is defined in
  Documentation/powerpc/dts-bindings/spi-bus.txt, but it definitely was
  a mistake
 
  Yup.
 
  Currently the spi-cs-high property is parsed in the
  of_register_spi_devices() function, but the CS polarity needs to be
  known before registering devices.  It needs to be factored out into
  another utility function callable by spi bus drivers so that it can
  get polarity data at probe time.
 
  Untill we have this, Torsten's patch is a real improvement, and
  works for non-broken hw/fw.
 
  So I think it should be applied.
 
 I disagree since it only band-aids the problem and uglifies the driver
 in the process.  In the immediate term the driver needs to be changed
 to read the spi-cs-high property out of the child nodes before
 registering the devices.

Hm. I thought we agreed that spi-cs-high is not good? Why do you
encourage using it then? We'll have to uglify the driver with
legacy device-tree handling code.

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: spi_mpc8xxx.c: chip select polarity problem

On Thu, Nov 26, 2009 at 12:01 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
 On Thu, Nov 26, 2009 at 11:50:05AM -0700, Grant Likely wrote:
 On Thu, Nov 26, 2009 at 11:41 AM, Anton Vorontsov
 avoront...@ru.mvista.com wrote:
  On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote:
  [...]
  The spi-cs-high property is defined in
  Documentation/powerpc/dts-bindings/spi-bus.txt, but it definitely was
  a mistake
 
  Yup.
 
  Currently the spi-cs-high property is parsed in the
  of_register_spi_devices() function, but the CS polarity needs to be
  known before registering devices.  It needs to be factored out into
  another utility function callable by spi bus drivers so that it can
  get polarity data at probe time.
 
  Untill we have this, Torsten's patch is a real improvement, and
  works for non-broken hw/fw.
 
  So I think it should be applied.

 I disagree since it only band-aids the problem and uglifies the driver
 in the process.  In the immediate term the driver needs to be changed
 to read the spi-cs-high property out of the child nodes before
 registering the devices.

 Hm. I thought we agreed that spi-cs-high is not good? Why do you
 encourage using it then? We'll have to uglify the driver with
 legacy device-tree handling code.

spi-cs-high is definitely not a complete solution, but it isn't
actively evil either.  Plus it is documented and (presumably) in
active use. so support for it should not be dropped.

Regardless, there needs to be a library function for parsing all the
SPI child nodes and returning the active state for each GPIO chip
select.  All the code for parsing the old spi-cs-high properties can
be contained in the same place as a new yet-to-be-defined bus node cs
polarity property.  The rework to the driver itself is not ugly.

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: [PATCH] Reserve memory for kdump kernel within RMO region

2009-11-26 Thread Bernhard Walle

M. Mohan Kumar schrieb:
 On 11/26/2009 12:22 AM, Bernhard Walle wrote:
 M. Mohan Kumar schrieb:
 Reserve memory for kdump kernel within RMO region

 When the kernel size exceeds 32MB(observed with some distros), memory
 for kdump kernel can not be reserved as kdump kernel base is assumed to
 be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled,
 provide the feature to reserve the memory for kdump kernel anywhere in
 the RMO region.
 
 Hi Bernhard,
 
 Correct me if I'm wrong, but: CONFIG_RELOCATABLE is for the kernel that
 gets loaded as crashkernel, not for the kernel that loads the
 crashkernel. So it would be perfectly fine that a kernel that has not
 CONFIG_RELOCATABLE set would load another kernel that has
 CONFIG_RELOCATABLE set on an address != 32 M.
 
 No, with relocatable option, the same kernel is used as both production 
 and kdump kernel.

Can be, but it's not strictly necessary. It depends what userland does.
Especially it's possible that a non-relocatable, self-compiled kernel
loads a relocatable distribution kernel as capture kernel.

Also, it would make sense to make the behaviour symmetric across
platforms. Currently we have:

 - x86 and ia64: Without offset on command line, use any offset
 With offset on command line, use that offset and fail
 if no memory is available at that offset.
 - ppc64: Always use 32M and ignore the offset.

If your patch gets applied, we have:

 - ppc64: With CONFIG_RELOCATABLE, use any offset
  With offset on command

I don't see why the behaviour on ppc64 should be completely different.

Having maintained kdump for SUSE for x86, ia64 and partly ppc64 in the
past, I always felt that ppc64 is more different from x86 than ia64 is
from x86. That's one more step into that direction without a technical
reason.

Having that all said: If your patch gets in mainline kernel, than we
should change the behaviour also for x86 and ia64.



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

[PATCH v6 0/2] pseries: Add cede support for cpu-offline

2009-11-26 Thread Vaidyanathan Srinivasan

Hi,

This is version 6 of patch series that provides a framework to choose the state
a pseries CPU must be put to when it is offlined.

Previous versions can be found here:
Version 5: http://lkml.org/lkml/2009/10/30/6
Version 4: http://lkml.org/lkml/2009/10/9/59
Version 3: http://lkml.org/lkml/2009/9/15/164
Version 2: http://lkml.org/lkml/2009/8/28/102
Version 1: http://lkml.org/lkml/2009/8/6/236

Changes from the previous version include:

- Built on Nathan Fontenot's v3 of Kernel handling of Dynamic
  Logical Partitioning http://lkml.org/lkml/2009/11/25/21

- Rebased to powerpc.git tree and hence dropped 1st and 2nd patch in
  the stack since they are already in the powerpc.git tree:

  With reference to previous version,

  Dropped:
  1/4 pSeries: extended_cede_processor() helper function
  2/4 pSeries: Add hooks to put the CPU into an appropriate offline state

  Posting only:
  3/4 pseries: Add code to online/offline CPUs of a DLPAR node
  4/4 pseries: Serialize cpu hotplug operations during deactivate Vs deallocate

  Minor changes in the above patchs due to changes in Nathan's routines.

Also,

- This approach addresses Peter Z's objections regarding layering
  violations. The user simply offlines the cpu and doesn't worry about what
  state the CPU should be put into. That part is automatically handled by the
  kernel.

  Acked-by: Peter Zijlstra a.p.zijls...@chello.nl
  http://lkml.org/lkml/2009/11/11/328

- It does not add any additional sysfs interface instead uses the existing
  sysfs interface to offline CPUs.

- On platforms which do not have support for ceding the vcpu with a
  latency specifier value, the offlining mechanism defaults to the current
  method of calling rtas_stop_self().

This patchset is based on powerpc.git + Nathan's patches and has been built and
tested on pseries platforms.  This series can be applied to powerpc.git after
Nathan's patches.

Thanks,
Vaidy

---

Gautham R Shenoy (2):
  pseries: Serialize cpu hotplug operations during deactivate Vs deallocate
  pseries: Add code to online/offline CPUs of a DLPAR node


 arch/powerpc/platforms/pseries/dlpar.c |  144 ++--
 drivers/base/cpu.c |2 
 include/linux/cpu.h|   13 +++
 3 files changed, 150 insertions(+), 9 deletions(-)

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

[PATCH v6 1/2] pseries: Add code to online/offline CPUs of a DLPAR node

2009-11-26 Thread Vaidyanathan Srinivasan

From: Gautham R Shenoy e...@in.ibm.com

Currently the cpu-allocation/deallocation on pSeries is a
two step process from the Userspace.

- Set the indicators and update the device tree by writing to the sysfs
  tunable probe during allocation and release during deallocation.
- Online / Offline the CPUs of the allocated/would_be_deallocated node by
  writing to the sysfs tunable online.

This patch adds kernel code to online/offline the CPUs soon_after/just_before
they have been allocated/would_be_deallocated. This way, the userspace tool
that performs DLPAR operations would only have to deal with one set of sysfs
tunables namely probe and release.

Signed-off-by: Gautham R Shenoy e...@in.ibm.com
Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
Acked-by: Vaidyanathan Srinivasan sva...@linux.vnet.ibm.com
---

 arch/powerpc/platforms/pseries/dlpar.c |  101 
 1 files changed, 101 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/dlpar.c 
b/arch/powerpc/platforms/pseries/dlpar.c
index fe8d4b3..642e1b2 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -16,6 +16,7 @@
 #include linux/proc_fs.h
 #include linux/spinlock.h
 #include linux/cpu.h
+#include offline_states.h
 
 #include asm/prom.h
 #include asm/machdep.h
@@ -287,6 +288,98 @@ int dlpar_detach_node(struct device_node *dn)
return 0;
 }
 
+int online_node_cpus(struct device_node *dn)
+{
+   int rc = 0;
+   unsigned int cpu;
+   int len, nthreads, i;
+   const u32 *intserv;
+
+   intserv = of_get_property(dn, ibm,ppc-interrupt-server#s, len);
+   if (!intserv)
+   return -EINVAL;
+
+   nthreads = len / sizeof(u32);
+
+   cpu_maps_update_begin();
+   for (i = 0; i  nthreads; i++) {
+   for_each_present_cpu(cpu) {
+   if (get_hard_smp_processor_id(cpu) != intserv[i])
+   continue;
+   BUG_ON(get_cpu_current_state(cpu)
+   != CPU_STATE_OFFLINE);
+   cpu_maps_update_done();
+   rc = cpu_up(cpu);
+   if (rc)
+   goto out;
+   cpu_maps_update_begin();
+
+   break;
+   }
+   if (cpu == num_possible_cpus())
+   printk(KERN_WARNING Could not find cpu to online 
+  with physical id 0x%x\n, intserv[i]);
+   }
+   cpu_maps_update_done();
+
+out:
+   return rc;
+
+}
+
+int offline_node_cpus(struct device_node *dn)
+{
+   int rc = 0;
+   unsigned int cpu;
+   int len, nthreads, i;
+   const u32 *intserv;
+
+   intserv = of_get_property(dn, ibm,ppc-interrupt-server#s, len);
+   if (!intserv)
+   return -EINVAL;
+
+   nthreads = len / sizeof(u32);
+
+   cpu_maps_update_begin();
+   for (i = 0; i  nthreads; i++) {
+   for_each_present_cpu(cpu) {
+   if (get_hard_smp_processor_id(cpu) != intserv[i])
+   continue;
+
+   if (get_cpu_current_state(cpu) == CPU_STATE_OFFLINE)
+   break;
+
+   if (get_cpu_current_state(cpu) == CPU_STATE_ONLINE) {
+   cpu_maps_update_done();
+   rc = cpu_down(cpu);
+   if (rc)
+   goto out;
+   cpu_maps_update_begin();
+   break;
+
+   }
+
+   /*
+* The cpu is in CPU_STATE_INACTIVE.
+* Upgrade it's state to CPU_STATE_OFFLINE.
+*/
+   set_preferred_offline_state(cpu, CPU_STATE_OFFLINE);
+   BUG_ON(plpar_hcall_norets(H_PROD, intserv[i])
+   != H_SUCCESS);
+   __cpu_die(cpu);
+   break;
+   }
+   if (cpu == num_possible_cpus())
+   printk(KERN_WARNING Could not find cpu to offline 
+  with physical id 0x%x\n, intserv[i]);
+   }
+   cpu_maps_update_done();
+
+out:
+   return rc;
+
+}
+
 #define DR_ENTITY_SENSE9003
 #define DR_ENTITY_PRESENT  1
 #define DR_ENTITY_UNUSABLE 2
@@ -385,6 +478,8 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t 
count)
dlpar_free_cc_nodes(dn);
}
 
+   rc = online_node_cpus(dn);
+
return rc ? rc : count;
 }
 
@@ -404,6 +499,12 @@ static ssize_t dlpar_cpu_release(const char *buf, size_t 
count)
return -EINVAL;
}
 
+   rc = offline_node_cpus(dn);
+   if (rc) {
+

[PATCH v6 2/2] pseries: Serialize cpu hotplug operations during deactivate Vs deallocate

2009-11-26 Thread Vaidyanathan Srinivasan

From: Gautham R Shenoy e...@in.ibm.com

Currently the cpu-allocation/deallocation process comprises of two steps:
- Set the indicators and to update the device tree with DLPAR node
  information.

- Online/offline the allocated/deallocated CPU.

This is achieved by writing to the sysfs tunables probe during allocation
and release during deallocation.

At the sametime, the userspace can independently online/offline the CPUs of
the system using the sysfs tunable online.

It is quite possible that when a userspace tool offlines a CPU
for the purpose of deallocation and is in the process of updating the device
tree, some other userspace tool could bring the CPU back online by writing to
the online sysfs tunable thereby causing the deallocate process to fail.

The solution to this is to serialize writes to the probe/release sysfs
tunable with the writes to the online sysfs tunable.

This patch employs a mutex to provide this serialization, which is a no-op on
all architectures except PPC_PSERIES

Signed-off-by: Gautham R Shenoy e...@in.ibm.com
Acked-by: Vaidyanathan Srinivasan sva...@linux.vnet.ibm.com
---

 arch/powerpc/platforms/pseries/dlpar.c |   45 +---
 drivers/base/cpu.c |2 +
 include/linux/cpu.h|   13 +
 3 files changed, 50 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/dlpar.c 
b/arch/powerpc/platforms/pseries/dlpar.c
index 642e1b2..fd2f0af 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -436,6 +436,18 @@ int dlpar_release_drc(u32 drc_index)
 
 #ifdef CONFIG_ARCH_CPU_PROBE_RELEASE
 
+static DEFINE_MUTEX(pseries_cpu_hotplug_mutex);
+
+void cpu_hotplug_driver_lock()
+{
+   mutex_lock(pseries_cpu_hotplug_mutex);
+}
+
+void cpu_hotplug_driver_unlock()
+{
+   mutex_unlock(pseries_cpu_hotplug_mutex);
+}
+
 static ssize_t dlpar_cpu_probe(const char *buf, size_t count)
 {
struct device_node *dn;
@@ -443,13 +455,18 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t 
count)
char *cpu_name;
int rc;
 
+   cpu_hotplug_driver_lock();
rc = strict_strtoul(buf, 0, drc_index);
-   if (rc)
-   return -EINVAL;
+   if (rc) {
+   rc = -EINVAL;
+   goto out;
+   }
 
dn = dlpar_configure_connector(drc_index);
-   if (!dn)
-   return -EINVAL;
+   if (!dn) {
+   rc = -EINVAL;
+   goto out;
+   }
 
/* configure-connector reports cpus as living in the base
 * directory of the device tree.  CPUs actually live in the
@@ -459,7 +476,8 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t 
count)
   GFP_KERNEL);
if (!cpu_name) {
dlpar_free_cc_nodes(dn);
-   return -ENOMEM;
+   rc = -ENOMEM;
+   goto out;
}
 
sprintf(cpu_name, /cpus%s, dn-full_name);
@@ -469,7 +487,8 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t 
count)
rc = dlpar_acquire_drc(drc_index);
if (rc) {
dlpar_free_cc_nodes(dn);
-   return -EINVAL;
+   rc = -EINVAL;
+   goto out;
}
 
rc = dlpar_attach_node(dn);
@@ -479,6 +498,8 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t 
count)
}
 
rc = online_node_cpus(dn);
+out:
+   cpu_hotplug_driver_unlock();
 
return rc ? rc : count;
 }
@@ -499,26 +520,30 @@ static ssize_t dlpar_cpu_release(const char *buf, size_t 
count)
return -EINVAL;
}
 
+   cpu_hotplug_driver_lock();
rc = offline_node_cpus(dn);
if (rc) {
of_node_put(dn);
-   return -EINVAL;
+   rc = -EINVAL;
+   goto out;
}
 
rc = dlpar_release_drc(*drc_index);
if (rc) {
of_node_put(dn);
-   return -EINVAL;
+   goto out;
}
 
rc = dlpar_detach_node(dn);
if (rc) {
dlpar_acquire_drc(*drc_index);
-   return rc;
+   goto out;
}
 
of_node_put(dn);
-   return count;
+out:
+   cpu_hotplug_driver_unlock();
+   return rc ? rc : count;
 }
 
 static int __init pseries_dlpar_init(void)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 7c03af7..27fd775 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -35,6 +35,7 @@ static ssize_t __ref store_online(struct sys_device *dev, 
struct sysdev_attribut
struct cpu *cpu = container_of(dev, struct cpu, sysdev);
ssize_t ret;
 
+   cpu_hotplug_driver_lock();
switch (buf[0]) {
case '0':
ret = cpu_down(cpu-sysdev.id);
@@ -49,6 +50,7 @@ static ssize_t __ref store_online(struct sys_device *dev, 
struct sysdev_attribut
default:
ret = -EINVAL;
}
+

Re: [RFC PATCH 04/19] powerpc: wii: device tree

On Thu, 2009-11-26 at 16:09 +0100, Albert Herranz wrote:

  Are the above OHCI and EHCI special ? If not, there's an existing
  binding for that sort of thing, which btw requires properties to
  indicate the endianness of the registers and in-memory data structures
  etc...
  
 
 They are a bit special because registers are in reverse little endian format,
 must be written in 32-bit chunks, and (all things point to) they have 
 hardware bugs.

Well.. first what is reverse little endian ? :-) Big endian ?

The OHCI driver today has separate flags to control register endianness
and memory based data structures endianness.

I think we also only use 32-bit reads and writes no ? So that should be
covered :-)

As for HW bugs, well, as long as we know them we can define a quirk bit
and add the necessary workarounds to the driver :-)

Do you have a patch somewhere that adds the OCHI and EHCI support btw ?
 
Cheers,
Ben.


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

Re: [RFC PATCH 04/19] powerpc: wii: device tree


  Good point. I can't even guarantee that the kernel will work reliably
  with nobats :-) At least you really want the kernel .text to be fully
  covered by an IBAT.
  
 
 It works with nobats.

But does it work -reliably- ? :-)

I haven't looked at that for years, but we used to have a subtle issue
if you happen to take a hash miss on the kernel text or data in the
wrong time, such as when SRR0/SRR1 are modified and before a subsequent
rfi. This is very very hard to trigger and maybe impossible without SMP
but to keep in mind.

Paulus added some code ages ago to close most of these by using the
MSR:RI bit so that the hash code could detect the situation and branch
to some recovery code, but from memory, while that dealt with missing
D-BATs, we still had a potential window of problem if the kernel text
itself wasn't entirely covered.

Any ways, not a big deal right now, as I said, we really want the BATs
for performances anyways, so we should probably just add some kind of
hack in mmu_mapin_ram() for the time being.

 I must say that all the patches posted (and the device drivers, which haven't
 been posted yet) are tested and working code.

That was my impression too, but in this case, I'm talking about a
potential very hard to hit problem that you may well have never managed
to actually trigger.

 There you can find the hardware interface that supports the IPC mechanism.
 It is made up of a pair of registers to pass data between the processors and a
 pair of control/flags registers.
 The hardware can interrupt the PowerPC side when there is data available for 
 it.

Ok. So the right way to do that would be to have a node purely
representing the HW IPC, unrelated to whatever is running on the
secondary processor.

However, it's ok to have -below- that node, a set of device nodes or a
node with properties or whatever representing the FW in there and the
function it exposes.

That can be discussed later tho. I'm not that keen on having those info
be in the .dts coming with the kernel since those functions essentially
depend on what FW is loaded on the aux. processor.

What might do however is to have a way for that FW itself to provide you
with the nodes and properties for the functions it provides :-) Then you
can have the boot wrapper or the kernel platform init code use some well
defined (and as stable as possible) IPC API to identify the FW there and
expose all that stuff.

Of course that wouldn't work with FW we don't have control on. Can Linux
run on the wii with the original N. FW on the aux. processor ? Can we
detect what is running there ? Do we care ?

 It is what Nintendo calls the Serial Interface (SI) which is a proprietary
 serial hardware to drive the gamepads (and a custom keyboard too, once 
 available
 for an RPG game).

So I would give it a different name than serial then. Make it gpsi
maybe ? (game pad serial interface ?) :-) Or invent something else...

Cheers,
Ben.

  Cheers,
  Ben.
  
 
 Thanks,
 Albert


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

Re: [RFC PATCH 09/19] powerpc: gamecube/wii: udbg support for usbgecko

On Thu, 2009-11-26 at 16:28 +0100, Albert Herranz wrote:
 Benjamin Herrenschmidt wrote:
  On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
  Add support for using the USB Gecko adapter via the udbg facility on
  the Nintendo GameCube and Wii video game consoles.
  The USB Gecko is a 3rd party memory card interface adapter that provides
  a EXI (External Interface) to USB serial converter.
  
  The main issue here is that the gecko is supposed to be something you
  can plug or unplug no ? Is it hotswap or only at boot ? In the later
  case, maybe the node should be created by the boot wrapper when
  detecting the presence of the device. If it's hotplug, then we need
  something smarter...
  
 
 The usbgecko is hotplugable and hotswappable.
 But as this is mostly a developer feature, not normaly used by end users,
 I think that we can just let it be as it is: autodetect it on boot (now 
 probing
 for it instead of using information from the device tree).
 If you unplug it later it causes no errors, you just miss whatever data is 
 sent to it.

Ack. We may still went ultimately to have some kind of nice hotplug
driver for that connector and we may even have a usbgecko driver for
that things after boot that creates areal tty etc... but for now, just
a hard probe will do just fine.

Of course a real OF implemention is welcome to create a device node for
it if it was indeed present at boot time.

Cheers,
Ben.

  Cheers,
  Ben.
  
 
 Thanks,
 Albert
 


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

Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support

On Thu, 2009-11-26 at 16:30 +0100, Albert Herranz wrote:
 Benjamin Herrenschmidt wrote:
  On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
  
  +static void flipper_pic_mask_and_ack(unsigned int virq)
  +{
  +  int irq = virq_to_hw(virq);
  +  void __iomem *io_base = get_irq_chip_data(virq);
  +
  +  clear_bit(irq, io_base + FLIPPER_IMR);
  +  set_bit(irq, io_base + FLIPPER_ICR);
  +}
  
  Do not use clear_bit and set_bit on IOs. They will do lwarx/stwcx. which
  is really not what you want. You can use __clear_bit and __set_bit but
  it's still fishy. Those operate on unsigned long, so the size vary
  between 32 and 64 bit etc... not something you care that much about, but
  it's still the wrong tool for the job.
  
  Do those guys have more than 32 interrupts ? If not, just hand
  code the msak  shifts. If they do, then maybe stick with __clear_bit()
  and __set_bit() which are the non atomic variants.
  
 
 There can be only 32 interrupt sources per pic.
 I'll build a mask and check if just a simple write works too (it should 
 IMHO), instead of a RWM.

For the ICR just writes should be ok. For the IMR, I wouldn't be
surprised if you need to RMW. In which case you have two options:

 - One is you just do RMW :-) As long as you don't do SMP, you don't
have a problem since these callbacks are generally called with local
IRQs off.

 - Or you could explicitely add a spinlock_irqsave just out of paranoia
or if you envision SMP type access to these things (from the aux
processor ? But then the spinlock would have to be shared with the aux
ptiocrocessor FW... fun)

 - In any case, clear_bit and set_bit are the wrong accessors since
lwarx and stwcx. are definitely the wrong instructions to use for non
cachable accesses. On other processor you probably would have blown up
here in fact. Also those accessors don't provide any memory barriers
which mean you may even have some ordering issues. Use readl_be() and
writel_be() (or the ppc specific in_be32/out_be32) or the _le variants
if you want to count bits backward :-)

- You could also keep in memory cache of what the mask is supposed to
be. You RMW the cache and do a simple store to the register. It won't
fix the concurrency problem (that you probably don't have anyways) but
it will make things faster by avoiding an MMIO load

 - However you probably need that MMIO load anyways :-) Trick is, the
store you do to ack and mask an interrupt may take some time to hit the
PIC before the said PIC actually lowers the CPU EE line. Enough time for
your code to go back, re-enable MSR:EE and start calling into the
handlers. Enough time thus to catch a spurrious interrupt. Old pmacs
have a similar PIC and have the same problem. I would recommend that
after a mask or a mask  ack, you also read back the register. The MMIO
accessors (readl, etc...) will use a twi;isync construct to ensure that
the load has been fully completed before execution continues which will
help.

 - The construct and flow handler you use assume all interrupts are
level sensitive, this is the case right ?

Cheers,
Ben.

  Cheers,
  Ben.
  
 
 Thanks,
 Albert


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

Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support

On Thu, 2009-11-26 at 16:33 +0100, Albert Herranz wrote:
 Benjamin Herrenschmidt wrote:
  On Sun, 2009-11-22 at 16:28 -0700, Grant Likely wrote:
  +unsigned int flipper_pic_get_irq(void)
  +{
  +   void __iomem *io_base = flipper_irq_host-host_data;
  +   int irq;
  +   u32 irq_status;
  +
  +   irq_status = in_be32(io_base + FLIPPER_ICR) 
  +in_be32(io_base + FLIPPER_IMR);
  +   if (irq_status == 0)
  +   return -1;  /* no more IRQs pending */
  NO_IRQ_IGNORE 
  
  Why no just 0 ? (aka NO_IRQ)
  
 
 I didn't know about 0 (I thought that was another valid interrupt).

0 is a valid hw number. It's not a valid linux virq number. In fact,
that's part of the reason why we generalized the whole virq thingy :-)
Because back then, Linus made the statement that 0 should never be a
valid IRQ number in linux. That also allowed us to make sure that 1..15
are never allocated to anything but a legacy 8259 to avoid all sorts of
problems with crackpot legacy x86 originated drivers who hard coded some
of these interrupts.

 I was used to -1 to tell that no IRQs were pending (at least from the
 ARCH=ppc days) :)

Yup, we changed that :-)

  Or do you know you are getting lots of spurrious that you don't want to
  account ?
  
 
 No, this is not the case here.

Cheers,
Ben.

  Cheers,
  Ben.
  
 
 Thanks,
 Albert


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

Re: [RFC PATCH 14/19] powerpc: allow ioremap within reserved fake ram regions

On Thu, 2009-11-26 at 16:35 +0100, Albert Herranz wrote:
 Benjamin Herrenschmidt wrote:
  On Tue, 2009-11-24 at 18:09 +0100, Albert Herranz wrote:
  I could use ppc_md.ioremap to duplicate ioremap except for the ioremap
  ram check.
  But calling the stock ioremap without modifying it is not possible
  because it checks and bails out when ioremapping a region marked as
  ram (even if it's not real ram and it's memreserved).
 
  Is the list of memreserved areas preserved once the kernel is running?
  If it is preserved another option would be to unban ioremapping ram if
  memreserved.
  
  Yes, check lmb's they should still be around.
  
 
 Good.
 So adding a kconfig option to allow ioremapping memreserved memory marked
 as ram and adding a proper check (under that kconfig) to unban this case
 in ioremap would be an acceptable solution?

Don't even make it Kconfig. Stick it under you GAMECUBE_COMMON for now
or CONFIG_WII or whatever. This is temporary until we sort out the whole
disctontig mem issue.

Cheers,
Ben.

  Cheers,
  Ben.
  
 
 Thanks,
 Albert


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

Re: [RFC PATCH 16/19] powerpc: wii: hollywood interrupt controller support

On Thu, 2009-11-26 at 16:42 +0100, Albert Herranz wrote:
 Benjamin Herrenschmidt wrote:
  On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
  
  +static void hlwd_pic_mask_and_ack(unsigned int virq)
  +{
  +  int irq = virq_to_hw(virq);
  +  void __iomem *io_base = get_irq_chip_data(virq);
  +
  +  clear_bit(irq, io_base + HW_BROADWAY_IMR);
  +  set_bit(irq, io_base + HW_BROADWAY_ICR);
  +}
  
  Same comment as with flipper. BTW. It looks really similar, can't you
  use the same driver ?
  
 
 I'll look at it. Surely, parts of it would be mergeable.

If it's too much work, we can do that later. No big deal.

Cheers,
Ben.

  Cheers,
  Ben.
  
 
 Thanks,
 Albert
 
  
  


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

Re: [RFC] powerpc/mm: honor O_SYNC flag for memory map


So what you are saying is that if the kernel has mapped a physical
page as cacheable while user application is trying to map it as
non-cacheable, there will be machine checks and checkstops rather than
just performance drop?  This is new to me.  Could you elaborate a bit?


If some data is in cache at a certain physical address, and you then
do an uncached read from that address, on at least some CPUs both the
bus interface and the cache will reply.  Bang, machine check.

Writes are problematic as well.


Segher

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

Re: [RFC PATCH 04/19] powerpc: wii: device tree

Benjamin Herrenschmidt wrote:
On Thu, 2009-11-26 at 16:09 +0100, Albert Herranz wrote:

Are the above OHCI and EHCI special ? If not, there's an existing
binding for that sort of thing, which btw requires properties to
indicate the endianness of the registers and in-memory data structures
etc...

They are a bit special because registers are in reverse little endian format,
must be written in 32-bit chunks, and (all things point to) they have
hardware bugs.

Well.. first what is reverse little endian ? :-) Big endian ?

It's the same case as the register access for the Freescale eSDHC controller,
which is already in the existing sdhci-of driver.

The OHCI driver today has separate flags to control register endianness
and memory based data structures endianness.

I think we also only use 32-bit reads and writes no ? So that should be
covered :-)

There are 8, 16 and 32 bit accesses. We need the same workarounds as present
for the Freescale eSDHC controller.

As for HW bugs, well, as long as we know them we can define a quirk bit
and add the necessary workarounds to the driver :-)

Yes, that's how it was done.
Although it it currently not integrated into sdhci-of. I think that the
specific eSDHC code should be moved to another file, and leave the sdhci-of
with the generic code and the sdhci_of_match table. Then adding a similar
driver would simply consist in adding another file with the sdhci_data
(containing ops and quirks) and adding an entry to the sdhci_of_match table in
sdhci-of.

Do you have a patch somewhere that adds the OCHI and EHCI support btw ?

Yes, too. Although it needs review and cleanup too.

I have a git tree with all the stuff, but it contains only the existing code
previous to the effort of mainlining it:

http://git.infradead.org/users/herraa1/gc-linux-2.6.git/shortlog/refs/heads/mini/gc-linux-2.6.31

Cheers,
Ben.

Thanks,
Albert

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

Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef

You're right, it's not, but makes merging less complex, and then I  
can

refactor properly.


Still, make them __be32 at least


There is no alignment guarantee at all either, better make it all u8
and use accessor functions everywhere.


Segher

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

Re: [RFC PATCH 04/19] powerpc: wii: device tree

Benjamin Herrenschmidt wrote:
 Good point. I can't even guarantee that the kernel will work reliably
 with nobats :-) At least you really want the kernel .text to be fully
 covered by an IBAT.

 It works with nobats.
 
 But does it work -reliably- ? :-)
 

It does AFAICT. My Wii is a 24x7 linux box although it is not stressed in any 
way usually.

 Any ways, not a big deal right now, as I said, we really want the BATs
 for performances anyways, so we should probably just add some kind of
 hack in mmu_mapin_ram() for the time being.
 

Yup. The idea is to map the first 16MB of MEM1 with a BAT.
Mapping the whole 24MB with BATs may not be possible because we want the 
framebuffer in MEM1 for performance reasons.

 I must say that all the patches posted (and the device drivers, which haven't
 been posted yet) are tested and working code.
 
 That was my impression too, but in this case, I'm talking about a
 potential very hard to hit problem that you may well have never managed
 to actually trigger.
 

I haven't actually, if that applies :)

 There you can find the hardware interface that supports the IPC mechanism.
 It is made up of a pair of registers to pass data between the processors and 
 a
 pair of control/flags registers.
 The hardware can interrupt the PowerPC side when there is data available for 
 it.
 
 Ok. So the right way to do that would be to have a node purely
 representing the HW IPC, unrelated to whatever is running on the
 secondary processor.
 

Totally agreed.

 However, it's ok to have -below- that node, a set of device nodes or a
 node with properties or whatever representing the FW in there and the
 function it exposes.
 
 That can be discussed later tho. I'm not that keen on having those info
 be in the .dts coming with the kernel since those functions essentially
 depend on what FW is loaded on the aux. processor.
 

I think we can leave this for later as you said.

 What might do however is to have a way for that FW itself to provide you
 with the nodes and properties for the functions it provides :-) Then you
 can have the boot wrapper or the kernel platform init code use some well
 defined (and as stable as possible) IPC API to identify the FW there and
 expose all that stuff.
 

Segher was playing with an OF implementation...

 Of course that wouldn't work with FW we don't have control on. Can Linux
 run on the wii with the original N. FW on the aux. processor ? Can we
 detect what is running there ? Do we care ?
 

Yes, it can. And it is done. But I think we don't care/need that in mainline.

 It is what Nintendo calls the Serial Interface (SI) which is a proprietary
 serial hardware to drive the gamepads (and a custom keyboard too, once 
 available
 for an RPG game).
 
 So I would give it a different name than serial then. Make it gpsi
 maybe ? (game pad serial interface ?) :-) Or invent something else...
 

I'd choose gcnsi with a compatible like nintendo,gamecube-si :)

(gcn is the official short abbreviation for the Nintendo GameCube)

 Cheers,
 Ben.
 

Thanks,
Albert

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

Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef

On Thu, 2009-11-26 at 22:36 +0100, Segher Boessenkool wrote:
  You're right, it's not, but makes merging less complex, and then I  
  can
  refactor properly.
 
  Still, make them __be32 at least
 
 There is no alignment guarantee at all either, better make it all u8
 and use accessor functions everywhere.

Well... if you want to force using an accessor, then make it an opaque
type. But __be32 is fine. It doesn't necessarily convey alignment and
besides, there happens to -be- aligned in almost all cases so far :-)
The flat tree format guarantees 32-bit alignment for the start of a
property, so we are good here I think.

Cheers,
Ben.


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

Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support


Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of GAMECUBE_COMMON
is a good name?


I'd prefer to not use a name that implies a specific hardware to  
describe two (mostly) similar but different hardwares.


Hollywood is 100% compatible to Flipper though.


+/*
+ * Each interrupt has a corresponding bit in both
+ * the Interrupt Cause (ICR) and Interrupt Mask (IMR) registers.
+ *
+ * Enabling/disabling an interrupt line involves asserting/clearing
+ * the corresponding bit in IMR. ACK'ing a request simply involves
+ * asserting the corresponding bit in ICR.
+ */


I looked it up in YAGCD; it says that _reading_ the ICR reg already
acks all interrupts (and clears the bits), you never write this reg!


+static void flipper_pic_ack(unsigned int virq)
+{
+int irq = virq_to_hw(virq);
+void __iomem *io_base = get_irq_chip_data(virq);
+
+set_bit(irq, io_base + FLIPPER_ICR);
+}


So it should be a simple write instead of an RMW here, right?
As it is you are ACKing _all_ IRQs as far as I can see.



No, it acks just a single IRQ.


No it doesn't.  Say IRQs 1 and 3 are asserted, so the reg contains 0x0a.
Now you want to ack IRQ1; set_bit() will write 0x0a | 0x02, not just  
0x02.



Segher

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

Re: [RFC PATCH 12/19] powerpc: gamecube: platform support


We need it as it currently doesn't match with the default bus ids.


Should I introduce a .type property matching any of those above in  
the soc node, and get rid of the explicit bus probe?


You don't need any fake bus as far as I can see, just probe the devices
you want.


Segher

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

Re: [RFC PATCH 17/19] powerpc: wii: bootmii starlet 'mini' firmware support


Add support for the BootMii 'mini' firmware replacement for the
Starlet processor.

'mini' is an open source IOS replacement written from scratch by
Team Twiizers.


It's not a replacement, it doesn't have any of the same  
functionality.


I didn't know 'replacement' had that semantics.


It's ambiguous.

My intention was to say that 'mini' firmware is an alternative to  
the stock IOS firmware, not trying to imply that it behaves like it  
or it is compatible with it.

Point taken.

I'll use 'mini' alternate firmware if that's ok.


Alternative firmware is fine.


+enum starlet_ipc_flavour {
+STARLET_IPC_IOS,
+STARLET_IPC_MINI,
+};


I thought you don't support IOS at all anymore?



I don't plan to mainline IOS support.
But to make runtime decisions I need to know if we are running  
along the 'mini' firmware or the default IOS firmware.

That's the intention of that enum.



Modern mini will always have AHBPROT set up to give you full access,
so this isn't needed either.



So we have two options here:
- assume that whatever firmware is running properly sets AHBPROT  
and hope it works
- or try to use the existing firmware interfaces to check and make  
sure that AHBPROT is indeed properly set


I chose the second option here.


It is much much simpler to simply require a new enough mini :-)

Do you need this driver to boot?  If not, it might be best to  
leave it

out for now.


Strictly speaking, we don't need the driver to boot if we asume  
that AHBPROT is properly set.
But we'll need it later to shutdown 'mini' drivers, unless 'mini'  
is changed to boot PowerPC code with all hardware already  
relinquished.


That is not true for the last available version of 'mini' firmware.  
That version still boots PowerPC code with at least the SDHCI  
controller driven by 'mini'.


I'll fix this.


Segher

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

Re: [PATCH] PPC: Sync guest visible MMU state

2009-11-26 Thread Alexander Graf



Am 26.11.2009 um 16:24 schrieb Alexander Graf ag...@suse.de:

Currently userspace has no chance to find out which virtual address  
space we're
in and resolve addresses. While that is a big problem for migration,  
it's also
unpleasent when debugging, as gdb and the monitor don't work on  
virtual

addresses.

This patch exports enough of the MMU segment state to userspace to  
make

debugging work and thus also includes the groundwork for migration.

Signed-off-by: Alexander Graf ag...@suse.de

---

Ben, please take this patch in your tree.

v2 - v3:

 - don't use anonymous unions/structs
---
arch/powerpc/include/asm/kvm.h|   20 +++-
arch/powerpc/include/asm/kvm_asm.h |1 +
arch/powerpc/include/asm/kvm_book3s.h |3 ++
arch/powerpc/kvm/book3s.c |   53  
+++-

arch/powerpc/kvm/book3s_64_emulate.c  |   38 ++-
arch/powerpc/kvm/book3s_64_mmu.c |2 +
arch/powerpc/kvm/powerpc.c|3 ++
include/linux/kvm.h   |3 ++
8 files changed, 104 insertions(+), 19 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/ 
asm/kvm.h

index c9ca97f..cb6ad08 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -46,8 +46,24 @@ struct kvm_regs {
};

struct kvm_sregs {
-__u32 pvr;
-char pad[1020];
+union {
+struct {
+__u32 pvr;


Meh this breaks old userspace. Better patch following tomorrow.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 18/19] powerpc: wii: platform support


+#ifdef CONFIG_STARLET_MINI
+
+#define HW_RESETS_OF_COMPATIBLEnintendo,hollywood-resets
+#define HW_GPIO_ALIAShw_gpio


This should be unconditional now I think?  You access the hardware
directly.


Yes, at this stage direct hardware should be possible, but only if  
'mini' support is compiled-in (which will be the default option at  
this stage).
We can either leave the conditionals as is now, or remove them and  
add them later if we support more than one firmware flavour.


I'm fine with both options.


Removing all superfluous code is best in my opinion.


+np = of_find_node_by_name(NULL, aliases);
+if (!np) {
+pr_err(unable to find node %s\n, aliases);
+goto out;
+}
+
+path = of_get_property(np, HW_GPIO_ALIAS, NULL);
+of_node_put(np);
+if (!path) {
+pr_err(alias %s unknown\n, HW_GPIO_ALIAS);
+goto out;
+}


Don't use an alias here, search for e.g. a matching compatible  
instead.


I used an alias because I wanted explicitly the second GPIO word.

Is there another way to select a specific instance of repeated  
identical hardware?


Yes, probe for it with its address.  There is no guarantee in which  
order

you will get them.


We have two instances of gpios here, matching the same compatible.


It's a pain in the behind that the GPIO binding will not allow you to
show the two GPIO regs as one controller, which it is.  Or can it
actually do that?


Segher

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

Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support

Segher Boessenkool wrote:
 Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of GAMECUBE_COMMON
 is a good name?

 I'd prefer to not use a name that implies a specific hardware to
 describe two (mostly) similar but different hardwares.
 
 Hollywood is 100% compatible to Flipper though.
 

No. There's no ARAM for example :)

 +/*
 + * Each interrupt has a corresponding bit in both
 + * the Interrupt Cause (ICR) and Interrupt Mask (IMR) registers.
 + *
 + * Enabling/disabling an interrupt line involves asserting/clearing
 + * the corresponding bit in IMR. ACK'ing a request simply involves
 + * asserting the corresponding bit in ICR.
 + */
 
 I looked it up in YAGCD; it says that _reading_ the ICR reg already
 acks all interrupts (and clears the bits), you never write this reg!
 

YAGCD is not always right. You should not take it as _the truth_.
I'm not telling this is the case. But I don't recall such behavior. It's been a 
long time since this is done this way.

 +static void flipper_pic_ack(unsigned int virq)
 +{
 +int irq = virq_to_hw(virq);
 +void __iomem *io_base = get_irq_chip_data(virq);
 +
 +set_bit(irq, io_base + FLIPPER_ICR);
 +}

 So it should be a simple write instead of an RMW here, right?
 As it is you are ACKing _all_ IRQs as far as I can see.


 No, it acks just a single IRQ.
 
 No it doesn't.  Say IRQs 1 and 3 are asserted, so the reg contains 0x0a.
 Now you want to ack IRQ1; set_bit() will write 0x0a | 0x02, not just 0x02.
 

Let me rephrase it. No it should just ack a single IRQ :)

So then this is working by accident.
If that's the case, I guess it works because the interrupt is not cleared at 
the source and the ICR is set again immediately for any pending interrupt?

 
 Segher
 
 

Thanks,
Albert

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

Re: [RFC PATCH 12/19] powerpc: gamecube: platform support

Segher Boessenkool wrote:
 We need it as it currently doesn't match with the default bus ids.
 
 Should I introduce a .type property matching any of those above in the
 soc node, and get rid of the explicit bus probe?
 
 You don't need any fake bus as far as I can see, just probe the devices
 you want.
 

But it's way easier to let the bus probe do it for us. I don't see the win here.

 
 Segher
 
 

Thanks,
Albert


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

Re: [RFC PATCH 02/19] powerpc: gamecube: device tree


If you have only one interrupt controller, like here, you don't
need to refer to it _at all_ :-)


I think Linux requires that you do though. It might be a mistake on  
our

part but heh ...


Linux doesn't require it; (old) Macs are like this, for example,
and that works fine.  Oh and all Maple firmwares are like that as
well I think.  Etc.


Segher

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

Re: [RFC PATCH 02/19] powerpc: gamecube: device tree


+   xfb-start = 0x01698000; /* end-of-ram - xfb-size */
+   xfb-size = 0x168000;


XFB address isn't fixed on the hardware, and the kernel might
want to move it, and you can easily probe for it anyway.  Remove
these last two properties please.


Ok but you need to know what it was setup to by the FW no ? To avoid
having a temporary display glitch while booting... Also on a 24M
config,it might get tough for the driver to allocate 2M contiguous  
like

that if it's done late in the boot process.


Sure, the platform code will have to probe this very early.  Can always
do the /memreserve/ if really needed.


+   aux...@0c005000 {
+   compatible = nintendo,flipper-auxram;
+   reg = 0x0c005000 0x200; /* DSP */
+   interrupts = 6;
+   interrupt-parent = pic;
+   };
+
+   au...@0c005000 {
+   compatible = nintendo,flipper-audio;
+   reg = 0x0c005000 0x200  /* DSP */
+  0x0c006c00 0x20; /* AI */
+   interrupts = 6;
+   interrupt-parent = pic;
+   };


These two have the same address, not good.  Just remove the
auxram node?


Or make it a child of audio ? :-)


Hrm, actually, DSP and AI should be separate nodes, and ARAM a child
of DSP (on its own bus, so it can show that it is 16MB etc.)


Segher

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

Re: [RFC PATCH 03/19] powerpc: gamecube: bootwrapper bits


So what's your proposal then? Placing it within a fake func?


Just do a .S file :-)


Yeah.  You might be able to do one that handles both GC and Wii,
maybe it's easier/clearer to keep them separate though.


Ouch. I wouldn't be surprised if those guys don't do cache coherency
in the bridge anyways.


That is correct; we haven't found any way to enable it, at least.
To be fair, it's actually better for performance to _not_ do RAM
coherency when used as a game system.


Segher

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

Re: [RFC PATCH 02/19] powerpc: gamecube: device tree


+   soc {


It would be better to rename this as IMMR or the bus type.  This node
doesn't actually describe the entire chip, but describes the internal
memory mapped registers.


I would really just call it flipper :-)


Yeah, I came to the same conclusion.


Since you're only doing 1:1 mappings; you could replace this with an
empty ranges; property instead.


On the other hand it is a useful documentation to specify the exact
range decoded when you know it :-)


Not the decoded range in this case, that is 0..4G :-)  The canonical
ranges is nice doc, yes.


Hint:  If you move the interrupt-parent property up to the root node,
then you don't need to specify it in every single device node; it  
will

just inherit from the parent.


Note that this is a linux-ism no ? (aka ePAPRism).


Nope, it is from the standard interrupt mapping recommended practice.
It is fine.


If they aim toward having a real OF which I think they do


We do.


Segher

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

Re: [RFC PATCH 04/19] powerpc: wii: device tree

On Thu, 2009-11-26 at 22:38 +0100, Albert Herranz wrote:

 Yup. The idea is to map the first 16MB of MEM1 with a BAT.
 Mapping the whole 24MB with BATs may not be possible because we want the 
 framebuffer
 in MEM1 for performance reasons.

How big is the fb ? We have plenty of BATs on these things... so one 16M
for the low mem and one 64M for the high mem, that leaves something
like 6 to manage as much as possible up to the fb :-)

Let's keep 1 or 2 for debug and maybe even BAT map the fb itself, we
still are quite comfortable :-)

That reminds me we still need to re-introduce a clean version of
io_block_mapping (or ioremap flag that does the same) so the platform
code can establish a BAT mapping for a whole bunch of IOs and ioremap
transparenty picks addresses in there. We used to do it, dropped it
mostly because it was done badly (virtual address was hard coded which
caused all sorts of issues) but it shouldn't be hard to do it right and
it would improve perfs a little bit more.

Cheers,
Ben.


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

Re: [RFC PATCH 04/19] powerpc: wii: device tree

+/memreserve/ 0x0180 0xe80;	/* memory hole (includes I/O  
area) */

+/memreserve/ 0x1000 0x0004000; /* DSP RAM */


Weird layout... nothing you can do about I suppose.

Out of curiosity, what is that DSP RAM ? Some actual DSP core  
somewhere

in the IO chip setup to use memory from up there ?


It's an actual DSP yes, and it seems it uses that fixed address range
(at the start of the 64MB GDDR3 memory) always.  So we have to stay
away from that memory range.


+   memory {
+   device_type = memory;
+   /* MEM1 + memory hole + MEM2 - firmware/buffers area */
+   reg = 0x 0x133e;
+   };


So we do have a nasty hole here in the middle. How bad it is if you  
try

to just have two ranges in there (ie as if it was discontiguous) ?


Not bad at all.  There is no as if -- it _is_ discontiguous memory,
they are totally different memory technology even.


+   /* Team Twiizers' 'mini' firmware IPC */


Out of curiosity, what are these ? :-)


There is an embedded ARM9 in the Hollywood.  It is the boss of the
system, not the PowerPC.  mini is the name of the code we run on it.

There is a hardware IPC interface between the ARM and the PowerPC (just
a bunch of doorbells and general purpose regs).


Similar comment as before, could the above be dynamically probed ? If
you are not a hacker you may not need that at all to use some linux
based piece of SW on the wii right ?


Yeah.  Well, after any other drivers have been merged, anyway, heh :-)


+   oh...@0d06 {


Why the 1 ?


Right, call them both just ohci please.  Or usb even.


+   PIC1: p...@0d800030 {
+   #interrupt-cells = 1;
+   compatible = nintendo,hollywood-pic;
+   reg = 0x0d800030 0x8;
+   interrupt-controller;
+   interrupts = 14;
+   interrupt-parent = PIC0;
+   };


Ah, a cascaded PIC, fun fun fun


Well at least this cascaded PIC is sane, the root PIC is less so :-P


+   hollywood-ahbp...@0d800064 {
+   compatible = nintendo,hollywood-ahbprot;
+   reg = 0x0d800064 0x4;
+   };


What is this ?


Most of the devices new in Hollywood (AES engine, NAND engine, USB,
SD, etc.) sit on an AHB bus.  The AHBPROT register is used to configure
which of these can be accessed from the PowerPC.

Modern mini always gives us full control.  Also, there is no reason
to single out the AHBPROT reg in the device tree like this, anyway.


Segher

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

Re: [RFC PATCH 02/19] powerpc: gamecube: device tree

On Thu, 2009-11-26 at 23:15 +0100, Segher Boessenkool wrote:
  If you have only one interrupt controller, like here, you don't
  need to refer to it _at all_ :-)
 
  I think Linux requires that you do though. It might be a mistake on  
  our
  part but heh ...
 
 Linux doesn't require it; (old) Macs are like this, for example,
 and that works fine.  Oh and all Maple firmwares are like that as
 well I think.  Etc.

It works fine on old macs thanks to a quirk we enable in the mac code
iirc and old maple works thanks to mere luck with the fallback code we
have which reads things of PCI config space :-)

Don't rely on that.

Cheers,
Ben.

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

Re: [RFC PATCH 04/19] powerpc: wii: device tree


BTW. If we want to play with clocks, maybe you should look at
my proposed binding for clocks and implementing the clk API :-)


There are no clocks that are configurable from the PowerPC side
(well, maybe things like the USB clocks, but we do not know how).


+   /* Team Twiizers' 'mini' firmware IPC */
+   m...@0d00 {


Although mini is awesome, it isn't hardware, and doesn't
belong in the device tree.


So what is at d000 ?


0c00 is the flipper-compatible stuff
0d00 is the hollywood new devices
0d80 is the same as part of 0d00, but with some extra bits
sometimes.


+   ser...@0d006400 {
+   compatible = nintendo,hollywood-serial;


You might want to pick a more descriptive name for this,
serial is usually understaood to mean RS232.  Which
this isn't.


What is it then ? You definitely want some other name if it's not
classic rs232 style serial.


It's SPI I think, with some extra signals.  It's the gamepads mostly.


Segher

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

Re: [RFC PATCH 10/19] powerpc: gamecube/wii: early debugging using usbgecko


This will probably break other platforms if
CONFIG_PPC_EARLY_DEBUG_USBGECKO
is set. In general, we try hard to make it possible to build generic
kernels for multiple systems, so it would be better to also add a
runtime check here.


No Arnd. The whole point of EARLY_DEBUG is that it is -known- to break
other platforms :-) So that we can use it before we even get to probe
anything.

I am still tempted, one day, to change the kernel early init to  
setup a

stack in .bss and go straight to C to do that sort of stuff by parsing
the flat DT, this could be done using pretty much completely generic
code :-) But not right now.


No Ben.  The whole point of EARLY_DEBUG is that it _always works_,  
because

it is such trivial code.  Don't break that please, or we'll be forced to
add a REALLY_EARLY_DEBUG instead :-)


Segher

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

Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support


+unsigned int flipper_pic_get_irq(void)
+{
+   void __iomem *io_base = flipper_irq_host-host_data;
+   int irq;
+   u32 irq_status;
+
+   irq_status = in_be32(io_base + FLIPPER_ICR) 
+in_be32(io_base + FLIPPER_IMR);
+   if (irq_status == 0)
+   return -1;  /* no more IRQs pending */


NO_IRQ_IGNORE


Why no just 0 ? (aka NO_IRQ)

Or do you know you are getting lots of spurrious that you don't  
want to

account ?


IRQ #0 is a valid IRQ here (graphics error IIRC), it should be
remapped I suppose?


Segher

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

Re: [RFC PATCH 16/19] powerpc: wii: hollywood interrupt controller support


+static void hlwd_pic_mask_and_ack(unsigned int virq)
+{
+   int irq = virq_to_hw(virq);
+   void __iomem *io_base = get_irq_chip_data(virq);
+
+   clear_bit(irq, io_base + HW_BROADWAY_IMR);
+   set_bit(irq, io_base + HW_BROADWAY_ICR);
+}


Same comment as with flipper. BTW. It looks really similar, can't you
use the same driver ?


No, they aren't actually similar; the old PIC acks when the status reg
is read, the new PIC acks when you write a 1.  Also, the new PIC has
more registers, it is an interrupt controller for the ARM as well.  Not
that we use it, but still.


Segher

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

Re: [RFC PATCH 03/19] powerpc: gamecube: bootwrapper bits

Sure, the memory controllers don't do coherency.  I'm slightly  
worried

about two things:
1) Will the generic code use M=0 as well?  Is it a problem if it
doesn't?


We can make it not do it.


2) Do lwarx. etc. work in M=0?


They should hopefully... as long as you don't rely on the reservation
blowing as a result of a DMA write.


Hmm, this really depends on whether the DMA transfers generate bus  
cycles

that require coherency or not.


They do not; device DMA never goes to the 6xx bus with this bridge.


Not the other way around. M=1 only forces
bus cycles to be snooped by other processors (asserting the GBL signal
on 603/604/750 busses).


Right, it enables sending probes, not receiving them.  On this CPU  
anyway.

The architecture specification is quite silent on this all.


Segher

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

Re: [RFC PATCH 04/19] powerpc: wii: device tree

Segher Boessenkool wrote:
 So what is at d000 ?
 
 0c00 is the flipper-compatible stuff
 0d00 is the hollywood new devices
 0d80 is the same as part of 0d00, but with some extra bits
 sometimes.
 

Also, when in Wii native mode, stuff like EXI, SI and AI (which is 
flipper-compatible stuff too) is available at 0d00 only.

 +ser...@0d006400 {
 +compatible = nintendo,hollywood-serial;

 You might want to pick a more descriptive name for this,
 serial is usually understaood to mean RS232.  Which
 this isn't.

 What is it then ? You definitely want some other name if it's not
 classic rs232 style serial.
 
 It's SPI I think, with some extra signals.  It's the gamepads mostly.
 

EXI is SPI.
But SI is a different thingy.

See http://www.int03.co.uk/crema/hardware/gamecube/gc-control.htm .

 
 Segher
 
 

Cheers,
Albert

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

Re: [RFC PATCH 09/19] powerpc: gamecube/wii: udbg support for usbgecko


The usbgecko is hotplugable and hotswappable.
But as this is mostly a developer feature, not normaly used by end  
users, I think that we can just let it be as it is: autodetect it  
on boot (now probing for it instead of using information from the  
device tree).
If you unplug it later it causes no errors, you just miss whatever  
data is sent to it.


You can get interrupts when an EXI device is plugged or unplugged; the
normal driver should use that.  But you haven't posted that yet.

The early debug driver can just assume the user doesn't like to hurt
himself, and provide pain when the user does, there's no problem with
that :-)


Segher

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

Re: [RFC PATCH 04/19] powerpc: wii: device tree

They are a bit special because registers are in reverse little  
endian format,
must be written in 32-bit chunks, and (all things point to) they  
have hardware bugs.


Well.. first what is reverse little endian ? :-) Big endian ?


Nah.  Little-endian, with a 32-bit bus swizzle.  This is not the
same thing as big-endian when not all your registers are 32 bits.

Also, you can only write 32 bits, they don't use byte enables.

As for HW bugs, well, as long as we know them we can define a quirk  
bit

and add the necessary workarounds to the driver :-)


The question is if the device is close enough to OHCI to declare it
as that in the device tree.  I would say yes.


Segher

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

Re: [RFC PATCH 04/19] powerpc: wii: device tree

There you can find the hardware interface that supports the IPC  
mechanism.
It is made up of a pair of registers to pass data between the  
processors and a

pair of control/flags registers.
The hardware can interrupt the PowerPC side when there is data  
available for it.


Ok. So the right way to do that would be to have a node purely
representing the HW IPC, unrelated to whatever is running on the
secondary processor.


Or you can keep it implicit in the Hollywood control registers.
It is one 512-byte block with lots of things thrown together (and
then mixed up real good).


However, it's ok to have -below- that node, a set of device nodes or a
node with properties or whatever representing the FW in there and the
function it exposes.


That's not really useful though, it's easy to probe for.

What might do however is to have a way for that FW itself to  
provide you

with the nodes and properties for the functions it provides :-)


You get a pointer at the very last word of memory.  It point to an
info header that has everything you need to know (most importantly,
a version identifier).

Of course that wouldn't work with FW we don't have control on. Can  
Linux

run on the wii with the original N. FW on the aux. processor ?


It _can_, but there are no advantages to doing that, and lots and  
lots of

disadvantages, so the plan is to not add support for that in mainline.


Can we
detect what is running there ? Do we care ?


You can detect this for anything that uses a mini-compatible interface.
You shouldn't care for anything else ;-)


Segher

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

Re: [RFC PATCH 10/19] powerpc: gamecube/wii: early debugging using usbgecko

On Thu, 2009-11-26 at 23:54 +0100, Segher Boessenkool wrote:
 No Ben.  The whole point of EARLY_DEBUG is that it _always works_,  
 because
 it is such trivial code.  Don't break that please, or we'll be forced to
 add a REALLY_EARLY_DEBUG instead :-) 

I do tend to agree but heh... temptation to do more cute hacks ... :-)

Cheers,
Ben.


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

Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef

2009-11-26 Thread David Miller

From: Segher Boessenkool seg...@kernel.crashing.org
Date: Thu, 26 Nov 2009 22:36:41 +0100

 You're right, it's not, but makes merging less complex, and then I can
 refactor properly.

 Still, make them __be32 at least

 There is no alignment guarantee at all either, better make it all u8
 and use accessor functions everywhere.

I think that might be overkill.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support

On Fri, 2009-11-27 at 00:00 +0100, Segher Boessenkool wrote:
  +unsigned int flipper_pic_get_irq(void)
  +{
  +   void __iomem *io_base = flipper_irq_host-host_data;
  +   int irq;
  +   u32 irq_status;
  +
  +   irq_status = in_be32(io_base + FLIPPER_ICR) 
  +in_be32(io_base + FLIPPER_IMR);
  +   if (irq_status == 0)
  +   return -1;  /* no more IRQs pending */
 
  NO_IRQ_IGNORE
 
  Why no just 0 ? (aka NO_IRQ)
 
  Or do you know you are getting lots of spurrious that you don't  
  want to
  account ?
 
 IRQ #0 is a valid IRQ here (graphics error IIRC), it should be
 remapped I suppose?

All interrupts are remapped. _get_irq() should call the appropriate
revmap function to remap the HW number into a linux number. 0 is never a
valid linux number and means no interrupt.

In the above case, it would seem to me that what he gets is a bitfield
so 0 means no interrupt. Hence the code should be:

if (irq_status == 0)
return 0;

Then, find first bit and return the linear revmap... Just look at what
the old pmac_pic does, same stuff basically.

Cheers,
Ben.


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

Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support

Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of  
GAMECUBE_COMMON

is a good name?


I'd prefer to not use a name that implies a specific hardware to
describe two (mostly) similar but different hardwares.


Hollywood is 100% compatible to Flipper though.


No. There's no ARAM for example :)


ARAM is an external device.


+/*
+ * Each interrupt has a corresponding bit in both
+ * the Interrupt Cause (ICR) and Interrupt Mask (IMR) registers.
+ *
+ * Enabling/disabling an interrupt line involves asserting/ 
clearing
+ * the corresponding bit in IMR. ACK'ing a request simply  
involves

+ * asserting the corresponding bit in ICR.
+ */


I looked it up in YAGCD; it says that _reading_ the ICR reg already
acks all interrupts (and clears the bits), you never write this reg!


YAGCD is not always right. You should not take it as _the truth_.


Oh I know.  But I have no better source of information.  Well I could
actually test it, that's very easy using OF :-)  Let's do that.


No, it acks just a single IRQ.


No it doesn't.  Say IRQs 1 and 3 are asserted, so the reg contains  
0x0a.
Now you want to ack IRQ1; set_bit() will write 0x0a | 0x02, not  
just 0x02.


Let me rephrase it. No it should just ack a single IRQ :)

So then this is working by accident.
If that's the case, I guess it works because the interrupt is not  
cleared at the source and the ICR is set again immediately for any  
pending interrupt?


Probably, yes.  Also, you will not often have more than one interrupt
pending anyway (on the legacy PIC).


Segher

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

Re: [RFC PATCH 12/19] powerpc: gamecube: platform support


We need it as it currently doesn't match with the default bus ids.


Should I introduce a .type property matching any of those above  
in the

soc node, and get rid of the explicit bus probe?


You don't need any fake bus as far as I can see, just probe the  
devices

you want.


But it's way easier to let the bus probe do it for us. I don't see  
the win here.


As long as this doesn't leak into the device tree in any way, I don't
care.  How's that? :-)


Segher

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

Re: [RFC PATCH 04/19] powerpc: wii: device tree


Yup. The idea is to map the first 16MB of MEM1 with a BAT.
Mapping the whole 24MB with BATs may not be possible because we  
want the framebuffer

in MEM1 for performance reasons.


How big is the fb ?


A bit more than a megabyte, something like that.


We have plenty of BATs on these things... so one 16M
for the low mem and one 64M for the high mem, that leaves something
like 6 to manage as much as possible up to the fb :-)


The CXe in the gamecube has only four BATs though.

In all code I have done for the XFB, I map it like any other RAM and
dcbst it after writing to it.  Maybe that is slower though, WIMG=0100
might be better.  Dunno.


Segher

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

Re: [RFC PATCH 02/19] powerpc: gamecube: device tree


If you have only one interrupt controller, like here, you don't
need to refer to it _at all_ :-)


I think Linux requires that you do though. It might be a mistake on
our
part but heh ...


Linux doesn't require it; (old) Macs are like this, for example,
and that works fine.  Oh and all Maple firmwares are like that as
well I think.  Etc.


It works fine on old macs thanks to a quirk we enable in the mac code
iirc and old maple works thanks to mere luck with the fallback code we
have which reads things of PCI config space :-)

Don't rely on that.


It is standard OF.  Let's fix the Linux code if that is needed (and I  
don't

think it is, anyway).

OTOH, it's nice to use the interrupt mapping stuff in all new device  
trees.



Segher

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

Re: [RFC PATCH 04/19] powerpc: wii: device tree

On Fri, 2009-11-27 at 01:16 +0100, Segher Boessenkool wrote:
 
 In all code I have done for the XFB, I map it like any other RAM and
 dcbst it after writing to it.  Maybe that is slower though, WIMG=0100
 might be better.  Dunno. 

Well, it depends also what you want to do with it. If you want to expose
it as a standard linux fbdev, it might break apps to expect them to use
dcbst... but it will make rmw cycles a lot faster and avoid wasting
memory with shadowfb.

It's going to mostly depend on what kind of HW accel we can get out of
it, if we get good enough accel we can probably got for I=1 like a
standard fb

Ben.


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

Re: [RFC] powerpc/mm: honor O_SYNC flag for memory map

2009-11-26 Thread Paul Mackerras

Li Yang writes:

 That's my concern too.  But after all mmap without O_SYNC on I/O
 devices should be deprecated.

It should?  Why?

Shouldn't the onus rather be on those proposing an incompatible change
to the kernel ABI, such as this is, to show why the change is
absolutely essential?

  A warning message in deprecation period
 could reduce potential problem caused by this change.

Not making the change at all would reduce the potential problems even
further. :)

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

Re: [PATCH] powerpc/mm: honor O_SYNC flag for memory mapping

2009-11-26 Thread Paul Mackerras

Li Yang writes:

 There was no way to set mapped memory as cacheable if the memory
 is not managed by Linux kernel.  It's not rare in real system to
 allocate some dedicated memory to a certain application which is not
 managed by kernel and then mmap'ed the memory to the application.
 The memory should be cacheable but we can't map it to be cacheable
 due to the intelligent setting of cacheability.
 
 The patch makes the cacheability depend on O_SYNC flag of the file
 mapped for non-kernel managed memory.  Also prints a deprecation
 warning for mmap users without using O_SYNC.

NAK, since it is an incompatible change to the kernel ABI.

What sort of memory is this that you want to map as cacheable?  Is it
normal system RAM that your platform code reserves, or is it some
other kind of memory?

If it's the normal system RAM, you could make phys_mem_access_prot()
smart enough to recognize that (by looking in the lmb array or the
device tree).

If it's another kind of memory, it should be described in the device
tree, and you could have a platform-specific phys_mem_access_prot
function for your platform that looks in the device tree to see if the
memory being mapped is this special sort of memory.

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

Re: [PATCH 0/4] powerpc: Fix minor build issues on 2.6.32-rc7 without CONFIG_XICS set