* [PATCH] powerpc/pseries: Cleanup device name printing.
From: Linas Vepstas @ 2006-03-24 23:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
Paul,
Please apply and forward.
--linas
[PATCH] powerpc/pseries: Cleanup device name printing.
This patch avoids printk'ing a NULL string.
Signed-off-by: Linas Vepstas <linas@linas.org>
----
arch/powerpc/platforms/pseries/eeh_driver.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
Index: linux-2.6.16-git6/arch/powerpc/platforms/pseries/eeh_driver.c
===================================================================
--- linux-2.6.16-git6.orig/arch/powerpc/platforms/pseries/eeh_driver.c 2006-03-24 16:46:25.836892186 -0600
+++ linux-2.6.16-git6/arch/powerpc/platforms/pseries/eeh_driver.c 2006-03-24 16:58:55.305489138 -0600
@@ -257,6 +257,7 @@ void handle_eeh_events (struct eeh_event
struct pci_bus *frozen_bus;
int rc = 0;
enum pci_ers_result result = PCI_ERS_RESULT_NONE;
+ const char *pci_str, *drv_str;
frozen_dn = find_device_pe(event->dn);
frozen_bus = pcibios_find_pci_bus(frozen_dn);
@@ -291,6 +292,13 @@ void handle_eeh_events (struct eeh_event
frozen_pdn = PCI_DN(frozen_dn);
frozen_pdn->eeh_freeze_count++;
+
+ pci_str = pci_name (frozen_pdn->pcidev);
+ drv_str = pcid_name (frozen_pdn->pcidev);
+ if (!pci_str) {
+ pci_str = pci_name (event->dev);
+ drv_str = pcid_name (event->dev);
+ }
if (frozen_pdn->eeh_freeze_count > EEH_MAX_ALLOWED_FREEZES)
goto hard_fail;
@@ -306,9 +314,7 @@ void handle_eeh_events (struct eeh_event
eeh_slot_error_detail(frozen_pdn, 1 /* Temporary Error */);
printk(KERN_WARNING
"EEH: This PCI device has failed %d times since last reboot: %s - %s\n",
- frozen_pdn->eeh_freeze_count,
- pci_name (frozen_pdn->pcidev),
- pcid_name(frozen_pdn->pcidev));
+ frozen_pdn->eeh_freeze_count, drv_str, pci_str);
/* Walk the various device drivers attached to this slot through
* a reset sequence, giving each an opportunity to do what it needs
@@ -360,9 +366,7 @@ hard_fail:
"EEH: PCI device %s - %s has failed %d times \n"
"and has been permanently disabled. Please try reseating\n"
"this device or replacing it.\n",
- pci_name (frozen_pdn->pcidev),
- pcid_name(frozen_pdn->pcidev),
- frozen_pdn->eeh_freeze_count);
+ drv_str, pci_str, frozen_pdn->eeh_freeze_count);
eeh_slot_error_detail(frozen_pdn, 2 /* Permanent Error */);
^ permalink raw reply
* Re: [PATCH] powerpc: dynamic probe - use ppc_md.pci_probe_mode()
From: Linas Vepstas @ 2006-03-24 22:48 UTC (permalink / raw)
To: John Rose; +Cc: Paul Mackerras, External List
In-Reply-To: <1143220753.2567.22.camel@sinatra.austin.ibm.com>
On Fri, Mar 24, 2006 at 11:19:13AM -0600, John Rose wrote:
> + if (mode == PCI_PROBE_DEVTREE) {
> + printk("%s: jhr: new probe\n", __FUNCTION__);
Did you intend to leave in this print statement? Its looks
suspiciously like a debug print.
--linas
^ permalink raw reply
* Re: Diagnostic tool
From: David Hawkins @ 2006-03-24 22:39 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA9112796415019ECEBA@xmb-sjc-212.amer.cisco.com>
Bizhan Gholikhamseh (bgholikh) wrote:
> Hi,
>
> I am using PQIII Freescale cpu 8541 on a custom board.
>
> Is anyone aware of diagnostics tool as a kernel module to test cpu,
> memory and other hardware components that may be out there. This is
> normally a test suit that will be used manufacturing for extensive HW
> testing.
>
The AMCC Yosemite 440EP board came with a proprietry
package called Kozio Diagnostics. If you don't get
any nice open source suggestions, you could check
them out. On the Yosemite board, they were run from
the U-Boot prompt as a stand-alone application.
Personally I'm not a fan of proprietry stuff, and would
write my own, but since you asked ...
Dave
^ permalink raw reply
* RE: memory with __get_free_pages and disabling caching
From: Benjamin Herrenschmidt @ 2006-03-24 22:30 UTC (permalink / raw)
To: Kallol Biswas; +Cc: linuxppc-dev
In-Reply-To: <478F19F21671F04298A2116393EEC3D50A9C21@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
On Fri, 2006-03-24 at 11:13 -0800, Kallol Biswas wrote:
> We have a little endian device on a PPC 440GX based system.
> The descriptors need to be swapped. With E bit turned on we can save swapping time.
>
> May be all the pages with _get_free_page already are mapped with large tlb entry.
>
> How about making a window (ptes) like consistent memory?
If you allocate with consistent allocator on 4xx, you should be able to
hack the PTEs to set the E bit, but I think it's not necessary. We've
been swapping descriptor for ages without any noticeable performance
loss since pretty much all network devices have little endian descriptor
rings :) Look into using the {ld,st}_le{16,32} inlines, they use the
native swapped load/store instructions of the CPU to store things in
little endian format. They shouldn't cost more or at least not
significantly more than normal load/stores.
Ben.
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Thursday, March 23, 2006 7:06 PM
> To: Kallol Biswas
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: memory with __get_free_pages and disabling caching
>
> On Thu, 2006-03-23 at 18:15 -0800, Kallol Biswas wrote:
> > Hello,
> > Is there an easy way to set page table attributes for the
> > memory returned by __get_free_pages()?
> >
> > I need to be able to turn off caching and turn on E bit for these
> > pages.
>
> The Evil bit ? heh ! what are you trying to do ? here ... you can always create a virtual mapping to those pages with different attributes but that's nor recommended as some processors will shoke pretty badly if you end up with both cacheable and non-cacheable mappings for the same page.
> However, it's not always possible to unmap the initial mapping since it's common to use things like large pages, BATs, large TLB entries etc... to map kernel memory..
>
> > I tried to walk through the page tables data structures to get the
> > pte, but it seems that the pmd is not present for the pages. If
> > someone has done investigation on this before please send me a reply.
> >
> Kernel linear memory isn't necessarily mapped by the page tables. What are you trying to do and with what processor ?
>
>
>
> Ben.
>
^ permalink raw reply
* RE: memory with __get_free_pages and disabling caching
From: Paul Mackerras @ 2006-03-24 22:17 UTC (permalink / raw)
To: Kallol Biswas; +Cc: linuxppc-dev
In-Reply-To: <478F19F21671F04298A2116393EEC3D50A9C21@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
Kallol Biswas writes:
> We have a little endian device on a PPC 440GX based system.
> The descriptors need to be swapped. With E bit turned on we can save
> swapping time.
Writing the descriptors with stwbrx should be just as fast as using
stw, and eliminates the need for a special mapping.
If you need it to be cache-inhibited, you should be using
dma_alloc_coherent() or pci_alloc_consistent().
Paul.
^ permalink raw reply
* Diagnostic tool
From: Bizhan Gholikhamseh (bgholikh) @ 2006-03-24 22:05 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 320 bytes --]
Hi,
I am using PQIII Freescale cpu 8541 on a custom board.
Is anyone aware of diagnostics tool as a kernel module to test cpu,
memory and other hardware components that may be out there. This is
normally a test suit that will be used manufacturing for extensive HW
testing.
Thanks and Regards,
Bizhan
[-- Attachment #2: Type: text/html, Size: 790 bytes --]
^ permalink raw reply
* [PATCH] PCI Error Recovery: e1000 network device driver
From: Linas Vepstas @ 2006-03-24 22:00 UTC (permalink / raw)
To: Jeff Garzik, john.ronciak, jesse.brandeburg, jeffrey.t.kirsher
Cc: netdev, linux-pci, linux-kernel, linuxppc-dev
Jeff,
Can you please review and forward this patch upstream? A previous
version of this patch has been ack'ed by Jesse Brandeburg, one
of the e1000 maintainers.
--linas
[PATCH] PCI Error Recovery: e1000 network device driver
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the intel gigabit
ethernet e1000 device driver. The patch has been tested, and appears
to work well.
Signed-off-by: Linas Vepstas <linas@linas.org>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
----
drivers/net/e1000/e1000_main.c | 114 ++++++++++++++++++++++++++++++++++++++++-
1 files changed, 113 insertions(+), 1 deletion(-)
Index: linux-2.6.16-git6/drivers/net/e1000/e1000_main.c
===================================================================
--- linux-2.6.16-git6.orig/drivers/net/e1000/e1000_main.c 2006-03-23 15:48:01.000000000 -0600
+++ linux-2.6.16-git6/drivers/net/e1000/e1000_main.c 2006-03-24 15:14:40.431371705 -0600
@@ -226,6 +226,16 @@ static int e1000_resume(struct pci_dev *
static void e1000_netpoll (struct net_device *netdev);
#endif
+static pci_ers_result_t e1000_io_error_detected(struct pci_dev *pdev,
+ pci_channel_state_t state);
+static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev);
+static void e1000_io_resume(struct pci_dev *pdev);
+
+static struct pci_error_handlers e1000_err_handler = {
+ .error_detected = e1000_io_error_detected,
+ .slot_reset = e1000_io_slot_reset,
+ .resume = e1000_io_resume,
+};
static struct pci_driver e1000_driver = {
.name = e1000_driver_name,
@@ -235,8 +245,9 @@ static struct pci_driver e1000_driver =
/* Power Managment Hooks */
#ifdef CONFIG_PM
.suspend = e1000_suspend,
- .resume = e1000_resume
+ .resume = e1000_resume,
#endif
+ .err_handler = &e1000_err_handler,
};
MODULE_AUTHOR("Intel Corporation, <linux.nics@intel.com>");
@@ -3063,6 +3074,10 @@ e1000_update_stats(struct e1000_adapter
#define PHY_IDLE_ERROR_COUNT_MASK 0x00FF
+ /* Prevent stats update while adapter is being reset */
+ if (adapter->link_speed == 0)
+ return;
+
spin_lock_irqsave(&adapter->stats_lock, flags);
/* these counters are modified from e1000_adjust_tbi_stats,
@@ -4631,4 +4646,101 @@ e1000_netpoll(struct net_device *netdev)
}
#endif
+/**
+ * e1000_io_error_detected - called when PCI error is detected
+ * @pdev: Pointer to PCI device
+ * @state: The current pci conneection state
+ *
+ * This function is called after a PCI bus error affecting
+ * this device has been detected.
+ */
+static pci_ers_result_t e1000_io_error_detected(struct pci_dev *pdev, pci_channel_state_t state)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev->priv;
+
+ netif_device_detach(netdev);
+
+ if (netif_running(netdev))
+ e1000_down(adapter);
+
+ /* Request a slot slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * e1000_io_slot_reset - called after the pci bus has been reset.
+ * @pdev: Pointer to PCI device
+ *
+ * Restart the card from scratch, as if from a cold-boot. Implementation
+ * resembles the first-half of the e1000_resume routine.
+ */
+static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev->priv;
+
+ if (pci_enable_device(pdev)) {
+ printk(KERN_ERR "e1000: Cannot re-enable PCI device after reset.\n");
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+ pci_set_master(pdev);
+
+ pci_enable_wake(pdev, 3, 0);
+ pci_enable_wake(pdev, 4, 0); /* 4 == D3 cold */
+
+ /* Perform card reset only on one instance of the card */
+ if(0 != PCI_FUNC (pdev->devfn))
+ return PCI_ERS_RESULT_RECOVERED;
+
+ e1000_reset(adapter);
+ E1000_WRITE_REG(&adapter->hw, WUS, ~0);
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * e1000_io_resume - called when traffic can start flowing again.
+ * @pdev: Pointer to PCI device
+ *
+ * This callback is called when the error recovery driver tells us that
+ * its OK to resume normal operation. Implementation resembles the
+ * second-half of the e1000_resume routine.
+ */
+static void e1000_io_resume(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev->priv;
+ uint32_t manc, swsm;
+
+ if(netif_running(netdev)) {
+ if (e1000_up(adapter)) {
+ printk("e1000: can't bring device back up after reset\n");
+ return;
+ }
+ }
+
+ netif_device_attach(netdev);
+
+ if(adapter->hw.mac_type >= e1000_82540 &&
+ adapter->hw.media_type == e1000_media_type_copper) {
+ manc = E1000_READ_REG(&adapter->hw, MANC);
+ manc &= ~(E1000_MANC_ARP_EN);
+ E1000_WRITE_REG(&adapter->hw, MANC, manc);
+ }
+
+ switch(adapter->hw.mac_type) {
+ case e1000_82573:
+ swsm = E1000_READ_REG(&adapter->hw, SWSM);
+ E1000_WRITE_REG(&adapter->hw, SWSM,
+ swsm | E1000_SWSM_DRV_LOAD);
+ break;
+ default:
+ break;
+ }
+
+ if(netif_running(netdev))
+ mod_timer(&adapter->watchdog_timer, jiffies);
+}
+
/* e1000_main.c */
^ permalink raw reply
* Re: pci_dlpar.c & probe mode
From: Benjamin Herrenschmidt @ 2006-03-24 21:48 UTC (permalink / raw)
To: John Rose; +Cc: External List
In-Reply-To: <1143217005.2567.12.camel@sinatra.austin.ibm.com>
On Fri, 2006-03-24 at 10:16 -0600, John Rose wrote:
> > I noticed that pcibios_add_pci_devices() test the platform type to
> > decide wether to do a device-tree based probe or a direct PCI probe. Why
> > can't it use ppc_md.probe_mode() like the rest of the PCI code does ?
>
> I can't see a good reason either! :) I'll have a patch in two shakes of
> a lamb's tail.
>
> On a related note, I don't understand why devtree-based probe is only
> desirable for the LPAR case (on pSeries).
I think it was dictated by a conservative approach .. it's necessary for
LPAR and we didn't want to change the behaviour on older machines...
besides, things like bare metal may not provide the PCI nodes in OF and
use the same code base.
> Also, do we anticipate future probe modes for new platforms or
> something? Adding such logic to ppc_md seems like mucho infrastructure
> to answer a simple question (lpar or not). For exmaple, _machine gets
> used all over the pmac code.
_machine is gone, see my last patch ... It's not only about lpar or
not .. on powermac, it's really a per-bus & per machine generation
decision wether to trust OF or not..
Ben.
^ permalink raw reply
* Re: memory with __get_free_pages and disabling caching
From: Kumar Gala @ 2006-03-24 19:29 UTC (permalink / raw)
To: Kallol Biswas; +Cc: linuxppc-dev
In-Reply-To: <478F19F21671F04298A2116393EEC3D50A9C21@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
On Mar 24, 2006, at 1:13 PM, Kallol Biswas wrote:
>
> We have a little endian device on a PPC 440GX based system.
> The descriptors need to be swapped. With E bit turned on we can
> save swapping time.
What's the device and what bus is it on? Are you writing a standard
kernel driver for it?
> May be all the pages with _get_free_page already are mapped with
> large tlb entry.
>
> How about making a window (ptes) like consistent memory?
>
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Thursday, March 23, 2006 7:06 PM
> To: Kallol Biswas
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: memory with __get_free_pages and disabling caching
>
> On Thu, 2006-03-23 at 18:15 -0800, Kallol Biswas wrote:
>> Hello,
>> Is there an easy way to set page table attributes for the
>> memory returned by __get_free_pages()?
>>
>> I need to be able to turn off caching and turn on E bit for these
>> pages.
>
> The Evil bit ? heh ! what are you trying to do ? here ... you can
> always create a virtual mapping to those pages with different
> attributes but that's nor recommended as some processors will shoke
> pretty badly if you end up with both cacheable and non-cacheable
> mappings for the same page.
> However, it's not always possible to unmap the initial mapping
> since it's common to use things like large pages, BATs, large TLB
> entries etc... to map kernel memory..
>
>> I tried to walk through the page tables data structures to get the
>> pte, but it seems that the pmd is not present for the pages. If
>> someone has done investigation on this before please send me a reply.
>>
> Kernel linear memory isn't necessarily mapped by the page tables.
> What are you trying to do and with what processor ?
>
>
>
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: memory with __get_free_pages and disabling caching
From: Kallol Biswas @ 2006-03-24 19:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
We have a little endian device on a PPC 440GX based system.
The descriptors need to be swapped. With E bit turned on we can save swapping time.
May be all the pages with _get_free_page already are mapped with large tlb entry.
How about making a window (ptes) like consistent memory?
-----Original Message-----
From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
Sent: Thursday, March 23, 2006 7:06 PM
To: Kallol Biswas
Cc: linuxppc-dev@ozlabs.org
Subject: Re: memory with __get_free_pages and disabling caching
On Thu, 2006-03-23 at 18:15 -0800, Kallol Biswas wrote:
> Hello,
> Is there an easy way to set page table attributes for the
> memory returned by __get_free_pages()?
>
> I need to be able to turn off caching and turn on E bit for these
> pages.
The Evil bit ? heh ! what are you trying to do ? here ... you can always create a virtual mapping to those pages with different attributes but that's nor recommended as some processors will shoke pretty badly if you end up with both cacheable and non-cacheable mappings for the same page.
However, it's not always possible to unmap the initial mapping since it's common to use things like large pages, BATs, large TLB entries etc... to map kernel memory..
> I tried to walk through the page tables data structures to get the
> pte, but it seems that the pmd is not present for the pages. If
> someone has done investigation on this before please send me a reply.
>
Kernel linear memory isn't necessarily mapped by the page tables. What are you trying to do and with what processor ?
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Kill machine numbers
From: Olof Johansson @ 2006-03-24 18:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Paul Mackerras, Linux Kernel list
In-Reply-To: <1143187298.3710.3.camel@localhost.localdomain>
On Fri, Mar 24, 2006 at 07:01:38PM +1100, Benjamin Herrenschmidt wrote:
>
> > It would be very useful to print the ppc_md.name of the found machine
> > here, even without debugging enabled.
>
> Not sure ... without debugging enabled, it's likely that you won't see
> anything that early anyway :)
True, but it'd be in the dmesg, and get printed when the console comes up.
> > It's really weird that IBM chose to use "chrp" to describe a
> > PAPR-compliant platform. I guess it's for historical reasons, but it
> > sure isn't CHRP any more.
>
> Yup, I'm trying to get that changed in the architecture but even if I'm
> successful, we'll have to deal with existing machines.
Right, it was mostly a side comment.
> > > + is _not_ "chrp" as this will be matched by the kernel to be a
> > > + CHRP machine on 32 bits kernel or a pSeries on 64 bits kernels
> >
> > ...or a PAPR-compliant machine on 64-bit kernels.
> >
> > (Also, "xx-bit kernels", not "xx bits kernels").
>
> yeah yeah :) Thanks for the review anyway !
Hey, I couldn't find much technical issues, so I ended up reading your
comments and picking errors there instead. :-)
-Olof
^ permalink raw reply
* powerpc: fix hvc-rtas comments
From: Arnd Bergmann @ 2006-03-24 18:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, cbe-oss-dev, linux-kernel
In-Reply-To: <200603232336.19683.arnd@arndb.de>
As notice by Olof Johansson, the comment about module_exit
in hvc_rtas is rather confusing, so remove it.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
Index: linus-2.6/drivers/char/hvc_rtas.c
===================================================================
--- linus-2.6.orig/drivers/char/hvc_rtas.c
+++ linus-2.6/drivers/char/hvc_rtas.c
@@ -119,7 +119,7 @@ static void __exit hvc_rtas_exit(void)
if (hvc_rtas_dev)
hvc_remove(hvc_rtas_dev);
}
-module_exit(hvc_rtas_exit); /* before drivers/char/hvc_console.c */
+module_exit(hvc_rtas_exit);
/* This will happen prior to module init. There is no tty at this time? */
static int hvc_rtas_console_init(void)
^ permalink raw reply
* [PATCH] powerpc: fix cell platform detection
From: Arnd Bergmann @ 2006-03-24 18:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Linux Kernel list, cbe-oss-dev
In-Reply-To: <200603240946.51793.arnd@arndb.de>
All future firmware should have 'CBEA' in the compatible
property in order to tell us that we are running on the
cell platform, so check for that as well as the now
deprecated value we have been using so far.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
This applies on top of the 'Kill machine numbers' patch
from Ben Herrenschmidt.
Index: linus-2.6/arch/powerpc/platforms/cell/setup.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/setup.c
+++ linus-2.6/arch/powerpc/platforms/cell/setup.c
@@ -198,7 +198,14 @@ static void __init cell_init_early(void)
static int __init cell_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (!of_flat_dt_is_compatible(root, "IBM,CPB"))
+
+ /*
+ * CPBW was used on early prototypes and will be removed.
+ * The correct identification is CBEA.
+ */
+ if (!of_flat_dt_is_compatible(root, "IBM,CPBW-1.0") &&
+ !of_flat_dt_is_compatible(root, "IBM,CBEA") &&
+ !of_flat_dt_is_compatible(root, "CBEA"))
return 0;
return 1;
^ permalink raw reply
* [PATCH] spufs: Fix endless protection fault on LS writes by SPE.
From: Arnd Bergmann @ 2006-03-24 18:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Arnd Bergmann, cbe-oss-dev, linux-kernel
In-Reply-To: <20060323203423.620978000@dyn-9-152-242-103.boeblingen.de.ibm.com>
If an SPE attempts a DMA put to a local store after already doing
a get, the kernel must update the HW PTE to allow the write access.
This case was not being handled correctly.
From: Mike Kistler <mkistler@us.ibm.com>
Signed-off-by: Mike Kistler <mkistler@us.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
diff -ur linux-2.6.15/arch/powerpc/platforms/cell/spu_base.c linux-2.6.15.fixed/arch/powerpc/platforms/cell/spu_base.c
--- linux-2.6.15/arch/powerpc/platforms/cell/spu_base.c 2006-03-22 12:30:07.000000000 -0600
+++ linux-2.6.15.fixed/arch/powerpc/platforms/cell/spu_base.c 2006-03-22 10:21:26.000000000 -0600
@@ -486,14 +486,13 @@
ea = spu->dar;
dsisr = spu->dsisr;
- if (dsisr & MFC_DSISR_PTE_NOT_FOUND) {
+ if (dsisr & (MFC_DSISR_PTE_NOT_FOUND | MFC_DSISR_ACCESS_DENIED)) {
access = (_PAGE_PRESENT | _PAGE_USER);
access |= (dsisr & MFC_DSISR_ACCESS_PUT) ? _PAGE_RW : 0UL;
if (hash_page(ea, access, 0x300) != 0)
error |= CLASS1_ENABLE_STORAGE_FAULT_INTR;
}
- if ((error & CLASS1_ENABLE_STORAGE_FAULT_INTR) ||
- (dsisr & MFC_DSISR_ACCESS_DENIED)) {
+ if (error & CLASS1_ENABLE_STORAGE_FAULT_INTR) {
if ((ret = spu_handle_mm_fault(spu)) != 0)
error |= CLASS1_ENABLE_STORAGE_FAULT_INTR;
else
^ permalink raw reply
* [PATCH] powerpc: use guarded ioremap for on-chip mappings
From: Arnd Bergmann @ 2006-03-24 18:47 UTC (permalink / raw)
To: linuxppc-dev
Cc: stk, linux-kernel, Milton Miller, Paul Mackerras, hpenner,
Arnd Bergmann, cbe-oss-dev
In-Reply-To: <1143152153.4257.28.camel@localhost.localdomain>
Subject: powerpc: use guarded ioremap for cell on-chip mappings
I'm not sure where the information came from, but I assumed
that doing cache-inhibited mappings for mmio regions was
sufficient.
It seems we also need the guarded bit set, like everyone
else, which is the default for ioremap.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Index: linus-2.6/arch/powerpc/platforms/cell/interrupt.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/interrupt.c
+++ linus-2.6/arch/powerpc/platforms/cell/interrupt.c
@@ -226,9 +226,7 @@ static int setup_iic_hardcoded(void)
regs += 0x20;
printk(KERN_INFO "IIC for CPU %d at %lx\n", cpu, regs);
- iic->regs = __ioremap(regs, sizeof(struct iic_regs),
- _PAGE_NO_CACHE);
-
+ iic->regs = ioremap(regs, sizeof(struct iic_regs));
iic->target_id = (nodeid << 4) + ((cpu & 1) ? 0xf : 0xe);
}
@@ -269,14 +267,12 @@ static int setup_iic(void)
}
iic = &per_cpu(iic, np[0]);
- iic->regs = __ioremap(regs[0], sizeof(struct iic_regs),
- _PAGE_NO_CACHE);
+ iic->regs = ioremap(regs[0], sizeof(struct iic_regs));
iic->target_id = ((np[0] & 2) << 3) + ((np[0] & 1) ? 0xf : 0xe);
printk("IIC for CPU %d at %lx mapped to %p\n", np[0], regs[0], iic->regs);
iic = &per_cpu(iic, np[1]);
- iic->regs = __ioremap(regs[2], sizeof(struct iic_regs),
- _PAGE_NO_CACHE);
+ iic->regs = ioremap(regs[2], sizeof(struct iic_regs));
iic->target_id = ((np[1] & 2) << 3) + ((np[1] & 1) ? 0xf : 0xe);
printk("IIC for CPU %d at %lx mapped to %p\n", np[1], regs[2], iic->regs);
Index: linus-2.6/arch/powerpc/platforms/cell/iommu.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/iommu.c
+++ linus-2.6/arch/powerpc/platforms/cell/iommu.c
@@ -344,8 +344,8 @@ static int cell_map_iommu_hardcoded(int
/* node 0 */
iommu = &cell_iommus[0];
- iommu->mapped_base = __ioremap(0x20000511000, 0x1000, _PAGE_NO_CACHE);
- iommu->mapped_mmio_base = __ioremap(0x20000510000, 0x1000, _PAGE_NO_CACHE);
+ iommu->mapped_base = ioremap(0x20000511000, 0x1000);
+ iommu->mapped_mmio_base = ioremap(0x20000510000, 0x1000);
enable_mapping(iommu->mapped_base, iommu->mapped_mmio_base);
@@ -357,8 +357,8 @@ static int cell_map_iommu_hardcoded(int
/* node 1 */
iommu = &cell_iommus[1];
- iommu->mapped_base = __ioremap(0x30000511000, 0x1000, _PAGE_NO_CACHE);
- iommu->mapped_mmio_base = __ioremap(0x30000510000, 0x1000, _PAGE_NO_CACHE);
+ iommu->mapped_base = ioremap(0x30000511000, 0x1000);
+ iommu->mapped_mmio_base = ioremap(0x30000510000, 0x1000);
enable_mapping(iommu->mapped_base, iommu->mapped_mmio_base);
@@ -407,8 +407,8 @@ static int cell_map_iommu(void)
iommu->base = *base;
iommu->mmio_base = *mmio_base;
- iommu->mapped_base = __ioremap(*base, 0x1000, _PAGE_NO_CACHE);
- iommu->mapped_mmio_base = __ioremap(*mmio_base, 0x1000, _PAGE_NO_CACHE);
+ iommu->mapped_base = ioremap(*base, 0x1000);
+ iommu->mapped_mmio_base = ioremap(*mmio_base, 0x1000);
enable_mapping(iommu->mapped_base,
iommu->mapped_mmio_base);
Index: linus-2.6/arch/powerpc/platforms/cell/pervasive.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/pervasive.c
+++ linus-2.6/arch/powerpc/platforms/cell/pervasive.c
@@ -203,7 +203,7 @@ found:
pr_debug("pervasive area for CPU %d at %lx, size %x\n",
cpu, real_address, size);
- p->regs = __ioremap(real_address, size, _PAGE_NO_CACHE);
+ p->regs = ioremap(real_address, size);
p->thread = thread;
return 0;
}
Index: linus-2.6/arch/powerpc/platforms/cell/spider-pic.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/spider-pic.c
+++ linus-2.6/arch/powerpc/platforms/cell/spider-pic.c
@@ -159,7 +159,7 @@ void spider_init_IRQ_hardcoded(void)
for (node = 0; node < num_present_cpus()/2; node++) {
spiderpic = pics[node];
printk(KERN_DEBUG "SPIDER addr: %lx\n", spiderpic);
- spider_pics[node] = __ioremap(spiderpic, 0x800, _PAGE_NO_CACHE);
+ spider_pics[node] = ioremap(spiderpic, 0x800);
for (n = 0; n < IIC_NUM_EXT; n++) {
int irq = n + IIC_EXT_OFFSET + node * IIC_NODE_STRIDE;
get_irq_desc(irq)->handler = &spider_pic;
@@ -210,7 +210,7 @@ void spider_init_IRQ(void)
if ( n != 2)
printk("reg property with invalid number of elements \n");
- spider_pics[node] = __ioremap(spider_reg, 0x800, _PAGE_NO_CACHE);
+ spider_pics[node] = ioremap(spider_reg, 0x800);
printk("SPIDER addr: %lx with %i addr_cells mapped to %p\n",
spider_reg, n, spider_pics[node]);
^ permalink raw reply
* [PATCH] powerpc: fix spider-pic affinity setting
From: Arnd Bergmann @ 2006-03-24 18:46 UTC (permalink / raw)
To: linuxppc-dev
Cc: Arnd Bergmann, Paul Mackerras, linux-kernel, Milton Miller,
cbe-oss-dev
In-Reply-To: <200603241905.04356.arnd.bergmann@de.ibm.com>
As noticed by Milton Miller, setting the initial affinity in
spider-pic can go wrong if the target node field was not orinally
empty.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
--- linus-2.6.orig/arch/powerpc/platforms/cell/spider-pic.c
+++ linus-2.6/arch/powerpc/platforms/cell/spider-pic.c
@@ -88,7 +88,7 @@ static void spider_enable_irq(unsigned i
void __iomem *cfg = spider_get_irq_config(irq);
irq = spider_get_nr(irq);
- out_be32(cfg, in_be32(cfg) | 0x3107000eu | nodeid);
+ out_be32(cfg, (in_be32(cfg) & ~0xf0)| 0x3107000eu | nodeid);
out_be32(cfg + 4, in_be32(cfg + 4) | 0x00020000u | irq);
}
^ permalink raw reply
* Re: [PATCH] powerpc: legacy_serial loop cleanup
From: Hollis Blanchard @ 2006-03-24 18:26 UTC (permalink / raw)
To: linuxppc-dev, mikey; +Cc: michael
In-Reply-To: <20060324041727.F131267B56@ozlabs.org>
On Thursday 23 March 2006 22:17, Michael Neuling wrote:
> We only ever execute the loop once, so let's move it to a function
> making it more readable. Cleanup patch, no functional change.
I don't understand: it's only used once, so make it a function? Why not just
change the "while" to an "if"?
Regardless, two style issues:
- remove the plain "return"
- reduce indenting like so:
if (console < 0)
return;
struct legacy_serial_info *info = ...
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> arch/powerpc/kernel/legacy_serial.c | 39
+++++++++++++++++++-----------------
> 1 files changed, 21 insertions(+), 18 deletions(-)
>
> Index: linux-2.6-linus/arch/powerpc/kernel/legacy_serial.c
> ===================================================================
> --- linux-2.6-linus.orig/arch/powerpc/kernel/legacy_serial.c
> +++ linux-2.6-linus/arch/powerpc/kernel/legacy_serial.c
> @@ -236,6 +236,26 @@ static int __init add_legacy_pci_port(st
> }
> #endif
>
> +static void __init setup_legacy_serial_console(int console)
> +{
> + if (console >= 0) {
> + struct legacy_serial_info *info =
> + &legacy_serial_infos[legacy_serial_console];
> + void __iomem *addr;
> +
> + if (info->taddr == 0)
> + return;
> + addr = ioremap(info->taddr, 0x1000);
> + if (addr == NULL)
> + return;
> + if (info->speed == 0)
> + info->speed = udbg_probe_uart_speed(addr, info->clock);
> + DBG("default console speed = %d\n", info->speed);
> + udbg_init_uart(addr, info->speed, info->clock);
> + }
> + return;
> +}
> +
> /*
> * This is called very early, as part of setup_system() or eventually
> * setup_arch(), basically before anything else in this file. This function
> @@ -319,24 +339,7 @@ void __init find_legacy_serial_ports(voi
>
> DBG("legacy_serial_console = %d\n", legacy_serial_console);
>
> - /* udbg is 64 bits only for now, that will change soon though ... */
> - while (legacy_serial_console >= 0) {
> - struct legacy_serial_info *info =
> - &legacy_serial_infos[legacy_serial_console];
> - void __iomem *addr;
> -
> - if (info->taddr == 0)
> - break;
> - addr = ioremap(info->taddr, 0x1000);
> - if (addr == NULL)
> - break;
> - if (info->speed == 0)
> - info->speed = udbg_probe_uart_speed(addr, info->clock);
> - DBG("default console speed = %d\n", info->speed);
> - udbg_init_uart(addr, info->speed, info->clock);
> - break;
> - }
> -
> + setup_legacy_serial_console(legacy_serial_console);
> DBG(" <- find_legacy_serial_port()\n");
> }
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [patch 06/13] powerpc: cell interrupt controller updates
From: Arnd Bergmann @ 2006-03-24 18:05 UTC (permalink / raw)
To: Milton Miller
Cc: stk, linux-kernel, linuxppc-dev, Paul Mackerras, hpenner,
Arnd Bergmann, cbe-oss-dev
In-Reply-To: <32140afe2349e8f1726d188eb85c780c@bga.com>
On Friday 24 March 2006 18:43, Milton Miller wrote:
> On Mar 22, 2006, at 5:00 PM, Arnd Bergmann wrote:
> > static void spider_enable_irq(unsigned int irq)
> > {
> > + int nodeid = (irq / IIC_NODE_STRIDE) * 0x10;
> > void __iomem *cfg = spider_get_irq_config(irq);
> > irq = spider_get_nr(irq);
> >
> > - out_be32(cfg, in_be32(cfg) | 0x3107000eu);
> > + out_be32(cfg, in_be32(cfg) | 0x3107000eu | nodeid);
> > out_be32(cfg + 4, in_be32(cfg + 4) | 0x00020000u | irq);
> > }
> >
>
> I just did a quick read of the code, but my first thought is what if
> some other node id was previously set? Perhaps you should mask off
> some bits before or'ing in the node id?
Good point. The firmware always sets nodeid zero (or the same one that
we set), but I can't see any reason why we should take that for granted.
Thanks,
Arnd <><
^ permalink raw reply
* Re: [patch 06/13] powerpc: cell interrupt controller updates
From: Milton Miller @ 2006-03-24 17:43 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, stk, linux-kernel, linuxppc-dev, Paul Mackerras,
hpenner, cbe-oss-dev
In-Reply-To: <20060323203521.862355000@dyn-9-152-242-103.boeblingen.de.ibm.com>
On Mar 22, 2006, at 5:00 PM, Arnd Bergmann wrote:
> static void spider_enable_irq(unsigned int irq)
> {
> + int nodeid = (irq / IIC_NODE_STRIDE) * 0x10;
> void __iomem *cfg = spider_get_irq_config(irq);
> irq = spider_get_nr(irq);
>
> - out_be32(cfg, in_be32(cfg) | 0x3107000eu);
> + out_be32(cfg, in_be32(cfg) | 0x3107000eu | nodeid);
> out_be32(cfg + 4, in_be32(cfg + 4) | 0x00020000u | irq);
> }
>
I just did a quick read of the code, but my first thought is what if
some other node id was previously set? Perhaps you should mask off
some bits before or'ing in the node id?
milton
^ permalink raw reply
* [PATCH] powerpc: dynamic probe - use ppc_md.pci_probe_mode()
From: John Rose @ 2006-03-24 17:25 UTC (permalink / raw)
To: benh; +Cc: External List, Paul Mackerras
In-Reply-To: <1143220753.2567.22.camel@sinatra.austin.ibm.com>
Change the dynamic PCI probe function for pSeries to use
ppc_md.pci_probe_mode() when appropriate.
Signed-off-by: John Rose <johnrose@austin.ibm.com>
---
Actually - how about a version without debug prints!? Original change
suggested by BenH. Tested on POWER5.
Thanks-
John
diff -puN arch/powerpc/platforms/pseries/pci_dlpar.c~use_probe_mode arch/powerpc/platforms/pseries/pci_dlpar.c
--- 2_6_linus/arch/powerpc/platforms/pseries/pci_dlpar.c~use_probe_mode 2006-03-24 09:57:08.000000000 -0600
+++ 2_6_linus-johnrose/arch/powerpc/platforms/pseries/pci_dlpar.c 2006-03-24 11:26:23.000000000 -0600
@@ -152,20 +152,24 @@ pcibios_pci_config_bridge(struct pci_dev
void
pcibios_add_pci_devices(struct pci_bus * bus)
{
- int slotno, num;
+ int slotno, num, mode;
struct pci_dev *dev;
struct device_node *dn = pci_bus_to_OF_node(bus);
eeh_add_device_tree_early(dn);
- if (_machine == PLATFORM_PSERIES_LPAR) {
+ mode = PCI_PROBE_NORMAL;
+ if (ppc_md.pci_probe_mode)
+ mode = ppc_md.pci_probe_mode(bus);
+
+ if (mode == PCI_PROBE_DEVTREE) {
/* use ofdt-based probe */
of_scan_bus(dn, bus);
if (!list_empty(&bus->devices)) {
pcibios_fixup_new_pci_devices(bus, 0);
pci_bus_add_devices(bus);
}
- } else {
+ } else if (mode == PCI_PROBE_NORMAL) {
/* use legacy probe */
slotno = PCI_SLOT(PCI_DN(dn->child)->devfn);
num = pci_scan_slot(bus, PCI_DEVFN(slotno, 0));
_
^ permalink raw reply
* [PATCH] powerpc: dynamic probe - use ppc_md.pci_probe_mode()
From: John Rose @ 2006-03-24 17:19 UTC (permalink / raw)
To: benh; +Cc: External List, Paul Mackerras
Change the dynamic PCI probe function for pSeries to use
ppc_md.pci_probe_mode() when appropriate.
Signed-off-by: John Rose <johnrose@austin.ibm.com>
---
As suggested by BenH. Tested on POWER5.
Thanks-
John
diff -puN arch/powerpc/platforms/pseries/pci_dlpar.c~use_probe_mode arch/powerpc/platforms/pseries/pci_dlpar.c
--- 2_6_cleanups/arch/powerpc/platforms/pseries/pci_dlpar.c~use_probe_mode 2006-03-24 09:57:08.000000000 -0600
+++ 2_6_cleanups-johnrose/arch/powerpc/platforms/pseries/pci_dlpar.c 2006-03-24 10:12:49.000000000 -0600
@@ -152,20 +152,26 @@ pcibios_pci_config_bridge(struct pci_dev
void
pcibios_add_pci_devices(struct pci_bus * bus)
{
- int slotno, num;
+ int slotno, num, mode;
struct pci_dev *dev;
struct device_node *dn = pci_bus_to_OF_node(bus);
eeh_add_device_tree_early(dn);
- if (_machine == PLATFORM_PSERIES_LPAR) {
+ mode = PCI_PROBE_NORMAL;
+ if (ppc_md.pci_probe_mode)
+ mode = ppc_md.pci_probe_mode(bus);
+
+ if (mode == PCI_PROBE_DEVTREE) {
+ printk("%s: jhr: new probe\n", __FUNCTION__);
/* use ofdt-based probe */
of_scan_bus(dn, bus);
if (!list_empty(&bus->devices)) {
pcibios_fixup_new_pci_devices(bus, 0);
pci_bus_add_devices(bus);
}
- } else {
+ } else if (mode == PCI_PROBE_NORMAL) {
+ printk("%s: jhr: old probe\n", __FUNCTION__);
/* use legacy probe */
slotno = PCI_SLOT(PCI_DN(dn->child)->devfn);
num = pci_scan_slot(bus, PCI_DEVFN(slotno, 0));
_
^ permalink raw reply
* Re: pci_dlpar.c & probe mode
From: John Rose @ 2006-03-24 16:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: External List
In-Reply-To: <1143160576.4257.51.camel@localhost.localdomain>
> I noticed that pcibios_add_pci_devices() test the platform type to
> decide wether to do a device-tree based probe or a direct PCI probe. Why
> can't it use ppc_md.probe_mode() like the rest of the PCI code does ?
I can't see a good reason either! :) I'll have a patch in two shakes of
a lamb's tail.
On a related note, I don't understand why devtree-based probe is only
desirable for the LPAR case (on pSeries).
Also, do we anticipate future probe modes for new platforms or
something? Adding such logic to ppc_md seems like mucho infrastructure
to answer a simple question (lpar or not). For exmaple, _machine gets
used all over the pmac code.
John
^ permalink raw reply
* Re: pci-x
From: Carlos Mitidieri @ 2006-03-24 15:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <24661B8C-C4DF-4D9C-8F4A-F2E6600AFFE2@kernel.crashing.org>
On Friday 24 March 2006 15:53, Kumar Gala wrote:
> That seems like a driver problem. Does lspci show your devices after
> you boot? Also, what kernel ver are you using?
No, the device behind the bridge is not recognized, although the bridge itself
is. I am using kernel 2.6.15.
--
Carlos Mitidieri
SYSGO AG - Office Ulm
^ permalink raw reply
* Re: pci-x
From: Kumar Gala @ 2006-03-24 14:53 UTC (permalink / raw)
To: Carlos Mitidieri; +Cc: linuxppc-embedded
In-Reply-To: <200603241221.44576.carlos.mitidieri@sysgo.com>
On Mar 24, 2006, at 5:21 AM, Carlos Mitidieri wrote:
>
> On Thursday 23 March 2006 16:41, Kumar Gala wrote:
>>> Is there PCI-X support for the mpc8540ads?
>>
>> Yes. You have to make sure the board is setup (switches in the right
>> place) properly for it.
>
> Thank you for answering.
>
> Looking the manuals and schematics, I have changed the "config"
> switch in
> SW1, and now the PCI-X support is activated in the kernel at the
> system
> initialization. Nevertheless, when I plug a bridge board to the
> slot 0, I
> get the following messages:
>
> PCI: Probing PCI hardware
> PCI: Cannot allocate resource region 1 of PCI bridge 1
> PCI: bridge 1 resource 1 moved to 9ff00000..9fffffff
> PCI: Cannot allocate resource region 2 of PCI bridge 1
> PCI: bridge 1 resource 2 moved to 9fe00000..9fefffff
>
> Would you guess that this is a driver problem, or that my board
> setup is still
> incorrect?
That seems like a driver problem. Does lspci show your devices after
you boot? Also, what kernel ver are you using?
- k
^ permalink raw reply
* MTD physmap issues trying to map flash
From: Randy Smith @ 2006-03-24 13:32 UTC (permalink / raw)
To: linuxppc-embedded
Hello everyone,
I have been trying to get my flash memory to show up as an mtd device in
my 2.4.25 kernel and I get the following error:
physmap flash device: 0 at 0
__ioremap(): phys addr 00000000 is RAM lr c000f67c
Failed to ioremap
My hardware is based on the Icecube reference design but uses one
Spansion S29G128M-R2 16 MByte flash chip at physical address 0xff00000.
I am using u-boot 1.1.4 and the flash operates correctly in that
environment (after some tweaking). I am using a vanilla 2.4.25 linux
kernel from DENX's ELDK 3.1 and I have tried almost every incantation
regarding MTD configuration but no joy.
Some questions:
1. Does 2.4.25 expect the physmap_map structure to be populated by
u-boot and if so, where should I look in u-boot to make that happen?
2. I am assuming that this chip is CFI compliant and should show up
with that probing (and AMD support) enabled. Does it matter if turn on
both CFI and JEDEC probes? Or put another way, why should I have to
probe if this information is passed by u-boot, if it is?
3. How does the partitioning (command line) of the chip effect the
recognition of the chip?
4. What should I put in the physmap menuconfig line for the physical
address and size of the chip? I am using 0xff000000 and 0x01000000. Is
this correct and something else is broken?
5. Is there a patch to the kernel or u-boot that addresses this type of
failure?
Thanks,
Randy Smith
Software Engineer
ImageMap, Inc.
^ 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