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

[Li Yang]

On Fri, Nov 27, 2009 at 10:30 AM, Paul Mackerras pau...@samba.org wrote:
 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?

In addition to the performance issue I stated earlier in this thread.
There was also cache paradoxes problem too.  If a memory region is
shared between two cores/OS'es and Linux can't map the region with the
same cacheable property as the other OS had mapped, there will be a
problem.  The best solution for this problem is to make the
cacheablity controllable.

And it seems to be generic issue which does not only exist on powerpc
platforms.  So it might be better dealt with the already existed
O_SYNC flag which was meant to deal with this kind of thing.  I agree
with your comment in another email that device tree could be used, but
that solution is not generic enough though.

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

[PATCH] PPC: Sync guest visible MMU state

[Alexander Graf]

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

v3 - v4:

  - don't change API to what it was before
---
 arch/powerpc/include/asm/kvm.h|   18 +++-
 arch/powerpc/include/asm/kvm_asm.h|1 +
 arch/powerpc/include/asm/kvm_book3s.h |3 ++
 arch/powerpc/kvm/book3s.c |   49 +
 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, 101 insertions(+), 16 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index c9ca97f..81f3b0b 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -47,7 +47,23 @@ struct kvm_regs {
 
 struct kvm_sregs {
__u32 pvr;
-   char pad[1020];
+   union {
+   struct {
+   __u64 sdr1;
+   struct {
+   struct {
+   __u64 slbe;
+   __u64 slbv;
+   } slb[64];
+   } ppc64;
+   struct {
+   __u32 sr[16];
+   __u64 ibat[8]; 
+   __u64 dbat[8]; 
+   } ppc32;
+   } s;
+   __u8 pad[1020];
+   } u;
 };
 
 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_MAX 16
 
 #define BOOK3S_HFLAG_DCBZ320x1
+#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..3e294bd 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,62 @@ 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)
 {
+   struct kvmppc_vcpu_book3s *vcpu3s = to_book3s(vcpu);
+   int i;
+
sregs-pvr = vcpu-arch.pvr;
+
+   sregs-u.s.sdr1 = to_book3s(vcpu)-sdr1;
+   if (vcpu-arch.hflags  BOOK3S_HFLAG_SLB) {
+   for (i = 0; i  64; i++) {
+   sregs-u.s.ppc64.slb[i].slbe = vcpu3s-slb[i].orige | i;
+   sregs-u.s.ppc64.slb[i].slbv = vcpu3s-slb[i].origv;
+   }
+   } else {
+   for (i = 0; i  16; i++) {
+   sregs-u.s.ppc32.sr[i] = vcpu3s-sr[i].raw;
+   sregs-u.s.ppc32.sr[i] = vcpu3s-sr[i].raw;
+   }
+   for (i = 0; i  8; i++) {
+   sregs-u.s.ppc32.ibat[i] = vcpu3s-ibat[i].raw;
+   sregs-u.s.ppc32.dbat[i] = vcpu3s-dbat[i].raw;
+   }
+   }
return 0;
 }
 
 int 

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

[Avi Kivity]

On 11/30/2009 03:02 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.
   


Looks good.  Ben, please carry this in your tree.

--
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] POWERPC 4xx: Fix PCI in AMCC 440EP Yosemite DTS

[Josh Boyer]

On Mon, Nov 16, 2009 at 11:36:40AM -0600, Curtis Wald wrote:
Yosemite.dts stanza for PCI was copied from Bamboo which has four PCI
slots; Yosemite only has one PCI slot which is mapped to
IDSEL 12, ADDR 22, IRQ2 Vector 25, INTA.

Signed-off-by: Curtis Wald cw...@watchguardvideo.com

Your patch looks correct (I think), but is very badly word wrapped and
whitespace damaged.  Could you resend?

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

Re: [PATCH] powerpc: Restore dma ops for powermac cardbus drivers

[roger blofeld]

 To: roger blofeld blofel...@yahoo.com

 Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; 
 sta...@kernel.org
 Sent: Sun, November 29, 2009 11:49:27 PM
 Subject: Re: [PATCH] powerpc: Restore dma ops for powermac cardbus drivers
 
 On Sun, 2009-11-29 at 20:23 -0800, roger blofeld wrote:
  Commit 4ae0ff606e848fa4957ebf8f97e5db5fdeec27be broke dma setup for cardbus
  devices such as sata_sil, rt2500 and ath5k. This patch restores the default
  dma ops for cardbus devices. Tested with sata_sil on a powerbook G4.
  
  bz#537176
  
  Signed-off-by: Roger Blofeld 
 
 Hi !
 
 That's an interesting way to do it :-)
 
 However, I suppose a better approach would be to fix cardbus to call the
 proper fixup code in the arch, ie, dma isn't the only thing that's going
 to be broken without that (at least maybe on pmac that is, but machines
 with an iommu will suffer etc...)
 
 I will try to have a look as soon as I'm done with porting the pmac IDE
 driver to libata.
 
 Cheers,
 Ben.
 

Thanks. That would be great. I just copied this mostly from what pasemi did for 
their cardbus.
-roger


  ---
  The inline patch is whitespace damaged by this mailer. The attachment 
  should 
 be ok,
  and passes checkpatch.pl
  
  
  diff -up linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c.orig 
 linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c
  --- linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c.orig
 2009-06-09 22:05:27.0 -0500
  +++ linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c2009-11-29 
 21:47:15.0 -0600
  @@ -514,6 +514,44 @@ static void __init pmac_init_early(void)
   #endif
   }
   
  +#ifdef CONFIG_CARDBUS
  +static int pmac_cardbus_notify(struct notifier_block *nb, unsigned long 
 action,
  + void *data)
  +{
  +struct device *dev = data;
  +struct device *parent;
  +struct pci_dev *pdev = to_pci_dev(dev);
  +
  +/* We are only interested in device addition */
  +if (action != BUS_NOTIFY_ADD_DEVICE)
  +return 0;
  +
  +parent = pdev-dev.parent;
  +
  +if (!parent-archdata.of_node)
  +return 0;
  +
  +if (!of_device_is_compatible(parent-archdata.of_node,
  +cardbus-bridge))
  +return 0;
  +
  +/* We use the direct ops for cardbus */
  +dev-archdata.dma_ops = dma_direct_ops;
  +
  +return 0;
  +}
  +
  +static struct notifier_block cardbus_notifier = {
  +.notifier_call = pmac_cardbus_notify,
  +};
  +
  +static int __init pmac_cardbus_init(void)
  +{
  +return bus_register_notifier(pci_bus_type, cardbus_notifier);
  +}
  +machine_device_initcall(powermac, pmac_cardbus_init);
  +#endif
  +
   static int __init pmac_declare_of_platform_devices(void)
   {
   struct device_node *np;
  
  
   
 From: Benjamin Herrenschmidt b...@kernel.crashing.org



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

Re: hypervisor call tracepoints hcall_stats touchup.

[Will Schmidt]

On Wed, 2009-11-25 at 16:19 -0500, Steven Rostedt wrote:
 On Wed, 2009-11-25 at 10:12 -0600, Will Schmidt wrote:
 
  Tested-by: Will Schmidt will_schm...@vnet.ibm.com
  Signed-off-by: Will Schmidt will_schm...@vnet.ibm.com
 
 Isn't it assumed that the one that made the patch also tested it? Well I
 would hope that is the norm.

I like to make that assumption, but wanted to be clear on the point for
anyone with doubts. :-)


 
 -- Steve
 
 


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

RE: [PATCH] POWERPC 4xx: Fix PCI in AMCC 440EP Yosemite DTS

[Curtis Wald]

Josh,
Here is a resend of the Yosemite.dts patch, deleting tabs and spaces in
the IDSEL section that should look better when viewing as 80 column. 

The comments added before the ranges declaration provides info on the
array element as processed by the kernel - there is no runtime
difference for this change, but adds some background. Since the ranges
declaration is beyond 80 columns the comments added are lined up with
the entries and when viewed as 80 column will wrap. If you have
suggestions on correcting this I will implement. 
Thanks,
-Curtis




The stanza for PCI was copied from Bamboo which has four PCI
slots; Yosemite only has one PCI slot which is mapped to
IDSEL 12, ADDR 22, IRQ2 Vector 25, INTA.

Signed-off-by: Curtis Wald cw...@watchguardvideo.com
---
 arch/powerpc/boot/dts/yosemite.dts |   17 +
 1 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/boot/dts/yosemite.dts
b/arch/powerpc/boot/dts/yosemite.dts
index 1fa3cb4..8328be5 100644
--- a/arch/powerpc/boot/dts/yosemite.dts
+++ b/arch/powerpc/boot/dts/yosemite.dts
@@ -276,27 +276,19 @@
 * later cannot be changed. Chip supports a second
 * IO range but we don't use it for now
 */
+
+ /*   u32  u64   u64
u64  */
+ /*   pci_spacepci_addr  cpu_addr
size */
 ranges = 0x0200 0x 0xa000 0x 0xa000
0x 0x2000
 0x0100 0x 0x 0x 0xe800
0x 0x0001;
 
/* Inbound 2GB range starting at 0 */
dma-ranges = 0x4200 0x0 0x0 0x0 0x0 0x0 0x8000;
 
-   /* Bamboo has all 4 IRQ pins tied together per slot */
interrupt-map-mask = 0xf800 0x0 0x0 0x0;
interrupt-map = 
-   /* IDSEL 1 */
-   0x800 0x0 0x0 0x0 UIC0 0x1c 0x8
-
-   /* IDSEL 2 */
-   0x1000 0x0 0x0 0x0 UIC0 0x1b 0x8
-
-   /* IDSEL 3 */
-   0x1800 0x0 0x0 0x0 UIC0 0x1a 0x8
-
-   /* IDSEL 4 */
-   0x2000 0x0 0x0 0x0 UIC0 0x19 0x8
+   /* IDSEL 12, ADDR 22, INTA, IRQ2 = Vector 25, 0x19 */
+   0x6000 0x0 0x0 0x0 UIC0 0x19 0x8
;
 };
};
-- 
1.5.5.6


 -Original Message-
 From: Josh Boyer [mailto:jwbo...@linux.vnet.ibm.com]
 Sent: Monday, November 30, 2009 7:42 AM
 To: Curtis Wald
 Cc: mpor...@kernel.crashing.org; linuxppc-...@ozlabs.org
 Subject: Re: [PATCH] POWERPC 4xx: Fix PCI in AMCC 440EP Yosemite DTS
 
 On Mon, Nov 16, 2009 at 11:36:40AM -0600, Curtis Wald wrote:
 Yosemite.dts stanza for PCI was copied from Bamboo which has four PCI
 slots; Yosemite only has one PCI slot which is mapped to
 IDSEL 12, ADDR 22, IRQ2 Vector 25, INTA.
 
 Signed-off-by: Curtis Wald cw...@watchguardvideo.com
 
 Your patch looks correct (I think), but is very badly word wrapped and
 whitespace damaged.  Could you resend?
 
 josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Ethernet issues with lite5200 board from linux-2.6.31

