Re: [PATCH 4/7] Celleb: New HTAB Guest OS Interface on Beat

[Ishizaki Kou]

 On Thu, 2007-09-27 at 16:53 +0900, Ishizaki Kou wrote:
  This is a patch kit to work with new Guest OS Interface
  to tweak HTAB on Beat. It detects old and new Guest OS Interfaces
  automatically.

 You may also consider adding an API to Beat to invalidate ranges of
 addresses. We could us that through the batch invalidate mechanism to
 speed up significantly process tear down and forks typically.

Thank you for your suggestion, we'll consider it for next release of
Beat.

Best regards,
Kou Ishizaki
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at

[Ishizaki Kou]

Ben-san,

  It should have been set in setup_64.c, in setup_paca() (which is
called
  twice) in that statement:
  
  local_paca = paca[cpu];
  
  As local_paca is defined as being a variable held in register r13.
Maybe
  something bad's happening with the compiler ?

 Can you check early_setup disassembly, see if r13 is assigned (it
should
 be in two spots) and if it's clobbered by the compiler somewhere ?

 Also, you may want to try adding --ffixed-r13 to the CFLAGS in the
 makefile and let us know if it makes a difference... r13 is marked
 reserved by the ABI but segher seems to imply that gcc may decide to
ues
 it anyway (ouch !)

I reviewed early_setup() disassembly sets r13 correctly. Now I found
the kernel works well without our hack, so I think I can decline the
patch [1/7].

Commit edd0622bd2e8f755c960827e15aa6908c3c5aa94 seems to break the
kernel and commit 175587cca7447daf5a13e4a53d32360ed8cba804 backs out
the symptom.  Calling slb_flush_and_rebolt() at slb_initialize()
function breaks the SLB table since it is called before setting up
PACA.

Thank you for your hint.

Best regards,
Kou Ishizaki
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 8/15] bootwrapper: convert flatdevtree to version 16

[Milton Miller]

On Sep 27, 2007, at 9:40 PM, David Gibson wrote:
 On Thu, Sep 27, 2007 at 10:44:27AM -0500, Milton Miller wrote:
 On Sep 26, 2007, at 9:45 PM, David Gibson wrote:
 The actual binary structure is compatable, just not the contents of
 the
 properties nor how any slave cpus wait (for some trees it doesn't
 matter).

 Sorry, copy and paste error.  I was tring to point out this changelog
 in 2.6.10:

 http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;
 a=commitdiff;h=e1b47549d1588ccea1fa5726eb430aae4e80f8ed

 Hrm, I see, yes that seems conclusive enough.  Yuck.

 In which case, I think we should try to forget that v1 ever existed.
 I don't think anyone ever generated v1 trees other than kernels which
 also consumed them,

I believe this to be true, unless you count telling dtc to do so.

 and I doubt current kernels will correctly deal
 with v1 trees in this form.

I'm quite certain of that.

 In any case, this is all rather beside the point.  My basic point is
 that this bootwrapper stuff should not attempt to be a general
 backwards compatibility layer for every broken early dt format that
 ever existed.

The only broken format was v1; I was submitting v2 :-).  Version 16 was  
... to support a more compact representation, for use by embedded  
systems mostly  
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git; 
a=commitdiff;h=34153fa3af45d84f3221d9b67ba2ab7e8a220d28

 In general we should try to make sure nothing ever uses
 v16 trees.  We want, here, to do the minimum we can get away with to
 support the specific v2 trees produced by kexec-tools, as an interim
 measure

As I stated, that by itself isn't sufficient for my usage, as I have  
other v2 trees I need to deal with, at least until that generator gets  
updated.

 while kexec-tools itself is fixed to produce v17 trees (say,
 by replacing fs2dt with dtc plus a libfdt based post-processing
 program).

If you thought there were complaints trying to require an external  
utility to build zImage, just wait until you try to make kexec-tools  
not be self-contained.  Currently kexec doesn't even use a data  
directory, instead it builds the purgatory and other trampoline  
binaries into the kexec program.  Incorporating the post-processing and  
generation using libfdt (with a copy of the library in the source)  
could fly, if people don't care about kexec into kernels from 2.6.10 to  
2.6.14 when v16 was merged (about 1 year).

Actually, there is another approach: put this converter in kexec's  
purgatory or even the kexec program.  It can then run conditionally  
under command line flags to keep compatibility with the old kernels.   
If and when its is decided to only support =v16 in kexec-tools it can  
be removed and we don't have this interim support code in the kernel  
forever (I'll handle my other usage out of tree).

milton

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

Please pull from 'for-2.6.23' branch

[Kumar Gala]

Please pull from 'for-2.6.23' branch of

master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.23

to receive the following updates:

 arch/powerpc/boot/dts/mpc8349emitx.dts  |1 +
 arch/powerpc/platforms/83xx/usb.c   |4 ++--
 arch/powerpc/sysdev/commproc.c  |2 +-
 arch/ppc/8xx_io/commproc.c  |2 +-
 drivers/serial/cpm_uart/cpm_uart_cpm1.h |2 +-
 5 files changed, 6 insertions(+), 5 deletions(-)

Jochen Friedrich (3):
  [POWERPC] Fix copy'n'paste typo in commproc.c
  [PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem
  [POWERPC] Fix cpm_uart driver for cpm1 machines

[EMAIL PROTECTED] (2):
  [POWERPC] Fix mpc834x USB-MPH configuration.
  [POWERPC] mpc8349emitx.dts: Setup USB-DR for peripheral mode.

commit f93c7c5aab8d5efaf99c88c8452d9303baabc89b
Author: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date:   Fri Sep 28 16:21:15 2007 +0200

[POWERPC] mpc8349emitx.dts: Setup USB-DR for peripheral mode.

Setup dr_mode for USB-DR to peripheral as the default (host mode) doesn't 
make
much sense for the mini-AB connector on the ITX board.

Peripheral mode is preferable to OTG as the fsl_usb2_udc.c driver doesn't 
yet
properly support it.

Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]

commit 39db0fd9db6caea8887f61fee4a0e53c6f8fec5e
Author: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date:   Fri Sep 28 16:21:14 2007 +0200

[POWERPC] Fix mpc834x USB-MPH configuration.

mpc834x USB-MPH configuration got broken by commit
6f442560021aecf08658e26ed9a37e6928ef0fa1. The selection bits in SICRL
should be cleared rather than set to configure the USB MUXes for the MPH.

Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]

commit d214602804a85e5da68b745ae69d9beaa5bedc93
Author: Jochen Friedrich [EMAIL PROTECTED]
Date:   Mon Sep 24 19:15:43 2007 +0200

[POWERPC] Fix cpm_uart driver for cpm1 machines

in cpm_uart_cpm1.h, DPRAM_BASE is assigned an address derived from cpmp.
On ARC=ppc, this is a physical address with 1:1 DMA mapping which can't
be used for arithmetric compare operations with virtual addresses
returned by cpm_dpram_addr. This patch changes the assignment to use
cpm_dpram_addr as well, like in cpm_uart_cpm2.h.

Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]

commit bc63818931ea55c54d6e59b7d38bff8f295dc8c1
Author: Jochen Friedrich [EMAIL PROTECTED]
Date:   Mon Sep 24 19:14:57 2007 +0200

[PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem

cpm_dpram_addr returns physical memory of the DP RAM instead of
iomapped virtual memory. As there usually is a 1:1 MMU map of
the IMMR area, this is often not noticed. However, cpm_dpram_phys
assumes this iomapped virtual memory and returns garbage on the
1:1 mapped memory causing CPM1 uart console to fail.

This patch fixes the problem (copied from the powerpc tree).

Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]

commit 83af919e0f239e87bc644a2c932b9cebf5771380
Author: Jochen Friedrich [EMAIL PROTECTED]
Date:   Mon Sep 24 19:13:46 2007 +0200

[POWERPC] Fix copy'n'paste typo in commproc.c

The powerpc version of commproc.c exports cpm_dpram_addr twice
and cpm_dpram_phys not at all due to a typo. This patch fixes this
problem.

CC  arch/powerpc/sysdev/commproc.o
arch/powerpc/sysdev/commproc.c:398: error: redefinition of 
'__kcrctab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of 
'__kcrctab_cpm_dpram_addr' was here
arch/powerpc/sysdev/commproc.c:398: error: redefinition of 
'__kstrtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of 
'__kstrtab_cpm_dpram_addr' was here
arch/powerpc/sysdev/commproc.c:398: error: redefinition of 
'__ksymtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of 
'__ksymtab_cpm_dpram_addr' was here
make[1]: *** [arch/powerpc/sysdev/commproc.o] Error 1
make: *** [arch/powerpc/sysdev] Error 2

Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]

diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts 
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 502f47c..44c065a 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -99,6 +99,7 @@
#size-cells = 0;
interrupt-parent =  ipic ;
interrupts = 26 8;
+   dr_mode = peripheral;
phy_type = ulpi;
};

diff --git a/arch/powerpc/platforms/83xx/usb.c 
b/arch/powerpc/platforms/83xx/usb.c
index e7fdf01..eafe760 100644
--- a/arch/powerpc/platforms/83xx/usb.c
+++ 

Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[Valentine Barshak]

David Gibson wrote:
 On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote:
 Currently zImage is linked at the 4MB base address.
 Some platforms (using cuboot, treeboot) need the zImage's
 entry point and base address. They place zImage exactly
 at the base address it's been linked to. Sometimes 4MB left
 at the start of the memory is simply not enough to unpack zImage.
 This could happen with initramfs enabled, since the kernel image
 packed along with initramfs.cpio could be over 5MB in size.
 This patch checks vmlinux image size and links zImage at
 the base address that is equal to the unpacked image size
 aligned to 4MB boundary. This way zImage base address is 4MB
 only if unpacked kernel image size is less then 4MB.
 
 Good plan.  However..
 
 [snip]
 diff -ruN linux-2.6.orig/arch/powerpc/boot/zImage.lds.S 
 linux-2.6/arch/powerpc/boot/zImage.lds.S
 --- linux-2.6.orig/arch/powerpc/boot/zImage.lds.S2007-09-22 
 00:48:08.0 +0400
 +++ linux-2.6/arch/powerpc/boot/zImage.lds.S 2007-09-22 04:03:58.0 
 +0400
 @@ -3,7 +3,7 @@
  EXTERN(_zimage_start)
  SECTIONS
  {
 -  . = (4*1024*1024);
 +  . = ALIGN((_kend - _kstart), (4*1024*1024));
 
 ..I don't see any reason to keep the 4MB granularity.  I would just
 align the address to say a 64k boundary (64k because that's the
 granularity used in the normal ABI).

Looking deeper at this I've found that currently u-boot thinks that 
memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ 
defined as (8  20)), although all physical memory is identity mapped. 
That's why it puts command line and board info structure as high as 
possible within the first 8MB. This worked fine with uImage, since 
u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher 
(we need space at the start of the memory to eventually put vmlinux 
image there). So, if unpacked kernel image crosses 8MB boundary, it gets 
damaged by u-boot when it prepares cmd_line and bdinfo. The possible 
workaround for that is to always link zImage at =8MB base or to have 
4MB granularity like this:

+  . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));

Reserve at least 64K for u-boot cmd_line and bdinfo.
Thanks,
Valentine.

 
_start = .;
.text  :
{
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev

 

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

Re: [PATCH 1/2] qemu platform, v2

[Segher Boessenkool]

 I'd be following this more closely if compiling a device tree didn't 
 currently
 require an external utility (dtc or some such) that doesn't come with 
 the
 Linux kernel.  No other target platform I've built kernels for 
 requires such
 an environmental dependency.

 No?  You haven't built kernels for other platforms that have external
 dependencies such as perl, gcc, make, binutils, etc.? :)

Two of the supported Linux archs cannot be built with a mainline
compiler, even!

And I have to install GNU sed/awk to get builds to work, too.

