* [patch] powerpc: hash lock use lock bitops
From: Nick Piggin @ 2007-11-20 5:09 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, linuxppc-dev; +Cc: Anton Blanchard
In-Reply-To: <20071120050826.GA18332@wotan.suse.de>
This isn't a bugfix, but may help performance slightly...
--
powerpc 64-bit hash pte lock bit is an actual lock, so it can take advantage
of lock bitops for slightly more optimal memory barriers (can avoid an lwsync
in the trylock).
Signed-off-by: Nick Piggin <npiggin@suse.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Index: linux-2.6/arch/powerpc/mm/hash_native_64.c
===================================================================
--- linux-2.6.orig/arch/powerpc/mm/hash_native_64.c
+++ linux-2.6/arch/powerpc/mm/hash_native_64.c
@@ -113,7 +113,7 @@ static inline void native_lock_hpte(stru
unsigned long *word = &hptep->v;
while (1) {
- if (!test_and_set_bit(HPTE_LOCK_BIT, word))
+ if (!test_and_set_bit_lock(HPTE_LOCK_BIT, word))
break;
while(test_bit(HPTE_LOCK_BIT, word))
cpu_relax();
@@ -124,8 +124,7 @@ static inline void native_unlock_hpte(st
{
unsigned long *word = &hptep->v;
- asm volatile("lwsync":::"memory");
- clear_bit(HPTE_LOCK_BIT, word);
+ clear_bit_unlock(HPTE_LOCK_BIT, word);
}
static long native_hpte_insert(unsigned long hpte_group, unsigned long va,
^ permalink raw reply
* [patch] xmon bitlock fix
From: Nick Piggin @ 2007-11-20 5:08 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, linuxppc-dev
(sorry, untested for lack of hardware)
--
xmon uses a bit lock spinlock but doesn't close the critical section
when releasing it. It doesn't seem like a big deal because it will
eventually break out of the lock anyway, but presumably that's only
in exceptional cases where some error is tolerated, while the lack of a memory
barrier could allow incorrect results during normal functioning operation
as well.
Convert it to use a regular spinlock instead.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Index: linux-2.6/arch/ppc/xmon/start.c
===================================================================
--- linux-2.6.orig/arch/ppc/xmon/start.c
+++ linux-2.6/arch/ppc/xmon/start.c
@@ -92,16 +92,14 @@ xmon_write(void *handle, void *ptr, int
{
char *p = ptr;
int i, c, ct;
-
-#ifdef CONFIG_SMP
- static unsigned long xmon_write_lock;
+ static DEFINE_SPINLOCK(xmon_write_lock);
int lock_wait = 1000000;
int locked;
- while ((locked = test_and_set_bit(0, &xmon_write_lock)) != 0)
+ while (!(locked = spin_trylock(&xmon_write_lock))) {
if (--lock_wait == 0)
break;
-#endif
+ }
if (!scc_initialized)
xmon_init_scc();
@@ -122,10 +120,9 @@ xmon_write(void *handle, void *ptr, int
eieio();
}
-#ifdef CONFIG_SMP
- if (!locked)
- clear_bit(0, &xmon_write_lock);
-#endif
+ if (locked)
+ spin_unlock(&xmon_write_lock);
+
return nb;
}
^ permalink raw reply
* RE: How can I make the DDR momory storage bigger than 256M?
From: Liu Dave @ 2007-11-20 4:38 UTC (permalink / raw)
To: 郭劲, linuxppc-embedded
In-Reply-To: <395483341.30896@tsinghua.org.cn>
Hello Guo,
Please post your question to u-boot maillist:
u-boot-users@lists.sourceforge.net=20
Please check if you have the correct BATs for 1GB memory.
1GB memory should need 4 BATs.
Regards,
Dave
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+daveliu=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+daveliu=3Dfreescale.com@ozlabs
> .org] On Behalf Of =B9=F9=BE=A2
> Sent: 2007=C4=EA11=D4=C219=C8=D5 10:42 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: How can I make the DDR momory storage bigger than 256M?
>=20
> Hi,friends,
>=20
> I used the U-Boot 1.2.0 on MPC8360E board. My board work=20
> nomally with 256M DDR-1
> Memory. If I change the DDR-1 up to 1GB, the U-Boot can=20
> visit the DDR address
> range from 0x00000000 to 0x10000000, but it can not visit the=20
> address bigger than
> 0x10000000,I wat wondering why? Thanks.
>=20
> Using the 1GB DDR-1, I can write the u-boot to my flash by=20
> CodeWarrior.
>=20
> Follow is the information that when I test the DDR on u-boot,=20
> the start address is
> 0x1ff00000, the end address is 0x20000000;it was dead when=20
> visit the DDR.
>=20
>=20
>=20
>=20
>=20
>=20
> U-Boot 1.2.0 (Nov 19 2007 - 20:55:34) MPC83XX =20
> =20
> =20
> =20
> CPU: e300c1, MPC8360E, Rev: 20 at 528 MHz, CSB: 264 MHz =20
> =20
> Board: Freescale MPC8360EMDS =20
> =20
> I2C: ready =20
> =20
> DRAM: =20
> =20
> DIMM type: =20
> =20
> SPD size: 128 =20
> =20
> EEPROM size: 256 =20
> =20
> Memory type: 7 =20
> =20
> Row addr: 13 =20
> =20
> Column addr: 11 =20
> =20
> # of rows: 2 =20
> =20
> Row density: 128 =20
> =20
> # of banks: 4 =20
> =20
> Data width: 64 =20
> =20
> Chip width: 8 =20
> =20
> Refresh rate: 82 =20
> =20
> CAS latencies: 18 =20
> =20
> Write latencies: 02 =20
> =20
> tRP: 60 =20
> =20
> tRCD: 60 =20
> =20
> =20
> =20
> =20
> =20
> cs0_bnds =3D 0x0000001f =20
> =20
> cs0_config =3D 0x80000103 =20
> =20
> cs1_bnds =3D 0x0020003f =20
> =20
> cs1_config =3D 0x80000103 =20
> =20
> DDR:bar=3D0x00000000 =20
> =20
> DDR:ar=3D0x8000001d =20
> =20
> DDR: caslat SPD bit is 4 =20
> =20
> DDR:Module maximum data rate is: 400Mhz =20
> =20
> DDR:Effective data rate is: 266Mhz =20
> =20
> DDR:The MSB 1 of CAS Latency is: 4 =20
> =20
> DDR: effective data rate is 266 MHz =20
> =20
> DDR: caslat SPD bit is 4, controller field is 0x5 =20
> =20
> DDR:timing_cfg_1=3D0x26252727 =20
> =20
> DDR:timing_cfg_2=3D0x00004841 =20
> =20
> =20
> =20
> DDR DIMM: data bus width is 64 bit without ECC =20
> =20
> DDR:sdram_mode=3D0x00000032 =20
> =20
> DDR: sdram_mode2 =3D 0x00000000 =20
> =20
> DDR:sdram_interval=3D0x04060100 =20
> =20
> DDR:sdram_clk_cntl=3D0x02000000 =20
> =20
> DDRC ECC mode: OFF =20
> =20
> DDR:sdram_cfg=3D0xc2008000 =20
> =20
> =20
> =20
> SDRAM on Local Bus: 64 MB =20
> =20
> DDR RAM: 1024 MB =20
> =20
> DDR test phase 1: =20
>=20
>=20
> (dead)
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* Re: [PATCH] fix scaled time accounting possible divide by zero
From: Michael Neuling @ 2007-11-20 4:36 UTC (permalink / raw)
To: balbir; +Cc: linuxppc-dev, paulus
In-Reply-To: <47425F8F.3060208@linux.vnet.ibm.com>
In message <47425F8F.3060208@linux.vnet.ibm.com> you wrote:
> Michael Neuling wrote:
> > This fixes a problem noticed by Balbir Singh
> >
> > Signed-off-by: Michael Neuling <mikey@neuling.org>
> > ---
> > Paulus: can we send this up for 2.6.24?
> >
> > arch/powerpc/kernel/time.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > Index: linux-2.6-ozlabs/arch/powerpc/kernel/time.c
> > ===================================================================
> > --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/time.c
> > +++ linux-2.6-ozlabs/arch/powerpc/kernel/time.c
> > @@ -244,8 +244,9 @@ void account_system_vtime(struct task_st
> > /* deltascaled includes both user and system time.
> > * Hence scale it based on the purr ratio to estimate
> > * the system time */
> > - deltascaled = deltascaled * get_paca()->system_time /
> > - (get_paca()->system_time + get_paca()->user_time);
> > + if (get_paca()->user_time)
> > + deltascaled = deltascaled * get_paca()->system_time /
> > + (get_paca()->system_time + get_paca()->user_time);
>
> Hi, Michael,
>
> I'd be doubly careful with scaled multiplication approach, we tried this
> for CFS (please see task_utime() and task_stime() and the fixes that
> went around it). We ran into problems were due to multiplication
> rounding errors, we would see stime and utime go back after a period
> of time.
>
> Please see http://kerneltrap.org/mailarchive/linux-kernel/2007/10/16/344377
>
> Our problems were made severe by the fact that sum_exec_runtime and
> stime/utime accounting occured differently. stime/utime were sampled
> at jiffy boundaries and hence could we incorrect. I think we need
> to use rounding to ensure that ac_scaled*time never goes back
> due to rounding errors.
I've not changed the math here much, just the case of user_time being
zero.
Is this related to this patch specifically, or something that's been
wrong with these patches for a while?
Mikey
^ permalink raw reply
* [PATCH] fix scaled time accounting possible divide by zero
From: Michael Neuling @ 2007-11-20 4:18 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Balbir Singh
In-Reply-To: <9965.1195529141@neuling.org>
If we get no user time allocated since the last account_system_vtime,
the system to user time ratio estimate can end up dividing by zero.
This was causing a problem noticed by Balbir Singh.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Resent as the first version had whitespace corruption.
Paulus: can we send this up for 2.6.24?
arch/powerpc/kernel/time.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/time.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/time.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/time.c
@@ -241,8 +241,9 @@ void account_system_vtime(struct task_st
/* deltascaled includes both user and system time.
* Hence scale it based on the purr ratio to estimate
* the system time */
- deltascaled = deltascaled * get_paca()->system_time /
- (get_paca()->system_time + get_paca()->user_time);
+ if (get_paca()->user_time)
+ deltascaled = deltascaled * get_paca()->system_time /
+ (get_paca()->system_time + get_paca()->user_time);
delta += get_paca()->system_time;
get_paca()->system_time = 0;
}
^ permalink raw reply
* Re: [PATCH] fix scaled time accounting possible divide by zero
From: Balbir Singh @ 2007-11-20 4:16 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus
In-Reply-To: <9965.1195529141@neuling.org>
Michael Neuling wrote:
> This fixes a problem noticed by Balbir Singh
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> Paulus: can we send this up for 2.6.24?
>
> arch/powerpc/kernel/time.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> Index: linux-2.6-ozlabs/arch/powerpc/kernel/time.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/time.c
> +++ linux-2.6-ozlabs/arch/powerpc/kernel/time.c
> @@ -244,8 +244,9 @@ void account_system_vtime(struct task_st
> /* deltascaled includes both user and system time.
> * Hence scale it based on the purr ratio to estimate
> * the system time */
> - deltascaled = deltascaled * get_paca()->system_time /
> - (get_paca()->system_time + get_paca()->user_time);
> + if (get_paca()->user_time)
> + deltascaled = deltascaled * get_paca()->system_time /
> + (get_paca()->system_time + get_paca()->user_time);
Hi, Michael,
I'd be doubly careful with scaled multiplication approach, we tried this
for CFS (please see task_utime() and task_stime() and the fixes that
went around it). We ran into problems were due to multiplication
rounding errors, we would see stime and utime go back after a period
of time.
Please see http://kerneltrap.org/mailarchive/linux-kernel/2007/10/16/344377
Our problems were made severe by the fact that sum_exec_runtime and
stime/utime accounting occured differently. stime/utime were sampled
at jiffy boundaries and hence could we incorrect. I think we need
to use rounding to ensure that ac_scaled*time never goes back
due to rounding errors.
> delta += get_paca()->system_time;
> get_paca()->system_time = 0;
> }
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* [PATCH] ibm_newemac: Fix possible lockup on close
From: Benjamin Herrenschmidt @ 2007-11-20 3:50 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc-dev, netdev
It's a bad idea to call flush_scheduled_work from within a
netdev->stop because the linkwatch will occasionally take the
rtnl lock from a workqueue context, and thus that can deadlock.
This reworks things a bit in that area to avoid the problem.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/net/ibm_newemac/core.c | 31 ++++++++++++++++++++-----------
drivers/net/ibm_newemac/core.h | 1 +
2 files changed, 21 insertions(+), 11 deletions(-)
Index: linux-work/drivers/net/ibm_newemac/core.c
===================================================================
--- linux-work.orig/drivers/net/ibm_newemac/core.c 2007-11-20 14:42:50.000000000 +1100
+++ linux-work/drivers/net/ibm_newemac/core.c 2007-11-20 14:46:51.000000000 +1100
@@ -642,9 +642,11 @@ static void emac_reset_work(struct work_
DBG(dev, "reset_work" NL);
mutex_lock(&dev->link_lock);
- emac_netif_stop(dev);
- emac_full_tx_reset(dev);
- emac_netif_start(dev);
+ if (dev->opened) {
+ emac_netif_stop(dev);
+ emac_full_tx_reset(dev);
+ emac_netif_start(dev);
+ }
mutex_unlock(&dev->link_lock);
}
@@ -1063,10 +1065,9 @@ static int emac_open(struct net_device *
dev->rx_sg_skb = NULL;
mutex_lock(&dev->link_lock);
+ dev->opened = 1;
- /* XXX Start PHY polling now. Shouldn't wr do like sungem instead and
- * always poll the PHY even when the iface is down ? That would allow
- * things like laptop-net to work. --BenH
+ /* Start PHY polling now.
*/
if (dev->phy.address >= 0) {
int link_poll_interval;
@@ -1145,9 +1146,11 @@ static void emac_link_timer(struct work_
int link_poll_interval;
mutex_lock(&dev->link_lock);
-
DBG2(dev, "link timer" NL);
+ if (!dev->opened)
+ goto bail;
+
if (dev->phy.def->ops->poll_link(&dev->phy)) {
if (!netif_carrier_ok(dev->ndev)) {
/* Get new link parameters */
@@ -1170,13 +1173,14 @@ static void emac_link_timer(struct work_
link_poll_interval = PHY_POLL_LINK_OFF;
}
schedule_delayed_work(&dev->link_work, link_poll_interval);
-
+ bail:
mutex_unlock(&dev->link_lock);
}
static void emac_force_link_update(struct emac_instance *dev)
{
netif_carrier_off(dev->ndev);
+ smp_rmb();
if (dev->link_polling) {
cancel_rearming_delayed_work(&dev->link_work);
if (dev->link_polling)
@@ -1191,11 +1195,14 @@ static int emac_close(struct net_device
DBG(dev, "close" NL);
- if (dev->phy.address >= 0)
+ if (dev->phy.address >= 0) {
+ dev->link_polling = 0;
cancel_rearming_delayed_work(&dev->link_work);
-
+ }
+ mutex_lock(&dev->link_lock);
emac_netif_stop(dev);
- flush_scheduled_work();
+ dev->opened = 0;
+ mutex_unlock(&dev->link_lock);
emac_rx_disable(dev);
emac_tx_disable(dev);
@@ -2756,6 +2763,8 @@ static int __devexit emac_remove(struct
unregister_netdev(dev->ndev);
+ flush_scheduled_work();
+
if (emac_has_feature(dev, EMAC_FTR_HAS_TAH))
tah_detach(dev->tah_dev, dev->tah_port);
if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII))
Index: linux-work/drivers/net/ibm_newemac/core.h
===================================================================
--- linux-work.orig/drivers/net/ibm_newemac/core.h 2007-11-20 14:42:50.000000000 +1100
+++ linux-work/drivers/net/ibm_newemac/core.h 2007-11-20 14:46:51.000000000 +1100
@@ -258,6 +258,7 @@ struct emac_instance {
int stop_timeout; /* in us */
int no_mcast;
int mcast_pending;
+ int opened;
struct work_struct reset_work;
spinlock_t lock;
};
^ permalink raw reply
* [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Kumar Gala @ 2007-11-20 3:36 UTC (permalink / raw)
To: linuxppc-dev
isel (Integer Select) is a new user space instruction in the
PowerISA 2.04 spec. Not all processors implement it so lets emulate
to ensure code built with isel will run everywhere.
---
arch/powerpc/kernel/traps.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
In my git tree for 2.6.25.
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 59c464e..cad6484 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -622,6 +622,9 @@ static void parse_fpe(struct pt_regs *regs)
#define INST_POPCNTB 0x7c0000f4
#define INST_POPCNTB_MASK 0xfc0007fe
+#define INST_ISEL 0x7c00001e
+#define INST_ISEL_MASK 0xfc00003e
+
static int emulate_string_inst(struct pt_regs *regs, u32 instword)
{
u8 rT = (instword >> 21) & 0x1f;
@@ -707,6 +710,23 @@ static int emulate_popcntb_inst(struct pt_regs *regs, u32 instword)
return 0;
}
+static int emulate_isel(struct pt_regs *regs, u32 instword)
+{
+ u8 rT = (instword >> 21) & 0x1f;
+ u8 rA = (instword >> 16) & 0x1f;
+ u8 rB = (instword >> 11) & 0x1f;
+ u8 BC = (instword >> 6) & 0x1f;
+ u8 bit;
+ unsigned long tmp;
+
+ tmp = (rA == 0) ? 0 : regs->gpr[rA];
+ bit = (regs->ccr >> (31 - BC)) & 0x1;
+
+ regs->gpr[rT] = bit ? tmp : regs->gpr[rB];
+
+ return 0;
+}
+
static int emulate_instruction(struct pt_regs *regs)
{
u32 instword;
@@ -749,6 +769,11 @@ static int emulate_instruction(struct pt_regs *regs)
return emulate_popcntb_inst(regs, instword);
}
+ /* Emulate isel (Integer Select) instruction */
+ if ((instword & INST_ISEL_MASK) == INST_ISEL) {
+ return emulate_isel(regs, instword);
+ }
+
return -EINVAL;
}
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH v2] PMU: replace information ioctls and schedule for removal
From: Paul Mackerras @ 2007-11-20 3:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1194981108.6695.11.camel@johannes.berg>
Johannes Berg writes:
> This patch adds sysfs attributes to the PMU to allow getting
> the information on the PMU type and whether adb is present from
> there instead of via the ioctl. The ioctl is made optional and
> scheduled for removal.
I don't see any reason to ever remove the ioctls. We're talking about
just 4 lines of code here. Sure we can add the sysfs attributes -
even though that adds an order of magnitude more lines of code
(thanks sysfs :) but I don't see any good reason to remove the
existing interface.
Paul.
^ permalink raw reply
* [PATCH] fix scaled time accounting possible divide by zero
From: Michael Neuling @ 2007-11-20 3:25 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Balbir Singh
This fixes a problem noticed by Balbir Singh
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Paulus: can we send this up for 2.6.24?
arch/powerpc/kernel/time.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/time.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/time.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/time.c
@@ -244,8 +244,9 @@ void account_system_vtime(struct task_st
/* deltascaled includes both user and system time.
* Hence scale it based on the purr ratio to estimate
* the system time */
- deltascaled = deltascaled * get_paca()->system_time /
- (get_paca()->system_time + get_paca()->user_time);
+ if (get_paca()->user_time)
+ deltascaled = deltascaled * get_paca()->system_time /
+ (get_paca()->system_time + get_paca()->user_time);
delta += get_paca()->system_time;
get_paca()->system_time = 0;
}
^ permalink raw reply
* libfdt: Abolish _typed() variants, add _cell() variants
From: David Gibson @ 2007-11-20 2:35 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In a number of places through libfdt and its tests, we have *_typed()
macro variants on functions which use gcc's typeof and statement
expression extensions to allow passing literals where the underlying
function takes a buffer and size.
These seemed like a good idea at the time, but in fact they have some
problems. They use typeof and statement expressions, extensions I'd
prefer to avoid for portability. Plus, they have potential gotchas -
although they'll deal with the size of the thing passed, they won't
deal with other representation issues (like endianness) and results
could be very strange if the type of the expression passed isn't what
you think it is.
In fact, the only users of these _typed() macros were when the value
passed is a single cell (32-bit integer). Therefore, this patch
removes all these _typed() macros and replaces them with explicit
_cell() variants which handle a single 32-bit integer, and which also
perform endian convesions as appropriate.
With this in place, it now becomes easy to use standardized big-endian
representation for integer valued properties in the testcases,
regardless of the platform we're running on. We therefore do that,
which has the additional advantage that all the example trees created
during a test run are now byte-for-byte identical regardless of
platform.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-11-20 13:04:09.000000000 +1100
+++ dtc/libfdt/libfdt.h 2007-11-20 13:05:24.000000000 +1100
@@ -657,12 +657,12 @@ int fdt_node_offset_by_compatible(const
int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
const void *val, int len);
-
-#define fdt_setprop_inplace_typed(fdt, nodeoffset, name, val) \
- ({ \
- typeof(val) x = val; \
- fdt_setprop_inplace(fdt, nodeoffset, name, &x, sizeof(x)); \
- })
+static inline int fdt_setprop_inplace_cell(void *fdt, int nodeoffset,
+ const char *name, uint32_t val)
+{
+ val = cpu_to_fdt32(val);
+ return fdt_setprop_inplace(fdt, nodeoffset, name, &val, sizeof(val));
+}
int fdt_nop_property(void *fdt, int nodeoffset, const char *name);
int fdt_nop_node(void *fdt, int nodeoffset);
@@ -676,11 +676,11 @@ int fdt_add_reservemap_entry(void *fdt,
int fdt_finish_reservemap(void *fdt);
int fdt_begin_node(void *fdt, const char *name);
int fdt_property(void *fdt, const char *name, const void *val, int len);
-#define fdt_property_typed(fdt, name, val) \
- ({ \
- typeof(val) x = (val); \
- fdt_property((fdt), (name), &x, sizeof(x)); \
- })
+static inline int fdt_property_cell(void *fdt, const char *name, uint32_t val)
+{
+ val = cpu_to_fdt32(val);
+ return fdt_property(fdt, name, &val, sizeof(val));
+}
#define fdt_property_string(fdt, name, str) \
fdt_property(fdt, name, str, strlen(str)+1)
int fdt_end_node(void *fdt);
@@ -698,11 +698,12 @@ int fdt_del_mem_rsv(void *fdt, int n);
int fdt_setprop(void *fdt, int nodeoffset, const char *name,
const void *val, int len);
-#define fdt_setprop_typed(fdt, nodeoffset, name, val) \
- ({ \
- typeof(val) x = (val); \
- fdt_setprop((fdt), (nodeoffset), (name), &x, sizeof(x)); \
- })
+static inline int fdt_setprop_cell(void *fdt, int nodeoffset, const char *name,
+ uint32_t val)
+{
+ val = cpu_to_fdt32(val);
+ return fdt_setprop(fdt, nodeoffset, name, &val, sizeof(val));
+}
#define fdt_setprop_string(fdt, nodeoffset, name, str) \
fdt_setprop((fdt), (nodeoffset), (name), (str), strlen(str)+1)
int fdt_delprop(void *fdt, int nodeoffset, const char *name);
Index: dtc/tests/setprop_inplace.c
===================================================================
--- dtc.orig/tests/setprop_inplace.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/setprop_inplace.c 2007-11-20 13:05:55.000000000 +1100
@@ -42,14 +42,14 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- intp = check_getprop_typed(fdt, 0, "prop-int", TEST_VALUE_1);
+ intp = check_getprop_cell(fdt, 0, "prop-int", TEST_VALUE_1);
verbose_printf("Old int value was 0x%08x\n", *intp);
- err = fdt_setprop_inplace_typed(fdt, 0, "prop-int", ~TEST_VALUE_1);
+ err = fdt_setprop_inplace_cell(fdt, 0, "prop-int", ~TEST_VALUE_1);
if (err)
FAIL("Failed to set \"prop-int\" to 0x08%x: %s",
~TEST_VALUE_1, fdt_strerror(err));
- intp = check_getprop_typed(fdt, 0, "prop-int", ~TEST_VALUE_1);
+ intp = check_getprop_cell(fdt, 0, "prop-int", ~TEST_VALUE_1);
verbose_printf("New int value is 0x%08x\n", *intp);
strp = check_getprop(fdt, 0, "prop-str", strlen(TEST_STRING_1)+1,
Index: dtc/tests/del_node.c
===================================================================
--- dtc.orig/tests/del_node.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/del_node.c 2007-11-20 13:04:09.000000000 +1100
@@ -48,19 +48,19 @@ int main(int argc, char *argv[])
if (subnode1_offset < 0)
FAIL("Couldn't find \"/subnode@1\": %s",
fdt_strerror(subnode1_offset));
- check_getprop_typed(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
+ check_getprop_cell(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode@2\": %s",
fdt_strerror(subnode2_offset));
- check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
- check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
err = fdt_del_node(fdt, subnode1_offset);
if (err)
@@ -76,13 +76,13 @@ int main(int argc, char *argv[])
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode2\": %s",
fdt_strerror(subnode2_offset));
- check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
- check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
err = fdt_del_node(fdt, subnode2_offset);
if (err)
Index: dtc/tests/del_property.c
===================================================================
--- dtc.orig/tests/del_property.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/del_property.c 2007-11-20 13:04:09.000000000 +1100
@@ -45,7 +45,7 @@ int main(int argc, char *argv[])
oldsize = fdt_totalsize(fdt);
- intp = check_getprop_typed(fdt, 0, "prop-int", TEST_VALUE_1);
+ intp = check_getprop_cell(fdt, 0, "prop-int", TEST_VALUE_1);
verbose_printf("int value was 0x%08x\n", *intp);
err = fdt_delprop(fdt, 0, "prop-int");
Index: dtc/tests/find_property.c
===================================================================
--- dtc.orig/tests/find_property.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/find_property.c 2007-11-20 13:04:09.000000000 +1100
@@ -35,7 +35,7 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- check_property_typed(fdt, 0, "prop-int", TEST_VALUE_1);
+ check_property_cell(fdt, 0, "prop-int", TEST_VALUE_1);
check_property(fdt, 0, "prop-str", strlen(TEST_STRING_1)+1, TEST_STRING_1);
PASS();
Index: dtc/tests/getprop.c
===================================================================
--- dtc.orig/tests/getprop.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/getprop.c 2007-11-20 13:04:09.000000000 +1100
@@ -36,7 +36,7 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- check_getprop_typed(fdt, 0, "prop-int", TEST_VALUE_1);
+ check_getprop_cell(fdt, 0, "prop-int", TEST_VALUE_1);
check_getprop(fdt, 0, "prop-str", strlen(TEST_STRING_1)+1, TEST_STRING_1);
PASS();
Index: dtc/tests/node_offset_by_prop_value.c
===================================================================
--- dtc.orig/tests/node_offset_by_prop_value.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/node_offset_by_prop_value.c 2007-11-20 13:04:09.000000000 +1100
@@ -67,9 +67,9 @@ void check_search_str(void *fdt, const c
va_end(ap);
}
-#define check_search_val(fdt, propname, propval, ...) \
+#define check_search_cell(fdt, propname, propval, ...) \
{ \
- typeof(propval) val = (propval); \
+ uint32_t val = cpu_to_fdt32(propval); \
check_search((fdt), (propname), &val, sizeof(val), \
##__VA_ARGS__); \
}
@@ -92,17 +92,17 @@ int main(int argc, char *argv[])
|| (subsubnode1_offset < 0) || (subsubnode2_offset < 0))
FAIL("Can't find required nodes");
- check_search_val(fdt, "prop-int", TEST_VALUE_1, 0, subnode1_offset,
- subsubnode1_offset, -FDT_ERR_NOTFOUND);
+ check_search_cell(fdt, "prop-int", TEST_VALUE_1, 0, subnode1_offset,
+ subsubnode1_offset, -FDT_ERR_NOTFOUND);
- check_search_val(fdt, "prop-int", TEST_VALUE_2, subnode2_offset,
- subsubnode2_offset, -FDT_ERR_NOTFOUND);
+ check_search_cell(fdt, "prop-int", TEST_VALUE_2, subnode2_offset,
+ subsubnode2_offset, -FDT_ERR_NOTFOUND);
check_search_str(fdt, "prop-str", TEST_STRING_1, 0, -FDT_ERR_NOTFOUND);
check_search_str(fdt, "prop-str", "no such string", -FDT_ERR_NOTFOUND);
- check_search_val(fdt, "prop-int", TEST_VALUE_1+1, -FDT_ERR_NOTFOUND);
+ check_search_cell(fdt, "prop-int", TEST_VALUE_1+1, -FDT_ERR_NOTFOUND);
check_search(fdt, "no-such-prop", NULL, 0, -FDT_ERR_NOTFOUND);
Index: dtc/tests/nop_node.c
===================================================================
--- dtc.orig/tests/nop_node.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/nop_node.c 2007-11-20 13:04:09.000000000 +1100
@@ -43,19 +43,19 @@ int main(int argc, char *argv[])
if (subnode1_offset < 0)
FAIL("Couldn't find \"/subnode1\": %s",
fdt_strerror(subnode1_offset));
- check_getprop_typed(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
+ check_getprop_cell(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode2\": %s",
fdt_strerror(subnode2_offset));
- check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
- check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
err = fdt_nop_node(fdt, subnode1_offset);
if (err)
@@ -71,13 +71,13 @@ int main(int argc, char *argv[])
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode2\": %s",
fdt_strerror(subnode2_offset));
- check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
- check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
+ check_getprop_cell(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
err = fdt_nop_node(fdt, subnode2_offset);
if (err)
Index: dtc/tests/nop_property.c
===================================================================
--- dtc.orig/tests/nop_property.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/nop_property.c 2007-11-20 13:04:09.000000000 +1100
@@ -41,7 +41,7 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- intp = check_getprop_typed(fdt, 0, "prop-int", TEST_VALUE_1);
+ intp = check_getprop_cell(fdt, 0, "prop-int", TEST_VALUE_1);
verbose_printf("int value was 0x%08x\n", *intp);
err = fdt_nop_property(fdt, 0, "prop-int");
Index: dtc/tests/rw_tree1.c
===================================================================
--- dtc.orig/tests/rw_tree1.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/rw_tree1.c 2007-11-20 13:04:09.000000000 +1100
@@ -73,27 +73,25 @@ int main(int argc, char *argv[])
CHECK(fdt_add_mem_rsv(fdt, TEST_ADDR_2, TEST_SIZE_2));
CHECK(fdt_setprop_string(fdt, 0, "compatible", "test_tree1"));
- CHECK(fdt_setprop_typed(fdt, 0, "prop-int", TEST_VALUE_1));
+ CHECK(fdt_setprop_cell(fdt, 0, "prop-int", TEST_VALUE_1));
CHECK(fdt_setprop_string(fdt, 0, "prop-str", TEST_STRING_1));
OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode@1"));
CHECK(fdt_setprop_string(fdt, offset, "compatible", "subnode1"));
- CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_1));
+ CHECK(fdt_setprop_cell(fdt, offset, "prop-int", TEST_VALUE_1));
OFF_CHECK(offset, fdt_add_subnode(fdt, offset, "subsubnode"));
CHECK(fdt_setprop(fdt, offset, "compatible",
"subsubnode1\0subsubnode", 23));
- CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_1));
+ CHECK(fdt_setprop_cell(fdt, offset, "prop-int", TEST_VALUE_1));
OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode@2"));
- CHECK(fdt_setprop_typed(fdt, offset, "linux,phandle",
- cpu_to_fdt32(PHANDLE_1)));
- CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_2));
+ CHECK(fdt_setprop_cell(fdt, offset, "linux,phandle", PHANDLE_1));
+ CHECK(fdt_setprop_cell(fdt, offset, "prop-int", TEST_VALUE_2));
OFF_CHECK(offset, fdt_add_subnode(fdt, offset, "subsubnode@0"));
- CHECK(fdt_setprop_typed(fdt, offset, "linux,phandle",
- cpu_to_fdt32(PHANDLE_2)));
+ CHECK(fdt_setprop_cell(fdt, offset, "linux,phandle", PHANDLE_2));
CHECK(fdt_setprop(fdt, offset, "compatible",
"subsubnode2\0subsubnode", 23));
- CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_2));
+ CHECK(fdt_setprop_cell(fdt, offset, "prop-int", TEST_VALUE_2));
CHECK(fdt_pack(fdt));
Index: dtc/tests/setprop.c
===================================================================
--- dtc.orig/tests/setprop.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/setprop.c 2007-11-20 13:04:09.000000000 +1100
@@ -52,7 +52,7 @@ int main(int argc, char *argv[])
fdt = buf;
- intp = check_getprop_typed(fdt, 0, "prop-int", TEST_VALUE_1);
+ intp = check_getprop_cell(fdt, 0, "prop-int", TEST_VALUE_1);
verbose_printf("Old int value was 0x%08x\n", *intp);
err = fdt_setprop_string(fdt, 0, "prop-int", NEW_STRING);
Index: dtc/tests/subnode_offset.c
===================================================================
--- dtc.orig/tests/subnode_offset.c 2007-11-20 13:04:09.000000000 +1100
+++ dtc/tests/subnode_offset.c 2007-11-20 13:04:09.000000000 +1100
@@ -70,16 +70,16 @@ int main(int argc, char *argv[])
if (subnode1_offset == subnode2_offset)
FAIL("Different subnodes have same offset");
- check_property_typed(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
- check_property_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
+ check_property_cell(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
+ check_property_cell(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
subsubnode1_offset = check_subnode(fdt, subnode1_offset, "subsubnode");
subsubnode2_offset = check_subnode(fdt, subnode2_offset, "subsubnode@0");
subsubnode2_offset2 = check_subnode(fdt, subnode2_offset, "subsubnode");
- check_property_typed(fdt, subsubnode1_offset, "prop-int", TEST_VALUE_1);
- check_property_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
- check_property_typed(fdt, subsubnode2_offset2, "prop-int", TEST_VALUE_2);
+ check_property_cell(fdt, subsubnode1_offset, "prop-int", TEST_VALUE_1);
+ check_property_cell(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
+ check_property_cell(fdt, subsubnode2_offset2, "prop-int", TEST_VALUE_2);
if (subsubnode2_offset != subsubnode2_offset2)
FAIL("Different offsets with and without unit address");
Index: dtc/tests/sw_tree1.c
===================================================================
--- dtc.orig/tests/sw_tree1.c 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/sw_tree1.c 2007-11-20 13:04:09.000000000 +1100
@@ -55,27 +55,27 @@ int main(int argc, char *argv[])
CHECK(fdt_begin_node(fdt, ""));
CHECK(fdt_property_string(fdt, "compatible", "test_tree1"));
- CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
+ CHECK(fdt_property_cell(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_property_string(fdt, "prop-str", TEST_STRING_1));
CHECK(fdt_begin_node(fdt, "subnode@1"));
CHECK(fdt_property_string(fdt, "compatible", "subnode1"));
- CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
+ CHECK(fdt_property_cell(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_begin_node(fdt, "subsubnode"));
CHECK(fdt_property(fdt, "compatible", "subsubnode1\0subsubnode",
23));
- CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
+ CHECK(fdt_property_cell(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_end_node(fdt));
CHECK(fdt_end_node(fdt));
CHECK(fdt_begin_node(fdt, "subnode@2"));
- CHECK(fdt_property_typed(fdt, "linux,phandle", cpu_to_fdt32(PHANDLE_1)));
- CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_2));
+ CHECK(fdt_property_cell(fdt, "linux,phandle", PHANDLE_1));
+ CHECK(fdt_property_cell(fdt, "prop-int", TEST_VALUE_2));
CHECK(fdt_begin_node(fdt, "subsubnode@0"));
- CHECK(fdt_property_typed(fdt, "linux,phandle", cpu_to_fdt32(PHANDLE_2)));
+ CHECK(fdt_property_cell(fdt, "linux,phandle", PHANDLE_2));
CHECK(fdt_property(fdt, "compatible", "subsubnode2\0subsubnode",
23));
- CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_2));
+ CHECK(fdt_property_cell(fdt, "prop-int", TEST_VALUE_2));
CHECK(fdt_end_node(fdt));
CHECK(fdt_end_node(fdt));
Index: dtc/tests/testdata.h
===================================================================
--- dtc.orig/tests/testdata.h 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/testdata.h 2007-11-20 13:04:09.000000000 +1100
@@ -20,8 +20,8 @@
#define TEST_ADDR_2 ASM_CONST_LL(123456789)
#define TEST_SIZE_2 ASM_CONST_LL(010000)
-#define TEST_VALUE_1 cell_to_fdt(0xdeadbeef)
-#define TEST_VALUE_2 cell_to_fdt(123456789)
+#define TEST_VALUE_1 0xdeadbeef
+#define TEST_VALUE_2 123456789
#define PHANDLE_1 0x2000
#define PHANDLE_2 0x2001
Index: dtc/tests/tests.h
===================================================================
--- dtc.orig/tests/tests.h 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/tests.h 2007-11-20 13:04:09.000000000 +1100
@@ -112,18 +112,18 @@ void check_mem_rsv(void *fdt, int n, uin
void check_property(void *fdt, int nodeoffset, const char *name,
int len, const void *val);
-#define check_property_typed(fdt, nodeoffset, name, val) \
+#define check_property_cell(fdt, nodeoffset, name, val) \
({ \
- typeof(val) x = val; \
+ uint32_t x = cpu_to_fdt32(val); \
check_property(fdt, nodeoffset, name, sizeof(x), &x); \
})
const void *check_getprop(void *fdt, int nodeoffset, const char *name,
int len, const void *val);
-#define check_getprop_typed(fdt, nodeoffset, name, val) \
+#define check_getprop_cell(fdt, nodeoffset, name, val) \
({ \
- typeof(val) x = val; \
+ uint32_t x = cpu_to_fdt32(val); \
check_getprop(fdt, nodeoffset, name, sizeof(x), &x); \
})
#define check_getprop_string(fdt, nodeoffset, name, s) \
Index: dtc/tests/trees.S
===================================================================
--- dtc.orig/tests/trees.S 2007-11-20 10:15:51.000000000 +1100
+++ dtc/tests/trees.S 2007-11-20 13:04:09.000000000 +1100
@@ -50,8 +50,7 @@ tree##_rsvmap_end: ;
#define PROP_INT(tree, name, val) \
PROPHDR(tree, name, 4) \
- /* For ease of testing the property values go in native-endian */ \
- .long val ;
+ FDTLONG(val) ;
#define PROP_STR(tree, name, str) \
PROPHDR(tree, name, 55f - 54f) \
@@ -100,11 +99,11 @@ test_tree1_struct:
END_NODE
BEGIN_NODE("subnode@2")
- PROP_INT(test_tree1, phandle, cell_to_fdt(PHANDLE_1))
+ PROP_INT(test_tree1, phandle, PHANDLE_1)
PROP_INT(test_tree1, prop_int, TEST_VALUE_2)
BEGIN_NODE("subsubnode@0")
- PROP_INT(test_tree1, phandle, cell_to_fdt(PHANDLE_2))
+ PROP_INT(test_tree1, phandle, PHANDLE_2)
PROP_STR(test_tree1, compatible, "subsubnode2\0subsubnode")
PROP_INT(test_tree1, prop_int, TEST_VALUE_2)
END_NODE
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH 03/59] arch/powerpc: Add missing "space"
From: Joe Perches @ 2007-11-20 1:47 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, anton, Paul Mackerras, Anton Blanchard, paulus
In-Reply-To: <ee1678e1bc8b80b7ae420059fffc7241486ea91a.1195454434.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/powerpc/kernel/isa-bridge.c | 4 ++--
arch/powerpc/mm/fault.c | 2 +-
arch/powerpc/platforms/8xx/m8xx_setup.c | 2 +-
arch/powerpc/platforms/celleb/io-workarounds.c | 2 +-
arch/powerpc/platforms/celleb/scc_epci.c | 2 +-
arch/powerpc/sysdev/fsl_pci.c | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/isa-bridge.c b/arch/powerpc/kernel/isa-bridge.c
index f0f49d1..965bfcc 100644
--- a/arch/powerpc/kernel/isa-bridge.c
+++ b/arch/powerpc/kernel/isa-bridge.c
@@ -108,7 +108,7 @@ static void __devinit pci_process_ISA_OF_ranges(struct device_node *isa_node,
if (size > 0x10000)
size = 0x10000;
- printk(KERN_ERR "no ISA IO ranges or unexpected isa range,"
+ printk(KERN_ERR "no ISA IO ranges or unexpected isa range, "
"mapping 64k\n");
__ioremap_at(phb_io_base_phys, (void *)ISA_IO_BASE,
@@ -116,7 +116,7 @@ static void __devinit pci_process_ISA_OF_ranges(struct device_node *isa_node,
return;
inval_range:
- printk(KERN_ERR "no ISA IO ranges or unexpected isa range,"
+ printk(KERN_ERR "no ISA IO ranges or unexpected isa range, "
"mapping 64k\n");
__ioremap_at(phb_io_base_phys, (void *)ISA_IO_BASE,
0x10000, _PAGE_NO_CACHE|_PAGE_GUARDED);
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 8135da0..10dda22 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -189,7 +189,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
return SIGSEGV;
/* in_atomic() in user mode is really bad,
as is current->mm == NULL. */
- printk(KERN_EMERG "Page fault in user mode with"
+ printk(KERN_EMERG "Page fault in user mode with "
"in_atomic() = %d mm = %p\n", in_atomic(), mm);
printk(KERN_EMERG "NIP = %lx MSR = %lx\n",
regs->nip, regs->msr);
diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c b/arch/powerpc/platforms/8xx/m8xx_setup.c
index d35eda8..ba645c2 100644
--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
@@ -120,7 +120,7 @@ void __init mpc8xx_calibrate_decr(void)
ppc_tb_freq /= 16;
ppc_proc_freq = 50000000;
if (!get_freq("clock-frequency", &ppc_proc_freq))
- printk(KERN_ERR "WARNING: Estimating processor frequency"
+ printk(KERN_ERR "WARNING: Estimating processor frequency "
"(not found)\n");
printk("Decrementer Frequency = 0x%lx\n", ppc_tb_freq);
diff --git a/arch/powerpc/platforms/celleb/io-workarounds.c b/arch/powerpc/platforms/celleb/io-workarounds.c
index 2b91214..32b9cec 100644
--- a/arch/powerpc/platforms/celleb/io-workarounds.c
+++ b/arch/powerpc/platforms/celleb/io-workarounds.c
@@ -256,7 +256,7 @@ int __init celleb_pci_workaround_init(void)
celleb_dummy_page_va = kmalloc(PAGE_SIZE, GFP_KERNEL);
if (!celleb_dummy_page_va) {
- printk(KERN_ERR "Celleb: dummy read disabled."
+ printk(KERN_ERR "Celleb: dummy read disabled. "
"Alloc celleb_dummy_page_va failed\n");
return 1;
}
diff --git a/arch/powerpc/platforms/celleb/scc_epci.c b/arch/powerpc/platforms/celleb/scc_epci.c
index 9d07642..a3c7cfb 100644
--- a/arch/powerpc/platforms/celleb/scc_epci.c
+++ b/arch/powerpc/platforms/celleb/scc_epci.c
@@ -95,7 +95,7 @@ void __init epci_workaround_init(struct pci_controller *hose)
private->dummy_page_da = dma_map_single(hose->parent,
celleb_dummy_page_va, PAGE_SIZE, DMA_FROM_DEVICE);
if (private->dummy_page_da == DMA_ERROR_CODE) {
- printk(KERN_ERR "EPCI: dummy read disabled."
+ printk(KERN_ERR "EPCI: dummy read disabled. "
"Map dummy page failed.\n");
return;
}
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 33df4c3..87e58e0 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -222,7 +222,7 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
hose->indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
}
- printk(KERN_INFO "Found FSL PCI host bridge at 0x%016llx."
+ printk(KERN_INFO "Found FSL PCI host bridge at 0x%016llx. "
"Firmware bus number: %d->%d\n",
(unsigned long long)rsrc.start, hose->first_busno,
hose->last_busno);
--
1.5.3.5.652.gf192c
^ permalink raw reply related
* [PATCH 04/59] arch/ppc: Add missing "space"
From: Joe Perches @ 2007-11-20 1:47 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <ee1678e1bc8b80b7ae420059fffc7241486ea91a.1195454434.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/ppc/platforms/ev64260.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/ppc/platforms/ev64260.c b/arch/ppc/platforms/ev64260.c
index 976270d..c1f77e1 100644
--- a/arch/ppc/platforms/ev64260.c
+++ b/arch/ppc/platforms/ev64260.c
@@ -336,7 +336,7 @@ ev64260_early_serial_map(void)
#endif
if (early_serial_setup(&port) != 0)
- printk(KERN_WARNING "Early serial init of port 0"
+ printk(KERN_WARNING "Early serial init of port 0 "
"failed\n");
first_time = 0;
@@ -388,7 +388,7 @@ ev64260_setup_arch(void)
ev64260_early_serial_map();
#endif
- printk(KERN_INFO "%s %s port (C) 2001 MontaVista Software, Inc."
+ printk(KERN_INFO "%s %s port (C) 2001 MontaVista Software, Inc. "
"(source@mvista.com)\n", BOARD_VENDOR, BOARD_MACHINE);
if (ppc_md.progress)
--
1.5.3.5.652.gf192c
^ permalink raw reply related
* Re: Revisited, audio codec device tree entries.
From: David Gibson @ 2007-11-20 1:42 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <4741C0C4.4070502@genesi-usa.com>
On Mon, Nov 19, 2007 at 04:58:44PM +0000, Matt Sealey wrote:
> Segher Boessenkool wrote:
> >> And I forgot the rant you guys usually get - for god's sake, why isn't
> >> anyone using the "model" property?
> >
> > Probably because it isn't useful all that often.
> >
> >> sound@0 {
> >> \\ this is our magic audio fabric
> >> device_type = "digispeaker,flinger";
> >
> > This is wrong in so many ways; see David's mail for a start.
>
> Why? I'm sorry but I am living in the real world where we have real
> firmwares and real dynamic device trees here. You can't just say
> "this is wrong because it has a device_type".
It's not wrong because it has a device_type, it's wrong because the
device_type value is some random made-up thing that doesn't have an OF
binding behind it. Nor do you suggest an OF binding. Nor should
driver selection be based off device_type.
--
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
* Please pull from 'for-2.6.24' branch of pasemi tree
From: Olof Johansson @ 2007-11-20 1:34 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.24
For the following bugfix for 2.6.24:
Olof Johansson (1):
[POWERPC] pasemi: Don't reset mpic at boot
setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Thanks,
Olof
^ permalink raw reply
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Jeff Garzik @ 2007-11-20 1:30 UTC (permalink / raw)
To: Kim Phillips; +Cc: netdev, Li Yang, paulus, linuxppc-dev
In-Reply-To: <20071119173652.55e385b2.kim.phillips@freescale.com>
Kim Phillips wrote:
> On Mon, 5 Nov 2007 12:15:30 -0600
> Kim Phillips <kim.phillips@freescale.com> wrote:
>
>> Hello all,
>>
>> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
>> according to erratum #2 (erratum text included below). Basically the
>> most intrusive part is the addition of two new RGMII Internal Delay
>> modes; one for TX delay only, and the other for RX delay only (i.e, not
>> both at the same time).
>>
>> Please review, and since this affects both netdev and powerpc trees,
>> one maintainer should ack them for the other to push upstream (i.e,
>> Kumar acks them, and Leo picks them up to go through netdev or the
>> other way around; either way is fine with me). I'm hoping they're
>> trivial enough to go in 2.6.24.
>>
> Kumar, Leo,
>
> re-ping due to (a) it's been 2 weeks and (b) Anton Vorontsov has since
> issued his Tested-by.
>
> Might I suggest Kumar ack the powerpc patches, and Leo/Jeff apply 5/5
> to go through netdev?
FWIW I just got back from vacation... I'm grabbing what DaveM has
collected into davem/netdev-2.6.git, and then going from there...
Jeff
^ permalink raw reply
* [PATCH] powerpc: fix os-term usage on kernel panic
From: Linas Vepstas @ 2007-11-20 1:28 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
The rtas_os_term() routine was being called at the wrong time.
The actual rtas call "os-term" will not ever return, and so
calling it from the panic notifier is too early. Instead,
call it from the machine_reset() call.
The patch splits the rtas_os_term() routine into two: one
part to capture the kernel panic message, invoked during
the panic notifier, and another part that is invoked during
machine_reset().
Prior to this patch, the os-term call was never being made,
because panic_timeout was always non-zero. Calling os-term
helps keep the hypervisor happy! We have to keep the hypervisor
happy to avoid service, dump and error reporting problems.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
One could make a strong argument to move all of this code
from kernel/rtas.c to platforms/pseries/setup.c I did not
do this, just so as to make the changes minimal.
arch/powerpc/kernel/rtas.c | 12 ++++++------
arch/powerpc/platforms/pseries/setup.c | 3 ++-
include/asm-powerpc/rtas.h | 3 ++-
3 files changed, 10 insertions(+), 8 deletions(-)
Index: linux-2.6.24-rc2-git4/arch/powerpc/kernel/rtas.c
===================================================================
--- linux-2.6.24-rc2-git4.orig/arch/powerpc/kernel/rtas.c 2007-11-19 18:58:53.000000000 -0600
+++ linux-2.6.24-rc2-git4/arch/powerpc/kernel/rtas.c 2007-11-19 19:01:10.000000000 -0600
@@ -631,18 +631,18 @@ void rtas_halt(void)
/* Must be in the RMO region, so we place it here */
static char rtas_os_term_buf[2048];
-void rtas_os_term(char *str)
+void rtas_panic_msg(char *str)
{
- int status;
+ snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
+}
- if (panic_timeout)
- return;
+void rtas_os_term(void)
+{
+ int status;
if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term"))
return;
- snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
-
do {
status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
__pa(rtas_os_term_buf));
Index: linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- linux-2.6.24-rc2-git4.orig/arch/powerpc/platforms/pseries/setup.c 2007-11-19 18:58:53.000000000 -0600
+++ linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/setup.c 2007-11-19 19:01:10.000000000 -0600
@@ -507,7 +507,8 @@ define_machine(pseries) {
.restart = rtas_restart,
.power_off = pSeries_power_off,
.halt = rtas_halt,
- .panic = rtas_os_term,
+ .panic = rtas_panic_msg,
+ .machine_shutdown = rtas_os_term,
.get_boot_time = rtas_get_boot_time,
.get_rtc_time = rtas_get_rtc_time,
.set_rtc_time = rtas_set_rtc_time,
Index: linux-2.6.24-rc2-git4/include/asm-powerpc/rtas.h
===================================================================
--- linux-2.6.24-rc2-git4.orig/include/asm-powerpc/rtas.h 2007-11-19 18:58:53.000000000 -0600
+++ linux-2.6.24-rc2-git4/include/asm-powerpc/rtas.h 2007-11-19 19:01:10.000000000 -0600
@@ -164,7 +164,8 @@ extern int rtas_call(int token, int, int
extern void rtas_restart(char *cmd);
extern void rtas_power_off(void);
extern void rtas_halt(void);
-extern void rtas_os_term(char *str);
+extern void rtas_panic_msg(char *str);
+extern void rtas_os_term(void);
extern int rtas_get_sensor(int sensor, int index, int *state);
extern int rtas_get_power_level(int powerdomain, int *level);
extern int rtas_set_power_level(int powerdomain, int level, int *setlevel);
^ permalink raw reply
* [PATCH v3] [POWERPC] vdso: Fixes for cache block sizes
From: Olof Johansson @ 2007-11-20 1:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, dwmw2
In-Reply-To: <20071119042519.GA28872@lixom.net>
[POWERPC] vdso: Fixes for cache line sizes
Current VDSO implementation is hardcoded to 128 byte cache blocks,
which are only used on IBM's 64-bit processors.
Convert it to get the blocks sizes out of vdso_data instead, similar
to how the ppc64 in-kernel cache flush does it.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
Added back the crclr instructions that got removed by mistake when moving over
the in-kernel functions.
-Olof
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 2c8e756..d67bcd8 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -284,6 +284,10 @@ int main(void)
DEFINE(CFG_SYSCALL_MAP32, offsetof(struct vdso_data, syscall_map_32));
DEFINE(WTOM_CLOCK_SEC, offsetof(struct vdso_data, wtom_clock_sec));
DEFINE(WTOM_CLOCK_NSEC, offsetof(struct vdso_data, wtom_clock_nsec));
+ DEFINE(CFG_ICACHE_BLOCKSZ, offsetof(struct vdso_data, icache_block_size));
+ DEFINE(CFG_DCACHE_BLOCKSZ, offsetof(struct vdso_data, dcache_block_size));
+ DEFINE(CFG_ICACHE_LOGBLOCKSZ, offsetof(struct vdso_data, icache_log_block_size));
+ DEFINE(CFG_DCACHE_LOGBLOCKSZ, offsetof(struct vdso_data, dcache_log_block_size));
#ifdef CONFIG_PPC64
DEFINE(CFG_SYSCALL_MAP64, offsetof(struct vdso_data, syscall_map_64));
DEFINE(TVAL64_TV_SEC, offsetof(struct timeval, tv_sec));
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 2322ba5..3702df7 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -699,11 +699,22 @@ static int __init vdso_init(void)
vdso_data->icache_size = ppc64_caches.isize;
vdso_data->icache_line_size = ppc64_caches.iline_size;
+ /* XXXOJN: Blocks should be added to ppc64_caches and used instead */
+ vdso_data->dcache_block_size = ppc64_caches.dline_size;
+ vdso_data->icache_block_size = ppc64_caches.iline_size;
+ vdso_data->dcache_log_block_size = ppc64_caches.log_dline_size;
+ vdso_data->icache_log_block_size = ppc64_caches.log_iline_size;
+
/*
* Calculate the size of the 64 bits vDSO
*/
vdso64_pages = (&vdso64_end - &vdso64_start) >> PAGE_SHIFT;
DBG("vdso64_kbase: %p, 0x%x pages\n", vdso64_kbase, vdso64_pages);
+#else
+ vdso_data->dcache_block_size = L1_CACHE_BYTES;
+ vdso_data->dcache_log_block_size = L1_CACHE_SHIFT;
+ vdso_data->icache_block_size = L1_CACHE_BYTES;
+ vdso_data->icache_log_block_size = L1_CACHE_SHIFT;
#endif /* CONFIG_PPC64 */
diff --git a/arch/powerpc/kernel/vdso32/cacheflush.S b/arch/powerpc/kernel/vdso32/cacheflush.S
index 9cb3199..1ba6feb 100644
--- a/arch/powerpc/kernel/vdso32/cacheflush.S
+++ b/arch/powerpc/kernel/vdso32/cacheflush.S
@@ -23,29 +23,46 @@
*
* Flushes the data cache & invalidate the instruction cache for the
* provided range [start, end[
- *
- * Note: all CPUs supported by this kernel have a 128 bytes cache
- * line size so we don't have to peek that info from the datapage
*/
V_FUNCTION_BEGIN(__kernel_sync_dicache)
.cfi_startproc
- li r5,127
- andc r6,r3,r5 /* round low to line bdy */
+ mflr r12
+ .cfi_register lr,r12
+ mr r11,r3
+ bl __get_datapage@local
+ mtlr r12
+ mr r10,r3
+
+ lwz r7,CFG_DCACHE_BLOCKSZ(r10)
+ addi r5,r7,-1
+ andc r6,r11,r5 /* round low to line bdy */
subf r8,r6,r4 /* compute length */
add r8,r8,r5 /* ensure we get enough */
- srwi. r8,r8,7 /* compute line count */
+ lwz r9,CFG_DCACHE_LOGBLOCKSZ(r10)
+ srw. r8,r8,r9 /* compute line count */
crclr cr0*4+so
beqlr /* nothing to do? */
mtctr r8
- mr r3,r6
-1: dcbst 0,r3
- addi r3,r3,128
+1: dcbst 0,r6
+ add r6,r6,r7
bdnz 1b
sync
+
+/* Now invalidate the instruction cache */
+
+ lwz r7,CFG_ICACHE_BLOCKSZ(r10)
+ addi r5,r7,-1
+ andc r6,r11,r5 /* round low to line bdy */
+ subf r8,r6,r4 /* compute length */
+ add r8,r8,r5
+ lwz r9,CFG_ICACHE_LOGBLOCKSZ(r10)
+ srw. r8,r8,r9 /* compute line count */
+ crclr cr0*4+so
+ beqlr /* nothing to do? */
mtctr r8
-1: icbi 0,r6
- addi r6,r6,128
- bdnz 1b
+2: icbi 0,r6
+ add r6,r6,r7
+ bdnz 2b
isync
li r3,0
blr
diff --git a/arch/powerpc/kernel/vdso64/cacheflush.S b/arch/powerpc/kernel/vdso64/cacheflush.S
index 66a36d3..69c5af2 100644
--- a/arch/powerpc/kernel/vdso64/cacheflush.S
+++ b/arch/powerpc/kernel/vdso64/cacheflush.S
@@ -23,29 +23,46 @@
*
* Flushes the data cache & invalidate the instruction cache for the
* provided range [start, end[
- *
- * Note: all CPUs supported by this kernel have a 128 bytes cache
- * line size so we don't have to peek that info from the datapage
*/
V_FUNCTION_BEGIN(__kernel_sync_dicache)
.cfi_startproc
- li r5,127
- andc r6,r3,r5 /* round low to line bdy */
+ mflr r12
+ .cfi_register lr,r12
+ mr r11,r3
+ bl V_LOCAL_FUNC(__get_datapage)
+ mtlr r12
+ mr r10,r3
+
+ lwz r7,CFG_DCACHE_BLOCKSZ(r10)
+ addi r5,r7,-1
+ andc r6,r11,r5 /* round low to line bdy */
subf r8,r6,r4 /* compute length */
add r8,r8,r5 /* ensure we get enough */
- srwi. r8,r8,7 /* compute line count */
+ lwz r9,CFG_DCACHE_LOGBLOCKSZ(r10)
+ srw. r8,r8,r9 /* compute line count */
crclr cr0*4+so
beqlr /* nothing to do? */
mtctr r8
- mr r3,r6
-1: dcbst 0,r3
- addi r3,r3,128
+1: dcbst 0,r6
+ add r6,r6,r7
bdnz 1b
sync
+
+/* Now invalidate the instruction cache */
+
+ lwz r7,CFG_ICACHE_BLOCKSZ(r10)
+ addi r5,r7,-1
+ andc r6,r11,r5 /* round low to line bdy */
+ subf r8,r6,r4 /* compute length */
+ add r8,r8,r5
+ lwz r9,CFG_ICACHE_LOGBLOCKSZ(r10)
+ srw. r8,r8,r9 /* compute line count */
+ crclr cr0*4+so
+ beqlr /* nothing to do? */
mtctr r8
-1: icbi 0,r6
- addi r6,r6,128
- bdnz 1b
+2: icbi 0,r6
+ add r6,r6,r7
+ bdnz 2b
isync
li r3,0
blr
diff --git a/include/asm-powerpc/vdso_datapage.h b/include/asm-powerpc/vdso_datapage.h
index 8a94f0e..f013932 100644
--- a/include/asm-powerpc/vdso_datapage.h
+++ b/include/asm-powerpc/vdso_datapage.h
@@ -77,6 +77,10 @@ struct vdso_data {
/* those additional ones don't have to be located anywhere
* special as they were not part of the original systemcfg
*/
+ __u32 dcache_block_size; /* L1 d-cache block size */
+ __u32 icache_block_size; /* L1 i-cache block size */
+ __u32 dcache_log_block_size; /* L1 d-cache log block size */
+ __u32 icache_log_block_size; /* L1 i-cache log block size */
__s32 wtom_clock_sec; /* Wall to monotonic clock */
__s32 wtom_clock_nsec;
__u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
@@ -99,6 +103,10 @@ struct vdso_data {
__s32 wtom_clock_sec; /* Wall to monotonic clock */
__s32 wtom_clock_nsec;
__u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
+ __u32 dcache_block_size; /* L1 d-cache block size */
+ __u32 icache_block_size; /* L1 i-cache block size */
+ __u32 dcache_log_block_size; /* L1 d-cache log block size */
+ __u32 icache_log_block_size; /* L1 i-cache log block size */
};
#endif /* CONFIG_PPC64 */
^ permalink raw reply related
* [PATCH] powerpc: mpc832x mds: Fix board PHY reset code
From: Kim Phillips @ 2007-11-20 1:04 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev; +Cc: Li Yang, peter.vanackeren
currently the board-level PHY reset code for the mpc832x MDS messes with
reset configuration words source settings which is plain wrong (it
looks like this board code was cut-n-pasted from the mpc8360 mds code,
which has the PHY reset bits in a different BCSR); this patch points
the PHY reset code to the proper mpc832x mds PHY reset bits in the BCSR.
Signed-off-by: Peter Van Ackeren <peter.vanackeren@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/platforms/83xx/mpc832x_mds.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index 972fa85..9e3bfcc 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -90,10 +90,11 @@ static void __init mpc832x_sys_setup_arch(void)
if ((np = of_find_compatible_node(NULL, "network", "ucc_geth"))
!= NULL){
- /* Reset the Ethernet PHY */
- bcsr_regs[9] &= ~0x20;
+ /* Reset the Ethernet PHYs */
+#define BCSR8_FETH_RST 0x50
+ bcsr_regs[8] &= ~BCSR8_FETH_RST;
udelay(1000);
- bcsr_regs[9] |= 0x20;
+ bcsr_regs[8] |= BCSR8_FETH_RST;
iounmap(bcsr_regs);
of_node_put(np);
}
--
1.5.2.2
^ permalink raw reply related
* Re: Revisited, audio codec device tree entries.
From: David Gibson @ 2007-11-20 0:59 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40711191128i59245403g3e15e3b6c545b6ee@mail.gmail.com>
On Mon, Nov 19, 2007 at 12:28:02PM -0700, Grant Likely wrote:
> On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > You might be stuck with using either a platform_device or an
> > > of_platform_device as a stepping stone to creating the device on the
> > > ALSA fabric driver.
> >
> > I also concluded that I need a of_platform stepping stone.
> >
> > There are several ways this could be done, which one is the right one?
> > a) fabric is global, create a global device node for it and implement
> > it as a of_platform device
>
> This is really board level description stuff. I'd make the node
> global off the root myself and use whatever linkage you think
> appropriate to get you to the codec nodes (phandle's most likely)
No. I think this is the whole damn point we've been spiralling
around.
An of_platform device is appropriate *only* if there is an OF node for
the device. There should be an OF node for the device only if it it
really is a well-defined hardware component which implements it.
As far as I can understand, the "fabric" driver is really just a
catchall to cover whatever various interconnections there are between
audio components on the board.
Those interconnections could (and probably should) be described in the
OF tree. But that description would be to describe each of those
interconnections individually e.g. codecs have links to "sound PHY"
devices (speakers) or whatever, codecs, i2s AC97 and so forth devices
have links between them appropriate to the type of device. Not as
some imaginary "fabric device".
Therefore the fabric driver cannot be instantiated as an of_platfornm
device.
Therfore arch code will have to instantiate the fabric driver some
other way. There are a couple of options here:
1) We have a "universal" device-tree-based fabric driver which
parses all the above-described interconnection information in the
device tree and handles any situation. Cool, but probably a lot of
work and fiddly to get right.
2) Or, the platform code instantiates an appopriate fabric
driver for the board (which will probably make assumptions about how
things are interconnected). Platform code can optionally examine
board level model properties or other device information to select the
correct fabric driver and/or options. The fabric driver can
optionally look at some parts of the device tree information to
configure details of its operation.
Option (2) is a hack, but it's a reasonably well-contained hack. It
works for now, and doesn't preclude switching to option (1) later -
without changes to the device tree, and on a board-by-board basis. It
can also handle the (almost inevitable) case of device trees with
missing or incorrect detailed audio interconnection information.
The basic thing is that we have a mismatch between the Linux driver
model and the device tree model. Rather than hacking the device tree
to match the Linux model, we should provide whatever glue code is
necessary to instantiate the necessary Linux drivers from the device
tree information we have. This is, essentially, the exact purpose for
which platform code exists.
--
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
* Looking for small form factor with HDLC
From: Kenneth Porter @ 2007-11-20 0:20 UTC (permalink / raw)
To: linuxppc-embedded
I'm attempting to create a middleware system that talks to one of my
vendor's motion control products. My vendor has an FPGA capable of perhaps
10 megabit performance, and RS485 full-duplex tranceivers. I want to be
able to send commands and receive events and bulk data efficiently. I'll
also add electrical isolation, possibly with suitable 485 transceivers.
I'm thinking that HDLC is a natural fit for the bit-level protocol, so I'm
looking for an SBC and Linux OS with natural HDLC support. Ideally the SBC
would fit in a 3"x3"x1" volume, and include Ethernet. It will go on a
backplane along with the motion control box.
The Freescale chips look like many have the hardware to do HDLC, so I'm
wondering what's available for boards and drivers.
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: David Gibson @ 2007-11-20 0:33 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <4741BA7D.10608@genesi-usa.com>
On Mon, Nov 19, 2007 at 04:31:57PM +0000, Matt Sealey wrote:
> David Gibson wrote:
> > On Sun, Nov 18, 2007 at 11:31:13PM +0000, Matt Sealey wrote:
> >
> > Gah! For the benefit of others on this list who may be misled.
> >
> > *Neither* of you correctly understands the device tree, what I've seen
> > of *both* your suggested approaches is crap.
> >
> > The device tree describes the _hardware_. If you start reasoning
> > about how to lay out the device tree based on your driver model,
> > you're already wrong.
> >
> > Matt, the various properties you list do not mean what you think they
> > mean.
>
> No, David, I understand exactly what they mean, in the context of a
> guy who works on Open Firmware, real Open Firmware, as was
> standardised 12 years ago.
No, you really don't. Either your knowledge of OF is out of date, or
you've forgotten what you thought you knew.
> Not your whacky newspeak device trees, which to be fair, are a good
> idea, but it seems you all have tried to change something for the
> sake of changing something.
With a couple of tiny exceptions, everything I've said applies equally
to real OF trees.
[snip]
> > device_type - indicates the open firmware method interface for the
> > device. Therefore, meaningless in flattened trees. No new driver
> > should use this.
>
> .. you seem to think you must only design for the guys making Linux
> flattened device trees. I'm sorry, but I am not one of those guys and
> I am much more concerned with how this will affect the OF device tree
> and the usage for anyone else.
No, which is exactly why it's wrong to organize the device tree so
that it's convenient for loading this "fabric driver" thing (which
AFAICT is a Linux-specific driver model limitation).
> Meaningless in flattened device trees, but useful information in real
> OF device trees, do you implement it or not? I'd say, yes. Even if
> you don't agree with "real firmware", you can't just ignore it, shrug
> it away and say it doesn't matter.
Useful information in a real OF tree *if* an OF runtime interface for
the device is defined and implemented.
[snip]
> > compatible - *this* is the one for driver selection. It describes the
> > hardware level interface(s) of the device.
>
> Compatible is meant to list alternative, compatible devices as a
> *supplement* to device_type. device_type is your "primary" and
> compatible is your "secondary". In this case, device_type is
> exactly what Jon wants, something to mark out that the audio device
> is his board design and requires special work (it is not merely an
> i2s bus that you can just "use" - although throwing PCM data at it
> would work, who knows what mixer it goes to, and what controls are
> needed to define the bitrate or other features)
No, as Segher explains, that's Just Plain Wrong. Originally "name"
did perform the function you think device_type had. But the generic
names convention, which has been very well established for a long time
now means that the register-level (or equivalent) programming
interface is described by "compatible". Period.
> > model - usually just for debugging / diagnosis / human-readable
> > purposes, describes exact model / revision of the hardware. It can be
> > used to enable driver quirks / workarounds for when various devices
> > are supposed to be compatible (as encoded in 'compatible') but
> > aren't, due to hardware bugs. However, you should never aim to use it
> > this way in design.
>
> I don't see why "model" can't encode the particular revision of the
> hardware in this way when it comes to the audio group of features on
> his board. After all, if you are looking at a "digispeaker,flinger"
> (I made that name up) then you need to know depending on the board
> or even based on weird configurability options of the board, what
> certain things may be - Apple used layout-id and a number. Why NOT
> encode the "model" in the "model"?
>
> Why choose some magical, new property, which then has to be further
> standardised for no reason?
>
> I also think that specifying an audio codec - after all the Open
> Firmware standard defines an audio interface and device tree
> requirements for it, even if they are methods that we don't
> implement and you don't care about - as a function of it's
> control interface is so backwards it doesn't bare thinking about.
Sure, it's fine for a firmware to implement the OF method interface
and put in the relevant device_type for audio in the appropriate place
(although with complex sound systems with many components, the right
place may be non-obvious or even not well defined). It's *not* fine
to make up random new device_type values because you think it's
convenient.
--
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: Revisited, audio codec device tree entries.
From: David Gibson @ 2007-11-20 0:22 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: PowerPC dev list
In-Reply-To: <f334e85d77c624ef0112437a4049a3cd@kernel.crashing.org>
On Mon, Nov 19, 2007 at 01:48:40PM +0100, Segher Boessenkool wrote:
> > Matt, the various properties you list do not mean what you think they
> > mean.
> >
> > name - should be named according to the generic names convention.
> > It's pretty much arbitrary, meant for human readability of the device
> > tree. Drivers should not depend on it (some do, historically, but new
> > drivers and trees should not).
>
> It is not arbitrary, there is a single well-defined name for every
> common
> "class" of device. It _is_ machine-readable (but shouldn't be used for
> driver matching, indeed -- it says nothing about the programming model).
Sorry, that was an (over?) simplification on my part. Yes, there are
conventions as to what devices should be called by class (usually, but
not universally observed), yes they can be used machine-readable under
some circumstances.
My point is that since driver matching is *not* done off name, and
machine-readable uses are not common, the name tends not to matter
very much. Plus if an incorrect name is used, it's usually not too
bad to fix.
> > device_type - indicates the open firmware method interface for the
> > device.
>
> Not "method interface", just "interface".
Right, I say "method interface" just to emphasise the fact that we're
talking about the runtime OF-call interface, rather than
register-level or other programming interface.
> > Therefore, meaningless in flattened trees.
>
> Even in flat trees, a "device_type" of for example "block" indicates the
> node will have the required properties for that device type, for example
> "block-size". Such properties are perfectly useful. OTOH, it isn't
> very
> useful to search for device with a specific device type from within the
> kernel, since it currently has no firmware interaction to speak of (flat
> trees don't interact, and the kernel kills "real" OF dead as soon as
> possible).
Uh... it was you who convinced me that device_type was not appropriate
for new flat-tree devices.
> > No new driver should use this.
>
> Not without very good rationalisation, anyway.
>
> > compatible - *this* is the one for driver selection. It describes the
> > hardware level interface(s) of the device.
> >
> > model - usually just for debugging / diagnosis / human-readable
> > purposes, describes exact model / revision of the hardware. It can be
> > used to enable driver quirks / workarounds for when various devices
> > are supposed to be compatible (as encoded in 'compatible') but
> > aren't, due to hardware bugs. However, you should never aim to use it
> > this way in design.
>
> Yeah. Any non-workaround value a driver would derive from "model" is
> usually better described using a separate property.
Well, yes, if the need for the workaround is known when the device
tree is created. But by their nature workarounds tend not to be
planned, so from the driver's perspective it's legitimate to use *any*
reliable-in-practice information to activate a workaround (even if
it's not reliable in theory, if there's no other option). That
includes both everything in the device tree, and any information the
driver can probe from the hardware.
My point above is that iIt's reasonably common in such cases for
"model" to be a decent choice.
--
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: 2.6 kernel hangs after loading device tree
From: abhi_linux @ 2007-11-20 0:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa84b3da0708290938l40d8f543oc0e34fa9bea806a4@mail.gmail.com>
Hello
Did u get a solution to this? I have similar issues. How do u enable
debugging in UBoot?
Thanks
charanya venkatraman wrote:
>
> Hi all
> Sorry about the previous mail.Got sent by mistake.
>
> Iam using the 2.6.22.5 kernel on MPC 8560 and MPC8540 on my custom
> board.Mykernel hangs after loading the device tree in both the
> processors .There is
> no output on the serial port after loading the device tree.Am using U-boot
> 1.2.0 as the bootloader.After enabling debug in u-boot i could see that
> the
> control is getting transferred to the kernel after which it hangs.Earlier
> i
> tried using 2.6.21 which also hangs at the same point.The config files
> used
> were MPC8540ADS_defconfig and MPC8560ADS_defconfig under powerpc
> directory.
> The changes that were made to the device tree are:
> 1.The reg and ranges properties of the soc node have been changed to
> account
> for the change in CCSRBAR of my board.
> 2.Removed the PCI,mdio nodes and ethernet nodes since i dont need support
> for these as of now.
>
> I have tried the following console arguments:
> MPC8540: bootargs root=/dev/ram rw console=ttyS0,115200
> MPC8560:bootargs root=/dev/ram rw console=ttyCPM0,115200
>
> Any help on this issue??
>
> Thanks.
> Charanya.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
View this message in context: http://www.nabble.com/2.6-kernel-hangs-after-loading-device-tree-tf4348921.html#a13848328
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Kim Phillips @ 2007-11-19 23:36 UTC (permalink / raw)
To: Li Yang, Kumar Gala, netdev, linuxppc-dev, paulus, jgarzik
In-Reply-To: <20071105121530.5c38fbb7.kim.phillips@freescale.com>
On Mon, 5 Nov 2007 12:15:30 -0600
Kim Phillips <kim.phillips@freescale.com> wrote:
> Hello all,
>
> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> according to erratum #2 (erratum text included below). Basically the
> most intrusive part is the addition of two new RGMII Internal Delay
> modes; one for TX delay only, and the other for RX delay only (i.e, not
> both at the same time).
>
> Please review, and since this affects both netdev and powerpc trees,
> one maintainer should ack them for the other to push upstream (i.e,
> Kumar acks them, and Leo picks them up to go through netdev or the
> other way around; either way is fine with me). I'm hoping they're
> trivial enough to go in 2.6.24.
>
Kumar, Leo,
re-ping due to (a) it's been 2 weeks and (b) Anton Vorontsov has since
issued his Tested-by.
Might I suggest Kumar ack the powerpc patches, and Leo/Jeff apply 5/5
to go through netdev?
Kim
^ 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