Re: [Patch] 8xx: MGSUVD support
Hello Vitaly,
Vitaly Bordug wrote:
Heiko Schocher wrote:
the following patch adds support for the MPC852 based mgsuvd board
from keymile.
Looks good overall. Please add supported/working/not working etc SoC devices
state along with the patch
description. Also a few really small comments below...
OK.
Signed-off-by: Heiko Schocher [EMAIL PROTECTED]
---
[...]
+
+PowerPC,[EMAIL PROTECTED] {
But it's mpc852, isn't it?
Yes your are right.
+device_type = cpu;
+reg = 0;
+d-cache-line-size = d#16;
+i-cache-line-size = d#16;
+d-cache-size = d#8192;
+i-cache-size = d#8192;
+timebase-frequency = 0; /* Filled in by
u-boot */
+bus-frequency = 0; /* Filled in by u-boot
*/
+clock-frequency = 0; /* Filled in by
u-boot */
+interrupts = f 2; // decrementer
interrupt
I would like all the comments to be consistent C style (because that's it for
the most other dts'es).
Okay, I fix this, and send a new patch.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Patch] 8xx: MGSUVD support
Hello Stephen,
Stephen Rothwell wrote:
On Sun, 09 Mar 2008 10:56:29 +0100 Heiko Schocher [EMAIL PROTECTED] wrote:
+++ b/arch/powerpc/platforms/8xx/mgsuvd.c
+#include asm/of_platform.h
You should include linux/of_platform.h (not asm/)
Ok.
+static struct cpm_pin mgsuvd_pins[] = {
Make this __initdata, please.
Argh... forgot this.
[...]
+static struct of_device_id __initdata of_bus_ids[] = {
Make this __initdata, please.
Hmm.. it is __initdata, or? But I fix it to:
static __initdata struct of_device_id of_bus_ids[]
+static int __init declare_of_platform_devices(void)
+{
+if (!machine_is(mgsuvd))
+return 0;
+
+of_platform_bus_probe(NULL, of_bus_ids, NULL);
+
+return 0;
+}
+device_initcall(declare_of_platform_devices);
This should be machine_device_initcall(mgsuvd,
declare_of_platform_devices); then you don't need the machine_is() check
above.
Ok
I will send a overworked patch.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Patch] 8xx: MGSUVD support
Hi,
On Mon, 10 Mar 2008 07:34:46 +0100 Heiko Schocher [EMAIL PROTECTED] wrote:
+static struct of_device_id __initdata of_bus_ids[] = {
Make this __initdata, please.
Hmm.. it is __initdata, or? But I fix it to:
OOPS, brain not working again after break :-)
sorry.
static __initdata struct of_device_id of_bus_ids[]
It is right either way. But linux/init.h says it should go just before
the '=' sign.
I will send a overworked patch.
Nice :-) (overworked means having too much work to do - I think you
meant reworked)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpYr0Be9Hpfd.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
Acked-by: Scott Wood [EMAIL PROTECTED], if I haven't already. -Scott I thought, you did it. Thank you. -- Dipl.-Ing. Sergej Stepanov Software-Entwicklung IDS GmbH E-PA (Entwicklung - Prozess Automatisierung) Nobelstr. 18, D-76275 Ettlingen T. (0) 72 43/2 18-615 F. (0) 72 43/2 18-100 E. [EMAIL PROTECTED] http://www.ids.de Geschäftsführer: Norbert Wagner, Friedrich Abriß Sitz der Gesellschaft: Ettlingen Amtsgericht Mannheim HRB 362503 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ADT746X: logical-bitwise confusion in set_max_duty_at_crit()
Benjamin Herrenschmidt wrote: On Mon, 2008-03-10 at 08:46 +0100, Colin Leroy wrote: On Mon, 10 Mar 2008 01:04:33 +0100, Roel Kluin wrote: logical-bitwise confusion Looks good to me, but I'm not really maintaining that anymore :-) I'm not sure who does, Cc:ing Benjamin as he'll probably know. Nobody is U suspect... Send it to the list linuxppc-dev@ozlabs.org, it should be picked up anyway. (linuxppc-dev CC'd) --- logical-bitwise confusion Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c index 9587869..8ea7da2 100644 --- a/drivers/hwmon/adt7473.c +++ b/drivers/hwmon/adt7473.c @@ -570,7 +570,7 @@ static ssize_t set_max_duty_at_crit(struct device *dev, struct i2c_client *client = to_i2c_client(dev); struct adt7473_data *data = i2c_get_clientdata(client); int temp = simple_strtol(buf, NULL, 10); - temp = temp 0xFF; + temp = 0xFF; mutex_lock(data-lock); data-max_duty_at_overheat = temp; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ADT746X: logical-bitwise confusion in set_max_duty_at_crit()
diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c index 9587869..8ea7da2 100644 --- a/drivers/hwmon/adt7473.c +++ b/drivers/hwmon/adt7473.c @@ -570,7 +570,7 @@ static ssize_t set_max_duty_at_crit(struct device *dev, struct i2c_client *client = to_i2c_client(dev); struct adt7473_data *data = i2c_get_clientdata(client); int temp = simple_strtol(buf, NULL, 10); - temp = temp 0xFF; + temp = 0xFF; mutex_lock(data-lock); data-max_duty_at_overheat = temp; The 0xff here is bogus anyway; temp is only ever used as an u8, so just declare it as that, or do proper overflow/underflow checking on it. The patch will need testing on hardware too, since it changes behaviour (it should be a bugfix, but who knows). Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ADT746X: logical-bitwise confusion in set_max_duty_at_crit()
Segher Boessenkool wrote:
diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
index 9587869..8ea7da2 100644
--- a/drivers/hwmon/adt7473.c
+++ b/drivers/hwmon/adt7473.c
@@ -570,7 +570,7 @@ static ssize_t set_max_duty_at_crit(struct device
*dev,
struct i2c_client *client = to_i2c_client(dev);
struct adt7473_data *data = i2c_get_clientdata(client);
int temp = simple_strtol(buf, NULL, 10);
-temp = temp 0xFF;
+temp = 0xFF;
mutex_lock(data-lock);
data-max_duty_at_overheat = temp;
The 0xff here is bogus anyway; temp is only ever used as an u8,
so just declare it as that, or do proper overflow/underflow checking
on it. The patch will need testing on hardware too, since it changes
behaviour (it should be a bugfix, but who knows).
Maybe someone can test this?
---
logical-bitwise confusion
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
---
diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
index 9587869..2a2de73 100644
--- a/drivers/hwmon/adt7473.c
+++ b/drivers/hwmon/adt7473.c
@@ -566,11 +566,11 @@ static ssize_t set_max_duty_at_crit(struct device *dev,
const char *buf,
size_t count)
{
- u8 reg;
+ u8 reg, temp;
struct i2c_client *client = to_i2c_client(dev);
struct adt7473_data *data = i2c_get_clientdata(client);
- int temp = simple_strtol(buf, NULL, 10);
- temp = temp 0xFF;
+
+ temp = simple_strtol(buf, NULL, 10) 0xFF;
mutex_lock(data-lock);
data-max_duty_at_overheat = temp;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
On Monday 10 March 2008 08:50, Sergej Stepanov wrote: Acked-by: Scott Wood [EMAIL PROTECTED], if I haven't already. -Scott I thought, you did it. Thank you. Your documentation patch states that The first reg resource is the I/O port register block on which MDIO resides. The second reg resource is the I/O port register block on which MDC resides. If there is only one reg resource, it is used for both MDIO and MDC. If I'm not mistaken the code uses the first reg resource for MDC and the second reg resource for MDIO. Which one should be fixed, the doc or the code ? Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpYSU5l95b8u.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Trouble with SCC UART ports when moving from ppc to powerpc
On Friday 07 March 2008 17:21, Scott Wood wrote:
On Fri, Mar 07, 2008 at 03:20:55PM +0100, Laurent Pinchart wrote:
The CPM dual port ram was defined in the device tree as follows (copied
from the MPC8272ADS board device tree).
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
ranges = 0 0 1;
[EMAIL PROTECTED] {
compatible = fsl,cpm-muram-data;
reg = 0 2000 9800 800;
};
};
Changing the reg property to
reg = 80 1f80 9800 800;
fixed my problem.
Perhaps there's an SMC1 running with its parameter RAM at offset zero?
Good guess. U-Boot configured SMC1 with its parameter RAM at offset 0.
Does anyone have any clue regarding what could write to the dpram ? I
thought about some CPM peripheral set up by the boot loader, but my board
initialization code calls cpm2_reset() long before initializing SCC1.
cpm2_reset() doesn't currently actually reset the CPM, for some reason
(unlike cpm1). This should probably be fixed, though then we'd have to
deal with assigning SMC parameter RAM addresses ourselves.
I had overlooked that. Resetting the CPM in cpm2_reset() helps. Is there any
reason not to rset the CPM in cpm2_reset() ?
How should SMC parameter RAM assignment be handled ? I'm not very familiar
with the CPM1, but for CPM2 the cpm_uart driver could easily cpm_dpalloc()
parameter RAM.
For now, the above fix should be done on any board with an active SMC
device (assuming SMC parameter RAM at zero, as u-boot sets it; other
bootloaders may need to exempt a different region).
Thanks for your help.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
pgpgzAwItLUnQ.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: DTC 1.1.0 Release!
Hi John, On Thu, 24 Jan 2008, Jon Loeliger wrote: You may find it using git here: git://www.jdl.com/software/dtc A tarball snap-shot is also available here: http://www.jdl.com/software/dtc-1.1.0.tgz Please let me know if there are problems with it! It looks like www.jdl.com got wiped out? I cannot get dtc anymore from your site, both git and http (default apache page) fail? With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
Am Montag, den 10.03.2008, 12:05 +0100 schrieb Laurent Pinchart: Your documentation patch states that The first reg resource is the I/O port register block on which MDIO resides. The second reg resource is the I/O port register block on which MDC resides. If there is only one reg resource, it is used for both MDIO and MDC. If I'm not mistaken the code uses the first reg resource for MDC and the second reg resource for MDIO. Which one should be fixed, the doc or the code ? Best regards, Ooops... Sorry... You are right: the first is MDC, second MDIO. I have to fix the docu, it would be simpler. Thank you and best regards Sergej. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC upstream kernel ignored DABR bug
On Monday 10 March 2008, Luis Machado wrote: Yes, I know. I tried it on the PS3 first and couldn't reproduce the bug he saw on the blade. Arnd, Do we have any news on this topic? I've seen this happening quite often within GDB when using hardware watchpoints on a shared variable in a threaded (7+ threads) binary. Sometimes the watchpoint won't trigger, even though the monitored variable's value was modified. On the Blade DABRX had to be set additional to DABR. PS3 and Celleb already did this. Uli Weigand found this back in November. I submitted a patch for this which went into 2.6.25-rc4. Can you please try again with rc4 ? Gruß, Jens IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1] [PPC] 8xx swap bug-fix
On Feb 2, 2008, at 1:47 AM, Yuri Tikhonov wrote: Hello, Here is the patch which makes Linux-2.6 swap routines operate correctly on the ppc-8xx-based machines. Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Make 83xx perfmon support selectable
On Mar 7, 2008, at 5:59 PM, Andy Fleming wrote: Not all e300 cores support the performance monitors, and the ones that don't will be confused by the mf/mtpmr instructions. This allows the support to be optional, so the 8349 can turn it off while the 8379 can turn it on. Sadly, those aren't config options, so it will be left to the defconfigs and the users to make that determination. Signed-off-by: Andy Fleming [EMAIL PROTECTED] --- Ugh. The previous version was a little hasty. Needed to base off PPC_83xx rather than 83xx arch/powerpc/platforms/Kconfig |1 - arch/powerpc/platforms/Kconfig.cputype |7 ++- 2 files changed, 6 insertions(+), 2 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
The patch updates the booting-without-of.txt-file. There is a description for the case if mdio data and clock pins are on different processor ports. It extends the [PATCH v3] using mii-bitbang on different processor ports. Signed-off-by: Laurent Pinchart [EMAIL PROTECTED] Signed-off-by: Scott Wood [EMAIL PROTECTED] Signed-off-by: Sergej Stepanov [EMAIL PROTECTED] -- diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 7b4e8a7..3285f58 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -2003,10 +2003,14 @@ platforms are moved over to use the flattened-device-tree model. Currently defined compatibles: fsl,pq1-fec-mdio (reg is same as first resource of FEC device) - fsl,cpm2-mdio-bitbang (reg is port C registers) + fsl,cpm2-mdio-bitbang Properties for fsl,cpm2-mdio-bitbang: - fsl,mdio-pin : pin of port C controlling mdio data - fsl,mdc-pin : pin of port C controlling mdio clock + The first reg resource is the I/O port register block on which MDC + resides. The second reg resource is the I/O port register block on + which MDIO resides. If there is only one reg resource, it is used for + both MDIO and MDC. + fsl,mdio-pin : pin of chosen port for controlling mdio data + fsl,mdc-pin : pin of chosen port for controlling mdio clock Example: ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
OF compatible MTD platform RAM driver ?
Hi everybody, as part of a ARCH=ppc to ARCH=powerpc migration process, I'm looking for an OpenFirmware compatible way to handle a RAM-based MTD device. On the platform_device based ppc architecture, the drivers/mtd/maps/plat-ram.c driver handled mtd-ram platform devices. There is no such driver for the OF-based powerpc architecture. As a temporary workaround I hacked the physmap_of driver to handle direct-mapped OF devices oh type ram by adding a corresponding entry in the of_flash_match[] array. This seems to work fine. What would be the preferred way to handle OF-compatible RAM-based MTD devices ? The 3 ways I can think of are 1. porting the plat-ram driver to OF (the driver isn't used in the kernel tree but I suspect it is used by out-of-tree boards) 2. creating a new plat-ram-of driver, much like the physmap_of driver comes from the physmap driver 3. extending the physmap_of driver to handle RAM devices (in which case references to flash in the function names should probably be replaced by mtd) I live option 3 better so far. Has anyone already worked on this ? Is there any defined device tree mapping for MTD RAM devices ? Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpwuFdl1bULg.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC upstream kernel ignored DABR bug
On the Blade DABRX had to be set additional to DABR. PS3 and Celleb already did this. Uli Weigand found this back in November. I submitted a patch for this which went into 2.6.25-rc4. Can you please try again with rc4 ? I will try it and will post the results back. Thanks Jens. Regards, -- Luis Machado Software Engineer IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Confused about usercopy_64.c
I'm confused about something in usercopy_64.c:
unsigned long copy_from_user(void *to, const void __user *from, unsigned long n)
{
if (likely(access_ok(VERIFY_READ, from, n)))
n = __copy_from_user(to, from, n);
else
memset(to, 0, n);
return n;
}
If access_ok() returns false, then that means that we cannot copy the data from
user-space. So why are we returning 'n'? Shouldn't we return zero, to let the
caller know that the function failed?
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Confused about usercopy_64.c
On Mon, Mar 10, 2008 at 11:38:49AM -0500, Timur Tabi wrote:
I'm confused about something in usercopy_64.c:
unsigned long copy_from_user(void *to, const void __user *from, unsigned long
n)
{
if (likely(access_ok(VERIFY_READ, from, n)))
n = __copy_from_user(to, from, n);
else
memset(to, 0, n);
return n;
}
If access_ok() returns false, then that means that we cannot copy the data
from
user-space. So why are we returning 'n'? Shouldn't we return zero, to let
the
caller know that the function failed?
copy_from_user() returns number of bytes _not_ copied.
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: OF compatible MTD platform RAM driver ?
[EMAIL PROTECTED] wrote:
Hi everybody,
as part of a ARCH=ppc to ARCH=powerpc migration process, I'm
looking for an
OpenFirmware compatible way to handle a RAM-based MTD device.
On the platform_device based ppc architecture, the
drivers/mtd/maps/plat-ram.c
driver handled mtd-ram platform devices. There is no such
driver for the
OF-based powerpc architecture.
As a temporary workaround I hacked the physmap_of driver to
handle direct-mapped OF devices oh type ram by adding a
corresponding entry in the of_flash_match[] array. This seems to work
fine.
What would be the preferred way to handle OF-compatible RAM-based MTD
devices ? The 3 ways I can think of are
1. porting the plat-ram driver to OF (the driver isn't used
in the kernel tree
but I suspect it is used by out-of-tree boards)
2. creating a new plat-ram-of driver, much like the
physmap_of driver comes
from the physmap driver
3. extending the physmap_of driver to handle RAM devices (in
which case
references to flash in the function names should probably
be replaced
by mtd)
I live option 3 better so far.
Has anyone already worked on this ? Is there any defined
device tree mapping
for MTD RAM devices ?
Best regards,
We ran ito the same issue.
We did option 3, as it was efinetly the easiest,
here is the sram entry in our dts:
[EMAIL PROTECTED],0 {
device_type = rom;
compatible = direct-mapped;
probe-type = RAM;
reg = 9 0 2;
bank-width = 2;
device-width = 2;
#address-cells = 1;
#size-cells = 1;
[EMAIL PROTECTED] {
label = SRAM;
reg = 0 2;
};
here is the change to physmap_of.c:
diff --git a/drivers/mtd/maps/physmap_of.c
b/drivers/mtd/maps/physmap_of.c
old mode 100644
new mode 100755
index aeed9ea..687ef54
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -201,6 +201,8 @@ static struct mtd_info * __devinit
obsolete_probe(struct of_device *dev,
return do_map_probe(cfi_probe, map);
} else if (strcmp(of_probe, JEDEC) == 0) {
return do_map_probe(jedec_probe, map);
+ } else if (strcmp(of_probe, RAM) == 0) {
+ return do_map_probe(map_ram, map);
} else {
if (strcmp(of_probe, ROM) != 0)
dev_warn(dev-dev, obsolete_probe: don't know
probe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'for-2.6.25' [updated]
Please pull from 'for-2.6.25' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25 to receive the following updates: arch/powerpc/boot/dts/mpc8377_mds.dts | 70 ++ arch/powerpc/boot/dts/mpc8378_mds.dts | 70 ++ arch/powerpc/boot/dts/mpc8379_mds.dts | 70 ++ arch/powerpc/boot/dts/sbc8548.dts | 16 arch/powerpc/boot/wrapper |6 arch/powerpc/configs/adder875-redboot_defconfig | 798 --- arch/powerpc/configs/adder875-uboot_defconfig | 798 --- arch/powerpc/configs/adder875_defconfig | 813 arch/powerpc/kernel/head_8xx.S | 30 arch/powerpc/platforms/83xx/mpc837x_mds.c |8 arch/powerpc/platforms/Kconfig |1 arch/powerpc/platforms/Kconfig.cputype |7 arch/powerpc/sysdev/qe_lib/qe.c |7 arch/ppc/kernel/head_8xx.S | 30 include/asm-powerpc/pgtable-ppc32.h |8 include/asm-ppc/pgtable.h |8 16 files changed, 1105 insertions(+), 1635 deletions(-) Andy Fleming (1): [POWERPC] 83xx: Make 83xx perfmon support selectable Ionut Nicu (1): [POWERPC] QE: Make qe_get_firmware_info reentrant Jeremy McNicoll (1): [POWERPC] 85xx: sbc8548 - Fix incorrect PCI-X and PCI interrupt map Li Yang (2): [POWERPC] 83xx: Fix wrong USB phy type in mpc837xmds dts [POWERPC] 83xx: Add local bus device nodes to MPC837xMDS device trees. Scott Wood (1): [POWERPC] 8xx: Fix wrapper platform for adder875, and combine defconfigs. Timur Tabi (1): [POWERPC] QE: Fix QE firmware uploading limit Vitaly Bordug (1): [POWERPC] 8xx: fix swap Yuri Tikhonov (1): [PPC] 8xx: swap bug-fix ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ADT746X: logical-bitwise confusion in set_max_duty_at_crit()
On Mon, Mar 10, 2008 at 10:59:43AM +0100, Roel Kluin wrote: The 0xff here is bogus anyway; temp is only ever used as an u8, so just declare it as that, or do proper overflow/underflow checking on it. The patch will need testing on hardware too, since it changes behaviour (it should be a bugfix, but who knows). Maybe someone can test this? I did. No regressions observed and it fixes that bug as well. Sorry I didn't catch it earlier... :/ Acked-by: Darrick J. Wong [EMAIL PROTECTED] --D ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC upstream kernel ignored DABR bug
On the Blade DABRX had to be set additional to DABR. PS3 and Celleb already did this. Uli Weigand found this back in November. I submitted a patch for this which went into 2.6.25-rc4. Can you please try again with rc4 ? This is not the problem. This came up before and everyone seems have forgotten. This bug has been reproduced on G5's, which do not have DABRX as I understand it. Thanks, Roland ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC upstream kernel ignored DABR bug
On Mon, 2008-03-10 at 12:19 -0700, Roland McGrath wrote: On the Blade DABRX had to be set additional to DABR. PS3 and Celleb already did this. Uli Weigand found this back in November. I submitted a patch for this which went into 2.6.25-rc4. Can you please try again with rc4 ? This is not the problem. This came up before and everyone seems have forgotten. This bug has been reproduced on G5's, which do not have DABRX as I understand it. Yes, now that you mentioned, i've been able to reproduce this on 970FX's blades, which i don't think have DABRX registers. I guess it's the almost the same CPU as G5's. Regards, -- Luis Machado Software Engineer IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC upstream kernel ignored DABR bug
On Mon, Mar 10, 2008 at 04:36:37PM -0300, Luis Machado wrote: On Mon, 2008-03-10 at 12:19 -0700, Roland McGrath wrote: On the Blade DABRX had to be set additional to DABR. PS3 and Celleb already did this. Uli Weigand found this back in November. I submitted a patch for this which went into 2.6.25-rc4. Can you please try again with rc4 ? This is not the problem. This came up before and everyone seems have forgotten. This bug has been reproduced on G5's, which do not have DABRX as I understand it. Yes, now that you mentioned, i've been able to reproduce this on 970FX's blades, which i don't think have DABRX registers. I guess it's the almost the same CPU as G5's. What Apple called G5 were during the production runs three different CPUs: 970 970FX 970MP 970 was only used in the very first models. 970MP was used in the last (the models with pci-express and up to 4 cpus). 970FX was used on almost everything else inbetween. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC upstream kernel ignored DABR bug
The G5 that I have says: cpu : PPC970FX, altivec supported revision: 3.0 (pvr 003c 0300) and it does indeed reproduce this bug. It also strange for it to be the DABRX issue given the failure mode. That is, it works sometimes but unreliably (as if the context switch sometimes fails to install the value). Thanks, Roland ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ADT746X: logical-bitwise confusion in set_max_duty_at_crit()
Andrew, I think you may want this patch instead of the other
adt746x-logical-bitwise-confusion-in-set_max_duty_at_crit.patch
It includes suggested changes by Segher Boessenkool and I think this
version was tested by Darrick J. Wong
---
logical-bitwise confusion
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
---
diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
index 9587869..2a2de73 100644
--- a/drivers/hwmon/adt7473.c
+++ b/drivers/hwmon/adt7473.c
@@ -566,11 +566,11 @@ static ssize_t set_max_duty_at_crit(struct device *dev,
const char *buf,
size_t count)
{
- u8 reg;
+ u8 reg, temp;
struct i2c_client *client = to_i2c_client(dev);
struct adt7473_data *data = i2c_get_clientdata(client);
- int temp = simple_strtol(buf, NULL, 10);
- temp = temp 0xFF;
+
+ temp = simple_strtol(buf, NULL, 10) 0xFF;
mutex_lock(data-lock);
data-max_duty_at_overheat = temp;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ADT746X: logical-bitwise confusion in set_max_duty_at_crit()
It includes suggested changes by Segher Boessenkool and I think this version was tested by Darrick J. Wong - u8 reg; + u8 reg, temp; struct i2c_client *client = to_i2c_client(dev); struct adt7473_data *data = i2c_get_clientdata(client); - int temp = simple_strtol(buf, NULL, 10); - temp = temp 0xFF; + + temp = simple_strtol(buf, NULL, 10) 0xFF; It still does this superfluous 0xff, which hides the lack of range checking. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC upstream kernel ignored DABR bug
On the Blade DABRX had to be set additional to DABR. PS3 and Celleb already did this. Uli Weigand found this back in November. I submitted a patch for this which went into 2.6.25-rc4. Can you please try again with rc4 ? This is not the problem. This came up before and everyone seems have forgotten. This bug has been reproduced on G5's, which do not have DABRX as I understand it. 970 (all versions) _does_ have a DABRX register. Dunno if it has the same register definition (I cannot find DABRX in the Cell docs). Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ADT746X: logical-bitwise confusion in set_max_duty_at_crit()
Segher Boessenkool wrote:
It includes suggested changes by Segher Boessenkool and I think this
version was tested by Darrick J. Wong
-u8 reg;
+u8 reg, temp;
struct i2c_client *client = to_i2c_client(dev);
struct adt7473_data *data = i2c_get_clientdata(client);
-int temp = simple_strtol(buf, NULL, 10);
-temp = temp 0xFF;
+
+temp = simple_strtol(buf, NULL, 10) 0xFF;
It still does this superfluous 0xff, which hides the lack of
range checking.
Sorry didn't quite grep that
---
logical-bitwise confusion
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
---
diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
index 9587869..98937d3 100644
--- a/drivers/hwmon/adt7473.c
+++ b/drivers/hwmon/adt7473.c
@@ -566,11 +566,11 @@ static ssize_t set_max_duty_at_crit(struct device *dev,
const char *buf,
size_t count)
{
- u8 reg;
+ u8 reg, temp;
struct i2c_client *client = to_i2c_client(dev);
struct adt7473_data *data = i2c_get_clientdata(client);
- int temp = simple_strtol(buf, NULL, 10);
- temp = temp 0xFF;
+
+ temp = simple_strtol(buf, NULL, 10);
mutex_lock(data-lock);
data-max_duty_at_overheat = temp;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Add some documentation for the dts formta
This patch adds a dts-format.txt in the Documentation directory, with
an introduction to the dtc source format. Note that this
documentation is also going into the upcoming ePAPR specification.
Signed-off-by: David Gibson [EMAIL PROTECTED]
---
Documentation/dts-format.txt | 110 +++
1 file changed, 110 insertions(+)
I wrote this documentation based on an earlier draft from Stuart
Yoder. Stuart, can you please reply with a Signed-off-by line?
Index: dtc/Documentation/dts-format.txt
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ dtc/Documentation/dts-format.txt2008-03-11 10:42:17.0 +1100
@@ -0,0 +1,110 @@
+Device Tree Source Format (version 1)
+=
+
+The Device Tree Source (DTS) format is a textual representation of a
+device tree in a form that can be processed by dtc into a binary
+device tree in the form expected by the kernel. The description below
+is not a formal syntax definition of DTS, but describes the basic
+constructs used to represent device trees.
+
+Node and property definitions
+-
+
+Device tree nodes are defined with a node name and unit address with
+braces marking the start and end of the node definition. They may be
+preceded by a label.
+
+ [label:] [EMAIL PROTECTED] {
+ [properties definitions]
+ [child nodes]
+ }
+
+Nodes may contain property definitions and/or child node
+definitions. If both are present, properties must come before child
+nodes.
+
+Property definitions are name value pairs in the form:
+ [label:] property-name = value;
+except for properties with empty (zero length) value which have the
+form:
+ [label:] property-name;
+
+Property values may be defined as an array of 32-bit integer cells, as
+NUL-terminated strings, as bytestrings or a combination of these.
+
+* Arrays of cells are represented by angle brackets surrounding a
+ space separated list of C-style integers
+
+ e.g. interrupts = 17 0xc;
+
+* A 64-bit value is represented with two 32-bit cells.
+
+ e.g. clock-frequency = 0x0001 0x;
+
+* A NUL-terminated string value is represented using double quotes
+ (the property value is considered to include the terminating NUL
+ character).
+
+ e.g. compatible = simple-bus;
+
+* A bytestring is enclosed in square brackets [] with each byte
+ represented by two hexadecimal digits. Spaces between each byte are
+ optional.
+
+ e.g. local-mac-address = [00 00 12 34 56 78]; or equivalently
+local-mac-address = [12345678];
+
+* Values may have several comma-separated components, which are
+ concatenated together.
+ e.g. compatible = ns16550, ns8250;
+example = 0xf00f 19, a strange property format;
+
+* In a cell array a reference to another node will be expanded to that
+ node's phandle. References may by '' followed by a node's label:
+ e.g. interrupt-parent = mpic ;
+ or they may be '' followed by a node's full path in braces:
+ e.g. interrupt-parent = {/soc/[EMAIL PROTECTED] ;
+
+* Outside a cell array, a reference to another node will be expanded
+ to that node's full path.
+ e.g. ethernet0 = EMAC0;
+
+* Labels may also appear before or after any component of a property
+ value, or between cells of a cell array, or between bytes of a
+ bytestring.
+ e.g. reg = reglabel: 0 sizelabel: 0x100;
+ e.g. prop = [ab cd ef byte4: 00 ff fe];
+ e.g. str = start: string value end: ;
+
+
+File layout
+---
+
+Version 1 DTS files have the overall layout:
+ /dts-v1/;
+
+ [memory reservations]
+
+ / {
+ [property definitions]
+ [child nodes]
+ };
+
+* The /dts-v1/; must be present to identify the file as a version 1
+ DTS (dts files without this tag will be treated by dtc as being in
+ the obsolete version 0, which uses a different format for integers
+ amongst other small but incompatible changes).
+
+* Memory reservations define an entry for the device tree blob's
+ memory reservation table. They have the form:
+ e.g. /memreserve/ address length;
+ Where address and length are 64-bit C-style integers.
+
+* The / { ... }; section defines the root node of the device tree.
+
+* C style (/* ... */) and C++ style (// ...) comments are supported.
+
+
+
+ -- David Gibson [EMAIL PROTECTED]
+ -- Yoder Stuart [EMAIL PROTECTED]
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote: This isn't a problem with this device tree, but it's probably time we started establishing some conventional generic names for nand flash and board-control devices. So, to start the ball rolling, I've seen several names for nand flash nodes, I'd suggest we standardise on nand-flash. What's wrong with the already well-established generic name flash? I was concerned that using flash for both NOR flash (which it already is) and NAND flash might be unwise. I am quite open to being convinced otherwise, though. I've seen several variants for board control devices (cpld, bcsr, fpga, etc.) I suggest we standardise on board-control Fine with me, but it's very vague (hard to avoid though). Yes. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc - ARCH=powerpc : help needed for dts file
On Sun, Mar 09, 2008 at 11:31:09PM +0100, Philippe De Muyter wrote: Hi Ben, I now have a working linux on my mpc8540 based board, with support for the compactflash disk and the i2c rtc. The network tough, does not work yet. altough the the integrated ethernet controller (FEC) seems to be recognized. Could it be a problem with the phy ? I notice that I do not have an entry for gfar_interrupt in /proc/interrupts on my ethernet-missing linux, while I have one ont the working arch/ppc linux ? Do I need to give the phy type in the dts file, and how ? I would also like to know if it is possible to still get in linux the mac address known by uboot when using a dts file, and how ? This chiefly depends on whether you're using an old u-boot that doesn't know about the device tree, or a new u-boot which itself supplies a device tree to the kernel. If the old u-boot, you'll need to write a bootwrapper for your platform which reads the bd_t and pokes the right mac addresses into the device tree. If the new u-boot, u-boot itself should put the address into the device tree. If it's not, why it's not is a u-boot question rather than a device tree question. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] bootwrapper: Allow specifying of image physical offset
On Fri, Mar 07, 2008 at 10:55:51AM -0600, Kumar Gala wrote: Normally we assume kernel images will be loaded at offset 0. However there are situations, like when the kernel itself is running at a non-zero physical address, that we don't want to load it at 0. Allow the wrapper to take an offset. We use this when building u-boot images. Signed-off-by: Kumar Gala [EMAIL PROTECTED] Hrm. It concerns me that with the patch as it stands, CONFIG_MEMORY_START looks like a fairly universal option, but it will only be respected on u-boot platforms (and only new u-boot, not cuboot at that). -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
On Tuesday 11 March 2008, David Gibson wrote: On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote: This isn't a problem with this device tree, but it's probably time we started establishing some conventional generic names for nand flash and board-control devices. So, to start the ball rolling, I've seen several names for nand flash nodes, I'd suggest we standardise on nand-flash. What's wrong with the already well-established generic name flash? I was concerned that using flash for both NOR flash (which it already is) and NAND flash might be unwise. I am quite open to being convinced otherwise, though. One argument for just using flash is that there are much finer differences than just NAND and NOR, with at least dataflash, OneNAND, SD/MMC being further types of flash that don't fit the categories exactly, though each one for different reasons. For SD/MMC, there are good reasons to use something completely different, for the others, calling them all flash sounds better than fitting them into nand and nor. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
On Thu, 2008-02-28 at 18:24 -0600, Manish Ahuja wrote:
Initial patch for reserving memory in early boot, and freeing it later.
If the previous boot had ended with a crash, the reserved memory would contain
a copy of the crashed kernel data.
Signed-off-by: Manish Ahuja [EMAIL PROTECTED]
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Hi Manish,
A few comments inline ..
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-02-28
21:57:52.0 -0600
@@ -0,0 +1,105 @@
+/*
+ * Hypervisor-assisted dump
+ *
+ * Linas Vepstas, Manish Ahuja 2008
+ * Copyright 2008 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+
+#include linux/init.h
+#include linux/mm.h
+#include linux/pfn.h
+#include linux/swap.h
+
+#include asm/page.h
+#include asm/phyp_dump.h
+#include asm/machdep.h
+#include asm/prom.h
+
+/* Global, used to communicate data between early boot and late boot */
+static struct phyp_dump phyp_dump_global;
+struct phyp_dump *phyp_dump_info = phyp_dump_global;
I don't see the point of this. You have a static (ie. non-global) struct
called phyp_dump_global, then you create a pointer to it and pass that
around. It could just be:
phyp_dump.h:
extern struct phyp_dump phyp_dump_info;
phyp_dump.c:
struct phyp_dump phyp_dump_info;
phyp_dump_info.foo = bar;
I also think the struct should be called phyp_dump_info, not phyp_dump -
it contains info about phyp_dump, not the dump itself.
+
+/**
+ * release_memory_range -- release memory previously lmb_reserved
+ * @start_pfn: starting physical frame number
+ * @nr_pages: number of pages to free.
+ *
+ * This routine will release memory that had been previously
+ * lmb_reserved in early boot. The released memory becomes
+ * available for genreal use.
+ */
+static void
+release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
+{
+ struct page *rpage;
+ unsigned long end_pfn;
+ long i;
+
+ end_pfn = start_pfn + nr_pages;
+
+ for (i = start_pfn; i = end_pfn; i++) {
+ rpage = pfn_to_page(i);
+ if (PageReserved(rpage)) {
+ ClearPageReserved(rpage);
+ init_page_count(rpage);
+ __free_page(rpage);
+ totalram_pages++;
+ }
+ }
+}
+
+static int __init phyp_dump_setup(void)
+{
+ unsigned long start_pfn, nr_pages;
+
+ /* If no memory was reserved in early boot, there is nothing to do */
+ if (phyp_dump_info-init_reserve_size == 0)
+ return 0;
+
+ /* Release memory that was reserved in early boot */
+ start_pfn = PFN_DOWN(phyp_dump_info-init_reserve_start);
+ nr_pages = PFN_DOWN(phyp_dump_info-init_reserve_size);
+ release_memory_range(start_pfn, nr_pages);
+
+ return 0;
+}
+machine_subsys_initcall(pseries, phyp_dump_setup);
+
+int __init early_init_dt_scan_phyp_dump(unsigned long node,
+ const char *uname, int depth, void *data)
+{
+#ifdef CONFIG_PHYP_DUMP
+ const unsigned int *sizes;
+
+ phyp_dump_info-phyp_dump_configured = 0;
+ phyp_dump_info-phyp_dump_is_active = 0;
+
+ if (depth != 1 || strcmp(uname, rtas) != 0)
+ return 0;
+
+ if (of_get_flat_dt_prop(node, ibm,configure-kernel-dump, NULL))
+ phyp_dump_info-phyp_dump_configured++;
+
+ if (of_get_flat_dt_prop(node, ibm,dump-kernel, NULL))
+ phyp_dump_info-phyp_dump_is_active++;
+
+ sizes = of_get_flat_dt_prop(node, ibm,configure-kernel-dump-sizes,
+ NULL);
+ if (!sizes)
+ return 0;
+
+ if (sizes[0] == 1)
+ phyp_dump_info-cpu_state_size = *((unsigned long *)sizes[1]);
+
+ if (sizes[3] == 2)
+ phyp_dump_info-hpte_region_size =
+ *((unsigned long *)sizes[4]);
+#endif
This doesn't need to be inside #ifdef, you have a dummy version already
defined in the header file.
Index: 2.6.25-rc1/arch/powerpc/kernel/prom.c
===
--- 2.6.25-rc1.orig/arch/powerpc/kernel/prom.c2008-02-28
21:54:57.0 -0600
+++ 2.6.25-rc1/arch/powerpc/kernel/prom.c 2008-02-28 21:55:27.0
-0600
@@ -1039,6 +1040,51 @@ static void __init early_reserve_mem(voi
#endif
}
+#ifdef CONFIG_PHYP_DUMP
+/**
+ * reserve_crashed_mem() - reserve all not-yet-dumped mmemory
+ *
+ * This routine
Re: OF compatible MTD platform RAM driver ?
On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote: [EMAIL PROTECTED] wrote: Hi everybody, as part of a ARCH=ppc to ARCH=powerpc migration process, I'm looking for an OpenFirmware compatible way to handle a RAM-based MTD device. On the platform_device based ppc architecture, the drivers/mtd/maps/plat-ram.c driver handled mtd-ram platform devices. There is no such driver for the OF-based powerpc architecture. As a temporary workaround I hacked the physmap_of driver to handle direct-mapped OF devices oh type ram by adding a corresponding entry in the of_flash_match[] array. This seems to work fine. What would be the preferred way to handle OF-compatible RAM-based MTD devices ? The 3 ways I can think of are 1. porting the plat-ram driver to OF (the driver isn't used in the kernel tree but I suspect it is used by out-of-tree boards) 2. creating a new plat-ram-of driver, much like the physmap_of driver comes from the physmap driver 3. extending the physmap_of driver to handle RAM devices (in which case references to flash in the function names should probably be replaced by mtd) I live option 3 better so far. Has anyone already worked on this ? Is there any defined device tree mapping for MTD RAM devices ? We ran ito the same issue. We did option 3, as it was efinetly the easiest, I think this is the best option in principle. here is the sram entry in our dts: Except that your implementation of it is not good. You're relying on the old obsolete flash binding with the probe-type field. The solution should be adapted to the new approach which uses values in the compatible field to indicate various sorts of flash device. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
On Tue, Mar 11, 2008 at 01:43:49AM +0100, Arnd Bergmann wrote: On Tuesday 11 March 2008, David Gibson wrote: On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote: This isn't a problem with this device tree, but it's probably time we started establishing some conventional generic names for nand flash and board-control devices. So, to start the ball rolling, I've seen several names for nand flash nodes, I'd suggest we standardise on nand-flash. What's wrong with the already well-established generic name flash? I was concerned that using flash for both NOR flash (which it already is) and NAND flash might be unwise. I am quite open to being convinced otherwise, though. One argument for just using flash is that there are much finer differences than just NAND and NOR, with at least dataflash, OneNAND, SD/MMC being further types of flash that don't fit the categories exactly, though each one for different reasons. For SD/MMC, there are good reasons to use something completely different, for the others, calling them all flash sounds better than fitting them into nand and nor. Ok, I'm convinced. flash it is. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] bootwrapper: Allow specifying of image physical offset
On Mar 10, 2008, at 7:37 PM, David Gibson wrote: On Fri, Mar 07, 2008 at 10:55:51AM -0600, Kumar Gala wrote: Normally we assume kernel images will be loaded at offset 0. However there are situations, like when the kernel itself is running at a non-zero physical address, that we don't want to load it at 0. Allow the wrapper to take an offset. We use this when building u- boot images. Signed-off-by: Kumar Gala [EMAIL PROTECTED] Hrm. It concerns me that with the patch as it stands, CONFIG_MEMORY_START looks like a fairly universal option, but it will only be respected on u-boot platforms (and only new u-boot, not cuboot at that). Nothing stops anyone from submitting patches that makes it work for other platforms. CONFIG_MEMORY_START is only of utility on book-e class machines at this point and from a Freescale point of view that's 85xx and thus means u-boot. IBM, AMCC, or a random Joe is free to submit patches to make it work on 44x. :) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Remove Kconfig option BOOT_LOAD
Nothing appears to use BOOT_LOAD so remove it as a configurable option. --- in my powerpc-next branch. - k arch/powerpc/Kconfig | 16 1 files changed, 0 insertions(+), 16 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index e4e13e0..803415e 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -663,22 +663,6 @@ config CONSISTENT_SIZE hex Size of consistent memory pool if CONSISTENT_SIZE_BOOL default 0x0020 if NOT_COHERENT_CACHE -config BOOT_LOAD_BOOL - bool Set the boot link/load address - depends on ADVANCED_OPTIONS !PPC_MULTIPLATFORM - help - This option allows you to set the initial load address of the zImage - or zImage.initrd file. This can be useful if you are on a board - which has a small amount of memory. - - Say N here unless you know what you are doing. - -config BOOT_LOAD - hex Link/load address for booting if BOOT_LOAD_BOOL - default 0x0040 if 40x || 8xx || 8260 - default 0x0100 if 44x - default 0x0080 - config PIN_TLB bool Pinned Kernel TLBs (860 ONLY) depends on ADVANCED_OPTIONS 8xx -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