[Grant Likely]

On Mon, Nov 30, 2009 at 2:50 AM, Yogesh Chaudhari mr.yog...@gmail.com wrote:
 Hello,
         I am running linux kernel with rt patch on embedded board
 based on lite5200 eval board. From linux-2.6.31 release, in which the
 mdio patch has gone inside,  the fec ethernet does not come up on this
 board. I get the following message at startup:
 mpc52xx MII bus: probed
 mdio_bus f0003000: error probing PHY at address 1


 After the bootup if I try to do a ifconfig I get the message:
 net eth2: of_phy_connect failed


 If I change the value of reg in dts file (lite5200.dts) to 0 then this
 ethernet comes up. However upto this kernel version, this was not
 required.

 Ethernet does not come up on board with original lite5200.dts file

Is your board based on the Lite5200 or the Lite5200B?  The phys are at
different addresses on those two revisions of the board.  There is a
different .dts file for each board.

 phy0: ethernet-...@1 {
                                 reg = 1;
                         };

 Ethernet comes up on board with this change
 phy0: ethernet-...@1 {
                                 reg = 0;
                         };

Some PHYs treat address 0 as the 'broadcast' address.  You need to
fill in this field (and modify the ethernet-phy@address node name)
to reflect the address that your phy is actually at.

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

Re: [PATCH] powerpc: Fix DEBUG_HIGHMEM build break from d4515646699

[Josh Boyer]

On Mon, Nov 23, 2009 at 04:28:53PM -0600, Becky Bruce wrote:
Code was added to mm/higmem.c that depends on several
kmap types that powerpc does not support.  We add dummy
invalid definitions for KM_NMI, KM_NM_PTE, and KM_IRQ_PTE.

According to list discussion, this fix should not be needed
anymore starting with 2.6.33.  The code is commented to this
effect so hopefully we will remember to remove this.

Signed-off-by: Becky Bruce bec...@kernel.crashing.org

Ben, I see you have this queued up in you 'next' branch, but this seems to be
impacting 2.6.32 and according to the comments won't be needed in 2.6.33.
Right now, 2.6.32 doesn't build for a general Fedora ppc32 kernel because of
this bug.  Should this be sent to Linus for .32?

( http://ppc.koji.fedoraproject.org/koji/getfile?taskID=31439name=build.log
for the curious among you that want to look at the build log)

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

Re: [PATCH] ppc64: re-enable kexec to allow module loads with CONFIG_MODVERSIONS and CONFIG_RELOCATABLE turned on

[Neil Horman]

On Thu, Nov 19, 2009 at 02:52:16PM -0500, Neil Horman wrote:
 Hey there-
   Before anyone flames me for what a oddball solution this is, let me just
 say I'm trying to get the ball rolling here.  I think there may be better
 solutions that can be impemented in reloc_64.S, but I've yet to make any of 
 the
 ones I've tried work successfully.  I'm open to suggestions, but this solution
 is the only one so far that I've been able to get to work. thanks :)
 
 
 Adjust crcs in __kcrctab_* sections if relocs are used with CONFIG_RELOCATABLE
 
 When CONFIG_MODVERSIONS and CONFIG_RELOCATABLE are enabled on powerpc 
 platforms,
 kdump has been failing in a rather odd way.  specifically modules will not
 install.  This is because when validating the crcs of symbols that the module
 needs, the crc of the module never matches the crc that is stored in the 
 kernel.
 
 The underlying cause of this is how CONFIG_MODVERSIONS is implemented, and how
 CONFIG_RELOCATABLE are implemented.  with CONFIG_MODVERSIONS enabled, for 
 every
 exported symbol in the kernel we emit 2 symbols, __crc_#sym which is declared
 extern and __kcrctab_##sym, which is placed in the __kcrctab section of the
 binary.  The latter has its value set equal to the address of the former
 (recalling it is declared extern).  After the object file is built, genksyms 
 is
 run on the processed source, and crcs are computed for each exported symbol.
 genksyms then emits a linker script which defines each of the needed 
 __crc_##sym
 symbols, and sets their addresses euqal to their respective crcs.  This script
 is then used in a secondary link to the previously build object file, so that
 the crcs of the missing symbol can be validated on module insert.
 
 The problem here is that because __kcrctab_sym is set equal to __crc_##sym, a
 relocation entry is emitted by the compiler for the __kcrctab__##sym.  
 Normally
 this is not a problem, since relocation on other arches is done without the 
 aid
 of .rel.dyn sections.  PPC however uses these relocations when
 CONFIG_RELOCATABLE is enabled.  nominally, since addressing starts at 0 for 
 ppc,
 its irrelevant, but if we start at a non-zero address (like we do when booting
 via kexec from reserved crashkernel memory), the ppc boot code iterates over 
 the
 relocation entries, and winds up adding that relocation offset to all symbols,
 including the symbols that are actually the aforementioned crc values in the
 __kcrctab_* sections.  This effectively corrupts the crcs and prevents any
 module loads from happening during a kdump.
 
 My solution is to 'undo' these relocations prior to boot up.  If
 ARCH_USES_RELOC_ENTRIES is defined, we add a symbol at address zero to the
 linker script for that arch (I call it reloc_start, so that reloc_start = 0).
 This symbol will then indicate the relocation offset for any given boot.  We
 also add an initcall to the module code that, during boot, scans the 
 __kcrctab_*
 sections and subtracts reloc_start from every entry in those sections,
 restoring the appropriate crc value.
 
 I've verified that this allows kexec to work properly on ppc64 systems myself.
 
 Signed-off-by: Neil Horman nhor...@tuxdriver.com
 

Paul, Ben, given that Rusty hasn't come back with any opinion on this patch, do 
you
feel comfortable merging it via the ppc tree?  Currently the earlyinit routine
is only compiled in and used for your arch, so I think its fairly benign.

Regards
Neil

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

RE: [PATCH v2] ppc440spe-adma: adds updated ppc440spe adma driver

[Tirumala Reddy Marri]

Sorry I meant drver/. Probably you should consider how the iop-dma is
done. 

-Original Message-
From: Anatolij Gustschin [mailto:ag...@denx.de] 
Sent: Friday, November 27, 2009 2:27 AM
To: Tirumala Reddy Marri
Cc: linux-r...@vger.kernel.org; w...@denx.de; d...@denx.de; Yuri Tikhonov;
linuxppc-...@ozlabs.org; dan.j.willi...@intel.com
Subject: Re: [PATCH v2] ppc440spe-adma: adds updated ppc440spe adma
driver

Tirumala Reddy Marri tma...@amcc.com wrote:

 Why are we having separate directory for 440spe. Can this be
generalized
 arch/dma/ppc4xx/ppc4xx_dma.c ?

currently there is only tested support for 440spe. If the driver
will be extended to support other CPUs, then the renaming can be
done while adding support for other CPUs. 'arch/' is not correct,
it should be 'driver/'.

Best regards,
Anatolij

--
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] Adding PCI-E support for 460SX based redwood board.

[Tirumala Reddy Marri]

Hi Ben,
 Could you please review the patch I sent .
Thanks,
Marri

-Original Message-
From: tma...@amcc.com [mailto:tma...@amcc.com] 
Sent: Wednesday, November 25, 2009 3:49 PM
To: linuxppc-...@ozlabs.org
Cc: tma...@macc.com; Tirumala Reddy Marri
Subject: [PATCH] Adding PCI-E support for 460SX based redwood board.

From: Tirumala Marri tma...@amcc.com

This patch would add PCI-E support for AMCC 460SX processor based 
redwood board.

Signed-off-by: Tirumala Marri tma...@amcc.com

---
 arch/powerpc/boot/dts/redwood.dts |  122
+
 arch/powerpc/sysdev/ppc4xx_pci.c  |  119

 arch/powerpc/sysdev/ppc4xx_pci.h  |   58 +
 3 files changed, 299 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/redwood.dts
b/arch/powerpc/boot/dts/redwood.dts
index ad402c4..9eeec28 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -233,6 +233,128 @@
has-inverted-stacr-oc;
has-new-stacr-staopc;
};
+   PCIE0: pc...@d {
+   device_type = pci;
+   #interrupt-cells = 1;
+   #size-cells = 2;
+   #address-cells = 3;
+   compatible = ibm,plb-pciex-460sx,
ibm,plb-pciex;
+   primary;
+   port = 0x0; /* port number */
+   reg = 0x000d 0x 0x2000
/* Config space access */
+  0x000c 0x1000
0x1000;/* Registers */
+   dcr-reg = 0x100 0x020;
+   sdr-base = 0x300;
+
+   /* Outbound ranges, one memory and one
IO,
+* later cannot be changed
+*/
+   ranges = 0x0200 0x
0x8000 0x000e 0x 0x 0x8000
+ 0x0100 0x
0x 0x000f 0x8000 0x 0x0001;
+
+   /* Inbound 2GB range starting at 0 */
+   dma-ranges = 0x4200 0x0 0x0 0x0 0x0
0x0 0x8000;
+
+   /* This drives busses 10 to 0x1f */
+   bus-range = 0x10 0x1f;
+
+   /* Legacy interrupts (note the weird
polarity, the bridge seems
+* to invert PCIe legacy interrupts).
+* We are de-swizzling here because the
numbers are actually for
+* port of the root complex virtual P2P
bridge. But I want
+* to avoid putting a node for it in the
tree, so the numbers
+* below are basically de-swizzled
numbers.
+* The real slot is on idsel 0, so the
swizzling is 1:1
+*/
+   interrupt-map-mask = 0x0 0x0 0x0 0x7;
+   interrupt-map = 
+   0x0 0x0 0x0 0x1 UIC3 0x0 0x4 /*
swizzled int A */
+   0x0 0x0 0x0 0x2 UIC3 0x1 0x4 /*
swizzled int B */
+   0x0 0x0 0x0 0x3 UIC3 0x2 0x4 /*
swizzled int C */
+   0x0 0x0 0x0 0x4 UIC3 0x3 0x4 /*
swizzled int D */;
+   };
+
+   PCIE1: pc...@d2000 {
+   device_type = pci;
+   #interrupt-cells = 1;
+   #size-cells = 2;
+   #address-cells = 3;
+   compatible = ibm,plb-pciex-460sx,
ibm,plb-pciex;
+   primary;
+   port = 0x1; /* port number */
+   reg = 0x000d 0x2000 0x2000
/* Config space access */
+  0x000c 0x10001000
0x1000;/* Registers */
+   dcr-reg = 0x120 0x020;
+   sdr-base = 0x340;
+
+   /* Outbound ranges, one memory and one
IO,
+* later cannot be changed
+*/
+   ranges = 0x0200 0x
0x8000 0x000e 0x8000 0x 0x8000
+ 0x0100 0x
0x 0x000f 0x8001 0x 0x0001;
+
+   /* Inbound 2GB range starting at 0 */
+   dma-ranges = 0x4200 0x0 0x0 0x0 0x0
0x0 

RE: [PATCH] Adding PCI-E support for 460SX based redwood board.

[Benjamin Herrenschmidt]

On Mon, 2009-11-30 at 10:52 -0800, Tirumala Reddy Marri wrote:
 Hi Ben,
  Could you please review the patch I sent .
 Thanks,
 Marri

Hi !

The original message never made it. This one did but the patch is line
wrapped. Please fix your mailer and re-send.

Cheers,
Ben.

 -Original Message-
 From: tma...@amcc.com [mailto:tma...@amcc.com] 
 Sent: Wednesday, November 25, 2009 3:49 PM
 To: linuxppc-...@ozlabs.org
 Cc: tma...@macc.com; Tirumala Reddy Marri
 Subject: [PATCH] Adding PCI-E support for 460SX based redwood board.
 
 From: Tirumala Marri tma...@amcc.com
 
 This patch would add PCI-E support for AMCC 460SX processor based 
 redwood board.
 
 Signed-off-by: Tirumala Marri tma...@amcc.com
 
 ---
  arch/powerpc/boot/dts/redwood.dts |  122
 +
  arch/powerpc/sysdev/ppc4xx_pci.c  |  119
 
  arch/powerpc/sysdev/ppc4xx_pci.h  |   58 +
  3 files changed, 299 insertions(+), 0 deletions(-)
 
 diff --git a/arch/powerpc/boot/dts/redwood.dts
 b/arch/powerpc/boot/dts/redwood.dts
 index ad402c4..9eeec28 100644
 --- a/arch/powerpc/boot/dts/redwood.dts
 +++ b/arch/powerpc/boot/dts/redwood.dts
 @@ -233,6 +233,128 @@
   has-inverted-stacr-oc;
   has-new-stacr-staopc;
   };
 + PCIE0: pc...@d {
 + device_type = pci;
 + #interrupt-cells = 1;
 + #size-cells = 2;
 + #address-cells = 3;
 + compatible = ibm,plb-pciex-460sx,
 ibm,plb-pciex;
 + primary;
 + port = 0x0; /* port number */
 + reg = 0x000d 0x 0x2000
 /* Config space access */
 +0x000c 0x1000
 0x1000;  /* Registers */
 + dcr-reg = 0x100 0x020;
 + sdr-base = 0x300;
 +
 + /* Outbound ranges, one memory and one
 IO,
 +  * later cannot be changed
 +  */
 + ranges = 0x0200 0x
 0x8000 0x000e 0x 0x 0x8000
 +   0x0100 0x
 0x 0x000f 0x8000 0x 0x0001;
 +
 + /* Inbound 2GB range starting at 0 */
 + dma-ranges = 0x4200 0x0 0x0 0x0 0x0
 0x0 0x8000;
 +
 + /* This drives busses 10 to 0x1f */
 + bus-range = 0x10 0x1f;
 +
 + /* Legacy interrupts (note the weird
 polarity, the bridge seems
 +  * to invert PCIe legacy interrupts).
 +  * We are de-swizzling here because the
 numbers are actually for
 +  * port of the root complex virtual P2P
 bridge. But I want
 +  * to avoid putting a node for it in the
 tree, so the numbers
 +  * below are basically de-swizzled
 numbers.
 +  * The real slot is on idsel 0, so the
 swizzling is 1:1
 +  */
 + interrupt-map-mask = 0x0 0x0 0x0 0x7;
 + interrupt-map = 
 + 0x0 0x0 0x0 0x1 UIC3 0x0 0x4 /*
 swizzled int A */
 + 0x0 0x0 0x0 0x2 UIC3 0x1 0x4 /*
 swizzled int B */
 + 0x0 0x0 0x0 0x3 UIC3 0x2 0x4 /*
 swizzled int C */
 + 0x0 0x0 0x0 0x4 UIC3 0x3 0x4 /*
 swizzled int D */;
 + };
 +
 + PCIE1: pc...@d2000 {
 + device_type = pci;
 + #interrupt-cells = 1;
 + #size-cells = 2;
 + #address-cells = 3;
 + compatible = ibm,plb-pciex-460sx,
 ibm,plb-pciex;
 + primary;
 + port = 0x1; /* port number */
 + reg = 0x000d 0x2000 0x2000
 /* Config space access */
 +0x000c 0x10001000
 0x1000;  /* Registers */
 + dcr-reg = 0x120 0x020;
 + sdr-base = 0x340;
 +
 + /* Outbound ranges, one memory and one
 IO,
 +  * later cannot be changed
 +  */
 + ranges = 0x0200 0x
 0x8000 0x000e 0x8000 0x 0x8000
 +   0x0100 0x
 

Re: [PATCH] powerpc: Fix DEBUG_HIGHMEM build break from d4515646699

[Benjamin Herrenschmidt]

On Mon, 2009-11-30 at 12:57 -0500, Josh Boyer wrote:
 On Mon, Nov 23, 2009 at 04:28:53PM -0600, Becky Bruce wrote:
 Code was added to mm/higmem.c that depends on several
 kmap types that powerpc does not support.  We add dummy
 invalid definitions for KM_NMI, KM_NM_PTE, and KM_IRQ_PTE.
 
 According to list discussion, this fix should not be needed
 anymore starting with 2.6.33.  The code is commented to this
 effect so hopefully we will remember to remove this.
 
 Signed-off-by: Becky Bruce bec...@kernel.crashing.org
 
 Ben, I see you have this queued up in you 'next' branch, but this seems to be
 impacting 2.6.32 and according to the comments won't be needed in 2.6.33.
 Right now, 2.6.32 doesn't build for a general Fedora ppc32 kernel because of
 this bug.  Should this be sent to Linus for .32?

Why would fedora have DEBUG_HIGHMEM enabled ? I'll see what I can do.

 ( http://ppc.koji.fedoraproject.org/koji/getfile?taskID=31439name=build.log
 for the curious among you that want to look at the build log)

Cheers,
Ben.

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

Re: [PATCH] powerpc: Fix DEBUG_HIGHMEM build break from d4515646699

[Josh Boyer]

On Tue, Dec 01, 2009 at 06:49:43AM +1100, Benjamin Herrenschmidt wrote:
On Mon, 2009-11-30 at 12:57 -0500, Josh Boyer wrote:
 On Mon, Nov 23, 2009 at 04:28:53PM -0600, Becky Bruce wrote:
 Code was added to mm/higmem.c that depends on several
 kmap types that powerpc does not support.  We add dummy
 invalid definitions for KM_NMI, KM_NM_PTE, and KM_IRQ_PTE.
 
 According to list discussion, this fix should not be needed
 anymore starting with 2.6.33.  The code is commented to this
 effect so hopefully we will remember to remove this.
 
 Signed-off-by: Becky Bruce bec...@kernel.crashing.org
 
 Ben, I see you have this queued up in you 'next' branch, but this seems to be
 impacting 2.6.32 and according to the comments won't be needed in 2.6.33.
 Right now, 2.6.32 doesn't build for a general Fedora ppc32 kernel because of
 this bug.  Should this be sent to Linus for .32?

Why would fedora have DEBUG_HIGHMEM enabled ? I'll see what I can do.

Why shouldn't it?  Fedora generally builds rawhide kernels with all kinds of
debug options set.

When you say you'll see what you can do, do you mean you'll see if you can get
the patch into .32, or change the Fedora config?  If you mean change the Fedora
config, I can do that myself.  I was more pointing out that you have a .32
patch not needed for .33 heading for .33... ;)

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

Re: [PATCH] powerpc: Fix DEBUG_HIGHMEM build break from d4515646699

[Benjamin Herrenschmidt]

 When you say you'll see what you can do, do you mean you'll see if you can get
 the patch into .32, or change the Fedora config?  If you mean change the 
 Fedora
 config, I can do that myself.  I was more pointing out that you have a .32
 patch not needed for .33 heading for .33... ;)

I'll try to get the patch in later today

Cheers,
Ben.


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

Re: [PATCH v2 0/3] Kernel handling of Dynamic Logical Partitioning

[Nathan Fontenot]

Eric W. Biederman wrote:

Nathan Fontenot nf...@austin.ibm.com writes:


version 2 of the patch set with updates from comments.

The Dynamic Logical Partitioning (DLPAR) capabilities of the powerpc pseries
platform allows for the addition and removal of resources (i.e. cpus,
memory, pci devices) from a partition. The removal of a resource involves
removing the resource's node from the device tree and then returning the
resource to firmware via the rtas set-indicator call.  To add a resource, it
is first obtained from firmware via the rtas set-indicator call and then a
new device tree node is created using the ibm,configure-coinnector rtas call
and added to the device tree.

The following set of patches implements the needed infrastructure to have the
kernel handle the DLPAR addition and removal of cpus (other DLPAR'able items to
follow in future patches).  The framework for this is to create a set of
probe/release sysfs files that will facilitate arch-specific call-outs to handle
addition and removal of cpus to the system.


How does this differ from /sys/devices/system/cpu/cpuX/online ?

From the descriptions it appears that we already have what you are trying to
add and you just need to tie it into DLPAR on ppc.



The DLPAR and hotplug operations need to be kept separate for ppc.  One big 
reason
for this is that DLPAR operations on ppc are driven from the Hardware Management
Console (HMC).  It is (almost always) not possible to DLPAR add a resource (i.e.
cpu, memory,pcie device) from the OS.  There are HMC = firmware interactions
that must occur to make the resource available to the partition.

Second is that there are times when one would want to hotplug add/remove
a cpu but not dlpar add/remove it.

When a resource is DLPAR removed, the OS has no knowledge that the resource exists. 
Likewise, this allows the addition of resources from the HMC after the system is booted.

This is a feature of ppc partitions that allows for the dynamic movement of 
resources
between partitions.

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

Re: [PATCH 00/10 v6] Fix 8xx MMU/TLB

[Scott Wood]

Benjamin Herrenschmidt wrote:

On Fri, 2009-11-27 at 11:57 +0100, Joakim Tjernlund wrote:

Scott and Rex, I think we need you s-o-b to make it into the kernel proper.

Marcelo and Vitaly, I noticed you guys are listed as 8xx maintainers.
Have you seen this? What do you think?


I think Marcelo isn't much involved with 8xx anymore. I'd say if Scott
and Vitaly are ok, then the patches are good. But I'll wait for at least
Scott to give an Ack as he can at least test which I can't :-)


ACK

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

Re: [PATCH 00/10 v6] Fix 8xx MMU/TLB

[Joakim Tjernlund]

Scott Wood scottw...@freescale.com wrote on 30/11/2009 23:25:30:

 Benjamin Herrenschmidt wrote:
  On Fri, 2009-11-27 at 11:57 +0100, Joakim Tjernlund wrote:
  Scott and Rex, I think we need you s-o-b to make it into the kernel proper.
 
  Marcelo and Vitaly, I noticed you guys are listed as 8xx maintainers.
  Have you seen this? What do you think?
 
  I think Marcelo isn't much involved with 8xx anymore. I'd say if Scott
  and Vitaly are ok, then the patches are good. But I'll wait for at least
  Scott to give an Ack as he can at least test which I can't :-)

 ACK

Yippie, lets see if I can work up the energy to do the
same for 2.4 once this is in 2.6 :)

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

[git pull] Please pull powerpc.git merge branch

[Benjamin Herrenschmidt]

Hi Linus

Please pull one patch from Becky to fix a build breakage in 2.6.32 with
CONFIG_DEBUG_HIGHMEM. This is, I believe, the same patch that went
into ARM to fix the same issue.

Cheers,
Ben.

The following changes since commit a8a8a669ea13d792296737505adc43ccacf3a648:
  Linus Torvalds (1):
Merge branch 'i2c-pnx-fixes' of git://git.fluff.org/bjdooks/linux

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge

Becky Bruce (1):
  powerpc: Fix DEBUG_HIGHMEM build break from d4515646699

 arch/powerpc/include/asm/kmap_types.h |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)


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

[PATCH] Adding PCI-E support for 460SX based redwood board.

[tmarri]

From: Tirumala Marri tma...@amcc.com

This patch would add PCI-E support for AMCC 460SX processor based 
redwood board.

Signed-off-by: Tirumala Marri tma...@amcc.com

---
 arch/powerpc/boot/dts/redwood.dts |  122 +
 arch/powerpc/sysdev/ppc4xx_pci.c  |  119 
 arch/powerpc/sysdev/ppc4xx_pci.h  |   58 +
 3 files changed, 299 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/redwood.dts 
b/arch/powerpc/boot/dts/redwood.dts
index ad402c4..9eeec28 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -233,6 +233,128 @@
has-inverted-stacr-oc;
has-new-stacr-staopc;
};
+   PCIE0: pc...@d {
+   device_type = pci;
+   #interrupt-cells = 1;
+   #size-cells = 2;
+   #address-cells = 3;
+   compatible = ibm,plb-pciex-460sx, 
ibm,plb-pciex;
+   primary;
+   port = 0x0; /* port number */
+   reg = 0x000d 0x 0x2000 /* 
Config space access */
+  0x000c 0x1000 0x1000;   
/* Registers */
+   dcr-reg = 0x100 0x020;
+   sdr-base = 0x300;
+
+   /* Outbound ranges, one memory and one IO,
+* later cannot be changed
+*/
+   ranges = 0x0200 0x 0x8000 
0x000e 0x 0x 0x8000
+ 0x0100 0x 0x 
0x000f 0x8000 0x 0x0001;
+
+   /* Inbound 2GB range starting at 0 */
+   dma-ranges = 0x4200 0x0 0x0 0x0 0x0 0x0 
0x8000;
+
+   /* This drives busses 10 to 0x1f */
+   bus-range = 0x10 0x1f;
+
+   /* Legacy interrupts (note the weird polarity, 
the bridge seems
+* to invert PCIe legacy interrupts).
+* We are de-swizzling here because the numbers 
are actually for
+* port of the root complex virtual P2P bridge. 
But I want
+* to avoid putting a node for it in the tree, 
so the numbers
+* below are basically de-swizzled numbers.
+* The real slot is on idsel 0, so the 
swizzling is 1:1
+*/
+   interrupt-map-mask = 0x0 0x0 0x0 0x7;
+   interrupt-map = 
+   0x0 0x0 0x0 0x1 UIC3 0x0 0x4 /* 
swizzled int A */
+   0x0 0x0 0x0 0x2 UIC3 0x1 0x4 /* 
swizzled int B */
+   0x0 0x0 0x0 0x3 UIC3 0x2 0x4 /* 
swizzled int C */
+   0x0 0x0 0x0 0x4 UIC3 0x3 0x4 /* 
swizzled int D */;
+   };
+
+   PCIE1: pc...@d2000 {
+   device_type = pci;
+   #interrupt-cells = 1;
+   #size-cells = 2;
+   #address-cells = 3;
+   compatible = ibm,plb-pciex-460sx, 
ibm,plb-pciex;
+   primary;
+   port = 0x1; /* port number */
+   reg = 0x000d 0x2000 0x2000 /* 
Config space access */
+  0x000c 0x10001000 0x1000;   
/* Registers */
+   dcr-reg = 0x120 0x020;
+   sdr-base = 0x340;
+
+   /* Outbound ranges, one memory and one IO,
+* later cannot be changed
+*/
+   ranges = 0x0200 0x 0x8000 
0x000e 0x8000 0x 0x8000
+ 0x0100 0x 0x 
0x000f 0x8001 0x 0x0001;
+
+   /* Inbound 2GB range starting at 0 */
+   dma-ranges = 0x4200 0x0 0x0 0x0 0x0 0x0 
0x8000;
+
+   /* This drives busses 10 to 0x1f */
+   bus-range = 0x20 0x2f;
+
+   /* Legacy interrupts (note the weird polarity, 
the bridge seems
+* to invert PCIe legacy 

[RFC PATCH v3 0/3] rework of usbgecko-based early debug

[Albert Herranz]

This series is a rework of the previously posted patch:
- [RFC PATCH v2 08/11] powerpc: gamecube/wii: early debugging using usbgecko

It tries to implement the ideas suggested by Benjamin Herrenschmidt
regarding the use of a fixmap entry to provide a valid I/O mapping
immediately after MMU_init runs and MMU is definitively enabled.

Albert Herranz (3):
  powerpc: udbg: add early remap hook
  powerpc: udbg: add fixmap entry for early debug
  powerpc: gamecube/wii: early debugging using usbgecko

 arch/powerpc/Kconfig.debug |8 +++
 arch/powerpc/include/asm/fixmap.h  |3 +
 arch/powerpc/include/asm/udbg.h|4 +
 arch/powerpc/kernel/head_32.S  |   21 +++
 arch/powerpc/kernel/udbg.c |5 ++
 arch/powerpc/mm/init_32.c  |   10 +++
 arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c |   59 
 arch/powerpc/platforms/embedded6xx/usbgecko_udbg.h |2 +
 8 files changed, 112 insertions(+), 0 deletions(-)

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

[RFC PATCH v3 1/3] powerpc: udbg: add early remap hook

[Albert Herranz]

The udbg facility provides an early debug extension that can be enabled
using CONFIG_PPC_EARLY_DEBUG.
In some cases, this early debugging facility cannot be used after
MMU_init runs (and the MMU is loaded and enabled with the definitive
mappings) because the early mappings are not valid anymore.

This patch provides a udbg hook called udbg_early_remap that gets called
at the end of MMU_init and can be used by a low level udbg driver
to accomplish several goals, like:
- extending the early debugging life by configuring and using a new
  valid I/O mapping
- safely disabling the early debugging

Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
 arch/powerpc/include/asm/udbg.h |3 +++
 arch/powerpc/kernel/udbg.c  |3 +++
 arch/powerpc/mm/init_32.c   |   10 ++
 3 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/udbg.h b/arch/powerpc/include/asm/udbg.h
index cd21e5e..9dfedec 100644
--- a/arch/powerpc/include/asm/udbg.h
+++ b/arch/powerpc/include/asm/udbg.h
@@ -18,6 +18,9 @@ extern void (*udbg_putc)(char c);
 extern void (*udbg_flush)(void);
 extern int (*udbg_getc)(void);
 extern int (*udbg_getc_poll)(void);
+#ifdef CONFIG_PPC_EARLY_DEBUG
+extern void (*udbg_early_remap)(void);
+#endif
 
 extern void udbg_puts(const char *s);
 extern int udbg_write(const char *s, int n);
diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c
index fc9af47..2711050 100644
--- a/arch/powerpc/kernel/udbg.c
+++ b/arch/powerpc/kernel/udbg.c
@@ -21,6 +21,9 @@ void (*udbg_putc)(char c);
 void (*udbg_flush)(void);
 int (*udbg_getc)(void);
 int (*udbg_getc_poll)(void);
+#ifdef CONFIG_PPC_EARLY_DEBUG
+void (*udbg_early_remap)(void);
+#endif
 
 /*
  * Early debugging facilities. You can enable _one_ of these via .config,
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 9ddcfb4..066e4ff 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -43,6 +43,7 @@
 #include asm/tlb.h
 #include asm/sections.h
 #include asm/system.h
+#include asm/udbg.h
 
 #include mmu_decl.h
 
@@ -180,6 +181,15 @@ void __init MMU_init(void)
 #ifdef CONFIG_BOOTX_TEXT
btext_unmap();
 #endif
+#ifdef CONFIG_PPC_EARLY_DEBUG
+   /*
+* This hook can be used by a low level early udbg driver to either
+* provide a new valid I/O mapping to be used after MMU_init
+* or just to safely disable actual udbg I/O from now on.
+*/
+   if (udbg_early_remap)
+   udbg_early_remap();
+#endif
 }
 
 /* This is only called until mem_init is done. */
-- 
1.6.3.3

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

[RFC PATCH v3 2/3] powerpc: udbg: add fixmap entry for early debug

[Albert Herranz]

Add a new entry to the fixmap table to allow low level early udbg drivers
to safely reserve virtual address space and create their I/O mappings.

Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
 arch/powerpc/include/asm/fixmap.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/fixmap.h 
b/arch/powerpc/include/asm/fixmap.h
index f1f4e23..424e5a6 100644
--- a/arch/powerpc/include/asm/fixmap.h
+++ b/arch/powerpc/include/asm/fixmap.h
@@ -48,6 +48,9 @@ enum fixed_addresses {
FIX_KMAP_BEGIN, /* reserved pte's for temporary kernel mappings */
FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
 #endif
+#ifdef CONFIG_PPC_EARLY_DEBUG
+   FIX_EARLY_DEBUG_BASE,
+#endif
/* FIX_PCIE_MCFG, */
__end_of_fixed_addresses
 };
-- 
1.6.3.3

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

[RFC PATCH v3 3/3] powerpc: gamecube/wii: early debugging using usbgecko

[Albert Herranz]

Add support for using the USB Gecko adapter as an early debugging
console 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.

Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
 arch/powerpc/Kconfig.debug |8 +++
 arch/powerpc/include/asm/udbg.h|1 +
 arch/powerpc/kernel/head_32.S  |   21 +++
 arch/powerpc/kernel/udbg.c |2 +
 arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c |   59 
 arch/powerpc/platforms/embedded6xx/usbgecko_udbg.h |2 +
 6 files changed, 93 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 3b10051..11e385b 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -254,6 +254,14 @@ config PPC_EARLY_DEBUG_CPM
  using a CPM-based serial port.  This assumes that the bootwrapper
  has run, and set up the CPM in a particular way.
 
+config PPC_EARLY_DEBUG_USBGECKO
+   bool Early debugging through the USB Gecko adapter
+   depends on GAMECUBE_COMMON
+   select USBGECKO_UDBG
+   help
+ Select this to enable early debugging for Nintendo GameCube/Wii
+ consoles via an external USB Gecko adapter.
+
 endchoice
 
 config PPC_EARLY_DEBUG_44x_PHYSLOW
diff --git a/arch/powerpc/include/asm/udbg.h b/arch/powerpc/include/asm/udbg.h
index 9dfedec..5abfd0f 100644
--- a/arch/powerpc/include/asm/udbg.h
+++ b/arch/powerpc/include/asm/udbg.h
@@ -54,6 +54,7 @@ extern void __init udbg_init_btext(void);
 extern void __init udbg_init_44x_as1(void);
 extern void __init udbg_init_40x_realmode(void);
 extern void __init udbg_init_cpm(void);
+extern void __init udbg_init_usbgecko(void);
 
 #endif /* __KERNEL__ */
 #endif /* _ASM_POWERPC_UDBG_H */
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 829c3fe..c3f3737 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -164,6 +164,9 @@ __after_mmu_off:
 #ifdef CONFIG_PPC_EARLY_DEBUG_CPM
bl  setup_cpm_bat
 #endif
+#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
+   bl  setup_usbgecko_bat
+#endif
 
 /*
  * Call setup_cpu for CPU 0 and initialize 6xx Idle
@@ -1203,6 +1206,24 @@ setup_cpm_bat:
blr
 #endif
 
+#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
+setup_usbgecko_bat:
+   /* prepare a BAT for early io */
+#if defined(CONFIG_GAMECUBE)
+   lis r8, 0x0c00
+#elif defined(CONFIG_WII)
+   lis r8, 0x0d00
+#else
+#error Invalid platform for USB Gecko based early debugging.
+#endif
+   mr  r11, r8
+   ori r8, r8, 0x002a  /* uncached, guarded ,rw */
+   ori r11, r11, 0x3   /* 128K */
+   mtspr   SPRN_DBAT1L, r8
+   mtspr   SPRN_DBAT1U, r11
+   blr
+#endif
+
 #ifdef CONFIG_8260
 /* Jump into the system reset for the rom.
  * We first disable the MMU, and then jump to the ROM reset address.
diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c
index 2711050..65a7926 100644
--- a/arch/powerpc/kernel/udbg.c
+++ b/arch/powerpc/kernel/udbg.c
@@ -63,6 +63,8 @@ void __init udbg_early_init(void)
udbg_init_40x_realmode();
 #elif defined(CONFIG_PPC_EARLY_DEBUG_CPM)
udbg_init_cpm();
+#elif defined(CONFIG_PPC_EARLY_DEBUG_USBGECKO)
+   udbg_init_usbgecko();
 #endif
 
 #ifdef CONFIG_PPC_EARLY_DEBUG
diff --git a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c 
b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
index ba4c7cc..3f125b6 100644
--- a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
+++ b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
@@ -17,6 +17,7 @@
 #include asm/io.h
 #include asm/prom.h
 #include asm/udbg.h
+#include asm/fixmap.h
 
 #include usbgecko_udbg.h
 
@@ -270,3 +271,61 @@ done:
of_node_put(np);
return;
 }
+
+#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
+
+static void __init ug_early_remap(void)
+{
+   unsigned long addr;
+   void __iomem *io;
+
+   if (ug_io_base) {
+   addr = (unsigned long)ug_io_base;
+   set_fixmap_nocache(FIX_EARLY_DEBUG_BASE, addr  PAGE_MASK);
+   io = (void __iomem *)__fix_to_virt(FIX_EARLY_DEBUG_BASE);
+   io += addr  ~PAGE_MASK;
+   udbg_printf(%s: %p - %p\n, __func__, ug_io_base, io);
+   ug_io_base = io;
+   }
+}
+
+static void __iomem * __init ug_early_grab_exi_io_base(void)
+{
+#if defined(CONFIG_GAMECUBE)
+   return (void __iomem *)0x0c006800;
+#elif defined(CONFIG_WII)
+   return (void __iomem *)0x0d006800;
+#else
+#error Invalid platform for USB Gecko based early debugging.
+#endif
+}
+
+/*
+ * USB Gecko early debug support initialization for udbg.
+ */
+void __init udbg_init_usbgecko(void)
+{
+   void __iomem *exi_io_base;
+
+   /*
+* At this point we have a BAT 

linux-next: powerpc tree build failure

[Stephen Rothwell]

Hi Ben,

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

arch/powerpc/mm/mmu_context_hash64.c: In function 'destroy_context':
arch/powerpc/mm/mmu_context_hash64.c:96: error: passing argument 1 of 
'subpage_prot_free' from incompatible pointer type
arch/powerpc/include/asm/mmu-hash64.h:404: note: expected 'pgd_t *' but 
argument is of type 'struct mm_struct *'

Casued by commit c045256d146800ea1d741a8e9e377dada6b7e195 (powerpc/mm:
Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT) which I
have reverted for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/


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

Re: [PATCH v2] ppc440spe-adma: adds updated ppc440spe adma driver

[Dan Williams]

Anatolij Gustschin wrote:

This patch adds new version of the PPC440SPe ADMA driver.

Signed-off-by: Anatolij Gustschin ag...@denx.de
Signed-off-by: Yuri Tikhonov y...@emcraft.com


[minor] Sign-offs are typically in delivery path order, so yours would 
appear last.


[..]

 drivers/dma/ppc440spe/ppc440spe-adma.c | 5015 
 drivers/dma/ppc440spe/ppc440spe_adma.h |  195 +
 drivers/dma/ppc440spe/ppc440spe_dma.h  |  223 +
 drivers/dma/ppc440spe/ppc440spe_xor.h  |  110 +


I belong to the school of thought that says something along the lines of 
don't duplicate the directory path in the filename.  You seem to have 
copied the iop-adma driver's inconsistent use of '-' and '_' let's not 
carry that forward, i.e. looking for a changelog like:


  drivers/dma/ppc440spe/adma.c | 5015 
  drivers/dma/ppc440spe/adma.h |  195 +
  drivers/dma/ppc440spe/dma.h  |  223 +
  drivers/dma/ppc440spe/xor.h  |  110 +


+/**
+ * ppc440spe_adma_prep_dma_pqzero_sum - prepare CDB group for
+ * a PQ_ZERO_SUM operation
+ */
+static struct dma_async_tx_descriptor *ppc440spe_adma_prep_dma_pqzero_sum(
+   struct dma_chan *chan, dma_addr_t *pq, dma_addr_t *src,
+   unsigned int src_cnt, const unsigned char *scf, size_t len,
+   enum sum_check_flags *pqres, unsigned long flags)
+{
+   struct ppc440spe_adma_chan *ppc440spe_chan;
+   struct ppc440spe_adma_desc_slot *sw_desc, *iter;
+   dma_addr_t pdest, qdest;
+   int slot_cnt, slots_per_op, idst, dst_cnt;
+
+   if (unlikely(!len))
+   return NULL;
+   if (len  PAGE_SIZE)
+   return NULL;


This won't work, as currently we'll end up in an infinite loop in 
async_syndrome_val() because all descriptor allocation failures are 
assumed to be time-limited.  The code just issues any pending operations 
and waits for descriptor resources to become available.


What this comes down to is that ppc440spe_adma is essentially fibbing 
about its support for the pq_val operation.  I think a more generic 
solution would be to advertise to the async_tx api that the driver has 
per channel temporary buffers that can be used to store intermediate pq 
results and let the async_tx api handle the emulation using its 
knowledge of -max_pq.  We would also need a mechanism for the async_tx 
api to lock out other requesters of the temporary buffer until a 
coherent set of descriptors referencing those temporary buffers has been 
submitted to the driver.  This would help other drivers like mv_xor 
which has no val support and ioatdma which currently can only validate 
up to 8 sources asynchronously.


Can you clarify what ppc440spe-adma supports in this area?  It looks 
like it has some hardware support for result checking but always needs 
to write p and/or q somewhere?  Some devices may be able to do the final 
comparison against the original parity values asynchronously while 
others may need to do it synchronously in software.  These details can 
be handled at the async_tx api level.


Until this is resolved I would prefer that ppe440spe-adma use the 
existing pq_val emulation by not setting DMA_PQ_VAL in the capability mask.


--
Dan

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

Re: [RFC PATCH v3 3/3] powerpc: gamecube/wii: early debugging using usbgecko

[Richard Holden]

Albert Herranz wrote:
 Add support for using the USB Gecko adapter as an early debugging
 console 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.
 
 Signed-off-by: Albert Herranz albert_herr...@yahoo.es
 ---
  arch/powerpc/Kconfig.debug |8 +++
  arch/powerpc/include/asm/udbg.h|1 +
  arch/powerpc/kernel/head_32.S  |   21 +++
  arch/powerpc/kernel/udbg.c |2 +
  arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c |   59 
 
  arch/powerpc/platforms/embedded6xx/usbgecko_udbg.h |2 +
  6 files changed, 93 insertions(+), 0 deletions(-)
 
 diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
 index 3b10051..11e385b 100644
 --- a/arch/powerpc/Kconfig.debug
 +++ b/arch/powerpc/Kconfig.debug
 @@ -254,6 +254,14 @@ config PPC_EARLY_DEBUG_CPM
 using a CPM-based serial port.  This assumes that the bootwrapper
 has run, and set up the CPM in a particular way.
  
 +config PPC_EARLY_DEBUG_USBGECKO
 + bool Early debugging through the USB Gecko adapter
 + depends on GAMECUBE_COMMON
 + select USBGECKO_UDBG
 + help
 +   Select this to enable early debugging for Nintendo GameCube/Wii
 +   consoles via an external USB Gecko adapter.
 +
  endchoice
  
  config PPC_EARLY_DEBUG_44x_PHYSLOW

Small nit, my preference would be for this to be in the patch 1 where it
is first referenced.

 diff --git a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c 
 b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
 index ba4c7cc..3f125b6 100644
 --- a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
 +++ b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
 @@ -17,6 +17,7 @@
  #include asm/io.h
  #include asm/prom.h
  #include asm/udbg.h
 +#include asm/fixmap.h
  
  #include usbgecko_udbg.h
  
 @@ -270,3 +271,61 @@ done:
   of_node_put(np);
   return;
  }
 +
 +#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
 +
 +static void __init ug_early_remap(void)

you may want to rename the ug_ prefix, it took me a while looking back
and forth through the patch to convince myself it wasn't a typo.

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

Re: [PATCH] ppc64: re-enable kexec to allow module loads with CONFIG_MODVERSIONS and CONFIG_RELOCATABLE turned on

[Rusty Russell]

On Tue, 1 Dec 2009 04:46:00 am Neil Horman wrote:
 Paul, Ben, given that Rusty hasn't come back with any opinion on this patch, 
 do you
 feel comfortable merging it via the ppc tree?  Currently the earlyinit routine
 is only compiled in and used for your arch, so I think its fairly benign.

Sorry, I *did* track down the archives for linuxppc-dev, then find your post,
then read your patch.  But I didn't actually reply.

Other than minor issues, there's one significant one: you shouldn't be trying
to change rodata.  It might work on PPC today, but it's poor form at least.

How's this?  Untested on ppc.

Other changes:
1) I also changed reloc_start to an array; this is a good idea for any
   linker-defined symbols so the compiler can't make assumptions about size.
2) local.h?  How about module.h?
3) I don't think the extra . = 0 is necessary.
4) ARCH_USES_RELOC_ENTRIES isn't clear enough for me; I prefer
   ARCH_RELOCATE_KCRCTAB.

module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y

http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-November/077972.html

Inspired-by: Neil Horman nhor...@tuxdriver.com
Signed-off-by: Rusty Russell ru...@rustcorp.com.au

diff --git a/arch/powerpc/include/asm/module.h 
b/arch/powerpc/include/asm/module.h
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -87,5 +87,10 @@ struct exception_table_entry;
 void sort_ex_table(struct exception_table_entry *start,
   struct exception_table_entry *finish);
 
+#ifdef CONFIG_MODVERSIONS
+#define ARCH_RELOCATES_KCRCTAB
+
+extern const unsigned long reloc_start[];
+#endif
 #endif /* __KERNEL__ */
 #endif /* _ASM_POWERPC_MODULE_H */
diff --git a/arch/powerpc/kernel/vmlinux.lds.S 
b/arch/powerpc/kernel/vmlinux.lds.S
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -38,6 +38,9 @@ jiffies = jiffies_64 + 4;
 #endif
 SECTIONS
 {
+   . = 0;
+   reloc_start = .;
+
. = KERNELBASE;
 
 /*
diff --git a/kernel/module.c b/kernel/module.c
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1030,11 +1030,23 @@ static int try_to_force_load(struct modu
 }
 
 #ifdef CONFIG_MODVERSIONS
+/* If the arch applies (non-zero) relocations to kernel kcrctab, unapply it. */
+static unsigned long maybe_relocated(unsigned long crc,
+const struct module *crc_owner)
+{
+#ifdef ARCH_RELOCATES_KCRCTAB
+   if (crc_owner == NULL)
+   return crc - (unsigned long)reloc_start;
+#endif
+   return crc;
+}
+
 static int check_version(Elf_Shdr *sechdrs,
 unsigned int versindex,
 const char *symname,
 struct module *mod, 
-const unsigned long *crc)
+const unsigned long *crc,
+const struct module *crc_owner)
 {
unsigned int i, num_versions;
struct modversion_info *versions;
@@ -1055,10 +1067,10 @@ static int check_version(Elf_Shdr *sechd
if (strcmp(versions[i].name, symname) != 0)
continue;
 
-   if (versions[i].crc == *crc)
+   if (versions[i].crc == maybe_relocated(*crc, crc_owner))
return 1;
DEBUGP(Found checksum %lX vs module %lX\n,
-  *crc, versions[i].crc);
+  maybe_relocated(*crc, crc_owner), versions[i].crc);
goto bad_version;
}
 
@@ -1081,7 +1093,8 @@ static inline int check_modstruct_versio
if (!find_symbol(MODULE_SYMBOL_PREFIX module_layout, NULL,
 crc, true, false))
BUG();
-   return check_version(sechdrs, versindex, module_layout, mod, crc);
+   return check_version(sechdrs, versindex, module_layout, mod, crc,
+NULL);
 }
 
 /* First part is kernel version, which we ignore if module has crcs. */
@@ -1099,7 +1112,8 @@ static inline int check_version(Elf_Shdr
unsigned int versindex,
const char *symname,
struct module *mod, 
-   const unsigned long *crc)
+   const unsigned long *crc,
+   const struct module *crc_owner)
 {
return 1;
 }
@@ -1134,8 +1148,8 @@ static const struct kernel_symbol *resol
/* use_module can fail due to OOM,
   or module initialization or unloading */
if (sym) {
-   if (!check_version(sechdrs, versindex, name, mod, crc) ||
-   !use_module(mod, owner))
+   if (!check_version(sechdrs, versindex, name, mod, crc, owner)
+   || !use_module(mod, owner))
sym = NULL;
}
return sym;

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org

Re: [RFC PATCH v3 3/3] powerpc: gamecube/wii: early debugging using usbgecko

[Albert Herranz]

Richard Holden wrote:
 Albert Herranz wrote:
 Add support for using the USB Gecko adapter as an early debugging
 console 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.

 Signed-off-by: Albert Herranz albert_herr...@yahoo.es
 ---
  arch/powerpc/Kconfig.debug |8 +++
  arch/powerpc/include/asm/udbg.h|1 +
  arch/powerpc/kernel/head_32.S  |   21 +++
  arch/powerpc/kernel/udbg.c |2 +
  arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c |   59 
 
  arch/powerpc/platforms/embedded6xx/usbgecko_udbg.h |2 +
  6 files changed, 93 insertions(+), 0 deletions(-)

 diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
 index 3b10051..11e385b 100644
 --- a/arch/powerpc/Kconfig.debug
 +++ b/arch/powerpc/Kconfig.debug
 @@ -254,6 +254,14 @@ config PPC_EARLY_DEBUG_CPM
using a CPM-based serial port.  This assumes that the bootwrapper
has run, and set up the CPM in a particular way.
  
 +config PPC_EARLY_DEBUG_USBGECKO
 +bool Early debugging through the USB Gecko adapter
 +depends on GAMECUBE_COMMON
 +select USBGECKO_UDBG
 +help
 +  Select this to enable early debugging for Nintendo GameCube/Wii
 +  consoles via an external USB Gecko adapter.
 +
  endchoice
  
  config PPC_EARLY_DEBUG_44x_PHYSLOW
 
 Small nit, my preference would be for this to be in the patch 1 where it
 is first referenced.
 

The first patch is generic, and uses PPC_EARLY_DEBUG.
This is the first patch where PPC_EARLY_DEBUG_USBGECKO is referenced.

 diff --git a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c 
 b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
 index ba4c7cc..3f125b6 100644
 --- a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
 +++ b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
 @@ -17,6 +17,7 @@
  #include asm/io.h
  #include asm/prom.h
  #include asm/udbg.h
 +#include asm/fixmap.h
  
  #include usbgecko_udbg.h
  
 @@ -270,3 +271,61 @@ done:
  of_node_put(np);
  return;
  }
 +
 +#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
 +
 +static void __init ug_early_remap(void)
 
 you may want to rename the ug_ prefix, it took me a while looking back
 and forth through the patch to convince myself it wasn't a typo.
 

What's wrong with ug_ ? (ug = (u)sb(g)ecko)

 -Richard Holden
 

Thanks,
Albert

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

ep440xs board boot problem

[Allan Wang]

Hello, All,

I am new to the list. I am still newbie to embedded linux. I have bought an 
ep440xs board which is similar to sequoia board. u-boot is working. I am trying 
to make it run linux.  I have the following problems and need your help. Thank 
you very much:


I am using linux kernel 2.6.30.4. I encounter 2 problems:
1. After console_init() is called inside start_kernel(), the console starts 
printing garbage like:
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x1ef600300 (irq = 16) is a 16550A
��

�
��
�.
2. It pakics when mounting the root file system(NFS):
(gdb) bt
#0  panic (fmt=0xc0290e94 VFS: Unable to mount root fs on %s)
at kernel/panic.c:70
#1  0xc02d8ce0 in mount_block_root (name=0xc0290de4 /dev/root, flags=0x8001)
at init/do_mounts.c:272
#2  0xc02d9084 in prepare_namespace () at init/do_mounts.c:415
#3  0xc02d81ec in kernel_init (unused=value optimized out) at init/main.c:885
#4  0xc000de60 in kernel_thread ()
There is a patch for Sequoia board to delete /chosen part in sequoia.dts, is 
/chosen required?

Allan



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

RE: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support

[Mahajan Vivek-B08308]

 From: Wood Scott-B07421 
 Sent: Friday, November 20, 2009 11:09 PM
  Cache-sram does not have any device tree entry since it is not a 
  hardware as such. Putting it under chosen can be another option.
  I think, Scott (cc'ed) was of the opinion that since 32b 
 base address 
  support is missing; so there is no point in moving this 
 address to the 
  command line and .config should be okay for now for it.
 
 I don't know what you mean by 32b base address support is 
 missing.  I have no objection to putting it on the command line.

It was a typo, it should be missing 36b address support. Since the
kernel 
did not run under different environment (i.e 32b / 36b base address); so
it 
was decided that .config may be okay for this.

 
 -Scott
 

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

Re: [RFC PATCH v3 3/3] powerpc: gamecube/wii: early debugging using usbgecko

[Michael Ellerman]

On Tue, 2009-12-01 at 06:23 +0100, Albert Herranz wrote:
 Richard Holden wrote:
  diff --git a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c 
  b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
  index ba4c7cc..3f125b6 100644
  --- a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
  +++ b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
  @@ -17,6 +17,7 @@
   #include asm/io.h
   #include asm/prom.h
   #include asm/udbg.h
  +#include asm/fixmap.h
   
   #include usbgecko_udbg.h
   
  @@ -270,3 +271,61 @@ done:
 of_node_put(np);
 return;
   }
  +
  +#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
  +
  +static void __init ug_early_remap(void)
  
  you may want to rename the ug_ prefix, it took me a while looking back
  and forth through the patch to convince myself it wasn't a typo.
  
 
 What's wrong with ug_ ? (ug = (u)sb(g)ecko)

What's wrong with usb_gecko_early_remap() :)

cheers



signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH v3 3/3] powerpc: gamecube/wii: early debugging using usbgecko

[Albert Herranz]

Michael Ellerman wrote:
 you may want to rename the ug_ prefix, it took me a while looking back
 and forth through the patch to convince myself it wasn't a typo.

 What's wrong with ug_ ? (ug = (u)sb(g)ecko)
 
 What's wrong with usb_gecko_early_remap() :)
 

Nothing, except that names end up been way long for my taste (like for example 
usb_gecko_early_grab_exi_io_base())
I prefer to use a shorter prefix consistently.

But that's my taste :)

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

[PATCH 1/5] powerpc/macio: Add devres support to macio_device

[Benjamin Herrenschmidt]

This adds some basic devres support. When enabled via macio_enable_devres()
resources requested by drivers will be automatically released.

Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---

 arch/powerpc/include/asm/macio.h |2 +
 drivers/macintosh/macio_asic.c   |   47 +++
 2 files changed, 49 insertions(+)

--- linux-work.orig/arch/powerpc/include/asm/macio.h2009-11-30 
12:48:33.0 +1100
+++ linux-work/arch/powerpc/include/asm/macio.h 2009-11-30 14:16:55.0 
+1100
@@ -78,6 +78,8 @@ static inline unsigned long macio_resour
return res-end - res-start + 1;
 }
 
+extern int macio_enable_devres(struct macio_dev *dev);
+
 extern int macio_request_resource(struct macio_dev *dev, int resource_no, 
const char *name);
 extern void macio_release_resource(struct macio_dev *dev, int resource_no);
 extern int macio_request_resources(struct macio_dev *dev, const char *name);
Index: linux-work/drivers/macintosh/macio_asic.c
===
--- linux-work.orig/drivers/macintosh/macio_asic.c  2009-11-30 
12:41:12.0 +1100
+++ linux-work/drivers/macintosh/macio_asic.c   2009-11-30 14:17:19.0 
+1100
@@ -538,6 +538,42 @@ void macio_unregister_driver(struct maci
driver_unregister(drv-driver);
 }
 