OTOH, it would be nice if we didn't need DTC -- it itself doesn't
build out-of-the-box on all systems, either ;-)

  (This is a problem both for hardwiring the
 device tree into the kernel and for building a new boot rom from the 
 linux
 kernel's ppc boot wrapper that would contain such a device tree to 
 feed to
 the kernel.)

 It's only really been a problem for ps3 so far, since the embedded
 guys don't seem to have any difficulty with installing dtc.  We are
 looking at what to do for ps3 and prep, and the answer may well
 involve bundling dtc in the kernel source (it's not too big, around
 3400 lines).

If only a few platforms have this problem, we could instead include
their .dtb files in the kernel source tree.


Segher

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

Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at

[Segher Boessenkool]

 Also, you may want to try adding --ffixed-r13 to the CFLAGS in the
 makefile and let us know if it makes a difference... r13 is marked
 reserved by the ABI but segher seems to imply that gcc may decide to 
 ues
 it anyway (ouch !)

That's what I thought for a second, but I misread the GCC sources.

This however brings up another point: for PPC32, -ffixed-r2 is
superfluous for all the same reasons as why we don't need -ffixed-r13
on PPC64.  Is there any reason to keep it or is this just historical
cruft?


Segher

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

Re: 2.6.23-rc8 dies somewhere during boot!?

[Gerhard Pircher]

 Original-Nachricht 
 Datum: Fri, 28 Sep 2007 09:31:31 +1000
 Von: Paul Mackerras [EMAIL PROTECTED]
 An: Gerhard Pircher [EMAIL PROTECTED]
 CC: linuxppc-dev@ozlabs.org
 Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?

 You appear to have a working 16550-style serial port which the udbg
 infrastructure sees.  Thus you should be able to use xmon, talking to
I couldn't get udbg running yet. Maybe i didn't specify a proper kernel
boot argument.

 it via the serial port.  Put xmon on the kernel command line and the
 kernel will drop into xmon early in the boot process (in setup_arch).
 Then, either the kernel will oops at some point and drop into xmon,
 and you can then inspect memory and registers and get a stack trace,
 or it will hang at some point.  If it hangs, you can work out where it
 hangs by putting in breakpoints at various points and seeing which
 breakpoints you get to (this might take several boots).
Okay, I'll investigate it. Is there a documentation for xmon (Google
wasn't really helpful in this case).

Thanks!

regards,

Gerhard
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[patch 1/2] Fix mpc834x USB-MPH configuration.

[jacmet]

mpc834x USB-MPH configuration got broken by commit
6f442560021aecf08658e26ed9a37e6928ef0fa1. The selection bits in SICRL
should be cleared rather than set to configure the USB MUXes for the MPH.

Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
---
 arch/powerpc/platforms/83xx/usb.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6.23-rc8/arch/powerpc/platforms/83xx/usb.c
===
--- linux-2.6.23-rc8.orig/arch/powerpc/platforms/83xx/usb.c
+++ linux-2.6.23-rc8/arch/powerpc/platforms/83xx/usb.c
@@ -76,14 +76,14 @@
if (port0_is_dr)
printk(KERN_WARNING
834x USB port0 can't be used by both 
DR and MPH!\n);
-   sicrl |= MPC834X_SICRL_USB0;
+   sicrl = ~MPC834X_SICRL_USB0;
}
prop = of_get_property(np, port1, NULL);
if (prop) {
if (port1_is_dr)
printk(KERN_WARNING
834x USB port1 can't be used by both 
DR and MPH!\n);
-   sicrl |= MPC834X_SICRL_USB1;
+   sicrl = ~MPC834X_SICRL_USB1;
}
of_node_put(np);
}

--
Bye, Peter Korsgaard
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[patch 2/2] mpc8349emitx.dts: Setup USB-DR for peripheral mode.

[jacmet]

Setup dr_mode for USB-DR to peripheral as the default (host mode) doesn't make
much sense for the mini-AB connector on the ITX board.

Peripheral mode is preferable to OTG as the fsl_usb2_udc.c driver doesn't yet
properly support it.

Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
---
 arch/powerpc/boot/dts/mpc8349emitx.dts |1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6.23-rc8/arch/powerpc/boot/dts/mpc8349emitx.dts
===
--- linux-2.6.23-rc8.orig/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ linux-2.6.23-rc8/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -99,6 +99,7 @@
#size-cells = 0;
interrupt-parent =  ipic ;
interrupts = 26 8;
+   dr_mode = peripheral;
phy_type = ulpi;
};
 

--
Bye, Peter Korsgaard
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [Cbe-oss-dev] [patch 0/8] PS3 AV Settings Driver patches for 2.6.24

[Michael Ellerman]

On Thu, 2007-09-27 at 10:23 -0700, Geoff Levand wrote:
 Michael Ellerman wrote:
  On Wed, 2007-09-26 at 18:33 +0200, Geert Uytterhoeven wrote:
 Hi,
  
  Here are some new patches for the PS3 AV Settings Driver (ps3av), which is
  used in close collaboration with the PS3 Virtual Frame Buffer Device Driver
  (ps3fb):
