* Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
From: Olof Johansson @ 2008-02-23 21:28 UTC (permalink / raw)
To: Jochen Friedrich
Cc: Jean Delvare, linuxppc-dev list, linux-kernel, Scott Wood, i2c
In-Reply-To: <47BEAF00.50106@scram.de>
On Fri, Feb 22, 2008 at 12:16:16PM +0100, Jochen Friedrich wrote:
> Fortunately, I2c no longer uses numeric device IDs but names. So what are the alternatives?
>
> 1. modify the I2c subsystem to accept OF names additionally to I2c names (proposed by Jon smirl).
Sounds like Jean isn't very excited about this idea..
> 2. record the I2c name in the dts tree, either as seperate tag (like linux,i2c-name="<i2c-name>")
> or as additional compatible entry (like compatible="...", "linux,<i2c-name>").
I have to say no on this one. The device tree is not supposed to know
about how linux uses devices, there are firmwares out there that don't
use DTS for thier device trees, etc.
> 3. use a glue layer with a translation map.
In my opinion this is an OK solution since the same information has to
be added somewhere already anyway -- eiither to the drivers or to this
translation table. It should of course be an abstacted shared table,
preferrably contained under the i2c source directories since several
platforms and architectures might share them.
-Olof
^ permalink raw reply
* [PATCH 1/2][OF] Add of_device_is_disabled function
From: Josh Boyer @ 2008-02-23 21:58 UTC (permalink / raw)
To: sfr, davem; +Cc: linuxppc-dev
IEEE 1275 defined a standard "status" property to indicate the operational
status of a device. The property has four possible values: okay, disabled,
fail, fail-xxx. The absence of this property means the operational status
of the device is unknown or okay.
This adds a function called of_device_is_disabled that checks to see if a
node has the status property set to "disabled". This can be quite useful
for devices that may be present but disabled due to pin sharing, etc.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
drivers/of/base.c | 18 ++++++++++++++++++
include/linux/of.h | 1 +
2 files changed, 19 insertions(+)
--- linux-2.6.orig/drivers/of/base.c
+++ linux-2.6/drivers/of/base.c
@@ -117,6 +117,24 @@ int of_device_is_compatible(const struct
EXPORT_SYMBOL(of_device_is_compatible);
/**
+ * of_device_is_disabled - Check if a device's status is disabled
+ * @device: device node to check
+ *
+ * Returns true or false depending on the value of the staus property
+ */
+int of_device_is_disabled(const struct device_node *device)
+{
+ const char *status;
+
+ status = of_get_property(device, "status", NULL);
+ if (status == NULL)
+ return 0;
+
+ return !(strcmp(status, "disabled"));
+}
+EXPORT_SYMBOL(of_device_is_disabled);
+
+/**
* of_get_parent - Get a node's parent if any
* @node: Node to get parent
*
--- linux-2.6.orig/include/linux/of.h
+++ linux-2.6/include/linux/of.h
@@ -62,6 +62,7 @@ extern struct property *of_find_property
int *lenp);
extern int of_device_is_compatible(const struct device_node *device,
const char *);
+extern int of_device_is_disabled(const struct device_node *device);
extern const void *of_get_property(const struct device_node *node,
const char *name,
int *lenp);
^ permalink raw reply
* [PATCH 2/2][POWERPC] Ignore disabled serial ports
From: Josh Boyer @ 2008-02-23 22:00 UTC (permalink / raw)
To: arnd; +Cc: sfr, davem, linuxppc-dev
In-Reply-To: <20080223155823.2c85d829@zod.rchland.ibm.com>
Some SoC chips have multiple serial ports on board. The usability of these
ports can rely on various factors, ranging from pin sharing to unpopulated
connectors. This uses the new of_device_is_disabled function to check for
and ignore disabled UARTs.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/kernel/legacy_serial.c | 4 ++++
drivers/serial/of_serial.c | 5 +++++
2 files changed, 9 insertions(+)
--- linux-2.6.orig/drivers/serial/of_serial.c
+++ linux-2.6/drivers/serial/of_serial.c
@@ -72,6 +72,11 @@ static int __devinit of_platform_serial_
int port_type;
int ret;
+ if (of_device_is_disabled(ofdev->node)) {
+ dev_info(&ofdev->dev, "Disabled serial port. Ignored\n");
+ return -ENODEV;
+ }
+
if (of_find_property(ofdev->node, "used-by-rtas", NULL))
return -EBUSY;
--- linux-2.6.orig/arch/powerpc/kernel/legacy_serial.c
+++ linux-2.6/arch/powerpc/kernel/legacy_serial.c
@@ -54,6 +54,10 @@ static int __init add_legacy_port(struct
u32 clock = BASE_BAUD * 16;
int index;
+ /* Check the status property if present. Ignore disabled devices */
+ if (of_device_is_disabled(np))
+ return -1;
+
/* get clock freq. if present */
clk = of_get_property(np, "clock-frequency", NULL);
if (clk && *clk)
^ permalink raw reply
* [PATCH 0/3] [POWERPC] 4xx: Add support for AMCC 440EP Yosemite board
From: Josh Boyer @ 2008-02-23 22:08 UTC (permalink / raw)
To: linuxppc-dev
This small series of patches adds support for the AMCC 440EP Yosemite
evaluation board. This is the newer evaluation board for PowerPC 440EP
chips, replacing the older Bamboo board.
This is just the initial round of patches, but they are functional.
Also of note is that while all for on-board UARTs are enumerated in the
DTS file, only two of them are usable on the board. The other two have
their "status" property set to disabled. If used in conjunction with
the of_device_is_disabled patches I just sent out, then devices for
those won't be created. This is not required.
josh
^ permalink raw reply
* [PATCH 1/3][POWERPC] 4xx: Add AMCC 440EP Yosemite DTS
From: Josh Boyer @ 2008-02-23 22:09 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080223160813.2f8d282b@zod.rchland.ibm.com>
This adds a DTS file for the AMCC 440EP Yosemite board.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/boot/dts/yosemite.dts | 306 +++++++++++++++++++++++++++++++++++++
1 file changed, 306 insertions(+)
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/dts/yosemite.dts
@@ -0,0 +1,306 @@
+/*
+ * Device Tree Source for AMCC Yosemite
+ *
+ * Copyright 2008 IBM Corp.
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * 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.
+ */
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,yosemite";
+ compatible = "amcc,yosemite","amcc,bamboo";
+ dcr-parent = <&/cpus/cpu@0>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ ethernet1 = &EMAC1;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ serial2 = &UART2;
+ serial3 = &UART3;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,440EP";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ timebase-frequency = <0>; /* Filled in by zImage */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <8000>;
+ d-cache-size = <8000>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0>; /* Filled in by zImage */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-440ep","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-440ep","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-440ep";
+ dcr-reg = <00e 002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-440ep";
+ dcr-reg = <00c 002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-440ep", "ibm,plb-440gp", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-440ep", "ibm,sdram-405gp";
+ dcr-reg = <010 2>;
+ };
+
+ DMA0: dma {
+ compatible = "ibm,dma-440ep", "ibm,dma-440gp";
+ dcr-reg = <100 027>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-440ep", "ibm,mcmal-440gp", "ibm,mcmal";
+ dcr-reg = <180 62>;
+ num-tx-chans = <4>;
+ num-rx-chans = <2>;
+ interrupt-parent = <&MAL0>;
+ interrupts = <0 1 2 3 4>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
+ /*RXEOB*/ 1 &UIC0 b 4
+ /*SERR*/ 2 &UIC1 0 4
+ /*TXDE*/ 3 &UIC1 1 4
+ /*RXDE*/ 4 &UIC1 2 4>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-440ep", "ibm,opb-440gp", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* Bamboo is oddball in the 44x world and doesn't use the ERPN
+ * bits.
+ */
+ ranges = <00000000 0 00000000 80000000
+ 80000000 0 80000000 80000000>;
+ interrupt-parent = <&UIC1>;
+ interrupts = <7 4>;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-440ep", "ibm,ebc-440gp", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ interrupts = <5 1>;
+ interrupt-parent = <&UIC1>;
+ };
+
+ UART0: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ current-speed = <1c200>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0 4>;
+ };
+
+ UART1: serial@ef600400 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600400 8>;
+ virtual-reg = <ef600400>;
+ clock-frequency = <0>;
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ UART2: serial@ef600500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600500 8>;
+ virtual-reg = <ef600500>;
+ clock-frequency = <0>;
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <3 4>;
+ status = "disabled";
+ };
+
+ UART3: serial@ef600600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600600 8>;
+ virtual-reg = <ef600600>;
+ clock-frequency = <0>;
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <4 4>;
+ status = "disabled";
+ };
+
+ IIC0: i2c@ef600700 {
+ compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
+ reg = <ef600700 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600800 {
+ compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
+ reg = <ef600800 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <7 4>;
+ };
+
+ spi@ef600900 {
+ compatible = "amcc,spi-440ep";
+ reg = <ef600900 6>;
+ interrupts = <8 4>;
+ interrupt-parent = <&UIC0>;
+ };
+
+ ZMII0: emac-zmii@ef600d00 {
+ compatible = "ibm,zmii-440ep", "ibm,zmii-440gp", "ibm,zmii";
+ reg = <ef600d00 c>;
+ };
+
+ EMAC0: ethernet@ef600e00 {
+ linux,network-index = <0>;
+ device_type = "network";
+ compatible = "ibm,emac-440ep", "ibm,emac-440gp", "ibm,emac";
+ interrupt-parent = <&UIC1>;
+ interrupts = <1c 4 1d 4>;
+ reg = <ef600e00 70>;
+ local-mac-address = [000000000000];
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0 1>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rmii";
+ phy-map = <00000000>;
+ zmii-device = <&ZMII0>;
+ zmii-channel = <0>;
+ };
+
+ EMAC1: ethernet@ef600f00 {
+ linux,network-index = <1>;
+ device_type = "network";
+ compatible = "ibm,emac-440ep", "ibm,emac-440gp", "ibm,emac";
+ interrupt-parent = <&UIC1>;
+ interrupts = <1e 4 1f 4>;
+ reg = <ef600f00 70>;
+ local-mac-address = [000000000000];
+ mal-device = <&MAL0>;
+ mal-tx-channel = <2 3>;
+ mal-rx-channel = <1>;
+ cell-index = <1>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rmii";
+ phy-map = <00000000>;
+ zmii-device = <&ZMII0>;
+ zmii-channel = <1>;
+ };
+
+ usb@ef601000 {
+ compatible = "ohci-be";
+ reg = <ef601000 80>;
+ interrupts = <8 4 9 4>;
+ interrupt-parent = < &UIC1 >;
+ };
+ };
+
+ PCI0: pci@ec000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb440ep-pci", "ibm,plb-pci";
+ primary;
+ reg = <0 eec00000 8 /* Config space access */
+ 0 eed00000 4 /* IACK */
+ 0 eed00000 4 /* Special cycle */
+ 0 ef400000 40>; /* Internal registers */
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed. Chip supports a second
+ * IO range but we don't use it for now
+ */
+ ranges = <02000000 0 a0000000 0 a0000000 0 20000000
+ 01000000 0 00000000 0 e8000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* Bamboo has all 4 IRQ pins tied together per slot */
+ interrupt-map-mask = <f800 0 0 0>;
+ interrupt-map = <
+ /* IDSEL 1 */
+ 0800 0 0 0 &UIC0 1c 8
+
+ /* IDSEL 2 */
+ 1000 0 0 0 &UIC0 1b 8
+
+ /* IDSEL 3 */
+ 1800 0 0 0 &UIC0 1a 8
+
+ /* IDSEL 4 */
+ 2000 0 0 0 &UIC0 19 8
+ >;
+ };
+ };
+
+ chosen {
+ linux,stdout-path = "/plb/opb/serial@ef600300";
+ };
+};
^ permalink raw reply
* [PATCH 2/3][POWERPC] 4xx: Add platform support for the AMCC Yosemite board
From: Josh Boyer @ 2008-02-23 22:09 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <20080223160813.2f8d282b@zod.rchland.ibm.com>
The AMCC 440EP Yosemite board is very similar to the original AMCC Bamboo
board. This adds a YOSEMITE option to Kconfig, and reuses the existing
bamboo board support in the kernel.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/platforms/44x/Kconfig | 9 +++++++++
arch/powerpc/platforms/44x/Makefile | 1 +
2 files changed, 10 insertions(+)
--- linux-2.6.orig/arch/powerpc/platforms/44x/Kconfig
+++ linux-2.6/arch/powerpc/platforms/44x/Kconfig
@@ -67,6 +67,15 @@ config WARP
See http://www.pikatechnologies.com/ and follow the "PIKA for Computer
Telephony Developers" link for more information.
+config YOSEMITE
+ bool "Yosemite"
+ depends on 44x
+ default n
+ select 440EP
+ select PCI
+ help
+ This option enables support for the AMCC PPC440EP evaluation board.
+
#config LUAN
# bool "Luan"
# depends on 44x
--- linux-2.6.orig/arch/powerpc/platforms/44x/Makefile
+++ linux-2.6/arch/powerpc/platforms/44x/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_44x) := misc_44x.o
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
+obj-$(CONFIG_YOSEMITE) += bamboo.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
^ permalink raw reply
* [PATCH 3/3][POWERPC] 4xx: Add bootwrapper for AMCC Yosemite board
From: Josh Boyer @ 2008-02-23 22:10 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080223160813.2f8d282b@zod.rchland.ibm.com>
Add the cuboot wrapper for the AMCC 440EP Yosemite board
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/boot/Makefile | 3 +-
arch/powerpc/boot/cuboot-yosemite.c | 42 ++++++++++++++++++++++++++++++++++++
2 files changed, 44 insertions(+), 1 deletion(-)
--- linux-2.6.orig/arch/powerpc/boot/Makefile
+++ linux-2.6/arch/powerpc/boot/Makefile
@@ -64,7 +64,7 @@ src-plat := of.c cuboot-52xx.c cuboot-82
cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
fixed-head.S ep88xc.c ep405.c \
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
- cuboot-warp.c cuboot-85xx-cpm2.c
+ cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -216,6 +216,7 @@ image-$(CONFIG_RAINIER) += cuImage.rai
image-$(CONFIG_TAISHAN) += cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
image-$(CONFIG_WARP) += cuImage.warp
+image-$(CONFIG_YOSEMITE) += cuImage.yosemite
# Board ports in arch/powerpc/platform/8xx/Kconfig
image-$(CONFIG_PPC_MPC86XADS) += cuImage.mpc866ads
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/cuboot-yosemite.c
@@ -0,0 +1,42 @@
+/*
+ * Old U-boot compatibility for Yosemite
+ *
+ * Author: Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * Copyright 2008 IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "4xx.h"
+#include "44x.h"
+#include "cuboot.h"
+
+#define TARGET_44x
+#include "ppcboot.h"
+
+static bd_t bd;
+
+static void yosemite_fixups(void)
+{
+ unsigned long sysclk = 66666666;
+
+ ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
+ ibm4xx_sdram_fixup_memsize();
+ ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
+ dt_fixup_mac_addresses(&bd.bi_enetaddr, &bd.bi_enet1addr);
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ platform_ops.fixups = yosemite_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+ fdt_init(_dtb_start);
+ serial_console_init();
+}
^ permalink raw reply
* Re: [PATCH 0/3] [POWERPC] 4xx: Add support for AMCC 440EP Yosemite board
From: Josh Boyer @ 2008-02-23 22:19 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080223160813.2f8d282b@zod.rchland.ibm.com>
On Sat, 23 Feb 2008 16:08:13 -0600
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> This small series of patches adds support for the AMCC 440EP Yosemite
> evaluation board. This is the newer evaluation board for PowerPC 440EP
> chips, replacing the older Bamboo board.
>
> This is just the initial round of patches, but they are functional.
> Also of note is that while all for on-board UARTs are enumerated in the
> DTS file, only two of them are usable on the board. The other two have
> their "status" property set to disabled. If used in conjunction with
> the of_device_is_disabled patches I just sent out, then devices for
> those won't be created. This is not required.
Olof asked on IRC why even bother enumerating the extra UARTs. I have
two reasons for this.
1) I want a user of the of_device_is_disabled patches, if only to show
it works and provide an example (it does work btw).
2) When I get to doing the EBC stuff for bamboo and yosemite, there are
devices that can come and go depending on dip switch settings (due to
pin sharing). My nefarious plan is to enumerate all of the devices in
the device tree, and poke a status = "disabled" property into the ones
that are no longer usable because of the dip switch settings. E.g.
EMAC1 becomes disabled if the NAND flash is enabled on Bamboo, etc.
josh
^ permalink raw reply
* Re: [PATCH 5/5] [POWERPC] Add 460EX PCIe support to 4xx pci driver
From: Paul Mackerras @ 2008-02-23 22:39 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <1203799608.6976.44.camel@pasglop>
Benjamin Herrenschmidt writes:
> Actually, the patch just adds a backend to my little framework for
> dealing with 4xx PCIe, which basically is a boring piece of code
> filling registers with values mostly from the spec... nothing really
> fancy there.
OK, then that's what the patch description should tell us...
Paul.
^ permalink raw reply
* Re: [PATCH 1/2][OF] Add of_device_is_disabled function
From: Josh Boyer @ 2008-02-24 0:59 UTC (permalink / raw)
To: sfr, davem, benh; +Cc: linuxppc-dev
In-Reply-To: <20080223155823.2c85d829@zod.rchland.ibm.com>
On Sat, 23 Feb 2008 15:58:23 -0600
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> IEEE 1275 defined a standard "status" property to indicate the operational
> status of a device. The property has four possible values: okay, disabled,
> fail, fail-xxx. The absence of this property means the operational status
> of the device is unknown or okay.
>
> This adds a function called of_device_is_disabled that checks to see if a
> node has the status property set to "disabled". This can be quite useful
> for devices that may be present but disabled due to pin sharing, etc.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Talking with Ben H a bit, he suggested to reverse this API. Basically,
create an of_device_is_available that returns 1 if the status property
is completely missing, or if it's set to "okay" or "ok". The latter is
to cope with some broken firmwares.
I can do either really. Eventually you could embed the is_available
check in the of_platform code so that devices don't even get presented
to drivers if they aren't available.
Dave, I'm not sure how applicable this all is to sparc. But for some
of the "newer" embedded ports that are coming into powerpc I can see it
being very useful.
Thoughts?
josh
^ permalink raw reply
* [PATCH][OF] Add of_device_is_available function
From: Josh Boyer @ 2008-02-24 2:23 UTC (permalink / raw)
To: sfr, davem, benh; +Cc: linuxppc-dev
In-Reply-To: <20080223185904.757c2884@zod.rchland.ibm.com>
On Sat, 23 Feb 2008 18:59:04 -0600
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Sat, 23 Feb 2008 15:58:23 -0600
> Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
>
> > IEEE 1275 defined a standard "status" property to indicate the operational
> > status of a device. The property has four possible values: okay, disabled,
> > fail, fail-xxx. The absence of this property means the operational status
> > of the device is unknown or okay.
> >
> > This adds a function called of_device_is_disabled that checks to see if a
> > node has the status property set to "disabled". This can be quite useful
> > for devices that may be present but disabled due to pin sharing, etc.
> >
> > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> Talking with Ben H a bit, he suggested to reverse this API. Basically,
> create an of_device_is_available that returns 1 if the status property
> is completely missing, or if it's set to "okay" or "ok". The latter is
> to cope with some broken firmwares.
And since I seem to be talking to myself and have nothing better to do
on a Saturday evening, here's the code.
josh
IEEE 1275 defined a standard "status" property to indicate the operational
status of a device. The property has four possible values: okay, disabled,
fail, fail-xxx. The absence of this property means the operational status
of the device is unknown or okay.
This adds a function called of_device_is_available that checks the state
of the status property of a device. If the property is absent or set to
either "okay" or "ok", it returns 1. Otherwise it returns 0.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
drivers/of/base.c | 23 +++++++++++++++++++++++
include/linux/of.h | 1 +
2 files changed, 24 insertions(+)
--- linux-2.6.orig/drivers/of/base.c
+++ linux-2.6/drivers/of/base.c
@@ -117,6 +117,29 @@ int of_device_is_compatible(const struct
EXPORT_SYMBOL(of_device_is_compatible);
/**
+ * of_device_is_available - check if a device is available for use
+ *
+ * @device: Node to check for availability
+ *
+ * Returns 1 if the status property is absent or set to "okay" or "ok",
+ * 0 otherwise
+ */
+int of_device_is_available(const struct device_node *device)
+{
+ const char *status;
+
+ status = of_get_property(device, "status", NULL);
+ if (status == NULL)
+ return 1;
+
+ if (!strcmp(status, "okay") || !strcmp(status, "ok"))
+ return 1;
+
+ return 0;
+}
+EXPORT_SYMBOL(of_device_is_available);
+
+/**
* of_get_parent - Get a node's parent if any
* @node: Node to get parent
*
--- linux-2.6.orig/include/linux/of.h
+++ linux-2.6/include/linux/of.h
@@ -62,6 +62,7 @@ extern struct property *of_find_property
int *lenp);
extern int of_device_is_compatible(const struct device_node *device,
const char *);
+extern int of_device_is_available(const struct device_node *device);
extern const void *of_get_property(const struct device_node *node,
const char *name,
int *lenp);
^ permalink raw reply
* Re: [PATCH 1/2][OF] Add of_device_is_disabled function
From: David Miller @ 2008-02-24 2:45 UTC (permalink / raw)
To: jwboyer; +Cc: linuxppc-dev, sfr
In-Reply-To: <20080223185904.757c2884@zod.rchland.ibm.com>
From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Date: Sat, 23 Feb 2008 18:59:04 -0600
> Dave, I'm not sure how applicable this all is to sparc. But for some
> of the "newer" embedded ports that are coming into powerpc I can see it
> being very useful.
I think I've seen this property on sparc boxes too, I'm fine
with whatever you guys come up with.
^ permalink raw reply
* Re: [PATCH] sata_fsl: fix build with ATA_VERBOSE_DEBUG
From: Jeff Garzik @ 2008-02-24 5:30 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <20080222165425.GA27460@localhost.localdomain>
Anton Vorontsov wrote:
> This patch fixes build and few warnings when ATA_VERBOSE_DEBUG
> is defined:
>
> CC drivers/ata/sata_fsl.o
> drivers/ata/sata_fsl.c: In function ‘sata_fsl_fill_sg’:
> drivers/ata/sata_fsl.c:338: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘void *’
> drivers/ata/sata_fsl.c:338: warning: format ‘%x’ expects type ‘unsigned int’, but argument 4 has type ‘struct prde *’
> drivers/ata/sata_fsl.c: In function ‘sata_fsl_qc_issue’:
> drivers/ata/sata_fsl.c:459: error: ‘csr_base’ undeclared (first use in this function)
> drivers/ata/sata_fsl.c:459: error: (Each undeclared identifier is reported only once
> drivers/ata/sata_fsl.c:459: error: for each function it appears in.)
> drivers/ata/sata_fsl.c: In function ‘sata_fsl_freeze’:
> drivers/ata/sata_fsl.c:525: error: ‘csr_base’ undeclared (first use in this function)
> make[2]: *** [drivers/ata/sata_fsl.o] Error 1
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/ata/sata_fsl.c | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
applied
^ permalink raw reply
* [PATCH] [POWERPC] mpc5200: fix build error on mpc52xx_psc_spi device driver
From: Grant Likely @ 2008-02-24 5:49 UTC (permalink / raw)
To: dbrownell, dragos.carp, linux-kernel, linuxppc-dev,
spi-devel-general
From: Grant Likely <grant.likely@secretlab.ca>
Commit id 94f389485e27641348c1951ab8d65157122a8939 (Separate MPC52xx PSC
FIOF regsiters from the rest of PSC) split the PSC fifo registers away
from the core PSC regs. Doing so broke the mpc52xx_psc_spi driver.
This patch teaches the mpc52xx_psc_spi driver about the new PSC fifo
register definitions.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
This is a build error bug fix which needs to go into .25
---
drivers/spi/mpc52xx_psc_spi.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index 253ed56..a86315a 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -42,6 +42,7 @@ struct mpc52xx_psc_spi {
/* driver internal data */
struct mpc52xx_psc __iomem *psc;
+ struct mpc52xx_psc_fifo __iomem *fifo;
unsigned int irq;
u8 bits_per_word;
u8 busy;
@@ -139,6 +140,7 @@ static int mpc52xx_psc_spi_transfer_rxtx(struct spi_device *spi,
{
struct mpc52xx_psc_spi *mps = spi_master_get_devdata(spi->master);
struct mpc52xx_psc __iomem *psc = mps->psc;
+ struct mpc52xx_psc_fifo __iomem *fifo = mps->fifo;
unsigned rb = 0; /* number of bytes receieved */
unsigned sb = 0; /* number of bytes sent */
unsigned char *rx_buf = (unsigned char *)t->rx_buf;
@@ -190,11 +192,11 @@ static int mpc52xx_psc_spi_transfer_rxtx(struct spi_device *spi,
out_8(&psc->mode, 0);
} else {
out_8(&psc->mode, MPC52xx_PSC_MODE_FFULL);
- out_be16(&psc->rfalarm, rfalarm);
+ out_be16(&fifo->rfalarm, rfalarm);
}
out_be16(&psc->mpc52xx_psc_imr, MPC52xx_PSC_IMR_RXRDY);
wait_for_completion(&mps->done);
- recv_at_once = in_be16(&psc->rfnum);
+ recv_at_once = in_be16(&fifo->rfnum);
dev_dbg(&spi->dev, "%d bytes received\n", recv_at_once);
send_at_once = recv_at_once;
@@ -331,6 +333,7 @@ static void mpc52xx_psc_spi_cleanup(struct spi_device *spi)
static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi *mps)
{
struct mpc52xx_psc __iomem *psc = mps->psc;
+ struct mpc52xx_psc_fifo __iomem *fifo = mps->fifo;
u32 mclken_div;
int ret = 0;
@@ -346,7 +349,7 @@ static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi *mps)
/* Disable interrupts, interrupts are based on alarm level */
out_be16(&psc->mpc52xx_psc_imr, 0);
out_8(&psc->command, MPC52xx_PSC_SEL_MODE_REG_1);
- out_8(&psc->rfcntl, 0);
+ out_8(&fifo->rfcntl, 0);
out_8(&psc->mode, MPC52xx_PSC_MODE_FFULL);
/* Configure 8bit codec mode as a SPI master and use EOF flags */
@@ -419,6 +422,8 @@ static int __init mpc52xx_psc_spi_do_probe(struct device *dev, u32 regaddr,
ret = -EFAULT;
goto free_master;
}
+ /* On the 5200, fifo regs are immediately ajacent to the psc regs */
+ mps->fifo = ((void __iomem *)mps->psc) + sizeof(struct mpc52xx_psc);
ret = request_irq(mps->irq, mpc52xx_psc_spi_isr, 0, "mpc52xx-psc-spi",
mps);
^ permalink raw reply related
* Re: [PATCH] Xilinx: hwicap: cleanup
From: Grant Likely @ 2008-02-24 6:16 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, git-dev, jirislaby, linux.kernel
In-Reply-To: <20080211182429.76E204D8018@mail62-sin.bigfish.com>
On Mon, Feb 11, 2008 at 11:24 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> Fix some missing __user tags and incorrect section tags.
> Convert semaphores to mutexes.
> Make probed_devices re-entrancy and error condition safe.
> Fix some backwards memcpys.
> Some other minor cleanups.
> Use kerneldoc format.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Thanks Steven, some more comments below.
>
> ---
>
> Grant, Since it appears that the driver will stay in as-is, here are
> the updates against mainline, based on Jiri's comments.
> ---
> drivers/char/xilinx_hwicap/buffer_icap.c | 80 ++++++++++----------
> drivers/char/xilinx_hwicap/fifo_icap.c | 60 +++++++-------
> drivers/char/xilinx_hwicap/xilinx_hwicap.c | 113 ++++++++++++++++------------
> drivers/char/xilinx_hwicap/xilinx_hwicap.h | 24 +++---
> 4 files changed, 148 insertions(+), 129 deletions(-)
>
> diff --git a/drivers/char/xilinx_hwicap/buffer_icap.c b/drivers/char/xilinx_hwicap/buffer_icap.c
> index dfea2bd..2c5d17d 100644
> --- a/drivers/char/xilinx_hwicap/buffer_icap.c
> +++ b/drivers/char/xilinx_hwicap/buffer_icap.c
> @@ -148,9 +148,9 @@ static inline void buffer_icap_set_size(void __iomem *base_address,
> }
>
> /**
> - * buffer_icap_mSetoffsetReg: Set the bram offset register.
> - * @parameter base_address: contains the base address of the device.
> - * @parameter data: is the value to be written to the data register.
> + * buffer_icap_mSetoffsetReg - Set the bram offset register.
This is the only function that is still in camel case; it should
probably be changed also... In fact, this functions doesn't seem to be
used at all. Can it just be removed? Are there any other unused
functions in this driver?
> diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> index 24f6aef..eddaa26 100644
> --- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> @@ -344,7 +345,7 @@ int hwicap_initialize_hwicap(struct hwicap_drvdata *drvdata)
> }
>
> static ssize_t
> -hwicap_read(struct file *file, char *buf, size_t count, loff_t *ppos)
> +hwicap_read(struct file *file, __user char *buf, size_t count, loff_t *ppos)
This looks like it should be 'char __user *buf' instead of '__user char *buf'.
> {
> struct hwicap_drvdata *drvdata = file->private_data;
> ssize_t bytes_to_read = 0;
> static ssize_t
> -hwicap_write(struct file *file, const char *buf,
> +hwicap_write(struct file *file, const __user char *buf,
> size_t count, loff_t *ppos)
Ditto on placement of __user
> @@ -549,8 +556,7 @@ static int hwicap_release(struct inode *inode, struct file *file)
> int i;
> int status = 0;
>
> - if (down_interruptible(&drvdata->sem))
> - return -ERESTARTSYS;
> + mutex_lock(&drvdata->sem);
Why not mutex_lock_interruptible()? (goes for all cases of mutex_lock())
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] Xilinx: hwicap: cleanup
From: Grant Likely @ 2008-02-24 6:20 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, git-dev, jirislaby, linux-kernel
In-Reply-To: <fa686aa40802232216s47b7751bi384352697dbf4ce2@mail.gmail.com>
Stephen, when you address these comments, please double check the lkml
address. It was misspelled when you sent this patch.
Cheers,
g.
On Sat, Feb 23, 2008 at 11:16 PM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Mon, Feb 11, 2008 at 11:24 AM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> > Fix some missing __user tags and incorrect section tags.
> > Convert semaphores to mutexes.
> > Make probed_devices re-entrancy and error condition safe.
> > Fix some backwards memcpys.
> > Some other minor cleanups.
> > Use kerneldoc format.
> >
> > Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
>
> Thanks Steven, some more comments below.
^^^^^^
Oops, sorry about the spelling.
g.
>
>
> >
> > ---
> >
> > Grant, Since it appears that the driver will stay in as-is, here are
> > the updates against mainline, based on Jiri's comments.
> > ---
> > drivers/char/xilinx_hwicap/buffer_icap.c | 80 ++++++++++----------
> > drivers/char/xilinx_hwicap/fifo_icap.c | 60 +++++++-------
> > drivers/char/xilinx_hwicap/xilinx_hwicap.c | 113 ++++++++++++++++------------
> > drivers/char/xilinx_hwicap/xilinx_hwicap.h | 24 +++---
> > 4 files changed, 148 insertions(+), 129 deletions(-)
> >
> > diff --git a/drivers/char/xilinx_hwicap/buffer_icap.c b/drivers/char/xilinx_hwicap/buffer_icap.c
> > index dfea2bd..2c5d17d 100644
> > --- a/drivers/char/xilinx_hwicap/buffer_icap.c
> > +++ b/drivers/char/xilinx_hwicap/buffer_icap.c
>
> > @@ -148,9 +148,9 @@ static inline void buffer_icap_set_size(void __iomem *base_address,
> > }
> >
> > /**
> > - * buffer_icap_mSetoffsetReg: Set the bram offset register.
> > - * @parameter base_address: contains the base address of the device.
> > - * @parameter data: is the value to be written to the data register.
> > + * buffer_icap_mSetoffsetReg - Set the bram offset register.
>
> This is the only function that is still in camel case; it should
> probably be changed also... In fact, this functions doesn't seem to be
> used at all. Can it just be removed? Are there any other unused
> functions in this driver?
>
>
> > diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> > index 24f6aef..eddaa26 100644
> > --- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> > +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
>
> > @@ -344,7 +345,7 @@ int hwicap_initialize_hwicap(struct hwicap_drvdata *drvdata)
> > }
> >
> > static ssize_t
> > -hwicap_read(struct file *file, char *buf, size_t count, loff_t *ppos)
> > +hwicap_read(struct file *file, __user char *buf, size_t count, loff_t *ppos)
>
> This looks like it should be 'char __user *buf' instead of '__user char *buf'.
>
>
> > {
> > struct hwicap_drvdata *drvdata = file->private_data;
> > ssize_t bytes_to_read = 0;
>
> > static ssize_t
> > -hwicap_write(struct file *file, const char *buf,
> > +hwicap_write(struct file *file, const __user char *buf,
> > size_t count, loff_t *ppos)
>
> Ditto on placement of __user
>
>
> > @@ -549,8 +556,7 @@ static int hwicap_release(struct inode *inode, struct file *file)
> > int i;
> > int status = 0;
> >
> > - if (down_interruptible(&drvdata->sem))
> > - return -ERESTARTSYS;
> > + mutex_lock(&drvdata->sem);
>
> Why not mutex_lock_interruptible()? (goes for all cases of mutex_lock())
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-02-24 7:35 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev, EricDuj
Paul, here is a bug fix that needs to go in for 2.6.25.
Thanks,
g.
The following changes since commit 42e6de0e6079f4a7ce6bd62340b1b14a1af314dc:
Oliver Pinter (1):
fix vmsas.c file permissions
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.25
Eric Dujardin (1):
[POWERPC] Add export for mpc52xx_set_psc_clkdiv
arch/powerpc/platforms/52xx/mpc52xx_common.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Jon Loeliger @ 2008-02-22 18:12 UTC (permalink / raw)
To: Scott Wood, jdl, linuxppc-dev
In-Reply-To: <20080222053450.GH3064@localhost.localdomain>
David Gibson wrote:
>> node {
>> prop = /incbin/("path/to/data");
>> };
>>
>> node {
>> prop = /incbin/("path/to/data", 8, 16);
>> };
>
> I still dislike the syntax, but haven't thought of a better one yet.
> There are some issues with the implementation too, but I've been a bit
> too busy with ePAPR stuff to review properly.
I'm OK with the syntax, but whatever-ish.
Would these be better?:
prop = /call/(incbin, "path/to/data", 17, 23);
prop = /call[incbin]/("path/to/data");
prop = /call incbin/("path/to/data", 12, 12+10);
What is the aspect of the syntax that you don't like?
I think we essentially need to stick in the /.../ realm
to be consistent with the other non-standard names being
used, like /include/.
I can see a generalized form that allows other pre-defined
or user-defined "functions" to be introduced and called
or used in a similar way:
prop = <(22 + /fibonacci/(7)) 1000>;
prop = /directoryof/("/path/to/some/file.doc");
interrupt-map = /pci_int_map/(8000, 2, 14);
or whatever. We can paint this bikeshed for a long time
if we need to. Or, we can get down to some serious issue
if there are any. Are there?
jdl
^ permalink raw reply
* [PATCH] ps3: Fix "unlikely" incorrect usage
From: Samuel Tardieu @ 2008-02-24 8:06 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, cbe-oss-dev
Fix unlikely(plug) == NO_IRQ into unlikely(plug == NO_IRQ).
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
---
arch/powerpc/platforms/ps3/interrupt.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/interrupt.c b/arch/powerpc/platforms/ps3/interrupt.c
index 3a6db04..a14e5cd 100644
--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -709,7 +709,7 @@ static unsigned int ps3_get_irq(void)
asm volatile("cntlzd %0,%1" : "=r" (plug) : "r" (x));
plug &= 0x3f;
- if (unlikely(plug) == NO_IRQ) {
+ if (unlikely(plug == NO_IRQ)) {
pr_debug("%s:%d: no plug found: thread_id %lu\n", __func__,
__LINE__, pd->thread_id);
dump_bmp(&per_cpu(ps3_private, 0));
--
1.5.4.2.197.g22c43
^ permalink raw reply related
* Status of 5200B and 440 Kernel Support
From: Albrecht Dreß @ 2008-02-24 10:17 UTC (permalink / raw)
To: LinuxPPC Embedded
[-- Attachment #1: Type: text/plain, Size: 640 bytes --]
Hi all,
sorry if this is a dumb question, I'm new in the list...
For a new project, I am looking through the available PPC based SoC's.
Good candidates are probably the Freescale 5200B or the AMCC 440EP (I
need a FPU).
For a decision, I need some further information about the Kernel
support (source code available, if possible in stock kernels, *not*
only vendor binary modules!) of the included devices, in particular
- MTD/NAND controller
- Ethernet
- UART, IIC and SPI
- USB host
- local external bus (not PCI) DMA
Any information or pointers would be really appreciated!
Thanks in advance,
Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Status of 5200B and 440 Kernel Support
From: Josh Boyer @ 2008-02-24 13:38 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: LinuxPPC Embedded
In-Reply-To: <1203848259l.2313l.1l@antares.localdomain>
On Sun, 24 Feb 2008 11:17:39 +0100
Albrecht Dre=C3=9F <albrecht.dress@arcor.de> wrote:
> For a decision, I need some further information about the Kernel =20
> support (source code available, if possible in stock kernels, *not* =20
> only vendor binary modules!) of the included devices, in particular
For 440EP in arch/powerpc:
> - MTD/NAND controller
NOR flash works. NAND needs some additional code.
> - Ethernet
Works.
> - UART, IIC and SPI
UART works. IIC has recent patches. No idea about SPI.
> - USB host
Works.
> - local external bus (not PCI) DMA
DMA to the EBC for what?
josh
^ permalink raw reply
* Re: How to dynamically disable/enable CPU features?
From: Gerhard Pircher @ 2008-02-24 14:47 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, miltonm
In-Reply-To: <1203719521.6976.30.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Sat, 23 Feb 2008 09:32:01 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: Milton Miller <miltonm@bga.com>, linuxppc-dev@ozlabs.org
> Betreff: Re: How to dynamically disable/enable CPU features?
> > The flag is in POSSIBLE. I now use this code in the platform probe
> > function to nop out the code affected by the flag:
> >
> > cur_cpu_spec->cpu_features &= ~CPU_FTR_NEED_COHERENT;
> > /* Patch out unwanted feature. */
> > do_feature_fixups(cur_cpu_spec->cpu_features,
> > PTRRELOC(&__start___ftr_fixup),
> > PTRRELOC(&__stop___ftr_fixup));
> >
> > It seems to work so far, but I would like to know if this is the right
> > way to do it, or if calling do_feature_fixups() more than once can have
> > any side effects.
>
> It's a bit hairy... Things -could- have been nop'ed out by the first
> call as a result of CPU_FTR_NEED_COHERENT being set and the second
> call will not be able to put them back in... now that may not be the
> case (depends what kind of patching is done with that flag) and so
> 'happen' to work for this specific bit but it isn't a nice solution...
I checked this now. Looks like it only needs to nop out some code (mainly
in the hash table code).
> A better long term approach is to look at moving the fixup to after
> the machine probe() after carefully checking whether that can cause
> any problem...
Well, that's a job for an more experienced kernel developer. :)
Thanks!
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
From: Jochen Friedrich @ 2008-02-24 15:16 UTC (permalink / raw)
To: Olof Johansson
Cc: Jean Delvare, linuxppc-dev list, linux-kernel, Scott Wood, i2c
In-Reply-To: <20080223212823.GA22131@lixom.net>
Hi Olof,
>> 2. record the I2c name in the dts tree, either as seperate tag (like linux,i2c-name="<i2c-name>")
>> or as additional compatible entry (like compatible="...", "linux,<i2c-name>").
>
> I have to say no on this one. The device tree is not supposed to know
> about how linux uses devices, there are firmwares out there that don't
> use DTS for thier device trees, etc.
I still believe this this could be done for embedded devices which are usually booted
via wrapper or U-Boot as those devices will most probably use the most exotic I2c devices
out there (e.g. home-grown devices used by stbs). However, I'm not an device tree expert.
>> 3. use a glue layer with a translation map.
>
> In my opinion this is an OK solution since the same information has to
> be added somewhere already anyway -- eiither to the drivers or to this
> translation table. It should of course be an abstacted shared table,
> preferrably contained under the i2c source directories since several
> platforms and architectures might share them.
I could think of a mixture between 2. and 3.:
Using the compatible attribute with the manufacturer stripped off as I2c name by default
and using an exception table. For now, the struct i2c_driver_device would currently only
need one entry ("dallas,ds1374", "rtc-ds1374").
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] PowerPC 44x: add missing define TARGET_4xx to cuboot-taishan.c
From: Josh Boyer @ 2008-02-24 15:32 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20080221144317.GA19395@ru.mvista.com>
On Thu, 21 Feb 2008 17:43:17 +0300
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> In order to get the proper bd_info structure for PowerPC 440,
> both TARGET_4xx and TARGET_44x should be defined.
Could you explain what this adds or why it's needed in the changelog?
Also, is this needed for other 440 boards?
josh
^ permalink raw reply
* Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
From: Jon Smirl @ 2008-02-24 16:19 UTC (permalink / raw)
To: Jean Delvare; +Cc: Scott Wood, linuxppc-dev list, i2c, linux-kernel
In-Reply-To: <47BEAF00.50106@scram.de>
On 2/22/08, Jochen Friedrich <jochen@scram.de> wrote:
> Hi Jean,
>
>
> >> +/*
> >> + * Wait for patch from Jon Smirl
> >> + * #include "powerpc-common.h"
> >> + */
> >
> > It doesn't make sense to merge this comment upstream.
>
>
> I know you don't like the patch from Jon Smirl and you also explained your reasons.
> Fortunately, I2c no longer uses numeric device IDs but names. So what are the alternatives?
>
> 1. modify the I2c subsystem to accept OF names additionally to I2c names (proposed by Jon smirl).
The correct statement is: modify the i2c subsystem to support the
standard kernel driver aliasing mechanism. Leaving powerpc and OF out
of the argument for the moment, i2c has a custom aliasing scheme on
the x86 too.
So as a first step, can we remove the custom i2c aliasing scheme and
change i2c to use standard module aliases on the x86? Patches for this
already exist.
On 2/23/08, Jean Delvare <khali@linux-fr.org> wrote:
> The problem I have with this is that it breaks compatibility. The chip
> name is not only used for device/driver matching, it is also exported
> to userspace as a sysfs attribute ("name"). Applications might rely on
> it. At least libsensors does.
I think there is some confusion here. The OF aliases are only used by
the kernel to load the correct driver. Would doing something like this
help?
static struct i2c_device_id pcf8563_id[] = {
{"pcf8563", 0, "sysfs_legacy_name"},
{"rtc8564", 0, "sysfs_legacy_name"},
OF_ID("phillips,pcf8563", &pcf8563_id[0], 0)
OF_ID("epson,rtc8564", &pcf8563_id[1], 0)
{},
};
MODULE_DEVICE_TABLE(i2c, pcf8563_id);
Then in the probe function you can use the pointer to find the base id
entry and i2c never has to be aware that the OF alias exists.
> 2. record the I2c name in the dts tree, either as separate tag (like linux,i2c-name="<i2c-name>")
Not really practical for the millions of machines (all PowerPC Macs)
already shipped.
> or as additional compatible entry (like compatible="...", "linux,<i2c-name>").
> 3. use a glue layer with a translation map.
Audio codecs have exactly the same problem. There are probably other
devices that also need mapping.
This mapping table will need to contain a map from the OF names to the
kernel driver names. It will need to stored permanently in RAM and
contain all possible mappings. This table will only grow in size.
The kernel has a widely used mechanism for mapping -- aliases in the
device drivers. Why do we want to build a new, parallel one?
What we are doing now is option 4.
4. Use kconfig to build custom kernels for each target system. Don't
load drivers automatically based on what the BIOS tells us.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox