RE: [PATCH 2/2] mmc: esdhc: get voltage from dts file
Thanks.
Regards
Haijun.
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, July 23, 2013 10:42 AM
> To: Zhang Haijun-B42677
> Cc: Wood Scott-B07421; linux-...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; cbouatmai...@gmail.com; c...@laptop.org; Fleming
> Andy-AFLEMING
> Subject: Re: [PATCH 2/2] mmc: esdhc: get voltage from dts file
>
> On 07/22/2013 09:38:33 PM, Zhang Haijun-B42677 wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, July 23, 2013 1:41 AM
> > > To: Zhang Haijun-B42677
> > > Cc: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > cbouatmai...@gmail.com; c...@laptop.org; Fleming Andy-AFLEMING; Zhang
> > > Haijun-B42677; Zhang Haijun-B42677
> > > Subject: Re: [PATCH 2/2] mmc: esdhc: get voltage from dts file
> > >
> > > On 07/22/2013 02:53:56 AM, Haijun Zhang wrote:
> > > > Add voltage-range support in esdhc of T4, So we can choose to read
> > > > voltages from dts file as one optional.
> > > > If we can get a valid voltage-range from device node, we use this
> > > > voltage as the final voltage support. Else we still read from
> > capacity
> > > > or from other provider.
> > > >
> > > > Signed-off-by: Haijun Zhang
> > > > Signed-off-by: Anton Vorontsov
> > > > ---
> > > > drivers/mmc/host/sdhci-of-esdhc.c | 31
> > > > +++
> > > > drivers/mmc/host/sdhci.c | 3 +++
> > > > include/linux/mmc/sdhci.h | 1 +
> > > > 3 files changed, 35 insertions(+)
> > > >
> > > > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> > > > b/drivers/mmc/host/sdhci-of-esdhc.c
> > > > index 15039e2..8b4b27a 100644
> > > > --- a/drivers/mmc/host/sdhci-of-esdhc.c
> > > > +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> > > > @@ -262,6 +262,35 @@ static int esdhc_pltfm_bus_width(struct
> > > > sdhci_host *host, int width)
> > > > return 0;
> > > > }
> > > >
> > > > +static void esdhc_get_voltage(struct sdhci_host *host,
> > > > + struct platform_device *pdev)
> > > > +{
> > > > + const u32 *voltage_ranges;
> > > > + int num_ranges, i;
> > > > + struct device_node *np;
> > > > + np = pdev->dev.of_node;
> > > > +
> > > > + voltage_ranges = of_get_property(np, "voltage-ranges",
> > > > &num_ranges);
> > > > + num_ranges = num_ranges / sizeof(*voltage_ranges) / 2;
> > > > + if (!voltage_ranges || !num_ranges) {
> > > > + dev_info(&pdev->dev, "OF: voltage-ranges
> > > > unspecified\n");
> > > > + return;
> > > > + }
> > > > +
> > > > + for (i = 0; i < num_ranges; i++) {
> > > > + const int j = i * 2;
> > > > + u32 mask;
> > > > + mask =
> > > > mmc_vddrange_to_ocrmask(be32_to_cpu(voltage_ranges[j]),
> > > > + be32_to_cpu(voltage_ranges[j + 1]));
> > > > + if (!mask) {
> > > > + dev_info(&pdev->dev,
> > > > + "OF: false voltage-ranges specified\n");
> > > > + return;
> > > > + }
> > > > + host->ocr_mask |= mask;
> > > > + }
> > > > +}
> > >
> > > Don't duplicate this code. Move it somewhere common and share it.
> > [Haijun Wrote:] So, move it drivers/mmc/host/sdhci-pltfm.c and share
> > it as Sdhc_get_voltage()?
>
> I'll let the MMC maintainer say what the appropriate place would be...
> Don't capitalize the function name, though. :-)
[Haijun Wrote:] Thanks scott. I'm always expecting chris's advice.
>
> -Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] mmc: esdhc: get voltage from dts file
Thanks.
Regards
Haijun.
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, July 23, 2013 1:41 AM
> To: Zhang Haijun-B42677
> Cc: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> cbouatmai...@gmail.com; c...@laptop.org; Fleming Andy-AFLEMING; Zhang
> Haijun-B42677; Zhang Haijun-B42677
> Subject: Re: [PATCH 2/2] mmc: esdhc: get voltage from dts file
>
> On 07/22/2013 02:53:56 AM, Haijun Zhang wrote:
> > Add voltage-range support in esdhc of T4, So we can choose to read
> > voltages from dts file as one optional.
> > If we can get a valid voltage-range from device node, we use this
> > voltage as the final voltage support. Else we still read from capacity
> > or from other provider.
> >
> > Signed-off-by: Haijun Zhang
> > Signed-off-by: Anton Vorontsov
> > ---
> > drivers/mmc/host/sdhci-of-esdhc.c | 31
> > +++
> > drivers/mmc/host/sdhci.c | 3 +++
> > include/linux/mmc/sdhci.h | 1 +
> > 3 files changed, 35 insertions(+)
> >
> > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> > b/drivers/mmc/host/sdhci-of-esdhc.c
> > index 15039e2..8b4b27a 100644
> > --- a/drivers/mmc/host/sdhci-of-esdhc.c
> > +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> > @@ -262,6 +262,35 @@ static int esdhc_pltfm_bus_width(struct
> > sdhci_host *host, int width)
> > return 0;
> > }
> >
> > +static void esdhc_get_voltage(struct sdhci_host *host,
> > + struct platform_device *pdev)
> > +{
> > + const u32 *voltage_ranges;
> > + int num_ranges, i;
> > + struct device_node *np;
> > + np = pdev->dev.of_node;
> > +
> > + voltage_ranges = of_get_property(np, "voltage-ranges",
> > &num_ranges);
> > + num_ranges = num_ranges / sizeof(*voltage_ranges) / 2;
> > + if (!voltage_ranges || !num_ranges) {
> > + dev_info(&pdev->dev, "OF: voltage-ranges
> > unspecified\n");
> > + return;
> > + }
> > +
> > + for (i = 0; i < num_ranges; i++) {
> > + const int j = i * 2;
> > + u32 mask;
> > + mask =
> > mmc_vddrange_to_ocrmask(be32_to_cpu(voltage_ranges[j]),
> > + be32_to_cpu(voltage_ranges[j + 1]));
> > + if (!mask) {
> > + dev_info(&pdev->dev,
> > + "OF: false voltage-ranges specified\n");
> > + return;
> > + }
> > + host->ocr_mask |= mask;
> > + }
> > +}
>
> Don't duplicate this code. Move it somewhere common and share it.
[Haijun Wrote:] So, move it drivers/mmc/host/sdhci-pltfm.c and share it as
Sdhc_get_voltage()?
>
> Why did you remove the range index from the error string, and why did you
> change it from dev_err to dev_info?
[Haijun Wrote:] I'll correct this. In case voltage-range specified if there is
still err.
It should be err.
>
> -Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] Powerpc: Add voltage ranges support for T4
Thanks.
Regards
Haijun.
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Monday, July 22, 2013 10:40 PM
> To: Wrobel Heinz-R39252
> Cc: Zhang Haijun-B42677; linux-...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; Wood Scott-B07421; c...@laptop.org; Fleming Andy-
> AFLEMING; cbouatmai...@gmail.com
> Subject: Re: [PATCH 1/2] Powerpc: Add voltage ranges support for T4
>
>
> On Jul 22, 2013, at 4:47 AM, Wrobel Heinz-R39252 wrote:
>
> >> Subject: [PATCH 1/2] Powerpc: Add voltage ranges support for T4
> >>
> >> Special voltages that can be support by eSDHC of T4 in esdhc node.
> >>
> >> Signed-off-by: Haijun Zhang
> >> Signed-off-by: Anton Vorontsov
> >
> >> --- a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
> >> +++ b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
> >> @@ -19,6 +19,8 @@ Optional properties:
> >> "bus-width = <1>" property.
> >> - sdhci,auto-cmd12: specifies that a controller can only handle auto
> >> CMD12.
> >> + - 3300 3300: specifies that eSDHC controller can support voltages
> >> ranges
> >> +from 3300 to 3300. This is an optional.
> >
> > "This is an optional." is an unclear statement.
> >
> >> +++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> >> @@ -399,6 +399,7 @@
> >>sdhc@114000 {
> >>compatible = "fsl,t4240-esdhc", "fsl,esdhc";
> >>sdhci,auto-cmd12;
> >> + voltage-ranges = <1800 1800 3300 3300>;
> >
> > This is IMHO incorrect and potentially dangerous.
> > The T4 silicon will only support 1.8V on SDHC pins per hardware
> specification.
> > The Freescale T4240QDS reference board has extra voltage shifters added
> to allow 3.3V operation, but that is _not_ a silicon feature. It is a
> specific board feature that may or may not translate to other boards,
> depending on how SD spec conformant a board builder wants to be.
> >
> > If the intent is to state that a physical SDHC interface on a board has
> to be built to support 3.3V operation to be SD spec conformant for off-
> the-shelf cards because a reset would change the signal voltage to 3.3V,
> then I am not sure that putting this down as silicon "feature" without
> further explanation about the background anywhere is the right way to go.
> > IMHO silicon features are really just silicon features and not
> technically optional external circuitry additions implied by common use.
> >
> > Best regards,
> >
> > Heinz
>
> I'd say that the t4240si-post.dtsi should be:
>
> voltage-ranges = <1800 1800>;
>
> Than have the t4240qds.dts do:
>
> voltage-ranges = <1800 1800 3300 3300>;
>
> As the 3.3V sounds like a board specific feature.
>
> [ send this as 2 patches, on for the t4240si-post.dtsi and another for
> the t4240qds.dts ]
[Haijun Wrote:] ok, thanks Heinz and Kumar.
>
> - k
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/4 V2] mmc: esdhc: Correct host version of T4240-R1.0
Thanks.
Regards
Haijun.
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Monday, July 22, 2013 10:30 PM
> To: Zhang Haijun-B42677
> Cc: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Wood Scott-
> B07421; c...@laptop.org; Fleming Andy-AFLEMING; cbouatmai...@gmail.com
> Subject: Re: [PATCH 3/4 V2] mmc: esdhc: Correct host version of T4240-
> R1.0
>
>
> On Jul 17, 2013, at 5:11 AM, Haijun Zhang wrote:
>
> > Vender version and sdhc spec version of T4240-R1.0 is incorrect.
> > The right value should be VVN=0x13, SVN = 0x1. The wrong version
> > number will break down the ADMA data transfer.
> > This defect only exist in T4240-R1.0. Will be fixed in T4240-R2.0.
> > Also share vvn and svr for public use.
> >
> > Signed-off-by: Haijun Zhang
> > ---
> > changes for V2:
> > - Remove broken ADMA quirk.
> > - Rebuild patch of Add quirks to support T4240 board
> >
> > drivers/mmc/host/sdhci-of-esdhc.c | 29 +
> > 1 file changed, 13 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> > b/drivers/mmc/host/sdhci-of-esdhc.c
> > index adfaadd..570bca8 100644
> > --- a/drivers/mmc/host/sdhci-of-esdhc.c
> > +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> > @@ -26,7 +26,7 @@
> > #define VENDOR_V_22 0x12
> > #define VENDOR_V_23 0x13
> >
> > -static u32 svr;
> > +static u32 svr, vvn;
> >
> > static u32 esdhc_readl(struct sdhci_host *host, int reg) { @@ -43,11
> > +43,9 @@ static u32 esdhc_readl(struct sdhci_host *host, int reg)
> > * For FSL eSDHC, must aligned 4-byte, so use 0xFC to read the
> > * the verdor version number, oxFE is SDHCI_HOST_VERSION.
> > */
> > - if ((reg == SDHCI_CAPABILITIES) && (ret & SDHCI_CAN_DO_ADMA1)) {
> > - u32 tmp = in_be32(host->ioaddr + SDHCI_SLOT_INT_STATUS);
> > - tmp = (tmp & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
> > - if (tmp > VENDOR_V_22)
> > - ret |= SDHCI_CAN_DO_ADMA2;
> > + if ((reg == SDHCI_CAPABILITIES) && (ret & SDHCI_CAN_DO_ADMA1) &&
> > + (vvn > VENDOR_V_22)) {
> > + ret |= SDHCI_CAN_DO_ADMA2;
> > }
> >
> > return ret;
> > @@ -63,6 +61,12 @@ static u16 esdhc_readw(struct sdhci_host *host, int
> reg)
> > ret = in_be32(host->ioaddr + base) & 0x;
> > else
> > ret = (in_be32(host->ioaddr + base) >> shift) & 0x;
> > +
> > + /* T4240-R1.0 had a incorrect vendor version and spec version */
> > + if ((reg == SDHCI_HOST_VERSION) &&
> > + ((SVR_SOC_VER(svr) == SVR_T4240) && (SVR_REV(svr) == 0x10)))
> > + ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> SDHCI_SPEC_200;
> > +
>
> is this check correct if this is on v2.0 Si as well?
[Haijun Wrote:] Oh, I forgot to rewrite the description above. This defect
exist both
on T4-R1.0 and T4-R2.0. I'll send patch v3 to correct this. thanks
>
> - k
>
> > return ret;
> > }
> >
> > @@ -175,17 +179,12 @@ static void esdhc_reset(struct sdhci_host *host,
> > u8 mask) */ static void esdhci_of_adma_workaround(struct sdhci_host
> > *host, u32 intmask) {
> > - u32 tmp;
> > bool applicable;
> > dma_addr_t dmastart;
> > dma_addr_t dmanow;
> >
> > - tmp = esdhc_readl(host, SDHCI_SLOT_INT_STATUS);
> > - tmp = (tmp & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
> > -
> > applicable = (intmask & SDHCI_INT_DATA_END) &&
> > - (intmask & SDHCI_INT_BLK_GAP) &&
> > - (tmp == VENDOR_V_23);
> > + (intmask & SDHCI_INT_BLK_GAP) && (vvn == VENDOR_V_23);
> > if (applicable) {
> >
> > esdhc_reset(host, SDHCI_RESET_DATA); @@ -318,10 +317,9 @@
> static
> > void esdhc_of_resume(struct sdhci_host *host)
> >
> > static void esdhc_of_platform_init(struct sdhci_host *host) {
> > - u32 vvn;
> > + svr = mfspr(SPRN_SVR);
> > + vvn = esdhc_readw(host, SDHCI_HOST_VERSION);
> >
> > - vvn = in_be32(host->ioaddr + SDHCI_SLOT_INT_STATUS);
> > - vvn = (vvn & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
> > if (vvn == VENDOR_V_22)
> > host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
> >
> > @@ -390,7 +388,6 @@ static int sdhci_esdhc_probe(struct platform_device
> *pdev)
> > struct device_node *np;
> > int ret;
> >
> > - svr = mfspr(SPRN_SVR);
> > host = sdhci_pltfm_init(pdev, &sdhci_esdhc_pdata, 0);
> > if (IS_ERR(host))
> > return PTR_ERR(host);
> > --
> > 1.8.0
> >
> >
> > ___
> > 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 1/4 V4] powerpc/85xx: Add support for 85xx cpu type detection
Many Thanks. Regards Haijun. > -Original Message- > From: Wood Scott-B07421 > Sent: Saturday, July 20, 2013 1:21 AM > To: Zhang Haijun-B42677 > Cc: Zhang Haijun-B42677; linux-...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; cbouatmai...@gmail.com; c...@laptop.org; Wood Scott- > B07421; Fleming Andy-AFLEMING; Zhao Chenhui-B35336 > Subject: Re: [PATCH 1/4 V4] powerpc/85xx: Add support for 85xx cpu type > detection > > On 07/18/2013 09:28:20 PM, Zhang Haijun-B42677 wrote: > > Hi, scott > > > > I had update this patch, this is the newest version. > > If there is no other problem, can you help merge this patch? > > I hope to make sure the following patch don't need to rebuild due to > > the change of this patch. > > It looks OK. I'll pick it up when I do my next batch of patch > application (hopefully soon). Go ahead and send the patches that depend > on it. > > -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 4/4 V2] mmc: esdhc: Add broken timeout quirk for p4/p5 board
Thanks. Regards Haijun. > -Original Message- > From: Wood Scott-B07421 > Sent: Saturday, July 20, 2013 1:24 AM > To: Zhang Haijun-B42677 > Cc: Wood Scott-B07421; linux-...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; cbouatmai...@gmail.com; c...@laptop.org; Fleming > Andy-AFLEMING > Subject: Re: [PATCH 4/4 V2] mmc: esdhc: Add broken timeout quirk for > p4/p5 board > > On 07/18/2013 09:19:59 PM, Zhang Haijun-B42677 wrote: > > > > > > Thanks. > > > > Regards > > Haijun. > > > > > > > -Original Message- > > > From: Wood Scott-B07421 > > > Sent: Thursday, July 18, 2013 1:14 AM > > > To: Zhang Haijun-B42677 > > > Cc: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; > > > cbouatmai...@gmail.com; c...@laptop.org; Fleming Andy-AFLEMING; Zhang > > > Haijun-B42677; Zhang Haijun-B42677 > > > Subject: Re: [PATCH 4/4 V2] mmc: esdhc: Add broken timeout quirk for > > > p4/p5 board > > > > > > On 07/17/2013 05:11:31 AM, Haijun Zhang wrote: > > > > Sometimes command can't be completed within the time give in > > > > eSDHC_SYSCTL[DTOCV]. So just give the max value 0x14 to avoid this > > > > issue. > > > > > > > > Signed-off-by: Haijun Zhang > > > > --- > > > > changes for v2: > > > > - Rebuild patch of eSDHC host need long time to generate > > > > command interrupt > > > > > > > > drivers/mmc/host/sdhci-of-esdhc.c | 6 ++ > > > > 1 file changed, 6 insertions(+) > > > > > > > > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c > > > > b/drivers/mmc/host/sdhci-of-esdhc.c > > > > index 570bca8..30bfb5c 100644 > > > > --- a/drivers/mmc/host/sdhci-of-esdhc.c > > > > +++ b/drivers/mmc/host/sdhci-of-esdhc.c > > > > @@ -325,6 +325,12 @@ static void esdhc_of_platform_init(struct > > > > sdhci_host *host) > > > > > > > > if (vvn > VENDOR_V_22) > > > > host->quirks &= ~SDHCI_QUIRK_NO_BUSY_IRQ; > > > > + > > > > + if ((SVR_SOC_VER(svr) == SVR_B4860) || > > > > + (SVR_SOC_VER(svr) == SVR_P5020) || > > > > + (SVR_SOC_VER(svr) == SVR_P5040) || > > > > + (SVR_SOC_VER(svr) == SVR_P4080)) > > > > + host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL; > > > > } > > > > > > Please don't line up the continuation lines of the if-condition > > with the > > > if-body. > > [Haijun Wrote:] I'll correct it. > > > > > > Please check variant SoCs as well. If the bug exists on p4080, > > then it > > > exists on p4040. Likewise with p5040/p5021, and p5020/p5010. > > > > > > Is it present on all revisions of these SoCs? How about p3041, > > which is > > > usually pretty similar to p5020? p2040/p2041? Is there an erratum > > > number for this problem? > > > > > [Haijun Wrote:] I only checked this on these boards. > > These aren't boards; they're chips. > > Please find out for sure which chips are affected, or else we'll have > support issues later when someone is using a chip you didn't test with. > And always include the fewer-core variants -- if p4080 is affected, then > p4040 is affected, and so on as described above. [Haijun Wrote:] Ok, I'll try to cover all the chips. > > > No errata number yet, > > Will one be coming? [Haijun Wrote:] I need to confirm with integration team. This may take a long time for so many chips. > > > This quirk only give the host max detecting time value to check card's > > response. No impact on performance or other functions. > > Does this affect boot time if a card is not present? [Haijun Wrote:] No impact on boot time. Normally a command can finished within 10*HZ, In extreme cases this time will be extended. > > -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/4 V4] powerpc/85xx: Add support for 85xx cpu type detection
Hi, scott I had update this patch, this is the newest version. If there is no other problem, can you help merge this patch? I hope to make sure the following patch don't need to rebuild due to the change of this patch. Thanks. Regards Haijun. > -Original Message- > From: Zhang Haijun-B42677 > Sent: Wednesday, July 17, 2013 1:12 PM > To: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > Cc: cbouatmai...@gmail.com; c...@laptop.org; Wood Scott-B07421; Fleming > Andy-AFLEMING; Zhang Haijun-B42677; Zhao Chenhui-B35336 > Subject: [PATCH 1/4 V4] powerpc/85xx: Add support for 85xx cpu type > detection > > Add this file to help detect cpu type in runtime. > These macros will be more favorable for driver to apply errata and > workaround to specified cpu type. > > Signed-off-by: Haijun Zhang > Signed-off-by: Zhao Chenhui > --- > changes for v4: > - Add new set of soc > > arch/powerpc/include/asm/mpc85xx.h | 92 > ++ > 1 file changed, 92 insertions(+) > create mode 100644 arch/powerpc/include/asm/mpc85xx.h > > diff --git a/arch/powerpc/include/asm/mpc85xx.h > b/arch/powerpc/include/asm/mpc85xx.h > new file mode 100644 > index 000..736d4ac > --- /dev/null > +++ b/arch/powerpc/include/asm/mpc85xx.h > @@ -0,0 +1,92 @@ > +/* > + * MPC85xx cpu type detection > + * > + * Copyright 2011-2012 Freescale Semiconductor, Inc. > + * > + * This 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. > + */ > + > +#ifndef __ASM_PPC_MPC85XX_H > +#define __ASM_PPC_MPC85XX_H > + > +#define SVR_REV(svr) ((svr) & 0xFF) /* SOC design resision */ > +#define SVR_MAJ(svr) (((svr) >> 4) & 0xF) /* Major revision field*/ > +#define SVR_MIN(svr) (((svr) >> 0) & 0xF) /* Minor revision field*/ > + > +/* Some parts define SVR[0:23] as the SOC version */ > +#define SVR_SOC_VER(svr) (((svr) >> 8) & 0xFFF7FF) /* SOC Version > fields */ > + > +#define SVR_8533 0x803400 > +#define SVR_8535 0x803701 > +#define SVR_8536 0x803700 > +#define SVR_8540 0x803000 > +#define SVR_8541 0x807200 > +#define SVR_8543 0x803200 > +#define SVR_8544 0x803401 > +#define SVR_8545 0x803102 > +#define SVR_8547 0x803101 > +#define SVR_8548 0x803100 > +#define SVR_8555 0x807100 > +#define SVR_8560 0x807000 > +#define SVR_8567 0x807501 > +#define SVR_8568 0x807500 > +#define SVR_8569 0x808000 > +#define SVR_8572 0x80E000 > +#define SVR_P10100x80F100 > +#define SVR_P10110x80E500 > +#define SVR_P10120x80E501 > +#define SVR_P10130x80E700 > +#define SVR_P10140x80F101 > +#define SVR_P10170x80F700 > +#define SVR_P10200x80E400 > +#define SVR_P10210x80E401 > +#define SVR_P10220x80E600 > +#define SVR_P10230x80F600 > +#define SVR_P10240x80E402 > +#define SVR_P10250x80E403 > +#define SVR_P20100x80E300 > +#define SVR_P20200x80E200 > +#define SVR_P20400x821000 > +#define SVR_P20410x821001 > +#define SVR_P30410x821103 > +#define SVR_P40400x820100 > +#define SVR_P40800x82 > +#define SVR_P50100x822100 > +#define SVR_P50200x822000 > +#define SVR_P50210X820500 > +#define SVR_P50400x820400 > +#define SVR_T42400x824000 > +#define SVR_T41200x824001 > +#define SVR_T41600x824100 > +#define SVR_C291 0x85 > +#define SVR_C292 0x850020 > +#define SVR_C293 0x850030 > +#define SVR_B48600X868000 > +#define SVR_G48600x868001 > +#define SVR_G40600x868003 > +#define SVR_B44400x868100 > +#define SVR_G44400x868101 > +#define SVR_B44200x868102 > +#define SVR_B42200x868103 > +#define SVR_T10400x852000 > +#define SVR_T10410x852001 > +#define SVR_T10420x852002 > +#define SVR_T10200x852100 > +#define SVR_T10210x852101 > +#define SVR_T10220x852102 > + > +#define SVR_8610 0x80A000 > +#define SVR_8641 0x809000 > +#define SVR_8641D0x809001 > + > +#define SVR_9130 0x860001 > +#define SVR_9131 0x86 > +#define SVR_9132 0x861000 > +#define SVR_9232 0x861400 > + > +#define SVR_Unknown 0xFF > + > +#endif > -- > 1.8.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system transaction
Hi, all
Expect your advice and any comments.
Thanks.
Regards
Haijun.
> -Original Message-
> From: Zhang Haijun-B42677
> Sent: Wednesday, July 17, 2013 6:11 PM
> To: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> Cc: cbouatmai...@gmail.com; c...@laptop.org; Wood Scott-B07421; Fleming
> Andy-AFLEMING; Zhang Haijun-B42677; Zhang Haijun-B42677
> Subject: [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last
> system transaction
>
> A-004388: eSDHC DMA might not stop if error occurs on system transaction
>
> eSDHC DMA(SDMA/ADMA) might not stop if an error occurs in the last system
> transaction. It may continue initiating additional transactions until
> software reset for data/all is issued during error recovery. There is not
> any data corruption to the SD data. The IRQSTAT[DMAE] is set when the
> erratum occurs.
> The only conditions under which issues occur are the following:
> 1. SDMA - For SD Write , the error occurs in the last system transaction.
> No issue for SD read
> 2. ADMA
> a. Block count is enabled: For SD write, the error occurs in the last
> system transaction. There is no issue for SD read when block count is
> enabled.
> b. Block count is disabled: Block count is designated by the ADMA
> descriptor table, and the error occurs in the last system transaction
> when ADMA is executing last descriptor line of table.
>
> eSDHC may initiate additional system transactions. There is no data
> integrity issue for case 1 and 2a described below. For case 2b, system
> data might be corrupted.
>
> Workaround: Set eSDHC_SYSCTL[RSTD] when IRQSTAT[DMAE] is set. For cases
> 2a and 2b above, add an extra descriptor line with zero data next to the
> last descriptor line.
>
> Signed-off-by: Haijun Zhang
> ---
> changes for V2:
> - Update the svr version list
>
> drivers/mmc/host/sdhci-of-esdhc.c | 112
> ++
> 1 file changed, 102 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-
> of-esdhc.c
> index 15039e2..adfaadd 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -21,9 +21,13 @@
> #include
> #include "sdhci-pltfm.h"
> #include "sdhci-esdhc.h"
> +#include
>
> #define VENDOR_V_22 0x12
> #define VENDOR_V_23 0x13
> +
> +static u32 svr;
> +
> static u32 esdhc_readl(struct sdhci_host *host, int reg) {
> u32 ret;
> @@ -142,6 +146,26 @@ static void esdhc_writeb(struct sdhci_host *host, u8
> val, int reg)
> sdhci_be32bs_writeb(host, val, reg);
> }
>
> +static void esdhc_reset(struct sdhci_host *host, u8 mask) {
> + u32 ier;
> + u32 uninitialized_var(isav);
> +
> + if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
> + isav = esdhc_readl(host, SDHCI_INT_ENABLE);
> +
> + esdhc_writeb(host, mask, SDHCI_SOFTWARE_RESET);
> + mdelay(100);
> +
> + if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET) {
> + ier = esdhc_readl(host, SDHCI_INT_ENABLE);
> + ier &= ~SDHCI_INT_ALL_MASK;
> + ier |= isav;
> + esdhc_writel(host, ier, SDHCI_INT_ENABLE);
> + esdhc_writel(host, ier, SDHCI_SIGNAL_ENABLE);
> + }
> +}
> +
> /*
> * For Abort or Suspend after Stop at Block Gap, ignore the ADMA
> * error(IRQSTAT[ADMAE]) if both Transfer Complete(IRQSTAT[TC]) @@ -
> 156,25 +180,92 @@ static void esdhci_of_adma_workaround(struct sdhci_host
> *host, u32 intmask)
> dma_addr_t dmastart;
> dma_addr_t dmanow;
>
> - tmp = in_be32(host->ioaddr + SDHCI_SLOT_INT_STATUS);
> + tmp = esdhc_readl(host, SDHCI_SLOT_INT_STATUS);
> tmp = (tmp & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
>
> applicable = (intmask & SDHCI_INT_DATA_END) &&
> (intmask & SDHCI_INT_BLK_GAP) &&
> (tmp == VENDOR_V_23);
> - if (!applicable)
> + if (applicable) {
> +
> + esdhc_reset(host, SDHCI_RESET_DATA);
> + host->data->error = 0;
> + dmastart = sg_dma_address(host->data->sg);
> + dmanow = dmastart + host->data->bytes_xfered;
> +
> + /* Force update to the next DMA block boundary. */
> + dmanow = (dmanow & ~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1)) +
> + SDHCI_DEFAULT_BOUNDARY_SIZE;
> + host->data->bytes_xfered = dmanow - dmastart;
> + esdhc_writel(host, dmanow, SDHCI_DMA_ADDRESS);
> +
> return;
> + }
RE: [PATCH 4/4 V2] mmc: esdhc: Add broken timeout quirk for p4/p5 board
Thanks. Regards Haijun. > -Original Message- > From: Wood Scott-B07421 > Sent: Thursday, July 18, 2013 1:14 AM > To: Zhang Haijun-B42677 > Cc: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; > cbouatmai...@gmail.com; c...@laptop.org; Fleming Andy-AFLEMING; Zhang > Haijun-B42677; Zhang Haijun-B42677 > Subject: Re: [PATCH 4/4 V2] mmc: esdhc: Add broken timeout quirk for > p4/p5 board > > On 07/17/2013 05:11:31 AM, Haijun Zhang wrote: > > Sometimes command can't be completed within the time give in > > eSDHC_SYSCTL[DTOCV]. So just give the max value 0x14 to avoid this > > issue. > > > > Signed-off-by: Haijun Zhang > > --- > > changes for v2: > > - Rebuild patch of eSDHC host need long time to generate > > command interrupt > > > > drivers/mmc/host/sdhci-of-esdhc.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c > > b/drivers/mmc/host/sdhci-of-esdhc.c > > index 570bca8..30bfb5c 100644 > > --- a/drivers/mmc/host/sdhci-of-esdhc.c > > +++ b/drivers/mmc/host/sdhci-of-esdhc.c > > @@ -325,6 +325,12 @@ static void esdhc_of_platform_init(struct > > sdhci_host *host) > > > > if (vvn > VENDOR_V_22) > > host->quirks &= ~SDHCI_QUIRK_NO_BUSY_IRQ; > > + > > + if ((SVR_SOC_VER(svr) == SVR_B4860) || > > + (SVR_SOC_VER(svr) == SVR_P5020) || > > + (SVR_SOC_VER(svr) == SVR_P5040) || > > + (SVR_SOC_VER(svr) == SVR_P4080)) > > + host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL; > > } > > Please don't line up the continuation lines of the if-condition with the > if-body. [Haijun Wrote:] I'll correct it. > > Please check variant SoCs as well. If the bug exists on p4080, then it > exists on p4040. Likewise with p5040/p5021, and p5020/p5010. > > Is it present on all revisions of these SoCs? How about p3041, which is > usually pretty similar to p5020? p2040/p2041? Is there an erratum > number for this problem? > [Haijun Wrote:] I only checked this on these boards. No errata number yet, This quirk only give the host max detecting time value to check card's response. No impact on performance or other functions. > -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V3] powerpc/85xx: Add support for 85xx cpu type detection
Of course. I'll send patch v4 to add the rest of them. Thanks. Regards Haijun. > -Original Message- > From: Wood Scott-B07421 > Sent: Wednesday, July 17, 2013 7:54 AM > To: Wood Scott-B07421 > Cc: Zhang Haijun-B42677; linux-...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; cbouatmai...@gmail.com; c...@laptop.org; Wood Scott- > B07421; Fleming Andy-AFLEMING; Wrobel Heinz-R39252; Zhao Chenhui-B35336 > Subject: Re: [PATCH V3] powerpc/85xx: Add support for 85xx cpu type > detection > > On 07/16/2013 12:02:09 PM, Scott Wood wrote: > > On 07/16/2013 03:46:44 AM, Zhang Haijun-B42677 wrote: > >> Hi, scott > >> > >> Need I change something? > >> I have some patches depend on this. > >> Expect your advice. > >> > >> Thanks. > >> > >> Regards > >> Haijun. > > > > It looks OK; go ahead and send the patches that depend on it. > > Actually, could you add p2040, p4040, p4080, p5021, and any other missing > ones you notice (lots of e500v2 P1/P2 chips are missing too)? > > At the very least p2040 and p5021 ought to be there if you're using this > to check for p2041/p5040 errata, since they're basically the same chip > and thus have the same errata. > > -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V3] powerpc/85xx: Add support for 85xx cpu type detection
Hi, scott Need I change something? I have some patches depend on this. Expect your advice. Thanks. Regards Haijun. > -Original Message- > From: Zhang Haijun-B42677 > Sent: Thursday, July 11, 2013 8:24 AM > To: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > Cc: cbouatmai...@gmail.com; c...@laptop.org; Wood Scott-B07421; Fleming > Andy-AFLEMING; Wrobel Heinz-R39252; Zhang Haijun-B42677; Zhao Chenhui- > B35336 > Subject: [PATCH V3] powerpc/85xx: Add support for 85xx cpu type detection > > Add this file to help detect cpu type in runtime. > These macros will be more favorable for driver to apply errata and > workaround to specified cpu type. > > Signed-off-by: Haijun Zhang > Signed-off-by: Zhao Chenhui > --- > changes for v3: > - remove get_svr and is_svr_rev > > arch/powerpc/include/asm/mpc85xx.h | 47 > ++ > 1 file changed, 47 insertions(+) > create mode 100644 arch/powerpc/include/asm/mpc85xx.h > > diff --git a/arch/powerpc/include/asm/mpc85xx.h > b/arch/powerpc/include/asm/mpc85xx.h > new file mode 100644 > index 000..824b619 > --- /dev/null > +++ b/arch/powerpc/include/asm/mpc85xx.h > @@ -0,0 +1,47 @@ > +/* > + * MPC85xx cpu type detection > + * > + * Copyright 2011-2012 Freescale Semiconductor, Inc. > + * > + * This 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. > + */ > + > +#ifndef __ASM_PPC_MPC85XX_H > +#define __ASM_PPC_MPC85XX_H > + > +#define SVR_REV(svr) ((svr) & 0xFF) /* SOC design resision */ > +#define SVR_MAJ(svr) (((svr) >> 4) & 0xF) /* Major revision field*/ > +#define SVR_MIN(svr) (((svr) >> 0) & 0xF) /* Minor revision field*/ > + > +/* Some parts define SVR[0:23] as the SOC version */ > +#define SVR_SOC_VER(svr) (((svr) >> 8) & 0xFFF7FF) /* SOC Version > fields */ > + > +#define SVR_8533 0x803400 > +#define SVR_8535 0x803701 > +#define SVR_8536 0x803700 > +#define SVR_8540 0x803000 > +#define SVR_8541 0x807200 > +#define SVR_8543 0x803200 > +#define SVR_8544 0x803401 > +#define SVR_8545 0x803102 > +#define SVR_8547 0x803101 > +#define SVR_8548 0x803100 > +#define SVR_8555 0x807100 > +#define SVR_8560 0x807000 > +#define SVR_8567 0x807501 > +#define SVR_8568 0x807500 > +#define SVR_8569 0x808000 > +#define SVR_8572 0x80E000 > +#define SVR_P10100x80f900 > +#define SVR_P20410x821001 > +#define SVR_P30410x821103 > +#define SVR_P50100x822100 > +#define SVR_P50200x822000 > +#define SVR_P50400x820400 > +#define SVR_T42400x824800 > +#define SVR_B48600x868800 > + > +#endif > -- > 1.8.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/4 V2] mmc: esdhc: Add quirks to support T4240QDS board
Hi, Anton You mean get voltage support from DTS? Or get voltage both from DTS and host capacity register? Thanks. Regards Haijun. > -Original Message- > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- > ow...@vger.kernel.org] On Behalf Of Anton Vorontsov > Sent: Saturday, July 13, 2013 2:35 AM > To: Wood Scott-B07421 > Cc: Zhang Haijun-B42677; linux-...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; c...@laptop.org; Fleming Andy-AFLEMING; Wrobel > Heinz-R39252 > Subject: Re: [PATCH 3/4 V2] mmc: esdhc: Add quirks to support T4240QDS > board > > On Mon, Jul 08, 2013 at 12:18:39PM -0500, Scott Wood wrote: > > On 07/08/2013 02:16:04 AM, Haijun Zhang wrote: > > >On T4240QDS board controllers has an unusable ADMA engine, so use > > >SDMA instead. > > >Also 3.0v is support on T4240QDS board even if the capacity detailed > > >only 1.8v support. Without this quirk SD card will declare voltage > > >not support and > > > > > >Signed-off-by: Haijun Zhang > > > > ...and what? > > > > Why is this board-specific? Isn't the controller part of the SoC, not > > part of the board? If it really is board-specific, could you be more > > detailed about why (ideally with an erratum number), and check the > > toplevel board compatible (or get the information from platform > > code) rather than modify the device tree? > > Yup, and if anything, I would recommend to reuse voltage-ranges property, > it is already implemented for mmc spi driver, > > drivers/mmc/host/of_mmc_spi.c > Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt > > Thanks, > > Anton > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/4 V2] powerpc/85xx: Add support for 85xx cpu type detection
Thanks. Regards Haijun. > -Original Message- > From: David Laight [mailto:david.lai...@aculab.com] > Sent: Thursday, July 11, 2013 4:44 PM > To: Wood Scott-B07421; Zhang Haijun-B42677 > Cc: Zhao Chenhui-B35336; linux-...@vger.kernel.org; Wrobel Heinz-R39252; > Fleming Andy-AFLEMING; Zhang Haijun-B42677; cbouatmai...@gmail.com; > c...@laptop.org; linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061 > Subject: RE: [PATCH 1/4 V2] powerpc/85xx: Add support for 85xx cpu type > detection > > > > +#define IS_SVR_REV(svr, maj, min) \ > > > + ((SVR_MAJ(svr) == (maj)) && (SVR_MIN(svr) == (min))) > > > > I don't think IS_SVR_REV is needed. Callers can just do "if > > (SVR_REV(svr) == 0x30)" or whatever, especially since we're relying on > > them to do this for greater/less than comparisons. > > Not only that, I'd guess that 'maj' and 'min' are likely to be constants > - so you'd want to combine them and compare against 'svr' > rather than have two conditionals. [Haijun Wrote:] yes, e.g: 1.0, 1.1 or 2.0. 'Major revision field' + '.' + 'Minor revision field ' I had resent the patch(V2). I'm not so clear about what you want to express.^_^ > > David > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: 答复: [PATCH] Powerpc/t4240: change the compatible flags for t4240qds board
Thanks. Regards Haijun. > -Original Message- > From: Wood Scott-B07421 > Sent: Thursday, July 11, 2013 4:30 AM > To: Zhang Haijun-B42677 > Cc: Wood Scott-B07421; linux-...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; cbouatmai...@gmail.com; c...@laptop.org; Fleming > Andy-AFLEMING; Wrobel Heinz-R39252 > Subject: Re: 答复: [PATCH] Powerpc/t4240: change the compatible flags for > t4240qds board > > On 07/09/2013 10:41:22 PM, Zhang Haijun-B42677 wrote: > > > No. It's still supposed to be describing the sdhc block itself, > > not the > > > board -- and any workarounds that key off of this will still fail > > to work > > > with existing device trees. > > [Haijun Wrote:] So, leave dts unchanged and to check compitable for > > board in sdhci-pltfm.c > > e.g.: > > unsigned long root = of_get_flat_dt_root(); > > > > if (of_flat_dt_is_compatible(root, "fsl,T4240QDS")) > > host->quirks |= XXX; > > Why are you looking at the flat tree at this point? Use the normal OF > accessors. The flat stuff is only for early boot. > > Also make sure that you only do this for quirks that are actually board- > specific. In your last patch you had two quirks keyed off of the board, > one of which is keyed off of the SoC for other chips. > [Haijun Wrote:] Actually there are only one board with T4240 Soc. I'll try to verify these two defect with hardware team. Hope can some help. Once clear I'll resend the patch. Thanks for your kindly review. > -SCott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: 答复: [PATCH] Powerpc/t4240: change the compatible flags for t4240qds board
Thanks.
Regards
Haijun.
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 10, 2013 4:04 AM
> To: Zhang Haijun-B42677
> Cc: Wood Scott-B07421; linux-...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; cbouatmai...@gmail.com; c...@laptop.org; Fleming
> Andy-AFLEMING; Wrobel Heinz-R39252
> Subject: Re: 答复: [PATCH] Powerpc/t4240: change the compatible flags for
> t4240qds board
>
> On 07/09/2013 01:04:01 AM, Zhang Haijun-B42677 wrote:
> >
> >
> > Regards & Thanks
> >
> > Haijun.
> >
> > ________
> > 发件人: Wood Scott-B07421
> > 发送时间: 2013年7月8日 17:14
> > 收件人: Zhang Haijun-B42677
> > 抄送: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > cbouatmai...@gmail.com; c...@laptop.org; Fleming Andy-AFLEMING; Wrobel
> > Heinz-R39252; Zhang Haijun-B42677
> > 主题: Re: [PATCH] Powerpc/t4240: change the compatible flags for
> > t4240qds board
> >
> > On 07/08/2013 02:16:03 AM, Haijun Zhang wrote:
> > > In order to make a difference between different T4240 board.
> > > Specify T4240QDS board the unique compatible flags for t4240qds
> > > eSDHC host.
> > >
> > > Signed-off-by: Haijun Zhang
> > > ---
> > > arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> > > b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> > > index bd611a9..08b47d0 100644
> > > --- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> > > +++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> > > @@ -397,7 +397,7 @@
> > >
> > > /include/ "qoriq-esdhc-0.dtsi"
> > > sdhc@114000 {
> > > - compatible = "fsl,t4240-esdhc", "fsl,esdhc";
> > > + compatible = "fsl,t4240qds-esdhc", "fsl,esdhc";
> > > sdhci,auto-cmd12;
> > > };
> >
> > NACK. This node is describing the sdhc block of the t4240 SoC. What
> > board you stick it in doesn't change what it is.
> >
> > Plus, what about users with old device trees?
> >
> > Currently no users use this ip block except esdhc driver.
>
> I'm not talking about code users. I'm talking about people users.
>
> > How about change this in arch/powerpc/boot/dts/t4240qds.dts
> >
> > +++ b/arch/powerpc/boot/dts/t4240qds.dts
> > @@ -117,6 +117,10 @@
> > };
> > };
> >
> >sdhc@114000 {
> > compatible = "fsl,t4240-esdhc", "fsl,esdhc";
> >};
> >
> >i2c@118000 {
> >
> >
> > +++ b/arch/powerpc/boot/dts/t4240qds.dts
> > @@ -117,6 +117,10 @@
> > };
> > };
> >
> > + sdhc@114000 {
> > + compatible = "fsl,t4240qds-esdhc",
> > "fsl,esdhc";
> > + };
> > +
> > i2c@118000 {
>
> No. It's still supposed to be describing the sdhc block itself, not the
> board -- and any workarounds that key off of this will still fail to work
> with existing device trees.
[Haijun Wrote:] So, leave dts unchanged and to check compitable for board in
sdhci-pltfm.c
e.g.:
unsigned long root = of_get_flat_dt_root();
if (of_flat_dt_is_compatible(root, "fsl,T4240QDS"))
host->quirks |= XXX;
Is this ok?
>
> -Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2 V3] powerpc/85xx: add the P1020RDB-PD DTS support
Hi, scott
Patch V4 had send, Pls review.
Thanks.
Regards
Haijun.
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 10, 2013 12:15 AM
> To: Zhang Haijun-B42677
> Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Fleming
> Andy-AFLEMING; Zhang Haijun-B42677; Huang Changming-R66093; Xie Xiaobo-
> R63061
> Subject: Re: [PATCH 2/2 V3] powerpc/85xx: add the P1020RDB-PD DTS support
>
> On 07/09/2013 03:35:43 AM, Haijun Zhang wrote:
> > Overview of P1020RDB-PD device:
> > - DDR3 2GB
> > - NOR flash 64MB
> > - NAND flash 128MB
> > - SPI flash 16MB
> > - I2C EEPROM 256Kb
> > - eTSEC1 (RGMII PHY) connected to VSC7385 L2 switch
> > - eTSEC2 (SGMII PHY)
> > - eTSEC3 (RGMII PHY)
> > - SDHC
> > - 2 USB ports
> > - 4 TDM ports
> > - PCIe
> >
> > Signed-off-by: Haijun Zhang
> > Signed-off-by: Jerry Huang
> > Signed-off-by: Xie Xiaobo-R63061
> > CC: Scott Wood
> > ---
> > changes for v3:
> > - Remove some blank and changed the usb node
> > - Renamed the dts file
> > - change the cpld name of pd board
> >
> > arch/powerpc/boot/dts/p1020rdb-pd.dts | 90
> > arch/powerpc/boot/dts/p1020rdb-pd.dtsi | 257
> > +
> > 2 files changed, 347 insertions(+)
> > create mode 100644 arch/powerpc/boot/dts/p1020rdb-pd.dts
> > create mode 100644 arch/powerpc/boot/dts/p1020rdb-pd.dtsi
>
> Again, why do you need a separate .dtsi? If this isn't for a 32/36-bit
> split, what is the criteria for what goes in the .dts versus what goes in
> the .dtsi?
>
> > + partition@60 {
> > + /* 4MB for Compressed Root file System Image */
> > + reg = <0x0060 0x0040>;
> > + label = "NAND Compressed RFS Image";
> > + };
> > +
> > + partition@a0 {
> > + /* 22MB for JFFS2 based Root file System */
> > + reg = <0x00a0 0x0160>;
> > + label = "NAND JFFS2 Root File System";
> > + };
>
> Don't refer to JFFS2. It's bad enough that we specify partition layout
> here -- no need to specify the filesystem type, especially when it's a fs
> type that is no longer recommended.
>
> > + partition@200 {
> > + /* 96MB for RAMDISK based Root file System */
> > + reg = <0x0200 0x0600>;
> > + label = "NAND Writable User area";
> > + };
>
> Wouldn't it be better to combine these last three partitions? Why do you
> need three root filesystems?
>
> > + cpld@2,0 {
> > + compatible = "fsl,p1020rdb-pd-cpld";
> > + reg = <0x2 0x0 0x2>;
> > + read-only;
> > + };
>
> Remove read-only.
>
> > + spi@7000 {
> > + flash@0 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "spansion,s25sl12801";
> > + reg = <0>;
> > + spi-max-frequency = <4000>; /* input clock
> > */
> > +
> > + partition@u-boot {
> > + /* 512KB for u-boot Bootloader Image */
> > + reg = <0x0 0x0008>;
> > + label = "u-boot";
> > + read-only;
> > + };
> > +
> > + partition@dtb {
> > + /* 512KB for DTB Image*/
> > + reg = <0x0008 0x0008>;
> > + label = "dtb";
> > + };
> > +
> > + partition@kernel {
> > + /* 4MB for Linux Kernel Image */
> > + reg = <0x0010 0x0040>;
> > + label = "kernel";
> > + };
>
> These unit addresses are not appropriate. They should match reg, not
> label.
>
> > + partition@fs {
> > + /* 4MB for Compressed RFS Image */
> > + reg = <0x0050 0x0040>;
> > + label = "file system";
> > + };
> &g
答复: [PATCH V2 2/2] powerpc/85xx: add the P1020RDB-PD DTS support
Regards & Thanks
Haijun.
发件人: Wood Scott-B07421
发送时间: 2013年7月8日 17:10
收件人: Zhang Haijun-B42677
抄送: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Fleming
Andy-AFLEMING; Zhang Haijun-B42677; Huang Changming-R66093
主题: Re: [PATCH V2 2/2] powerpc/85xx: add the P1020RDB-PD DTS support
On 07/04/2013 07:05:00 PM, Haijun Zhang wrote:
> diff --git a/arch/powerpc/boot/dts/p1020rdb-pc.dtsi
> b/arch/powerpc/boot/dts/p1020rdb-pc.dtsi
> index c952cd3..9d24501 100644
> --- a/arch/powerpc/boot/dts/p1020rdb-pc.dtsi
> +++ b/arch/powerpc/boot/dts/p1020rdb-pc.dtsi
> @@ -131,9 +131,7 @@
> };
>
> cpld@3,0 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - compatible = "cpld";
> + compatible = "fsl, p1020rdb-cpld";
No space after "fsl,".
I'll change it thanks.
> + partition@fs {
> + /* 4MB for Compressed RFS Image */
> + reg = <0x0050 0x0040>;
> + label = "file system";
> + };
> +
> + partition@jffs-fs {
> + /* 7MB for JFFS2 based RFS */
> + reg = <0x0090 0x0070>;
> + label = "file system jffs2";
> + };
> + };
> + slic@0 {
> + compatible = "zarlink,le88266";
> + reg = <1>;
> + spi-max-frequency = <800>;
> + };
> + slic@1 {
> + compatible = "zarlink,le88266";
> + reg = <2>;
> + spi-max-frequency = <800>;
> + };
> +
> + };
Remove that last blank line, and insert a blank line before each
"slic@..." (like you do between the partition nodes).
I'll change it thanks.
> + /* USB2 is shared with localbus, so it must be disabled
> +by default. We can't put 'status = "disabled";' here
> +since U-Boot doesn't clear the status property when
> +it enables USB2. OTOH, U-Boot does create a new node
> +when there isn't any. So, just comment it out.
> + */
/*
* Linux multi-line
* comment style
* is like this.
*/
> + usb@23000 {
> + status = "disabled";
> + phy_type = "ulpi";
> + };
Didn't you just say above that you can't use status = "disabled"?
And can U-Boot be fixed to set status = "disabled" on whichever I/O is
not usable?
I had checked with ip owner, this node is not needed. I'll mask it.
> +/include/ "fsl/p1020si-pre.dtsi"
> +/ {
> + model = "fsl,P1020RDB-PD";
> + compatible = "fsl,P1020RDB-PD";
> +
> + memory {
> + device_type = "memory";
> + };
> +
> + lbc: localbus@ffe05000 {
> + reg = <0x0 0xffe05000 0x0 0x1000>;
> +
> + /* NOR, NAND flash and L2 switch */
> + ranges = <0x0 0x0 0x0 0xec00 0x0400
> + 0x1 0x0 0x0 0xff80 0x0004
> + 0x2 0x0 0x0 0xffa0 0x0002
> + 0x3 0x0 0x0 0xffb0 0x0002>;
If you're going to have a comment here about what is mapped by the
ranges, why exclude the CPLD?
I'll add it.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
答复: [PATCH] Powerpc/t4240: change the compatible flags for t4240qds board
Regards & Thanks
Haijun.
发件人: Wood Scott-B07421
发送时间: 2013年7月8日 17:14
收件人: Zhang Haijun-B42677
抄送: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
cbouatmai...@gmail.com; c...@laptop.org; Fleming Andy-AFLEMING; Wrobel
Heinz-R39252; Zhang Haijun-B42677
主题: Re: [PATCH] Powerpc/t4240: change the compatible flags for t4240qds board
On 07/08/2013 02:16:03 AM, Haijun Zhang wrote:
> In order to make a difference between different T4240 board.
> Specify T4240QDS board the unique compatible flags for t4240qds
> eSDHC host.
>
> Signed-off-by: Haijun Zhang
> ---
> arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> index bd611a9..08b47d0 100644
> --- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> @@ -397,7 +397,7 @@
>
> /include/ "qoriq-esdhc-0.dtsi"
> sdhc@114000 {
> - compatible = "fsl,t4240-esdhc", "fsl,esdhc";
> + compatible = "fsl,t4240qds-esdhc", "fsl,esdhc";
> sdhci,auto-cmd12;
> };
NACK. This node is describing the sdhc block of the t4240 SoC. What
board you stick it in doesn't change what it is.
Plus, what about users with old device trees?
Currently no users use this ip block except esdhc driver.
How about change this in arch/powerpc/boot/dts/t4240qds.dts
+++ b/arch/powerpc/boot/dts/t4240qds.dts
@@ -117,6 +117,10 @@
};
};
sdhc@114000 {
compatible = "fsl,t4240-esdhc", "fsl,esdhc";
};
i2c@118000 {
+++ b/arch/powerpc/boot/dts/t4240qds.dts
@@ -117,6 +117,10 @@
};
};
+ sdhc@114000 {
+ compatible = "fsl,t4240qds-esdhc", "fsl,esdhc";
+ };
+
i2c@118000 {
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
答复: 答复: [PATCH 2/2] powerpc/85xx: add the P1020RDB-PD DTS support
Regards & Thanks
Haijun.
发件人: Wood Scott-B07421
发送时间: 2013年7月8日 17:08
收件人: Zhang Haijun-B42677
抄送: Wood Scott-B07421; ga...@kernel.crashing.org;
linuxppc-dev@lists.ozlabs.org; Huang Changming-R66093; Xie Xiaobo-R63061
主题: Re: 答复: [PATCH 2/2] powerpc/85xx: add the P1020RDB-PD DTS support
On 07/03/2013 09:04:40 PM, Zhang Haijun-B42677 wrote:
>
>
> Regards & Thanks
>
> Haijun.
>
>
> 发件人: Wood Scott-B07421
> 发送时间: 2013年7月3日 19:09
> 收件人: Zhang Haijun-B42677
> Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Zhang
> Haijun-B42677; Huang Changming-R66093
> 主题: Re: [PATCH 2/2] powerpc/85xx: add the P1020RDB-PD DTS support
>
> On 06/30/2013 11:12:23 PM, Haijun Zhang wrote:
> > From: "Haijun.Zhang"
> >
> > Overview of P1020RDB-PD device:
> > - DDR3 2GB
> > - NOR flash 64MB
> > - NAND flash 128MB
> > - SPI flash 16MB
> > - I2C EEPROM 256Kb
> > - eTSEC1 (RGMII PHY) connected to VSC7385 L2 switch
> > - eTSEC2 (SGMII PHY)
> > - eTSEC3 (RGMII PHY)
> > - SDHC
> > - 2 USB ports
> > - 4 TDM ports
> > - PCIe
> >
> > Signed-off-by: Haijun Zhang
> > Signed-off-by: Jerry Huang
> > CC: Scott Wood
> > ---
> > arch/powerpc/boot/dts/p1020rdb-pd.dtsi| 257
> > ++
> > arch/powerpc/boot/dts/p1020rdb-pd_32b.dts | 90 +++
> > 2 files changed, 347 insertions(+)
> > create mode 100644 arch/powerpc/boot/dts/p1020rdb-pd.dtsi
> > create mode 100644 arch/powerpc/boot/dts/p1020rdb-pd_32b.dts
>
> What about 36b?
>
> Haijun: 2G DDR was fix on P1020RDB-PD board. No need 36bit support.
> Also no 36bit uboot support.
So then why not just have one "p1020rdb-pd.dts"?
Ok， i'll remove '_32b'.
Or, can you have a common p1020rdb.dtsi that all the variants use, with
the .dts file only handling the differences?
I think no need to do this, almost all of variants in xxx.dtsi are different.
> > + cpld@2,0 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "cpld";
> > + reg = <0x2 0x0 0x2>;
> > + read-only;
> > + };
>
> Where does "cpld" as a compatible come from (it's way too vague)?
> What
> is read-only supposed to mean here?
>
> Haijun: In fact almost all board has its special CPLD. This node just
> copy from p1020rdb-pc board.
>
> So, change it to :
>
> cpld@2,0 {
> compatible = "fsl, p1020rdb-cpld";
> reg = <0x2 0x0 0x2>;
> read-only;
> };
Again, what is read-only supposed to mean here? I don't care that it's
copied from the PC version. It doesn't make sense, and is not
documented in a binding.
Mostly CPLD only used to read configuration from. Supposed not been changed.
Is the -pd CPLD 100% identical to the -pc CPLD? If not, shouldn't the
compatible note the difference between the two?
oh, yes they should had their own name. I'll change it.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
答复: [PATCH 2/2] powerpc/85xx: add the P1020RDB-PD DTS support
Regards & Thanks
Haijun.
发件人: Wood Scott-B07421
发送时间: 2013年7月3日 19:09
收件人: Zhang Haijun-B42677
Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Zhang
Haijun-B42677; Huang Changming-R66093
主题: Re: [PATCH 2/2] powerpc/85xx: add the P1020RDB-PD DTS support
On 06/30/2013 11:12:23 PM, Haijun Zhang wrote:
> From: "Haijun.Zhang"
>
> Overview of P1020RDB-PD device:
> - DDR3 2GB
> - NOR flash 64MB
> - NAND flash 128MB
> - SPI flash 16MB
> - I2C EEPROM 256Kb
> - eTSEC1 (RGMII PHY) connected to VSC7385 L2 switch
> - eTSEC2 (SGMII PHY)
> - eTSEC3 (RGMII PHY)
> - SDHC
> - 2 USB ports
> - 4 TDM ports
> - PCIe
>
> Signed-off-by: Haijun Zhang
> Signed-off-by: Jerry Huang
> CC: Scott Wood
> ---
> arch/powerpc/boot/dts/p1020rdb-pd.dtsi| 257
> ++
> arch/powerpc/boot/dts/p1020rdb-pd_32b.dts | 90 +++
> 2 files changed, 347 insertions(+)
> create mode 100644 arch/powerpc/boot/dts/p1020rdb-pd.dtsi
> create mode 100644 arch/powerpc/boot/dts/p1020rdb-pd_32b.dts
What about 36b?
Haijun: 2G DDR was fix on P1020RDB-PD board. No need 36bit support. Also no
36bit uboot support.
> + cpld@2,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "cpld";
> + reg = <0x2 0x0 0x2>;
> + read-only;
> + };
Where does "cpld" as a compatible come from (it's way too vague)? What
is read-only supposed to mean here?
Haijun: In fact almost all board has its special CPLD. This node just copy from
p1020rdb-pc board.
So, change it to :
cpld@2,0 {
compatible = "fsl, p1020rdb-cpld";
reg = <0x2 0x0 0x2>;
read-only;
};
CPLD was just like a EEPROM, it contain the config information about TDM, LED,
POWER, watchdog, FXO, FXS and so on.
We changed it under uboot, when kernel setup we only need to read, supposed not
be changed.
Why do you have #address-cells/#size-cells if there are no child nodes?
I'll remove this.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] DTS: Add compatible list for eSDHC
Regards Haijun. > -Original Message- > From: Wood Scott-B07421 > Sent: Wednesday, July 03, 2013 2:55 AM > To: Zhang Haijun-B42677 > Cc: Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc- > d...@lists.ozlabs.org; Fleming Andy-AFLEMING > Subject: Re: [PATCH] DTS: Add compatible list for eSDHC > > On 07/02/2013 03:00:43 AM, Zhang Haijun-B42677 wrote: > > > > > > > > Regards > > Haijun. > > > > > -Original Message- > > > From: Wood Scott-B07421 > > > Sent: Tuesday, July 02, 2013 8:05 AM > > > To: Zhang Haijun-B42677 > > > Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Zhang > > > Haijun-B42677; Fleming Andy-AFLEMING > > > Subject: Re: [PATCH] DTS: Add compatible list for eSDHC > > > > > > On 07/01/2013 12:21:50 AM, Haijun Zhang wrote: > > > > Add compatible of esdhc for below board: > > > > p2041 p3041 p4080 p5020 p5040 > > > > > > > > Signed-off-by: Haijun Zhang > > > > CC: Scott Wood > > > > CC: Fleming Andrew-AFLEMING > > > > --- > > > > arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 1 + > > > > arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 1 + > > > > arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 1 + > > > > arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 1 + > > > > arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 1 + > > > > 5 files changed, 5 insertions(+) > > > > > > Is there something specific that depends on this, or are you just > > trying > > > to conform to other examples? > > > > > > I don't think we need the SoC name here, given that eSDHC has a > > version > > > register that you can read (and an SVR in the unlikely case that > > that > > > isn't adequate). If you did end up relying on this device tree > > change, > > > you'd be broken if an older device trees is used. > > > > > [Haijun Wrote:] Yes, in mmc driver (sdhci-pltfm.c)some quirks depends > > on Soc name and its Soc version (sdhci-of-esdhc.c), even if they had > > the same eSDHC version. > > Then please use SVR for applying errata workarounds to these chips, > rather than rely on the device tree being updated. The SVR approach also > lets you deal with cases where the erratum is present in one rev of an > SoC but not another. [Haijun Wrote:] Ok, I'll update this in mmc driver. > > Is SDHCI_QUIRK_BROKEN_TIMEOUT_VAL present on these chips? If so, which > chips (of the same eSDHC version) is it not present on? > [Haijun Wrote:] I also confused about this quirk, I'm not sure if this quirk is indeed need by them. The calculation of the timeout value used to have some defect, so some board may encounter timeout err when using sd card. I had send patch to change it, but I'm not sure which of them is due to the calculation err. This quirk just let the card use the max value to wait for data or command transfer complete. No impact to performance and function. So I leave them no changed. > -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] DTS: Add compatible list for eSDHC
Regards Haijun. > -Original Message- > From: Wood Scott-B07421 > Sent: Tuesday, July 02, 2013 8:05 AM > To: Zhang Haijun-B42677 > Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Zhang > Haijun-B42677; Fleming Andy-AFLEMING > Subject: Re: [PATCH] DTS: Add compatible list for eSDHC > > On 07/01/2013 12:21:50 AM, Haijun Zhang wrote: > > Add compatible of esdhc for below board: > > p2041 p3041 p4080 p5020 p5040 > > > > Signed-off-by: Haijun Zhang > > CC: Scott Wood > > CC: Fleming Andrew-AFLEMING > > --- > > arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 1 + > > arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 1 + > > arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 1 + > > arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 1 + > > arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 1 + > > 5 files changed, 5 insertions(+) > > Is there something specific that depends on this, or are you just trying > to conform to other examples? > > I don't think we need the SoC name here, given that eSDHC has a version > register that you can read (and an SVR in the unlikely case that that > isn't adequate). If you did end up relying on this device tree change, > you'd be broken if an older device trees is used. > [Haijun Wrote:] Yes, in mmc driver (sdhci-pltfm.c)some quirks depends on Soc name and its Soc version (sdhci-of-esdhc.c), even if they had the same eSDHC version. > -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
