* Re: I2C on mpc8248 / device tree
From: Kumar Gala @ 2007-11-14 7:17 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0711131539n228f9f21q7b2acc896499b80d@mail.gmail.com>
On Nov 13, 2007, at 5:39 PM, Alan Bennett wrote:
> I've got four devices on i2c that I need to read. Simple thermal
> and voltage monitors. I2c works fine in uboot, and now I'm trying
> to get things to work in linux.
>
> In the kernel .config I enable
> I2C
> and
> I2C_MPC
This driver isn't for the I2C on 8248. You need a cpm2 i2c driver
for that controller.
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Fix fs_enet module build
From: David Miller @ 2007-11-14 5:09 UTC (permalink / raw)
To: jochen; +Cc: jeff, netdev, linux-kernel, linuxppc-embedded, akpm
In-Reply-To: <4739EDA8.6020800@scram.de>
From: Jochen Friedrich <jochen@scram.de>
Date: Tue, 13 Nov 2007 19:32:08 +0100
> If fs_enet is build as module, on PPC_CPM_NEW_BINDING platforms
> mii-fec/mii-bitbang should be build as module, as well. On other
> platforms, mii-fec/mii-bitbang must be included into the main module.
> Otherwise some symbols remain undefined. Additionally, fs_enet uses
> libphy, so add a select PHYLIB.
>
> Building modules, stage 2.
> MODPOST 5 modules
> ERROR: "fs_scc_ops" [drivers/net/fs_enet/fs_enet.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
This is truly ugly and creates an unnecessarily hard to
maintain and complex driver.
Please find a way to fix this for real, so that the
PPC_CPM_NEW_BINDING ifdef is not necessary at all and
things get built modular or not naturally as we handle
things for other cases like this.
THanks.
^ permalink raw reply
* Re: [PATCH] cell: Convert #include of asm/of_{platform, device}.h into linux/of_{platform, device}.h.
From: Stephen Rothwell @ 2007-11-14 4:11 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1Irw8I-0000b4-5e@jdl.com>
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
On Tue, 13 Nov 2007 07:48:50 -0600 Jon Loeliger <jdl@jdl.com> wrote:
>
> I'm assuming I can chip away at _all_ of these,
> including the ones in the drivers/ directories as well.
Knock yourself out! :-)
> I haven't a clue who will really pick all these up.
> We could arrange for Paul to grab the arch/powerpc.
> But the rest? Mr Morton perhaps?
Just keep in mind that some of these changes may affect Sparc and
Sparc64, so Dave Miller is you man for those.
--
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] pSeries: make pseries_defconfig minus PCI build again
From: Stephen Rothwell @ 2007-11-14 4:07 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/pseries/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index 16e4e40..306a9d0 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -21,7 +21,7 @@ config PPC_SPLPAR
config EEH
bool "PCI Extended Error Handling (EEH)" if EMBEDDED
- depends on PPC_PSERIES
+ depends on PPC_PSERIES && PCI
default y if !EMBEDDED
config SCANLOG
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH 0/2] PowerPC: 4xx uic updates
From: Benjamin Herrenschmidt @ 2007-11-14 3:40 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, dwg
In-Reply-To: <20071113200514.72d03792@zod.rchland.ibm.com>
On Tue, 2007-11-13 at 20:05 -0600, Josh Boyer wrote:
> On Tue, 13 Nov 2007 23:15:59 +0300
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
> > These patches update 4xx uic code. The first one
> > fixes a minor issue with edge-triggered interrupts,
> > while the second one makes it use generic level and edge irq
> > handlers. I've added irq ack'ing to the unmask callback for
> > level-triggered interrupts, because to de-assert them we have
> > to do 2 things is the exact order as below:
> > 1. de-assert the external source in the ISR.
> > 2. ack the IRQ on the UIC.
> > So, ack'ing level interrupts before unmasking them makes possible
> > to use generic level irq handler and it doesn't hurt, cause
> > we can never miss a level-triggered interrupt. It always stays
> > asserted untill the external source is removed and ack'ed on UIC.
> >
> > These have been tested on Sequoia PowerPC 440EPx board.
>
> Is my mail server slow, or did patch 2 of 2 never make it out?
It never reached me neither.
Ben
^ permalink raw reply
* Re: [PATCH 2/2] PowerPC: make 4xx uic use generic edge and level irq handlers
From: Benjamin Herrenschmidt @ 2007-11-14 3:43 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071114021326.GB19378@localhost.localdomain>
On Wed, 2007-11-14 at 13:13 +1100, David Gibson wrote:
> Hrm. I *think* I'm convinced this is safe, although acking in a
> callback which doesn't say it acks is rather yucky. Essentially this
> code is trading flow readability (because just reading
> handle_level_irq will tell you something other than what it does in
> our case) for smaller code size. I'm not sure if this is a good trade
> or not.
>
> There's also one definite problem: according to the discussions I had
> with Thomas Gleixner when I wrote uic.c, handle_edge_irq is not what
> we want for edge interrupts.
>
> Apparently handle_edge_irq is only for edge interrupts on "broken"
> PICs which won't latch new interrupts while the irq is masked. UIC is
> not in this category, so handle_level_irq is actually what we want,
> even for an edge irq.
>
> Yes, I thought the naming was more than a little confusing, too.
Hrm... handle_edge_irq works for both and you have a small performance
benefit in not masking, and thus using handle_edge_irq, so I don't
totally agree here. Basically, what handle_edge_irq() does is lazy
masking. Now there -is- an issue here is that if you do lazy masking,
you need to be able to re-emit in some convenient way.
Ben.
^ permalink raw reply
* Re: [PATCH] pci hotplug: fix rpaphp directory naming
From: Greg KH @ 2007-11-14 3:26 UTC (permalink / raw)
To: Linas Vepstas
Cc: rick.jones2, pcihpd-discuss, Alex Chiang, Matthew Wilcox, gregkh,
linux-kernel, linuxppc-dev, linux-acpi, Kristen Carlson Accardi,
linux-pci, strosake, lenb
In-Reply-To: <20071114003455.GD8509@austin.ibm.com>
On Tue, Nov 13, 2007 at 06:34:55PM -0600, Linas Vepstas wrote:
>
>
> Fix presentation of the slot number in the /sys/bus/pci/slots
> directory to match that used in the majority of other drivers.
We need a signed-off-by: to be able to apply this...
thanks,
greg k-h
^ permalink raw reply
* RE: printk/console_init - baud rate setting
From: Siva Prasad @ 2007-11-14 2:28 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.62.0711130915480.31003@pademelon.sonytel.be>
Thanks a lot Geert and Benjamin for your response.
Code is indeed calling register_console from three different places=20
1) con_init()[name-tty],=20
2) serial8250_console_init()[name-ttyS],=20
3) early_uart_console_init()[name-uart].=20
Among these, 8250 must be the active one. Also
serial8250_console_write() keeps hitting the BDI2000 break point with
same address and count again and again.
I am getting garbage on the screen. So, I presume this must be some sort
of baud rate issue. Can some one help me out understand how this baud is
set for serial drivers? I want to run at 115200.
Thanks
Siva
-----Original Message-----
From: geert@sonytel.be [mailto:geert@sonytel.be] On Behalf Of Geert
Uytterhoeven
Sent: Tuesday, November 13, 2007 12:17 AM
To: Siva Prasad
Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
Subject: Re: printk/console_init
On Mon, 12 Nov 2007, Siva Prasad wrote:
> I am using 2.6.19 Linux on 8641D based system.
>=20
> I am using early printk's and it works fine until console_init() is
> executed. After that it does not, as the early printk's get disabled,
> which is fine. However, I don't see any prints after that at all, that
> are based on regular printk statements. I looked directly into the
> memory at __log_buf and found all the print messages. It is just not
> coming out to the serial port properly.
>=20
> It would be great if some one can tell me various parameters that I
need
> to consider changing, to successfully port the serial driver for a new
> board.
>=20
> Based on the early printk's, I am getting the following messages...
>=20
> Using MPC86xx HPCN machine description
> Total memory =3D 1024MB; using 2048kB for hash table (at cfe00000)
> Linux version 2.6.19 (sprasad@cider.bivio.net) (gcc version 4.1.1
> 20060525 (Red Hat 4.1.1-1)) #115 SMP Mon Nov 12 18:21:43 PST 2007
> Found legacy serial port 0 for /soc8641@ff700000/serial@4500
> mem=3Dff704500, taddr=3Dff704500, irq=3D1a, clk=3D1496250, speed=3D0
> Found MPC86xx PCIE host bridge at 0x00000000ff708000. Firmware bus
> number: 0->254
> Found MPC86xx PCIE host bridge at 0x00000000ff709000. Firmware bus
> number: 0->255
> MPC86xx HPCN board from Freescale Semiconductor
> Zone PFN ranges:
> DMA 0 -> 196608
> Normal 196608 -> 196608
> HighMem 196608 -> 262144
> early_node_map[1] active PFN ranges
> 0: 0 -> 262144
> start_kernel: 8 22000000.
> Built 1 zonelists. Total pages: 260096
> Kernel command line: console=3DttyS0,115200 root=3D/dev/sda8
^^^^^^^^^^^^
> mpic: Setting up MPIC " MPIC " version 1.2 at ff740000, max 2 CPUs
> mpic: ISU size: 16, shift: 4, mask: f
> mpic: Initializing for 80 sources
> PID hash table entries: 4096 (order: 12, 16384 bytes)
> time_init: decrementer frequency =3D 150.000000 MHz
> time_init: processor frequency =3D 1496.250000 MHz
> <........ Nothing gets printed after this .......>
Did your serial driver (a) call register_console() (b) using the correct
name?
With kind regards,
=20
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village * Da Vincilaan 7-D1 * B-1935 Zaventem * Belgium
=20
Phone: +32 (0)2 700 8453=09
Fax: +32 (0)2 700 8622=09
E-mail: Geert.Uytterhoeven@sonycom.com=09
Internet: http://www.sony-europe.com/
=09
Sony Network and Software Technology Center Europe=09
A division of Sony Service Centre (Europe) N.V.=09
Registered office: Technologielaan 7 * B-1840 Londerzeel * Belgium=09
VAT BE 0413.825.160 * RPR Brussels=09
Fortis Bank Zaventem * Swift GEBABEBB08A * IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH 0/2] PowerPC: 4xx uic updates
From: David Gibson @ 2007-11-14 2:14 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071113200514.72d03792@zod.rchland.ibm.com>
On Tue, Nov 13, 2007 at 08:05:14PM -0600, Josh Boyer wrote:
> On Tue, 13 Nov 2007 23:15:59 +0300
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
> > These patches update 4xx uic code. The first one
> > fixes a minor issue with edge-triggered interrupts,
> > while the second one makes it use generic level and edge irq
> > handlers. I've added irq ack'ing to the unmask callback for
> > level-triggered interrupts, because to de-assert them we have
> > to do 2 things is the exact order as below:
> > 1. de-assert the external source in the ISR.
> > 2. ack the IRQ on the UIC.
> > So, ack'ing level interrupts before unmasking them makes possible
> > to use generic level irq handler and it doesn't hurt, cause
> > we can never miss a level-triggered interrupt. It always stays
> > asserted untill the external source is removed and ack'ed on UIC.
> >
> > These have been tested on Sequoia PowerPC 440EPx board.
>
> Is my mail server slow, or did patch 2 of 2 never make it out?
It reached me eventually, but only to my ibm address, not via the
list (whereas I got both copies of 0 and 1).
--
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/2] PowerPC: make 4xx uic use generic edge and level irq handlers
From: David Gibson @ 2007-11-14 2:13 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071113202731.GA26319@ru.mvista.com>
On Tue, Nov 13, 2007 at 11:27:31PM +0300, Valentine Barshak wrote:
> This patch makes PowerPC 4xx UIC use generic edge and level irq handlers
> instead of a custom handle_uic_irq() function. Acking a level irq on UIC
> has no effect if the interrupt is still asserted by the device, even if
> the interrupt is already masked. So, to really de-assert the interrupt
> we need to de-assert the external source first *and* ack it on UIC then.
> The handle_level_irq() function masks and ack's the interrupt with mask_ack
> callback prior to calling the actual ISR and unmasks it at the end.
> So, to use it with UIC level interrupts we need to ack in the unmask
> callback instead, after the ISR has de-asserted the external interrupt source.
> Even if we ack the interrupt that we didn't handle (unmask/ack it at
> the end of the handler, while next irq is already pending) it will not
> de-assert the irq, untill we de-assert its exteral source.
Hrm. I *think* I'm convinced this is safe, although acking in a
callback which doesn't say it acks is rather yucky. Essentially this
code is trading flow readability (because just reading
handle_level_irq will tell you something other than what it does in
our case) for smaller code size. I'm not sure if this is a good trade
or not.
There's also one definite problem: according to the discussions I had
with Thomas Gleixner when I wrote uic.c, handle_edge_irq is not what
we want for edge interrupts.
Apparently handle_edge_irq is only for edge interrupts on "broken"
PICs which won't latch new interrupts while the irq is masked. UIC is
not in this category, so handle_level_irq is actually what we want,
even for an edge irq.
Yes, I thought the naming was more than a little confusing, too.
--
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 0/2] PowerPC: 4xx uic updates
From: Josh Boyer @ 2007-11-14 2:05 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, dwg
In-Reply-To: <20071113201559.GA26172@ru.mvista.com>
On Tue, 13 Nov 2007 23:15:59 +0300
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> These patches update 4xx uic code. The first one
> fixes a minor issue with edge-triggered interrupts,
> while the second one makes it use generic level and edge irq
> handlers. I've added irq ack'ing to the unmask callback for
> level-triggered interrupts, because to de-assert them we have
> to do 2 things is the exact order as below:
> 1. de-assert the external source in the ISR.
> 2. ack the IRQ on the UIC.
> So, ack'ing level interrupts before unmasking them makes possible
> to use generic level irq handler and it doesn't hurt, cause
> we can never miss a level-triggered interrupt. It always stays
> asserted untill the external source is removed and ack'ed on UIC.
>
> These have been tested on Sequoia PowerPC 440EPx board.
Is my mail server slow, or did patch 2 of 2 never make it out?
josh
^ permalink raw reply
* Xilinx Linux git server available
From: Wolfgang Reissnegger @ 2007-11-14 1:56 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I'm happy to announce that the Xilinx Linux Kernel git server is finally up and running and available to the public.
The Xilinx Linux Kernel is based on the mainline Linux Kernel from kernel.org and adds driver support for various Xilinx IP cores and Xilinx reference boards. It contains many (but not all) of the MicroBlaze contributions and enhancements from John Williams' PetaLogix Linux distribution and some PPC work from Grant Likely. It also contains contributions from Stephen Neuendorffer, Joachim Foerster and Brian Hill, to name a few.
The kernel includes drivers to support the following Xilinx IP cores:
* EMAC, EMACLITE, TEMAC, LLTEMAC
* UART, UARTLITE
* SYSACE
* SPI, GPIO, FB, GPIO, HWICAP, AC97
and support for the following boards:
* ML40x, ML4x0
* Spartan 3E 1600, XUPV2P
In a couple weeks we will be adding MicroBlaze v7 MMU support.
The kernel is licensed under the GPL version 2 and is provided AS IS. It is _not_ supported in any way or form by the Xilinx Support Center. If you call the Xilinx Support center, they will not be able to help you. For those interested in a supported Linux distribution, please contact one of the many partner companies at:
http://www.xilinx.com/ise/embedded/epartners/listing.htm
Please, also keep in mind that the kernel is not actively being tested and will may set your house on fire.
The git URL for the Xilinx Linux Kernel sources is:
git://git.xilinx.com/linux-2.6-xlnx.git
The Web front-end for this server can be found at:
http://git.xilinx.com
At this time there are two branches available:
* lin26-xlnx
This branch is based on the latest stable kernel release (currently 2.6.23)
* lin26-xlnx-rc
This branch tracks the leading edge mainline (currently 2.6.24-rc2)
The git server also hosts a clone of Grant Likely's OF device tree generation tool with additions by Stephen Neuendorffer to support MicroBlaze systems. The git URL for this repository is:
git://git.xilinx.com/gen-mhs-devtree.git
If you have suggestions or want to contribute to the Xilinx Linux Kernel, please send your feedback, patches or other contributions to:
git _at_ xilinx.com
Hope to hear from you soon :-)
Thanks,
Wolfgang
^ permalink raw reply
* Xilinx Linux git server
From: Wolfgang Reissnegger @ 2007-11-14 1:38 UTC (permalink / raw)
To: linuxppc-embedded, uclinux-dev
Hi all,
I'm happy to announce that the Xilinx Linux Kernel git server is finally up and running and available to the public.
The Xilinx Linux Kernel is based on the mainline Linux Kernel from kernel.org and adds driver support for various Xilinx IP cores and Xilinx reference boards. It contains many (but not all) of the MicroBlaze contributions and enhancements from John Williams' PetaLogix Linux distribution and some PPC work from Grant Likely. It also contains contributions from Stephen Neuendorffer, Joachim Foerster and Brian Hill, to name a few.
The kernel includes drivers to support the following Xilinx IP cores:
* EMAC, EMACLITE, TEMAC, LLTEMAC
* UART, UARTLITE
* SYSACE
* SPI, GPIO, FB, GPIO, HWICAP, AC97
and support for the following boards:
* ML40x, ML4x0
* Spartan 3E 1600, XUPV2P
In a couple weeks we will be adding MicroBlaze v7 MMU support.
The kernel is licensed under the GPL version 2 and is provided AS IS. It is _not_ supported in any way or form by the Xilinx Support Center. If you call the Xilinx Support center, they will not be able to help you. For those interested in a supported Linux distribution, please contact one of the many partner companies at:
http://www.xilinx.com/ise/embedded/epartners/listing.htm
Please, also keep in mind that the kernel is not actively being tested and will may set your house on fire.
The git URL for the Xilinx Linux Kernel sources is:
git://git.xilinx.com/linux-2.6-xlnx.git
The Web front-end for this server can be found at:
http://git.xilinx.com
At this time there are two branches available:
* lin26-xlnx
This branch is based on the latest stable kernel release (currently 2.6.23)
* lin26-xlnx-rc
This branch tracks the leading edge mainline (currently 2.6.24-rc2)
The git server also hosts a clone of Grant Likely's OF device tree generation tool with additions by Stephen Neuendorffer to support MicroBlaze systems. The git URL for this repository is:
git://git.xilinx.com/gen-mhs-devtree.git
If you have suggestions or want to contribute to the Xilinx Linux Kernel, please send your feedback, patches or other contributions to:
git _at_ xilinx.com
Hope to hear from you soon :-)
Thanks,
Wolfgang
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Jon Smirl @ 2007-11-14 1:32 UTC (permalink / raw)
To: benh; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <1195003078.28865.18.camel@pasglop>
On 11/13/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > That's why Dominic wants to get OpenOCD running on the PowerPC. All we
> > need is the programming documentation for controlling the CPU via the
> > debug hardware.
>
> Note that this is basically different for every CPU around.
I'd like to get it for the MPC5200 because of the project I am working
on, an open source audio device. It would be nice if there was a cheap
hardware debugger available for hackers to use on it. Maybe one of the
Freescale developers will see this and send me the right docs.
Is it radically different? Dominic has been able to support every ARM
7/9 chip he can get his hands on without too much trouble once the
core support was written. I don't think he has ARM 11 working yet.
>
> > Obviously this documentation exist, all of the commercial vendors had
> > to have it to develop their debuggers. Maybe it is already out there
> > and we just don't know where to look.
>
> Ben.
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] pci hotplug: rm bogus item in rpaphp struct
From: Linas Vepstas @ 2007-11-14 1:19 UTC (permalink / raw)
To: Greg KH, gregkh, Kristen Carlson Accardi; +Cc: linuxppc-dev, linux-pci
Remove unused struct element.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/pci/hotplug/rpaphp.h | 1 -
drivers/pci/hotplug/rpaphp_pci.c | 1 -
2 files changed, 2 deletions(-)
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp.h
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp.h 2007-11-13 18:37:31.000000000 -0600
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp.h 2007-11-13 19:00:42.000000000 -0600
@@ -76,7 +76,6 @@ struct slot {
char *name;
struct device_node *dn;
struct pci_bus *bus;
- struct list_head *pci_devs;
struct hotplug_slot *hotplug_slot;
};
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp_pci.c 2007-11-13 18:37:31.000000000 -0600
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c 2007-11-13 19:00:13.000000000 -0600
@@ -100,7 +100,6 @@ int rpaphp_enable_slot(struct slot *slot
info->adapter_status = EMPTY;
slot->bus = bus;
- slot->pci_devs = &bus->devices;
/* if there's an adapter in the slot, go add the pci devices */
if (state == PRESENT) {
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Benjamin Herrenschmidt @ 2007-11-14 1:17 UTC (permalink / raw)
To: Jon Smirl; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <9e4733910711131553ked87330ubc0c439c42e51ace@mail.gmail.com>
> That's why Dominic wants to get OpenOCD running on the PowerPC. All we
> need is the programming documentation for controlling the CPU via the
> debug hardware.
Note that this is basically different for every CPU around.
> Obviously this documentation exist, all of the commercial vendors had
> to have it to develop their debuggers. Maybe it is already out there
> and we just don't know where to look.
Ben.
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Benjamin Herrenschmidt @ 2007-11-14 1:17 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071113222149.271610@gmx.net>
On Tue, 2007-11-13 at 23:21 +0100, Gerhard Pircher wrote:
> -------- Original-Nachricht --------
> > Datum: Tue, 13 Nov 2007 17:10:29 -0500
> > Von: "Jon Smirl" <jonsmirl@gmail.com>
> > An: "Grant Likely" <grant.likely@secretlab.ca>
> > CC: "Gerhard Pircher" <gerhard_pircher@gmx.net>, linuxppc-dev@ozlabs.org
> > Betreff: Re: Hardware debuggers for PPC74xx G4 CPUs
>
> > On 11/13/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > On 11/13/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > Abatron BDI-2000.
> > >
> > > Oops, but that's not all that cheap. ($2750USD). You might try
> > > looking at the Macraigor Wiggler
> > > (http://www.macraigor.com/wiggler.htm), but it has limited powerpc
> > > support.
> >
> > Here are the choices:
> > http://www.macraigor.com/cpus.htm
> Looks like the Abatron BDI-2000 is the cheapest hardware debugger that
> supports 74xx G4 CPUs. :-(
Do you have the appropriate connector for it on the motherboard as
well ? If not, then you are out of luck...
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] PowerPC: 4xx uic: add mask_ack callback
From: David Gibson @ 2007-11-14 0:57 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071113202521.GA26295@ru.mvista.com>
On Tue, Nov 13, 2007 at 11:25:21PM +0300, Valentine Barshak wrote:
> This adds uic_mask_ack_irq() callback to PowerPC 4xx uic code
> to avoid kernel crash. It is used for edge-triggered interrupts
> by handle_uic_irq().
Oops. Obviously never caught this obvious bug, because I've never
used an edge-triggered interrupt on the Ebony yet.
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.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
* [PATCH] pci hotplug: fix rpaphp directory naming
From: Linas Vepstas @ 2007-11-14 0:34 UTC (permalink / raw)
To: Greg KH, gregkh, Kristen Carlson Accardi
Cc: pcihpd-discuss, Alex Chiang, Matthew Wilcox, rick.jones2,
linux-kernel, linuxppc-dev, linux-acpi, linux-pci, strosake, lenb
Fix presentation of the slot number in the /sys/bus/pci/slots
directory to match that used in the majority of other drivers.
------
On Tue, Nov 13, 2007 at 02:58:30PM -0700, Matthew Wilcox wrote:
> On Tue, Nov 13, 2007 at 03:41:21PM -0600, Linas Vepstas wrote:
> > /sys/bus/pci/slots
> > /sys/bus/pci/slots/control
> > /sys/bus/pci/slots/control/remove_slot
> > /sys/bus/pci/slots/control/add_slot
> > /sys/bus/pci/slots/0001:00:02.0
> > /sys/bus/pci/slots/0001:00:02.0/phy_location
>
> Ugh. Almost two years ago, paulus promised me he was going to fix the
> slot name for rpaphp. Guess he didn't.
You have to ask the right person. :-) I've been defacto mainaining
the rpaphp code for unpteen years now. On the other hand, I am also
much, much better at promising than delivering.
> This is one of the hateful things about the current design -- hotplug
> drivers do too much. Instead of being just the interface between the
> Linux PCI code and the hardware, they create sysfs directories, add
> files,
> and generally have far too much freedom.
I chopped out several hundred LOC from rpaphp a year ago,
and hopefuly that might make furthre simplification easier
someday.
> We have four different schemes currently for naming in slots/,
> 1. slot number. Used by cpqphp, ibmphp, acpiphp, pciehp, shpc.
> 2. domain:bus:dev:fn. Used by fakephp.
> 3a. domain:bus:dev. Used by rpaphp and sgihp.
> 3b. Except that rpaphp uses phy_location to present the information
> that
> should be in the name and sgihp uses path.
>
> ... I've forgotten what cpci uses. And yenta doesn't use it.
>
> How is anyone supposed to write sane managability tools in the
> presence
> of such anarchy?
>
> > ~ # cat /sys/bus/pci/slots/0000:00:02.2/phy_location
> > U787A.001.DNZ00Z5-P1-C2
>
> Right. This should look like:
>
> # cat /sys/bus/pci/slots/U787A.001.DNZ00Z5-P1-C2/address
> 0000:00:02
This patch implements exactly what you describe. Boot tested.
I assume you really mean it -- if so, then please review and
ack the patch !?
I have absolutely no clue if this breaks any existing IBM tools.
I'm pretty sure it doesn't ... but attention Mike Strosaker! does it?
drivers/pci/hotplug/rpaphp.h | 1
drivers/pci/hotplug/rpaphp_pci.c | 14 -----------
drivers/pci/hotplug/rpaphp_slot.c | 47 +++++++++++++++++++-------------------
3 files changed, 24 insertions(+), 38 deletions(-)
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp_pci.c 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c 2007-11-13 17:52:10.000000000 -0600
@@ -64,19 +64,6 @@ int rpaphp_get_sensor_state(struct slot
return rc;
}
-static void set_slot_name(struct slot *slot)
-{
- struct pci_bus *bus = slot->bus;
- struct pci_dev *bridge;
-
- bridge = bus->self;
- if (bridge)
- strcpy(slot->name, pci_name(bridge));
- else
- sprintf(slot->name, "%04x:%02x:00.0", pci_domain_nr(bus),
- bus->number);
-}
-
/**
* rpaphp_enable_slot - record slot state, config pci device
*
@@ -114,7 +101,6 @@ int rpaphp_enable_slot(struct slot *slot
info->adapter_status = EMPTY;
slot->bus = bus;
slot->pci_devs = &bus->devices;
- set_slot_name(slot);
/* if there's an adapter in the slot, go add the pci devices */
if (state == PRESENT) {
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_slot.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp_slot.c 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_slot.c 2007-11-13 18:05:13.000000000 -0600
@@ -33,23 +33,31 @@
#include <asm/rtas.h>
#include "rpaphp.h"
-static ssize_t location_read_file (struct hotplug_slot *php_slot, char *buf)
+static ssize_t address_read_file (struct hotplug_slot *php_slot, char *buf)
{
- char *value;
- int retval = -ENOENT;
+ int retval;
struct slot *slot = (struct slot *)php_slot->private;
+ struct pci_bus *bus;
if (!slot)
- return retval;
+ return -ENOENT;
- value = slot->location;
- retval = sprintf (buf, "%s\n", value);
+ bus = slot->bus;
+ if (!bus)
+ return -ENOENT;
+
+ if (bus->self)
+ retval = sprintf(buf, pci_name(bus->self));
+ else
+ retval = sprintf(buf, "%04x:%02x:00.0",
+ pci_domain_nr(bus), bus->number);
+
return retval;
}
-static struct hotplug_slot_attribute php_attr_location = {
- .attr = {.name = "phy_location", .mode = S_IFREG | S_IRUGO},
- .show = location_read_file,
+static struct hotplug_slot_attribute php_attr_address = {
+ .attr = {.name = "address", .mode = S_IFREG | S_IRUGO},
+ .show = address_read_file,
};
/* free up the memory used by a slot */
@@ -64,7 +72,6 @@ void dealloc_slot_struct(struct slot *sl
kfree(slot->hotplug_slot->info);
kfree(slot->hotplug_slot->name);
kfree(slot->hotplug_slot);
- kfree(slot->location);
kfree(slot);
}
@@ -83,16 +90,13 @@ struct slot *alloc_slot_struct(struct de
GFP_KERNEL);
if (!slot->hotplug_slot->info)
goto error_hpslot;
- slot->hotplug_slot->name = kmalloc(BUS_ID_SIZE + 1, GFP_KERNEL);
+ slot->hotplug_slot->name = kmalloc(strlen(drc_name) + 1, GFP_KERNEL);
if (!slot->hotplug_slot->name)
goto error_info;
- slot->location = kmalloc(strlen(drc_name) + 1, GFP_KERNEL);
- if (!slot->location)
- goto error_name;
slot->name = slot->hotplug_slot->name;
+ strcpy(slot->name, drc_name);
slot->dn = dn;
slot->index = drc_index;
- strcpy(slot->location, drc_name);
slot->power_domain = power_domain;
slot->hotplug_slot->private = slot;
slot->hotplug_slot->ops = &rpaphp_hotplug_slot_ops;
@@ -100,8 +104,6 @@ struct slot *alloc_slot_struct(struct de
return (slot);
-error_name:
- kfree(slot->hotplug_slot->name);
error_info:
kfree(slot->hotplug_slot->info);
error_hpslot:
@@ -133,8 +135,8 @@ int rpaphp_deregister_slot(struct slot *
list_del(&slot->rpaphp_slot_list);
- /* remove "phy_location" file */
- sysfs_remove_file(&php_slot->kobj, &php_attr_location.attr);
+ /* remove "address" file */
+ sysfs_remove_file(&php_slot->kobj, &php_attr_address.attr);
retval = pci_hp_deregister(php_slot);
if (retval)
@@ -166,8 +168,8 @@ int rpaphp_register_slot(struct slot *sl
return retval;
}
- /* create "phy_location" file */
- retval = sysfs_create_file(&php_slot->kobj, &php_attr_location.attr);
+ /* create "address" file */
+ retval = sysfs_create_file(&php_slot->kobj, &php_attr_address.attr);
if (retval) {
err("sysfs_create_file failed with error %d\n", retval);
goto sysfs_fail;
@@ -175,8 +177,7 @@ int rpaphp_register_slot(struct slot *sl
/* add slot to our internal list */
list_add(&slot->rpaphp_slot_list, &rpaphp_slot_head);
- info("Slot [%s](PCI location=%s) registered\n", slot->name,
- slot->location);
+ info("Slot [%s] registered\n", slot->name);
return 0;
sysfs_fail:
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp.h
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp.h 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp.h 2007-11-13 18:06:16.000000000 -0600
@@ -74,7 +74,6 @@ struct slot {
u32 type;
u32 power_domain;
char *name;
- char *location;
struct device_node *dn;
struct pci_bus *bus;
struct list_head *pci_devs;
^ permalink raw reply
* Re: I2C on mpc8248 / device tree
From: Jon Smirl @ 2007-11-13 23:56 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0711131539n228f9f21q7b2acc896499b80d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 397 bytes --]
I am working on a patch for i2c and device tree. I attached the current version.
DTC entry looks like this.
i2c@3d40 {
compatible = "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";
reg = <3d40 40>;
interrupts = <2 10 0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
rtc@51f {
compatible = "epson,rtc8564";
reg = <51>;
};
};
--
Jon Smirl
jonsmirl@gmail.com
[-- Attachment #2: jds-i2c-list --]
[-- Type: application/octet-stream, Size: 9036 bytes --]
Extend i2c-core to support lists of device tree compatible names when matching drivers
From: Jon Smirl <jonsmirl@gmail.com>
Patch creates a new field, aliases, in the i2c_driver structure. i2c chip device drivers can use this field to add alias names. For example in Open Firmware format: "ricoh,rs5c372a". Three drivers implement alias names as an example. fsl_soc.c is adjusted to remove private mapping mechanism and use this more general form.
---
arch/powerpc/sysdev/fsl_soc.c | 46 ++++++-----------------------------------
drivers/i2c/i2c-core.c | 16 +++++++++++++-
drivers/rtc/rtc-ds1307.c | 14 ++++++++++++
drivers/rtc/rtc-ds1374.c | 1 +
drivers/rtc/rtc-pcf8563.c | 1 +
drivers/rtc/rtc-rs5c372.c | 18 +++++++++++++---
include/linux/i2c.h | 13 +++++++++---
7 files changed, 63 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..cb95a72 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -320,48 +320,12 @@ arch_initcall(gfar_of_init);
#ifdef CONFIG_I2C_BOARDINFO
#include <linux/i2c.h>
-struct i2c_driver_device {
- char *of_device;
- char *i2c_driver;
- char *i2c_type;
-};
-
-static struct i2c_driver_device i2c_devices[] __initdata = {
- {"ricoh,rs5c372a", "rtc-rs5c372", "rs5c372a",},
- {"ricoh,rs5c372b", "rtc-rs5c372", "rs5c372b",},
- {"ricoh,rv5c386", "rtc-rs5c372", "rv5c386",},
- {"ricoh,rv5c387a", "rtc-rs5c372", "rv5c387a",},
- {"dallas,ds1307", "rtc-ds1307", "ds1307",},
- {"dallas,ds1337", "rtc-ds1307", "ds1337",},
- {"dallas,ds1338", "rtc-ds1307", "ds1338",},
- {"dallas,ds1339", "rtc-ds1307", "ds1339",},
- {"dallas,ds1340", "rtc-ds1307", "ds1340",},
- {"stm,m41t00", "rtc-ds1307", "m41t00"},
- {"dallas,ds1374", "rtc-ds1374", "rtc-ds1374",},
-};
-
-static int __init of_find_i2c_driver(struct device_node *node,
- struct i2c_board_info *info)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
- if (!of_device_is_compatible(node, i2c_devices[i].of_device))
- continue;
- if (strlcpy(info->driver_name, i2c_devices[i].i2c_driver,
- KOBJ_NAME_LEN) >= KOBJ_NAME_LEN ||
- strlcpy(info->type, i2c_devices[i].i2c_type,
- I2C_NAME_SIZE) >= I2C_NAME_SIZE)
- return -ENOMEM;
- return 0;
- }
- return -ENODEV;
-}
static void __init of_register_i2c_devices(struct device_node *adap_node,
int bus_num)
{
struct device_node *node = NULL;
+ const char *compatible;
while ((node = of_get_next_child(adap_node, node))) {
struct i2c_board_info info = {};
@@ -378,9 +342,13 @@ static void __init of_register_i2c_devices(struct device_node *adap_node,
if (info.irq == NO_IRQ)
info.irq = -1;
- if (of_find_i2c_driver(node, &info) < 0)
+ compatible = of_get_property(node, "compatible", &len);
+ if (!compatible) {
+ printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing compatible attribute\n");
continue;
-
+ }
+ strncpy(info.name, compatible, sizeof(info.name));
+
info.addr = *addr;
i2c_register_board_info(bus_num, &info, 1);
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 1a4e8dc..8b49860 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -51,6 +51,7 @@ static int i2c_device_match(struct device *dev, struct device_driver *drv)
{
struct i2c_client *client = to_i2c_client(dev);
struct i2c_driver *driver = to_i2c_driver(drv);
+ char const **alias;
/* make legacy i2c drivers bypass driver model probing entirely;
* such drivers scan each i2c adapter/bus themselves.
@@ -61,7 +62,20 @@ static int i2c_device_match(struct device *dev, struct device_driver *drv)
/* new style drivers use the same kind of driver matching policy
* as platform devices or SPI: compare device and driver IDs.
*/
- return strcmp(client->driver_name, drv->name) == 0;
+ if (strcmp(client->driver_name, drv->name) == 0)
+ return true;
+
+ /* Match against arrary of alias device tree names. When a match
+ * is found change the reference to point at the copy inside the
+ * chip driver allowing the caller's string to be freed.
+ */
+ alias = driver->aliases;
+ while (alias && *alias) {
+ if (strnicmp(client->driver_name, *alias, sizeof client->driver_name) == 0)
+ return true;
+ alias++;
+ }
+ return 0;
}
#ifdef CONFIG_HOTPLUG
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index db6f3f0..456b7ca 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -135,6 +135,11 @@ static inline const struct chip_desc *find_chip(const char *s)
for (i = 0; i < ARRAY_SIZE(chips); i++)
if (strnicmp(s, chips[i].name, sizeof chips[i].name) == 0)
return &chips[i];
+ /* check the alias names */
+ for (i = ds_1307; i <= m41t00; i++)
+ if (strnicmp(client->driver_name, ds1307_driver.aliases[i], sizeof client->driver_name) == 0)
+ return &chips[i];
+
return NULL;
}
@@ -442,6 +447,15 @@ static struct i2c_driver ds1307_driver = {
.name = "rtc-ds1307",
.owner = THIS_MODULE,
},
+ .aliases = (char const *[]){
+ [ds_1307] = "dallas,ds1307",
+ [ds_1337] = "dallas,ds1337",
+ [ds_1338] = "dallas,ds1338",
+ [ds_1339] = "dallas,ds1339",
+ [ds_1340] = "dallas,ds1340",
+ [m41t00] = "stm,m41t00",
+ 0
+ },
.probe = ds1307_probe,
.remove = __devexit_p(ds1307_remove),
};
diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
index 45bda18..df8eca4 100644
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -427,6 +427,7 @@ static struct i2c_driver ds1374_driver = {
.name = "rtc-ds1374",
.owner = THIS_MODULE,
},
+ .aliases = (char const *[]){"dallas,ds1374", 0},
.probe = ds1374_probe,
.remove = __devexit_p(ds1374_remove),
};
diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index 0242d80..fa04dc5 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -266,6 +266,7 @@ static struct i2c_driver pcf8563_driver = {
.driver = {
.name = "pcf8563",
},
+ .aliases = (char const *[]){"philips,pcf8563", "epson,rtc8564", 0},
.id = I2C_DRIVERID_PCF8563,
.attach_adapter = &pcf8563_attach,
.detach_client = &pcf8563_detach,
diff --git a/drivers/rtc/rtc-rs5c372.c b/drivers/rtc/rtc-rs5c372.c
index 6b67b50..b458f5f 100644
--- a/drivers/rtc/rtc-rs5c372.c
+++ b/drivers/rtc/rtc-rs5c372.c
@@ -62,7 +62,6 @@
enum rtc_type {
- rtc_undef = 0,
rtc_rs5c372a,
rtc_rs5c372b,
rtc_rv5c386,
@@ -531,8 +530,14 @@ static int rs5c372_probe(struct i2c_client *client)
else if (strcmp(client->name, "rv5c387a") == 0)
rs5c372->type = rtc_rv5c387a;
else {
- rs5c372->type = rtc_rs5c372b;
- dev_warn(&client->dev, "assuming rs5c372b\n");
+ /* check the alias names */
+ for (rs5c372->type = rtc_rs5c372a; rs5c372->type <= rtc_rv5c387a; rs5c372->type++)
+ if (strnicmp(client->driver_name, rs5c372_driver.aliases[rs5c372->type], sizeof client->driver_name) == 0)
+ break;
+ if (rs5c372->type > rtc_rv5c387a) {
+ rs5c372->type = rtc_rs5c372b;
+ dev_warn(&client->dev, "assuming rs5c372b\n");
+ }
}
/* clock may be set for am/pm or 24 hr time */
@@ -649,6 +654,13 @@ static struct i2c_driver rs5c372_driver = {
.driver = {
.name = "rtc-rs5c372",
},
+ .aliases = (char const *[]){
+ [rtc_rs5c372a] = "ricoh,rs5c372a",
+ [rtc_rs5c372b] = "ricoh,rs5c372b",
+ [rtc_rv5c386] = "ricoh,rv5c386",
+ [rtc_rv5c387a] = "ricoh,rv5c387a",
+ 0
+ },
.probe = rs5c372_probe,
.remove = rs5c372_remove,
};
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 8033e6b..b952c8a 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -105,6 +105,13 @@ extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client * client,
struct i2c_driver {
int id;
unsigned int class;
+
+ /* Alias names for the driver. Used to support device trees on
+ * the PowerPC architecture. Device tree names take the form of
+ * vendor,chip. For example "epson,rtc8564". Alias is a list of
+ * strings terminated by a zero entry.
+ */
+ char const **aliases;
/* Notifies the driver that a new bus has appeared. This routine
* can be used by the driver to test if the bus meets its conditions
@@ -144,7 +151,7 @@ struct i2c_driver {
};
#define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
-#define I2C_NAME_SIZE 20
+#define I2C_NAME_SIZE 40
/**
* struct i2c_client - represent an I2C slave device
@@ -179,7 +186,7 @@ struct i2c_client {
/* to the client */
struct device dev; /* the device structure */
int irq; /* irq issued by device (or -1) */
- char driver_name[KOBJ_NAME_LEN];
+ char driver_name[I2C_NAME_SIZE];
struct list_head list;
struct completion released;
};
@@ -223,7 +230,7 @@ static inline void i2c_set_clientdata (struct i2c_client *dev, void *data)
* with the adapter already known.
*/
struct i2c_board_info {
- char driver_name[KOBJ_NAME_LEN];
+ char driver_name[I2C_NAME_SIZE];
char type[I2C_NAME_SIZE];
unsigned short flags;
unsigned short addr;
[-- Attachment #3: jds-mpc-i2c --]
[-- Type: application/octet-stream, Size: 10663 bytes --]
Convert PowerPC MPC i2c to of_platform_driver from platform_driver
From: Jon Smirl <jonsmirl@gmail.com>
Convert MPC i2c driver from being a platform_driver to an open firmware version. Error returns were improved. Routine names were changed from fsl_ to mpc_ to make them match the file name.
---
arch/powerpc/sysdev/fsl_soc.c | 96 -----------------------
drivers/i2c/busses/i2c-mpc.c | 169 +++++++++++++++++++++++++++--------------
2 files changed, 113 insertions(+), 152 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index cb95a72..d6ef264 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -318,102 +318,6 @@ err:
arch_initcall(gfar_of_init);
-#ifdef CONFIG_I2C_BOARDINFO
-#include <linux/i2c.h>
-
-static void __init of_register_i2c_devices(struct device_node *adap_node,
- int bus_num)
-{
- struct device_node *node = NULL;
- const char *compatible;
-
- while ((node = of_get_next_child(adap_node, node))) {
- struct i2c_board_info info = {};
- const u32 *addr;
- int len;
-
- addr = of_get_property(node, "reg", &len);
- if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
- printk(KERN_WARNING "fsl_soc.c: invalid i2c device entry\n");
- continue;
- }
-
- info.irq = irq_of_parse_and_map(node, 0);
- if (info.irq == NO_IRQ)
- info.irq = -1;
-
- compatible = of_get_property(node, "compatible", &len);
- if (!compatible) {
- printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing compatible attribute\n");
- continue;
- }
- strncpy(info.name, compatible, sizeof(info.name));
-
- info.addr = *addr;
-
- i2c_register_board_info(bus_num, &info, 1);
- }
-}
-
-static int __init fsl_i2c_of_init(void)
-{
- struct device_node *np;
- unsigned int i;
- struct platform_device *i2c_dev;
- int ret;
-
- for (np = NULL, i = 0;
- (np = of_find_compatible_node(np, "i2c", "fsl-i2c")) != NULL;
- i++) {
- struct resource r[2];
- struct fsl_i2c_platform_data i2c_data;
- const unsigned char *flags = NULL;
-
- memset(&r, 0, sizeof(r));
- memset(&i2c_data, 0, sizeof(i2c_data));
-
- ret = of_address_to_resource(np, 0, &r[0]);
- if (ret)
- goto err;
-
- of_irq_to_resource(np, 0, &r[1]);
-
- i2c_dev = platform_device_register_simple("fsl-i2c", i, r, 2);
- if (IS_ERR(i2c_dev)) {
- ret = PTR_ERR(i2c_dev);
- goto err;
- }
-
- i2c_data.device_flags = 0;
- flags = of_get_property(np, "dfsrr", NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
-
- flags = of_get_property(np, "fsl5200-clocking", NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_CLOCK_5200;
-
- ret =
- platform_device_add_data(i2c_dev, &i2c_data,
- sizeof(struct
- fsl_i2c_platform_data));
- if (ret)
- goto unreg;
-
- of_register_i2c_devices(np, i);
- }
-
- return 0;
-
-unreg:
- platform_device_unregister(i2c_dev);
-err:
- return ret;
-}
-
-arch_initcall(fsl_i2c_of_init);
-#endif
-
#ifdef CONFIG_PPC_83xx
static int __init mpc83xx_wdt_init(void)
{
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index d8de4ac..d20669b 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -17,7 +17,7 @@
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/init.h>
-#include <linux/platform_device.h>
+#include <linux/of_platform.h>
#include <asm/io.h>
#include <linux/fsl_devices.h>
@@ -25,13 +25,13 @@
#include <linux/interrupt.h>
#include <linux/delay.h>
-#define MPC_I2C_ADDR 0x00
+#define DRV_NAME "mpc-i2c"
+
#define MPC_I2C_FDR 0x04
#define MPC_I2C_CR 0x08
#define MPC_I2C_SR 0x0c
#define MPC_I2C_DR 0x10
#define MPC_I2C_DFSRR 0x14
-#define MPC_I2C_REGION 0x20
#define CCR_MEN 0x80
#define CCR_MIEN 0x40
@@ -180,7 +180,7 @@ static void mpc_i2c_stop(struct mpc_i2c *i2c)
static int mpc_write(struct mpc_i2c *i2c, int target,
const u8 * data, int length, int restart)
{
- int i;
+ int i, result;
unsigned timeout = i2c->adap.timeout;
u32 flags = restart ? CCR_RSTA : 0;
@@ -192,15 +192,15 @@ static int mpc_write(struct mpc_i2c *i2c, int target,
/* Write target byte */
writeb((target << 1), i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ if ((result = i2c_wait(i2c, timeout, 1)) < 0)
+ return result;
for (i = 0; i < length; i++) {
/* Write data byte */
writeb(data[i], i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ if ((result = i2c_wait(i2c, timeout, 1)) < 0)
+ return result;
}
return 0;
@@ -210,7 +210,7 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
u8 * data, int length, int restart)
{
unsigned timeout = i2c->adap.timeout;
- int i;
+ int i, result;
u32 flags = restart ? CCR_RSTA : 0;
/* Start with MEN */
@@ -221,8 +221,8 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
/* Write target address byte - this time with the read flag set */
writeb((target << 1) | 1, i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ if ((result = i2c_wait(i2c, timeout, 1)) < 0)
+ return result;
if (length) {
if (length == 1)
@@ -234,8 +234,8 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
}
for (i = 0; i < length; i++) {
- if (i2c_wait(i2c, timeout, 0) < 0)
- return -1;
+ if ((result = i2c_wait(i2c, timeout, 0)) < 0)
+ return result;
/* Generate txack on next to last byte */
if (i == length - 2)
@@ -312,74 +312,115 @@ static struct i2c_adapter mpc_ops = {
.retries = 1
};
-static int fsl_i2c_probe(struct platform_device *pdev)
+struct i2c_driver_device {
+ char *of_device;
+ char *i2c_driver;
+ char *i2c_type;
+};
+
+static void of_register_i2c_devices(struct i2c_adapter *adap, struct device_node *adap_node)
+{
+ struct device_node *node = NULL;
+
+ while ((node = of_get_next_child(adap_node, node))) {
+ struct i2c_board_info info;
+ const u32 *addr;
+ const char *compatible;
+ int len;
+
+ addr = of_get_property(node, "reg", &len);
+ if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
+ printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing reg attribute\n");
+ continue;
+ }
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ if (info.irq == NO_IRQ)
+ info.irq = -1;
+
+ compatible = of_get_property(node, "compatible", &len);
+ if (!compatible) {
+ printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing compatible attribute\n");
+ continue;
+ }
+ strncpy(info.driver_name, compatible, sizeof(info.driver_name));
+ info.type[0] = '\0';
+
+ info.platform_data = NULL;
+ info.addr = *addr;
+
+ i2c_new_device(adap, &info);
+ }
+}
+
+static int mpc_i2c_probe(struct of_device *op, const struct of_device_id *match)
{
int result = 0;
struct mpc_i2c *i2c;
- struct fsl_i2c_platform_data *pdata;
- struct resource *r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
- pdata = (struct fsl_i2c_platform_data *) pdev->dev.platform_data;
if (!(i2c = kzalloc(sizeof(*i2c), GFP_KERNEL))) {
return -ENOMEM;
}
- i2c->irq = platform_get_irq(pdev, 0);
- if (i2c->irq < 0) {
- result = -ENXIO;
- goto fail_get_irq;
- }
- i2c->flags = pdata->device_flags;
- init_waitqueue_head(&i2c->queue);
+ if (of_get_property(op->node, "dfsrr", NULL))
+ i2c->flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
- i2c->base = ioremap((phys_addr_t)r->start, MPC_I2C_REGION);
+ if (of_device_is_compatible(op->node, "mpc5200-i2c"))
+ i2c->flags |= FSL_I2C_DEV_CLOCK_5200;
+ init_waitqueue_head(&i2c->queue);
+
+ i2c->base = of_iomap(op->node, 0);
if (!i2c->base) {
printk(KERN_ERR "i2c-mpc - failed to map controller\n");
result = -ENOMEM;
goto fail_map;
}
- if (i2c->irq != 0)
- if ((result = request_irq(i2c->irq, mpc_i2c_isr,
- IRQF_SHARED, "i2c-mpc", i2c)) < 0) {
- printk(KERN_ERR
- "i2c-mpc - failed to attach interrupt\n");
- goto fail_irq;
- }
+ i2c->irq = irq_of_parse_and_map(op->node, 0);
+ if (i2c->irq == NO_IRQ) {
+ result = -ENXIO;
+ goto fail_irq;
+ }
+
+ if ((result = request_irq(i2c->irq, mpc_i2c_isr,
+ IRQF_SHARED, "i2c-mpc", i2c)) < 0) {
+ printk(KERN_ERR "i2c-mpc - failed to attach interrupt\n");
+ goto fail_irq;
+ }
mpc_i2c_setclock(i2c);
- platform_set_drvdata(pdev, i2c);
+
+ dev_set_drvdata(&op->dev, i2c);
i2c->adap = mpc_ops;
- i2c->adap.nr = pdev->id;
i2c_set_adapdata(&i2c->adap, i2c);
- i2c->adap.dev.parent = &pdev->dev;
- if ((result = i2c_add_numbered_adapter(&i2c->adap)) < 0) {
+ i2c->adap.dev.parent = &op->dev;
+ if ((result = i2c_add_adapter(&i2c->adap)) < 0) {
printk(KERN_ERR "i2c-mpc - failed to add adapter\n");
goto fail_add;
}
+
+ of_register_i2c_devices(&i2c->adap, op->node);
return result;
- fail_add:
+fail_add:
if (i2c->irq != 0)
free_irq(i2c->irq, i2c);
- fail_irq:
+fail_irq:
iounmap(i2c->base);
- fail_map:
- fail_get_irq:
+fail_map:
kfree(i2c);
return result;
};
-static int fsl_i2c_remove(struct platform_device *pdev)
+static int mpc_i2c_remove(struct of_device *op)
{
- struct mpc_i2c *i2c = platform_get_drvdata(pdev);
+ struct mpc_i2c *i2c = dev_get_drvdata(&op->dev);
i2c_del_adapter(&i2c->adap);
- platform_set_drvdata(pdev, NULL);
+ dev_set_drvdata(&op->dev, NULL);
if (i2c->irq != 0)
free_irq(i2c->irq, i2c);
@@ -389,28 +430,44 @@ static int fsl_i2c_remove(struct platform_device *pdev)
return 0;
};
+static struct of_device_id mpc_i2c_of_match[] = {
+ {
+ .compatible = "fsl-i2c",
+ },
+};
+MODULE_DEVICE_TABLE(of, mpc_i2c_of_match);
+
+
/* Structure for a device driver */
-static struct platform_driver fsl_i2c_driver = {
- .probe = fsl_i2c_probe,
- .remove = fsl_i2c_remove,
- .driver = {
- .owner = THIS_MODULE,
- .name = "fsl-i2c",
+static struct of_platform_driver mpc_i2c_driver = {
+ .match_table = mpc_i2c_of_match,
+ .probe = mpc_i2c_probe,
+ .remove = __devexit_p(mpc_i2c_remove),
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = DRV_NAME,
},
};
-static int __init fsl_i2c_init(void)
+static int __init mpc_i2c_init(void)
{
- return platform_driver_register(&fsl_i2c_driver);
+ int rv;
+
+ rv = of_register_platform_driver(&mpc_i2c_driver);
+ if (rv) {
+ printk(KERN_ERR DRV_NAME " of_register_platform_driver failed (%i)\n", rv);
+ return rv;
+ }
+ return 0;
}
-static void __exit fsl_i2c_exit(void)
+static void __exit mpc_i2c_exit(void)
{
- platform_driver_unregister(&fsl_i2c_driver);
+ of_unregister_platform_driver(&mpc_i2c_driver);
}
-module_init(fsl_i2c_init);
-module_exit(fsl_i2c_exit);
+module_init(mpc_i2c_init);
+module_exit(mpc_i2c_exit);
MODULE_AUTHOR("Adrian Cox <adrian@humboldt.co.uk>");
MODULE_DESCRIPTION
[-- Attachment #4: jds-pfc-rtc --]
[-- Type: application/octet-stream, Size: 3762 bytes --]
Convert pfc8563 i2c driver from old style to new style
From: Jon Smirl <jonsmirl@gmail.com>
---
drivers/rtc/rtc-pcf8563.c | 103 +++++++++------------------------------------
1 files changed, 21 insertions(+), 82 deletions(-)
diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index fa04dc5..bebe139 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -25,10 +25,6 @@
* located at 0x51 will pass the validation routine due to
* the way the registers are implemented.
*/
-static unsigned short normal_i2c[] = { I2C_CLIENT_END };
-
-/* Module parameters */
-I2C_CLIENT_INSMOD;
#define PCF8563_REG_ST1 0x00 /* status */
#define PCF8563_REG_ST2 0x01
@@ -72,9 +68,6 @@ struct pcf8563 {
int c_polarity; /* 0: MO_C=1 means 19xx, otherwise MO_C=1 means 20xx */
};
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind);
-static int pcf8563_detach(struct i2c_client *client);
-
/*
* In the routines that deal directly with the pcf8563 hardware, we use
* rtc_time -- month 0-11, hour 0-23, yr = calendar year-epoch.
@@ -257,99 +250,45 @@ static const struct rtc_class_ops pcf8563_rtc_ops = {
.set_time = pcf8563_rtc_set_time,
};
-static int pcf8563_attach(struct i2c_adapter *adapter)
+static int pcf8563_remove(struct i2c_client *client)
{
- return i2c_probe(adapter, &addr_data, pcf8563_probe);
+ struct rtc_device *rtc = i2c_get_clientdata(client);
+
+ if (rtc)
+ rtc_device_unregister(rtc);
+
+ return 0;
}
+static int pcf8563_probe(struct i2c_client *client);
+
static struct i2c_driver pcf8563_driver = {
.driver = {
- .name = "pcf8563",
+ .name = "rtc-pcf8563",
},
.aliases = (char const *[]){"philips,pcf8563", "epson,rtc8564", 0},
.id = I2C_DRIVERID_PCF8563,
- .attach_adapter = &pcf8563_attach,
- .detach_client = &pcf8563_detach,
+ .probe = &pcf8563_probe,
+ .remove = &pcf8563_remove,
};
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind)
+static int pcf8563_probe(struct i2c_client *client)
{
- struct pcf8563 *pcf8563;
- struct i2c_client *client;
+ int result;
struct rtc_device *rtc;
-
- int err = 0;
-
- dev_dbg(&adapter->dev, "%s\n", __FUNCTION__);
-
- if (!i2c_check_functionality(adapter, I2C_FUNC_I2C)) {
- err = -ENODEV;
- goto exit;
- }
-
- if (!(pcf8563 = kzalloc(sizeof(struct pcf8563), GFP_KERNEL))) {
- err = -ENOMEM;
- goto exit;
- }
-
- client = &pcf8563->client;
- client->addr = address;
- client->driver = &pcf8563_driver;
- client->adapter = adapter;
-
- strlcpy(client->name, pcf8563_driver.driver.name, I2C_NAME_SIZE);
-
- /* Verify the chip is really an PCF8563 */
- if (kind < 0) {
- if (pcf8563_validate_client(client) < 0) {
- err = -ENODEV;
- goto exit_kfree;
- }
- }
-
- /* Inform the i2c layer */
- if ((err = i2c_attach_client(client)))
- goto exit_kfree;
-
- dev_info(&client->dev, "chip found, driver version " DRV_VERSION "\n");
-
+
+ result = pcf8563_validate_client(client);
+ if (result)
+ return result;
+
rtc = rtc_device_register(pcf8563_driver.driver.name, &client->dev,
&pcf8563_rtc_ops, THIS_MODULE);
-
- if (IS_ERR(rtc)) {
- err = PTR_ERR(rtc);
- goto exit_detach;
- }
+ if (IS_ERR(rtc))
+ return PTR_ERR(rtc);
i2c_set_clientdata(client, rtc);
return 0;
-
-exit_detach:
- i2c_detach_client(client);
-
-exit_kfree:
- kfree(pcf8563);
-
-exit:
- return err;
-}
-
-static int pcf8563_detach(struct i2c_client *client)
-{
- struct pcf8563 *pcf8563 = container_of(client, struct pcf8563, client);
- int err;
- struct rtc_device *rtc = i2c_get_clientdata(client);
-
- if (rtc)
- rtc_device_unregister(rtc);
-
- if ((err = i2c_detach_client(client)))
- return err;
-
- kfree(pcf8563);
-
- return 0;
}
static int __init pcf8563_init(void)
^ permalink raw reply related
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Jon Smirl @ 2007-11-13 23:53 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071113233906.GA32689@lixom.net>
On 11/13/07, Olof Johansson <olof@lixom.net> wrote:
> On Tue, Nov 13, 2007 at 03:23:29PM -0800, Dan Malek wrote:
> >
> > On Nov 13, 2007, at 1:59 PM, Grant Likely wrote:
> >
> > >> Abatron BDI-2000.
> > >
> > > Oops, but that's not all that cheap. ($2750USD).
> >
> > If you place any value on your time or development
> > schedule, it's a bargain.
>
> That only applies for cases where time means money, i.e. professional
> work. Spending three thousand dollars to debug a board that you spent
> a few hundred dollars buying just for a hobby is pretty crazy.
That's why Dominic wants to get OpenOCD running on the PowerPC. All we
need is the programming documentation for controlling the CPU via the
debug hardware.
Obviously this documentation exist, all of the commercial vendors had
to have it to develop their debuggers. Maybe it is already out there
and we just don't know where to look.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] powerpc: Add support for PORTA and PORTB odr registers
From: Scott Wood @ 2007-11-13 23:46 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: paulus, linux-kernel, linuxppc-embedded@ozlabs.org
In-Reply-To: <4739ECDA.4010200@scram.de>
Jochen Friedrich wrote:
> @@ -474,6 +481,12 @@ static void cpm1_set_pin16(int port, int pin, int
> flags)
> else
> clrbits16(&iop->par, pin);
>
> + if (port == CPM_PORTA) {
> + if (flags & CPM_PIN_OPENDRAIN)
> + setbits16(&iop->odr, pin);
> + else
> + clrbits16(&iop->odr, pin);
> + }
> if (port == CPM_PORTC) {
> if (flags & CPM_PIN_SECONDARY)
> setbits16(&iop->sor, pin);
Where is the odr field of cpm_ioport16 defined? It's the same position
as sor, so maybe call it odr_sor or something.
Also, please add an extra newline after the closing brace.
-Scott
^ permalink raw reply
* I2C on mpc8248 / device tree
From: Alan Bennett @ 2007-11-13 23:39 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]
I've got four devices on i2c that I need to read. Simple thermal and
voltage monitors. I2c works fine in uboot, and now I'm trying to get things
to work in linux.
In the kernel .config I enable
I2C
and
I2C_MPC
During the platform boot code:
I init the IO ports for i2c, (same as ep8248e code)
{3, 14, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
{3, 15, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
__Do I need to configure a brg for the i2c along with the other devices ?
i.e. cpm2_clk_setup ?
Next, I'm sure my device tree needs work, but my first stab adds i2c onto
the SOC @ 11860 (immr+11860= I2c mode register) and interrupt 1.
soc@e0000000 {
...
cpm@119c0 {
...
i2c@11860 {
device_type = "i2c";
compatible = "fsl-i2c";
reg = <11860 18>;
interrupts = <1 3>;
interrupt-parent = <&PIC>;
};
After Cleaning up these routines and descriptions, would I be expected to
continue using the /dev/i2c- entries?
-Alan
[-- Attachment #2: Type: text/html, Size: 2054 bytes --]
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Olof Johansson @ 2007-11-13 23:39 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <FA44C867-4933-40F2-8EBA-5C9967005223@embeddedalley.com>
On Tue, Nov 13, 2007 at 03:23:29PM -0800, Dan Malek wrote:
>
> On Nov 13, 2007, at 1:59 PM, Grant Likely wrote:
>
> >> Abatron BDI-2000.
> >
> > Oops, but that's not all that cheap. ($2750USD).
>
> If you place any value on your time or development
> schedule, it's a bargain.
That only applies for cases where time means money, i.e. professional
work. Spending three thousand dollars to debug a board that you spent
a few hundred dollars buying just for a hobby is pretty crazy.
-Olof
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Benjamin Herrenschmidt @ 2007-11-13 23:37 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071113220655.85840@gmx.net>
On Tue, 2007-11-13 at 23:06 +0100, Gerhard Pircher wrote:
> Well, I only disabled power saving with powersave=off. Are there any
> other
> ways to disable idle? What do you mean with instrumenting locks or
> irq enable/disable?
Add printk's to things :-) It's a UP kernel so there should be no
spinlocks anyway.
Best is to try to get a 100% reprocase and printk your way toward the
origin of the problem if you don't have a HW debugger. Unless you manage
to sneak in an irq to xmon but if you are totally locked up, you
probably can't.
Could also be something you do that your buggy northbridge doesn't like.
For example, maybe it dislikes M bit in the hash table and you end up
with it set due to other reasons (I know we had changes in this area).
> > Also, did you try booting with all kernel debug options enabled ?
> I compiled in almost all kernel debugging options and booted the
> kernel
> with driver_debug, initcall_debug and debug. I didn't notice any
> serious
> error messages so far. Not sure however, if I missed a debug option.
>
> > Finally, since the problem seem to have started around a specific
> kernel
> > version, can you try to bisect the patch that causes it ?
> Hmm, I'm not sure how to do this (only worked on platform code so
> far).
> I guess you think about checking out a kernel version from the git
> repository, which doesn't contain the patch for kernel_execve().
> I still suspect the kernel_execve() function (which was introduced in
> 2.6.17) because the kernel locks up after starting the first user
> program.
> AFAIK kernel threads should be running much earlier.
They are but they cause a lot less MMU pressure, could be an
indication...
Ben.
^ 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