Re: UIO not working on ppc405 onchip registers
On Tuesday 22 July 2008, Ben Nizette wrote: But I'll let you get back to solving the UIO problem at hand :-D I already surrendered and created (hacked) a read/write driver, which let me use the old userspace drivers I'm trying to port (with some changes of course). This was way faster than understanding all the involved APIs and creating glue code between them. And the amount of time it needs was easy to estimate. However accidently I ran over the old school userland mmap code with /dev/mem. I already knew mapping with /dev/mem is possible but I haven't thought this could make a difference. http://ozlabs.org/pipermail/linuxppc-embedded/2006-August/023811.html Also I was wrong with my assumption that uio worked well on the peripherals. It worked (very) well on the leds, just to fool me!!! But it returned crap on some version registers. With a working and a non working version of mmap it should be rather easy to trace this bug. Unfortunately I was already short of time before running into this (and other) problems and it didn't get any better. So I would need some help from someone with more experience to fix this. Any instructions? Markus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.27-rc5-mm1 mystery trace
On Thu, 4 Sep 2008, Andrew Morton wrote: On Fri, 05 Sep 2008 14:36:41 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Thu, 2008-09-04 at 20:49 -0700, Andrew Morton wrote: On Fri, 05 Sep 2008 13:42:44 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: g5:/usr/src/25 gdb vmlinux GNU gdb Red Hat Linux (6.3.0.0-1.21rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as ppc-yellowdog-linux-gnu.../usr/src/25/vmlinux: not in executable format: File format not recognized probably there's some command line magic to make it work, but there shouldn't be. Is this a 64 bits gdb ? I don't think so - it's whatever ydl4.1 gave me. A 64-bit binary on a 64-bit machine Should Just Work. Maybe that's me being simplistic. But is it a 64 bits binary ? vmlinux? Yup. According to file(1). No, gdb. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre 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/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.27-rc5-mm1 mystery trace
A 64-bit binary on a 64-bit machine Should Just Work. Maybe that's me being simplistic. But is it a 64 bits binary ? vmlinux? Yup. According to file(1). No, I'm talking about gdb :-0 IE. If it's a 32 bits gdb variant that cannot do 64 bits.. then it's stuffed. Is there a gdb64 binary somewhere ? Some distro have that. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] ibm_newemac: MAL support for PowerPC 405EZ
+ if (of_device_is_compatible(ofdev-node, ibm,mcmal-405ez)) + mal-features |= (MAL_FTR_CLEAR_ICINTSTAT | MAL_FTR_COMMON_ERR_INT); The above like is 80 characters wide. But I'm not sure that anyone cares. I don't. If Ben complains I'll change it. I wouldn't do a tatrum over it but if you're going to respin the patch you may as well put the second constant on the next line. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/44x: Add hwmon support to Sequoia device tree
On Thursday 04 September 2008, Matthias Fuchs wrote:
This patch adds support for the AD7414 temperature sensor
on Sequoia PPC440EPx board.
Signed-off-by: Matthias Fuchs [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/sequoia.dts |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/sequoia.dts
b/arch/powerpc/boot/dts/sequoia.dts index 72d15f0..9ba5def 100644
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -246,13 +246,22 @@
};
IIC0: [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
compatible = ibm,iic-440epx, ibm,iic;
reg = 0xef600700 0x0014;
interrupt-parent = UIC0;
interrupts = 0x2 0x4;
+
+ [EMAIL PROTECTED] {
Not sure if we shouldn't use
[EMAIL PROTECTED] {
here. This is the way it is already done in warp.dts.
Other than this:
Acked-by: Stefan Roese [EMAIL PROTECTED]
Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][USB] powerpc: Workaround for the PPC440EPX USBH_23 errata
В Thu, 4 Sep 2008 17:40:49 -0400 (EDT) Alan Stern [EMAIL PROTECTED] пишет: On Fri, 5 Sep 2008, Vitaly Bordug wrote: I've started looking this way. Sorry, but this approach is a little bit fragile, and unreliable. First, it just did not work out in case of usb2 hub with memory stick and keybord plugged - OHCI did not suspend, ehci is hosed and we're happily using hi-speed device on full-speed: Secondly, we may *not* rely on the fact, that OHCI will always have the same suspend policy. Even kicking the code up to the shape when it will automagically suspend in proper timing to get the HW issue around, we cannot be sure that it will persist along kernel lifecycle, and won't require concerned people to kick suspend timings back to the working state subsequently each rc release. Thirdly, PM is disabled by Kconfig explicitly in case of 44x. Reasoning is not clear at the moment, but I believe that isn't there just in case. I assume that's the reason the suggested approach failed. Oh geez. I may miss some small point, but dunno what made me appear *that* dense. The kernel was properly rebuilt with Kconfig fixed and _PM set. What to do when CONFIG_PM is off is a separate matter. Let's not worry about it for now -- especially since, as Matthias suggested, you can use a USB 2.0 hub. Not every hub will work (none of available did so far), and it is often not an option for embedded device without rewiring. It's odd that your hubs don't work. What's wrong with them? well, they do not have transaction translators then. Nothing really wrong As this touches powerpc stuff only, are there any objections to let powerpc peolple consider if approach suggested earlier is applicable or not? I don't mind doing that, provided the changes are cleaned up so that they don't affect people who aren't building kernels for 44x systems. OK, thanks for review and comments... -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Updated 4xx next branch
Hi All, The following patches have been pushed to the next branch of the 4xx tree. As usual, I'll let them sit there for a bit before asking Paul to pull. If I've missed any patches, please let me know. We have lots of time before the .28 merge window opens, so don't worry too much. josh Ilya Yanok (1): powerpc/4xx: Necessary fixes to PCI for 4GB RAM size Josh Boyer (9): powerpc/44x: Add PowerPC 44x simple platform support powerpc/44x: Migrate Bamboo support to ppc44x_simple powerpc/44x: Migrate Canyonlands support to ppc44x_simple powerpc/44x: Migrate Katmai support to ppc44x_simple powerpc/44x: Migrate Rainier support to ppc44x_simple powerpc/44x: Migrate Sequoia support to ppc44x_simple powerpc/44x: Migrate Taishan support to ppc44x_simple powerpc/44x: Add explicit support for AMCC Glacier powerpc/44x: Add explicit Yosemite support Tirumala R Marri (1): powerpc/44x: AMCC PPC460GT/EX PCI-E de-emphasis adjustment fix ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH, RFC] mv643xx_eth: move sram window setting code into the driver
Lennert Buytenhek wrote: On Thu, Sep 04, 2008 at 08:44:31AM -0500, Matt Sealey wrote: script, but in either case, wouldn't a real sram node in the device tree be the proper solution here? Hardcoding addresses for devices Probably. I guess you don't want to pass that info _directly_ to the mv643xx_eth driver, though -- since the on-chip SRAM can be used for many things, and you're not necessarily sure that the user wants to use it for descriptors. (Or how much of it they want to use for descriptors.) (Or for the descriptors of which of the 8 possible transmit and receive queues, considering the 2.6.27 driver supports multiple queues.) Well, I'm not sure what the best solution is. :-) In my view... an sram node (it would be /buildin/sram on Pegasos) which defines the location of sram. In the mv643xx_eth driver you'd check if you're on Pegasos and set it up, which is what the extra code amounts to anyway. It just reduces the need to have this address hardcoded in the kernel. Or, perhaps an sram driver - like the sram driver on the MPC5200B which BestComm relies on. It's simply an rheap wrapper and a few extra bobbins to find the base address and suchlike from the device tree. I'm surprised there isn't a generic sram framework in the same way there is now a generic GPIO framework. Using rheap allocators and a generic API you can mark every sram allocation to the owner module/usage.. I don't have a Pegasos running right now to test but I will, as soon as possible, make sure this works first. Cool, thanks. It would be nice if you could give the driver in 2.6.27-rc5 a spin, it has seen a _lot_ of changes since 2.6.25 and I'd really like to make sure it still works on Pegasos. I will definitely give it a try, time permitting. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] ehea: Fix DLPAR memory handling
The ehea busmap must be allocated only once in the first of many calls of the ehea_create_busmap_callback. Signed-off-by: Hannes Hering [EMAIL PROTECTED] --- diff -Nurp -X dontdiff linux-2.6.27-rc5/drivers/net/ehea/ehea_qmr.c patched_kernel/drivers/net/ehea/ehea_qmr.c --- linux-2.6.27-rc5/drivers/net/ehea/ehea_qmr.c2008-08-29 00:52:02.0 +0200 +++ patched_kernel/drivers/net/ehea/ehea_qmr.c 2008-09-05 15:31:30.0 +0200 @@ -595,7 +595,8 @@ static int ehea_create_busmap_callback(u end_section = start_section + ((nr_pages * PAGE_SIZE) / EHEA_SECTSIZE); mr_len = *(unsigned long *)arg; - ehea_bmap = kzalloc(sizeof(struct ehea_bmap), GFP_KERNEL); + if (!ehea_bmap) + ehea_bmap = kzalloc(sizeof(struct ehea_bmap), GFP_KERNEL); if (!ehea_bmap) return -ENOMEM; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] ehea: Enable DLPAR memory remove
This patch adds the capability flag to the capability list for dynamic LPAR memory remove to enable this feature. Signed-off-by: Hannes Hering [EMAIL PROTECTED] --- diff -Nurp -X dontdiff linux-2.6.27-rc5/drivers/net/ehea/ehea.h patched_kernel/drivers/net/ehea/ehea.h --- linux-2.6.27-rc5/drivers/net/ehea/ehea.h2008-08-29 00:52:02.0 +0200 +++ patched_kernel/drivers/net/ehea/ehea.h 2008-09-05 15:33:12.0 +0200 @@ -40,13 +40,13 @@ #include asm/io.h #define DRV_NAME ehea -#define DRV_VERSIONEHEA_0092 +#define DRV_VERSIONEHEA_0093 /* eHEA capability flags */ #define DLPAR_PORT_ADD_REM 1 #define DLPAR_MEM_ADD 2 #define DLPAR_MEM_REM 4 -#define EHEA_CAPABILITIES (DLPAR_PORT_ADD_REM | DLPAR_MEM_ADD) +#define EHEA_CAPABILITIES (DLPAR_PORT_ADD_REM | DLPAR_MEM_ADD | DLPAR_MEM_REM) #define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \ | NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [RFC] adding hwmon support to sequoia device tree
Yes, the ad7414 driver was finally accepted into the kernel. The ad7414 is a
generic temperature chip.
FWIW, the warp.dts uses [EMAIL PROTECTED], not hwmon.
Cheers,
Sean
-Original Message-
From: [EMAIL PROTECTED] on behalf of Matthias Fuchs
Sent: Thu 9/4/2008 10:28 AM
To: Josh Boyer
Cc: linuxppc-dev@ozlabs.org
Subject:Re: [RFC] adding hwmon support to sequoia device tree
Hi,
On Thursday 04 September 2008 14:25, Josh Boyer wrote:
On Thu, Sep 04, 2008 at 11:55:02AM +0200, Matthias Fuchs wrote:
Hi,
I added support for the Sequoia on-board I2C temperature sensor to the
device.
I am not sure if there is any node naming convention for such devices.
The needed I2C driver can be found under drivers/hwmon in the kernel sources,
so I found hwmon suitable for the node.
Do we want to add this to the sequoia dts file? If this is how it should be
done,
I will commit a proper patch.
See comments below. Out of curiosity, do you have a working driver and
setup with this?
Of course.
You need
CONFIG_HWMON=y
CONFIG_SENSORS_AD7414=y
Via sysfs you get:
sequoia:~# cat /sys/bus/i2c/devices/0-0048/temp1_input
34750
sequoia:~# cat /sys/class/hwmon/hwmon0/device/temp1_input
34750
sequoia:~#
34750 = 34.75°C
diff --git a/arch/powerpc/boot/dts/sequoia.dts
b/arch/powerpc/boot/dts/sequoia.dts
index 72d15f0..82fdfdf 100644
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -246,13 +246,23 @@
};
IIC0: [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
compatible = ibm,iic-440epx, ibm,iic;
reg = 0xef600700 0x0014;
interrupt-parent = UIC0;
interrupts = 0x2 0x4;
+
+ [EMAIL PROTECTED] {
+ device_type = hwmon;
We don't need device_type. Particularly not a new one like this.
I will remove that.
+ compatible = analog,ad7414;
Perhaps 'compatible = analog,ad7417, amcc,hwmon-440epx;'
It has nothing to do with either AMCC or 440EPx.
Patch is on the way.
Matthias
___
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/44x: Add hwmon support to Sequoia device tree
Hi,
I was inspired by some I2C RTC node (tqm5200.dts). Those nodes
are named [EMAIL PROTECTED] But to be in common I can change it. Also
the vendor is differnet in warp's dts file. adi (analog device inc.) against
analog.
So I will update my patch to be compatible with warp.dts.
I keep your ack, Stefan.
Matthias
On Friday 05 September 2008 12:19, Stefan Roese wrote:
diff --git a/arch/powerpc/boot/dts/sequoia.dts
b/arch/powerpc/boot/dts/sequoia.dts index 72d15f0..9ba5def 100644
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -246,13 +246,22 @@
};
IIC0: [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
compatible = ibm,iic-440epx, ibm,iic;
reg = 0xef600700 0x0014;
interrupt-parent = UIC0;
interrupts = 0x2 0x4;
+
+ [EMAIL PROTECTED] {
Not sure if we shouldn't use
[EMAIL PROTECTED] {
here. This is the way it is already done in warp.dts.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: gpio driver for mpc831x/834x/837x with OF bindings
Structured similar to the existing QE GPIO support.
Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
---
.../powerpc/dts-bindings/fsl/83xx_gpio.txt | 33 +
arch/powerpc/sysdev/Kconfig|9 ++
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/mpc83xx_gpio.c | 141
4 files changed, 184 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/fsl/83xx_gpio.txt
create mode 100644 arch/powerpc/sysdev/mpc83xx_gpio.c
diff --git a/Documentation/powerpc/dts-bindings/fsl/83xx_gpio.txt
b/Documentation/powerpc/dts-bindings/fsl/83xx_gpio.txt
new file mode 100644
index 000..f43f048
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/83xx_gpio.txt
@@ -0,0 +1,33 @@
+GPIO controllers on MPC831x/834x/837x SoCs
+
+Every GPIO controller node must have #gpio-cells property defined,
+this information will be used to translate gpio-specifiers.
+
+Required properties:
+- compatible : fsl,mpc8349-gpio
+- #gpio-cells : Should be two. The first cell is the pin number and the
+ second cell is used to specify optional parameters (currently unused).
+ - interrupts : Interrupt mapping for GPIO IRQ (currently unused).
+ - interrupt-parent : Phandle for the interrupt controller that
+ services interrupts for this device.
+- gpio-controller : Marks the port as GPIO controller.
+
+Example of gpio-controller nodes for a MPC8349 SoC:
+
+ gpio1: [EMAIL PROTECTED] {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8349-gpio;
+ reg = 0xc00 0x100;
+ interrupts = 74 0x8;
+ interrupt-parent = ipic;
+ gpio-controller;
+ };
+
+ gpio2: [EMAIL PROTECTED] {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8349-gpio;
+ reg = 0xd00 0x100;
+ interrupts = 75 0x8;
+ interrupt-parent = ipic;
+ gpio-controller;
+ };
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 72fb35b..d28c3c5 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -6,3 +6,12 @@ config PPC4xx_PCI_EXPRESS
bool
depends on PCI 4xx
default n
+
+config MPC83xx_GPIO
+ bool MPC83xx GPIO support
+ depends on PPC_MPC831x || PPC_MPC834x || PPC_MPC837x
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
+ help
+ Say Y here if you're going to use hardware that connects to the
+ MPC831x/834x/837x GPIOs.
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index a90054b..ced5793 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
+obj-$(CONFIG_MPC83xx_GPIO) += mpc83xx_gpio.o
obj-$(CONFIG_RAPIDIO) += fsl_rio.o
obj-$(CONFIG_TSI108_BRIDGE)+= tsi108_pci.o tsi108_dev.o
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
diff --git a/arch/powerpc/sysdev/mpc83xx_gpio.c
b/arch/powerpc/sysdev/mpc83xx_gpio.c
new file mode 100644
index 000..a8a132d
--- /dev/null
+++ b/arch/powerpc/sysdev/mpc83xx_gpio.c
@@ -0,0 +1,141 @@
+/*
+ * GPIOs on MPC831x/834x/837x
+ *
+ * Copyright (C) 2008 Peter Korsgaard [EMAIL PROTECTED]
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/spinlock.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/gpio.h
+
+#define GPIO_DIR 0x00
+#define GPIO_ODR 0x04
+#define GPIO_DAT 0x08
+#define GPIO_IER 0x0c
+#define GPIO_IMR 0x10
+#define GPIO_ICR 0x14
+
+struct mpc83xx_gpio_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+};
+
+static inline struct mpc83xx_gpio_chip *
+to_mpc83xx_gpio_chip(struct of_mm_gpio_chip *mm)
+{
+ return container_of(mm, struct mpc83xx_gpio_chip, mm_gc);
+}
+
+static int mpc83xx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
+ u32 bit = 1u (31-gpio);
+
+ return !!(in_be32(mm-regs + GPIO_DAT) bit);
+}
+
+static void mpc83xx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
+ struct mpc83xx_gpio_chip *mpc83xx_gc = to_mpc83xx_gpio_chip(mm);
+ unsigned long flags;
+ u32 data, bit = 1u (31-gpio);
+
+ spin_lock_irqsave(mpc83xx_gc-lock, flags);
+
+ data = in_be32(mm-regs + GPIO_DAT);
+ if (val)
+ data |= bit;
+ else
+ data = ~bit;
+
Re: [RFC][USB] powerpc: Workaround for the PPC440EPX USBH_23 errata
On Fri, 5 Sep 2008, Vitaly Bordug wrote: Not every hub will work (none of available did so far), and it is often not an option for embedded device without rewiring. It's odd that your hubs don't work. What's wrong with them? well, they do not have transaction translators then. Nothing really wrong No. If the hubs run at high speed then they must have transaction translators; it's required by the USB 2.0 specification. Did you try using them with ohci-hcd not loaded? Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/44x: Add hwmon support to Sequoia device tree
On Fri, Sep 05, 2008 at 12:19:43PM +0200, Stefan Roese wrote:
+
+ [EMAIL PROTECTED] {
Not sure if we shouldn't use
[EMAIL PROTECTED] {
here. This is the way it is already done in warp.dts.
We shouldn't. Node names are supposed to be generic:
http://playground.sun.com/1275/practice/gnames/gnamv14a.html
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: gpio driver for mpc831x/834x/837x with OF bindings
On Fri, Sep 05, 2008 at 05:08:47PM +0200, Peter Korsgaard wrote:
Structured similar to the existing QE GPIO support.
Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
---
I posted identical driver in June. ;-)
http://ozlabs.org/pipermail/linuxppc-dev/2008-June/057395.html
.../powerpc/dts-bindings/fsl/83xx_gpio.txt | 33 +
arch/powerpc/sysdev/Kconfig|9 ++
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/mpc83xx_gpio.c | 141
4 files changed, 184 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/fsl/83xx_gpio.txt
create mode 100644 arch/powerpc/sysdev/mpc83xx_gpio.c
diff --git a/Documentation/powerpc/dts-bindings/fsl/83xx_gpio.txt
b/Documentation/powerpc/dts-bindings/fsl/83xx_gpio.txt
new file mode 100644
index 000..f43f048
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/83xx_gpio.txt
@@ -0,0 +1,33 @@
+GPIO controllers on MPC831x/834x/837x SoCs
+
+Every GPIO controller node must have #gpio-cells property defined,
+this information will be used to translate gpio-specifiers.
+
+Required properties:
+- compatible : fsl,mpc8349-gpio
+- #gpio-cells : Should be two. The first cell is the pin number and the
+ second cell is used to specify optional parameters (currently unused).
+ - interrupts : Interrupt mapping for GPIO IRQ (currently unused).
+ - interrupt-parent : Phandle for the interrupt controller that
+ services interrupts for this device.
+- gpio-controller : Marks the port as GPIO controller.
+
+Example of gpio-controller nodes for a MPC8349 SoC:
+
+ gpio1: [EMAIL PROTECTED] {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8349-gpio;
+ reg = 0xc00 0x100;
+ interrupts = 74 0x8;
+ interrupt-parent = ipic;
+ gpio-controller;
+ };
+
+ gpio2: [EMAIL PROTECTED] {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8349-gpio;
+ reg = 0xd00 0x100;
+ interrupts = 75 0x8;
+ interrupt-parent = ipic;
+ gpio-controller;
+ };
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 72fb35b..d28c3c5 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -6,3 +6,12 @@ config PPC4xx_PCI_EXPRESS
bool
depends on PCI 4xx
default n
+
+config MPC83xx_GPIO
+ bool MPC83xx GPIO support
+ depends on PPC_MPC831x || PPC_MPC834x || PPC_MPC837x
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
+ help
+ Say Y here if you're going to use hardware that connects to the
+ MPC831x/834x/837x GPIOs.
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index a90054b..ced5793 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_FSL_PCI)+= fsl_pci.o $(fsl-msi-obj-y)
obj-$(CONFIG_FSL_LBC)+= fsl_lbc.o
obj-$(CONFIG_FSL_GTM)+= fsl_gtm.o
+obj-$(CONFIG_MPC83xx_GPIO) += mpc83xx_gpio.o
obj-$(CONFIG_RAPIDIO)+= fsl_rio.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
diff --git a/arch/powerpc/sysdev/mpc83xx_gpio.c
b/arch/powerpc/sysdev/mpc83xx_gpio.c
new file mode 100644
index 000..a8a132d
--- /dev/null
+++ b/arch/powerpc/sysdev/mpc83xx_gpio.c
@@ -0,0 +1,141 @@
+/*
+ * GPIOs on MPC831x/834x/837x
+ *
+ * Copyright (C) 2008 Peter Korsgaard [EMAIL PROTECTED]
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/spinlock.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/gpio.h
+
+#define GPIO_DIR 0x00
+#define GPIO_ODR 0x04
+#define GPIO_DAT 0x08
+#define GPIO_IER 0x0c
+#define GPIO_IMR 0x10
+#define GPIO_ICR 0x14
+
+struct mpc83xx_gpio_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+};
+
+static inline struct mpc83xx_gpio_chip *
+to_mpc83xx_gpio_chip(struct of_mm_gpio_chip *mm)
+{
+ return container_of(mm, struct mpc83xx_gpio_chip, mm_gc);
+}
+
+static int mpc83xx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
+ u32 bit = 1u (31-gpio);
+
+ return !!(in_be32(mm-regs + GPIO_DAT) bit);
+}
+
+static void mpc83xx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int
val)
+{
+ struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
+ struct mpc83xx_gpio_chip *mpc83xx_gc = to_mpc83xx_gpio_chip(mm);
+
Re: [PATCH]: [MPC5200] Add ATA DMA support
Tim Yamin-2 wrote:
On Wed, Aug 13, 2008 at 7:11 AM, Grant Likely [EMAIL PROTECTED]
wrote:
Sounds good to me. You will get more testers that way. I can pick it
up for -next if everything else looks good.
Here are the new patches; tested against 2.6.27-rc3.
Thanks,
Tim
I have been trying this patch against 2.6.26.3 on our own MPC5200B based
board. I am using a seagate ST980815A. The drive mounts O.K, and I can
transfer small files, but during large transfers there is the following
problem.
.
## Booting kernel from Legacy Image at 0050 ...
Image Name: Linux-2.6.26.3
Created: 2008-09-05 17:01:31 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:1409558 Bytes = 1.3 MB
Load Address:
Entry Point:
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Flattened Device Tree blob at 0040
Booting using the fdt blob at 0x40
[0.00] Using m9000 machine description
[0.00] Linux version 2.6.26.3 ([EMAIL PROTECTED]) (gcc version
4.1.2) #2 Fri Sep 5 13:01:26 EDT 2008
[0.00] Zone PFN ranges:
[0.00] DMA 0 -32767
[0.00] Normal 32767 -32767
[0.796907] Driver 'sd' needs updating - please use bus_type methods
[0.803944] ata: MPC52xx IDE/ATA libata driver
[0.809300] scsi0 : mpc52xx_ata
[0.813246] ata1: PATA max UDMA/33 ata_regs 0xf0003a00 irq 135
[0.980196] ata1.00: ATA-6: ST980815A, 3.ALC, max UDMA/100
[0.985864] ata1.00: 156301488 sectors, multi 0: LBA48
[1.004074] ata1.00: configured for UDMA/33
[1.009047] scsi 0:0:0:0: Direct-Access ATA ST980815A
3.AL PQ: 0 ANSI: 5
[1.018652] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026
MB)
[1.026104] sd 0:0:0:0: [sda] Write Protect is off
[1.031419] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[1.041235] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026
MB)
[1.048681] sd 0:0:0:0: [sda] Write Protect is off
[1.053994] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[1.063308] sda: unknown partition table
[1.077092] sd 0:0:0:0: [sda] Attached SCSI disk
...
-sh-2.05b#
-sh-2.05b# cp test.txt /mnt/hd/writetest
-sh-2.05b# cp test2.txt /mnt/hd/writetest
-sh-2.05b# cp -R /test /mnt/hd/writetest
[ 170.239726] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[ 170.247020] ata1.00: cmd ca/00:18:30:00:00/00:00:00:00:00/e0 tag 0 dma
12288 out
[ 170.247033] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
[ 170.262180] ata1.00: status: { DRDY }
[ 170.265995] ata1: soft resetting link
[ 170.423867] ata1.00: revalidation failed (errno=-2)
[ 170.428902] ata1: failed to recover some devices, retrying in 5 secs
[ 175.435694] ata1: soft resetting link
[ 175.591873] ata1.00: revalidation failed (errno=-2)
[ 175.596909] ata1: failed to recover some devices, retrying in 5 secs
[ 180.603697] ata1: soft resetting link
[ 180.759873] ata1.00: revalidation failed (errno=-2)
[ 180.764907] ata1.00: disabled
[ 181.271725] ata1: soft resetting link
[ 181.427741] ata1: EH complete
[ 181.430856] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
[ 181.437358] end_request: I/O error, dev sda, sector 48
[ 181.442652] Buffer I/O error on device sda, logical block 6
[ 181.448386] lost page write due to I/O error on sda
[ 181.453429] Buffer I/O error on device sda, logical block 7
[ 181.459165] lost page write due to I/O error on sda
[ 181.464205] Buffer I/O error on device sda, logical block 8
[ 181.469939] lost page write due to I/O error on sda
[ 181.475076] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
[ 181.481580] end_request: I/O error, dev sda, sector 8
[ 181.486782] Buffer I/O error on device sda, logical block 1
[ 181.492515] lost page write due to I/O error on sda
[ 181.497653] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
[ 181.504158] end_request: I/O error, dev sda, sector 0
[ 181.509361] Buffer I/O error on device sda, logical block 0
[ 181.515091] lost page write due to I/O error on sda
[ 181.520252] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
[ 181.526762] end_request: I/O error, dev sda, sector 180232
[ 181.532441] Buffer I/O error on device sda, logical block 22540
[ 181.538534] lost page write due to I/O error on sda
[ 181.543784] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
[ 181.550259] end_request: I/O error, dev sda, sector 180328
[ 181.556223] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
[ 181.562707] end_request: I/O error, dev sda, sector 181352
[ 181.568659] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
[ 181.575144] end_request: I/O error, dev sda, sector 182376
[ 181.581094] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
[ 181.587579]
Re: [PATCH] powerpc: gpio driver for mpc831x/834x/837x with OF bindings
Anton == Anton Vorontsov [EMAIL PROTECTED] writes: Anton On Fri, Sep 05, 2008 at 05:08:47PM +0200, Peter Korsgaard wrote: Structured similar to the existing QE GPIO support. Signed-off-by: Peter Korsgaard [EMAIL PROTECTED] --- Anton I posted identical driver in June. ;-) Anton http://ozlabs.org/pipermail/linuxppc-dev/2008-June/057395.html Ahh, I must have missed it back then. Seems like you never got any feedback on it - Now, as we both independently got to ~same result, it must be a good approach ;) Kumar, what do you say? From a quick look, your driver seems to set the data / direction registers in the wrong order in fsl_gpio_dir_out causing a glitch with high level outputs: http://peter.korsgaard.com/patches/uboot/mpc83xx-gpio-level-before-direction.patch (Never seems to have made it to the U-Boot list archive, but it's in git now). -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 2/4] powerpc: Fixes for CONFIG_PTE_64BIT for SMP support
On Sep 3, 2008, at 10:12 PM, Benjamin Herrenschmidt wrote: On Wed, 2008-09-03 at 13:09 -0500, Kumar Gala wrote: There are some minor issues with support 64-bit PTEs on a 32-bit processor when dealing with SMP. * We need to order the stores in set_pte_at to make sure the flag word is set second. * Change pte_clear to use pte_update so only the flag word is cleared Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Fixed pte_clear to not break on 6xx. Thanks :-) static inline unsigned long long pte_update(pte_t *p, unsigned long clr, unsigned long set) @@ -658,8 +656,17 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr, #if _PAGE_HASHPTE != 0 pte_update(ptep, ~_PAGE_HASHPTE, pte_val(pte) ~_PAGE_HASHPTE); #else +#if defined(CONFIG_PTE_64BIT) defined(CONFIG_SMP) Minor nit, but there's #elif :-) + __asm__ __volatile__(\ + stw%U0%X0 %2,%0\n\ + eieio\n\ + stw%U0%X0 %L2,%1 + : =m (*ptep), =m (*((unsigned char *)ptep+4)) + : r (pte) : memory); Any reason why it has to be in assembly ? Can gcc re-order stores around eieio() if written in C ? I would hope not but heh ... it's gcc :-) I'm leaving it asm. Its more explicit and easier to read in my opinion and I don't give gcc a chance to screw us over. I also wonder if you should first ensure that the PTE is invalid and if not, clear it and flush the TLB page ... Or at least add a WARN_ON(pte_valid()) in case we get that wrong ... I believe that's an issue since kmap_atomic() will call set_pte_at and have the valid bit set. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: gpio driver for mpc831x/834x/837x with OF bindings
On Fri, Sep 05, 2008 at 08:45:33PM +0200, Peter Korsgaard wrote: Anton == Anton Vorontsov [EMAIL PROTECTED] writes: Anton On Fri, Sep 05, 2008 at 05:08:47PM +0200, Peter Korsgaard wrote: Structured similar to the existing QE GPIO support. Signed-off-by: Peter Korsgaard [EMAIL PROTECTED] --- Anton I posted identical driver in June. ;-) Anton http://ozlabs.org/pipermail/linuxppc-dev/2008-June/057395.html Ahh, I must have missed it back then. Seems like you never got any feedback on it - Now, as we both independently got to ~same result, it must be a good approach ;) Kumar, what do you say? From a quick look, your driver seems to set the data / direction registers in the wrong order in fsl_gpio_dir_out causing a glitch with high level outputs: http://peter.korsgaard.com/patches/uboot/mpc83xx-gpio-level-before-direction.patch (Never seems to have made it to the U-Boot list archive, but it's in git now). Yeah, I saw similar patch in the u-boot-users mailing list. Will incorporate that change, thanks! -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 2/4] powerpc: Fixes for CONFIG_PTE_64BIT for SMP support
On Fri, 2008-09-05 at 14:44 -0500, Kumar Gala wrote: I also wonder if you should first ensure that the PTE is invalid and if not, clear it and flush the TLB page ... Or at least add a WARN_ON(pte_valid()) in case we get that wrong ... I believe that's an issue since kmap_atomic() will call set_pte_at and have the valid bit set. Hrm... on the other hand, it's safe because kmap_atomic() is per-CPU and thus won't race with anything... On the other hand, if others (mprotect, mremap, whoever...) does it, it's not safe. I'm keen on letting set_pte_at() to the job and maybe if we can remove the explicit flush kmap_atomic does... Though it's not totally trivial to know it's a flush that doesn't need global invalidations... May be worth moving your current stuff into a __set_pte_at() that you use from kmap atomic, and have set_pte_at() wrap that along with a present warn. That would do for the time being. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ibm_newemac: Add support for GPCS, SGMII and M88E1112 PHY
From: Victor Gallardo [EMAIL PROTECTED]
This patch adds GPCS, SGMII and M88E1112 PHY support
for the AMCC PPC460GT/EX processors.
Signed-off-by: Victor Gallardo [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/core.c | 40 +++
drivers/net/ibm_newemac/core.h |3 +
drivers/net/ibm_newemac/phy.c | 84
drivers/net/ibm_newemac/phy.h |2 +
4 files changed, 120 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 2e720f2..cef76fe 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -201,13 +201,15 @@ static inline int emac_phy_supports_gige(int phy_mode)
{
return phy_mode == PHY_MODE_GMII ||
phy_mode == PHY_MODE_RGMII ||
+ phy_mode == PHY_MODE_SGMII ||
phy_mode == PHY_MODE_TBI ||
phy_mode == PHY_MODE_RTBI;
}
static inline int emac_phy_gpcs(int phy_mode)
{
- return phy_mode == PHY_MODE_TBI ||
+ return phy_mode == PHY_MODE_SGMII ||
+ phy_mode == PHY_MODE_TBI ||
phy_mode == PHY_MODE_RTBI;
}
@@ -547,8 +549,9 @@ static int emac_configure(struct emac_instance *dev)
switch (dev-phy.speed) {
case SPEED_1000:
if (emac_phy_gpcs(dev-phy.mode)) {
- mr1 |= EMAC_MR1_MF_1000GPCS |
- EMAC_MR1_MF_IPPA(dev-phy.address);
+ mr1 |= EMAC_MR1_MF_1000GPCS | EMAC_MR1_MF_IPPA(
+ (dev-phy.gpcs_address != 0x) ?
+dev-phy.gpcs_address : dev-phy.address);
/* Put some arbitrary OUI, Manuf Rev IDs so we can
* identify this GPCS PHY later.
@@ -660,8 +663,12 @@ static int emac_configure(struct emac_instance *dev)
out_be32(p-iser, r);
/* We need to take GPCS PHY out of isolate mode after EMAC reset */
- if (emac_phy_gpcs(dev-phy.mode))
- emac_mii_reset_phy(dev-phy);
+ if (emac_phy_gpcs(dev-phy.mode)) {
+ if (dev-phy.gpcs_address != 0x)
+ emac_mii_reset_gpcs(dev-phy);
+ else
+ emac_mii_reset_phy(dev-phy);
+ }
/* Required for Pause packet support in EMAC */
dev_mc_add(ndev, default_mcast_addr, sizeof(default_mcast_addr), 1);
@@ -869,7 +876,9 @@ static int emac_mdio_read(struct net_device *ndev, int id,
int reg)
struct emac_instance *dev = netdev_priv(ndev);
int res;
- res = __emac_mdio_read(dev-mdio_instance ? dev-mdio_instance : dev,
+ res = __emac_mdio_read((dev-mdio_instance
+ dev-phy.gpcs_address != id) ?
+ dev-mdio_instance : dev,
(u8) id, (u8) reg);
return res;
}
@@ -878,7 +887,9 @@ static void emac_mdio_write(struct net_device *ndev, int
id, int reg, int val)
{
struct emac_instance *dev = netdev_priv(ndev);
- __emac_mdio_write(dev-mdio_instance ? dev-mdio_instance : dev,
+ __emac_mdio_write((dev-mdio_instance
+ dev-phy.gpcs_address != id) ?
+ dev-mdio_instance : dev,
(u8) id, (u8) reg, (u16) val);
}
@@ -2367,7 +2378,11 @@ static int __devinit emac_init_phy(struct emac_instance
*dev)
* XXX I probably should move these settings to the dev tree
*/
dev-phy.address = -1;
- dev-phy.features = SUPPORTED_100baseT_Full | SUPPORTED_MII;
+ dev-phy.features = SUPPORTED_MII;
+ if (emac_phy_supports_gige(dev-phy_mode))
+ dev-phy.features |= SUPPORTED_1000baseT_Full;
+ else
+ dev-phy.features |= SUPPORTED_100baseT_Full;
dev-phy.pause = 1;
return 0;
@@ -2406,7 +2421,9 @@ static int __devinit emac_init_phy(struct emac_instance
*dev)
* Note that the busy_phy_map is currently global
* while it should probably be per-ASIC...
*/
- dev-phy.address = dev-cell_index;
+ dev-phy.gpcs_address = dev-gpcs_address;
+ if (dev-phy.gpcs_address == 0x)
+ dev-phy.address = dev-cell_index;
}
emac_configure(dev);
@@ -2516,6 +2533,8 @@ static int __devinit emac_init_config(struct
emac_instance *dev)
dev-phy_address = 0x;
if (emac_read_uint_prop(np, phy-map, dev-phy_map, 0))
dev-phy_map = 0x;
+ if (emac_read_uint_prop(np, gpcs-address, dev-gpcs_address, 0))
+ dev-gpcs_address = 0x;
if (emac_read_uint_prop(np-parent, clock-frequency,
dev-opb_bus_freq, 1))
return -ENXIO;
[PATCH] ibm_newemac: Add support for GPCS, SGMII and M88E1112 PHY
This patch adds GPCS, SGMII and M88E1112 PHY support
for the AMCC PPC460GT/EX processors.
Signed-off-by: Victor Gallardo [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/core.c | 40 +++
drivers/net/ibm_newemac/core.h |3 +
drivers/net/ibm_newemac/phy.c | 84
drivers/net/ibm_newemac/phy.h |2 +
4 files changed, 120 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 2e720f2..cef76fe 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -201,13 +201,15 @@ static inline int emac_phy_supports_gige(int phy_mode)
{
return phy_mode == PHY_MODE_GMII ||
phy_mode == PHY_MODE_RGMII ||
+ phy_mode == PHY_MODE_SGMII ||
phy_mode == PHY_MODE_TBI ||
phy_mode == PHY_MODE_RTBI;
}
static inline int emac_phy_gpcs(int phy_mode)
{
- return phy_mode == PHY_MODE_TBI ||
+ return phy_mode == PHY_MODE_SGMII ||
+ phy_mode == PHY_MODE_TBI ||
phy_mode == PHY_MODE_RTBI;
}
@@ -547,8 +549,9 @@ static int emac_configure(struct emac_instance *dev)
switch (dev-phy.speed) {
case SPEED_1000:
if (emac_phy_gpcs(dev-phy.mode)) {
- mr1 |= EMAC_MR1_MF_1000GPCS |
- EMAC_MR1_MF_IPPA(dev-phy.address);
+ mr1 |= EMAC_MR1_MF_1000GPCS | EMAC_MR1_MF_IPPA(
+ (dev-phy.gpcs_address != 0x) ?
+dev-phy.gpcs_address : dev-phy.address);
/* Put some arbitrary OUI, Manuf Rev IDs so we can
* identify this GPCS PHY later.
@@ -660,8 +663,12 @@ static int emac_configure(struct emac_instance *dev)
out_be32(p-iser, r);
/* We need to take GPCS PHY out of isolate mode after EMAC reset */
- if (emac_phy_gpcs(dev-phy.mode))
- emac_mii_reset_phy(dev-phy);
+ if (emac_phy_gpcs(dev-phy.mode)) {
+ if (dev-phy.gpcs_address != 0x)
+ emac_mii_reset_gpcs(dev-phy);
+ else
+ emac_mii_reset_phy(dev-phy);
+ }
/* Required for Pause packet support in EMAC */
dev_mc_add(ndev, default_mcast_addr, sizeof(default_mcast_addr), 1);
@@ -869,7 +876,9 @@ static int emac_mdio_read(struct net_device *ndev, int id,
int reg)
struct emac_instance *dev = netdev_priv(ndev);
int res;
- res = __emac_mdio_read(dev-mdio_instance ? dev-mdio_instance : dev,
+ res = __emac_mdio_read((dev-mdio_instance
+ dev-phy.gpcs_address != id) ?
+ dev-mdio_instance : dev,
(u8) id, (u8) reg);
return res;
}
@@ -878,7 +887,9 @@ static void emac_mdio_write(struct net_device *ndev, int
id, int reg, int val)
{
struct emac_instance *dev = netdev_priv(ndev);
- __emac_mdio_write(dev-mdio_instance ? dev-mdio_instance : dev,
+ __emac_mdio_write((dev-mdio_instance
+ dev-phy.gpcs_address != id) ?
+ dev-mdio_instance : dev,
(u8) id, (u8) reg, (u16) val);
}
@@ -2367,7 +2378,11 @@ static int __devinit emac_init_phy(struct emac_instance
*dev)
* XXX I probably should move these settings to the dev tree
*/
dev-phy.address = -1;
- dev-phy.features = SUPPORTED_100baseT_Full | SUPPORTED_MII;
+ dev-phy.features = SUPPORTED_MII;
+ if (emac_phy_supports_gige(dev-phy_mode))
+ dev-phy.features |= SUPPORTED_1000baseT_Full;
+ else
+ dev-phy.features |= SUPPORTED_100baseT_Full;
dev-phy.pause = 1;
return 0;
@@ -2406,7 +2421,9 @@ static int __devinit emac_init_phy(struct emac_instance
*dev)
* Note that the busy_phy_map is currently global
* while it should probably be per-ASIC...
*/
- dev-phy.address = dev-cell_index;
+ dev-phy.gpcs_address = dev-gpcs_address;
+ if (dev-phy.gpcs_address == 0x)
+ dev-phy.address = dev-cell_index;
}
emac_configure(dev);
@@ -2516,6 +2533,8 @@ static int __devinit emac_init_config(struct
emac_instance *dev)
dev-phy_address = 0x;
if (emac_read_uint_prop(np, phy-map, dev-phy_map, 0))
dev-phy_map = 0x;
+ if (emac_read_uint_prop(np, gpcs-address, dev-gpcs_address, 0))
+ dev-gpcs_address = 0x;
if (emac_read_uint_prop(np-parent, clock-frequency,
dev-opb_bus_freq, 1))
return -ENXIO;
if (emac_read_uint_prop(np,
Re: [PATCH] powerpc/44x: Add hwmon support to Sequoia device tree
On Fri, 5 Sep 2008 11:00:18 -0500
Scott Wood [EMAIL PROTECTED] wrote:
On Fri, Sep 05, 2008 at 12:19:43PM +0200, Stefan Roese wrote:
+
+ [EMAIL PROTECTED] {
Not sure if we shouldn't use
[EMAIL PROTECTED] {
here. This is the way it is already done in warp.dts.
We shouldn't. Node names are supposed to be generic:
http://playground.sun.com/1275/practice/gnames/gnamv14a.html
Damn. Where were you a year ago when I first introduced this? ;)
And if it is really supposed to be generic, would [EMAIL PROTECTED] be a
better name since this is basically a generic temperature chip?
Now that the i2c driver is a full of platform driver, I think I
can change the name with no repercussions. So I can live with whatever
decision is made. Can't do anything about the systems that are out in
the field though
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2] ftrace: fixes for PPC
I spent the day chasing a bug that would hang PPC on boot up when ftrace is configured in. I found that it was simply a stupid bug I did to handle the non MCOUNT_RECORD case. Since I was testing only on x86, and the MCOUNT_RECORD is automatically set for dynamic ftrace if it is available, I did not test the case where MCOUNT_RECORD was not set. I have not finished porting MCOUNT_RECORD to PPC, but have found that it has caused some issues for archs that do not support it yet. This patch series handles these cases. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] ftrace: use ftrace_release for all dynamic ftrace functions
ftrace_release is necessary for all uses of dynamic ftrace and not just
the archs that have CONFIG_FTRACE_MCOUNT_RECORD defined.
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
include/linux/ftrace.h |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
Index: linux-tip.git/include/linux/ftrace.h
===
--- linux-tip.git.orig/include/linux/ftrace.h 2008-09-05 16:04:34.0
-0700
+++ linux-tip.git/include/linux/ftrace.h2008-09-05 20:10:47.0
-0700
@@ -77,8 +77,10 @@ extern void mcount_call(void);
extern int skip_trace(unsigned long ip);
-void ftrace_disable_daemon(void);
-void ftrace_enable_daemon(void);
+extern void ftrace_release(void *start, unsigned long size);
+
+extern void ftrace_disable_daemon(void);
+extern void ftrace_enable_daemon(void);
#else
# define skip_trace(ip)({ 0; })
@@ -86,6 +88,7 @@ void ftrace_enable_daemon(void);
# define ftrace_set_filter(buf, len, reset)do { } while (0)
# define ftrace_disable_daemon() do { } while (0)
# define ftrace_enable_daemon()do { } while (0)
+static inline void ftrace_release(void *start, unsigned long size) { }
#endif /* CONFIG_DYNAMIC_FTRACE */
/* totally disable ftrace - can not re-enable after this */
@@ -199,12 +202,10 @@ static inline void ftrace_dump(void) { }
#ifdef CONFIG_FTRACE_MCOUNT_RECORD
extern void ftrace_init(void);
extern void ftrace_init_module(unsigned long *start, unsigned long *end);
-extern void ftrace_release(void *start, unsigned long size);
#else
static inline void ftrace_init(void) { }
static inline void
ftrace_init_module(unsigned long *start, unsigned long *end) { }
-static inline void ftrace_release(void *start, unsigned long size) { }
#endif
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
