* [PATCH 3/3] Support for PCI Express reset type
From: Mike Mason @ 2009-07-30 22:42 UTC (permalink / raw)
To: linuxppc-dev, linux-pci, linasvepstas, benh, Paul Mackerras; +Cc: Richard Lary
In-Reply-To: <4A722121.4010307@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 772 bytes --]
This is the third of three patches that implement a bit field that PCI Express device drivers can use to indicate they need a fundamental reset during error recovery.
By default, the EEH framework on powerpc does what's known as a "hot reset" during recovery of a PCI Express device. We've found a case where the device needs a "fundamental reset" to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction.
The attached patch makes changes to EEH to utilize the new bit field.
These patches supersede the previously submitted patch that implemented a fundamental reset bit field.
Please review and let me know of any concerns.
Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
Signed-off-by: Richard Lary <rlary@us.ibm.com>
[-- Attachment #2: eeh_fundamental_reset.patch --]
[-- Type: text/plain, Size: 1360 bytes --]
diff -uNrp a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
--- a/arch/powerpc/kernel/pci_64.c 2009-07-13 14:25:24.000000000 -0700
+++ b/arch/powerpc/kernel/pci_64.c 2009-07-15 10:26:26.000000000 -0700
@@ -143,6 +143,7 @@ struct pci_dev *of_create_pci_dev(struct
dev->dev.bus = &pci_bus_type;
dev->devfn = devfn;
dev->multifunction = 0; /* maybe a lie? */
+ dev->needs_freset = 0; /* pcie fundamental reset required */
dev->vendor = get_int_prop(node, "vendor-id", 0xffff);
dev->device = get_int_prop(node, "device-id", 0xffff);
diff -uNrp a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
--- a/arch/powerpc/platforms/pseries/eeh.c 2009-06-09 20:05:27.000000000 -0700
+++ b/arch/powerpc/platforms/pseries/eeh.c 2009-07-15 10:29:04.000000000 -0700
@@ -744,7 +744,15 @@ int pcibios_set_pcie_reset_state(struct
static void __rtas_set_slot_reset(struct pci_dn *pdn)
{
- rtas_pci_slot_reset (pdn, 1);
+ struct pci_dev *dev = pdn->pcidev;
+
+ /* Determine type of EEH reset required by device,
+ * default hot reset or fundamental reset
+ */
+ if (dev->needs_freset)
+ rtas_pci_slot_reset(pdn, 3);
+ else
+ rtas_pci_slot_reset(pdn, 1);
/* The PCI bus requires that the reset be held high for at least
* a 100 milliseconds. We wait a bit longer 'just in case'. */
^ permalink raw reply
* [PATCH 2/3] Support for PCI Express reset type
From: Mike Mason @ 2009-07-30 22:39 UTC (permalink / raw)
To: linuxppc-dev, linux-pci, linasvepstas, benh, Paul Mackerras; +Cc: Richard Lary
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]
This is the second of three patches that implement a bit field that PCI Express device drivers can use to indicate they need a fundamental reset during error recovery.
By default, the EEH framework on powerpc does what's known as a "hot reset" during recovery of a PCI Express device. We've found a case where the device needs a "fundamental reset" to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction.
The attached patch updates the Documentation/PCI/pci-error-recovery.txt file with changes related to this new bit field, as well a few unrelated updates.
These patches supersede the previously submitted patch that implemented a fundamental reset bit field.
Please review and let me know of any concerns.
Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
Signed-off-by: Richard Lary <rlary@us.ibm.com>
[-- Attachment #2: doc-pci-error-recovery.txt.patch --]
[-- Type: text/plain, Size: 11408 bytes --]
--- a/Documentation/PCI/pci-error-recovery.txt 2009-06-09 20:05:27.000000000 -0700
+++ b/Documentation/PCI/pci-error-recovery.txt 2009-07-30 13:57:15.000000000 -0700
@@ -4,15 +4,17 @@
February 2, 2006
Current document maintainer:
- Linas Vepstas <linas@austin.ibm.com>
+ Linas Vepstas <linasvepstas@gmail.com>
+ updated by Richard Lary <rlary@us.ibm.com>
+ and Mike Mason <mmlnx@us.ibm.com> on 27-Jul-2009
Many PCI bus controllers are able to detect a variety of hardware
PCI errors on the bus, such as parity errors on the data and address
busses, as well as SERR and PERR errors. Some of the more advanced
chipsets are able to deal with these errors; these include PCI-E chipsets,
-and the PCI-host bridges found on IBM Power4 and Power5-based pSeries
-boxes. A typical action taken is to disconnect the affected device,
+and the PCI-host bridges found on IBM Power4, Power5 and Power6-based
+pSeries boxes. A typical action taken is to disconnect the affected device,
halting all I/O to it. The goal of a disconnection is to avoid system
corruption; for example, to halt system memory corruption due to DMA's
to "wild" addresses. Typically, a reconnection mechanism is also
@@ -37,10 +39,11 @@ is forced by the need to handle multi-fu
devices that have multiple device drivers associated with them.
In the first stage, each driver is allowed to indicate what type
of reset it desires, the choices being a simple re-enabling of I/O
-or requesting a hard reset (a full electrical #RST of the PCI card).
-If any driver requests a full reset, that is what will be done.
+or requesting a slot reset.
-After a full reset and/or a re-enabling of I/O, all drivers are
+If any driver requests a slot reset, that is what will be done.
+
+After a reset and/or a re-enabling of I/O, all drivers are
again notified, so that they may then perform any device setup/config
that may be required. After these have all completed, a final
"resume normal operations" event is sent out.
@@ -101,7 +104,7 @@ if it implements any, it must implement
is not implemented, the corresponding feature is considered unsupported.
For example, if mmio_enabled() and resume() aren't there, then it
is assumed that the driver is not doing any direct recovery and requires
-a reset. If link_reset() is not implemented, the card is assumed as
+a slot reset. If link_reset() is not implemented, the card is assumed to
not care about link resets. Typically a driver will want to know about
a slot_reset().
@@ -111,7 +114,7 @@ sequence described below.
STEP 0: Error Event
-------------------
-PCI bus error is detect by the PCI hardware. On powerpc, the slot
+A PCI bus error is detected by the PCI hardware. On powerpc, the slot
is isolated, in that all I/O is blocked: all reads return 0xffffffff,
all writes are ignored.
@@ -139,7 +142,7 @@ The driver must return one of the follow
a chance to extract some diagnostic information (see
mmio_enable, below).
- PCI_ERS_RESULT_NEED_RESET:
- Driver returns this if it can't recover without a hard
+ Driver returns this if it can't recover without a
slot reset.
- PCI_ERS_RESULT_DISCONNECT:
Driver returns this if it doesn't want to recover at all.
@@ -169,11 +172,11 @@ is STEP 6 (Permanent Failure).
>>> The current powerpc implementation doesn't much care if the device
>>> attempts I/O at this point, or not. I/O's will fail, returning
->>> a value of 0xff on read, and writes will be dropped. If the device
->>> driver attempts more than 10K I/O's to a frozen adapter, it will
->>> assume that the device driver has gone into an infinite loop, and
->>> it will panic the kernel. There doesn't seem to be any other
->>> way of stopping a device driver that insists on spinning on I/O.
+>>> a value of 0xff on read, and writes will be dropped. If more than
+>>> EEH_MAX_FAILS I/O's are attempted to a frozen adapter, EEH
+>>> assumes that the device driver has gone into an infinite loop
+>>> and prints an error to syslog. A reboot is then required to
+>>> get the device working again.
STEP 2: MMIO Enabled
-------------------
@@ -182,15 +185,14 @@ DMA), and then calls the mmio_enabled()
device drivers.
This is the "early recovery" call. IOs are allowed again, but DMA is
-not (hrm... to be discussed, I prefer not), with some restrictions. This
-is NOT a callback for the driver to start operations again, only to
-peek/poke at the device, extract diagnostic information, if any, and
-eventually do things like trigger a device local reset or some such,
-but not restart operations. This is callback is made if all drivers on
-a segment agree that they can try to recover and if no automatic link reset
-was performed by the HW. If the platform can't just re-enable IOs without
-a slot reset or a link reset, it wont call this callback, and instead
-will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset)
+not, with some restrictions. This is NOT a callback for the driver to
+start operations again, only to peek/poke at the device, extract diagnostic
+information, if any, and eventually do things like trigger a device local
+reset or some such, but not restart operations. This callback is made if
+all drivers on a segment agree that they can try to recover and if no automatic
+link reset was performed by the HW. If the platform can't just re-enable IOs
+without a slot reset or a link reset, it will not call this callback, and
+instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset)
>>> The following is proposed; no platform implements this yet:
>>> Proposal: All I/O's should be done _synchronously_ from within
@@ -228,9 +230,6 @@ proceeds to either STEP3 (Link Reset) or
If any driver returned PCI_ERS_RESULT_NEED_RESET, then the platform
proceeds to STEP 4 (Slot Reset)
->>> The current powerpc implementation does not implement this callback.
-
-
STEP 3: Link Reset
------------------
The platform resets the link, and then calls the link_reset() callback
@@ -253,16 +252,33 @@ The platform then proceeds to either STE
>>> The current powerpc implementation does not implement this callback.
-
STEP 4: Slot Reset
------------------
-The platform performs a soft or hard reset of the device, and then
-calls the slot_reset() callback.
-A soft reset consists of asserting the adapter #RST line and then
+In response to a return value of PCI_ERS_RESULT_NEED_RESET, the
+the platform will peform a slot reset on the requesting PCI device(s).
+The actual steps taken by a platform to perform a slot reset
+will be platform-dependent. Upon completion of slot reset, the
+platform will call the device slot_reset() callback.
+
+Powerpc platforms implement two levels of slot reset:
+soft reset(default) and fundamental(optional) reset.
+
+Powerpc soft reset consists of asserting the adapter #RST line and then
restoring the PCI BAR's and PCI configuration header to a state
that is equivalent to what it would be after a fresh system
power-on followed by power-on BIOS/system firmware initialization.
+Soft reset is also known as hot-reset.
+
+Powerpc fundamental reset is supported by PCI Express cards only
+and results in device's state machines, hardware logic, port states and
+configuration registers to initialize to their default conditions.
+
+For most PCI devices, a soft reset will be sufficient for recovery.
+Optional fundamental reset is provided to support a limited number
+of PCI Express PCI devices for which a soft reset is not sufficient
+for recovery.
+
If the platform supports PCI hotplug, then the reset might be
performed by toggling the slot electrical power off/on.
@@ -274,10 +290,12 @@ may result in hung devices, kernel panic
This call gives drivers the chance to re-initialize the hardware
(re-download firmware, etc.). At this point, the driver may assume
-that he card is in a fresh state and is fully functional. In
-particular, interrupt generation should work normally.
+that the card is in a fresh state and is fully functional. The slot
+is unfrozen and the driver has full access to PCI config space,
+memory mapped I/O space and DMA. Interrupts (Legacy, MSI, or MSI-X)
+will also be available.
-Drivers should not yet restart normal I/O processing operations
+Drivers should not restart normal I/O processing operations
at this point. If all device drivers report success on this
callback, the platform will call resume() to complete the sequence,
and let the driver restart normal I/O processing.
@@ -302,11 +320,21 @@ driver performs device init only from PC
- PCI_ERS_RESULT_DISCONNECT
Same as above.
+Drivers for PCI Express cards that require a fundamental reset must
+set the needs_freset bit in the pci_dev structure in their probe function.
+For example, the QLogic qla2xxx driver sets the needs_freset bit for certain
+PCI card types:
+
++ /* Set EEH reset type to fundamental if required by hba */
++ if (IS_QLA24XX(ha) || IS_QLA25XX(ha) || IS_QLA81XX(ha))
++ pdev->needs_freset = 1;
++
+
Platform proceeds either to STEP 5 (Resume Operations) or STEP 6 (Permanent
Failure).
->>> The current powerpc implementation does not currently try a
->>> power-cycle reset if the driver returned PCI_ERS_RESULT_DISCONNECT.
+>>> The current powerpc implementation does not try a power-cycle
+>>> reset if the driver returned PCI_ERS_RESULT_DISCONNECT.
>>> However, it probably should.
@@ -348,7 +376,7 @@ software errors.
Conclusion; General Remarks
---------------------------
-The way those callbacks are called is platform policy. A platform with
+The way the callbacks are called is platform policy. A platform with
no slot reset capability may want to just "ignore" drivers that can't
recover (disconnect them) and try to let other cards on the same segment
recover. Keep in mind that in most real life cases, though, there will
@@ -361,8 +389,8 @@ That is, the recovery API only requires
- There is no guarantee that interrupt delivery can proceed from any
device on the segment starting from the error detection and until the
-resume callback is sent, at which point interrupts are expected to be
-fully operational.
+slot_reset callback is called, at which point interrupts are expected
+to be fully operational.
- There is no guarantee that interrupt delivery is stopped, that is,
a driver that gets an interrupt after detecting an error, or that detects
@@ -381,16 +409,23 @@ anyway :)
>>> Implementation details for the powerpc platform are discussed in
>>> the file Documentation/powerpc/eeh-pci-error-recovery.txt
->>> As of this writing, there are six device drivers with patches
->>> implementing error recovery. Not all of these patches are in
+>>> As of this writing, there is a growing list of device drivers with
+>>> patches implementing error recovery. Not all of these patches are in
>>> mainline yet. These may be used as "examples":
>>>
->>> drivers/scsi/ipr.c
->>> drivers/scsi/sym53cxx_2
+>>> drivers/scsi/ipr
+>>> drivers/scsi/sym53c8xx_2
+>>> drivers/scsi/qla2xxx
+>>> drivers/scsi/lpfc
+>>> drivers/next/bnx2.c
>>> drivers/next/e100.c
>>> drivers/net/e1000
+>>> drivers/net/e1000e
>>> drivers/net/ixgb
+>>> drivers/net/ixgbe
+>>> drivers/net/cxgb3
>>> drivers/net/s2io.c
+>>> drivers/net/qlge
The End
-------
^ permalink raw reply
* [PATCH 1/3] Support for PCI Express reset type
From: Mike Mason @ 2009-07-30 22:33 UTC (permalink / raw)
To: linuxppc-dev, linux-pci, linasvepstas, benh, Paul Mackerras; +Cc: Richard Lary
[-- Attachment #1: Type: text/plain, Size: 859 bytes --]
This is the first of three patches that implement a bit field that PCI Express device drivers can use to indicate they need a fundamental reset during error recovery.
By default, the EEH framework on powerpc does what's known as a "hot reset" during recovery of a PCI Express device. We've found a case where the device needs a "fundamental reset" to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction.
The attached patch (courtesy of Richard Lary) adds a bit field to pci_dev that indicates whether the device requires a fundamental reset during recovery.
These patches supersede the previously submitted patch that implemented a fundamental reset bit field.
Please review and let me know of any concerns.
Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
Signed-off-by: Richard Lary <rlary@us.ibm.com>
[-- Attachment #2: pci_fundamental_reset.patch --]
[-- Type: text/plain, Size: 490 bytes --]
diff -uNrp a/include/linux/pci.h b/include/linux/pci.h
--- a/include/linux/pci.h 2009-07-13 14:25:37.000000000 -0700
+++ b/include/linux/pci.h 2009-07-15 10:25:37.000000000 -0700
@@ -273,6 +273,7 @@ struct pci_dev {
unsigned int ari_enabled:1; /* ARI forwarding */
unsigned int is_managed:1;
unsigned int is_pcie:1;
+ unsigned int needs_freset:1; /* Dev requires fundamental reset */
unsigned int state_saved:1;
unsigned int is_physfn:1;
unsigned int is_virtfn:1;
^ permalink raw reply
* Re: [PATCH] gianfar: fix coalescing setup in ethtool support
From: David Miller @ 2009-07-30 21:21 UTC (permalink / raw)
To: leoli; +Cc: netdev, b06378, linuxppc-dev
In-Reply-To: <1248857517-8270-1-git-send-email-leoli@freescale.com>
From: Li Yang <leoli@freescale.com>
Date: Wed, 29 Jul 2009 16:51:57 +0800
> Parameter order for using mk_ic_value(count, time) was reversed,
> the patch fixes this.
>
> Signed-off-by: Jiajun Wu <b06378@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC
From: Josh Boyer @ 2009-07-30 20:08 UTC (permalink / raw)
To: Solomon Peachy; +Cc: linuxppc-dev
In-Reply-To: <20090730194506.GA30066@linux-wlan.com>
On Thu, Jul 30, 2009 at 03:45:06PM -0400, Solomon Peachy wrote:
>On Thu, Jul 30, 2009 at 10:06:30AM -0400, Josh Boyer wrote:
>> >+ devp = finddevice("/plb/opb/serial@ef600300");
>> >+ if (!devp)
>> >+ fatal("Can't find node for /plb/opb/serial@ef600300");
>> >+ del_node(devp);
>>
>> Slightly confused here. You delete the first serial node in the single eth
>> case?
>
>The board is actually single eth/serial or dual eth/serial. And strictly
>speaking, this serial port is the second one in the devicetree...
Maybe a brief comment in the code explaining that would help. Also, I did
notice the DTS had them in the order you mention, and I forgot to come back
and correct my question there.
>> >+
>> >+ devp = finddevice("/plb/opb/ethernet@ef600900");
>> >+ if (!devp)
>> >+ fatal("Can't find node for /plb/opb/ethernet@ef600900");
>> >+ del_node(devp);
>> >+ }
>> >+
>> >+ ibm4xx_quiesce_eth((u32 *)0xef600800, (u32 *)0xef600900);
>>
>> Shouldn't you do the quiesce conditionally if the other eth port doesn't
>> exist?
>
>I don't know if this is strictly necessary with the modern ibm_emac
>driver, but it's certainly safe to call because all 405EPs have dual
>ethernet controllers.
>
>From the (pre-dts) driver perspecive, the only way to tell if the
>hotfoot had one ethernet port or two was that the second PHY failed to
>initialize.
>
>Additionally, the production bootloader (u-boot 1.2.0.x) isn't terribly
>smart and tries to drive the second controller if the first one doesn't
>have a cable plugged in, so it's possible the second controller is
>running when control is handed over to Linux, even on single ethernet
>boards.
OK, that makes sense.
>
>> >+ UART0: serial@ef600400 {
>> >+ device_type = "serial";
>> >+ compatible = "ns16550";
>> >+ reg = <0xef600400 0x00000008>;
>> >+ virtual-reg = <0xef600400>;
>> >+ clock-frequency = <0>; /* Filled in by zImage */
>> >+ current-speed = <0x9600>;
>>
>> Just a question, but is the baud supposed to be 38400 or 9600? At first glance
>> it almost seems like a typo :).
>
>It's supposed to be 38400 baud, hence the explicit 0x in front. (I lost
>count of the number of times I saw '38400' listed in various dts
>files...)
Cool. Just checking.
>> >+ gpio-leds {
>> >+ compatible = "gpio-leds";
>> >+ status {
>> >+ label = "Status";
>> >+ gpios = <&GPIO 1 0>;
>> >+ /* linux,default=trigger = ".."; */
>> >+ };
>>
>> What does that comment mean?
>
>Whoops, it's supposed to read 'linux,default-trigger', but the LEDs are
>manually twiddled for the time being. I'd forgotten to strip that out.
>
>(see linux/Documentation/powerpc/dts-bindings/gpio/led.txt)
OK. If it's not needed just yank it.
>
>> Ok. So I'm not really all that thrilled with changes to ppcboot.h.
>> We try to keep this file as much in-sync with U-Boot as we can. Did
>> your HOTFOOT changes get pulled into upstream U-Boot?
>
>Yeah, I thought this may be a problem, but I didn't know a better way to
>go about this and still maintain compatibility with the many thousands
>of boards already in the field. I mean, I could strip out the ppcboot.h
>changes and maintain that as an out-of-tree patch, but without that
>patch, the kernel won't boot on in-the-field boards, rendering the
>upstreaming of support for this board kinda pointless.
>
>I haven't tried to push anything to upstream u-boot, given how ancient
>the in-production bootloader is. The guy who originally mangled u-boot
>for this board did so before the "standard" 405EP dual ethernet layout
>was added, and never tried to push it upstream. Any upstream uboot work
>will take the form of a native dts/fdt port that probably won't use
>ppcboot.h anyway, which brings us full circle...
There is another way. Perhaps you could just copy ppcboot.h to a new file
called "hotfoot.h" and just use that. It's a duplication of ppcboot.h to
some degree, but it seems to make sense for your board and it helps preserve
the "stock" ppcboot.h for other boards.
josh
^ permalink raw reply
* Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC
From: Solomon Peachy @ 2009-07-30 19:45 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20090730140630.GD10244@zod.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3996 bytes --]
On Thu, Jul 30, 2009 at 10:06:30AM -0400, Josh Boyer wrote:
> >+ devp = finddevice("/plb/opb/serial@ef600300");
> >+ if (!devp)
> >+ fatal("Can't find node for /plb/opb/serial@ef600300");
> >+ del_node(devp);
>
> Slightly confused here. You delete the first serial node in the single eth
> case?
The board is actually single eth/serial or dual eth/serial. And strictly
speaking, this serial port is the second one in the devicetree...
(The PPC405EP's serial boards aren't created equally; the first is a
dumb tx/rx-only port while the second has a full set of signals.
The hotfoot is wired such that the second, full-featured port is the
primary/console/boot port)
> >+
> >+ devp = finddevice("/plb/opb/ethernet@ef600900");
> >+ if (!devp)
> >+ fatal("Can't find node for /plb/opb/ethernet@ef600900");
> >+ del_node(devp);
> >+ }
> >+
> >+ ibm4xx_quiesce_eth((u32 *)0xef600800, (u32 *)0xef600900);
>
> Shouldn't you do the quiesce conditionally if the other eth port doesn't
> exist?
I don't know if this is strictly necessary with the modern ibm_emac
driver, but it's certainly safe to call because all 405EPs have dual
ethernet controllers.
From the (pre-dts) driver perspecive, the only way to tell if the
hotfoot had one ethernet port or two was that the second PHY failed to
initialize.
Additionally, the production bootloader (u-boot 1.2.0.x) isn't terribly
smart and tries to drive the second controller if the first one doesn't
have a cable plugged in, so it's possible the second controller is
running when control is handed over to Linux, even on single ethernet
boards.
> >+ UART0: serial@ef600400 {
> >+ device_type = "serial";
> >+ compatible = "ns16550";
> >+ reg = <0xef600400 0x00000008>;
> >+ virtual-reg = <0xef600400>;
> >+ clock-frequency = <0>; /* Filled in by zImage */
> >+ current-speed = <0x9600>;
>
> Just a question, but is the baud supposed to be 38400 or 9600? At first glance
> it almost seems like a typo :).
It's supposed to be 38400 baud, hence the explicit 0x in front. (I lost
count of the number of times I saw '38400' listed in various dts
files...)
> >+ gpio-leds {
> >+ compatible = "gpio-leds";
> >+ status {
> >+ label = "Status";
> >+ gpios = <&GPIO 1 0>;
> >+ /* linux,default=trigger = ".."; */
> >+ };
>
> What does that comment mean?
Whoops, it's supposed to read 'linux,default-trigger', but the LEDs are
manually twiddled for the time being. I'd forgotten to strip that out.
(see linux/Documentation/powerpc/dts-bindings/gpio/led.txt)
> Ok. So I'm not really all that thrilled with changes to ppcboot.h.
> We try to keep this file as much in-sync with U-Boot as we can. Did
> your HOTFOOT changes get pulled into upstream U-Boot?
Yeah, I thought this may be a problem, but I didn't know a better way to
go about this and still maintain compatibility with the many thousands
of boards already in the field. I mean, I could strip out the ppcboot.h
changes and maintain that as an out-of-tree patch, but without that
patch, the kernel won't boot on in-the-field boards, rendering the
upstreaming of support for this board kinda pointless.
I haven't tried to push anything to upstream u-boot, given how ancient
the in-production bootloader is. The guy who originally mangled u-boot
for this board did so before the "standard" 405EP dual ethernet layout
was added, and never tried to push it upstream. Any upstream uboot work
will take the form of a native dts/fdt port that probably won't use
ppcboot.h anyway, which brings us full circle...
- Solomon
--
Solomon Peachy solomon@linux-wlan.com
AbsoluteValue Systems http://www.linux-wlan.com
721-D North Drive +1 (321) 259-0737 (office)
Melbourne, FL 32934 +1 (321) 259-0286 (fax)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: fsldma patches?
From: Dan Williams @ 2009-07-30 17:41 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev Development, Ira W. Snyder
In-Reply-To: <97CDF92A-2FAF-445D-B5B0-1D06884F8259@freescale.com>
Kumar Gala wrote:
> Dan,
>
> What happened with the set of patches that Ira posted for fsldma?
I have just sent a pull request with the pending backlog of dmaengine
fixes. Our discussion of the fsldma slave implementation did not
conclude in time for me to get a pull request out before the close of
the 2.6.31 merge window. I have queued it up for 2.6.32.
--
Dan
^ permalink raw reply
* Re: can the kernel show user task stack backtrace ?
From: Nicholas Mc Guire @ 2009-07-30 16:55 UTC (permalink / raw)
To: Alessandro Rubini; +Cc: linuxppc-dev, nvbolhuis
In-Reply-To: <20090730161941.GA14988@mail.gnudd.com>
On Thu, 30 Jul 2009, Alessandro Rubini wrote:
> > We're dealing with some complex (3rd party) applications and I like to see a
> > user task stack backtrace.
> >
> > (Of course the way to go here is to use a debugger (gdb) and
> > do a backtrace (with the coredump file).
>
> Actually, you can intercept SIGSEGV and print your own stack from within
> the signal handler. You can also open /proc/self/maps and print it, to
> ease understanding the various pointers in there, especially if the
> application is using a number of shared libs.
>
> This is usually easier than getting to a core dump, although there is
> less information than what the core offers.
>
> I have the code for ARM and I've it on ppc once, but I must dig for the actual
> code.
>
I think libSegFault.so (part of glibc) can do that by simply preloading it
LD_PRELOAD=/lib/libSegFault.so ./your_segfaulting_app
should do the trick.
hofrat
^ permalink raw reply
* Re: can the kernel show user task stack backtrace ?
From: Alessandro Rubini @ 2009-07-30 16:19 UTC (permalink / raw)
To: nvbolhuis; +Cc: linuxppc-dev
In-Reply-To: <4A71C04E.6060506@aimvalley.nl>
> We're dealing with some complex (3rd party) applications and I like to see a
> user task stack backtrace.
>
> (Of course the way to go here is to use a debugger (gdb) and
> do a backtrace (with the coredump file).
Actually, you can intercept SIGSEGV and print your own stack from within
the signal handler. You can also open /proc/self/maps and print it, to
ease understanding the various pointers in there, especially if the
application is using a number of shared libs.
This is usually easier than getting to a core dump, although there is
less information than what the core offers.
I have the code for ARM and I've it on ppc once, but I must dig for the actual
code.
/alessandro
^ permalink raw reply
* [PATCH] powerpc: missing tests after ioremap()?
From: Roel Kluin @ 2009-07-30 16:02 UTC (permalink / raw)
To: benh, linuxppc-dev, Andrew Morton
Missing tests after ioremap()
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Shouldn't we test whether ioremaps fail?
diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
index e6c0040..3a4ebd3 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -2589,9 +2589,16 @@ static void __init probe_uninorth(void)
if (address == 0)
return;
uninorth_base = ioremap(address, 0x40000);
+ if (uninorth_base == NULL)
+ return;
uninorth_rev = in_be32(UN_REG(UNI_N_VERSION));
- if (uninorth_maj == 3 || uninorth_maj == 4)
+ if (uninorth_maj == 3 || uninorth_maj == 4) {
u3_ht_base = ioremap(address + U3_HT_CONFIG_BASE, 0x1000);
+ if (u3_ht_base == NULL) {
+ iounmap(uninorth_base);
+ return;
+ }
+ }
printk(KERN_INFO "Found %s memory controller & host bridge"
" @ 0x%08x revision: 0x%02x\n", uninorth_maj == 3 ? "U3" :
^ permalink raw reply related
* can the kernel show user task stack backtrace ?
From: Norbert van Bolhuis @ 2009-07-30 15:46 UTC (permalink / raw)
To: linuxppc-dev
Afaik the kernel only shows the stack backtrace of the kernel stack
(of a task).
I wonder if there would be anything wrong with letting it show
the user task stack backtrace in certain cases.
Read the rest to see what I mean.
If kernel.print-fatal-signals has been enabled a crashing
application makes the kernel show this:
ca2/943: potentially unexpected fatal signal 11.
NIP: 1000044c LR: 10000444 CTR: 00000000
REGS: ce73df50 TRAP: 0300 Not tainted (2.6.28)
MSR: 0000d032 <EE,PR,ME,IR,DR> CR: 22000422 XER: 20000000
DAR: d0000003, DSISR: 22000000
TASK = ceb7a3e0[943] 'ca2' THREAD: ce73c000
GPR00: 0000000e bf963b30 48025450 0000000a 0ff0ac2c 22000422 00000001 0ff5e6b0
GPR08: 00000001 d0000003 00001032 00000000 ffffffff 1001896c 0ffe9000 00000000
GPR16: 0ffca59c 00000000 1009b940 100a8b6a 100bf234 bfea22b8 100bf224 00000000
GPR24: 100bf008 1009b960 4801e858 4802dd34 4802e7e0 00000000 0ffec8d8 bf963b30
Call Trace:
Segmentation fault
#
It's a real pity the user task stack backtrace isn't shown.
We're dealing with some complex (3rd party) applications and I like to see a
user task stack backtrace.
(Of course the way to go here is to use a debugger (gdb) and
do a backtrace (with the coredump file).
However, debugging takes some time. Besides the info is there
it only needs to be shown. Often just this info is enough to
pinpoint the problem)
Obviously the arch/powerpc/kernel/process.c:show_stack function
isn't meant for doing this. It only shows the kernel stack.
Btw. this doesn't work in my case since validate_sp returns 0 (because
sp is assigned the user-space stack (bf963b30) while kernel stack starts at ce73c000).
Though if it would work it isn't very usefull I guess since the crashing app
not enters kernel-mode (via sys-calls).
If I change arch/powerpc/kernel/process.c:show_stack (of kernel 2.6.28) like this:
do {
#if 0
if (!validate_sp(sp, tsk, STACK_FRAME_OVERHEAD))
return;
#endif
.
.
.
} while ((count++ < kstack_depth_to_print) && (sp != 0));
the following is shown:
ca2/943: potentially unexpected fatal signal 11.
NIP: 1000044c LR: 10000444 CTR: c001fd7c
REGS: ce73df50 TRAP: 0300 Not tainted (2.6.28)
MSR: 0000f932 <EE,PR,FP,ME,IR,DR> CR: 22000422 XER: 20000000
DAR: d0000003, DSISR: 22000000
TASK = cf09b340[943] 'ca2' THREAD: ce73c000
GPR00: 0000000e bfd65b30 48025450 0000000a 0ff0ac2c 22000422 00000001 0ff5e6b0
GPR08: 00000001 d0000003 00001032 00000000 ffffffff 1001896c 0ffe9000 00000000
GPR16: 0ffca59c 00000000 1009b940 100a8b6a 100bf234 bfb532b8 100bf224 00000000
GPR24: 100bf008 1009b960 4801e858 4802dd34 4802e7e0 00000000 0ffec8d8 bfd65b30
Call Trace:
[bfd65b30] [10000444] 0x10000444 (unreliable)
[bfd65b60] [10000490] 0x10000490
[bfd65b90] [100004cc] 0x100004cc
[bfd65ba0] [0feb39c8] 0xfeb39c8
[bfd65dd0] [0feb3ad4] 0xfeb3ad4
[bfd65de0] [00000000] 0x000000
Segmentation fault
#
which is what I want.
^ permalink raw reply
* Re: [PATCH 5/5] sound/aoa: Add kmalloc NULL tests
From: Johannes Berg @ 2009-07-30 14:17 UTC (permalink / raw)
To: Julia Lawall; +Cc: linuxppc-dev, alsa-devel, kernel-janitors, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0907301610550.8734@ask.diku.dk>
[-- Attachment #1: Type: text/plain, Size: 578 bytes --]
On Thu, 2009-07-30 at 16:11 +0200, Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> Check that the result of kzalloc is not NULL before a dereference.
> irq_client = kzalloc(sizeof(struct pmf_irq_client),
> GFP_KERNEL);
> + if (!irq_client) {
> + err = -ENOMEM;
> + printk(KERN_ERR "snd-aoa: gpio layer failed to"
> + " register %s irq (%d)\n", name, err);
> + goto out_unlock;
> + }
Looks good, thanks, but I'd really drop the printk if only to not have
the string there, that doesn't really seem interesting.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Help, please... Multi-Media Distro for PPC?
From: skateaboard @ 2009-07-30 14:33 UTC (permalink / raw)
To: linuxppc-dev
Ok so I'm really new to this but a single line answer will do, like "One of
the best and noob friendly PPC Multi media distributors would be _________."
What I have:
A PPC ibook G3 laptop
What I need help with:
Finding a linux based multi-media workstation
Why:
I really want to become more savvy with linux and I need this element added
to my physical studio's repertoire. My artist studio needs a computer
workstation and linux seems the best way for me to go.
Specifically:
I've been searching around the web for a while now and have not yet found a
PPC optimized(or even kind-of) distro for a multi-media studio for PPC based
macs. I need some sort of:
-image, video, audio editing and layering software package.
So, Does this even exist? I've seen "Umbutu Studio"; that seems to do the
job, however I've read that it would not work with my hardware, true? or is
there a similar type package for PPC?
Thank you all so much and any input is much appreciated!
-Andrew
--
View this message in context: http://www.nabble.com/Help%2C-please...-Multi-Media-Distro-for-PPC--tp24628615p24628615.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 5/5] sound/aoa: Add kmalloc NULL tests
From: Julia Lawall @ 2009-07-30 14:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel, kernel-janitors, linux-kernel
In-Reply-To: <1248963420.16129.0.camel@johannes.local>
On Thu, 30 Jul 2009, Johannes Berg wrote:
> On Thu, 2009-07-30 at 16:11 +0200, Julia Lawall wrote:
> > From: Julia Lawall <julia@diku.dk>
> >
> > Check that the result of kzalloc is not NULL before a dereference.
>
> > irq_client = kzalloc(sizeof(struct pmf_irq_client),
> > GFP_KERNEL);
> > + if (!irq_client) {
> > + err = -ENOMEM;
> > + printk(KERN_ERR "snd-aoa: gpio layer failed to"
> > + " register %s irq (%d)\n", name, err);
> > + goto out_unlock;
> > + }
>
> Looks good, thanks, but I'd really drop the printk if only to not have
> the string there, that doesn't really seem interesting.
The printk is based on similar error handling code a few lines later:
if (err) {
printk(KERN_ERR "snd-aoa: gpio layer failed to"
" register %s irq (%d)\n", name,
err);
kfree(irq_client);
goto out_unlock;
}
Should the printk be removed in this case as well? Or is it ok to fail
silently in one case and not in the other?
julia
^ permalink raw reply
* [PATCH 5/5] sound/aoa: Add kmalloc NULL tests
From: Julia Lawall @ 2009-07-30 14:11 UTC (permalink / raw)
To: johannes, linuxppc-dev, alsa-devel, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Check that the result of kzalloc is not NULL before a dereference.
The semantic match that finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
expression *x;
identifier f;
constant char *C;
@@
x = \(kmalloc\|kcalloc\|kzalloc\)(...);
... when != x == NULL
when != x != NULL
when != (x || ...)
(
kfree(x)
|
f(...,C,...,x,...)
|
*f(...,x,...)
|
*x->f
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
sound/aoa/core/gpio-pmf.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/sound/aoa/core/gpio-pmf.c b/sound/aoa/core/gpio-pmf.c
index 5ca2220..b4439ce 100644
--- a/sound/aoa/core/gpio-pmf.c
+++ b/sound/aoa/core/gpio-pmf.c
@@ -182,6 +182,12 @@ static int pmf_set_notify(struct gpio_runtime *rt,
if (!old && notify) {
irq_client = kzalloc(sizeof(struct pmf_irq_client),
GFP_KERNEL);
+ if (!irq_client) {
+ err = -ENOMEM;
+ printk(KERN_ERR "snd-aoa: gpio layer failed to"
+ " register %s irq (%d)\n", name, err);
+ goto out_unlock;
+ }
irq_client->data = notif;
irq_client->handler = pmf_handle_notify_irq;
irq_client->owner = THIS_MODULE;
^ permalink raw reply related
* Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC
From: Josh Boyer @ 2009-07-30 14:06 UTC (permalink / raw)
To: Solomon Peachy; +Cc: linuxppc-dev
In-Reply-To: <1248448916-29473-1-git-send-email-solomon@linux-wlan.com>
On Fri, Jul 24, 2009 at 11:21:56AM -0400, Solomon Peachy wrote:
>This patch adds support for the ESTeem 195E Hotfoot SBC.
>I've been maintaining this out-of-tree for some time now for
>older kernels, but recently I ported it to the new unified powerpc
>tree with the intent of pushing it upstream.
>
>The 195E boards use ancient versions of u-boot and a slightly mangled
>verison of the oft-abused ppcboot header.
>
>There are several variants of the SBC deployed, single/dual
>ethernet+serial, and also 4MB/8MB flash variations. In the interest of
>having a single kernel image boot on all boards, the cuboot shim detects
>the differences and mangles the DTS tree appropriately.
>
>With the exception of the CF interface that was never populated on
>production boards, this code/DTS supports all boardpop options.
>
>Signed-off-by: Solomon Peachy <solomon@linux-wlan.com>
Overall, really nice. Just a few questions below.
>--- linux-2.6.30/arch/powerpc/boot/cuboot-hotfoot.c 1969-12-31 19:00:00.000000000 -0500
>+++ linux-2.6.30.hotfoot/arch/powerpc/boot/cuboot-hotfoot.c 2009-07-07 12:55:23.000000000 -0400
>@@ -0,0 +1,142 @@
>+/*
>+ * Old U-boot compatibility for Esteem 195E Hotfoot CPU Board
>+ *
>+ * Author: Solomon Peachy <solomon@linux-wlan.com>
>+ *
>+ * This program is free software; you can redistribute it and/or modify it
>+ * under the terms of the GNU General Public License version 2 as published
>+ * by the Free Software Foundation.
>+ */
>+
>+#include "ops.h"
>+#include "stdio.h"
>+#include "reg.h"
>+#include "dcr.h"
>+#include "4xx.h"
>+#include "cuboot.h"
>+
>+#define TARGET_4xx
>+#define TARGET_HOTFOOT
>
>+#include "ppcboot.h"
>+
>+static bd_t bd;
>+
>+#define NUM_REGS 3
>+
>+static void hotfoot_fixups(void)
>+{
>+ u32 uart = mfdcr(DCRN_CPC0_UCR) & 0x7f;
>+
>+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
>+
>+ dt_fixup_cpu_clocks(bd.bi_procfreq, bd.bi_procfreq, 0);
>+ dt_fixup_clock("/plb", bd.bi_plb_busfreq);
>+ dt_fixup_clock("/plb/opb", bd.bi_opbfreq);
>+ dt_fixup_clock("/plb/ebc", bd.bi_pci_busfreq);
>+ dt_fixup_clock("/plb/opb/serial@ef600300", bd.bi_procfreq / uart);
>+ dt_fixup_clock("/plb/opb/serial@ef600400", bd.bi_procfreq / uart);
>+
>+ dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
>+ dt_fixup_mac_address_by_alias("ethernet1", bd.bi_enet1addr);
>+
>+ /* Is this a single eth/serial board? */
>+ if ((bd.bi_enet1addr[0] == 0) &&
>+ (bd.bi_enet1addr[1] == 0) &&
>+ (bd.bi_enet1addr[2] == 0) &&
>+ (bd.bi_enet1addr[3] == 0) &&
>+ (bd.bi_enet1addr[4] == 0) &&
>+ (bd.bi_enet1addr[5] == 0)) {
>+ void *devp;
>+
>+ printf("Trimming devtree for single eth board\n");
>+
>+ devp = finddevice("/plb/opb/serial@ef600300");
>+ if (!devp)
>+ fatal("Can't find node for /plb/opb/serial@ef600300");
>+ del_node(devp);
Slightly confused here. You delete the first serial node in the single eth
case?
>+
>+ devp = finddevice("/plb/opb/ethernet@ef600900");
>+ if (!devp)
>+ fatal("Can't find node for /plb/opb/ethernet@ef600900");
>+ del_node(devp);
>+ }
>+
>+ ibm4xx_quiesce_eth((u32 *)0xef600800, (u32 *)0xef600900);
Shouldn't you do the quiesce conditionally if the other eth port doesn't
exist?
>+
>+ /* Fix up flash size in fdt for 4M boards. */
>+ if (bd.bi_flashsize < 0x800000) {
>+ u32 regs[NUM_REGS];
>+ void *devp = finddevice("/plb/ebc/nor_flash@0");
>+ if (!devp)
>+ fatal("Can't find FDT node for nor_flash!??");
>+
>+ printf("Fixing devtree for 4M Flash\n");
>+
>+ /* First fix up the base addresse */
>+ getprop(devp, "reg", regs, sizeof(regs));
>+ regs[0] = 0;
>+ regs[1] = 0xffc00000;
>+ regs[2] = 0x00400000;
>+ setprop(devp, "reg", regs, sizeof(regs));
>+
>+ /* Then the offsets */
>+ devp = finddevice("/plb/ebc/nor_flash@0/partition@0");
>+ if (!devp)
>+ fatal("Can't find FDT node for partition@0");
>+ getprop(devp, "reg", regs, 2*sizeof(u32));
>+ regs[0] -= 0x400000;
>+ setprop(devp, "reg", regs, 2*sizeof(u32));
>+
>+ devp = finddevice("/plb/ebc/nor_flash@0/partition@1");
>+ if (!devp)
>+ fatal("Can't find FDT node for partition@1");
>+ getprop(devp, "reg", regs, 2*sizeof(u32));
>+ regs[0] -= 0x400000;
>+ setprop(devp, "reg", regs, 2*sizeof(u32));
>+
>+ devp = finddevice("/plb/ebc/nor_flash@0/partition@2");
>+ if (!devp)
>+ fatal("Can't find FDT node for partition@2");
>+ getprop(devp, "reg", regs, 2*sizeof(u32));
>+ regs[0] -= 0x400000;
>+ setprop(devp, "reg", regs, 2*sizeof(u32));
>+
>+ devp = finddevice("/plb/ebc/nor_flash@0/partition@3");
>+ if (!devp)
>+ fatal("Can't find FDT node for partition@3");
>+ getprop(devp, "reg", regs, 2*sizeof(u32));
>+ regs[0] -= 0x400000;
>+ setprop(devp, "reg", regs, 2*sizeof(u32));
>+
>+ devp = finddevice("/plb/ebc/nor_flash@0/partition@4");
>+ if (!devp)
>+ fatal("Can't find FDT node for partition@4");
>+ getprop(devp, "reg", regs, 2*sizeof(u32));
>+ regs[0] -= 0x400000;
>+ setprop(devp, "reg", regs, 2*sizeof(u32));
>+
>+ devp = finddevice("/plb/ebc/nor_flash@0/partition@6");
>+ if (!devp)
>+ fatal("Can't find FDT node for partition@6");
>+ getprop(devp, "reg", regs, 2*sizeof(u32));
>+ regs[0] -= 0x400000;
>+ setprop(devp, "reg", regs, 2*sizeof(u32));
>+
>+ /* Delete the FeatFS node */
>+ devp = finddevice("/plb/ebc/nor_flash@0/partition@5");
>+ if (!devp)
>+ fatal("Can't find FDT node for partition@5");
>+ del_node(devp);
>+ }
>+}
>+
>+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
>+ unsigned long r6, unsigned long r7)
>+{
>+ CUBOOT_INIT();
>+ platform_ops.fixups = hotfoot_fixups;
>+ platform_ops.exit = ibm40x_dbcr_reset;
>+ fdt_init(_dtb_start);
>+ serial_console_init();
>+}
>diff -Naur linux-2.6.30/arch/powerpc/boot/dts/hotfoot.dts linux-2.6.30.hotfoot/arch/powerpc/boot/dts/hotfoot.dts
>--- linux-2.6.30/arch/powerpc/boot/dts/hotfoot.dts 1969-12-31 19:00:00.000000000 -0500
>+++ linux-2.6.30.hotfoot/arch/powerpc/boot/dts/hotfoot.dts 2009-07-07 12:55:23.000000000 -0400
>@@ -0,0 +1,299 @@
>+/*
>+ * Device Tree Source for ESTeem 195E Hotfoot
>+ *
>+ * Copyright 2009 AbsoluteValue Systems <solomon@linux-wlan.com>
>+ *
>+ * This file is licensed under the terms of the GNU General Public
>+ * License version 2. This program is licensed "as is" without
>+ * any warranty of any kind, whether express or implied.
>+ */
>+
>+/dts-v1/;
>+
>+/ {
>+ #address-cells = <1>;
>+ #size-cells = <1>;
>+ model = "est,hotfoot";
>+ compatible = "est,hotfoot";
>+ dcr-parent = <&{/cpus/cpu@0}>;
>+
>+ aliases {
>+ ethernet0 = &EMAC0;
>+ ethernet1 = &EMAC1;
>+ serial0 = &UART0;
>+ serial1 = &UART1;
>+ };
>+
>+ cpus {
>+ #address-cells = <1>;
>+ #size-cells = <0>;
>+
>+ cpu@0 {
>+ device_type = "cpu";
>+ model = "PowerPC,405EP";
>+ reg = <0x00000000>;
>+ clock-frequency = <0>; /* Filled in by zImage */
>+ timebase-frequency = <0>; /* Filled in by zImage */
>+ i-cache-line-size = <0x20>;
>+ d-cache-line-size = <0x20>;
>+ i-cache-size = <0x4000>;
>+ d-cache-size = <0x4000>;
>+ dcr-controller;
>+ dcr-access-method = "native";
>+ };
>+ };
>+
>+ memory {
>+ device_type = "memory";
>+ reg = <0x00000000 0x00000000>; /* Filled in by zImage */
>+ };
>+
>+ UIC0: interrupt-controller {
>+ compatible = "ibm,uic";
>+ interrupt-controller;
>+ cell-index = <0>;
>+ dcr-reg = <0x0c0 0x009>;
>+ #address-cells = <0>;
>+ #size-cells = <0>;
>+ #interrupt-cells = <2>;
>+ };
>+
>+ plb {
>+ compatible = "ibm,plb3";
>+ #address-cells = <1>;
>+ #size-cells = <1>;
>+ ranges;
>+ clock-frequency = <0>; /* Filled in by zImage */
>+
>+ SDRAM0: memory-controller {
>+ compatible = "ibm,sdram-405ep";
>+ dcr-reg = <0x010 0x002>;
>+ };
>+
>+ MAL: mcmal {
>+ compatible = "ibm,mcmal-405ep", "ibm,mcmal";
>+ dcr-reg = <0x180 0x062>;
>+ num-tx-chans = <4>;
>+ num-rx-chans = <2>;
>+ interrupt-parent = <&UIC0>;
>+ interrupts = <
>+ 0xb 0x4 /* TXEOB */
>+ 0xc 0x4 /* RXEOB */
>+ 0xa 0x4 /* SERR */
>+ 0xd 0x4 /* TXDE */
>+ 0xe 0x4 /* RXDE */>;
>+ };
>+
>+ POB0: opb {
>+ compatible = "ibm,opb-405ep", "ibm,opb";
>+ #address-cells = <1>;
>+ #size-cells = <1>;
>+ ranges = <0xef600000 0xef600000 0x00a00000>;
>+ dcr-reg = <0x0a0 0x005>;
>+ clock-frequency = <0>; /* Filled in by zImage */
>+
>+ /* Hotfoot has UART0/UART1 swapped */
>+
>+ UART0: serial@ef600400 {
>+ device_type = "serial";
>+ compatible = "ns16550";
>+ reg = <0xef600400 0x00000008>;
>+ virtual-reg = <0xef600400>;
>+ clock-frequency = <0>; /* Filled in by zImage */
>+ current-speed = <0x9600>;
Just a question, but is the baud supposed to be 38400 or 9600? At first glance
it almost seems like a typo :).
>+ interrupt-parent = <&UIC0>;
>+ interrupts = <0x1 0x4>;
>+ };
>+
>+ UART1: serial@ef600300 {
>+ device_type = "serial";
>+ compatible = "ns16550";
>+ reg = <0xef600300 0x00000008>;
>+ virtual-reg = <0xef600300>;
>+ clock-frequency = <0>; /* Filled in by zImage */
>+ current-speed = <0x9600>;
>+ interrupt-parent = <&UIC0>;
>+ interrupts = <0x0 0x4>;
>+ };
>+
>+
>+ IIC: i2c@ef600500 {
>+ compatible = "ibm,iic-405ep", "ibm,iic";
>+ reg = <0xef600500 0x00000011>;
>+ interrupt-parent = <&UIC0>;
>+ interrupts = <0x2 0x4>;
>+
>+ rtc@68 {
>+ /* Actually a DS1339 */
>+ compatible = "dallas,ds1307";
>+ reg = <0x68>;
>+ };
>+
>+ temp@4a {
>+ /* Not present on all boards */
>+ compatible = "national,lm75";
>+ reg = <0x4a>;
>+ };
>+ };
>+
>+ GPIO: gpio@ef600700 {
>+ #gpio-cells = <2>;
>+ compatible = "ibm,ppc4xx-gpio";
>+ reg = <0xef600700 0x00000020>;
>+ gpio-controller;
>+ };
>+
>+ gpio-leds {
>+ compatible = "gpio-leds";
>+ status {
>+ label = "Status";
>+ gpios = <&GPIO 1 0>;
>+ /* linux,default=trigger = ".."; */
What does that comment mean?
>+ };
>+ radiorx {
>+ label = "Rx";
>+ gpios = <&GPIO 0xe 0>;
>+ /* linux,default=trigger = ".."; */
>+ };
>+ };
>+
<snip>
>diff -Naur linux-2.6.30/arch/powerpc/boot/ppcboot.h linux-2.6.30.hotfoot/arch/powerpc/boot/ppcboot.h
>--- linux-2.6.30/arch/powerpc/boot/ppcboot.h 2009-06-09 23:05:27.000000000 -0400
>+++ linux-2.6.30.hotfoot/arch/powerpc/boot/ppcboot.h 2009-07-07 12:55:18.000000000 -0400
>@@ -52,6 +52,11 @@
> unsigned long bi_bootflags; /* boot / reboot flag (for LynxOS) */
> unsigned long bi_ip_addr; /* IP Address */
> unsigned char bi_enetaddr[6]; /* Ethernet address */
>+#if defined(TARGET_HOTFOOT)
>+ /* second onboard ethernet port */
>+ unsigned char bi_enet1addr[6];
>+#define HAVE_ENET1ADDR
>+#endif /* TARGET_HOOTFOOT */
> unsigned short bi_ethspeed; /* Ethernet speed in Mbps */
> unsigned long bi_intfreq; /* Internal Freq, in MHz */
> unsigned long bi_busfreq; /* Bus Freq, in MHz */
>@@ -74,6 +79,9 @@
> unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
> unsigned char bi_pci_enetaddr[6]; /* PCI Ethernet MAC address */
> #endif
>+#if defined(TARGET_HOTFOOT)
>+ unsigned int bi_pllouta_freq; /* PLL OUTA speed, in Hz */
>+#endif
> #if defined(TARGET_HYMOD)
> hymod_conf_t bi_hymod_conf; /* hymod configuration information */
> #endif
>@@ -94,6 +102,10 @@
> unsigned char bi_enet3addr[6];
> #define HAVE_ENET3ADDR
> #endif
>+#if defined(TARGET_HOTFOOT)
>+ int bi_phynum[2]; /* Determines phy mapping */
>+ int bi_phymode[2]; /* Determines phy mode */
>+#endif
> #if defined(TARGET_4xx)
> unsigned int bi_opbfreq; /* OB clock in Hz */
> int bi_iic_fast[2]; /* Use fast i2c mode */
Ok. So I'm not really all that thrilled with changes to ppcboot.h. We try to
keep this file as much in-sync with U-Boot as we can. Did your HOTFOOT changes
get pulled into upstream U-Boot?
josh
^ permalink raw reply
* Re: [PATCH][sata_fsl] Defer non-ncq commands when ncq commands active
From: Kumar Gala @ 2009-07-30 14:02 UTC (permalink / raw)
To: Kalra Ashish-B00888; +Cc: linuxppc-dev, linux-ide, Robert Hancock
In-Reply-To: <16444A0F3094A24C83EAB7836A12C63B032E5C@zin33exm20.fsl.freescale.net>
On Jul 30, 2009, at 8:58 AM, Kalra Ashish-B00888 wrote:
> Hello Kumar,
>
> >> > This doesn't look like it should change anything. sata_fsl_ops
> >> inherits
> >> > from sata_pmp_port_ops, which inherits from sata_port_ops, which
> >> already
> >> > sets qc_defer to ata_std_qc_defer.
> >> Oh, yes. Actually this patch was for older kernels where there
> >> inheritence was not there. As you mentioned, this patch is not
> >> required now.
> >>
> >How old? Should we be asking for this to be applied to some of the
> >stable kernel series?
>
> I believe that the inheritence stuff was added in 2.6.26, thus, this
> patch is
> required for quite old kernels ( < 2.6.26 ).
Ok, than I'm not going to worry about it.
- k
^ permalink raw reply
* RE: [PATCH][sata_fsl] Defer non-ncq commands when ncq commands active
From: Kalra Ashish-B00888 @ 2009-07-30 13:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-ide, Robert Hancock
In-Reply-To: <E8D39D04-E4B6-4420-AD54-6A95BE35EB30@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]
Hello Kumar,
>> > This doesn't look like it should change anything. sata_fsl_ops
>> inherits
>> > from sata_pmp_port_ops, which inherits from sata_port_ops, which
>> already
>> > sets qc_defer to ata_std_qc_defer.
>> Oh, yes. Actually this patch was for older kernels where there
>> inheritence was not there. As you mentioned, this patch is not
>> required now.
>>
>How old? Should we be asking for this to be applied to some of the
>stable kernel series?
I believe that the inheritence stuff was added in 2.6.26, thus, this patch is
required for quite old kernels ( < 2.6.26 ).
Thanks,
Ashish
[-- Attachment #2: Type: text/html, Size: 1246 bytes --]
^ permalink raw reply
* Re: [PATCH][sata_fsl] Defer non-ncq commands when ncq commands active
From: Kumar Gala @ 2009-07-30 13:43 UTC (permalink / raw)
To: Kalra Ashish-B00888; +Cc: linuxppc-dev, linux-ide, Robert Hancock
In-Reply-To: <16444A0F3094A24C83EAB7836A12C63B032E5A@zin33exm20.fsl.freescale.net>
On Jul 30, 2009, at 8:23 AM, Kalra Ashish-B00888 wrote:
> Hello,
>
> >> Signed-off-by: Ashish Kalra <Ashish.Kalra@freescale.com>
> >> ---
> >> drivers/ata/sata_fsl.c | 1 +
> >> 1 files changed, 1 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
> >> index 5a88b44..a33f130 100644
> >> --- a/drivers/ata/sata_fsl.c
> >> +++ b/drivers/ata/sata_fsl.c
> >> @@ -1262,6 +1262,7 @@ static struct scsi_host_template
> sata_fsl_sht = {
> >> static struct ata_port_operations sata_fsl_ops = {
> >> .inherits = &sata_pmp_port_ops,
> >>
> >> + .qc_defer = ata_std_qc_defer;
> >> .qc_prep = sata_fsl_qc_prep,
> >> .qc_issue = sata_fsl_qc_issue,
> >> .qc_fill_rtf = sata_fsl_qc_fill_rtf,
>
> > This doesn't look like it should change anything. sata_fsl_ops
> inherits
> > from sata_pmp_port_ops, which inherits from sata_port_ops, which
> already
> > sets qc_defer to ata_std_qc_defer.
> Oh, yes. Actually this patch was for older kernels where there
> inheritence was not there. As you mentioned, this patch is not
> required now.
>
How old? Should we be asking for this to be applied to some of the
stable kernel series?
- k
^ permalink raw reply
* RE: [PATCH][sata_fsl] Defer non-ncq commands when ncq commands active
From: Kalra Ashish-B00888 @ 2009-07-30 13:23 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <4A70A78D.7070601@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]
Hello,
>> Signed-off-by: Ashish Kalra <Ashish.Kalra@freescale.com>
>> ---
>> drivers/ata/sata_fsl.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
>> index 5a88b44..a33f130 100644
>> --- a/drivers/ata/sata_fsl.c
>> +++ b/drivers/ata/sata_fsl.c
>> @@ -1262,6 +1262,7 @@ static struct scsi_host_template sata_fsl_sht = {
>> static struct ata_port_operations sata_fsl_ops = {
>> .inherits = &sata_pmp_port_ops,
>>
>> + .qc_defer = ata_std_qc_defer;
>> .qc_prep = sata_fsl_qc_prep,
>> .qc_issue = sata_fsl_qc_issue,
>> .qc_fill_rtf = sata_fsl_qc_fill_rtf,
> This doesn't look like it should change anything. sata_fsl_ops inherits
> from sata_pmp_port_ops, which inherits from sata_port_ops, which already
> sets qc_defer to ata_std_qc_defer.
Oh, yes. Actually this patch was for older kernels where there inheritence was not there. As you mentioned, this patch is not required now.
Thanks,
Ashish
[-- Attachment #2: Type: text/html, Size: 1698 bytes --]
^ permalink raw reply
* Re: Next July 29 : Hugetlb test failure (OOPS free_hugepte_range)
From: Benjamin Herrenschmidt @ 2009-07-30 12:30 UTC (permalink / raw)
To: Sachin Sant; +Cc: Stephen Rothwell, linux-next, linuxppc-dev
In-Reply-To: <4A719129.5030302@in.ibm.com>
On Thu, 2009-07-30 at 17:55 +0530, Sachin Sant wrote:
> Sachin Sant wrote:
> > next-20090728 worked fine. Last commit that changed
> > arch/powerpc/mm/hugetlbpage.c was
> > cb7f3f2d92d1b26c13e30e639b6ee4a78e9a3afa
> >
> > powerpc: Add memory management headers for new 64-bit BookE
> >
> > I will try reverting that commit and check if that helps.
> Hi Ben,
>
> Reverting the above patch helped. The tests ran fine against the
> patched kernel. But ofcourse that's not the solution :-)
>
> Here is some data from xmon that might help find the reason for
> the failure. This is with today's next.
Thanks. I'll have a look next week. I think when I changed the indices
I may have forgotten to update something.
Cheers,
Ben.
> : ------------[ cut here ]------------
> cpu 0x0: Vector: 700 (Program Check) at [c000000038923560]
> pc: c0000000000486d4: .free_hugepte_range+0x68/0xa0
> lr: c000000000048954: .hugetlb_free_pgd_range+0x248/0x38c
> sp: c0000000389237e0
> msr: 8000000000029032
> current = 0xc00000003b1d7780
> paca = 0xc000000001002400
> pid = 2839, comm = readback
> kernel BUG at /home/linux-2.6.31-rc4/arch/powerpc/include/asm/pgalloc.h:36!
> enter ? for help
> [c000000038923880] c000000000048954 .hugetlb_free_pgd_range+0x248/0x38c
> [c000000038923970] c000000000165a48 .free_pgtables+0xa0/0x154
> [c000000038923a30] c000000000167f78 .exit_mmap+0x13c/0x1cc
> [c000000038923ae0] c0000000000997ec .mmput+0x68/0x14c
> [c000000038923b70] c00000000009f1d4 .exit_mm+0x190/0x1b8
> [c000000038923c20] c0000000000a16e8 .do_exit+0x214/0x784
> [c000000038923d00] c0000000000a1d1c .do_group_exit+0xc4/0xf8
> [c000000038923da0] c0000000000a1d7c .SyS_exit_group+0x2c/0x48
> [c000000038923e30] c0000000000085b4 syscall_exit+0x0/0x40
> --- Exception: c01 (System Call) at 000000000fe15038
> SP (ffb8e030) is in userspace
> 0:mon> e
> cpu 0x0: Vector: 700 (Program Check) at [c000000038923560]
> pc: c0000000000486d4: .free_hugepte_range+0x68/0xa0
> lr: c000000000048954: .hugetlb_free_pgd_range+0x248/0x38c
> sp: c0000000389237e0
> msr: 8000000000029032
> current = 0xc00000003b1d7780
> paca = 0xc000000001002400
> pid = 2839, comm = readback
> kernel BUG at /home/linux-2.6.31-rc4/arch/powerpc/include/asm/pgalloc.h:36!
> 0:mon> r
> R00 = 0000000000000001 R16 = 0000000000000000
> R01 = c0000000389237e0 R17 = 0000000000000001
> R02 = c000000000f165a8 R18 = 000000003fffffff
> R03 = c0000000014504d0 R19 = 0000000000000000
> R04 = c000000039390001 R20 = 0000000000000000
> R05 = 0000000000000007 R21 = 0000010000000000
> R06 = 0000000000000000 R22 = 0000000040000000
> R07 = 0000000040000000 R23 = c0000000014504d0
> R08 = c00000003d708188 R24 = 000000003fffffff
> R09 = c00000003eb40000 R25 = 0000000000000007
> R10 = c00000003d708188 R26 = c00000003ebd41b8
> R11 = 0000000000000018 R27 = c0000000014504d0
> R12 = 0000000040000448 R28 = c00000003eb40018
> R13 = c000000001002400 R29 = 0000000000000008
> R14 = 00000000ffffffff R30 = 0000000040000000
> R15 = 00000000ffffffff R31 = c0000000389237e0
> pc = c0000000000486d4 .free_hugepte_range+0x68/0xa0
> lr = c000000000048954 .hugetlb_free_pgd_range+0x248/0x38c
> msr = 8000000000029032 cr = 20042444
> ctr = 800000000000b6f4 xer = 0000000000000001 trap = 700
> 0:mon>
>
> Line 36 of arch/powerpc/include/asm/pgalloc.h corresponds to
>
> BUG_ON(cachenum > PGF_CACHENUM_MASK);
>
> May be something to do with number of elements in huge_pgtable_cache_name ??
>
> Thanks
> -Sachin
>
^ permalink raw reply
* Re: Next July 29 : Hugetlb test failure (OOPS free_hugepte_range)
From: Sachin Sant @ 2009-07-30 12:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Stephen Rothwell, linux-next, linuxppc-dev
In-Reply-To: <4A706504.6040704@in.ibm.com>
Sachin Sant wrote:
> next-20090728 worked fine. Last commit that changed
> arch/powerpc/mm/hugetlbpage.c was
> cb7f3f2d92d1b26c13e30e639b6ee4a78e9a3afa
>
> powerpc: Add memory management headers for new 64-bit BookE
>
> I will try reverting that commit and check if that helps.
Hi Ben,
Reverting the above patch helped. The tests ran fine against the
patched kernel. But ofcourse that's not the solution :-)
Here is some data from xmon that might help find the reason for
the failure. This is with today's next.
: ------------[ cut here ]------------
cpu 0x0: Vector: 700 (Program Check) at [c000000038923560]
pc: c0000000000486d4: .free_hugepte_range+0x68/0xa0
lr: c000000000048954: .hugetlb_free_pgd_range+0x248/0x38c
sp: c0000000389237e0
msr: 8000000000029032
current = 0xc00000003b1d7780
paca = 0xc000000001002400
pid = 2839, comm = readback
kernel BUG at /home/linux-2.6.31-rc4/arch/powerpc/include/asm/pgalloc.h:36!
enter ? for help
[c000000038923880] c000000000048954 .hugetlb_free_pgd_range+0x248/0x38c
[c000000038923970] c000000000165a48 .free_pgtables+0xa0/0x154
[c000000038923a30] c000000000167f78 .exit_mmap+0x13c/0x1cc
[c000000038923ae0] c0000000000997ec .mmput+0x68/0x14c
[c000000038923b70] c00000000009f1d4 .exit_mm+0x190/0x1b8
[c000000038923c20] c0000000000a16e8 .do_exit+0x214/0x784
[c000000038923d00] c0000000000a1d1c .do_group_exit+0xc4/0xf8
[c000000038923da0] c0000000000a1d7c .SyS_exit_group+0x2c/0x48
[c000000038923e30] c0000000000085b4 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000000000fe15038
SP (ffb8e030) is in userspace
0:mon> e
cpu 0x0: Vector: 700 (Program Check) at [c000000038923560]
pc: c0000000000486d4: .free_hugepte_range+0x68/0xa0
lr: c000000000048954: .hugetlb_free_pgd_range+0x248/0x38c
sp: c0000000389237e0
msr: 8000000000029032
current = 0xc00000003b1d7780
paca = 0xc000000001002400
pid = 2839, comm = readback
kernel BUG at /home/linux-2.6.31-rc4/arch/powerpc/include/asm/pgalloc.h:36!
0:mon> r
R00 = 0000000000000001 R16 = 0000000000000000
R01 = c0000000389237e0 R17 = 0000000000000001
R02 = c000000000f165a8 R18 = 000000003fffffff
R03 = c0000000014504d0 R19 = 0000000000000000
R04 = c000000039390001 R20 = 0000000000000000
R05 = 0000000000000007 R21 = 0000010000000000
R06 = 0000000000000000 R22 = 0000000040000000
R07 = 0000000040000000 R23 = c0000000014504d0
R08 = c00000003d708188 R24 = 000000003fffffff
R09 = c00000003eb40000 R25 = 0000000000000007
R10 = c00000003d708188 R26 = c00000003ebd41b8
R11 = 0000000000000018 R27 = c0000000014504d0
R12 = 0000000040000448 R28 = c00000003eb40018
R13 = c000000001002400 R29 = 0000000000000008
R14 = 00000000ffffffff R30 = 0000000040000000
R15 = 00000000ffffffff R31 = c0000000389237e0
pc = c0000000000486d4 .free_hugepte_range+0x68/0xa0
lr = c000000000048954 .hugetlb_free_pgd_range+0x248/0x38c
msr = 8000000000029032 cr = 20042444
ctr = 800000000000b6f4 xer = 0000000000000001 trap = 700
0:mon>
Line 36 of arch/powerpc/include/asm/pgalloc.h corresponds to
BUG_ON(cachenum > PGF_CACHENUM_MASK);
May be something to do with number of elements in huge_pgtable_cache_name ??
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-07-30 11:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here's a bunch of defconfig updates for freescale embedded platforms
along with a handful of fixes for those from Kumar, and one important
one liner fix for a thinko/typo by myself in the embedded CPU context
management code on SMP.
The following changes since commit 658874f05d040ca96eb5ba9b1c30ce0ff287d762:
Linus Torvalds (1):
Merge branch 'i2c-fixes-rc4' of git://aeryn.fluff.org.uk/bjdooks/linux
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Anton Vorontsov (3):
powerpc/85xx: Fix ethernet link detection on MPC8569E-MDS boards
powerpc/85xx: Don't scan for TBI PHY addresses on MPC8569E-MDS boards
powerpc/83xx: Fix PCI IO base address on MPC837xE-RDB boards
Kumar Gala (2):
powerpc/mm: Fix SMP issue with MMU context handling code
powerpc: Update defconfigs for embedded 6xx/7xxx, 8xx, 8{3,5,6}xxx
Mark Ware (1):
cpm_uart: Don't use alloc_bootmem in cpm_uart_cpm2.c
Martyn Welch (2):
powerpc/86xx: Update defconfig for GE Fanuc's PPC9A
powerpc/86xx: Update GE Fanuc sbc310 default configuration
arch/powerpc/boot/dts/mpc8377_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8378_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8379_rdb.dts | 2 +-
arch/powerpc/boot/dts/mpc8569mds.dts | 4 +
arch/powerpc/configs/83xx/asp8347_defconfig | 106 +++--
arch/powerpc/configs/83xx/kmeter1_defconfig | 176 +++++---
arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 168 +++++--
arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 168 +++++--
arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 111 +++--
arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 120 +++--
arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 114 +++--
arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 114 +++--
arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 104 +++--
arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 111 +++--
arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 104 +++--
arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 110 +++--
arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 162 +++++---
arch/powerpc/configs/83xx/sbc834x_defconfig | 103 +++--
arch/powerpc/configs/85xx/ksi8560_defconfig | 93 +++--
arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 91 +++--
arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 99 +++--
arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 99 +++--
arch/powerpc/configs/85xx/sbc8548_defconfig | 96 +++--
arch/powerpc/configs/85xx/sbc8560_defconfig | 91 +++--
arch/powerpc/configs/85xx/socrates_defconfig | 165 +++++---
arch/powerpc/configs/85xx/stx_gp3_defconfig | 119 +++--
arch/powerpc/configs/85xx/tqm8540_defconfig | 100 +++--
arch/powerpc/configs/85xx/tqm8541_defconfig | 101 +++--
arch/powerpc/configs/85xx/tqm8548_defconfig | 100 +++--
arch/powerpc/configs/85xx/tqm8555_defconfig | 101 +++--
arch/powerpc/configs/85xx/tqm8560_defconfig | 101 +++--
arch/powerpc/configs/85xx/xes_mpc85xx_defconfig | 118 +++--
arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 521 ++++++++-------------
arch/powerpc/configs/86xx/gef_sbc310_defconfig | 216 +++++++---
arch/powerpc/configs/86xx/gef_sbc610_defconfig | 130 ++++--
arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig | 118 +++--
arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig | 186 ++++----
arch/powerpc/configs/86xx/sbc8641d_defconfig | 112 +++--
arch/powerpc/configs/adder875_defconfig | 97 +++--
arch/powerpc/configs/c2k_defconfig | 121 +++--
arch/powerpc/configs/ep8248e_defconfig | 97 +++--
arch/powerpc/configs/ep88xc_defconfig | 91 +++--
arch/powerpc/configs/linkstation_defconfig | 116 +++--
arch/powerpc/configs/mgcoge_defconfig | 97 +++--
arch/powerpc/configs/mgsuvd_defconfig | 89 ++--
arch/powerpc/configs/mpc7448_hpc2_defconfig | 103 +++--
arch/powerpc/configs/mpc8272_ads_defconfig | 104 +++--
arch/powerpc/configs/mpc83xx_defconfig | 162 +++++---
arch/powerpc/configs/mpc85xx_defconfig | 193 ++++----
arch/powerpc/configs/mpc85xx_smp_defconfig | 193 ++++----
arch/powerpc/configs/mpc866_ads_defconfig | 92 ++--
arch/powerpc/configs/mpc86xx_defconfig | 186 ++++----
arch/powerpc/configs/mpc885_ads_defconfig | 91 +++--
arch/powerpc/configs/pq2fads_defconfig | 110 +++--
arch/powerpc/configs/prpmc2800_defconfig | 158 +++++--
arch/powerpc/configs/storcenter_defconfig | 108 +++--
arch/powerpc/mm/mmu_context_nohash.c | 1 +
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 13 +
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 2 +-
59 files changed, 4007 insertions(+), 2755 deletions(-)
^ permalink raw reply
* [PATCH v2] powerpc/86xx: Update GE Fanuc sbc310 DTS
From: Martyn Welch @ 2009-07-30 8:13 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
Update GE Fanuc DTS to match the alterations suggested during the merge of
the ppc9a DTS in commit 740d36ae6344f38c4da64c2ede765d7d2dd1f132
Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
---
v2: Fixed run on message.
Kumar: I think the problem may be that this patch depends on a previous patch:
http://patchwork.ozlabs.org/patch/29335/
Martyn
arch/powerpc/boot/dts/gef_sbc310.dts | 29 +++++++++++++----------------
1 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc310.dts b/arch/powerpc/boot/dts/gef_sbc310.dts
index 7810ea9..2107d3c 100644
--- a/arch/powerpc/boot/dts/gef_sbc310.dts
+++ b/arch/powerpc/boot/dts/gef_sbc310.dts
@@ -83,34 +83,34 @@
/* flash@0,0 is a mirror of part of the memory in flash@1,0
flash@0,0 {
- compatible = "cfi-flash";
- reg = <0 0 0x01000000>;
+ compatible = "gef,sbc310-firmware-mirror", "cfi-flash";
+ reg = <0x0 0x0 0x01000000>;
bank-width = <2>;
device-width = <2>;
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "firmware";
- reg = <0x00000000 0x01000000>;
+ reg = <0x0 0x01000000>;
read-only;
};
};
*/
flash@1,0 {
- compatible = "cfi-flash";
- reg = <1 0 0x8000000>;
+ compatible = "gef,sbc310-paged-flash", "cfi-flash";
+ reg = <0x1 0x0 0x8000000>;
bank-width = <2>;
device-width = <2>;
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "user";
- reg = <0x00000000 0x07800000>;
+ reg = <0x0 0x7800000>;
};
partition@7800000 {
label = "firmware";
- reg = <0x07800000 0x00800000>;
+ reg = <0x7800000 0x800000>;
read-only;
};
};
@@ -121,18 +121,16 @@
};
wdt@4,2000 {
- #interrupt-cells = <2>;
- device_type = "watchdog";
- compatible = "gef,fpga-wdt";
+ compatible = "gef,sbc310-fpga-wdt", "gef,fpga-wdt-1.00",
+ "gef,fpga-wdt";
reg = <0x4 0x2000 0x8>;
interrupts = <0x1a 0x4>;
interrupt-parent = <&gef_pic>;
};
/*
wdt@4,2010 {
- #interrupt-cells = <2>;
- device_type = "watchdog";
- compatible = "gef,fpga-wdt";
+ compatible = "gef,sbc310-fpga-wdt", "gef,fpga-wdt-1.00",
+ "gef,fpga-wdt";
reg = <0x4 0x2010 0x8>;
interrupts = <0x1b 0x4>;
interrupt-parent = <&gef_pic>;
@@ -141,7 +139,7 @@
gef_pic: pic@4,4000 {
#interrupt-cells = <1>;
interrupt-controller;
- compatible = "gef,fpga-pic";
+ compatible = "gef,sbc310-fpga-pic", "gef,fpga-pic";
reg = <0x4 0x4000 0x20>;
interrupts = <0x8
0x9>;
@@ -161,7 +159,7 @@
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "soc";
- compatible = "simple-bus";
+ compatible = "fsl,mpc8641-soc", "simple-bus";
ranges = <0x0 0xfef00000 0x00100000>;
bus-frequency = <33333333>;
@@ -412,5 +410,4 @@
0x0 0x00400000>;
};
};
-
};
^ permalink raw reply related
* Re: 82xx, mgcoge: updates for 2.6.32
From: Heiko Schocher @ 2009-07-30 5:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <820BFB98-F940-4B5C-8D4A-9C069B3DC199@kernel.crashing.org>
Hello Kumar,
Kumar Gala wrote:
>
> On Jul 29, 2009, at 3:32 AM, Heiko Schocher wrote:
>
>> - add I2C support
>> - add FCC1 and FCC2 support
>> - fix bogus gpio numbering in plattformcode
>>
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>> ---
>> - based on git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
>> next branch
>> - checked with checkpatch.pl:
>> $ ./scripts/checkpatch.pl 0001-82xx-mgcoge-updates-for-2.6.32.patch
>> total: 0 errors, 0 warnings, 531 lines checked
>>
>> 0001-82xx-mgcoge-updates-for-2.6.32.patch has no obvious style
>> problems and is ready for submission.
>> $
>>
>> BTW: Who is PPC82XX Maintainer? I couldn;t find such an entry
>> in the MAINTAINERS file ...
>
> its me.
Ah, thought it, but I wasn;t sure ... Hmm, maybe you can update
the MAINTAINERS entry?
>> arch/powerpc/boot/dts/mgcoge.dts | 56 ++++++++++
>> arch/powerpc/configs/mgcoge_defconfig | 178
>> +++++++++++++++++++++++++-------
>
> Can we hold off or pull the defconfig update into a separate patch. I
> normally update defconfigs in a late -rc series and that will probably
> generate merge conflicts.
I make a seperate patch for the defconfig.
Thanks. I wait for more comments, before I post the next version
of this patch.
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ 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