Re: [PATCH] fix appletouch geyser 1 breakage
OK then let's play safe and don't touch fountains at all. How about the patch below? Looks fine to me, works with my fountain touchpad and should fix Joseph's error too. Input: appletouch - idle reset logic broke older Fountains Fountains do not support change mode request and therefore should be excluded from idle reset attempts. Also: - do not re-submit URB when we decide that toucvhpad needs to be reinicialized - do not repeat size detection when reinitializing the touchpad - Add missing KERN_* prefixes to messages Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED] Acked-by: Johannes Berg [EMAIL PROTECTED] --- drivers/input/mouse/appletouch.c | 125 --- 1 file changed, 77 insertions(+), 48 deletions(-) johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix demotion of segments to 4K pages
On Mon, 29 Oct 2007, Benjamin Herrenschmidt wrote: On Sun, 2007-10-28 at 22:06 -0500, Olof Johansson wrote: And I don't care, I will continue adding them because the opposite is fugly :-) Yeah , I know what you mean . This looks so much more natural . Who said it has to be consistent ? :-) I use spaces before ? and ! mostly. In fact, it might even be the rule in french, I'm not too sure :-) Yes it is http://en.wikipedia.org/wiki/Punctuation_in_French ;-) C'est permis, mais seulement en Français ;-) 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] ehea: add kexec support
Jan-Bernd Themann wrote: eHEA resources that are allocated via H_CALLs have a unique identifier each. These identifiers are necessary to free the resources. A reboot notifier is used to free all eHEA resources before the indentifiers get lost, i.e before kexec starts a new kernel. Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED] applied to #upstream-fixes ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4.3] FEC - fast ethernet controller for mpc52xx
Domen Puncer wrote:
On 26/10/07 07:18 -0700, Dale Farnsworth wrote:
On Fri, Oct 26, 2007 at 01:59:09PM +0200, Domen Puncer wrote:
+static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
+{
+ struct net_device *dev = dev_id;
+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ spin_lock(priv-lock);
+
+ while (bcom_buffer_done(priv-tx_dmatsk)) {
+ struct sk_buff *skb;
+ struct bcom_fec_bd *bd;
+ skb = bcom_retrieve_buffer(priv-tx_dmatsk, NULL,
+ (struct bcom_bd **)bd);
+ /* Here (and in rx routines) would be a good place for
+* dma_unmap_single(), but bcom doesn't return bcom_bd of the
+* finished transfer, and _unmap is empty on this platfrom.
+*/
Oops, you forgot to remove the above comment. :)
Argh!
Repost w/o the comment.
Sorry for receiving all this almost-spam.
Otherwise,
Acked-by: Dale Farnsworth [EMAIL PROTECTED]
Domen, thanks for all your work on this. It's good to see it finally go in.
-Dale
--- again, use your scisors here ;-) ---
Driver for ethernet on mpc5200/mpc5200b SoCs (FEC).
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
Acked-by: Dale Farnsworth [EMAIL PROTECTED]
---
drivers/net/Kconfig | 24
drivers/net/Makefile |4
drivers/net/fec_mpc52xx.c | 1112
++
drivers/net/fec_mpc52xx.h | 313 +++
drivers/net/fec_mpc52xx_phy.c | 198 +++
5 files changed, 1651 insertions(+)
applied to #upstream-fixes
it's not strictly a fix, but I did not want to hold this back until
2.6.25 either
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ucc_geth: add support for netpoll
On Mon, Oct 29, 2007 at 02:12:07PM +0800, Li Yang-r58472 wrote:
[...]
+#ifdef CONFIG_NET_POLL_CONTROLLER
+/*
+ * Polling 'interrupt' - used by things like netconsole to send
+skbs
+ * without having to re-enable interrupts. It's not called while
+ * the interrupt routine is executing.
+ */
+static void ucc_netpoll(struct net_device *dev) {
+ struct ucc_geth_private *ugeth = netdev_priv(dev);
+
+ disable_irq(ugeth-ug_info-uf_info.irq);
+ ucc_geth_irq_handler(ugeth-ug_info-uf_info.irq, dev);
+ enable_irq(ugeth-ug_info-uf_info.irq);
Why not make it less complex (for a reader and gcc too :-) ?
Yup, I'm agree here but it's too late. Again. ;-)
This patch already accepted into the -mm (a week or so after
the silence), so.. now I'd rather not bother Andrew with such
really cosmetic changes. But if Jeff would directly apply
modfied patch, I'll send it. ;-)
Oops. The original patch happened to hit the Junk mail box. :(
That one as well? http://lkml.org/lkml/2007/10/11/128
I think
the patch is good to merge after the cosmetic change. I can do it in
next pull request to Jeff.
Ok, great. Thanks.
Here it is:
- - - -
From: Anton Vorontsov [EMAIL PROTECTED]
Subject: [PATCH] ucc_geth: add support for netpoll
This patch adds netpoll support for the QE UCC Gigabit Ethernet
driver. Tested using netconsole and KGDBoE.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/net/ucc_geth.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index bec413b..94e78d8 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3678,6 +3678,23 @@ static irqreturn_t ucc_geth_irq_handler(int irq, void
*info)
return IRQ_HANDLED;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+/*
+ * Polling 'interrupt' - used by things like netconsole to send skbs
+ * without having to re-enable interrupts. It's not called while
+ * the interrupt routine is executing.
+ */
+static void ucc_netpoll(struct net_device *dev)
+{
+ struct ucc_geth_private *ugeth = netdev_priv(dev);
+ int irq = ugeth-ug_info-uf_info.irq;
+
+ disable_irq(irq);
+ ucc_geth_irq_handler(irq, dev);
+ enable_irq(irq);
+}
+#endif /* CONFIG_NET_POLL_CONTROLLER */
+
/* Called when something needs to use the ethernet device */
/* Returns 0 for success. */
static int ucc_geth_open(struct net_device *dev)
@@ -3963,6 +3980,9 @@ static int ucc_geth_probe(struct of_device* ofdev, const
struct of_device_id *ma
#ifdef CONFIG_UGETH_NAPI
netif_napi_add(dev, ugeth-napi, ucc_geth_poll, UCC_GETH_DEV_WEIGHT);
#endif /* CONFIG_UGETH_NAPI */
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ dev-poll_controller = ucc_netpoll;
+#endif
dev-stop = ucc_geth_close;
//dev-change_mtu = ucc_geth_change_mtu;
dev-mtu = 1500;
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] powerpc: Pass PID argument to _tlbie (WAS: Apparent kernel bug with GDB on ppc405)
On Sat, 27 Oct 2007 17:32:02 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Allright, so Matt, let me know if that fixes your problem with gdb, and I'll clean the patch up a bit and submit it. I want to double check if something similar may be needed for freescale booke. Basically, the problem is that things like get_user_pages() can cause COW operations which in turn call _tlbie() to be called for translations that aren't in the current address space. The current 40x and 44x implementation of _tlbie doesn't handle that properly as it only invalidates entries in the current PID. This is an attempt at fixing it. Untested, I just checked it builds for arch/powerpc and arch/ppc. I also haven't looked whether the freescale BookE _tlbie needs similar treatement (it will get passed the pid in r4 with that patch, so if it needs to do something with it, it can). Kumar, can you have a look ? This looks pretty good at first glance. I'll try to test it out today, but I'd still like to hear if it solves Matt's problem as I doubt I'll be able to duplicate it. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC] Fix duplicate time accounting
Hello. Paul Mackerras wrote: Currently, process user and system times are advancing twice as fast as they should because they are being accounted in two places - in the generic code and in timer_interrupt. This fixes it by removing the call to account_process_time in timer_interrupt. But will the deterministic accounting option continue to work with such fix? Signed-off-by: Paul Mackerras [EMAIL PROTECTED] --- diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index 9eb3284..5e253d6 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -599,16 +599,6 @@ void timer_interrupt(struct pt_regs * regs) get_lppaca()-int_dword.fields.decr_int = 0; #endif - /* - * We cannot disable the decrementer, so in the period - * between this cpu's being marked offline in cpu_online_map - * and calling stop-self, it is taking timer interrupts. - * Avoid calling into the scheduler rebalancing code if this - * is the case. - */ - if (!cpu_is_offline(cpu)) - account_process_time(regs); - if (evt-event_handler) evt-event_handler(evt); else WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
boot/wrap assumes a biarch toolchain?
Hi, Jan is seeing the following fail: WRAParch/powerpc/boot/zImage.pmac powerpc-linux-objcopy: vmlinux: File format not recognized He is using a cross compile toolchain invoked with the following command line: # make HOSTCC=gcc-4.0 ARCH=powerpc CROSS_COMPILE=powerpc64-linux- CROSS32_COMPILE=powerpc-linux- It seems like boot/wrap wants to use both 64bit and 32bit tools, however it only receives the 32bit path: ifneq ($(CROSS32_COMPILE),) CROSSWRAP := -C $(CROSS32_COMPILE) else ifneq ($(CROSS_COMPILE),) CROSSWRAP := -C $(CROSS_COMPILE) endif endif Thoughts? I guess we have to pass in both cross compile targets. One way to make this go away would be to build binutils as biarch: # configure --target=powerpc-linux --enable-targets=powerpc64-linux ... Anton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RFC: replace device_type with new class property?
We've had some discussions internally here at Freescale among various PPC Linux developers about the device_type property and how 'classes' of devices should be represented in the device tree. Taking a long term view, the question I'd like to pose is how should classes of device should be identified in the flat device tree model? A device class, as I'm using it, refers basically to general categories of devices-- devices that share common properties. Examples in current device would be cpu, memory, pci, network, serial. Today the device_type property serves this purpose to some degree. However, the original meaning of device_type in Open Firmware is related to the method interface of a node it has a recent history of abuse in the Linux kernel DTS files, with a plethora of types made up in an ad hoc way. In addition, an OS can match on compatible and in the absence of method interfaces really doesn't need device_type anyway. However, one good thing about device_type (if properly used) is that it could identify which device nodes follow an official binding, vs proprietary devices or one-off device node definitions. Without something like device_type the _human_ reader of a DTS file has to infer from the name or compatible what the device type is. So, device class identifiers like memory, cpu, serial, pci, network provide that clarity. So, what should the long term approach be? Here are a couple of options: 1. Keep device_type, with it's use specifically defined to mean that the node with that property implements an 'official' binding. In the flat device tree model a binding is just a defined set of required (and optional properties. 2. Get rid of device_type and create a _new_ property like class. The only nodes permitted to have this property are those with 'official' bindings. These nodes would have a set of required (and optional) properties. The benefit of a new property is cutting all baggage associated with the old device_type property. One other point-- the intent of a device class is not necessarily to specify a sufficient set of properties to implement drivers. The network class would have a base set of required properties (e.g. mac-address,etc), but most likely would need additional properties to implement a driver for a specific device. The value in the class is when a developer needs to represent a new device that fits into an existing class he has a base set of properties to start with that has had some good thinking put into defining it. A device class would facilitate and encourage consistent use of properties names, which would be a good thing. The initial list of official classes would be small-- cpu,memory, cache, pci, serial, network, open-pic(?). As other types get codified in actual use and have official bindings specified (perhaps through power.org) new types would be supported--e.g. i2c, jdec-flash. Thoughts? Stuart Yoder Freescale Semiconductor, Inc. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: boot/wrap assumes a biarch toolchain?
Anton Blanchard [EMAIL PROTECTED] writes: One way to make this go away would be to build binutils as biarch: # configure --target=powerpc-linux --enable-targets=powerpc64-linux ... If you configure your toolchain for powerpc64-linux you get a biarch toolchain by default. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
David Gibson wrote: On Thu, Oct 25, 2007 at 05:46:19PM +0200, Marian Balakowicz wrote: Grant Likely wrote: On 10/25/07, Martin Krause [EMAIL PROTECTED] wrote: [snip] On a board with 16 MiB FLASH for example the big-fs _and_ the misc partition could not be used. big-fs, because the memory is too small (which is OK) and misc, because it overlaps 1 MiB over the physikal flash border. So only the first 9 MiB of the flash could be used in Linux. The remaining 7 MiB couldn't be accessed. Perhaps it would be better to drop the flash layout from the in-kernel dts files entirely since flash layout can be a fluid thing. Well, but that would not be really user friendly, I'd rather stick with some default config. Strictly speaking the device-tree is not the right place for flash partitioning information. We put it there because it's preferable to having hardcoded per-board flash layouts in the code itself. It only really works well, though, when there are strong conventions (shared with the firmware) about how to partition the flash. Where it's really up to the user to determine how they want to lay out their flash, putting things in the device tree isn't a really good idea. In principle, you are right, we should not be putting a user dependent configuration into .dts files. But on the other hand, bindings have been defined for flash-like devices and their partition layouts and physmap_of device driver is expecting to get this information from the blob. So, it is the place for it. But if we are not to put partition layouts into the default kernel .dts files then we should provide/maintain some examples an that may be a even bigger mess. Incidentally, it's not required that *all* the flash address space be in partitions, so it is possible only give partitions for those flash chunks which the firmware needs to know about. That might be nicer solution but different variants of TQM5200 boards do not share the same subset of partitions (default u-boot partitions at least), so it will not help much. Cheers, m. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: boot/wrap assumes a biarch toolchain?
Hi, If you configure your toolchain for powerpc64-linux you get a biarch toolchain by default. I was wondering about people using pre biarch gcc toolchains. But I take your point - I'm guessing binutils has been biarch for a long time. Since we are only calling binutils functions in boot/wrap, maybe we can just do: diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 18e3271..8961afd 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -121,13 +121,9 @@ wrapperbits:= $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree) \ # # Bits for building various flavours of zImage -ifneq ($(CROSS32_COMPILE),) -CROSSWRAP := -C $(CROSS32_COMPILE) -else ifneq ($(CROSS_COMPILE),) CROSSWRAP := -C $(CROSS_COMPILE) endif -endif # args (to if_changed): 1 = (this rule), 2 = platform, 3 = dts 4=dtb 5=initrd quiet_cmd_wrap = WRAP$@ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new class property?
Yoder Stuart-B08248 wrote: We've had some discussions internally here at Freescale among various PPC Linux developers about the device_type property and how 'classes' of devices should be represented in the device tree. The initial list of official classes would be small-- cpu,memory, cache, pci, serial, network, open-pic(?). As other types get codified in actual use and have official bindings specified (perhaps through power.org) new types would be supported--e.g. i2c, jdec-flash. Thoughts? I think device_type, compatible and model properties fulfil this already, they simply aren't being used correctly. Remember that, while you may want to make FDTs easier to design, OpenFirmware and the requirement on device interfaces through the client interface still exist and are still implemented (from time to time). What I would recommend is that the device_type encapsulate the class of the device as it is currently. This means for a display, you set device_type to display. OF platform devices for displays can then get a list of all the displays available on a system, or i2c controllers available on a system. For readability, the name of the device needn't match device_type; for instance on the 5121E it may be that the 'diu' unit be called diu, but be of device_type 'display' - further information can be added through the 'compatible' property of devices that also support the same register model. Further differentiation should be done through the 'model' property in my opinion. This is optional in the OpenFirmware spec, but that does not mean it should be important. It is currently defined as something to determine the exact model of a chip in order to enable quirks, bugfixes and suchlike, but most implementations switch on something else entirely (like SVR or a heuristic behaviour). Selecting the model would be no different to, for example, having a list of PCI IDs that will work with a driver. Basically, I envision that instead device trees should be a little more verbose, and that OF device probing should be improved so that drivers can hook in on many levels of matching. There was a little discussion at bplan once that it would be easier to implement a kind of vendor/device id system much like PCI, USB etc. implements in hardware in order to match hardware. I suppose you could use a class property to implement this - but for instance in the case of USB or PCI, this is already encoded in the device_type for anything the firmware cannot work out (pci1106,6062 or so). Perhaps it is a solution though; mark each device with a class property, for instance on the 5200B give it a unique chip ID (fsl5200 or soc5200?) and each unit a device id and take a big hint from PCI class codes and programming interfaces here - USB might be fsl5200,0c0310 (0c, 03 and 10 are all the PCI class, subclass and progif for USB OHCI). Additionally you can add more specific information such as the type of USB controller, for instance in the case of EHCI, perhaps also differentiate between EHCI with a companion controller, EHCI with a transaction translator and no companion controller, etc. with a further code - fsl520B,0c0320.01 References to peek at: http://www.openbios.org/data/docs/bus.usb.pdf http://www.openbios.org/data/docs/bus.pci.pdf Especially take a peek at the PCI docs, page 10 where Table 1: Generic Names based upon Class Code gives a bunch of really nice name/device_types. Note that none of this adds any further properties to the specification for identification - you can do it all using device_type and compatible. So, why not start up a registry of vendor, device and class-code numbers for SoC devices for when PCI numbering cannot adequately fill the gap? In this case, Freescale, IBM, AMCC and PASemi already have registered vendor codes, class-codes for 99% of interfaces can be derived from the PCI specifications? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4.3] FEC - fast ethernet controller for mpc52xx
On 10/29/07, Jeff Garzik [EMAIL PROTECTED] wrote: Domen Puncer wrote: drivers/net/Kconfig | 24 drivers/net/Makefile |4 drivers/net/fec_mpc52xx.c | 1112 ++ drivers/net/fec_mpc52xx.h | 313 +++ drivers/net/fec_mpc52xx_phy.c | 198 +++ 5 files changed, 1651 insertions(+) applied to #upstream-fixes it's not strictly a fix, but I did not want to hold this back until 2.6.25 either Fantastic! Thanks Jeff. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: boot/wrap assumes a biarch toolchain?
Jan Dittmer [EMAIL PROTECTED] writes: $ powerpc64-linux-gcc-4.0.4 -v Using built-in specs. Target: powerpc64-linux Configured with: ../configure --prefix=/usr/cc217 --exec-prefix=/usr/cc217/powerpc64 --target=powerpc64-linux --disable-shared --disable-werror --disable-nls --disable-threads --disable-werror --disable-libmudflap --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c Thread model: single gcc version 4.0.4 g5_defconfig: $ make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux- CROSS32_COMPILE=powerpc64-linux- Your compiler still needs -m32 to generate 32-bit code (or use --with-cpu=default32 to make that the default). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
On 10/29/07, Marian Balakowicz [EMAIL PROTECTED] wrote: David Gibson wrote: On Thu, Oct 25, 2007 at 05:46:19PM +0200, Marian Balakowicz wrote: Grant Likely wrote: On 10/25/07, Martin Krause [EMAIL PROTECTED] wrote: [snip] On a board with 16 MiB FLASH for example the big-fs _and_ the misc partition could not be used. big-fs, because the memory is too small (which is OK) and misc, because it overlaps 1 MiB over the physikal flash border. So only the first 9 MiB of the flash could be used in Linux. The remaining 7 MiB couldn't be accessed. Perhaps it would be better to drop the flash layout from the in-kernel dts files entirely since flash layout can be a fluid thing. Well, but that would not be really user friendly, I'd rather stick with some default config. Strictly speaking the device-tree is not the right place for flash partitioning information. We put it there because it's preferable to having hardcoded per-board flash layouts in the code itself. It only really works well, though, when there are strong conventions (shared with the firmware) about how to partition the flash. Where it's really up to the user to determine how they want to lay out their flash, putting things in the device tree isn't a really good idea. In principle, you are right, we should not be putting a user dependent configuration into .dts files. But on the other hand, bindings have been defined for flash-like devices and their partition layouts and physmap_of device driver is expecting to get this information from the blob. So, it is the place for it. But if we are not to put partition layouts into the default kernel .dts files then we should provide/maintain some examples an that may be a even bigger mess. Incidentally, it's not required that *all* the flash address space be in partitions, so it is possible only give partitions for those flash chunks which the firmware needs to know about. That might be nicer solution but different variants of TQM5200 boards do not share the same subset of partitions (default u-boot partitions at least), so it will not help much. It's probably more appropriate to have the flash partition layout in the u-boot environment and have u-boot populate the partition information in the device tree. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC] Fix off-by-one error in setting decrementer on Book E
Hello.
Paul Mackerras wrote:
The decrementer in Book E and 4xx processors interrupts on the
transition from 1 to 0, rather than on the 0 to -1 transition as on
64-bit server and 32-bit classic (6xx/7xx/7xxx) processors.
This fixes the problem by making set_dec subtract 1 from the count for
server and classic processors. Since set_dec already had a bunch of
ifdefs to handle different processor types, there is no net increase
in ugliness. :)
This also removes a redundant call to set the decrementer to
0x7fff - it was already set to that earlier in timer_interrupt.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
Heh, I have alike patch but refrained from posting being busy with other
stuff and nt having any PPC target at hand... so, I'm late as usual
---
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 9eb3284..5e253d6 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -586,7 +586,7 @@ void timer_interrupt(struct pt_regs * regs)
/* not time for this event yet */
now = per_cpu(decrementer_next_tb, cpu) - now;
if (now = DECREMENTER_MAX)
- set_dec((unsigned int)now - 1);
+ set_dec((int)now);
return;
}
old_regs = set_irq_regs(regs);
@@ -601,10 +601,8 @@ void timer_interrupt(struct pt_regs * regs)
if (evt-event_handler)
evt-event_handler(evt);
- else
- evt-set_next_event(DECREMENTER_MAX, evt);
#ifdef CONFIG_PPC_ISERIES
if (firmware_has_feature(FW_FEATURE_ISERIES) hvlpevent_is_pending())
@@ -826,9 +824,6 @@ static int decrementer_set_next_event(unsigned long evt,
struct clock_event_device *dev)
{
__get_cpu_var(decrementer_next_tb) = get_tb_or_rtc() + evt;
- /* The decrementer interrupts on the 0 - -1 transition */
- if (evt)
- --evt;
set_dec(evt);
return 0;
}
diff --git a/include/asm-powerpc/time.h b/include/asm-powerpc/time.h
index f058955..eed64bd 100644
--- a/include/asm-powerpc/time.h
+++ b/include/asm-powerpc/time.h
@@ -183,6 +183,7 @@ static inline void set_dec(int val)
#elif defined(CONFIG_8xx_CPU6)
set_dec_cpu6(val);
#else
+ --val; /* classic decrementer interrupts when dec goes negative */
I got an impression that set_dec_cpu6() needs the decremented val as well.
Plus for iSeries compiler will complain for iSeries about cur_dec being
declared after val-- statement, C++ style. How about such variant (and the
same for asm-ppc/time.h)?
Index: powerpc/include/asm-powerpc/time.h
===
--- powerpc.orig/include/asm-powerpc/time.h
+++ powerpc/include/asm-powerpc/time.h
@@ -178,16 +178,24 @@ static inline unsigned int get_dec(void)
static inline void set_dec(int val)
{
+ /*
+* The classic decrementer interrupts at 0 to -1 transition, while
+* 40x and book E decrementers interrupt at 1 to 0 transition.
+*/
#if defined(CONFIG_40x)
mtspr(SPRN_PIT, val);
-#elif defined(CONFIG_8xx_CPU6)
+#else
+#if !defined(CONFIG_BOOKE)
+ val = val ? val - 1 : 0;
+#endif
+#if defined(CONFIG_8xx_CPU6)
set_dec_cpu6(val);
-#ifdef CONFIG_PPC_ISERIES
- int cur_dec;
-
+#if defined(CONFIG_PPC_ISERIES)
if (firmware_has_feature(FW_FEATURE_ISERIES)
- get_lppaca()-shared_proc) {
+ get_lppaca()-shared_proc) {
+ int cur_dec;
+
get_lppaca()-virtual_decr = val;
cur_dec = get_dec();
if (cur_dec val)
@@ -195,7 +203,8 @@ static inline void set_dec(int val)
} else
#endif
mtspr(SPRN_DEC, val);
-#endif /* not 40x or 8xx_CPU6 */
+#endif /* not 8xx_CPU6 */
+#endif /* not 40x */
}
static inline unsigned long tb_ticks_since(unsigned long tstamp)
WBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new class property?
Scott wrote: Personally, I'm fine with just using name and compatible, but others such as Stuart have expressed a desire for something to formally indicate compliance with a standard binding. I don't think we should expand the use of device_type in any case. I agree that the existing compatible property is sufficient to do what Stuart wants. All that is required is to define some standard bindings and give them well-known names for the compatible property. If needed, we could define a prefix that indicates that a compatible entry refers to a standards-compliant binding. For example, standard,network, or standard,display. I don't see the benefit of creating a new property similar to device_type. -Dale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [Powerpc V2] fix switch_slb handling of 1T ESID values
[Powerpc V2] fix switch_slb handling of 1T ESID values
Now that we have 1TB segment size support, we need to be using the
GET_ESID_1T macro when comparing ESID values for pc,stack, and
unmapped_base within switch_slb().A new helper function called
esids_match() contains the logic for deciding when to call GET_ESID
and GET_ESID_1T.
This also happens to fix a duplicate-slb-entry inspired machine-check
exception I was seeing when trying to run java on a power6 partition.
Tested on power6 and power5.
Signed-Off-By: Will Schmidt [EMAIL PROTECTED]
---
arch/powerpc/mm/slb.c | 33 ++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index bbd2c51..152f4cd 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -148,6 +148,34 @@ void slb_vmalloc_update(void)
slb_flush_and_rebolt();
}
+/* Helper function to compare esids. There are four cases to handle.
+ * 1. The system is not 1T segment size capable. Use the GET_ESID compare.
+ * 2. The system is 1T capable, both addresses are 1T, use the GET_ESID
compare.
+ * 3. The system is 1T capable, only one of the two addresses is 1T. This
is not a match.
+ * 4. The system is 1T capable, both addresses are 1T, use the GET_ESID_1T
macro to compare.
+ */
+static inline int esids_match(unsigned long addr1, unsigned long addr2)
+{
+ int esid_1t_count;
+
+ /* System is not 1T segment size capable. */
+ if (!cpu_has_feature(CPU_FTR_1T_SEGMENT))
+ return (GET_ESID(addr1) == GET_ESID(addr2));
+
+ esid_1t_count = (((addr1SID_SHIFT_1T)!=0) +
((addr2SID_SHIFT_1T)!=0));
+
+ /* both addresses are 1T */
+ if (esid_1t_count == 0)
+ return (GET_ESID(addr1) == GET_ESID(addr2));
+
+ /* One address 1T, the other 1T. Not a match */
+ if (esid_1t_count == 1)
+ return 0;
+
+ /* Both addresses are 1T. */
+ return (GET_ESID_1T(addr1) == GET_ESID_1T(addr2));
+}
+
/* Flush all user entries from the segment table of the current processor. */
void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
{
@@ -193,15 +221,14 @@ void switch_slb(struct task_struct *tsk, struct mm_struct
*mm)
return;
slb_allocate(pc);
- if (GET_ESID(pc) == GET_ESID(stack))
+ if (esids_match(pc,stack))
return;
if (is_kernel_addr(stack))
return;
slb_allocate(stack);
- if ((GET_ESID(pc) == GET_ESID(unmapped_base))
- || (GET_ESID(stack) == GET_ESID(unmapped_base)))
+ if (esids_match(pc,unmapped_base) || esids_match(stack,unmapped_base))
return;
if (is_kernel_addr(unmapped_base))
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new class property?
Scott Wood wrote: On Mon, Oct 29, 2007 at 03:20:56PM +, Matt Sealey wrote: I think device_type, compatible and model properties fulfil this already, they simply aren't being used correctly. device_type has a few drawbacks, though: 1. You can only specify one type, whereas with a new property we could define it as a list (similar to compatible). This is the whole point; device_type and compatible are companion properties. You specify the exact thing in device_type and give it a list of compatible device_types in compatible. 2. We want to avoid any confusion with OF bindings and abused device_type entries that have been allowed to become existing practice. Creating whole new device type bindings that are not OF standards, which puts OF vendors at a sort of impass; do they comply to the Open Firmware standard or use the Linux Standard? Flat device trees are already somewhat of a strange beast, it is probably best not to make them much stranger. 3. It's the only standard property (AFAIK) with an underscore in it. :-) Petty :D For readability, the name of the device needn't match device_type; for instance on the 5121E it may be that the 'diu' unit be called diu, but be of device_type 'display' I don't think that's more readable than setting the name to display. Something containing diu will be in the compatible list. It at least makes the device tree far more human readable. Name and Device Type are not required to be the same thing. A name is just a human readable marker, device_type is what drivers need to match on. While name is derived from device_type on creation of a device (after all a display is a display), giving it a human readable name is sometimes a boon. Remember that Open Firmware is not just a text file you compile with U-Boot - the console you get on boot needs to be useful to users too. In that sense, 8 USB controllers with names [EMAIL PROTECTED], [EMAIL PROTECTED] going upwards to infinity is not the greatest thing in the world. Selecting the model would be no different to, for example, having a list of PCI IDs that will work with a driver. It's what we currently do with compatible. Why break it into two properties? Because encoding human-readable descriptions of devices in the compatible property is ridiculously long-winded. Currently it's being terribly misused, in my opinion (USB especially, there is no need to tell that it is compatible with mpc5200b-usb, USB is a well-defined standard with 3 possible host controllers, encoding the specific SoC into it is going way overboard) No, you should use compatible for that. No, that goes in name/compatible according to the OF PCI binding. This is absolutely contrary to your own request for comments; you want to implement a new class property, but.. you can use device_type and compatible for it, as is evident everywhere and in two already existing bus bindings. If you need more information in the device tree for each device, I simply recommend we take a hint from the PCI and USB bindings and add properties of the same names and descriptions (why create new standards when old ones work fine). Perhaps it is a solution though; mark each device with a class property, for instance on the 5200B give it a unique chip ID (fsl5200 or soc5200?) No. That's precisely the sort of device_type abuse we want to get away from with class. It is not an abuse to give a device_type by some very easily matchable device type. Personally, I'm fine with just using name and compatible, but others such as Stuart have expressed a desire for something to formally indicate compliance with a standard binding. I don't think we should expand the use of device_type in any case. You can formally indicate compliance with a standard binding by using the standard bindings.. be they the USB or PCI standard, be your device not on USB or PCI, they already exist, and already do what Stuart asks. For devices which do not have a standard binding you run into a problem; who arbitrates what class goes where? Reusing vendor codes from PCI and USB, class codes from PCI and USB, and implementing a few 'non-standard others' is far more efficient as there is plenty of code in the Linux tree for parsing and collecting this data. It is not so far a leap to go from parsing pci or usb device_types to collecting fsl or soc data and a selection of appended codes. Therefore, if there is not a standard binding that gives it a neat name (i2c would be a good example), I suggest following the route of PCI and USB, and encoding that specific device as a set of matchable codes, rather than a list of strings. soc5121,0c0320 matches a device exactly where usb particularly does not. As with the specification for PCI where such a device may not have a particular device_type name (not a good example with USB) simply prefix with the bus type, then vendor code, device code, class code etc. gives you an identical match. Why not; chickenlittle
[PATCH 0/3] Add device-tree aware NDFC driver
This adds a device-tree aware PowerPC 44x NanD Flash Controller driver The code is based on the original NDFC driver by Thomas Gleixner, but since it's been changed much and has initialization/clean-up completely reworked it's been put into a separate ndfc_of.c file. This version supports both separate mtd devices on each chip attached to NDFC banks and single mtd device spread across identical chips (not using mtdconcat) as well. The choice is selected with device tree settings. This has been tested on PowerPC 440EPx Sequoia board. Any comments are greatly appreciated. Thanks, Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new class property?
Matt Sealey wrote: Scott Wood wrote: On Mon, Oct 29, 2007 at 03:20:56PM +, Matt Sealey wrote: I think device_type, compatible and model properties fulfil this already, they simply aren't being used correctly. device_type has a few drawbacks, though: 1. You can only specify one type, whereas with a new property we could define it as a list (similar to compatible). This is the whole point; device_type and compatible are companion properties. You specify the exact thing in device_type and give it a list of compatible device_types in compatible. That sounds more like a description of model, or the original use of name, than device_type. 2. We want to avoid any confusion with OF bindings and abused device_type entries that have been allowed to become existing practice. Creating whole new device type bindings that are not OF standards, which puts OF vendors at a sort of impass; do they comply to the Open Firmware standard or use the Linux Standard? We try to stay compatible with OF when practical; however, we have no choice if an OF device_type implies a method interface that we cannot provide. For readability, the name of the device needn't match device_type; for instance on the 5121E it may be that the 'diu' unit be called diu, but be of device_type 'display' I don't think that's more readable than setting the name to display. Something containing diu will be in the compatible list. It at least makes the device tree far more human readable. Unless you're familiar with the hardware, diu is likely to be a meaningless acronym. display is obvious, and much more human-friendly. While name is derived from device_type on creation of a device (after all a display is a display), giving it a human readable name is sometimes a boon. name generally comes from the generic names document, not device_type. Remember that Open Firmware is not just a text file you compile with U-Boot - the console you get on boot needs to be useful to users too. In that sense, 8 USB controllers with names [EMAIL PROTECTED], [EMAIL PROTECTED] going upwards to infinity is not the greatest thing in the world. And the alternative is? Selecting the model would be no different to, for example, having a list of PCI IDs that will work with a driver. It's what we currently do with compatible. Why break it into two properties? Because encoding human-readable descriptions of devices in the compatible property is ridiculously long-winded. Putting something human readable in model is fine. It's not a reason to force drivers to care about it by failing to include a highly specific entry in the compatible list. Currently it's being terribly misused, in my opinion (USB especially, there is no need to tell that it is compatible with mpc5200b-usb, USB is a well-defined standard with 3 possible host controllers, encoding the specific SoC into it is going way overboard) Well, there are various non-standard registers also present on many embedded USB controllers. No, you should use compatible for that. No, that goes in name/compatible according to the OF PCI binding. This is absolutely contrary to your own request for comments; you want to implement a new class property, but.. you can use device_type and compatible for it, as is evident everywhere and in two already existing bus bindings. It was Stuart's RFC, not mine. :-) What I originally proposed was deprecating device_type, and using name and compatible. Stuart wanted something to indicate formal adherence to a standard binding, so I suggested class if such a thing is really needed. You seem to be confusing name and device_type, BTW. Perhaps it is a solution though; mark each device with a class property, for instance on the 5200B give it a unique chip ID (fsl5200 or soc5200?) No. That's precisely the sort of device_type abuse we want to get away from with class. It is not an abuse to give a device_type by some very easily matchable device type. That's not a device type, it's a device. For devices which do not have a standard binding you run into a problem; who arbitrates what class goes where? The issue that brought all this up was new bindings for device classes that OF doesn't have bindings for. Reusing vendor codes from PCI and USB, OF already specifies OUI numbers for this, why be different? We use things like ibm and fsl for common, unambiguous vendors for readability sake. class codes from PCI and USB, What do we need the class codes for? and implementing a few 'non-standard others' is far more efficient as there is plenty of code in the Linux tree for parsing and collecting this data. I highly doubt there's any code in Linux that wants a PCI or USB class ID for something that isn't a PCI or USB device. It is not so far a leap to go from parsing pci or usb device_types name/compatible, not device_type. Please actually read the PCI binding. And you
Re: RFC: replace device_type with new class property?
Dale Farnsworth wrote: Scott wrote: Personally, I'm fine with just using name and compatible, but others such as Stuart have expressed a desire for something to formally indicate compliance with a standard binding. I don't think we should expand the use of device_type in any case. I agree that the existing compatible property is sufficient to do what Stuart wants. All that is required is to define some standard bindings and give them well-known names for the compatible property. If needed, we could define a prefix that indicates that a compatible entry refers to a standards-compliant binding. For example, standard,network, or standard,display. I don't see the benefit of creating a new property similar to device_type. I don't see how this makes anything any better. Under Open Firmware, if device_type is display, then it had better act as a display through the client interface, interpose it's framebuffer methods properly and suchlike. In FDT, what is the purpose of the binding but to report devices? It does not really define any interface whatsoever. Having it conform to a standards-compliant binding by reporting standard,display goes in the direction of ignoring the simple fact that most displays act and are programmed very differently (with the glorious exception of potentially giving it a compatible of vga - on PCI this is handled very easily by the PCI class code! Which was exactly my point..). I would say the same for USB, where standard,usb would be really glossing over the simple fact that *all usb controllers should by default be created equal*. OHCI does not act any different, and UHCI doesn't act any different, in the specification. If the chip does weird things, you do not go around revoking it's status as an OHCI controller, do you? As an addendum to Scott's other mail I came up with a good reason to give users readable names but standard device_types. Consider 802.11g, which may have a name of wifi but since it is a network adapter, have device_type ethernet. It is ethernet after all, but users would like to know which it is compared with the onboard ethernet, given a list of devices on the OF console, without knowing the base addresses of registers. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] PowerPC: 44x NanD Flash Controller (NDFC) bindings
PowerPC 44x NanD Flash Controller (NDFC) bindings.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt | 64 +++
1 files changed, 64 insertions(+)
--- linux-2.6.orig/Documentation/powerpc/booting-without-of.txt 2007-10-29
16:02:07.0 +0300
+++ linux-2.6/Documentation/powerpc/booting-without-of.txt 2007-10-29
21:34:14.0 +0300
@@ -52,6 +52,7 @@ Table of Contents
i) Freescale QUICC Engine module (QE)
j) CFI or JEDEC memory-mapped NOR flash
k) Global Utilities Block
+ l) 44x NanD Flash Controller (NDFC)
VII - Specifying interrupt information for devices
1) interrupts property
@@ -2242,6 +2243,69 @@ platforms are moved over to use the flat
available.
For Axon: 0x012a
+ l) 44x NanD Flash Controller (NDFC)
+
+ Required properties:
+ - compatible : should be ibm,ndfc.
+ - reg : should contain address and length of the NDFC registers.
+
+ ndfc node should contain at least one ndfc-mtd sub-node describing
+ chip properties and bank settings for the chip(s) attached to particular
+ ndfc bank(s).
+
+ Required ndfc-mtd properties:
+ - bank-map : at least one value (less than number of NDFC banks available)
+identifying bank number the chip is attached to. If we have several
+identical chips and want to spread a single mtd device across all of them,
+we need to specify here the bank numbers the chips are attached to.
+E.g. bank-map = 0 3; means a single mtd device will be created
+for 2 identical NAND chips attached to banks 0 and 3 of the NDFC.
+ Optional ndfc-mtd properties:
+ - chip-options : NAND chip options.
+ - chip-delay : NAND chip delay. Default is 50us.
+ - bank-settings : NDFC bank settings for the chip(s). This value is
+written to the NDFC Bank Configuration Register.
+If not specified, the default timings (RR=RWH=RWP=CRW=2) and
+bank width from the bank-width property will be used for the chip.
+ - bank-width : NAND chip bus width. Should be 1 for 8-bit NAND or
+2 for 16-bit NAND. By default an 8-bit width is set.
+ - #address-cells, #size-cells : Must be present if the flash has
+sub-nodes representing partitions (see below). In this case
+both #address-cells and #size-cells must be equal to 1.
+
+ ndfc_mtd can have partition sub-nodes, which are described the same way
+ as for the CFI or JEDEC memory-mapped NOR flash.
+
+ Example (Sequoia 440EPx):
+ NDFC is relocatable within EBC and should have EBC as a parent node.
+ Here we have NDFC on EBC CS3 bank and one NAND chip attached to bank 3
+ of the NanD Flash Controller:
+
+ [EMAIL PROTECTED],0 {
+ compatible = ibm,ndfc-440epx, ibm,ndfc;
+ reg = 3 00 2000;
+ ndfc-mtd0 {
+ bank-settings = 8000;
+ bank-map = 3;
+ chip-delay = 32;
+ #address-cells = 1;
+ #size-cells = 1;
+ [EMAIL PROTECTED] {
+ label = u-boot-nand;
+ reg = 0 008;
+ };
+ [EMAIL PROTECTED] {
+ label = kernel-nand;
+ reg = 008 018;
+ };
+ [EMAIL PROTECTED] {
+ label = filesystem;
+ reg = 020 1e0;
+ };
+ };
+ };
+
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] PowerPC: NDFC entry for 440EPx Sequoia DTS
NDFC DTS entry for PowerPC 440EPx Sequoia board.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/sequoia.dts | 23 +++
1 files changed, 23 insertions(+)
diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts
linux-2.6/arch/powerpc/boot/dts/sequoia.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts2007-10-29
16:02:11.0 +0300
+++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts 2007-10-29 18:59:11.0
+0300
@@ -141,6 +141,29 @@
interrupts = 5 1;
interrupt-parent = UIC1;
+ [EMAIL PROTECTED],0 {
+ compatible = ibm,ndfc-440epx,
ibm,ndfc;
+ reg = 3 00 2000;
+ ndfc-mtd0 {
+ bank-settings = 8000;
+ bank-map = 3;
+ chip-delay = 32;
+ #address-cells = 1;
+ #size-cells = 1;
+ [EMAIL PROTECTED] {
+ label = u-boot-nand;
+ reg = 0 008;
+ };
+ [EMAIL PROTECTED] {
+ label = kernel-nand;
+ reg = 008 018;
+ };
+ [EMAIL PROTECTED] {
+ label = filesystem;
+ reg = 020 1e0;
+ };
+ };
+ };
[EMAIL PROTECTED],0 {
compatible = amd,s29gl256n,
cfi-flash;
bank-width = 2;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] PowerPC: Add device-tree aware PowerPC 44x NDFC driver
This adds support of the built-in PowerPC 44x NanD Flash Controller (NDFC)
based on the OF description. This version supports both separate mtd devices on
each NDFC bank and mtd devices spread across identical chips attached to NDFC
banks depending on the device tree settings. This is based on the original NDFC
driver by Thomas Gleixner, but since a lot of things have been reworked it's
been put to a separate ndfc_of file.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
drivers/mtd/nand/Kconfig |7
drivers/mtd/nand/Makefile |1
drivers/mtd/nand/ndfc_of.c | 599 +
include/linux/mtd/ndfc.h |4
4 files changed, 611 insertions(+)
diff -pruN linux-2.6.orig/drivers/mtd/nand/Kconfig
linux-2.6/drivers/mtd/nand/Kconfig
--- linux-2.6.orig/drivers/mtd/nand/Kconfig 2007-10-29 16:02:37.0
+0300
+++ linux-2.6/drivers/mtd/nand/Kconfig 2007-10-29 19:02:13.0 +0300
@@ -158,6 +158,13 @@ config MTD_NAND_NDFC
help
NDFC Nand Flash Controllers are integrated in IBM/AMCC's 4xx SoCs
+config MTD_NAND_NDFC_OF
+ tristate NDFC NanD Flash Controller based on OF
+ depends on 44x PPC_MERGE
+ select MTD_NAND_ECC_SMC
+ help
+NDFC Nand Flash Controllers are integrated in EP44x SoCs
+
config MTD_NAND_S3C2410_CLKSTOP
bool S3C2410 NAND IDLE clock stop
depends on MTD_NAND_S3C2410
diff -pruN linux-2.6.orig/drivers/mtd/nand/Makefile
linux-2.6/drivers/mtd/nand/Makefile
--- linux-2.6.orig/drivers/mtd/nand/Makefile2007-10-29 16:02:37.0
+0300
+++ linux-2.6/drivers/mtd/nand/Makefile 2007-10-29 18:59:11.0 +0300
@@ -24,6 +24,7 @@ obj-$(CONFIG_MTD_NAND_TS7250) += ts7250
obj-$(CONFIG_MTD_NAND_NANDSIM) += nandsim.o
obj-$(CONFIG_MTD_NAND_CS553X) += cs553x_nand.o
obj-$(CONFIG_MTD_NAND_NDFC)+= ndfc.o
+obj-$(CONFIG_MTD_NAND_NDFC_OF) += ndfc_of.o
obj-$(CONFIG_MTD_NAND_AT91)+= at91_nand.o
obj-$(CONFIG_MTD_NAND_CM_X270) += cmx270_nand.o
obj-$(CONFIG_MTD_NAND_BASLER_EXCITE) += excite_nandflash.o
diff -pruN linux-2.6.orig/drivers/mtd/nand/ndfc_of.c
linux-2.6/drivers/mtd/nand/ndfc_of.c
--- linux-2.6.orig/drivers/mtd/nand/ndfc_of.c 1970-01-01 03:00:00.0
+0300
+++ linux-2.6/drivers/mtd/nand/ndfc_of.c2007-10-29 22:07:45.0
+0300
@@ -0,0 +1,598 @@
+/*
+ * Overview:
+ * Platform independend driver for NDFC (NanD Flash Controller)
+ * integrated into EP440 cores with OF device tree support
+ *
+ * Based on the original ndfc driver by Thomas Gleixner
+ *
+ * Copyright 2006 IBM
+ *
+ * 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/module.h
+#include linux/mtd/nand.h
+#include linux/mtd/nand_ecc.h
+#include linux/mtd/partitions.h
+#include linux/mtd/ndfc.h
+#include linux/mtd/mtd.h
+#include linux/of.h
+#include linux/of_platform.h
+
+#include asm/io.h
+
+
+struct of_ndfc {
+ __iomem void*base;
+ struct resource *res;
+ uint32_tbank_mask;
+ struct nand_hw_control control;
+ struct list_headlist;
+};
+
+struct of_ndfc_mtd {
+ struct list_headlist;
+ struct of_ndfc *ndfc;
+ unsigned char banks[NDFC_MAX_BANKS];
+ unsignedchip_cnt;
+ struct nand_chipchip;
+ struct mtd_info mtd;
+#ifdef CONFIG_MTD_PARTITIONS
+ struct mtd_partition*parts;
+#endif
+};
+
+static inline u32 ndfc_raw_readl(struct of_ndfc *ndfc, u32 off)
+{
+ return __raw_readl(ndfc-base + off);
+}
+
+static inline void ndfc_raw_writel(struct of_ndfc *ndfc, u32 off, u32 val)
+{
+ __raw_writel(val, ndfc-base + off);
+}
+
+static inline void ndfc_writel(struct of_ndfc *ndfc, u32 off, u32 val)
+{
+ writel(val, ndfc-base + off);
+}
+
+static void ndfc_select_chip(struct mtd_info *mtd, int chip)
+{
+ struct nand_chip *this = mtd-priv;
+ struct of_ndfc_mtd *ndfc_mtd = this-priv;
+ struct of_ndfc *ndfc = ndfc_mtd-ndfc;
+ uint32_t ccr;
+
+ ccr = ndfc_raw_readl(ndfc, NDFC_CCR);
+ if ((chip = 0) (chip ndfc_mtd-chip_cnt)) {
+ ccr = ~NDFC_CCR_BS_MASK;
+ ccr |= NDFC_CCR_BS(ndfc_mtd-banks[chip]);
+ } else
+ ccr |= NDFC_CCR_RESET_CE;
+ ndfc_raw_writel(ndfc, NDFC_CCR, ccr);
+}
+
+static void ndfc_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
+{
+ struct nand_chip *this = mtd-priv;
+ struct of_ndfc_mtd *ndfc_mtd = this-priv;
+ struct of_ndfc *ndfc = ndfc_mtd-ndfc;
+
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ if (ctrl NAND_CLE)
+
[PATCH] [Powerpc] include udbg.h when using udbg_printf
[Powerpc] include udbg.h when using udbg_printf this fixes the error error: implicit declaration of function ‘udbg_printf’ We have a few spots where we reference udbg_printf() without #including udbg.h. These are within #ifdef DEBUG blocks, so unnoticed until we do a #define DEBUG or #define DEBUG_LOW nearby. Signed-Off-By: Will Schmidt [EMAIL PROTECTED] --- arch/powerpc/mm/hash_utils_64.c |1 + arch/powerpc/mm/slb.c |1 + arch/powerpc/platforms/cell/smp.c |1 + arch/powerpc/platforms/pseries/firmware.c |1 + 4 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c index c78dc91..94b8ca0 100644 --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -51,6 +51,7 @@ #include asm/cputable.h #include asm/sections.h #include asm/spu.h +#include asm/udbg.h #ifdef DEBUG #define DBG(fmt...) udbg_printf(fmt) diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c index bbd2c51..637afb2 100644 --- a/arch/powerpc/mm/slb.c +++ b/arch/powerpc/mm/slb.c @@ -25,6 +25,7 @@ #include asm/smp.h #include asm/firmware.h #include linux/compiler.h +#include asm/udbg.h #ifdef DEBUG #define DBG(fmt...) udbg_printf(fmt) diff --git a/arch/powerpc/platforms/cell/smp.c b/arch/powerpc/platforms/cell/smp.c index 1c0acba..e443845 100644 --- a/arch/powerpc/platforms/cell/smp.c +++ b/arch/powerpc/platforms/cell/smp.c @@ -44,6 +44,7 @@ #include asm/rtas.h #include interrupt.h +#include asm/udbg.h #ifdef DEBUG #define DBG(fmt...) udbg_printf(fmt) diff --git a/arch/powerpc/platforms/pseries/firmware.c b/arch/powerpc/platforms/pseries/firmware.c index 8b18a1c..b765b7c 100644 --- a/arch/powerpc/platforms/pseries/firmware.c +++ b/arch/powerpc/platforms/pseries/firmware.c @@ -25,6 +25,7 @@ #include asm/firmware.h #include asm/prom.h +#include asm/udbg.h #ifdef DEBUG #define DBG(fmt...) udbg_printf(fmt) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new class property?
Matt Sealey wrote: I don't see how this makes anything any better. Under Open Firmware, if device_type is display, then it had better act as a display through the client interface, interpose it's framebuffer methods properly and suchlike. In FDT, what is the purpose of the binding but to report devices? It does not really define any interface whatsoever. Having it conform to a standards-compliant binding by reporting standard,display goes in the direction of ignoring the simple fact that most displays act and are programmed very differently In that case, it probably make sense to simply not have a binding for displays. I would say the same for USB, where standard,usb would be really glossing over the simple fact that *all usb controllers should by default be created equal*. OHCI does not act any different, and UHCI doesn't act any different, in the specification. If the chip does weird things, you do not go around revoking it's status as an OHCI controller, do you? If its weird things are sufficiently non-OHCI, yes. :-) Good luck fitting a CPM USB controller into some *HCI designation. As an addendum to Scott's other mail I came up with a good reason to give users readable names but standard device_types. Consider 802.11g, which may have a name of wifi This is reasonable. but since it is a network adapter, have device_type ethernet. This is acceptable as existing practice, but standard,ethernet would be just fine. And there may be additional properties defined for wireless devices, and an additional standard,wifi binding could be added. You can't have multiple device_types. It is ethernet after all, but users would like to know which it is compared with the onboard ethernet, given a list of devices on the OF console, without knowing the base addresses of registers. My preferred solution to this particular problem is a label property, that can go beyond ethernet/wifi and say things like front panel ethernet, back panel ethernet A, back panel ethernet B, wireless, etc., without taking away name's existing use, and without limiting the label to the characters allowed in a node name. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new class property?
Here's an example of what I'm trying to get at-- take
a node from a FSL device tree. The ideas I've heard
for expressing the class are like this--
#1 don't express any class at all:
[EMAIL PROTECTED] {
compatible = fsl,ucc_geth;
model = UCC;
device-id = 3;
reg = 2200 200;
interrupts = 22;
interrupt-parent = qeic ;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = 19;
tx-clock = 1a;
phy-handle = phy3 ;
pio-handle = pio3 ;
This is bad IMHO because the human reader has to
infer the class of device. Can the human reader
tell if it implements a standardized binding or
not??
#2 use device_type
[EMAIL PROTECTED] {
device_type = network;
compatible = fsl,ucc_geth;
model = UCC;
device-id = 3;
reg = 2200 200;
interrupts = 22;
interrupt-parent = qeic ;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = 19;
tx-clock = 1a;
phy-handle = phy3 ;
pio-handle = pio3 ;
};
This is better...I can tell it implments the network
binding. The problem is the past abuse and OF
connotations.
#3 use a new class property
[EMAIL PROTECTED] {
class = network;
compatible = fsl,ucc_geth;
model = UCC;
device-id = 3;
reg = 2200 200;
interrupts = 22;
interrupt-parent = qeic ;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = 19;
tx-clock = 1a;
phy-handle = phy3 ;
pio-handle = pio3 ;
};
This is good...I can tell it implments the network
binding. There is no association with the abused
OF device_type.
#4 use compatible
[EMAIL PROTECTED] {
compatible = fsl,ucc_geth,[official spec],network;
model = UCC;
device-id = 3;
reg = 2200 200;
interrupts = 22;
interrupt-parent = qeic ;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = 19;
tx-clock = 1a;
phy-handle = phy3 ;
pio-handle = pio3 ;
};
I don't like this...we are overloading compatible with
stuff that is not specifying a programming interface. compatible
is supposed to be specifying a programming interface which
the device complies to.
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] MTD: small physmap_of partition parsing fixes
Use of_get_next_child for proper ref counting as suggested by Stephen Rothwell
and remove add_mtd_partitions from parse_partitions to avoid duplicate
mtd device registration for RedBoot partitions.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
drivers/mtd/maps/physmap_of.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff -pruN linux-2.6.orig/drivers/mtd/maps/physmap_of.c
linux-2.6/drivers/mtd/maps/physmap_of.c
--- linux-2.6.orig/drivers/mtd/maps/physmap_of.c2007-10-29
16:02:37.0 +0300
+++ linux-2.6/drivers/mtd/maps/physmap_of.c 2007-10-29 22:41:08.0
+0300
@@ -94,14 +94,13 @@ static int __devinit parse_partitions(st
* line, these take precedence over device tree information */
nr_parts = parse_mtd_partitions(info-mtd, part_probe_types,
info-parts, 0);
- if (nr_parts 0) {
- add_mtd_partitions(info-mtd, info-parts, nr_parts);
- return 0;
- }
+ if (nr_parts 0)
+ return nr_parts;
/* First count the subnodes */
nr_parts = 0;
- for (pp = dp-child; pp; pp = pp-sibling)
+ for (pp = of_get_next_child(dp, NULL); pp;
+pp = of_get_next_child(dp, pp))
nr_parts++;
if (nr_parts == 0)
@@ -112,12 +111,14 @@ static int __devinit parse_partitions(st
if (!info-parts)
return -ENOMEM;
- for (pp = dp-child, i = 0; pp; pp = pp-sibling, i++) {
+ for (pp = of_get_next_child(dp, NULL), i = 0; pp;
+pp = of_get_next_child(dp, pp), i++) {
const u32 *reg;
int len;
reg = of_get_property(pp, reg, len);
if (!reg || (len != 2*sizeof(u32))) {
+ of_node_put(pp);
dev_err(dev-dev, Invalid 'reg' on %s\n,
dp-full_name);
kfree(info-parts);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new class property?
Yoder Stuart-B08248 wrote:
Here's an example of what I'm trying to get at-- take
a node from a FSL device tree. The ideas I've heard
for expressing the class are like this--
#1 don't express any class at all:
[EMAIL PROTECTED] {
compatible = fsl,ucc_geth;
model = UCC;
device-id = 3;
reg = 2200 200;
interrupts = 22;
interrupt-parent = qeic ;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = 19;
tx-clock = 1a;
phy-handle = phy3 ;
pio-handle = pio3 ;
Of course, this should properly be something like
[EMAIL PROTECTED] {
compatible = fsl,mpc8360-qe-enet, fsl,qe-enet;
local-mac-address = [ 00 00 00 00 00 00 ];
...
};
With no mac-address, and a more useful model if any at all.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5 v3] Porting RapidIO driver from ppc to powerpc architecture and adding memory mapped RapidIO driver.
Can anyone tell me what the status of these are? What kernel release are they targetted for? Currently I'm trying to work with 2.6.23 plus these patches locally. Cheers Phil On Thu, 2007-07-26 at 16:42 +0800, Zhang Wei wrote: These patches are the version 3 patches for RapidIO with dts update and some minor fixups. These patches are used for supporting RapidIO controllers of Freescale. I ported them from ppc architecture to powerpc architecture and added some new features, such as memory mapped driver. [PATCH 1/5] Add the explanation and sample of RapidIO DTS OF-node to the document of booting-without-of.txt file. [PATCH 2/5] Add RapidIO OF-node to MPC8641HPCN board dts file. [PATCH 3/5] Add the platform device support with RapidIO to MPC8641HPCN platform. [PATCH 4/5] Add RapidIO support to powerpc architecture. [PATCH 5/5] Add the memory management driver to RapidIO. Please see below descriptions of these patches: 1. Add the RapidIO driver of-device support. 2. Add the RapidIO driver support to MPC8641HPCN board. 3. Port the RapidIO from ppc to powerpc architecture. 4. Add Memory mapped RapidIO driver. 5. Add the support to multi master ports. 6. Add a simple bitmap RapidIO space allocator driver. 7. Change the RapidIO system size of menuconfig to automatically detection. Thanks! Best Regards, Zhang Wei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [powerpc] update xmon slb code
On Mon, Oct 29, 2007 at 02:59:27PM -0500, Will Schmidt wrote: [powerpc] update xmon slb code adds a bit more detail to the xmon SLB output. When the valid bit is set, This displays the ESID and VSID values, as well as decoding the segment size. (1T or 256M). This supresses the output for any slb entries that contain only zeros. I debated a bit on whether to check for just (valid) versus checking for (valid|esid|vsid). By inspection on power5, I do have SLB entries that contain values but without the valid bit set, so opted to display any non-zero values. Yeah, newer versions of the architecture specify that invalid entries must read as 0, while POWER5 doesn't. Printing them doesn't hurt. sample output from power6 (1T segment support): 00 c800 40004f7ca3000500 1T ESID=c0 VSID=40004f7ca3 01 d800 4000eb71b400 1T ESID=d0 VSID=4000eb71b0 24 cf000800 400011b26500 1T ESID=cf VSID=400011b260 25 04000800 4000a9e949000c80 1T ESID=4 VSID=4000a9e949 26 1800 5e93bfd49c80 256M ESID=1 VSID=5e93bfd49 27 0f000800 4000e262a4000c80 1T ESID=f VSID=4000e262a4 28 0800 5dd45172ec80 256M ESID=0 VSID=5dd45172e sample output from power5 (notice the non-valid but non-zero entries) 54 4800 cf33bb059c80 256M ESID=4 VSID=cf33bb059 55 1800 ccf56fe08c80 256M ESID=1 VSID=ccf56fe08 56 1000 dd82ce799c80 57 cf000800 d59aca40f500 256M ESID=cf000 VSID=d59aca40f 58 c0007800 45cb97751500 256M ESID=c0007 VSID=45cb97751 59 0400 61552db1bc80 Tested on power5 and power6. Nice, I like it! I wonder if it would make sense to (space) pad the ESID/VSID fields so they line up, it'd make output just a little tidier. (If you end up changing that, please also break the long printf lines in two.) Beside that it looks good to me! :) -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new class property?
On Mon, Oct 29, 2007 at 07:37:04AM -0700, Yoder Stuart-B08248 wrote: We've had some discussions internally here at Freescale among various PPC Linux developers about the device_type property and how 'classes' of devices should be represented in the device tree. Taking a long term view, the question I'd like to pose is how should classes of device should be identified in the flat device tree model? A device class, as I'm using it, refers basically to general categories of devices-- devices that share common properties. Examples in current device would be cpu, memory, pci, network, serial. Today the device_type property serves this purpose to some degree. However, the original meaning of device_type in Open Firmware is related to the method interface of a node it has a recent history of abuse in the Linux kernel DTS files, with a plethora of types made up in an ad hoc way. In addition, an OS can match on compatible and in the absence of method interfaces really doesn't need device_type anyway. However, one good thing about device_type (if properly used) is that it could identify which device nodes follow an official binding, vs proprietary devices or one-off device node definitions. Without something like device_type the _human_ reader of a DTS file has to infer from the name or compatible what the device type is. So, device class identifiers like memory, cpu, serial, pci, network provide that clarity. So, what should the long term approach be? Here are a couple of options: 1. Keep device_type, with it's use specifically defined to mean that the node with that property implements an 'official' binding. In the flat device tree model a binding is just a defined set of required (and optional properties. 2. Get rid of device_type and create a _new_ property like class. The only nodes permitted to have this property are those with 'official' bindings. These nodes would have a set of required (and optional) properties. The benefit of a new property is cutting all baggage associated with the old device_type property. I don't see how switching the property name from device_type to class is going to stop people from misunderstanding it's intended use. There's nothing inherently more understandable in calling it class -- it also invites people to make up their own class names as they go along, just as what happened to device_type. I also don't understand the people wanting to use compatible for _everything_. It's just mashing together two separate pieces of information into one property, and I seriously don't see how that helps anything or anyone. It's absolutely useless for a driver to be able to bind to a compatible field of standard,network or whatever it might be, since there's no way that standard, will imply that the register layout and programming model is somehow the same as all other standard-labelled devices. So yes, there is a problem with the device trees and how people build them, and it requires education on how to properly craft one. I don't think changing the layout to either be flatter (only using compatible), or changing names of a property (device_type-class) will help anything at all. I actually prefer keeping device_type myself, since it means existing OF-based device trees will already have some of the labels. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] powerpc: Pass PID argument to _tlbie (WAS: Apparent kernel bug with GDB on ppc405)
[adding back gdb list]
On Tue, Oct 30, 2007 at 07:35:06AM +1100, Benjamin Herrenschmidt wrote:
Did a boot test on my ebony board with this patch included. It seems
to be happy about things so far. If Matt gets around to trying this
out and it works, we should probably look at getting this into 2.6.24.
Oh, and I'd need a signed-off-by for it Ben :)
Sure, I'll send you a cleaned up version (the version I posted for test
breaks 64 bits builds :-)
But I'm also waiting for Matt to test first.
Ok, just backported the 405 bits of this to my client's sad sad MV
2.6.10 kernel and it appears to work fine. Only tricky bit was
context.id - context. So:
Tested-by: Matt Mackall [EMAIL PROTECTED]
And here's my backported patch, just for reference:
Index: k/arch/ppc/kernel/misc.S
===
--- k.orig/arch/ppc/kernel/misc.S 2007-10-29 15:33:03.0 -0500
+++ k/arch/ppc/kernel/misc.S2007-10-29 15:34:29.0 -0500
@@ -496,7 +496,13 @@ _GLOBAL(_tlbia)
*/
_GLOBAL(_tlbie)
#if defined(CONFIG_40x)
+ mfmsr r5
+ mfspr r6,SPRN_PID
+ wrteei 0
+ mtspr SPRN_PID,r4
tlbsx. r3, 0, r3
+ mtspr SPRN_PID,r6
+ wrtee r5
bne 10f
sync
/* There are only 64 TLB entries, so r3 64, which means bit 25 is
clear.
Index: k/arch/ppc/mm/fault.c
===
--- k.orig/arch/ppc/mm/fault.c 2007-10-29 15:30:04.0 -0500
+++ k/arch/ppc/mm/fault.c 2007-10-29 16:11:10.0 -0500
@@ -234,7 +234,7 @@ good_area:
set_bit(PG_arch_1, page-flags);
}
pte_update(ptep, 0, _PAGE_HWEXEC);
- _tlbie(address);
+ _tlbie(address, mm-context);
pte_unmap(ptep);
up_read(mm-mmap_sem);
ltt_ev_trap_exit();
Index: k/arch/ppc/mm/mmu_decl.h
===
--- k.orig/arch/ppc/mm/mmu_decl.h 2007-10-29 15:34:48.0 -0500
+++ k/arch/ppc/mm/mmu_decl.h2007-10-29 16:11:25.0 -0500
@@ -54,7 +54,7 @@ extern unsigned int num_tlbcam_entries;
#define mmu_mapin_ram()(0UL)
#elif defined(CONFIG_4xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(pid, va, pg)_tlbie(va, pid)
extern void MMU_init_hw(void);
extern unsigned long mmu_mapin_ram(void);
Index: k/include/asm-ppc/tlbflush.h
===
--- k.orig/include/asm-ppc/tlbflush.h 2007-10-29 15:31:29.0 -0500
+++ k/include/asm-ppc/tlbflush.h2007-10-29 16:11:32.0 -0500
@@ -13,7 +13,7 @@
#include linux/config.h
#include linux/mm.h
-extern void _tlbie(unsigned long address);
+extern void _tlbie(unsigned long address, unsigned int pid);
extern void _tlbia(void);
#if defined(CONFIG_4xx)
@@ -28,10 +28,10 @@ static inline void flush_tlb_mm(struct m
{ __tlbia(); }
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
- { _tlbie(vmaddr); }
+ { _tlbie(vmaddr, vma-vm_mm-context); }
static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
unsigned long vmaddr)
- { _tlbie(vmaddr); }
+ { _tlbie(vmaddr, vma-vm_mm-context); }
static inline void flush_tlb_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end)
{ __tlbia(); }
--
Mathematics is the supreme nostalgia of our time.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] powerpc: Pass PID argument to _tlbie (WAS: Apparent kernel bug with GDB on ppc405)
On Mon, 29 Oct 2007 07:08:24 -0500 Josh Boyer [EMAIL PROTECTED] wrote: On Sat, 27 Oct 2007 17:32:02 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Allright, so Matt, let me know if that fixes your problem with gdb, and I'll clean the patch up a bit and submit it. I want to double check if something similar may be needed for freescale booke. Basically, the problem is that things like get_user_pages() can cause COW operations which in turn call _tlbie() to be called for translations that aren't in the current address space. The current 40x and 44x implementation of _tlbie doesn't handle that properly as it only invalidates entries in the current PID. This is an attempt at fixing it. Untested, I just checked it builds for arch/powerpc and arch/ppc. I also haven't looked whether the freescale BookE _tlbie needs similar treatement (it will get passed the pid in r4 with that patch, so if it needs to do something with it, it can). Kumar, can you have a look ? This looks pretty good at first glance. I'll try to test it out today, but I'd still like to hear if it solves Matt's problem as I doubt I'll be able to duplicate it. Did a boot test on my ebony board with this patch included. It seems to be happy about things so far. If Matt gets around to trying this out and it works, we should probably look at getting this into 2.6.24. Oh, and I'd need a signed-off-by for it Ben :) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [powerpc] update xmon slb code
[powerpc] update xmon slb code
adds a bit more detail to the xmon SLB output. When the valid bit is
set, This displays the ESID and VSID values, as well as decoding the
segment size. (1T or 256M). This supresses the output for any slb entries
that contain only zeros.
I debated a bit on whether to check for just (valid) versus checking for
(valid|esid|vsid). By inspection on power5, I do have SLB entries that
contain values but without the valid bit set, so opted to display any
non-zero values.
sample output from power6 (1T segment support):
00 c800 40004f7ca3000500 1T ESID=c0 VSID=40004f7ca3
01 d800 4000eb71b400 1T ESID=d0 VSID=4000eb71b0
24 cf000800 400011b26500 1T ESID=cf VSID=400011b260
25 04000800 4000a9e949000c80 1T ESID=4 VSID=4000a9e949
26 1800 5e93bfd49c80 256M ESID=1 VSID=5e93bfd49
27 0f000800 4000e262a4000c80 1T ESID=f VSID=4000e262a4
28 0800 5dd45172ec80 256M ESID=0 VSID=5dd45172e
sample output from power5 (notice the non-valid but non-zero entries)
54 4800 cf33bb059c80 256M ESID=4 VSID=cf33bb059
55 1800 ccf56fe08c80 256M ESID=1 VSID=ccf56fe08
56 1000 dd82ce799c80
57 cf000800 d59aca40f500 256M ESID=cf000 VSID=d59aca40f
58 c0007800 45cb97751500 256M ESID=c0007 VSID=45cb97751
59 0400 61552db1bc80
Tested on power5 and power6.
Signed-Off-By: Will Schmidt [EMAIL PROTECTED]
---
arch/powerpc/xmon/xmon.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 121b04d..97984f3 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2527,16 +2527,24 @@ static void xmon_print_symbol(unsigned long address,
const char *mid,
static void dump_slb(void)
{
int i;
- unsigned long tmp;
+ unsigned long esid,vsid,valid;
printf(SLB contents of cpu %x\n, smp_processor_id());
for (i = 0; i SLB_NUM_ENTRIES; i++) {
- asm volatile(slbmfee %0,%1 : =r (tmp) : r (i));
- printf(%02d %016lx , i, tmp);
-
- asm volatile(slbmfev %0,%1 : =r (tmp) : r (i));
- printf(%016lx\n, tmp);
+ asm volatile(slbmfee %0,%1 : =r (esid) : r (i));
+ asm volatile(slbmfev %0,%1 : =r (vsid) : r (i));
+ valid = (esid SLB_ESID_V);
+ if (valid | esid | vsid) {
+ printf(%02d %016lx %016lx, i, esid, vsid);
+ if (valid) {
+ if (vsid SLB_VSID_B_1T)
+ printf( 1T ESID=%lx VSID=%lx \n,
GET_ESID_1T(esid),vsid SLB_VSID_SHIFT_1T);
+ else
+ printf( 256M ESID=%lx VSID=%lx \n,
GET_ESID(esid),vsid SLB_VSID_SHIFT);
+ } else
+ printf(\n);
+ }
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: boot/wrap assumes a biarch toolchain?
Andreas Schwab wrote: Jan Dittmer [EMAIL PROTECTED] writes: Andreas Schwab wrote: Jan Dittmer [EMAIL PROTECTED] writes: $ powerpc64-linux-gcc-4.0.4 -v Using built-in specs. Target: powerpc64-linux Configured with: ../configure --prefix=/usr/cc217 --exec-prefix=/usr/cc217/powerpc64 --target=powerpc64-linux --disable-shared --disable-werror --disable-nls --disable-threads --disable-werror --disable-libmudflap --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c Thread model: single gcc version 4.0.4 g5_defconfig: $ make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux- CROSS32_COMPILE=powerpc64-linux- Your compiler still needs -m32 to generate 32-bit code (or use --with-cpu=default32 to make that the default). 4.1.2 exhibits the same behavior. What do you mean with the same behavior? Same error, you write above that a newer compiler version should not need -m32 or --with-cpu=default32 any more? But I still get: CC arch/powerpc/kernel/signal.o LDS arch/powerpc/kernel/vdso32/vdso32.lds VDSO32A arch/powerpc/kernel/vdso32/sigtramp.o VDSO32A arch/powerpc/kernel/vdso32/gettimeofday.o /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S: Assembler messages: /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:33: Error: syntax error; found `@' but expected `,' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:33: Error: junk at end of line: [EMAIL PROTECTED]' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:37: Error: syntax error; found `@' but expected `,' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:37: Error: junk at end of line: [EMAIL PROTECTED]' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:95: Error: syntax error; found `@' but expected `,' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:95: Error: junk at end of line: [EMAIL PROTECTED]' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:103: Error: syntax error; found `@' but expected `,' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:103: Error: junk at end of line: [EMAIL PROTECTED]' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:130: Error: syntax error; found `@' but expected `,' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:130: Error: junk at end of line: [EMAIL PROTECTED]' make[3]: *** [arch/powerpc/kernel/vdso32/gettimeofday.o] Error 1 make[2]: *** [arch/powerpc/kernel/vdso32] Error 2 make[1]: *** [arch/powerpc/kernel] Error 2 make: *** [sub-make] Error 2 Jan Andreas. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new class property?
-Original Message-
From: Wood Scott-B07421
Sent: Monday, October 29, 2007 2:44 PM
To: Yoder Stuart-B08248
Cc: Matt Sealey; Dale Farnsworth; Linuxppc-dev@ozlabs.org
Subject: Re: RFC: replace device_type with new class property?
Yoder Stuart-B08248 wrote:
Here's an example of what I'm trying to get at-- take
a node from a FSL device tree. The ideas I've heard
for expressing the class are like this--
#1 don't express any class at all:
[EMAIL PROTECTED] {
compatible = fsl,ucc_geth;
model = UCC;
device-id = 3;
reg = 2200 200;
interrupts = 22;
interrupt-parent = qeic ;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = 19;
tx-clock = 1a;
phy-handle = phy3 ;
pio-handle = pio3 ;
Of course, this should properly be something like
[EMAIL PROTECTED] {
compatible = fsl,mpc8360-qe-enet, fsl,qe-enet;
local-mac-address = [ 00 00 00 00 00 00 ];
...
};
With no mac-address, and a more useful model if any at all.
That's fine, but as a human reader there is nothing
that would tell me this node implemented a defined
binding that specified required properties.
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: boot/wrap assumes a biarch toolchain?
Andreas Schwab wrote: Jan Dittmer [EMAIL PROTECTED] writes: $ powerpc64-linux-gcc-4.0.4 -v Using built-in specs. Target: powerpc64-linux Configured with: ../configure --prefix=/usr/cc217 --exec-prefix=/usr/cc217/powerpc64 --target=powerpc64-linux --disable-shared --disable-werror --disable-nls --disable-threads --disable-werror --disable-libmudflap --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c Thread model: single gcc version 4.0.4 g5_defconfig: $ make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux- CROSS32_COMPILE=powerpc64-linux- Your compiler still needs -m32 to generate 32-bit code (or use --with-cpu=default32 to make that the default). 4.1.2 exhibits the same behavior. When did it start to work without additional options? 4.2? Jan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5 v3] Porting RapidIO driver from ppc to powerpc architecture and adding memory mapped RapidIO driver.
On Oct 29, 2007, at 2:38 PM, Phil Terry wrote: Can anyone tell me what the status of these are? What kernel release are they targetted for? Currently I'm trying to work with 2.6.23 plus these patches locally. hopefully 2.6.25. I'd like to get the documentation updates in 2.6.24 if we have agreement on them. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix 4xx flush_tlb_page()
On 4xx CPUs, the current implementation of flush_tlb_page() uses
a low level _tlbie() assembly function that only works for the
current PID. Thus, invalidations caused by, for example, a COW
fault triggered by get_user_pages() from a different context will
not work properly, causing among other things, gdb breakpoints
to fail.
This patch adds a pid argument to _tlbie() on 4xx processors,
and uses it to flush entries in the right context. FSL BookE
also gets the argument but it seems they don't need it (their
tlbivax form ignores the PID when invalidating according to the
document I have).
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/kernel/misc_32.S| 23 ---
arch/powerpc/mm/fault.c |2 +-
arch/powerpc/mm/mmu_decl.h |4 ++--
arch/ppc/kernel/misc.S | 22 +++---
arch/ppc/mm/fault.c |2 +-
arch/ppc/mm/mmu_decl.h |4 ++--
arch/ppc/platforms/4xx/ebony.c |2 +-
arch/ppc/platforms/4xx/ocotea.c |2 +-
arch/ppc/platforms/4xx/taishan.c |2 +-
include/asm-powerpc/tlbflush.h | 12 ++--
10 files changed, 46 insertions(+), 29 deletions(-)
Index: linux-work/arch/powerpc/mm/fault.c
===
--- linux-work.orig/arch/powerpc/mm/fault.c 2007-10-25 13:15:47.0
+1000
+++ linux-work/arch/powerpc/mm/fault.c 2007-10-29 10:13:11.0 +1100
@@ -309,7 +309,7 @@ good_area:
set_bit(PG_arch_1, page-flags);
}
pte_update(ptep, 0, _PAGE_HWEXEC);
- _tlbie(address);
+ _tlbie(address, mm-context.id);
pte_unmap_unlock(ptep, ptl);
up_read(mm-mmap_sem);
return 0;
Index: linux-work/include/asm-powerpc/tlbflush.h
===
--- linux-work.orig/include/asm-powerpc/tlbflush.h 2007-10-25
13:15:52.0 +1000
+++ linux-work/include/asm-powerpc/tlbflush.h 2007-10-29 10:13:57.0
+1100
@@ -1,5 +1,6 @@
#ifndef _ASM_POWERPC_TLBFLUSH_H
#define _ASM_POWERPC_TLBFLUSH_H
+
/*
* TLB flushing:
*
@@ -16,9 +17,6 @@
*/
#ifdef __KERNEL__
-struct mm_struct;
-struct vm_area_struct;
-
#if defined(CONFIG_4xx) || defined(CONFIG_8xx) || defined(CONFIG_FSL_BOOKE)
/*
* TLB flushing for software loaded TLB chips
@@ -28,7 +26,9 @@ struct vm_area_struct;
* specific tlbie's
*/
-extern void _tlbie(unsigned long address);
+#include linux/mm.h
+
+extern void _tlbie(unsigned long address, unsigned int pid);
#if defined(CONFIG_40x) || defined(CONFIG_8xx)
#define _tlbia() asm volatile (tlbia; sync : : : memory)
@@ -44,13 +44,13 @@ static inline void flush_tlb_mm(struct m
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr);
+ _tlbie(vmaddr, vma-vm_mm-context.id);
}
static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr);
+ _tlbie(vmaddr, vma-vm_mm-context.id);
}
static inline void flush_tlb_range(struct vm_area_struct *vma,
Index: linux-work/arch/powerpc/kernel/misc_32.S
===
--- linux-work.orig/arch/powerpc/kernel/misc_32.S 2007-09-28
11:42:05.0 +1000
+++ linux-work/arch/powerpc/kernel/misc_32.S2007-10-29 10:13:11.0
+1100
@@ -288,7 +288,16 @@ _GLOBAL(_tlbia)
*/
_GLOBAL(_tlbie)
#if defined(CONFIG_40x)
+ /* We run the search with interrupts disabled because we have to change
+* the PID and I don't want to preempt when that happens.
+*/
+ mfmsr r5
+ mfspr r6,SPRN_PID
+ wrteei 0
+ mtspr SPRN_PID,r4
tlbsx. r3, 0, r3
+ mtspr SPRN_PID,r6
+ wrtee r5
bne 10f
sync
/* There are only 64 TLB entries, so r3 64, which means bit 25 is
clear.
@@ -297,23 +306,23 @@ _GLOBAL(_tlbie)
tlbwe r3, r3, TLB_TAG
isync
10:
+
#elif defined(CONFIG_44x)
- mfspr r4,SPRN_MMUCR
- mfspr r5,SPRN_PID /* Get PID */
- rlwimi r4,r5,0,24,31 /* Set TID */
+ mfspr r5,SPRN_MMUCR
+ rlwimi r5,r4,0,24,31 /* Set TID */
/* 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
+ mfmsr r4
lis
Re: [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines
On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote: This commit made an incorrect assumption: -- Author: Lennert Buytenhek [EMAIL PROTECTED] Date: Fri Oct 19 04:10:10 2007 +0200 mv643xx_eth: Move ethernet register definitions into private header Move the mv643xx's ethernet-related register definitions from include/linux/mv643xx.h into drivers/net/mv643xx_eth.h, since they aren't of any use outside the ethernet driver. Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED] Acked-by: Tzachi Perelstein [EMAIL PROTECTED] Signed-off-by: Dale Farnsworth [EMAIL PROTECTED] -- arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there. [EMAIL PROTECTED]:~/devel/wireless-2.6$ git-describe v2.6.24-rc1-138-g0119130 This patch fixes this by internalizing 3 defines onto pegasos which are simply no longer available elsewhere. Without this your compile will fail whenever you enable 'Common Hardware Reference Platform (CHRP) based machines', [...] diff --git a/arch/powerpc/platforms/chrp/pegasos_eth.c b/arch/powerpc/platforms/chrp/pegasos_eth.c index 5bcc58d..1fc9e8c 100644 --- a/arch/powerpc/platforms/chrp/pegasos_eth.c +++ b/arch/powerpc/platforms/chrp/pegasos_eth.c @@ -24,6 +24,9 @@ #define PEGASOS2_SRAM_BASE_ETH0 (PEGASOS2_SRAM_BASE) #define PEGASOS2_SRAM_BASE_ETH1 (PEGASOS2_SRAM_BASE_ETH0 + (PEGASOS2_SRAM_SIZE / 2) ) +#define PEGASOS2_ETH_BAR_4 0x2220 +#define PEGASOS2_ETH_SIZE_REG_4 0x2224 +#define PEGASOS2_ETH_BASE_ADDR_ENABLE_REG0x2290 #define PEGASOS2_SRAM_RXRING_SIZE(PEGASOS2_SRAM_SIZE/4) #define PEGASOS2_SRAM_TXRING_SIZE(PEGASOS2_SRAM_SIZE/4) @@ -147,13 +150,13 @@ static int Enable_SRAM(void) ALong = 0x02; ALong |= PEGASOS2_SRAM_BASE 0x; - MV_WRITE(MV643XX_ETH_BAR_4, ALong); + MV_WRITE(PEGASOS2_ETH_BAR_4, ALong); - MV_WRITE(MV643XX_ETH_SIZE_REG_4, (PEGASOS2_SRAM_SIZE-1) 0x); + MV_WRITE(PEGASOS2_ETH_SIZE_REG_4, (PEGASOS2_SRAM_SIZE-1) 0x); - MV_READ(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong); + MV_READ(PEGASOS2_ETH_BASE_ADDR_ENABLE_REG, ALong); ALong = ~(1 4); - MV_WRITE(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong); + MV_WRITE(PEGASOS2_ETH_BASE_ADDR_ENABLE_REG, ALong); #ifdef BE_VERBOSE printk(Pegasos II/Marvell MV64361: register unmapped\n); Al Viro sent a patch for this breakage a couple of days ago: http://marc.info/?l=linux-kernelm=119351541706811w=2 (FWIW, I think that code outside of mv643xx_eth.c should not be poking into the mv643xx's registers directly. Ideally, this info should just be passed by pegasos_eth into mv643xx_eth via platform data, and then mv643xx_eth can write the relevant hardware registers.) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines
On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote:
This commit made an incorrect assumption:
--
Author: Lennert Buytenhek [EMAIL PROTECTED]
Date: Fri Oct 19 04:10:10 2007 +0200
mv643xx_eth: Move ethernet register definitions into private header
Move the mv643xx's ethernet-related register definitions from
include/linux/mv643xx.h into drivers/net/mv643xx_eth.h, since
they aren't of any use outside the ethernet driver.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Acked-by: Tzachi Perelstein [EMAIL PROTECTED]
Signed-off-by: Dale Farnsworth [EMAIL PROTECTED]
--
arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there.
[EMAIL PROTECTED]:~/devel/wireless-2.6$ git-describe
v2.6.24-rc1-138-g0119130
This patch fixes this by internalizing 3 defines onto pegasos which are
simply no longer available elsewhere. Without this your compile will fail
That compile failure was fixed in commit
30e69bf4cce16d4c2dcfd629a60fcd8e1aba9fee by Al Viro.
However, as I examine that commit, I see that it defines offsets from
the eth block in the chip, rather than the full chip registeri block
as the Pegasos 2 code expects. So, I think it fixes the compile
failure, but leaves the Pegasos 2 broken.
Luis, do you have Pegasos 2 hardware? Can you (or anyone) verify that
the following patch is needed for the Pegasos 2?
Thanks,
-Dale
-
mv643xx_eth: Fix MV643XX_ETH offsets used by Pegasos 2
In the mv643xx_eth driver, we now use offsets from the ethernet
register block within the chip, but the pegasos 2 platform still
needs offsets from the full chip's register base address.
Signed-off-by: Dale Farnsworth [EMAIL PROTECTED]
---
include/linux/mv643xx_eth.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/mv643xx_eth.h b/include/linux/mv643xx_eth.h
index 8df230a..30e11aa 100644
--- a/include/linux/mv643xx_eth.h
+++ b/include/linux/mv643xx_eth.h
@@ -8,9 +8,9 @@
#define MV643XX_ETH_NAME mv643xx_eth
#define MV643XX_ETH_SHARED_REGS0x2000
#define MV643XX_ETH_SHARED_REGS_SIZE 0x2000
-#define MV643XX_ETH_BAR_4 0x220
-#define MV643XX_ETH_SIZE_REG_4 0x224
-#define MV643XX_ETH_BASE_ADDR_ENABLE_REG 0x0290
+#define MV643XX_ETH_BAR_4 0x2220
+#define MV643XX_ETH_SIZE_REG_4 0x2224
+#define MV643XX_ETH_BASE_ADDR_ENABLE_REG 0x2290
struct mv643xx_eth_platform_data {
int port_number;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new class property?
On Mon, Oct 29, 2007 at 12:34:40PM -0700, Yoder Stuart-B08248 wrote:
#4 use compatible
[EMAIL PROTECTED] {
compatible = fsl,ucc_geth,[official spec],network;
model = UCC;
device-id = 3;
reg = 2200 200;
interrupts = 22;
interrupt-parent = qeic ;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = 19;
tx-clock = 1a;
phy-handle = phy3 ;
pio-handle = pio3 ;
};
I don't like this...we are overloading compatible with
stuff that is not specifying a programming interface. compatible
is supposed to be specifying a programming interface which
the device complies to.
If your proposed class property doesn't specify a programming interface,
then I agree that we shouldn't put that info in compatible. My point
was that compatible is the one and only property that a driver should
look at to find a node with a suitable programming interface.
But, that begs the question: How will the code use your class property?
Another post implied that it's for human-readable purposes. If that's
all, I'd leave it out, or use a comment instead.
-Dale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: boot/wrap assumes a biarch toolchain?
Andreas Schwab wrote: Anton Blanchard [EMAIL PROTECTED] writes: One way to make this go away would be to build binutils as biarch: # configure --target=powerpc-linux --enable-targets=powerpc64-linux ... If you configure your toolchain for powerpc64-linux you get a biarch toolchain by default. Hmm: $ powerpc64-linux-ld -V GNU ld (Linux/GNU Binutils) 2.17.50.0.17.20070615 Supported emulations: elf64ppc elf32ppclinux elf32ppc elf32ppcsim $ powerpc64-linux-gcc-4.0.4 -v Using built-in specs. Target: powerpc64-linux Configured with: ../configure --prefix=/usr/cc217 --exec-prefix=/usr/cc217/powerpc64 --target=powerpc64-linux --disable-shared --disable-werror --disable-nls --disable-threads --disable-werror --disable-libmudflap --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c Thread model: single gcc version 4.0.4 g5_defconfig: $ make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux- CROSS32_COMPILE=powerpc64-linux- ... CC arch/powerpc/kernel/signal.o LDS arch/powerpc/kernel/vdso32/vdso32.lds VDSO32A arch/powerpc/kernel/vdso32/sigtramp.o VDSO32A arch/powerpc/kernel/vdso32/gettimeofday.o /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S: Assembler messages: /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:33: Error: syntax error; found `@' but expected `,' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:33: Error: junk at end of line: [EMAIL PROTECTED]' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:37: Error: syntax error; found `@' but expected `,' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:37: Error: junk at end of line: [EMAIL PROTECTED]' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:95: Error: syntax error; found `@' but expected `,' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:95: Error: junk at end of line: [EMAIL PROTECTED]' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:103: Error: syntax error; found `@' but expected `,' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:103: Error: junk at end of line: [EMAIL PROTECTED]' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:130: Error: syntax error; found `@' but expected `,' /usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:130: Error: junk at end of line: [EMAIL PROTECTED]' make[3]: *** [arch/powerpc/kernel/vdso32/gettimeofday.o] Error 1 make[2]: *** [arch/powerpc/kernel/vdso32] Error 2 make[1]: *** [arch/powerpc/kernel] Error 2 make: *** [sub-make] Error 2 Jan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines
This commit made an incorrect assumption: -- Author: Lennert Buytenhek [EMAIL PROTECTED] Date: Fri Oct 19 04:10:10 2007 +0200 mv643xx_eth: Move ethernet register definitions into private header Move the mv643xx's ethernet-related register definitions from include/linux/mv643xx.h into drivers/net/mv643xx_eth.h, since they aren't of any use outside the ethernet driver. Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED] Acked-by: Tzachi Perelstein [EMAIL PROTECTED] Signed-off-by: Dale Farnsworth [EMAIL PROTECTED] -- arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there. [EMAIL PROTECTED]:~/devel/wireless-2.6$ git-describe v2.6.24-rc1-138-g0119130 This patch fixes this by internalizing 3 defines onto pegasos which are simply no longer available elsewhere. Without this your compile will fail whenever you enable 'Common Hardware Reference Platform (CHRP) based machines', (CONFIG_PPC_CHRP) as the Makefile for chrp adds it always: obj-y += setup.o time.o pegasos_eth.o pci.o If these defines are platform specific then they should later just be added back to include/linux/mv643xx.h. Compile error: CC arch/powerpc/platforms/chrp/pegasos_eth.o arch/powerpc/platforms/chrp/pegasos_eth.c: In function 'Enable_SRAM': arch/powerpc/platforms/chrp/pegasos_eth.c:150: error: 'MV643XX_ETH_BAR_4' undeclared (first use in this function) arch/powerpc/platforms/chrp/pegasos_eth.c:150: error: (Each undeclared identifier is reported only once arch/powerpc/platforms/chrp/pegasos_eth.c:150: error: for each function it appears in.) arch/powerpc/platforms/chrp/pegasos_eth.c:152: error: 'MV643XX_ETH_SIZE_REG_4' undeclared (first use in this function) arch/powerpc/platforms/chrp/pegasos_eth.c:154: error: 'MV643XX_ETH_BASE_ADDR_ENABLE_REG' undeclared (first use in this function) make[2]: *** [arch/powerpc/platforms/chrp/pegasos_eth.o] Error 1 make[1]: *** [arch/powerpc/platforms/chrp] Error 2 make: *** [arch/powerpc/platforms] Error 2 Signed-off-by: Luis R. Rodriguez [EMAIL PROTECTED] --- arch/powerpc/platforms/chrp/pegasos_eth.c | 11 +++ 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/platforms/chrp/pegasos_eth.c b/arch/powerpc/platforms/chrp/pegasos_eth.c index 5bcc58d..1fc9e8c 100644 --- a/arch/powerpc/platforms/chrp/pegasos_eth.c +++ b/arch/powerpc/platforms/chrp/pegasos_eth.c @@ -24,6 +24,9 @@ #define PEGASOS2_SRAM_BASE_ETH0(PEGASOS2_SRAM_BASE) #define PEGASOS2_SRAM_BASE_ETH1 (PEGASOS2_SRAM_BASE_ETH0 + (PEGASOS2_SRAM_SIZE / 2) ) +#define PEGASOS2_ETH_BAR_4 0x2220 +#define PEGASOS2_ETH_SIZE_REG_40x2224 +#define PEGASOS2_ETH_BASE_ADDR_ENABLE_REG 0x2290 #define PEGASOS2_SRAM_RXRING_SIZE (PEGASOS2_SRAM_SIZE/4) #define PEGASOS2_SRAM_TXRING_SIZE (PEGASOS2_SRAM_SIZE/4) @@ -147,13 +150,13 @@ static int Enable_SRAM(void) ALong = 0x02; ALong |= PEGASOS2_SRAM_BASE 0x; - MV_WRITE(MV643XX_ETH_BAR_4, ALong); + MV_WRITE(PEGASOS2_ETH_BAR_4, ALong); - MV_WRITE(MV643XX_ETH_SIZE_REG_4, (PEGASOS2_SRAM_SIZE-1) 0x); + MV_WRITE(PEGASOS2_ETH_SIZE_REG_4, (PEGASOS2_SRAM_SIZE-1) 0x); - MV_READ(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong); + MV_READ(PEGASOS2_ETH_BASE_ADDR_ENABLE_REG, ALong); ALong = ~(1 4); - MV_WRITE(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong); + MV_WRITE(PEGASOS2_ETH_BASE_ADDR_ENABLE_REG, ALong); #ifdef BE_VERBOSE printk(Pegasos II/Marvell MV64361: register unmapped\n); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [Powerpc V2] fix switch_slb handling of 1T ESID values
Hi Will,
Just a trivial comment ...
On Mon, 29 Oct 2007 13:32:19 -0500 Will Schmidt [EMAIL PROTECTED] wrote:
+static inline int esids_match(unsigned long addr1, unsigned long addr2)
+{
+ int esid_1t_count;
+
+ /* System is not 1T segment size capable. */
+ if (!cpu_has_feature(CPU_FTR_1T_SEGMENT))
+ return (GET_ESID(addr1) == GET_ESID(addr2));
+
+ esid_1t_count = (((addr1SID_SHIFT_1T)!=0) +
((addr2SID_SHIFT_1T)!=0));
Please use spaces around binary operators (as you have elsewhere). Even
if it pushes the line slightly over 80 characters ...
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpLsYJ7RHmtU.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: boot/wrap assumes a biarch toolchain?
Jan Dittmer [EMAIL PROTECTED] writes: Same error, you write above that a newer compiler version should not need -m32 or --with-cpu=default32 any more? ??? Where did I say that? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] MTD: small physmap_of partition parsing fixes
On Mon, Oct 29, 2007 at 11:29:02PM +0300, Valentine Barshak wrote: Use of_get_next_child for proper ref counting as suggested by Stephen Rothwell and remove add_mtd_partitions from parse_partitions to avoid duplicate mtd device registration for RedBoot partitions. Signed-off-by: Valentine Barshak [EMAIL PROTECTED] Oops, yes. I think the extra add_mtd_partitions() was left over from an earlier version which always did the add_mtd_partitions() from within the probe function. Acked-by: David Gibson [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: RFC: replace device_type with new class property?
On Mon, Oct 29, 2007 at 11:11:40AM -0500, Scott Wood wrote: On Mon, Oct 29, 2007 at 03:20:56PM +, Matt Sealey wrote: I think device_type, compatible and model properties fulfil this already, they simply aren't being used correctly. device_type has a few drawbacks, though: 1. You can only specify one type, whereas with a new property we could define it as a list (similar to compatible). It's possible for one node to comply with multiple class bindings, such as when there's a binding for clients of the type of bus it's on as well as the type of device it is, or when there are multiple levels of detail (such as complying with both simple-bus and some specific bus binding). 2. We want to avoid any confusion with OF bindings and abused device_type entries that have been allowed to become existing practice. 3. It's the only standard property (AFAIK) with an underscore in it. :-) Remember that, while you may want to make FDTs easier to design, OpenFirmware and the requirement on device interfaces through the client interface still exist and are still implemented (from time to time). Sure -- and we don't want to risk the code thinking it can call into OF based on what we put in a flat device tree, right? For readability, the name of the device needn't match device_type; for instance on the 5121E it may be that the 'diu' unit be called diu, but be of device_type 'display' I don't think that's more readable than setting the name to display. Something containing diu will be in the compatible list. Further differentiation should be done through the 'model' property in my opinion. This is optional in the OpenFirmware spec, but that does not mean it should be important. It is currently defined as something to determine the exact model of a chip in order to enable quirks, bugfixes and suchlike, but most implementations switch on something else entirely (like SVR or a heuristic behaviour). Selecting the model would be no different to, for example, having a list of PCI IDs that will work with a driver. It's what we currently do with compatible. Why break it into two properties? The PCI ID thing can be quite a headache, BTW, when you get a new PCI device that won't work with the existing driver, for no reason other than that it hasn't been updated with the new ID. Indeed. Replacing the flexible string based matching we have already, with a limited ID based matching is just silly. There was a little discussion at bplan once that it would be easier to implement a kind of vendor/device id system much like PCI, USB etc. implements in hardware in order to match hardware. I suppose you could use a class property to implement this - No, you should use compatible for that. Yes. Driver binding should be based on compatible. Period. Drivers can enable quirks based on 'model' or any other information available to them (either from the device tree or direct from the hardware). -- 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: RFC: replace device_type with new class property?
On Mon, Oct 29, 2007 at 10:27:24AM -0700, Dale Farnsworth wrote: Scott wrote: Personally, I'm fine with just using name and compatible, but others such as Stuart have expressed a desire for something to formally indicate compliance with a standard binding. I don't think we should expand the use of device_type in any case. I agree that the existing compatible property is sufficient to do what Stuart wants. All that is required is to define some standard bindings and give them well-known names for the compatible property. If needed, we could define a prefix that indicates that a compatible entry refers to a standards-compliant binding. For example, standard,network, or standard,display. I don't see the benefit of creating a new property similar to device_type. That would overload the meaning of compatible. A driver which matches any compatible entry should be able to drive the device, even if it can't use all the devices features. You can't do that if all you know is that something is a display. So, standardised or defacto-standard hardware-level interfaces belong in compatible, e.g. ohci, uhci, ns16550. The mere fact that something is a display or network interface (and has *general* properties related to such devices) doesn't let you drive it. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
On Mon, Oct 29, 2007 at 09:40:23AM -0600, Grant Likely wrote: On 10/29/07, Marian Balakowicz [EMAIL PROTECTED] wrote: David Gibson wrote: On Thu, Oct 25, 2007 at 05:46:19PM +0200, Marian Balakowicz wrote: Grant Likely wrote: On 10/25/07, Martin Krause [EMAIL PROTECTED] wrote: [snip] On a board with 16 MiB FLASH for example the big-fs _and_ the misc partition could not be used. big-fs, because the memory is too small (which is OK) and misc, because it overlaps 1 MiB over the physikal flash border. So only the first 9 MiB of the flash could be used in Linux. The remaining 7 MiB couldn't be accessed. Perhaps it would be better to drop the flash layout from the in-kernel dts files entirely since flash layout can be a fluid thing. Well, but that would not be really user friendly, I'd rather stick with some default config. Strictly speaking the device-tree is not the right place for flash partitioning information. We put it there because it's preferable to having hardcoded per-board flash layouts in the code itself. It only really works well, though, when there are strong conventions (shared with the firmware) about how to partition the flash. Where it's really up to the user to determine how they want to lay out their flash, putting things in the device tree isn't a really good idea. In principle, you are right, we should not be putting a user dependent configuration into .dts files. But on the other hand, bindings have been defined for flash-like devices and their partition layouts and physmap_of device driver is expecting to get this information from the blob. So, it is the place for it. But if we are not to put partition layouts into the default kernel .dts files then we should provide/maintain some examples an that may be a even bigger mess. Incidentally, it's not required that *all* the flash address space be in partitions, so it is possible only give partitions for those flash chunks which the firmware needs to know about. That might be nicer solution but different variants of TQM5200 boards do not share the same subset of partitions (default u-boot partitions at least), so it will not help much. It's probably more appropriate to have the flash partition layout in the u-boot environment and have u-boot populate the partition information in the device tree. That sounds like a reasonable idea. But if the flash partition layout is *not* fixed - but selectable by the board installer, then it should certainly not be hardcoded into a fixed dts. -- 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: RFC: replace device_type with new class property?
On Mon, Oct 29, 2007 at 12:34:40PM -0700, Yoder Stuart-B08248 wrote:
Here's an example of what I'm trying to get at-- take
a node from a FSL device tree. The ideas I've heard
for expressing the class are like this--
#1 don't express any class at all:
[EMAIL PROTECTED] {
compatible = fsl,ucc_geth;
model = UCC;
device-id = 3;
reg = 2200 200;
interrupts = 22;
interrupt-parent = qeic ;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = 19;
tx-clock = 1a;
phy-handle = phy3 ;
pio-handle = pio3 ;
This is bad IMHO because the human reader has to
infer the class of device. Can the human reader
tell if it implements a standardized binding or
not??
Well... except that by the generic names convention, the node should
be called [EMAIL PROTECTED], which makes it rather clearer to a human
reader.
--
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: RFC: replace device_type with new class property?
On Mon, Oct 29, 2007 at 04:22:13PM -0500, Olof Johansson wrote: [snip] I don't see how switching the property name from device_type to class is going to stop people from misunderstanding it's intended use. There's nothing inherently more understandable in calling it class -- it also invites people to make up their own class names as they go along, just as what happened to device_type. I also don't understand the people wanting to use compatible for _everything_. It's just mashing together two separate pieces of information into one property, and I seriously don't see how that helps anything or anyone. It's absolutely useless for a driver to be able to bind to a compatible field of standard,network or whatever it might be, since there's no way that standard, will imply that the register layout and programming model is somehow the same as all other standard-labelled devices. So yes, there is a problem with the device trees and how people build them, and it requires education on how to properly craft one. I don't think changing the layout to either be flatter (only using compatible), or changing names of a property (device_type-class) will help anything at all. I actually prefer keeping device_type myself, since it means existing OF-based device trees will already have some of the labels. Yeah.. what he said. The *only* substantive change with the class proposal is the fact that multiple classes can be specified. That's nice, but I don't think it's worth the trouble of attempting to define a whole new chunk of standard for. Stuart, I think you overestimate the value of this class property to a human reader. The generic names convention (not followed as much as it should be) means the name should give the reader some idea of what the device is, in most cases. For trickier cases, if we really want something for humans reading the tree, we could add an optional comment or description property with purely human readable information. I think we should leave existing IEEE1275 defined uses of device_type, in order not to make flat trees gratuitously different from real-OF trees, but we should avoid any new use of device_type. Explicitly specifying what device class bindings / conventions the node complies with is cute, but not actually all that useful in practice. If it looks like a duck class device node, and it quacks^Whas the properties of a duck class device node, it's duck class compliant. Or to look at it another way, class bindings aren't really bindings, but rather a set of conventions that device bindings for specific devices in that class ought to follow. -- 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 0/3] Add device-tree aware NDFC driver
On Mon, 29 Oct 2007, Valentine Barshak wrote: This adds a device-tree aware PowerPC 44x NanD Flash Controller driver The code is based on the original NDFC driver by Thomas Gleixner, but since it's been changed much and has initialization/clean-up completely reworked it's been put into a separate ndfc_of.c file. This version supports both separate mtd devices on each chip attached to NDFC banks and single mtd device spread across identical chips (not using mtdconcat) as well. The choice is selected with device tree settings. This has been tested on PowerPC 440EPx Sequoia board. Any comments are greatly appreciated. Did I express myself not clear enough in my first reply or is this just a repeated epiphany in my inbox ? You got plenty of comments to your patches, but you decided to ignore them silently. Darn, fix it the right way once and forever and please don't try to tell me another heartrending why I did it my way story. This all can be done with a nice series of incremental patches including a fixup to the existing users. We have enough dump and run shit in the kernel already. No thanks, tglx ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Remove leftover debugging printf() from mangle-layout
The mangle-layout testcase/utility had a leftover debugging printf(). This patch removes it. Signed-off-by: David Gibson [EMAIL PROTECTED] Index: dtc/tests/mangle-layout.c === --- dtc.orig/tests/mangle-layout.c 2007-10-29 15:58:55.0 +1100 +++ dtc/tests/mangle-layout.c 2007-10-29 15:59:16.0 +1100 @@ -96,8 +96,6 @@ void add_block(struct bufstate *buf, int } offset = ALIGN(buf-size, align); - fprintf(stderr, Moving block %c from %p, to offset %d, size %d\n, - block, src, offset, size); expand_buf(buf, offset+size); -- 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
libfdt: Correctly handle versions 17
If future dtb version 17 are defined, that are still backwards compatible with v16, libfdt will of course be able to read and understand them. However, when modifying such a tree, it can't guarantee that it won't clobber additional structure from the new version which it doesn't know about. Therefore, before making modifications to a tree of version 17, we must change it's version to be exactly 17. Signed-off-by: David Gibson [EMAIL PROTECTED] Index: dtc/libfdt/fdt_rw.c === --- dtc.orig/libfdt/fdt_rw.c2007-10-29 16:09:23.0 +1100 +++ dtc/libfdt/fdt_rw.c 2007-10-29 16:34:37.0 +1100 @@ -61,7 +61,7 @@ static int rw_check_header(void *fdt) if ((err = fdt_check_header(fdt))) return err; - if (fdt_version(fdt) 0x11) + if (fdt_version(fdt) 17) return -FDT_ERR_BADVERSION; if (fdt_off_mem_rsvmap(fdt) ALIGN(sizeof(struct fdt_header), 8)) return -FDT_ERR_BADLAYOUT; @@ -74,6 +74,9 @@ static int rw_check_header(void *fdt) if (fdt_totalsize(fdt) (fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt))) return -FDT_ERR_BADLAYOUT; + if (fdt_version(fdt) 17) + fdt_set_version(fdt, 17); + return 0; } -- 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: Fix 4xx flush_tlb_page()
On Oct 29, 2007, at 5:46 PM, Benjamin Herrenschmidt wrote: On 4xx CPUs, the current implementation of flush_tlb_page() uses a low level _tlbie() assembly function that only works for the current PID. Thus, invalidations caused by, for example, a COW fault triggered by get_user_pages() from a different context will not work properly, causing among other things, gdb breakpoints to fail. This patch adds a pid argument to _tlbie() on 4xx processors, and uses it to flush entries in the right context. FSL BookE also gets the argument but it seems they don't need it (their tlbivax form ignores the PID when invalidating according to the document I have). Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- arch/powerpc/kernel/misc_32.S| 23 --- arch/powerpc/mm/fault.c |2 +- arch/powerpc/mm/mmu_decl.h |4 ++-- arch/ppc/kernel/misc.S | 22 +++--- arch/ppc/mm/fault.c |2 +- arch/ppc/mm/mmu_decl.h |4 ++-- arch/ppc/platforms/4xx/ebony.c |2 +- arch/ppc/platforms/4xx/ocotea.c |2 +- arch/ppc/platforms/4xx/taishan.c |2 +- include/asm-powerpc/tlbflush.h | 12 ++-- 10 files changed, 46 insertions(+), 29 deletions(-) Acked-by: Kumar Gala [EMAIL PROTECTED] - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC] Fix off-by-one error in setting decrementer on Book E
On Oct 28, 2007, at 9:57 PM, Paul Mackerras wrote: The decrementer in Book E and 4xx processors interrupts on the transition from 1 to 0, rather than on the 0 to -1 transition as on 64-bit server and 32-bit classic (6xx/7xx/7xxx) processors. This fixes the problem by making set_dec subtract 1 from the count for server and classic processors. Since set_dec already had a bunch of ifdefs to handle different processor types, there is no net increase in ugliness. :) This also removes a redundant call to set the decrementer to 0x7fff - it was already set to that earlier in timer_interrupt. Signed-off-by: Paul Mackerras [EMAIL PROTECTED] --- ... diff --git a/include/asm-powerpc/time.h b/include/asm-powerpc/time.h index f058955..eed64bd 100644 --- a/include/asm-powerpc/time.h +++ b/include/asm-powerpc/time.h @@ -183,6 +183,7 @@ static inline void set_dec(int val) #elif defined(CONFIG_8xx_CPU6) set_dec_cpu6(val); #else + --val; /* classic decrementer interrupts when dec goes negative */ #ifdef CONFIG_PPC_ISERIES int cur_dec; Unless I'm reading set_dec() you are getting --val on booke. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix build failure in platforms/celleb/setup.c which CONFIG_VIRT_CPU_ACCOUNTING is not defined.
Without this patch I get the following build failure CC arch/powerpc/platforms/celleb/setup.o arch/powerpc/platforms/celleb/setup.c:151: error: 'generic_calibrate_decr' undeclared here (not in a function) Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- arch/powerpc/platforms/celleb/setup.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/celleb/setup.c b/arch/powerpc/platforms/celleb/setup.c index 1769d75..ddfb35a 100644 --- a/arch/powerpc/platforms/celleb/setup.c +++ b/arch/powerpc/platforms/celleb/setup.c @@ -49,6 +49,7 @@ #include asm/machdep.h #include asm/cputable.h #include asm/irq.h +#include asm/time.h #include asm/spu_priv1.h #include asm/firmware.h #include asm/of_platform.h -- 1.5.3.4 Yours Tony linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/ Jan 28 - Feb 02 2008 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [Powerpc V2] fix switch_slb handling of 1T ESID values
On Mon, 2007-10-29 at 13:32 -0500, Will Schmidt wrote: [Powerpc V2] fix switch_slb handling of 1T ESID values Now that we have 1TB segment size support, we need to be using the GET_ESID_1T macro when comparing ESID values for pc,stack, and unmapped_base within switch_slb().A new helper function called esids_match() contains the logic for deciding when to call GET_ESID and GET_ESID_1T. This also happens to fix a duplicate-slb-entry inspired machine-check exception I was seeing when trying to run java on a power6 partition. Tested on power6 and power5. Signed-Off-By: Will Schmidt [EMAIL PROTECTED] --- Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH] powerpc: Deal with 44x virtually tagged icache
The 44x family has an interesting feature which is a virtually tagged instruction cache (yuck !). So far, we haven't dealt with it properly, which means we've been mostly lucky or people didn't report the problems, unless people have been running custom patches in their distro... This is an attempt at fixing it properly. I chose to do it by setting a global flag whenever we change a PTE that was previously marked executable, and flush the entire instruction cache upon return to user space when that happens. This is a bit heavy handed, but it's hard to do more fine grained flushes as the icbi instruction, on those processor, for some very strange reasons (since the cache is virtually mapped) still requires a valid TLB entry for reading in the target address space, which isn't something I want to deal with. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- Fortunately, we don't support SMP on these or this solution wouldn't work. It does mean we do a bit of over-flushing on swap but on the other hand, the code is simple. Another option would have been to do the iccci after any syscall that potentially unmaps or changes a mapping, like sys_munmap, sys_mremap, sys_sbrk, but also the shmem stuff etc... I decided there was just too many and was worried I would miss one. This not very tested as I don't have a test case at hand showing the problem and didn't feel like writing one today :-) It boots though. Careful eyes will notice I didn't do the flush on fast_exception_return, which shouldn't be necessary. arch/powerpc/kernel/entry_32.S | 25 + arch/powerpc/kernel/misc_32.S |9 + arch/powerpc/mm/44x_mmu.c |1 + include/asm-powerpc/pgtable-ppc32.h | 13 + 4 files changed, 48 insertions(+) Index: linux-work/arch/powerpc/kernel/entry_32.S === --- linux-work.orig/arch/powerpc/kernel/entry_32.S 2007-10-15 11:19:35.0 +1000 +++ linux-work/arch/powerpc/kernel/entry_32.S 2007-10-30 16:09:51.0 +1100 @@ -244,6 +244,13 @@ syscall_exit_cont: andis. r10,r0,[EMAIL PROTECTED] bnel- load_dbcr0 #endif +#ifdef CONFIG_44x + lis r4,[EMAIL PROTECTED] + lwz r5,[EMAIL PROTECTED](r4) + cmplwi cr0,r5,0 + bne-2f +1: +#endif /* CONFIG_44x */ stwcx. r0,0,r1 /* to clear the reservation */ lwz r4,_LINK(r1) lwz r5,_CCR(r1) @@ -259,6 +266,13 @@ syscall_exit_cont: SYNC RFI +#ifdef CONFIG_44x +2: li r7,0 + iccci r0,r0 + stw r7,[EMAIL PROTECTED](r4) + b 1b +#endif /* CONFIG_44x */ + 66:li r3,-ENOSYS b ret_from_syscall @@ -683,6 +697,17 @@ resume_kernel: /* interrupts are hard-disabled at this point */ restore: +#ifdef CONFIG_44x + lis r4,[EMAIL PROTECTED] + lwz r5,[EMAIL PROTECTED](r4) + cmplwi cr0,r5,0 + beq+1f + iccci r0,r0 + li r6,0 + iccci r0,r0 + stw r6,[EMAIL PROTECTED](r4) +1: +#endif /* CONFIG_44x */ lwz r0,GPR0(r1) lwz r2,GPR2(r1) REST_4GPRS(3, r1) Index: linux-work/arch/powerpc/mm/44x_mmu.c === --- linux-work.orig/arch/powerpc/mm/44x_mmu.c 2007-09-28 11:42:05.0 +1000 +++ linux-work/arch/powerpc/mm/44x_mmu.c2007-10-30 15:30:50.0 +1100 @@ -35,6 +35,7 @@ */ unsigned int tlb_44x_index; /* = 0 */ unsigned int tlb_44x_hwater = PPC44x_TLB_SIZE - 1 - PPC44x_EARLY_TLBS; +int icache_44x_need_flush; /* * Pins a 256MB TLB entry in AS0 for kernel lowmem Index: linux-work/include/asm-powerpc/pgtable-ppc32.h === --- linux-work.orig/include/asm-powerpc/pgtable-ppc32.h 2007-09-28 11:42:10.0 +1000 +++ linux-work/include/asm-powerpc/pgtable-ppc32.h 2007-10-30 15:30:50.0 +1100 @@ -11,6 +11,11 @@ extern unsigned long va_to_phys(unsigned long address); extern pte_t *va_to_pte(unsigned long address); extern unsigned long ioremap_bot, ioremap_base; + +#ifdef CONFIG_44x +extern int icache_44x_need_flush; +#endif + #endif /* __ASSEMBLY__ */ /* @@ -562,6 +567,10 @@ static inline unsigned long pte_update(p : =r (old), =r (tmp), =m (*p) : r (p), r (clr), r (set), m (*p) : cc ); +#ifdef CONFIG_44x + if ((old _PAGE_USER) (old _PAGE_HWEXEC)) + icache_44x_need_flush = 1; +#endif return old; } #else @@ -582,6 +591,10 @@ static inline unsigned long long pte_upd : =r (old), =r (tmp), =m (*p) : r (p), r ((unsigned long)(p) + 4), r (clr), r (set), m (*p) : cc ); +#ifdef CONFIG_44x + if ((old _PAGE_USER) (old _PAGE_HWEXEC)) + icache_44x_need_flush = 1; +#endif return old; } #endif Index:
Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
On 10/29/07, David Gibson [EMAIL PROTECTED] wrote: On Mon, Oct 29, 2007 at 09:40:23AM -0600, Grant Likely wrote: It's probably more appropriate to have the flash partition layout in the u-boot environment and have u-boot populate the partition information in the device tree. That sounds like a reasonable idea. But if the flash partition layout is *not* fixed - but selectable by the board installer, then it should certainly not be hardcoded into a fixed dts. Exactly my point! :-) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
