* [PATCH 10/11] dtc: align header comments in asm output
From: Milton Miller @ 2007-07-07 6:18 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <dtc-5-00.miltonm@bga.com>
Insert tabs to align the comments describing the fields of the
boot parameters header struct.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
Previously some of the comments were seperated by one space and
others by one tab from the field.
Purely cosmetic, but then so are the comments.
Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c 2007-06-20 03:13:25.000000000 -0500
+++ dtc/flattree.c 2007-06-20 03:13:51.000000000 -0500
@@ -469,21 +469,21 @@ void dt_to_asm(FILE *f, struct boot_info
emit_label(f, symprefix, "blob_start");
emit_label(f, symprefix, "header");
- fprintf(f, "\t.long\tOF_DT_HEADER /* magic */\n");
- fprintf(f, "\t.long\t_%s_blob_abs_end - _%s_blob_start /* totalsize */\n",
+ fprintf(f, "\t.long\tOF_DT_HEADER\t\t\t\t/* magic */\n");
+ fprintf(f, "\t.long\t_%s_blob_abs_end - _%s_blob_start\t/* totalsize */\n",
symprefix, symprefix);
- fprintf(f, "\t.long\t_%s_struct_start - _%s_blob_start /* off_dt_struct */\n",
+ fprintf(f, "\t.long\t_%s_struct_start - _%s_blob_start\t/* off_dt_struct */\n",
symprefix, symprefix);
- fprintf(f, "\t.long\t_%s_strings_start - _%s_blob_start /* off_dt_strings */\n",
+ fprintf(f, "\t.long\t_%s_strings_start - _%s_blob_start\t/* off_dt_strings */\n",
symprefix, symprefix);
- fprintf(f, "\t.long\t_%s_reserve_map - _%s_blob_start /* off_dt_strings */\n",
+ fprintf(f, "\t.long\t_%s_reserve_map - _%s_blob_start\t/* off_dt_strings */\n",
symprefix, symprefix);
- fprintf(f, "\t.long\t%d /* version */\n", vi->version);
- fprintf(f, "\t.long\t%d /* last_comp_version */\n",
+ fprintf(f, "\t.long\t%d\t\t\t\t\t/* version */\n", vi->version);
+ fprintf(f, "\t.long\t%d\t\t\t\t\t/* last_comp_version */\n",
vi->last_comp_version);
if (vi->flags & FTF_BOOTCPUID)
- fprintf(f, "\t.long\t%i\t/*boot_cpuid_phys*/\n",
+ fprintf(f, "\t.long\t%i\t\t\t\t\t/* boot_cpuid_phys */\n",
boot_cpuid_phys);
if (vi->flags & FTF_STRTABSIZE)
^ permalink raw reply
* [PATCH 09/11] dtc: add a testcase with labels
From: Milton Miller @ 2007-07-07 6:18 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <dtc-5-00.miltonm@bga.com>
Create a source file with labels for use as a testcase
to check parsing dts files.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
I started with the existing test01.dts and added labels and
a labeled subnode.
The labels could instead be added to that file if desired,
but that would mean the output of the compiler would not
match the input when writing dts from dts or dtb input.
I haven't studied how to use the new testsuite to check
the result. Initially I was going to suggest diff on the
asm output, but with the libfdt library we could write a
test to change the property and reserve contents then
use the library to fetch and compare.
Index: dtc/tests/label01.dts
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/label01.dts 2007-06-14 22:17:39.000000000 -0500
@@ -0,0 +1,60 @@
+/memreserve/ 1000000000000000 0000000002000000;
+memrsv2: /memreserve/ 2000000000000000-20ffffffffffffff;
+/memreserve/ 0-13;
+
+/ {
+ model = "MyBoardName";
+ compatible = "MyBoardName", "MyBoardFamilyName";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ linux,phandle = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ PowerPC,970@0 {
+ name = "PowerPC,970";
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency = <5f5e1000>;
+ timebase-frequency = <1FCA055>;
+ linux,boot-cpu;
+ i-cache-size = <10000>;
+ d-cache-size = <8000>;
+ };
+
+ PowerPC,970@1 {
+ name = "PowerPC,970";
+ device_type = "cpu";
+ reg = <1>;
+ clock-frequency = <5f5e1000>;
+ timebase-frequency = <1FCA055>;
+ i-cache-size = <10000>;
+ d-cache-size = <8000>;
+ };
+
+ };
+
+ node: randomnode {
+ prop: string = data: "\xff\0stuffstuff\t\t\t\n\n\n" data_end: ;
+ blob = [byte: 0a 0b 0c 0d de ea ad be ef byte_end: ];
+ ref = < cell: &/memory@0 cell_end: >;
+ mixed = "abc", pre: [1234] post: , gap: < aligned: a b c>;
+ subnode: child {
+ };
+ /* subnode_end: is auto-generated by node emit */
+ };
+ /* node_end: is auto-generated by node emit */
+
+ memory@0 {
+ device_type = "memory";
+ memreg: reg = <00000000 00000000 00000000 20000000>;
+ };
+
+ chosen {
+ bootargs = "root=/dev/sda2";
+ linux,platform = <00000600>;
+ };
+
+};
+
^ permalink raw reply
* [PATCH 11/11] dtc: format memory reserve as pairs on two lines
From: Milton Miller @ 2007-07-07 6:18 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <dtc-5-00.miltonm@bga.com>
When writing the memory reserve table in assembly output,
emit both halves of each 64 bit number on a single .long
statement. This results in two lines per memory reserve
slot instead of four, each line contains one field (start
or size).
Signed-off-by: Milton Miller <miltonm@bga.com>
---
Purely consmentic but aids in showing the data is from
a single 64 bit quantity. The end marker and the extra
reserved slots were already emitting a pair of zeros per
statement.
Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c 2007-06-14 22:59:24.000000000 -0500
+++ dtc/flattree.c 2007-06-14 22:59:28.000000000 -0500
@@ -514,10 +514,10 @@ void dt_to_asm(FILE *f, struct boot_info
fprintf(f, "\t.globl\t%s\n", re->label);
fprintf(f, "%s:\n", re->label);
}
- fprintf(f, "\t.long\t0x%08x\n\t.long\t0x%08x\n",
+ fprintf(f, "\t.long\t0x%08x, 0x%08x\n",
(unsigned int)(re->re.address >> 32),
(unsigned int)(re->re.address & 0xffffffff));
- fprintf(f, "\t.long\t0x%08x\n\t.long\t0x%08x\n",
+ fprintf(f, "\t.long\t0x%08x, 0x%08x\n",
(unsigned int)(re->re.size >> 32),
(unsigned int)(re->re.size & 0xffffffff));
}
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Clifford Wolf @ 2007-07-07 8:41 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-embedded
In-Reply-To: <468F239B.5070800@freescale.com>
Hi,
On Sat, Jul 07, 2007 at 12:24:43AM -0500, Timur Tabi wrote:
> Clifford Wolf wrote:
>> Hi,
>> On Mon, Jun 25, 2007 at 08:01:10PM +0200, Clifford Wolf wrote:
>>> I've put a 'draft header file' of an api as I would have expected it
>>> online: [...]
>> Ok, so here comes the first implementation:
>> (I also have other projects, so it took a while.. ;-)
>> http://www.clifford.at/priv/dmatransfer-20070704.diff
>
> Why aren't you following the DMA API in include/linux/dmaengine.h?
because dmaengine statically assigns dma channels to drivers. it does trhat
becaus it is in fact not a generic api but only designed for speeding up
TCP using the Intel I/OAT engine. If more drivers would try to use it one
would need to decide at compile time which driver should be the one that
may use the dmaengine.
My dmatransfer api assigns the dma channels dynamically and there is no
limit how many drivers could use dmatransfer instead of ioremap and memcpy.
Also my framework has support for scatter/gather dma, fifo modes and all
that stuff (but the mpc8349dma driver doen't implement it yet).
'Extending' dmaengine in a way so it supports all this would result in
replacing every public api function of dmaengine and having a much more
complicated backend. The only current dmaengine user is the tcp/ip code
which is just a few (less than 10 if i remember correctly) lines of code.
Imo dmaengine should be replaced by an entirely different api instead of
hacking around its shortcommings. Thats why I propose the dmatransfer api.
yours,
- clifford
--
for(var d,i=<>just</>,j=function(){d~=i~(defined(i=next[*],i)?" ":"
");},just,another,SPL,hacker;defined i||({debug d;return 0;});j());
^ permalink raw reply
* [PATCH 1/2] [ide] mmio ide support
From: Vitaly Bordug @ 2007-07-07 9:48 UTC (permalink / raw)
To: linux-ide; +Cc: linuxppc-dev, linux-kernel
This adds support for MMIO IDE device like CompactFlash
in TrueIDE mode.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
drivers/ide/Kconfig | 6 +
drivers/ide/legacy/Makefile | 2
drivers/ide/legacy/mmio-ide.c | 211 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 219 insertions(+), 0 deletions(-)
diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig
index b1a9b81..0dab799 100644
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -946,6 +946,12 @@ config BLK_DEV_MPC8xx_IDE
If unsure, say N.
+config BLK_DEV_MMIOIDE
+ tristate "Memory Mapped IDE support"
+ help
+ This is the IDE driver for Memory Mapped IDE devices. Like
+ Compact Flash running in True IDE mode.
+
choice
prompt "Type of MPC8xx IDE interface"
depends on BLK_DEV_MPC8xx_IDE
diff --git a/drivers/ide/legacy/Makefile b/drivers/ide/legacy/Makefile
index c797106..61bd21e 100644
--- a/drivers/ide/legacy/Makefile
+++ b/drivers/ide/legacy/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_BLK_DEV_UMC8672) += umc8672.o
obj-$(CONFIG_BLK_DEV_IDECS) += ide-cs.o
+obj-$(CONFIG_BLK_DEV_MMIOIDE) += mmio-ide.o
+
# Last of all
obj-$(CONFIG_BLK_DEV_HD) += hd.o
diff --git a/drivers/ide/legacy/mmio-ide.c b/drivers/ide/legacy/mmio-ide.c
new file mode 100644
index 0000000..77fb7dd
--- /dev/null
+++ b/drivers/ide/legacy/mmio-ide.c
@@ -0,0 +1,211 @@
+/*
+ * Memory Mapped IDE driver
+ *
+ * Author: Kumar Gala <galak@kernel.crashing.org>
+ *
+ * 2007 (c) MontaVista Software, Inc.
+ * Vitaly Bordug <vitb@kernel.crashing.org>
+ * Anton Vorontsov <avorontsov@ru.mvista.com>
+ *
+ * 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/types.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/ide.h>
+#include <linux/ioport.h>
+#include <linux/module.h>
+#include <linux/mmio-ide.h>
+#include <asm/io.h>
+
+static struct {
+ void __iomem *mmio_ide_mapbase;
+ void __iomem *mmio_ide_alt_mapbase;
+ ide_hwif_t *hwif;
+ int index;
+} hwif_prop;
+
+static ide_hwif_t * __devinit mmio_ide_locate_hwif(void __iomem * base,
+ void __iomem * ctrl, struct mmio_ide_platform_data *pdata, int irq)
+{
+ unsigned long port = (unsigned long)base;
+ ide_hwif_t *hwif;
+ int index, i;
+
+ for (index = 0; index < MAX_HWIFS; ++index) {
+ hwif = ide_hwifs + index;
+ if (hwif->io_ports[IDE_DATA_OFFSET] == port)
+ goto found;
+ }
+
+ for (index = 0; index < MAX_HWIFS; ++index) {
+ hwif = ide_hwifs + index;
+ if (hwif->io_ports[IDE_DATA_OFFSET] == 0)
+ goto found;
+ }
+
+ return NULL;
+
+found:
+
+ hwif->hw.io_ports[IDE_DATA_OFFSET] = port;
+
+ port += pdata->regaddr_step + pdata->byte_lanes_swapping;
+ for (i = IDE_ERROR_OFFSET; i <= IDE_STATUS_OFFSET;
+ i++, port += pdata->regaddr_step)
+ hwif->hw.io_ports[i] = port;
+
+ hwif->hw.io_ports[IDE_CONTROL_OFFSET] = (unsigned long)ctrl +
+ 6 * pdata->regaddr_step + pdata->byte_lanes_swapping;
+
+ memcpy(hwif->io_ports, hwif->hw.io_ports, sizeof(hwif->hw.io_ports));
+ hwif->hw.irq = hwif->irq = irq;
+ hwif->selectproc = pdata->selectproc;
+
+ hwif->hw.dma = NO_DMA;
+ hwif->hw.chipset = ide_generic;
+
+ hwif->mmio = 2;
+ pdata->mmiops(hwif);
+ hwif_prop.hwif = hwif;
+ hwif_prop.index = index;
+
+ return hwif;
+}
+
+static int __devinit mmio_ide_probe(struct platform_device *pdev)
+{
+ struct resource *res_base, *res_alt, *res_irq;
+ ide_hwif_t *hwif;
+ struct mmio_ide_platform_data *pdata;
+ int ret = 0;
+
+ pdata = (struct mmio_ide_platform_data*)pdev->dev.platform_data;
+
+ /* get a pointer to the register memory */
+ res_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ res_alt = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+
+ if ((!res_base) || (!res_alt) || (!res_irq)) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ if (!request_mem_region(res_base->start, res_base->end -
+ res_base->start + 1, pdev->name)) {
+ dev_dbg(&pdev->dev, "%s: request_mem_region of base failed\n",
+ pdev->name);
+ ret = -EBUSY;
+ goto out;
+ }
+
+ if (!request_mem_region(res_alt->start, res_alt->end -
+ res_alt->start + 1, pdev->name)) {
+ dev_dbg(&pdev->dev, "%s: request_mem_region of alt failed\n",
+ pdev->name);
+ ret = -EBUSY;
+ goto release_base;
+ }
+
+ hwif_prop.mmio_ide_mapbase = ioremap(res_base->start, res_base->end -
+ res_base->start + 1);
+ if (!hwif_prop.mmio_ide_mapbase) {
+ ret = -ENOMEM;
+ goto release_alt;
+ }
+
+ hwif_prop.mmio_ide_alt_mapbase = ioremap(res_alt->start, res_alt->end -
+ res_alt->start + 1);
+ if (!hwif_prop.mmio_ide_alt_mapbase) {
+ ret = -ENOMEM;
+ goto unmap_base;
+ }
+
+ hwif = mmio_ide_locate_hwif(hwif_prop.mmio_ide_mapbase,
+ hwif_prop.mmio_ide_alt_mapbase, pdata, res_irq->start);
+
+ if (!hwif) {
+ ret = -ENODEV;
+ goto unmap_alt;
+ }
+ hwif->gendev.parent = &pdev->dev;
+ hwif->noprobe = 0;
+
+ probe_hwif_init(hwif);
+
+ platform_set_drvdata(pdev, hwif);
+ create_proc_ide_interfaces();
+
+ return 0;
+
+unmap_alt:
+ iounmap(hwif_prop.mmio_ide_alt_mapbase);
+unmap_base:
+ iounmap(hwif_prop.mmio_ide_mapbase);
+release_alt:
+ release_mem_region(res_alt->start, res_alt->end - res_alt->start + 1);
+release_base:
+ release_mem_region(res_base->start,
+ res_base->end - res_base->start + 1);
+out:
+ return ret;
+}
+
+static int __devexit mmio_ide_remove(struct platform_device *pdev)
+{
+ ide_hwif_t *hwif = pdev->dev.driver_data;
+ struct resource *res_base, *res_alt;
+
+ /* get a pointer to the register memory */
+ res_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ res_alt = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+
+ release_mem_region(res_base->start,
+ res_base->end - res_base->start + 1);
+ release_mem_region(res_alt->start, res_alt->end - res_alt->start + 1);
+
+ platform_set_drvdata(pdev, NULL);
+
+ if (hwif != hwif_prop.hwif)
+ dev_printk(KERN_DEBUG, &pdev->dev, "%s: hwif value error",
+ pdev->name);
+ else {
+ ide_unregister (hwif_prop.index);
+ hwif_prop.index = 0;
+ hwif_prop.hwif = NULL;
+ }
+
+ iounmap(hwif_prop.mmio_ide_mapbase);
+ iounmap(hwif_prop.mmio_ide_alt_mapbase);
+
+ return 0;
+}
+
+static struct platform_driver mmio_ide_driver = {
+ .driver {
+ .name = "mmio-ide",
+ },
+ .probe = mmio_ide_probe,
+ .remove = __devexit_p(mmio_ide_remove),
+};
+
+static int __init mmio_ide_init(void)
+{
+ return platform_driver_register(&mmio_ide_driver);
+}
+
+static void __exit mmio_ide_exit(void)
+{
+ platform_driver_unregister(&mmio_ide_driver);
+}
+
+MODULE_DESCRIPTION("Memory Mapped IDE driver");
+MODULE_LICENSE("GPL");
+
+module_init(mmio_ide_init);
+module_exit(mmio_ide_exit);
^ permalink raw reply related
* [PATCH 2/2] [POWERPC] mmio ide support for mpc8349-itx target
From: Vitaly Bordug @ 2007-07-07 9:49 UTC (permalink / raw)
To: linux-ide; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20070707094852.9473.21013.stgit@localhost.localdomain>
This updates relevant platform code
(freescale mpc8349itx target) to make the CompactFlash
work in TrueIDE mode.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
arch/powerpc/boot/dts/mpc8349emitx.dts | 17 +++++
arch/powerpc/sysdev/fsl_soc.c | 113 ++++++++++++++++++++++++++++++++
2 files changed, 129 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
index db0d003..b3e80ab 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -42,7 +42,7 @@
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "soc";
- ranges = <0 e0000000 00100000>;
+ ranges = <0 e0000000 1f000000>;
reg = <e0000000 00000200>;
bus-frequency = <0>; // from bootloader
@@ -229,6 +229,21 @@
descriptor-types-mask = <01010ebf>;
};
+ ide@10000000 {
+ #interrupt-cells = <2>;
+ interrupts = <17 8>;
+ interrupt-map = <0 0 0 1 700 17 8>;
+ interrupt-map-mask = <0>;
+
+ #size-cells = <1>;
+ #address-cells = <1>;
+ reg = <10000000 10 10000200 10>;
+
+ device_type = "ide";
+ compatible = "mmio-ide";
+ interrupt-parent = < &ipic >;
+ };
+
ipic: pic@700 {
interrupt-controller;
#address-cells = <0>;
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index cad1757..b3fe011 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -1103,3 +1103,116 @@ err:
arch_initcall(cpm_smc_uart_of_init);
#endif /* CONFIG_8xx */
+
+#ifdef CONFIG_MPC834x_ITX
+
+#include <linux/ide.h>
+#include <linux/mmio-ide.h>
+#include <asm-ppc/mpc83xx.h>
+
+static void mmio_ide_outsw(unsigned long port, void *addr, u32 count)
+{
+ _outsw_ns((void __iomem *)port, addr, count);
+}
+
+static void mmio_ide_insw(unsigned long port, void *addr, u32 count)
+{
+ _insw_ns((void __iomem *)port, addr, count);
+}
+
+void mmio_ide_mmiops (ide_hwif_t *hwif)
+{
+ default_hwif_mmiops(hwif);
+ hwif->OUTL = NULL;
+ hwif->OUTSW = mmio_ide_outsw;
+ hwif->OUTSL = NULL;
+ hwif->INL = NULL;
+ hwif->INSW = mmio_ide_insw;
+ hwif->INSL = NULL;
+}
+
+void mmio_ide_selectproc (ide_drive_t *drive)
+{
+ u8 stat;
+
+ stat = drive->hwif->INB(IDE_STATUS_REG);
+ if ((stat & READY_STAT) && (stat & BUSY_STAT))
+ drive->present = 0;
+ else
+ drive->present = 1;
+}
+
+static int __init fsl_mmio_ide_of_init(void)
+{
+ struct device_node *np;
+ unsigned int i;
+
+ for (np = NULL, i = 0;
+ (np = of_find_compatible_node(np, "ide", "mmio-ide")) != NULL;
+ i++) {
+ int ret = 0;
+ struct resource res[3];
+ struct platform_device *pdev = NULL;
+ static struct mmio_ide_platform_data pdata = {
+ /* TODO: pass via OF? */
+ .byte_lanes_swapping = 0,
+ .regaddr_step = 2,
+ .mmiops = mmio_ide_mmiops,
+ .selectproc = mmio_ide_selectproc,
+ };
+
+ memset(res, 0, sizeof(res));
+
+ ret = of_address_to_resource(np, 0, &res[0]);
+ if (ret) {
+ printk(KERN_ERR "mmio-ide.%d: unable to get "
+ "resource from OF\n",i );
+ goto err0;
+ }
+
+ ret = of_address_to_resource(np, 1, &res[1]);
+ if (ret) {
+ printk(KERN_ERR "mmio-ide.%d: unable to get "
+ "resource from OF\n", i);
+ goto err0;
+ }
+
+ res[2].start = res[2].end = irq_of_parse_and_map(np, 0);
+ if (res[2].start == NO_IRQ) {
+ printk(KERN_ERR "mmio-ide.%d: no IRQ\n", i);
+ goto err0;
+ }
+ res[2].name = "mmio-ide";
+ res[2].flags = IORESOURCE_IRQ;;
+
+ pdev = platform_device_alloc("mmio-ide", i);
+ if (!pdev)
+ goto err1;
+
+ ret = platform_device_add_data(pdev, &pdata, sizeof(pdata));
+ if (ret)
+ goto err1;
+
+ ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
+ if (ret)
+ goto err1;
+
+ ret = platform_device_register(pdev);
+ if (ret)
+ goto err1;
+
+ continue;
+err1:
+ printk(KERN_ERR "mmio-ide.%d: registration failed\n", i);
+ platform_device_del(pdev); /* it will free everything */
+err0:
+ /* Even if some device failed, try others */
+ continue;
+ }
+
+ return 0;
+}
+
+arch_initcall(fsl_mmio_ide_of_init);
+
+#endif /* CONFIG_MPC834x_ITX */
^ permalink raw reply related
* Re: [PATCH] Handle reg-shift property for of_serial ports
From: Arnd Bergmann @ 2007-07-07 12:10 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, paulus
In-Reply-To: <1183784308.3066.16.camel@shinybook.infradead.org>
On Saturday 07 July 2007, David Woodhouse wrote:
>
> The MV64660 has reg-shift==2 for its otherwise 16550-compatible uarts.
> While the bootwrapper copes with this, of_serial.c doesn't. (The udbg
> code doesn't either, but I'll fix that later).
>
> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Given the existence of the boards, it looks correct to do this.
However, I wonder if it was correct for the MV64660 to claim
compatibily witn ns16550 if the programming model is not exactly
the same. The official OF serial port bindings don't mention the
reg-shift property, so it maybe would have been better to have
a different value for the "compatible" property, in order not
to confuse existing operating systems that implement the standard.
Also, what about etherboot and yaboot? Do they handle this
correctly?
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/2] [ide] mmio ide support
From: Arnd Bergmann @ 2007-07-07 12:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel, linux-ide
In-Reply-To: <20070707094852.9473.21013.stgit@localhost.localdomain>
On Saturday 07 July 2007, Vitaly Bordug wrote:
>=20
> This adds support for MMIO IDE device like CompactFlash=20
> in TrueIDE mode.
> =A0
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>=20
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Hmm, are we still adding new IDE drivers? Do you also have a
driver for the new libata layer? I think it would even be
simpler to do.
You could also make it an of_platform_driver at the same time
instead of adding more cruft to fsl_soc.c. Since we're already
about to add the electra_ide.c driver in 2.6.23, I guess there
should really be _one_ driver that is able to handle all
of_device based ATA hosts.
Arnd <><
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Arnd Bergmann @ 2007-07-07 13:08 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Clifford Wolf
In-Reply-To: <20070704090554.GA30693@clifford.at>
On Wednesday 04 July 2007, Clifford Wolf wrote:
> Ok, so here comes the first implementation:
> (I also have other projects, so it took a while.. ;-)
>
> http://www.clifford.at/priv/dmatransfer-20070704.diff
>
> This is just for the MPC8349 DMA now, registers are still hardcoded in the
> driver instead of beeing taken from the platform files and support for
> scatter-gather is still missing and the Kconfig integration isn't checking
> if we are building for the mpc8349 (or even ppc) yet. But I think the
> direction of the API is pretty clear.
Is this a superset of what the dmaengine API can do? If not, I would
guess that things can get really confusing for the user.
Is it possible to wrap the existing dmaengine code inside of a
dmatransfer implementation?
You should probably have the authors of the dmaengine on Cc in
your next version of the driver, if you indend to replace their
code.
> +
> +/*** A dmatransfer is described using input and output chunks ***/
> +
> +// set one of this bits in fifo mode an none in linear mode
Please follow the common kernel commenting style, which allows
/* one-line comment */
/*
* multi-line
* comment
*/
/**
* identifier - description in kerneldoc format
* @name: struct member or function argument
* @name2: another one
*
* long description here
*/
> +struct dmatransfer
> +{
> + struct kref refcount;
> +
> + // callbacks (may be called in interrupt context)
> + dmatransfer_progress_callback_t progress_callback;
> + dmatransfer_finish_callback_t finish_callback;
> + dmatransfer_release_callback_t release_callback;
> +
> + // private data from the requestor
> + union {
> + void *data_voidp;
> + __u32 data_u32;
> + __u64 data_u64;
> + } data;
This could simply be an unsigned long, I guess. We tend to
use unsigned long for generic data, unless it always is a pointer.
> + __u32 flags;
> +
> + // how many input and output junks
> + int n_input_chunks;
> + int n_output_chunks;
unsigned?
> + // these are used internally in dmatransfer_request_*
> + enum {
> + DMATRANSFER_ASYNC,
> + DMATRANSFER_WAITING,
> + DMATRANSFER_FINISHED
> + } status;
> + wait_queue_head_t wq;
> +
> + // these are used internally in the backends
> + struct dmatransfer_backend *backend;
> + struct list_head backend_spool;
> + void *backend_data_voidp;
> +
> + // this array first contains all input and output chunk descriptions (in
> this order) + struct dmatransfer_chunk chunks[];
> +};
> +
> +// This functions may return -EINVAL when the requested transfer can't be
> +// done in hardware and DMATRANSFER_DMAONLY is set and -EAGAIN if there
> are +// no free DMA channels and DMATRANSFER_NOSPOOL is set for the
> transfer. +extern int dmatransfer_request_async(struct dmatransfer
> *transfer);
Put the description in front of the function definition in kerneldoc format
> +extern int dmatransfer_request_wait(struct dmatransfer *transfer);
> +extern struct dmatransfer *dmatransfer_malloc(int chunks_n, int flags);
maybe better dmatransfer_alloc instead of dmatransfer_malloc?
To me, malloc sort of implies that it only does a pure allocation,
not also the initialization.
> +extern void dmatransfer_release(struct kref *kref);
There is a recent tendency to always leave out the 'extern' keyword
for function declarations.
> +/*** Backend drivers register themself using this struct ***/
> +
> +enum dmatransfer_quality {
> + DMATRANSFER_QUALITY_NO = 0,
> + DMATRANSFER_QUALITY_SOFT = 1,
> + DMATRANSFER_QUALITY_SPOOL = 2,
> + DMATRANSFER_QUALITY_GOOD = 3,
> + DMATRANSFER_QUALITY_BEST = 4,
> +};
> +
> +struct dmatransfer_backend
> +{
> + enum dmatransfer_quality (*check)(struct dmatransfer *transfer);
> + void (*perform)(struct dmatransfer *transfer);
> +
> + // performing transfers is 'reading' and unregistering is 'writing'
> + struct rw_semaphore unreg_sem;
> +
> + // internally used by the dmatransfer core
> + struct list_head backend_list;
> +};
> +
> +extern void dmatransfer_finish(struct dmatransfer *transfer);
> +
> +extern void dmatransfer_register_backend(struct dmatransfer_backend
> *backend); +
> +// This function may sleep until all pending dma transfers for this
> backend +// have been finished.
> +extern void dmatransfer_unregister_backend(struct dmatransfer_backend
> *backend); +
> +#endif /* DMATRANSFER_H */
> +
> +#include <linux/dmatransfer.h>
> +#include <linux/module.h>
> +#include <linux/sched.h>
> +
> +static rwlock_t backend_list_lock = RW_LOCK_UNLOCKED;
> +static LIST_HEAD(backend_list);
> +
> +static int dmatransfer_request_worker(struct dmatransfer *transfer)
> +{
> + enum dmatransfer_quality best_quality = DMATRANSFER_QUALITY_NO;
> + struct dmatransfer_backend *best_backend = 0;
> + int error_ret = -EINVAL;
> + struct list_head *p;
> +
> + // WARNING:
> + // There is a non-critical race in this codepath: backend->check() may
> return + // that the DMA request can be performed without spooling for two
> concurrently + // running dmatransfer_request_worker() instances. If the
> backend has only one + // free channel this will result in one request
> beeing executed without spooling + // and the other one beeing spooled. So
> DMATRANSFER_NOSPOOL does not guarantee + // that the request isn't spooled
> - just that we _try_ to avoid spooling. +
You appear to have a lot of overly long lines. Try to limit your code to less
than 80 characters per line.
> +struct dmatransfer *dmatransfer_malloc(int chunks_n, int flags)
> +{
> + size_t transfer_size = sizeof(struct dmatransfer) + 2*sizeof(struct
> dmatransfer_chunk); + struct dmatransfer *transfer = kmalloc(transfer_size,
> flags);
> + memset(transfer, 0, transfer_size);
Use kzalloc instead kmalloc+memset.
> +void dmatransfer_register_backend(struct dmatransfer_backend *backend)
> +{
> + unsigned long irqflags;
> +
> + init_rwsem(&backend->unreg_sem);
> +
> + write_lock_irqsave(&backend_list_lock, irqflags);
> + INIT_LIST_HEAD(&backend->backend_list);
> + list_add(&backend->backend_list, &backend_list);
> + write_unlock_irqrestore(&backend_list_lock, irqflags);
> +}
> +
> +void dmatransfer_unregister_backend(struct dmatransfer_backend *backend)
> +{
> + unsigned long irqflags;
> + write_lock_irqsave(&backend_list_lock, irqflags);
> + list_del(&backend->backend_list);
> + write_unlock_irqrestore(&backend_list_lock, irqflags);
> +
> + // make sure all pending requests have finished before returning
> + down_write(&backend->unreg_sem);
> + up_write(&backend->unreg_sem);
> +}
This usage of rw semaphores looks fishy.
> +EXPORT_SYMBOL(dmatransfer_request_async);
> +EXPORT_SYMBOL(dmatransfer_request_wait);
> +
> +EXPORT_SYMBOL(dmatransfer_malloc);
> +EXPORT_SYMBOL(dmatransfer_release);
> +
> +EXPORT_SYMBOL(dmatransfer_finish);
> +
> +EXPORT_SYMBOL(dmatransfer_register_backend);
> +EXPORT_SYMBOL(dmatransfer_unregister_backend);
Please put the EXPORT_SYMBOL lines directly below the respective symbol definitions.
Also, make them EXPORT_SYMBOL_GPL() or explain why you don't. For new subsystems,
we normally don't use non-GPL exports any more.
> +#define CHANNEL_N 4
> +
> +static LIST_HEAD(spool);
> +static struct dmatransfer *spool_current_transfers[CHANNEL_N];
> +static spinlock_t spool_lock = SPIN_LOCK_UNLOCKED;
use DEFINE_SPINLOCK instead of assigning to SPIN_LOCK_UNLOCKED.
> +#define BIT(_name, _n) (1<<(_n))
I personally don't like such macros. Why don't you just define named
constants for the bits in there right position?
s/BIT(TE, 7)/DMASR_TE/
> + iowrite32(transfer->chunks[0].bus_address,
> reg_map[i]+REG_OFFSET_DMASAR);
> + iowrite32(transfer->chunks[1].bus_address,
> reg_map[i]+REG_OFFSET_DMADAR); + iowrite32(transfer->chunks[1].bytecount,
> reg_map[i]+REG_OFFSET_DMABCR); +
> + iowrite32(BIT(TE, 7) | BIT(EOSI, 1) | BIT(EOCDI, 0),
> reg_map[i]+REG_OFFSET_DMASR); +
> + dmamr = 0;
> + dmamr |= BIT(EOTIE, 7);
> + dmamr |= BIT(CTM, 2);
> + iowrite32(dmamr, reg_map[i]+REG_OFFSET_DMAMR);
> +
> + dmamr |= BIT(CS, 0);
> + iowrite32(dmamr, reg_map[i]+REG_OFFSET_DMAMR);
> + }
> +}
iowrite32 is currently only well-defined for PCI devices, which I believe
this devide is not. Use out_be32 or out_le32 instead.
> + if ((dmasr & (BIT(TE, 7) | BIT(EOCDI, 0))) != 0) {
> + if ((dmasr & BIT(TE, 7)) != 0) {
> + printk(KERN_ERR "MPC8349 DMA Transfer Error on DMA channel #%d.\n",
> i); + BUG();
> + }
BUG() may be a little harsh here, especially since you are holding spinlocks.
It would be better to try to recover here, unless you expect actual data
corruption, in which case a full panic() might be more appropriate.
Arnd <><
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Clifford Wolf @ 2007-07-07 13:27 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-embedded
In-Reply-To: <200707071508.04143.arnd@arndb.de>
Hi,
Thanks for your feedback. I will incorporate to my code and release a new
version of Tuesday when I'm back in the office..
On Sat, Jul 07, 2007 at 03:08:03PM +0200, Arnd Bergmann wrote:
> > +void dmatransfer_unregister_backend(struct dmatransfer_backend *backend)
> > +{
> > + unsigned long irqflags;
> > + write_lock_irqsave(&backend_list_lock, irqflags);
> > + list_del(&backend->backend_list);
> > + write_unlock_irqrestore(&backend_list_lock, irqflags);
> > +
> > + // make sure all pending requests have finished before returning
> > + down_write(&backend->unreg_sem);
> > + up_write(&backend->unreg_sem);
> > +}
>
> This usage of rw semaphores looks fishy.
yep. do you have a better idea how to implement this easily?
> > + if ((dmasr & (BIT(TE, 7) | BIT(EOCDI, 0))) != 0) {
> > + if ((dmasr & BIT(TE, 7)) != 0) {
> > + printk(KERN_ERR "MPC8349 DMA Transfer Error on DMA channel #%d.\n",
> > i); + BUG();
> > + }
>
> BUG() may be a little harsh here, especially since you are holding spinlocks.
> It would be better to try to recover here, unless you expect actual data
> corruption, in which case a full panic() might be more appropriate.
in this way dmatransfer() is designed to be used like memcpy(): you don't
try and check for errors afterwards, you only start a dmatransfer if you
know it is ok and can't fail.
This codepath triggeres if 'the impossible' happens: a dma transfer
actually fails. Since there is no datapath to communicate this error back
to the caller it is almost sure that we have lost data. I will change that
to use panic() instead.
yours,
- clifford
--
Some languages are designed to solve a problem. Others are designed to
prove a point.
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Clifford Wolf @ 2007-07-07 13:34 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-embedded
In-Reply-To: <200707071508.04143.arnd@arndb.de>
Hi again,
On Sat, Jul 07, 2007 at 03:08:03PM +0200, Arnd Bergmann wrote:
> Is this a superset of what the dmaengine API can do? If not, I would
> guess that things can get really confusing for the user.
dmatransfer should replace the dmaengine API. dmaengine has only one client
(the tcp/ip network stack - just a few lines of code) and provides only one
driver (ioatdma).
I would have added a ioatdma driver to dmatransfer but unfortunately I
don't have the hardware..
> Is it possible to wrap the existing dmaengine code inside of a
> dmatransfer implementation?
sure - but that wouldn't make much sense. dmaengine gives away exclusive
use rights to dma channels. so if dmatransfer is using dmaengine, noone
else could use it.
> You should probably have the authors of the dmaengine on Cc in
> your next version of the driver, if you indend to replace their
> code.
I'll write them a personal mail to get things rolling as soon as the next
dmatransfer release with the cleanups you suggested and scatter/gather as
well as fifo support is out.
yours,
- clifford
--
ocaml graphics.cma <( echo 'open Graphics;;open_graph " 640x480"let
complex_mul(a,b)(c,d)=(a*.c-.b*.d,a*.d+.b*.c)let complex_add(a,b)(c
,d)=(a+.c,b+.d);;let rec mandel c n=if n>0 then let z=mandel c(n-1)
in complex_add(complex_mul z z)c else (0.0,0.0);; for x=0 to 640 do
for y=0 to 480 do let c=((float_of_int(x-450))/.200.0,(float_of_int
(y-240))/.200.0) in let cabs2(a,b)=(a*.a)+.(b*.b)in if cabs2(mandel
c 50)<4.0 then plot x y done done;;read_line()' )
^ permalink raw reply
* Re: Mem-2-Mem DMA - Generalized API
From: Arnd Bergmann @ 2007-07-07 13:28 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Clifford Wolf
In-Reply-To: <20070707132748.GB32740@clifford.at>
On Saturday 07 July 2007, Clifford Wolf wrote:
> > > +=A0=A0=A0// make sure all pending requests have finished before retu=
rning
> > > +=A0=A0=A0down_write(&backend->unreg_sem);
> > > +=A0=A0=A0up_write(&backend->unreg_sem);
> > > +}
> >=20
> > This usage of rw semaphores looks fishy.=20
>=20
> yep. do you have a better idea how to implement this easily?
>=20
I'd guess what you really want is reference counting. Every request
that gets assigned to a backend should get a kref on that backend
and give that up once it gets released itself.
I guess you can then have one more reference that you get in
dmatransfer_register_backend and release in dmatransfer_unregister_backend.
When you release the last reference, you call complete(),
and dmatransfer_unregister_backend() ends with a wait_for_completion().
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/2] [ide] mmio ide support
From: Olof Johansson @ 2007-07-07 15:01 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20070707094852.9473.21013.stgit@localhost.localdomain>
On Sat, Jul 07, 2007 at 01:48:52PM +0400, Vitaly Bordug wrote:
>
> This adds support for MMIO IDE device like CompactFlash
> in TrueIDE mode.
Doesn't this duplicate most of pata_platform, but as the
no-longer-preferred legacy IDE device? Did you try using
pata_platform instead?
-Olof
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] mmio ide support for mpc8349-itx target
From: Olof Johansson @ 2007-07-07 15:07 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20070707094900.9473.48577.stgit@localhost.localdomain>
On Sat, Jul 07, 2007 at 01:49:00PM +0400, Vitaly Bordug wrote:
>
> This updates relevant platform code
> (freescale mpc8349itx target) to make the CompactFlash
> work in TrueIDE mode.
Shouldn't you be writing a PCMCIA driver instead for the CF, so it
handles other devices as well? Then you get storage "for free", as
well as hotplug, etc.
It's not hard:
http://patchwork.ozlabs.org/linuxppc/patch?person=124&id=12044
-Olof
^ permalink raw reply
* Re: [PATCH] Handle reg-shift property for of_serial ports
From: David Woodhouse @ 2007-07-07 14:59 UTC (permalink / raw)
To: Arnd Bergmann, wmb; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707071410.14998.arnd@arndb.de>
On Sat, 2007-07-07 at 14:10 +0200, Arnd Bergmann wrote:
> On Saturday 07 July 2007, David Woodhouse wrote:
> >
> > The MV64660 has reg-shift==2 for its otherwise 16550-compatible uarts.
> > While the bootwrapper copes with this, of_serial.c doesn't. (The udbg
> > code doesn't either, but I'll fix that later).
> >
> > Signed-off-by: David Woodhouse <dwmw2@infradead.org>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> Given the existence of the boards, it looks correct to do this.
> However, I wonder if it was correct for the MV64660 to claim
> compatibily witn ns16550 if the programming model is not exactly
> the same. The official OF serial port bindings don't mention the
> reg-shift property, so it maybe would have been better to have
> a different value for the "compatible" property, in order not
> to confuse existing operating systems that implement the standard.
Well, so far this only exists in the hacked-up device tree for my
bootwrapper; not in any real firmware. If a reg-shift property is the
wrong way to do it, we can change it. I got the reg-shift thing from
Mark's code in arch/powerpc/boot/ns16550.c, which handles it that way
for the bootwrapper (although I don't see any device-tree blobs which
use it, apart from mine).
--
dwmw2
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] mmio ide support for mpc8349-itx target
From: Arnd Bergmann @ 2007-07-07 15:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, linux-kernel, linux-ide
In-Reply-To: <20070707150708.GA5387@lixom.net>
On Saturday 07 July 2007, Olof Johansson wrote:
> On Sat, Jul 07, 2007 at 01:49:00PM +0400, Vitaly Bordug wrote:
> >
> > This updates relevant platform code
> > (freescale mpc8349itx target) to make the CompactFlash
> > work in TrueIDE mode.
>
> Shouldn't you be writing a PCMCIA driver instead for the CF, so it
> handles other devices as well? Then you get storage "for free", as
> well as hotplug, etc.
CF memory cards can be in either TrueIDE mode or PCMCIA mode. If you
only need to support memory cards, you should always use True-IDE
mode, because that offers a _much_ higher throughput with PIO mode
6 (25 MB/s) or UDMA mode 6 (133MB/s), compared to the PIO mode 0
(3.3 MB/s) in PCMCIA mode.
Of course, if the bus can only sustain PIO mode 0 anyway, you can
just as well do a PCMCIA driver, and get the ability to plug in
other cards, e.g. wlan or modem cards.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] mmio ide support for mpc8349-itx target
From: Sergei Shtylyov @ 2007-07-07 16:46 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20070707094900.9473.48577.stgit@localhost.localdomain>
Hello.
Vitaly Bordug wrote:
> This updates relevant platform code
> (freescale mpc8349itx target) to make the CompactFlash
> work in TrueIDE mode.
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
It would have been good if you tried to actualy compile your code. ;-)
> diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
> index db0d003..b3e80ab 100644
> --- a/arch/powerpc/boot/dts/mpc8349emitx.dts
> +++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
> @@ -42,7 +42,7 @@
> #size-cells = <1>;
> #interrupt-cells = <2>;
> device_type = "soc";
> - ranges = <0 e0000000 00100000>;
> + ranges = <0 e0000000 1f000000>;
> reg = <e0000000 00000200>;
> bus-frequency = <0>; // from bootloader
>
> @@ -229,6 +229,21 @@
> descriptor-types-mask = <01010ebf>;
> };
>
> + ide@10000000 {
> + #interrupt-cells = <2>;
Hm, why define that prop for a node with no children?
> + interrupts = <17 8>;
> + interrupt-map = <0 0 0 1 700 17 8>;
> + interrupt-map-mask = <0>;
> +
> + #size-cells = <1>;
> + #address-cells = <1>;
Same question here.
> + reg = <10000000 10 10000200 10>;
> +
> + device_type = "ide";
I think that already adopted device type is "ata", not "ide".
> + compatible = "mmio-ide";
> + interrupt-parent = < &ipic >;
> + };
> +
> ipic: pic@700 {
> interrupt-controller;
> #address-cells = <0>;
> diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
> index cad1757..b3fe011 100644
> --- a/arch/powerpc/sysdev/fsl_soc.c
> +++ b/arch/powerpc/sysdev/fsl_soc.c
> @@ -1103,3 +1103,116 @@ err:
> arch_initcall(cpm_smc_uart_of_init);
>
> #endif /* CONFIG_8xx */
> +
> +#ifdef CONFIG_MPC834x_ITX
Erm, isn't this stuff misplaced? Is this really SoC device? I remember
seeng this in the arch/ppc/ platform code before (in the internal tree)...
> +#include <linux/ide.h>
> +#include <linux/mmio-ide.h>
> +#include <asm-ppc/mpc83xx.h>
> +
> +static void mmio_ide_outsw(unsigned long port, void *addr, u32 count)
> +{
> + _outsw_ns((void __iomem *)port, addr, count);
> +}
> +
> +static void mmio_ide_insw(unsigned long port, void *addr, u32 count)
> +{
> + _insw_ns((void __iomem *)port, addr, count);
> +}
> +
> +void mmio_ide_mmiops (ide_hwif_t *hwif)
> +{
> + default_hwif_mmiops(hwif);
> + hwif->OUTL = NULL;
OUTL() method no longer exists.
> + hwif->OUTSW = mmio_ide_outsw;
> + hwif->OUTSL = NULL;
> + hwif->INL = NULL;
And neither INL() does.
> + hwif->INSW = mmio_ide_insw;
> + hwif->INSL = NULL;
> +}
> +
> +void mmio_ide_selectproc (ide_drive_t *drive)
> +{
> + u8 stat;
> +
> + stat = drive->hwif->INB(IDE_STATUS_REG);
> + if ((stat & READY_STAT) && (stat & BUSY_STAT))
> + drive->present = 0;
> + else
> + drive->present = 1;
> +}
> +
Heh, attempt to emulate hotplug. :-)
> +static int __init fsl_mmio_ide_of_init(void)
> +{
> + struct device_node *np;
> + unsigned int i;
> +
> + for (np = NULL, i = 0;
> + (np = of_find_compatible_node(np, "ide", "mmio-ide")) != NULL;
> + i++) {
> + int ret = 0;
> + struct resource res[3];
> + struct platform_device *pdev = NULL;
> + static struct mmio_ide_platform_data pdata = {
> + /* TODO: pass via OF? */
> + .byte_lanes_swapping = 0,
> + .regaddr_step = 2,
> + .mmiops = mmio_ide_mmiops,
> + .selectproc = mmio_ide_selectproc,
Definitely, you won't be able to pass methods via of_platform_device. :-)
> + };
> +
> + memset(res, 0, sizeof(res));
> +
> + ret = of_address_to_resource(np, 0, &res[0]);
> + if (ret) {
> + printk(KERN_ERR "mmio-ide.%d: unable to get "
> + "resource from OF\n",i );
CodingStyle: space after comma, no space before paren.
[...]
> + res[2].name = "mmio-ide";
> + res[2].flags = IORESOURCE_IRQ;;
One ; too many here. ;-)
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/2] [ide] mmio ide support
From: Sergei Shtylyov @ 2007-07-07 16:51 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linux-kernel, linux-ide
In-Reply-To: <200707071419.52650.arnd@arndb.de>
Arnd Bergmann wrote:
>>This adds support for MMIO IDE device like CompactFlash
>>in TrueIDE mode.
>>Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> Hmm, are we still adding new IDE drivers? Do you also have a
Yes, why not?
> driver for the new libata layer?
No (sorry for replying for Vitaly but I know the situation).
> I think it would even be simpler to do.
Wel have no interest in it right now.
> You could also make it an of_platform_driver at the same time
> instead of adding more cruft to fsl_soc.c. Since we're already
That's a fair point (and fsl_soc.c doesn't seem proper place anyway).
> about to add the electra_ide.c driver in 2.6.23, I guess there
> should really be _one_ driver that is able to handle all
> of_device based ATA hosts.
One driver to rule them all. :-)
That may be not so simple as it seems...
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] Handle reg-shift property for of_serial ports
From: David Woodhouse @ 2007-07-07 16:51 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707071410.14998.arnd@arndb.de>
On Sat, 2007-07-07 at 14:10 +0200, Arnd Bergmann wrote:
> Given the existence of the boards, it looks correct to do this.
> However, I wonder if it was correct for the MV64660 to claim
> compatibily witn ns16550 if the programming model is not exactly
> the same. The official OF serial port bindings don't mention the
> reg-shift property, so it maybe would have been better to have
> a different value for the "compatible" property, in order not
> to confuse existing operating systems that implement the standard.
Ok, how about 'sparse16550'? Otherwise identical to ns16550, but with
the reg-shift property. I'll send a patch shortly, and I'll reorder the
match table -- if something claims compatibility with both 8250 and
16550, shouldn't we drive it as the latter?
Can we add properties to indicate the common high-speed modes too? The
Natsemi baud-base thing could be autodetected by 8250.c if you'd let it,
but the SMSC trick just has to be set as a UPF_MAGIC_MULTIPLIER flag.
--
dwmw2
^ permalink raw reply
* [PATCH 1/2] Add 'sparse16550' to of_serial.c and handle 'reg-shift' property.
From: David Woodhouse @ 2007-07-07 16:57 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707071410.14998.arnd@arndb.de>
Some boards have UARTs which are mostly compatible with a 16550, but
with registers spaced more widely. This isn't strictly compatible with
ns16550, so introduce a new 'compatible' type for it: sparse16550. The
'reg-shift' property indicates how far the registers are separated.
Also, reorder the match table to favour better modes if a device claims
compatibility with both 8250 and 16550, for example.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 7ffdaea..6ae1b5e 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -25,12 +25,13 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
{
struct resource resource;
struct device_node *np = ofdev->node;
- const unsigned int *clk, *spd;
+ const unsigned int *clk, *spd, *rs;
int ret;
memset(port, 0, sizeof *port);
spd = of_get_property(np, "current-speed", NULL);
clk = of_get_property(np, "clock-frequency", NULL);
+ rs = of_get_property(np, "reg-shift", NULL);
if (!clk) {
dev_warn(&ofdev->dev, "no clock-frequency property set\n");
return -ENODEV;
@@ -48,6 +49,8 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
port->iotype = UPIO_MEM;
port->type = type;
port->uartclk = *clk;
+ if (rs)
+ port->regshift = *rs;
port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
| UPF_FIXED_PORT;
port->dev = &ofdev->dev;
@@ -111,11 +114,12 @@ static int of_platform_serial_remove(struct of_device *ofdev)
* A few common types, add more as needed.
*/
static struct of_device_id __devinitdata of_platform_serial_table[] = {
- { .type = "serial", .compatible = "ns8250", .data = (void *)PORT_8250, },
- { .type = "serial", .compatible = "ns16450", .data = (void *)PORT_16450, },
- { .type = "serial", .compatible = "ns16550", .data = (void *)PORT_16550, },
- { .type = "serial", .compatible = "ns16750", .data = (void *)PORT_16750, },
- { .type = "serial", .data = (void *)PORT_UNKNOWN, },
+ { .type = "serial", .compatible = "sparse16550", .data = (void *)PORT_16550, },
+ { .type = "serial", .compatible = "ns16750", .data = (void *)PORT_16750, },
+ { .type = "serial", .compatible = "ns16550", .data = (void *)PORT_16550, },
+ { .type = "serial", .compatible = "ns16450", .data = (void *)PORT_16450, },
+ { .type = "serial", .compatible = "ns8250", .data = (void *)PORT_8250, },
+ { .type = "serial", .data = (void *)PORT_UNKNOWN, },
{ /* end of list */ },
};
--
dwmw2
^ permalink raw reply related
* [PATCH 2/2] Add 'sparse16550' support to PowerPC bootwrapper
From: David Woodhouse @ 2007-07-07 16:57 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707071410.14998.arnd@arndb.de>
The bootwrapper already handles a 'reg-shift' property on serial ports
and does the right thing. However, these ports really shouldn't be
claiming to be compatible with 'ns16550'. Introduce a new 'sparse16550'
type for them instead.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index 7fd3233..6d9f3f8 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -123,7 +123,7 @@ int serial_console_init(void)
if (getprop(devp, "compatible", compat, sizeof(compat)) < 0)
goto err_out;
- if (!strcmp(compat, "ns16550"))
+ if (!strcmp(compat, "ns16550") || !strcmp(compat, "sparse16550"))
rc = ns16550_console_init(devp, &serial_cd);
else if (!strcmp(compat, "marvell,mpsc"))
rc = mpsc_console_init(devp, &serial_cd);
--
dwmw2
^ permalink raw reply related
* Re: [PATCH] Handle reg-shift property for of_serial ports
From: Sergei Shtylyov @ 2007-07-07 17:07 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <1183827083.3066.64.camel@shinybook.infradead.org>
Hello.
David Woodhouse wrote:
>>Given the existence of the boards, it looks correct to do this.
>>However, I wonder if it was correct for the MV64660 to claim
>>compatibily witn ns16550 if the programming model is not exactly
>>the same. The official OF serial port bindings don't mention the
>>reg-shift property, so it maybe would have been better to have
I'd preferred "reg-stride" or "reg-size" but see below...
>>a different value for the "compatible" property, in order not
>>to confuse existing operating systems that implement the standard.
> Ok, how about 'sparse16550'? Otherwise identical to ns16550, but with
Erm, wouldn't it be *too* generic approach? I'd suggest to name the
device with its own name and make of_serial.c recognize it and register with
8250.c as needed.
> the reg-shift property. I'll send a patch shortly, and I'll reorder the
> match table -- if something claims compatibility with both 8250 and
> 16550, shouldn't we drive it as the latter?
Certainly. BTW, was there really "ns8250" -- 8250 is Intel's chip?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] Handle reg-shift property for of_serial ports
From: Arnd Bergmann @ 2007-07-07 17:52 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Woodhouse, paulus
In-Reply-To: <468FC849.20801@ru.mvista.com>
On Saturday 07 July 2007, Sergei Shtylyov wrote:
> > the reg-shift property. I'll send a patch shortly, and I'll reorder the
> > match table -- if something claims compatibility with both 8250 and
> > 16550, shouldn't we drive it as the latter?
>=20
> =A0 =A0 Certainly. BTW, was there really "ns8250" -- 8250 is Intel's chip?
>=20
No, you're right. http://playground.sun.com/1275/proposals/Closed/Accepted/=
384-it.txt
actually mentions that the the name should be "i8250". It also mentions
that the compatible property should contain "pnpPNP,501" for ns16450 and=20
higher, and "pnpPNP,500" for all serial ports starting from i8250.
Arnd <><
^ permalink raw reply
* Re: [PATCH] Handle reg-shift property for of_serial ports
From: Arnd Bergmann @ 2007-07-07 17:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, David Woodhouse
In-Reply-To: <1183827083.3066.64.camel@shinybook.infradead.org>
On Saturday 07 July 2007, David Woodhouse wrote:
> Can we add properties to indicate the common high-speed modes too? The
> Natsemi baud-base thing could be autodetected by 8250.c if you'd let it,
> but the SMSC trick just has to be set as a UPF_MAGIC_MULTIPLIER flag.
Yes, that sounds good. I do not have enough understanding about the
extra feature to know which ones should get detected with their own
property, so I left that out for the next person that needs it...
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/2] [ide] mmio ide support
From: Sergei Shtylyov @ 2007-07-07 18:15 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20070707094852.9473.21013.stgit@localhost.localdomain>
Hello.
Vitaly Bordug wrote:
> This adds support for MMIO IDE device like CompactFlash
> in TrueIDE mode.
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
[...]
> diff --git a/drivers/ide/legacy/mmio-ide.c b/drivers/ide/legacy/mmio-ide.c
> new file mode 100644
> index 0000000..77fb7dd
> --- /dev/null
> +++ b/drivers/ide/legacy/mmio-ide.c
[...]
> + hwif->mmio = 2;
That hwif->mmio is single-bit field now, so can only be 0 or 1.
MBR, Sergei
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox