Re: [PATCH] powerpc/83xx: Enable FIXED_PHY in mpc834x_itx and mpc83xx defconfigs
Anton Vorontsov wrote: The FIXED_PHY driver isn't enabled in the defconfig. Following patch should fix the issue. arch/powerpc/configs/83xx/mpc834x_itx_defconfig |2 +- arch/powerpc/configs/mpc83xx_defconfig |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Acked-by: Timur Tabi [EMAIL PROTECTED] Kumar, please apply. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/83xx: add support for MCU on 8349emitx, 837xrdb and 8315erdb boards
On Fri, Oct 17, 2008 at 12:57 PM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
MCU is an external Freescale MC9S08QG8 microcontroller, mainly used to
provide soft power-off function, but also exports two GPIOs (wired to
the LEDs and also available from the external headers).
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Kumar, I think you merged this patch incorrectly ...
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 7fc5414..4bdbaf4 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -91,6 +91,14 @@
interrupts = 18 0x8;
interrupt-parent = ipic;
};
+
+ mcu_pio: [EMAIL PROTECTED] {
+ #gpio-cells = 2;
+ compatible = fsl,mc9s08qg8-mpc8349emitx,
+fsl,mcu-mpc8349emitx;
+ reg = 0x0a;
+ gpio-controller;
+ };
This node is supposed to go under the I2C node, but you put it under
the DMA node.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: i2c-mpc clocking scheme
Trent Piepho wrote: Seems like it should keep the clock registers at what u-boot set them too. Or we could have U-Boot put the i2c clock frequency into the I2C node, and let the driver program the hardware again. That would keep the ugliness in U-Boot. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: i2c-mpc clocking scheme
André Schwarz wrote: Wouldn't it be easier to omit frequency re-programming at all ? Maybe configurable for non U-Boot users ... Well, the real problem is that Linux is ignoring what the boot loader has done. This is bad, regardless as to which boot loader you're using. The question is, do we give Linux the capability to program the I2C bus speed, or is this something that the boot loader should do? Unfortunately, the current Linux code means that this issue is not properly architected. You mentioned people who don't use U-Boot. Do they use some other boot loader? Or no boot loader at all? Do other boot loaders program the I2C bus speed? The reason I ask is that I want to know whether it's okay for Linux to ignore the FDR and DFSRR registers. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: i2c-mpc clocking scheme
Trent Piepho wrote: For a bus device like an i2c controller, you really have two clocks. The input clock the controller runs from and the speed it runs the bus at. One could say that one clock is for the device node and the other clock is for the device's sub-nodes. We could add a property to each I2C device nodes that lists the maximum speed that this supports. Then the I2C driver could find the smallest of these speeds, and program the I2C controller for that speed. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: i2c-mpc clocking scheme
On Thu, Nov 27, 2008 at 9:00 AM, Andre Schwarz [EMAIL PROTECTED] wrote: All, is anybody working on some improvements regarding configurable I2C frequency inside the i2c-mpc driver ? If not - would anybody be intersted in getting this done, i.e. configurable via device tree ? Maybe I'm missing something, but U-Boot configures the I2C bus speed. It does this because the algorithm is specific to the SOC itself. For example, the 8544 is different from the 8548. It would be a mess to duplicate this code in the kernel. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
Milton Miller wrote: We want the last console= parameter on the command line to win. So if that implys the last call to add_preferred_console wins, then you have code overriding the command line. Hmm, good point. However, how likely is it that we'll have more than one console driver? Also, without calling add_preferred_console(), the kernel needs to have a console= on the command line. In my case, my driver only calls add_preferred_console() if the device tree contains a specific property that it looks for. In effect, this property override the console= line. However, the console= line goes to the HVC subsystem, and not my driver, and I can't use it to send the configuration data the driver needs. Unfortunately, my driver hasn't been published yet, so it's hard to explain the details. I guess I need to think about this more. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
David Gibson wrote: Um.. yeah.. I'm a bit baffled by this.. all the existing backends are listed after hvc_console, I just added hvc_udbg to the end. I didn't really understand the rationale in that commit, but then I haven't had time to look at it very much yet. No, some are before: obj-$(CONFIG_HVC_RTAS) += hvc_rtas.o --- obj-$(CONFIG_HVC_BEAT) += hvc_beat.o --- obj-$(CONFIG_HVC_DRIVER)+= hvc_console.o obj-$(CONFIG_HVC_IRQ) += hvc_irq.o obj-$(CONFIG_HVC_XEN) += hvc_xen.o obj-$(CONFIG_HVC_UDBG) += hvc_udbg.o Until your patch, only Xen was wrong. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
David Gibson wrote: Given the variety of strange I/O configurations in prototype and embedded platforms, I can't imagine this was a unique situation. So I've pushed my patch out, so anyone else in a similar situation can immediately turn their little udbg methods for whatever strange I/O they have into a fully-functional console. Maybe it's not something you'd want to go to release with, but it certainly simplifies life during bringup. Ok, I understand now. However, I would like to see two changes: 1) Re-arrange the Makefile as I pointed out in another post. 2) Update the Kconfig help file to be very clear that this feature is only meaningful if the platform has a udbg back-end but no other console or TTY driver. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
On Thu, Oct 23, 2008 at 9:54 PM, David Gibson [EMAIL PROTECTED] wrote: This can be used to quickly implement a userspace usable console while you're working on a proper driver for whatever console I/O device the hardware has. Or, it can be used to avoid writing a full blown tty/console driver entirely for quick-and-dirty I/O hardware that will later be replaced by something else. Ok, I think I understand this better now. Your approach seems backwards to me. HVC console client drivers already have simple put/get functions. You've written an hvc driver that makes udbg calls. Wouldn't it have been better to make a udbg driver that makes hvc calls? That way, you effectively give udbg support to all hvc drivers in one shot. In order to support udbg in my hvc driver, I have to add udbg calls. In fact, now that I've thought about it, I don't understand what your driver does. You take hvc callbacks and route them through udbg, but this only works on drivers that have udbg callbacks in the first place. In that case, why would these drivers need an hvc middle-man? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
On Thu, Oct 23, 2008 at 9:54 PM, David Gibson [EMAIL PROTECTED] wrote: One other thing ... --- working-2.6.orig/drivers/char/Makefile 2008-10-22 15:50:59.0 +1100 +++ working-2.6/drivers/char/Makefile 2008-10-24 14:22:59.0 +1100 @@ -50,6 +50,7 @@ obj-$(CONFIG_HVC_BEAT)+= hvc_beat.o obj-$(CONFIG_HVC_DRIVER) += hvc_console.o obj-$(CONFIG_HVC_IRQ) += hvc_irq.o obj-$(CONFIG_HVC_XEN) += hvc_xen.o +obj-$(CONFIG_HVC_UDBG) += hvc_udbg.o HVC console drivers must be compiled before hvc_console.o, so the above should look like this: obj-$(CONFIG_HVC_XEN) += hvc_xen.o obj-$(CONFIG_HVC_UDBG) += hvc_udbg.o obj-$(CONFIG_HVC_DRIVER) += hvc_console.o obj-$(CONFIG_HVC_IRQ) += hvc_irq.o see http://git.kernel.org/?p=linux/kernel/git/paulus/powerpc.git;a=commit;h=938473b24636d77dc5e9c3f41090d071b6cf4389 -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Some udbg questions
I'm adding udbg support to my console driver, and I've noticed that there is not much consistency on how the various platforms implement udbg support. So I have a few questions: 1. What is the point of implementing udbg_getc? What does the console do with any characters it receives this early? 2. In my driver's udbg initialization function, should I be able to parse the device tree to get parameters? 3. What about command-line parameters? 4. The LPAR and PMAC platforms call register_early_udbg_console (in the udbg_init_debug_lpar and pmac_init_early functions, respectively), but none of the other platforms do. It appears that the other platforms rely on setup_32.c and setup_64.c to call this function. What's so special about LPAR and PMAC? 5. Some platforms (like mv64x60) use the ppc_md.init_early function to initialize the early console. Others update function udbg_early_init() in udbg.c instead. Why do some platforms do it one way, and other platforms do it the other way? Which way is preferred? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
On Mon, Nov 17, 2008 at 6:40 PM, David Gibson [EMAIL PROTECTED] wrote: Because the udbg console works for kernel messages, but doesn't support a full tty interface, so you can't run userspace with only a udbg console. I still don't understand the point of your driver. You're just routing hcalls to a udbg back-end. So if you have a driver that supports udbg but not standard console or TTY, then you can use your driver to get console/tty I/O. Is there a platform where such a setup exists? All HVC drivers support console and TTY, as do all serial drivers. So what platform would use your driver? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/qe: Move cmxgcr_lock definition from the ucc.c into the qe.c
On Tue, Nov 11, 2008 at 9:31 AM, Anton Vorontsov [EMAIL PROTECTED] wrote: With this patch we can compile the qe_lib/usb.c without the UCC support (that is, without UCC_GETH and/or SERIAL_QE). Fixes following link error (CONFIG_SMP should be =y to trigger this): arch/powerpc/sysdev/built-in.o: In function `qe_usb_clock_set': (.text+0x3cae): undefined reference to `cmxgcr_lock' make: *** [.tmp_vmlinux1] Error 1 While at it, also add missing spinlock.h includes. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] Acked-By: Timur Tabi [EMAIL PROTECTED] -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V3] powerpc: Fix Book-E watchdog timer interval setting
Matthias Fuchs wrote: This patch fixes the setting of the Book-E watchdog timer interval setup on initialization and by ioctl(). On initialization the period bits have to be masked before setting a new period. In WDIOC_SETTIMEOUT ioctl we have to use the correct mask. Signed-off-by: Matthias Fuchs [EMAIL PROTECTED] Acked-by: Timur Tabi [EMAIL PROTECTED] -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc: Fix Book-E watchdog timer interval setting
Matthias Fuchs wrote: Timur, I missed you posting. But you are right. My patch is ok for 4xx CPUs and touching the CONFIG_FSL_BOOKE path was not my intention. So for CONFIG_FSL_BOOKE WDTP_MASK should be WDTP(0). There is still a slightly difference between WDTP(0)=(3 30) | (0x3c 15) and (3 30) | (15 15). Can you check that please and I will resend my patch. Yes, I think WDTP(0) is correct for Book E. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'for-2.6.28' branch
On Tue, Oct 21, 2008 at 9:49 AM, Kumar Gala [EMAIL PROTECTED] wrote: I understood, just haven't had time to look at these patches. I don't know if this is likely to make it into 2.6.28. I ack'd the QE library portions of these patches back in April. Sure, a lot has changed since then, but what's the point of having a merge window if you don't actually merge the code? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: disable CHRP and PMAC support in various defconfigs
Because CHRP and PMAC are by default enabled, several non-CHRP and non-PMAC PowerPC defconfigs will have these Kconfig options set erroneously. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- arch/powerpc/configs/83xx/asp8347_defconfig |2 ++ arch/powerpc/configs/83xx/mpc8313_rdb_defconfig |2 ++ arch/powerpc/configs/83xx/mpc8315_rdb_defconfig |2 ++ arch/powerpc/configs/83xx/mpc832x_mds_defconfig |2 ++ arch/powerpc/configs/83xx/mpc832x_rdb_defconfig |2 ++ arch/powerpc/configs/83xx/mpc834x_itx_defconfig |2 ++ arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig |2 ++ arch/powerpc/configs/83xx/mpc834x_mds_defconfig |2 ++ arch/powerpc/configs/83xx/mpc836x_mds_defconfig |2 ++ arch/powerpc/configs/83xx/mpc836x_rdk_defconfig |2 ++ arch/powerpc/configs/83xx/mpc837x_mds_defconfig |2 ++ arch/powerpc/configs/83xx/mpc837x_rdb_defconfig |2 ++ arch/powerpc/configs/83xx/sbc834x_defconfig |2 ++ arch/powerpc/configs/86xx/gef_sbc610_defconfig|5 - arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig |2 ++ arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig |2 ++ arch/powerpc/configs/86xx/sbc8641d_defconfig |2 ++ arch/powerpc/configs/ep8248e_defconfig|2 ++ arch/powerpc/configs/mpc8272_ads_defconfig|2 ++ arch/powerpc/configs/mpc83xx_defconfig|2 ++ arch/powerpc/configs/pq2fads_defconfig|2 ++ 21 files changed, 44 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/configs/83xx/asp8347_defconfig b/arch/powerpc/configs/83xx/asp8347_defconfig index 6638f5a..0b1fa20 100644 --- a/arch/powerpc/configs/83xx/asp8347_defconfig +++ b/arch/powerpc/configs/83xx/asp8347_defconfig @@ -164,6 +164,8 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +# CONFIG_PPC_PMAC is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set diff --git a/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig b/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig index df125f3..b7eae2b 100644 --- a/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig +++ b/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig @@ -163,6 +163,8 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +# CONFIG_PPC_PMAC is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set diff --git a/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig b/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig index 6e0e08c..b0a27a6 100644 --- a/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig +++ b/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig @@ -163,6 +163,8 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +# CONFIG_PPC_PMAC is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set diff --git a/arch/powerpc/configs/83xx/mpc832x_mds_defconfig b/arch/powerpc/configs/83xx/mpc832x_mds_defconfig index d6e204a..ad825bc 100644 --- a/arch/powerpc/configs/83xx/mpc832x_mds_defconfig +++ b/arch/powerpc/configs/83xx/mpc832x_mds_defconfig @@ -163,6 +163,8 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +# CONFIG_PPC_PMAC is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set diff --git a/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig b/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig index 1f3d343..3826750 100644 --- a/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig +++ b/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig @@ -163,6 +163,8 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +# CONFIG_PPC_PMAC is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set diff --git a/arch/powerpc/configs/83xx/mpc834x_itx_defconfig b/arch/powerpc/configs/83xx/mpc834x_itx_defconfig index 4686c21..90aab34 100644 --- a/arch/powerpc/configs/83xx/mpc834x_itx_defconfig +++ b/arch/powerpc/configs/83xx/mpc834x_itx_defconfig @@ -163,6 +163,8 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +# CONFIG_PPC_PMAC is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set diff --git a/arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig b/arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig index f11c25e..7458a24 100644 --- a/arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig +++ b/arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig @@ -163,6 +163,8 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +# CONFIG_PPC_PMAC is not set # CONFIG_MPC5121_ADS is not set
[PATCH] powerpc: reserve two DMA channels for audio in MPC8610 HPCD device tree
The Freescale Elo DMA driver binds to all DMA channels in the device tree that
are compatible with fsl,eloplus-dma-channel. This conflicts with the sound
drivers for the MPC8610 HPCD. On this board, the SSI uses two DMA channels and
therefore those channels are not available for general purpose use. We
change the compatible properties for these channels fsl,ssi-dma-channel.
This works because the sound drivers don't actually check the compatible
property when it grabs channels.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8610_hpcd.dts |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 0f3a36e..3f4c610 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -237,7 +237,7 @@
dma00: [EMAIL PROTECTED] {
compatible = fsl,mpc8610-dma-channel,
- fsl,eloplus-dma-channel;
+ fsl,ssi-dma-channel;
cell-index = 0;
reg = 0x0 0x80;
interrupt-parent = mpic;
@@ -245,7 +245,7 @@
};
dma01: [EMAIL PROTECTED] {
compatible = fsl,mpc8610-dma-channel,
- fsl,eloplus-dma-channel;
+ fsl,ssi-dma-channel;
cell-index = 1;
reg = 0x80 0x80;
interrupt-parent = mpic;
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: document the fsl, ssi-dma-channel compatible property
The fsl,ssi-dma-channel compatible property is used to specify a DMA channel on the Freescale Elo DMA controller that should be used exclusively by the Freescale SSI audio controller. When a property is marked as such, the Elo DMA driver will ignore it, and so it will be available for the sound drivers. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- Documentation/powerpc/dts-bindings/fsl/dma.txt | 13 +++-- Documentation/powerpc/dts-bindings/fsl/ssi.txt | 20 ++-- 2 files changed, 25 insertions(+), 8 deletions(-) diff --git a/Documentation/powerpc/dts-bindings/fsl/dma.txt b/Documentation/powerpc/dts-bindings/fsl/dma.txt index 86826df..cc45311 100644 --- a/Documentation/powerpc/dts-bindings/fsl/dma.txt +++ b/Documentation/powerpc/dts-bindings/fsl/dma.txt @@ -20,7 +20,7 @@ Required properties: - compatible: compatible list, contains 2 entries, first is fsl,CHIP-dma-channel, where CHIP is the processor (mpc8349, mpc8350, etc.) and the second is -fsl,elo-dma-channel +fsl,elo-dma-channel. However, see note below. - reg : registers mapping for channel - cell-index: dma channel index starts at 0. @@ -82,7 +82,7 @@ Required properties: - compatible: compatible list, contains 2 entries, first is fsl,CHIP-dma-channel, where CHIP is the processor (mpc8540, mpc8560, etc.) and the second is -fsl,eloplus-dma-channel +fsl,eloplus-dma-channel. However, see note below. - cell-index: dma channel index starts at 0. - reg : registers mapping for channel - interrupts: interrupt mapping for DMA channel IRQ @@ -125,3 +125,12 @@ Example: interrupts = 17 2; }; }; + +Note on DMA channel compatible properties: The compatible property must say +fsl,elo-dma-channel or fsl,eloplus-dma-channel to be used by the Elo DMA +driver (fsldma). Any DMA channel used by fsldma cannot be used by another +DMA driver, such as the SSI sound drivers for the MPC8610. Therefore, any DMA +channel that should be used for another driver should not use +fsl,elo-dma-channel or fsl,eloplus-dma-channel. For the SSI drivers, for +example, the compatible property should be fsl,ssi-dma-channel. See ssi.txt +for more information. diff --git a/Documentation/powerpc/dts-bindings/fsl/ssi.txt b/Documentation/powerpc/dts-bindings/fsl/ssi.txt index 5d98413..a2d9639 100644 --- a/Documentation/powerpc/dts-bindings/fsl/ssi.txt +++ b/Documentation/powerpc/dts-bindings/fsl/ssi.txt @@ -24,12 +24,12 @@ Required properties: rj-master - r.j., SSI is clock master ac97-slave - AC97 mode, SSI is clock slave ac97-master - AC97 mode, SSI is clock master -- fsl,playback-dma: phandle to a DMA node for the DMA channel to use for - playback of audio. This is typically dictated by SOC - design. See the notes below. -- fsl,capture-dma: phandle to a DMA node for the DMA channel to use for - capture (recording) of audio. This is typically dictated - by SOC design. See the notes below. +- fsl,playback-dma: phandle to a node for the DMA channel to use for +playback of audio. This is typically dictated by SOC +design. See the notes below. +- fsl,capture-dma: phandle to a node for the DMA channel to use for +capture (recording) of audio. This is typically dictated +by SOC design. See the notes below. Optional properties: - codec-handle : phandle to a 'codec' node that defines an audio @@ -51,3 +51,11 @@ playback and DMA channel 1 for capture. SSI2 must use DMA channel 2 for playback and DMA channel 3 for capture. The developer can choose which DMA controller to use, but the channels themselves are hard-wired. The purpose of these two properties is to represent this hardware design. + +The device tree nodes for the DMA channels that are referenced by +fsl,playback-dma and fsl,capture-dma must be marked as compatible with +fsl,ssi-dma-channel. The SOC-specific compatible string (e.g. +fsl,mpc8610-dma-channel) can remain. If these nodes are left as +fsl,elo-dma-channel or fsl,eloplus-dma-channel, then the generic Elo DMA +drivers (fsldma) will attempt to use them, and it will conflict with the +sound drivers. -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove default=y from PMAC and CHRP Kconfigs
Benjamin Herrenschmidt wrote: I'm happy with -all- platforms for a given CPU type defaulting to y. I'm not sure I understand. The current Kconfigs defaults to Y for CHRP and PMAC on *all* PowerPC systems, including those that are neither CHRP nor PMAC. Are you saying that's a good thing? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove default=y from PMAC and CHRP Kconfigs
On Thu, Oct 9, 2008 at 10:59 AM, Matt Sealey [EMAIL PROTECTED] wrote: If you really want to build a single-cpu single-board kernel, disable CHRP and PMAC for those board configs, but the default definitely should be to enable them all within reason The problem is that this is inconsistent with most Kconfig options. Last I heard, the kernel community generally frowns on default y in Kconfig options. I'm waiting for someone to explain to me what's so special about CHRP and PMAC that these two platforms should be enabled by default, when all other PowerPC platforms are disabled by default. This is what I see in menuconfig when I create a fresh .config for PowerPC: │ │[*] Common Hardware Reference Platform (CHRP) based machines (NEW) │ │[ ] Freescale MPC5121E ADS (NEW) │ │[ ] Generic support for simple MPC5121 based boards (NEW) │ │[ ] 52xx-based boards (NEW) │ │[*] Apple PowerMac based machines (NEW) │ │[ ] 82xx-based boards (PQ II) (NEW) --- │ │[ ] 83xx-based boards (NEW) --- │ │[ ] 86xx-based boards (NEW) --- │ │[ ] Embedded 6xx/7xx/7xxx-based boards (NEW) CHRP and PMAC aren't following the rules that everyone else is following. Why? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Compact Flash on 8349mITX
On Thu, Oct 9, 2008 at 10:52 AM, Jeff Borlin [EMAIL PROTECTED] wrote: I have taken over this effort to get Compact Flash working on the 8349mITX board and am running into these same issues. I can get uBoot to list the contents of a CF card, but am running into a couple problems through the kernel. There appears to be an IRQ problem and a general communication problem with the CF card, possibly related. I've heard on-and-off that there are problems with the CF support on the 8349 ITX, but I've never had the chance to investigate it. Can you try using the latest BSP kernel and see if the problem is present there? Sometimes the BSP has a hacked-up kernel that addresses hardware issues, but these patches aren't pushed upstream, so the mainline kernel has problems. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove default=y from PMAC and CHRP Kconfigs
On Thu, Oct 9, 2008 at 11:49 AM, Matt Sealey [EMAIL PROTECTED] wrote: Because they are by far the historically most common configuration, and still in production as the defacto standard PowerPC system configuration. Not really. PMAC systems are not being built any more. So that leaves CHRP. IBM blades etc. with SLOF will boot up as a CHRP-ish system, as well as the Efika and Pegasos and anything else Genesi produces. Since Linux distributions generally do not support tiny embedded boards, So what? Distributions don't need our help to turn on the options that are important to them. This is a ridiculous argument. you can imagine why it's disabled by default, but there's no reason it can't be ENABLED by default and turned off by a distribution, the same way it can't be enabled by default and turned off by YOU (compare and contrast having to manually select which board you want to build for every time). This problem is solved with defconfigs. Kconfig options are supposed to make sense. Not all PowerPC systems are CHRP, therefore CHRP should not be enabled by default. But, turning them all on would not matter. You would build a kernel for every one and a device tree for every one increasing your build time a bit for a default kernel, Not really true. Having the default be disabled for specific platforms can make a big difference in compile time. but you would be guaranteed to get a kernel binary somewhere in the tree that would work on all of them :) Again, not relevant. One giant kernel that works on a Freescale embedded system *and* an IBM mainframe is useless. No one would actually ever do that. Genesi, Manager, Developer Relations Developer Relations, eh? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove default=y from PMAC and CHRP Kconfigs
On Thu, Oct 9, 2008 at 3:18 PM, Sven Luther [EMAIL PROTECTED] wrote: Not really true. Having the default be disabled for specific platforms can make a big difference in compile time. Notice that the defconfigs answer also applies here :) Not really. In order for me to create a new defconfig for an embedded platform, I have to turn *off* CHRP *and* PMAC support, and then turn on whatever platform I want. That's the point behind my patch. The default is on, so anyone creating a non-CHRP or non-PMAC platform has to do extra work. And the argument that embedded platforms aren't as important as the exalted CHRP is bollocks. All platforms should be treated equally. And like I said earlier, PMAC platforms aren't even being built any more, so it's ridiculous to consider that the default. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove default=y from PMAC and CHRP Kconfigs
Sven Luther wrote: You just turn it on by default for 64bit and idsable it for 32bit :) That hack might work for now, but it will break once we have 64-bit embedded systems. Regardless, it doesn't address the core issue - there should be no default platform for PowerPC. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove default=y from PMAC and CHRP Kconfigs
On Thu, Oct 9, 2008 at 8:22 PM, Kumar Gala [EMAIL PROTECTED] wrote: The problem with making all platforms default to N is that if you take the default values for all config options you end up with a config that won't build. So we want at least one platform to default to Y, and pmac has been as good a choice as any for that (and probably still is). Ok, I can accept that. I've got no issue w/grandfathering CHRP or PMAC as default Y. However I DO NOT think we should default other platforms to 'Y' as that means updating configs will pick up platforms they dont want. As far as I know, CHRP and PMAC are the only PowerPC platforms that default to Y. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove CHRP and PMAC support from defconfigs, fix Kconfigs
Benjamin Herrenschmidt wrote: yeah well, there's a consistency problem. If we remove default for these we should remove default for all. I only removed the default from the ones I knew were wrong. The bug I think is in your original patch in fact to just remove those from .config rather than explicitely set them to not set. I did that because with the Kconfig changes, it's not necessary to set them to not set, so it kept the patch smaller. I'm not going to remove the applied patch to avoid rebasing, it's harmless to keep it in, please send another one that does the above. Ok. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: remove default=y from PMAC and CHRP Kconfigs
Remove the default y from the Kconfig options for CHRP, PMAC, and PMAC64 platforms. This patch is a follow-up to remove CHRP and PMAC support from defconfigs, fix Kconfigs, which was applied incompletely. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- Ben, in the future, please apply either all of my patch or none of it. Applying half of my patch and thinking about the other half doesn't do me any good. arch/powerpc/platforms/chrp/Kconfig |1 - arch/powerpc/platforms/powermac/Kconfig |4 2 files changed, 0 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/platforms/chrp/Kconfig b/arch/powerpc/platforms/chrp/Kconfig index 22b4b4e..682afbc 100644 --- a/arch/powerpc/platforms/chrp/Kconfig +++ b/arch/powerpc/platforms/chrp/Kconfig @@ -9,4 +9,3 @@ config PPC_CHRP select PPC_UDBG_16550 select PPC_NATIVE select PCI - default y diff --git a/arch/powerpc/platforms/powermac/Kconfig b/arch/powerpc/platforms/powermac/Kconfig index 055990c..85619d3 100644 --- a/arch/powerpc/platforms/powermac/Kconfig +++ b/arch/powerpc/platforms/powermac/Kconfig @@ -6,7 +6,6 @@ config PPC_PMAC select PPC_INDIRECT_PCI if PPC32 select PPC_MPC106 if PPC32 select PPC_NATIVE - default y config PPC_PMAC64 bool @@ -16,6 +15,3 @@ config PPC_PMAC64 select MPIC_U3_HT_IRQS select GENERIC_TBSYNC select PPC_970_NAP - default y - - -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove default=y from PMAC and CHRP Kconfigs
On Wed, Oct 8, 2008 at 3:03 PM, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: No. Instead, send a patch that fixes the defconfig's to explicitely set those to n. As to whether those should be defaults or not, this is a different discussion (I'm almost tempted to have everything default to y). But this is the reason I sent you the patch in the first place. I think default y is wrong and doesn't make any sense, so I'm asking you for a technical reason why PMAC and CHRP should default to yes. That is the focus of my patch. The defconfig changes are just to clean up the mess that default y left behind. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove CHRP and PMAC support from defconfigs, fix Kconfigs
On Fri, Sep 26, 2008 at 12:19 PM, Timur Tabi [EMAIL PROTECTED] wrote: The Kconfig files for PowerPC CHRP and PMAC support had default=y for some Kconfig options, and this caused support for CHRP and PMAC platforms to be enabled incorrectly for several platforms. Fix the Kconfigs and the affected defconfigs. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- This patch is for 2.6.28. Ben, please review and make sure I'm not being to conservative or too aggressive. I don't know enough about CHRP and PMAC to be sure I'm doing this right. Ping. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: make Freescale QE support a selectable Kconfig option
Anton Vorontsov wrote: Btw, as for the need.. yes, it was needed to support the FHCI. But now the FHCI would just depend on it, which is better approach anyway. I also noticed that QE GPIO support is a top-level Kconfig option, instead of under Device Drivers - GPIO. Is that intentional? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: make Freescale QE support a selectable Kconfig option
Anton Vorontsov wrote: Yup. David said that platform GPIO controllers should not go into the drivers/gpio/, their place is in the arch/. Then when I do make menuconfig, why doesn't that option appear under Platform support? This is what I see now: [*] Networking support --- Device Drivers --- File systems --- [*] QE GPIO support Library routines --- Kernel hacking --- -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: make Freescale QE support a selectable Kconfig option
Modify the Kconfig so that Freescale QUICC Engine (QE) support is a selectable option, thereby allowing users to compile kernels without any QE support. The drawback is that QE support is now disabled by default on platforms that have a QE, and so a defconfig is needed to enable QE and QE devices (like UCC GETH). Fortunately, all the current relevant defconfigs do that already. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- This patch should be applied to Kumar's branch for 2.6.28 patches. arch/powerpc/platforms/83xx/Kconfig |5 - arch/powerpc/platforms/85xx/Kconfig |1 - arch/powerpc/platforms/Kconfig |3 ++- 3 files changed, 2 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig index 6159c5d..83c664a 100644 --- a/arch/powerpc/platforms/83xx/Kconfig +++ b/arch/powerpc/platforms/83xx/Kconfig @@ -19,7 +19,6 @@ config MPC831x_RDB config MPC832x_MDS bool Freescale MPC832x MDS select DEFAULT_UIMAGE - select QUICC_ENGINE select PPC_MPC832x help This option enables support for the MPC832x MDS evaluation board. @@ -27,7 +26,6 @@ config MPC832x_MDS config MPC832x_RDB bool Freescale MPC832x RDB select DEFAULT_UIMAGE - select QUICC_ENGINE select PPC_MPC832x help This option enables support for the MPC8323 RDB board. @@ -57,15 +55,12 @@ config MPC834x_ITX config MPC836x_MDS bool Freescale MPC836x MDS select DEFAULT_UIMAGE - select QUICC_ENGINE help This option enables support for the MPC836x MDS Processor Board. config MPC836x_RDK bool Freescale/Logic MPC836x RDK select DEFAULT_UIMAGE - select QUICC_ENGINE - select QE_GPIO select FSL_GTM select FSL_LBC help diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index 291675b..b79dc71 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -33,7 +33,6 @@ config MPC85xx_CDS config MPC85xx_MDS bool Freescale MPC85xx MDS select DEFAULT_UIMAGE - select QUICC_ENGINE select PHYLIB help This option enables support for the MPC85xx MDS board diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig index 9578c45..6cf517f 100644 --- a/arch/powerpc/platforms/Kconfig +++ b/arch/powerpc/platforms/Kconfig @@ -239,7 +239,8 @@ config TAU_AVERAGE If in doubt, say N here. config QUICC_ENGINE - bool + bool Freescale QUICC Engine (QE) Support + depends on FSL_SOC select PPC_LIB_RHEAP select CRC32 help -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: make Freescale QE support a selectable Kconfig option
On Fri, Oct 3, 2008 at 11:23 AM, Anton Vorontsov [EMAIL PROTECTED] wrote: How about this patch? Or we can move QUICC_ENGINE into the qe_lib/Kconfig and include it in the platform/Kconfig... either way would work. Thanks for noticing. arch/powerpc/Kconfig |2 -- arch/powerpc/platforms/Kconfig | 36 arch/powerpc/sysdev/qe_lib/Kconfig | 35 --- 3 files changed, 36 insertions(+), 37 deletions(-) delete mode 100644 arch/powerpc/sysdev/qe_lib/Kconfig Acked-by: Timur Tabi [EMAIL PROTECTED] -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: make Freescale QE support a selectable Kconfig option
Kumar Gala wrote: applied I have a few other patches that I've sent you over the past couple weeks that you haven't applied: powerpc: fix conflict with Elo DMA driver in MPC8610 device tree powerpc: remove CHRP and PMAC support from defconfigs, fix Kconfigs powerpc: remove support for bootmem-allocated memory for the DIU driver -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: make Freescale QE support a selectable Kconfig option
Modify the Kconfig so that Freescale QUICC Engine (QE) support is a selectable option, thereby allowing users to compile kernels without any QE support. The drawback is that QE support is now disabled by default on platforms that have a QE, and so a defconfig is needed to enable QE and QE devices (like UCC GETH). Fortunately, all the current relevant defconfigs do that already. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- This patch should be applied to Kumar's branch for 2.6.28 patches. arch/powerpc/platforms/83xx/Kconfig |4 arch/powerpc/platforms/Kconfig |3 ++- 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig index 6159c5d..4a6cc78 100644 --- a/arch/powerpc/platforms/83xx/Kconfig +++ b/arch/powerpc/platforms/83xx/Kconfig @@ -19,7 +19,6 @@ config MPC831x_RDB config MPC832x_MDS bool Freescale MPC832x MDS select DEFAULT_UIMAGE - select QUICC_ENGINE select PPC_MPC832x help This option enables support for the MPC832x MDS evaluation board. @@ -27,7 +26,6 @@ config MPC832x_MDS config MPC832x_RDB bool Freescale MPC832x RDB select DEFAULT_UIMAGE - select QUICC_ENGINE select PPC_MPC832x help This option enables support for the MPC8323 RDB board. @@ -57,14 +55,12 @@ config MPC834x_ITX config MPC836x_MDS bool Freescale MPC836x MDS select DEFAULT_UIMAGE - select QUICC_ENGINE help This option enables support for the MPC836x MDS Processor Board. config MPC836x_RDK bool Freescale/Logic MPC836x RDK select DEFAULT_UIMAGE - select QUICC_ENGINE select QE_GPIO select FSL_GTM select FSL_LBC diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig index 9578c45..6cf517f 100644 --- a/arch/powerpc/platforms/Kconfig +++ b/arch/powerpc/platforms/Kconfig @@ -239,7 +239,8 @@ config TAU_AVERAGE If in doubt, say N here. config QUICC_ENGINE - bool + bool Freescale QUICC Engine (QE) Support + depends on FSL_SOC select PPC_LIB_RHEAP select CRC32 help -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: remove CHRP and PMAC support from defconfigs, fix Kconfigs
The Kconfig files for PowerPC CHRP and PMAC support had default=y for some Kconfig options, and this caused support for CHRP and PMAC platforms to be enabled incorrectly for several platforms. Fix the Kconfigs and the affected defconfigs. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- This patch is for 2.6.28. Ben, please review and make sure I'm not being to conservative or too aggressive. I don't know enough about CHRP and PMAC to be sure I'm doing this right. arch/powerpc/configs/83xx/asp8347_defconfig |2 -- arch/powerpc/configs/83xx/mpc8313_rdb_defconfig |2 -- arch/powerpc/configs/83xx/mpc8315_rdb_defconfig |2 -- arch/powerpc/configs/83xx/mpc832x_mds_defconfig |2 -- arch/powerpc/configs/83xx/mpc832x_rdb_defconfig |2 -- arch/powerpc/configs/83xx/mpc834x_itx_defconfig |2 -- arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig |2 -- arch/powerpc/configs/83xx/mpc834x_mds_defconfig |2 -- arch/powerpc/configs/83xx/mpc836x_mds_defconfig |2 -- arch/powerpc/configs/83xx/mpc836x_rdk_defconfig |2 -- arch/powerpc/configs/83xx/mpc837x_mds_defconfig |2 -- arch/powerpc/configs/83xx/mpc837x_rdb_defconfig |2 -- arch/powerpc/configs/83xx/sbc834x_defconfig |2 -- arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig |2 -- arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig |2 -- arch/powerpc/configs/86xx/sbc8641d_defconfig |2 -- arch/powerpc/configs/ep8248e_defconfig|2 -- arch/powerpc/configs/mpc8272_ads_defconfig|2 -- arch/powerpc/configs/mpc83xx_defconfig|2 -- arch/powerpc/configs/pq2fads_defconfig|2 -- arch/powerpc/platforms/chrp/Kconfig |1 - arch/powerpc/platforms/powermac/Kconfig |4 22 files changed, 0 insertions(+), 45 deletions(-) diff --git a/arch/powerpc/configs/83xx/asp8347_defconfig b/arch/powerpc/configs/83xx/asp8347_defconfig index 5e6780a..6638f5a 100644 --- a/arch/powerpc/configs/83xx/asp8347_defconfig +++ b/arch/powerpc/configs/83xx/asp8347_defconfig @@ -164,11 +164,9 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y -CONFIG_PPC_CHRP=y # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set -CONFIG_PPC_PMAC=y # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_82xx is not set diff --git a/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig b/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig index 2028337..df125f3 100644 --- a/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig +++ b/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig @@ -163,11 +163,9 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y -CONFIG_PPC_CHRP=y # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set -CONFIG_PPC_PMAC=y # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_82xx is not set diff --git a/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig b/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig index dd80eb0..6e0e08c 100644 --- a/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig +++ b/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig @@ -163,11 +163,9 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y -CONFIG_PPC_CHRP=y # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set -CONFIG_PPC_PMAC=y # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_82xx is not set diff --git a/arch/powerpc/configs/83xx/mpc832x_mds_defconfig b/arch/powerpc/configs/83xx/mpc832x_mds_defconfig index bdf50c8..d6e204a 100644 --- a/arch/powerpc/configs/83xx/mpc832x_mds_defconfig +++ b/arch/powerpc/configs/83xx/mpc832x_mds_defconfig @@ -163,11 +163,9 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y -CONFIG_PPC_CHRP=y # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set -CONFIG_PPC_PMAC=y # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_82xx is not set diff --git a/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig b/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig index 4eef8c9..1f3d343 100644 --- a/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig +++ b/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig @@ -163,11 +163,9 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y -CONFIG_PPC_CHRP=y # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set -CONFIG_PPC_PMAC=y # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_82xx is not set diff --git a/arch/powerpc/configs/83xx/mpc834x_itx_defconfig b/arch/powerpc/configs/83xx/mpc834x_itx_defconfig index 8d65139..4686c21 100644 --- a/arch/powerpc/configs/83xx/mpc834x_itx_defconfig +++ b/arch/powerpc/configs/83xx
[PATCH] powerpc: fix conflict with Elo DMA driver in MPC8610 device tree
The Freescale Elo DMA driver binds to all DMA channels in the device tree that
are compatible with fsl,eloplus-dma-channel. This conflicts with the sound
drivers for the MPC8610. To avoid the conflict, change the compatible property
for the DMA channels needed by the sound drivers to fsl,ssi-dma-channel.
This works because the sound drivers don't actually check the compatible
property when it grabs DMA channels.
Also update dma.txt and ssi.txt with this information.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
Documentation/powerpc/dts-bindings/fsl/dma.txt | 13 +++--
Documentation/powerpc/dts-bindings/fsl/ssi.txt | 12 ++--
arch/powerpc/boot/dts/mpc8610_hpcd.dts |4 ++--
3 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/dma.txt
b/Documentation/powerpc/dts-bindings/fsl/dma.txt
index 86826df..cc45311 100644
--- a/Documentation/powerpc/dts-bindings/fsl/dma.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/dma.txt
@@ -20,7 +20,7 @@ Required properties:
- compatible: compatible list, contains 2 entries, first is
fsl,CHIP-dma-channel, where CHIP is the processor
(mpc8349, mpc8350, etc.) and the second is
-fsl,elo-dma-channel
+fsl,elo-dma-channel. However, see note below.
- reg : registers mapping for channel
- cell-index: dma channel index starts at 0.
@@ -82,7 +82,7 @@ Required properties:
- compatible: compatible list, contains 2 entries, first is
fsl,CHIP-dma-channel, where CHIP is the processor
(mpc8540, mpc8560, etc.) and the second is
-fsl,eloplus-dma-channel
+fsl,eloplus-dma-channel. However, see note below.
- cell-index: dma channel index starts at 0.
- reg : registers mapping for channel
- interrupts: interrupt mapping for DMA channel IRQ
@@ -125,3 +125,12 @@ Example:
interrupts = 17 2;
};
};
+
+Note on DMA channel compatible properties: The compatible property must say
+fsl,elo-dma-channel or fsl,eloplus-dma-channel to be used by the Elo DMA
+driver (fsldma). Any DMA channel used by fsldma cannot be used by another
+DMA driver, such as the SSI sound drivers for the MPC8610. Therefore, any DMA
+channel that should be used for another driver should not use
+fsl,elo-dma-channel or fsl,eloplus-dma-channel. For the SSI drivers, for
+example, the compatible property should be fsl,ssi-dma-channel. See ssi.txt
+for more information.
diff --git a/Documentation/powerpc/dts-bindings/fsl/ssi.txt
b/Documentation/powerpc/dts-bindings/fsl/ssi.txt
index 5d98413..f11ec34 100644
--- a/Documentation/powerpc/dts-bindings/fsl/ssi.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/ssi.txt
@@ -24,10 +24,10 @@ Required properties:
rj-master - r.j., SSI is clock master
ac97-slave - AC97 mode, SSI is clock slave
ac97-master - AC97 mode, SSI is clock master
-- fsl,playback-dma: phandle to a DMA node for the DMA channel to use for
+- fsl,playback-dma: phandle to a node for the DMA channel to use for
playback of audio. This is typically dictated by SOC
design. See the notes below.
-- fsl,capture-dma: phandle to a DMA node for the DMA channel to use for
+- fsl,capture-dma: phandle to a node for the DMA channel to use for
capture (recording) of audio. This is typically dictated
by SOC design. See the notes below.
@@ -51,3 +51,11 @@ playback and DMA channel 1 for capture. SSI2 must use DMA
channel 2 for
playback and DMA channel 3 for capture. The developer can choose which
DMA controller to use, but the channels themselves are hard-wired. The
purpose of these two properties is to represent this hardware design.
+
+The device tree nodes for the DMA channels that are referenced by
+fsl,playback-dma and fsl,capture-dma must be marked as compatible with
+fsl,ssi-dma-channel. The SOC-specific compatible string (e.g.
+fsl,mpc8610-dma-channel) can remain. If these nodes are left as
+fsl,elo-dma-channel or fsl,eloplus-dma-channel, then the generic Elo DMA
+drivers (fsldma) will attempt to use them, and it will conflict with the
+sound drivers.
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 855f70c..f724d72 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -237,7 +237,7 @@
dma00: [EMAIL PROTECTED] {
compatible = fsl,mpc8610-dma-channel,
- fsl,eloplus-dma-channel;
+ fsl,ssi-dma-channel
Re: [PATCH v2] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
Li Yang wrote: -subsys_initcall(of_fsl_dma_chan_init); subsys_initcall(of_fsl_dma_init); Not a critical problem. But module_init() are preferred for modules. This was intentional. When compiled as a module, subsys_initcall becomes module_init(). When compiled in-kernel, this code is initialized before most drivers, so it's ready when the drivers are loaded. Acked-by: Li Yang [EMAIL PROTECTED] Thanks. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
On Thu, Sep 25, 2008 at 1:40 PM, Scott Wood [EMAIL PROTECTED] wrote: If there's a dependency there, how will it work when this is built as a module? There are no dependencies. fsldma registers with the DMA engine, which is always built in-kernel. The DMA engine is what handles linking DMA clients to DMA drivers. The DMA clients get a callback whenever a DMA driver registers with the DMA engine. If the DMA driver is already registered when the client registers, then the client will get a callback immediately after it registers. I chose subsys_initcall() to increase the probability that fsldma is already present when DMA clients are loaded/initialized and register. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
Scott Wood wrote: I chose subsys_initcall() to increase the probability that fsldma is already present when DMA clients are loaded/initialized and register. If there's no dependency, why does it matter whether fsldma is already present? Re-read my explanation, please. Technically, it doesn't *matter* in that nothing will break, but so what? It's nicer if the DMA driver is already available when the client drivers load, so that they can use the DMA facilities right away. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: enforce sane MAX_ORDER
On Wed, Sep 24, 2008 at 9:29 AM, Johannes Berg [EMAIL PROTECTED] wrote: Indeed, it makes little sense to allow you to set more than the address space, so here's a version with max 64. Acked-by: Timur Tabi [EMAIL PROTECTED] However, the max is actually less than 64. Assuming a 64-bit address space, the maximum number of pages in one allocation can be 2^(64-PAGE_SHIFT). For 4KB pages, the max value for FORCE_MAX_ZONEORDER is 53. For 64KB pages, the max is 49. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
Kumar Gala wrote: Dan, any update on this patch? I'm going to post a new version. This whole thing is more complicated than I thought. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
Modify the Freescale Elo / Elo Plus DMA driver so that it can be compiled as
a module.
The primary change is to stop treating the DMA controller as a bus, and the
DMA channels as devices on the bus. This is because the Open Firmware (OF)
kernel code does not allow busses to be removed, so although we can call
of_platform_bus_probe() to probe the DMA channels, there is no
of_platform_bus_remove(). Instead, the DMA channels are manually probed,
similar to what fsl_elbc_nand.c does.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
v2: updated per comments
This patch is for the 2.6.28 kernel. This patch exposes a bug in the dmatest
module, so my other patch dmatest: properly handle duplicate DMA channels
should be applied if this patch is applied.
drivers/dma/Kconfig | 10 ++--
drivers/dma/fsldma.c | 138 --
drivers/dma/fsldma.h |1 +
3 files changed, 94 insertions(+), 55 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index cd30390..904e575 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -48,13 +48,13 @@ config DW_DMAC
can be integrated in chips such as the Atmel AT32ap7000.
config FSL_DMA
- bool Freescale MPC85xx/MPC83xx DMA support
- depends on PPC
+ tristate Freescale Elo and Elo Plus DMA support
+ depends on FSL_SOC
select DMA_ENGINE
---help---
- Enable support for the Freescale DMA engine. Now, it support
- MPC8560/40, MPC8555, MPC8548 and MPC8641 processors.
- The MPC8349, MPC8360 is also supported.
+ Enable support for the Freescale Elo and Elo Plus DMA controllers.
+ The Elo is the DMA controller on some 82xx and 83xx parts, and the
+ Elo Plus is the DMA controller on 85xx and 86xx parts.
config MV_XOR
bool Marvell XOR engine support
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index e9b2638..0b95dcc 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -370,7 +370,10 @@ static int fsl_dma_alloc_chan_resources(struct dma_chan
*chan,
struct dma_client *client)
{
struct fsl_dma_chan *fsl_chan = to_fsl_chan(chan);
- LIST_HEAD(tmp_list);
+
+ /* Has this channel already been allocated? */
+ if (fsl_chan-desc_pool)
+ return 1;
/* We need the descriptor to be aligned to 32bytes
* for meeting FSL DMA specification requirement.
@@ -410,6 +413,8 @@ static void fsl_dma_free_chan_resources(struct dma_chan
*chan)
}
spin_unlock_irqrestore(fsl_chan-desc_lock, flags);
dma_pool_destroy(fsl_chan-desc_pool);
+
+ fsl_chan-desc_pool = NULL;
}
static struct dma_async_tx_descriptor *
@@ -786,33 +791,29 @@ static void dma_do_tasklet(unsigned long data)
fsl_chan_ld_cleanup(fsl_chan);
}
-static int __devinit of_fsl_dma_chan_probe(struct of_device *dev,
- const struct of_device_id *match)
+static int __devinit fsl_dma_chan_probe(struct fsl_dma_device *fdev,
+ struct device_node *node, u32 feature, const char *compatible)
{
- struct fsl_dma_device *fdev;
struct fsl_dma_chan *new_fsl_chan;
int err;
- fdev = dev_get_drvdata(dev-dev.parent);
- BUG_ON(!fdev);
-
/* alloc channel */
new_fsl_chan = kzalloc(sizeof(struct fsl_dma_chan), GFP_KERNEL);
if (!new_fsl_chan) {
- dev_err(dev-dev, No free memory for allocating
+ dev_err(fdev-dev, No free memory for allocating
dma channels!\n);
return -ENOMEM;
}
/* get dma channel register base */
- err = of_address_to_resource(dev-node, 0, new_fsl_chan-reg);
+ err = of_address_to_resource(node, 0, new_fsl_chan-reg);
if (err) {
- dev_err(dev-dev, Can't get %s property 'reg'\n,
- dev-node-full_name);
+ dev_err(fdev-dev, Can't get %s property 'reg'\n,
+ node-full_name);
goto err_no_reg;
}
- new_fsl_chan-feature = *(u32 *)match-data;
+ new_fsl_chan-feature = feature;
if (!fdev-feature)
fdev-feature = new_fsl_chan-feature;
@@ -822,13 +823,13 @@ static int __devinit of_fsl_dma_chan_probe(struct
of_device *dev,
*/
WARN_ON(fdev-feature != new_fsl_chan-feature);
- new_fsl_chan-dev = dev-dev;
+ new_fsl_chan-dev = new_fsl_chan-common.dev;
new_fsl_chan-reg_base = ioremap(new_fsl_chan-reg.start,
new_fsl_chan-reg.end - new_fsl_chan-reg.start + 1);
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,
+ dev_err(fdev-dev, There is no %d channel!\n
[PATCH] powerpc: remove support for bootmem-allocated memory for the DIU driver
Early versions of the Freescale DIU framebuffer driver depended on a bootmem
allocation of memory for the video buffer. The need for this feature was
removed in commit 6b51d51a, so now we can remove the platform-specific code
that allocated that memory.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
This patch is for 2.6.28.
arch/powerpc/platforms/86xx/mpc8610_hpcd.c |1 -
arch/powerpc/sysdev/fsl_soc.c | 38 +---
arch/powerpc/sysdev/fsl_soc.h |8 --
3 files changed, 1 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 5eedb71..e8d54ac 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -238,7 +238,6 @@ static void __init mpc86xx_hpcd_setup_arch(void)
}
#endif
#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
- preallocate_diu_videomemory();
diu_ops.get_pixel_format= mpc8610hpcd_get_pixel_format;
diu_ops.set_gamma_table = mpc8610hpcd_set_gamma_table;
diu_ops.set_monitor_port= mpc8610hpcd_set_monitor_port;
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 214388e..a64a23e 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -767,42 +767,6 @@ void fsl_rstcr_restart(char *cmd)
#endif
#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
-struct platform_diu_data_ops diu_ops = {
- .diu_size = 1280 * 1024 * 4,/* default one 1280x1024 buffer */
-};
+struct platform_diu_data_ops diu_ops;
EXPORT_SYMBOL(diu_ops);
-
-int __init preallocate_diu_videomemory(void)
-{
- pr_debug(diu_size=%lu\n, diu_ops.diu_size);
-
- diu_ops.diu_mem = __alloc_bootmem(diu_ops.diu_size, 8, 0);
- if (!diu_ops.diu_mem) {
- printk(KERN_ERR fsl-diu: cannot allocate %lu bytes\n,
- diu_ops.diu_size);
- return -ENOMEM;
- }
-
- pr_debug(diu_mem=%p\n, diu_ops.diu_mem);
-
- rh_init(diu_ops.diu_rh_info, 4096, ARRAY_SIZE(diu_ops.diu_rh_block),
- diu_ops.diu_rh_block);
- return rh_attach_region(diu_ops.diu_rh_info,
- (unsigned long) diu_ops.diu_mem,
- diu_ops.diu_size);
-}
-
-static int __init early_parse_diufb(char *p)
-{
- if (!p)
- return 1;
-
- diu_ops.diu_size = _ALIGN_UP(memparse(p, p), 8);
-
- pr_debug(diu_size=%lu\n, diu_ops.diu_size);
-
- return 0;
-}
-early_param(diufb, early_parse_diufb);
-
#endif
diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h
index 0242998..60f7f22 100644
--- a/arch/powerpc/sysdev/fsl_soc.h
+++ b/arch/powerpc/sysdev/fsl_soc.h
@@ -20,14 +20,7 @@ extern int fsl_spi_init(struct spi_board_info *board_infos,
extern void fsl_rstcr_restart(char *cmd);
#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
-#include linux/bootmem.h
-#include asm/rheap.h
struct platform_diu_data_ops {
- rh_block_t diu_rh_block[16];
- rh_info_t diu_rh_info;
- unsigned long diu_size;
- void *diu_mem;
-
unsigned int (*get_pixel_format) (unsigned int bits_per_pixel,
int monitor_port);
void (*set_gamma_table) (int monitor_port, char *gamma_table_base);
@@ -38,7 +31,6 @@ struct platform_diu_data_ops {
};
extern struct platform_diu_data_ops diu_ops;
-int __init preallocate_diu_videomemory(void);
#endif
#endif
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Merge linuxppc-embedded with linuxppc-dev
I also vote to kill the separate embedded list. It has such low traffic, and it seems like a lot of messages end up cross-posted to linuxppc-dev, anyway. I also agree that we should kill linuxppc-embedded. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc: Fix Book-E watchdog timer interval setting
On Tue, Sep 23, 2008 at 10:04 AM, Matthias Fuchs [EMAIL PROTECTED] wrote: #ifdef CONFIG_FSL_BOOKE #define WDTP(x)63-x)0x3)30)|(((63-x)0x3c)15)) +#define WDTP_MASK (WDTP(63)) WDTP(63) is 63-63)0x3)30)|(((63-63)0x3c)15)), which is equal to 0. Shouldn't WDTP_MASK be equal to (3 30) | (15 15)? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fsldma: remove internal self-test from Freescale Elo DMA driver
The Freescale Elo DMA driver runs an internal self-test before registering
the channels with the DMA engine. This self-test has a fundemental flaw in
that it calls the DMA engine's callback functions directly before the
registration. However, the registration initializes some variables that the
callback functions uses, namely the device struct.
The code works today because there are two device structs: the one created
by the DMA engine, and one created by the Open Firmware (OF) subsystem. The
self-test currently uses the device struct created by OF. However, in the
future, some of the device structs created by OF will be eliminated.
This means that the self-test will only have access to the device struct
created by the DMA engine. But this device struct isn't initialized when
the self-test runs, and this causes a kernel panic.
Since there is already a DMA test module (dmatest), the internal self-test
code is not useful anyway. It is extremely unlikely that the test will fail
in normal usage. It may have been helpful during development, but not any more.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
This patch is for 2.6.28.
drivers/dma/fsldma.c | 132 --
1 files changed, 0 insertions(+), 132 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index c0059ca..e9b2638 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -786,132 +786,6 @@ static void dma_do_tasklet(unsigned long data)
fsl_chan_ld_cleanup(fsl_chan);
}
-static void fsl_dma_callback_test(void *param)
-{
- struct fsl_dma_chan *fsl_chan = param;
- if (fsl_chan)
- dev_dbg(fsl_chan-dev, selftest: callback is ok!\n);
-}
-
-static int fsl_dma_self_test(struct fsl_dma_chan *fsl_chan)
-{
- struct dma_chan *chan;
- int err = 0;
- dma_addr_t dma_dest, dma_src;
- dma_cookie_t cookie;
- u8 *src, *dest;
- int i;
- size_t test_size;
- struct dma_async_tx_descriptor *tx1, *tx2, *tx3;
-
- test_size = 4096;
-
- src = kmalloc(test_size * 2, GFP_KERNEL);
- if (!src) {
- dev_err(fsl_chan-dev,
- selftest: Cannot alloc memory for test!\n);
- return -ENOMEM;
- }
-
- dest = src + test_size;
-
- for (i = 0; i test_size; i++)
- src[i] = (u8) i;
-
- chan = fsl_chan-common;
-
- if (fsl_dma_alloc_chan_resources(chan, NULL) 1) {
- dev_err(fsl_chan-dev,
- selftest: Cannot alloc resources for DMA\n);
- err = -ENODEV;
- goto out;
- }
-
- /* TX 1 */
- dma_src = dma_map_single(fsl_chan-dev, src, test_size / 2,
-DMA_TO_DEVICE);
- dma_dest = dma_map_single(fsl_chan-dev, dest, test_size / 2,
- DMA_FROM_DEVICE);
- tx1 = fsl_dma_prep_memcpy(chan, dma_dest, dma_src, test_size / 2, 0);
- async_tx_ack(tx1);
-
- cookie = fsl_dma_tx_submit(tx1);
- fsl_dma_memcpy_issue_pending(chan);
- msleep(2);
-
- if (fsl_dma_is_complete(chan, cookie, NULL, NULL) != DMA_SUCCESS) {
- dev_err(fsl_chan-dev, selftest: Time out!\n);
- err = -ENODEV;
- goto free_resources;
- }
-
- /* Test free and re-alloc channel resources */
- fsl_dma_free_chan_resources(chan);
-
- if (fsl_dma_alloc_chan_resources(chan, NULL) 1) {
- dev_err(fsl_chan-dev,
- selftest: Cannot alloc resources for DMA\n);
- err = -ENODEV;
- goto free_resources;
- }
-
- /* Continue to test
-* TX 2
-*/
- dma_src = dma_map_single(fsl_chan-dev, src + test_size / 2,
- test_size / 4, DMA_TO_DEVICE);
- dma_dest = dma_map_single(fsl_chan-dev, dest + test_size / 2,
- test_size / 4, DMA_FROM_DEVICE);
- tx2 = fsl_dma_prep_memcpy(chan, dma_dest, dma_src, test_size / 4, 0);
- async_tx_ack(tx2);
-
- /* TX 3 */
- dma_src = dma_map_single(fsl_chan-dev, src + test_size * 3 / 4,
- test_size / 4, DMA_TO_DEVICE);
- dma_dest = dma_map_single(fsl_chan-dev, dest + test_size * 3 / 4,
- test_size / 4, DMA_FROM_DEVICE);
- tx3 = fsl_dma_prep_memcpy(chan, dma_dest, dma_src, test_size / 4, 0);
- async_tx_ack(tx3);
-
- /* Interrupt tx test */
- tx1 = fsl_dma_prep_interrupt(chan, 0);
- async_tx_ack(tx1);
- cookie = fsl_dma_tx_submit(tx1);
-
- /* Test exchanging the prepared tx sort */
- cookie = fsl_dma_tx_submit(tx3);
- cookie = fsl_dma_tx_submit(tx2);
-
- if (dma_has_cap(DMA_INTERRUPT, ((struct fsl_dma_device *)
- dev_get_drvdata(fsl_chan-dev-parent
[PATCH] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
Modify the Freescale Elo / Elo Plus DMA driver so that it can be compiled as
a module.
The primary change is to stop treating the DMA controller as a bus, and the
DMA channels as devices on the bus. This is because the Open Firmware (OF)
kernel code does not allow busses to be removed, so although we can call
of_platform_bus_probe() to probe the DMA channels, there is no
of_platform_bus_remove(). Therefore, the DMA channels must be manually probed.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
(Reposting because I forgot to CC: the maintainers)
This patch is for the 2.6.28 kernel. This patch exposes a bug in the dmatest
module, so my other patch dmatest: properly handle duplicate DMA channels
should be applied if this patch is applied.
drivers/dma/Kconfig | 10 ++--
drivers/dma/fsldma.c | 165 ++
drivers/dma/fsldma.h |2 +
3 files changed, 119 insertions(+), 58 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index cd30390..9dfd502 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -48,13 +48,13 @@ config DW_DMAC
can be integrated in chips such as the Atmel AT32ap7000.
config FSL_DMA
- bool Freescale MPC85xx/MPC83xx DMA support
- depends on PPC
+ tristate Freescale Elo and Elo Plus DMA support
+ depends on PPC_83xx || PPC_85xx || PPC_86xx
select DMA_ENGINE
---help---
- Enable support for the Freescale DMA engine. Now, it support
- MPC8560/40, MPC8555, MPC8548 and MPC8641 processors.
- The MPC8349, MPC8360 is also supported.
+ Enable support for the Freescale Elo and Elo Plus DMA controllers.
+ The Elo is the DMA controller on 83xx parts, and the Elo Plus is
+ the DMA controller on 85xx and 86xx parts.
config MV_XOR
bool Marvell XOR engine support
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index c0059ca..327c485 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -372,6 +372,10 @@ static int fsl_dma_alloc_chan_resources(struct dma_chan
*chan,
struct fsl_dma_chan *fsl_chan = to_fsl_chan(chan);
LIST_HEAD(tmp_list);
+ /* Has this channel already been allocated? */
+ if (fsl_chan-desc_pool)
+ return 1;
+
/* We need the descriptor to be aligned to 32bytes
* for meeting FSL DMA specification requirement.
*/
@@ -381,7 +385,7 @@ static int fsl_dma_alloc_chan_resources(struct dma_chan
*chan,
if (!fsl_chan-desc_pool) {
dev_err(fsl_chan-dev, No memory for channel %d
descriptor dma pool.\n, fsl_chan-id);
- return 0;
+ return -ENOMEM;
}
return 1;
@@ -410,6 +414,8 @@ static void fsl_dma_free_chan_resources(struct dma_chan
*chan)
}
spin_unlock_irqrestore(fsl_chan-desc_lock, flags);
dma_pool_destroy(fsl_chan-desc_pool);
+
+ fsl_chan-desc_pool = NULL;
}
static struct dma_async_tx_descriptor *
@@ -912,33 +918,37 @@ out:
return err;
}
-static int __devinit of_fsl_dma_chan_probe(struct of_device *dev,
- const struct of_device_id *match)
+static int __devinit fsl_dma_chan_probe(struct fsl_dma_device *fdev,
+ struct device_node *node, u32 feature, const char *compatible)
{
- struct fsl_dma_device *fdev;
struct fsl_dma_chan *new_fsl_chan;
+ const u32 *iprop;
int err;
- fdev = dev_get_drvdata(dev-dev.parent);
- BUG_ON(!fdev);
-
/* alloc channel */
new_fsl_chan = kzalloc(sizeof(struct fsl_dma_chan), GFP_KERNEL);
if (!new_fsl_chan) {
- dev_err(dev-dev, No free memory for allocating
+ dev_err(fdev-dev, No free memory for allocating
dma channels!\n);
return -ENOMEM;
}
+ new_fsl_chan-of_dev = of_platform_device_create(node, NULL, fdev-dev);
+ if (!new_fsl_chan-of_dev) {
+ dev_err(fdev-dev, cannot create platform device\n);
+ err = -EINVAL;
+ goto err_no_dev;
+ }
+
/* get dma channel register base */
- err = of_address_to_resource(dev-node, 0, new_fsl_chan-reg);
+ err = of_address_to_resource(node, 0, new_fsl_chan-reg);
if (err) {
- dev_err(dev-dev, Can't get %s property 'reg'\n,
- dev-node-full_name);
+ dev_err(fdev-dev, Can't get %s property 'reg'\n,
+ node-full_name);
goto err_no_reg;
}
- new_fsl_chan-feature = *(u32 *)match-data;
+ new_fsl_chan-feature = feature;
if (!fdev-feature)
fdev-feature = new_fsl_chan-feature;
@@ -948,17 +958,22 @@ static int __devinit of_fsl_dma_chan_probe(struct
of_device *dev,
*/
WARN_ON(fdev-feature != new_fsl_chan-feature
Re: [git pull] Please pull powerpc.git merge branch
On Thu, Sep 18, 2008 at 11:36 AM, Paul Mackerras [EMAIL PROTECTED] wrote: powerpc: Fix interrupt values for DMA2 in MPC8610 HPCD device tree For Freescale 8xxx devices that use an MPIC, the interrupt numbers in the device tree must be 16 greater than the values documented in the reference manual. In these chips, the MPIC is wired to use the first 16 numbers for external interrupts, but the documentation numbers internal interrupts from 0. In the MPC8610 HPCD device tree, the interrupt properties for the DMA channels for DMA2 were not the adjusted values. This fixes that. Did you edit this patch when you pulled it from Kumar's repo? The commit in Kumar's repo says This patch fixes that., which is what I wrote. However, in your tree, the word patch is missing. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2] Pass actual dev ptr to dma_* in ucc and cpm_uart serial
On Fri, Sep 12, 2008 at 10:42 AM, Becky Bruce [EMAIL PROTECTED] wrote: Signed-off-by: Becky Bruce [EMAIL PROTECTED] Acked-By: Timur Tabi [EMAIL PROTECTED] The changelog could be a little beefier, though. I'm not a fan of having the changelog be an extension of the patch title. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Pass actual dev ptr to dma_* in ucc and cpm_uart serial
On Mon, Sep 8, 2008 at 2:56 PM, Scott Wood [EMAIL PROTECTED] wrote: This patch doesn't change that for cpm2, since port.dev is never initialized. :-P I don't initialize port-dev in the UCC UART driver, but it's still non-zero, so why isn't it initialized in the CPM UART driver? (P.S. Becky - please CC: me on any UCC UART or QE LIB patches) -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: fix interrupt values for DMA2 in MPC8610 HPCD device tree
The interrupt values in a device tree must be 16 greater than the actual
interrupt number for a given device. The interrupt property for the DMA
channels for DMA2 in the MPC8610 HPCD device tree was using the raw values,
not the adjusted ones.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
Kumar, I have no idea how this was missed for so long, but this patch is a
must-fix for 2.6.27.
arch/powerpc/boot/dts/mpc8610_hpcd.dts |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 3b3a106..584a4f1 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -281,7 +281,7 @@
cell-index = 0;
reg = 0x0 0x80;
interrupt-parent = mpic;
- interrupts = 60 2;
+ interrupts = 76 2;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8610-dma-channel,
@@ -289,7 +289,7 @@
cell-index = 1;
reg = 0x80 0x80;
interrupt-parent = mpic;
- interrupts = 61 2;
+ interrupts = 77 2;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8610-dma-channel,
@@ -297,7 +297,7 @@
cell-index = 2;
reg = 0x100 0x80;
interrupt-parent = mpic;
- interrupts = 62 2;
+ interrupts = 78 2;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8610-dma-channel,
@@ -305,7 +305,7 @@
cell-index = 3;
reg = 0x180 0x80;
interrupt-parent = mpic;
- interrupts = 63 2;
+ interrupts = 79 2;
};
};
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: fix interrupt values for DMA2 in MPC8610 HPCD device tree
For Freescale 8xxx devices that use an MPIC, the interrupt numbers in the
device tree must be 16 greater than the values documented in the reference
manual. In these chips, the MPIC is wired to use the first 16 numbers for
external interrupts, but the documentation numbers internal interrupts from 0.
In the MPC8610 HPCD device tree, the interrupt properties for the DMA channels
for DMA2 were not the adjusted values. This patch fixes that.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
I have no idea how this was missed for so long, but this patch is a
must-fix for 2.6.27.
(changes for v2: improve changelog text)
arch/powerpc/boot/dts/mpc8610_hpcd.dts |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 3b3a106..584a4f1 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -281,7 +281,7 @@
cell-index = 0;
reg = 0x0 0x80;
interrupt-parent = mpic;
- interrupts = 60 2;
+ interrupts = 76 2;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8610-dma-channel,
@@ -289,7 +289,7 @@
cell-index = 1;
reg = 0x80 0x80;
interrupt-parent = mpic;
- interrupts = 61 2;
+ interrupts = 77 2;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8610-dma-channel,
@@ -297,7 +297,7 @@
cell-index = 2;
reg = 0x100 0x80;
interrupt-parent = mpic;
- interrupts = 62 2;
+ interrupts = 78 2;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8610-dma-channel,
@@ -305,7 +305,7 @@
cell-index = 3;
reg = 0x180 0x80;
interrupt-parent = mpic;
- interrupts = 63 2;
+ interrupts = 79 2;
};
};
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add SSI-to-DMA properties to Freescale MPC8610 HPCD device tree
On Wed, Aug 6, 2008 at 11:48 AM, Timur Tabi [EMAIL PROTECTED] wrote: Add the fsl,playback-dma and fsl,capture-dma properties to the Freescale MPC8610 HPCD device tree. These properties connect the SSI nodes to the DMA nodes for the DMA channels that the SSI should use. Also update the ssi.txt documentation. These properties will be needed when the ASoC V2 version of the Freescale MPC8610 device drivers are merged into the mainline. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- Kumar, any thoughts on this patch? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix memory leaks in QE library
On Wed, Aug 20, 2008 at 1:38 AM, Tony Breeds [EMAIL PROTECTED] wrote: It's been pointed out in http://bugzilla.kernel.org/show_bug.cgi?id=11371 that ucc_slow suffers from the same (welll clsoe enough) 2 problems. Care to fix them aswell? Sure. I'll do a sweep o the QE code just to make sure there aren't even more. Of course, it would have been nice if someone had looked up the maintainer of the QE library in the MAINTAINERS file and notified me about these bugs. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: fix memory leaks in QE library
Fix two memory leaks in the Freescale QE library: add a missing kfree() in
ucc_fast_init() and ucc_slow_init() if the ioremap() fails, and update
ucc_fast_free() and ucc_slow_free() to call iounmap() if necessary.
Based on a patch from Tony Breeds [EMAIL PROTECTED].
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
arch/powerpc/sysdev/qe_lib/ucc_fast.c |4
arch/powerpc/sysdev/qe_lib/ucc_slow.c |8 +---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index 1aecb07..25fbbfa 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -208,6 +208,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct
ucc_fast_private ** ucc
uccf-uf_regs = ioremap(uf_info-regs, sizeof(struct ucc_fast));
if (uccf-uf_regs == NULL) {
printk(KERN_ERR %s: Cannot map UCC registers\n, __func__);
+ kfree(uccf);
return -ENOMEM;
}
@@ -355,6 +356,9 @@ void ucc_fast_free(struct ucc_fast_private * uccf)
if (uccf-ucc_fast_rx_virtual_fifo_base_offset)
qe_muram_free(uccf-ucc_fast_rx_virtual_fifo_base_offset);
+ if (uccf-uf_regs)
+ iounmap(uccf-uf_regs);
+
kfree(uccf);
}
EXPORT_SYMBOL(ucc_fast_free);
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_slow.c
b/arch/powerpc/sysdev/qe_lib/ucc_slow.c
index a578bc7..e1d6a13 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_slow.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_slow.c
@@ -171,6 +171,7 @@ int ucc_slow_init(struct ucc_slow_info * us_info, struct
ucc_slow_private ** ucc
uccs-us_regs = ioremap(us_info-regs, sizeof(struct ucc_slow));
if (uccs-us_regs == NULL) {
printk(KERN_ERR %s: Cannot map UCC registers\n, __func__);
+ kfree(uccs);
return -ENOMEM;
}
@@ -367,10 +368,11 @@ void ucc_slow_free(struct ucc_slow_private * uccs)
if (uccs-tx_base_offset)
qe_muram_free(uccs-tx_base_offset);
- if (uccs-us_pram) {
+ if (uccs-us_pram)
qe_muram_free(uccs-us_pram_offset);
- uccs-us_pram = NULL;
- }
+
+ if (uccs-us_regs)
+ iounmap(uccs-us_regs);
kfree(uccs);
}
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: fix memory leaks in QE library
Fix two memory leaks in the Freescale QE library: add a missing kfree() in
ucc_fast_init() if the ioremap() fails, and update ucc_fast_free() to call
iounmap() on uf_regs.
Based on a patch from Tony Breeds [EMAIL PROTECTED].
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
arch/powerpc/sysdev/qe_lib/ucc_fast.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index 1aecb07..25fbbfa 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -208,6 +208,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct
ucc_fast_private ** ucc
uccf-uf_regs = ioremap(uf_info-regs, sizeof(struct ucc_fast));
if (uccf-uf_regs == NULL) {
printk(KERN_ERR %s: Cannot map UCC registers\n, __func__);
+ kfree(uccf);
return -ENOMEM;
}
@@ -355,6 +356,9 @@ void ucc_fast_free(struct ucc_fast_private * uccf)
if (uccf-ucc_fast_rx_virtual_fifo_base_offset)
qe_muram_free(uccf-ucc_fast_rx_virtual_fifo_base_offset);
+ if (uccf-uf_regs)
+ iounmap(uccf-uf_regs);
+
kfree(uccf);
}
EXPORT_SYMBOL(ucc_fast_free);
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2] DTC: Remove support for the legacy DTS source file format.
On Thu, Aug 14, 2008 at 7:29 PM, David Gibson [EMAIL PROTECTED] wrote: On Thu, Aug 14, 2008 at 06:02:43PM -0500, Jon Loeliger wrote: Now that all in-kernel-tree DTS files are properly /dts-v1/, remove direct support for the older, un-numbered DTS source file format. Um.. why? I just don't see a compelling reason to remove this backwards compatibility. It costs us very little to keep it around indefinitely. I agree, why are we removing backwards compatibility? The dts-v1 format isn't that old, so I'm sure there are plenty of device trees out there, especially on our BSPs, that haven't been updated yet. How about just printing a warning and saying that the device tree should be updated with the conversion tool? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
Grant Likely wrote: So, seeing as settling on a way to determine stdout still up in the air, it probably makes sense to condense that code down to a single authoritative function so that changes in this area are contained in one place. For now, I'll stick with decoding linux,stdout-path and on Sparc decoding the ihandle with the expectation that there will be further refinements to be made. Ack. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
Yoder Stuart wrote: The second was the idea that we may need a /aliases/stdin as well. You could conceptually have stdout be a monitor and a stdin be a keyboard. I don't think the hypervisor console subsystem supports this. I don't see any way of registering separate clients for input vs. output. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
Milton Miller wrote: Why should what the hvc driver support have any effect on what the binding should be? Because my hypervisor console driver uses the hypervisor console/tty subsystem. If the subsystem assumes one stdout/stdin device, then I must abide by that. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] usb: add Freescale QE/CPM USB peripheral controller driver
On Wed, Aug 6, 2008 at 2:16 AM, Li Yang [EMAIL PROTECTED] wrote: +/*- + * Mask definitions for usb BD * + **/ +#define QE_SIZEOF_BD sizeof(struct qe_bd) + +#define BD_BUFFER_ARG(bd) (((struct qe_bd *)bd)-buf) +#define BD_BUFFER_CLEAR(bd) out_be32((BD_BUFFER_ARG(bd)), 0); +#define BD_BUFFER(bd) in_be32((BD_BUFFER_ARG(bd))) +#define BD_STATUS_AND_LENGTH_SET(bd, val) out_be32((u32 *)bd, val) +#define BD_STATUS_AND_LENGTH(bd)in_be32((u32 *)bd) +#define BD_BUFFER_SET(bd, buffer) out_be32((BD_BUFFER_ARG(bd)), \ + (u32)(buffer)) Delete all of these. Don't use these silly macros at all. Reference the structure fields directly, and use the in_ and out_ functions directly. Using macros like these encourages unnecessary typecasts. struct qe_bd has been defined, so you should use it. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
On Wed, Aug 6, 2008 at 1:02 AM, Grant Likely [EMAIL PROTECTED] wrote: From: Grant Likely [EMAIL PROTECTED] of_lookup_stdout() is useful for figuring out what device to use as output for early boot progress messages. It returns the node pointed to by the linux,stdout-path property in the chosen node. I thought linux,stdout-path is deprecated are we're supposed to be using the aliases node instead? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: add SSI-to-DMA properties to Freescale MPC8610 HPCD device tree
Add the fsl,playback-dma and fsl,capture-dma properties to the Freescale
MPC8610 HPCD device tree. These properties connect the SSI nodes to the
DMA nodes for the DMA channels that the SSI should use. Also update the
ssi.txt documentation.
These properties will be needed when the ASoC V2 version of the Freescale
MPC8610 device drivers are merged into the mainline.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
Documentation/powerpc/dts-bindings/fsl/ssi.txt | 15 +++
arch/powerpc/boot/dts/mpc8610_hpcd.dts |8 +---
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/ssi.txt
b/Documentation/powerpc/dts-bindings/fsl/ssi.txt
index d100555..5d98413 100644
--- a/Documentation/powerpc/dts-bindings/fsl/ssi.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/ssi.txt
@@ -24,6 +24,12 @@ Required properties:
rj-master - r.j., SSI is clock master
ac97-slave - AC97 mode, SSI is clock slave
ac97-master - AC97 mode, SSI is clock master
+- fsl,playback-dma: phandle to a DMA node for the DMA channel to use for
+ playback of audio. This is typically dictated by SOC
+ design. See the notes below.
+- fsl,capture-dma: phandle to a DMA node for the DMA channel to use for
+ capture (recording) of audio. This is typically dictated
+ by SOC design. See the notes below.
Optional properties:
- codec-handle : phandle to a 'codec' node that defines an audio
@@ -36,3 +42,12 @@ Child 'codec' node required properties:
Child 'codec' node optional properties:
- clock-frequency : The frequency of the input clock, which typically
comes from an on-board dedicated oscillator.
+
+Notes on fsl,playback-dma and fsl,capture-dma:
+
+On SOCs that have an SSI, specific DMA channels are hard-wired for playback
+and capture. On the MPC8610, for example, SSI1 must use DMA channel 0 for
+playback and DMA channel 1 for capture. SSI2 must use DMA channel 2 for
+playback and DMA channel 3 for capture. The developer can choose which
+DMA controller to use, but the channels themselves are hard-wired. The
+purpose of these two properties is to represent this hardware design.
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 666185f..2a2b84f 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -202,7 +202,7 @@
fsl,has-rstcr;
};
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
compatible = fsl,mpc8610-ssi;
cell-index = 0;
reg = 0x16000 0x100;
@@ -210,6 +210,8 @@
interrupts = 62 2;
fsl,mode = i2s-slave;
codec-handle = cs4270;
+ fsl,playback-dma = dma00;
+ fsl,capture-dma = dma01;
};
[EMAIL PROTECTED] {
@@ -228,7 +230,7 @@
reg = 0x21300 0x4; /* DMA general status register */
ranges = 0x0 0x21100 0x200;
- [EMAIL PROTECTED] {
+ dma00: [EMAIL PROTECTED] {
compatible = fsl,mpc8610-dma-channel,
fsl,eloplus-dma-channel;
cell-index = 0;
@@ -236,7 +238,7 @@
interrupt-parent = mpic;
interrupts = 20 2;
};
- [EMAIL PROTECTED] {
+ dma01: [EMAIL PROTECTED] {
compatible = fsl,mpc8610-dma-channel,
fsl,eloplus-dma-channel;
cell-index = 1;
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
On Thu, Jul 31, 2008 at 6:32 PM, Trent Piepho [EMAIL PROTECTED] wrote: The real problem, which kept me from making a patch to do this months ago, is that the source clock that the I2C freq divider applies to is different for just about every MPC8xxx platform. Not just a different value, but a totally different internal clock. Sometimes is CCB, sometimes CCB/2, sometimes tsec2's clock, etc. On which SOC is it the tesc2 clock? Sometimes the two i2c controllers don't even have the same clock. On which platform is that the case? I thought I had all 8[356]xx boards covered. Did I miss some? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
On Thu, Jul 31, 2008 at 9:35 PM, Jon Smirl [EMAIL PROTECTED] wrote: I've having trouble with whether these clocks are a system resource or something that belongs to i2c. If they are a system resource then we should make nodes in the root and use a phandle in the i2c node to link to them. I can't speak for 52xx, but for 8[356]xx, I would say the clocks belong to the I2C devices. The screwball determination of whether to divide by 1, 2, or 3 only applies to the I2C device only. The divider itself is not used to drive a clock for any other device. If you disable I2C support, then you don't need to care about the divider (or its output clock) at all. That's why I think have the I2C clock in the parent node is wrong, because it would only be used if you had I2C child nodes. If you didn't have any I2C nodes, then you would need to delete the property from the parent node as well. The phandle in the mpc5200 case could be implicit since it is fixed in silicon. If we want to use the same I2C driver for 52xx and 83xx, it shouldn't be implicit. Otherwise, the driver will have to check the platform to determine where to look. Is this register in a system register bank or an i2c one? gur-pordevsr2 MPC85xx_PORDEVSR2_SEC_CFG That should be guts- I think. The global utilities is a block of miscellaneous registers, one per SOC. It's not part of the I2C block. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Jon Smirl wrote: What about the Efika which is mpc5200 based and doesn't use uboot? How does the Efika handle the dozen other properties that U-Boot normally initializes in the device tree? -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Trent Piepho wrote: All 83xx other than 832x. Never mind, I forgot that 83xx support for i2c1_clk was already in U-Boot: #if defined(CONFIG_MPC834X) i2c1_clk = tsec2_clk; #elif defined(CONFIG_MPC8360) i2c1_clk = csb_clk; #elif defined(CONFIG_MPC832X) i2c1_clk = enc_clk; #elif defined(CONFIG_MPC831X) i2c1_clk = enc_clk; #elif defined(CONFIG_MPC837X) i2c1_clk = sdhc_clk; #endif #if !defined(CONFIG_MPC832X) i2c2_clk = csb_clk; /* i2c-2 clk is equal to csb clk */ #endif -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Jon Smirl wrote: Aren't the tables in the manual there just to make it easy for a human to pick out the line they want? For a computer you'd program the formula that was used to create the tables. Actually, the tables in the manuals are just an example of what can be programmed. They don't cover all cases. The tables assume a specific value of DFSR. For 8xxx, you want to use AN2919 to figure out how to really program the device. The table I generated for U-Boot is based on the calculations outlined in AN2919. I debated trying to implement the actual algorithm, but decided that pre-calculating the values was better. The algorithm is very convoluted. I agree that it took me half an hour to figure out the formula that was needed to compute the i2s clocks, but once you figure out the formula it solves all of the cases and no one needs to read the manual any more. The i2c formula may even need a small loop which compares different solutions looking for the smallest error term. But it's a small space to search. My understanding is that the algorithm itself is different on 8xxx vs. 52xx. It might be possible to combine 5200A and 5200B into one table/algorithm, but I don't think you can combine it with the 8xxx table. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Grant Likely wrote:
static const struct of_device_id mpc_i2c_of_match[] = {
{.compatible = fsl,mpc5200b-i2c, .data = fsl_i2c_mpc5200b_set_freq, },
{.compatible = fsl,mpc5200-i2c, .data = fsl_i2c_mpc5200_set_freq, },
{.compatible = fsl,mpc8260-i2c, .data = fsl_i2c_mpc8xxx_set_freq, },
{.compatible = fsl,mpc8349-i2c, .data = fsl_i2c_mpc8xxx_set_freq, },
{.compatible = fsl,mpc8540-i2c, .data = fsl_i2c_mpc8xxx_set_freq, },
{.compatible = fsl,mpc8543-i2c, .data =
fsl_i2c_mpc8xxx_div2_set_freq, },
{.compatible = fsl,mpc8544-i2c, .data =
fsl_i2c_mpc8xxx_div3_set_freq, },
So we need to update this table every time there's a new SOC? All 83xx, 85xx,
and 86xx SOCs use the same table. I'd prefer an implementation that does need a
specific entry for each variant of 8[356]xx.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Wolfgang Grandegger wrote: We could add a property source-clock-divider = 2/3 if it's needed!? How about we just get U-Boot to put the core frequency in the device tree? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Grant Likely wrote: On Thu, Jul 31, 2008 at 12:07 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote: We could add a property source-clock-divider = 2/3 if it's needed!? fsl,source-clock-divider But, yes, this is a good solution (assuming that it is a board or SoC characteristic, and not just a choice that the driver has the option of making on it's own). I was going to suggest the actual clock frequency of the I2C device. It would be value of gd-i2c1_clk or gd-i2c2_clk from U-Boot. The actual divider value is meaningless. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Grant Likely wrote: This is a solved problem. The device tree simple claims compatibility with an older part that has the identical register-level interface. That would assume that the clock frequency is the only thing that decides compatibility, which may technically be true now, but I don't think it's a good idea. I don't understand what's wrong with simply specifying the actual clock frequency that the device uses? It varies from SOC to SOC, but U-Boot calculates today already: #if defined(CONFIG_MPC8540) || defined(CONFIG_MPC8541) || \ defined(CONFIG_MPC8560) || defined(CONFIG_MPC8555) gd-i2c1_clk = sys_info.freqSystemBus; #elif defined(CONFIG_MPC8544) /* * On the 8544, the I2C clock is the same as the SEC clock. This can be * either CCB/2 or CCB/3, depending on the value of cfg_sec_freq. See * 4.4.3.3 of the 8544 RM. Note that this might actually work for all * 85xx, but only the 8544 has cfg_sec_freq, so it's unknown if the * PORDEVSR2_SEC_CFG bit is 0 on all 85xx boards that are not an 8544. */ if (gur-pordevsr2 MPC85xx_PORDEVSR2_SEC_CFG) gd-i2c1_clk = sys_info.freqSystemBus / 3; else gd-i2c1_clk = sys_info.freqSystemBus / 2; #else /* Most 85xx SOCs use CCB/2, so this is the default behavior. */ gd-i2c1_clk = sys_info.freqSystemBus / 2; #endif gd-i2c2_clk = gd-i2c1_clk; We need this ugliness in U-Boot. Let's take advantage of this and do something clean and elegant in the device tree. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Jon Smirl wrote:
The existence of the dfsrr and fsl,mpc5200-i2c attributes imply to me
that the compatible strings were not done correctly. If these devices
really were compatible we wouldn't need extra attributes to tell them
apart.
I agree with that.
So I'm with Grant on adding compatible strings sufficient to remove
the need for dfsrr and fsl,mpc5200-i2c.
Let's just make sure we don't break backwards compatibility.
Something like...
static const struct of_device_id mpc_i2c_of_match[] = {
{.compatible = fsl,mpc5200b-i2c, .data = fsl_i2c_mpc5200, },
{.compatible = fsl,mpc5200-i2c, .data = fsl_i2c_mpc5200, },
{.compatible = fsl,mpc8xxx-i2c, .data = fsl_i2c_dfsrr, },
That seems ok.
As for the source clock, how about creating a new global like
ppc_proc_freq called ppc_ipb_freq. The platform code can then set the
right clock value into the variable. For mpc8 get it from uboot.
mpc5200 can easily compute it from ppc_proc_freq and checking how the
ipb divider is set. That will move the clock problem out of the i2c
driver.
I don't want to differentiate between 52xx and 8xxx any more than we have to.
If 8xxx has the clock frequency in the device tree, then 52xx should have it
there, too.
For backwards compatibility purposes, we can have the driver provide a
hard-coded value of some kind if the property does not exist.
I'd like to move towards a more generic uboot that gets the processor
minimally running and then use the device tree to customize as many
things as possible. But that's just my opinion.
U-Boot needs to configure the I2C bus speed because U-Boot uses the I2C. We
should capitalize on that by taking the information that U-Boot has calculated
and re-use it.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Scott Wood wrote: Timur Tabi wrote: Grant Likely wrote: No it doesn't, it depends on the register interface to decide compatibility. Clock interface is part of that. I don't think so. The interface for programming the clock registers is identical on all 8[356]xx parts. The only thing that matters is what specific values to put in the FDR and DFSR registers to get a desired I2C bus speed. If it affects the values you need to write to the registers to achieve a given result, how is it not a difference in the register interface? I think we're splitting hairs, here. The code for actually programming the registers is the same, regardless of the input frequency. It's just that the input frequency is a value needed to calculate the right value. But like I said, I don't think this distinction is that relevant. A clock-frequency property is OK, and is in line with what we do in other types of nodes. However, in the long run it might be nice to introduce some sort of clock binding where, for example, the i2c node can point to a clock elsewhere in the device tree as an input clock. The only problem with that is that the actual input clock to the I2C device is not the same as any other device. It's a unique clock. Look at the code I had to write to figure out this clock just on 85xx: /* * The base clock for I2C depends on the actual SOC. Unfortunately, * there is no pattern that can be used to determine the frequency, so * the only choice is to look up the actual SOC number and use the value * for that SOC. This information is taken from application note * AN2919. */ #if defined(CONFIG_MPC8540) || defined(CONFIG_MPC8541) || \ defined(CONFIG_MPC8560) || defined(CONFIG_MPC8555) gd-i2c1_clk = sys_info.freqSystemBus; #elif defined(CONFIG_MPC8544) /* * On the 8544, the I2C clock is the same as the SEC clock. This can be * either CCB/2 or CCB/3, depending on the value of cfg_sec_freq. See * 4.4.3.3 of the 8544 RM. Note that this might actually work for all * 85xx, but only the 8544 has cfg_sec_freq, so it's unknown if the * PORDEVSR2_SEC_CFG bit is 0 on all 85xx boards that are not an 8544. */ if (gur-pordevsr2 MPC85xx_PORDEVSR2_SEC_CFG) gd-i2c1_clk = sys_info.freqSystemBus / 3; else gd-i2c1_clk = sys_info.freqSystemBus / 2; #else /* Most 85xx SOCs use CCB/2, so this is the default behavior. */ gd-i2c1_clk = sys_info.freqSystemBus / 2; #endif This is just for 85xx, and it only applies to the I2C devices. That way, less knowledge is required by the firmware to poke values all over the place, and it also allows one to describe situations where the frequency of the input clock can change (such as in low-power modes). I don't think it's possible to do what you want to do. I2C clocking is completely screwed up, and that's just the way the hardware was designed. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Wolfgang Grandegger wrote: No, the source clock is not identical for all 8[356]xx. Some use half or even a third of the SOC clock frequency. The platform clock divided by 2 or 3 *is* the source clock to the I2C. That's what I'm talking about. Linux must determine the real source clock frequency somehow. We may introduce the SOC property i2c-clock-frequency, which could be fixed up by U-Boot or a pre-loader (in case U-Boot is not used). Like for other frequency properties as well. That's what I'm proposing, but drop the i2c-. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Wolfgang Grandegger wrote: But clock-frequency, aka bus-frequency, is already used by fsl_get_sys_freq(): http://lxr.linux.no/linux+v2.6.26/arch/powerpc/sysdev/fsl_soc.c#L80 So? clock-frequency is a per-node property. I use it in the codec node on the 8610 (mpc8610_hpcd.dts). It does not mean platform clock frequency. U-Boot could then fixup that value like bus-frequency() and the i2c-mpc driver simply calls fsl_get_i2c_freq(). This is just more complicated than it needs to be. Why should the I2C driver fetch the platform clock and the divider from the parent node, and then do additional math, when it could just get the value it needs right from the node it's probing? Besides, U-Boot does not currently store the divider value. Look at the code I've posted twice already - it stores the frequency in i2c1_clk. So now I would need to create another variable in the gd_t to store the divider? No thanks. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Wolfgang Grandegger wrote: I'm a bit confused. The frequency of the I2C source clock and the real I2C clock frequency are two different things. There are two frequencies: 1) The frequency of the input clock to the I2C device, after it has gone through a divider. This is what I call the I2C clock frequency and what I think belongs in the clock-frequency property. This is usually the platform clock divided by 1, 2, or 3. 2) The speed of the I2C bus, as seen by devices on that bus. This is usually 400KHz. The first one is common for all I2C devices, the second can be different. What properties would you like to use for defining both? The platform clock has no value to the I2C hardware, so I don't care anything about it. Besides, U-Boot does not currently store the divider value. Look at the code I've posted twice already - it stores the frequency in i2c1_clk. So now I would need to create another variable in the gd_t to store the divider? No thanks. OK, that's an argument but it's biased by U-Boot. As long as a method that is favorable to U-Boot does not put any undo hardship on non-U-Boot methods, I would say that it is the preferred method. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Wolfgang Grandegger wrote: Is it not exactly that? For me it's not a per I2C device property, at least. Of course it's a per-I2C device property. The input frequency to the I2C device is only seen by the I2C device, and no other device. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Wolfgang Grandegger wrote: 2) The speed of the I2C bus, as seen by devices on that bus. This is usually 400KHz. Which should be defined with the property current-speed, right? I would use something like bus-speed, but yes. The word current shouldn't be in a property string. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Jon Smirl wrote: For mpc5200 it is easy, mpc52xx_find_ipb_freq() already exists to get the source clock for the i2c devices. Each i2c node in the device tree can then specify clock-frequency = 40; or let it default. You 400KHz is the *speed* of the I2C bus, so let's be sure to use speed in the property name. Reserve the word bus for the input clock to the I2C device. #if defined(CONFIG_MPC8540) || defined(CONFIG_MPC8541) || \ defined(CONFIG_MPC8560) || defined(CONFIG_MPC8555) gd-i2c1_clk = sys_info.freqSystemBus; #elif defined(CONFIG_MPC8544) /* * On the 8544, the I2C clock is the same as the SEC clock. This can be * either CCB/2 or CCB/3, depending on the value of cfg_sec_freq. See * 4.4.3.3 of the 8544 RM. Note that this might actually work for all * 85xx, but only the 8544 has cfg_sec_freq, so it's unknown if the * PORDEVSR2_SEC_CFG bit is 0 on all 85xx boards that are not an 8544. */ if (gur-pordevsr2 MPC85xx_PORDEVSR2_SEC_CFG) gd-i2c1_clk = sys_info.freqSystemBus / 3; else gd-i2c1_clk = sys_info.freqSystemBus / 2; #else /* Most 85xx SOCs use CCB/2, so this is the default behavior. */ gd-i2c1_clk = sys_info.freqSystemBus / 2; #endif gd-i2c2_clk = gd-i2c1_clk; I think the whole point is to eliminate duplicating this code in the Linux driver. It's hideously ugly, so it should be limited as much as possible. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Grant Likely wrote: How is the divider controlled? Is it a fixed property of the SoC? Yes. The divider is either 1, 2, or 3, and the only way to know which one it is is to look up the specific SOC model number. And depending on the SOC model, there may also be a register that needs to be looked up. a shared register setting? or a register setting within the i2c device? The I2C device itself has no idea what the divider is. It only sees the result of the divider. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Jon Smirl wrote: It wouldn't go into the i2c driver, it would go into the mpc8xxx platform driver. Why is it bad to put it into the mpc8xxx platform driver? It is an accurate description of the mpc8xxx platform isn't it? There's no need to put that code in the platform driver because U-Boot will put the final result in the device tree! That way, we won't need to update the platform driver *and* U-Boot for any new SOC. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Jon Smirl wrote: Isn't there a single global divider that generates all the i2c source clocks? You don't want to copy a global value into each i2c node. Why not? There are only two I2C devices, and it's theoretically possible for them to have different input clock frequencies. Keeping it in the I2C node allows the I2C driver to reference a property directly in the node that its probing. Aren't we talking about the /2 or /3 or /1 divider that appears to be randomly implemented on various members of the mpc8xxx family? Yes. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Jon Smirl wrote: But that's the same as saying we should copy the system clock frequency into all of the PSC nodes because we might implement hardware where they aren't all clocked off from the same input clock source. The I2C clock is only visible to the I2C devices. The system clock is seen by many devices. There's the difference. Aren't we talking about the /2 or /3 or /1 divider that appears to be randomly implemented on various members of the mpc8xxx family? I don't this these dividers or clocks need to be exposed at all if you'd just put that ugly code snippet into your platform driver. That's why I don't think the divider belongs in the device tree. Just put the actual resulting clock frequency in the device tree. Besides, putting that snippet in the platform driver *is* exposing it. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Wolfgang Grandegger wrote: U-Boot does not (yet) use the FDT and it has therefore to use that ugly code to derive the I2C input clock frequency. I think its completely legal to put that hardware specific information into the FDT and get rid of such code. Huh? U-Boot initializes several fields and creates several properties in the FDT today, so what's wrong with adding another one? The clock frequencies have always been calculated by U-Boot, because putting them in the device tree is a bad idea. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: I2C node in device tree breaks old-style drivers
On Wed, Jul 30, 2008 at 5:54 AM, Jochen Friedrich [EMAIL PROTECTED] wrote: Hi Timur, So my conclusion is that specifying an I2C node in the device tree *requires* that the driver be new-style. Is there any way we can fix this? I'm not going to have time to update the CS4270 driver to a new-style interface before the 2.6.27 window closes. This conclusion is correct. One possible way to fix this is to add support for blacklisting to drivers/of/base.c (untested): No need. I posted a patch to alsa-devel that makes the CS4270 a new-style I2C driver. I'd hate to think that my driver is the only I2C driver used on PowerPC systems that was outdated. :-) -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
On Fri, Jul 25, 2008 at 8:12 AM, Grant Likely [EMAIL PROTECTED] wrote: Yes, please use something like clock-frequency or current-speed and do the calculation. Ditto. I already wrote the code that does that for U-Boot, so all you need to do is port it. Although I'm curious, if U-Boot already programs the speed, why does the driver program it again? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Wolfgang Grandegger wrote: I know but we still need an algorithm for MPC52xx and MPC82xx as well. That's true, but I still think hard-coding values of DFSR and FDR in the device tree is not a good way to do this. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
Jon Smirl wrote: I'm just going to ignore 2.6.27 and wait for 2.6.28. 2.6.28 might have ASoC V2, or at least portions of it. You might want to just port your driver to ASoC V2 like I did and not worry about it. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Grant Likely wrote: Okay, I've changed my mind. :-) I'll back off a bit from this extreme and call it: sound/soc/fsl/soc-of-simple.c That works for me. And please don't forget to CC: me on any discussion involving sound/soc/fsl. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
Grant Likely wrote: + aic26-codec.reg_cache_size = sizeof(aic26-reg_cache); + aic26-codec.reg_cache = aic26-reg_cache; ... + /* Register the sysfs files for debugging */ + /* Create SysFS files */ + rc = device_create_file(spi-dev, dev_attr_regs); + rc |= device_create_file(spi-dev, dev_attr_regs_cache); + rc |= device_create_file(spi-dev, dev_attr_keyclick); + if (rc) + dev_info(spi-dev, error creating sysfs files\n); I believe ASoC creates sysfs entries if you use reg_cache and reg_cache_size, so you should not be creating your own sysfs entries if you use these variables. + +#if defined(CONFIG_SND_SOC_OF) + /* Tell the of_soc helper about this codec */ + of_snd_soc_register_codec(aic26_soc_codec_dev, aic26, aic26_dai, + spi-dev.archdata.of_node); +#endif I haven't paid any attention to the of_soc helper, because it's for ASoC V1 only. However, I don't understand why you need to reference it in the codec driver. My CS4270 codec driver knows nothing about OF and works fine in arch/powerpc. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] I2C: fsl-i2c: make device probing configurable via FDT
Jon Smirl wrote: Probing an i2c bus does not necessarily come to a good conclusion. The probes for some chips can alter the states in others. People have accidentally changed voltage settings and fried CPU chips. The process is not well defined. I agree. We should not be implementing any feature that encourages I2C bus probing. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: fix ALSA options in Freescale 85xx and 86xx defconfigs
Timur Tabi wrote: The defconfigs for Freescale 85xx and 86xx SOCs had bad choices for some audio related options. In particular, OSS emulation should be enabled, and the old ALSA API should be disabled. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- Kumar, can you apply this patch, please? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Jon Smirl wrote: Which are we going to call it, fabric or machine? Fabric. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Mark Brown wrote: The PowerPC side isn't without fault too. PowerPC still doesn't have a good way to load the fabric/machine driver. I'm finding it difficult to square these two statements - from an ASoC point of view the main thing this patch is doing is adding a machine driver and that's not something that's going to go away. Jon's concern is that there is no straightforward way to build a kernel with multiple fabric drivers and have the right one chosen via the device tree. This is just a limitation of the device tree model, and no one has come up with a good solution yet. The problem still exists in ASoC V2. However, it's not anything that ASoC itself needs to be concerned with. It's purely a PowerPC problem. Which are we going to call it, fabric or machine? I had been working on the Apple code in sound/aoa. It is called fabric in that code. The equivalent driver is called machine in ASoC v1. ASoC has always called it a machine driver. Wait, I thought it's supposed to be called a fabric driver now? On PowerPC, it should be called a fabric driver because we already have machine drivers. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] task_pt_regs for powerpc systems
Srinivasa D S wrote: +#define task_pt_regs(tsk)(tsk)-thread.regs Shouldn't this be: #define task_pt_regs(tsk) ((tsk)-thread.regs) just to be safe? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Mark Brown wrote: Desktop Management Interface, a standard BIOS interface for getting system data on x86 class hardware. Of particular interest here is the fact that it contains various ID strings for things like motherboard and chassis - on Linux drivers can be automatically loaded based on these strings. See drivers/misc/thinkpad_acpi.c for an example of a driver that does this. The only problem with this is that the OF probing code in the kernel binds drivers to device tree nodes. So when a driver claims a node, no other driver will be probed with it. So we can't have generic nodes that classify the motherboard and just let everyone get probed on it. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