+/* Managed MacIO resources */
+struct macio_devres {
+   u32 res_mask;
+};
+
+static void maciom_release(struct device *gendev, void *res)
+{
+   struct macio_dev *dev = to_macio_device(gendev);
+   struct macio_devres *dr = res;
+   int i, max;
+
+   max = min(dev-n_resources, 32);
+   for (i = 0; i  max; i++) {
+   if (dr-res_mask  (1  i))
+   macio_release_resource(dev, i);
+   }
+}
+
+int macio_enable_devres(struct macio_dev *dev)
+{
+   struct macio_devres *dr;
+
+   dr = devres_find(dev-ofdev.dev, maciom_release, NULL, NULL);
+   if (!dr) {
+   dr = devres_alloc(maciom_release, sizeof(*dr), GFP_KERNEL);
+   if (!dr)
+   return -ENOMEM;
+   }
+   return devres_get(dev-ofdev.dev, dr, NULL, NULL) != NULL;
+}
+
+static struct macio_devres * find_macio_dr(struct macio_dev *dev)
+{
+   return devres_find(dev-ofdev.dev, maciom_release, NULL, NULL);
+}
+
 /**
  * macio_request_resource - Request an MMIO resource
  * @dev: pointer to the device holding the resource
@@ -555,6 +591,8 @@ void macio_unregister_driver(struct maci
 int macio_request_resource(struct macio_dev *dev, int resource_no,
   const char *name)
 {
+   struct macio_devres *dr = find_macio_dr(dev);
+
if (macio_resource_len(dev, resource_no) == 0)
return 0;

@@ -562,6 +600,9 @@ int macio_request_resource(struct macio_
macio_resource_len(dev, resource_no),
name))
goto err_out;
+
+   if (dr  resource_no  32)
+   dr-res_mask |= 1  resource_no;

return 0;
 
@@ -582,10 +623,14 @@ err_out:
  */
 void macio_release_resource(struct macio_dev *dev, int resource_no)
 {
+   struct macio_devres *dr = find_macio_dr(dev);
+
if (macio_resource_len(dev, resource_no) == 0)
return;
release_mem_region(macio_resource_start(dev, resource_no),
   macio_resource_len(dev, resource_no));
+   if (dr  resource_no  32)
+   dr-res_mask = ~(1  resource_no);
 }
 
 /**
@@ -744,3 +789,5 @@ EXPORT_SYMBOL(macio_request_resource);
 EXPORT_SYMBOL(macio_release_resource);
 EXPORT_SYMBOL(macio_request_resources);
 EXPORT_SYMBOL(macio_release_resources);
+EXPORT_SYMBOL(macio_enable_devres);
+
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/5] powerpc/macio: Add dma_parms support to macio

[Benjamin Herrenschmidt]

This adds dma_parms to macio devices and initializes them with
default values. This will allow pata_macio to setup the appropriate
max segment size for the block layer.

Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---

 arch/powerpc/include/asm/macio.h |1 +
 drivers/macintosh/macio_asic.c   |5 +
 2 files changed, 6 insertions(+)

--- linux-work.orig/arch/powerpc/include/asm/macio.h2009-11-27 
14:38:05.0 +1100
+++ linux-work/arch/powerpc/include/asm/macio.h 2009-11-27 14:38:20.0 
+1100
@@ -39,6 +39,7 @@ struct macio_dev
struct macio_bus*bus;   /* macio bus this device is on 
*/
struct macio_dev*media_bay; /* Device is part of a media 
bay */
struct of_deviceofdev;
+   struct device_dma_parameters dma_parms; /* ide needs that */
int n_resources;
struct resource resource[MACIO_DEV_COUNT_RESOURCES];
int n_interrupts;
Index: linux-work/drivers/macintosh/macio_asic.c
===
--- linux-work.orig/drivers/macintosh/macio_asic.c  2009-11-27 
14:39:24.0 +1100
+++ linux-work/drivers/macintosh/macio_asic.c   2009-11-27 16:37:39.0 
+1100
@@ -379,6 +379,11 @@ static struct macio_dev * macio_add_one_
dev-ofdev.dev.parent = parent;
dev-ofdev.dev.bus = macio_bus_type;
dev-ofdev.dev.release = macio_release_dev;
+   dev-ofdev.dev.dma_parms = dev-dma_parms;
+
+   /* Standard DMA paremeters */
+   dma_set_max_seg_size(dev-ofdev.dev, 65536);
+   dma_set_seg_boundary(dev-ofdev.dev, 0x);
 
 #ifdef CONFIG_PCI
/* Set the DMA ops to the ones from the PCI device, this could be
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 3/5] powerpc/macio: Rework hotplug media bay support

[Benjamin Herrenschmidt]

The hotplug mediabay has tendrils deep into drivers/ide code
which makes a libata port reather difficult. In addition it's
ugly and could be done better.

This reworks the interface between the mediabay and the rest
of the world so that:

   - Any macio_driver can now have a mediabay_event callback
which will be called when that driver sits on a mediabay and
it's been either plugged or unplugged. The device type is
passed as an argument. We can now move all the IDE cruft
into the IDE driver itself

   - A check_media_bay() function can be used to take a peek
at the type of device currently in the bay if any, a cleaner
variant of the previous function with the same name.

   - A pair of lock/unlock functions are exposed to allow the
IDE driver to block the hotplug callbacks during the initial
setup and probing of the bay in order to avoid nasty race
conditions.

   - The mediabay code no longer needs to spin on the status
register of the IDE interface when it detects an IDE device,
this is done just fine by the IDE code itself

Overall, less code, simpler, and allows for another driver
than our old drivers/ide based one.

Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---

 arch/powerpc/include/asm/macio.h|3 
 arch/powerpc/include/asm/mediabay.h |   29 +--
 drivers/block/swim3.c   |   39 +---
 drivers/ide/pmac.c  |   87 ++---
 drivers/macintosh/mediabay.c|  328 +---
 5 files changed, 213 insertions(+), 273 deletions(-)

--- linux-work.orig/arch/powerpc/include/asm/macio.h2009-12-01 
16:51:50.0 +1100
+++ linux-work/arch/powerpc/include/asm/macio.h 2009-12-01 16:51:51.0 
+1100
@@ -134,6 +134,9 @@ struct macio_driver
int (*resume)(struct macio_dev* dev);
int (*shutdown)(struct macio_dev* dev);
 
+#ifdef CONFIG_PMAC_MEDIABAY
+   void(*mediabay_event)(struct macio_dev* dev, int mb_state);
+#endif
struct device_driverdriver;
 };
 #defineto_macio_driver(drv) container_of(drv,struct macio_driver, 
driver)
Index: linux-work/arch/powerpc/include/asm/mediabay.h
===
--- linux-work.orig/arch/powerpc/include/asm/mediabay.h 2009-12-01 
16:51:11.0 +1100
+++ linux-work/arch/powerpc/include/asm/mediabay.h  2009-12-01 
17:50:11.0 +1100
@@ -17,26 +17,31 @@
 #define MB_POWER   6   /* media bay contains a Power device (???) */
 #define MB_NO  7   /* media bay contains nothing */
 
-/* Number of bays in the machine or 0 */
-extern int media_bay_count;
+struct macio_dev;
 
-#ifdef CONFIG_BLK_DEV_IDE_PMAC
-#include linux/ide.h
+#ifdef CONFIG_PMAC_MEDIABAY
 
-int check_media_bay_by_base(unsigned long base, int what);
-/* called by IDE PMAC host driver to register IDE controller for media bay */
-int media_bay_set_ide_infos(struct device_node *which_bay, unsigned long base,
-   int irq, ide_hwif_t *hwif);
-
-int check_media_bay(struct device_node *which_bay, int what);
+/* Check the content type of the bay, returns MB_NO if the bay is still
+ * transitionning
+ */
+extern int check_media_bay(struct macio_dev *bay);
+
+/* The ATA driver uses the calls below to temporarily hold on the
+ * media bay callbacks while initializing the interface
+ */
+extern void lock_media_bay(struct macio_dev *bay);
+extern void unlock_media_bay(struct macio_dev *bay);
 
 #else
 
-static inline int check_media_bay(struct device_node *which_bay, int what)
+static inline int check_media_bay(struct macio_dev *bay)
 {
-   return -ENODEV;
+   return MB_NO;
 }
 
+static inline void lock_media_bay(struct macio_dev *bay) { }
+static inline void unlock_media_bay(struct macio_dev *bay) { }
+
 #endif
 
 #endif /* __KERNEL__ */
Index: linux-work/drivers/macintosh/mediabay.c
===
--- linux-work.orig/drivers/macintosh/mediabay.c2009-12-01 
16:51:11.0 +1100
+++ linux-work/drivers/macintosh/mediabay.c 2009-12-01 17:51:32.0 
+1100
@@ -33,15 +33,6 @@
 #include linux/adb.h
 #include linux/pmu.h
 
-
-#define MB_DEBUG
-
-#ifdef MB_DEBUG
-#define MBDBG(fmt, arg...) printk(KERN_INFO fmt , ## arg)
-#else
-#define MBDBG(fmt, arg...) do { } while (0)
-#endif
-
 #define MB_FCR32(bay, r)   ((bay)-base + ((r)  2))
 #define MB_FCR8(bay, r)(((volatile u8 __iomem *)((bay)-base)) 
+ (r))
 
@@ -76,28 +67,14 @@ struct media_bay_info {
int index;
int cached_gpio;
int sleeping;
+   int user_lock;
struct mutexlock;
-#ifdef CONFIG_BLK_DEV_IDE_PMAC
-   ide_hwif_t  *cd_port;
-   void __iomem*cd_base;
-   int cd_irq;
-   int  

[PATCH 4/5] libata/sff: Use ops-bmdma_stop instead of ata_bmdma_stop()

[Benjamin Herrenschmidt]

In libata-sff, ata_sff_post_internal_cmd() directly calls ata_bmdma_stop()
instead of ap-ops-bmdma_stop(). This can be a problem for controllers
that use their own bmdma_stop for which the generic sff one isn't suitable

Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---

 drivers/ata/libata-sff.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-work.orig/drivers/ata/libata-sff.c2009-12-01 17:48:27.0 
+1100
+++ linux-work/drivers/ata/libata-sff.c 2009-12-01 17:48:48.0 +1100
@@ -2384,7 +2384,7 @@ void ata_sff_post_internal_cmd(struct at
ap-hsm_task_state = HSM_ST_IDLE;
 
if (ap-ioaddr.bmdma_addr)
-   ata_bmdma_stop(qc);
+   ap-ops-bmdma_stop(qc);
 
spin_unlock_irqrestore(ap-lock, flags);
 }
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 5/5] libata/drivers: Add pata_macio, driver Apple PowerMac/PowerBook IDE controller

[Benjamin Herrenschmidt]

This is a libata driver for the macio IDE controller used on most Apple
PowerMac and PowerBooks. It's a libata equivalent of drivers/ide/ppc/pmac.c

It supports all the features of its predecessor, including mediabay hotplug
and suspend/resume. It should also support module load/unload.

The timing calculations have been simplified to use pre-calculated tables
compared to drivers/ide/pmac.c and it uses the new mediabay interface
provided by a previous patch.

Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---

