Re: issues calling of_platform_bus_probe() twice
On Sat, 17 Mar 2012 08:23:54 +1100, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2012-03-16 at 16:21 -0500, Kumar Gala wrote: Guys, Are you aware of any reason that we can't call of_platform_bus_probe() or multiple times. Timur's run into an issue in which all devices don't get registered properly if we call of_platform_bus_probe() times with different of_device_id struct's. Nothing comes to mind... Grant ? Neither for me. Should work. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] Device Tree Bindings for Freescale TDM controller
Thanks Scott for the review. Will send an updated revision with the comments taken care. Regards Poonam -Original Message- From: Wood Scott-B07421 Sent: Saturday, March 17, 2012 12:00 AM To: Aggrwal Poonam-B10812 Cc: devicetree-disc...@lists.ozlabs.org; linuxppc-dev@lists.ozlabs.org; Singh Sandeep-B37400 Subject: Re: [PATCH] Device Tree Bindings for Freescale TDM controller On 03/15/2012 08:30 PM, Poonam Aggrwal wrote: From: Poonam Aggrwal poonam.aggr...@freescale.com This TDM controller is available in various Freescale SOCs like MPC8315, P1020, P1022, P1010. Signed-off-by: Sandeep Singh sand...@freescale.com Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com --- Documentation/devicetree/bindings/tdm/fsl-tdm.txt | 71 + 1 files changed, 71 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/tdm/fsl-tdm.txt diff --git a/Documentation/devicetree/bindings/tdm/fsl-tdm.txt b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt new file mode 100644 index 000..61431e3 --- /dev/null +++ b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt @@ -0,0 +1,71 @@ += +TDM Device Tree Binding +Copyright (C) 2012 Freescale Semiconductor Inc. + +NOTE: The bindings described in this document are preliminary and +subject to change. + += +TDM (Time Division Multiplexing) + +DESCRIPTION + +The TDM is full duplex serial port designed to allow various devices +including digital signal processors (DSPs) to communicate with a +variety of serial devices including industry standard framers, codecs, other DSPs and microprocessors. + +The below properties describe the device tree bindings for Freescale +TDM controller. +This TDM controller is available on various Freescale Processors like +MPC8313, P1020, P1022 and P1010. + +PROPERTIES + + - compatible + Usage: required + Value type: string + Definition: Should contain fsl,mpc8315-tdm. + So mpc8313 will have compatible = fsl,mpc8315-tdm; + p1010 will have compatible fsl,p1010-tdm, fsl,mpc8315-tdm; Shouldn't mpc8313 have: compatible = fsl,mpc8313-tdm, fsl,mpc8315-tdm? I thought we were going to use 8313 as the canonical implementation, not 8315. MPC8315 was the first FSL platform to have this controller. MPC8313 does not have TDM. + - reg + Usage: required + Value type: tdm-reg-offset tdm-reg-size dmac-reg-offset dmac- reg-size + Definition: A standard property. Specifies the physical address + offset and length of the TDM registers and TDM DMAC registers for + the device. Just say there's two reg resources, and that the first is the TDM registers and the second is the TDM DMAC registers. It's typically not going to be the actual physical address, but rather an offset that gets translated through a parent node's ranges. Okay, I think we missed this comment, you already gave this earlier. Sorry for that. Remove value type; it's standard. Okay. So just definition must suffice, right? + - clock-frequency + Usage: optional + Value type: u32 + Definition: The frequency at which the TDM block is operating. Will this frequency ever need to be 4GHz? Don't think so, at max this will be CCB, not sure if CCB on our platforms may get bigger than 4G ever. Might want to specify as u32 or u64, as ePAPR suggests. Means Value type: u32 or u64? In this case the driver must always use 64bit data structure to read this. Is this correct? + - interrupts + Usage: required + Value type: tdm-err-intr tdm-err-intr-type dmac-intr dmac-intr- type + Definition: This field defines two interrupt specifiers namely interrupt + number and interrupt type for TDM error and TDM DMAC. What is tdm-err-intr-type? The interrupt specifier encoding is defined by the interrupt controller. There might be one cell, two cells, four cells, etc. Remove value type, it's standard. okay + - phy-handle + Usage: optional + Value type: phandle + Definition: Phandle of the line controller node or framer node eg. SLIC, + E1\T1 etc. Use a forward slash -- this isn't a Windows filesystem path. :-) Okay, agreed. + - fsl-max-time-slots + Usage: required + Value type: u32 + Definition: Maximum number of 8-bit time slots in one TDM frame. + This is the maximum number which TDM hardware supports. fsl,tdm-max-time-slots Sure. This again got missed. + +EXAMPLE + + tdm@16000 { + device_type = tdm; No device_type Okay. + compatible = fsl,p1010-tdm, fsl,mpc8315-tdm; + reg = 0x16000 0x200 0x2c000 0x2000; + clock-frequency = 0; Show a real
[PATCH][v2] powerpc/85xx:Add BSC9131 RDB Support
BSC9131RDB is a Freescale reference design board for BSC9131 SoC.The BSC9131 is integrated SoC that targets Femto base station market. It combines Power Architecture e500v2 and DSP StarCore SC3850 core technologies with MAPLE-B2F baseband acceleration processing elements. The BSC9131 SoC includes the following function and features: . Power Architecture subsystem including a e500 processor with 256-Kbyte shared L2 cache . StarCore SC3850 DSP subsystem with a 512-Kbyte private L2 cache . The Multi Accelerator Platform Engine for Femto BaseStation Baseband Processing (MAPLE-B2F) . A multi-standard baseband algorithm accelerator for Channel Decoding/Encoding, Fourier Transforms, UMTS chip rate processing, LTE UP/DL Channel processing, and CRC algorithms . Consists of accelerators for Convolution, Filtering, Turbo Encoding, Turbo Decoding, Viterbi decoding, Chiprate processing, and Matrix Inversion operations . DDR3/3L memory interface with 32-bit data width without ECC and 16-bit with ECC, up to 400-MHz clock/800 MHz data rate . Dedicated security engine featuring trusted boot . DMA controller . OCNDMA with four bidirectional channels . Interfaces . Two triple-speed Gigabit Ethernet controllers featuring network acceleration including IEEE 1588. v2 hardware support and virtualization (eTSEC) . eTSEC 1 supports RGMII/RMII . eTSEC 2 supports RGMII . High-speed USB 2.0 host and device controller with ULPI interface . Enhanced secure digital (SD/MMC) host controller (eSDHC) . Antenna interface controller (AIC), supporting three industry standard JESD207/three custom ADI RF interfaces (two dual port and one single port) and three MAXIM's MaxPHY serial interfaces . ADI lanes support both full duplex FDD support and half duplex TDD support . Universal Subscriber Identity Module (USIM) interface that facilitates communication to SIM cards or Eurochip pre-paid phone cards . TDM with one TDM port . Two DUART, four eSPI, and two I2C controllers . Integrated Flash memory controller (IFC) . TDM with 256 channels . GPIO . Sixteen 32-bit timers The DSP portion of the SoC consists of DSP core (SC3850) and various accelerators pertaining to DSP operations. BSC9131RDB Overview -- BSC9131 SoC 1Gbyte DDR3 (on board DDR) 128Mbyte 2K page size NAND Flash 256 Kbit M24256 I2C EEPROM 128 Mbit SPI Flash memory USB-ULPI eTSEC1: Connected to RGMII PHY eTSEC2: Connected to RGMII PHY DUART interface: supports one UARTs up to 115200 bps for console display Linux runs on e500v2 core and access some DSP peripherals like AIC Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com Signed-off-by: Priyanka Jain priyanka.j...@freescale.com Signed-off-by: Akhil Goyal akhil.go...@freescale.com Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Rajan Srivastava rajan.srivast...@freescale.com Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Note: Name of PSC9131 has been changed to BSC9131 because of new nomenclature Please reject earlier patchpowerpc/85xx:Add PSC9131 RDB Support http://patchwork.ozlabs.org/patch/146349/ Beased on http://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git branch master Changes for v2: - Change board file name as bsc913x_rdb.c - Removed all I2C's board device. A separate patch will be send. - Combined SPI's 2 RFS partition into single RFS parition - Added SEC/crypto node in dts arch/powerpc/boot/dts/bsc9131rdb.dts | 34 + arch/powerpc/boot/dts/bsc9131rdb.dtsi | 142 ++ arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi | 193 + arch/powerpc/boot/dts/fsl/bsc9131si-pre.dtsi | 59 arch/powerpc/platforms/85xx/Kconfig |9 ++ arch/powerpc/platforms/85xx/Makefile |1 + arch/powerpc/platforms/85xx/bsc913x_rdb.c | 95 7 files changed, 533 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/boot/dts/bsc9131rdb.dts create mode 100644 arch/powerpc/boot/dts/bsc9131rdb.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/bsc9131si-pre.dtsi create mode 100644 arch/powerpc/platforms/85xx/bsc913x_rdb.c diff --git a/arch/powerpc/boot/dts/bsc9131rdb.dts b/arch/powerpc/boot/dts/bsc9131rdb.dts new file mode 100644 index 000..e13d2d4 --- /dev/null +++ b/arch/powerpc/boot/dts/bsc9131rdb.dts @@ -0,0 +1,34 @@ +/* + * BSC9131 RDB Device Tree Source + * + * Copyright 2011-2012 Freescale Semiconductor Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation;
[PATCH]corenet32_smp_defconfig:Added I2C_CHARDEV option in defconfig to have compiled I2C device interface
Signed-off-by: Shaveta Leekha shav...@freescale.com --- arch/powerpc/configs/corenet32_smp_defconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig index f8aef20..91db656 100644 --- a/arch/powerpc/configs/corenet32_smp_defconfig +++ b/arch/powerpc/configs/corenet32_smp_defconfig @@ -116,6 +116,7 @@ CONFIG_SERIAL_8250_RSA=y CONFIG_HW_RANDOM=y CONFIG_NVRAM=y CONFIG_I2C=y +CONFIG_I2C_CHARDEV=y CONFIG_I2C_MPC=y CONFIG_SPI=y CONFIG_SPI_GPIO=y -- 1.5.5.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] corenet64_smp_defconfig:Added I2C_CHARDEV and I2C_MPC options in defconfig to have compiled I2C device interface
Signed-off-by: Shaveta Leekha shav...@freescale.com --- arch/powerpc/configs/corenet64_smp_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 7ed8d4c..8a42ebb 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -71,6 +71,8 @@ CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y CONFIG_I2C=y +CONFIG_I2C_CHARDEV=y +CONFIG_I2C_MPC=y # CONFIG_HWMON is not set CONFIG_VIDEO_OUTPUT_CONTROL=y # CONFIG_HID_SUPPORT is not set -- 1.5.5.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] mpc85xx_defconfig:Added I2C_CHARDEV option in defconfig to have compiled I2C device interface
Signed-off-by: Shaveta Leekha shav...@freescale.com --- arch/powerpc/configs/mpc85xx_defconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig index f37a2ab..28378e8 100644 --- a/arch/powerpc/configs/mpc85xx_defconfig +++ b/arch/powerpc/configs/mpc85xx_defconfig @@ -116,6 +116,7 @@ CONFIG_SERIAL_8250_RSA=y CONFIG_SERIAL_QE=m CONFIG_NVRAM=y CONFIG_I2C=y +CONFIG_I2C_CHARDEV=y CONFIG_I2C_CPM=m CONFIG_I2C_MPC=y CONFIG_SPI=y -- 1.5.5.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] mpc85xx_smp_defconfig:Added I2C_CHARDEV option in defconfig to have compiled I2C device interface
Signed-off-by: Shaveta Leekha shav...@freescale.com --- arch/powerpc/configs/mpc85xx_smp_defconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig index abdcd31..f95b302 100644 --- a/arch/powerpc/configs/mpc85xx_smp_defconfig +++ b/arch/powerpc/configs/mpc85xx_smp_defconfig @@ -118,6 +118,7 @@ CONFIG_SERIAL_8250_RSA=y CONFIG_SERIAL_QE=m CONFIG_NVRAM=y CONFIG_I2C=y +CONFIG_I2C_CHARDEV=y CONFIG_I2C_CPM=m CONFIG_I2C_MPC=y CONFIG_SPI=y -- 1.5.5.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH]corenet32_smp_defconfig:Added I2C_CHARDEV option in defconfig to have compiled I2C device interface
Signed-off-by: Shaveta Leekha shav...@freescale.com --- arch/powerpc/configs/corenet32_smp_defconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig index f8aef20..91db656 100644 --- a/arch/powerpc/configs/corenet32_smp_defconfig +++ b/arch/powerpc/configs/corenet32_smp_defconfig @@ -116,6 +116,7 @@ CONFIG_SERIAL_8250_RSA=y CONFIG_HW_RANDOM=y CONFIG_NVRAM=y CONFIG_I2C=y +CONFIG_I2C_CHARDEV=y CONFIG_I2C_MPC=y CONFIG_SPI=y CONFIG_SPI_GPIO=y -- 1.5.5.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: issues calling of_platform_bus_probe() twice
Grant Likely wrote: Are you aware of any reason that we can't call of_platform_bus_probe() or multiple times. Timur's run into an issue in which all devices don't get registered properly if we call of_platform_bus_probe() times with different of_device_id struct's. Nothing comes to mind... Grant ? Neither for me. Should work. I posted a work-around patch here: http://patchwork.ozlabs.org/patch/128533/ Without this patch, drivers cannot probe on DMA *channels*, or any other grandchildren of the root node. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mpc85xx_defconfig:Added I2C_CHARDEV option in defconfig to have compiled I2C device interface
On Sat, Mar 17, 2012 at 4:00 AM, Shaveta Leekha shav...@freescale.com wrote: Signed-off-by: Shaveta Leekha shav...@freescale.com --- Where's the patch description? You need to explain WHY this change is a good idea. And you should change all defconfigs in one patch. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Problem with framebuffer mmap on platforms with large addressing
Hello, I'm trying to make framebuffer to work on PPC460EX board (canyonlands). The peculiarity of this platform is the fact that it has sizeof(unsigned long) = 4, but physical address on it is 36 bits width. It is a common to various pieces of the code to expect that unsigned long variable is able to contain physical address. Most of those places are easy to fix. The problem I'm stuck with is a fb_mmap() code. To find a right memory to map it uses information from struct fb_fix_screeninfo provided by the driver. This structure uses two unsigned long fields to hold physical addresses (smem_start and mmio_start). It would be easy to change that structure to use phys_addr_t instead of unsigned long, but this structure is a part of userspace ABI. It is returned to userspace on FBIOGET_FSCREENINFO ioctl. And now I'm stuck with it. In my driver code I have just overwritten the fb_mmap function with driver-private fb_mmap callback supporting 64-bit addressing, but this doesn't look like a generic and correct solution. What is the best way to fix this problem? Should we break ABI with the goal of correctness? Should we add new FBIOGET_FSCREENINFO2, which will return a correct structure with phys_addr_t (or simply u64) fields and make FBIOGET_FSCREENINFO a wrapper returning partially bogus structure (with smem_start and mmio_start fields being truncated to just unsigned long)? What would developers recommend? Thank you. -- With best wishes Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Device Tree Bindings for Freescale TDM controller
On Sat, Mar 17, 2012 at 2:33 AM, Aggrwal Poonam-B10812 b10...@freescale.com wrote: + - clock-frequency + Usage: optional + Value type: u32 + Definition: The frequency at which the TDM block is operating. Will this frequency ever need to be 4GHz? Don't think so, at max this will be CCB, not sure if CCB on our platforms may get bigger than 4G ever. Apparently, 4GB is the new 640K. In Poonam's defense, every clock frequency property in the device tree is a 32-bit integer. I've never seen a 64-bit one. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Device Tree Bindings for Freescale TDM controller
On Sat, Mar 17, 2012 at 2:33 AM, Aggrwal Poonam-B10812 b10...@freescale.com wrote: + compatible = fsl,p1010-tdm, fsl,mpc8315-tdm; + reg = 0x16000 0x200 0x2c000 0x2000; + clock-frequency = 0; Show a real clock-frequency, perhaps with a comment saying it's typically filled in by boot software. Okay. Scott, are you suggesting that Poonam put a non-zero number in the DTS for clock-frequency? If so, then I don't think that's a good idea, if U-Boot will always override it. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: fsl pci edac patches
Hello, On Sat, Mar 17, 2012 at 1:13 AM, Kumar Gala ga...@kernel.crashing.org wrote: Guys, I'm not sure what the state of the EDAC patches and latest kernel are.. I'm going to mark the ones in patch works as 'dead' and hopefully you guys will resend if there is still an interest. I don't have mpc85xx hardware to test at this point, so probably I don't care about 85xx EDAC binding right now. Strictly speaking I forgot about these patches :( -- With best wishes Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: issues calling of_platform_bus_probe() twice
On Sat, 2012-03-17 at 13:35 +, Tabi Timur-B04825 wrote: Are you aware of any reason that we can't call of_platform_bus_probe() or multiple times. Timur's run into an issue in which all devices don't get registered properly if we call of_platform_bus_probe() times with different of_device_id struct's. Nothing comes to mind... Grant ? Neither for me. Should work. I posted a work-around patch here: http://patchwork.ozlabs.org/patch/128533/ Without this patch, drivers cannot probe on DMA *channels*, or any other grandchildren of the root node. Why don't you track down the actual bug instead ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev