* mpc5200 linux 2.4 wakeup interrupt problem
From: RonLee @ 2007-04-20 22:07 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am running linux on a mpc5200 chip and Im having problems with the
mpc5200's simple and wakeup interrupts. The version of Linux I am starting
with is linuxppc_2_4_devel_1_0_0 from Denx. Modifications have been made to
the kernel, but none for enabling the wakeup register set and/or the wakeup
interrupts.
Does a patch exist to enable this behavior? Can anyone point me in the
right direction if I would like to enable the wakeup interrupts myself?
I noticed the behavior when attempting to write a device driver to interface
with the psc1_4 pin on the mpc5200 chip. I am able to get the chip to
generate interrupts, but when the interrupts occur I get the following error
message in /proc/kmsg "Unhandled interrupt c, disabled". After getting this
error, I installed an interrupt handler on IRQ 12 (hex c). This caused the
kernel to lock up.
Thanks for any help,
-Ron
--
View this message in context: http://www.nabble.com/mpc5200-linux-2.4-wakeup-interrupt-problem-tf3620873.html#a10111122
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/4 v3] powerpc: document interface-type property
From: Andy Fleming @ 2007-04-20 21:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <B0B16FB3-62D7-434B-9135-E87D2AFFFF07@kernel.crashing.org>
On Apr 20, 2007, at 15:57, Kumar Gala wrote:
>
> On Apr 20, 2007, at 3:11 PM, Kim Phillips wrote:
>
>> Since ucc_geth is being migrated to use the phylib, the existing
>> (undocumented) 'interface' property is being deprecated in favour
>> of a stringified version, 'interface-type'.
>>
>> interface-type is maintained one-to-one with definitions
>> in include/linux/phy.h. If not specified, "mii" is assumed.
>>
>> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
>> ---
>> removed max-speed property, since the name is apparently too generic
>> (it's derived from the interface-type anyway)
>
> Are you sure? Is not possible to use a gmii phy on a 8323 and limit
> it to 10/100?
Ahem. Just to maintain this point: It's not a GMII PHY. It would be
a PHY that supports the GMII interface. In this case, we would
specify that the controller is connecting to its PHY over interface-
type "mii". The real issue (right now) would be an RGMII or SGMII
connection for a non-gigabit controller.
However, the UCC doesn't currently support SGMII, and there aren't
any implementations that have non-gigabit RGMII connections.
In other words, this could become an issue in the future, but we're
punting on pushing through a specifier for that situation until it
comes up.
Andy
^ permalink raw reply
* Re: Kernel Panic booting cdrom
From: David Huffman @ 2007-04-20 21:05 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev
In-Reply-To: <20070417054537.GF6062@localdomain>
Nathan,
I think I determined why I received a kernel panic and the numa=off
argument fixed the problem. When we boot from cdrom we specify maxcpus=1
as a kernel argument. A system with numa enabled fails. I plan on
adding numa=off whenever I use maxcpus=1, but I wonder if you could
answer a question for me.
I originally was told that in the case where I am booting a basic system
into an initrd instead of in normal mode, I should use maxcpus=1 because
there may be power and cooling daemons that are not running and try to
limit the system resources by limiting the number of cpus. Does this
sound right? I can successfully boot a cdrom without the maxcpus flag on
an SMP system but maybe it is typically not a good idea?
I can prevent the kernel panics by removing maxcpus=1 and not adding
numa=off. I am a little more informed about numa (now), but I am fuzzy
as to all the implications with allowing more cpus for cdrom install
media. The maxcpus=1 argument was something we added to our install boot
media years ago and few here remember why it was such a great idea. The
power/resource management was the only thing we could come up with.
David Huffman
Storix, Inc
Nathan Lynch wrote:
> David Huffman wrote:
>
>> Nathan,
>>
>> Thank you very much for the info. This worked to get the system booted
>> from cdrom. However, in normal mode, the numa=off argument is not in the
>> yaboo.conf file. Any idea why it works without it in normal mode, but
>> requires numa=off when using the same kernel and booting from cdrom?
>>
>
> No, that doesn't make sense to me. If you'd like to dig deeper into
> it, diff -u the output of dmesg from both boots. (and please copy the
> list next time, thanks :)
>
^ permalink raw reply
* Re: [PATCH 1/4 v3] powerpc: document interface-type property
From: Kumar Gala @ 2007-04-20 20:57 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20070420151136.3fdb160f.kim.phillips@freescale.com>
On Apr 20, 2007, at 3:11 PM, Kim Phillips wrote:
> Since ucc_geth is being migrated to use the phylib, the existing
> (undocumented) 'interface' property is being deprecated in favour
> of a stringified version, 'interface-type'.
>
> interface-type is maintained one-to-one with definitions
> in include/linux/phy.h. If not specified, "mii" is assumed.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> removed max-speed property, since the name is apparently too generic
> (it's derived from the interface-type anyway)
Are you sure? Is not possible to use a gmii phy on a 8323 and limit
it to 10/100?
- k
^ permalink raw reply
* Re: how to cross compile assembly file for powerpc
From: Conn Clark @ 2007-04-20 20:47 UTC (permalink / raw)
To: patel nirav; +Cc: linux ppc
In-Reply-To: <290919.56258.qm@web43131.mail.sp1.yahoo.com>
patel nirav writes:
> hello all,
> I have installed croostool for power pc.
> Now I created assembly file (.s) with the help of cross compiler.
> ./powerpc-gcc -S hello.c
> Now We have hello.s with us.
> Now I make changes in the hello.s
> Now I want to create binary executable of hello.s for PowerPC.
> So what can I do?
> Any help will be appreciated.
>
> Thanks & Regards
>
> Nirav
> Institute for Plasma Research,
> India.
>
Change the name of hello.s to hello.S
then type
./powerpc-gcc hello.S
That should do it.
Conn
---------------------------------------
Conn Clark
Electronic Systems Technology
415 N. Quay Street Building B1 (509)-735-9092 ext 117
Kennewick, WA. 99336
Gentoo Linux RU13$!!!
^ permalink raw reply
* [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Linas Vepstas @ 2007-04-20 20:47 UTC (permalink / raw)
To: matthew; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070420204114.GL31947@austin.ibm.com>
Implement the so-called "first failure data capture" (FFDC) for the
symbios PCI error recovery. After a PCI error event is reported,
the driver requests that MMIO be enabled. Once enabled, it
then reads and dumps assorted status registers, and concludes
by requesting the usual reset sequence.
(includes a whitespace fix for bad indentation).
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/scsi/sym53c8xx_2/sym_glue.c | 15 +++++++++++++++
drivers/scsi/sym53c8xx_2/sym_glue.h | 1 +
drivers/scsi/sym53c8xx_2/sym_hipd.c | 18 ++++++++++++++----
3 files changed, 30 insertions(+), 4 deletions(-)
Index: linux-2.6.21-rc4-git4/drivers/scsi/sym53c8xx_2/sym_glue.c
===================================================================
--- linux-2.6.21-rc4-git4.orig/drivers/scsi/sym53c8xx_2/sym_glue.c 2007-04-20 12:52:01.000000000 -0500
+++ linux-2.6.21-rc4-git4/drivers/scsi/sym53c8xx_2/sym_glue.c 2007-04-20 15:25:35.000000000 -0500
@@ -1987,6 +1987,20 @@ static pci_ers_result_t sym2_io_error_de
disable_irq(pdev->irq);
pci_disable_device(pdev);
+ /* Request that MMIO be enabled, so register dump can be taken. */
+ return PCI_ERS_RESULT_CAN_RECOVER;
+}
+
+/**
+ * sym2_io_slot_dump -- Enable MMIO and dump debug registers
+ * @pdev: pointer to PCI device
+ */
+static pci_ers_result_t sym2_io_slot_dump (struct pci_dev *pdev)
+{
+ struct sym_hcb *np = pci_get_drvdata(pdev);
+
+ sym_dump_registers(np);
+
/* Request a slot reset. */
return PCI_ERS_RESULT_NEED_RESET;
}
@@ -2241,6 +2255,7 @@ MODULE_DEVICE_TABLE(pci, sym2_id_table);
static struct pci_error_handlers sym2_err_handler = {
.error_detected = sym2_io_error_detected,
+ .mmio_enabled = sym2_io_slot_dump,
.slot_reset = sym2_io_slot_reset,
.resume = sym2_io_resume,
};
Index: linux-2.6.21-rc4-git4/drivers/scsi/sym53c8xx_2/sym_glue.h
===================================================================
--- linux-2.6.21-rc4-git4.orig/drivers/scsi/sym53c8xx_2/sym_glue.h 2007-04-20 12:15:07.000000000 -0500
+++ linux-2.6.21-rc4-git4/drivers/scsi/sym53c8xx_2/sym_glue.h 2007-04-20 15:21:31.000000000 -0500
@@ -270,5 +270,6 @@ void sym_xpt_async_bus_reset(struct sym_
void sym_xpt_async_sent_bdr(struct sym_hcb *np, int target);
int sym_setup_data_and_start (struct sym_hcb *np, struct scsi_cmnd *csio, struct sym_ccb *cp);
void sym_log_bus_error(struct sym_hcb *np);
+void sym_dump_registers(struct sym_hcb *np);
#endif /* SYM_GLUE_H */
Index: linux-2.6.21-rc4-git4/drivers/scsi/sym53c8xx_2/sym_hipd.c
===================================================================
--- linux-2.6.21-rc4-git4.orig/drivers/scsi/sym53c8xx_2/sym_hipd.c 2007-04-20 12:18:59.000000000 -0500
+++ linux-2.6.21-rc4-git4/drivers/scsi/sym53c8xx_2/sym_hipd.c 2007-04-20 15:18:01.000000000 -0500
@@ -1180,10 +1180,10 @@ static void sym_log_hard_error(struct sy
scr_to_cpu((int) *(u32 *)(script_base + script_ofs)));
}
- printf ("%s: regdump:", sym_name(np));
- for (i=0; i<24;i++)
- printf (" %02x", (unsigned)INB_OFF(np, i));
- printf (".\n");
+ printf ("%s: regdump:", sym_name(np));
+ for (i=0; i<24;i++)
+ printf (" %02x", (unsigned)INB_OFF(np, i));
+ printf (".\n");
/*
* PCI BUS error.
@@ -1192,6 +1192,16 @@ static void sym_log_hard_error(struct sy
sym_log_bus_error(np);
}
+void sym_dump_registers(struct sym_hcb *np)
+{
+ u_short sist;
+ u_char dstat;
+
+ sist = INW(np, nc_sist);
+ dstat = INB(np, nc_dstat);
+ sym_log_hard_error(np, sist, dstat);
+}
+
static struct sym_chip sym_dev_table[] = {
{PCI_DEVICE_ID_NCR_53C810, 0x0f, "810", 4, 8, 4, 64,
FE_ERL}
^ permalink raw reply
* [PATCH 1/2]: PCI Error Recovery: Symbios SCSI base support
From: Linas Vepstas @ 2007-04-20 20:41 UTC (permalink / raw)
To: matthew; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
Hi Matthew,
After a long hiatus, I took another stab at pci error recovery
for the symbios. This is very nearly the same patch as before,
with only an update to enable MWI, and to support chip workarounds.
I think I've addressed all the other issues that came up. Thus,
again, I'll ask that the patch go in (for 2.6.22 of course).
To recap the only outstanding issue:
>> @@ -657,6 +657,10 @@ static irqreturn_t sym53c8xx_intr(int ir
>> + /* Avoid spinloop trying to handle interrupts on frozen device */
>> + if (pci_channel_offline(np->s.device))
>> + return IRQ_HANDLED;
>
>Just wondering ... should we really be returning HANDLED? What if the
>IRQ is shared? Will the hardware de-assert the level interrupt when it
>puts the device in reset (ie is this a transitory glitch?), or do we
>have to cope with a screaming interrupt?
This routine *always* returns HANDLED anyway, so this patch does
not change semantics. For a symbios device plugged into a shared
irq line, this is a problem with or without my patch.
Yes, irq's will typically scream until handled. Yes, the device
reset will eventually clear the irq, assuming the system doesn't
deadlock on a screaming irq.
--linas
Here's the formal changelog entry:
Various PCI bus errors can be signaled by newer PCI controllers.
This patch adds the PCI error recovery callbacks to the Symbios
SCSI device driver. The patch has been tested, and appears to
work well.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
--
drivers/scsi/sym53c8xx_2/sym_glue.c | 136 ++++++++++++++++++++++++++++++++++++
drivers/scsi/sym53c8xx_2/sym_glue.h | 4 +
drivers/scsi/sym53c8xx_2/sym_hipd.c | 6 +
3 files changed, 146 insertions(+)
Index: linux-2.6.21-rc4-git4/drivers/scsi/sym53c8xx_2/sym_glue.c
===================================================================
--- linux-2.6.21-rc4-git4.orig/drivers/scsi/sym53c8xx_2/sym_glue.c 2007-04-20 12:07:38.000000000 -0500
+++ linux-2.6.21-rc4-git4/drivers/scsi/sym53c8xx_2/sym_glue.c 2007-04-20 12:52:01.000000000 -0500
@@ -657,6 +657,10 @@ static irqreturn_t sym53c8xx_intr(int ir
unsigned long flags;
struct sym_hcb *np = (struct sym_hcb *)dev_id;
+ /* Avoid spinloop trying to handle interrupts on frozen device */
+ if (pci_channel_offline(np->s.device))
+ return IRQ_HANDLED;
+
if (DEBUG_FLAGS & DEBUG_TINY) printf_debug ("[");
spin_lock_irqsave(np->s.host->host_lock, flags);
@@ -726,6 +730,20 @@ static int sym_eh_handler(int op, char *
dev_warn(&cmd->device->sdev_gendev, "%s operation started.\n", opname);
+ /* We may be in an error condition because the PCI bus
+ * went down. In this case, we need to wait until the
+ * PCI bus is reset, the card is reset, and only then
+ * proceed with the scsi error recovery. There's no
+ * point in hurrying; take a leisurely wait.
+ */
+#define WAIT_FOR_PCI_RECOVERY 35
+ if (pci_channel_offline(np->s.device)) {
+ int finished_reset = wait_for_completion_timeout(
+ &np->s.io_reset_wait, WAIT_FOR_PCI_RECOVERY*HZ);
+ if (!finished_reset)
+ return SCSI_FAILED;
+ }
+
spin_lock_irq(host->host_lock);
/* This one is queued in some place -> to wait for completion */
FOR_EACH_QUEUED_ELEMENT(&np->busy_ccbq, qp) {
@@ -1510,6 +1528,7 @@ static struct Scsi_Host * __devinit sym_
np->maxoffs = dev->chip.offset_max;
np->maxburst = dev->chip.burst_max;
np->myaddr = dev->host_id;
+ init_completion(&np->s.io_reset_wait);
/*
* Edit its name.
@@ -1948,6 +1967,116 @@ static void __devexit sym2_remove(struct
attach_count--;
}
+/**
+ * sym2_io_error_detected() -- called when PCI error is detected
+ * @pdev: pointer to PCI device
+ * @state: current state of the PCI slot
+ */
+static pci_ers_result_t sym2_io_error_detected (struct pci_dev *pdev,
+ enum pci_channel_state state)
+{
+ struct sym_hcb *np = pci_get_drvdata(pdev);
+
+ /* If slot is permanently frozen, turn everything off */
+ if (state == pci_channel_io_perm_failure) {
+ sym2_remove(pdev);
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ init_completion(&np->s.io_reset_wait);
+ disable_irq(pdev->irq);
+ pci_disable_device(pdev);
+
+ /* Request a slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * sym2_reset_workarounds -- hardware-specific work-arounds
+ *
+ * This routine is similar to sym_set_workarounds(), except
+ * that, at this point, we already know that the device was
+ * succesfully intialized at least once before, and so most
+ * of the steps taken there are un-needed here.
+ */
+static void sym2_reset_workarounds (struct pci_dev *pdev)
+{
+ u_char revision;
+ u_short status_reg;
+ struct sym_chip *chip;
+
+ pci_read_config_byte(pdev, PCI_CLASS_REVISION, &revision);
+ chip = sym_lookup_chip_table(pdev->device, revision);
+
+ /* Work around for errant bit in 895A, in a fashion
+ * similar to what is done in sym_set_workarounds().
+ */
+ pci_read_config_word(pdev, PCI_STATUS, &status_reg);
+ if (!(chip->features & FE_66MHZ) && (status_reg & PCI_STATUS_66MHZ)) {
+ status_reg = PCI_STATUS_66MHZ;
+ pci_write_config_word(pdev, PCI_STATUS, status_reg);
+ pci_read_config_word(pdev, PCI_STATUS, &status_reg);
+ }
+}
+
+/**
+ * sym2_io_slot_reset() -- called when the pci bus has been reset.
+ * @pdev: pointer to PCI device
+ *
+ * Restart the card from scratch.
+ */
+static pci_ers_result_t sym2_io_slot_reset (struct pci_dev *pdev)
+{
+ struct sym_hcb *np = pci_get_drvdata(pdev);
+
+ printk(KERN_INFO "%s: recovering from a PCI slot reset\n",
+ sym_name(np));
+
+ if (pci_enable_device(pdev)) {
+ printk(KERN_ERR "%s: Unable to enable afer PCI reset\n",
+ sym_name(np));
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ pci_set_master(pdev);
+ enable_irq(pdev->irq);
+
+ /* If the chip can do Memory Write Invalidate, enable it */
+ if (np->features & FE_WRIE) {
+ if (pci_set_mwi(pdev))
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ /* Perform work-arounds, analogous to sym_set_workarounds() */
+ sym2_reset_workarounds(pdev);
+
+ /* Perform host reset only on one instance of the card */
+ if (PCI_FUNC (pdev->devfn) == 0) {
+ if (sym_reset_scsi_bus(np, 0)) {
+ printk(KERN_ERR "%s: Unable to reset scsi host\n",
+ sym_name(np));
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+ sym_start_up(np, 1);
+ }
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * sym2_io_resume() -- resume normal ops after PCI reset
+ * @pdev: pointer to PCI device
+ *
+ * Called when the error recovery driver tells us that its
+ * OK to resume normal operation. Use completion to allow
+ * halted scsi ops to resume.
+ */
+static void sym2_io_resume (struct pci_dev *pdev)
+{
+ struct sym_hcb *np = pci_get_drvdata(pdev);
+ complete_all(&np->s.io_reset_wait);
+}
+
static void sym2_get_signalling(struct Scsi_Host *shost)
{
struct sym_hcb *np = sym_get_hcb(shost);
@@ -2110,11 +2239,18 @@ static struct pci_device_id sym2_id_tabl
MODULE_DEVICE_TABLE(pci, sym2_id_table);
+static struct pci_error_handlers sym2_err_handler = {
+ .error_detected = sym2_io_error_detected,
+ .slot_reset = sym2_io_slot_reset,
+ .resume = sym2_io_resume,
+};
+
static struct pci_driver sym2_driver = {
.name = NAME53C8XX,
.id_table = sym2_id_table,
.probe = sym2_probe,
.remove = __devexit_p(sym2_remove),
+ .err_handler = &sym2_err_handler,
};
static int __init sym2_init(void)
Index: linux-2.6.21-rc4-git4/drivers/scsi/sym53c8xx_2/sym_glue.h
===================================================================
--- linux-2.6.21-rc4-git4.orig/drivers/scsi/sym53c8xx_2/sym_glue.h 2007-04-20 12:07:38.000000000 -0500
+++ linux-2.6.21-rc4-git4/drivers/scsi/sym53c8xx_2/sym_glue.h 2007-04-20 12:15:07.000000000 -0500
@@ -40,6 +40,7 @@
#ifndef SYM_GLUE_H
#define SYM_GLUE_H
+#include <linux/completion.h>
#include <linux/delay.h>
#include <linux/ioport.h>
#include <linux/pci.h>
@@ -179,6 +180,9 @@ struct sym_shcb {
char chip_name[8];
struct pci_dev *device;
+ /* Waiter for clearing of frozen PCI bus */
+ struct completion io_reset_wait;
+
struct Scsi_Host *host;
void __iomem * ioaddr; /* MMIO kernel io address */
Index: linux-2.6.21-rc4-git4/drivers/scsi/sym53c8xx_2/sym_hipd.c
===================================================================
--- linux-2.6.21-rc4-git4.orig/drivers/scsi/sym53c8xx_2/sym_hipd.c 2007-04-20 12:07:38.000000000 -0500
+++ linux-2.6.21-rc4-git4/drivers/scsi/sym53c8xx_2/sym_hipd.c 2007-04-20 12:18:59.000000000 -0500
@@ -2809,6 +2809,12 @@ void sym_interrupt (struct sym_hcb *np)
dstat |= INB(np, nc_dstat);
istatc = INB(np, nc_istat);
istat |= istatc;
+
+ /* Prevent deadlock waiting on a condition that may never clear. */
+ if (unlikely(sist == 0xffff && dstat == 0xff)) {
+ if (pci_channel_offline(np->s.device))
+ return;
+ }
} while (istatc & (SIP|DIP));
if (DEBUG_FLAGS & DEBUG_TINY)
^ permalink raw reply
* [PATCH 1/4 v3] powerpc: document interface-type property
From: Kim Phillips @ 2007-04-20 20:11 UTC (permalink / raw)
To: linuxppc-dev
Since ucc_geth is being migrated to use the phylib, the existing
(undocumented) 'interface' property is being deprecated in favour
of a stringified version, 'interface-type'.
interface-type is maintained one-to-one with definitions
in include/linux/phy.h. If not specified, "mii" is assumed.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
removed max-speed property, since the name is apparently too generic
(it's derived from the interface-type anyway)
Documentation/powerpc/booting-without-of.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 88cdb59..e128282 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1562,6 +1562,9 @@ platforms are moved over to use the flattened-device-tree model.
network device. This is used by the bootwrapper to interpret
MAC addresses passed by the firmware when no information other
than indices is available to associate an address with a device.
+ - interface-type : a string naming the controller/PHY interface type,
+ i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "tbi",
+ or "rtbi".
Example:
ucc@2000 {
@@ -1573,6 +1576,7 @@ platforms are moved over to use the flattened-device-tree model.
interrupts = <a0 0>;
interrupt-parent = <700>;
mac-address = [ 00 04 9f 00 23 23 ];
+ interface-type = "gmii";
rx-clock = "none";
tx-clock = "clk9";
phy-handle = <212000>;
--
1.5.0.3
^ permalink raw reply related
* Re: [RFC][PATCH]Kprobes for PPC32(BOOKE)
From: Kumar Gala @ 2007-04-20 19:33 UTC (permalink / raw)
To: rsmadhvesh; +Cc: linuxppc-dev, madhvesh.s
In-Reply-To: <e38bf5391d991.4628b0f3@vsnl.net>
On Apr 20, 2007, at 2:24 AM, rsmadhvesh@vsnl.net wrote:
> Hi Kumar,
>
> This is regarding the kprobes patches for
> PPC32 BOOKE version. The attached patches
> contain the implementation for this version.
>
> I saw your earlier postings and commits to 2.6.21
> regarding kprobes for PPC32. Since the single
> step mechanism in BookE is quite different, I
> thought i can share some of the issues faced
> in this implementation and get your review
> feedback for those patches.
I'd love to review these patches. Is there any possibility that I
could get you to build them for arch/powerpc on top of David Gibson's
port of ebony to arch/powerpc.
http://ozlabs.org/pipermail/linuxppc-dev/2007-April/034483.html
I dont see much value in adding kprobes into arch/ppc and have been
trying to push any 'new' functionality get added to arch/powerpc and
only bug fixes to arch/ppc.
- k
^ permalink raw reply
* Re: RFC: powerpc: Start splitting up mmu.h by MMU type
From: Kumar Gala @ 2007-04-20 19:26 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070420005616.GA14382@localhost.localdomain>
On Apr 19, 2007, at 7:56 PM, David Gibson wrote:
> On Thu, Apr 19, 2007 at 07:11:07AM -0500, Kumar Gala wrote:
>>
>> On Apr 19, 2007, at 1:54 AM, David Gibson wrote:
>>
>>> This patch makes a start to sorting out the tangled mess of MMU
>>> related header files in asm-powerpc, and weaning arch/powerpc off
>>> the
>>> remaining asm-ppc headers it uses.
>>>
>>> Specifically it splits the ppc64 specific (or more strictly, the
>>> 64-bit hash table specific) parts of asm-powerpc/mmu.h into its own
>>> file, asm-powerpc/mmu-hash64/mmu.h. Similarly, PowerPC 44x
>>> definitions are taken from asm-ppc/mmu.h, trimmed down for use in
>>> arch/powerpc and place in their own file, asm-powerpc/mmu-44x/mmu.h.
>>>
>>> mmu.h definitions for other 32-bit MMU types remain in asm-ppc/mmu.h
>>> for now, but should be likewise split into their own files.
>>
>> I asked this before, but why the need for a separate directory per
>> mmu type? why not just include/asm-powerpc/mmu-44x.h?
>
> Because I have further patches in the works that add MMU specific
> versions of tlbflush.h, pgtable.h and so forth to the same
> directories.
Well I agree pgtable.h getting split wouldn't be a bad idea. But
tlbflush.h is only 146 lines, splitting it doesn't seem worth the
trouble. So having a mmu-44x, mmu-hash32, mmu-hash64, mmu-8xx, mmu-
fsl_booke, mmu-40x for just two files seems a bit much.
> I'm not wedded to the idea, but it seemed like a reasonable way to
> organize things.
- k
^ permalink raw reply
* MPC5200 ethernet communication stops unexpected
From: Eberhard Stoll @ 2007-04-20 19:21 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
can someone help me?
I have some problem with our MPC5200 board running denx linux kernel
2.4.25 with ethernet communication.
My problem is that our board stops receiving and transmitting any
ethernet frames suddenly and unexpected. No pings - nothing is getting
thru the ethernet any more! The rest of the controller is running well.
This situation is very rare - only a constellation with 6 Controllers
and a special ethernet communication load leads to this fault - in about
one day!
When i check how many tx and rx buffers are used in the BestComm buffer
descriptor ring (via TaskBDInUse() call) which hold pointers to transmit
and receive data, i see all tx and rx buffers are in use! When i look at
the FEC Tx Fifo Status Register i get the value 0x00030000. This means
FEC Tx Fifo empty!
When i check fec Task Control register i see Tx and Rx Task are enabled,
current Pointer register points to 0xF000828C which belongs to FEC Tx
BestComm Microcode.
When i now examine the status value of my currently active buffer
descriptor for Tx task, it shows that this buffer belongs to BestComm.
In my opinion BestComm shold tranfer this buffer to the empty FEC Tx
Fifo - but it doesn't!
Now the question for me is: WHY?
Do i oversee some bits in the registers/ram locations which lead to this
situation?
I don't know much about BestComm/FEC, but my conclusion out of this is
BestComm is stuck somewhere out of some reason. Is this a hardware
issue? Does someone know? Has someone similar problems?
Can someone help me or check if i'm right with my conclusion (see
registers and ram locations down)? Or give me a hint where to look further.
Any help is very welcome!
Many Thanks,
Eberhard
PS: I saw this problem only on MPC5200B processors until now. And we use
BestComm Api 2.2 (the newest denx 2.4.x code for bestcomm)
Here are some registers and ram addresses i collected in this situation:
BTW: I saw BestComm Microcode changing in 16k SRAM after the first
Ethernet frames were sent. This seems very strange to me - but maybe is
correct behaviour - i don't know. Does someone of you?
Its the address 0xf00082e8 (in FEC Tx BestComm microcode). After reset
(no frame sent) the ram at this address is 0x088AC398 after the first(?)
ethernet frame it's 0x0C8AC398!
=== BestComm registers ===
taskBar 0xF0008000
currentPointer 0xF000828C
endPointer 0x00000000
variablePointer 0xF0008800
IntVect1 0x0000000F
IntVect2 0x0000000F
PtdCntrl 0x00000001
IntPend 0x00000000
IntMask 0xFFFFFFF3
tcr_0 0x0000
tcr_1 0x0000
tcr_2 0xE082
tcr_3 0xC383
tcr_4 0x0000
tcr_5 0x0000
tcr_6 0x0000
tcr_7 0x0000
tcr_8 0x0000
tcr_9 0x0000
tcr_a 0x0000
tcr_b 0x0000
tcr_c 0x0000
tcr_d 0x0000
tcr_e 0x0000
tcr_f 0x0000
IPR0 0x07
IPR1 0x00
IPR2 0x00
IPR3 0x04
IPR4 0x03
IPR5 0x06
IPR6 0x05
IPR7 0x00
IPR8 0x00
IPR9 0x00
IPR10 0x00
IPR11 0x00
IPR12 0x00
IPR13 0x00
IPR14 0x00
IPR15 0x00
IPR16 0x00
IPR17 0x00
IPR18 0x00
IPR19 0x00
IPR20 0x00
IPR21 0x00
IPR22 0x00
IPR23 0x00
IPR24 0x00
IPR25 0x00
IPR26 0x00
IPR27 0x00
IPR28 0x00
IPR29 0x00
IPR30 0x00
IPR31 0x00
task_size0 0x00000000
task_size1 0x00000000
MDEDebug 0x01000008
ADSDebug 0x00000000
Value1 0x00000000
Value2 0x00000000
Control 0x00000000
Status 0x00000000
EU00 0x04155519
EU01 0x00000000
EU02 0x00000000
EU03 0x00000000
EU04 0x00000000
EU05 0x00000000
EU06 0x00000000
EU07 0x00000000
EU10 0x00000000
EU11 0x00000000
EU12 0x00000000
EU13 0x00000000
EU14 0x00000000
EU15 0x00000000
EU16 0x00000000
EU17 0x00000000
EU20 0x00000000
EU21 0x00000000
EU22 0x00000000
EU23 0x00000000
EU24 0x00000000
EU25 0x00000000
EU26 0x00000000
EU27 0x00000000
EU30 0x00000000
EU31 0x00000000
EU32 0x00000000
EU33 0x00000000
EU34 0x00000000
EU35 0x00000000
EU36 0x00000000
EU37 0x00000000
=== Return values of BestComm Api Functions ===
t_tasknum = 2
TaskBDInUse(tx) = 256
TaskStatus(tx) = run (0x00008000)
TaskIntPending(tx) = 0
r_tasknum = 3
TaskBDInUse(rx) = 256
TaskStatus(rx) = run (0x00008000)
TaskIntPending(rx) = 0
TasksGetSramOffset = 0x00002500
task 0: stop int: 0x00000000
task 1: stop int: 0x00000000
task 2: run int: 0x00000000
task 3: run int: 0x00000000
task 4: stop int: 0x00000000
task 5: stop int: 0x00000000
task 6: stop int: 0x00000000
task 7: stop int: 0x00000000
task 8: stop int: 0x00000000
task 9: stop int: 0x00000000
task 10: stop int: 0x00000000
task 11: stop int: 0x00000000
task 12: stop int: 0x00000000
task 13: stop int: 0x00000000
task 14: stop int: 0x00000000
task 15: stop int: 0x00000000
=== FEC Registers ===
fec base addr f0003000
fec_id 0x00000000
ievent 0x08000000
imask 0xF0FE0000
r_des_active 0x00000000
x_des_active 0x00000000
ecntrl 0xF0000002
mii_data 0x5F821200
mii_speed 0x0000001C
mib_control 0x40000000
r_cntrl 0x05EE0024
r_hash 0x8A000000
x_cntrl 0x00000004
paddr1 0x00E0BA90
paddr2 0x07DC8808
op_pause 0x00010020
iaddr1 0x00000000
iaddr2 0x00000000
gaddr1 0x00400000
gaddr2 0x00000000
x_wmrk 0x00000000
rfifo_status 0x214E0000
rfifo_cntrl 0x0F240000
rfifo_lrf_ptr 0x0000005D
rfifo_lwf_ptr 0x0000038D
rfifo_alarm 0x0000030C
rfifo_rdptr 0x0000005D
rfifo_wrptr 0x0000005D
tfifo_status 0x00030000
tfifo_cntrl 0x0F200000
tfifo_lrf_ptr 0x0000023C
tfifo_lwf_ptr 0x0000023C
tfifo_alarm 0x00000100
tfifo_rdptr 0x0000023C
tfifo_wrptr 0x0000023C
reset_cntrl 0x01000000
xmit_fsm 0x03000000
=== FEC driver vars ===
MBAR 0xF0000000
MBAR SIZE 0x10000000
queue_stopped 1
mpc5xxx_bdi_tx 73 (x49)
mpc5xxx_bdi_rx 97 (x61)
adr(tx_fifo_skb) c0233744
adr(tx_fifo_skb[0]) c0233744
adr(tx_fifo_skb[1]) c0233748
tx_fifo_skb[0] c2474f20
tx_fifo_skb[1] c24846e0
sizeof(tx_fifo_skb) 1024
sizeof(tx_fifo_skb[0]) 4
MPC5xxx_FEC_TBD_NUM 256
adr(rx_fifo_skb) c0233b44
sizeof(rx_fifo_skb) 1024
sizeof(rx_fifo_skb[0]) 4
MPC5xxx_FEC_RBD_NUM 256
full_duplex 1
tx_full 1
r_tasknum 3
t_tasknum 2
r_irq 24
t_irq 23
last_transmit_time 0
last_receive_time 0
phy_id 0x0015F442
phy_id_done 1
phy_status 0x00000000
phy_speed 28
sequence_done 0
link 0
duplex_change 0
link_up 0
old_status 0x00000000
=== BDHead Table ===
TASK #0
[0xC0232D74] = 0x00
[0xC0232D75] = 0x00
[0xC0232D76] = 0x00
[0xC0232D77] = 0x00
TASK #1
[0xC0232D78] = 0x00
[0xC0232D79] = 0x00
[0xC0232D7A] = 0x00
[0xC0232D7B] = 0x00
TASK #2 - tx task
[0xC0232D7C] = 0x00
[0xC0232D7D] = 0x00
[0xC0232D7E] = 0x00
[0xC0232D7F] = 0x49
--> actual tx index: 0x49->73
TASK #3 - rx task
[0xC0232D80] = 0x00
[0xC0232D81] = 0x00
[0xC0232D82] = 0x00
[0xC0232D83] = 0x61
--> actual rx index: 0x61->97
[0xC0232D84] = 0x00
[0xC0232D85] = 0x00
[0xC0232D86] = 0x00
...
=== TaskBDIdxTable ===
TASK#0
numBD [0xC0232DF4] = 0x0000
numPtr [0xC0232DF6] = 0x00
apiConfig [0xC0232DF7] = 0x00
BDTablePtr [0xC0232DF8] = 0x00000000
BDStartPtr [0xC0232DFC] = 0x00000000
currBDInUse[0xC0232E00] = 0x0000
[0xC0232E02] = 0x00
[0xC0232E03] = 0x00
TASK#1
[0xC0232E04] = 0x00
[0xC0232E05] = 0x00
[0xC0232E06] = 0x00
[0xC0232E07] = 0x00
[0xC0232E08] = 0x00
[0xC0232E09] = 0x00
[0xC0232E0A] = 0x00
[0xC0232E0B] = 0x00
[0xC0232E0C] = 0x00
[0xC0232E0D] = 0x00
[0xC0232E0E] = 0x00
[0xC0232E0F] = 0x00
[0xC0232E10] = 0x00
[0xC0232E11] = 0x00
[0xC0232E12] = 0x00
[0xC0232E13] = 0x00
TASK#2 - tx task
numBD [0xC0232E14] = 0x0100
numPtr [0xC0232E16] = 0x01
apiConfig [0xC0232E17] = 0x01
BDTablePtr [0xC0232E18] = 0xF0009D00
BDStartPtr [0xC0232E1C] = 0xF0008814
currBDInUse[0xC0232E20] = 0x0100
[0xC0232E22] = 0x00
[0xC0232E23] = 0x00
TASK#3 - rx task
numBD [0xC0232E24] = 0x0100
numPtr [0xC0232E26] = 0x01
apiConfig [0xC0232E27] = 0x00
BDTablePtr [0xC0232E28] = 0xF0009500
BDStartPtr [0xC0232E2C] = 0xF0008890
currBDInUse[0xC0232E30] = 0x0100
[0xC0232E32] = 0x00
[0xC0232E33] = 0x00
TASK#4
[0xC0232E34] = 0x00
[0xC0232E35] = 0x00
...
=== Tx Descriptor Ring ===
IDX 0x49-(73) is interesting, because active (see BDHeadTable).
So our descriptor is as Addr 0xF0009D00 + (0x49 * 0x8) = 0xF0009F48
IDX 0
[0xF0009D00] = 0x4C00003C
[0xF0009D04] = 0x02475922
IDX 1
[0xF0009D08] = 0x4C00003C
[0xF0009D0C] = 0x02475CA2
...
IDX 72
[0xF0009F40] = 0x4C00003C
[0xF0009F44] = 0x024665A2
IDX 73 - active descriptor
[0xF0009F48] = 0x4C00004E - owns BestComm, should transfer
[0xF0009F4C] = 0x0243F05E
IDX 74
[0xF0009F50] = 0x4C00004E
[0xF0009F54] = 0x0243F85E
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
^ permalink raw reply
* Re: [PATCH 1/4 v2] powerpc: document max-speed and interface-type properties
From: Andy Fleming @ 2007-04-20 19:13 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <d16d2a0d1742a32e45597baabfc3735a@kernel.crashing.org>
On Apr 20, 2007, at 03:34, Segher Boessenkool wrote:
>>>> ..but I'm not interested in specifying what interfaces the PHY
>>>> supports.
>>>
>>> But you *have* to. The device tree describes the hardware,
>>> it is not a configuration file for Linux to use as it sees fit.
>>
>> not for the purposes of this patch; ucc_geth passes interface_type,
>
> It doesn't matter what the Linux code does. The device tree
> describes the hardware, it is not a configuration file for
> Linux to use as it sees fit.
Agreed.
>
>> a
>> property of the board describing the connection between the MAC
>> and PHY
>> (not a list of what connection types the PHY is capable of) to the
>> phylib, and the phylib is left to probe, identify, and configure the
>> PHY
>> appropriately.
>
> Sure there's an argument for describing what type of
> interface the PHY is connected on, if it supports more
> than one -- but that should be a property in the PHY
> node, not the controller node, since you can have multiple
> PHYs connected to the same controller, possibly on
> different interfaces each.
I just want to reiterate that I disagree strongly with this
statement. If you have multiple PHYs hooked up to one ethernet
controller, you're going to need to change the device tree to use a
different PHY, anyway. That, or have Linux ignore the phandle that
points to the connected PHY.
Also, you'd need to do something to the hardware, since the different
interfaces are not, typically, on different pins. Just in different
combinations.
And if you put it in the PHY node, you haven't really helped out the
people who can change the interface type by flipping a dip switch. I
can think of two or three boards off the top of my head that do that
(though I know of very few people who actually use this functionality).
My point, again, is that the interface type is not strongly tied to
the PHY. It is strongly tied to the board configuration. We *could*
put the interface type in the PHY node, but I want to disabuse you of
the notion that it would be any better there.
Andy
^ permalink raw reply
* how to cross compile assembly file for powerpc
From: patel nirav @ 2007-04-20 19:01 UTC (permalink / raw)
To: linux ppc
[-- Attachment #1: Type: text/plain, Size: 541 bytes --]
hello all,
I have installed croostool for power pc.
Now I created assembly file (.s) with the help of cross compiler.
./powerpc-gcc -S hello.c
Now We have hello.s with us.
Now I make changes in the hello.s
Now I want to create binary executable of hello.s for PowerPC.
So what can I do?
Any help will be appreciated.
Thanks & Regards
Nirav
Institute for Plasma Research,
India.
---------------------------------
Ahhh...imagining that irresistible "new car" smell?
Check outnew cars at Yahoo! Autos.
[-- Attachment #2: Type: text/html, Size: 855 bytes --]
^ permalink raw reply
* [PATCH] generic check_legacy_ioport
From: Olaf Hering @ 2007-04-20 18:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070417210745.GA3567@aepfle.de>
check_legacy_ioport makes only sense on PREP, CHRP and pSeries.
They may have an isa node with PS/2, parport, floppy and serial ports.
Cell has IPMI, check for that too.
Remove the check_legacy_ioport call from ppc_md, its not needed anymore.
Hardware capabilities come from the device-tree.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
arch/powerpc/kernel/setup-common.c | 42 ++++++++++++++++++++++++++++++--
arch/powerpc/platforms/cell/setup.c | 10 -------
arch/powerpc/platforms/celleb/setup.c | 10 -------
arch/powerpc/platforms/iseries/setup.c | 10 -------
arch/powerpc/platforms/pasemi/setup.c | 7 -----
arch/powerpc/platforms/powermac/setup.c | 10 -------
arch/powerpc/platforms/pseries/setup.c | 27 --------------------
include/asm-powerpc/io.h | 7 ++++-
include/asm-powerpc/machdep.h | 3 --
9 files changed, 46 insertions(+), 80 deletions(-)
Index: b/arch/powerpc/kernel/setup-common.c
===================================================================
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -498,9 +498,47 @@ void probe_machine(void)
int check_legacy_ioport(unsigned long base_port)
{
- if (ppc_md.check_legacy_ioport == NULL)
+ struct device_node *np;
+
+ switch(base_port) {
+#ifdef CONFIG_SERIO_I8042
+ case I8042_DATA_REG:
+ np = of_find_node_by_type(NULL, "8042");
+ if (np == NULL)
+ return -ENODEV;
+ of_node_put(np);
+ return 0;
+#endif
+#ifdef CONFIG_BLK_DEV_FD
+ case FDC_BASE: /* FDC1 */
+ np = of_find_node_by_type(NULL, "fdc");
+ if (np == NULL)
+ return -ENODEV;
+ of_node_put(np);
+ return 0;
+#endif
+#ifdef CONFIG_IPMI_HANDLER
+ /* IPMI */
+ case 0xca2:
+ case 0xca9:
+ case 0xe4:
+ np = of_find_node_by_type(NULL, "ipmi");
+ if (np == NULL)
+ return -ENODEV;
+ of_node_put(np);
return 0;
- return ppc_md.check_legacy_ioport(base_port);
+#endif
+#ifdef CONFIG_PPC_PREP
+ case _PIDXR:
+ case _PNPWRP:
+ case PNPBIOS_BASE:
+ /* implement me for PReP */
+#endif
+ default:
+ printk(KERN_DEBUG "%s rejected access to port %u\n", __FUNCTION__, base_port);
+ WARN_ON(base_port);
+ }
+ return -ENODEV;
}
EXPORT_SYMBOL(check_legacy_ioport);
Index: b/arch/powerpc/platforms/cell/setup.c
===================================================================
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -190,15 +190,6 @@ static int __init cell_probe(void)
return 1;
}
-/*
- * Cell has no legacy IO; anything calling this function has to
- * fail or bad things will happen
- */
-static int cell_check_legacy_ioport(unsigned int baseport)
-{
- return -ENODEV;
-}
-
define_machine(cell) {
.name = "Cell",
.probe = cell_probe,
@@ -211,7 +202,6 @@ define_machine(cell) {
.get_rtc_time = rtas_get_rtc_time,
.set_rtc_time = rtas_set_rtc_time,
.calibrate_decr = generic_calibrate_decr,
- .check_legacy_ioport = cell_check_legacy_ioport,
.progress = cell_progress,
.init_IRQ = cell_init_irq,
.pci_setup_phb = rtas_setup_phb,
Index: b/arch/powerpc/platforms/celleb/setup.c
===================================================================
--- a/arch/powerpc/platforms/celleb/setup.c
+++ b/arch/powerpc/platforms/celleb/setup.c
@@ -128,15 +128,6 @@ static int __init celleb_probe(void)
return 1;
}
-/*
- * Cell has no legacy IO; anything calling this function has to
- * fail or bad things will happen
- */
-static int celleb_check_legacy_ioport(unsigned int baseport)
-{
- return -ENODEV;
-}
-
#ifdef CONFIG_KEXEC
static void celleb_kexec_cpu_down(int crash, int secondary)
{
@@ -173,7 +164,6 @@ define_machine(celleb) {
.get_rtc_time = beat_get_rtc_time,
.set_rtc_time = beat_set_rtc_time,
.calibrate_decr = generic_calibrate_decr,
- .check_legacy_ioport = celleb_check_legacy_ioport,
.progress = celleb_progress,
.power_save = beat_power_save,
.nvram_size = beat_nvram_get_size,
Index: b/arch/powerpc/platforms/iseries/setup.c
===================================================================
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -628,15 +628,6 @@ static void iseries_iounmap(volatile voi
{
}
-/*
- * iSeries has no legacy IO, anything calling this function has to
- * fail or bad things will happen
- */
-static int iseries_check_legacy_ioport(unsigned int baseport)
-{
- return -ENODEV;
-}
-
static int __init iseries_probe(void)
{
unsigned long root = of_get_flat_dt_root();
@@ -667,7 +658,6 @@ define_machine(iseries) {
.calibrate_decr = generic_calibrate_decr,
.progress = iSeries_progress,
.probe = iseries_probe,
- .check_legacy_ioport = iseries_check_legacy_ioport,
.ioremap = iseries_ioremap,
.iounmap = iseries_iounmap,
/* XXX Implement enable_pmcs for iSeries */
Index: b/arch/powerpc/platforms/pasemi/setup.c
===================================================================
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -101,12 +101,6 @@ void __init pas_setup_arch(void)
pasemi_idle_init();
}
-/* No legacy IO on our parts */
-static int pas_check_legacy_ioport(unsigned int baseport)
-{
- return -ENODEV;
-}
-
static __init void pas_init_IRQ(void)
{
struct device_node *np;
@@ -237,7 +231,6 @@ define_machine(pas) {
.restart = pas_restart,
.get_boot_time = pas_get_boot_time,
.calibrate_decr = generic_calibrate_decr,
- .check_legacy_ioport = pas_check_legacy_ioport,
.progress = pas_progress,
.machine_check_exception = pas_machine_check_handler,
.pci_irq_fixup = pas_pci_irq_fixup,
Index: b/arch/powerpc/platforms/powermac/setup.c
===================================================================
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -616,15 +616,6 @@ static void __init pmac_init_early(void)
#endif
}
-/*
- * pmac has no legacy IO, anything calling this function has to
- * fail or bad things will happen
- */
-static int pmac_check_legacy_ioport(unsigned int baseport)
-{
- return -ENODEV;
-}
-
static int __init pmac_declare_of_platform_devices(void)
{
struct device_node *np;
@@ -736,7 +727,6 @@ define_machine(powermac) {
.get_rtc_time = pmac_get_rtc_time,
.calibrate_decr = pmac_calibrate_decr,
.feature_call = pmac_do_feature_call,
- .check_legacy_ioport = pmac_check_legacy_ioport,
.progress = udbg_progress,
#ifdef CONFIG_PPC64
.pci_probe_mode = pmac_pci_probe_mode,
Index: b/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -334,32 +334,6 @@ static void __init pSeries_init_early(vo
DBG(" <- pSeries_init_early()\n");
}
-
-static int pSeries_check_legacy_ioport(unsigned int baseport)
-{
- struct device_node *np;
-
-#define I8042_DATA_REG 0x60
-#define FDC_BASE 0x3f0
-
-
- switch(baseport) {
- case I8042_DATA_REG:
- np = of_find_node_by_type(NULL, "8042");
- if (np == NULL)
- return -ENODEV;
- of_node_put(np);
- break;
- case FDC_BASE:
- np = of_find_node_by_type(NULL, "fdc");
- if (np == NULL)
- return -ENODEV;
- of_node_put(np);
- break;
- }
- return 0;
-}
-
/*
* Called very early, MMU is off, device-tree isn't unflattened
*/
@@ -532,7 +506,6 @@ define_machine(pseries) {
.set_rtc_time = rtas_set_rtc_time,
.calibrate_decr = generic_calibrate_decr,
.progress = rtas_progress,
- .check_legacy_ioport = pSeries_check_legacy_ioport,
.system_reset_exception = pSeries_system_reset_exception,
.machine_check_exception = pSeries_machine_check_exception,
};
Index: b/include/asm-powerpc/io.h
===================================================================
--- a/include/asm-powerpc/io.h
+++ b/include/asm-powerpc/io.h
@@ -11,7 +11,12 @@
/* Check of existence of legacy devices */
extern int check_legacy_ioport(unsigned long base_port);
-#define PNPBIOS_BASE 0xf000 /* only relevant for PReP */
+#define I8042_DATA_REG 0x60
+#define FDC_BASE 0x3f0
+/* only relevant for PReP */
+#define _PIDXR 0x279
+#define _PNPWRP 0xa79
+#define PNPBIOS_BASE 0xf000
#include <linux/compiler.h>
#include <asm/page.h>
Index: b/include/asm-powerpc/machdep.h
===================================================================
--- a/include/asm-powerpc/machdep.h
+++ b/include/asm-powerpc/machdep.h
@@ -153,9 +153,6 @@ struct machdep_calls {
*/
long (*feature_call)(unsigned int feature, ...);
- /* Check availability of legacy devices like i8042 */
- int (*check_legacy_ioport)(unsigned int baseport);
-
/* Get legacy PCI/IDE interrupt mapping */
int (*pci_get_legacy_ide_irq)(struct pci_dev *dev, int channel);
^ permalink raw reply
* Re: [patch] ipmi: check, if default ports are accessible on PPC
From: Olaf Hering @ 2007-04-20 18:08 UTC (permalink / raw)
To: Christian Krafft
Cc: linuxppc-dev@ozlabs.org, openipmi-developer@lists.sourceforge.net,
Arnd Bergmann
In-Reply-To: <20070420174821.GA4176@aepfle.de>
On Fri, Apr 20, Olaf Hering wrote:
> On Mon, Feb 26, Christian Krafft wrote:
>
> > ipmi_si_intf tries to access default ports, if no device could
> > be found elsewhere. On PPC we have a function to check,
> > if these legacy IO ports are accessible. This patch adds
> > a check for these ports on PPC.
> > This patch fixes a breakage of IPMI module
> > on PPC machines without a BMC.
>
> This patch is a no-op even for IPMI capable systems.
I missed the 'return 0;' in pSeries_check_legacy_ioport().
^ permalink raw reply
* POSIX semaphores on ppc_6xx
From: Ben Warren @ 2007-04-20 17:55 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
The cross-compiled glibc that is included in ELDK 4.0 doesn't seem to
have support for POSIX semaphores. I get the following runtime errors:
sem_open: Function not implemented
when trying to implement a named semaphore, and
sem_init: Function not implemented
when trying to implement an unnamed semaphore.
Does anybody know if POSIX semaphores have been ported to ppc_6xx, and
if so, where I could find a binary copy?
thanks,
Ben
^ permalink raw reply
* Re: [patch] ipmi: check, if default ports are accessible on PPC
From: Olaf Hering @ 2007-04-20 17:48 UTC (permalink / raw)
To: Christian Krafft
Cc: linuxppc-dev@ozlabs.org, openipmi-developer@lists.sourceforge.net,
Arnd Bergmann
In-Reply-To: <20070226160917.2c801ec7@localhost>
On Mon, Feb 26, Christian Krafft wrote:
> ipmi_si_intf tries to access default ports, if no device could
> be found elsewhere. On PPC we have a function to check,
> if these legacy IO ports are accessible. This patch adds
> a check for these ports on PPC.
> This patch fixes a breakage of IPMI module
> on PPC machines without a BMC.
This patch is a no-op even for IPMI capable systems.
None of the platform check_legacy_ioport() functions check for port
number 0xca2, 0xca9 or 0xe4.
What exactly did you test? Appearently not Linus tree.
^ permalink raw reply
* Re: FDT for MPC5200, CPU revision, MSCAN
From: Wolfgang Grandegger @ 2007-04-20 16:11 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0704200702i328ba9dbvc62473e5a634d5ac@mail.gmail.com>
Grant Likely wrote:
> On 4/20/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> Wolfgang Grandegger wrote:
>> > Hello,
>> >
>> > is there a way to distinguish the CPU revision (Rev.A vs. Rev.B) of the
>> > MPC5200, preferably at run time? Or should this be defined in the FDT?
>> > I ask, because some settings depend on the CPU revision due to hardware
>> > bugs, like the clock source used for MSCAN.
>
> This stuff is defined in the device tree. If you need to detect the
> version at runtime, then ideally your bootloader will read the PVR/SVR
> to determine the chip version and then pass the correct FDT to the
> kernel.
OK, I already realized the revision field in the DTS.
>> I found the information here:
>>
>> $ cat Documentation/powerpc/mpc52xx-device-tree-bindings.txt
> <snip>
>> Sorry for the noise.
>
> Not noise; good question.
OK, then more questions for MSCAN related properties. The clock source
for MSCAN is either derived from IPB or directly from the oscillator
clock via CLKSRC bit. I guess that the property "system-clock" should
provide that frequency:
$ cat Documentation/powerpc/mpc52xx-device-tree-bindings.txt
...
system-frequency int Fsystem frequency; source of all
other clocks.
It needs also to be defined by the boot loader.
Thanks.
Wolfgang.
^ permalink raw reply
* Re: [PATCH][RFC][POWERPC] i2c: adds support for i2c bus on 8xx
From: Milton Miller @ 2007-04-20 15:15 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: ppcdev
In-Reply-To: <20070420082714.4f10f186@localhost.localdomain>
At Fri Apr 20 14:27:14 EST 2007, Vitaly Bordug wrote:
> + i2c_dev =
> platform_device_register_simple("fsl-i2c-cpm", i, &r[0], 3);
> + if (IS_ERR(i2c_dev)) {
> + ret = PTR_ERR(i2c_dev);
> + goto err;
> + }
> +
> + ret =
> + platform_device_add_data(i2c_dev, &i2c_data,
> + sizeof(struct
> +
> fsl_i2c_platform_data));
>
This exposes a period of time where the device is registerd, but
the platform data is not available. It might work for the
everything-in-the kernel model where the device is added before
the driver is registered, but is inherently racy.
You need to do alloc / add_resources / add_data / add.
milton
^ permalink raw reply
* Re: [PATCH 7/7] MPIC MSI backend
From: Michael Ellerman @ 2007-04-20 14:39 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-pci
In-Reply-To: <11965613d9e0cec72d210466d8ec7f6e@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
On Fri, 2007-04-20 at 10:40 +0200, Segher Boessenkool wrote:
> > MPIC MSI backend. Based on code from Segher, heavily hacked by me.
>
> I guess I'll have to do
>
> Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
>
> again, you keep losing it :-)
Oh sorry, I do keep losing it. Actually looking at it closer there isn't
any of your code left, except in spirit I guess :)
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: FDT for MPC5200, CPU revision, MSCAN
From: Grant Likely @ 2007-04-20 14:02 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-embedded
In-Reply-To: <46286A0F.9080608@grandegger.com>
On 4/20/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Wolfgang Grandegger wrote:
> > Hello,
> >
> > is there a way to distinguish the CPU revision (Rev.A vs. Rev.B) of the
> > MPC5200, preferably at run time? Or should this be defined in the FDT?
> > I ask, because some settings depend on the CPU revision due to hardware
> > bugs, like the clock source used for MSCAN.
This stuff is defined in the device tree. If you need to detect the
version at runtime, then ideally your bootloader will read the PVR/SVR
to determine the chip version and then pass the correct FDT to the
kernel.
> I found the information here:
>
> $ cat Documentation/powerpc/mpc52xx-device-tree-bindings.txt
<snip>
> Sorry for the noise.
Not noise; good question.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] Don't shutdown TX on mpc5200 serial port if it is a console
From: Bartlomiej Sieka @ 2007-04-20 13:28 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <11770117743675-git-send-email-grant.likely@secretlab.ca>
Grant Likely wrote:
> If the serial port gets shut down, then console output stalls. 9 out
> of 10 kernel hackers agree, this is a bad thing.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> Wolfgang, please verify this new patch. Sylvain rightly pointed out that
> RX and interrupts should be turned off regardless. If it works for you,
> please reply with a Signed-of-by line.
Patch verified on a MPC5200B-based board.
Signed-off-by: Bartlomiej Sieka <tur@semihalf.com>
Regards,
Bartlomiej
^ permalink raw reply
* Re: [PATCH] Fix the -S to modify the totalsize properly.
From: Jon Loeliger @ 2007-04-20 13:46 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev, u-boot-users
In-Reply-To: <20070420022235.GA1703@dellserver.lan>
So, like, the other day Jerry Van Baren mumbled:
> With the last improvement to pad out the blob, I broke the blob
> header totalsize adjustment. The adjustment was moved up in the
> code before the memory image of the blob is created.
>
> Signed-off-by: Gerald Van Baren <vanbaren@cideas.com>
Applied!
> Hi Jon,
>
> This fixes my header totalsize screwup. Until this is applied, the -S
> adds padding but is not effective.
>
> My apologies,
[Vader Voice]
Apology... accepted.
[/Vader Voice]
Thanks,
jdl
^ permalink raw reply
* kernel 2.6.20 panic
From: Matvejchikov Ilya @ 2007-04-20 13:05 UTC (permalink / raw)
To: linuxppc-embedded
Good day!
My system is : mpc8260 + FCC1(LAN), FCC2(FIBER), FCC3(FIBER) + 2.6.20
+ bridging.
I have a problem... :( Is anybody can tell me where to dig?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - -
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc0046978
Oops: Kernel access of bad area, sig: 11 [#1]
Modules linked in:
NIP: C0046978 LR: C00FFED0 CTR: C0146E30
REGS: c01cdc40 TRAP: 0300 Not tainted (2.6.20ppc)
MSR: 00009032 <EE,ME,IR,DR> CR: 28002024 XER: 20000000
DAR: 00000000, DSISR: 20000000
TASK = c01bc110[0] 'swapper' THREAD: c01cc000
GPR00: C00FFED0 C01CDCF0 C01BC110 00000000 C0163CC0 0000A9E3 00000000 00000000
GPR08: 00600800 00000004 00000000 C01CC000 28002028 00404002 00FFB000 007FFC13
GPR16: 00000001 00000000 FFFFFFFF 00800000 00FF5EAC 00000000 C01C0000 C01CDE48
GPR24: FFFF46B8 C01EA244 C01EA4C0 FFFFFFFF C0F6B000 C0E7CC00 C0E7CC00 00000001
NIP [C0046978] put_page+0x14/0x110
LR [C00FFED0] skb_release_data+0xb0/0xc4
Call Trace:
[C01CDCF0] [C003D600] handle_edge_irq+0xe4/0x1a8 (unreliable)
[C01CDD00] [C00FFED0] skb_release_data+0xb0/0xc4
[C01CDD10] [C00FFBD0] kfree_skbmem+0x18/0xf4
[C01CDD20] [C010606C] dev_hard_start_xmit+0x17c/0x29c
[C01CDD40] [C0114178] __qdisc_run+0x9c/0x1b8
[C01CDD70] [C0108350] dev_queue_xmit+0x168/0x298
[C01CDD90] [C0155A74] br_dev_queue_push_xmit+0x78/0xc4
[C01CDDA0] [C01567C8] br_handle_frame_finish+0x13c/0x154
[C01CDDC0] [C0156924] br_handle_frame+0x144/0x190
--- Exception: c01cdea0 at 0xff5eac
LR = 0xc01e0000
[C01CDDE0] [C0105BC8] netif_receive_skb+0x1b8/0x354 (unreliable)
[C01CDE10] [C0107954] process_backlog+0xa0/0x180
[C01CDE40] [C0107ACC] net_rx_action+0x98/0x18c
[C01CDE70] [C001F43C] __do_softirq+0x80/0xf4
[C01CDEA0] [C0006158] do_softirq+0x58/0x5c
[C01CDEB0] [C001F1D4] irq_exit+0x48/0x58
[C01CDEC0] [C0006204] do_IRQ+0xa8/0xc8
[C01CDED0] [C000F5DC] ret_from_except+0x0/0x14
--- Exception: 501 at cpu_idle+0xa0/0xe8
LR = cpu_idle+0xa0/0xe8
[C01CDF90] [C0008EC0] cpu_idle+0xd8/0xe8 (unreliable)
[C01CDFB0] [C0003B9C] rest_init+0x28/0x38
[C01CDFC0] [C01A06B4] start_kernel+0x1b8/0x238
[C01CDFF0] [00003438] 0x3438
Instruction dump:
90010014 4bffff8d 38600000 80010014 38210010 7c0803a6 4e800020 9421fff0
7c0802a6 7c671b78 39230004 90010014 <80030000> 700b4000 408200e4 7c004828
<0>Kernel panic - not syncing: Fatal exception in interrupt
<0>Rebooting in 180 seconds..
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Best Regards,
Matvejchikov Ilya.
^ permalink raw reply
* Re: [PATCH][RFC][POWERPC] i2c: adds support for i2c bus on 8xx
From: Segher Boessenkool @ 2007-04-20 8:57 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Jean Delvare, linuxppc-dev@ozlabs.org, lkml
In-Reply-To: <20070420082714.4f10f186@localhost.localdomain>
> + compatible = "fsl-i2c-cpm";
"fsl,i2c-cpm" instead.
Segher
^ 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