* signals handling in the kernel
From: Mirek23 @ 2007-08-07 11:32 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I would like to send signals from the interrupt handler routine (in the
kernel) to the user application (in user space).
I have googled on that net and I have found that it could be done with the
function:
kill_proc_info.
When I have compiled my module which uses the kill_proc_info I have got and
error messge:
WARNING: "kill_proc_info" [drivers/char/xilinx_gpio/xilinx_gpio.ko]
undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
The kill_proc_info source code is in the kernel/signal.c file. Due to
unknown reason the kill_proc_info symbol is not exported with EXPORT_SYMBOL
entry.
I can modify the file kernel/signal.c adding the line
EXPORT_SYMBOL(kill_proc_info) but maybe it is a good reason in order not to
use this function straight. If so what would be the best way to send a
signal form the kernel interrupt handler routine to the user space together
with the siginfo data.
Best Regards
Mirek
--
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12032525
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Anton Vorontsov @ 2007-08-07 10:53 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <d36303a31bb9cd2ab7cb38a09428e616@kernel.crashing.org>
On Mon, Aug 06, 2007 at 08:18:47PM +0200, Segher Boessenkool wrote:
[...]
>>> The hardware should be described in the device tree. This isn't
>>> the same as simply copying all your Linux code into it ;-)
>>
>> Ugh. SD/MMC slot is the hardware, isn't it? It have wired SPI pins,
>> and chip select pin. To set up this pin, I need mmc node, which means
>> that I can't completely move mmc definitions to the board file, as
>> suggested by Kumar Gala.
>>
>> Advices?
>
> You need to declare in the SPI node which GPIOs it uses for
> what. You shouldn't have the actual values to put into the
> GPIO registers in the device tree; the kernel driver can
> figure it out.
Well, how SPI differs from UCC in that regard? This is how mpc832x_mds.dts,
mpc832x_rdb.dts, mpc836x_mds.dts, ... doing things already for UCC pins.
And then what pio-map exists for?.. In my understanding pio-map tries to
describe hardware (GPIO) wiring, exactly how SPI (and UCC) nodes trying
to use it.
Heh.. anyway, it's really hard to find proper logic around device tree,
do's and don'ts, so I'll just follow your suggestions in hope that I'll
get it as time goes by. ;-)
> Hope this helps,
Thanks!
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: pci in arch/powerpc vs arch/ppc
From: Alexandros Kostopoulos @ 2007-08-07 9:06 UTC (permalink / raw)
To: Kumar Gala, Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <F081E320-CFF9-497C-87D5-50E2E5C15A24@kernel.crashing.org>
Except from some macros arch/powerpc/include/asm/io.h / mpc8260_pci9.h, I
can seem to find anywhere the code regarding PCI Erratum 9. The defined
macros(in io.h) for read/write are sufficient as a workaround for PCI9?
Who does DMA and register initialization for this (it used to be done in
arch/ppc/syslib/m8260_pci_erratum9.c in arc/ppc). Maybe u-boot or the
bootwrapper?
Another question regarding resource allocation: when
alloc_resource(pci_32.c), called from pcibios_allocate_resources(), during
pcibios init, attempts to allocate resources using request_resource(), the
request fails. This seems to happen because the previously scanned PCI
devices request resources in the form, e.g. 00000- 0000f (i.e. starting
from zero), and this should be mapped somewhere else in cpu mem space. My
question (in order to find my bug) is, who performs this mapping, from PCI
space to CPU space, the kernel (and if yes, where?) or the host bridge (in
which case, I've probably failed to configure it properly).
Thank you
On Sat, 04 Aug 2007 19:39:58 +0300, Kumar Gala <galak@kernel.crashing.org>
wrote:
>
> On Aug 3, 2007, at 3:10 PM, Scott Wood wrote:
>
>> On Fri, Aug 03, 2007 at 05:58:56PM +0300, Alexandros Kostopoulos wrote:
>>> Hi all,
>>> in the old arch/ppc tree, there was a function called
>>> pq2ads_setup_pci()
>>> that set up PCI regs for 8272xx, in m82xx_pci.c. I was wandering, where
>>> are these registers configured now in arch/powerpc? I can't seem to
>>> find
>>> these code now.
>>
>> It's done by the firmware or the bootwrapper.
>
>>> Also, I can see that now bus 0, dev 0 (which I think represents the
>>> host
>>> bridge, right?) is now excluded using pq2_pci_exclude_device, but it
>>> wasn't in older code. Why is that?
>>
>> The older code probably either excluded all host bridges by class, or
>> just lived with the error message that gets printed on boot.
>
> This will change in 2.6.24. I've fixed the reason we excluded the host
> bridges on Freescale host bridges.
>
> - k
^ permalink raw reply
* Sequoia PPC440EPx GPIO Inquiry
From: Jeyner Gil Caga @ 2007-08-07 9:05 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 282 bytes --]
Hi,
I have a Sequoia evaluation board PPC440EPx and it has some GPIOs. This
board is running on Linux 2.6.21. I would like to make use of two GPIOs, to
control LEDs but I don't know how to do it.
May I ask if anyone has done sequoia GPIO controls? How is it done?
Thanks,
Jeyner
[-- Attachment #2: Type: text/html, Size: 312 bytes --]
^ permalink raw reply
* Re: [PATCH] Consolidate XILINX_VIRTEX board support
From: Peter Korsgaard @ 2007-08-07 7:01 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070806225642.7D72A7B005B@mail34-fra.bigfish.com>
>>>>> "WR" == Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com> writes:
Hi,
WR> diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
WR> index 5b87779..05631fe 100644
WR> --- a/arch/ppc/boot/simple/Makefile
WR> +++ b/arch/ppc/boot/simple/Makefile
WR> @@ -187,8 +187,7 @@ boot-$(CONFIG_REDWOOD_6) += embed_config.o
WR> boot-$(CONFIG_8xx) += embed_config.o
WR> boot-$(CONFIG_8260) += embed_config.o
WR> boot-$(CONFIG_EP405) += embed_config.o
WR> -boot-$(CONFIG_XILINX_ML300) += embed_config.o
WR> -boot-$(CONFIG_XILINX_ML403) += embed_config.o
WR> +boot-$(CONFIG_XILINX_VIRTEX) += embed_config.o
Don't do that. Other boards with Xilinx FPGAs don't necessarily need
embed_config.c
WR> boot-$(CONFIG_BSEIP) += iic.o
WR> boot-$(CONFIG_MBX) += iic.o pci.o qspan_pci.o
WR> boot-$(CONFIG_MV64X60) += misc-mv64x60.o
WR> diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
WR> index 840bff2..e0b8954 100644
WR> --- a/arch/ppc/boot/simple/embed_config.c
WR> +++ b/arch/ppc/boot/simple/embed_config.c
WR> @@ -744,7 +744,7 @@ embed_config(bd_t **bdp)
WR> }
WR> #endif /* WILLOW */
WR> -#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
WR> +#if defined(CONFIG_XILINX_VIRTEX)
WR> void
WR> embed_config(bd_t ** bdp)
.. And if they do, they might have another embed_config (E.G. if the
bootloader provides a valid struct bd_t).
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] Consolidate XILINX_VIRTEX board support
From: Peter Korsgaard @ 2007-08-07 7:17 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070806225642.7D72A7B005B@mail34-fra.bigfish.com>
>>>>> "WR" == Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com> writes:
Hi,
WR> diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
WR> index 5b87779..05631fe 100644
WR> --- a/arch/ppc/boot/simple/Makefile
WR> +++ b/arch/ppc/boot/simple/Makefile
WR> @@ -187,8 +187,7 @@ boot-$(CONFIG_REDWOOD_6) += embed_config.o
WR> boot-$(CONFIG_8xx) += embed_config.o
WR> boot-$(CONFIG_8260) += embed_config.o
WR> boot-$(CONFIG_EP405) += embed_config.o
WR> -boot-$(CONFIG_XILINX_ML300) += embed_config.o
WR> -boot-$(CONFIG_XILINX_ML403) += embed_config.o
WR> +boot-$(CONFIG_XILINX_VIRTEX) += embed_config.o
Don't do that. Other boards with Xilinx FPGAs don't necessarily need
embed_config.c
WR> boot-$(CONFIG_BSEIP) += iic.o
WR> boot-$(CONFIG_MBX) += iic.o pci.o qspan_pci.o
WR> boot-$(CONFIG_MV64X60) += misc-mv64x60.o
WR> diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
WR> index 840bff2..e0b8954 100644
WR> --- a/arch/ppc/boot/simple/embed_config.c
WR> +++ b/arch/ppc/boot/simple/embed_config.c
WR> @@ -744,7 +744,7 @@ embed_config(bd_t **bdp)
WR> }
WR> #endif /* WILLOW */
WR> -#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
WR> +#if defined(CONFIG_XILINX_VIRTEX)
WR> void
WR> embed_config(bd_t ** bdp)
.. And if they do, they might have another embed_config (E.G. if the
bootloader provides a valid struct bd_t).
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH v2] lite5200b: flash definition in dts
From: Domen Puncer @ 2007-08-07 7:02 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40708012323p2eca4b05pd47acac635cf6370@mail.gmail.com>
Add flash definition for in lite5200b dts, and while at it
fix "ranges" for soc node.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
---
OK.
Then how about something like this?
# ls /sys/devices/
total 0
drwxr-xr-x 34 root root 0 Dec 9 1993 f0000000.soc5200
drwxr-xr-x 3 root root 0 Dec 9 1993 fe000000.flash
drwxr-xr-x 3 root root 0 Dec 9 1993 ff000000.flash
drwxr-xr-x 4 root root 0 Dec 9 1993 pci0000:00
drwxr-xr-x 5 root root 0 Dec 9 1993 platform
drwxr-xr-x 6 root root 0 Aug 7 08:39 system
# cat /proc/mtd
dev: size erasesize name
mtd0: 01000000 00020000 "data0"
mtd1: 00f00000 00020000 "data1"
mtd2: 00100000 00020000 "u-boot"
Domen
arch/powerpc/boot/dts/lite5200b.dts | 23 ++++++++++++++++++++++-
arch/powerpc/platforms/52xx/mpc52xx_common.c | 15 +++++++++++++++
2 files changed, 37 insertions(+), 1 deletion(-)
Index: clean-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
===================================================================
--- clean-powerpc.git.orig/arch/powerpc/boot/dts/lite5200b.dts
+++ clean-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
@@ -52,7 +52,7 @@
revision = ""; // from bootloader
#interrupt-cells = <3>;
device_type = "soc";
- ranges = <0 f0000000 f0010000>;
+ ranges = <00000000 f0000000 00010000>;
reg = <f0000000 00010000>;
bus-frequency = <0>; // from bootloader
system-frequency = <0>; // from bootloader
@@ -345,4 +345,25 @@
reg = <8000 4000>;
};
};
+
+ flash@fe000000 {
+ device_type = "rom";
+ compatible = "direct-mapped";
+ probe-type = "CFI";
+ reg = <fe000000 01000000>;
+ bank-width = <1>;
+ partitions = <00000000 01000000>;
+ partition-names = "data0";
+ };
+
+ flash@ff000000 {
+ device_type = "rom";
+ compatible = "direct-mapped";
+ probe-type = "CFI";
+ reg = <ff000000 01000000>;
+ bank-width = <1>;
+ partitions = <00000000 00f00000
+ 00f00000 00100000>;
+ partition-names = "data1", "u-boot";
+ };
};
Index: clean-powerpc.git/arch/powerpc/platforms/52xx/mpc52xx_common.c
===================================================================
--- clean-powerpc.git.orig/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ clean-powerpc.git/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -119,9 +119,24 @@ unmap_regs:
void __init
mpc52xx_declare_of_platform_devices(void)
{
+ struct device_node *root, *child;
+ static const struct of_device_id matches[] = {
+ { .type = "rom", .compatible = "direct-mapped", },
+ {}
+ };
+
/* Find every child of the SOC node and add it to of_platform */
if (of_platform_bus_probe(NULL, NULL, NULL))
printk(KERN_ERR __FILE__ ": "
"Error while probing of_platform bus\n");
+
+ /* add flash chips */
+ root = of_find_node_by_path("/");
+ child = NULL;
+ while ((child = of_get_next_child(root, child))) {
+ if (of_match_node(matches, child))
+ of_platform_device_create(child, NULL, NULL);
+ }
+ of_node_put(root);
}
^ permalink raw reply
* Device tree aware EMAC driver
From: David Gibson @ 2007-08-07 6:22 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, Josh Boyer, Jon Loeliger,
linuxppc-dev
Based on BenH's earlier work, this is a new version of the EMAC driver
for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
same ASIC is also found in the Axon bridge chip. This new version is
designed to work in the arch/powerpc tree, using the device tree to
probe the device, rather than the old and ugly arch/ppc OCP layer.
This driver is designed to sit alongside the old driver (it lies in
drivers/net/ibm_emac and this one in drivers/net/ibm_newemac). The
old driver is left in place to support arch/ppc until arch/ppc itself
reaches its final demise (not too long now, with luck).
This driver still has a number of things that could do with cleaning
up, but I think they can be fixed up after merging. Specifically:
- Should be adjusted to properly use the dma mapping API.
Axon needs this.
- Probe logic needs reworking, in conjuction with the general
probing code for of_platform devices. The dependencies here between
EMAC, MAL, ZMII etc. make this complicated. At present, it usually
works, because we initialize and register the sub-drivers before the
EMAC driver itself, and (being in driver code) runs after the devices
themselves have been instantiated from the device tree.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Paul, I discussed with BenH, and although there are some problems with
the driver still, we think it's good enough to merge in 2.6.24, the
warts can be fixed up later.
Too big for the list, patch is at:
http://ozlabs.org/~dgibson/home/emac/powerpc-emac-new-20070807.patch
--
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
* Fix small race in 44x tlbie function
From: David Gibson @ 2007-08-07 4:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Todd Inglett, Volkmar Uhlig
The 440 family of processors don't have a tlbie instruction. So, we
implement TLB invalidates by explicitly searching the TLB with tlbsx.,
then clobbering the relevant entry, if any. Unfortunately the PID for
the search needs to be stored in the MMUCR register, which is also
used by the TLB miss handler. Interrupts were enabled in _tlbie(), so
an interrupt between loading the MMUCR and the tlbsx could cause
incorrect search results, and thus a failure to invalide TLB entries
which needed to be invalidated.
This patch fixes the problem in both arch/ppc and arch/powerpc by
inhibiting interrupts (even critical and debug interrupts) across the
relevant instructions.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Paul, this one's a bugfix, which I think should go into 2.6.23.
Index: working-2.6/arch/powerpc/kernel/misc_32.S
===================================================================
--- working-2.6.orig/arch/powerpc/kernel/misc_32.S 2007-07-27 14:19:46.000000000 +1000
+++ working-2.6/arch/powerpc/kernel/misc_32.S 2007-07-27 14:30:46.000000000 +1000
@@ -301,9 +301,19 @@ _GLOBAL(_tlbie)
mfspr r4,SPRN_MMUCR
mfspr r5,SPRN_PID /* Get PID */
rlwimi r4,r5,0,24,31 /* Set TID */
- mtspr SPRN_MMUCR,r4
+ /* We have to run the search with interrupts disabled, even critical
+ * and debug interrupts (in fact the only critical exceptions we have
+ * are debug and machine check). Otherwise an interrupt which causes
+ * a TLB miss can clobber the MMUCR between the mtspr and the tlbsx. */
+ mfmsr r5
+ lis r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@ha
+ addi r6,r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@l
+ andc r6,r5,r6
+ mtmsr r6
+ mtspr SPRN_MMUCR,r4
tlbsx. r3, 0, r3
+ mtmsr r5
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64,
Index: working-2.6/arch/ppc/kernel/misc.S
===================================================================
--- working-2.6.orig/arch/ppc/kernel/misc.S 2007-07-27 14:19:46.000000000 +1000
+++ working-2.6/arch/ppc/kernel/misc.S 2007-07-27 14:31:31.000000000 +1000
@@ -237,9 +237,19 @@ _GLOBAL(_tlbie)
mfspr r4,SPRN_MMUCR
mfspr r5,SPRN_PID /* Get PID */
rlwimi r4,r5,0,24,31 /* Set TID */
- mtspr SPRN_MMUCR,r4
+ /* We have to run the search with interrupts disabled, even critical
+ * and debug interrupts (in fact the only critical exceptions we have
+ * are debug and machine check). Otherwise an interrupt which causes
+ * a TLB miss can clobber the MMUCR between the mtspr and the tlbsx. */
+ mfmsr r5
+ lis r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@ha
+ addi r6,r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@l
+ andc r6,r5,r6
+ mtmsr r6
+ mtspr SPRN_MMUCR,r4
tlbsx. r3, 0, r3
+ mtmsr r5
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64,
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] powerpc: Pegasos keyboard detection
From: Alan Curry @ 2007-08-07 4:16 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <46B79562.9020202@genesi-usa.com>
I'm almost sorry I spoke up...
Matt Sealey writes the following:
>
>Okay before you add to the nvramrc you also need to add probe-all to build the
>device tree first; I assumed this was common knowledge.
Maybe for experienced OpenFirmware developers; this is the first time I've
had to touch the stuff. So first I had to learn Forth. To patch the kernel
you only need to know C. (Of course I already knew C -- it's common
knowledge.)
^ permalink raw reply
* Re: [PING][PATCH] PPC 4xx HW Watchpoint
From: David Gibson @ 2007-08-07 4:14 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070807000824.GB3925@crusty.rchland.ibm.com>
On Mon, Aug 06, 2007 at 07:08:25PM -0500, Josh Boyer wrote:
> On Mon, Aug 06, 2007 at 06:10:29PM -0300, rrbranco@br.ibm.com wrote:
> > Hello guys,
> >
> > I'm just writting to know if someone have some opinion about the patch I
> > sent a week ago. I'm not sending it again cause I'm traveling and don't
> > have it here in this machine.
>
> Sorry Rodrigo. I'll try to find some time this week to review it. It's been
> on my list, I just haven't gotten to it yet.
Same here, pretty much. I don't really know enough about the general
ptrace() architecture to know where to start, particularly.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-07 4:11 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <a9100305ca02c8609458c72edb99342c@kernel.crashing.org>
On Mon, Aug 06, 2007 at 10:15:39PM +0200, Segher Boessenkool wrote:
> >>> + UIC0: interrupt-controller0 {
> >>> + compatible = "ibm,uic-440gp","ibm,uic";
> >>
> >> The first compatible entry should always be the precise model, so in
> >> this case "ibm,uic-440epx". If it is (supposed to be) identical to
> >> the UIC in the 440GP, it can also have an "ibm,uic-440gp" entry, but
> >> since I believe all the UICs are supposed to operate the same, I think
> >> that's implicit in the "ibm,uic" entry.
> >
> > Most UICs are the same. There are some oddball chips that either hide
> > particular registers because they are unused, or they change the
> > addressing stride. I'm not sure that is a common enough case to worry
> > about now though.
>
> You only need to worry about the oddball cases in the device
> trees for a device that uses one off those.
>
> It is prudent to put the exact name of the device you're
> working with in there whenever possible, in case you later
> discover it has some quirks. If that doesn't happen, the
> kernel can happily keep probing on the more generic name.
Right. In that case I suggest the sequoia just specify:
compatible = "ibm,uic-440epx", "ibm,uic";
Because we have no particular reason to think that the 440EPx version
of UIC is any more similar to the 440GP version of UIC than it is to
the "normal" UIC.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-07 4:12 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <163e1bcdc507ddcde3193e842c96da43@kernel.crashing.org>
On Mon, Aug 06, 2007 at 10:54:33PM +0200, Segher Boessenkool wrote:
> > Aha! Ok, now I understand the sorts of situations you're talking
> > about. By "not direct mapped", I thought you were talking about some
> > kind of access via address/data registers on some indirect bus
> > controller, rather than weird variations on endianness and
> > bit-swizzling.
> >
> > Hrm.. this is a property of how the flash is wired onto the bus,
> > rather than of the flash chips themselves, so I'm not entirely sure
> > where description of it belongs.
> >
> > Simplest option seems to me to add a property "endianness" or
> > "bit-swizzling" or something which can be defined to describe some odd
> > connections. If absent we'd default to direct mapping. Segher, is
> > that idea going to cause you to scream?
>
> No, that's fine with me. I would recommend either using a
> _good_ _descriptive_ name for such a property describing the
> swizzling, if this swizzling is common; or just put the whole
> bloody weirdo address permutation into some nice big array,
> something like
>
> address-permutation = <0 1 3 2 4 5 7 6 e f d c a b 9 8>;
Yes, I was contemplating something like that.
[snip]
> > So I left out ranges, on the grounds that there isn't actually
> > anything at present which will attempt to access flash partitions
> > "generically" as a device tree device.
>
> It looks good to me like this.
>
> In a real OF, the "register" access for the flash partition
> node would be handled by its parent node, which would know
> to do the direct-mapping thing (at least mapping it to _its_
> parent, which typically asks the nodes further up, etc.)
>
> For the kernel world, we should just document it in the binding.
>
> > I'm not sold on this approach, but I haven't heard you give a better
> > argument yet.
>
> I haven't heard or thought of anything better either. Using "ranges"
> is conceptually wrong, even ignoring the technical problems that come
> with it.
Why is "ranges" conceptually wrong?
To be honest this looks rather to me like another case where having
overlapping 'reg' and 'ranges' would actually make sense.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-07 4:09 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <f8e837f0c3f73a9b47d52be05f1d54cc@kernel.crashing.org>
On Mon, Aug 06, 2007 at 10:35:57PM +0200, Segher Boessenkool wrote:
> >> To be honest, I'm not sure that describing the mapping is really the
> >> job of the compatible property. That the flash is mapped into the
> >> address space is kind of implicit in the way the reg interacts with
> >> the parents' ranges property.
> >
> > Ah, I keep forgetting about implied 1:1 parent/child address
> > correspondence... :-<
>
> It's not implied, it is explicitly specified.
>
> > But does it really imply how the (low) address bits of the *child*
> > bus
> > ("ebc" in this case) are connected to the chip? I don't think so...
>
> The currently proposed binding assumes linear mapping.
>
> Strange setups will need to extend this binding; this
> does mean that the burden for that is not on the "normal"
> case.
>
> There are so many weird ways in which people wire up memory
> devices that there is no chance to define a "generic" binding
> that works for all in less than 400 pages of documentation.
>
> > Well, "device-width" is not the thing that we care about either.
> > ;-)
>
> You need to know the device-width to drive the chip (and no,
> it isn't enough to know the exact chip model even) -- why do
> you say you don't care about it?
>
> >>> Hmm... what does @2,0 mean? :-O
> >
> >> EBC chip select 2, offset 0.
> >
> > Well, so this node is under some kind of local bus node -- that's
> > good.
> > Didn't know that the spec allows commas after @...
>
> Most characters are allowed in the unit-address... The following
> is just fine: "my-secret-base@the-moon". ISA uses letters to
> distinguish between its different address spaces, for example.
Yeah, I should probably make dtc a bit more flexible about accepting
that, too. At present, it only takes hex digits and ',', since those
are the common character.
> There is a direct correspondence between the first "reg"
> address and the text representation of the unit address;
> this correspondence is bus-dependent however.
>
> David, can multiple devices sit on the same chip-select
> on EBC, or on the same "minor" address? If not, you can
> simplify your unit address representation.
As far as I know, multiple devices could sit on the same chip select:
provided there was enough address decoding logic in or around the
devices, and that there existing bus timing parameters which would
work with all the devices on a chip select (or "bank" in the
terminology of the EBC bridge documentation).
Devices on different banks can certainly have the same address/offset
within the bank - e.g. on Ebony most of the devices are at offset 0.
The OPB address range for each bank is separately programmable in the
EBC bridge DCRs.
(Incidentally, this is why I created the binding in this way, rather
than just using the firmware established addresses in OPB space, which
are usually fixed for a particular board/platform. This way provides
enough information that, if necessary, the kernel or another client
can reprogram the EBC from scratch to access the various devices
present. Well.. actually fully reprogramming would also need the the
bus timing parameters, which I was thinking of adding information
before, but I haven't gotten to it yet.)
> >> "direct-mapped" is simply not a sufficiently specific compatible
> >> property, no two ways about it.
> >
> > Yes, for example "direct-mapped-cfi" and "direct-mapped-jedec"
> > would have
> > been better...
>
> Nah. These memory devices are meant to sit at some address/data
> bus; whether it is direct-mapped or not is obvious from the node
> hierarchy the flash node hangs under already; let's make the simple
> case simple and the complicated cases possible.
>
>
> Segher
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 10/10] Bamboo zImage wrapper
From: David Gibson @ 2007-08-07 3:04 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070803161711.457497000@linux.vnet.ibm.com>
On Fri, Aug 03, 2007 at 11:09:10AM -0500, Josh Boyer wrote:
> Add a bootwrapper for the AMCC 440EP Bamboo Eval board. This also adds a
> common fixup_clock function for all 440EP(x) chips.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 02/10] 4xx Kconfig cleanup
From: David Gibson @ 2007-08-07 3:06 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070806123144.GY3925@crusty.rchland.ibm.com>
On Mon, Aug 06, 2007 at 07:31:44AM -0500, Josh Boyer wrote:
> On Sat, Aug 04, 2007 at 05:45:38PM +1000, David Gibson wrote:
> > On Fri, Aug 03, 2007 at 11:09:02AM -0500, Josh Boyer wrote:
> > > Remove some leftover cruft in the 40x Kconfig file. Also make sure we
> > > select WANT_DEVICE_TREE for 40x.
> > >
> > > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > >
> > > ---
> > > arch/powerpc/platforms/40x/Kconfig | 77 ---------------------------------
> > > arch/powerpc/platforms/Kconfig.cputype | 1
> > > 2 files changed, 1 insertion(+), 77 deletions(-)
> > >
> > > --- linux-2.6.orig/arch/powerpc/platforms/40x/Kconfig
> > > +++ linux-2.6/arch/powerpc/platforms/40x/Kconfig
> > > @@ -1,16 +1,3 @@
> > > -config 4xx
> > > - bool
> > > - depends on 40x || 44x
> > > - default y
> >
> > You've removed this one, but I don't see you re-add it anywhere. We
> > still need to define the CONFIG_4xx symbol or things will break..
>
> I don't need to re-add it. It's already in
>
> arch/powerpc/platforms/Kconfig.cputype
Ah, so it is. Sorry. In that case:
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 04/10] 4xx bootwrapper reworks
From: David Gibson @ 2007-08-07 3:05 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070806123602.GZ3925@crusty.rchland.ibm.com>
On Mon, Aug 06, 2007 at 07:36:03AM -0500, Josh Boyer wrote:
> On Mon, Aug 06, 2007 at 02:38:55PM +1000, David Gibson wrote:
> > On Fri, Aug 03, 2007 at 11:09:04AM -0500, Josh Boyer wrote:
> > > -#define SPRN_DBCR0 0x134
> > > -#define DBCR0_RST_SYSTEM 0x30000000
> > > +#define DBCR0_RST_SYSTEM 0x30000000
> >
> > Rather than just removing these defines and using hardcoded values,
> > I'd prefer to see separate SPRN_DBCR0_40X and SPRN_DBCR0_44X defines.
>
> Ok. And place them where? In the same file since they aren't DCR defines?
> Seems fairly trivial, but ok.
Just where the old 44x specific define was. And yes, it is fairly
trivial.
> > [snip]
> > > +#define EMAC_RESET 0x20000000
> > > +#define MAL_RESET 0x80000000
> >
> > I think the MAL_RESET definition should go in the same place as the
> > DCR number definition.
>
> Ok. Trivial.
Yes.
> > As I think I said before, I'm not really happy with this being
> > hardcoded assuming exactly 2 ethernets.
>
> Well, it's hardcoded to assume one or two. I know of only one board that has
> more than two EMACs. I was hoping we could get this in for 2.6.24 as-is and
> change it when needs be. But I'll look at making it var-args or similar.
>
> josh
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 10/10] Bamboo zImage wrapper
From: David Gibson @ 2007-08-07 3:04 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070806123901.GA3925@crusty.rchland.ibm.com>
On Mon, Aug 06, 2007 at 07:39:02AM -0500, Josh Boyer wrote:
> On Mon, Aug 06, 2007 at 03:00:12PM +1000, David Gibson wrote:
> > On Fri, Aug 03, 2007 at 11:09:10AM -0500, Josh Boyer wrote:
> > > Add a bootwrapper for the AMCC 440EP Bamboo Eval board. This also adds a
> > > common fixup_clock function for all 440EP(x) chips.
> >
> > Ok, you have a separate bamboo.c and treeboot-bamboo.c, like with
> > ebony. However here, therer's only one outermost wrapper -
> > treeboot-bamboo.c which means there's not really any point to this
> > separation.
>
> Milton already mentioned this the first time I submitted the patch.
>
> > Do you know if there are Bamboo boards with old u-boot versions, or
> > some other bootloader which would make the separation worthwhile
> > later?
>
> Yes, there are. And yes, I plan on submitting the cuboot-bamboo.c
> wrapper just as soon as I get a chance to get my board switched back
> to u-boot. It's actually pretty trivial to keep both PIBS and
> u-boot on a bamboo board, since you can program u-boot into the
> flash from PIBS and flip some switches to boot from it.
Ok.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-07 3:41 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <59e87834966d80bb143e1683fe751cd1@kernel.crashing.org>
On Mon, Aug 06, 2007 at 09:59:24PM +0200, Segher Boessenkool wrote:
> >>> Yeah, better names please -- if possible, something that someone
> >>> without knowledge of this SoC will understand what it is.
> >>
> >> I think the names are probably ok - I'm assuming they're in keeping
> >> with the convention I've used of using the same names / abbreviations
> >> as in the CPU user manual. I'm asking just for my own information,
> >> although a comment might not be a bad idea.
>
> Fine with me -- I personally prefer "system-device-controller"
> and "clock-power-controller" or similar, but that is mostly a
> matter of taste. As long as it's human readable it's fine.
Actually, it occurs to me that I've only sometimes been using that
convention for the names: basically just for the weirdo chip control
devices that don't have a more widespread generic name. I *have* been
strictly keeping to that convention for the labels in the dts (which
is why the PLB<->OPB bridge node is labelled POB rather than OPB, for
example).
> > - Required properties:
> > + - compatible : should contain the specific model of flash
> > chip(s) used
>
> "if known".
Added.
> > + followed by either "cfi-flash" or "jedec-flash"
>
>
> > + Flash partitions
> > + - reg :
> > + - read-only : (optional)
>
> I'll hold off commenting on this until you've finish writing it,
> you probably know my opinion about it anyway :-)
Heh.. actually I was kind of hoping for your input on what's still
missing. For example, I don't know what the necessary extra
properties for JEDEC chips are.
> One thing though -- what _exactly_ does "read-only" signify?
That's... a good 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
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-07 3:35 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <3831d2304a027a1790e6d3cd666c2494@kernel.crashing.org>
On Mon, Aug 06, 2007 at 10:20:01PM +0200, Segher Boessenkool wrote:
> >>> + - compatible : should contain the specific model of flash
> >>> chip(s) used
> >>> + followed by either "cfi-flash" or "jedec-flash"
> >>
> >> This "compatible" prop (and the node in whole) doesn't say a
> >> thing about how the flash is mapped into the CPU address space. I
> >> strongly disagree that this node provides enough info to select a
> >> driver. :-/
> >
> > To be honest, I'm not sure that describing the mapping is really the
> > job of the compatible property. That the flash is mapped into the
> > address space is kind of implicit in the way the reg interacts with
> > the parents' ranges property.
>
> Exactly.
>
> > Can you describe some of the options for *not* direct mapped flash
> > chips - I can't reasonably come up with a way of describing the
> > distinction when I've never seen NOR flash other than direct mapped.
>
> What, you've never seen SPI flash or IIC flash? :-)
Nope. Colour me ignorant :-p.
--
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: Please pull powerpc.git merge branch
From: Zhang Wei-r63237 @ 2007-08-07 3:31 UTC (permalink / raw)
To: michael, Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1186456715.19257.16.camel@concordia.ozlabs.ibm.com>
Hi, Michael,
I get them. Thanks for your work! :)
Best Regards,
Zhang Wei
> -----Original Message-----
> From: Michael Ellerman [mailto:michael@ellerman.id.au]=20
> Sent: Tuesday, August 07, 2007 11:19 AM
> To: Zang Roy-r61911
> Cc: Kumar Gala; linuxppc-dev list; Paul Mackerras; Zhang Wei-r63237
> Subject: Re: Please pull powerpc.git merge branch
>=20
> On Tue, 2007-08-07 at 10:57 +0800, Zang Roy-r61911 wrote:
> > On Tue, 2007-08-07 at 09:06, Michael Ellerman wrote:
> > > On Mon, 2007-08-06 at 08:57 -0500, Kumar Gala wrote:
> > > > On Aug 6, 2007, at 12:57 AM, Zhang Wei-r63237 wrote:
> > > >=20
> > > > > Hi, Paul,
> > > > >
> > > > > How about following patches?
> > > > >
> > > > > [PATCH 1/2] Add sysdev/pci_quirks.c file into PowerPC
> > > architecture =20
> > > > > with
> > > > > ULI chip quirk functions.
> > > > > URL:
> > > http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040363.html
> > > > > [PATCH 2/2] Remove ULI chip quirks functions from=20
> MPC8641HPCN and
> > > > > MPC8544DS boards.
> > > > > URL:
> > > http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040364.html
> > > > >
> > > > > [PATCH 1/3] Add a new member name to structure irq_host
> > > > > URL:
> > > http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039896.html
> > > > > [PATCH 2/3] Add irq host name for all powerpc interrupt
> > > controllors.
> > > > > URL:
> > > http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039897.html
> > > > > [PATCH 3/3] Add irq debugfs and virq_mapping for=20
> getting the virq
> > > > > URL:
> > > http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039895.html
> > > >=20
> > > > These patches aren't fixing any bugs and would be for 2.6.24 at
> > > this =20
> > > > point.
> > >=20
> > > And I reworked them and posted new versions.
> > Where are the new versions?
> > I missed them?
>=20
> On the list, I though I cc'ed you but I guess I forgot :)
>=20
> http://patchwork.ozlabs.org/linuxppc/patch?q=3Dellerman&id=3D12612
> http://patchwork.ozlabs.org/linuxppc/patch?q=3Dellerman&id=3D12613
> http://patchwork.ozlabs.org/linuxppc/patch?q=3Dellerman&id=3D12614
> http://patchwork.ozlabs.org/linuxppc/patch?q=3Dellerman&id=3D12615
> http://patchwork.ozlabs.org/linuxppc/patch?q=3Dellerman&id=3D12616
>=20
> cheers
>=20
> --=20
> Michael Ellerman
> OzLabs, IBM Australia Development Lab
>=20
> wwweb: http://michael.ellerman.id.au
> phone: +61 2 6212 1183 (tie line 70 21183)
>=20
> We do not inherit the earth from our ancestors,
> we borrow it from our children. - S.M.A.R.T Person
>=20
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-07 3:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1186438523.938.83.camel@localhost.localdomain>
On Tue, Aug 07, 2007 at 08:15:23AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-08-06 at 22:37 +0400, Sergei Shtylyov wrote:
> >
> > Actually, checking for the presence of all possible perverted
> > mapping
> > props doesn't seem a good idea -- it's simpler to check for the
> > presence of
> > one prop (like "direct-mapped" I was thinking about, or maybe
> > "simple-map").
>
> Or more simply... if it's not a direct mapping, it doesn't have a ranges
> property and can't be walked down by conventional means.
But the ranges property is in the parent. And if the flash bank is
only one of several devices in the same address space, it might be
messy to exclude the flash range from the parent's ranges property.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-07 3:28 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <46B76A5A.3030300@ru.mvista.com>
On Mon, Aug 06, 2007 at 10:37:14PM +0400, Sergei Shtylyov wrote:
> Hello.
[snip]
> >>>Can you describe some of the options for *not* direct mapped flash
> >>>chips - I can't reasonably come up with a way of describing the
> >>>distinction when I've never seen NOR flash other than direct mapped.
>
> >> You're lucky to live in the single-endian world. Once you're in bi-endian
> >>one, all kinds of strange mappings become possible. I've seen the MIPS
>
> Well, not necessarily -- 16-bit only accesses are always possibly (no
> dount this would be a strange mapping however)...
I have no idea what you're getting at here.
> >>mapping driver which required swapping flash bytes in s/w in BE mode, i.e.
> >>couldn't be served by physmap, yet that's not all... here's the code of its
> >>map read*() methods:
>
> > Aha! Ok, now I understand the sorts of situations you're talking
> > about. By "not direct mapped", I thought you were talking about some
> > kind of access via address/data registers on some indirect bus
> > controller, rather than weird variations on endianness and
> > bit-swizzling.
>
> No, that would be just too ridiculous for a NOR flash -- I hope. :-)
Heh. In my experience, very little is so ridiculous that some
embedded vendor won't do it.
> > Hrm.. this is a property of how the flash is wired onto the bus,
> > rather than of the flash chips themselves,
>
> Indeed.
>
> > so I'm not entirely sure where description of it belongs.
>
> So, you're saying that the 1:1 address correspondence rule stops to apply
> here?
Well.. it all depends what exactly you consider the address space of
the flash bank. By which I mean the whole shmozzle represented by the
device node, not the individual flash chips. It's not immediately
obvious whether or not that should include any swizzling done by the
bus wiring.
It would be possible, I guess, to define a 'swizzled-ranges' property
or something which allows child devices to be embedded in the parent's
address range in a not-direct way. However, the swizzling on the
flash bank is really a property of the flash bank, not of the parent
bus - requiring it to be encoded in the parent is pretty yucky -
especially if the flash bank is just part of a larger chunk of bus
address space, defined by a single large ranges entry in the parent.
> > Simplest option seems to me to add a property "endianness" or
>
> And we even have a precedent of "big-endian" prop in the MPIC nodes
> (although I'm not sure why it's needed there).
>
> > "bit-swizzling" or something which can be defined to describe some odd
> > connections. If absent we'd default to direct mapping. Segher, is
> > that idea going to cause you to scream?
>
> Actually, checking for the presence of all possible perverted mapping
> props doesn't seem a good idea -- it's simpler to check for the presence of
> one prop (like "direct-mapped" I was thinking about, or maybe "simple-map").
>
> >>>>>+ - reg : Address range of the flash chip
> >>>>>+ - bank-width : Width (in bytes) of the flash bank. Equal to the device width
> >>>>>+ times the number of interleaved chips.
> >>>>>+ - device-width : (optional) Width of a single flash chip. If omitted,
> >>>>>+ assumed to be equal to 'bank-width'.
>
> >>>> Why then not just introduce the "interleave" prop and obsolete the
> >>>>"bank-width"?
>
> >>>Because they're equivalent information, and bank-width is what the
> >>>code ends up actually caring about. I don't see any reason to prefer
> >>>giving the interleave.
>
> >> Well, "device-width" is not the thing that we care about either. ;-)
>
> > Well, yes but we need to encode it somehow. Segher preferred
> > device-width to interleave, because it's closer to a description of
> > the actual hardware, rather than an abstration decribing its wiring.
>
> > In other words I *still* don't see any reason to prefer giving the
> > interleave.
>
> I wasn't talking of "interleave" preference over "device-width", I was
> talking about obsoleting "bank-width" with this pair.
Whatever. You haven't given any argument to prefer interleave over
either device-width or bank-width.
> >>>>>Index: working-2.6/drivers/mtd/maps/physmap_of.c
> >>>>>===================================================================
> >>>>>--- working-2.6.orig/drivers/mtd/maps/physmap_of.c 2007-07-30 17:07:11.000000000 +1000
> >>>>>+++ working-2.6/drivers/mtd/maps/physmap_of.c 2007-07-30 17:07:14.000000000 +1000
>
> >>[...]
>
> >>>>>+ for (pp = dp->child, i = 0 ; pp; pp = pp->sibling, i++) {
> >>>>>+ const u32 *reg;
> >>>>>+ const char *name;
> >>>>>+ const void *ro;
>
> >>>> We hardly need the above 2 variables.
>
> >>>They're all used...
>
> >> I meant that there's no necessity in them.
>
> > By which you mean....?
>
> They're only written to once, and then read immediately which might be
> easily collapsed into a single statement.
Ah, yes, ok. Changed.
> >>[...]
>
> >>>>>@@ -221,6 +297,14 @@ err_out:
> >>>>>
> >>>>>static struct of_device_id of_physmap_match[] = {
> >>>>> {
> >>>>>+ .compatible = "cfi-flash",
> >>>>>+ .data = (void *)"cfi_probe",
> >>>>>+ },
> >>>>>+ {
> >>>>>+ .compatible = "jedec-flash",
> >>>>>+ .data = (void *)"jedec_probe",
> >>>>>+ },
> >>>>>+ {
>
> >>>> This would also trigger on non-linearly mapped CFI or JEDEC
> >>>>flashes which is not a good idea -- however, as we're using the MTD
> >>>>probing code anyway, it will just fail, so it's not luckily is not a
> >>>>fatal design flaw.
>
> >>>Well, if there's nothing else to distinguish them. Which there isn't
> >>>yet, but will need to be: see above about incomplete - helpful
> >>>suggestions about how to describe the mapping would be more useful
> >>>than merely pointing out the lack.
>
> >> I was thinking about adding "direct-mapped" prop... but maybe adding
> >>"ranges" to the parent node (that's "ebc") would indeed ensure that the flash
> >>is mapped 1:1 to the EBC's parent bus also.
>
> > The ebc already has a ranges property. But that can't describe the
>
> Not in the device tree that started that thread -- I haven't seen another.
Ah sorry. The ranges property isn't in the dts, it's added by the
bootwrapper based on the EBC register contents.
> > sorts of bit-swizzling you're talking about.
>
> Let's hear what Segher says (if he's not yet tired of all this :-).
>
> >>>>>Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
> >>>>>===================================================================
> >>>>>--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-07-30 17:07:14.000000000 +1000
> >>>>>+++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-07-30 17:07:14.000000000 +1000
>
> >>>>[...]
>
> >>>>>@@ -158,14 +161,20 @@
> >>>>> };
>
> >>>>> large-flash@2,0 {
>
> >>>> Hmm... what does @2,0 mean? :-O
>
> >>>EBC chip select 2, offset 0.
>
> >> Well, so this node is under some kind of local bus node -- that's good.
> >>Didn't know that the spec allows commas after @...
>
> > Well, now you do. I believe USB usually uses that format, too.
>
> USB what, hosts or devices?
Devices.
> >>>>>- device_type = "rom";
> >>>>>- compatible = "direct-mapped";
> >>>>>- probe-type = "JEDEC";
> >>>>>+ compatible = "jedec-flash";
> >>>>> bank-width = <1>;
> >>>>>- partitions = <0 380000
> >>>>>- 380000 80000>;
> >>>>>- partition-names = "fs", "firmware";
> >>>>>+// partitions = <0 380000
> >>>>>+// 380000 80000>;
> >>>>>+// partition-names = "fs", "firmware";
> >>>>> reg = <2 0 400000>;
> >>>>>+ #address-cells = <1>;
> >>>>>+ #size-cells = <1>;
>
> >>>> Heh...
>
> >>>Yeah, that bit's a bit ugly, I'll grant you.
>
> >> Don't we need "ranges" here, at least from the formal PoV -- as the parent
> >>and child address spaces differ? I know the physmap_of parser doesn't care but
> >>still...
>
> > That's one I've wondered about. To describe the partitions address
> > space as lying (ultimately) in the physical address space, which in a
> > sense it does, yes we'd need a ranges property here. But we also have
> > a 'reg' at the top level which would overlap with that hypothetical
> > ranges which would be weird. Or we could exclude the top-level reg,
> > but then that's a pain if we do want to map the flash as a whole.
>
> Hm, right... the option here would be to always have at least one
> partition and no "reg" property in the MTD node itself... or have "reg" with
> no partition and "ranges" if partitions are there... :-)
Eck.
> > So I left out ranges, on the grounds that there isn't actually
> > anything at present which will attempt to access flash partitions
> > "generically" as a device tree device.
>
> > I'm not sold on this approach, but I haven't heard you give a better
> > argument yet.
>
> Well, that was mostly thoretic speculation...
>
> WBR, Sergei
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
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: Please pull powerpc.git merge branch
From: Michael Ellerman @ 2007-08-07 3:18 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras, Zhang Wei-r63237
In-Reply-To: <1186455451.2163.3.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]
On Tue, 2007-08-07 at 10:57 +0800, Zang Roy-r61911 wrote:
> On Tue, 2007-08-07 at 09:06, Michael Ellerman wrote:
> > On Mon, 2007-08-06 at 08:57 -0500, Kumar Gala wrote:
> > > On Aug 6, 2007, at 12:57 AM, Zhang Wei-r63237 wrote:
> > >
> > > > Hi, Paul,
> > > >
> > > > How about following patches?
> > > >
> > > > [PATCH 1/2] Add sysdev/pci_quirks.c file into PowerPC
> > architecture
> > > > with
> > > > ULI chip quirk functions.
> > > > URL:
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040363.html
> > > > [PATCH 2/2] Remove ULI chip quirks functions from MPC8641HPCN and
> > > > MPC8544DS boards.
> > > > URL:
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040364.html
> > > >
> > > > [PATCH 1/3] Add a new member name to structure irq_host
> > > > URL:
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039896.html
> > > > [PATCH 2/3] Add irq host name for all powerpc interrupt
> > controllors.
> > > > URL:
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039897.html
> > > > [PATCH 3/3] Add irq debugfs and virq_mapping for getting the virq
> > > > URL:
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039895.html
> > >
> > > These patches aren't fixing any bugs and would be for 2.6.24 at
> > this
> > > point.
> >
> > And I reworked them and posted new versions.
> Where are the new versions?
> I missed them?
On the list, I though I cc'ed you but I guess I forgot :)
http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=12612
http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=12613
http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=12614
http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=12615
http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=12616
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Zang Roy-r61911 @ 2007-08-07 2:57 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev list, Paul Mackerras, Zhang Wei-r63237
In-Reply-To: <1186448777.19257.0.camel@concordia.ozlabs.ibm.com>
On Tue, 2007-08-07 at 09:06, Michael Ellerman wrote:
> On Mon, 2007-08-06 at 08:57 -0500, Kumar Gala wrote:
> > On Aug 6, 2007, at 12:57 AM, Zhang Wei-r63237 wrote:
> >
> > > Hi, Paul,
> > >
> > > How about following patches?
> > >
> > > [PATCH 1/2] Add sysdev/pci_quirks.c file into PowerPC
> architecture
> > > with
> > > ULI chip quirk functions.
> > > URL:
> http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040363.html
> > > [PATCH 2/2] Remove ULI chip quirks functions from MPC8641HPCN and
> > > MPC8544DS boards.
> > > URL:
> http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040364.html
> > >
> > > [PATCH 1/3] Add a new member name to structure irq_host
> > > URL:
> http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039896.html
> > > [PATCH 2/3] Add irq host name for all powerpc interrupt
> controllors.
> > > URL:
> http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039897.html
> > > [PATCH 3/3] Add irq debugfs and virq_mapping for getting the virq
> > > URL:
> http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039895.html
> >
> > These patches aren't fixing any bugs and would be for 2.6.24 at
> this
> > point.
>
> And I reworked them and posted new versions.
Where are the new versions?
I missed them?
Roy
^ 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