Only lightly tested so far, this is for review, NOT for merge.

I would like to merge it eventually via the powerpc tree since there's a
few dependent patches, though I would need the libata fix for
bmdma_stop to go in first, unless I carry it as well with appropriate
acks.

I have addressed some of the comments from the previous version (almost a
year ago I think). I have kept the single function for the PIO and DMA
timings due to the one bit overlap between the fields in the HW register
on the shasta chipset. It seems to work fine.


 drivers/ata/Kconfig  |   10 
 drivers/ata/Makefile |1 
 drivers/ata/pata_macio.c | 1390 +++
 3 files changed, 1401 insertions(+)

--- /dev/null   1970-01-01 00:00:00.0 +
+++ linux-work/drivers/ata/pata_macio.c 2009-12-01 17:48:48.0 +1100
@@ -0,0 +1,1390 @@
+/*
+ * Libata based driver for Apple macio family of PATA controllers
+ *
+ * Copyright 2008/2009 Benjamin Herrenschmidt, IBM Corp
+ * b...@kernel.crashing.org
+ *
+ * Some bits and pieces from drivers/ide/ppc/pmac.c
+ *
+ */
+
+#undef DEBUG
+#undef DEBUG_DMA
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/blkdev.h
+#include linux/ata.h
+#include linux/libata.h
+#include linux/adb.h
+#include linux/pmu.h
+#include linux/scatterlist.h
+#include linux/of.h
+
+#include scsi/scsi.h
+#include scsi/scsi_host.h
+#include scsi/scsi_device.h
+
+#include asm/macio.h
+#include asm/io.h
+#include asm/dbdma.h
+#include asm/pci-bridge.h
+#include asm/machdep.h
+#include asm/pmac_feature.h
+#include asm/mediabay.h
+
+#ifdef DEBUG_DMA
+#define dev_dbgdma(dev, format, arg...)\
+   dev_printk(KERN_DEBUG , dev , format , ## arg)
+#else
+#define dev_dbgdma(dev, format, arg...)\
+   ({ if (0) dev_printk(KERN_DEBUG, dev, format, ##arg); 0; })
+#endif
+
+#define DRV_NAME   pata_macio
+#define DRV_VERSION0.9
+
+/* Models of macio ATA controller */
+enum {
+   controller_ohare,   /* OHare based */
+   controller_heathrow,/* Heathrow/Paddington */
+   controller_kl_ata3, /* KeyLargo ATA-3 */
+   controller_kl_ata4, /* KeyLargo ATA-4 */
+   controller_un_ata6, /* UniNorth2 ATA-6 */
+   controller_k2_ata6, /* K2 ATA-6 */
+   controller_sh_ata6, /* Shasta ATA-6 */
+};
+
+static const char* macio_ata_names[] = {
+   OHare ATA,/* OHare based */
+   Heathrow ATA, /* Heathrow/Paddington */
+   KeyLargo ATA-3,   /* KeyLargo ATA-3 (MDMA only) */
+   KeyLargo ATA-4,   /* KeyLargo ATA-4 (UDMA/66) */
+   UniNorth ATA-6,   /* UniNorth2 ATA-6 (UDMA/100) */
+   K2 ATA-6, /* K2 ATA-6 (UDMA/100) */
+   Shasta ATA-6, /* Shasta ATA-6 (UDMA/133) */
+};
+
+/*
+ * Extra registers, both 32-bit little-endian
+ */
+#define IDE_TIMING_CONFIG  0x200
+#define IDE_INTERRUPT  0x300
+
+/* Kauai (U2) ATA has different register setup */
+#define IDE_KAUAI_PIO_CONFIG   0x200
+#define IDE_KAUAI_ULTRA_CONFIG 0x210
+#define IDE_KAUAI_POLL_CONFIG  0x220
+
+/*
+ * Timing configuration register definitions
+ */
+
+/* Number of IDE_SYSCLK_NS ticks, argument is in nanoseconds */
+#define SYSCLK_TICKS(t)(((t) + IDE_SYSCLK_NS - 1) / 
IDE_SYSCLK_NS)
+#define SYSCLK_TICKS_66(t) (((t) + IDE_SYSCLK_66_NS - 1) / 
IDE_SYSCLK_66_NS)
+#define IDE_SYSCLK_NS  30  /* 33Mhz cell */
+#define IDE_SYSCLK_66_NS   15  /* 66Mhz cell */
+
+/* 133Mhz cell, found in shasta.
+ * See comments about 100 Mhz Uninorth 2...
+ * Note that PIO_MASK and MDMA_MASK seem to overlap, that's just
+ * weird and I don't now why .. at this stage
+ */
+#define TR_133_PIOREG_PIO_MASK 0xff000fff
+#define TR_133_PIOREG_MDMA_MASK0x00fff800
+#define TR_133_UDMAREG_UDMA_MASK   0x0003
+#define TR_133_UDMAREG_UDMA_EN 0x0001
+
+/* 100Mhz cell, found in Uninorth 2 and K2. It appears as a pci device
+ * (106b/0033) on uninorth or K2 internal PCI bus and it's clock is
+ * controlled like gem or fw. It appears to be an evolution of keylargo
+ * ATA4 with a timing register extended to 2x32bits registers (one
+ * for PIO  MWDMA and one for UDMA, and a similar DBDMA channel.
+ * It has it's own local feature control register as well.
+ *
+ * After scratching my mind over the timing values, at least for PIO
+ * 

Re: [PATCH 1/5] powerpc/macio: Add devres support to macio_device

[Tejun Heo]

On 12/01/2009 04:08 PM, Benjamin Herrenschmidt wrote:
 This adds some basic devres support. When enabled via macio_enable_devres()
 resources requested by drivers will be automatically released.
 
 Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org

Acked-by: Tejun Heo t...@kernel.org

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

Re: [PATCH 4/5] libata/sff: Use ops-bmdma_stop instead of ata_bmdma_stop()

[Tejun Heo]

On 12/01/2009 04:08 PM, Benjamin Herrenschmidt wrote:
 In libata-sff, ata_sff_post_internal_cmd() directly calls ata_bmdma_stop()
 instead of ap-ops-bmdma_stop(). This can be a problem for controllers
 that use their own bmdma_stop for which the generic sff one isn't suitable
 
 Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org

Oh... that's a scary bug lurking around.  Thanks for catching it.

Acked-by: Tejun Heo t...@kernel.org

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

Re: [PATCH 4/5] libata/sff: Use ops-bmdma_stop instead of ata_bmdma_stop()

[Benjamin Herrenschmidt]

On Tue, 2009-12-01 at 16:25 +0900, Tejun Heo wrote:
 On 12/01/2009 04:08 PM, Benjamin Herrenschmidt wrote:
  In libata-sff, ata_sff_post_internal_cmd() directly calls ata_bmdma_stop()
  instead of ap-ops-bmdma_stop(). This can be a problem for controllers
  that use their own bmdma_stop for which the generic sff one isn't suitable
  
  Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
 
 Oh... that's a scary bug lurking around.  Thanks for catching it.
 
 Acked-by: Tejun Heo t...@kernel.org

Feel free to pick that one up earlier if you want (ie for 2.6.32), as
long as we manage to get it in in 2.6.33 -before- I push powerpc-next to
Linus, I'm happy :-) (or we can have it in both trees).

Cheers,
Ben.


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

Re: [PATCH 4/5] libata/sff: Use ops-bmdma_stop instead of ata_bmdma_stop()

[Tejun Heo]

On 12/01/2009 04:29 PM, Benjamin Herrenschmidt wrote:
 On Tue, 2009-12-01 at 16:25 +0900, Tejun Heo wrote:
 On 12/01/2009 04:08 PM, Benjamin Herrenschmidt wrote:
 In libata-sff, ata_sff_post_internal_cmd() directly calls ata_bmdma_stop()
 instead of ap-ops-bmdma_stop(). This can be a problem for controllers
 that use their own bmdma_stop for which the generic sff one isn't suitable

 Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org

 Oh... that's a scary bug lurking around.  Thanks for catching it.

 Acked-by: Tejun Heo t...@kernel.org
 
 Feel free to pick that one up earlier if you want (ie for 2.6.32), as
 long as we manage to get it in in 2.6.33 -before- I push powerpc-next to
 Linus, I'm happy :-) (or we can have it in both trees).

As nasty as the bug might be, given that we haven't had too much
problem with that, I think it would be best to give it some time to be
tested before releasing it to users.  It causes behavior differences
for all bmdma drivers which implement custom bmdma_stop.  It's an
apparent bug fix but well the nasty ones are always apparent bug
fixes, right?  :-)

Thanks.

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

Re: [RFC PATCH v3 3/3] powerpc: gamecube/wii: early debugging using usbgecko

[Richard Holden]

On Nov 30, 2009, at 10:23 PM, Albert Herranz wrote:

 Richard Holden wrote:
 Albert Herranz wrote:
 The first patch is generic, and uses PPC_EARLY_DEBUG.
 This is the first patch where PPC_EARLY_DEBUG_USBGECKO is referenced.

Sorry, you are correct.

 diff --git a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c 
 b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
 index ba4c7cc..3f125b6 100644
 --- a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
 +++ b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c
 @@ -17,6 +17,7 @@
 #include asm/io.h
 #include asm/prom.h
 #include asm/udbg.h
 +#include asm/fixmap.h
 
 #include usbgecko_udbg.h
 
 @@ -270,3 +271,61 @@ done:
 of_node_put(np);
 return;
 }
 +
 +#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
 +
 +static void __init ug_early_remap(void)
 
 you may want to rename the ug_ prefix, it took me a while looking back
 and forth through the patch to convince myself it wasn't a typo.
 
 
 What's wrong with ug_ ? (ug = (u)sb(g)ecko)
 

At first look I thought it was a typo of udbg_early_remap. I prefer the longer 
names although we could use gecko_early_remap unless the gecko prefix conflicts 
with anything else. If there is not going to be a non usb gecko then there is 
no need to have usb in the prefix.

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

Re: [PATCH 4/5] libata/sff: Use ops-bmdma_stop instead of ata_bmdma_stop()

[Benjamin Herrenschmidt]

On Tue, 2009-12-01 at 16:33 +0900, Tejun Heo wrote:
  Feel free to pick that one up earlier if you want (ie for 2.6.32),
 as
  long as we manage to get it in in 2.6.33 -before- I push
 powerpc-next to
  Linus, I'm happy :-) (or we can have it in both trees).
 
 As nasty as the bug might be, given that we haven't had too much
 problem with that, I think it would be best to give it some time to be
 tested before releasing it to users.  It causes behavior differences
 for all bmdma drivers which implement custom bmdma_stop.  It's an
 apparent bug fix but well the nasty ones are always apparent bug
 fixes, right?  :-) 

Yeah, I agree. I wouldn't be comfortable pushing it into .32 to be
honest after a quick grep of how many drivers actually use that hook and
considering that no problem was reported so far...

I'll merge it with the rest of the powerpc stuff during the .33 merge
window if you are ok with that.

Cheers,
Ben.


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