* RE: TEMAC support of Uboot on ML403
From: Ming Liu @ 2007-08-08 12:10 UTC (permalink / raw)
To: sharonf; +Cc: Linuxppc-embedded
In-Reply-To: <8506C3905ED0764F889ADEB33E3A9E8062D0CC@MAIA.scopus.net>
Dear Sharon,
Sorry that I don't know the detail of what you suggested. Could you say
something more on that? Shall I patch U-boot to add the driver for TEMAC in
U-boot? and where is the patch? Or I just modify some parameters in the
existing files? Thanks for your detailed information and sharing your
experience.
BR
Ming
>From: "Sharon Feldman" <sharonf@scopus.net>
>To: "Ming Liu" <eemingliu@hotmail.com>
>Subject: RE: TEMAC support of Uboot on ML403
>Date: Wed, 8 Aug 2007 14:11:22 +0300
>
>YES IT DOES WORK WITH TEMAC. YOU NEED TO MAKE THE RIGHT ADAPTATIONS
>
>-----Original Message-----
>From: linuxppc-embedded-bounces+sharonf=scopus.net@ozlabs.org
[mailto:linuxppc-embedded-bounces+sharonf=scopus.net@ozlabs.org]On Behalf
Of Ming Liu
>Sent: Wednesday, August 08, 2007 1:08 PM
>To: linuxppc-embedded@ozlabs.org
>Subject: TEMAC support of Uboot on ML403
>
>
>Dear all,
>Does anyone know that whether U-boot can support Xilinx TEMAC core to tftp
>the Linux kernel or not. In my design I am using TEMAC instead of the
>normal enet. While I found that in the Xilinx u-boot tree, there is only a
>directory for xilinx_enet instead of xilinx_temac. I am not sure if I am
>right, but I remember a long time before, there was a patch for supporting
>Xilinx TEMAC in U-boot.
>
>Any suggestion will be appreciated a lot for this topic. Thank you in
>advance for your telling.
>
>BR
>Ming
>
>_________________________________________________________________
>享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: [patch 0/3] PS3 bugfix patches for 2.6.23
From: Michael Ellerman @ 2007-08-08 12:06 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070808174740.8426f5f6.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
On Wed, 2007-08-08 at 17:47 +1000, Stephen Rothwell wrote:
> Hi Geoff,
>
> On Wed, 8 Aug 2007 17:17:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au>
> wrote:
> >
> > LD .tmp_vmlinux1
> > arch/powerpc/platforms/built-in.o: In function `of_has_vicinity':
> > /home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:681:
> > undefined reference to `.spu_devnode'
>
> Ben pointed out patch "[PATCH v2] cell: move SPU affinity init to
> spu_management_of_ops" to me.
Can someone please merge it!
:)
--
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: pci in arch/powerpc vs arch/ppc
From: Alexandros Kostopoulos @ 2007-08-08 11:42 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <46B88DAC.70005@freescale.com>
On Tue, 07 Aug 2007 18:20:12 +0300, Scott Wood <scottwood@freescale.com>=
=
wrote:
> Alexandros Kostopoulos wrote:
>> Except from some macros arch/powerpc/include/asm/io.h / mpc8260_pci9.=
h, =
>> I can seem to find anywhere the code regarding PCI Erratum 9. The =
>> defined macros(in io.h) for read/write are sufficient as a workaroun=
d =
>> for PCI9? Who does DMA and register initialization for this (it used=
=
>> to be done in arch/ppc/syslib/m8260_pci_erratum9.c in arc/ppc). Mayb=
e =
>> u-boot or the bootwrapper?
>
> I don't think the workaround exists yet in arch/powerpc, despite the =
> config option.
>
Is there a plan to be implemented on arch/powerpc, or devices with the =
erratum will have to keep on using the legacy arch/ppc code?
>> Another question regarding resource allocation: when =
>> alloc_resource(pci_32.c), called from pcibios_allocate_resources(), =
>> during pcibios init, attempts to allocate resources using =
>> request_resource(), the request fails. This seems to happen because =
=
>> the previously scanned PCI devices request resources in the form, e.=
g. =
>> 00000- 0000f (i.e. starting from zero), and this should be mapped =
>> somewhere else in cpu mem space. My question (in order to find my bu=
g) =
>> is, who performs this mapping, from PCI space to CPU space, the kern=
el =
>> (and if yes, where?) or the host bridge (in which case, I've probabl=
y =
>> failed to configure it properly).
>
> If the error message is the one I'm thinking of (it always helps to po=
st =
> the actual messages), that's normal for when the PCI bus hasn't been =
> probed by the firmware. Linux first tries to use the BARs as they're =
=
> already set, which will obviously fail because they haven't been set, =
=
> and then it will properly allocated them. It's harmless verbosity, =
> though it'd be nice to have a flag to tell the PCI layer to not bother=
=
> trying to preserve any existing BARs.
>
Well, the error message is:
PCI:0000:00:16.0: Resource 0: 0000000000000000-0000000000000fff (f=3D200=
)
PCI: Cannot allocate resource region 0 of device 0000:00:16.0
PCI: parent is c03c4058: 0000000080000000-00000000bfffffff (f=3D200)
The thing is, POBARs are already setup by uboot. However the resource =
allocation for the PCI devices (not the host bridge) fails in =
request_resource (which seems to use the region requested by the device =
as =
is and not some mapped region in the cpu address space), and I can not =
find where in the code happens the mapping from PCI to local bus mem =
region. I mean, each PCI device requests some region, e.g. from 0000-00f=
f =
and this is mapped to some region in the PCI outbound window, right. For=
=
some reason this fails in my case, and I cannot find where in the code =
this mapping should happen.
Thank you for your help
Alex
> -Scott
^ permalink raw reply
* no output to serial console from /init process on ml405
From: Anton Kowalski @ 2007-08-08 11:28 UTC (permalink / raw)
To: linuxppc-embedded
Hi All:
I'm trying to bring up linux 2.6.21.1 on an ml405 board. The kernel
boots fine but the init process does not produce any output. The /init
program resides in an initramfs file system and I believe the /dev
device files have been set up correctly. Here's an excerpt from my
initramfs specification:
dir /dev 755 0 0
nod /dev/console 644 0 0 c 5 1
nod /dev/ttyS0 644 0 0 c 4 64
(I am able to open these files from the init program. I tested this by
sleeping for a specified time on success.)
Also, printk continues to function after /init terminates and before
the kernel panics.
Here are the last few lines of the console output:
[ 0.507478] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports,
IRQ sharing disabled
[ 0.513862] serial8250.0: ttyS0 at MMIO 0x80201003 (irq = 3) is a 16550A
[ 2.927509] RAMDISK driver initialized: 1 RAM disks of 8192K size
1024 blocksize
[ 3.018391] tun: Universal TUN/TAP device driver, 1.6
[ 3.079115] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 3.154919] mice: PS/2 mouse device common for all mice
[ 3.218021] TCP cubic registered
[ 3.257034] NET: Registered protocol family 1
[ 3.309405] NET: Registered protocol family 17
[ 3.363462] Freeing unused kernel memory: 300k init
[ 23.488277] Kernel panic - not syncing: Attempted to kill init!
[ 23.559517] Rebooting in 180 seconds..<NULL>
I'm using the plb uart and the 8250.c driver. (The obp uartlite driver
didn't work so I switched.) The kernel and the init program were
compiled with eldk.
Any insights into resolving this problem are greatly appreciated.
Anton
^ permalink raw reply
* TEMAC support of Uboot on ML403
From: Ming Liu @ 2007-08-08 10:08 UTC (permalink / raw)
To: linuxppc-embedded
Dear all,
Does anyone know that whether U-boot can support Xilinx TEMAC core to tftp
the Linux kernel or not. In my design I am using TEMAC instead of the
normal enet. While I found that in the Xilinx u-boot tree, there is only a
directory for xilinx_enet instead of xilinx_temac. I am not sure if I am
right, but I remember a long time before, there was a patch for supporting
Xilinx TEMAC in U-boot.
Any suggestion will be appreciated a lot for this topic. Thank you in
advance for your telling.
BR
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* Re: signals handling in the kernel
From: Mirek23 @ 2007-08-08 8:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46B8BA93.8020909@ovro.caltech.edu>
Hi Dave,
I have found the book by Rubini you have mentioned:
http://www.oreilly.com/catalog/linuxdrive3/book/index.csp
I did not find however what would be the best way to propagate interrupt
signals to the USER level / notify the client that interrupt has occurred.
I have checked also in the kernel 2.4 kernel/signal.c file and
kill_proc_info symbol was there exported but in the kernel 2.6 it is not a
case. I have modified the kernel/signal.c file inserting the line:
EXPORT_SYMBOL(kill_proc_info);
and I use the kill_proc_info straight from the interrupt handler routine. I
do not know however if it is a safe
solution. This what does not work with kill_proc_info is that (struct
siginfo *) pInfo->si_value.sival_int
is not passed to the user space. To pass an integer value I use (struct
siginfo *) pInfo->si_code instead.
This works but it is not an elegant solution since the si_code is meant to
be used for something else.
Best Regards
Mirek
David Hawkins-3 wrote:
>
>
> Hi Mirek,
>
>>> I would like to send signals from the interrupt handler
>>> routine (in the kernel) to the user application (in user space).
>>> I have googled on that net and I have found that it could be done with
>>> the
>>> function: kill_proc_info.
>>
>> Look in Rubini for the section regarding asynchronous
>> notification, Ch 6.
>>
>> The callback to generate SIGIO is fasync.
>>
>
> Actually, before you go off and implement something, can
> you describe why you want to use signals.
>
> I mistakenly used signals once to indicate notification of
> an event. Then when I wanted multiple events from multiple
> boards I found the problem with signals; you don't know
> who sent it.
>
> Using select() on multiple file descriptors ended up being
> a more appropriate solution for my application. That
> solution also works nicely with the ACE C++ ACE_Reactor
> pattern.
>
> Cheers,
> Dave
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12048974
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix more section mismatches in head_64.S
From: Geert Uytterhoeven @ 2007-08-08 7:51 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20070731164413.0421b430.sfr@canb.auug.org.au>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1429 bytes --]
On Tue, 31 Jul 2007, Stephen Rothwell wrote:
> WARNING: vmlinux.o(.text+0x8174): Section mismatch: reference to .init.text:.prom_init (between '.__boot_from_prom' and '.__after_prom_start')
> WARNING: vmlinux.o(.text+0x8498): Section mismatch: reference to .init.text:.early_setup (between '.start_here_multiplatform' and '.start_here_common')
> WARNING: vmlinux.o(.text+0x8514): Section mismatch: reference to .init.text:.setup_system (between '.start_here_common' and 'system_call_common')
> WARNING: vmlinux.o(.text+0x8530): Section mismatch: reference to .init.text:.start_kernel (between '.start_here_common' and 'system_call_common')
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Nice, the last few section warnings in my PS3 build went away!
Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [patch 2/3] PS3: Remove incomplete message
From: Geert Uytterhoeven @ 2007-08-08 7:49 UTC (permalink / raw)
To: geoffrey.levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070808033120.055823394@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1779 bytes --]
On Tue, 7 Aug 2007 geoffrey.levand@am.sony.com wrote:
> Remove the Kconfig message that indicates the PS3 platform support is
> incomplete.
>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
> arch/powerpc/platforms/ps3/Kconfig | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> --- a/arch/powerpc/platforms/ps3/Kconfig
> +++ b/arch/powerpc/platforms/ps3/Kconfig
> @@ -1,5 +1,5 @@
> config PPC_PS3
> - bool "Sony PS3 (incomplete)"
> + bool "Sony PS3"
> depends on PPC_MULTIPLATFORM && PPC64
> select PPC_CELL
> select USB_ARCH_HAS_OHCI
> @@ -10,10 +10,10 @@ config PPC_PS3
> select MEMORY_HOTPLUG
> help
> This option enables support for the Sony PS3 game console
> - and other platforms using the PS3 hypervisor.
> - Support for this platform is not yet complete, so
> - enabling this will not result in a bootable kernel on a
> - PS3 system.
> + and other platforms using the PS3 hypervisor. Enabling this
> + option will allow building otheros.bld, a kernel image suitable
> + for programming into flash memory, and vmlinux, a kernel image
> + suitable loading via kexec.
^
for
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [patch 0/3] PS3 bugfix patches for 2.6.23
From: Stephen Rothwell @ 2007-08-08 7:47 UTC (permalink / raw)
To: geoffrey.levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070808171738.40d99505.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 516 bytes --]
Hi Geoff,
On Wed, 8 Aug 2007 17:17:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au>
wrote:
>
> LD .tmp_vmlinux1
> arch/powerpc/platforms/built-in.o: In function `of_has_vicinity':
> /home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:681:
> undefined reference to `.spu_devnode'
Ben pointed out patch "[PATCH v2] cell: move SPU affinity init to
spu_management_of_ops" to me.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Device tree aware EMAC driver
From: Benjamin Herrenschmidt @ 2007-08-08 7:34 UTC (permalink / raw)
To: David Gibson; +Cc: LinuxPPC-dev
In-Reply-To: <20070808050937.GF20482@localhost.localdomain>
On Wed, 2007-08-08 at 15:09 +1000, David Gibson wrote:
>
> Eh, all the c++ comments are FIXMEs anyway. I'm inclined to leave
> them.
Ahah... maybe I -did- add some of those then :-) I do use C++ comments
for FIXME's on purpose, because they are ugly, it improves the changes
that I actually get to fix whatever needs fixing :-)
Ben.
^ permalink raw reply
* Re: Device tree aware EMAC driver
From: Benjamin Herrenschmidt @ 2007-08-08 7:33 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, David Gibson
In-Reply-To: <20070808031643.GK10345@bakeyournoodle.com>
> * c++ style comments
Ouch... I haven't removed them all ? I promise I didn't -add- any :-)
> * in emac_probe():
> + /* Wait for dependent devices */
> + err = -ENODEV;
> + err = emac_wait_deps(dev);
> The initialisation to -ENODEV is pointless right?
Leftover from when it was coded differently yes.
> * s/get_property/of_get_property/g or you'll make sfr grumpy ;)
> * In drivers/net/ibm_newemac/Makefile, I think the preferred method is
> to use ibm_newemac-y rather than ibm_newemac-objs.
>
> Is there any reason to leave config IBM_NEW_EMAC (and IBM_EMAC) in
> drivers/net/Kconfig ? It seems to me they'd be nicer to in the
> appropriate drivers/net/*Kconfig.
Probably.
Ben.
^ permalink raw reply
* Re: signals handling in the kernel
From: Mirek23 @ 2007-08-08 7:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46B8BA93.8020909@ovro.caltech.edu>
Hi Dave,
I run embedded Linux on ppc405 (ml403 xilinx evaluation board). I use
the GPIO based device build on FPGA part of the xilinx chip. My gpio device
generates interrupts whenever it changes its state.
I use Montavista gpio driver with some modifications to react on interrupts.
Each time when interrupt occurs the interrupt handler routine is called.
This routine sends the signal to the application in user space to trigger
it. When the application is triggered it reads the data from the GPIO
device.
I read that in this situation the best is to use signals. In my case the
ideal would be to use kill_proc_info which sends to the application the
Signal with info data were I intended to put just one integer value. Such a
value determines how to react for the signal on the application level.
Would you have some other suggestion better then the kill_proc_info function
use or even different technique then signaling.
Could you please direct me to the Rubini documentation which you have
mentioned in your last post.
Many thanks
Mirek
David Hawkins-3 wrote:
>
>
> Hi Mirek,
>
>>> I would like to send signals from the interrupt handler
>>> routine (in the kernel) to the user application (in user space).
>>> I have googled on that net and I have found that it could be done with
>>> the
>>> function: kill_proc_info.
>>
>> Look in Rubini for the section regarding asynchronous
>> notification, Ch 6.
>>
>> The callback to generate SIGIO is fasync.
>>
>
> Actually, before you go off and implement something, can
> you describe why you want to use signals.
>
> I mistakenly used signals once to indicate notification of
> an event. Then when I wanted multiple events from multiple
> boards I found the problem with signals; you don't know
> who sent it.
>
> Using select() on multiple file descriptors ended up being
> a more appropriate solution for my application. That
> solution also works nicely with the ACE C++ ACE_Reactor
> pattern.
>
> Cheers,
> Dave
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12048448
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [patch 0/3] PS3 bugfix patches for 2.6.23
From: Stephen Rothwell @ 2007-08-08 7:17 UTC (permalink / raw)
To: geoffrey.levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070808033119.833895506@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]
Hi Geoff,
On Tue, 07 Aug 2007 20:31:19 -0700 geoffrey.levand@am.sony.com wrote:
>
> This small set of PS3 bugfix patches for 2.6.23.
>
> [patch 1/3] PS3: Fix storage probe logic
> [patch 2/3] PS3: Remove incomplete message
> [patch 3/3] PS3: Update ps3_defconfig
>
> Patch 1 fixes a cold startup timing bug in the hard disk probe logic.
>
> Patch 2 removes the 'incomplete' message in the PS3 Kconfig. We now
> have all drivers and platform support needed to build a kernel for the
> PS3. The only major thing missing is wireless networking support, which
> we plan to have ready for 2.6.24.
$ mkdir ../ps3
$ make O=../ps3 ps3_defconfig
$ make O=../ps3
.
.
LD .tmp_vmlinux1
arch/powerpc/platforms/built-in.o: In function `of_has_vicinity':
/home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:681: undefined reference to `.spu_devnode'
arch/powerpc/platforms/built-in.o: In function `init_aff_fw_vicinity_node':
/home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:726: undefined reference to `.spu_devnode'
arch/powerpc/platforms/built-in.o: In function `aff_devnode_spu':
/home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:690: undefined reference to `.spu_devnode'
arch/powerpc/platforms/built-in.o: In function `aff_node_next_to':
/home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:703: undefined reference to `.spu_devnode'
/home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:705: undefined reference to `.spu_devnode'
arch/powerpc/platforms/built-in.o:/home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:649: more undefined references to `.spu_devnode' follow
make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [_all] Error 2
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Fix size check for hugetlbfs
From: Benjamin Herrenschmidt @ 2007-08-08 5:44 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Paul Mackerras, stable
My "slices" address space management code that was added in 2.6.22
implementation of get_unmapped_area() doesn't properly check that the
size is a multiple of the requested page size. This allows userland to
create VMAs that aren't a multiple of the huge page size with hugetlbfs
(since hugetlbfs entirely relies on get_unmapped_area() to do that
checking) which leads to a kernel BUG() when such areas are torn down.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This should go to 2.6.22.x stable in addition to current 2.6.23-*
Index: linux-work/arch/powerpc/mm/slice.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/slice.c 2007-08-08 15:16:06.000000000 +1000
+++ linux-work/arch/powerpc/mm/slice.c 2007-08-08 15:16:41.000000000 +1000
@@ -405,6 +405,8 @@ unsigned long slice_get_unmapped_area(un
if (len > mm->task_size)
return -ENOMEM;
+ if (len & ((1ul << pshift) - 1))
+ return -EINVAL;
if (fixed && (addr & ((1ul << pshift) - 1)))
return -EINVAL;
if (fixed && addr > (mm->task_size - len))
^ permalink raw reply
* Re: Device tree aware EMAC driver
From: David Gibson @ 2007-08-08 5:09 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev
In-Reply-To: <20070808031643.GK10345@bakeyournoodle.com>
On Wed, Aug 08, 2007 at 01:16:43PM +1000, Tony Breeds wrote:
> On Tue, Aug 07, 2007 at 04:22:31PM +1000, David Gibson wrote:
> > Based on BenH's earlier work, this is a new version of the EMAC driver
> > for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
> > same ASIC is also found in the Axon bridge chip. This new version is
> > designed to work in the arch/powerpc tree, using the device tree to
> > probe the device, rather than the old and ugly arch/ppc OCP layer.
>
> <snip>
>
> Hi David,
> I had a look over the patch FWIW, asside from the points below
> looks good.
>
> Minor nits:
> * Shouldn't ndev->priv accesses, use netdev_priv() ? if not a comment
> somewhere about why not will keep the janators off your back.
netdev_priv() hey? Hadn't heard of that before. I guess
so... Changed.
> * c++ style comments
Eh, all the c++ comments are FIXMEs anyway. I'm inclined to leave
them.
> * in emac_probe():
> + /* Wait for dependent devices */
> + err = -ENODEV;
> + err = emac_wait_deps(dev);
> The initialisation to -ENODEV is pointless right?
Yes, I think so. Removed.
> * s/get_property/of_get_property/g or you'll make sfr grumpy ;P
Oops, yes.
> * In drivers/net/ibm_newemac/Makefile, I think the preferred method is
> to use ibm_newemac-y rather than ibm_newemac-objs.
>
> Is there any reason to leave config IBM_NEW_EMAC (and IBM_EMAC) in
> drivers/net/Kconfig ? It seems to me they'd be nicer to in the
> appropriate drivers/net/*Kconfig.
Yes, and that also seems to be how it's done for tulip. Moved.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [patch 3/3] PS3: Update ps3_defconfig
From: geoffrey.levand @ 2007-08-08 3:31 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070808033119.833895506@am.sony.com>
Update ps3_defconfig.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/configs/ps3_defconfig | 200 ++++++++++++-------------------------
1 file changed, 65 insertions(+), 135 deletions(-)
--- a/arch/powerpc/configs/ps3_defconfig
+++ b/arch/powerpc/configs/ps3_defconfig
@@ -1,9 +1,23 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.22-rc6
-# Tue Jun 26 14:15:19 2007
+# Linux kernel version: 2.6.23-rc2
+# Tue Aug 7 19:17:26 2007
#
CONFIG_PPC64=y
+
+#
+# Processor support
+#
+# CONFIG_POWER4_ONLY is not set
+CONFIG_POWER3=y
+CONFIG_POWER4=y
+CONFIG_PPC_FPU=y
+CONFIG_ALTIVEC=y
+CONFIG_PPC_STD_MMU=y
+# CONFIG_PPC_MM_SLICES is not set
+CONFIG_VIRT_CPU_ACCOUNTING=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=2
CONFIG_64BIT=y
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
@@ -15,6 +29,7 @@ CONFIG_ARCH_HAS_ILOG2_U64=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
+CONFIG_ARCH_NO_VIRT_TO_BUS=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_COMPAT=y
@@ -22,50 +37,32 @@ CONFIG_SYSVIPC_COMPAT=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
+CONFIG_OF=y
# CONFIG_PPC_UDBG_16550 is not set
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_DEFAULT_UIMAGE is not set
-
-#
-# Processor support
-#
-# CONFIG_POWER4_ONLY is not set
-CONFIG_POWER3=y
-CONFIG_POWER4=y
-CONFIG_PPC_FPU=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
# CONFIG_PPC_OF_PLATFORM_PCI is not set
-CONFIG_ALTIVEC=y
-CONFIG_PPC_STD_MMU=y
-# CONFIG_PPC_MM_SLICES is not set
-CONFIG_VIRT_CPU_ACCOUNTING=y
-CONFIG_SMP=y
-CONFIG_NR_CPUS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
-# Code maturity level options
+# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
-
-#
-# General setup
-#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
-# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
-# CONFIG_UTS_NS is not set
+# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
@@ -100,10 +97,6 @@ CONFIG_SLAB=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
-
-#
-# Loadable module support
-#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
@@ -111,12 +104,9 @@ CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
-
-#
-# Block layer
-#
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
+CONFIG_BLK_DEV_BSG=y
#
# IO Schedulers
@@ -136,7 +126,9 @@ CONFIG_DEFAULT_IOSCHED="anticipatory"
#
CONFIG_PPC_MULTIPLATFORM=y
# CONFIG_EMBEDDED6xx is not set
-# CONFIG_APUS is not set
+# CONFIG_PPC_82xx is not set
+# CONFIG_PPC_83xx is not set
+# CONFIG_PPC_86xx is not set
# CONFIG_PPC_PSERIES is not set
# CONFIG_PPC_ISERIES is not set
# CONFIG_PPC_MPC52xx is not set
@@ -223,6 +215,7 @@ CONFIG_MEMORY_HOTPLUG_SPARSE=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
+CONFIG_BOUNCE=y
CONFIG_ARCH_MEMORY_PROBE=y
# CONFIG_PPC_HAS_HASH_64K is not set
# CONFIG_PPC_64K_PAGES is not set
@@ -241,6 +234,7 @@ CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
# CONFIG_PCI is not set
# CONFIG_PCI_DOMAINS is not set
+# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
#
@@ -365,6 +359,7 @@ CONFIG_WIRELESS_EXT=y
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
# CONFIG_RFKILL is not set
+# CONFIG_NET_9P is not set
#
# Device Drivers
@@ -379,26 +374,11 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
-
-#
-# Connector - unified userspace <-> kernelspace linker
-#
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
-
-#
-# Parallel port support
-#
+CONFIG_OF_DEVICE=y
# CONFIG_PARPORT is not set
-
-#
-# Plug and Play support
-#
-# CONFIG_PNPACPI is not set
-
-#
-# Block devices
-#
+CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
@@ -411,11 +391,8 @@ CONFIG_BLK_DEV_RAM_SIZE=65535
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
-
-#
-# Misc devices
-#
-# CONFIG_BLINK is not set
+CONFIG_MISC_DEVICES=y
+# CONFIG_EEPROM_93CX6 is not set
# CONFIG_IDE is not set
#
@@ -423,6 +400,7 @@ CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
+CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y
@@ -455,37 +433,22 @@ CONFIG_SCSI_WAIT_SCAN=m
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
-
-#
-# SCSI low-level drivers
-#
-# CONFIG_ISCSI_TCP is not set
-# CONFIG_SCSI_DEBUG is not set
+# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_ATA is not set
-
-#
-# Multi-device support (RAID and LVM)
-#
# CONFIG_MD is not set
# CONFIG_MACINTOSH_DRIVERS is not set
-
-#
-# Network device support
-#
CONFIG_NETDEVICES=y
+# CONFIG_NETDEVICES_MULTIQUEUE is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
+# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
-
-#
-# Ethernet (10 or 100Mbit)
-#
# CONFIG_NET_ETHERNET is not set
CONFIG_MII=m
CONFIG_NETDEV_1000=y
-CONFIG_NETDEV_10000=y
CONFIG_GELIC_NET=y
+# CONFIG_NETDEV_10000 is not set
#
# Wireless LAN
@@ -518,15 +481,7 @@ CONFIG_USB_NET_MCS7830=m
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
-
-#
-# ISDN subsystem
-#
# CONFIG_ISDN is not set
-
-#
-# Telephony Support
-#
# CONFIG_PHONE is not set
#
@@ -604,10 +559,6 @@ CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=16
-
-#
-# IPMI
-#
# CONFIG_IPMI_HANDLER is not set
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
@@ -616,10 +567,6 @@ CONFIG_GEN_RTC=y
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set
-
-#
-# TPM devices
-#
# CONFIG_TCG_TPM is not set
# CONFIG_I2C is not set
@@ -628,11 +575,8 @@ CONFIG_GEN_RTC=y
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
-
-#
-# Dallas's 1-wire bus
-#
# CONFIG_W1 is not set
+# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
#
@@ -657,6 +601,7 @@ CONFIG_GEN_RTC=y
#
# CONFIG_DISPLAY_SUPPORT is not set
# CONFIG_VGASTATE is not set
+CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
@@ -691,11 +636,13 @@ CONFIG_FB_PS3_DEFAULT_SIZE_M=18
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
+CONFIG_FB_LOGO_EXTRA=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
@@ -709,6 +656,8 @@ CONFIG_SOUND=y
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
+CONFIG_SND_TIMER=y
+CONFIG_SND_PCM=y
# CONFIG_SND_SEQUENCER is not set
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
@@ -735,6 +684,12 @@ CONFIG_SND_VERBOSE_PROCFS=y
#
#
+# ALSA PowerPC devices
+#
+CONFIG_SND_PS3=y
+CONFIG_SND_PS3_DEFAULT_START_DELAY=2000
+
+#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
@@ -747,13 +702,14 @@ CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_SOC is not set
#
-# Open Sound System
+# SoC Audio support for SuperH
#
-# CONFIG_SOUND_PRIME is not set
#
-# HID Devices
+# Open Sound System
#
+# CONFIG_SOUND_PRIME is not set
+CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
@@ -770,10 +726,7 @@ CONFIG_USB_HID=m
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
-
-#
-# USB support
-#
+CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
@@ -803,6 +756,7 @@ CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_BIG_ENDIAN_MMIO=y
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_SL811_HCD is not set
+# CONFIG_USB_R8A66597_HCD is not set
#
# USB Device Class drivers
@@ -879,31 +833,8 @@ CONFIG_USB_MON=y
#
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
-
-#
-# LED devices
-#
# CONFIG_NEW_LEDS is not set
-
-#
-# LED drivers
-#
-
-#
-# LED Triggers
-#
-
-#
-# InfiniBand support
-#
-
-#
-# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
-#
-
-#
-# Real Time Clock
-#
+# CONFIG_EDAC is not set
# CONFIG_RTC_CLASS is not set
#
@@ -920,6 +851,11 @@ CONFIG_USB_MON=y
#
#
+# Userspace I/O
+#
+# CONFIG_UIO is not set
+
+#
# File systems
#
CONFIG_EXT2_FS=m
@@ -948,8 +884,8 @@ CONFIG_QUOTA=y
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
-# CONFIG_AUTOFS_FS is not set
-CONFIG_AUTOFS4_FS=y
+CONFIG_AUTOFS_FS=m
+CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set
#
@@ -1030,7 +966,6 @@ CONFIG_CIFS=m
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
-# CONFIG_9P_FS is not set
#
# Partition Types
@@ -1096,6 +1031,7 @@ CONFIG_BITREVERSE=y
# CONFIG_CRC16 is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
+# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
@@ -1120,6 +1056,7 @@ CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
+CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_SLAB is not set
@@ -1150,10 +1087,6 @@ CONFIG_IRQSTACKS=y
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
-
-#
-# Cryptographic options
-#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
@@ -1191,7 +1124,4 @@ CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set
-
-#
-# Hardware crypto devices
-#
+CONFIG_CRYPTO_HW=y
--
^ permalink raw reply
* [patch 1/3] PS3: Fix storage probe logic
From: geoffrey.levand @ 2007-08-08 3:31 UTC (permalink / raw)
To: paulus; +Cc: Geert Uytterhoeven, linuxppc-dev
In-Reply-To: <20070808033119.833895506@am.sony.com>
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Fix the PS3 storage probe logic to properly find device regions on cold
startup.
o Change the storage probe event mask from notify_device_ready
to notify_region_update.
o Improve the storage probe error handling.
o Change ps3_storage_wait_for_device() to use a temporary variable to hold
the buffer address.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/device-init.c | 34 +++++++++++++++----------------
1 file changed, 17 insertions(+), 17 deletions(-)
--- a/arch/powerpc/platforms/ps3/device-init.c
+++ b/arch/powerpc/platforms/ps3/device-init.c
@@ -273,55 +273,57 @@ static int ps3stor_wait_for_completion(u
static int ps3_storage_wait_for_device(const struct ps3_repository_device *repo)
{
+ int error = -ENODEV;
int result;
const u64 notification_dev_id = (u64)-1LL;
const unsigned int timeout = HZ;
u64 lpar;
u64 tag;
+ void *buf;
+ enum ps3_notify_type {
+ notify_device_ready = 1,
+ notify_region_update = 2,
+ };
struct {
u64 operation_code; /* must be zero */
- u64 event_mask; /* 1 = device ready */
+ u64 event_mask; /* OR of ps3_notify_type */
} *notify_cmd;
struct {
- u64 event_type; /* notify_device_ready */
+ u64 event_type; /* enum ps3_notify_type */
u64 bus_id;
u64 dev_id;
u64 dev_type;
u64 dev_port;
} *notify_event;
- enum {
- notify_device_ready = 1
- };
pr_debug(" -> %s:%u: bus_id %u, dev_id %u, dev_type %u\n", __func__,
__LINE__, repo->bus_id, repo->dev_id, repo->dev_type);
- notify_cmd = kzalloc(512, GFP_KERNEL);
- notify_event = (void *)notify_cmd;
- if (!notify_cmd)
+ buf = kzalloc(512, GFP_KERNEL);
+ if (!buf)
return -ENOMEM;
- lpar = ps3_mm_phys_to_lpar(__pa(notify_cmd));
+ lpar = ps3_mm_phys_to_lpar(__pa(buf));
+ notify_cmd = buf;
+ notify_event = buf;
result = lv1_open_device(repo->bus_id, notification_dev_id, 0);
if (result) {
printk(KERN_ERR "%s:%u: lv1_open_device %s\n", __func__,
__LINE__, ps3_result(result));
- result = -ENODEV;
goto fail_free;
}
/* Setup and write the request for device notification. */
- notify_cmd->operation_code = 0; /* must be zero */
- notify_cmd->event_mask = 0x01; /* device ready */
+ notify_cmd->operation_code = 0; /* must be zero */
+ notify_cmd->event_mask = notify_region_update;
result = lv1_storage_write(notification_dev_id, 0, 0, 1, 0, lpar,
&tag);
if (result) {
printk(KERN_ERR "%s:%u: write failed %s\n", __func__, __LINE__,
ps3_result(result));
- result = -ENODEV;
goto fail_close;
}
@@ -332,13 +334,11 @@ static int ps3_storage_wait_for_device(c
if (result) {
printk(KERN_ERR "%s:%u: write not completed %s\n", __func__,
__LINE__, ps3_result(result));
- result = -ENODEV;
goto fail_close;
}
/* Loop here processing the requested notification events. */
- result = -ENODEV;
while (1) {
memset(notify_event, 0, sizeof(*notify_event));
@@ -386,9 +386,9 @@ static int ps3_storage_wait_for_device(c
fail_close:
lv1_close_device(repo->bus_id, notification_dev_id);
fail_free:
- kfree(notify_cmd);
+ kfree(buf);
pr_debug(" <- %s:%u\n", __func__, __LINE__);
- return result;
+ return error;
}
static int ps3_setup_storage_dev(const struct ps3_repository_device *repo,
--
^ permalink raw reply
* [patch 2/3] PS3: Remove incomplete message
From: geoffrey.levand @ 2007-08-08 3:31 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070808033119.833895506@am.sony.com>
Remove the Kconfig message that indicates the PS3 platform support is
incomplete.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/Kconfig | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -1,5 +1,5 @@
config PPC_PS3
- bool "Sony PS3 (incomplete)"
+ bool "Sony PS3"
depends on PPC_MULTIPLATFORM && PPC64
select PPC_CELL
select USB_ARCH_HAS_OHCI
@@ -10,10 +10,10 @@ config PPC_PS3
select MEMORY_HOTPLUG
help
This option enables support for the Sony PS3 game console
- and other platforms using the PS3 hypervisor.
- Support for this platform is not yet complete, so
- enabling this will not result in a bootable kernel on a
- PS3 system.
+ and other platforms using the PS3 hypervisor. Enabling this
+ option will allow building otheros.bld, a kernel image suitable
+ for programming into flash memory, and vmlinux, a kernel image
+ suitable loading via kexec.
menu "PS3 Platform Options"
depends on PPC_PS3
--
^ permalink raw reply
* [patch 0/3] PS3 bugfix patches for 2.6.23
From: geoffrey.levand @ 2007-08-08 3:31 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
This small set of PS3 bugfix patches for 2.6.23.
[patch 1/3] PS3: Fix storage probe logic
[patch 2/3] PS3: Remove incomplete message
[patch 3/3] PS3: Update ps3_defconfig
Patch 1 fixes a cold startup timing bug in the hard disk probe logic.
Patch 2 removes the 'incomplete' message in the PS3 Kconfig. We now
have all drivers and platform support needed to build a kernel for the
PS3. The only major thing missing is wireless networking support, which
we plan to have ready for 2.6.24.
-Geoff
--
^ permalink raw reply
* Re: Linux with data2mem
From: jozsef imrek @ 2007-08-08 3:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OF56B29E3B.75AC018C-ON85257330.0055CDE0-85257330.0056CDD1@ct.wec.com>
On Tue, 7 Aug 2007 Glenn.G.Hart@us.westinghouse.com wrote:
> ERROR:Data2MEM:33 - Matching ADDRESS_SPACE for code segment #0 not found in
> 'sys
> tem_bd.bmm'.
> Code segment #0 occupies [0x00400000:0x0062AFFF]
>
...
> ///////////////////////////////////////////////////////////////////////////////
>
> ADDRESS_SPACE plb_bram_if_cntlr_1_bram_combined RAMB16
> [0xFFFFC000:0xFFFFFFFF]
make sure that the memory range your software wants to use is backed
by real memory. it seems that your elf expects itself to be loaded at
0x00400000:0x0062AFFF, but you block memory is at 0xFFFFC000:0xFFFFFFFF
(use readelf -l to find out what address ranges does your software want
to use).
probably what you want is a boot loader in the bram, not the kernel image
(the zImage). the boot loader would load the linux kernel into the main
memory (starting at memory address 0x00000000).
--
mazsi
----------------------------------------------------------------
strawberry fields forever! imrek@atomki.hu
----------------------------------------------------------------
^ permalink raw reply
* Re: Device tree aware EMAC driver
From: Tony Breeds @ 2007-08-08 3:16 UTC (permalink / raw)
To: LinuxPPC-dev, David Gibson
In-Reply-To: <20070807062231.GB8351@localhost.localdomain>
On Tue, Aug 07, 2007 at 04:22:31PM +1000, David Gibson wrote:
> Based on BenH's earlier work, this is a new version of the EMAC driver
> for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
> same ASIC is also found in the Axon bridge chip. This new version is
> designed to work in the arch/powerpc tree, using the device tree to
> probe the device, rather than the old and ugly arch/ppc OCP layer.
<snip>
Hi David,
I had a look over the patch FWIW, asside from the points below
looks good.
Minor nits:
* Shouldn't ndev->priv accesses, use netdev_priv() ? if not a comment
somewhere about why not will keep the janators off your back.
* c++ style comments
* in emac_probe():
+ /* Wait for dependent devices */
+ err = -ENODEV;
+ err = emac_wait_deps(dev);
The initialisation to -ENODEV is pointless right?
* s/get_property/of_get_property/g or you'll make sfr grumpy ;P
* In drivers/net/ibm_newemac/Makefile, I think the preferred method is
to use ibm_newemac-y rather than ibm_newemac-objs.
Is there any reason to leave config IBM_NEW_EMAC (and IBM_EMAC) in
drivers/net/Kconfig ? It seems to me they'd be nicer to in the
appropriate drivers/net/*Kconfig.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [patch 04/10] 4xx bootwrapper reworks
From: David Gibson @ 2007-08-08 1:19 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070807081038.06925ccb@weaponx.rchland.ibm.com>
On Tue, Aug 07, 2007 at 08:10:38AM -0500, Josh Boyer wrote:
> On Tue, 7 Aug 2007 13:05:47 +1000
> David Gibson <dwg@au1.ibm.com> wrote:
>
> > > > Rather than just removing these defines and using hardcoded values,
> > > > I'd prefer to see separate SPRN_DBCR0_40X and SPRN_DBCR0_44X defines.
> > >
> > > Ok. And place them where? In the same file since they aren't DCR defines?
> > > Seems fairly trivial, but ok.
> >
> > Just where the old 44x specific define was. And yes, it is fairly
> > trivial.
>
> Fixed.
>
> > > > [snip]
> > > > > +#define EMAC_RESET 0x20000000
> > > > > +#define MAL_RESET 0x80000000
> > > >
> > > > I think the MAL_RESET definition should go in the same place as the
> > > > DCR number definition.
> > >
> > > Ok. Trivial.
> >
> > Yes.
>
> Fixed.
>
> > > > As I think I said before, I'm not really happy with this being
> > > > hardcoded assuming exactly 2 ethernets.
> > >
> > > Well, it's hardcoded to assume one or two. I know of only one board that has
> > > more than two EMACs. I was hoping we could get this in for 2.6.24 as-is and
> > > change it when needs be. But I'll look at making it var-args or similar.
>
> I'm going to hold off on this for now. I'm not disagreeing with you,
> but there are no upcoming board ports that have more than two EMACs so
> I'd like to focus on getting Bamboo (440EP) and Sequoia (440EPx)
> in-tree first. Perhaps even Walnut, if there's time.
Fair enough.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] Remove dtc build cruft from DTS files
From: David Gibson @ 2007-08-08 0:15 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070807122848.6bdf2f43@weaponx.rchland.ibm.com>
On Tue, Aug 07, 2007 at 12:28:48PM -0500, Josh Boyer wrote:
> The patch below removes the dtc incantation instructions from the
> in-kernel DTS files. It's not needed, and is prone to being
> out-of-date most of the time.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Device tree aware EMAC driver
From: David Gibson @ 2007-08-08 1:18 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070807071539.6dbb49a5@weaponx.rchland.ibm.com>
On Tue, Aug 07, 2007 at 07:15:39AM -0500, Josh Boyer wrote:
> On Tue, 7 Aug 2007 16:22:31 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > Based on BenH's earlier work, this is a new version of the EMAC driver
> > for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
> > same ASIC is also found in the Axon bridge chip. This new version is
> > designed to work in the arch/powerpc tree, using the device tree to
> > probe the device, rather than the old and ugly arch/ppc OCP layer.
> >
> > This driver is designed to sit alongside the old driver (it lies in
> > drivers/net/ibm_emac and this one in drivers/net/ibm_newemac). The
> > old driver is left in place to support arch/ppc until arch/ppc itself
> > reaches its final demise (not too long now, with luck).
> >
> > This driver still has a number of things that could do with cleaning
> > up, but I think they can be fixed up after merging. Specifically:
> > - Should be adjusted to properly use the dma mapping API.
> > Axon needs this.
> > - Probe logic needs reworking, in conjuction with the general
> > probing code for of_platform devices. The dependencies here between
> > EMAC, MAL, ZMII etc. make this complicated. At present, it usually
> > works, because we initialize and register the sub-drivers before the
> > EMAC driver itself, and (being in driver code) runs after the devices
> > themselves have been instantiated from the device tree.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Hm. Should this go through Jeff Garzik or Paul? If it's the latter,
> I'll pull this into my git tree soon.
Through Jeff Garzik, I think. I was planning to send it to him today
or tomorrow if there are no screams from the linuxppc-dev list.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-08 1:51 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <03211b7766f4a21c90889344f843a564@kernel.crashing.org>
On Tue, Aug 07, 2007 at 06:33:01PM +0200, Segher Boessenkool wrote:
> >>>>> Yeah, better names please -- if possible, something that someone
> >>>>> without knowledge of this SoC will understand what it is.
> >>>>
> >>>> I think the names are probably ok - I'm assuming they're in keeping
> >>>> with the convention I've used of using the same names /
> >>>> abbreviations
> >>>> as in the CPU user manual. I'm asking just for my own information,
> >>>> although a comment might not be a bad idea.
> >>
> >> Fine with me -- I personally prefer "system-device-controller"
> >> and "clock-power-controller" or similar, but that is mostly a
> >> matter of taste. As long as it's human readable it's fine.
> >
> > Actually, it occurs to me that I've only sometimes been using that
> > convention for the names: basically just for the weirdo chip control
> > devices that don't have a more widespread generic name.
>
> It's pretty darn hard to make good sensible "generic names" for
> some of the devices on a SoC; using the acronym that's in the
> documentation for that SoC certainly isn't the worst choice.
My thoughts exactly.
> >>> + Flash partitions
> >>> + - reg :
> >>> + - read-only : (optional)
> >>
> >> I'll hold off commenting on this until you've finish writing it,
> >> you probably know my opinion about it anyway :-)
> >
> > Heh.. actually I was kind of hoping for your input on what's still
> > missing. For example, I don't know what the necessary extra
> > properties for JEDEC chips are.
>
> I meant for the "partitions" stuff only.
>
> For the JEDEC chips, we need a "vendor-id" and "device-id"
> property at least (or similar names -- whatever is general
> practice for this); both are a single byte, encoded as with
> encode-int.
Ok... should those really be separate properties, or should that go in
compatible, i.e. something like:
compatible = "amd,XXXXXX", "jedec,a4-b7", "jedec-flash";
> >> One thing though -- what _exactly_ does "read-only" signify?
> >
> > That's... a good question.
>
> Yeah. It seems to me that the way it is currently used is
> pure policy enforcement, which doesn't belong in the device
> tree.
Well.. not really policy enforcement, but a policy hint.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox