RE: [PATCH 1/2][v3] powerpc/fsl-booke: Add initial T104x_QDS board support
Hi Tabi, > -Original Message- > From: Timur Tabi [mailto:ti...@tabi.org] > Sent: Friday, September 20, 2013 2:03 AM > To: Kushwaha Prabhakar-B32579 > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Jain Priyanka- > B32167; Aggrwal Poonam-B10812 > Subject: Re: [PATCH 1/2][v3] powerpc/fsl-booke: Add initial T104x_QDS > board support > > On Thu, Sep 19, 2013 at 4:00 AM, Prabhakar Kushwaha > wrote: > > > - Video > > - DIU supports video at up to 1280x1024x32bpp > > You mention DIU support, except there's no DIU enablement in the platform > file. You need the T104x equivalent of > p1022ds_set_pixel_clock() and the other functions. My primary object is to put base patch in Linux. once it done other things can be enabled one by one. Also, I am not familiar with DIU driver :(. or shall I remove the DIU node, and while adding support of DIU, all modification will be sent. Please advice. Regards, Prabhakar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/mpc85xx:Add initial device tree support of T104x
> -Original Message- > From: Wood Scott-B07421 > Sent: Tuesday, September 17, 2013 2:49 AM > To: Kushwaha Prabhakar-B32579 > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; > ga...@kernel.crashing.org; Aggrwal Poonam-B10812; Jain Priyanka-B32167; > Sethi Varun-B16395 > Subject: Re: [PATCH] powerpc/mpc85xx:Add initial device tree support of > T104x > > On Fri, 2013-09-13 at 02:30 -0500, Kushwaha Prabhakar-B32579 wrote: > > > I also question the need to define separate t1040 compatible values > > > for all of these, if the only difference is whether the onboard > > > switch is enabled or not. > > > > > > > so should I use T104x as compatible field. and in T1040 device tree add > extra node for l2 switch. I am using T1042 as base dts and T1040 includes T1040 + l2switch. so if I use T1042 in compatible. It will give wrong field for someone working on T1040QDS. best solution should be to have a) have T1042 in compatible field. b) T1040 dts override T1042 to t1040 in compatible field. it will give correct picture Regards, Prabhakar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc/fsl-booke: Add initial T104x_QDS board support
> -Original Message- > From: Wood Scott-B07421 > Sent: Thursday, September 12, 2013 5:11 AM > To: Kushwaha Prabhakar-B32579 > Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Jain > Priyanka-B32167; Aggrwal Poonam-B10812 > Subject: Re: [PATCH 1/2] powerpc/fsl-booke: Add initial T104x_QDS board > support > > On Wed, 2013-09-11 at 12:28 +0530, Prabhakar Kushwaha wrote: > > Add support for T104x board in board file t104x_qds.c, It is common > > for both T1040 and T1042 as they share same QDS board. > > > > T1040QDS board Overview > > --- > > - SERDES Connections, 8 lanes supporting: > > — PCI Express: supporting Gen 1 and Gen 2; > > — SGMII > > — QSGMII > > — SATA 2.0 > > — Aurora debug with dedicated connectors (T1040 only) > > - DDR Controller > > - Supports rates of up to 1600 MHz data-rate > > - Supports one DDR3LP UDIMM/RDIMMs, of single-, dual- or quad-rank > types. > > -IFC/Local Bus > > - NAND flash: 8-bit, async, up to 2GB. > > - NOR: 8-bit or 16-bit, non-multiplexed, up to 512MB > > - GASIC: Simple (minimal) target within Qixis FPGA > > - PromJET rapid memory download support > > - Ethernet > > - Two on-board RGMII 10/100/1G ethernet ports. > > - PHY #0 remains powered up during deep-sleep (T1040 only) > > - QIXIS System Logic FPGA > > - Clocks > > - System and DDR clock (SYSCLK, “DDRCLK”) > > - SERDES clocks > > - Power Supplies > > - Video > > - DIU supports video at up to 1280x1024x32bpp > > - USB > > - Supports two USB 2.0 ports with integrated PHYs > > — Two type A ports with 5V@1.5A per port. > > — Second port can be converted to OTG mini-AB > > - SDHC > > - SDHC port connects directly to an adapter card slot, featuring: > > - Supporting SD slots for: SD, SDHC (1x, 4x, 8x) and/or MMC > > — Supporting eMMC memory devices > > - SPI > > - On-board support of 3 different devices and sizes > > - Other IO > > - Two Serial ports > > - ProfiBus port > > - Four I2C ports > > > > Add T104xQDS support in Kconfig and Makefile. Also create device tree. > > > > Signed-off-by: Priyanka Jain > > Signed-off-by: Poonam Aggrwal > > Signed-off-by: Prabhakar Kushwaha > > --- > > Based upon > > git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git > > > > TODO: Add noded for ethernet and board stuff > > "board stuff"? > > Isn't "board stuff" the whole point of this patch? :-) > :) > > arch/powerpc/boot/dts/t1040qds.dts | 201 > +++ > > arch/powerpc/boot/dts/t1042qds.dts | 201 > +++ > > arch/powerpc/platforms/85xx/Kconfig | 20 +++ > > arch/powerpc/platforms/85xx/Makefile|1 + > > arch/powerpc/platforms/85xx/t104x_qds.c | 102 > > 5 files changed, 525 insertions(+) > > create mode 100644 arch/powerpc/boot/dts/t1040qds.dts > > create mode 100644 arch/powerpc/boot/dts/t1042qds.dts > > create mode 100644 arch/powerpc/platforms/85xx/t104x_qds.c > > > > diff --git a/arch/powerpc/boot/dts/t1040qds.dts > > b/arch/powerpc/boot/dts/t1040qds.dts > > new file mode 100644 > > index 000..cea5632 > > --- /dev/null > > +++ b/arch/powerpc/boot/dts/t1040qds.dts > > @@ -0,0 +1,201 @@ > > +/* > > + * T1040QDS Device Tree Source > > + * > > + * Copyright 2013 Freescale Semiconductor Inc. > > + * > > + * Redistribution and use in source and binary forms, with or without > > + * modification, are permitted provided that the following conditions > are met: > > + * * Redistributions of source code must retain the above > copyright > > + * notice, this list of conditions and the following disclaimer. > > + * * Redistributions in binary form must reproduce the above > copyright > > + * notice, this list of conditions and the following disclaimer in > the > > + * documentation and/or other materials provided with the > distribution. > > + * * Neither the name of Freescale Semiconductor nor the > > + * names of its contributors may be used to endorse or promote > products > > + * derived from this software without specific prior written > permission. > > + * > > + * > > + * ALTERNATIVELY, this software may be distributed under the terms of > > +the > > + * GNU General Public
RE: [PATCH] powerpc/mpc85xx:Add initial device tree support of T104x
thanks Scott for review.
Please find my reply in-lined.
Regards,
Prabhakar
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, September 12, 2013 4:54 AM
> To: Kushwaha Prabhakar-B32579
> Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Aggrwal
> Poonam-B10812; Jain Priyanka-B32167; Sethi Varun-B16395
> Subject: Re: [PATCH] powerpc/mpc85xx:Add initial device tree support of
> T104x
>
> On Wed, 2013-09-11 at 12:28 +0530, Prabhakar Kushwaha wrote:
> > The QorIQ T1040/T1042 processor support four integrated 64-bit e5500
> > PA processor cores with high-performance data path acceleration
> > architecture and network peripheral interfaces required for networking
> & telecommunications.
> >
> > T1042 personality is a reduced personality of T1040 without Integrated
> > 8-port Gigabit Ethernet switch.
> >
> > The T1040/T1042 SoC includes the following function and features:
> >
> > - Four e5500 cores, each with a private 256 KB L2 cache
> > - 256 KB shared L3 CoreNet platform cache (CPC)
> > - Interconnect CoreNet platform
> > - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and
> interleaving
> >support
> > - Data Path Acceleration Architecture (DPAA) incorporating
> > acceleration for the following functions:
> > - Packet parsing, classification, and distribution
> > - Queue management for scheduling, packet sequencing, and
> congestion
> > management
> > - Cryptography Acceleration (SEC 5.0)
> > - RegEx Pattern Matching Acceleration (PME 2.2)
> > - IEEE Std 1588 support
> > - Hardware buffer management for buffer allocation and
> > deallocation
> > - Ethernet interfaces
> > - Integrated 8-port Gigabit Ethernet switch (T1040 only)
> > - Four 1 Gbps Ethernet controllers
> > - Two RGMII interfaces or one RGMII and one MII interfaces
> > - High speed peripheral interfaces
> >- Four PCI Express 2.0 controllers running at up to 5 GHz
> >- Two SATA controllers supporting 1.5 and 3.0 Gb/s operation
> >- Upto two QSGMII interface
> >- Upto six SGMII interface supporting 1000 Mbps
> >- One SGMII interface supporting upto 2500 Mbps
> > - Additional peripheral interfaces
> >- Two USB 2.0 controllers with integrated PHY
> >- SD/eSDHC/eMMC
> >- eSPI controller
> >- Four I2C controllers
> >- Four UARTs
> >- Four GPIO controllers
> >- Integrated flash controller (IFC)
> >- Change this to LCD/ HDMI interface (DIU) with 12 bit dual data
> rate
> >- TDM interface
> > - Multicore programmable interrupt controller (PIC)
> > - Two 8-channel DMA engines
> > - Single source clocking implementation
> > - Deep Sleep power implementaion (wakeup from
> > GPIO/Timer/Ethernet/USB)
> >
> > Signed-off-by: Poonam Aggrwal
> > Signed-off-by: Priyanka Jain
> > Signed-off-by: Varun Sethi
> > Signed-off-by: Prabhakar Kushwaha
> > ---
> > Based upon
> > git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
>
> Everything in there has already been pulled by Linus, so there's no
> reason to use that tree as a base right now.
>
I will rebase this patch.
> > +/include/ "t1042si-post.dtsi"
> [snip]
> > + serdes: serdes@ea000 {
> > + compatible = "fsl,t1040-serdes";
> > + reg= <0xea000 0x4000>;
> > + };
> > +
> > + sdhc@114000 {
> > + compatible = "fsl,t1040-esdhc", "fsl,esdhc";
> > + sdhci,auto-cmd12;
> > + };
>
> Why does sdhci,auto-cmd12 need to be specified here? It's already in
> t1042si-post.dtsi which you've included. Likewise with reg on the serdes
> node.
>
I will take care of this.
> I also question the need to define separate t1040 compatible values for
> all of these, if the only difference is whether the onboard switch is
> enabled or not.
>
so should I use T104x as compatible field. and in T1040 device tree add extra
node for l2 switch.
> > + clockgen: global-utilities@e1000 {
> > + compatible = "fsl,t1042-clockgen", "fsl,qoriq-clockgen-2.0",
> > + "fixed-clock";
> > + reg = <0xe1000 0x1000>;
> > + clock-output-names = "sysclk";
> > + #clock-cells = <0>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + pll0: pl
RE: [PATCH][v2] powerpc/85xx:Add BSC9131 RDB Support
Thanks Kumar for clarifying my doubts.
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Wednesday, March 21, 2012 11:08 PM
> To: Kushwaha Prabhakar-B32579
> Cc: linuxppc-dev@lists.ozlabs.org; devicetree-disc...@lists.ozlabs.org;
> Jain Priyanka-B32167; Mehresh Ramneek-B31383; Srivastava Rajan-B34330;
> Goyal Akhil-B35197
> Subject: Re: [PATCH][v2] powerpc/85xx:Add BSC9131 RDB Support
>
>
> On Mar 21, 2012, at 12:29 PM, Kushwaha Prabhakar-B32579 wrote:
>
> >>
> >>
> >> [snip]
> >>
> >
> > ??
> > Not getting you..
>
> Just meant, I was removing parts of the patch in the email to reduce
> things.
>
Oh :)
> >
> >>> diff --git a/arch/powerpc/platforms/85xx/bsc913x_rdb.c
> >>> b/arch/powerpc/platforms/85xx/bsc913x_rdb.c
> >>> new file mode 100644
> >>> index 000..611c289
> >>> --- /dev/null
> >>> +++ b/arch/powerpc/platforms/85xx/bsc913x_rdb.c
> >>> @@ -0,0 +1,95 @@
> >>> +/*
> >>> + * BSC913xRDB Board Setup
> >>> + *
> >>> + * Author: Priyanka Jain
> >>> + *
> >>> + * 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; either version 2 of the License, or
> >>> +(at your
> >>> + * option) any later version.
> >>> + */
> >>> +
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +
> >>> +void __init bsc913x_rdb_pic_init(void) {
> >>> + struct mpic *mpic;
> >>> + struct resource r;
> >>> + struct device_node *np;
> >>> +
> >>> + np = of_find_node_by_type(NULL, "open-pic");
> >>> + if (!np) {
> >>> + pr_err("bsc913x: Could not find open-pic node\n");
> >>> + return;
> >>> + }
> >>> +
> >>> + if (of_address_to_resource(np, 0, &r)) {
> >>> + pr_err("bsc913x: Failed to map mpic register space\n");
> >>> + of_node_put(np);
> >>> + return;
> >>> + }
> >>> +
> >>> + mpic = mpic_alloc(np, r.start, MPIC_WANTS_RESET |
> >>> + MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS | MPIC_SINGLE_DEST_CPU,
> >>> + 0, 256, " OpenPIC ");
> >>> +
> >>> + of_node_put(np);
> >>> +
> >>> + if (!mpic)
> >>> + pr_err("bsc913x: Failed to allocate MPIC structure\n");
> >>> + else
> >>> + mpic_init(mpic);
> >>> +}
> >>> +
> >>
> >> This code is still out of date w/other board ports. Have you tried
> >> building this against upstream??
> >>
> >
> > I build with powerpc.git.
> > do you mean build with upstream code base ??
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> >
>
> I mean if you use my 'next' branch of galak/powerpc.git and apply this
> patch, and enable it. For example MPIC_BROKEN_FRR_NIRQS doesn't exist
> anymore
>
I did on master branch. I will check on "next" branch and if required send new
patch version.
--Prabhakar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][v2] powerpc/85xx:Add BSC9131 RDB Support
Hi Kumar, Thanks for reviewing it. Please find my response in-lined. > -Original Message- > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > Sent: Wednesday, March 21, 2012 10:51 PM > To: Kushwaha Prabhakar-B32579 > Cc: linuxppc-dev@lists.ozlabs.org; devicetree-disc...@lists.ozlabs.org; > Jain Priyanka-B32167; Mehresh Ramneek-B31383; Srivastava Rajan-B34330; > Goyal Akhil-B35197 > Subject: Re: [PATCH][v2] powerpc/85xx:Add BSC9131 RDB Support > > > On Mar 17, 2012, at 3:39 AM, Prabhakar Kushwaha wrote: > > > 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 > > Signed-off-by: Priyanka Jain > > Signed-off-by: Akhil Goyal > > Signed-off-by: Poonam Aggrwal > > Signed-off-by: Rajan Srivastava > > Signed-off-by: Prabhakar Kushwaha > > --- > > Note: Name of PSC9131 has been changed to BSC9131 because of new > nomenclature > > Please reject earlier patch"powerpc/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
RE: [PATCH] powerpc/85xx:Add BSC9131 RDB Support
Thanks Kumar for reviewing this patch.
Please find my response in-lined..
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Saturday, March 17, 2012 1:43 AM
> To: Kushwaha Prabhakar-B32579
> Cc: linuxppc-dev@lists.ozlabs.org; devicetree-disc...@lists.ozlabs.org;
> Mehresh Ramneek-B31383; Jain Priyanka-B32167; Goyal Akhil-B35197; Aggrwal
> Poonam-B10812; Srivastava Rajan-B34330
> Subject: Re: [PATCH] powerpc/85xx:Add BSC9131 RDB Support
>
> >
> >
> > diff --git a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > new file mode 100644
> > index 000..d274c014
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > @@ -0,0 +1,179 @@
> > +/*
> > + * BSC9131 RDB Device Tree Source stub (no addresses or top-level
> > +ranges)
> > + *
> > + * Copyright 2011-2012 Freescale Semiconductor Inc.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> are met:
> > + * * Redistributions of source code must retain the above
> copyright
> > + * notice, this list of conditions and the following disclaimer.
> > + * * Redistributions in binary form must reproduce the above
> copyright
> > + * notice, this list of conditions and the following disclaimer
> in the
> > + * documentation and/or other materials provided with the
> distribution.
> > + * * Neither the name of Freescale Semiconductor nor the
> > + * names of its contributors may be used to endorse or promote
> products
> > + * derived from this software without specific prior written
> permission.
> > + *
> > + *
> > + * ALTERNATIVELY, this software may be distributed under the terms of
> > +the
> > + * GNU General Public License ("GPL") as published by the Free
> > +Software
> > + * Foundation, either version 2 of that License or (at your option)
> > +any
> > + * later version.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND
> > +ANY
> > + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> > +IMPLIED
> > + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> > +ARE
> > + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE
> > +FOR ANY
> > + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> > +DAMAGES
> > + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> > +SERVICES;
> > + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> > +CAUSED AND
> > + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
> > +OR TORT
> > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
> > +USE OF THIS
> > + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +
> > +&board_ifc {
> > +
> > + nand@0,0 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "fsl,ifc-nand";
> > + reg = <0x0 0x0 0x4000>;
> > +
> > + partition@0 {
> > + /* This location must not be altered */
> > + /* 3MB for u-boot Bootloader Image */
> > + reg = <0x0 0x0030>;
> > + label = "NAND U-Boot Image";
> > + read-only;
> > + };
> > +
> > + partition@30 {
> > + /* 1MB for DTB Image */
> > + reg = <0x0030 0x0010>;
> > + label = "NAND DTB Image";
> > + };
> > +
> > + partition@40 {
> > + /* 8MB for Linux Kernel Image */
> > + reg = <0x0040 0x0080>;
> > + label = "NAND Linux Kernel Image";
> > + };
> > +
> > + partition@c0 {
> > + /* Rest space for Root file System Image */
> > + reg = <0x00c0 0x0740>;
> > + label = " NAND RFS Image";
> > + };
> > + };
> > +};
> > +
> > +&board_soc {
> > + i2c@3000 {
> > + gpio3: gpio@21 {
> > + compatible = "nxp,pca9555";
>
> Is there any bindi
RE: [PATCH][v3] NAND Machine support for Integrated Flash Controller
Hi Kumar, This patch is supposed to be pushed via powerpc.git repository to main-line. Because of dependent patch in powerpc/mpc85xx: " powerpc/fsl: Add support for Integrated Flash Controller support" And it is already picked by you. Commit ID: a20cbdeffce247a2b6fb83cd8d22433994068565 So, can you please pick this patch in powerpc.git for future main-line pull request as early as possible. It will avoid future rebasing of this :) Regards, Prabhakar > -Original Message- > From: Kushwaha Prabhakar-B32579 > Sent: Friday, January 20, 2012 6:22 PM > To: linuxppc-dev@lists.ozlabs.org; linux-...@lists.infradead.org > Cc: Kushwaha Prabhakar-B32579; Dipen Dudhat; Wood Scott-B07421; Li Yang- > R58472; Liu Shuo-B35362; Aggrwal Poonam-B10812 > Subject: [PATCH][v3] NAND Machine support for Integrated Flash Controller > > Integrated Flash Controller(IFC) can be used to hook NAND Flash chips > using NAND Flash Machine available on it. > > Signed-off-by: Dipen Dudhat > Signed-off-by: Scott Wood > Signed-off-by: Li Yang > Signed-off-by: Liu Shuo > Signed-off-by: Poonam Aggrwal > Signed-off-by: Prabhakar Kushwaha > --- > Based upon > git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git (branch > next) > > Tested on P1010RDB > > Changes for v2: Ported IFC driver for linux-3.2.0-rc3 > - Use chip->bbt_options for BBT > - Use mtd_device_parse_register instead of old parse_mtd_partitions > > Changes for v3: Squashed following patch to make singe NAND driver > patch > - mtd/nand:Fix wrong usage of is_blank() in fsl_ifc_run_command > http://patchwork.ozlabs.org/patch/136547/ > - mtd/nand: Fix IFC driver to support 2K NAND page > http://patchwork.ozlabs.org/patch/135010/ > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/85xx:Add PSC9131 RDB Support
Thanks Andy and Timur for correcting the statement. I will make sure of this in future patches. --Prabhakar > -Original Message- > From: Andy Fleming [mailto:aflem...@gmail.com] > Sent: Saturday, February 18, 2012 4:56 AM > To: Tabi Timur-B04825 > Cc: Kushwaha Prabhakar-B32579; Goyal Akhil-B35197; Aggrwal Poonam-B10812; > Srivastava Rajan-B34330; Mehresh Ramneek-B31383; devicetree- > disc...@lists.ozlabs.org; linuxppc-dev@lists.ozlabs.org; Jain Priyanka- > B32167 > Subject: Re: [PATCH] powerpc/85xx:Add PSC9131 RDB Support > > On Fri, Feb 17, 2012 at 1:20 PM, Tabi Timur-B04825 > wrote: > > On Tue, Feb 14, 2012 at 2:37 AM, Prabhakar Kushwaha > > wrote: > >> > >> Applied on > >> git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git > >> branch next > > > > This is actually a false statement. "Applied" is past tense, so you > > are saying that this patch has *already* been applied to Kumar's > > powerpc.git repository. But this is not true -- Kumar's repository > > has not been updated in the last three weeks, and this patch is > > nowhere to be found. > > I'm pretty sure the sentence should read: > > Based on git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git > branch next > > Good idea to correct that for future submissions, as it is otherwise > confusing. Could also say "Developed against" instead of "Based on". > > Andy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] mtd/nand:Fix wrong usage of is_blank() in fsl_ifc_run_command
> -Original Message- > From: Artem Bityutskiy [mailto:dedeki...@gmail.com] > Sent: Friday, January 27, 2012 6:46 PM > To: Kushwaha Prabhakar-B32579 > Cc: linuxppc-dev@lists.ozlabs.org; linux-...@lists.infradead.org; Wood > Scott-B07421; Aggrwal Poonam-B10812 > Subject: Re: [PATCH] mtd/nand:Fix wrong usage of is_blank() in > fsl_ifc_run_command > > On Wed, 2012-01-18 at 09:43 +0530, Prabhakar Kushwaha wrote: > > Freescale IFC NAND Machine calculates ECC on 512byte sector and same > > is used in > > fsl_ifc_run_command() during ECC status verification. Also this sector > > is passed to is_blank() for blank checking. It is wrong at first place > > because is_blank()'s implementation checks for Page size and OOB area > size. > > is_blank() should be called per page for main and OOB area > verification. > > > > Variables name are redefined to avoid confusion between buffer and ecc > sector. > > > > Signed-off-by: Poonam Aggrwal > > Signed-off-by: Scott Wood > > Signed-off-by: Prabhakar Kushwaha > > The driver is not in 3.3-rc1, so I skip this patch. > This patch is squashed in Linux NAND driver patch. It will be provided by galak's tree "NAND Machine support for Integrated Flash Controller" http://patchwork.ozlabs.org/patch/137024/ --Prabhakar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/85xx: Save and restore pcie ATMU windows for PM
> -Original Message- > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > Sent: Friday, May 20, 2011 10:19 AM > To: Kushwaha Prabhakar-B32579 > Cc: linuxppc-dev@lists.ozlabs.org; meet2pra...@gmail.com; Jiang Yutang- > B14898 > Subject: Re: [PATCH] powerpc/85xx: Save and restore pcie ATMU windows for > PM > > > On May 19, 2011, at 11:41 PM, Kushwaha Prabhakar-B32579 wrote: > > > > > > >> -Original Message- > >> From: Kumar Gala [mailto:ga...@kernel.crashing.org] > >> Sent: Thursday, May 19, 2011 6:53 PM > >> To: Kushwaha Prabhakar-B32579 > >> Cc: linuxppc-dev@lists.ozlabs.org; meet2pra...@gmail.com; Jiang > >> Yutang- > >> B14898 > >> Subject: Re: [PATCH] powerpc/85xx: Save and restore pcie ATMU windows > >> for PM > >> > >> > >> On May 19, 2011, at 6:22 AM, Kushwaha Prabhakar-B32579 wrote: > >> > >>> Hi Kumar, > >>> Please find my answer in-lined > >>> > >>>> -Original Message- > >>>> From: Kumar Gala [mailto:ga...@kernel.crashing.org] > >>>> Sent: Thursday, May 19, 2011 12:00 PM > >>>> To: Kushwaha Prabhakar-B32579 > >>>> Cc: linuxppc-dev@lists.ozlabs.org; meet2pra...@gmail.com; Jiang > >>>> Yutang- > >>>> B14898 > >>>> Subject: Re: [PATCH] powerpc/85xx: Save and restore pcie ATMU > >>>> windows for PM > >>>> > >>>> > >>>> On Apr 28, 2011, at 1:38 AM, Prabhakar Kushwaha wrote: > >>>> > >>>>> D3-cold state indicates removal of the clock and power. however > >>>>> auxiliary (AUX) Power may remain available even after the main > >>>>> power > >>>> rails are powered down. > >>>>> > >>>>> wakeup from D3-cold state requires full context restore. Other > >>>>> things are taken care in pci-driver except ATMUs. > >>>>> ATMU windows needs to be saved and restored during suspend and > >> resume. > >>>>> > >>>>> Signed-off-by: Jiang Yutang > >>>>> Signed-off-by: Prabhakar Kushwaha > >>>>> --- > >>>>> Based upon > >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.g > >>>>> it > >>>>> (b > >>>>> ranch master) > >>>>> > >>>>> arch/powerpc/sysdev/fsl_pci.c | 116 > >>>> + > >>>>> arch/powerpc/sysdev/fsl_pci.h |7 ++- > >>>>> 2 files changed, 121 insertions(+), 2 deletions(-) > >>>> > >>>> Is this patch for when we are a host or agent? > >>> > >>> This patch is independent of host or agent. It is for supporting D3 > >> cold state for P1022. > >>> These functions are called during System level suspend and resume. > >>> > >>> --Prabhakar > >> > >> I'm trying to figure out why this is limited to P1022. > > > > Till now, No SOC was supporting D3 cold state. First time P1022 > supporting it. > > Note: D3 cold state == PCIe block Power down > > > > I'm wondering a few things: > > 1. Is there any reason not to do this for ALL FSL PCIe SoCs? Yes, I am agree with you. It can be done. But as only P1022 SOC supporting it. There is no use of handling it. > 2. why do bother saving state, we don't we re-parse the .dts and > reconfigure ATMUs that way? I also thought of this case. But Agent use case scenario forbid me to do this. As ATMU's are programmed by host depending upon different use case . And this information is never stored in the dts. --Prabhakar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/85xx: Save and restore pcie ATMU windows for PM
> -Original Message- > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > Sent: Thursday, May 19, 2011 6:53 PM > To: Kushwaha Prabhakar-B32579 > Cc: linuxppc-dev@lists.ozlabs.org; meet2pra...@gmail.com; Jiang Yutang- > B14898 > Subject: Re: [PATCH] powerpc/85xx: Save and restore pcie ATMU windows for > PM > > > On May 19, 2011, at 6:22 AM, Kushwaha Prabhakar-B32579 wrote: > > > Hi Kumar, > > Please find my answer in-lined > > > >> -Original Message- > >> From: Kumar Gala [mailto:ga...@kernel.crashing.org] > >> Sent: Thursday, May 19, 2011 12:00 PM > >> To: Kushwaha Prabhakar-B32579 > >> Cc: linuxppc-dev@lists.ozlabs.org; meet2pra...@gmail.com; Jiang > >> Yutang- > >> B14898 > >> Subject: Re: [PATCH] powerpc/85xx: Save and restore pcie ATMU windows > >> for PM > >> > >> > >> On Apr 28, 2011, at 1:38 AM, Prabhakar Kushwaha wrote: > >> > >>> D3-cold state indicates removal of the clock and power. however > >>> auxiliary (AUX) Power may remain available even after the main power > >> rails are powered down. > >>> > >>> wakeup from D3-cold state requires full context restore. Other > >>> things are taken care in pci-driver except ATMUs. > >>> ATMU windows needs to be saved and restored during suspend and > resume. > >>> > >>> Signed-off-by: Jiang Yutang > >>> Signed-off-by: Prabhakar Kushwaha > >>> --- > >>> Based upon > >>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > >>> (b > >>> ranch master) > >>> > >>> arch/powerpc/sysdev/fsl_pci.c | 116 > >> + > >>> arch/powerpc/sysdev/fsl_pci.h |7 ++- > >>> 2 files changed, 121 insertions(+), 2 deletions(-) > >> > >> Is this patch for when we are a host or agent? > > > > This patch is independent of host or agent. It is for supporting D3 > cold state for P1022. > > These functions are called during System level suspend and resume. > > > > --Prabhakar > > I'm trying to figure out why this is limited to P1022. Till now, No SOC was supporting D3 cold state. First time P1022 supporting it. Note: D3 cold state == PCIe block Power down --Prabhakar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/85xx: add host-pci(e) bridge only for RC
Hello Kumar,
Please find my answer in-lined
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Thursday, May 19, 2011 11:55 AM
> To: Kushwaha Prabhakar-B32579
> Cc: linuxppc-dev@lists.ozlabs.org; meet2pra...@gmail.com; Vivek Mahajan
> Subject: Re: [PATCH] powerpc/85xx: add host-pci(e) bridge only for RC
>
>
> On Apr 27, 2011, at 12:35 AM, Prabhakar Kushwaha wrote:
>
> > FSL PCIe controller can act as agent(EP) or host(RC).
> > Under Agent(EP) mode they are configured via Host. So it is not
> > required to add with the PCI(e) sub-system.
> >
> > Add and configure PCIe controller only for RC mode.
> >
> > Signed-off-by: Vivek Mahajan
> > Signed-off-by: Prabhakar Kushwaha
> > ---
> > Based upon
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(b
> > ranch master)
> >
> > arch/powerpc/sysdev/fsl_pci.c | 14 ++
> > 1 files changed, 14 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/sysdev/fsl_pci.c
> > b/arch/powerpc/sysdev/fsl_pci.c index 68ca929..87ac11b 100644
> > --- a/arch/powerpc/sysdev/fsl_pci.c
> > +++ b/arch/powerpc/sysdev/fsl_pci.c
> > @@ -323,6 +323,7 @@ int __init fsl_add_bridge(struct device_node *dev,
> int is_primary)
> > struct pci_controller *hose;
> > struct resource rsrc;
> > const int *bus_range;
> > + u8 is_agent;
> >
> > if (!of_device_is_available(dev)) {
> > pr_warning("%s: disabled\n", dev->full_name); @@ -353,6
> +354,19 @@
> > int __init fsl_add_bridge(struct device_node *dev, int is_primary)
> >
> > setup_indirect_pci(hose, rsrc.start, rsrc.start + 0x4,
> > PPC_INDIRECT_TYPE_BIG_ENDIAN);
> > +
> > + early_read_config_byte(hose, 0, 0, PCI_HEADER_TYPE, &is_agent);
>
> Why are we looking at PCI_HEADER_TYPE? We should look at PCI_CLASS_PROG.
I think both are OK. We can check for any one.
Is there any problem with PCI_HEADER_TYPE?
> > + if ((is_agent & 0x7f) == PCI_HEADER_TYPE_NORMAL) {
> > + u32 temp;
> > +
> > + temp = (u32)hose->cfg_data & ~PAGE_MASK;
> > + if (((u32)hose->cfg_data & PAGE_MASK) != (u32)hose->cfg_addr)
> > + iounmap(hose->cfg_data - temp);
> > + iounmap(hose->cfg_addr);
> > + pcibios_free_controller(hose);
> > + return 0;
> > + }
> > +
> > setup_pci_cmd(hose);
> >
> > /* check PCI express link status */
> > --
> > 1.7.3
> >
> >
> > ___
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/85xx: Save and restore pcie ATMU windows for PM
Hi Kumar, Please find my answer in-lined > -Original Message- > From: Kumar Gala [mailto:ga...@kernel.crashing.org] > Sent: Thursday, May 19, 2011 12:00 PM > To: Kushwaha Prabhakar-B32579 > Cc: linuxppc-dev@lists.ozlabs.org; meet2pra...@gmail.com; Jiang Yutang- > B14898 > Subject: Re: [PATCH] powerpc/85xx: Save and restore pcie ATMU windows for > PM > > > On Apr 28, 2011, at 1:38 AM, Prabhakar Kushwaha wrote: > > > D3-cold state indicates removal of the clock and power. however > > auxiliary (AUX) Power may remain available even after the main power > rails are powered down. > > > > wakeup from D3-cold state requires full context restore. Other things > > are taken care in pci-driver except ATMUs. > > ATMU windows needs to be saved and restored during suspend and resume. > > > > Signed-off-by: Jiang Yutang > > Signed-off-by: Prabhakar Kushwaha > > --- > > Based upon > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(b > > ranch master) > > > > arch/powerpc/sysdev/fsl_pci.c | 116 > + > > arch/powerpc/sysdev/fsl_pci.h |7 ++- > > 2 files changed, 121 insertions(+), 2 deletions(-) > > Is this patch for when we are a host or agent? This patch is independent of host or agent. It is for supporting D3 cold state for P1022. These functions are called during System level suspend and resume. --Prabhakar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC v2] virtio: add virtio-over-PCI driver
Thanks Ira for your kind reply. I will look for the mentioned pointers :) Prabhakar > -Original Message- > From: Ira W. Snyder [mailto:i...@ovro.caltech.edu] > Sent: Friday, May 06, 2011 9:36 PM > To: Kushwaha Prabhakar-B32579 > Cc: Zang Roy-R61911; Gala Kumar-B11780; Gupta Maneesh-B18878; Aggrwal > Poonam-B10812; Kalra Ashish-B00888; linux-ker...@vger.kernel.org; > linuxppc-...@ozlabs.org; net...@vger.kernel.org > Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver > > On Fri, May 06, 2011 at 12:00:34PM +0000, Kushwaha Prabhakar-B32579 > wrote: > > Hi, > > > > I want to use this patch as base patch for "FSL 85xx platform" to > support PCIe Agent. > > The work looks to be little old now. So wanted to understand if any > development has happened further on it. > > > > In case no, I would take this work forward for PCIe Agent. > > > > Any help/suggestions are most appreciated in this regard. > > > > Hi Prabhakar, > > I use PCI agent mode on an mpc8349emds board. All of the important setup > is done very early in the boot process, by U-Boot. Search the U-Boot > source for CONFIG_PCISLAVE. I hunch that the setup needed for 85xx boards > are similar. > > This virtio-over-PCI work is now very old. It was intended to provide a > communication mechanism between a PCI Master and many PCI Agents > (slaves). > Dave Miller (networking maintainer) suggested to use virtio for this so > that many different devices could be used. Such as: > - network interface > - serial port (for serial console) > > I am aware of other ongoing work in this area. Specifically, some ARM > developers are working on a virtio API using their message registers. > This work is much newer, and will be a much better starting place for > you. > > Search the virtualization mailing list for: > "[PATCH 00/02] virtio: Virtio platform driver" > > Here is a link to some of their code: > http://www.spinics.net/lists/linux-sh/msg07188.html > > I am currently using a custom driver to provide a network device on my > PCI agents. Searching the mailing list archives for "PCINet", you will > find early versions of the driver. I am happy to provide you a current > copy. It does not use virtio at all, and is unlikely to be accepted into > mainline Linux. > > I am happy to provide any of my code if you think it would help you get > started. Specifically, the current version of "PCINet" show how to use > the DMA controller in order to get good network performance. I am also > happy to help port code to 83xx, as well as test on 83xx. Please ask any > questions you may have. > > I have people ask about this code about once every two months. There is > plenty of interest in a mainline Linux solution to this problem. :) I > will be moving to 85xx someday, and I hope there is an accepted mainline > solution by then. > > I hope it helps, > Ira > > > -Original Message- > > From: linux-kernel-ow...@vger.kernel.org > > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Ira Snyder > > Sent: Friday, 27 February, 2009 3:19 AM > > To: Arnd Bergmann > > Cc: linux-ker...@vger.kernel.org; Rusty Russell; Jan-Bernd Themann; > > linuxppc-...@ozlabs.org; net...@vger.kernel.org > > Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver > > > > On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote: > > > On Thursday 26 February 2009, Ira Snyder wrote: > > > > On Thu, Feb 26, 2009 at 05:15:27PM +0100, Arnd Bergmann wrote: > > > > > > > > I think so too. I was just getting something working, and thought > > > > it would be better to have it "out there" rather than be working > > > > on it forever. I'll try to break things up as I have time. > > > > > > Ok, perfect! > > > > > > > For the "libraries", would you suggest breaking things into > > > > seperate code files, and using EXPORT_SYMBOL_GPL()? I'm not very > > > > familiar with doing that, I've mostly been writing code within the > > > > existing device driver frameworks. Or do I need export symbol at > all? I'm not sure... > > > > > > You have both options. When you list each file as a separate module > > > in the Makefile, you use EXPORT_SYMBOL_GPL to mark functions that > > > get called by dependent modules, but this will work only in one way. > > > > > > You can also link multiple files together into one module, although > > > it is less common to link a single source file into multiple modu
[RFC v2] virtio: add virtio-over-PCI driver
Hi,
I want to use this patch as base patch for "FSL 85xx platform" to support PCIe
Agent.
The work looks to be little old now. So wanted to understand if any development
has happened further on it.
In case no, I would take this work forward for PCIe Agent.
Any help/suggestions are most appreciated in this regard.
Thanks,
Prabhakar
-Original Message-
From: linux-kernel-ow...@vger.kernel.org
[mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Ira Snyder
Sent: Friday, 27 February, 2009 3:19 AM
To: Arnd Bergmann
Cc: linux-ker...@vger.kernel.org; Rusty Russell; Jan-Bernd Themann;
linuxppc-...@ozlabs.org; net...@vger.kernel.org
Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver
On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote:
> On Thursday 26 February 2009, Ira Snyder wrote:
> > On Thu, Feb 26, 2009 at 05:15:27PM +0100, Arnd Bergmann wrote:
> >
> > I think so too. I was just getting something working, and thought it
> > would be better to have it "out there" rather than be working on it
> > forever. I'll try to break things up as I have time.
>
> Ok, perfect!
>
> > For the "libraries", would you suggest breaking things into seperate
> > code files, and using EXPORT_SYMBOL_GPL()? I'm not very familiar
> > with doing that, I've mostly been writing code within the existing
> > device driver frameworks. Or do I need export symbol at all? I'm not sure...
>
> You have both options. When you list each file as a separate module in
> the Makefile, you use EXPORT_SYMBOL_GPL to mark functions that get
> called by dependent modules, but this will work only in one way.
>
> You can also link multiple files together into one module, although it
> is less common to link a single source file into multiple modules.
>
Ok. I'm more familiar with the EXPORT_SYMBOL_GPL interface, so I'll do that. If
we decide it sucks later, we'll change it.
> > I always thought you were supposed to use packed for data structures
> > that are external to the system. I purposely designed the structures
> > so they wouldn't need padding.
>
> That would only make sense for structures that are explicitly
> unaligned, like a register layout using
>
> struct my_registers {
> __le16 first;
> __le32 second __attribute__((packed));
> __le16 third;
> };
>
> Even here, I'd recommend listing the individual members as packed
> rather than the entire struct. Obviously if you layout the members in
> a sane way, you don't need either.
>
Ok. I'll drop the __attribute__((packed)) and make sure there aren't problems.
I don't suspect any, though.
> > I mostly don't need it. In fact, the only place I'm using registers
> > not specific to the messaging unit is in the probe routine, where I
> > setup the 1GB window into host memory and setting up access to the
> > guest memory on the PCI bus.
>
> You could add the registers you need for this to the "reg" property of
> your device, to be mapped with of_iomap.
>
> If the registers for setting up this window don't logically fit into
> the same device as the one you already use, the cleanest solution
> would be to have another device just for this and then make a function
> call into that driver to set up the window.
>
The registers are part of the board control registers. They don't fit at all in
the message unit. Doing this in the bootloader seems like a logical place, but
that would require any testers to flash a new U-Boot image into their
mpc8349emds boards.
The first set of access is used to set up a 1GB region in the memory map that
accesses the host's memory. Any reads/writes to addresses 0x8000-0xc000
actually hit the host's memory.
The last access sets up PCI BAR1 to hit the memory from dma_alloc_coherent().
The bootloader already sets up the window as 16K, it just doesn't point it
anywhere. Maybe this /should/ go into the bootloader. Like above, it would
require testers to flash a new U-Boot image into their mpc8349emds boards.
> > Now, I wouldn't need to access these registers at all if the
> > bootloader could handle it. I just don't know if it is possible to
> > have Linux not use some memory that the bootloader allocated, other
> > than with the mem=XXX trick, which I'm sure wouldn't be acceptable.
> > I've just used regular RAM so this is portable to my custom board
> > (mpc8349emds based) and a regular mpc8349emds. I didn't want to
> > change anything board specific.
> >
> > I would love to have the bootloader allocate (or reserve somewhere
> > in the memory map) 16K of RAM, and not be required to allocate it
> > with dma_alloc_coherent(). It would save me plenty of headaches.
>
> I believe you can do that through the "memory" devices in the device
> tree, by leaving out a small part of the description of main memory,
> at putting it into the "reg" property of your own device.
>
I'll explore this option. I didn't even know you could do this. Is a driver
that requires the trick
RE: [PATCH 2/2] powerpc: add support for MPIC message register API
> > > > > > > > > Hi, > > > > > > > > I have no comments about coding and architecture. It looks fine. > > > > > > > > Only have a query about its use case.. > > > >"Any application intended to use message interrupt requires to > > > > know > > > reg_num because of struct mpic_msgr* mpic_msgr_get(unsigned int > > > reg_num) API" > > > > > > > > It will be good to search available unit internally and provide > > > > its > > > pointer. It will make application more flexible. > > > > > > > > > > The problem is that you fundamentally cannot implement an allocator > > > for MSG registers if you're going to communicate with another kernel > > > (how would both kernels' allocators be synchronized?). So the > > > message register allocation must be decided at design time, not run > time. > > > > > > > I agree with you.. It is true while communicating with another kernel. > > But message interrupts can be used by different independent drivers > within same kernel. For eg. PCIe and Ethernet driver. > > As per current design both drivers needs to be in sync before > requesting any message unit for avoiding any conflict. As these drivers > are completely independent. It is very difficult. > > > > Can it be possible to provide new API to take care it. > > Do you have a real use case in mind where these message registers (not > MSIs) are used internally in this manner? Yes, we use for PCIe host/agent test case scenario. Host usage message register to interrupt Agent... Agent uses message register to generate irq_out (automatically generate MSI) to interrupt master. Please see RM for more details about irq_out Note: PCIe host/agent test scenario is used internally and we are working on pushing it out.. > Perhaps an allocator could be added in the same patchset that adds such a > user. > Yaa. It can be done. Otherwise module has to query each message unit for its availability. --Prabhakar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] powerpc: add support for MPIC message register API
> > Hi, > > > > I have no comments about coding and architecture. It looks fine. > > > > Only have a query about its use case.. > >"Any application intended to use message interrupt requires to know > reg_num because of struct mpic_msgr* mpic_msgr_get(unsigned int reg_num) > API" > > > > It will be good to search available unit internally and provide its > pointer. It will make application more flexible. > > > > The problem is that you fundamentally cannot implement an allocator for > MSG registers if you're going to communicate with another kernel (how > would both kernels' allocators be synchronized?). So the message register > allocation must be decided at design time, not run time. > I agree with you.. It is true while communicating with another kernel. But message interrupts can be used by different independent drivers within same kernel. For eg. PCIe and Ethernet driver. As per current design both drivers needs to be in sync before requesting any message unit for avoiding any conflict. As these drivers are completely independent. It is very difficult. Can it be possible to provide new API to take care it. --Prabhakar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] powerpc: add support for MPIC message register API
Hi,
I have no comments about coding and architecture. It looks fine.
Only have a query about its use case..
"Any application intended to use message interrupt requires to know reg_num
because of struct mpic_msgr* mpic_msgr_get(unsigned int reg_num) API"
It will be good to search available unit internally and provide its pointer. It
will make application more flexible.
Regards,
Prabhakar
> -Original Message-
> From: devicetree-discuss-bounces+b32579=freescale@lists.ozlabs.org
> [mailto:devicetree-discuss-bounces+b32579=freescale@lists.ozlabs.org]
> On Behalf Of Meador Inge
> Sent: Tuesday, April 19, 2011 10:30 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: openmcapi-...@googlegroups.com; devicetree-disc...@lists.ozlabs.org;
> Hollis Blanchard
> Subject: [PATCH 2/2] powerpc: add support for MPIC message register API
>
> Some MPIC implementations contain one or more blocks of message registers
> that are used to send messages between cores via IPIs. A simple API has
> been added to access (get/put, read, write, etc ...) these message
> registers.
> The available message registers are initially discovered via nodes in the
> device tree. A separate commit contains a binding for the message
> register nodes.
>
> Signed-off-by: Meador Inge
> Cc: Benjamin Herrenschmidt
> Cc: Hollis Blanchard
> ---
> arch/powerpc/include/asm/mpic_msgr.h | 35 +
> arch/powerpc/platforms/Kconfig |8 +
> arch/powerpc/sysdev/Makefile |3 +-
> arch/powerpc/sysdev/mpic_msgr.c | 279
> ++
> 4 files changed, 324 insertions(+), 1 deletions(-) create mode 100644
> arch/powerpc/include/asm/mpic_msgr.h
> create mode 100644 arch/powerpc/sysdev/mpic_msgr.c
>
> diff --git a/arch/powerpc/include/asm/mpic_msgr.h
> b/arch/powerpc/include/asm/mpic_msgr.h
> new file mode 100644
> index 000..370dcb4
> --- /dev/null
> +++ b/arch/powerpc/include/asm/mpic_msgr.h
> @@ -0,0 +1,35 @@
> +/*
> + * Copyright 2011-2012, Meador Inge, Mentor Graphics Corporation.
> + *
> + * 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; version 2 of the
> + * License.
> + *
> + */
> +
> +#ifndef _ASM_MPIC_MSGR_H
> +#define _ASM_MPIC_MSGR_H
> +
> +#include
> +
> +struct mpic_msgr {
> + u32 __iomem *addr;
> + u32 __iomem *mer;
> + u32 __iomem *msr;
> + int irq;
> + atomic_t in_use;
> + int num;
> +};
> +
> +extern struct mpic_msgr* mpic_msgr_get(unsigned int reg_num); extern
> +void mpic_msgr_put(struct mpic_msgr* msgr); extern void
> +mpic_msgr_enable(struct mpic_msgr *msgr); extern void
> +mpic_msgr_disable(struct mpic_msgr *msgr); extern void
> +mpic_msgr_write(struct mpic_msgr *msgr, u32 message); extern u32
> +mpic_msgr_read(struct mpic_msgr *msgr); extern void
> +mpic_msgr_clear(struct mpic_msgr *msgr); extern void
> +mpic_msgr_set_destination(struct mpic_msgr *msgr, u32 cpu_num); extern
> +int mpic_msgr_get_irq(struct mpic_msgr *msgr);
> +
> +#endif
> diff --git a/arch/powerpc/platforms/Kconfig
> b/arch/powerpc/platforms/Kconfig index f7b0772..4d65593 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -78,6 +78,14 @@ config MPIC_WEIRD
> bool
> default n
>
> +config MPIC_MSGR
> + bool "MPIC message register support"
> + depends on MPIC
> + default n
> + help
> + Enables support for the MPIC message registers. These
> + registers are used for inter-processor communication.
> +
> config PPC_I8259
> bool
> default n
> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
> index 1e0c933..6d40185 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -3,7 +3,8 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
> ccflags-$(CONFIG_PPC64) := -mno-minimal-toc
>
> mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o
> mpic_pasemi_msi.o
> -obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
> +mpic-msgr-obj-$(CONFIG_MPIC_MSGR)+= mpic_msgr.o
> +obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y) $(mpic-msgr-
> obj-y)
> fsl-msi-obj-$(CONFIG_PCI_MSI)+= fsl_msi.o
> obj-$(CONFIG_PPC_MSI_BITMAP) += msi_bitmap.o
>
> diff --git a/arch/powerpc/sysdev/mpic_msgr.c
> b/arch/powerpc/sysdev/mpic_msgr.c new file mode 100644 index
> 000..352bfa6
> --- /dev/null
> +++ b/arch/powerpc/sysdev/mpic_msgr.c
> @@ -0,0 +1,279 @@
> +/*
> + * Copyright 2011-2012, Meador Inge, Mentor Graphics Corporation.
> + *
> + * Some ideas based on un-pushed work done by Vivek Mahajan, Jason Jin,
> +and
> + * Mingkai Hu from 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; version 2 of the
> + * Li
RE: Problem with mini-PCI-E slot on P2020RDB
Added Linxppc-dev > -Original Message- > From: Aggrwal Poonam-B10812 > Sent: Friday, April 15, 2011 11:47 AM > To: Felix Radensky > Cc: Kushwaha Prabhakar-B32579; leon.woestenb...@gmail.com > Subject: FW: Problem with mini-PCI-E slot on P2020RDB > > Hello Felix > > We checked with the Board designer, we need the board fixes "mentioned in > Board errata doc" on the board for this issue. Sorry for the confusion. > > The fixes are not present on RevC, also on some RevDs this fix also may > be absent. > > > Please let us know in case of any issues. > > Regards > Poonam > > > -Original Message- > > From: Leon Woestenberg [mailto:leon.woestenb...@gmail.com] > > Sent: Wednesday, April 13, 2011 2:52 PM > > To: Felix Radensky > > Cc: Aggrwal Poonam-B10812; linuxppc-...@ozlabs.org; Gupta > > Maneesh-B18878; Kushwaha Prabhakar-B32579 > > Subject: Re: Problem with mini-PCI-E slot on P2020RDB > > > > Felix, > > > > On Tue, Apr 12, 2011 at 6:54 AM, Felix Radensky > > > > wrote: > > > On 04/12/2011 07:05 AM, Aggrwal Poonam-B10812 wrote: > > >> As such there is no hardware fix related to this issue between RevC > > >> to RevD. The solution was a software patch to resolve the issue > > >> related to IRQ0. > > > > > > Are you sure ? Please take a look at Freescale document titled > > > "P1020E/P2020E RDB System Errata". > > > There's errata CE10, IRQ0 held low. It is fixed in Rev D. Vivek > > > Mahajan, who looked at the issue back in 2009, estimated that > > > problem can be related to missing pull-up on IRQ0. > > > This is exactly what is > > > fixed in Rev D. > > > > > > > That's my understanding as well. > > > > Check if R420 and R423 are populated. These are the required pull-ups. > > On Rev D they are populated. You might be able to add them yourself. > > > > Even if you have an Rev A-C PCB, this fix can already be applied; it > > was on my board! (the bottom of the board mentions the schematic > > revision) > > > > The resistors have a silkscreen designator block called X, the > > resistors are situated to the left and bottom of the silkscreen X. > > IIRC, between the flash and Px020 part. > > > > On the left side of R420 (or R423) I measured the block wave from the > > RTC, which fires the 32kHz interrupt rate on IRQ0. This fixed by the > > u- boot patch. > > > > Regards, > > > > Leon. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with mini-PCI-E slot on P2020RDB
Hi Felix, > -Original Message- > From: linuxppc-dev-bounces+priyanka.jain=freescale@lists.ozlabs.org > [mailto:linuxppc-dev- > bounces+priyanka.jain=freescale@lists.ozlabs.org] On Behalf Of Felix > Radensky > Sent: Tuesday, April 12, 2011 10:24 AM > To: Aggrwal Poonam-B10812 > Cc: linuxppc-...@ozlabs.org; Gupta Maneesh-B18878; Kushwaha Prabhakar- > B32579 > Subject: Re: Problem with mini-PCI-E slot on P2020RDB > > Hi Poonam > > On 04/12/2011 07:05 AM, Aggrwal Poonam-B10812 wrote: > > Hello Felix > > > > Please find some comments inline. > > > > Regards > > Poonam > > > >> -Original Message- > >> From: Kushwaha Prabhakar-B32579 > >> Sent: Tuesday, April 12, 2011 9:26 AM > >> To: Aggrwal Poonam-B10812 > >> Subject: FW: Problem with mini-PCI-E slot on P2020RDB > >> > >> > >> > >> -Original Message- > >> From: Felix Radensky [mailto:fe...@embedded-sol.com] > >> Sent: Monday, April 11, 2011 7:16 PM > >> To: Kushwaha Prabhakar-B32579 > >> Cc: Fabian Bertholm; Leon Woestenberg; linuxppc-...@ozlabs.org; > >> Mahajan Vivek-B08308; Aggrwal Poonam-B10812; Gupta Maneesh-B18878 > >> Subject: Re: Problem with mini-PCI-E slot on P2020RDB > >> > >> Hi Prabhakar, > >> > >> On 04/11/2011 02:09 PM, Kushwaha Prabhakar-B32579 wrote: > >>> Hi, > >>> > >>> Yes. It wil be applicable for all revisions. > >>> > >>> Regards, > >>> Prabhakar > >>> > >> I'm sure this is applicable to all revisions, but it doesn't > >> necessarily makes things work. The problem I've reported back in 2009 > >> still exists on P2020RDB revC, even if I use the latest u-boot and > >> kernel and make device tree changes that you've suggested. > >> I've attached the boot log. > > As such there is no hardware fix related to this issue between RevC to > RevD. The solution was a software patch to resolve the issue related to > IRQ0. > > Are you sure ? Please take a look at Freescale document titled > "P1020E/P2020E RDB System Errata". > There's errata CE10, IRQ0 held low. It is fixed in Rev D. Vivek Mahajan, > who looked at the issue back in 2009, estimated that problem can be > related to missing pull-up on IRQ0. This is exactly what is fixed in Rev > D. > We are looking into it and are in discussion with design team. We will keep you posted for the same.. --Prabhakar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with mini-PCI-E slot on P2020RDB
Hi, Yes. It wil be applicable for all revisions. Regards, Prabhakar > -Original Message- > From: Felix Radensky [mailto:fe...@embedded-sol.com] > Sent: Monday, April 11, 2011 2:10 PM > To: Kushwaha Prabhakar-B32579 > Cc: Fabian Bertholm; Leon Woestenberg; linuxppc-...@ozlabs.org; Mahajan > Vivek-B08308; Aggrwal Poonam-B10812; Gupta Maneesh-B18878 > Subject: Re: Problem with mini-PCI-E slot on P2020RDB > > Hi, > > Assuming I have all patches in place, will this problem be resolved on > earlier board revisions (before rev D) ? > > Felix. > > On 04/11/2011 12:06 PM, Kushwaha Prabhakar-B32579 wrote: > > Hi Fabe, > > > > Yes .. P1020/P1011 RDB has same issue as of P2020RDB. > > > > It was because of some missing patches at u-boot and Linux. > > > > U-boot patch : It is already present in open source. Please use latest > > code base Linux patch : I am in process of posting in open source. > Please make mentioned changes of IDSEL. > > > > --Prabhakar > > > >> -Original Message----- > >> From: Fabian Bertholm [mailto:fabeisag...@googlemail.com] > >> Sent: Monday, April 11, 2011 1:53 PM > >> To: Kushwaha Prabhakar-B32579 > >> Cc: Leon Woestenberg; linuxppc-...@ozlabs.org; Mahajan Vivek-B08308; > >> Felix Radensky; Aggrwal Poonam-B10812; Gupta Maneesh-B18878 > >> Subject: Re: Problem with mini-PCI-E slot on P2020RDB > >> > >> Hello Kushwaha Prabhakar, > >> > >> Our impression is that there is the same issue on the P1020/P1011 RDB. > >> Can you confirm this? > >> > >> Best Regards, > >> Fabe > >> > >> > >> 2011/4/8 Kushwaha Prabhakar-B32579: > >>> > >>>> -Original Message- > >>>> From: Leon Woestenberg [mailto:leon.woestenb...@gmail.com] > >>>> Sent: Thursday, April 07, 2011 10:50 PM > >>>> To: linuxppc-...@ozlabs.org > >>>> Cc: Kumar Gala; Mahajan Vivek-B08308; Aggrwal Poonam-B10812; Felix > >>>> Radensky; Kushwaha Prabhakar-B32579 > >>>> Subject: Re: Problem with mini-PCI-E slot on P2020RDB > >>>> > >>>> Hello, > >>>> > >>>> On Thu, Dec 17, 2009 at 9:28 PM, Felix Radensky > >>>> > >>>> wrote: > >>>>> Kumar Gala wrote: > >>>>>> On Dec 17, 2009, at 2:59 AM, Mahajan Vivek-B08308 wrote: > >>>>>>>> Thanks a lot. If I understand you correctly, the only way I can > >>>>>>>> get ath9k driver to work on this board using legacy interrupts > >>>>>>>> is to wait for a hardware fix. Right ? > >>>>>>>> > >>>>>>> Correct > >>>>>> I'm confused. What's the issue with IRQ0 on the P2020RDB? Is it > >>>>>> used for another purpose? > >>>>> There's a problem with IRQ0 with respect to mini-PCI-E slot. I > >>>>> have Atheros wireless card plugged into it. ath9k wireless driver > >>>>> for this card uses legacy PCI-E interrupts, and I get "irq 16: > >>>>> nobody > >> cared" > >>>>> message when driver executes request_irq(). Vivek has come to a > >>>>> conclusion that the problem is related to incorrect IRQ0 routing > >>>>> for mini-PCI-E slot on P2020RDB. > >>>>> > >>>> I would like to understand this issue better, as I seem to be > >>>> running into something similar, and it puts my board design on hold. > >>>> > >>>> Can someone (from Freescale) explain what happens if a PCI Express > >>>> end point on the mini-PCIe slot raises a legacy interrupt, and > >>>> where this goes wrong? > >>>> > >>>> From what document or source code file can I conclude that the > >>>> PCIe legacy interrupt is shared with IRQ0? > >>>> > >>>> > >>>> I found this: > >>>> > >>>> P1020E/P2020E RDB System Errata, Last Update: 2/15/2010: > >>>> Problem:IRQ0 held low > >>>> Fix: Add 4.7K pull-up (to 3.3.V) for RTC_INT_N. > >>>> See R420 in Rev D schematic. > >>>> Add 4.7K pull-up (to 3.3.V) for MCU_INT_N. > >>>> See R423 in Rev D schematic. > >>>> > >>>> > >>> Hello Leon, > >>> > >>> Yes you are right, PCIe leagacy interrupt is shared with IRQ0. For > >> Atheros issue. > >>> Can you please try followings, Meanwhile I will try to dig into it. > >>> > >>> http://old.nabble.com/Problem-with-mini-PCI-E-slot-on-P2020RDB-td268 > >>> 02 > >>> 038.html > >>> > >>> Regarding sata_sil24, Please see my e-mail on Linux-ide for correct > >> IDSEL value. > >>> Please first try IDSEL value mentioned in email on Linux-ide. Then > >>> try > >> this URL.. > >>> --Prabhakar > >>> > >>> ___ > >>> Linuxppc-dev mailing list > >>> Linuxppc-dev@lists.ozlabs.org > >>> https://lists.ozlabs.org/listinfo/linuxppc-dev > >>> > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with mini-PCI-E slot on P2020RDB
Hi Fabe, Yes .. P1020/P1011 RDB has same issue as of P2020RDB. It was because of some missing patches at u-boot and Linux. U-boot patch : It is already present in open source. Please use latest code base Linux patch : I am in process of posting in open source. Please make mentioned changes of IDSEL. --Prabhakar > -Original Message- > From: Fabian Bertholm [mailto:fabeisag...@googlemail.com] > Sent: Monday, April 11, 2011 1:53 PM > To: Kushwaha Prabhakar-B32579 > Cc: Leon Woestenberg; linuxppc-...@ozlabs.org; Mahajan Vivek-B08308; > Felix Radensky; Aggrwal Poonam-B10812; Gupta Maneesh-B18878 > Subject: Re: Problem with mini-PCI-E slot on P2020RDB > > Hello Kushwaha Prabhakar, > > Our impression is that there is the same issue on the P1020/P1011 RDB. > Can you confirm this? > > Best Regards, > Fabe > > > 2011/4/8 Kushwaha Prabhakar-B32579 : > > > > > >> -Original Message- > >> From: Leon Woestenberg [mailto:leon.woestenb...@gmail.com] > >> Sent: Thursday, April 07, 2011 10:50 PM > >> To: linuxppc-...@ozlabs.org > >> Cc: Kumar Gala; Mahajan Vivek-B08308; Aggrwal Poonam-B10812; Felix > >> Radensky; Kushwaha Prabhakar-B32579 > >> Subject: Re: Problem with mini-PCI-E slot on P2020RDB > >> > >> Hello, > >> > >> On Thu, Dec 17, 2009 at 9:28 PM, Felix Radensky > >> > >> wrote: > >> > Kumar Gala wrote: > >> >> On Dec 17, 2009, at 2:59 AM, Mahajan Vivek-B08308 wrote: > >> >>>> Thanks a lot. If I understand you correctly, the only way I can > >> >>>> get ath9k driver to work on this board using legacy interrupts > >> >>>> is to wait for a hardware fix. Right ? > >> >>>> > >> >>> Correct > >> >> > >> >> I'm confused. What's the issue with IRQ0 on the P2020RDB? Is it > >> >> used for another purpose? > >> > > >> > There's a problem with IRQ0 with respect to mini-PCI-E slot. I have > >> > Atheros wireless card plugged into it. ath9k wireless driver for > >> > this card uses legacy PCI-E interrupts, and I get "irq 16: nobody > cared" > >> > message when driver executes request_irq(). Vivek has come to a > >> > conclusion that the problem is related to incorrect IRQ0 routing > >> > for mini-PCI-E slot on P2020RDB. > >> > > >> > >> I would like to understand this issue better, as I seem to be running > >> into something similar, and it puts my board design on hold. > >> > >> Can someone (from Freescale) explain what happens if a PCI Express > >> end point on the mini-PCIe slot raises a legacy interrupt, and where > >> this goes wrong? > >> > >> From what document or source code file can I conclude that the PCIe > >> legacy interrupt is shared with IRQ0? > >> > >> > >> I found this: > >> > >> P1020E/P2020E RDB System Errata, Last Update: 2/15/2010: > >> Problem:IRQ0 held low > >> Fix: Add 4.7K pull-up (to 3.3.V) for RTC_INT_N. > >> See R420 in Rev D schematic. > >> Add 4.7K pull-up (to 3.3.V) for MCU_INT_N. > >> See R423 in Rev D schematic. > >> > >> > > > > Hello Leon, > > > > Yes you are right, PCIe leagacy interrupt is shared with IRQ0. For > Atheros issue. > > Can you please try followings, Meanwhile I will try to dig into it. > > > > http://old.nabble.com/Problem-with-mini-PCI-E-slot-on-P2020RDB-td26802 > > 038.html > > > > Regarding sata_sil24, Please see my e-mail on Linux-ide for correct > IDSEL value. > > Please first try IDSEL value mentioned in email on Linux-ide. Then try > this URL.. > > > > --Prabhakar > > > > ___ > > Linuxppc-dev mailing list > > Linuxppc-dev@lists.ozlabs.org > > https://lists.ozlabs.org/listinfo/linuxppc-dev > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: known working sata_sil24.c setup on powerpc platforms?
Hi Leon,
interrupt-map-mask is missing for pcie@ffe0a000 node. Please see my comment
there...
pcie@ffe0a000 node deals with mini-PCIe.
one more thing, can you please tell P1020Si version. It will be there on u-boot
log.
--Prabhakar
> -Original Message-
> From: Leon Woestenberg [mailto:leon.woestenb...@gmail.com]
> Sent: Friday, April 08, 2011 2:43 PM
> To: Kushwaha Prabhakar-B32579
> Cc: Moffett, Kyle D; linux-...@vger.kernel.org; Tejun Heo; Jeff Garzik;
> Linux PPC; Gupta Maneesh-B18878
> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
>
> Hello Prabhakar,
>
> On Fri, Apr 8, 2011 at 10:31 AM, Kushwaha Prabhakar-B32579
> wrote:
> > Hi Leon,
> >
> >
> >> -Original Message-
> >> From: Leon Woestenberg [mailto:leon.woestenb...@gmail.com]
> >> Sent: Friday, April 08, 2011 1:55 PM
> >> To: Kushwaha Prabhakar-B32579
> >> Cc: Moffett, Kyle D; linux-...@vger.kernel.org; Tejun Heo; Jeff
> >> Garzik; Linux PPC; Gupta Maneesh-B18878
> >> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
> >>
> >> Hello Prabhakar,
> >>
> >> On Fri, Apr 8, 2011 at 5:44 AM, Kushwaha Prabhakar-B32579
> >> wrote:
> >> >> -Original Message-
> >> >> From: linux-ide-ow...@vger.kernel.org [mailto:linux-ide-
> >> >> ow...@vger.kernel.org] On Behalf Of Leon Woestenberg
> >> >> Sent: Thursday, April 07, 2011 10:23 PM
> >> >> To: Kushwaha Prabhakar-B32579
> >> >> Cc: Moffett, Kyle D; Linux PPC; linux-...@vger.kernel.org; Tejun
> >> >> Heo; Jeff Garzik
> >> >> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
> >> >>
> >> >> On Thu, Apr 7, 2011 at 6:48 AM, Kushwaha Prabhakar-B32579
> >> >> wrote:
> >> >> > Can you please check p2020rdb.dts for IDSEL entries for pci0/1
> node?
> >> >> >
> >> >> > In order to work in legacy mode, IDSEL entries are required.
> >> >> >
> >> >> No, the p1020rdb and p2020rdb do not have the IDSEL entries:
> >> >> What would the correct IDSEL entries be?
> >> >
> >> > For legacy interrupt to work IDSEL values are required.. please
> >> > find
> >> the correct IDSEL values for pci0/1.
> >> >
> >> > pci0: pcie@ffe09000 {
> >> > ...
> >> > Please try with this.. I am in process of pushing these IDSEL
> >> > values to
> >> upstream.
> >> >
> >>
> >> Do you have these for P1020RDB as well? I found a P1020RDB board
> >> that has the CE10 errata fixed, so IRQ0 is properly pulled up.
> >>
> >
> > Same IDSEL values are valid for P1020RDB also.
> >
> I compiled the new device tree binary, the dump is below(*) and booted
> the P1020RDB from that.
>
> I verified using an oscilloscope that IRQ0 indeed remains high.
>
> However, no interrupt seems to come in from the sata_sil24 driver, see
> boot log (**).
>
> (*) dtb dump:
> $ dtc -I dtb -O dts /tftpboot/p1020rdb/uImage.dtb
>
> pcie@ffe09000 {
> compatible = "fsl,mpc8548-pcie";
> device_type = "pci";
> #interrupt-cells = <0x1>;
> #size-cells = <0x2>;
> #address-cells = <0x3>;
> reg = <0x0 0xffe09000 0x0 0x1000>;
> bus-range = <0x0 0xff>;
> ranges = <0x200 0x0 0xa000 0x0 0xa000 0x0
> 0x2000 0x100 0x0 0x0 0x0 0xffc3 0x0 0x1>;
> clock-frequency = <0x1fca055>;
> interrupt-parent = <0x2>;
> interrupts = <0x10 0x2>;
> interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
> interrupt-map = <0x0 0x0 0x0 0x1 0x2 0x4 0x1 0x0 0x0 0x0 0x2
> 0x2 0x5
> 0x1 0x0 0x0 0x0 0x3 0x2 0x6 0x1 0x0 0x0 0x0 0x4 0x2 0x7 0x1>;
>
> pcie@0 {
> reg = <0x0 0x0 0x0 0x0 0x0>;
> #size-cells = <0x2>;
> #address-cells = <0x3>;
> device_type = "pci";
> ranges = <0x200 0x0 0xa000 0x200 0x0
> 0xa000 0x0 0x2000 0x100 0x0 0x0 0x100 0x0 0x0 0x0
> 0x10>;
> };
> };
>
> pcie@ffe0a000 {
> compatible = "fsl,mpc8548-pcie";
> device_type = &
RE: known working sata_sil24.c setup on powerpc platforms?
Hi Leon,
> -Original Message-
> From: Leon Woestenberg [mailto:leon.woestenb...@gmail.com]
> Sent: Friday, April 08, 2011 1:55 PM
> To: Kushwaha Prabhakar-B32579
> Cc: Moffett, Kyle D; linux-...@vger.kernel.org; Tejun Heo; Jeff Garzik;
> Linux PPC; Gupta Maneesh-B18878
> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
>
> Hello Prabhakar,
>
> On Fri, Apr 8, 2011 at 5:44 AM, Kushwaha Prabhakar-B32579
> wrote:
> >> -Original Message-
> >> From: linux-ide-ow...@vger.kernel.org [mailto:linux-ide-
> >> ow...@vger.kernel.org] On Behalf Of Leon Woestenberg
> >> Sent: Thursday, April 07, 2011 10:23 PM
> >> To: Kushwaha Prabhakar-B32579
> >> Cc: Moffett, Kyle D; Linux PPC; linux-...@vger.kernel.org; Tejun Heo;
> >> Jeff Garzik
> >> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
> >>
> >> On Thu, Apr 7, 2011 at 6:48 AM, Kushwaha Prabhakar-B32579
> >> wrote:
> >> > Can you please check p2020rdb.dts for IDSEL entries for pci0/1 node?
> >> >
> >> > In order to work in legacy mode, IDSEL entries are required.
> >> >
> >> No, the p1020rdb and p2020rdb do not have the IDSEL entries:
> >> What would the correct IDSEL entries be?
> >
> > For legacy interrupt to work IDSEL values are required.. please find
> the correct IDSEL values for pci0/1.
> >
> > pci0: pcie@ffe09000 {
> > ...
> > Please try with this.. I am in process of pushing these IDSEL values to
> upstream.
> >
>
> Do you have these for P1020RDB as well? I found a P1020RDB board that
> has the CE10 errata fixed, so IRQ0 is properly pulled up.
>
Same IDSEL values are valid for P1020RDB also.
--Prabhakar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with mini-PCI-E slot on P2020RDB
> -Original Message- > From: Leon Woestenberg [mailto:leon.woestenb...@gmail.com] > Sent: Thursday, April 07, 2011 10:50 PM > To: linuxppc-...@ozlabs.org > Cc: Kumar Gala; Mahajan Vivek-B08308; Aggrwal Poonam-B10812; Felix > Radensky; Kushwaha Prabhakar-B32579 > Subject: Re: Problem with mini-PCI-E slot on P2020RDB > > Hello, > > On Thu, Dec 17, 2009 at 9:28 PM, Felix Radensky > wrote: > > Kumar Gala wrote: > >> On Dec 17, 2009, at 2:59 AM, Mahajan Vivek-B08308 wrote: > >>>> Thanks a lot. If I understand you correctly, the only way I can get > >>>> ath9k driver to work on this board using legacy interrupts is to > >>>> wait for a hardware fix. Right ? > >>>> > >>> Correct > >> > >> I'm confused. What's the issue with IRQ0 on the P2020RDB? Is it > >> used for another purpose? > > > > There's a problem with IRQ0 with respect to mini-PCI-E slot. I have > > Atheros wireless card plugged into it. ath9k wireless driver for this > > card uses legacy PCI-E interrupts, and I get "irq 16: nobody cared" > > message when driver executes request_irq(). Vivek has come to a > > conclusion that the problem is related to incorrect IRQ0 routing for > > mini-PCI-E slot on P2020RDB. > > > > I would like to understand this issue better, as I seem to be running > into something similar, and it puts my board design on hold. > > Can someone (from Freescale) explain what happens if a PCI Express end > point on the mini-PCIe slot raises a legacy interrupt, and where this > goes wrong? > > From what document or source code file can I conclude that the PCIe > legacy interrupt is shared with IRQ0? > > > I found this: > > P1020E/P2020E RDB System Errata, Last Update: 2/15/2010: > Problem:IRQ0 held low > Fix: Add 4.7K pull-up (to 3.3.V) for RTC_INT_N. > See R420 in Rev D schematic. > Add 4.7K pull-up (to 3.3.V) for MCU_INT_N. > See R423 in Rev D schematic. > > Hello Leon, Yes you are right, PCIe leagacy interrupt is shared with IRQ0. For Atheros issue. Can you please try followings, Meanwhile I will try to dig into it. http://old.nabble.com/Problem-with-mini-PCI-E-slot-on-P2020RDB-td26802038.html Regarding sata_sil24, Please see my e-mail on Linux-ide for correct IDSEL value. Please first try IDSEL value mentioned in email on Linux-ide. Then try this URL.. --Prabhakar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: known working sata_sil24.c setup on powerpc platforms?
> -Original Message-
> From: linux-ide-ow...@vger.kernel.org [mailto:linux-ide-
> ow...@vger.kernel.org] On Behalf Of Leon Woestenberg
> Sent: Thursday, April 07, 2011 10:23 PM
> To: Kushwaha Prabhakar-B32579
> Cc: Moffett, Kyle D; Linux PPC; linux-...@vger.kernel.org; Tejun Heo;
> Jeff Garzik
> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
>
> Hello Prabhakar,
>
> thanks for your response. My answer below:
>
> On Thu, Apr 7, 2011 at 6:48 AM, Kushwaha Prabhakar-B32579
> wrote:
> > Hi Leon,
> >
> > Can you please check p2020rdb.dts for IDSEL entries for pci0/1 node?
> >
> > In order to work in legacy mode, IDSEL entries are required.
> >
> No, the p1020rdb and p2020rdb do not have the IDSEL entries:
>
> http://lxr.linux.no/#linux+v2.6.38/arch/powerpc/boot/dts/p2020rdb.dts
>
> whereas the p2020ds has:
>
> http://lxr.linux.no/#linux+v2.6.38/arch/powerpc/boot/dts/p2020ds.dts
>
>
> What would the correct IDSEL entries be?
For legacy interrupt to work IDSEL values are required.. please find the
correct IDSEL values for pci0/1.
pci0: pcie@ffe09000 {
---
---
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x0 */
0x0 0x0 0x1 &mpic 0x4 0x1
0x0 0x0 0x2 &mpic 0x5 0x1
0x0 0x0 0x3 &mpic 0x6 0x1
0x0 0x0 0x4 &mpic 0x7 0x1
>;
---
---
};
pci1: pcie@ffe0a000 {
---
---
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x0 */
0x0 0x0 0x1 &mpic 0x0 0x1
0x0 0x0 0x2 &mpic 0x1 0x1
0x0 0x0 0x3 &mpic 0x2 0x1
0x0 0x0 0x4 &mpic 0x3 0x1
>;
---
---
};
};
Please try with this.. I am in process of pushing these IDSEL values to
upstream.
> Also, did you see the reference to Felix' thread?
> "Problem with mini-PCI-E slot on P2020RDB"
>
I will look into it..
--Prabhakar
> >
> >> -Original Message-
> >> From: linux-ide-ow...@vger.kernel.org [mailto:linux-ide-
> >> ow...@vger.kernel.org] On Behalf Of Leon Woestenberg
> >> Sent: Thursday, April 07, 2011 12:20 AM
> >> To: Jeff Garzik
> >> Cc: Moffett, Kyle D; Linux PPC; linux-...@vger.kernel.org; Tejun Heo
> >> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
> >>
> >> Hello Jeff, all,
> >>
> >> On Wed, Apr 6, 2011 at 8:12 PM, Jeff Garzik wrote:
> >> > On 04/06/2011 01:48 PM, Moffett, Kyle D wrote:
> >> >> On Apr 06, 2011, at 13:00, Leon Woestenberg wrote:
> >> >>> after investigating problems with sata_sil24.c on a freescale
> >> >>> p2020 soc, I wonder if this driver works on powerpc at all?
> >> >>>
> >> >>> Does anyone know of a working setup of sata_sil24 on a big endian
> >> >>> powerpc system?
> >> >>
> >> >> Our P2020 boards work fine with legacy PCI interrupts (I think
> >> >> it's a
> >> >> sil3124 over PCI-E); the only deficiency is that MSI does not seem
> >> >> to
> >> work.
> >> >>
> >> >
> >> > We've definitely had issues with sata_sil24 + MSI, also...
> >> >
> >> > sata_sil24 does work on big endian in general.
> >> >
> >>
> >> On my system, I have the contrary to Kyle's experience (thanks for
> >> sharing).
> >>
> >> PowerPC P2020RDB
> >> vanilla 2.6.38
> >> Sil3132 on mini-PCI Express card
> >>
> >>
> >> Enabling msi gets me further than disabling it (default).
> >>
> >> modprobe sata_sil
> >>
> >> [ 8.834613] sata_sil24 0001:03:00.0: version 1.1 [ 8.885581]
> >> scsi0 : sata_sil24 [ 8.901420] scsi1 : sata_sil24 [ 8.904642]
> >> ata1: SATA max UDMA/100 host m128@0xc000 port 0xc0004000 irq 16 [
>
> >> 8.911961] ata2: SATA max UDMA/100 host m128@0xc000 port
> >> 0xc0006000 irq 16 [ 11.095127] ata1: SATA link up 3.0 Gbps (SStatus
> >> 123 SControl 0) [ 14.906986] eth0: no IPv6 routers present [
> >> 16.099016] ata1.00: qc timeout (
RE: known working sata_sil24.c setup on powerpc platforms?
Hi Leon, Can you please check p2020rdb.dts for IDSEL entries for pci0/1 node? In order to work in legacy mode, IDSEL entries are required. --Prabhakar > -Original Message- > From: linux-ide-ow...@vger.kernel.org [mailto:linux-ide- > ow...@vger.kernel.org] On Behalf Of Leon Woestenberg > Sent: Thursday, April 07, 2011 12:20 AM > To: Jeff Garzik > Cc: Moffett, Kyle D; Linux PPC; linux-...@vger.kernel.org; Tejun Heo > Subject: Re: known working sata_sil24.c setup on powerpc platforms? > > Hello Jeff, all, > > On Wed, Apr 6, 2011 at 8:12 PM, Jeff Garzik wrote: > > On 04/06/2011 01:48 PM, Moffett, Kyle D wrote: > >> On Apr 06, 2011, at 13:00, Leon Woestenberg wrote: > >>> after investigating problems with sata_sil24.c on a freescale p2020 > >>> soc, I wonder if this driver works on powerpc at all? > >>> > >>> Does anyone know of a working setup of sata_sil24 on a big endian > >>> powerpc system? > >> > >> Our P2020 boards work fine with legacy PCI interrupts (I think it's a > >> sil3124 over PCI-E); the only deficiency is that MSI does not seem to > work. > >> > > > > We've definitely had issues with sata_sil24 + MSI, also... > > > > sata_sil24 does work on big endian in general. > > > > On my system, I have the contrary to Kyle's experience (thanks for > sharing). > > PowerPC P2020RDB > vanilla 2.6.38 > Sil3132 on mini-PCI Express card > > > Enabling msi gets me further than disabling it (default). > > modprobe sata_sil > > [8.834613] sata_sil24 0001:03:00.0: version 1.1 > [8.885581] scsi0 : sata_sil24 > [8.901420] scsi1 : sata_sil24 > [8.904642] ata1: SATA max UDMA/100 host m128@0xc000 port > 0xc0004000 irq 16 > [8.911961] ata2: SATA max UDMA/100 host m128@0xc000 port > 0xc0006000 irq 16 > [ 11.095127] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0) > [ 14.906986] eth0: no IPv6 routers present > [ 16.099016] ata1.00: qc timeout (cmd 0xec) > [ 16.103128] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) > [ 18.299050] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0) > [ 28.303026] ata1.00: qc timeout (cmd 0xec) > [ 28.307139] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) > [ 28.313233] ata1: limiting SATA link speed to 1.5 Gbps > [ 30.523059] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 10) > > > modprobe sata_sil msi=1 > > [ 92.984120] sata_sil24 0001:03:00.0: version 1.1 > [ 92.988897] irq: irq 0 on host /soc@ffe0/msi@41600 mapped to > virtual irq 41 > [ 92.996229] sata_sil24 0001:03:00.0: Using MSI > [ 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering > [ 93.011628] scsi2 : sata_sil24 > [ 93.022463] scsi3 : sata_sil24 > [ 93.025695] ata3: SATA max UDMA/100 host m128@0xc000 port > 0xc0004000 irq 41 > [ 93.033023] ata4: SATA max UDMA/100 host m128@0xc000 port > 0xc0006000 irq 41 > [ 95.203029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0) > [ 95.209045] ata3: spurious interrupt (slot_stat 0x0 active_tag > -84148995 sactive 0x0) > [ 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max > UDMA/133 > [ 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth > 31/32) > [ 95.230905] ata3.00: configured for UDMA/100 > [ 95.235399] scsi 2:0:0:0: Direct-Access ATA INTEL > SSDSA2M080 2CV1 PQ: 0 ANSI: 5 > [ 95.244002] sd 2:0:0:0: Attached scsi generic sg0 type 0 > [ 95.252041] sd 2:0:0:0: [sda] 156301488 512-byte logical blocks: > (80.0 GB/74.5 GiB) > [ 95.260219] sd 2:0:0:0: [sda] Write Protect is off > [ 95.265063] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 > [ 95.270500] sd 2:0:0:0: [sda] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 95.283779] sda: sda1 sda2 sda3 sda4 > [ 95.289482] sd 2:0:0:0: [sda] Attached SCSI disk > [ 95.965897] EXT3-fs: barriers not enabled > [ 95.977279] kjournald starting. Commit interval 5 seconds > [ 95.983296] EXT3-fs (sda2): using internal journal > [ 95.988143] EXT3-fs (sda2): recovery complete > [ 95.992504] EXT3-fs (sda2): mounted filesystem with writeback data > mode > [ 96.111587] NTFS volume version 3.1. > [ 97.331005] ata4: SATA link down (SStatus 0 SControl 0) > > root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=1000 > 1000+0 records in > 1000+0 records out > 4096000 bytes (4.1 MB) copied, 0.0315629 s, 130 MB/s root@p1020rdb:~# dd > if=/dev/sda of=/dev/null bs=4k count=1 > 1+0 records in > 1+0 records out > 4096 bytes (41 MB) copied, 0.471802 s, 86.8 MB/s > > root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=10 > > That stalls, I see the controller fail. See dmesg below: > > ^C^Cdd: reading `/dev/sda': Input/output error > 51804+0 records in > 51804+0 records out > 212189184 bytes (212 MB) copied, 85.6537 s, 2.5 MB/s > dd: closing input file `/dev/sda': Bad file descriptor > > > [ 92.984120] sata_sil24 0001:03:00.0: version 1.1 > [ 92.988897] irq: irq 0 on host /soc@ffe0/msi@41600 mapped to > vir
Query: PCIe range entry at pcie@0 in dts files
Hi all,
I have query about usage of range field at pcie@0 under PCIe controller.
Please find snap shot from mpc8536_36.dts..
pci3: pcie@fffe0b000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <0xf 0xffe0b000 0 0x1000>;
bus-range = <0 0xff>;
ranges = <0x0200 0 0xe000 0xc 0x2000 0 0x2000
0x0100 0 0x 0xf 0xffc3 0 0x0001>;
clock-frequency = <>;
interrupt-parent = <&mpic>;
interrupts = <27 0x2>;
interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <
/* IDSEL 0x0 */
0 0 1 &mpic 8 1
0 0 2 &mpic 9 1
0 0 3 &mpic 10 1
0 0 4 &mpic 11 1
>;
pcie@0 {
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <0x0200 0 0xe000 --> child/port start
address
0x0200 0 0xe000 --> Parent bus address
0 0x2000
0x0100 0 0x
0x0100 0 0x
0 0x0010>;
};
};
Question:
A) is ranges filed of pcie@0 really required?
I just went through the code and found scan_OF_for_pci_dev() called
from pci_busdev_to_OF_node() touches pcie@0 node. But, It does not even uses
range filed.
static struct device_node *scan_OF_for_pci_dev(struct device_node
*parent,unsigned int devfn) {
---
---
for_each_child_of_node(parent, np) {
reg = of_get_property(np, "reg", &psize);
---
---
if (!strcmp(np->name, "multifunc-device")) {
}
I also checked "Power_ePAPR_APPROVED_v1.0.pdf". It never say range filed
required for child bus.
B) if range field of pcie@0 required. why does child/port start address same as
Parent bus address? Range property provides mapping of port address to parent
address space.
So the value should be 0x. Means port's address starting from
0x to size 0x2000 is mapped parent's 0xe000.
ranges = <0x0200 0 0x --> Child/port's
start address
0x0200 0 0xe000--> Parent bus
address
0 0x2000
0x0100 0 0x
0x0100 0 0x
0 0x0010>;
--Prabhakar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Query: PCIe range entry at pcie@0 in dts files
Hi all,
I have query about usage of range field at pcie@0 under PCIe controller.
Please find snap shot from mpc8536_36.dts..
pci3: pcie@fffe0b000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <0xf 0xffe0b000 0 0x1000>;
bus-range = <0 0xff>;
ranges = <0x0200 0 0xe000 0xc 0x2000 0 0x2000
0x0100 0 0x 0xf 0xffc3 0 0x0001>;
clock-frequency = <>;
interrupt-parent = <&mpic>;
interrupts = <27 0x2>;
interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <
/* IDSEL 0x0 */
0 0 1 &mpic 8 1
0 0 2 &mpic 9 1
0 0 3 &mpic 10 1
0 0 4 &mpic 11 1
>;
pcie@0 {
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <0x0200 0 0xe000 --> child/port start
address
0x0200 0 0xe000 --> Parent bus address
0 0x2000
0x0100 0 0x
0x0100 0 0x
0 0x0010>;
};
};
Question:
A) is ranges filed of pcie@0 really required?
I just went through the code and found scan_OF_for_pci_dev() called
from pci_busdev_to_OF_node() touches pcie@0 node. But, It does not even uses
range filed.
static struct device_node *scan_OF_for_pci_dev(struct device_node
*parent,unsigned int devfn) {
---
---
for_each_child_of_node(parent, np) {
reg = of_get_property(np, "reg", &psize);
---
---
if (!strcmp(np->name, "multifunc-device")) {
}
I also checked "Power_ePAPR_APPROVED_v1.0.pdf". It never say range filed
required for child bus.
B) if range field of pcie@0 required. why does child/port start address same as
Parent bus address? Range property provides mapping of port address to parent
address space.
So the value should be 0x. Means port's address starting from
0x to size 0x2000 is mapped parent's 0xe000.
ranges = <0x0200 0 0x --> Child/port's
start address
0x0200 0 0xe000--> Parent bus
address
0 0x2000
0x0100 0 0x
0x0100 0 0x
0 0x0010>;
--Prabhakar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][v3] driver/FSL SATA:Fix wrong Device Error Register usage
Hi Jeff,
I am not finding any new comments on this.
Could you please ACK this patch so that it can be applied on external list.
--Prabhakar
> -Original Message-
> From: Kushwaha Prabhakar-B32579
> Sent: Wednesday, March 09, 2011 12:47 PM
> To: linux-...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org; jgar...@pobox.com;
> meet2pra...@gmail.com; Kushwaha Prabhakar-B32579; Kalra Ashish-B00888
> Subject: [PATCH][v3] driver/FSL SATA:Fix wrong Device Error Register
> usage
>
> When a single device error is detected, the device under the error is
> indicated by the error bit set in the DER. There is a one to one mapping
> between register bit and devices on Port multiplier(PMP) i.e. bit 0
> represents PMP device 0 and bit 1 represents PMP device 1 etc.
>
> Current implementation treats Device error register value as device
> number not set of bits representing multiple device on PMP. It is changed
> to consider bit level.
> No need to check for each set bit as all command is going to be aborted.
>
> Signed-off-by: Ashish Kalra
> Signed-off-by: Prabhakar Kushwaha
> ---
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> (branch master)
>
> This patch is already gone through review of linuxppc-dev mail list.
> Making CC linuxppc-dev@lists.ozlabs.org
>
> Changes for v2: Incorporated Sergei Shtylyov's comment
> - Put space after -
> - added a line
> Changes for v3: Incorporated David Laight's comment
> - Condition check for dereg 0 for hardware error
>
> drivers/ata/sata_fsl.c |7 +--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index
> b0214d0..ad84ddc 100644
> --- a/drivers/ata/sata_fsl.c
> +++ b/drivers/ata/sata_fsl.c
> @@ -1040,12 +1040,15 @@ static void sata_fsl_error_intr(struct ata_port
> *ap)
>
> /* find out the offending link and qc */
> if (ap->nr_pmp_links) {
> + unsigned int dev_num;
> +
> dereg = ioread32(hcr_base + DE);
> iowrite32(dereg, hcr_base + DE);
> iowrite32(cereg, hcr_base + CE);
>
> - if (dereg < ap->nr_pmp_links) {
> - link = &ap->pmp_link[dereg];
> + dev_num = ffs(dereg) - 1;
> + if (dev_num < ap->nr_pmp_links && dereg != 0) {
> + link = &ap->pmp_link[dev_num];
> ehi = &link->eh_info;
> qc = ata_qc_from_tag(ap, link->active_tag);
> /*
> --
> 1.7.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] driver/FSL SATA: Update RX_WATER_MARK for TRANSCFG
Hi Jeff,
I am not finding any comments on this.
Could you please ACK this patch so that it can be applied in external list.
--Prabhakar
> -Original Message-
> From: Kushwaha Prabhakar-B32579
> Sent: Monday, March 07, 2011 10:00 AM
> To: linux-...@vger.kernel.org
> Cc: jgar...@pobox.com; meet2pra...@gmail.com; linuxppc-
> d...@lists.ozlabs.org; Kushwaha Prabhakar-B32579
> Subject: [PATCH] driver/FSL SATA: Update RX_WATER_MARK for TRANSCFG
>
> RX_WATER_MARK sets the number of locations in Rx FIFO that can be used
> before the transport layer instructs the link layer to transmit HOLDS.
> Note that it can take some time for the HOLDs to get to the other end,
> and that in the interim there must be enough room in the FIFO to absorb
> all data that could arrive.
>
> Update the new recommended value to 16.
>
> Signed-off-by: Prabhakar Kushwaha
> ---
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> (branch master)
>
> This patch is already gone through review of linuxppc-dev mail list.
> Making CC linuxppc-dev@lists.ozlabs.org
>
> drivers/ata/sata_fsl.c | 12
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index
> 895771c..29d2f29 100644
> --- a/drivers/ata/sata_fsl.c
> +++ b/drivers/ata/sata_fsl.c
> @@ -186,6 +186,11 @@ enum {
> COMMANDSTAT = 0x20,
> };
>
> +/* TRANSCFG (transport-layer) configuration control */ enum {
> + TRANSCFG_RX_WATER_MARK = (1 << 4),
> +};
> +
> /* PHY (link-layer) configuration control */ enum {
> PHY_BIST_ENABLE = 0x01,
> @@ -1305,6 +1310,7 @@ static int sata_fsl_probe(struct platform_device
> *ofdev,
> struct sata_fsl_host_priv *host_priv = NULL;
> int irq;
> struct ata_host *host;
> + u32 temp;
>
> struct ata_port_info pi = sata_fsl_port_info[0];
> const struct ata_port_info *ppi[] = { &pi, NULL }; @@ -1319,6
> +1325,12 @@ static int sata_fsl_probe(struct platform_device *ofdev,
> ssr_base = hcr_base + 0x100;
> csr_base = hcr_base + 0x140;
>
> + if (!of_device_is_compatible(ofdev->dev.of_node, "fsl,mpc8315-
> sata")) {
> + temp = ioread32(csr_base + TRANSCFG);
> + temp = temp & 0xffe0;
> + iowrite32(temp | TRANSCFG_RX_WATER_MARK, csr_base +
> TRANSCFG);
> + }
> +
> DPRINTK("@reset i/o = 0x%x\n", ioread32(csr_base + TRANSCFG));
> DPRINTK("sizeof(cmd_desc) = %d\n", sizeof(struct command_desc));
> DPRINTK("sizeof(#define cmd_desc) = %d\n", SATA_FSL_CMD_DESC_SIZE);
> --
> 1.7.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][v2] driver/FSL SATA:Fix wrong Device Error Register usage
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Wednesday, March 02, 2011 8:56 AM
> To: Kushwaha Prabhakar-B32579
> Cc: linuxppc-dev@lists.ozlabs.org; meet2pra...@gmail.com; Kalra Ashish-
> B00888
> Subject: Re: [PATCH][v2] driver/FSL SATA:Fix wrong Device Error Register
> usage
>
> On Mon, 2011-02-21 at 15:27 +0530, Prabhakar Kushwaha wrote:
> > When a single device error is detected, the device under the error is
> > indicated by the error bit set in the DER. There is a one to one
> > mapping between register bit and devices on Port multiplier(PMP) i.e.
> > bit 0 represents PMP device 0 and bit 1 represents PMP device 1 etc.
>
> It might help to send those patches to the linux-ide mailing list and
> appropriate libata maintainers in addition to CC'ing linuxppc-dev.
>
Thanks Benjamin!!
I will take care your point in near future.
--Prabhakar
> > Current implementation treats Device error register value as device
> > number not set of bits representing multiple device on PMP. It is
> > changed to consider bit level.
> > No need to check for each set bit as all command is going to be
> aborted.
> >
> > Signed-off-by: Prabhakar Kushwaha
> > Signed-off-by: Ashish Kalra
> > ---
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > (branch master)
> >
> > Changes for v1: Incorporated David Laight's comment
> > - Single usage of ffs()
> >
> > Changes for v2: Incorporated David Laight's comment
> > - Changed type of dev_num to unsigned
> >
> > drivers/ata/sata_fsl.c |6 --
> > 1 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index
> > b0214d0..895771c 100644
> > --- a/drivers/ata/sata_fsl.c
> > +++ b/drivers/ata/sata_fsl.c
> > @@ -1040,12 +1040,14 @@ static void sata_fsl_error_intr(struct
> > ata_port *ap)
> >
> > /* find out the offending link and qc */
> > if (ap->nr_pmp_links) {
> > + unsigned int dev_num;
> > dereg = ioread32(hcr_base + DE);
> > iowrite32(dereg, hcr_base + DE);
> > iowrite32(cereg, hcr_base + CE);
> >
> > - if (dereg < ap->nr_pmp_links) {
> > - link = &ap->pmp_link[dereg];
> > + dev_num = ffs(dereg)-1;
> > + if (dev_num < ap->nr_pmp_links) {
> > + link = &ap->pmp_link[dev_num];
> > ehi = &link->eh_info;
> > qc = ata_qc_from_tag(ap, link->active_tag);
> > /*
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] driver/FSL SATA:Fix wrong Device Error Register usage
Thanks David for review comments!!
Please find my reply in-lined
> -Original Message-
> From: David Laight [mailto:david.lai...@aculab.com]
> Sent: Friday, February 18, 2011 2:12 PM
> To: Kushwaha Prabhakar-B32579; linuxppc-dev@lists.ozlabs.org
> Cc: Kalra Ashish-B00888
> Subject: RE: [PATCH] driver/FSL SATA:Fix wrong Device Error Register
> usage
>
>
> > + if ((ffs(dereg)-1) < ap->nr_pmp_links) {
> > + /* array start from 0 */
> > + link = &ap->pmp_link[ffs(dereg)-1];
>
> I'd only call ffs() once - it could be a slow library function.
This function is called during error handling. So it won't matter.
Anyway, I will update the patch for singe usage of ffs().
> Any comment should note that ffs() returns 0 when no bits are set -
> rather than anything about array indexes.
>
sata_fsl_error_intr() is called during device error.
The mentioned scenario will never comes. It can be observed via code:-
if (cereg) { --> cereg is set on command error. Means there is at
least 1 device present.
abort = 1;
---
---
---
/* find out the offending link and qc */
if (ap->nr_pmp_links) { --> if Port multiplier
---
---
if ((ffs(dereg)-1) < ap->nr_pmp_links) {
---
---
} else { --> Single device
dereg = ioread32(hcr_base + DE);
iowrite32(dereg, hcr_base + DE);
iowrite32(cereg, hcr_base + CE);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] driver/FSL SATA:Fix wrong Device Error Register usage
Thanks David for review comments!!
Please find my reply in-lined
> -Original Message-
> From: David Laight [mailto:david.lai...@aculab.com]
> Sent: Friday, February 18, 2011 2:12 PM
> To: Kushwaha Prabhakar-B32579; linuxppc-dev@lists.ozlabs.org
> Cc: Kalra Ashish-B00888
> Subject: RE: [PATCH] driver/FSL SATA:Fix wrong Device Error Register
> usage
>
>
> > + if ((ffs(dereg)-1) < ap->nr_pmp_links) {
> > + /* array start from 0 */
> > + link = &ap->pmp_link[ffs(dereg)-1];
>
> I'd only call ffs() once - it could be a slow library function.
This function is called during error handling. So it won't matter.
Anyway, I will update the patch for singe usage of ffs().
> Any comment should note that ffs() returns 0 when no bits are set -
> rather than anything about array indexes.
>
sata_fsl_error_intr() is called during device error.
The mentioned scenario will never comes. It can be observed via code:-
if (cereg) { --> cereg is set on command error. Means there is at
least 1 device present.
abort = 1;
---
---
---
/* find out the offending link and qc */
if (ap->nr_pmp_links) { --> if Port multiplier
---
---
if ((ffs(dereg)-1) < ap->nr_pmp_links) {
---
---
} else { --> Single device
dereg = ioread32(hcr_base + DE);
iowrite32(dereg, hcr_base + DE);
iowrite32(cereg, hcr_base + CE);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
