loading NOR flash from DT
Hello, I have here a MPC8544 DS board with NOR flash on it and Kumar's git tree. I'm trying to detect this flash with the physmap_of module. I added a nor_flash block (I used sequoia.dts as an example) into my device tree on the same level as soc8544 or memory (or between them). After modprobing physmap_of nothing happend. Then I tried to make a tree with plb -> opb -> ebc and finally nor_flash but still nothing changed. Is there a user space dependency or did I just edit my device tree the wrong way? Any hints are welcome :) Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: loading NOR flash from DT
* Josh Boyer | 2007-10-17 14:47:59 [-0500]: >On Wed, 17 Oct 2007 21:26:51 +0200 >Sebastian Siewior <[EMAIL PROTECTED]> wrote: > >> Hello, >> >> I have here a MPC8544 DS board with NOR flash on it and Kumar's git >> tree. I'm trying to detect this flash with the physmap_of module. I >> added a nor_flash block (I used sequoia.dts as an example) into my >> device tree on the same level as soc8544 or memory (or between them). >> After modprobing physmap_of nothing happend. Then I tried to make a tree >> with plb -> opb -> ebc and finally nor_flash but still nothing changed. >> >> Is there a user space dependency or did I just edit my device tree the >> wrong way? Any hints are welcome :) > >Post your device tree please. I don't recall MPC8544 even having PLB, >OPB, or EBC busses, so they likely aren't getting probed. /* * MPC8544 DS Device Tree Source * * Copyright 2007 Freescale Semiconductor Inc. * * 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. */ / { model = "MPC8544DS"; compatible = "MPC8544DS", "MPC85xxDS"; #address-cells = <1>; #size-cells = <1>; cpus { #cpus = <1>; #address-cells = <1>; #size-cells = <0>; PowerPC,[EMAIL PROTECTED] { device_type = "cpu"; reg = <0>; d-cache-line-size = <20>; // 32 bytes i-cache-line-size = <20>; // 32 bytes d-cache-size = <8000>; // L1, 32K i-cache-size = <8000>; // L1, 32K timebase-frequency = <0>; bus-frequency = <0>; clock-frequency = <0>; }; }; memory { device_type = "memory"; reg = < >; // Filled by U-Boot }; [EMAIL PROTECTED] { compatible = "amd,s29gl512n", "cfi-flash"; reg = ; bank-width = <2>; #address-cells = <1>; #size-cells = <1>; [EMAIL PROTECTED] { label = "fs"; reg = <0 f8>; }; [EMAIL PROTECTED] { label ="firmware"; reg = ; read-only; }; [EMAIL PROTECTED] { #address-cells = <1>; #size-cells = <1>; device_type = "soc"; ranges = < e000 0010>; reg = ; // CCSRBAR 1M bus-frequency = <0>;// Filled out by uboot. [EMAIL PROTECTED] { compatible = "fsl,8544-memory-controller"; reg = <2000 1000>; interrupt-parent = <&mpic>; interrupts = <12 2>; }; [EMAIL PROTECTED] { compatible = "fsl,8544-l2-cache-controller"; reg = <2 1000>; cache-line-size = <20>; // 32 bytes cache-size = <4>; // L2, 256K interrupt-parent = <&mpic>; interrupts = <10 2>; }; [EMAIL PROTECTED] { device_type = "i2c"; compatible = "fsl-i2c"; reg = <3000 100>; interrupts = <2b 2>; interrupt-parent = <&mpic>; dfsrr; }; [EMAIL PROTECTED] { #address-cells = <1>; #size-cells = <0>; device_type = "mdio"; compatible = "gianfar"; reg = <24520 20>; phy0: [EMAIL PROTECTED] { interrupt-parent = <&mpic>;
Re: loading NOR flash from DT
* Sergei Shtylyov | 2007-10-17 23:54:08 [+0400]: > Hello. Hello, >I guess you were using quite recent kernel version where the file that > published the node (arch/powerpc/sysdev/rom.c) had been already dremoved > and and the platform code still didn't publish the on-board devices via > of_platform_bus_probe(). > >> After modprobing physmap_of nothing happend. Then I tried to make a tree >> with plb -> opb -> ebc and finally nor_flash but still nothing changed. > >Add either of_platform_bus_probe() or platform_device_create() to > arch/powerpc/platforms/85xx/85xx_ds.c. > >> Is there a user space dependency or did I just edit my device tree the >> wrong way? Any hints are welcome :) > Thanks, that was the missing piece :) > > WBR, Sergei Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Linux root file system with X window support for a powerpc board
* mahendra varman | 2007-10-19 19:30:37 [+0530]: >Can anybody help me how to create a Linux root file system with X window >support for a powerpc 74xx based board ? > >Any documents/links related to that is also welcome If you are familiar with Gentoo based systems I would recommend [1]. >R.Mahendravarman [1] http://www.gentoo.org/proj/en/base/embedded/cross-development.xml Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[RFC/PATCH] [POWER] mpc85xx_ds add DMA engine to the DT and parse it.
The DT entry is copy / paste from the documentation. Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]> --- arch/powerpc/boot/dts/mpc8544ds.dts | 41 ++ arch/powerpc/platforms/85xx/mpc85xx_ds.c | 13 + 2 files changed, 54 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts b/arch/powerpc/boot/dts/mpc8544ds.dts index 688af9d..fdaf793 100644 --- a/arch/powerpc/boot/dts/mpc8544ds.dts +++ b/arch/powerpc/boot/dts/mpc8544ds.dts @@ -116,6 +116,47 @@ }; }; + [EMAIL PROTECTED] { + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma"; + reg = <21300 4>; + ranges = <0 21100 200>; + cell-index = <0>; + [EMAIL PROTECTED] { + compatible = "fsl,mpc8540-dma-channel", + "fsl,eloplus-dma-channel"; + reg = <0 80>; + cell-index = <0>; + interrupt-parent = <&mpic>; + interrupts = <14 2>; + }; + [EMAIL PROTECTED] { + compatible = "fsl,mpc8540-dma-channel", + "fsl,eloplus-dma-channel"; + reg = <80 80>; + cell-index = <1>; + interrupt-parent = <&mpic>; + interrupts = <15 2>; + }; + [EMAIL PROTECTED] { + compatible = "fsl,mpc8540-dma-channel", + "fsl,eloplus-dma-channel"; + reg = <100 80>; + cell-index = <2>; + interrupt-parent = <&mpic>; + interrupts = <16 2>; + }; + [EMAIL PROTECTED] { + compatible = "fsl,mpc8540-dma-channel", + "fsl,eloplus-dma-channel"; + reg = <180 80>; + cell-index = <3>; + interrupt-parent = <&mpic>; + interrupts = <17 2>; + }; + }; + enet0: [EMAIL PROTECTED] { cell-index = <0>; device_type = "network"; diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c index bdb3d0b..b9a3094 100644 --- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c +++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include @@ -183,6 +184,18 @@ static int __init mpc8544_ds_probe(void) } } +static struct of_device_id mpc85xxds_ids[] = { + { .type = "soc", }, + { .compatible = "soc", }, + {}, +}; + +static int __init mpc85xxds_publish_devices(void) +{ + return of_platform_bus_probe(NULL, mpc85xxds_ids, NULL); +} +machine_device_initcall(mpc8544_ds, mpc85xxds_publish_devices); + /* * Called very early, device-tree isn't unflattened */ -- 1.5.4.3 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Using the loop feature of the DMA controller on MPC8544 DS
Hello, I have here a MPC8544 DS board and I tried to utilise the dma controller. For the transfers I need set the [S|D]AHE bit in the Mode Register. This seems to be implemented but is currently unused in the driver. I haven't found a way how to set this bit except globally for the whole channel. Is it possible to solve this nicely except dedicating one channel for such an operation? thanks, Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Using the loop feature of the DMA controller on MPC8544 DS
* Timur Tabi | 2008-03-12 10:58:21 [-0500]: >Sebastian Siewior wrote: >> Hello, >> >> I have here a MPC8544 DS board and I tried to utilise the dma >> controller. For the transfers I need set the [S|D]AHE bit in the Mode >> Register. This seems to be implemented but is currently unused in the >> driver. > >Which driver? Zhang's DMA driver? Yes, fsldma.c, that's the only one in tree for the CPU unless there are some hidden trees :) >I haven't looked at Zhang's driver, but I just spotted this code: > >case FSL_DMA_IP_85XX: > new_fsl_chan->toggle_ext_start = fsl_chan_toggle_ext_start; > new_fsl_chan->toggle_ext_pause = fsl_chan_toggle_ext_pause; >case FSL_DMA_IP_83XX: > new_fsl_chan->set_src_loop_size = fsl_chan_set_src_loop_size; > new_fsl_chan->set_dest_loop_size = fsl_chan_set_dest_loop_size; > >(Don't let the missing "break" from FSL_DMA_IP_85XX fool you) > >So it looks like there already is a way to set the SAHE and DAHE bits. I guess >this is what you mean by "seems to be implemented but is currently unused"? Yes it is :) >> I haven't found a way how to set this bit except globally for >> the whole channel. > >Well, the SAHE bit is part of the MR register, so it can only apply to a whole >channel. This is a hardware limitation. Argh, I hoped that could be hidden at the offset 0x1c in the link descriptor which is marked as reserved. >> Is it possible to solve this nicely except dedicating one channel for >> such an operation? > >No. I need to hold src & dst each with one and two bytes makes four channels. And then I need one for normal transfers. So I guess I have to talk to my HW ppl that we have to change something :) Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
fsldma seems to be buggy, noticed in loop mode
Hello, I have a little kmod where I dma data from one place to another (can post it if someone wants to see it). It works in general according to memcmp :) If I set the DAHE flag (DAHTS = 0, for one byte transfers) everything seems to work as well (I see only the last byte which has the correct value). Now if I change the destination address to my FIFO I get the requested transfer size plus some extra bytes. The extra bytes are looking like exactly the same DMA transfer once again. Then my FIFO overruns. Enabling some printks in the kernel gave me the following log: |of-fsl-dma-channel e0021100.dma-channe: new link desc alloc df32a000 |of-fsl-dma-channel e0021100.dma-channe: --memcpy issue-- |of-fsl-dma-channel e0021100.dma-channe: Ch 0, LD 1f32a000 |of-fsl-dma-channel e0021100.dma-channe: LD offset 0: 0005 |of-fsl-dma-channel e0021100.dma-channe: LD offset 1: 1f0be000 |of-fsl-dma-channel e0021100.dma-channe: LD offset 2: 0005 |of-fsl-dma-channel e0021100.dma-channe: LD offset 3: 1f36c000 |of-fsl-dma-channel e0021100.dma-channe: LD offset 4: |of-fsl-dma-channel e0021100.dma-channe: LD offset 5: 0001 |of-fsl-dma-channel e0021100.dma-channe: LD offset 6: 0100 |of-fsl-dma-channel e0021100.dma-channe: LD offset 7: |of-fsl-dma-channel e0021100.dma-channe: |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x1f32a000 |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x1f32a000 |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x1f32a000 |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x1f32a000 |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x1f32a000 |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x1f32a000 |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x1f32a000 |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x1f32a000 |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x1f32a000 |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x1f32a000 |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x1f32a000 |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x1f32a000 |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x1f32a000 |of-fsl-dma-channel e0021100.dma-channe: chan completed_cookie = 1 |of-fsl-dma-channel e0021100.dma-channe: link descriptor df32a000 will be recycle. |of-fsl-dma-channel e0021100.dma-channe: chan completed_cookie = 1 |of-fsl-dma-channel e0021100.dma-channe: chan completed_cookie = 1 done. I have one list entry which is df32a000. According to the output that single request gets started a couple of times what would explain why the FIFO overruns. Is it possible that the driver does not properly recognize that the transfer is finished _and_ that is the last one in line? Enabling the dma self test Kconfig option shows no error message but the number of interrupts that have been generated differ from channel to channel, from boot to boot. btw: It is a MPC8544 DS with -rc5. thanks, Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Using the loop feature of the DMA controller on MPC8544 DS
* Timur Tabi | 2008-03-12 13:47:30 [-0500]: >Sebastian Siewior wrote: > >> I need to hold src & dst each with one and two bytes makes four >> channels. And then I need one for normal transfers. So I guess I have to >> talk to my HW ppl that we have to change something :) > >What kind of driver are you writing that needs four simultaneous DMA transfers? Multiple drivers and those transfers may or may not happen simultaneously. I have an USB driver that does slave dma only. For that one I need the normal memcpy. Than there is the FPGA. That one gives me a few components, for instance a few SPI channels. Every SPI channel has two FIFOs, one for write and one for read. Those FIFOs have either 8, 16 or 32 bits. For those few I need the (different) [S|D]AHTS bits. I thing you have the picture. Now. My understanding of the DMA engine API is that multiple clients may use the same channel simultaneously and they rebalence oneself. The xHE bits are one per channel so the USB driver can't share the DMA channel with the SPI driver. In order to share them, I have to lock a channel, set the required bits and after the transfer is done, the channel could be unlocked again. Locking channels isn't currently possible because everyone can call dma_async_client_chan_request() and get every channel that is suitable. Adding DMA_MEMCPY_HOLD_[S|D]_{8|16|32} creates more possibilities than available channel. A nicer solution would be to add DMA_MEMCPY_HOLD and set the required bits for every request but this is unfortunately not possible. What is left... Ah I could lock the channel via DMA_RESOURCE_REMOVED, do my transfer and then give it back. The channels are not freed immediately so transfers from the interrupt handler could be problematic. Do you recommend another solution? Or did I miss an important part of the API that solves this kind of problem. >Timur Tabi >Linux kernel developer at Freescale Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Using the loop feature of the DMA controller on MPC8544 DS
* Timur Tabi | 2008-03-12 15:49:50 [-0500]: >Well, I need to solve this problem myself, but I wasn't planning on doing it >for >a while since I have a higher priority assignment at the moment. My 8610 sound >driver does DMA all on its own and completely ignores Zhang's driver, so I need >to fix that. Ah okey. So you grab one DMA channel for yourself and you hope no one else is going to use it? Are you using lists descriptors or single transfers? >Unfortunately, I'm not familiar with Zhang's driver at all (it's changed too >much since I last looked at it), so I don't know what the *best* way is. His driver uses DMA engine so you can't use the cool features / arch specific settings. >For my >sound driver, I don't even know if I'll be able to leverage Zhang's driver at >all, since I need to use a specific DMA channel, and I need to control each of >the link descriptors. Zhang's driver abstracts DMA too much. So all I was >going to do is come up with a way to reserve channels. Welcome in my world :) >Timur Tabi >Linux kernel developer at Freescale Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: fsldma seems to be buggy, noticed in loop mode
* Zhang Wei | 2008-03-13 15:03:54 [+0800]: >Could you please apply these two patches and test again? > >http://lkml.org/lkml/2008/3/10/64 >http://lkml.org/lkml/2008/3/13/36 Ui, that fast. Did you find this on your own or after me reporting that bug? It solves my FIFO problem, thanks. >Thanks! >Wei. Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: fsldma seems to be buggy, noticed in loop mode
* Zhang Wei | 2008-03-13 17:17:31 [+0800]: >Just after you reported. :) okey. Do you want me to add a tested by on lkml? > >Cheers! >Wei. Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH v2] [POWER] mpc85xx_ds add DMA engine to the DT and parse it.
This is a modified entry I found in the documentation for the 8544. Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]> --- arch/powerpc/boot/dts/mpc8544ds.dts | 41 ++ arch/powerpc/platforms/85xx/mpc85xx_ds.c | 13 + 2 files changed, 54 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts b/arch/powerpc/boot/dts/mpc8544ds.dts index 688af9d..131ffaa 100644 --- a/arch/powerpc/boot/dts/mpc8544ds.dts +++ b/arch/powerpc/boot/dts/mpc8544ds.dts @@ -116,6 +116,47 @@ }; }; + [EMAIL PROTECTED] { + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,mpc8544-dma", "fsl,eloplus-dma"; + reg = <21300 4>; + ranges = <0 21100 200>; + cell-index = <0>; + [EMAIL PROTECTED] { + compatible = "fsl,mpc8544-dma-channel", + "fsl,eloplus-dma-channel"; + reg = <0 80>; + cell-index = <0>; + interrupt-parent = <&mpic>; + interrupts = <14 2>; + }; + [EMAIL PROTECTED] { + compatible = "fsl,mpc8544-dma-channel", + "fsl,eloplus-dma-channel"; + reg = <80 80>; + cell-index = <1>; + interrupt-parent = <&mpic>; + interrupts = <15 2>; + }; + [EMAIL PROTECTED] { + compatible = "fsl,mpc8544-dma-channel", + "fsl,eloplus-dma-channel"; + reg = <100 80>; + cell-index = <2>; + interrupt-parent = <&mpic>; + interrupts = <16 2>; + }; + [EMAIL PROTECTED] { + compatible = "fsl,mpc8544-dma-channel", + "fsl,eloplus-dma-channel"; + reg = <180 80>; + cell-index = <3>; + interrupt-parent = <&mpic>; + interrupts = <17 2>; + }; + }; + enet0: [EMAIL PROTECTED] { cell-index = <0>; device_type = "network"; diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c index bdb3d0b..b9a3094 100644 --- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c +++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include @@ -183,6 +184,18 @@ static int __init mpc8544_ds_probe(void) } } +static struct of_device_id mpc85xxds_ids[] = { + { .type = "soc", }, + { .compatible = "soc", }, + {}, +}; + +static int __init mpc85xxds_publish_devices(void) +{ + return of_platform_bus_probe(NULL, mpc85xxds_ids, NULL); +} +machine_device_initcall(mpc8544_ds, mpc85xxds_publish_devices); + /* * Called very early, device-tree isn't unflattened */ -- 1.5.4.3 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Kernel Panic - not syncing: Attempted to kill init!
* Sreen Tallam | 2008-04-09 19:07:01 [-0700]: >VFS: Mounted root (jffs2 filesystem) readonly. >Freeing unused kernel memory: 156k init >Warning: unable to open an initial console. >init/main.c -- 819 >init/main.c -- 821 >init/main.c -- 844 >init/main.c -- 704 -- /sbin/tallam_init<0>Kernel panic - not syncing: >Attempted to kill init! >Call Trace: >[C3FE7E60] [C0006D98] (unreliable) >[C3FE7EA0] [C001F150] >[C3FE7EF0] [C0023630] >[C3FE7F30] [C0023734] >[C3FE7F40] [C000DBC0] > <0>Rebooting in 180 seconds.. > This looks like you are missing /dev/console and probably /dev/null. You need atleast those two nodes in your rootfs if you are using udev. You will need a static /dev if you don't use udev/mdev. >Thanks, >Sreen Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH v2] [POWER] mpc85xx_ds add DMA engine to the DT and parse it.
* Kumar Gala | 2008-04-10 09:46:39 [-0500]: >>This is a modified entry I found in the documentation for the 8544. >> >>Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]> >>--- >>arch/powerpc/boot/dts/mpc8544ds.dts | 41 + >>+ >>arch/powerpc/platforms/85xx/mpc85xx_ds.c | 13 + >>2 files changed, 54 insertions(+), 0 deletions(-) > >applied. Thank you. >I also added updating the defconfig to enable the driver by default. I just noticed that commit 049c9d455 renamed the ids. I couldn't find this commit in your git tree. Did you rename the ids in the .dts file (or want me to do this)? >- k Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH v2] [POWER] mpc85xx_ds add DMA engine to the DT and parse it.
* Kumar Gala | 2008-04-10 10:33:11 [-0500]: >>>I also added updating the defconfig to enable the driver by default. >>I just noticed that commit 049c9d455 renamed the ids. I couldn't find >>this commit in your git tree. Did you rename the ids in the .dts file >>(or want me to do this)? > >I think they are already in sync am I missing something? Ah, the .dts has mpc8544* and eloplus* so it should be fine. Just got confused by the another commit. >- k Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] DMA Engine: fix error path(s) in fsl-dma driver
of_fsl_dma_probe: - kfree(NULL) doesn't hurt but dereferencing the pointer in iounmap does - also, the irq can be freed of_fsl_dma_chan_probe: - iounmap(NULL) resolved in vunmap() what which in turn is able to handle NULL pointer but dereferencing still doesn't work - don't clean up not yet allocated ressources, like list_del before list_add fsl_dma_self_test: - call fsl_dma_free_chan_resources() if the first dma trans didn't complete Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]> --- drivers/dma/fsldma.c | 38 -- 1 files changed, 24 insertions(+), 14 deletions(-) diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index 054eabf..d36098c 100644 --- a/drivers/dma/fsldma.c +++ b/drivers/dma/fsldma.c @@ -842,7 +842,7 @@ static int fsl_dma_self_test(struct fsl_dma_chan *fsl_chan) if (fsl_dma_is_complete(chan, cookie, NULL, NULL) != DMA_SUCCESS) { dev_err(fsl_chan->dev, "selftest: Time out!\n"); err = -ENODEV; - goto out; + goto free_resources; } /* Test free and re-alloc channel resources */ @@ -927,8 +927,7 @@ static int __devinit of_fsl_dma_chan_probe(struct of_device *dev, if (!new_fsl_chan) { dev_err(&dev->dev, "No free memory for allocating " "dma channels!\n"); - err = -ENOMEM; - goto err; + return -ENOMEM; } /* get dma channel register base */ @@ -936,7 +935,7 @@ static int __devinit of_fsl_dma_chan_probe(struct of_device *dev, if (err) { dev_err(&dev->dev, "Can't get %s property 'reg'\n", dev->node->full_name); - goto err; + goto err_free_mem; } new_fsl_chan->feature = *(u32 *)match->data; @@ -953,12 +952,17 @@ static int __devinit of_fsl_dma_chan_probe(struct of_device *dev, new_fsl_chan->reg_base = ioremap(new_fsl_chan->reg.start, new_fsl_chan->reg.end - new_fsl_chan->reg.start + 1); + if (!new_fsl_chan->reg_base) { + err = -ENOMEM; + goto err_free_mem; + } + new_fsl_chan->id = ((new_fsl_chan->reg.start - 0x100) & 0xfff) >> 7; if (new_fsl_chan->id > FSL_DMA_MAX_CHANS_PER_DEVICE) { dev_err(&dev->dev, "There is no %d channel!\n", new_fsl_chan->id); err = -EINVAL; - goto err; + goto err_unnmap; } fdev->chan[new_fsl_chan->id] = new_fsl_chan; tasklet_init(&new_fsl_chan->tasklet, dma_do_tasklet, @@ -997,23 +1001,28 @@ static int __devinit of_fsl_dma_chan_probe(struct of_device *dev, if (err) { dev_err(&dev->dev, "DMA channel %s request_irq error " "with return %d\n", dev->node->full_name, err); - goto err; + goto err_remove_list; } } err = fsl_dma_self_test(new_fsl_chan); if (err) - goto err; + goto err_test; dev_info(&dev->dev, "#%d (%s), irq %d\n", new_fsl_chan->id, match->compatible, new_fsl_chan->irq); - return 0; -err: + +err_test: dma_halt(new_fsl_chan); - iounmap(new_fsl_chan->reg_base); - free_irq(new_fsl_chan->irq, new_fsl_chan); + if (new_fsl_chan->irq != NO_IRQ) + free_irq(new_fsl_chan->irq, new_fsl_chan); +err_remove_list: list_del(&new_fsl_chan->common.device_node); + fdev->common.chancnt--; +err_unnmap: + iounmap(new_fsl_chan->reg_base); +err_free_mem: kfree(new_fsl_chan); return err; } @@ -1054,8 +1063,7 @@ static int __devinit of_fsl_dma_probe(struct of_device *dev, fdev = kzalloc(sizeof(struct fsl_dma_device), GFP_KERNEL); if (!fdev) { dev_err(&dev->dev, "No enough memory for 'priv'\n"); - err = -ENOMEM; - goto err; + return -ENOMEM; } fdev->dev = &dev->dev; INIT_LIST_HEAD(&fdev->common.channels); @@ -1091,7 +1099,7 @@ static int __devinit of_fsl_dma_probe(struct of_device *dev, if (err) { dev_err(&dev->dev, "DMA device request_irq error " "with return %d\n", err); - goto err; + goto err_remove_irq; } } @@ -1101,6 +1109,8 @@ static int __devinit of_fsl_d
Re: Device tree configuration for I2C eeprom
* Ayman El-Khashab | 2008-09-18 14:44:44 [-0500]: >Here is a snippet from the dts file, and I assume I need something like >what I've added: > >IIC0: [EMAIL PROTECTED] { >compatible = "ibm,iic-460ex", "ibm,iic"; >reg = ; >interrupt-parent = <&UIC0>; >interrupts = <2 4>; >#address-cells = <1>; >#size-cells = <0>; >[EMAIL PROTECTED] { >compatible = "stm,m41t80"; >reg = <68>; >}; >[EMAIL PROTECTED] { >compatible = "?"; > something >something; >}; This should look like: |IIC0: [EMAIL PROTECTED] { |compatible = "ibm,iic-460ex", "ibm,iic"; |reg = ; |interrupt-parent = <&UIC0>; |interrupts = <2 4>; |#address-cells = <1>; |#size-cells = <0>; |[EMAIL PROTECTED] { |compatible = "m41t80"; |reg = <68>; |}; |[EMAIL PROTECTED] { |compatible = "eeprom"; |reg = <50>; |}; Compatible is the ID of the driver. You can find it in the driver itself: if you look in ./drivers/rtc/rtc-m41t80.c you will find a struct m41t80_id which contains the ids. The same applies to the eeprom driver. You might want to update your dts from current kernel tree which contains the "/dts-v1/" tag at the beginning and then your field must contain an 0x prefix. >Once I do all that, how does one use the eeprom driver to read and write >this part? The eeprom driver should create an eeprom file somewhere in /sys I am not sure where exactly. The help entry in Kconfig says that is module provides only RO access to the eeprom. Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Device tree configuration for I2C eeprom
* Grant Likely | 2008-09-18 22:04:41 [-0700]: >No, don't use the generic chip names. Device tree convention is to be >specific and prefix the part number with the vendor name. ie. You should >be using "at,at24c64", not "24c64". What about the i2c drivers which don't have any prefix like the m41t80? Prior commit 0d1cde2 aka "powerpc/i2c: Convert i2c-mpc into an of_platform driver" the ids were converted. > >g. > Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Device tree configuration for I2C eeprom
* Grant Likely | 2008-09-19 00:44:58 [-0700]: >Do not fall into the temptation of writing the device tree to reflect >the current implementation of the operating system. Stick to >established conventions and documented bindings. > >That being said, it is a non-issue in this case. The current Linux OF >support code automagically strips off the manufacturer prefix when >registering I2C devices. Take a look at of_modalias_node() in >drivers/of/base.c for details. Thanks for this information. > >g. Sebastian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded