Re: cell-index vs. index vs. no index in I2C device nodes
On Thursday 05 June 2008, Sean MacLennan wrote: On Wed, 4 Jun 2008 22:05:55 -0500 Josh Boyer [EMAIL PROTECTED] wrote: I'm not proposing we remove that. I'm just proposing that it can be derived from something other than an index property. Fill it in using a static integer that gets incremented for each new device found. It's not like we have an indeterminate probe order, or these IIC macros can be hot-plugged. That's how it used to work by default. It was decided to drop that and enforce an index. The following is a quote from Jean Delvare from a I added Jean to CC now. post from 8/2/16 4:31: I don't like this static index thing much. Can't you just make the index OF property mandatory? Mixing ways to number things can become very confusing. In particular as you are using dev-idx later to call i2c_add_numbered_adapter(), the caller is really supposed to know what they are doing with the bus numbers. Maybe it is time to remove the index, or maybe we should go back to using both a static and the index. But at the time we decided to enforce an index. So what should we do now? Currently I2C doesn't work at all on 4xx since the driver expects the index property and no dts sets this property. Personally I would like to move to using cell-index here, since this seems to be more common. But I could also life with removing the index property and using the static index if this is preferred and/or acceptable. Please advise. Thanks. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] [POWERPC] 85xx: add board support for the TQM8548 modules
Kumar Gala wrote: On Jun 4, 2008, at 4:43 AM, Wolfgang Grandegger wrote: David Gibson wrote: On Tue, Jun 03, 2008 at 09:33:12AM -0500, Kumar Gala wrote: On Jun 3, 2008, at 5:08 AM, Wolfgang Grandegger wrote: Kumar Gala wrote: On Jun 1, 2008, at 9:03 PM, David Gibson wrote: On Fri, May 30, 2008 at 08:49:45AM +0200, Wolfgang Grandegger wrote: [snip] You have a whole lot of 'cell-index' properties through both these trees, and they all look wrong. cell-index is a hack, which should be avoided wherever practical - it should only be used when the index is used to offset into some global register block, never simply to differentiate (use reg for that) or name the devices (use aliases for that). this is why FSL device tree's have cell-index. We have global control registers that need to know such things. Should I remove them or not? OF is still a mystery for me :-(. Don't remove them. Yes, they're ok, given this usage. I'm puzzled. Could someone point me to some real code where cell-index is used as a pointer into some global data. Sorry for my ignorance. http://ozlabs.org/pipermail/linuxppc-dev/2008-June/057254.html Yep, I saw that it's used for I2C (and SPI). But cell-index is also defined for network, serial and PCI nodes, which are also assigned via aliases. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] [POWERPC] 85xx: add board support for the TQM8548 modules
I'm puzzled. Could someone point me to some real code where cell- index is used as a pointer into some global data. Sorry for my ignorance. http://ozlabs.org/pipermail/linuxppc-dev/2008-June/057254.html Yep, I saw that it's used for I2C (and SPI). But cell-index is also defined for network, serial and PCI nodes, which are also assigned via aliases. Some of this is for the future. There are other SoC registers (like on 85xx in GUTS) that need index information. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] [POWERPC] 85xx: add board support for the TQM8548 modules
Kumar Gala wrote: I'm puzzled. Could someone point me to some real code where cell-index is used as a pointer into some global data. Sorry for my ignorance. http://ozlabs.org/pipermail/linuxppc-dev/2008-June/057254.html Yep, I saw that it's used for I2C (and SPI). But cell-index is also defined for network, serial and PCI nodes, which are also assigned via aliases. Some of this is for the future. There are other SoC registers (like on 85xx in GUTS) that need index information. Ah, OK, Thanks. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, 5 Jun 2008 08:22:00 +0200, Stefan Roese wrote: On Thursday 05 June 2008, Sean MacLennan wrote: On Wed, 4 Jun 2008 22:05:55 -0500 Josh Boyer [EMAIL PROTECTED] wrote: I'm not proposing we remove that. I'm just proposing that it can be derived from something other than an index property. Fill it in using a static integer that gets incremented for each new device found. It's not like we have an indeterminate probe order, or these IIC macros can be hot-plugged. That's how it used to work by default. It was decided to drop that and enforce an index. The following is a quote from Jean Delvare from a I added Jean to CC now. post from 8/2/16 4:31: I don't like this static index thing much. Can't you just make the index OF property mandatory? Mixing ways to number things can become very confusing. In particular as you are using dev-idx later to call i2c_add_numbered_adapter(), the caller is really supposed to know what they are doing with the bus numbers. Maybe it is time to remove the index, or maybe we should go back to using both a static and the index. But at the time we decided to enforce an index. So what should we do now? Currently I2C doesn't work at all on 4xx since the driver expects the index property and no dts sets this property. Personally I would like to move to using cell-index here, since this seems to be more common. But I could also life with removing the index property and using the static index if this is preferred and/or acceptable. Please advise. Thanks. As far as I am concerned, it's really up to the maintainers and users of this platform. All I am asking for is that you do not call i2c_add_numbered_adapter() on an adapter with an automatically generated number. This function must only be used for adapter's those number is well defined. If an adapter doesn't have a well-defined number then use i2c_add_adapter() (but then you can no longer declare your I2C devices as part of the platform data.) Thanks, -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
10th Real-Time Linux Workshop - Call for Papers
hi, I'm really sorry if this message disturb anybody, however.. = 10th Real-Time Linux Workshop October 29 November 1, 2008 University of Guadalajara Centro Universitario del Norte Carretera Federal # 23 Km 191, C.P. 46200 Colotl醤, Jalisco, Mexico Following the meetings of developers and users at the previous 9 successful real-time Linux workshops held in Vienna, Orlando, Milano, Boston, and Valencia, Singapur, Lille, Lanzhou, and Linz the Real-Time Linux Workshop for 2008 will come to Mexico. CALL FOR PAPERS General Following the meetings of developers and users at the previous 9 successful real-time Linux workshops, the Real Time Linux Workshop for 2008 will come to Mexico, to be held at the Centro Universitario del Norte, University of Guadalajara. Embedded and real-time Linux is continuously growing player in the embedded appliance market world wide notably initiatives in the industrial world have been moving embedded and real-time linux into automation/control safety related applications and into industrial applications with high security demands alongside typical control capabilities. Embedded systems in automation/control, measurement and robotics have been continuously moving towards 32bit systems, opening the door for the use of full featured OS like GNU/Linux on COTS based systems. With real-time capabilities being a common demand for embedded systems the soft and hard real-time variants are an important extension to the versatile GNU/Linux GPOS. Authors are invited to submit original work dealing with general topics related to real-time Linux research, experiments and case studies, as well as issues of integration of real-time and embedded Linux. A special focus will be on industrial applications and safety related systems. Topics of interest include, but are not limited to: * Real-time programming models and methods in mainstream-Linux * Modifications and variants of the GNU/Linux operating system extending it's real-time capabilities * Contributions to real-time Linux variants, drivers and extensions. * User-mode real-time concepts, implementation and experience * Real-time Linux applications, in academia, research and industry * Real-time Linux in measurement and data-acquisition systems * Linux/real-time Linux in safety-related systems * Signal processing with Linux/real-time Linux. * Work in progress reports, covering recent developments * Educational material on real-time Linux. * Tools for embedding Linux or real-time Linux and embedded real-time Linux applications * RTOS core concepts, RT-safe synchronization mechanisms * Analysis and Benchmarking methods and results of real-time GNU/Linux variants. * Debugging techniques and tools, both for code and temporal debugging of core RTOS components, drivers and real-time applications * Real-time related extensions to development environments Registration In order to participate to the workshop, please register on the Registration Page at: http://www.realtimelinuxfoundation.org/rtlws10/Register.php Venue Colotl醤, Jalisco Universidad de Guadalajara, Centro Universitario del Norte Accommodation There are three main Hotels in Colotl醤 and some other smaller ones. Due to the lack of English speakers at these Hotels, and the limited space, reservations will be handled through the University of Guadalajara staff. We will need a copy of your airline reservations faxed or emailed in order to complete the reservation. The prices will be under 30 Euros per night. We will also try to find alternate accommodations for students. More information coming soon. Important dates August 15, 2008 Abstract submission September 5, 2008 Notification of acceptance October 1, 2008 Final paper October 29 - November 1 Workshop Organization committee: * Dr. Donald W. CARR (MEXICO) * I.C. Alejandro Lopez RODRIGUEZ (MEXICO) * Ing. Oscar Perez MORA (MEXICO) * Dr. Zhou QINGGUO (LZU, CHINA) * Dr. Peter WURMSDOBLER , (RTLF, USA) * Prof. Nicholas MCGUIRE , (LZU, CHINA) Program committee: PhD. Apolinar Gonzalez, University of Colima (MEXICO) Ernesto Pablo Corona Alcala, Freescale Semiconductor Guadalajara (MEXICO) MSI Jorge Gutierrez, Tata Consultancy Services, Guadalajara Jalisco (MEXICO) PhD. Carlos Eduardo Pereira, University Federal do Rio Grande do Soul (BRAZIL) PhD. Alvaro Rendon Gallon, University of Cauca (COLOMBIA) PhD Francisco Torres, Instituto Tecnologico de Costa Rica (COSTA RICA) MsC Diego Mart韓ez Castro, University Autonoma de Occidente (COLOMBIA) Ernesto Pablo Corona Alcala, Freescale Semiconductor Guadalajara (MEXICO) MSI Jorge Gutierrez, Tata Consultancy Services, Guadalajara (MEXICO)
[PATCH] i2c-ibm_iic: Enable driver for all PPC4xx variants in arch/powerpc
This patch enables the IBM I2C driver for all PPC4xx variants by adding
ibm,iic to the compatible list. This way all currently available
arch/powerpc 4xx ports can make use of this driver without any changes.
Additionally all other compatible entries are removed since they are
not needed anymore.
Currently all 4xx PPC's have the same compatible I2C macro. If at some
time an incompatibility is detected we can take care of this with an
additional property.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-ibm_iic.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index 3a364a7..ed73801 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -807,11 +807,7 @@ static int __devexit iic_remove(struct of_device *ofdev)
}
static const struct of_device_id ibm_iic_match[] = {
- { .compatible = ibm,iic-405ex, },
- { .compatible = ibm,iic-405gp, },
- { .compatible = ibm,iic-440gp, },
- { .compatible = ibm,iic-440gpx, },
- { .compatible = ibm,iic-440grx, },
+ { .compatible = ibm,iic, },
{}
};
--
1.5.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
Jesse Barnes wrote: Now, in hindsight, using a PIO write set test flag approach in writeX/spin_unlock (ala powerpc) might have been a better approach, but iirc that never came up in the discussion, probably because we were focused on PCI posting and not uncached vs. cached ordering. Hi Jesse, I am going to take a stab at implementing this so we can see how much of an impact it will have. Cheers, Jes ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Thu, 2008-06-05 at 10:40 +0200, Jes Sorensen wrote: Jesse Barnes wrote: Now, in hindsight, using a PIO write set test flag approach in writeX/spin_unlock (ala powerpc) might have been a better approach, but iirc that never came up in the discussion, probably because we were focused on PCI posting and not uncached vs. cached ordering. Hi Jesse, I am going to take a stab at implementing this so we can see how much of an impact it will have. Note that the powerpc implementation currently clears the flag on spin_lock and tests it on unlock. We are considering changing that to not touch the flag on spin_lock and just clear it whenever we do a sync (ie, on unlock, on explicit mmiowb, and possibly even on readl's where we happen to do sync's). Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] [NAND] driver extension to support NAND on TQM85xx modules
[NAND] driver extension to support NAND on TQM85xx modules
This patch extends the FSL UPM NAND driver from Anton Vorontsov to
support NAND on the TQM85xx modules. Unfortunately, the hardware does
not support the R/B pins of the NAND chip and therefore the specified
maximum delay time must used. It therefore re-introduces the chip-delay
property.
Note: this patch is based on various patches from Anton Vorontsov posted
to this list:
http://ozlabs.org/pipermail/linuxppc-dev/2008-April/055587.html.
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/057158.html
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/056531.html
http://ozlabs.org/pipermail/linuxppc-dev/2008-June/057244.html
They should show up mainstream soon.
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt |1 +
drivers/mtd/nand/Kconfig |2 +-
drivers/mtd/nand/fsl_upm.c | 17 +
3 files changed, 15 insertions(+), 5 deletions(-)
Index: linux-2.6-galak/drivers/mtd/nand/Kconfig
===
--- linux-2.6-galak.orig/drivers/mtd/nand/Kconfig
+++ linux-2.6-galak/drivers/mtd/nand/Kconfig
@@ -380,7 +380,7 @@ config MTD_NAND_FSL_ELBC
config MTD_NAND_FSL_UPM
tristate Support for NAND on Freescale UPM
- depends on MTD_NAND OF_GPIO (PPC_83xx || PPC_85xx)
+ depends on MTD_NAND (PPC_83xx || PPC_85xx)
select FSL_LBC
help
Enables support for NAND Flash chips wired onto Freescale PowerPC
Index: linux-2.6-galak/drivers/mtd/nand/fsl_upm.c
===
--- linux-2.6-galak.orig/drivers/mtd/nand/fsl_upm.c
+++ linux-2.6-galak/drivers/mtd/nand/fsl_upm.c
@@ -13,6 +13,7 @@
#include linux/kernel.h
#include linux/module.h
+#include linux/delay.h
#include linux/mtd/nand.h
#include linux/mtd/nand_ecc.h
#include linux/mtd/partitions.h
@@ -36,6 +37,7 @@ struct fsl_upm_nand {
uint8_t upm_cmd_offset;
void __iomem *io_base;
int rnb_gpio;
+ int chip_delay;
};
#define to_fsl_upm_nand(mtd) container_of(mtd, struct fsl_upm_nand, mtd)
@@ -58,10 +60,11 @@ static void fun_wait_rnb(struct fsl_upm_
if (fun-rnb_gpio = 0) {
while (--cnt !fun_chip_ready(fun-mtd))
cpu_relax();
+ if (!cnt)
+ dev_err(fun-dev, tired waiting for RNB\n);
+ } else {
+ ndelay(100);
}
-
- if (!cnt)
- dev_err(fun-dev, tired waiting for RNB\n);
}
static void fun_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
@@ -129,7 +132,7 @@ static int __devinit fun_chip_init(struc
fun-chip.IO_ADDR_R = fun-io_base;
fun-chip.IO_ADDR_W = fun-io_base;
fun-chip.cmd_ctrl = fun_cmd_ctrl;
- fun-chip.chip_delay = 50;
+ fun-chip.chip_delay = fun-chip_delay;
fun-chip.read_byte = fun_read_byte;
fun-chip.read_buf = fun_read_buf;
fun-chip.write_buf = fun_write_buf;
@@ -233,6 +236,12 @@ static int __devinit fun_probe(struct of
goto err2;
}
+ prop = of_get_property(ofdev-node, chip-delay, NULL);
+ if (prop)
+ fun-chip_delay = *prop;
+ else
+ fun-chip_delay = 50;
+
fun-io_base = devm_ioremap_nocache(ofdev-dev, io_res.start,
io_res.end - io_res.start + 1);
if (!fun-io_base) {
Index: linux-2.6-galak/Documentation/powerpc/booting-without-of.txt
===
--- linux-2.6-galak.orig/Documentation/powerpc/booting-without-of.txt
+++ linux-2.6-galak/Documentation/powerpc/booting-without-of.txt
@@ -3007,6 +3007,7 @@ platforms are moved over to use the flat
- reg : should specify localbus chip select and size used for the chip.
- fsl,upm-addr-offset : UPM pattern offset for the address latch.
- fsl,upm-cmd-offset : UPM pattern offset for the command latch.
+ - chip-delay : may specify a delay value in milliseconds.
- gpios : may specify optional GPIO connected to the Ready-Not-Busy pin.
Example:
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 0/4] [POWERPC] 85xx: Add suport for TQM8548 and some TQM85xx fixes
Hello, it follows version 2 of patches adding support for the TQM8548 modules from TQ Components (http://www.tqc.de) and furthermore fixing some issues with other TQM85xx modules. They are already based on Kumar's powerpc Linux tree (linux-2.6-galak). The NAND support requires the patch with the subject [PATCH v2] [NAND] driver extension to support NAND on TQM85xx modules posted to this list a few minutes ago. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 2/4] [POWERPC] 85xx: support for the TQM8548 module using the big Flash
Some TQM85xx boards could be equipped with up to 1 GiB (NOR) flash
memory and therefore a modified memory map is required and setup by
the board loader. This patch adds an appropriate DTS file.
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 368 +
1 file changed, 368 insertions(+)
create mode 100644 arch/powerpc/boot/dts/tqm8548-bigflash.dts
Index: linux-2.6/arch/powerpc/boot/dts/tqm8548-bigflash.dts
===
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/dts/tqm8548-bigflash.dts
@@ -0,0 +1,368 @@
+/*
+ * TQM8548 Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ * Copyright 2008 Wolfgang Grandegger [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = tqm,8548;
+ compatible = tqm,8548, tqm,85xx;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ ethernet3 = enet3;
+
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32; // 32 bytes
+ i-cache-line-size = 32; // 32 bytes
+ d-cache-size = 0x8000;// L1, 32K
+ i-cache-size = 0x8000;// L1, 32K
+ timebase-frequency = 0; // from U-Boot
+ bus-frequency = 0;// from U-Boot
+ clock-frequency = 0; // from U-Boot
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x2000;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges = 0x0 0xa000 0x10;
+ reg = 0xa000 0x1000; // CCSRBAR
+ bus-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,8548-memory-controller;
+ reg = 0x2000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 18 2;
+ };
+
+ L2: [EMAIL PROTECTED] {
+ compatible = fsl,8548-l2-cache-controller;
+ reg = 0x2 0x1000;
+ cache-line-size = 32; // 32 bytes
+ cache-size = 0x8; // L2, 512K
+ interrupt-parent = mpic;
+ interrupts = 16 2;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ compatible = fsl-i2c;
+ reg = 0x3100 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,gianfar-mdio;
+ reg = 0x24520 0x20;
+
+ phy1: [EMAIL PROTECTED] {
+ interrupt-parent = mpic;
+ interrupts = 8 1;
+ reg = 1;
+ device_type = ethernet-phy;
+ };
+ phy2: [EMAIL PROTECTED] {
+ interrupt-parent = mpic;
+ interrupts = 8 1;
+ reg = 2;
+ device_type = ethernet-phy;
+ };
+ phy3: [EMAIL PROTECTED] {
+ interrupt-parent = mpic;
+
[PATCH v2 1/4] [POWERPC] 85xx: add board support for the TQM8548 modules
[POWERPC] 85xx: add board support for the TQM8548 modules
This patch adds support for the TQM8548 modules from TQ-Components
GmbH (http://www.tqc.de).
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
arch/powerpc/boot/Makefile |1
arch/powerpc/boot/dts/tqm8548.dts | 368 +
arch/powerpc/boot/wrapper |2
arch/powerpc/configs/85xx/tqm8548_defconfig | 1094
arch/powerpc/platforms/85xx/Kconfig |8
arch/powerpc/platforms/85xx/tqm85xx.c | 15
6 files changed, 1485 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/boot/dts/tqm8548.dts
create mode 100644 arch/powerpc/configs/85xx/tqm8548_defconfig
Index: linux-2.6-galak/arch/powerpc/boot/Makefile
===
--- linux-2.6-galak.orig/arch/powerpc/boot/Makefile
+++ linux-2.6-galak/arch/powerpc/boot/Makefile
@@ -255,6 +255,7 @@ image-$(CONFIG_MPC85xx_DS) += cuImage.m
cuImage.mpc8572ds
image-$(CONFIG_TQM8540)+= cuImage.tqm8540
image-$(CONFIG_TQM8541)+= cuImage.tqm8541
+image-$(CONFIG_TQM8548)+= cuImage.tqm8548
image-$(CONFIG_TQM8555)+= cuImage.tqm8555
image-$(CONFIG_TQM8560)+= cuImage.tqm8560
image-$(CONFIG_SBC8548)+= cuImage.sbc8548
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8548.dts
===
--- /dev/null
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8548.dts
@@ -0,0 +1,368 @@
+/*
+ * TQM8548 Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ * Copyright 2008 Wolfgang Grandegger [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = tqm,8548;
+ compatible = tqm,8548, tqm,85xx;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ ethernet3 = enet3;
+
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32; // 32 bytes
+ i-cache-line-size = 32; // 32 bytes
+ d-cache-size = 0x8000;// L1, 32K
+ i-cache-size = 0x8000;// L1, 32K
+ timebase-frequency = 0; // from U-Boot
+ bus-frequency = 0;// from U-Boot
+ clock-frequency = 0; // from U-Boot
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x2000;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges = 0x0 0xe000 0x10;
+ reg = 0xe000 0x1000; // CCSRBAR
+ bus-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,8548-memory-controller;
+ reg = 0x2000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 18 2;
+ };
+
+ L2: [EMAIL PROTECTED] {
+ compatible = fsl,8548-l2-cache-controller;
+ reg = 0x2 0x1000;
+ cache-line-size = 32; // 32 bytes
+ cache-size = 0x8; // L2, 512K
+ interrupt-parent = mpic;
+ interrupts = 16 2;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ compatible = fsl-i2c;
+ reg = 0x3100 0x100;
+
[PATCH v2 3/4] [POWERPC] 85xx: add local bus nodes for Flash and CAN to tqm8560.dts
Add local bus nodes for Flash and CAN to tqm8560.dts
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/tqm8560.dts | 65 ++
1 file changed, 65 insertions(+)
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8560.dts
===
--- linux-2.6-galak.orig/arch/powerpc/boot/dts/tqm8560.dts
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8560.dts
@@ -2,6 +2,7 @@
* TQM 8560 Device Tree Source
*
* Copyright 2008 Freescale Semiconductor Inc.
+ * Copyright 2008 Wolfgang Grandegger [EMAIL PROTECTED]
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -223,6 +224,70 @@
};
};
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8560-localbus, fsl,pq3-localbus,
+simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0xe0005000 0x100; // BRx, ORx, etc.
+
+ ranges =
+ 0 0x0 0xfc00 0x0400 // NOR FLASH bank 1
+ 1 0x0 0xf800 0x0800 // NOR FLASH bank 0
+ 2 0x0 0xe300 0x8000 // CAN (2 x i82527)
+ ;
+
+ [EMAIL PROTECTED],0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 1 0x0 0x800;
+ bank-width = 4;
+ device-width = 1;
+
+ [EMAIL PROTECTED] {
+ label = kernel;
+ reg = 0x 0x0020;
+ };
+ [EMAIL PROTECTED] {
+ label = root;
+ reg = 0x0020 0x0030;
+ };
+ [EMAIL PROTECTED] {
+ label = user;
+ reg = 0x0050 0x07a0;
+ };
+ [EMAIL PROTECTED] {
+ label = env1;
+ reg = 0x07f0 0x0004;
+ };
+ [EMAIL PROTECTED] {
+ label = env2;
+ reg = 0x07f4 0x0004;
+ };
+ [EMAIL PROTECTED] {
+ label = u-boot;
+ reg = 0x07f8 0x0008;
+ read-only;
+ };
+ };
+
+ /* Note: CAN support needs be enabled in U-Boot */
+ [EMAIL PROTECTED],0 {
+ compatible = intel,82527; // Bosch CC770
+ reg = 2 0x0 0x100;
+ interrupts = 4 0;
+ interrupt-parent = mpic;
+ };
+
+ [EMAIL PROTECTED],100 {
+ compatible = intel,82527; // Bosch CC770
+ reg = 2 0x100 0x100;
+ interrupts = 4 0;
+ interrupt-parent = mpic;
+ };
+ };
+
pci0: [EMAIL PROTECTED] {
cell-index = 0;
#interrupt-cells = 1;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 4/4] [POWERPC] 85xx: correct vendor prefix in DTS files for TQM85xx modules
Like for the TQM5200, the vendor prefix tqc, is now used for all
TQM85xx modules from TQ-Components GmbH (http://www.tqc.de) in the
corresponding DTS files.
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/tqm8540.dts |4 ++--
arch/powerpc/boot/dts/tqm8541.dts |4 ++--
arch/powerpc/boot/dts/tqm8548-bigflash.dts |4 ++--
arch/powerpc/boot/dts/tqm8548.dts |4 ++--
arch/powerpc/boot/dts/tqm8555.dts |4 ++--
arch/powerpc/boot/dts/tqm8560.dts |4 ++--
arch/powerpc/platforms/85xx/tqm85xx.c | 10 +-
7 files changed, 17 insertions(+), 17 deletions(-)
Index: linux-2.6/arch/powerpc/boot/dts/tqm8540.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/tqm8540.dts
+++ linux-2.6/arch/powerpc/boot/dts/tqm8540.dts
@@ -12,8 +12,8 @@
/dts-v1/;
/ {
- model = tqm,8540;
- compatible = tqm,8540, tqm,85xx;
+ model = tqc,8540;
+ compatible = tqc,8540, tqc,85xx;
#address-cells = 1;
#size-cells = 1;
Index: linux-2.6/arch/powerpc/boot/dts/tqm8541.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/tqm8541.dts
+++ linux-2.6/arch/powerpc/boot/dts/tqm8541.dts
@@ -12,8 +12,8 @@
/dts-v1/;
/ {
- model = tqm,8541;
- compatible = tqm,8541, tqm,85xx;
+ model = tqc,8541;
+ compatible = tqc,8541, tqc,85xx;
#address-cells = 1;
#size-cells = 1;
Index: linux-2.6/arch/powerpc/boot/dts/tqm8548-bigflash.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/tqm8548-bigflash.dts
+++ linux-2.6/arch/powerpc/boot/dts/tqm8548-bigflash.dts
@@ -13,8 +13,8 @@
/dts-v1/;
/ {
- model = tqm,8548;
- compatible = tqm,8548, tqm,85xx;
+ model = tqc,8548;
+ compatible = tqc,8548, tqc,85xx;
#address-cells = 1;
#size-cells = 1;
Index: linux-2.6/arch/powerpc/boot/dts/tqm8548.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/tqm8548.dts
+++ linux-2.6/arch/powerpc/boot/dts/tqm8548.dts
@@ -13,8 +13,8 @@
/dts-v1/;
/ {
- model = tqm,8548;
- compatible = tqm,8548, tqm,85xx;
+ model = tqc,8548;
+ compatible = tqc,8548, tqc,85xx;
#address-cells = 1;
#size-cells = 1;
Index: linux-2.6/arch/powerpc/boot/dts/tqm8555.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/tqm8555.dts
+++ linux-2.6/arch/powerpc/boot/dts/tqm8555.dts
@@ -12,8 +12,8 @@
/dts-v1/;
/ {
- model = tqm,8555;
- compatible = tqm,8555, tqm,85xx;
+ model = tqc,8555;
+ compatible = tqc,8555, tqc,85xx;
#address-cells = 1;
#size-cells = 1;
Index: linux-2.6/arch/powerpc/boot/dts/tqm8560.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/tqm8560.dts
+++ linux-2.6/arch/powerpc/boot/dts/tqm8560.dts
@@ -13,8 +13,8 @@
/dts-v1/;
/ {
- model = tqm,8560;
- compatible = tqm,8560, tqm,85xx;
+ model = tqc,8560;
+ compatible = tqc,8560, tqc,85xx;
#address-cells = 1;
#size-cells = 1;
Index: linux-2.6/arch/powerpc/platforms/85xx/tqm85xx.c
===
--- linux-2.6.orig/arch/powerpc/platforms/85xx/tqm85xx.c
+++ linux-2.6/arch/powerpc/platforms/85xx/tqm85xx.c
@@ -175,11 +175,11 @@ static int __init tqm85xx_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if ((of_flat_dt_is_compatible(root, tqm,8540)) ||
- (of_flat_dt_is_compatible(root, tqm,8541)) ||
- (of_flat_dt_is_compatible(root, tqm,8548)) ||
- (of_flat_dt_is_compatible(root, tqm,8555)) ||
- (of_flat_dt_is_compatible(root, tqm,8560)))
+ if ((of_flat_dt_is_compatible(root, tqc,8540)) ||
+ (of_flat_dt_is_compatible(root, tqc,8541)) ||
+ (of_flat_dt_is_compatible(root, tqc,8548)) ||
+ (of_flat_dt_is_compatible(root, tqc,8555)) ||
+ (of_flat_dt_is_compatible(root, tqc,8560)))
return 1;
return 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: inline assembly
Scott Wood [EMAIL PROTECTED] wrote:
int tmp;
asm volatile(addi %1, %2, -1;
andc %1, %2, %1;
cntlzw %1, %1;
subfic %0, %1, 31 : =r (j), =r (tmp) : r (i));
Registers are usually assumed to be 'long' in size, so I'd recommend using
that rather than 'int' for tmp, though I suspect it'll make little difference
(except, perhaps on x86 where you can partially use registers).
However, it'd be better to let the compiler do more, by just using the
existing cntlzw() function.
Look in include/asm-powerpc/bitops.h. There are examples of the things you're
trying to do:
static __inline__ __attribute__((const))
int __ilog2(unsigned long x)
{
int lz;
asm (PPC_CNTLZL %0,%1 : =r (lz) : r (x));
return BITS_PER_LONG - 1 - lz;
}
static __inline__ int __ffs(unsigned long x)
{
return __ilog2(x -x);
}
Where:
asm-compat.h:79:#define PPC_CNTLZL stringify_in_c(cntlzd)
asm-compat.h:100:#define PPC_CNTLZL stringify_in_c(cntlzw)
Depending on whether you're in 32-bit mode or 64-bit mode.
David
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Linux 2.6.26-rc5
On Wed, Jun 04, Linus Torvalds wrote: Another week, another batch of mostly pretty small fixes. Hopefully the regression list is shrinking, and we've fixed at least a couple of the oopses on Arjan's list. SATA on a dualcore G5 is broken, it happend between c3b25b32e8bef526cca748e1ba023c6bdd705a99..53c8ba95402be65d412a806cda3430f0e72cd107 irq 18: nobody cared (try booting with the irqpoll option) Disabling IRQ #18 ctrl alt del on the USB keyboard does not trigger a reboot. Sometimes the cursor stops blinking, sometimes just nothing happens after ctrl alt del. Does 53c8ba95402be65d412a806cda3430f0e72cd107 work for others on G5? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-ibm_iic: Enable driver for all PPC4xx variants in arch/powerpc
On Thu, 5 Jun 2008 10:10:53 +0200
Stefan Roese [EMAIL PROTECTED] wrote:
This patch enables the IBM I2C driver for all PPC4xx variants by adding
ibm,iic to the compatible list. This way all currently available
arch/powerpc 4xx ports can make use of this driver without any changes.
Additionally all other compatible entries are removed since they are
not needed anymore.
Currently all 4xx PPC's have the same compatible I2C macro. If at some
time an incompatibility is detected we can take care of this with an
additional property.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
Acked-by: Josh Boyer [EMAIL PROTECTED]
josh
---
drivers/i2c/busses/i2c-ibm_iic.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c
b/drivers/i2c/busses/i2c-ibm_iic.c
index 3a364a7..ed73801 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -807,11 +807,7 @@ static int __devexit iic_remove(struct of_device *ofdev)
}
static const struct of_device_id ibm_iic_match[] = {
- { .compatible = ibm,iic-405ex, },
- { .compatible = ibm,iic-405gp, },
- { .compatible = ibm,iic-440gp, },
- { .compatible = ibm,iic-440gpx, },
- { .compatible = ibm,iic-440grx, },
+ { .compatible = ibm,iic, },
{}
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, 5 Jun 2008 10:45:42 +0200 Stefan Roese [EMAIL PROTECTED] wrote: On Thursday 05 June 2008, Jean Delvare wrote: Maybe it is time to remove the index, or maybe we should go back to using both a static and the index. But at the time we decided to enforce an index. So what should we do now? Currently I2C doesn't work at all on 4xx since the driver expects the index property and no dts sets this property. Personally I would like to move to using cell-index here, since this seems to be more common. But I could also life with removing the index property and using the static index if this is preferred and/or acceptable. Please advise. Thanks. As far as I am concerned, it's really up to the maintainers and users of this platform. All I am asking for is that you do not call i2c_add_numbered_adapter() on an adapter with an automatically generated number. This function must only be used for adapter's those number is well defined. If an adapter doesn't have a well-defined number then use i2c_add_adapter() (but then you can no longer declare your I2C devices as part of the platform data.) Full ack from me. So I suggest to use cell-index if available and otherwise use an incremented number, same as the FSL i2c driver does now: http://ozlabs.org/pipermail/linuxppc-dev/2008-June/057254.html If nobody objects I'll send a patch to add the cell-index to all 4xx dts files in a short while. I have no large objections. Though as Scott pointed out, this isn't really a proper use of cell-index. Something like: linux,i2c-index seems to be a more distinct definition of what this is. But I have no idea how well that would go over, and it would probably need to be changed in all the fsl boards as well. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Linux 2.6.26-rc5 (G5 SATA broken)
On Thu, 5 Jun 2008, Olaf Hering wrote: On Wed, Jun 04, Linus Torvalds wrote: Another week, another batch of mostly pretty small fixes. Hopefully the regression list is shrinking, and we've fixed at least a couple of the oopses on Arjan's list. SATA on a dualcore G5 is broken, it happend between c3b25b32e8bef526cca748e1ba023c6bdd705a99..53c8ba95402be65d412a806cda3430f0e72cd107 irq 18: nobody cared (try booting with the irqpoll option) Disabling IRQ #18 ctrl alt del on the USB keyboard does not trigger a reboot. Sometimes the cursor stops blinking, sometimes just nothing happens after ctrl alt del. Does 53c8ba95402be65d412a806cda3430f0e72cd107 work for others on G5? I've been bisecting that on Quad G5 (sata_svw): irq 18: nobody cared ..., then later endless ata1.00: exception..., blah blah, ata1: EH complete. It comes down to: commit a57c1bade5a0ee5cd8b74502db9cbebb7f5780b2 Author: Alan Cox [EMAIL PROTECTED] Date: Thu May 29 22:10:58 2008 +0100 libata-sff: Fix oops reported in kerneloops.org for pnp devices with no ctl And the patch I'm finding successful is below: I won't sign it off, for all I know it's reverting part of what Alan is trying to achieve; but I expect it'll help towards the right fix. Hugh --- 2.6.26-rc5/drivers/ata/libata-sff.c 2008-06-05 07:18:07.0 +0100 +++ linux/drivers/ata/libata-sff.c 2008-06-05 12:42:39.0 +0100 @@ -278,7 +278,7 @@ static u8 ata_sff_irq_status(struct ata_ return status; } /* Clear INTRQ latch */ - status = ata_sff_check_status(ap); + status = ap-ops-sff_check_status(ap); return status; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] MTD support for the AMCC Taishan
bump? :)
On Mon, 17 Mar 2008 14:48:23 +0100, Imre Kaloz [EMAIL PROTECTED] wrote:
Signed-off-by: Imre Kaloz [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/taishan.dts | 29 +++-
arch/powerpc/configs/taishan_defconfig | 79
+++-
2 files changed, 106 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/taishan.dts
b/arch/powerpc/boot/dts/taishan.dts
index 8278068..db102e9 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -174,7 +174,34 @@
interrupts = 5 4;
interrupt-parent = UIC1;
- /* TODO: Add other EBC devices */
+ [EMAIL PROTECTED],0 {
+ compatible = cfi-flash;
+ bank-width = 4;
+ device-width = 2;
+ reg = 0 00 400;
+ #address-cells = 1;
+ #size-cells = 1;
+ [EMAIL PROTECTED] {
+ label = kernel;
+ reg = 0 18;
+ };
+ [EMAIL PROTECTED] {
+ label = root;
+ reg = 18 20;
+ };
+ [EMAIL PROTECTED] {
+ label = user;
+ reg = 38 3bc;
+ };
+ [EMAIL PROTECTED] {
+ label = env;
+ reg = 3f4 8;
+ };
+ [EMAIL PROTECTED] {
+ label = u-boot;
+ reg = 3fc 4;
+ };
+ };
};
diff --git a/arch/powerpc/configs/taishan_defconfig
b/arch/powerpc/configs/taishan_defconfig
index 087aedc..e53c926 100644
--- a/arch/powerpc/configs/taishan_defconfig
+++ b/arch/powerpc/configs/taishan_defconfig
@@ -348,7 +348,83 @@ CONFIG_FW_LOADER=y
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+CONFIG_MTD_CMDLINE_PARTS=y
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+# CONFIG_MTD_BLKDEVS is not set
+# CONFIG_MTD_BLOCK is not set
+# CONFIG_MTD_BLOCK_RO is not set
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+# CONFIG_MTD_OOPS is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+# CONFIG_MTD_JEDECPROBE is not set
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+# CONFIG_MTD_CFI_INTELEXT is not set
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+# CONFIG_MTD_PHYSMAP is not set
+CONFIG_MTD_PHYSMAP_OF=y
+# CONFIG_MTD_INTEL_VR_NOR is not set
+# CONFIG_MTD_PLATRAM is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_PMC551 is not set
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_PHRAM is not set
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+# CONFIG_MTD_NAND is not set
+# CONFIG_MTD_ONENAND is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI is not set
CONFIG_OF_DEVICE=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
@@ -660,6 +736,7 @@ CONFIG_TMPFS=y
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
+# CONFIG_JFFS2_FS is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
___
Linuxppc-dev mailing list
Re: Linux 2.6.26-rc5
On Thu, 5 Jun 2008 13:24:36 +0200 Olaf Hering [EMAIL PROTECTED] wrote: On Wed, Jun 04, Linus Torvalds wrote: Another week, another batch of mostly pretty small fixes. Hopefully the regression list is shrinking, and we've fixed at least a couple of the oopses on Arjan's list. SATA on a dualcore G5 is broken, it happend between See the patch I just posted to Nick/Jeff should fix it. I always said ata_sff_check_status() was asking for trouble as a name and neither I nor Jeff nor Linus noticed the bug... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Linux 2.6.26-rc5 (G5 SATA broken)
And the patch I'm finding successful is below: I won't sign it off, for all I know it's reverting part of what Alan is trying to achieve; but I expect it'll help towards the right fix. Its the right fix ata_sff_check_altstatus() is a routine which does the altstatus check and may or may not call the helper ata_sff_check_status() is a default method for ap-ops- This lunatic naming leads to mistakes 8( ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] MTD support for the AMCC Taishan
On Thu, 05 Jun 2008 14:50:41 +0200 Imre Kaloz [EMAIL PROTECTED] wrote: bump? :) It won't apply anymore, but the fixups are trivial. I can do that if Stefan acks the changes. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] [POWERPC] 85xx: add board support for the TQM8548 modules
On Jun 5, 2008, at 4:05 AM, Wolfgang Grandegger wrote:
[POWERPC] 85xx: add board support for the TQM8548 modules
This patch adds support for the TQM8548 modules from TQ-Components
GmbH (http://www.tqc.de).
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
arch/powerpc/boot/Makefile |1
arch/powerpc/boot/dts/tqm8548.dts | 368 +
arch/powerpc/boot/wrapper |2
arch/powerpc/configs/85xx/tqm8548_defconfig | 1094 ++
++
arch/powerpc/platforms/85xx/Kconfig |8
arch/powerpc/platforms/85xx/tqm85xx.c | 15
6 files changed, 1485 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/boot/dts/tqm8548.dts
create mode 100644 arch/powerpc/configs/85xx/tqm8548_defconfig
Index: linux-2.6-galak/arch/powerpc/boot/Makefile
===
--- linux-2.6-galak.orig/arch/powerpc/boot/Makefile
+++ linux-2.6-galak/arch/powerpc/boot/Makefile
@@ -255,6 +255,7 @@ image-$(CONFIG_MPC85xx_DS) += cuImage.m
cuImage.mpc8572ds
image-$(CONFIG_TQM8540) += cuImage.tqm8540
image-$(CONFIG_TQM8541) += cuImage.tqm8541
+image-$(CONFIG_TQM8548)+= cuImage.tqm8548
image-$(CONFIG_TQM8555) += cuImage.tqm8555
image-$(CONFIG_TQM8560) += cuImage.tqm8560
image-$(CONFIG_SBC8548) += cuImage.sbc8548
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8548.dts
===
--- /dev/null
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8548.dts
@@ -0,0 +1,368 @@
+/*
+ * TQM8548 Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ * Copyright 2008 Wolfgang Grandegger [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License as
published by the
+ * Free Software Foundation; either version 2 of the License, or
(at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = tqm,8548;
+ compatible = tqm,8548, tqm,85xx;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ ethernet3 = enet3;
+
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32; // 32 bytes
+ i-cache-line-size = 32; // 32 bytes
+ d-cache-size = 0x8000; // L1, 32K
+ i-cache-size = 0x8000; // L1, 32K
+ timebase-frequency = 0; // from U-Boot
+ bus-frequency = 0; // from U-Boot
+ clock-frequency = 0;// from U-Boot
u-boot will add this for us so no need for them.
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x2000;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges = 0x0 0xe000 0x10;
+ reg = 0xe000 0x1000;// CCSRBAR
+ bus-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,8548-memory-controller;
Can you make this fsl,mpc8548...
I need to fix all the other device trees
+ reg = 0x2000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 18 2;
+ };
+
+ L2: [EMAIL PROTECTED] {
+ compatible = fsl,8548-l2-cache-controller;
Can you make this fsl,mpc8548
+ reg = 0x2 0x1000;
+ cache-line-size = 32; // 32 bytes
+ cache-size = 0x8; // L2, 512K
+ interrupt-parent = mpic;
+ interrupts = 16 2;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+
[PATCH] libata: fix G5 SATA broken on -rc5
Fix G5 SATA irq 18: nobody cared, reported on -rc5 by Olaf Hering: fixlet to a57c1bade5a0ee5cd8b74502db9cbebb7f5780b2 libata-sff: Fix oops reported in kerneloops.org for pnp devices with no ctl Signed-off-by: Hugh Dickins [EMAIL PROTECTED] Acked-by: Alan Cox [EMAIL PROTECTED] --- drivers/ata/libata-sff.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- 2.6.26-rc5/drivers/ata/libata-sff.c 2008-06-05 07:18:07.0 +0100 +++ linux/drivers/ata/libata-sff.c 2008-06-05 12:42:39.0 +0100 @@ -278,7 +278,7 @@ static u8 ata_sff_irq_status(struct ata_ return status; } /* Clear INTRQ latch */ - status = ata_sff_check_status(ap); + status = ap-ops-sff_check_status(ap); return status; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/4] [POWERPC] 85xx: support for the TQM8548 module using the big Flash
On Jun 5, 2008, at 4:09 AM, Wolfgang Grandegger wrote: Some TQM85xx boards could be equipped with up to 1 GiB (NOR) flash memory and therefore a modified memory map is required and setup by the board loader. This patch adds an appropriate DTS file. Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED] --- arch/powerpc/boot/dts/tqm8548-bigflash.dts | 368 +++ ++ 1 file changed, 368 insertions(+) create mode 100644 arch/powerpc/boot/dts/tqm8548-bigflash.dts similar comments as to the base tqm8548.dts also is it not possible to deal w/the differences in u-boot itself? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 4/4] [POWERPC] 85xx: correct vendor prefix in DTS files for TQM85xx modules
On Jun 5, 2008, at 4:13 AM, Wolfgang Grandegger wrote: Like for the TQM5200, the vendor prefix tqc, is now used for all TQM85xx modules from TQ-Components GmbH (http://www.tqc.de) in the corresponding DTS files. Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED] --- arch/powerpc/boot/dts/tqm8540.dts |4 ++-- arch/powerpc/boot/dts/tqm8541.dts |4 ++-- arch/powerpc/boot/dts/tqm8548-bigflash.dts |4 ++-- arch/powerpc/boot/dts/tqm8548.dts |4 ++-- arch/powerpc/boot/dts/tqm8555.dts |4 ++-- arch/powerpc/boot/dts/tqm8560.dts |4 ++-- arch/powerpc/platforms/85xx/tqm85xx.c | 10 +- any reason that tqm8548*.dts just dont have these changes to begin with (since they are new)? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] PowerPC 44x: small warp-nand fix
The ndfc-chip device doesn't need any resources. All resources
are handled by the ndfc-nand device. Registering the same memory
resource twice causes cat /proc/iomem to go into an infinite loop
displaying NDFC memory addresses.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
arch/powerpc/platforms/44x/warp-nand.c |3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.orig/arch/powerpc/platforms/44x/warp-nand.c 2008-04-25
22:04:50.0 +0400
+++ linux-2.6/arch/powerpc/platforms/44x/warp-nand.c2008-06-05
17:24:06.0 +0400
@@ -86,8 +86,7 @@ static struct platform_nand_chip warp_na
static struct platform_device warp_nand_device = {
.name = ndfc-chip,
.id = 0,
- .num_resources = 1,
- .resource = warp_ndfc,
+ .num_resources = 0,
.dev = {
.platform_data = warp_nand_chip0,
.parent = warp_ndfc_device.dev,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] 4xx: PCIe driver now detects if a port is disabled via the dev-tree
This patch add a check to the PPC4xx PCIe driver to detect if the port
is disabled via the device-tree. This is needed for the AMCC Canyonlands
board which has an option to either select 2 PCIe ports or 1 PCIe port
and one SATA port. The SATA port and the 1st PCIe port pins are multiplexed
so we can't start both drivers.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
arch/powerpc/sysdev/ppc4xx_pci.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index b4a54c5..76886cf 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -1634,6 +1634,15 @@ static void __init ppc4xx_probe_pciex_bridge(struct
device_node *np)
}
port = ppc4xx_pciex_ports[portno];
port-index = portno;
+
+ /*
+* Check if device is enabled
+*/
+ if (!of_device_is_available(np)) {
+ printk(KERN_INFO PCIE%d: Port disabled via device-tree\n,
port-index);
+ return;
+ }
+
port-node = of_node_get(np);
pval = of_get_property(np, sdr-base, NULL);
if (pval == NULL) {
--
1.5.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC 44x: small warp-nand fix
On Thursday 05 June 2008, Valentine Barshak wrote: The ndfc-chip device doesn't need any resources. All resources are handled by the ndfc-nand device. Registering the same memory resource twice causes cat /proc/iomem to go into an infinite loop displaying NDFC memory addresses. Signed-off-by: Valentine Barshak [EMAIL PROTECTED] 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: [PATCH] libata: fix G5 SATA broken on -rc5
On Thu, Jun 05, Hugh Dickins wrote: Fix G5 SATA irq 18: nobody cared, reported on -rc5 by Olaf Hering: fixlet to a57c1bade5a0ee5cd8b74502db9cbebb7f5780b2 libata-sff: Fix oops reported in kerneloops.org for pnp devices with no ctl Signed-off-by: Hugh Dickins [EMAIL PROTECTED] Acked-by: Alan Cox [EMAIL PROTECTED] Tested-by: Olaf Hering [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
4xx support in arch/ppc is going away Real Soon Now
This commit (patch omitted due to size) is sitting in my local tree: commit 0d7efc1e80fc262bcc507a605482c5681e3f082a Author: Josh Boyer [EMAIL PROTECTED] Date: Thu Jun 5 09:46:17 2008 -0500 ppc/4xx: Remove 4xx support from arch/ppc Remove support for PPC 403, 405, and 440 processors from arch/ppc. The arch/powerpc equivalents should be used. Boards that are not ported yet will need to be ported to arch/powerpc to have continued support. Signed-off-by: Josh Boyer [EMAIL PROTECTED] I will push this to my -next branch in the next few days, and ask Paul to pull it. The diffstat is below. josh arch/ppc/4xx_io/Makefile |6 - arch/ppc/4xx_io/serial_sicc.c | 2005 arch/ppc/Kconfig | 73 +- arch/ppc/Kconfig.debug |4 +- arch/ppc/Makefile |5 - arch/ppc/boot/common/ns16550.c |3 - arch/ppc/boot/common/util.S|9 - arch/ppc/boot/simple/Makefile | 61 - arch/ppc/boot/simple/embed_config.c| 221 +--- arch/ppc/boot/simple/misc-embedded.c |4 +- arch/ppc/boot/simple/misc.c| 23 - arch/ppc/boot/simple/openbios.c| 128 -- arch/ppc/boot/simple/pibs.c| 104 - arch/ppc/boot/simple/rw4/ppc_40x.h | 664 --- arch/ppc/boot/simple/rw4/rw4_init.S| 78 - arch/ppc/boot/simple/rw4/rw4_init_brd.S| 1125 --- arch/ppc/boot/simple/rw4/stb.h | 239 --- arch/ppc/boot/simple/uartlite_tty.c|1 - arch/ppc/configs/bamboo_defconfig | 944 - arch/ppc/configs/bubinga_defconfig | 592 -- arch/ppc/configs/cpci405_defconfig | 631 -- arch/ppc/configs/ebony_defconfig | 585 -- arch/ppc/configs/ep405_defconfig | 572 -- arch/ppc/configs/luan_defconfig| 668 --- arch/ppc/configs/ml300_defconfig | 739 --- arch/ppc/configs/ml403_defconfig | 740 arch/ppc/configs/ocotea_defconfig | 599 -- arch/ppc/configs/redwood5_defconfig| 557 -- arch/ppc/configs/redwood6_defconfig| 535 -- arch/ppc/configs/sycamore_defconfig| 663 --- arch/ppc/configs/taishan_defconfig | 1077 --- arch/ppc/configs/walnut_defconfig | 578 -- arch/ppc/kernel/Makefile |2 - arch/ppc/kernel/asm-offsets.c |2 +- arch/ppc/kernel/entry.S| 64 +- arch/ppc/kernel/head_44x.S | 769 arch/ppc/kernel/head_4xx.S | 1021 -- arch/ppc/kernel/misc.S | 91 - arch/ppc/kernel/ppc_ksyms.c|3 - arch/ppc/kernel/traps.c| 56 +- arch/ppc/mm/44x_mmu.c | 101 - arch/ppc/mm/4xx_mmu.c | 135 -- arch/ppc/mm/Makefile |2 - arch/ppc/mm/fault.c|6 +- arch/ppc/mm/mmu_decl.h |5 - arch/ppc/platforms/4xx/Kconfig | 285 --- arch/ppc/platforms/4xx/Makefile| 31 - arch/ppc/platforms/4xx/bamboo.c| 442 - arch/ppc/platforms/4xx/bamboo.h| 133 -- arch/ppc/platforms/4xx/bubinga.c | 265 --- arch/ppc/platforms/4xx/bubinga.h | 54 - arch/ppc/platforms/4xx/cpci405.c | 201 -- arch/ppc/platforms/4xx/cpci405.h | 28 - arch/ppc/platforms/4xx/ebony.c | 334 arch/ppc/platforms/4xx/ebony.h | 97 - arch/ppc/platforms/4xx/ep405.c | 196 -- arch/ppc/platforms/4xx/ep405.h | 52 - arch/ppc/platforms/4xx/ibm405ep.c | 141 -- arch/ppc/platforms/4xx/ibm405ep.h | 145 -- arch/ppc/platforms/4xx/ibm405gp.c | 120 -- arch/ppc/platforms/4xx/ibm405gp.h | 148 -- arch/ppc/platforms/4xx/ibm405gpr.c | 115 -- arch/ppc/platforms/4xx/ibm405gpr.h | 148 -- arch/ppc/platforms/4xx/ibm440ep.c | 220 --- arch/ppc/platforms/4xx/ibm440ep.h | 73 - arch/ppc/platforms/4xx/ibm440gp.c | 163 -- arch/ppc/platforms/4xx/ibm440gp.h | 63 - arch/ppc/platforms/4xx/ibm440gx.c | 231 --- arch/ppc/platforms/4xx/ibm440gx.h
[RFC][PATCH] powerpc/85xx: add DOZE/NAP support for e500 core
From: Dave Liu [EMAIL PROTECTED]
The e500 core enter DOZE/NAP power-saving modes when the core go to
cpu_idle routine.
The power management default running mode is DOZE, If the user
echo 1 /proc/sys/kernel/powersave-nap
the system will change to NAP running mode.
---
I'm post this for review feedback. The one thing we plan on changing is
the L1 cache flush code that is in idle_e500.S.
- k
arch/powerpc/kernel/Makefile |1 +
arch/powerpc/kernel/cputable.c |2 -
arch/powerpc/kernel/entry_32.S |8 ++--
arch/powerpc/kernel/head_fsl_booke.S | 35 +++
arch/powerpc/kernel/idle_6xx.S |2 +-
arch/powerpc/kernel/idle_e500.S | 79 ++
arch/powerpc/kernel/setup_32.c |5 ++
include/asm-powerpc/cputable.h |7 ++-
include/asm-powerpc/machdep.h|1 +
9 files changed, 130 insertions(+), 10 deletions(-)
create mode 100644 arch/powerpc/kernel/idle_e500.S
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 2346d27..0e8f928 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_IBMVIO) += vio.o
obj-$(CONFIG_IBMEBUS) += ibmebus.o
obj-$(CONFIG_GENERIC_TBSYNC) += smp-tbsync.o
obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
+obj-$(CONFIG_E500) += idle_e500.o
obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6xx.o cpu_setup_6xx.o
obj-$(CONFIG_TAU) += tau_6xx.o
obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o \
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index e44d553..4a187e5 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1491,7 +1491,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pvr_mask = 0x,
.pvr_value = 0x8020,
.cpu_name = e500,
- /* xxx - galak: add CPU_FTR_MAYBE_CAN_DOZE */
.cpu_features = CPU_FTRS_E500,
.cpu_user_features = COMMON_USER_BOOKE |
PPC_FEATURE_HAS_SPE_COMP |
@@ -1508,7 +1507,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pvr_mask = 0x,
.pvr_value = 0x8021,
.cpu_name = e500v2,
- /* xxx - galak: add CPU_FTR_MAYBE_CAN_DOZE */
.cpu_features = CPU_FTRS_E500_2,
.cpu_user_features = COMMON_USER_BOOKE |
PPC_FEATURE_HAS_SPE_COMP |
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index fe21674..ab2d62f 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -176,14 +176,14 @@ transfer_to_handler:
cmplw r1,r9 /* if r1 = ksp_limit */
ble-stack_ovf /* then the kernel stack overflowed */
5:
-#ifdef CONFIG_6xx
+#if defined(CONFIG_6xx) || defined(CONFIG_E500)
rlwinm r9,r1,0,0,31-THREAD_SHIFT
tophys(r9,r9) /* check local flags */
lwz r12,TI_LOCAL_FLAGS(r9)
mtcrf 0x01,r12
bt- 31-TLF_NAPPING,4f
bt- 31-TLF_SLEEPING,7f
-#endif /* CONFIG_6xx */
+#endif /* CONFIG_6xx || CONFIG_E500 */
.globl transfer_to_handler_cont
transfer_to_handler_cont:
3:
@@ -196,10 +196,10 @@ transfer_to_handler_cont:
SYNC
RFI /* jump to handler, enable MMU */
-#ifdef CONFIG_6xx
+#if defined (CONFIG_6xx) || defined(CONFIG_E500)
4: rlwinm r12,r12,0,~_TLF_NAPPING
stw r12,TI_LOCAL_FLAGS(r9)
- b power_save_6xx_restore
+ b power_save_ppc32_restore
7: rlwinm r12,r12,0,~_TLF_SLEEPING
stw r12,TI_LOCAL_FLAGS(r9)
diff --git a/arch/powerpc/kernel/head_fsl_booke.S
b/arch/powerpc/kernel/head_fsl_booke.S
index 503f860..b46744f 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -39,6 +39,7 @@
#include asm/thread_info.h
#include asm/ppc_asm.h
#include asm/asm-offsets.h
+#include asm/cache.h
#include head_booke.h
/* As with the other PowerPC ports, it is expected that when code
@@ -1066,6 +1067,40 @@ _GLOBAL(set_context)
blr
/*
+ * Flush all of d-cache, assume the cache size is 32K Bytes
+ * with 8 ways and PLRU replacement policy.
+ * We have to do load/flush in n KB continued space to
+ * guarante all of d-cache evict.
+ * It is enough to set n = cache-size * 13 / 8,
+ */
+_GLOBAL(flush_dcache_L1)
+ sync
+
+ /* Load counter to 0x680 cache lines and
+* load cache with datas
+*/
+ li r3,0x680
+ mtctr r3
+ lis r3,[EMAIL PROTECTED]
+1:
+ lwz r4,0(r3)
+ addir3,r3,L1_CACHE_BYTES/* Go to start of next cache line */
+
Re: [PATCH 3/3] mmc: change .get_ro() callback semantics
On Tue, Jun 03, 2008 at 12:07:49PM +0200, Marc Pignat wrote:
Hi all!
On Friday 23 May 2008, Anton Vorontsov wrote:
get_ro() callback must return values = 0 for its logical state, and
...
static void pxamci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index f2e9885..ef3b773 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -55,6 +55,9 @@ struct mmc_host_ops {
* Avoid calling these three functions too often or in a fast path,
* since underlaying controller might implement them in an expensive
* and/or slow way.
+*
+* .get_ro and .get_cd should return = 0 for their logical values,
+* or negative errno value in case of error.
*/
I would suggest to use something more strict (bulletproof), something like:
/*
* get_ro will return:
* 0 for a read/write card
* 1 for a read-only card
This isn't always practical. For example, host is using u8 register for
the status, so it might safely return u8 mask, that will always fit
into int. Or very smart/adventurous authors might be aware that, for the
particular host, mask's bit isn't last, and safely do uXX mask. :-)
The above is weak argument of course, since it is about optimization.
As an counter-evidence, the strict scheme that you described probably
less error prone. But is it? To implement it we'll need something like
WARN_ON(ret 0 ret != 1) to catch erroneous users. Take a closer
look though, will it catch uXX lastbit case? Nope. :-)
We can catch bogus users though... via hack (_assuming_ that there
are no errno values of 1 (sizeof(int) * 8 - 1)), i.e.
WARN_ON(ret == (1 (sizeof(int) * 8 - 1)). Though, to do so, we don't
need the strict scheme, this debugging hack will work in the current
scheme too.
--
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: 4xx support in arch/ppc is going away Real Soon Now
On Thu, Jun 5, 2008 at 8:52 AM, Josh Boyer [EMAIL PROTECTED] wrote: This commit (patch omitted due to size) is sitting in my local tree: commit 0d7efc1e80fc262bcc507a605482c5681e3f082a Author: Josh Boyer [EMAIL PROTECTED] Date: Thu Jun 5 09:46:17 2008 -0500 ppc/4xx: Remove 4xx support from arch/ppc Remove support for PPC 403, 405, and 440 processors from arch/ppc. The arch/powerpc equivalents should be used. Boards that are not ported yet will need to be ported to arch/powerpc to have continued support. This looks like unneeded churn. Paulus, Can we just kill all of arch/ppc for .27 right now? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 4xx support in arch/ppc is going away Real Soon Now
On Thu, 5 Jun 2008 09:11:48 -0600 Grant Likely [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 8:52 AM, Josh Boyer [EMAIL PROTECTED] wrote: This commit (patch omitted due to size) is sitting in my local tree: commit 0d7efc1e80fc262bcc507a605482c5681e3f082a Author: Josh Boyer [EMAIL PROTECTED] Date: Thu Jun 5 09:46:17 2008 -0500 ppc/4xx: Remove 4xx support from arch/ppc Remove support for PPC 403, 405, and 440 processors from arch/ppc. The arch/powerpc equivalents should be used. Boards that are not ported yet will need to be ported to arch/powerpc to have continued support. This looks like unneeded churn. Excellent. My prompting has succeeded. Though now I won't get to be on top of the top contributors list in the lwn.net pages like Kumar was. Oh well. Paulus, Can we just kill all of arch/ppc for .27 right now? Please. Pretty please? Acked-by: Josh Boyer [EMAIL PROTECTED] josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Josh Boyer wrote: From a device tree perspective, index and cell-index are both incorrect. The IIC macros don't share register blocks with anything, are enumerated as unique instances per macro in the device tree, and should be able to be distinguished by regs and/or unit address. I think we should just expand the definition of cell-index to include standard device enumeration for when it's needed. The original definition is too limited, IMHO. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Josh Boyer wrote: seems to be a more distinct definition of what this is. But I have no idea how well that would go over, and it would probably need to be changed in all the fsl boards as well. Which would end up breaking backwards compatibility with older device trees. Like I said earlier, I'm in favor of expanding the definition of cell-index. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Stefan Roese wrote: So what should we do now? Currently I2C doesn't work at all on 4xx since the driver expects the index property and no dts sets this property. Personally I would like to move to using cell-index here, since this seems to be more common. But I could also life with removing the index property and using the static index if this is preferred and/or acceptable. My opinion: In situations where it doesn't matter which I2C bus is #1 and which one is #2, then I think the code should just initialize idx based on the order the nodes are found in the tree. In situations where it does matter, then we should use cell-index. The patch I posted (Update fsl_soc to use cell-index property of I2C nodes) does both. If the cell-index property is present, then its value is used in the call to platform_device_register_simple(). Otherwise, it just keeps count of each node, and uses that count. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, Jun 5, 2008 at 9:13 AM, Timur Tabi [EMAIL PROTECTED] wrote: Josh Boyer wrote: From a device tree perspective, index and cell-index are both incorrect. The IIC macros don't share register blocks with anything, are enumerated as unique instances per macro in the device tree, and should be able to be distinguished by regs and/or unit address. I think we should just expand the definition of cell-index to include standard device enumeration for when it's needed. The original definition is too limited, IMHO. nak if you need explicit indexing then use an alias. My opinion however is that explicit indexing is unnecessary and is just an artifact of current i2c subsystem internals. There is already enough information in the device tree to match i2c devices with i2c busses without resorting to indexes. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Grant Likely wrote: if you need explicit indexing then use an alias. My opinion however is that explicit indexing is unnecessary and is just an artifact of current i2c subsystem internals. There is already enough information in the device tree to match i2c devices with i2c busses without resorting to indexes. Not for ALSA SoC V2 devices. In ASoC V2, the fabric driver needs to identify the codec by its specific I2C bus and address number. The codec driver is not an OF driver (normally), so it doesn't have access to any OF data. It's just an I2C driver, so its given an I2C address and some number that represents an adapter. Therefore, the fabric driver and the codec driver need to independently determine the I2C bus number, and they need to match. The fabric driver parses the OF tree and looks up the cell-index property. The codec driver uses the adapter-nr variable. The patch I posted ensures that the two contain the same number. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Hi Timur, In situations where it doesn't matter which I2C bus is #1 and which one is #2, then I think the code should just initialize idx based on the order the nodes are found in the tree. In situations where it does matter, then we should use cell-index. that's what I did in i2c-cpm, as well. However, here I use the property linux,i2c-index instead (see http://patchwork.ozlabs.org/linuxppc/patch?id=18603). Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
I think we should just expand the definition of cell-index to include standard device enumeration for when it's needed. The original definition is too limited, IMHO. nak if you need explicit indexing then use an alias. My opinion however is that explicit indexing is unnecessary and is just an artifact of current i2c subsystem internals. There is already enough information in the device tree to match i2c devices with i2c busses without resorting to indexes. Fully agreed. Let me say it as well, it makes me feel powerful: NAK Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 4xx support in arch/ppc is going away Real Soon Now
-Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Josh Boyer Sent: Thursday, June 05, 2008 8:19 AM To: Grant Likely Cc: linuxppc-dev@ozlabs.org; Paul Mackerras Subject: Re: 4xx support in arch/ppc is going away Real Soon Now On Thu, 5 Jun 2008 09:11:48 -0600 Grant Likely [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 8:52 AM, Josh Boyer [EMAIL PROTECTED] wrote: This commit (patch omitted due to size) is sitting in my local tree: commit 0d7efc1e80fc262bcc507a605482c5681e3f082a Author: Josh Boyer [EMAIL PROTECTED] Date: Thu Jun 5 09:46:17 2008 -0500 ppc/4xx: Remove 4xx support from arch/ppc Remove support for PPC 403, 405, and 440 processors from arch/ppc. The arch/powerpc equivalents should be used. Boards that are not ported yet will need to be ported to arch/powerpc to have continued support. This looks like unneeded churn. Excellent. My prompting has succeeded. Though now I won't get to be on top of the top contributors list in the lwn.net pages like Kumar was. Oh well. Paulus, Can we just kill all of arch/ppc for .27 right now? Please. Pretty please? Acked-by: Josh Boyer [EMAIL PROTECTED] josh For what it's worth, Acked-by: Stephen Neuendorffer [EMAIL PROTECTED] I'd like to see this happen soon so a few stacked patches we have can finally go in. Steve This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Jochen Friedrich wrote: Hi Timur, In situations where it doesn't matter which I2C bus is #1 and which one is #2, then I think the code should just initialize idx based on the order the nodes are found in the tree. In situations where it does matter, then we should use cell-index. that's what I did in i2c-cpm, as well. However, here I use the property linux,i2c-index instead (see http://patchwork.ozlabs.org/linuxppc/patch?id=18603). Well, I just don't see the point of having two different properties that say the same thing. I'm not an IEE 1275 purist, so I don't think we should be hampered by old node definitions. I especially don't like having a property specifically for indexing I2C nodes that can't be used to enumerate other nodes. The DMA and SSI controllers on Freescale parts use cell-index to enumerate them. It just seems dumb to invent a new property. Will there ever be a situation where a node will contain cell-index and linux,i2c-index? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Hi Grant, if you need explicit indexing then use an alias. My opinion however is that explicit indexing is unnecessary and is just an artifact of current i2c subsystem internals. There is already enough information in the device tree to match i2c devices with i2c busses without resorting to indexes. True. However, there are currently drivers which need platform data for its initialisation (like drivers/gpio/pca953x.c). Unless these drivers are rewritten, they can't be loaded just by parsing the device tree, so they must be loaded from platform init code and here the adapter index is needed to attach the driver. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
if you need explicit indexing then use an alias. My opinion however is that explicit indexing is unnecessary and is just an artifact of current i2c subsystem internals. There is already enough information in the device tree to match i2c devices with i2c busses without resorting to indexes. Not for ALSA SoC V2 devices. In ASoC V2, the fabric driver needs to identify the codec by its specific I2C bus and address number. The codec driver is not an OF driver (normally), so it doesn't have access to any OF data. It's just an I2C driver, so its given an I2C address and some number that represents an adapter. Therefore, the fabric driver and the codec driver need to independently determine the I2C bus number, and they need to match. The fabric driver parses the OF tree and looks up the cell-index property. The codec driver uses the adapter-nr variable. The patch I posted ensures that the two contain the same number. Sounds to me like both simply need to use adapter-nr. For access to Linux-internal data structures (and that is what this index is), you shouldn't have to go via the device tree. If the Linux data structures do not have the information you need, well, fix that. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, Jun 5, 2008 at 9:52 AM, Jochen Friedrich [EMAIL PROTECTED] wrote: Hi Grant, if you need explicit indexing then use an alias. My opinion however is that explicit indexing is unnecessary and is just an artifact of current i2c subsystem internals. There is already enough information in the device tree to match i2c devices with i2c busses without resorting to indexes. True. However, there are currently drivers which need platform data for its initialisation (like drivers/gpio/pca953x.c). Unless these drivers are rewritten, they can't be loaded just by parsing the device tree, so they must be loaded from platform init code and here the adapter index is needed to attach the driver. ... which means that platform code is responsible to figure it out. Don't encode it into the device tree. Besides, this is just a binding. I see absolutely no problem adding probe code to the bindings to extract data from the device tree. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [v2] Fix definitions for dbcr0, dbcr1, dbcr2 register for bookE processors
Update: Consolidated dbcr1 dbcr2 under one define. Taken from the PowerPC ISA BookIII-E specifies that DBCR0 is different for all others that are not ppc405 chips. So I have now chnaged the conditional to reflect this. Also added definitions needed for DBCR1 DBCR2. Signed-off-by: Jerone Young [EMAIL PROTECTED] diff --git a/include/asm-powerpc/reg_booke.h b/include/asm-powerpc/reg_booke.h --- a/include/asm-powerpc/reg_booke.h +++ b/include/asm-powerpc/reg_booke.h @@ -253,6 +253,7 @@ #define ESR_BO 0x0002 /* Byte Ordering */ /* Bit definitions related to the DBCR0. */ +#if defined(CONFIG_40x) #define DBCR0_EDM 0x8000 /* External Debug Mode */ #define DBCR0_IDM 0x4000 /* Internal Debug Mode */ #define DBCR0_RST 0x3000 /* all the bits in the RST field */ @@ -275,6 +276,44 @@ #define DBCR0_IA12T0x8000 /* Instr Addr 1-2 range Toggle */ #define DBCR0_IA34T0x4000 /* Instr Addr 3-4 range Toggle */ #define DBCR0_FT 0x0001 /* Freeze Timers on debug event */ +#elif defined(CONFIG_BOOKE) +#define DBCR0_EDM 0x8000 /* External Debug Mode */ +#define DBCR0_IDM 0x4000 /* Internal Debug Mode */ +#define DBCR0_RST 0x3000 /* all the bits in the RST field */ +#define DBCR0_RST_SYSTEM 0x3000/* System Reset */ +#define DBCR0_RST_CHIP 0x2000 /* Chip Reset */ +#define DBCR0_RST_CORE 0x1000 /* Core Reset */ +#define DBCR0_RST_NONE 0x /* No Reset */ +#define DBCR0_IC 0x0800 /* Instruction Completion */ +#define DBCR0_BT 0x0400 /* Branch Taken */ +#define DBCR0_EDE 0x0200 /* Exception Debug Event */ +#define DBCR0_TDE 0x0100 /* TRAP Debug Event */ +#define DBCR0_IA1 0x0080 /* Instr Addr compare 1 enable */ +#define DBCR0_IA2 0x0040 /* Instr Addr compare 2 enable */ +#define DBCR0_IA3 0x0020 /* Instr Addr compare 3 enable */ +#define DBCR0_IA4 0x0010 /* Instr Addr compare 4 enable */ +#define DBCR0_DAC1R0x0008 /* DAC 1 Read enable */ +#define DBCR0_DAC1W0x0004 /* DAC 1 Write enable */ +#define DBCR0_DAC2R0x0002 /* DAC 2 Read enable */ +#define DBCR0_DAC2W0x0001 /* DAC 2 Write enable */ +#define DBCR0_RET 0x8000 /* Return Debug Event */ +#define DBCR0_FT 0x0001 /* Freeze Timers on debug event */ +#endif + +#if defined(CONFIG_BOOKE) +/* Bit definitions related to the DBCR1. */ +#define DBCR1_IA12 0x0080 /* Instr Addr 1-2 range enable */ +#define DBCR1_IA12X0x00C0 /* Instr Addr 1-2 range eXclusive */ +#define DBCR1_IA12T0x0001 /* Instr Addr 1-2 range Toggle */ +#define DBCR1_IA34 0x0080 /* Instr Addr 3-4 range enable */ +#define DBCR1_IA34X0x00C0 /* Instr Addr 3-4 range eXclusive */ +#define DBCR1_IA34T0x0001 /* Instr Addr 3-4 range Toggle */ + +/* Bit definitions related to the DBCR2. */ +#define DBCR2_DAC120x0080 /* DAC 1-2 range enable */ +#define DBCR2_DAC12X 0x00C0 /* DAC 1-2 range eXclusive */ +#define DBCR2_DAC12A 0x0020 /* DAC 1-2 Asynchronous */ +#endif /* Bit definitions related to the TCR. */ #define TCR_WP(x) (((x)0x3)30) /* WDT Period */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] mmc: change .get_ro() callback semantics
On Thursday 05 June 2008, Anton Vorontsov wrote:
On Tue, Jun 03, 2008 at 12:07:49PM +0200, Marc Pignat wrote:
Hi all!
On Friday 23 May 2008, Anton Vorontsov wrote:
get_ro() callback must return values = 0 for its logical state, and
...
static void pxamci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index f2e9885..ef3b773 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -55,6 +55,9 @@ struct mmc_host_ops {
* Avoid calling these three functions too often or in a fast path,
* since underlaying controller might implement them in an expensive
* and/or slow way.
+ *
+ * .get_ro and .get_cd should return = 0 for their logical values,
+ * or negative errno value in case of error.
*/
I would suggest to use something more strict (bulletproof), something like:
/*
* get_ro will return:
* 0 for a read/write card
* 1 for a read-only card
This isn't always practical. For example, host is using u8 register for
the status, so it might safely return u8 mask, that will always fit
into int. Or very smart/adventurous authors might be aware that, for the
particular host, mask's bit isn't last, and safely do uXX mask. :-)
The above is weak argument of course, since it is about optimization.
Ack, we will gain at most 1-4 assembly instructions, in a function that
is unlikely to be called more than once a second.
As an counter-evidence, the strict scheme that you described probably
less error prone. But is it? To implement it we'll need something like
WARN_ON(ret 0 ret != 1) to catch erroneous users. Take a closer
look though, will it catch uXX lastbit case? Nope. :-)
WARN_ON(ret 0 ret != 1 || ret == INT_MIN) will do ;)
I agree with you once more, I never thinked about a runtime check.
I don't really want to see a WARN_ON(foo) after each call to get_ro or get_cd.
But I'm sure if we specify give me a positive value when a card is detected,
someone will write gpio bit, and three years later, someone will fall in
the (gpio lastbit 0 case).
So we should specify: give me 1 whan a card is present, 0 when not, -ENOSYS if
you don't know and a negative errno when something else goes wrong.
Best regards
Marc
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, Jun 5, 2008 at 9:43 AM, Timur Tabi [EMAIL PROTECTED] wrote: Grant Likely wrote: if you need explicit indexing then use an alias. My opinion however is that explicit indexing is unnecessary and is just an artifact of current i2c subsystem internals. There is already enough information in the device tree to match i2c devices with i2c busses without resorting to indexes. Not for ALSA SoC V2 devices. In ASoC V2, the fabric driver needs to identify the codec by its specific I2C bus and address number. The codec driver is not an OF driver (normally), so it doesn't have access to any OF data. It's just an I2C driver, so its given an I2C address and some number that represents an adapter. Therefore, the fabric driver and the codec driver need to independently determine the I2C bus number, and they need to match. The fabric driver parses the OF tree and looks up the cell-index property. The codec driver uses the adapter-nr variable. The patch I posted ensures that the two contain the same number. That is still Linux internal artifacts leaking out. Don't encode that data into the device tree. Besides, the whole thing looks bass ackwards and doesn't match the Linux driver model. 'busses' should register 'devices'. 'drivers' should then bind to those 'devices'. Where ASoC is concerned, the i2c bus should register its own child devices, which includes the codecs, and an ASoC codec driver should bind against it. The fabric driver should then use the codec's exported API. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Segher Boessenkool wrote: Sounds to me like both simply need to use adapter-nr. How can a non-I2C driver get the adapter structure for another driver that is an I2C driver? For access to Linux-internal data structures (and that is what this index is), you shouldn't have to go via the device tree. If the Linux data structures do not have the information you need, well, fix that. The fabric driver doesn't have access to any I2C structures when it starts looking for the codec driver. The fabric driver is like an OF platform driver, in that it's OF-aware and machine-specific. By parsing the device tree (which is the only tool I have to know how the board is laid out), the fabric driver can determine that SSI1 is attached to a CS4270 on I2C bus #1, address 0x4F. That's the only information it has. The CS4270 driver, on the other hand, knows nothing about OF. It just knows whatever is passed to its I2C probe function, i.e. the i2c_adapter and i2c_client structures. So in order for the two drivers to be able to link to each other, there needs to be some code that takes data from the device tree and places it into the I2C data structures. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, Jun 5, 2008 at 9:50 AM, Timur Tabi [EMAIL PROTECTED] wrote:
Jochen Friedrich wrote:
Hi Timur,
In situations where it doesn't matter which I2C bus is #1 and which one is
#2,
then I think the code should just initialize idx based on the order the
nodes
are found in the tree.
In situations where it does matter, then we should use cell-index.
that's what I did in i2c-cpm, as well. However, here I use the property
linux,i2c-index instead (see
http://patchwork.ozlabs.org/linuxppc/patch?id=18603).
Well, I just don't see the point of having two different properties that say
the
same thing. I'm not an IEE 1275 purist, so I don't think we should be
hampered
by old node definitions. I especially don't like having a property
specifically
for indexing I2C nodes that can't be used to enumerate other nodes.
The DMA and SSI controllers on Freescale parts use cell-index to enumerate
them.
It just seems dumb to invent a new property.
Will there ever be a situation where a node will contain cell-index and
linux,i2c-index?
You are trying to describe 2 different things. cell-index is purely
for identifying multiple devices within a silicon block that share
resources. Indexing devices has a very different scope. The whole
scheme breaks the moment you put down 2 identical multifunction
peripherals into the same system. If the chip has multiple devices
that share resources, and those resources are described with cell
index; then you'll get something like this (notice how cell-index
values are duplicated):
[EMAIL PROTECTED] {
#size-cells = 1;
#address-cells = 1;
ranges = 0 0xe 0x1000;
[EMAIL PROTECTED] {
cell-index = 0;
regs = 0 0x100;
}
[EMAIL PROTECTED] {
cell-index = 1;
regs = 0x100 0x100;
}
}
[EMAIL PROTECTED] {
#size-cells = 1;
#address-cells = 1;
ranges = 0 0xe1000 0x1000;
[EMAIL PROTECTED] {
cell-index = 0;
regs = 0 0x100;
}
[EMAIL PROTECTED] {
cell-index = 1;
regs = 0x100 0x100;
}
}
cell-index must *not* be repurposed as a system level index.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Grant Likely wrote: That is still Linux internal artifacts leaking out. Don't encode that data into the device tree. The I2C bus number is *not* an internal artifact. On Freescale parts, the one I2C adapter is specifically designated I2C1, and the 2nd one is specifically designated I2C2. This is part of the silicon, and so the device tree should specify it. Besides, the whole thing looks bass ackwards and doesn't match the Linux driver model. 'busses' should register 'devices'. 'drivers' should then bind to those 'devices'. Where ASoC is concerned, the i2c bus should register its own child devices, which includes the codecs, and an ASoC codec driver should bind against it. The fabric driver should then use the codec's exported API. Sorry, I don't really understand that. The codec driver is just an I2C driver that registers callbacks with ASoC. The fabric driver does not know what codec driver is present. In many cases, there could be multiple codecs. Sometimes they're the same type of codec, just at different I2C addresses. Sometimes, they're completely different codecs. So I could have any number of codec drivers loaded. How would I know which exported API to call? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [RFC v3] OF: OpenFirmware bindings for the mmc_spi driver
Here is v3. I'm out of ideas if you won't like it. :-)
v3:
- Now these bindings are using bus notifiers chain, thus we adhere to the
spi bus.
By the way, this scheme (IMO) looks good for I2C devices which needs
platform_data extracted from the device tree too (Cc'ing Jochen).
- Plus changed the OF bindings themselves, implemented voltage-range
property. (Pierre, please take a look at vddrange_to_ocrmask(). I
wonder if you would like this in the MMC core instead, with a kernel
doc, of course.)
v2:
- Bindings were adhered to the MMC_SPI driver. Withdrawn by Pierre Ossman.
v1:
- Bindings were adhered to the OF SPI core. Withdrawn by OF people.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt | 21 +++
drivers/of/Kconfig |8 +
drivers/of/Makefile |1 +
drivers/of/of_mmc_spi.c | 210 ++
4 files changed, 240 insertions(+), 0 deletions(-)
create mode 100644 drivers/of/of_mmc_spi.c
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 6e1711c..6c55f3f 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -3143,7 +3143,28 @@ platforms are moved over to use the
flattened-device-tree model.
};
};
+...) MMC-over-SPI
+ Required properties:
+ - compatible : should be mmc-spi.
+ - reg : should specify SPI address (chip-select number).
+ - max-speed : (optional) maximum frequency for this device (Hz).
+ - voltage-range : two cells are required, first cell specifies minimum
+slot voltage (mV), second cell specifies maximum slot voltage (mV).
+ - gpios : (optional) may specify GPIOs in this order: Write-Protect GPIO,
+Card-Detect GPIO.
+
+ Example:
+
+ [EMAIL PROTECTED] {
+ compatible = mmc-spi;
+ reg = 0;
+ max-speed = 5000;
+ /* Unregulated slot. */
+ voltage-range = 3300 3300;
+ gpios = sdcsr_pio 1 0 /* WP */
+sdcsr_pio 0 1; /* nCD */
+ };
VII - Marvell Discovery mv64[345]6x System Controller chips
===
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 3a7a11a..aadbfb3 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -13,3 +13,11 @@ config OF_I2C
depends on PPC_OF I2C
help
OpenFirmware I2C accessors
+
+config OF_MMC_SPI
+ bool OpenFirmware bindings for MMC/SD over SPI
+ depends on PPC_OF SPI
+ default y if MMC_SPI
+ help
+ Say Y here to enable OpenFirmware bindings for the MMC/SD over SPI
+ driver.
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 548772e..a7c44fc 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -2,3 +2,4 @@ obj-y = base.o
obj-$(CONFIG_OF_DEVICE) += device.o platform.o
obj-$(CONFIG_OF_GPIO) += gpio.o
obj-$(CONFIG_OF_I2C) += of_i2c.o
+obj-$(CONFIG_OF_MMC_SPI) += of_mmc_spi.o
diff --git a/drivers/of/of_mmc_spi.c b/drivers/of/of_mmc_spi.c
new file mode 100644
index 000..aa4e017
--- /dev/null
+++ b/drivers/of/of_mmc_spi.c
@@ -0,0 +1,210 @@
+/*
+ * OpenFirmware bindings for the MMC-over-SPI driver
+ *
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Anton Vorontsov [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/init.h
+#include linux/device.h
+#include linux/notifier.h
+#include linux/gpio.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/of_platform.h
+#include linux/spi/spi.h
+#include linux/spi/mmc_spi.h
+#include linux/mmc/host.h
+
+/*
+ * XXX: Place it somewhere in the generic MMC code?
+ */
+static int vdd_to_bitnum(int vdd)
+{
+ int bit;
+ const int max_bit = ilog2(MMC_VDD_35_36);
+
+ if (vdd 1650 || vdd 3600)
+ return -EINVAL;
+
+ if (vdd = 1650 vdd = 1950)
+ return ilog2(MMC_VDD_165_195);
+
+ /* base 2000 mV, step 100 mV, bit's base 8 */
+ bit = (vdd - 2000) / 100 + 8;
+ if (bit max_bit)
+ return max_bit;
+ return bit;
+}
+
+static int vddrange_to_ocrmask(int vdd_min, int vdd_max, unsigned int *mask)
+{
+ if (vdd_max vdd_min)
+ return -EINVAL;
+
+ vdd_max = vdd_to_bitnum(vdd_max);
+ if (vdd_max 0)
+ return -EINVAL;
+
+ vdd_min = vdd_to_bitnum(vdd_min);
+ if (vdd_min 0)
+ return -EINVAL;
+
+ /* fill the mask, from max bit to min bit */
+
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, 05 Jun 2008 11:13:23 -0500 Timur Tabi [EMAIL PROTECTED] wrote: Grant Likely wrote: That is still Linux internal artifacts leaking out. Don't encode that data into the device tree. The I2C bus number is *not* an internal artifact. On Freescale parts, the one I2C adapter is specifically designated I2C1, and the 2nd one is specifically designated I2C2. This is part of the silicon, and so the device tree should specify it. And it does. It does so by the unique regs properties and unit-names. You can assign the index that the i2c subsystem needs based on probe order, like I already said. I don't know why Jean doesn't like that. It's not a made up number. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Hi Timur, It's a little late for that. I'm okay with coming up with a new property to provide system-level indexing, but it needs to be the same property name for each type of device. I don't want linux,i2c-index and linux,dma-index and linux,ssi-index, etc. I also don't understand why we need the linux, prefix, since device enumeration is not specific to Linux. Full ACK here. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [v2] Fix definitions for dbcr0, dbcr1, dbcr2 register for bookE processors
On Jun 5, 2008, at 10:56 AM, Jerone Young wrote: Update: Consolidated dbcr1 dbcr2 under one define. Taken from the PowerPC ISA BookIII-E specifies that DBCR0 is different for all others that are not ppc405 chips. So I have now chnaged the conditional to reflect this. Also added definitions needed for DBCR1 DBCR2. Signed-off-by: Jerone Young [EMAIL PROTECTED] diff --git a/include/asm-powerpc/reg_booke.h b/include/asm-powerpc/ reg_booke.h --- a/include/asm-powerpc/reg_booke.h +++ b/include/asm-powerpc/reg_booke.h @@ -253,6 +253,7 @@ #define ESR_BO 0x0002 /* Byte Ordering */ /* Bit definitions related to the DBCR0. */ +#if defined(CONFIG_40x) #define DBCR0_EDM 0x8000 /* External Debug Mode */ #define DBCR0_IDM 0x4000 /* Internal Debug Mode */ #define DBCR0_RST 0x3000 /* all the bits in the RST field */ @@ -275,6 +276,44 @@ #define DBCR0_IA12T 0x8000 /* Instr Addr 1-2 range Toggle */ #define DBCR0_IA34T 0x4000 /* Instr Addr 3-4 range Toggle */ #define DBCR0_FT0x0001 /* Freeze Timers on debug event */ +#elif defined(CONFIG_BOOKE) +#define DBCR0_EDM 0x8000 /* External Debug Mode */ +#define DBCR0_IDM 0x4000 /* Internal Debug Mode */ +#define DBCR0_RST 0x3000 /* all the bits in the RST field */ +#define DBCR0_RST_SYSTEM 0x3000/* System Reset */ +#define DBCR0_RST_CHIP 0x2000 /* Chip Reset */ +#define DBCR0_RST_CORE 0x1000 /* Core Reset */ +#define DBCR0_RST_NONE 0x /* No Reset */ Add a comment about these RST_ being 44x specific, fsl booke doesnt follow this. +#define DBCR0_IC 0x0800 /* Instruction Completion */ +#define DBCR0_BT 0x0400 /* Branch Taken */ +#define DBCR0_EDE 0x0200 /* Exception Debug Event */ +#define DBCR0_TDE 0x0100 /* TRAP Debug Event */ +#define DBCR0_IA1 0x0080 /* Instr Addr compare 1 enable */ +#define DBCR0_IA2 0x0040 /* Instr Addr compare 2 enable */ +#define DBCR0_IA3 0x0020 /* Instr Addr compare 3 enable */ +#define DBCR0_IA4 0x0010 /* Instr Addr compare 4 enable */ Can we stick with orig book-e field names, ICMP, BRT, IRPT, TRAP, IAC1, IAC2, IAC3, IAC4. These are also the names in the POWER 2.05 ISA spec. +#define DBCR0_DAC1R0x0008 /* DAC 1 Read enable */ +#define DBCR0_DAC1W0x0004 /* DAC 1 Write enable */ +#define DBCR0_DAC2R0x0002 /* DAC 2 Read enable */ +#define DBCR0_DAC2W0x0001 /* DAC 2 Write enable */ +#define DBCR0_RET 0x8000 /* Return Debug Event */ +#define DBCR0_FT 0x0001 /* Freeze Timers on debug event */ +#endif + +#if defined(CONFIG_BOOKE) +/* Bit definitions related to the DBCR1. */ +#define DBCR1_IA12 0x0080 /* Instr Addr 1-2 range enable */ +#define DBCR1_IA12X0x00C0 /* Instr Addr 1-2 range eXclusive */ +#define DBCR1_IA12T0x0001 /* Instr Addr 1-2 range Toggle */ +#define DBCR1_IA34 0x0080 /* Instr Addr 3-4 range enable */ +#define DBCR1_IA34X0x00C0 /* Instr Addr 3-4 range eXclusive */ +#define DBCR1_IA34T0x0001 /* Instr Addr 3-4 range Toggle */ Is there a reason you don't have all the fields? IAC1US, IAC1ER, etc..? + +/* Bit definitions related to the DBCR2. */ +#define DBCR2_DAC120x0080 /* DAC 1-2 range enable */ +#define DBCR2_DAC12X 0x00C0 /* DAC 1-2 range eXclusive */ +#define DBCR2_DAC12A 0x0020 /* DAC 1-2 Asynchronous */ similar comment about matching 2.05 spec. +#endif /* Bit definitions related to the TCR. */ #define TCR_WP(x) (((x)0x3)30) /* WDT Period */ - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, Jun 05, 2008 at 11:09:16AM -0500, Timur Tabi wrote: The fabric driver doesn't have access to any I2C structures when it starts looking for the codec driver. The fabric driver is like an OF platform driver, in that it's OF-aware and machine-specific. By parsing the device tree (which is the only tool I have to know how the board is laid out), the fabric driver can determine that SSI1 is attached to a CS4270 on I2C bus #1, address 0x4F. That's the only information it has. No, it's not. It can determine that it's at address 0x4f on the i2c bus at 0xe0003100. This is exactly how the ethernet phy lookup is done. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, Jun 5, 2008 at 10:22 AM, Jochen Friedrich [EMAIL PROTECTED] wrote: Hi Timur, It's a little late for that. I'm okay with coming up with a new property to provide system-level indexing, but it needs to be the same property name for each type of device. I don't want linux,i2c-index and linux,dma-index and linux,ssi-index, etc. I also don't understand why we need the linux, prefix, since device enumeration is not specific to Linux. Full ACK here. NAK because there is already a mechanism that does what you want. Its called the aliases node. For the record, I'm making 2 arguments here: 1) if you *do* need an enumerated index then use the aliases node. You don't need to invent a new property 2) for i2c purposes, explicit enumeration is not needed or desired. All the necessary data is already present in the device tree in that i2c device nodes are children of i2c bus nodes. The i2c bus numbers should be dynamically assigned. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Josh Boyer wrote: And it does. It does so by the unique regs properties and unit-names. You can assign the index that the i2c subsystem needs based on probe order, like I already said. The probe order is not sufficient on platforms that specifically enumerate their I2C (or whatever) devices. For instance, in order to do audio playback on an MPC8610, SSI1 needs to use DMA channel 0. The SSI driver specifically needs to find the register addresses for DMA channel 0. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, Jun 5, 2008 at 10:18 AM, Timur Tabi [EMAIL PROTECTED] wrote:
Grant Likely wrote:
[EMAIL PROTECTED] {
#size-cells = 1;
#address-cells = 1;
ranges = 0 0xe 0x1000;
[EMAIL PROTECTED] {
cell-index = 0;
regs = 0 0x100;
}
[EMAIL PROTECTED] {
cell-index = 1;
regs = 0x100 0x100;
}
}
[EMAIL PROTECTED] {
#size-cells = 1;
#address-cells = 1;
ranges = 0 0xe1000 0x1000;
[EMAIL PROTECTED] {
cell-index = 0;
regs = 0 0x100;
}
[EMAIL PROTECTED] {
cell-index = 1;
regs = 0x100 0x100;
}
}
What resources are being shared in this example? Each I2C device has its own
address ranges. I don't see how cell-index provides any useful info here.
As I said; *assume* that the i2c devices have shared resources. I
didn't explicitly show them in the example, but assume that there are
shared registers in the multifunction nodes.
cell-index provides details about which bits in the shared registers
belong to the device, but since there are 2 identical multifunction
devices in the system there are 2 sets of shared regs. You cannot now
use the values 0, 1, 2 and 3 for each cell index because '2' and '3'
have no valid meaning on how to reference the shared resource. So,
cell-index isn't useful for enumerating the i2c busses at the system
level.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, Jun 5, 2008 at 10:25 AM, Timur Tabi [EMAIL PROTECTED] wrote: Josh Boyer wrote: And it does. It does so by the unique regs properties and unit-names. You can assign the index that the i2c subsystem needs based on probe order, like I already said. The probe order is not sufficient on platforms that specifically enumerate their I2C (or whatever) devices. For instance, in order to do audio playback on an MPC8610, SSI1 needs to use DMA channel 0. The SSI driver specifically needs to find the register addresses for DMA channel 0. then you use a phandle for that; but that entirely different from bus enumeration because it describes a real property of the hardware. Cheers, g. -- Timur Tabi Linux kernel developer at Freescale -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Grant Likely wrote: 2) for i2c purposes, explicit enumeration is not needed or desired. All the necessary data is already present in the device tree in that i2c device nodes are children of i2c bus nodes. The i2c bus numbers should be dynamically assigned. NACK. For ASoC driver, they cannot be dynamically assigned. I2C1 must be labeled as such. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC v3] OF: OpenFirmware bindings for the mmc_spi driver
On Thu, Jun 5, 2008 at 10:16 AM, Anton Vorontsov [EMAIL PROTECTED] wrote: Here is v3. I'm out of ideas if you won't like it. :-) v3: - Now these bindings are using bus notifiers chain, thus we adhere to the spi bus. By the way, this scheme (IMO) looks good for I2C devices which needs platform_data extracted from the device tree too (Cc'ing Jochen). - Plus changed the OF bindings themselves, implemented voltage-range property. (Pierre, please take a look at vddrange_to_ocrmask(). I wonder if you would like this in the MMC core instead, with a kernel doc, of course.) v2: - Bindings were adhered to the MMC_SPI driver. Withdrawn by Pierre Ossman. Personally I think your v2 was better, and if I'm interpreting Pierre's comments correctly I think his main point is that instead of using the 'stock' probe/remove hooks for the spi mmc driver, the driver should be mildly reworked to provide a common block of code that can be used by both the OF and non-OF versions of the probe/remove routines. I also think that is the way to go. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: inline assembly
On Thu, Jun 05, 2008 at 11:44:51AM +0100, David Howells wrote: Scott Wood [EMAIL PROTECTED] wrote: int tmp; asm volatile(addi %1, %2, -1; andc %1, %2, %1; cntlzw %1, %1; subfic %0, %1, 31 : =r (j), =r (tmp) : r (i)); Registers are usually assumed to be 'long' in size, so I'd recommend using that rather than 'int' for tmp, though I suspect it'll make little difference (except, perhaps on x86 where you can partially use registers). I had originally written that as long, but I changed it since the asm code is explicitly assuming 32-bit. It's more documentation than anything else. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] mmc: toughen get_ro() and get_cd() return values
For the sake of safety, document that drivers should return only
1 or 0 from the get_ro() and get_cd() callbacks. Also document context
in which these callbacks should be executed.
wbsd driver modified to comply with this requirement.
Also, fix mmc_spi driver to not return raw values from the platform
get_cd hook (oops).
Suggested-by: Marc Pignat [EMAIL PROTECTED]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
On Thu, Jun 05, 2008 at 05:58:59PM +0200, Marc Pignat wrote:
[...]
* get_ro will return:
* 0 for a read/write card
* 1 for a read-only card
This isn't always practical. For example, host is using u8 register for
the status, so it might safely return u8 mask, that will always fit
into int. Or very smart/adventurous authors might be aware that, for the
particular host, mask's bit isn't last, and safely do uXX mask. :-)
The above is weak argument of course, since it is about optimization.
Ack, we will gain at most 1-4 assembly instructions, in a function that
is unlikely to be called more than once a second.
As an counter-evidence, the strict scheme that you described probably
less error prone. But is it? To implement it we'll need something like
WARN_ON(ret 0 ret != 1) to catch erroneous users. Take a closer
look though, will it catch uXX lastbit case? Nope. :-)
WARN_ON(ret 0 ret != 1 || ret == INT_MIN) will do ;)
I agree with you once more, I never thinked about a runtime check.
I don't really want to see a WARN_ON(foo) after each call to get_ro or get_cd.
But I'm sure if we specify give me a positive value when a card is detected,
someone will write gpio bit, and three years later, someone will fall in
the (gpio lastbit 0 case).
So we should specify: give me 1 whan a card is present, 0 when not, -ENOSYS
if
you don't know and a negative errno when something else goes wrong.
Well, ok.
Pierre, I see you didn't yet pushed out the mmc tree, so.. would you
prefer this patch folded into 0/3 series and resent?
drivers/mmc/host/mmc_spi.c |2 +-
drivers/mmc/host/wbsd.c|2 +-
include/linux/mmc/host.h | 16 ++--
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index 85d9853..4e82f64 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -1139,7 +1139,7 @@ static int mmc_spi_get_cd(struct mmc_host *mmc)
struct mmc_spi_host *host = mmc_priv(mmc);
if (host-pdata host-pdata-get_cd)
- return host-pdata-get_cd(mmc-parent);
+ return !!host-pdata-get_cd(mmc-parent);
return -ENOSYS;
}
diff --git a/drivers/mmc/host/wbsd.c b/drivers/mmc/host/wbsd.c
index be624a0..9283b85 100644
--- a/drivers/mmc/host/wbsd.c
+++ b/drivers/mmc/host/wbsd.c
@@ -939,7 +939,7 @@ static int wbsd_get_ro(struct mmc_host *mmc)
spin_unlock_bh(host-lock);
- return csr WBSD_WRPT;
+ return !!(csr WBSD_WRPT);
}
static const struct mmc_host_ops wbsd_ops = {
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index ef3b773..753b723 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -56,8 +56,20 @@ struct mmc_host_ops {
* since underlaying controller might implement them in an expensive
* and/or slow way.
*
-* .get_ro and .get_cd should return = 0 for their logical values,
-* or negative errno value in case of error.
+* Also note that these functions might sleep, so don't call them
+* in the atomic contexts!
+*
+* Return values for the get_ro callback should be:
+* 0 for a read/write card
+* 1 for a read-only card
+* -ENOSYS when not supported (equal to NULL callback)
+* or a negative errno value when something bad happened
+*
+* Return values for the get_ro callback should be:
+* 0 for a absent card
+* 1 for a present card
+* -ENOSYS when not supported (equal to NULL callback)
+* or a negative errno value when something bad happened
*/
void(*set_ios)(struct mmc_host *host, struct mmc_ios *ios);
int (*get_ro)(struct mmc_host *host);
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3 1/4] [POWERPC] 85xx: correct vendor prefix in DTS files for TQM85xx modules
Like for the TQM5200, the vendor prefix tqc, is now used for all
TQM85xx modules from TQ-Components GmbH (http://www.tqc.de) in the
corresponding DTS files.
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/tqm8540.dts |4 ++--
arch/powerpc/boot/dts/tqm8541.dts |4 ++--
arch/powerpc/boot/dts/tqm8555.dts |4 ++--
arch/powerpc/boot/dts/tqm8560.dts |4 ++--
arch/powerpc/platforms/85xx/tqm85xx.c |8
5 files changed, 12 insertions(+), 12 deletions(-)
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8540.dts
===
--- linux-2.6-galak.orig/arch/powerpc/boot/dts/tqm8540.dts
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8540.dts
@@ -12,8 +12,8 @@
/dts-v1/;
/ {
- model = tqm,8540;
- compatible = tqm,8540, tqm,85xx;
+ model = tqc,8540;
+ compatible = tqc,8540, tqc,85xx;
#address-cells = 1;
#size-cells = 1;
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8541.dts
===
--- linux-2.6-galak.orig/arch/powerpc/boot/dts/tqm8541.dts
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8541.dts
@@ -12,8 +12,8 @@
/dts-v1/;
/ {
- model = tqm,8541;
- compatible = tqm,8541, tqm,85xx;
+ model = tqc,8541;
+ compatible = tqc,8541, tqc,85xx;
#address-cells = 1;
#size-cells = 1;
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8555.dts
===
--- linux-2.6-galak.orig/arch/powerpc/boot/dts/tqm8555.dts
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8555.dts
@@ -12,8 +12,8 @@
/dts-v1/;
/ {
- model = tqm,8555;
- compatible = tqm,8555, tqm,85xx;
+ model = tqc,8555;
+ compatible = tqc,8555, tqc,85xx;
#address-cells = 1;
#size-cells = 1;
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8560.dts
===
--- linux-2.6-galak.orig/arch/powerpc/boot/dts/tqm8560.dts
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8560.dts
@@ -12,8 +12,8 @@
/dts-v1/;
/ {
- model = tqm,8560;
- compatible = tqm,8560, tqm,85xx;
+ model = tqc,8560;
+ compatible = tqc,8560, tqc,85xx;
#address-cells = 1;
#size-cells = 1;
Index: linux-2.6-galak/arch/powerpc/platforms/85xx/tqm85xx.c
===
--- linux-2.6-galak.orig/arch/powerpc/platforms/85xx/tqm85xx.c
+++ linux-2.6-galak/arch/powerpc/platforms/85xx/tqm85xx.c
@@ -165,10 +165,10 @@ static int __init tqm85xx_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if ((of_flat_dt_is_compatible(root, tqm,8540)) ||
- (of_flat_dt_is_compatible(root, tqm,8541)) ||
- (of_flat_dt_is_compatible(root, tqm,8555)) ||
- (of_flat_dt_is_compatible(root, tqm,8560)))
+ if ((of_flat_dt_is_compatible(root, tqc,8540)) ||
+ (of_flat_dt_is_compatible(root, tqc,8541)) ||
+ (of_flat_dt_is_compatible(root, tqc,8555)) ||
+ (of_flat_dt_is_compatible(root, tqc,8560)))
return 1;
return 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3 2/4] [POWERPC] 85xx: add board support for the TQM8548 modules
This patch adds support for the TQM8548 modules from TQ-Components
GmbH (http://www.tqc.de).
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
arch/powerpc/boot/Makefile |1
arch/powerpc/boot/dts/tqm8548.dts | 365 +
arch/powerpc/boot/wrapper |2
arch/powerpc/configs/85xx/tqm8548_defconfig | 1094
arch/powerpc/platforms/85xx/Kconfig |8
arch/powerpc/platforms/85xx/tqm85xx.c | 15
6 files changed, 1482 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/boot/dts/tqm8548.dts
create mode 100644 arch/powerpc/configs/85xx/tqm8548_defconfig
Index: linux-2.6-galak/arch/powerpc/boot/Makefile
===
--- linux-2.6-galak.orig/arch/powerpc/boot/Makefile
+++ linux-2.6-galak/arch/powerpc/boot/Makefile
@@ -255,6 +255,7 @@ image-$(CONFIG_MPC85xx_DS) += cuImage.m
cuImage.mpc8572ds
image-$(CONFIG_TQM8540)+= cuImage.tqm8540
image-$(CONFIG_TQM8541)+= cuImage.tqm8541
+image-$(CONFIG_TQM8548)+= cuImage.tqm8548
image-$(CONFIG_TQM8555)+= cuImage.tqm8555
image-$(CONFIG_TQM8560)+= cuImage.tqm8560
image-$(CONFIG_SBC8548)+= cuImage.sbc8548
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8548.dts
===
--- /dev/null
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8548.dts
@@ -0,0 +1,365 @@
+/*
+ * TQM8548 Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ * Copyright 2008 Wolfgang Grandegger [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = tqc,8548;
+ compatible = tqc,8548, tqc,85xx;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ ethernet3 = enet3;
+
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32; // 32 bytes
+ i-cache-line-size = 32; // 32 bytes
+ d-cache-size = 0x8000;// L1, 32K
+ i-cache-size = 0x8000;// L1, 32K
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x2000;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges = 0x0 0xe000 0x10;
+ reg = 0xe000 0x1000; // CCSRBAR
+ bus-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8548-memory-controller;
+ reg = 0x2000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 18 2;
+ };
+
+ L2: [EMAIL PROTECTED] {
+ compatible = fsl,mpc8548-l2-cache-controller;
+ reg = 0x2 0x1000;
+ cache-line-size = 32; // 32 bytes
+ cache-size = 0x8; // L2, 512K
+ interrupt-parent = mpic;
+ interrupts = 16 2;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ compatible = fsl-i2c;
+ reg = 0x3100 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+
[PATCH v3 3/4] [POWERPC] 85xx: support for the TQM8548 module using the big Flash
Some TQM85xx boards could be equipped with up to 1 GiB (NOR) flash
memory and therefore a modified memory map is required and setup by
the board loader. This patch adds an appropriate DTS file.
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 365 +
1 file changed, 365 insertions(+)
create mode 100644 arch/powerpc/boot/dts/tqm8548-bigflash.dts
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8548-bigflash.dts
===
--- /dev/null
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8548-bigflash.dts
@@ -0,0 +1,365 @@
+/*
+ * TQM8548 Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ * Copyright 2008 Wolfgang Grandegger [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = tqc,8548;
+ compatible = tqc,8548, tqc,85xx;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ ethernet3 = enet3;
+
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32; // 32 bytes
+ i-cache-line-size = 32; // 32 bytes
+ d-cache-size = 0x8000;// L1, 32K
+ i-cache-size = 0x8000;// L1, 32K
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x2000;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges = 0x0 0xa000 0x10;
+ reg = 0xa000 0x1000; // CCSRBAR
+ bus-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8548-memory-controller;
+ reg = 0x2000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 18 2;
+ };
+
+ L2: [EMAIL PROTECTED] {
+ compatible = fsl,mpc8548-l2-cache-controller;
+ reg = 0x2 0x1000;
+ cache-line-size = 32; // 32 bytes
+ cache-size = 0x8; // L2, 512K
+ interrupt-parent = mpic;
+ interrupts = 16 2;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ compatible = fsl-i2c;
+ reg = 0x3100 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,gianfar-mdio;
+ reg = 0x24520 0x20;
+
+ phy1: [EMAIL PROTECTED] {
+ interrupt-parent = mpic;
+ interrupts = 8 1;
+ reg = 1;
+ device_type = ethernet-phy;
+ };
+ phy2: [EMAIL PROTECTED] {
+ interrupt-parent = mpic;
+ interrupts = 8 1;
+ reg = 2;
+ device_type = ethernet-phy;
+ };
+ phy3: [EMAIL PROTECTED] {
+ interrupt-parent = mpic;
+ interrupts = 8 1;
+ reg = 3;
+ device_type = ethernet-phy;
+ };
+ phy4:
[PATCH v3 4/4] [POWERPC] 85xx: add local bus nodes for Flash and CAN to tqm8560.dts
Add local bus nodes for Flash and CAN to the DTS file of the TQM8650 module.
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/tqm8560.dts | 65 ++
1 file changed, 65 insertions(+)
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8560.dts
===
--- linux-2.6-galak.orig/arch/powerpc/boot/dts/tqm8560.dts
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8560.dts
@@ -2,6 +2,7 @@
* TQM 8560 Device Tree Source
*
* Copyright 2008 Freescale Semiconductor Inc.
+ * Copyright 2008 Wolfgang Grandegger [EMAIL PROTECTED]
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -223,6 +224,70 @@
};
};
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8560-localbus, fsl,pq3-localbus,
+simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0xe0005000 0x100; // BRx, ORx, etc.
+
+ ranges =
+ 0 0x0 0xfc00 0x0400 // NOR FLASH bank 1
+ 1 0x0 0xf800 0x0800 // NOR FLASH bank 0
+ 2 0x0 0xe300 0x8000 // CAN (2 x i82527)
+ ;
+
+ [EMAIL PROTECTED],0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 1 0x0 0x800;
+ bank-width = 4;
+ device-width = 1;
+
+ [EMAIL PROTECTED] {
+ label = kernel;
+ reg = 0x 0x0020;
+ };
+ [EMAIL PROTECTED] {
+ label = root;
+ reg = 0x0020 0x0030;
+ };
+ [EMAIL PROTECTED] {
+ label = user;
+ reg = 0x0050 0x07a0;
+ };
+ [EMAIL PROTECTED] {
+ label = env1;
+ reg = 0x07f0 0x0004;
+ };
+ [EMAIL PROTECTED] {
+ label = env2;
+ reg = 0x07f4 0x0004;
+ };
+ [EMAIL PROTECTED] {
+ label = u-boot;
+ reg = 0x07f8 0x0008;
+ read-only;
+ };
+ };
+
+ /* Note: CAN support needs be enabled in U-Boot */
+ [EMAIL PROTECTED],0 {
+ compatible = intel,82527; // Bosch CC770
+ reg = 2 0x0 0x100;
+ interrupts = 4 0;
+ interrupt-parent = mpic;
+ };
+
+ [EMAIL PROTECTED],100 {
+ compatible = intel,82527; // Bosch CC770
+ reg = 2 0x100 0x100;
+ interrupts = 4 0;
+ interrupt-parent = mpic;
+ };
+ };
+
pci0: [EMAIL PROTECTED] {
cell-index = 0;
#interrupt-cells = 1;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] [POWERPC] 85xx: add board support for the TQM8548 modules
Kumar Gala wrote: On Jun 5, 2008, at 4:05 AM, Wolfgang Grandegger wrote: [POWERPC] 85xx: add board support for the TQM8548 modules This patch adds support for the TQM8548 modules from TQ-Components GmbH (http://www.tqc.de). Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED] [...deletions...] === --- linux-2.6-galak.orig/arch/powerpc/boot/wrapper +++ linux-2.6-galak/arch/powerpc/boot/wrapper @@ -177,7 +177,7 @@ cuboot*) *-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555|*-ksi8560*) platformo=$object/cuboot-85xx-cpm2.o ;; -*-mpc85*|*-tqm8540|*-sbc85*) +*-mpc85*|*-tqm8540|*-tqm8548|*-sbc85*) why not just *-tqm85* Hm, yes, *-tqm85* should cover all TQM85xx without CPM. I just sent out v3 patches addressing this and all other issues. Hope they are OK now. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC v3] OF: OpenFirmware bindings for the mmc_spi driver
On Thu, Jun 05, 2008 at 10:45:17AM -0600, Grant Likely wrote: On Thu, Jun 5, 2008 at 10:16 AM, Anton Vorontsov [EMAIL PROTECTED] wrote: Here is v3. I'm out of ideas if you won't like it. :-) v3: - Now these bindings are using bus notifiers chain, thus we adhere to the spi bus. By the way, this scheme (IMO) looks good for I2C devices which needs platform_data extracted from the device tree too (Cc'ing Jochen). - Plus changed the OF bindings themselves, implemented voltage-range property. (Pierre, please take a look at vddrange_to_ocrmask(). I wonder if you would like this in the MMC core instead, with a kernel doc, of course.) v2: - Bindings were adhered to the MMC_SPI driver. Withdrawn by Pierre Ossman. Personally I think your v2 was better, and if I'm interpreting Pierre's comments correctly I think his main point is that instead of using the 'stock' probe/remove hooks for the spi mmc driver, the driver should be mildly reworked to provide a common block of code that can be used by both the OF and non-OF versions of the probe/remove routines. I also think that is the way to go. Well, I mentioned the usb_add_hcd()-alike approach for the mmc_spi host... The absence of enthusiasm I equaled to no. Heh. p.s. Btw, you forgot another downside of v2 approach: struct spi_driver duplication... Not sure if everyone will be happy about it. Though, v2 is only version where we can make modular OF_MMC_SPI. -- 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] [RFC v3] OF: OpenFirmware bindings for the mmc_spi driver
On Thu, Jun 5, 2008 at 11:27 AM, Anton Vorontsov [EMAIL PROTECTED] wrote: On Thu, Jun 05, 2008 at 10:45:17AM -0600, Grant Likely wrote: On Thu, Jun 5, 2008 at 10:16 AM, Anton Vorontsov [EMAIL PROTECTED] wrote: Here is v3. I'm out of ideas if you won't like it. :-) v3: - Now these bindings are using bus notifiers chain, thus we adhere to the spi bus. By the way, this scheme (IMO) looks good for I2C devices which needs platform_data extracted from the device tree too (Cc'ing Jochen). - Plus changed the OF bindings themselves, implemented voltage-range property. (Pierre, please take a look at vddrange_to_ocrmask(). I wonder if you would like this in the MMC core instead, with a kernel doc, of course.) v2: - Bindings were adhered to the MMC_SPI driver. Withdrawn by Pierre Ossman. Personally I think your v2 was better, and if I'm interpreting Pierre's comments correctly I think his main point is that instead of using the 'stock' probe/remove hooks for the spi mmc driver, the driver should be mildly reworked to provide a common block of code that can be used by both the OF and non-OF versions of the probe/remove routines. I also think that is the way to go. Well, I mentioned the usb_add_hcd()-alike approach for the mmc_spi host... The absence of enthusiasm I equaled to no. Heh. I'm allergic to USB HCD code; I was probably having convulsions under my desk. p.s. Btw, you forgot another downside of v2 approach: struct spi_driver duplication... Not sure if everyone will be happy about it. Though, v2 is only version where we can make modular OF_MMC_SPI. I think we've got our wires crossed. I'm not referring to the option of an of_mmc_spi driver registering an mmc_spi device (which can then be probed by the mmc_spi_driver). I'm referring to refactoring the probe/remove code so that common stuff is callable by both the mmc_spi and of_mmc_spi drivers without the oddity of the of_mmc_spi probe hook calling the mmc_spi probe hook. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Scott Wood wrote: No, it's not. It can determine that it's at address 0x4f on the i2c bus at 0xe0003100. This is exactly how the ethernet phy lookup is done. But how does the fabric driver know whether e0003100 is I2C1 or I2C2? And how does the codec driver, which sees only I2C information, know that it's at e0003100? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC v3] OF: OpenFirmware bindings for the mmc_spi driver
On Thu, Jun 05, 2008 at 11:36:09AM -0600, Grant Likely wrote: On Thu, Jun 5, 2008 at 11:27 AM, Anton Vorontsov [EMAIL PROTECTED] wrote: On Thu, Jun 05, 2008 at 10:45:17AM -0600, Grant Likely wrote: On Thu, Jun 5, 2008 at 10:16 AM, Anton Vorontsov [EMAIL PROTECTED] wrote: Here is v3. I'm out of ideas if you won't like it. :-) v3: - Now these bindings are using bus notifiers chain, thus we adhere to the spi bus. By the way, this scheme (IMO) looks good for I2C devices which needs platform_data extracted from the device tree too (Cc'ing Jochen). - Plus changed the OF bindings themselves, implemented voltage-range property. (Pierre, please take a look at vddrange_to_ocrmask(). I wonder if you would like this in the MMC core instead, with a kernel doc, of course.) v2: - Bindings were adhered to the MMC_SPI driver. Withdrawn by Pierre Ossman. Personally I think your v2 was better, and if I'm interpreting Pierre's comments correctly I think his main point is that instead of using the 'stock' probe/remove hooks for the spi mmc driver, the driver should be mildly reworked to provide a common block of code that can be used by both the OF and non-OF versions of the probe/remove routines. I also think that is the way to go. Well, I mentioned the usb_add_hcd()-alike approach for the mmc_spi host... The absence of enthusiasm I equaled to no. Heh. I'm allergic to USB HCD code; I was probably having convulsions under my desk. :-) Ok, I also mentioned drivers/ata/pata_of_platform.c (OF version is using common code from drivers/ata/pata_platform.c). Please look there, and tell me if this is what you have in mind. (ignore _probe in the __pata_platform_probe name. Imagine pata_platform_add_controller or something). p.s. Btw, you forgot another downside of v2 approach: struct spi_driver duplication... Not sure if everyone will be happy about it. Though, v2 is only version where we can make modular OF_MMC_SPI. I think we've got our wires crossed. I'm not referring to the option of an of_mmc_spi driver registering an mmc_spi device (which can then be probed by the mmc_spi_driver). I'm not refrering to this option either. I'm referring to refactoring the probe/remove code so that common stuff is callable by both the mmc_spi and of_mmc_spi drivers without the oddity of the of_mmc_spi probe hook calling the mmc_spi probe hook. I understand this. -- 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: cell-index vs. index vs. no index in I2C device nodes
Timur Tabi wrote: Scott Wood wrote: No, it's not. It can determine that it's at address 0x4f on the i2c bus at 0xe0003100. This is exactly how the ethernet phy lookup is done. But how does the fabric driver know whether e0003100 is I2C1 or I2C2? It shouldn't have to care. And how does the codec driver, which sees only I2C information, know that it's at e0003100? This is an internal communications failure within the i2c layer, not something that warrants expression in the device tree. Some solutions, in increasing order of desirability, are: 1. Assign the I2C bus number based on the adapter's register offset. 2. Let the adapter provide a more helpful bus_id than a Linux-assigned index. 3. Create a way to look up an I2C device by its OF node. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC v3] OF: OpenFirmware bindings for the mmc_spi driver
On Thu, Jun 5, 2008 at 12:00 PM, Anton Vorontsov [EMAIL PROTECTED] wrote: On Thu, Jun 05, 2008 at 11:36:09AM -0600, Grant Likely wrote: On Thu, Jun 5, 2008 at 11:27 AM, Anton Vorontsov [EMAIL PROTECTED] wrote: Well, I mentioned the usb_add_hcd()-alike approach for the mmc_spi host... The absence of enthusiasm I equaled to no. Heh. I'm allergic to USB HCD code; I was probably having convulsions under my desk. :-) Ok, I also mentioned drivers/ata/pata_of_platform.c (OF version is using common code from drivers/ata/pata_platform.c). Please look there, and tell me if this is what you have in mind. (ignore _probe in the __pata_platform_probe name. Imagine pata_platform_add_controller or something). Yes, I like that. I've done something very similar for drivers with both of and non-of bindings. For another example, this time all contained within a single .c file, see drivers/video/xilinxfb.c p.s. Btw, you forgot another downside of v2 approach: struct spi_driver duplication... Not sure if everyone will be happy about it. Though, v2 is only version where we can make modular OF_MMC_SPI. I think we've got our wires crossed. I'm not referring to the option of an of_mmc_spi driver registering an mmc_spi device (which can then be probed by the mmc_spi_driver). I'm not refrering to this option either. Okay, I'm confused then. Where is the duplication of struct spi_driver? Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, 05 Jun 2008 11:25:23 -0500 Timur Tabi [EMAIL PROTECTED] wrote: Josh Boyer wrote: And it does. It does so by the unique regs properties and unit-names. You can assign the index that the i2c subsystem needs based on probe order, like I already said. The probe order is not sufficient on platforms that specifically enumerate their I2C (or whatever) devices. For instance, in order to do audio playback on an MPC8610, SSI1 needs to use DMA channel 0. The SSI driver specifically needs to find the register addresses for DMA channel 0. I don't understand this statement. Are your I2C macros hot-pluggable? Can you dynamically add/remove an I2C engine on your hardware somehow? Are you mucking about with the DTB and randomly moving around the I2C node blobs so they probe order differs from boot to boot? If not, then the probe order will be static for every boot. You can assign the index using a static int that is incremented after each node is discovered and the ordering of the devices will never change. Can you explain why something like that isn't possible or sufficient? (And I'm talking about I2C, not DMA. I don't care about DMA because this conversation will go off into the weeds if we start talking about cell-index and every possible device out there.) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC v3] OF: OpenFirmware bindings for the mmc_spi driver
On Thu, Jun 05, 2008 at 12:18:56PM -0600, Grant Likely wrote:
On Thu, Jun 5, 2008 at 12:00 PM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
On Thu, Jun 05, 2008 at 11:36:09AM -0600, Grant Likely wrote:
On Thu, Jun 5, 2008 at 11:27 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
Well, I mentioned the usb_add_hcd()-alike approach for the mmc_spi
host... The absence of enthusiasm I equaled to no.
Heh.
I'm allergic to USB HCD code; I was probably having convulsions under my
desk.
:-)
Ok, I also mentioned drivers/ata/pata_of_platform.c (OF version is using
common code from drivers/ata/pata_platform.c).
Please look there, and tell me if this is what you have in mind. (ignore
_probe in the __pata_platform_probe name. Imagine
pata_platform_add_controller or something).
Yes, I like that. I've done something very similar for drivers with
both of and non-of bindings. For another example, this time all
contained within a single .c file, see drivers/video/xilinxfb.c
Ok, great. As I said previously, this is quite easy to do.
p.s.
Btw, you forgot another downside of v2 approach: struct spi_driver
duplication... Not sure if everyone will be happy about it.
Though, v2 is only version where we can make modular OF_MMC_SPI.
I think we've got our wires crossed. I'm not referring to the option
of an of_mmc_spi driver registering an mmc_spi device (which can then
be probed by the mmc_spi_driver).
I'm not refrering to this option either.
Okay, I'm confused then. Where is the duplication of struct spi_driver?
Here it is http://lkml.org/lkml/2008/5/23/299
+ static struct spi_driver of_mmc_spi_driver = {
And here http://lkml.org/lkml/2008/5/24/153 David Brownell says:
The only thing that looks odd to me about this is that the wrapper
is a spi_device rather than an of_device. To me it makes more sense
to just have an of_device setting up the right spi_device. (Though
maybe I missed some discussion about why that can't work.)
^^^ That reminds me v1.
Here http://lkml.org/lkml/2008/5/25/5 you answered though, but there
was no bottom line.
I hope the bottom line is that we're now all happy to create another
spi_driver to handle OF MMC-o-SPI devices..?
--
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: cell-index vs. index vs. no index in I2C device nodes
Josh Boyer wrote: I don't understand this statement. Are your I2C macros hot-pluggable? Can you dynamically add/remove an I2C engine on your hardware somehow? Are you mucking about with the DTB and randomly moving around the I2C node blobs so they probe order differs from boot to boot? If not, then the probe order will be static for every boot. You're making two assumptions: 1) That every I2C adapter will be present in the device tree. Some device trees don't list I2C adapters if there are no devices on them. 2) That the nodes in the device tree are put in order Besides, let's say I have a pointer to a specific I2C device node in the tree. How do I find out the bus number it's on? With my way, it's easy: iprop = of_get_property(of_get_parent(codec_np), cell-index, NULL); bus = *iprop; With your way, I'll need to scan the entire device tree, poking inside each I2C adapter node looking for my I2C device node while keeping track of the I2C adapters. You can assign the index Assign it to where? When the fabric driver goes to find codec nodes, the only information it has is the device tree. So when I assign this index to some random variable that you're talking about, my fabric driver will know nothing about that. using a static int that is incremented after each node is discovered and the ordering of the devices will never change. Can you explain why something like that isn't possible or sufficient? Yes, I just did. (And I'm talking about I2C, not DMA. I don't care about DMA because this conversation will go off into the weeds if we start talking about cell-index and every possible device out there.) But we are talking about every device. It's the same problem for every device. Making this problem I2C-specific is not going to solve anything. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, 05 Jun 2008 13:35:18 -0500 Timur Tabi [EMAIL PROTECTED] wrote: Josh Boyer wrote: I don't understand this statement. Are your I2C macros hot-pluggable? Can you dynamically add/remove an I2C engine on your hardware somehow? Are you mucking about with the DTB and randomly moving around the I2C node blobs so they probe order differs from boot to boot? If not, then the probe order will be static for every boot. You're making two assumptions: 1) That every I2C adapter will be present in the device tree. Some device trees don't list I2C adapters if there are no devices on them. Which isn't a problem. 2) That the nodes in the device tree are put in order Which isn't a problem. Besides, let's say I have a pointer to a specific I2C device node in the tree. How do I find out the bus number it's on? With my way, it's easy: iprop = of_get_property(of_get_parent(codec_np), cell-index, NULL); bus = *iprop; With your way, I'll need to scan the entire device tree, poking inside each I2C adapter node looking for my I2C device node while keeping track of the I2C adapters. You can assign the index Assign it to where? When the fabric driver goes to find codec nodes, the only information it has is the device tree. So when I assign this index to some random variable that you're talking about, my fabric driver will know nothing about that. Your driver is sufficiently different then. The i2c-ibm_iic driver keeps an index property in it's private device structure. using a static int that is incremented after each node is discovered and the ordering of the devices will never change. Can you explain why something like that isn't possible or sufficient? Yes, I just did. Sort of. (And I'm talking about I2C, not DMA. I don't care about DMA because this conversation will go off into the weeds if we start talking about cell-index and every possible device out there.) But we are talking about every device. It's the same problem for every device. Making this problem I2C-specific is not going to solve anything. I've been driven to the point of not caring anymore. If you need a simple index property, then maybe Sean was right to just call the damn thing index. Overloading cell-index, which already has a specific semantic associated with it, seems odd to me. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC v3] OF: OpenFirmware bindings for the mmc_spi driver
On Thu, Jun 5, 2008 at 12:31 PM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
On Thu, Jun 05, 2008 at 12:18:56PM -0600, Grant Likely wrote:
On Thu, Jun 5, 2008 at 12:00 PM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
On Thu, Jun 05, 2008 at 11:36:09AM -0600, Grant Likely wrote:
On Thu, Jun 5, 2008 at 11:27 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
Well, I mentioned the usb_add_hcd()-alike approach for the mmc_spi
host... The absence of enthusiasm I equaled to no.
Heh.
I'm allergic to USB HCD code; I was probably having convulsions under my
desk.
:-)
Ok, I also mentioned drivers/ata/pata_of_platform.c (OF version is using
common code from drivers/ata/pata_platform.c).
Please look there, and tell me if this is what you have in mind. (ignore
_probe in the __pata_platform_probe name. Imagine
pata_platform_add_controller or something).
Yes, I like that. I've done something very similar for drivers with
both of and non-of bindings. For another example, this time all
contained within a single .c file, see drivers/video/xilinxfb.c
Ok, great. As I said previously, this is quite easy to do.
p.s.
Btw, you forgot another downside of v2 approach: struct spi_driver
duplication... Not sure if everyone will be happy about it.
Though, v2 is only version where we can make modular OF_MMC_SPI.
I think we've got our wires crossed. I'm not referring to the option
of an of_mmc_spi driver registering an mmc_spi device (which can then
be probed by the mmc_spi_driver).
I'm not refrering to this option either.
Okay, I'm confused then. Where is the duplication of struct spi_driver?
Here it is http://lkml.org/lkml/2008/5/23/299
+ static struct spi_driver of_mmc_spi_driver = {
Right; I was going down the wrong thought path. I have no problem with this.
BTW, while on that topic, I think it is reasonable to roll the members
of of_mmc_spi into either the mmc_spi_platform_data or the
mmc_spi_host structure. It is just 2 integers and that would
eliminate storing driver data pointers in seemingly random places.
And here http://lkml.org/lkml/2008/5/24/153 David Brownell says:
The only thing that looks odd to me about this is that the wrapper
is a spi_device rather than an of_device. To me it makes more sense
to just have an of_device setting up the right spi_device. (Though
maybe I missed some discussion about why that can't work.)
Yeah; I'm not fond of that approach. It incurs runtime cost of
multiple 'struct device' for a single device which is unnecessary.
I hope the bottom line is that we're now all happy to create another
spi_driver to handle OF MMC-o-SPI devices..?
Yes, I'm cool with it.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, Jun 5, 2008 at 12:27 PM, Josh Boyer [EMAIL PROTECTED] wrote: On Thu, 05 Jun 2008 11:25:23 -0500 Timur Tabi [EMAIL PROTECTED] wrote: Josh Boyer wrote: And it does. It does so by the unique regs properties and unit-names. You can assign the index that the i2c subsystem needs based on probe order, like I already said. The probe order is not sufficient on platforms that specifically enumerate their I2C (or whatever) devices. For instance, in order to do audio playback on an MPC8610, SSI1 needs to use DMA channel 0. The SSI driver specifically needs to find the register addresses for DMA channel 0. I don't understand this statement. Are your I2C macros hot-pluggable? Can you dynamically add/remove an I2C engine on your hardware somehow? Are you mucking about with the DTB and randomly moving around the I2C node blobs so they probe order differs from boot to boot? If not, then the probe order will be static for every boot. You can assign the index using a static int that is incremented after each node is discovered and the ordering of the devices will never change. Can you explain why something like that isn't possible or sufficient? (And I'm talking about I2C, not DMA. I don't care about DMA because this conversation will go off into the weeds if we start talking about cell-index and every possible device out there.) I need to disagree here. Behavior should never be dependent on device tree order. It should be absolutely fine for devices to be probed in a different order and different bus ids to be assigned. In Timur's case, it is absolutely appropriate to use cell-index and/or a phandle to make sure it gets the correct DMA registers (which is what cell-index is intended to solve). It is not appropriate to depend on that same number to also be the logical i2c bus number. Cheers, g. josh -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, 5 Jun 2008 12:46:39 -0600 Grant Likely [EMAIL PROTECTED] wrote: (And I'm talking about I2C, not DMA. I don't care about DMA because this conversation will go off into the weeds if we start talking about cell-index and every possible device out there.) I need to disagree here. Behavior should never be dependent on device tree order. It should be absolutely fine for devices to be probed in a different order and different bus ids to be assigned. Meh. I'll begrudgingly agree. In Timur's case, it is absolutely appropriate to use cell-index and/or a phandle to make sure it gets the correct DMA registers (which is what cell-index is intended to solve). It is not appropriate to depend on that same number to also be the logical i2c bus number. Hence index would be a better fit for the latter then, yes? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 2/4] [POWERPC] 85xx: add board support for the TQM8548 modules
===
--- /dev/null
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8548.dts
+ memory {
+ device_type = memory;
+ reg = 0x 0x2000;
+ };
is memory fixed on this board to 256M?
just let me know and I can fix when I commit it.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 4xx support in arch/ppc is going away Real Soon Now
On Jun 5, 2008, at 10:18 AM, Josh Boyer wrote: On Thu, 5 Jun 2008 09:11:48 -0600 Grant Likely [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 8:52 AM, Josh Boyer [EMAIL PROTECTED] wrote: This commit (patch omitted due to size) is sitting in my local tree: commit 0d7efc1e80fc262bcc507a605482c5681e3f082a Author: Josh Boyer [EMAIL PROTECTED] Date: Thu Jun 5 09:46:17 2008 -0500 ppc/4xx: Remove 4xx support from arch/ppc Remove support for PPC 403, 405, and 440 processors from arch/ ppc. The arch/powerpc equivalents should be used. Boards that are not ported yet will need to be ported to arch/powerpc to have continued support. This looks like unneeded churn. Excellent. My prompting has succeeded. Though now I won't get to be on top of the top contributors list in the lwn.net pages like Kumar was. Oh well. defconfig updates is the secret :) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, Jun 5, 2008 at 12:56 PM, Josh Boyer [EMAIL PROTECTED] wrote: On Thu, 5 Jun 2008 12:46:39 -0600 Grant Likely [EMAIL PROTECTED] wrote: In Timur's case, it is absolutely appropriate to use cell-index and/or a phandle to make sure it gets the correct DMA registers (which is what cell-index is intended to solve). It is not appropriate to depend on that same number to also be the logical i2c bus number. Hence index would be a better fit for the latter then, yes? No; use an alias in the aliases node. That is what aliases is designed for. Something like 'index' is a reinvention of the wheel. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 4xx support in arch/ppc is going away Real Soon Now
On Thu, 5 Jun 2008 13:59:44 -0500 Kumar Gala [EMAIL PROTECTED] wrote: On Jun 5, 2008, at 10:18 AM, Josh Boyer wrote: On Thu, 5 Jun 2008 09:11:48 -0600 Grant Likely [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 8:52 AM, Josh Boyer [EMAIL PROTECTED] wrote: This commit (patch omitted due to size) is sitting in my local tree: commit 0d7efc1e80fc262bcc507a605482c5681e3f082a Author: Josh Boyer [EMAIL PROTECTED] Date: Thu Jun 5 09:46:17 2008 -0500 ppc/4xx: Remove 4xx support from arch/ppc Remove support for PPC 403, 405, and 440 processors from arch/ ppc. The arch/powerpc equivalents should be used. Boards that are not ported yet will need to be ported to arch/powerpc to have continued support. This looks like unneeded churn. Excellent. My prompting has succeeded. Though now I won't get to be on top of the top contributors list in the lwn.net pages like Kumar was. Oh well. defconfig updates is the secret :) If only I had as many boards as you! ;) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, 5 Jun 2008 13:14:00 -0600 Grant Likely [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 12:56 PM, Josh Boyer [EMAIL PROTECTED] wrote: On Thu, 5 Jun 2008 12:46:39 -0600 Grant Likely [EMAIL PROTECTED] wrote: In Timur's case, it is absolutely appropriate to use cell-index and/or a phandle to make sure it gets the correct DMA registers (which is what cell-index is intended to solve). It is not appropriate to depend on that same number to also be the logical i2c bus number. Hence index would be a better fit for the latter then, yes? No; use an alias in the aliases node. That is what aliases is designed for. Something like 'index' is a reinvention of the wheel. Ah. Good point. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Grant Likely wrote: No; use an alias in the aliases node. That is what aliases is designed for. Something like 'index' is a reinvention of the wheel. Do aliases work in reverse? That is, if I have a pointer to a device node, can I look up its alias directly? Or do I have to scan the aliases node and do a comparison of each phandle, one at a time, until I find a match? And when I find a match, will I need to do sscanf() in order to extract the actual index value from the property? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/ppc is going away Real Soon Now
On Thursday 05 June 2008, Stephen Neuendorffer wrote: Grant Likely [EMAIL PROTECTED] wrote: Paulus, Can we just kill all of arch/ppc for .27 right now? Acked-by: Josh Boyer [EMAIL PROTECTED] Acked-by: Stephen Neuendorffer [EMAIL PROTECTED] Acked-by: Arnd Bergmann [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/ppc is going away Real Soon Now
On Thu, Jun 5, 2008 at 2:12 PM, Arnd Bergmann [EMAIL PROTECTED] wrote: On Thursday 05 June 2008, Stephen Neuendorffer wrote: Grant Likely [EMAIL PROTECTED] wrote: Paulus, Can we just kill all of arch/ppc for .27 right now? Acked-by: Josh Boyer [EMAIL PROTECTED] Acked-by: Stephen Neuendorffer [EMAIL PROTECTED] Acked-by: Arnd Bergmann [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/ppc is going away Real Soon Now
Olof Johansson wrote: On Jun 5, 2008, at 3:12 PM, Arnd Bergmann wrote: On Thursday 05 June 2008, Stephen Neuendorffer wrote: Grant Likely [EMAIL PROTECTED] wrote: Paulus, Can we just kill all of arch/ppc for .27 right now? Acked-by: Josh Boyer [EMAIL PROTECTED] Acked-by: Stephen Neuendorffer [EMAIL PROTECTED] Acked-by: Arnd Bergmann [EMAIL PROTECTED] Acked-by: Olof Johansson [EMAIL PROTECTED] Acked-by: Scott Wood [EMAIL PROTECTED] -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/ppc is going away Real Soon Now
On Jun 5, 2008, at 3:30 PM, Scott Wood wrote: Olof Johansson wrote: On Jun 5, 2008, at 3:12 PM, Arnd Bergmann wrote: On Thursday 05 June 2008, Stephen Neuendorffer wrote: Grant Likely [EMAIL PROTECTED] wrote: Paulus, Can we just kill all of arch/ppc for .27 right now? Acked-by: Josh Boyer [EMAIL PROTECTED] Acked-by: Stephen Neuendorffer [EMAIL PROTECTED] Acked-by: Arnd Bergmann [EMAIL PROTECTED] Acked-by: Olof Johansson [EMAIL PROTECTED] Acked-by: Scott Wood [EMAIL PROTECTED] Acked-by: Becky Bruce [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 2/4] [POWERPC] 85xx: add board support for the TQM8548 modules
Kumar Gala wrote:
===
--- /dev/null
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8548.dts
+memory {
+device_type = memory;
+reg = 0x 0x2000;
+};
is memory fixed on this board to 256M?
Ah, no, actually I have a module with 512 MB but it can be ordered with
less or more memory like the other TQM85xx modules as well. Does U-Boot
fixup this value? Is it used by Linux?
just let me know and I can fix when I commit it.
That would be great... thanks.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/ppc is going away Real Soon Now
[Fixed up the collision between Grant and Olof] Grant Likely [EMAIL PROTECTED] wrote: Paulus, Can we just kill all of arch/ppc for .27 right now? Acked-by: Josh Boyer [EMAIL PROTECTED] Acked-by: Stephen Neuendorffer [EMAIL PROTECTED] Acked-by: Arnd Bergmann [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] Acked-by: Olof Johansson [EMAIL PROTECTED] Acked-by: Segher Boessenkool [EMAIL PROTECTED] Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
No; use an alias in the aliases node. That is what aliases is designed for. Something like 'index' is a reinvention of the wheel. Do aliases work in reverse? That is, if I have a pointer to a device node, can I look up its alias directly? Or do I have to scan the aliases node and do a comparison of each phandle, one at a time, until I find a match? And when I find a match, will I need to do sscanf() in order to extract the actual index value from the property? Aliases are one-way. You can have multiple aliases point to the same node, as well (and that is quite common, even). If you need a unique identifier for an OF node, use its phandle. It sounds to me like you just need to set up a mapping between phandles and Linux i2c bus ids here? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Thu, 5 Jun 2008 08:22:00 +0200 Stefan Roese [EMAIL PROTECTED] wrote: So what should we do now? Currently I2C doesn't work at all on 4xx since the driver expects the index property and no dts sets this property. Personally I would like to move to using cell-index here, since this seems to be more common. But I could also life with removing the index property and using the static index if this is preferred and/or acceptable. The warp DTS does ;) Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
