* Re: [PATCH v3] powerpc: fix suspend states again
From: Johannes Berg @ 2007-05-01 14:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <1177933035.5102.33.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 927 bytes --]
On Mon, 2007-04-30 at 13:37 +0200, Johannes Berg wrote:
> In commit 0fba3a1f39f8b0a50b56c8b068fa52131cbc84c2 (a very long time ago,
> May 2006), I fixed a bug that caused powermacs to crash when you tried
> entering standby/mem suspend states.
>
> As I'm now getting more familiar with the suspend code I notice a few
> more things:
[...]
Regardless of the follow-up pmu pm_ops patch you should really merge
this patch since I changed the generic pm_ops infrastructure to be less
broken, and the current code in .21 may sometimes work due to the
breakage that is now no longer there; pm_ops will now not be invoked for
suspend to disk unless
(1) the user has 'platform' in /sys/power/disk
(2) pm_ops.pm_disk_mode is set to PM_DISK_PLATFORM
(1) can be changed by the user so even the old code was just correct in
case the user didn't change anything, and (2) isn't true in the current
tree.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: Anyone using mpc832x_mds & freescale's GIT repo?
From: Kim Phillips @ 2007-05-01 14:26 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <46374938.6090707@cambridgebroadband.com>
On Tue, 01 May 2007 15:05:44 +0100
Alex Zeffertt <ajz@cambridgebroadband.com> wrote:
>
> Would you recommend using powerpc.git v2.6.21 in preference to the 2.6.11
> kernel that comes with the latest Freescale BSP (MPC832xE_MDS_K26_20070130-LTIB.iso)?
personally, and in general, yes. But it really depends on your
application, device driver requirements, etc..
Kim
^ permalink raw reply
* RFC: new device types in the device tree (RE: [PATCH] powerpc: Add EDAC platform devices for 85xx)
From: Yoder Stuart-B08248 @ 2007-05-01 15:11 UTC (permalink / raw)
To: Segher Boessenkool, Dave Jiang; +Cc: linuxppc-dev, bluesmoke-devel, david
In-Reply-To: <e359e43198096bc73cdac058c6e5ad6d@kernel.crashing.org>
=20
> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Segher Boessenkool
> Sent: Thursday, April 26, 2007 1:57 PM
> To: Dave Jiang
> Cc: linuxppc-dev@ozlabs.org; david@gibson.dropbear.id.au;=20
> bluesmoke-devel@lists.sourceforge.net
> Subject: Re: [PATCH] powerpc: Add EDAC platform devices for 85xx
>=20
> >>> + mem-ctrl@2000 {
> >>> + device_type =3D "mem-ctrl";
> >>> + compatible =3D "85xx";
> >>>
> >> I'm concerned this is too generic.
> >>
> > I'm supposing not all 85xx uses the same soc? Is there=20
> something more
> > appropriate you can suggest? Thx!
>=20
> "name" =3D "memory-controller"
> "compatible" =3D "fsl,85xx-memory-controller"
> (or a more specific 85xx model if the controller
> isn't identical across those chips)
> No "device_type" at all, since there is no binding
> for this kind of device.
Is "no device_type" really the approach that should be
taken? =20
booting-without-of.txt currently reads:
Every node which actually represents an actual device
(that is, a node which isn't only a virtual "container"
for more nodes, like "/cpus" is) is also required to
have a "device_type" property indicating the type of
node
The 1275 spec is 'Open Firmware centric' in that it says
you don't need a device_type if the node is not used
by Open Firmware.
What should the approach be for new device types that
keep popping up? If the device type is generally useful
I think it makes sense to create a binding and add it to
booting-without-of.txt-- essentially documenting the
required properties, their values, and what they mean.
If it is vendor specific, that vendor should create some
vendors specific doc for their bindings--
Documentation/powerpc/fsl-of-dev-bindings.txt.
Comments?
Thanks,
Stuart Yoder
^ permalink raw reply
* [PATCH] Remove duplicate export of __div64_32.
From: Scott Wood @ 2007-05-01 16:05 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Change 3927f2e8f9afa3424bb51ca81f7abac01ffd0005 moved lib/lib64.c from
lib-y to obj-y, preventing the export in ppc_ksyms.c from overriding
the one in lib, and thus causing a duplicate-export warning.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kernel/ppc_ksyms.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index ff252aa..c96fa9b 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -66,7 +66,6 @@ EXPORT_SYMBOL(clear_pages);
EXPORT_SYMBOL(ISA_DMA_THRESHOLD);
EXPORT_SYMBOL(DMA_MODE_READ);
EXPORT_SYMBOL(DMA_MODE_WRITE);
-EXPORT_SYMBOL(__div64_32);
EXPORT_SYMBOL(do_signal);
EXPORT_SYMBOL(transfer_to_handler);
--
1.5.0.3
^ permalink raw reply related
* Re: Small cleanups to the cuboot bootwrapper code
From: Scott Wood @ 2007-05-01 16:40 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070430034202.GB6436@localhost.localdomain>
David Gibson wrote:
> This patch makes a few small cleanups to the cuboot code.
> - It removes the double layered selection of images, via
> cuboot-plat-y, instead having the cuboot platforms directly select a
> suitable image-y (this changes the name of the final cuboot image from
> plain cuImage to cuImage.<platform>).
> - Factors out some code in the wrapper that's potentially
> useful to platforms other than uboot.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Scott Wood <scottwood@freescale.com>
-Scott
^ permalink raw reply
* [PATCH] gianfar: Add I/O barriers when touching buffer descriptor ownership.
From: Scott Wood @ 2007-05-01 16:55 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
The hardware must not see that is given ownership of a buffer until it is
completely written, and when the driver receives ownership of a buffer,
it must ensure that any other reads to the buffer reflect its final
state. Thus, I/O barriers are added where required.
Without this patch, I have observed GCC reordering the setting of
bdp->length and bdp->status in gfar_new_skb.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
drivers/net/gianfar.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index b666a0c..f187dc3 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1025,6 +1025,7 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
dev->trans_start = jiffies;
+ iobarrier_w();
txbdp->status = status;
/* If this was the last BD in the ring, the next one */
@@ -1301,6 +1302,7 @@ struct sk_buff * gfar_new_skb(struct net_device *dev, struct rxbd8 *bdp)
bdp->length = 0;
/* Mark the buffer empty */
+ iobarrier_w();
bdp->status |= (RXBD_EMPTY | RXBD_INTERRUPT);
return skb;
@@ -1484,6 +1486,7 @@ int gfar_clean_rx_ring(struct net_device *dev, int rx_work_limit)
bdp = priv->cur_rx;
while (!((bdp->status & RXBD_EMPTY) || (--rx_work_limit < 0))) {
+ iobarrier_r();
skb = priv->rx_skbuff[priv->skb_currx];
if (!(bdp->status &
--
1.5.0.3
^ permalink raw reply related
* [PATCH 1/2] Fix the PCI ranges in the MPC832x_MDS device tree.
From: Scott Wood @ 2007-05-01 17:48 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
The MPC832x_MDS device tree's PCI non-prefetchable MMIO range was
specified incorrectly. Both the local and bus addresses start at
0x90000000.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/boot/dts/mpc832x_mds.dts | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts b/arch/powerpc/boot/dts/mpc832x_mds.dts
index c798491..3c0eeb7 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -146,7 +146,7 @@
interrupt-parent = < &ipic >;
interrupts = <42 8>;
bus-range = <0 0>;
- ranges = <02000000 0 a0000000 90000000 0 10000000
+ ranges = <02000000 0 90000000 90000000 0 10000000
42000000 0 80000000 80000000 0 10000000
01000000 0 00000000 d0000000 0 00100000>;
clock-frequency = <0>;
--
1.5.0.3
^ permalink raw reply related
* [PATCH 2/2] Fix the PCI ranges in the MPC834x_MDS device tree.
From: Scott Wood @ 2007-05-01 17:49 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
The PCI ranges on the MPC834x_MDS don't match what u-boot configures.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/boot/dts/mpc834x_mds.dts | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc834x_mds.dts b/arch/powerpc/boot/dts/mpc834x_mds.dts
index 07bcc51..df773fa 100644
--- a/arch/powerpc/boot/dts/mpc834x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc834x_mds.dts
@@ -223,7 +223,7 @@
interrupt-parent = < &ipic >;
interrupts = <42 8>;
bus-range = <0 0>;
- ranges = <02000000 0 a0000000 a0000000 0 10000000
+ ranges = <02000000 0 90000000 90000000 0 10000000
42000000 0 80000000 80000000 0 10000000
01000000 0 00000000 e2000000 0 00100000>;
clock-frequency = <3f940aa>;
@@ -284,7 +284,7 @@
interrupts = <42 8>;
bus-range = <0 0>;
ranges = <02000000 0 b0000000 b0000000 0 10000000
- 42000000 0 90000000 90000000 0 10000000
+ 42000000 0 a0000000 a0000000 0 10000000
01000000 0 00000000 e2100000 0 00100000>;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
--
1.5.0.3
^ permalink raw reply related
* [PATCH] powerpc: publish 85xx soc devices as of_device on cds and ads
From: Dave Jiang @ 2007-05-01 18:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <9903F55A-5E4E-42CE-8C27-6B7143B9FE25@kernel.crashing.org>
Publish the devices in dts under soc as of_device just like what
mpc85xx_mds platforms do.
Signed-off-by: Dave Jiang <djiang@mvista.com>
---
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 19 +++++++++++++++++++
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 19 +++++++++++++++++++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index 5d27621..217cc13 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -18,6 +18,8 @@
#include <linux/delay.h>
#include <linux/seq_file.h>
+#include <asm/of_device.h>
+#include <asm/of_platform.h>
#include <asm/system.h>
#include <asm/time.h>
#include <asm/machdep.h>
@@ -277,6 +279,23 @@ static int __init mpc85xx_ads_probe(void)
return of_flat_dt_is_compatible(root, "MPC85xxADS");
}
+static struct of_device_id mpc85xx_ids[] = {
+ { .type = "soc", },
+ { .compatible = "soc", },
+ {},
+};
+
+static int __init mpc85xx_publish_devices(void)
+{
+ if (!machine_is(mpc85xx_ads))
+ return 0;
+
+ of_platform_bus_probe(NULL, mpc85xx_ids, NULL);
+
+ return 0;
+}
+device_initcall(mpc85xx_publish_devices);
+
define_machine(mpc85xx_ads) {
.name = "MPC85xx ADS",
.probe = mpc85xx_ads_probe,
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index 7e71636..e783d77 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -26,6 +26,8 @@
#include <linux/module.h>
#include <linux/fsl_devices.h>
+#include <asm/of_device.h>
+#include <asm/of_platform.h>
#include <asm/system.h>
#include <asm/pgtable.h>
#include <asm/page.h>
@@ -296,6 +298,23 @@ static int __init mpc85xx_cds_probe(void)
return of_flat_dt_is_compatible(root, "MPC85xxCDS");
}
+static struct of_device_id mpc85xx_ids[] = {
+ { .type = "soc", },
+ { .compatible = "soc", },
+ {},
+};
+
+static int __init mpc85xx_publish_devices(void)
+{
+ if (!machine_is(mpc85xx_cds))
+ return 0;
+
+ of_platform_bus_probe(NULL, mpc85xx_ids, NULL);
+
+ return 0;
+}
+device_initcall(mpc85xx_publish_devices);
+
define_machine(mpc85xx_cds) {
.name = "MPC85xx CDS",
.probe = mpc85xx_cds_probe,
^ permalink raw reply related
* [PATCH] enable compile on !CONFIG_PCI and CONFIG_PPC_EFIKA
From: Domen Puncer @ 2007-05-01 19:37 UTC (permalink / raw)
To: linuxppc-embedded
Trivial fix to enable compile on !CONFIG_PCI and CONFIG_PPC_EFIKA
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
---
Used in arch/powerpc/platforms/52xx/efika.c by
define_machine(efika) { .phys_mem_access_prot = }
include/asm-powerpc/pci.h | 4 ++++
1 file changed, 4 insertions(+)
Index: grant.git/include/asm-powerpc/pci.h
===================================================================
--- grant.git.orig/include/asm-powerpc/pci.h
+++ grant.git/include/asm-powerpc/pci.h
@@ -240,10 +240,14 @@ extern int pci_read_irq_line(struct pci_
extern void pcibios_add_platform_entries(struct pci_dev *dev);
struct file;
+#ifdef CONFIG_PCI
extern pgprot_t pci_phys_mem_access_prot(struct file *file,
unsigned long pfn,
unsigned long size,
pgprot_t prot);
+#else
+#define pci_phys_mem_access_prot NULL
+#endif
#define HAVE_ARCH_PCI_RESOURCE_TO_USER
extern void pci_resource_to_user(const struct pci_dev *dev, int bar,
^ permalink raw reply
* Re: [PATCH 0/11] Consolidation of Open Firmware routines
From: David Miller @ 2007-05-01 19:36 UTC (permalink / raw)
To: jengelh; +Cc: sparclinux, sfr, paulus, linuxppc-dev
In-Reply-To: <Pine.LNX.4.61.0705011311470.18504@yvahk01.tjqt.qr>
From: Jan Engelhardt <jengelh@linux01.gwdg.de>
Date: Tue, 1 May 2007 13:17:42 +0200 (MEST)
>
> On May 1 2007 01:51, David Miller wrote:
> >From: Jan Engelhardt <jengelh@linux01.gwdg.de>
> >Date: Tue, 1 May 2007 10:30:02 +0200 (MEST)
> >
> >> but i'd kinda want drivers/openfirmware, even if it's a bit longer.
> >
> >So much for the unix sense of elegance in short names.
> >I think there is zero confusion about what "of" is.
>
> A prepositional word in the English language, as
> http://en.wiktionary.org/wiki/of tells me. And it's used quite often placed
> 2nd.
> Just see http://ask.slashdot.org/article.pl?sid=07/03/03/028258
Stop this sillyness.
If it feels out of context, which "of" will here, people know
to consider it's probably an acronym of some kind.
^ permalink raw reply
* Re: Correct location for ADC/DAC drivers
From: Guennadi Liakhovetski @ 2007-05-01 21:03 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200705011435.45046.ml@stefan-roese.de>
On Tue, 1 May 2007, Stefan Roese wrote:
> I'm in the stage of integrating some ADC and DAC drivers for the AMCC 405EZ
> PPC and looking for the correct location to place these drivers in the Linux
> source tree. The drivers are basically character-drivers, so my first thought
> is to put them in "drivers/char/adc/foo.c" or "drivers/char/adc_foo.c". Is
> this a good solution?
drivers/mfd following ucb1x00?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: vm changes from linux-2.6.14 to linux-2.6.15
From: Benjamin Herrenschmidt @ 2007-05-01 21:31 UTC (permalink / raw)
To: Mark Fortescue
Cc: linux-mm, wli, linuxppc-dev, andrea, sparclinux, akpm,
David Miller
In-Reply-To: <Pine.LNX.4.61.0705011453380.4771@mtfhpc.demon.co.uk>
> I have attached a patch (so pine does not mangle it) for linux-2.6.20.9.
> Is this what you had in mind?
>
> For linux-2.6.21, more work will be needed as it has more code calling
> ptep_set_access_flags.
I'm not 100% sure we need the 'update' argument... we can remove the
whole old_entry, pte_same, etc... and just have pte_set_access_flags()
read the old PTE and decide wether something needs to be changed or not.
Ben.
^ permalink raw reply
* Re: vm changes from linux-2.6.14 to linux-2.6.15
From: Mark Fortescue @ 2007-05-01 23:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-mm, wli, linuxppc-dev, andrea, sparclinux, akpm,
David Miller
In-Reply-To: <1178055110.13263.2.camel@localhost.localdomain>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 794 bytes --]
On Wed, 2 May 2007, Benjamin Herrenschmidt wrote:
>
>> I have attached a patch (so pine does not mangle it) for linux-2.6.20.9.
>> Is this what you had in mind?
>>
>> For linux-2.6.21, more work will be needed as it has more code calling
>> ptep_set_access_flags.
>
> I'm not 100% sure we need the 'update' argument... we can remove the
> whole old_entry, pte_same, etc... and just have pte_set_access_flags()
> read the old PTE and decide wether something needs to be changed or not.
>
> Ben.
>
>
The attached patch works on sun4c (with my simple ADA compile test) but
the change in functionality may break things other platforms.
The advantage of the previous patch is that the functionality is only
changed for sparc sun4c so less testing would be required.
Regards
Mark Fortescue.
[-- Attachment #2: Type: TEXT/PLAIN, Size: 10932 bytes --]
diff -ruNpd linux-2.6.20.9/include/asm-generic/pgtable.h linux-test/include/asm-generic/pgtable.h
--- linux-2.6.20.9/include/asm-generic/pgtable.h 2007-05-01 12:57:56.000000000 +0100
+++ linux-test/include/asm-generic/pgtable.h 2007-05-01 23:13:23.000000000 +0100
@@ -30,10 +30,17 @@ do { \
* to optimize this.
*/
#define ptep_set_access_flags(__vma, __address, __ptep, __entry, __dirty) \
-do { \
- set_pte_at((__vma)->vm_mm, (__address), __ptep, __entry); \
- flush_tlb_page(__vma, __address); \
-} while (0)
+({ \
+ int __update = !pte_same(*(__ptep), __entry); \
+ \
+ if (__update) { \
+ set_pte_at((__vma)->vm_mm, (__address), __ptep, __entry); \
+ flush_tlb_page(__vma, __address); \
+ } else if (__dirty) { \
+ flush_tlb_page(__vma, __address); \
+ } \
+ __update; \
+})
#endif
#ifndef __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
diff -ruNpd linux-2.6.20.9/include/asm-i386/pgtable.h linux-test/include/asm-i386/pgtable.h
--- linux-2.6.20.9/include/asm-i386/pgtable.h 2007-05-01 12:57:56.000000000 +0100
+++ linux-test/include/asm-i386/pgtable.h 2007-05-01 23:18:50.000000000 +0100
@@ -273,14 +273,19 @@ static inline pte_t pte_mkhuge(pte_t pte
* bit at the same time.
*/
#define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
-#define ptep_set_access_flags(vma, address, ptep, entry, dirty) \
-do { \
- if (dirty) { \
- (ptep)->pte_low = (entry).pte_low; \
- pte_update_defer((vma)->vm_mm, (address), (ptep)); \
- flush_tlb_page(vma, address); \
- } \
-} while (0)
+#define ptep_set_access_flags(__vma, __address, __ptep, __entry, __dirty) \
+({ \
+ int __update = !pte_same(*(__ptep), __entry); \
+ \
+ if (__dirty) { \
+ if (__update) { \
+ (__ptep)->pte_low = (__entry).pte_low; \
+ pte_update_defer((__vma)->vm_mm, (__address), (__ptep)); \
+ } \
+ flush_tlb_page(__vma, __address); \
+ } \
+ __update; \
+})
/*
* We don't actually have these, but we want to advertise them so that
diff -ruNpd linux-2.6.20.9/include/asm-ia64/pgtable.h linux-test/include/asm-ia64/pgtable.h
--- linux-2.6.20.9/include/asm-ia64/pgtable.h 2007-04-30 19:04:59.000000000 +0100
+++ linux-test/include/asm-ia64/pgtable.h 2007-05-01 23:16:47.000000000 +0100
@@ -537,16 +537,29 @@ extern void lazy_mmu_prot_update (pte_t
* daccess_bit in ivt.S).
*/
#ifdef CONFIG_SMP
-# define ptep_set_access_flags(__vma, __addr, __ptep, __entry, __safely_writable) \
-do { \
- if (__safely_writable) { \
- set_pte(__ptep, __entry); \
- flush_tlb_page(__vma, __addr); \
- } \
-} while (0)
+# define ptep_set_access_flags(__vma, __addr, __ptep, __entry, __dirty) \
+({ \
+ int __update = !pte_same(*(__ptep), __entry); \
+ \
+ if (__dirty) { \
+ if (__update) \
+ set_pte(__ptep, __entry); \
+ flush_tlb_page(__vma, __addr); \
+ } \
+ __update; \
+})
#else
-# define ptep_set_access_flags(__vma, __addr, __ptep, __entry, __safely_writable) \
- ptep_establish(__vma, __addr, __ptep, __entry)
+# define ptep_set_access_flags(__vma, __addr, __ptep, __entry, __dirty) \
+({ \
+ int __update = !pte_same(*(__ptep), __entry); \
+ \
+ if (__update) \
+ ptep_establish(__vma, __addr, __ptep, __entry); \
+ else if (__dirty) \
+ flush_tlb_page(__vma, __addr); \
+ } \
+ __update; \
+})
#endif
# ifdef CONFIG_VIRTUAL_MEM_MAP
diff -ruNpd linux-2.6.20.9/include/asm-powerpc/pgtable.h linux-test/include/asm-powerpc/pgtable.h
--- linux-2.6.20.9/include/asm-powerpc/pgtable.h 2007-05-01 12:57:56.000000000 +0100
+++ linux-test/include/asm-powerpc/pgtable.h 2007-05-01 23:21:18.000000000 +0100
@@ -438,10 +438,16 @@ static inline void __ptep_set_access_fla
:"cc");
}
#define ptep_set_access_flags(__vma, __address, __ptep, __entry, __dirty) \
- do { \
+({ \
+ int __update = !pte_same(*(__ptep), __entry); \
+ \
+ if (__update) { \
__ptep_set_access_flags(__ptep, __entry, __dirty); \
- flush_tlb_page_nohash(__vma, __address); \
- } while(0)
+ flush_tlb_page_nohash(__vma, __address); \
+ } else if (__dirty) \
+ flush_tlb_page(__vma, __address); \
+ __update; \
+})
/*
* Macro to mark a page protection value as "uncacheable".
diff -ruNpd linux-2.6.20.9/include/asm-ppc/pgtable.h linux-test/include/asm-ppc/pgtable.h
--- linux-2.6.20.9/include/asm-ppc/pgtable.h 2007-04-30 19:05:00.000000000 +0100
+++ linux-test/include/asm-ppc/pgtable.h 2007-05-01 23:15:29.000000000 +0100
@@ -694,10 +694,16 @@ static inline void __ptep_set_access_fla
}
#define ptep_set_access_flags(__vma, __address, __ptep, __entry, __dirty) \
- do { \
+({ \
+ int __update = !pte_same(*(__ptep), __entry); \
+ \
+ if (__update) { \
__ptep_set_access_flags(__ptep, __entry, __dirty); \
- flush_tlb_page_nohash(__vma, __address); \
- } while(0)
+ flush_tlb_page_nohash(__vma, __address); \
+ } else if (__dirty) \
+ flush_tlb_page(__vma, __address); \
+ __update; \
+})
/*
* Macro to mark a page protection value as "uncacheable".
diff -ruNpd linux-2.6.20.9/include/asm-s390/pgtable.h linux-test/include/asm-s390/pgtable.h
--- linux-2.6.20.9/include/asm-s390/pgtable.h 2007-05-01 12:57:56.000000000 +0100
+++ linux-test/include/asm-s390/pgtable.h 2007-05-01 23:19:58.000000000 +0100
@@ -628,8 +628,16 @@ ptep_establish(struct vm_area_struct *vm
set_pte(ptep, entry);
}
-#define ptep_set_access_flags(__vma, __address, __ptep, __entry, __dirty) \
- ptep_establish(__vma, __address, __ptep, __entry)
+#define ptep_set_access_flags(__vma, __address, __ptep, __entry, __dirty) \
+ ({ \
+ int __update = !pte_same(*(__ptep), __entry); \
+ \
+ if (__update) \
+ ptep_establish(__vma, __address, __ptep, __entry); \
+ else if (__dirty) \
+ flush_tlb_page(__vma, __address); \
+ __update; \
+ })
/*
* Test and clear dirty bit in storage key.
diff -ruNpd linux-2.6.20.9/include/asm-sparc/pgtable.h linux-test/include/asm-sparc/pgtable.h
--- linux-2.6.20.9/include/asm-sparc/pgtable.h 2007-04-30 19:05:01.000000000 +0100
+++ linux-test/include/asm-sparc/pgtable.h 2007-05-01 23:10:49.000000000 +0100
@@ -446,6 +446,27 @@ extern int io_remap_pfn_range(struct vm_
#define GET_IOSPACE(pfn) (pfn >> (BITS_PER_LONG - 4))
#define GET_PFN(pfn) (pfn & 0x0fffffffUL)
+#define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
+#define ptep_set_access_flags(__vma, __address, __ptep, __entry, __dirty) \
+({ \
+ int __update; \
+ \
+ if (sparc_cpu_model == sun4c) { \
+ set_pte_at((__vma)->vm_mm, (__address), __ptep, __entry); \
+ flush_tlb_page(__vma, __address); \
+ __update = 1; \
+ } else { \
+ __update = !pte_same(*(__ptep), __entry); \
+ if (__update) { \
+ set_pte_at((__vma)->vm_mm, (__address), __ptep, __entry); \
+ flush_tlb_page(__vma, __address); \
+ } else if (__dirty) { \
+ flush_tlb_page(__vma, __address); \
+ } \
+ } \
+ __update; \
+})
+
#include <asm-generic/pgtable.h>
#endif /* !(__ASSEMBLY__) */
diff -ruNpd linux-2.6.20.9/include/asm-x86_64/pgtable.h linux-test/include/asm-x86_64/pgtable.h
--- linux-2.6.20.9/include/asm-x86_64/pgtable.h 2007-05-01 12:57:57.000000000 +0100
+++ linux-test/include/asm-x86_64/pgtable.h 2007-05-01 23:13:53.000000000 +0100
@@ -397,12 +397,16 @@ static inline pte_t pte_modify(pte_t pte
* bit at the same time. */
#define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
#define ptep_set_access_flags(__vma, __address, __ptep, __entry, __dirty) \
- do { \
+ ({ \
+ int __update = !pte_same(*(__ptep), __entry); \
+ \
if (__dirty) { \
- set_pte(__ptep, __entry); \
+ if (__update) \
+ set_pte(__ptep, __entry); \
flush_tlb_page(__vma, __address); \
} \
- } while (0)
+ __update; \
+ })
/* Encode and de-code a swap entry */
#define __swp_type(x) (((x).val >> 1) & 0x3f)
diff -ruNpd linux-2.6.20.9/mm/hugetlb.c linux-test/mm/hugetlb.c
--- linux-2.6.20.9/mm/hugetlb.c 2007-05-01 13:01:10.000000000 +0100
+++ linux-test/mm/hugetlb.c 2007-05-01 23:02:08.000000000 +0100
@@ -313,9 +313,10 @@ static void set_huge_ptep_writable(struc
pte_t entry;
entry = pte_mkwrite(pte_mkdirty(*ptep));
- ptep_set_access_flags(vma, address, ptep, entry, 1);
- update_mmu_cache(vma, address, entry);
- lazy_mmu_prot_update(entry);
+ if (ptep_set_access_flags(vma, address, ptep, entry, 1)) {
+ update_mmu_cache(vma, address, entry);
+ lazy_mmu_prot_update(entry);
+ }
}
diff -ruNpd linux-2.6.20.9/mm/memory.c linux-test/mm/memory.c
--- linux-2.6.20.9/mm/memory.c 2007-05-01 12:57:57.000000000 +0100
+++ linux-test/mm/memory.c 2007-05-01 23:06:21.000000000 +0100
@@ -1553,9 +1553,11 @@ static int do_wp_page(struct mm_struct *
flush_cache_page(vma, address, pte_pfn(orig_pte));
entry = pte_mkyoung(orig_pte);
entry = maybe_mkwrite(pte_mkdirty(entry), vma);
- ptep_set_access_flags(vma, address, page_table, entry, 1);
- update_mmu_cache(vma, address, entry);
- lazy_mmu_prot_update(entry);
+ if (ptep_set_access_flags(vma, address,
+ page_table, entry, 1)) {
+ update_mmu_cache(vma, address, entry);
+ lazy_mmu_prot_update(entry);
+ }
ret |= VM_FAULT_WRITE;
goto unlock;
}
@@ -2387,10 +2389,9 @@ static inline int handle_pte_fault(struc
pte_t *pte, pmd_t *pmd, int write_access)
{
pte_t entry;
- pte_t old_entry;
spinlock_t *ptl;
- old_entry = entry = *pte;
+ entry = *pte;
if (!pte_present(entry)) {
if (pte_none(entry)) {
if (vma->vm_ops) {
@@ -2423,19 +2424,9 @@ static inline int handle_pte_fault(struc
entry = pte_mkdirty(entry);
}
entry = pte_mkyoung(entry);
- if (!pte_same(old_entry, entry)) {
- ptep_set_access_flags(vma, address, pte, entry, write_access);
+ if (ptep_set_access_flags(vma, address, pte, entry, write_access)) {
update_mmu_cache(vma, address, entry);
lazy_mmu_prot_update(entry);
- } else {
- /*
- * This is needed only for protection faults but the arch code
- * is not yet telling us if this is a protection fault or not.
- * This still avoids useless tlb flushes for .text page faults
- * with threads.
- */
- if (write_access)
- flush_tlb_page(vma, address);
}
unlock:
pte_unmap_unlock(pte, ptl);
^ permalink raw reply
* RE: How do external irq's get mapped?
From: Charles Krinke @ 2007-05-01 23:11 UTC (permalink / raw)
To: Andy Fleming; +Cc: Randy Brown, Chris Carlson, Kevin Smith, linuxppc-embedded
In-Reply-To: <269D8EB0-71BD-4C93-BD60-E7E14C533D84@freescale.com>
Please pardon the top post, it is done to help my local compatriots read
more easily.
Andy, our MPC85xx_OPENPIC_IRQ_OFFSET is 80, but the call to
openpic_init(MPC85xx_OPENPIC_IRQ_OFFSET) occurs after the two calls to
openpic_set_sources. This leads me to believe that the mapping goes
Internal irqs are 00..31 based on first openpic_set_sources(0, 32, ..)
External irqs are 48..60 based on second openpic_set_sources(48, 12,
...)
Then we have the openpic_init(80) call.
So, I though the external IRQ0 was mapped to 48. But is it really mapped
to 80 + 32 or 112 instead. If that is the case, there is another
problem.=20
The new problem is that if I set the irq to 112, when it is insmodded, I
get an error from open_pic.c of the form:
Open_pic.c:720 invalid irq 112
This seems to be coming from the macro at line 144 in open_pic.c
#define check_arg_irq(irq) \
if (irq < open_pic_irq_offset || irq >=3D
NumSources+open_pic_irq_offset \
|| ISR[irq - open_pic_irq_offset] =3D=3D 0) { \
printk("open_pic.c:%d: invalid irq %d\n", __LINE__, irq); \
dump_stack(); }
Charles
-----Original Message-----
From: Andy Fleming [mailto:afleming@freescale.com]=20
Sent: Monday, April 30, 2007 5:23 PM
To: Charles Krinke
Cc: Sergei Shtylyov; Randy Brown; Chris Carlson; Kevin Smith;
linuxppc-embedded@ozlabs.org
Subject: Re: How do external irq's get mapped?
On Apr 30, 2007, at 09:32, Charles Krinke wrote:
>
>
> At this point, I would just like to confirm I am thinking clearly and
> now understand the IRQ mapping. We are constrained to finish this
> project with the kernel we started with, linux-2.6.17.11, so this
> discussion is centered around that code base. This is my understanding
> based on last week's e-mails and my research.
>
> 1. In arch/ppc/platforms/85xx/mpc85xx_cds_common.c is the
> mpc85xx_cds_openpic_initsenses[] whose first 4 members are set to
> IRQ_SENSE_LEVEL or'ed with IRQ_POLARITY_NEGATIVE. This means the first
> four external interrupts are enabled and neg polarity. I can use these
> entries as is and change the others from 0x0 as I need more of the
> external interrupt pins.
>
> Just for reference, here are a few lines from mpc85xx_cds_init_IRQ
>
> mpc85xx_cds_init_IRQ(void)
> {
> openpic_set_sources(0, 32, OpenPIC_Addr + 0x10200);
> /* Map PIC IRQs 0-11 */
> openpic_set_sources(48, 12, OpenPIC_Addr + 0x10000);
This line is almost more important:
openpic_init(MPC85xx_OPENPIC_IRQ_OFFSET);
You need to find out what that is defined to be. My tree says it's =20
defined as CPM_IRQ_OFFSET + NR_CPM_INTS (or 0, if CONFIG_CPM2 isn't =20
defined).
So that's the 80, if NR_8259_INTS is 16. Otherwise it's 64. So 112 =20
could work, but if you have your config different, the numbers will =20
move.
>
> 2. In this routine, the first openpic_set_source call is for the 32
> internal IRQ's and the second openpic_set_sources maps the 12 external
> IRQ's beginning at 48, so that means my external IRQ mapping is:
>
> ExtIrQ LinuxIrqNum
> 0 48 (first four are enabled)
> 1 49
> 2 50
> 3 51
> 4 52 (last 8 not enabled by default)
> 5 53
> 6 54
> 7 55
> 8 56
> 9 57=09
> 10 58=09
> 11 59
>
> Is this correct?
Depends on your configuration. But probably not. The CPM takes up =20
some space, too.
Andy
^ permalink raw reply
* Re: [PATCH 13/14] powerpc: add ps3 platform system bus support
From: Arnd Bergmann @ 2007-05-01 23:39 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Olaf Hering, David Woodhouse
In-Reply-To: <1178001851.3085.137.camel@pmac.infradead.org>
On Tuesday 01 May 2007, David Woodhouse wrote:
> I have no particular objection to this, but would observe that it's more
> normal to have the number->name mapping done in userspace by modprobe,
> rather than inside the kernel.
I have one ;-)
> For now I'd just added explicit aliases like 'MODULE_ALIAS("ps3:3");' to
> the modules in question, because I hadn't yet worked out how to do all
> the mod_devicetable stuff to pick it out of the match_id in the driver
> structure.
I think the simple numbering is far more straightforward, because this
way the bus doesn't need to know about what devices can be connected
to it. The way that Olaf's patch does it, every new device type that
may get added in the future needs both a device driver and a change to
the bus code, while the other way, we can simply add a new driver.
Arnd <><
^ permalink raw reply
* Re: [PATCH v2] powerpc: Show current speed in /proc/cpuinfo
From: Arnd Bergmann @ 2007-05-01 23:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, paulus
In-Reply-To: <20070430035339.GA15771@lixom.net>
On Monday 30 April 2007, Olof Johansson wrote:
> On other architectures, the frequency in /proc/cpuinfo moves with cpufreq
> changes. It makes sense to do the same on powerpc to keep users from
> getting confused.
>=20
> Change the format to three decimals, having full Hz granularity is silly
> these days. Also specify in output if it's cpufreq or firmware-reported:
>=20
> clock =A0 =A0 =A0 =A0 =A0 : 1250.000MHz (from firmware)
> or:
> clock =A0 =A0 =A0 =A0 =A0 : 2500.000MHz (actual speed)
Good idea, but I'd be _very_ careful with changing any field in
/proc/cpuinfo. Having the extra text in there can easily confuse
parsers in poorly written user applications, maybe even in good ones ;-)
How about rather adding a new line in there for one of the fields, either
clock : 1250.000MHz
max-clock : 2500.000MHz
or
clock : 2500.000MHz
current-clock : 1250.000MHz
Arnd <><
^ permalink raw reply
* Re: RFC: new device types in the device tree (RE: [PATCH] powerpc: Add EDAC platform devices for 85xx)
From: Segher Boessenkool @ 2007-05-02 0:34 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: linuxppc-dev, david, bluesmoke-devel
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA302D5DC6F@az33exm25.fsl.freescale.net>
>> "name" = "memory-controller"
>> "compatible" = "fsl,85xx-memory-controller"
>> (or a more specific 85xx model if the controller
>> isn't identical across those chips)
>> No "device_type" at all, since there is no binding
>> for this kind of device.
>
> Is "no device_type" really the approach that should be
> taken?
Yes.
> booting-without-of.txt currently reads:
>
> Every node which actually represents an actual device
> (that is, a node which isn't only a virtual "container"
> for more nodes, like "/cpus" is) is also required to
> have a "device_type" property indicating the type of
> node
That is wrong, IMNSHO.
> The 1275 spec is 'Open Firmware centric' in that it says
> you don't need a device_type if the node is not used
> by Open Firmware.
It is "Open firmware centric" in every way; it is
the Open firmware definition after all.
"device_type" specifies what firmware interfaces a
node implements. "name" and "compatible" are for
the client (i.e., OS, bootloader, etc.) to use for
matching drivers to device nodes.
It typically makes no sense to create a new "device_type"
value for anything else than very generic classes of
device, where you can drive the device without knowing
anything else than what is defined in the binding for
that "device_type".
> What should the approach be for new device types that
> keep popping up? If the device type is generally useful
> I think it makes sense to create a binding and add it to
> booting-without-of.txt-- essentially documenting the
> required properties, their values, and what they mean.
And the associated methods and anything else that is
needed. It would be a big mistake to create incompatibilities
with "real OF" where those can be avoided just as easily.
> If it is vendor specific, that vendor should create some
> vendors specific doc for their bindings--
> Documentation/powerpc/fsl-of-dev-bindings.txt.
>
> Comments?
In short: having a "device_type" in your node doesn't
help at all if all users need to know the "compatible"
property as well; and it _does_ hurt.
Segher
^ permalink raw reply
* Re: [PATCH] gianfar: Add I/O barriers when touching buffer descriptor ownership.
From: Segher Boessenkool @ 2007-05-02 0:54 UTC (permalink / raw)
To: Scott Wood; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20070501165542.GA31285@ld0162-tx32.am.freescale.net>
> The hardware must not see that is given ownership of a buffer until it
> is
> completely written, and when the driver receives ownership of a buffer,
> it must ensure that any other reads to the buffer reflect its final
> state. Thus, I/O barriers are added where required.
>
> Without this patch, I have observed GCC reordering the setting of
> bdp->length and bdp->status in gfar_new_skb.
The :::"memory" in the barriers you used prevent GCC
from reordering accesses around the barriers.
AFAICS you need stronger barriers though; {w,r,}mb(),
to prevent _any_ reordering of those memory accesses,
not just the compiler-generated ones.
Segher
^ permalink raw reply
* Re: RFC: new device types in the device tree (RE: [PATCH] powerpc: Add EDAC platform devices for 85xx)
From: David Gibson @ 2007-05-02 1:19 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Yoder Stuart-B08248, bluesmoke-devel
In-Reply-To: <567cddf8855d809f2e0c5b4101c2c15a@kernel.crashing.org>
On Wed, May 02, 2007 at 02:34:45AM +0200, Segher Boessenkool wrote:
> >> "name" = "memory-controller"
> >> "compatible" = "fsl,85xx-memory-controller"
> >> (or a more specific 85xx model if the controller
> >> isn't identical across those chips)
> >> No "device_type" at all, since there is no binding
> >> for this kind of device.
> >
> > Is "no device_type" really the approach that should be
> > taken?
>
> Yes.
>
> > booting-without-of.txt currently reads:
> >
> > Every node which actually represents an actual device
> > (that is, a node which isn't only a virtual "container"
> > for more nodes, like "/cpus" is) is also required to
> > have a "device_type" property indicating the type of
> > node
>
> That is wrong, IMNSHO.
I tend to agree. Device drivers should generally be searching on the
"compatible" property, not "device_type". Defining new device_type
values isn't really of any use to the kernel, so we should just avoid
it.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 08/11] Begin to consolidate of_device.c
From: Segher Boessenkool @ 2007-05-02 1:23 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: sparclinux, ppc-dev, paulus, David S. Miller
In-Reply-To: <20070501173143.9d514ea4.sfr@canb.auug.org.au>
> This moves all the common parts for the Sparc, Sparc64 and PowerPC
> of_device.c files into drivers/openfw/device.c.
s/openfw/of/
Cheers,
Segher
^ permalink raw reply
* powerpc.git master branch reset
From: Paul Mackerras @ 2007-05-02 2:04 UTC (permalink / raw)
To: linuxppc-dev
Since Linus has pulled the for-2.6.22 branch, the master branch of
powerpc.git doesn't have anything useful in it except some merges.
Hence I have reset it to point to the head of Linus' tree. If you are
following the master branch you'll need to do a git pull -f (or a new
clone).
Paul.
^ permalink raw reply
* Re: [RFC/PATCH] Change 440GP platform to ppc440
From: Kumar Gala @ 2007-05-02 3:38 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Roland Dreier, Paul Mackerras
In-Reply-To: <200704240746.05129.sr@denx.de>
On Apr 24, 2007, at 12:46 AM, Stefan Roese wrote:
> On Tuesday 24 April 2007 02:12, Roland Dreier wrote:
>>>> I recall dimly that there was some user-visible difference
>>>> between the
>>>> 440GP and the other 440 processors, and that's why we made the
>>>> platform string different. I don't recall what the difference was.
>>
>> FWIW, I've run the same userspace (binaries) on 405GPr, 440GP and
>> 440SPe without any problems. Not that I'm a 4xx expert by any
>> stretch, but I don't know of anything special about the 440GP.
>
> I don't know of any differences either. So I'm voting to change the
> platform
> to ppc440 too.
After some discussion with Paul we think we figured out why 440GP was
marked differently. I doesn't implement 'isel', and all other 440's do.
- k
^ permalink raw reply
* Re: [PATCH] powermac: proper time of day after resume
From: Paul Mackerras @ 2007-05-02 4:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1170357390.4036.9.camel@johannes.berg>
Johannes Berg writes:
> +static int timer_resume(struct sys_device *dev)
> +{
> + struct timeval tv;
> + struct timespec ts;
> + struct rtc_time cur_rtc_tm;
> + unsigned long cur_rtc_time, diff;
> +
> + /* get current RTC time and convert to seconds */
> + get_rtc_time(&cur_rtc_tm);
> + rtc_tm_to_time(&cur_rtc_tm, &cur_rtc_time);
Why not just use get_boot_time() here? Or if not that, then use
mktime() instead of rtc_tm_to_time(). Either way we don't need to
select RTC_LIB.
> + diff = cur_rtc_time - suspend_rtc_time;
> +
> + /* adjust time of day by seconds that elapsed while
> + * we were suspended */
> + do_gettimeofday(&tv);
> + ts.tv_sec = tv.tv_sec + diff;
> + ts.tv_nsec = tv.tv_usec * NSEC_PER_USEC;
> + do_settimeofday(&ts);
This will fail if ts.tv_nsec ends up being >= NSEC_PER_SEC.
Paul.
^ permalink raw reply
* Re: [PATCH] powermac: proper time of day after resume
From: Paul Mackerras @ 2007-05-02 4:47 UTC (permalink / raw)
To: Johannes Berg, Benjamin Herrenschmidt, linuxppc-dev
In-Reply-To: <17976.5964.593278.752595@cargo.ozlabs.ibm.com>
I wrote:
> This will fail if ts.tv_nsec ends up being >= NSEC_PER_SEC.
Sorry, silly comment, I didn't look at the code closely enough...
Paul.
^ 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