[1] ps3av: eliminate unneeded temporary variables
[2] ps3av: eliminate PS3AV_DEBUG
[3] ps3av: use PS3 video mode ids in autodetect code
[4] ps3av: treat DVI-D like HDMI in autodetect
[5] ps3av: add autodetection for VESA modes
[6] ps3av: add quirk database for broken monitors
[7] ps3av: remove unused ps3av_set_mode()
[8] ps3av: don't distinguish between `boot' and `non-boot' autodetection
  
  Please review, and queue for 2.6.24 if they're ok. Thanks!
  
  Question: As several DVI-D displays advertise they support 1080i modes 
  while
  they actually don't (cfr. the quirk database), perhaps I should drop 1080i
  modes completely from the ps3av_preferred_modes[] table? Usually 720p looks
  better than 1080i anyway.  What do you think?
  
  Definitely. If the autodetection fails Linux is basically unusable on
  PS3 unless you hack the kernel sources and build your own kboot and
  otheros.bld - not entirely trivial for novice users. So it's pretty
  important that it works 100%.
 
 It is not that bad.  If a bootloader is configued to use autodetection
 so that it is shown at best video mode, then it should have advertised
 key sequences to default to known video modes, with at least a 480p 'safe'
 mode.

Oh OK, that is a good idea. What's the safe mode key sequence for the
otheros.bld you provide on kernel.org?

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person


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

Re: [PATCH 08/10] ia64: Convert cpu_sibling_map to a per_cpu data array (v3)

[Paul Jackson]

Mike,

I think there is a bug either in this ia64 patch, or in the related
generic arch patch: Convert cpu_sibling_map to be a per cpu variable
(v3).

It dies early in boot on me, on the SGI internal 8 processor IA64
system that you and I know as 'margin'.  The death is a hard hang, due
to a corrupt stack, due to a bogus cpu index.

I haven't tracked it down all the way, but have gotten this far.  If I add
the following patch, I get a panic on the BUG_ON if I have these two patches
in 2.6.23-rc8-mm1, but it boots just fine if I don't have these two patches.

It seems that the cpu_sibling_map[cpu] cpumask_t is empty (all zero
bits) with your two patches applied, but has some non-zero bits
otherwise, which leads to 'group' being NR_CPUS instead of a useful CPU
number.  Unfortunately, I have no idea why the cpu_sibling_map[cpu]
cpumask_t is empty -- good luck on that part.

The patch that catches this bug earlier is this:

--- 2.6.23-rc8-mm1.orig/kernel/sched.c  2007-09-28 01:42:20.144561024 -0700
+++ 2.6.23-rc8-mm1/kernel/sched.c   2007-09-28 02:27:14.239075497 -0700
@@ -5905,6 +5905,7 @@ static int cpu_to_phys_group(int cpu, co
 #else
group = cpu;
 #endif
+   BUG_ON(group == NR_CPUS);
if (sg)
*sg = per_cpu(sched_group_phys, group);
return group;


-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson [EMAIL PROTECTED] 1.925.600.0401
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 04/18] Xilinx Virtex: Add generic virtex board support

[Grant Likely]

From: Grant Likely [EMAIL PROTECTED]

Signed-off-by: Grant Likely [EMAIL PROTECTED]
---

 arch/powerpc/platforms/40x/Makefile |1 +
 arch/powerpc/platforms/40x/virtex.c |   50 +++
 2 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/40x/Makefile 
b/arch/powerpc/platforms/40x/Makefile
index e6c0bbd..0a3cfe9 100644
--- a/arch/powerpc/platforms/40x/Makefile
+++ b/arch/powerpc/platforms/40x/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_WALNUT) += walnut.o
+obj-$(CONFIG_XILINX_VIRTEX_GENERIC_BOARD) += virtex.o
diff --git a/arch/powerpc/platforms/40x/virtex.c 
b/arch/powerpc/platforms/40x/virtex.c
new file mode 100644
index 000..ede982c
--- /dev/null
+++ b/arch/powerpc/platforms/40x/virtex.c
@@ -0,0 +1,50 @@
+/*
+ * Xilinx Virtex (IIpro  4FX) based board support
+ *
+ * Copyright 2007 Secret Lab Technologies Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/init.h
+#include asm/machdep.h
+#include asm/prom.h
+#include asm/time.h
+#include asm/xilinx_intc.h
+#include asm/of_platform.h
+
+static int __init virtex_device_probe(void)
+{
+   if (!machine_is(virtex))
+   return 0;
+
+   of_platform_bus_probe(NULL, NULL, NULL);
+
+   return 0;
+}
+device_initcall(virtex_device_probe);
+
+static int __init virtex_probe(void)
+{
+   unsigned long root = of_get_flat_dt_root();
+
+   if (!of_flat_dt_is_compatible(root, xilinx,virtex))
+   return 0;
+
+   return 1;
+}
+
+static void __init virtex_setup_arch(void)
+{
+}
+
+define_machine(virtex) {
+   .name   = Xilinx Virtex,
+   .probe  = virtex_probe,
+   .setup_arch = virtex_setup_arch,
+   .init_IRQ   = xilinx_intc_init_tree,
+   .get_irq= xilinx_intc_get_irq,
+   .calibrate_decr = generic_calibrate_decr,
+};

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

[PATCH 13/18] Add Xilinx SystemACE entry to maintainers

[Grant Likely]

From: Grant Likely [EMAIL PROTECTED]

Signed-off-by: Grant Likely [EMAIL PROTECTED]
---

 MAINTAINERS |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index ea4ff15..759cc40 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4186,6 +4186,13 @@ W:   http://oss.sgi.com/projects/xfs
 T: git git://oss.sgi.com:8090/xfs/xfs-2.6.git
 S: Supported
 
+XILINX SYSTEMACE DRIVER
+P: Grant Likely
+M: [EMAIL PROTECTED]
+W: http://www.secretlab.ca/
+L: [EMAIL PROTECTED]
+S: Maintained
+
 XILINX UARTLITE SERIAL DRIVER
 P: Peter Korsgaard
 M: [EMAIL PROTECTED]

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

[PATCH 18/18] xsysace: Add of_platform_bus binding

[Grant Likely]

From: Grant Likely [EMAIL PROTECTED]

Signed-off-by: Grant Likely [EMAIL PROTECTED]
---

 drivers/block/xsysace.c |   89 +++
 1 files changed, 89 insertions(+), 0 deletions(-)

diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
index 296d567..a68301a 100644
--- a/drivers/block/xsysace.c
+++ b/drivers/block/xsysace.c
@@ -91,6 +91,10 @@
 #include linux/blkdev.h
 #include linux/hdreg.h
 #include linux/platform_device.h
+#if defined(CONFIG_OF)
+#include linux/of_device.h
+#include linux/of_platform.h
+#endif
 
 MODULE_AUTHOR(Grant Likely [EMAIL PROTECTED]);
 MODULE_DESCRIPTION(Xilinx SystemACE device driver);
@@ -1158,6 +1162,85 @@ static struct platform_driver ace_platform_driver = {
 };
 
 /* -
+ * OF_Platform Bus Support
+ */
+
+#if defined(CONFIG_OF)
+static int __devinit
+ace_of_probe(struct of_device *op, const struct of_device_id *match)
+{
+   struct resource res;
+   unsigned long physaddr;
+   const u32 *id;
+   int irq, bus_width, rc;
+
+   dev_dbg(op-dev, ace_of_probe(%p, %p)\n, op, match);
+
+   /* device id */
+   id = of_get_property(op-node, port-number, NULL);
+
+   /* physaddr */
+   rc = of_address_to_resource(op-node, 0, res);
+   if (rc) {
+   dev_err(op-dev, invalid address\n);
+   return rc;
+   }
+   physaddr = res.start;
+
+   /* irq */
+   irq = irq_of_parse_and_map(op-node, 0);
+
+   /* bus width */
+   bus_width = ACE_BUS_WIDTH_16;
+   if (of_find_property(op-node, 8-bit, NULL))
+   bus_width = ACE_BUS_WIDTH_8;
+
+   /* Call the bus-independant setup code */
+   return ace_alloc(op-dev, id ? *id : 0, physaddr, irq, bus_width);
+}
+
+static int __devexit ace_of_remove(struct of_device *op)
+{
+   ace_free(op-dev);
+   return 0;
+}
+
+/* Match table for of_platform binding */
+static struct of_device_id __devinit ace_of_match[] = {
+   { .compatible = xilinx,xsysace, },
+   {},
+};
+MODULE_DEVICE_TABLE(of, ace_of_match);
+
+static struct of_platform_driver ace_of_driver = {
+   .owner = THIS_MODULE,
+   .name = xsysace,
+   .match_table = ace_of_match,
+   .probe = ace_of_probe,
+   .remove = ace_of_remove,
+   .driver = {
+   .name = xsysace,
+   },
+};
+
+/* Registration helpers to keep the number of #ifdefs to a minimum */
+static int __init ace_of_register(void)
+{
+   pr_debug(xsysace: registering OF binding\n);
+   return of_register_platform_driver(ace_of_driver);
+}
+
+static void __exit ace_of_unregister(void)
+{
+   of_unregister_platform_driver(ace_of_driver);
+}
+#else /* CONFIG_OF */
+/* CONFIG_OF not enabled; do nothing helpers */
+static int __init ace_of_register(void) { return 0 }
+static void __exit ace_of_unregister(void) { }
+#endif /* CONFIG_OF */
+
+/* -
  * Module init/exit routines
  */
 static int __init ace_init(void)
@@ -1170,6 +1253,9 @@ static int __init ace_init(void)
goto err_blk;
}
 
+   if ((rc = ace_of_register()) != 0)
+   goto err_of;
+
pr_debug(xsysace: registering platform binding\n);
if ((rc = platform_driver_register(ace_platform_driver)) != 0)
goto err_plat;
@@ -1178,6 +1264,8 @@ static int __init ace_init(void)
return 0;
 
   err_plat:
+   ace_of_unregister();
+  err_of:
unregister_blkdev(ace_major, xsysace);
   err_blk:
printk(KERN_ERR xsysace: registration failed; err=%i\n, rc);
@@ -1188,6 +1276,7 @@ static void __exit ace_exit(void)
 {
pr_debug(Unregistering Xilinx SystemACE driver\n);
platform_driver_unregister(ace_platform_driver);
+   ace_of_unregister();
unregister_blkdev(ace_major, xsysace);
 }
 

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

[PATCH 10/18] Uartlite: improve in-code comments

[Grant Likely]

From: Grant Likely [EMAIL PROTECTED]

Signed-off-by: Grant Likely [EMAIL PROTECTED]
---

 drivers/serial/uartlite.c |   43 ---
 1 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index c00a627..ed13b9f 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -23,9 +23,13 @@
 #define ULITE_MINOR187
 #define ULITE_NR_UARTS 4
 
-/* For register details see datasheet:
-   http://www.xilinx.com/bvdocs/ipcenter/data_sheet/opb_uartlite.pdf
-*/
+/* -
+ * Register definitions
+ *
+ * For register details see datasheet:
+ * http://www.xilinx.com/bvdocs/ipcenter/data_sheet/opb_uartlite.pdf
+ */
+
 #define ULITE_RX   0x00
 #define ULITE_TX   0x04
 #define ULITE_STATUS   0x08
@@ -49,6 +53,10 @@
 
 static struct uart_port ulite_ports[ULITE_NR_UARTS];
 
+/* -
+ * Core UART driver operations
+ */
+
 static int ulite_receive(struct uart_port *port, int stat)
 {
struct tty_struct *tty = port-info-tty;
@@ -308,6 +316,10 @@ static struct uart_ops ulite_ops = {
.verify_port= ulite_verify_port
 };
 
+/* -
+ * Console driver operations
+ */
+
 #ifdef CONFIG_SERIAL_UARTLITE_CONSOLE
 static void ulite_console_wait_tx(struct uart_port *port)
 {
@@ -413,6 +425,19 @@ static struct uart_driver ulite_uart_driver = {
 #endif
 };
 
+/* -
+ * Port assignment functions (mapping devices to uart_port structures)
+ */
+
+/** ulite_assign: register a uartlite device with the driver
+ *
+ * @dev: pointer to device structure
+ * @id: requested id number.  Pass -1 for automatic port assignment
+ * @base: base address of uartlite registers
+ * @irq: irq number for uartlite
+ *
+ * Returns: 0 on success, 0 otherwise
+ */
 static int __devinit ulite_assign(struct device *dev, int id, u32 base, int 
irq)
 {
struct uart_port *port;
@@ -465,6 +490,10 @@ static int __devinit ulite_assign(struct device *dev, int 
id, u32 base, int irq)
return 0;
 }
 
+/** ulite_release: register a uartlite device with the driver
+ *
+ * @dev: pointer to device structure
+ */
 static int __devinit ulite_release(struct device *dev)
 {
struct uart_port *port = dev_get_drvdata(dev);
@@ -479,6 +508,10 @@ static int __devinit ulite_release(struct device *dev)
return rc;
 }
 
+/* -
+ * Platform bus binding
+ */
+
 static int __devinit ulite_probe(struct platform_device *pdev)
 {
struct resource *res, *res2;
@@ -508,6 +541,10 @@ static struct platform_driver ulite_platform_driver = {
   },
 };
 
+/* -
+ * Module setup/teardown
+ */
+
 int __init ulite_init(void)
 {
int ret;

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

[PATCH 06/18] [POWERPC] Fix UARTLITE reg io for little-endian architectures (ie. microblaze)

[Grant Likely]

From: Grant Likely [EMAIL PROTECTED]

Signed-off-by: Grant Likely [EMAIL PROTECTED]
Acked-by: John Williams [EMAIL PROTECTED]
---

 arch/ppc/syslib/virtex_devices.c |2 +-
 drivers/serial/uartlite.c|   32 
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/ppc/syslib/virtex_devices.c b/arch/ppc/syslib/virtex_devices.c
index ace4ec0..270ad3a 100644
--- a/arch/ppc/syslib/virtex_devices.c
+++ b/arch/ppc/syslib/virtex_devices.c
@@ -28,7 +28,7 @@
.num_resources = 2, \
.resource = (struct resource[]) { \
{ \
-   .start = XPAR_UARTLITE_##num##_BASEADDR + 3, \
+   .start = XPAR_UARTLITE_##num##_BASEADDR, \
.end = XPAR_UARTLITE_##num##_HIGHADDR, \
.flags = IORESOURCE_MEM, \
}, \
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index f5051cf..59b674a 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -61,7 +61,7 @@ static int ulite_receive(struct uart_port *port, int stat)
/* stats */
if (stat  ULITE_STATUS_RXVALID) {
port-icount.rx++;
-   ch = readb(port-membase + ULITE_RX);
+   ch = in_be32((void*)port-membase + ULITE_RX);
 
if (stat  ULITE_STATUS_PARITY)
port-icount.parity++;
@@ -106,7 +106,7 @@ static int ulite_transmit(struct uart_port *port, int stat)
return 0;
 
if (port-x_char) {
-   writeb(port-x_char, port-membase + ULITE_TX);
+   out_be32((void*)port-membase + ULITE_TX, port-x_char);
port-x_char = 0;
port-icount.tx++;
return 1;
@@ -115,7 +115,7 @@ static int ulite_transmit(struct uart_port *port, int stat)
if (uart_circ_empty(xmit) || uart_tx_stopped(port))
return 0;
 
-   writeb(xmit-buf[xmit-tail], port-membase + ULITE_TX);
+   out_be32((void*)port-membase + ULITE_TX, xmit-buf[xmit-tail]);
xmit-tail = (xmit-tail + 1)  (UART_XMIT_SIZE-1);
port-icount.tx++;
 
@@ -132,7 +132,7 @@ static irqreturn_t ulite_isr(int irq, void *dev_id)
int busy;
 
do {
-   int stat = readb(port-membase + ULITE_STATUS);
+   int stat = in_be32((void*)port-membase + ULITE_STATUS);
busy  = ulite_receive(port, stat);
busy |= ulite_transmit(port, stat);
} while (busy);
@@ -148,7 +148,7 @@ static unsigned int ulite_tx_empty(struct uart_port *port)
unsigned int ret;
 
spin_lock_irqsave(port-lock, flags);
-   ret = readb(port-membase + ULITE_STATUS);
+   ret = in_be32((void*)port-membase + ULITE_STATUS);
spin_unlock_irqrestore(port-lock, flags);
 
return ret  ULITE_STATUS_TXEMPTY ? TIOCSER_TEMT : 0;
@@ -171,7 +171,7 @@ static void ulite_stop_tx(struct uart_port *port)
 
 static void ulite_start_tx(struct uart_port *port)
 {
-   ulite_transmit(port, readb(port-membase + ULITE_STATUS));
+   ulite_transmit(port, in_be32((void*)port-membase + ULITE_STATUS));
 }
 
 static void ulite_stop_rx(struct uart_port *port)
@@ -200,17 +200,17 @@ static int ulite_startup(struct uart_port *port)
if (ret)
return ret;
 
-   writeb(ULITE_CONTROL_RST_RX | ULITE_CONTROL_RST_TX,
-  port-membase + ULITE_CONTROL);
-   writeb(ULITE_CONTROL_IE, port-membase + ULITE_CONTROL);
+   out_be32((void*)port-membase + ULITE_CONTROL,
+ULITE_CONTROL_RST_RX | ULITE_CONTROL_RST_TX);
+   out_be32((void*)port-membase + ULITE_CONTROL, ULITE_CONTROL_IE);
 
return 0;
 }
 
 static void ulite_shutdown(struct uart_port *port)
 {
-   writeb(0, port-membase + ULITE_CONTROL);
-   readb(port-membase + ULITE_CONTROL); /* dummy */
+   out_be32((void*)port-membase + ULITE_CONTROL, 0);
+   in_be32((void*)port-membase + ULITE_CONTROL); /* dummy */
free_irq(port-irq, port);
 }
 
@@ -314,7 +314,7 @@ static void ulite_console_wait_tx(struct uart_port *port)
 
/* wait up to 10ms for the character(s) to be sent */
for (i = 0; i  1; i++) {
-   if (readb(port-membase + ULITE_STATUS)  ULITE_STATUS_TXEMPTY)
+   if (in_be32((void*)port-membase + ULITE_STATUS)  
ULITE_STATUS_TXEMPTY)
break;
udelay(1);
}
@@ -323,7 +323,7 @@ static void ulite_console_wait_tx(struct uart_port *port)
 static void ulite_console_putchar(struct uart_port *port, int ch)
 {
ulite_console_wait_tx(port);
-   writeb(ch, port-membase + ULITE_TX);
+   out_be32((void*)port-membase + ULITE_TX, ch);
 }
 
 static void ulite_console_write(struct console *co, const char *s,
@@ -340,8 +340,8 @@ static void ulite_console_write(struct console *co, const 
char *s,
spin_lock_irqsave(port-lock, flags);
 
/* save and 

[PATCH 08/18] Uartlite: Add macro for uartlite device name

[Grant Likely]

From: Grant Likely [EMAIL PROTECTED]

Changed to make the OF bus binding a wee bit cleaner

Signed-off-by: Grant Likely [EMAIL PROTECTED]
---

 arch/powerpc/platforms/40x/Kconfig |4 ++--
 drivers/serial/uartlite.c  |5 +++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/platforms/40x/Kconfig 
b/arch/powerpc/platforms/40x/Kconfig
index 1aae0e6..44f08dd 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -65,8 +65,8 @@ config XILINX_VIRTEX_GENERIC_BOARD
bool Generic Xilinx Virtex board
depends on 40x
default y
-   select VIRTEX_II_PRO
-   select VIRTEX_4_FX
+   select XILINX_VIRTEX_II_PRO
+   select XILINX_VIRTEX_4_FX
help
  This option enables generic support for Xilinx Virtex based boards.
 
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index ae05a67..10e0da9 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -18,6 +18,7 @@
 #include linux/interrupt.h
 #include asm/io.h
 
+#define ULITE_NAME ttyUL
 #define ULITE_MAJOR204
 #define ULITE_MINOR187
 #define ULITE_NR_UARTS 4
@@ -381,7 +382,7 @@ static int __init ulite_console_setup(struct console *co, 
char *options)
 static struct uart_driver ulite_uart_driver;
 
 static struct console ulite_console = {
-   .name   = ttyUL,
+   .name   = ULITE_NAME,
.write  = ulite_console_write,
.device = uart_console_device,
.setup  = ulite_console_setup,
@@ -403,7 +404,7 @@ console_initcall(ulite_console_init);
 static struct uart_driver ulite_uart_driver = {
.owner  = THIS_MODULE,
.driver_name= uartlite,
-   .dev_name   = ttyUL,
+   .dev_name   = ULITE_NAME,
.major  = ULITE_MAJOR,
.minor  = ULITE_MINOR,
.nr = ULITE_NR_UARTS,

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

[PATCH 01/18] Virtex: Add uartlite bootwrapper driver

[Grant Likely]

From: Grant Likely [EMAIL PROTECTED]

Signed-off-by: Grant Likely [EMAIL PROTECTED]
---

 arch/powerpc/boot/Makefile   |2 +
 arch/powerpc/boot/ops.h  |1 +
 arch/powerpc/boot/serial.c   |2 +
 arch/powerpc/boot/uartlite.c |   64 ++
 4 files changed, 68 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index ca469e5..ac488ab 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -51,7 +51,7 @@ src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c 
flatdevtree_misc.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
-   cpm-serial.c stdlib.c
+   cpm-serial.c stdlib.c uartlite.c
 src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index 703255b..4ef30e4 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -84,6 +84,7 @@ int serial_console_init(void);
 int ns16550_console_init(void *devp, struct serial_console_data *scdp);
 int mpsc_console_init(void *devp, struct serial_console_data *scdp);
 int cpm_console_init(void *devp, struct serial_console_data *scdp);
+int uartlite_console_init(void *devp, struct serial_console_data *scdp);
 void *simple_alloc_init(char *base, unsigned long heap_size,
unsigned long granularity, unsigned long max_allocs);
 extern void flush_cache(void *, unsigned long);
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index d47f8e0..70f36bf 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -126,6 +126,8 @@ int serial_console_init(void)
 dt_is_compatible(devp, fsl,cpm2-scc-uart) ||
 dt_is_compatible(devp, fsl,cpm2-smc-uart))
rc = cpm_console_init(devp, serial_cd);
+   else if (dt_is_compatible(devp, xilinx,uartlite))
+   rc = uartlite_console_init(devp, serial_cd);
 
/* Add other serial console driver calls here */
 
diff --git a/arch/powerpc/boot/uartlite.c b/arch/powerpc/boot/uartlite.c
new file mode 100644
index 000..f4249a7
--- /dev/null
+++ b/arch/powerpc/boot/uartlite.c
@@ -0,0 +1,64 @@
+/*
+ * Xilinx UARTLITE bootloader driver
+ *
+ * Copyright (C) 2007 Secret Lab Technologies Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include stdarg.h
+#include stddef.h
+#include types.h
+#include string.h
+#include stdio.h
+#include io.h
+#include ops.h
+
+static void * reg_base;
+
+static int uartlite_open(void)
+{
+   /* Clear the RX FIFO */
+   out_be32(reg_base + 0x0C, 0x2);
+   return 0;
+}
+
+static void uartlite_putc(unsigned char c)
+{
+   while ((in_be32(reg_base + 0x8)  0x08) != 0); /* spin */
+   out_be32(reg_base + 0x4, c);
+}
+
+static unsigned char uartlite_getc(void)
+{
+   while ((in_be32(reg_base + 0x8)  0x01) == 0); /* spin */
+   return in_be32(reg_base);
+}
+
+static u8 uartlite_tstc(void)
+{
+   return ((in_be32(reg_base + 0x8)  0x01) != 0);
+}
+
+int uartlite_console_init(void *devp, struct serial_console_data *scdp)
+{
+   int n;
+   unsigned long reg_phys;
+
+   n = getprop(devp, virtual-reg, reg_base, sizeof(reg_base));
+   if (n != sizeof(reg_base)) {
+   if (!dt_xlate_reg(devp, 0, reg_phys, NULL))
+   return -1;
+
+   reg_base = (void *)reg_phys;
+   }
+
+   scdp-open = uartlite_open;
+   scdp-putc = uartlite_putc;
+   scdp-getc = uartlite_getc;
+   scdp-tstc = uartlite_tstc;
+   scdp-close = NULL;
+   return 0;
+}

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

[PATCH 00/18] Virtex support in arch/powerpc

[Grant Likely]

This series adds Xilinx Virtex support to arch/powerpc.  Please review
and comment.  It includes support for the uartlite and SystemACE devices

Cheers,
g.

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

Re: [PATCH 02/18] Add Kconfig macros for Xilinx Virtex support

[Scott Wood]

Grant Likely wrote:
 From: Grant Likely [EMAIL PROTECTED]
 
 Signed-off-by: Grant Likely [EMAIL PROTECTED]
 ---
 
  arch/powerpc/platforms/40x/Kconfig |   30 +-
  1 files changed, 17 insertions(+), 13 deletions(-)
 
 diff --git a/arch/powerpc/platforms/40x/Kconfig 
 b/arch/powerpc/platforms/40x/Kconfig
 index c3dce3b..1aae0e6 100644
 --- a/arch/powerpc/platforms/40x/Kconfig
 +++ b/arch/powerpc/platforms/40x/Kconfig
 @@ -61,13 +61,14 @@ config WALNUT
   help
 This option enables support for the IBM PPC405GP evaluation board.
  
 -#config XILINX_ML300
 -#bool Xilinx-ML300
 -#depends on 40x
 -#default y
 -#select VIRTEX_II_PRO
 -#help
 -#  This option enables support for the Xilinx ML300 evaluation board.
 +config XILINX_VIRTEX_GENERIC_BOARD
 + bool Generic Xilinx Virtex board
 + depends on 40x
 + default y
 + select VIRTEX_II_PRO
 + select VIRTEX_4_FX
 + help
 +   This option enables generic support for Xilinx Virtex based boards.

I don't think we want default y here.

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

[PATCH 11/18] Virtex: Port UARTLITE driver to of-platform-bus

[Grant Likely]

From: Grant Likely [EMAIL PROTECTED]

Signed-off-by: Grant Likely [EMAIL PROTECTED]
---

 drivers/serial/uartlite.c |  101 +
 1 files changed, 93 insertions(+), 8 deletions(-)

diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index ed13b9f..8f742e0 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -1,7 +1,8 @@
 /*
  * uartlite.c: Serial driver for Xilinx uartlite serial controller
  *
- * Peter Korsgaard [EMAIL PROTECTED]
+ * Copyright (C) 2006 Peter Korsgaard [EMAIL PROTECTED]
+ * Copyright (C) 2007 Secret Lab Technologies Ltd.
  *
  * This file is licensed under the terms of the GNU General Public License
  * version 2.  This program is licensed as is without any warranty of any
@@ -17,6 +18,10 @@
 #include linux/delay.h
 #include linux/interrupt.h
 #include asm/io.h
+#if defined(CONFIG_OF)
+#include linux/of_device.h
+#include linux/of_platform.h
+#endif
 
 #define ULITE_NAME ttyUL
 #define ULITE_MAJOR204
@@ -382,8 +387,10 @@ static int __init ulite_console_setup(struct console *co, 
char *options)
port = ulite_ports[co-index];
 
/* not initialized yet? */
-   if (!port-membase)
+   if (!port-membase) {
+   pr_debug(console on ttyUL%i not initialized\n, co-index);
return -ENODEV;
+   }
 
if (options)
uart_parse_options(options, baud, parity, bits, flow);
@@ -542,6 +549,72 @@ static struct platform_driver ulite_platform_driver = {
 };
 
 /* -
+ * OF bus bindings
+ */
+#if defined(CONFIG_OF)
+static int __devinit
+ulite_of_probe(struct of_device *op, const struct of_device_id *match)
+{
+   struct resource res;
+   const unsigned int *id;
+   int irq, rc;
+
+   dev_dbg(op-dev, %s(%p, %p)\n, __FUNCTION__, op, match);
+
+   rc = of_address_to_resource(op-node, 0, res);
+   if (rc) {
+   dev_err(op-dev, invalide address\n);
+   return rc;
+   }
+
+   irq = irq_of_parse_and_map(op-node, 0);
+
+   id = of_get_property(op-node, port-number, NULL);
+
+   return ulite_assign(op-dev, id ? *id : -1, res.start, irq);
+}
+
+static int ulite_of_remove(struct of_device *op)
+{
+   return ulite_release(op-dev);
+}
+
+/* Match table for of_platform binding */
+static struct of_device_id __devinit ulite_of_match[] = {
+   { .type = serial, .compatible = xilinx,uartlite, },
+   {},
+};
+MODULE_DEVICE_TABLE(of, ulite_of_match);
+
+static struct of_platform_driver ulite_of_driver = {
+   .owner = THIS_MODULE,
+   .name = uartlite,
+   .match_table = ulite_of_match,
+   .probe = ulite_of_probe,
+   .remove = ulite_of_remove,
+   .driver = {
+   .name = uartlite,
+   },
+};
+
+/* Registration helpers to keep the number of #ifdefs to a minimum */
+static inline int __init ulite_of_register(void)
+{
+   pr_debug(uartlite: calling of_register_platform_driver()\n);
+   return of_register_platform_driver(ulite_of_driver);
+}
+
+static inline void __init ulite_of_unregister(void)
+{
+   of_unregister_platform_driver(ulite_of_driver);
+}
+#else /* CONFIG_OF */
+/* CONFIG_OF not enabled; do nothing helpers */
+static inline int __init ulite_of_register(void) { return 0; }
+static inline void __init ulite_of_unregister(void) { }
+#endif /* CONFIG_OF */
+
+/* -
  * Module setup/teardown
  */
 
@@ -549,20 +622,32 @@ int __init ulite_init(void)
 {
int ret;
 
-   ret = uart_register_driver(ulite_uart_driver);
-   if (ret)
-   return ret;
+   pr_debug(uartlite: calling uart_register_driver()\n);
+   if ((ret = uart_register_driver(ulite_uart_driver)) != 0)
+   goto err_uart;
 
-   ret = platform_driver_register(ulite_platform_driver);
-   if (ret)
-   uart_unregister_driver(ulite_uart_driver);
+   if ((ret = ulite_of_register()) != 0)
+   goto err_of;
 
+   pr_debug(uartlite: calling platform_driver_register()\n);
+   if ((ret = platform_driver_register(ulite_platform_driver)) != 0)
+   goto err_plat;
+
+   return 0;
+
+err_plat:
+   ulite_of_unregister();
+err_of:
+   uart_unregister_driver(ulite_uart_driver);
+err_uart:
+   printk(KERN_ERR registering uartlite driver failed: err=%i, ret);
return ret;
 }
 
 void __exit ulite_exit(void)
 {
platform_driver_unregister(ulite_platform_driver);
+   ulite_of_unregister();
uart_unregister_driver(ulite_uart_driver);
 }
 

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

[PATCH 16/18] Sysace: minor rework and cleanup changes

[Grant Likely]

From: Grant Likely [EMAIL PROTECTED]

Signed-off-by: Grant Likely [EMAIL PROTECTED]
---

 drivers/block/xsysace.c |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
index 555939b..10bb4e5 100644
--- a/drivers/block/xsysace.c
+++ b/drivers/block/xsysace.c
@@ -158,6 +158,9 @@ MODULE_LICENSE(GPL);
 #define ACE_FIFO_SIZE (32)
 #define ACE_BUF_PER_SECTOR (ACE_SECTOR_SIZE / ACE_FIFO_SIZE)
 
+#define ACE_BUS_WIDTH_8  0
+#define ACE_BUS_WIDTH_16 1
+
 struct ace_reg_ops;
 
 struct ace_device {
@@ -931,9 +934,11 @@ static int __devinit ace_setup(struct ace_device *ace)
 {
u16 version;
u16 val;
-
int rc;
 
+   dev_dbg(ace-dev, ace_setup(ace=0x%p)\n, ace);
+   dev_dbg(ace-dev, physaddr=0x%lx irq=%i\n, ace-physaddr, ace-irq);
+
spin_lock_init(ace-lock);
init_completion(ace-id_completion);
 
@@ -982,7 +987,7 @@ static int __devinit ace_setup(struct ace_device *ace)
snprintf(ace-gd-disk_name, 32, xs%c, ace-id + 'a');
 
/* set bus width */
-   if (ace-bus_width == 1) {
+   if (ace-bus_width == ACE_BUS_WIDTH_16) {
/* 0x0101 should work regardless of endianess */
ace_out_le16(ace, ACE_BUSMODE, 0x0101);
 
@@ -1117,7 +1122,7 @@ static void __devexit ace_free(struct device *dev)
 static int __devinit ace_probe(struct platform_device *dev)
 {
unsigned long physaddr = 0;
-   int bus_width = 1; /* FIXME: should not be hard coded */
+   int bus_width = ACE_BUS_WIDTH_16; /* FIXME: should not be hard coded */
int id = dev-id;
int irq = NO_IRQ;
int i;
@@ -1166,6 +1171,7 @@ static int __init ace_init(void)
goto err_blk;
}
 
+   pr_debug(xsysace: registering platform binding\n);
if ((rc = platform_driver_register(ace_platform_driver)) != 0)
goto err_plat;
 

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

[PATCH 17/18] Sysace: Move IRQ handler registration to occur after FSM is initialized

[Grant Likely]

From: Grant Likely [EMAIL PROTECTED]

The FSM needs to be initialized before it is safe to call the ISR

Signed-off-by: Grant Likely [EMAIL PROTECTED]
---

 drivers/block/xsysace.c |   21 ++---
 1 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
index 10bb4e5..296d567 100644
--- a/drivers/block/xsysace.c
+++ b/drivers/block/xsysace.c
@@ -949,15 +949,6 @@ static int __devinit ace_setup(struct ace_device *ace)
if (!ace-baseaddr)
goto err_ioremap;
 
-   if (ace-irq != NO_IRQ) {
-   rc = request_irq(ace-irq, ace_interrupt, 0, systemace, ace);
-   if (rc) {
-   /* Failure - fall back to polled mode */
-   dev_err(ace-dev, request_irq failed\n);
-   ace-irq = NO_IRQ;
-   }
-   }
-
/*
 * Initialize the state machine tasklet and stall timer
 */
@@ -1015,6 +1006,16 @@ static int __devinit ace_setup(struct ace_device *ace)
val |= ACE_CTRL_DATABUFRDYIRQ | ACE_CTRL_ERRORIRQ;
ace_out(ace, ACE_CTRL, val);
 
+   /* Now we can hook up the irq handler */
+   if (ace-irq != NO_IRQ) {
+   rc = request_irq(ace-irq, ace_interrupt, 0, systemace, ace);
+   if (rc) {
+   /* Failure - fall back to polled mode */
+   dev_err(ace-dev, request_irq failed\n);
+   ace-irq = NO_IRQ;
+   }
+   }
+
/* Print the identification */
dev_info(ace-dev, Xilinx SystemACE revision %i.%i.%i\n,
 (version  12)  0xf, (version  8)  0x0f, version  0xff);
@@ -1035,8 +1036,6 @@ static int __devinit ace_setup(struct ace_device *ace)
blk_cleanup_queue(ace-queue);
   err_blk_initq:
iounmap(ace-baseaddr);
-   if (ace-irq != NO_IRQ)
-   free_irq(ace-irq, ace);
   err_ioremap:
dev_info(ace-dev, xsysace: error initializing device at 0x%lx\n,
   ace-physaddr);

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

Re: [PATCH 05/18] Add PowerPC Xilinx Virtex entry to maintainers

[Grant Likely]

On 9/28/07, Grant Likely [EMAIL PROTECTED] wrote:
 From: Grant Likely [EMAIL PROTECTED]

 Signed-off-by: Grant Likely [EMAIL PROTECTED]
 ---

 Paul, is this okay by you?  Josh has already okayed it.

Specifically, I'll collect the virtex changes and ask Josh to pull
them from me before requesting a pull from you.

Cheers,
g.

 diff --git a/MAINTAINERS b/MAINTAINERS
 index 8f80068..ea4ff15 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -2304,6 +2304,13 @@ L:   [EMAIL PROTECTED]
  T: git kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc.git
  S: Maintained

 +LINUX FOR POWERPC EMBEDDED XILINX VIRTEX
 +P: Grant Likely
 +M: [EMAIL PROTECTED]
 +W: http://www.secretlab.ca/
 +L: [EMAIL PROTECTED]
 +S: Maintained
 +
  LINUX FOR POWERPC BOOT CODE
  P: Tom Rini
  M: [EMAIL PROTECTED]




-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] cpm: Describe multi-user ram in its own device node.

[Scott Wood]

The way the current CPM binding describes available multi-user (a.k.a.
dual-ported) RAM doesn't work well when there are multiple free regions,
and it doesn't work at all if the region doesn't begin at the start of
the muram area (as the hardware needs to be programmed with offsets into
this area).  The latter situation can happen with SMC UARTs on CPM2, as its
parameter RAM is relocatable, u-boot puts it at zero, and the kernel doesn't
support moving it.

It is now described with a muram node, similar to QE.  The current CPM
binding is sufficiently recent (i.e. never appeared in an official release)
that compatibility with existing device trees is not an issue.

The code supporting the new binding is shared between cpm1 and cpm2, rather
than remain separated.  QE should be able to use this code as well, once
minor fixes are made to its device trees.

Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
 Documentation/powerpc/booting-without-of.txt |   40 ++-
 arch/powerpc/Kconfig.debug   |6 +-
 arch/powerpc/boot/cpm-serial.c   |   44 +--
 arch/powerpc/boot/dts/ep88xc.dts |   13 ++-
 arch/powerpc/boot/dts/mpc8272ads.dts |   11 ++
 arch/powerpc/boot/dts/mpc885ads.dts  |   13 ++-
 arch/powerpc/boot/dts/pq2fads.dts|   13 ++-
 arch/powerpc/sysdev/commproc.c   |   11 ++-
 arch/powerpc/sysdev/cpm2_common.c|   36 ++
 arch/powerpc/sysdev/cpm_common.c |  159 ++
 drivers/serial/cpm_uart/cpm_uart_cpm2.c  |4 +-
 include/asm-powerpc/commproc.h   |   12 ++
 include/asm-powerpc/cpm.h|   14 +++
 include/asm-powerpc/cpm2.h   |   10 ++
 14 files changed, 338 insertions(+), 48 deletions(-)
 create mode 100644 include/asm-powerpc/cpm.h

diff --git a/Documentation/powerpc/booting-without-of.txt 
b/Documentation/powerpc/booting-without-of.txt
index c36dcd2..ce5d67f 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1861,9 +1861,7 @@ platforms are moved over to use the flattened-device-tree 
model.
 
Properties:
- compatible : fsl,cpm1, fsl,cpm2, or fsl,qe.
-   - reg : The first resource is a 48-byte region beginning with
-   CPCR.  The second is the available general-purpose
-   DPRAM.
+   - reg : A 48-byte region beginning with CPCR.
 
Example:
[EMAIL PROTECTED] {
@@ -1871,7 +1869,7 @@ platforms are moved over to use the flattened-device-tree 
model.
#size-cells = 1;
#interrupt-cells = 2;
compatible = fsl,mpc8272-cpm, fsl,cpm2;
-   reg = 119c0 30 0 2000;
+   reg = 119c0 30;
}
 
ii) Properties common to mulitple CPM/QE devices
@@ -2017,6 +2015,40 @@ platforms are moved over to use the 
flattened-device-tree model.
fsl,cpm-command = 2e60;
};
 
+   viii) Multi-User RAM (MURAM)
+
+   The multi-user/dual-ported RAM is expressed as a bus under the CPM node.
+
+   Ranges must be set up subject to the following restrictions:
+
+   - Children's reg nodes must be offsets from the start of all muram, even
+ if the user-data area does not begin at zero.
+   - If multiple range entries are used, the difference between the parent
+ address and the child address must be the same in all, so that a single
+ mapping can cover them all while maintaining the ability to determine
+ CPM-side offsets with pointer subtraction.  It is recommended that
+ multiple range entries not be used.
+   - A child address of zero must be translatable, even if no reg resources
+ contain it.
+
+   A child data node must exist, compatible with fsl,cpm-muram-data, to
+   indicate the portion of muram that is usable by the OS for arbitrary
+   purposes.  The data node may have an arbitrary number of reg resources,
+   all of which contribute to the allocatable muram pool.
+
+   Example, based on mpc8272:
+
+   [EMAIL PROTECTED] {
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges = 0 0 1;
+
+   [EMAIL PROTECTED] {
+   compatible = fsl,cpm-muram-data;
+   reg = 0 2000 9800 800;
+   };
+   };
+
m) Chipselect/Local Bus
 
Properties:
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index f4e5d22..464f9b4 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -245,9 +245,9 @@ config PPC_EARLY_DEBUG_44x_PHYSHIGH
 config PPC_EARLY_DEBUG_CPM_ADDR
hex CPM UART early debug transmit descriptor address
depends on PPC_EARLY_DEBUG_CPM
-   default 0xfa202808 if PPC_EP88XC
-   default 0xf808 if CPM2
-   default 0xff002808 if CPM1
+   default 0xfa202008 if PPC_EP88XC
+   default 0xf008 if CPM2
+   default 0xff002008 if CPM1
help
  This 

Re: [Cbe-oss-dev] [patch 0/8] PS3 AV Settings Driver patches for 2.6.24

[Geoff Levand]

Michael Ellerman wrote:
 On Thu, 2007-09-27 at 10:23 -0700, Geoff Levand wrote:
 Michael Ellerman wrote:
  On Wed, 2007-09-26 at 18:33 +0200, Geert Uytterhoeven wrote:
  Question: As several DVI-D displays advertise they support 1080i modes 
  while
  they actually don't (cfr. the quirk database), perhaps I should drop 1080i
  modes completely from the ps3av_preferred_modes[] table? Usually 720p 
  looks
  better than 1080i anyway.  What do you think?
  
  Definitely. If the autodetection fails Linux is basically unusable on
  PS3 unless you hack the kernel sources and build your own kboot and
  otheros.bld - not entirely trivial for novice users. So it's pretty
  important that it works 100%.
 
 It is not that bad.  If a bootloader is configued to use autodetection
 so that it is shown at best video mode, then it should have advertised
 key sequences to default to known video modes, with at least a 480p 'safe'
 mode.
 
 Oh OK, that is a good idea. What's the safe mode key sequence for the
 otheros.bld you provide on kernel.org?


I don't maintain that, and have no idea how it sets its video mode.  Did you
have trouble with it?  I know in the past it used a fixed 480p mode. 


-Geoff


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

Re: [PATCH 11/18] Virtex: Port UARTLITE driver to of-platform-bus

[Arnd Bergmann]

On Friday 28 September 2007, Grant Likely wrote:
 -   ret = uart_register_driver(ulite_uart_driver);
 -   if (ret)
 -   return ret;
 +   pr_debug(uartlite: calling uart_register_driver()\n);
 +   if ((ret = uart_register_driver(ulite_uart_driver)) != 0)
 +   goto err_uart;
  
 -   ret = platform_driver_register(ulite_platform_driver);
 -   if (ret)
 -   uart_unregister_driver(ulite_uart_driver);
 +   if ((ret = ulite_of_register()) != 0)
 +   goto err_of;
  
 +   pr_debug(uartlite: calling platform_driver_register()\n);
 +   if ((ret = platform_driver_register(ulite_platform_driver)) != 0)
 +   goto err_plat;
 +
 +   return 0;

I don't see this as much of an improvement. Doing an assignment in the
condition makes the code less readable IMHO, so it should really
be written as

ret = try_something();
if (ret)
goto something_failed;

This keeps the normal code to the left, and the error handling indented
to the right.


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

Re: [PATCH 12/18] Uartlite: Let the console be initialized earlier

[Arnd Bergmann]

On Friday 28 September 2007, Grant Likely wrote:
 +#else /* CONFIG_OF */
 +static void __init ulite_console_of_find_device(int id) { /* do nothing */ }
 +#endif /* CONFIG_OF */

Shouldn't this be inline? It shouldn't matter much since most of the time
gcc -funit-at-a-time takes care of this, but it's common to make the inlining
explicit.

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

Re: [PATCH 01/18] Virtex: Add uartlite bootwrapper driver

[Arnd Bergmann]

On Friday 28 September 2007, Grant Likely wrote:
 +static void uartlite_putc(unsigned char c)
 +{
 +   while ((in_be32(reg_base + 0x8)  0x08) != 0); /* spin */
 +   out_be32(reg_base + 0x4, c);
 +}

When coding a spin-loop, it's better to do a cpu_relax() between
each attempt.

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

Re: [PATCH 12/18] Uartlite: Let the console be initialized earlier

[Grant Likely]

On 9/28/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
 On Friday 28 September 2007, Grant Likely wrote:
  +#else /* CONFIG_OF */
  +static void __init ulite_console_of_find_device(int id) { /* do nothing */ 
  }
  +#endif /* CONFIG_OF */

 Shouldn't this be inline? It shouldn't matter much since most of the time
 gcc -funit-at-a-time takes care of this, but it's common to make the inlining
 explicit.

heh, I even had the inline in there on an earlier version of the
patch.  I can add it back it.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 10/18] Uartlite: improve in-code comments

[Grant Likely]

On 9/28/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
 On Friday 28 September 2007, Grant Likely wrote:
  +/* -
  + * Core UART driver operations
  + */
  +

 This is a rather unusual style of commenting. IMHO it would be better if you
 left out the - line.

I find the horizontal breaks useful when parsing through the code.  If
others agree with you, then I'll happily remove them.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 01/18] Virtex: Add uartlite bootwrapper driver

[Grant Likely]

On 9/28/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
 On Friday 28 September 2007, Grant Likely wrote:
  +static void uartlite_putc(unsigned char c)
  +{
  +while ((in_be32(reg_base + 0x8)  0x08) != 0); /* spin */
  +out_be32(reg_base + 0x4, c);
  +}

 When coding a spin-loop, it's better to do a cpu_relax() between
 each attempt.

Is cpu_relax even implemented in the bootwrapper?

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 03/18] Virtex: add xilinx interrupt controller driver

[Olof Johansson]

On Fri, Sep 28, 2007 at 12:16:07PM -0600, Grant Likely wrote:

 +/*
 + * INTC Registers
 + */
 +#define ISR  0   /* Interrupt Status */
 +#define IPR  4   /* Interrupt Pending */
 +#define IER  8   /* Interrupt Enable */
 +#define IAR  12  /* Interrupt Acknowledge */
 +#define SIE  16  /* Set Interrupt Enable bits */
 +#define CIE  20  /* Clear Interrupt Enable bits */
 +#define IVR  24  /* Interrupt Vector */
 +#define MER  28  /* Master Enable */

The defines are fairly generic, I guess you haven't ran across cases
where there's naming conflicts, but you might want to prefix them with
something more unique just in case.

 +static struct irq_host *master_irqhost;
 +
 +/*
 + * IRQ Chip operations
 + */
 +static void xilinx_intc_mask(unsigned int virq)
 +{
 + int irq = irq_map[virq].hwirq;
 + void * regs = get_irq_chip_data(virq);
 + pr_debug(mask: %d\n, irq);
 + out_be32(regs + CIE, 1  irq);
 +}
 +
 +static void xilinx_intc_unmask(unsigned int virq)
 +{
 + int irq = irq_map[virq].hwirq;
 + void * regs = get_irq_chip_data(virq);
 + pr_debug(unmask: %d\n, irq);
 + out_be32(regs + SIE, 1  irq);
 +}
 +
 +static void xilinx_intc_ack(unsigned int virq)
 +{
 + int irq = irq_map[virq].hwirq;
 + void * regs = get_irq_chip_data(virq);
 + pr_debug(ack: %d\n, irq);
 + out_be32(regs + IAR, 1  irq);
 +}

I guess some of the above are open-coded instead of using virq_to_hw()
for performance reasons, it could be useful to have comments regarding
this so they aren't changed by some janitor down the road. Or, in case
they're not performance-critical, change them to use virq_to_hw.


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

Re: [PATCH 1/2] qemu platform, v2

[Rob Landley]

On Friday 28 September 2007 11:53:28 am Segher Boessenkool wrote:
  I'd be following this more closely if compiling a device tree didn't
  currently
  require an external utility (dtc or some such) that doesn't come with
  the
  Linux kernel.  No other target platform I've built kernels for
  requires such
  an environmental dependency.
 
  No?  You haven't built kernels for other platforms that have external
  dependencies such as perl, gcc, make, binutils, etc.? :)

 Two of the supported Linux archs cannot be built with a mainline
 compiler, even!

Strange definition of supported...

 And I have to install GNU sed/awk to get builds to work, too.

I extended busybox sed until it built everything I threw at it.  (I even added 
a lie to autoconf step that replies to --version to say This is not gnu 
sed 4.0 so a regex in autoconf doesn't do something stupid.)

That's how I got into busybox development in the first place...

 OTOH, it would be nice if we didn't need DTC -- it itself doesn't
 build out-of-the-box on all systems, either ;-)

I've built x86, x86-64, mips, arm, and sparc.  None of them needed anything 
but the seven packages I mentioned.  I'm poking at adding m68k, alpha, bfin, 
and powerpc, but my free time's been spoken for recently.  (I'll become 
interested in sh or parisc when qemu grows support for it.  I'm only 
interested in bfin because I was given some free blackfin hardware at OLS.)

I've even poked at running s390 under Hercules but the setup was insane enough 
to throw it way the heck down on my todo list.  (Step 1: download and 
configure an IBM operating system image from the 1970's...  Oh yeah, fills me 
with enthusiasm...)

   (This is a problem both for hardwiring the
  device tree into the kernel and for building a new boot rom from the
  linux
  kernel's ppc boot wrapper that would contain such a device tree to
  feed to
  the kernel.)
 
  It's only really been a problem for ps3 so far, since the embedded
  guys don't seem to have any difficulty with installing dtc.  We are
  looking at what to do for ps3 and prep, and the answer may well
  involve bundling dtc in the kernel source (it's not too big, around
  3400 lines).

 If only a few platforms have this problem, we could instead include
 their .dtb files in the kernel source tree.

I've had it clarified that the recent qemu-ppc patches from Milton only 
require dtc to build the ROM image to boot qemu with.  The Linux kernel image 
you build hasn't got a device tree in it (although that means it needs one 
passed in from the rom image)...

Using some other patches that floated by, I did build a prep kernel a couple 
of weeks ago, which qemu happily handed control off to...  which then failed 
to boot because it couldn't parse the incomplete residual data left over from 
open hackware.  The solution the ppc list recommended?  Hardwire a device 
tree into said linux kernel using dtc...


 Segher

Rob
-- 
One of my most productive days was throwing away 1000 lines of code.
  - Ken Thompson.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 02/18] Add Kconfig macros for Xilinx Virtex support

[Olof Johansson]

On Fri, Sep 28, 2007 at 12:16:01PM -0600, Grant Likely wrote:
 From: Grant Likely [EMAIL PROTECTED]
 
 Signed-off-by: Grant Likely [EMAIL PROTECTED]
 ---
 
  arch/powerpc/platforms/40x/Kconfig |   30 +-
  1 files changed, 17 insertions(+), 13 deletions(-)
 
 diff --git a/arch/powerpc/platforms/40x/Kconfig 
 b/arch/powerpc/platforms/40x/Kconfig
 index c3dce3b..1aae0e6 100644
 --- a/arch/powerpc/platforms/40x/Kconfig
 +++ b/arch/powerpc/platforms/40x/Kconfig
 @@ -61,13 +61,14 @@ config WALNUT
   help
 This option enables support for the IBM PPC405GP evaluation board.
  
 -#config XILINX_ML300
 -#bool Xilinx-ML300
 -#depends on 40x
 -#default y
 -#select VIRTEX_II_PRO
 -#help
 -#  This option enables support for the Xilinx ML300 evaluation board.
 +config XILINX_VIRTEX_GENERIC_BOARD
 + bool Generic Xilinx Virtex board
 + depends on 40x
 + default y
 + select VIRTEX_II_PRO
 + select VIRTEX_4_FX
 + help
 +   This option enables generic support for Xilinx Virtex based boards.

I would appreciate a bit verboser help text here, i.e. including what
boards are considered generic. Maybe something like ...including ML403,
x, y, and other 4FX/IIPro-based boards?


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

Re: [PATCH] cpm: Describe multi-user ram in its own device node.

[Vitaly Bordug]

Hello Scott,

On Fri, 28 Sep 2007 15:10:51 -0500
Scott Wood wrote:

 Vitaly Bordug wrote:
  Hello Scott,
  
  Looks good, only one note:
  
  On Fri, 28 Sep 2007 14:06:16 -0500
  Scott Wood wrote:
  
  +  im_dprambase = cpm2_immr-im_dprambase;
  +
 /* Attach the usable dpmem area */
 /* XXX: This is actually crap. CPM_DATAONLY_BASE and
  * CPM_DATAONLY_SIZE is only a subset of the available dpram. It
  * varies with the processor and the microcode patches activated.
  * But the following should be at least safe.
  */
  -  rh_attach_region(cpm_dpmem_info, 0, r.end - r.start + 1);
  +  rh_attach_region(cpm_dpmem_info, CPM_MAP_ADDR + CPM_DATAONLY_BASE,
  +   CPM_DATAONLY_SIZE);
   }
   
  
  Can we have something to address upper comment? I mean,any way to
  have dpram beginning and size encoded in the device tree? We seem to
  be adding new bus, and still pulling the information from the
  defines. Maybe I miss something here, but it looks a bit odd.
 
 This bit is #ifndef CONFIG_PPC_CPM_NEW_BINDING (and can come out once 
 all arch/powerpc boards are converted and tested -- I think it's just 
 mpc866ads and CPM mpc85xx left to go).  The new code in 
 arch/powerpc/sysdev/cpm_common.c does get it from the device tree.
 
ok, sorry for the noise. If so, I'll try to test-n-fix upper two soon. 
Unfortunately,
there are many 8xx in ppc, that may depend on cpm (need to check).




-- 
Sincerely, Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 03/18] Virtex: add xilinx interrupt controller driver

[Grant Likely]

On 9/28/07, Olof Johansson [EMAIL PROTECTED] wrote:
 On Fri, Sep 28, 2007 at 12:16:07PM -0600, Grant Likely wrote:

  +/*
  + * INTC Registers
  + */
  +#define ISR  0   /* Interrupt Status */
  +#define IPR  4   /* Interrupt Pending */
  +#define IER  8   /* Interrupt Enable */
  +#define IAR  12  /* Interrupt Acknowledge */
  +#define SIE  16  /* Set Interrupt Enable bits */
  +#define CIE  20  /* Clear Interrupt Enable bits */
  +#define IVR  24  /* Interrupt Vector */
  +#define MER  28  /* Master Enable */

 The defines are fairly generic, I guess you haven't ran across cases
 where there's naming conflicts, but you might want to prefix them with
 something more unique just in case.

Will do


  +static void xilinx_intc_ack(unsigned int virq)
  +{
  + int irq = irq_map[virq].hwirq;
  + void * regs = get_irq_chip_data(virq);
  + pr_debug(ack: %d\n, irq);
  + out_be32(regs + IAR, 1  irq);
  +}

 I guess some of the above are open-coded instead of using virq_to_hw()
 for performance reasons, it could be useful to have comments regarding
 this so they aren't changed by some janitor down the road. Or, in case
 they're not performance-critical, change them to use virq_to_hw.

Or it was just that my example code from another driver wasn't using
virq_to_hw() either.  I'll fix this.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 01/18] Virtex: Add uartlite bootwrapper driver

[Josh Boyer]

On Fri, 28 Sep 2007 14:04:04 -0600
Grant Likely [EMAIL PROTECTED] wrote:

 On 9/28/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
  On Friday 28 September 2007, Grant Likely wrote:
   +static void uartlite_putc(unsigned char c)
   +{
   +while ((in_be32(reg_base + 0x8)  0x08) != 0); /* spin */
   +out_be32(reg_base + 0x4, c);
   +}
 
  When coding a spin-loop, it's better to do a cpu_relax() between
  each attempt.
 
 Is cpu_relax even implemented in the bootwrapper?

No.  And it doesn't need to be :)

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

Re: [PATCH] cpm: Describe multi-user ram in its own device node.

[Vitaly Bordug]

Hello Scott,

Looks good, only one note:

On Fri, 28 Sep 2007 14:06:16 -0500
Scott Wood wrote:

 + im_dprambase = cpm2_immr-im_dprambase;
 +
   /* Attach the usable dpmem area */
   /* XXX: This is actually crap. CPM_DATAONLY_BASE and
* CPM_DATAONLY_SIZE is only a subset of the available dpram. It
* varies with the processor and the microcode patches activated.
* But the following should be at least safe.
*/
 - rh_attach_region(cpm_dpmem_info, 0, r.end - r.start + 1);
 + rh_attach_region(cpm_dpmem_info, CPM_MAP_ADDR + CPM_DATAONLY_BASE,
 +  CPM_DATAONLY_SIZE);
  }
  
Can we have something to address upper comment? I mean,any way to have dpram 
beginning and size encoded in the device tree? We seem to be adding new bus, 
and still pulling the information from the defines. Maybe I miss something
here, but it looks a bit odd.

-- 
Sincerely, Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 00/18] Virtex support in arch/powerpc

[Grant Likely]

On 9/28/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
 Hi Grant!

 On Friday 28 September 2007, Grant Likely wrote:
  This series adds Xilinx Virtex support to arch/powerpc. Please review
  and comment. It includes support for the uartlite and SystemACE devices

 Very nice set of patches, I looked at all of them but couldn't find much
 to complain about, just trivial details.

Thank you very much for the review!

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 06/18] [POWERPC] Fix UARTLITE reg io for little-endian architectures (ie. microblaze)

[Olof Johansson]

On Fri, Sep 28, 2007 at 12:17:13PM -0600, Grant Likely wrote:
 From: Grant Likely [EMAIL PROTECTED]
 
 Signed-off-by: Grant Likely [EMAIL PROTECTED]
 Acked-by: John Williams [EMAIL PROTECTED]
 ---
 
  arch/ppc/syslib/virtex_devices.c |2 +-
  drivers/serial/uartlite.c|   32 
  2 files changed, 17 insertions(+), 17 deletions(-)
 
 diff --git a/arch/ppc/syslib/virtex_devices.c 
 b/arch/ppc/syslib/virtex_devices.c
 index ace4ec0..270ad3a 100644
 --- a/arch/ppc/syslib/virtex_devices.c
 +++ b/arch/ppc/syslib/virtex_devices.c
 @@ -28,7 +28,7 @@
   .num_resources = 2, \
   .resource = (struct resource[]) { \
   { \
 - .start = XPAR_UARTLITE_##num##_BASEADDR + 3, \
 + .start = XPAR_UARTLITE_##num##_BASEADDR, \
   .end = XPAR_UARTLITE_##num##_HIGHADDR, \
   .flags = IORESOURCE_MEM, \
   }, \
 diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
 index f5051cf..59b674a 100644
 --- a/drivers/serial/uartlite.c
 +++ b/drivers/serial/uartlite.c
 @@ -61,7 +61,7 @@ static int ulite_receive(struct uart_port *port, int stat)
   /* stats */
   if (stat  ULITE_STATUS_RXVALID) {
   port-icount.rx++;
 - ch = readb(port-membase + ULITE_RX);
 + ch = in_be32((void*)port-membase + ULITE_RX);

Hmm, I see the start changed, and you're now reading/writing a full
32-bit word instead of individual bytes. Still, looks a little fishy to
me. Wouldn't it be more appropriate to change the ULITE_RX offset to be
3 higher and still read/write bytes?

Or are the registers defined as 32-bit ones? (I don't remember, it was
so long since I touched uartlite myself. :-)

(Same for the other functions below, but the general principle applies.)

Also, I'm not sure you need to cast port-membase to void*, do you? The
math will still be right since it's declared as char *.


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

Re: [PATCH 02/18] Add Kconfig macros for Xilinx Virtex support

[Grant Likely]

On 9/28/07, Olof Johansson [EMAIL PROTECTED] wrote:
 On Fri, Sep 28, 2007 at 12:16:01PM -0600, Grant Likely wrote:
  From: Grant Likely [EMAIL PROTECTED]
 
  Signed-off-by: Grant Likely [EMAIL PROTECTED]
  ---
 
   arch/powerpc/platforms/40x/Kconfig |   30 +-
   1 files changed, 17 insertions(+), 13 deletions(-)
 
  diff --git a/arch/powerpc/platforms/40x/Kconfig 
  b/arch/powerpc/platforms/40x/Kconfig
  index c3dce3b..1aae0e6 100644
  --- a/arch/powerpc/platforms/40x/Kconfig
  +++ b/arch/powerpc/platforms/40x/Kconfig
  @@ -61,13 +61,14 @@ config WALNUT
help
  This option enables support for the IBM PPC405GP evaluation board.
 
  -#config XILINX_ML300
  -#bool Xilinx-ML300
  -#depends on 40x
  -#default y
  -#select VIRTEX_II_PRO
  -#help
  -#  This option enables support for the Xilinx ML300 evaluation board.
  +config XILINX_VIRTEX_GENERIC_BOARD
  + bool Generic Xilinx Virtex board
  + depends on 40x
  + default y
  + select VIRTEX_II_PRO
  + select VIRTEX_4_FX
  + help
  +   This option enables generic support for Xilinx Virtex based boards.

 I would appreciate a bit verboser help text here, i.e. including what
 boards are considered generic. Maybe something like ...including ML403,
 x, y, and other 4FX/IIPro-based boards?

Done.

  This option enables generic support for Xilinx Virtex based boards.

+ The generic virtex board support matches any device tree which
+ specifies 'xilinx,virtex' in its compatible field.  This includes
+ the Xilinx ML3xx and ML4xx reference designs using the powerpc
+ core.
+
+ Most Virtex designs should use this unless it needs to do some
+ special configuration at board probe time.
+

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 06/18] [POWERPC] Fix UARTLITE reg io for little-endian architectures (ie. microblaze)

[Grant Likely]

On 9/28/07, Olof Johansson [EMAIL PROTECTED] wrote:
 On Fri, Sep 28, 2007 at 12:17:13PM -0600, Grant Likely wrote:
  From: Grant Likely [EMAIL PROTECTED]
 
  Signed-off-by: Grant Likely [EMAIL PROTECTED]
  Acked-by: John Williams [EMAIL PROTECTED]
  ---
 
   arch/ppc/syslib/virtex_devices.c |2 +-
   drivers/serial/uartlite.c|   32 
   2 files changed, 17 insertions(+), 17 deletions(-)
 
  diff --git a/arch/ppc/syslib/virtex_devices.c 
  b/arch/ppc/syslib/virtex_devices.c
  index ace4ec0..270ad3a 100644
  --- a/arch/ppc/syslib/virtex_devices.c
  +++ b/arch/ppc/syslib/virtex_devices.c
  @@ -28,7 +28,7 @@
.num_resources = 2, \
.resource = (struct resource[]) { \
{ \
  - .start = XPAR_UARTLITE_##num##_BASEADDR + 3, \
  + .start = XPAR_UARTLITE_##num##_BASEADDR, \
.end = XPAR_UARTLITE_##num##_HIGHADDR, \
.flags = IORESOURCE_MEM, \
}, \
  diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
  index f5051cf..59b674a 100644
  --- a/drivers/serial/uartlite.c
  +++ b/drivers/serial/uartlite.c
  @@ -61,7 +61,7 @@ static int ulite_receive(struct uart_port *port, int stat)
/* stats */
if (stat  ULITE_STATUS_RXVALID) {
port-icount.rx++;
  - ch = readb(port-membase + ULITE_RX);
  + ch = in_be32((void*)port-membase + ULITE_RX);

 Hmm, I see the start changed, and you're now reading/writing a full
 32-bit word instead of individual bytes. Still, looks a little fishy to
 me. Wouldn't it be more appropriate to change the ULITE_RX offset to be
 3 higher and still read/write bytes?

 Or are the registers defined as 32-bit ones? (I don't remember, it was
 so long since I touched uartlite myself. :-)

All the registers are defined as 32 bit ones.  I think it makes more
sense to access the registers as they are documented, and it
eliminates the 'magic' +3 needed to make it work now.


 (Same for the other functions below, but the general principle applies.)

 Also, I'm not sure you need to cast port-membase to void*, do you? The
 math will still be right since it's declared as char *.

membase is now defined as u32*, so the cast is needed.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 06/18] [POWERPC] Fix UARTLITE reg io for little-endian architectures (ie. microblaze)

[Olof Johansson]

On Fri, Sep 28, 2007 at 02:42:32PM -0600, Grant Likely wrote:
 On 9/28/07, Olof Johansson [EMAIL PROTECTED] wrote:

  Hmm, I see the start changed, and you're now reading/writing a full
  32-bit word instead of individual bytes. Still, looks a little fishy to
  me. Wouldn't it be more appropriate to change the ULITE_RX offset to be
  3 higher and still read/write bytes?
 
  Or are the registers defined as 32-bit ones? (I don't remember, it was
  so long since I touched uartlite myself. :-)
 
 All the registers are defined as 32 bit ones.  I think it makes more
 sense to access the registers as they are documented, and it
 eliminates the 'magic' +3 needed to make it work now.

Ok, thaks for the clarification. Feel free to add it as motivation in
the patch description. :)

  (Same for the other functions below, but the general principle applies.)
 
  Also, I'm not sure you need to cast port-membase to void*, do you? The
  math will still be right since it's declared as char *.
 
 membase is now defined as u32*, so the cast is needed.

Hm, I must have looked at a stale tree.


Thanks,

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

Re: [PATCH 06/18] [POWERPC] Fix UARTLITE reg io for little-endian architectures (ie. microblaze)

[Grant Likely]

On 9/28/07, Olof Johansson [EMAIL PROTECTED] wrote:
 On Fri, Sep 28, 2007 at 02:42:32PM -0600, Grant Likely wrote:
  On 9/28/07, Olof Johansson [EMAIL PROTECTED] wrote:
   Also, I'm not sure you need to cast port-membase to void*, do you? The
   math will still be right since it's declared as char *.
 
  membase is now defined as u32*, so the cast is needed.

 Hm, I must have looked at a stale tree.

No, wait.  You're right.  It is a char*.  I'll drop the cast.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 06/18] [POWERPC] Fix UARTLITE reg io for little-endian architectures (ie. microblaze)

[Grant Likely]

On 9/28/07, Grant Likely [EMAIL PROTECTED] wrote:
 On 9/28/07, Olof Johansson [EMAIL PROTECTED] wrote:
  On Fri, Sep 28, 2007 at 02:42:32PM -0600, Grant Likely wrote:
   On 9/28/07, Olof Johansson [EMAIL PROTECTED] wrote:
Also, I'm not sure you need to cast port-membase to void*, do you? The
math will still be right since it's declared as char *.
  
   membase is now defined as u32*, so the cast is needed.
 
  Hm, I must have looked at a stale tree.

 No, wait.  You're right.  It is a char*.  I'll drop the cast.

Wait, I'm wrong again... it's in/out_be32 that expects an (unsigned*).
 The compiler complains without the cast.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] cpm: Describe multi-user ram in its own device node.

[Vitaly Bordug]

Kumar,

Realizing this may suffer a bit from cleanest-dts flame war, but anyway I 
pretty much see a lot of
sense in getting this in during next merge window. Is this possible?

On Fri, 28 Sep 2007 14:06:16 -0500
Scott Wood wrote:

 The way the current CPM binding describes available multi-user (a.k.a.
 dual-ported) RAM doesn't work well when there are multiple free regions,
 and it doesn't work at all if the region doesn't begin at the start of
 the muram area (as the hardware needs to be programmed with offsets into
 this area).  The latter situation can happen with SMC UARTs on CPM2, as its
 parameter RAM is relocatable, u-boot puts it at zero, and the kernel doesn't
 support moving it.
 
 It is now described with a muram node, similar to QE.  The current CPM
 binding is sufficiently recent (i.e. never appeared in an official release)
 that compatibility with existing device trees is not an issue.
 
 The code supporting the new binding is shared between cpm1 and cpm2, rather
 than remain separated.  QE should be able to use this code as well, once
 minor fixes are made to its device trees.
 
 Signed-off-by: Scott Wood [EMAIL PROTECTED]
Acked-by: Vitaly Bordug [EMAIL PROTECTED]

 ---
  Documentation/powerpc/booting-without-of.txt |   40 ++-
  arch/powerpc/Kconfig.debug   |6 +-
  arch/powerpc/boot/cpm-serial.c   |   44 +--
  arch/powerpc/boot/dts/ep88xc.dts |   13 ++-
  arch/powerpc/boot/dts/mpc8272ads.dts |   11 ++
  arch/powerpc/boot/dts/mpc885ads.dts  |   13 ++-
  arch/powerpc/boot/dts/pq2fads.dts|   13 ++-
  arch/powerpc/sysdev/commproc.c   |   11 ++-
  arch/powerpc/sysdev/cpm2_common.c|   36 ++
  arch/powerpc/sysdev/cpm_common.c |  159 
 ++
  drivers/serial/cpm_uart/cpm_uart_cpm2.c  |4 +-
  include/asm-powerpc/commproc.h   |   12 ++
  include/asm-powerpc/cpm.h|   14 +++
  include/asm-powerpc/cpm2.h   |   10 ++
  14 files changed, 338 insertions(+), 48 deletions(-)

-- 
Sincerely, Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Powerbook shuts down hard when hot, patch found

[Michael Buesch]

Hi,

some time ago I already mailed you about this problem.
I will quickly describe what's going on, again:

My powerbook boots fine when it's cold. You can work with
it and you can also run it hot (compile something, etc...).
But when you try to boot it while it is hot, it will
automatically shutdown hard inside of the boot process.
Some part of the hardware is shutting it down.
This does not happen when it's getting hot _after_ boot.
Only while boot when it's hot.

I bisected the problem and found out that the following patch
is responsible for this. Yeah, this sounds a little bit
crazy, as this patch does not seem to be related to
this at all. But I confirmed it by booting kernel
4f71c5de19c27f2198105d3b26b398494d5c353b
That kernel triggered the bug. Then I patch -R the patch below
and it booted properly, even when hot. I also rechecked
that it really was hot enough to trigger the event by
immediately rebooting into a known bad kernel, that immediately
shut down the pbook, as expected.
So I'm pretty sure it's the patch below causing this weird
behaviour. Any idea why?


commit 4f71c5de19c27f2198105d3b26b398494d5c353b
Author: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date:   Fri Nov 17 15:35:00 2006 +1100

[PATCH] Fix radeon DDC regression

When radeonfb was changed to use the new generic ddc, a bit of
code initializing the GPIO lines was lost, causing it to not work
if the firmware didn't configure them properly, which seems to
happen on some cards.

Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]

diff --git a/drivers/video/aty/radeon_i2c.c b/drivers/video/aty/radeon_i2c.c
index 6767545..869725a 100644
--- a/drivers/video/aty/radeon_i2c.c
+++ b/drivers/video/aty/radeon_i2c.c
@@ -139,7 +139,13 @@ void radeon_delete_i2c_busses(struct rad
 int radeon_probe_i2c_connector(struct radeonfb_info *rinfo, int conn,
   u8 **out_edid)
 {
-   u8 *edid = fb_ddc_read(rinfo-i2c[conn-1].adapter);
+   u32 reg = rinfo-i2c[conn-1].ddc_reg;
+   u8 *edid;
+
+   OUTREG(reg, INREG(reg) 
+   ~(VGA_DDC_DATA_OUTPUT | VGA_DDC_CLK_OUTPUT));
+
+   edid = fb_ddc_read(rinfo-i2c[conn-1].adapter);
 
if (out_edid)
*out_edid = edid;

-- 
Greetings Michael.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Powerbook shuts down hard when hot, patch found

[Benjamin Herrenschmidt]

On Fri, 2007-09-28 at 23:32 +0200, Michael Buesch wrote:
 Hi,
 
 some time ago I already mailed you about this problem.
 I will quickly describe what's going on, again:
 
 My powerbook boots fine when it's cold. You can work with
 it and you can also run it hot (compile something, etc...).
 But when you try to boot it while it is hot, it will
 automatically shutdown hard inside of the boot process.
 Some part of the hardware is shutting it down.
 This does not happen when it's getting hot _after_ boot.
 Only while boot when it's hot.
 
 I bisected the problem and found out that the following patch
 is responsible for this. Yeah, this sounds a little bit
 crazy, as this patch does not seem to be related to
 this at all. But I confirmed it by booting kernel
 4f71c5de19c27f2198105d3b26b398494d5c353b
 That kernel triggered the bug. Then I patch -R the patch below
 and it booted properly, even when hot. I also rechecked
 that it really was hot enough to trigger the event by
 immediately rebooting into a known bad kernel, that immediately
 shut down the pbook, as expected.
 So I'm pretty sure it's the patch below causing this weird
 behaviour. Any idea why?

This is very strange... Can you try also clearing VGA_DDC_CLK_OUT_EN and
VGA_DDC_DATA_OUT_EN and the same time and see if that helps ?

 
 commit 4f71c5de19c27f2198105d3b26b398494d5c353b
 Author: Benjamin Herrenschmidt [EMAIL PROTECTED]
 Date:   Fri Nov 17 15:35:00 2006 +1100
 
 [PATCH] Fix radeon DDC regression
 
 When radeonfb was changed to use the new generic ddc, a bit of
 code initializing the GPIO lines was lost, causing it to not work
 if the firmware didn't configure them properly, which seems to
 happen on some cards.
 
 Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
 Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
 
 diff --git a/drivers/video/aty/radeon_i2c.c b/drivers/video/aty/radeon_i2c.c
 index 6767545..869725a 100644
 --- a/drivers/video/aty/radeon_i2c.c
 +++ b/drivers/video/aty/radeon_i2c.c
 @@ -139,7 +139,13 @@ void radeon_delete_i2c_busses(struct rad
  int radeon_probe_i2c_connector(struct radeonfb_info *rinfo, int conn,
  u8 **out_edid)
  {
 - u8 *edid = fb_ddc_read(rinfo-i2c[conn-1].adapter);
 + u32 reg = rinfo-i2c[conn-1].ddc_reg;
 + u8 *edid;
 +
 + OUTREG(reg, INREG(reg) 
 + ~(VGA_DDC_DATA_OUTPUT | VGA_DDC_CLK_OUTPUT));
 +
 + edid = fb_ddc_read(rinfo-i2c[conn-1].adapter);
  
   if (out_edid)
   *out_edid = edid;
 

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

Re: [PATCH 01/18] Virtex: Add uartlite bootwrapper driver

[Arnd Bergmann]

On Friday 28 September 2007, Josh Boyer wrote:
 
  Is cpu_relax even implemented in the bootwrapper?
 
 No.  And it doesn't need to be :)

I think I should learn to read subject lines. You are of course
both right.

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

Re: [PATCH] cpm: Describe multi-user ram in its own device node.

[Kumar Gala]

On Sep 28, 2007, at 3:30 PM, Vitaly Bordug wrote:

 Kumar,

 Realizing this may suffer a bit from cleanest-dts flame war, but  
 anyway I pretty much see a lot of
 sense in getting this in during next merge window. Is this possible?

Probably, does QE have muram?  I can't keep these things straight.

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

Re: [PATCH 3/9] fs_enet: Don't share the interrupt.

[Jeff Garzik]

Scott Wood wrote:
 This driver can't handle an interrupt immediately after request_irq

You MUST assume that you will receive an interrupt immediately after 
request_irq().  If fs_enet cannot handle that, then that is what wants 
fixing.

Please send along a fix for this, rather than band-aiding the problem.

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

Re: [PATCH 1/9] fs_enet: Whitespace cleanup.

[Jeff Garzik]

Scott Wood wrote:
 Signed-off-by: Scott Wood [EMAIL PROTECTED]
 ---
  drivers/net/fs_enet/fs_enet-main.c |   85 ---
  drivers/net/fs_enet/fs_enet.h  |4 +-
  drivers/net/fs_enet/mac-fcc.c  |1 -
  drivers/net/fs_enet/mii-bitbang.c  |3 -
  drivers/net/fs_enet/mii-fec.c  |1 -
  5 files changed, 41 insertions(+), 53 deletions(-)

ACK patches 1-2, 4-9

This patch doesn't apply cleanly to netdev-2.6.git#upstream (nor 
net-2.6.24.git), so this and the rest of the patch series failed to apply.

Please resend series on top of netdev-2.6.git#upstream or net-2.6.24.git.


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