[linux-sunxi] Re: [PATCH v2 30/52] dt-bindings: mmc: Convert MMC Card binding to a schema

[Ulf Hansson]

On Wed, 1 Sept 2021 at 11:19, Maxime Ripard  wrote:
>
> MMC Cards can have an optional Device Tree binding to add
> non-discoverable properties.
>
> Now that we have the DT validation in place, let's convert the device
> tree bindings for that driver over to a YAML schema.
>
> Some of these properties were already described in the MMC controller
> binding, even though they are not generic and do not apply to any
> device, so we took the occasion to fix this.
>
> Cc: linux-...@vger.kernel.org
> Cc: Ulf Hansson 
> Signed-off-by: Maxime Ripard 
>

Queued for v5.16 on the temporary devel branch, thanks!

Kind regards
Uffe


> ---
>
> Changes from v1:
>   - Fixed additionalProperties
> ---
>  .../devicetree/bindings/mmc/mmc-card.txt  | 30 
>  .../devicetree/bindings/mmc/mmc-card.yaml | 48 +++
>  .../bindings/mmc/mmc-controller.yaml  |  6 ---
>  3 files changed, 48 insertions(+), 36 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.txt
>  create mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.yaml
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.txt 
> b/Documentation/devicetree/bindings/mmc/mmc-card.txt
> deleted file mode 100644
> index 8d2d71758907..
> --- a/Documentation/devicetree/bindings/mmc/mmc-card.txt
> +++ /dev/null
> @@ -1,30 +0,0 @@
> -mmc-card / eMMC bindings
> -
> -
> -This documents describes the devicetree bindings for a mmc-host controller
> -child node describing a mmc-card / an eMMC, see "Use of Function subnodes"
> -in mmc.txt
> -
> -Required properties:
> --compatible : Must be "mmc-card"
> --reg: Must be <0>
> -
> -Optional properties:
> --broken-hpi : Use this to indicate that the mmc-card has a broken hpi
> -  implementation, and that hpi should not be used
> -
> -Example:
> -
> - {
> -   pinctrl-names = "default";
> -   pinctrl-0 = <_pins_a>;
> -   vmmc-supply = <_vcc3v3>;
> -   bus-width = <8>;
> -   non-removable;
> -
> -   mmccard: mmccard@0 {
> -   reg = <0>;
> -   compatible = "mmc-card";
> -   broken-hpi;
> -   };
> -};
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml 
> b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> new file mode 100644
> index ..b17d454442b3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mmc/mmc-card.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MMC Card / eMMC Generic Device Tree Bindings
> +
> +maintainers:
> +  - Ulf Hansson 
> +
> +description: |
> +  This documents describes the devicetree bindings for a mmc-host controller
> +  child node describing a mmc-card / an eMMC.
> +
> +properties:
> +  compatible:
> +const: mmc-card
> +
> +  reg:
> +const: 0
> +
> +  broken-hpi:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description:
> +  Use this to indicate that the mmc-card has a broken hpi
> +  implementation, and that hpi should not be used.
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +mmc {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +card@0 {
> +compatible = "mmc-card";
> +reg = <0>;
> +broken-hpi;
> +};
> +};
> +
> +...
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml 
> b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
> index 25ac8e200970..513f3c8758aa 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
> +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
> @@ -333,12 +333,6 @@ patternProperties:
>subnode describes. A value of 0 denotes the memory SD
>function, values from 1 to 7 denote the SDIO functions.
>
> -  broken-hpi:
> -$ref: /schemas/types.yaml#/definitions/flag
> -description:
> -  Use this to indicate that the mmc-card has a broken hpi
> -  implementation, and that hpi should not be used.
> -
>  required:
>- reg
>
> --
> 2.31.1
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/CAPDyKFrZr-%2BQeVE7DtZqVWDLFgLi1wYOzTMngD9JYXJBQ-ZtLA%40mail.gmail.com.

[linux-sunxi] Re: [PATCH 25/54] dt-bindings: mmc: Convert MMC Card binding to a schema

[Ulf Hansson]

On Fri, 23 Jul 2021 at 23:57, Rob Herring  wrote:
>
> On Wed, Jul 21, 2021 at 04:03:55PM +0200, Maxime Ripard wrote:
> > MMC Cards can have an optional Device Tree binding to add
> > non-discoverable properties.
> >
> > Now that we have the DT validation in place, let's convert the device
> > tree bindings for that driver over to a YAML schema.
> >
> > Some of these properties were already described in the MMC controller
> > binding, even though they are not generic and do not apply to any
> > device, so we took the occasion to fix this.
> >
> > Cc: linux-...@vger.kernel.org
> > Cc: Ulf Hansson 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  .../devicetree/bindings/mmc/mmc-card.txt  | 30 
> >  .../devicetree/bindings/mmc/mmc-card.yaml | 48 +++
> >  .../bindings/mmc/mmc-controller.yaml  |  6 ---
> >  3 files changed, 48 insertions(+), 36 deletions(-)
> >  delete mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.txt
> >  create mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.txt 
> > b/Documentation/devicetree/bindings/mmc/mmc-card.txt
> > deleted file mode 100644
> > index 8d2d71758907..
> > --- a/Documentation/devicetree/bindings/mmc/mmc-card.txt
> > +++ /dev/null
> > @@ -1,30 +0,0 @@
> > -mmc-card / eMMC bindings
> > -
> > -
> > -This documents describes the devicetree bindings for a mmc-host controller
> > -child node describing a mmc-card / an eMMC, see "Use of Function subnodes"
> > -in mmc.txt
> > -
> > -Required properties:
> > --compatible : Must be "mmc-card"
> > --reg: Must be <0>
> > -
> > -Optional properties:
> > --broken-hpi : Use this to indicate that the mmc-card has a broken hpi
> > -  implementation, and that hpi should not be used
> > -
> > -Example:
> > -
> > - {
> > - pinctrl-names = "default";
> > - pinctrl-0 = <_pins_a>;
> > - vmmc-supply = <_vcc3v3>;
> > - bus-width = <8>;
> > - non-removable;
> > -
> > - mmccard: mmccard@0 {
> > - reg = <0>;
> > - compatible = "mmc-card";
> > - broken-hpi;
> > - };
> > -};
> > diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml 
> > b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> > new file mode 100644
> > index ..aefdd8748b72
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> > @@ -0,0 +1,48 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/mmc/mmc-card.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: MMC Card / eMMC Generic Device Tree Bindings
> > +
> > +maintainers:
> > +  - Ulf Hansson 
> > +
> > +description: |
> > +  This documents describes the devicetree bindings for a mmc-host 
> > controller
> > +  child node describing a mmc-card / an eMMC.
> > +
> > +properties:
> > +  compatible:
> > +const: mmc-card
> > +
> > +  reg:
> > +const: 0
> > +
> > +  broken-hpi:
> > +$ref: /schemas/types.yaml#/definitions/flag
> > +description:
> > +  Use this to indicate that the mmc-card has a broken hpi
> > +  implementation, and that hpi should not be used.
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +
> > +additionalProperties: true
>
> Like what? If there's other properties, then there should really be a
> specific compatible.

I agree.

Maxime, thanks for working on this. I assume you will be sending a new
version that I can pick up?

[...]

Kind regards
Uffe

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/CAPDyKFr8-%2BzqhZfALux8p6XaDbR2T-DSP%3D_Kx_6p_LqdCrmCAA%40mail.gmail.com.

[linux-sunxi] Re: [PATCH v2 09/21] mmc: sunxi: add support for A100 mmc controller

[Ulf Hansson]

On Fri, 11 Dec 2020 at 02:20, Andre Przywara  wrote:
>
> From: Yangtao Li 
>
> This patch adds support for A100 MMC controller, which use word address
> for internal dma.
>
> Signed-off-by: Yangtao Li 
> Signed-off-by: Andre Przywara 

Applied for next to my mmc tree, thanks!

Kind regards
Uffe


> ---
>  drivers/mmc/host/sunxi-mmc.c | 28 +---
>  1 file changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index fc62773602ec..1518b64112b7 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -244,6 +244,7 @@ struct sunxi_idma_des {
>
>  struct sunxi_mmc_cfg {
> u32 idma_des_size_bits;
> +   u32 idma_des_shift;
> const struct sunxi_mmc_clk_delay *clk_delays;
>
> /* does the IP block support autocalibration? */
> @@ -343,7 +344,7 @@ static int sunxi_mmc_init_host(struct sunxi_mmc_host 
> *host)
> /* Enable CEATA support */
> mmc_writel(host, REG_FUNS, SDXC_CEATA_ON);
> /* Set DMA descriptor list base address */
> -   mmc_writel(host, REG_DLBA, host->sg_dma);
> +   mmc_writel(host, REG_DLBA, host->sg_dma >> host->cfg->idma_des_shift);
>
> rval = mmc_readl(host, REG_GCTRL);
> rval |= SDXC_INTERRUPT_ENABLE_BIT;
> @@ -373,8 +374,10 @@ static void sunxi_mmc_init_idma_des(struct 
> sunxi_mmc_host *host,
>
> next_desc += sizeof(struct sunxi_idma_des);
> pdes[i].buf_addr_ptr1 =
> -   cpu_to_le32(sg_dma_address(>sg[i]));
> -   pdes[i].buf_addr_ptr2 = cpu_to_le32((u32)next_desc);
> +   cpu_to_le32(sg_dma_address(>sg[i]) >>
> +   host->cfg->idma_des_shift);
> +   pdes[i].buf_addr_ptr2 = cpu_to_le32((u32)next_desc >>
> +   
> host->cfg->idma_des_shift);
> }
>
> pdes[0].config |= cpu_to_le32(SDXC_IDMAC_DES0_FD);
> @@ -1178,6 +1181,23 @@ static const struct sunxi_mmc_cfg sun50i_a64_emmc_cfg 
> = {
> .needs_new_timings = true,
>  };
>
> +static const struct sunxi_mmc_cfg sun50i_a100_cfg = {
> +   .idma_des_size_bits = 16,
> +   .idma_des_shift = 2,
> +   .clk_delays = NULL,
> +   .can_calibrate = true,
> +   .mask_data0 = true,
> +   .needs_new_timings = true,
> +};
> +
> +static const struct sunxi_mmc_cfg sun50i_a100_emmc_cfg = {
> +   .idma_des_size_bits = 13,
> +   .idma_des_shift = 2,
> +   .clk_delays = NULL,
> +   .can_calibrate = true,
> +   .needs_new_timings = true,
> +};
> +
>  static const struct of_device_id sunxi_mmc_of_match[] = {
> { .compatible = "allwinner,sun4i-a10-mmc", .data = _a10_cfg },
> { .compatible = "allwinner,sun5i-a13-mmc", .data = _a13_cfg },
> @@ -1186,6 +1206,8 @@ static const struct of_device_id sunxi_mmc_of_match[] = 
> {
> { .compatible = "allwinner,sun9i-a80-mmc", .data = _a80_cfg },
> { .compatible = "allwinner,sun50i-a64-mmc", .data = _a64_cfg },
> { .compatible = "allwinner,sun50i-a64-emmc", .data = 
> _a64_emmc_cfg },
> +   { .compatible = "allwinner,sun50i-a100-mmc", .data = _a100_cfg 
> },
> +   { .compatible = "allwinner,sun50i-a100-emmc", .data = 
> _a100_emmc_cfg },
> { /* sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(of, sunxi_mmc_of_match);
> --
> 2.17.5
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/CAPDyKFokNt1megz9MHcn8rSgYki%3Dc_s%3DUeNk8cBLUaHVVKrQ6A%40mail.gmail.com.

[linux-sunxi] Re: [PATCH v2 08/21] dt-bindings: mmc: sunxi: Add Allwinner A100 and H616 compatibles

[Ulf Hansson]

On Fri, 11 Dec 2020 at 02:20, Andre Przywara  wrote:
>
> From: Yangtao Li 
>
> Add binding for A100's and H616's mmc and emmc controller.
>
> Signed-off-by: Yangtao Li 
> Signed-off-by: Andre Przywara 

Applied for next to my mmc tree, thanks!

Kind regards
Uffe


> ---
>  .../devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml  | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git 
> a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml 
> b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
> index e82c9a07b6fb..e75b3a8ba816 100644
> --- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
> +++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
> @@ -26,6 +26,8 @@ properties:
>- const: allwinner,sun9i-a80-mmc
>- const: allwinner,sun50i-a64-emmc
>- const: allwinner,sun50i-a64-mmc
> +  - const: allwinner,sun50i-a100-emmc
> +  - const: allwinner,sun50i-a100-mmc
>- items:
>- const: allwinner,sun8i-a83t-mmc
>- const: allwinner,sun7i-a20-mmc
> @@ -47,6 +49,12 @@ properties:
>- items:
>- const: allwinner,sun50i-h6-mmc
>- const: allwinner,sun50i-a64-mmc
> +  - items:
> +  - const: allwinner,sun50i-h616-emmc
> +  - const: allwinner,sun50i-a100-emmc
> +  - items:
> +  - const: allwinner,sun50i-h616-mmc
> +  - const: allwinner,sun50i-a100-mmc
>
>reg:
>  maxItems: 1
> --
> 2.17.5
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/CAPDyKFrXdCUTV_WdRXGrqZ9YQAnVkieinmdsEO6%3D-YifA8abbw%40mail.gmail.com.

[linux-sunxi] Re: [PATCH] mmc: sunxi: fix unusuable eMMC on some H6 boards by disabling DDR

[Ulf Hansson]

On Wed, 28 Aug 2019 at 12:52, Alejandro González
 wrote:
>
> El 27/8/19 a las 15:24, Ulf Hansson escribió:> Assuming this should go stable 
> as well? Perhaps you can find a
> > relevant commit that we can put as a fixes tag as well?
> >
> > Kind regards
> > Uffe
>
> The most relevant commit I've found that is related to enabling DDR speeds
> on H6 boards is this one: 
> https://github.com/torvalds/linux/commit/07bafc1e3536a4e3c422dbd13341688b54f159bb
>  .
> But it doesn't address the H6 SoC specifically, so I doubted whether it would
> be appropiate to mark this patch as fixing it, and opted to not do it. I don't
> mind adding that tag if it's appropiate, though :-)

Hard to say what makes sense here, but how about picking this below instead?

Fixes: 0a23f1ad88fc ("dt-binding: mmc: sunxi: add H6 compatible (with
A64 fallback)")

>
> On the other hand, I'm not sure that I understood correctly what do you mean 
> by
> this patch going stable, but I might say the changes themselves are stable 
> and work.
> The only downside I can think of to them is that they are a kind of 
> workaround that
> reduces performance on H6 boards and/or eMMC not affected by this problem 
> (are there
> any?), unless device trees are changed.

Adding a stable tag and a fixes tag for the commit, makes maintainers
of stable kernels to try to backport this commit and fix the problem
for "older" kernels.

Kind regards
Uffe

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/CAPDyKFp420OaeoedkR%3DKuX1EMNwOvCkCfJHZPRDXhVz-w8J0mg%40mail.gmail.com.

[linux-sunxi] Re: [PATCH v2 1/3] mmc: sunxi: Disable HS-DDR mode for H5 eMMC controller by default

[Ulf Hansson]

On Tue, 5 Feb 2019 at 16:42, Chen-Yu Tsai  wrote:
>
> Some H5 boards seem to not have proper trace lengths for eMMC to be able
> to use the default setting for the delay chains under HS-DDR mode. These
> include the Bananapi M2+ H5 and NanoPi NEO Core2. However the Libre
> Computer ALL-H3-CC-H5 works just fine.
>
> For the H5 (at least for now), default to not enabling HS-DDR modes in
> the driver, and expect the device tree to signal HS-DDR capability on
> boards that work.
>
> Reported-by: Chris Blake 
> Fixes: 07bafc1e3536 ("mmc: sunxi: Use new timing mode for A64 eMMC 
> controller")
> Cc: 
> Acked-by: Maxime Ripard 
> Signed-off-by: Chen-Yu Tsai 

Applied for fixes, thanks!

Kind regards
Uffe


> ---
>  drivers/mmc/host/sunxi-mmc.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 279e326e397e..7415af8c8ff6 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -1399,7 +1399,16 @@ static int sunxi_mmc_probe(struct platform_device 
> *pdev)
> mmc->caps  |= MMC_CAP_MMC_HIGHSPEED | 
> MMC_CAP_SD_HIGHSPEED |
>   MMC_CAP_ERASE | MMC_CAP_SDIO_IRQ;
>
> -   if (host->cfg->clk_delays || host->use_new_timings)
> +   /*
> +* Some H5 devices do not have signal traces precise enough to
> +* use HS DDR mode for their eMMC chips.
> +*
> +* We still enable HS DDR modes for all the other controller
> +* variants that support them.
> +*/
> +   if ((host->cfg->clk_delays || host->use_new_timings) &&
> +   !of_device_is_compatible(pdev->dev.of_node,
> +"allwinner,sun50i-h5-emmc"))
> mmc->caps  |= MMC_CAP_1_8V_DDR | MMC_CAP_3_3V_DDR;
>
> ret = mmc_of_parse(mmc);
> --
> 2.20.1
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 2/3] mmc: sunxi: Filter out unsupported modes declared in the device tree

[Ulf Hansson]

On Tue, 5 Feb 2019 at 16:42, Chen-Yu Tsai  wrote:
>
> The MMC device tree bindings include properties used to signal various
> signalling speed modes. Until now the sunxi driver was accepting them
> without any further filtering, while the sunxi device trees were not
> actually using them.
>
> Since some of the H5 boards can not run at higher speed modes stably,
> we are resorting to declaring the higher speed modes per-board.
>
> Regardless, having boards declare modes and blindly following them,
> even without proper support in the driver, is generally a bad thing.
>
> Filter out all unsupported modes from the capabilities mask after
> the device tree properties have been parsed.
>
> Cc: 
> Signed-off-by: Chen-Yu Tsai 
>

Applied for fixes, thanks!

Kind regards
Uffe


> ---
>
> This should be backported to stable kernels in case people try to run
> new device trees (that declare newly supported modes) with old kernels.
> ---
>  drivers/mmc/host/sunxi-mmc.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 7415af8c8ff6..70fadc976795 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -1415,6 +1415,21 @@ static int sunxi_mmc_probe(struct platform_device 
> *pdev)
> if (ret)
> goto error_free_dma;
>
> +   /*
> +* If we don't support delay chains in the SoC, we can't use any
> +* of the higher speed modes. Mask them out in case the device
> +* tree specifies the properties for them, which gets added to
> +* the caps by mmc_of_parse() above.
> +*/
> +   if (!(host->cfg->clk_delays || host->use_new_timings)) {
> +   mmc->caps &= ~(MMC_CAP_3_3V_DDR | MMC_CAP_1_8V_DDR |
> +  MMC_CAP_1_2V_DDR | MMC_CAP_UHS);
> +   mmc->caps2 &= ~MMC_CAP2_HS200;
> +   }
> +
> +   /* TODO: This driver doesn't support HS400 mode yet */
> +   mmc->caps2 &= ~MMC_CAP2_HS400;
> +
> ret = sunxi_mmc_init_host(host);
> if (ret)
> goto error_free_dma;
> --
> 2.20.1
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 1/3] mmc: sunxi: add support for the MMC controller on H6

[Ulf Hansson]

On 26 April 2018 at 16:07, Icenowy Zheng  wrote:
> The new Allwinner H6 SoC have 3 MMC controllers. The first and second
> ones are similar to the ones on A64, but the third one adds EMCE
> (Embedded Crypto Engine) support which does hardware transparent crypto
> on the eMMC.
>
> As we still do not have support for EMCE, and the support of it is
> disabled by defualt, we just duplicate the A64 mmc configurations and
> change the compatible string.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  Documentation/devicetree/bindings/mmc/sunxi-mmc.txt |  2 ++

DT doc changes in separate patches please!

>  drivers/mmc/host/sunxi-mmc.c| 16 
>  2 files changed, 18 insertions(+)
>

Kind regards
Uffe

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH] mmc: sunxi: Fix clock rate passed to sunxi_mmc_clk_set_phase

[Ulf Hansson]

On 10 August 2017 at 05:29, Chen-Yu Tsai  wrote:
> sunxi_mmc_clk_set_phase expects the actual card clock rate to be passed
> to it. When the internal divider code was reworked in commit 9a639c6073d3
> ("mmc: sunxi: Support MMC DDR52 transfer mode with new timing mode"),
> this requirement was missed, and the module clock rate was passed in
> instead. This broke 8 bit DDR MMC on old controllers, as the module
> clock rate is double the card clock rate, for which we have no valid
> delay settings.
>
> Fix this by applying the internal divider to the clock rate right after
> we configure it in hardware.
>
> Fixes: 9a639c6073d3 ("mmc: sunxi: Support MMC DDR52 transfer mode with
>   new timing mode")
> Signed-off-by: Chen-Yu Tsai 

Thanks, applied for next!

Kind regards
Uffe

> ---
>
> Sorry for all the regressions the A83T MMC series has caused.
> I only caught this while testing some other patches on the H3.
> I really hope this is the last one.
>
> ---
>  drivers/mmc/host/sunxi-mmc.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 6c7eb859ace1..da5f46a14497 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -821,6 +821,9 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
> *host,
> rval |= div - 1;
> mmc_writel(host, REG_CLKCR, rval);
>
> +   /* update card clock rate to account for internal divider */
> +   rate /= div;
> +
> if (host->use_new_timings) {
> /* Don't touch the delay bits */
> rval = mmc_readl(host, REG_SD_NTSR);
> @@ -828,6 +831,7 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
> *host,
> mmc_writel(host, REG_SD_NTSR, rval);
> }
>
> +   /* sunxi_mmc_clk_set_phase expects the actual card clock rate */
> ret = sunxi_mmc_clk_set_phase(host, ios, rate);
> if (ret)
> return ret;
> @@ -849,7 +853,7 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
> *host,
> return ret;
>
> /* And we just enabled our clock back */
> -   mmc->actual_clock = rate / div;
> +   mmc->actual_clock = rate;
>
> return 0;
>  }
> --
> 2.13.3
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2] mmc: sunxi: fix support for new timings mode only SoCs

[Ulf Hansson]

On 8 August 2017 at 09:09, Icenowy Zheng  wrote:
> The A83T MMC support code introduces the timings mode switch, however
> such a switch doesn't exist on new SoCs with only new timings mode.
>
> Only execute the switch if the SoC really have the timings mode switch,
> to fix the regression shown on new timings mode only SoCs (A64, H5,
> etc).
>
> Fixes: b0600daebf31 ("mmc: sunxi: Support controllers that can use
>   both old and new timings")
> Signed-off-by: Icenowy Zheng 
> Reviewed-by: Chen-Yu Tsai 

Thanks, applied for next!

Kind regards
Uffe

> ---
> Changes in v2:
> - Slightly adjusted the format of the Fixes: line/
> - Added review tag from Chen-Yu.
>
>  drivers/mmc/host/sunxi-mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 020547e5fa45..7447d41833ee 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -789,7 +789,7 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
> *host,
> clock <<= 1;
> }
>
> -   if (host->use_new_timings) {
> +   if (host->use_new_timings && host->cfg->has_timings_switch) {
> ret = sunxi_ccu_set_mmc_timing_mode(host->clk_mmc, true);
> if (ret) {
> dev_err(mmc_dev(mmc),
> --
> 2.13.0
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2] mmc: sunxi: Fix NULL pointer reference on clk_delays

[Ulf Hansson]

On 8 August 2017 at 09:02, Chen-Yu Tsai  wrote:
> Some SoCs do not support clk delays for MMC in the clock control unit.
> These include the old controllers in A10/A10s/A13/R8, and the new eMMC
> controller in A64. The config structure for these controllers do not
> specify clk_delays, but the check for this was replaced in commit
> b0600daebf31 ("mmc: sunxi: Support controllers that can use both old
> and new timings").
>
> This patch adds back the check for clk_delays, and also adds comments
> for both checks in sunxi_mmc_clk_set_phase().
>
> Fixes: b0600daebf31 ("mmc: sunxi: Support controllers that can use
>   both old and new timings")
> Signed-off-by: Chen-Yu Tsai 

Thanks, applied for next!

Kind regards
Uffe

> ---
> This fixes an mmc regression on A10/A10s/A13/R8 and A64 introduced
> by the A83T mmc patches.
>
> v1 was inlined in a reply to "mmc: sunxi: fix new timings mode on A64
> EMMC (MMC2) controller"
>
> Changes since v1:
>
>   - Polished comments
>
> I've tested this on my A10 Cubieboard and A20 Cubieboard2.
> ---
>  drivers/mmc/host/sunxi-mmc.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 3777517982dd..9dc6d726ec49 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -722,9 +722,14 @@ static int sunxi_mmc_clk_set_phase(struct sunxi_mmc_host 
> *host,
>  {
> int index;
>
> +   /* clk controller delays not used under new timings mode */
> if (host->use_new_timings)
> return 0;
>
> +   /* some old controllers don't support delays */
> +   if (!host->cfg->clk_delays)
> +   return 0;
> +
> /* determine delays */
> if (rate <= 40) {
> index = SDXC_CLK_400K;
> --
> 2.13.3
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v3 00/10] ARM: sun8i: a83t: Add support for MMC controllers

[Ulf Hansson]

On 3 August 2017 at 13:25, Chen-Yu Tsai <w...@csie.org> wrote:
> On Thu, Aug 3, 2017 at 7:19 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote:
>> On 26 July 2017 at 21:45, Maxime Ripard
>> <maxime.rip...@free-electrons.com> wrote:
>>> On Wed, Jul 26, 2017 at 10:09:41PM +0800, Chen-Yu Tsai wrote:
>>>> On Mon, Jul 24, 2017 at 9:58 PM, Chen-Yu Tsai <w...@csie.org> wrote:
>>>> > Hi everyone,
>>>> >
>>>> > This is v3 of my MMC controller support series.
>>>> >
>>>>
>>>> [...]
>>>>
>>>> > Chen-Yu Tsai (10):
>>>> >   clk: sunxi-ng: Add interface to query or configure MMC timing modes.
>>>> >   clk: sunxi-ng: Add MP_MMC clocks that support MMC timing modes
>>>> > switching
>>>> >   clk: sunxi-ng: a83t: Support new timing mode for mmc2 clock
>>>> >   mmc: sunxi: Support controllers that can use both old and new timings
>>>> >   mmc: sunxi: Support MMC DDR52 transfer mode with new timing mode
>>>> >   mmc: sunxi: Add support for A83T eMMC (MMC2)
>>>>
>>>> So this series seems to be ready for inclusion, unless Ulf has further
>>>> concerns about the clk usage.
>>>>
>>>> The first mmc patch have build time dependencies on the first clk patch.
>>>> Shall we put the clk patch on a separate immutable branch for both trees
>>>> to pull? Or we could just merge everything through the mmc tree? I don't
>>>> think we'll touch this part of the sunxi-ng clk driver for the remainder
>>>> of this cycle.
>>>
>>> I guess the easiest would be for it to go through Ulf tree, unless he
>>> says otherwise of course :)
>>
>> Okay, I have picked up the series and applied it for my next branch.
>
> I guess I wasn't very clear. When I meant "everything" I meant the mmc
> and clk patches. We will take the dts patches through the sunxi tree.
>
> Can you drop the four dts patches from your tree? That would be the
> last four patches on mmc/next at the moment.

Done!

Kind regards
Uffe

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v3 00/10] ARM: sun8i: a83t: Add support for MMC controllers

[Ulf Hansson]

On 26 July 2017 at 21:45, Maxime Ripard
 wrote:
> On Wed, Jul 26, 2017 at 10:09:41PM +0800, Chen-Yu Tsai wrote:
>> On Mon, Jul 24, 2017 at 9:58 PM, Chen-Yu Tsai  wrote:
>> > Hi everyone,
>> >
>> > This is v3 of my MMC controller support series.
>> >
>>
>> [...]
>>
>> > Chen-Yu Tsai (10):
>> >   clk: sunxi-ng: Add interface to query or configure MMC timing modes.
>> >   clk: sunxi-ng: Add MP_MMC clocks that support MMC timing modes
>> > switching
>> >   clk: sunxi-ng: a83t: Support new timing mode for mmc2 clock
>> >   mmc: sunxi: Support controllers that can use both old and new timings
>> >   mmc: sunxi: Support MMC DDR52 transfer mode with new timing mode
>> >   mmc: sunxi: Add support for A83T eMMC (MMC2)
>>
>> So this series seems to be ready for inclusion, unless Ulf has further
>> concerns about the clk usage.
>>
>> The first mmc patch have build time dependencies on the first clk patch.
>> Shall we put the clk patch on a separate immutable branch for both trees
>> to pull? Or we could just merge everything through the mmc tree? I don't
>> think we'll touch this part of the sunxi-ng clk driver for the remainder
>> of this cycle.
>
> I guess the easiest would be for it to go through Ulf tree, unless he
> says otherwise of course :)

Okay, I have picked up the series and applied it for my next branch.

Thanks and kind regards
Uffe

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode

[Ulf Hansson]

+stable

On 14 July 2017 at 08:42, Chen-Yu Tsai  wrote:
> The register for the "new timing mode" also has bit fields for setting
> output and sample timing phases. According to comments in Allwinner's
> BSP kernel, the default values are good enough.
>
> Keep the default values already in the hardware when setting new timing
> mode, instead of overwriting the whole register.
>
> Fixes: 9a37e53e451e ("mmc: sunxi: Enable the new timings for the A64 MMC
>   controllers")
> Signed-off-by: Chen-Yu Tsai 

Thanks, applied for fixes and added a stable tag.

Kind regards
Uffe

> ---
>  drivers/mmc/host/sunxi-mmc.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index d6fa2214aaae..0fb4e4c119e1 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -793,8 +793,12 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
> *host,
> }
> mmc_writel(host, REG_CLKCR, rval);
>
> -   if (host->cfg->needs_new_timings)
> -   mmc_writel(host, REG_SD_NTSR, SDXC_2X_TIMING_MODE);
> +   if (host->cfg->needs_new_timings) {
> +   /* Don't touch the delay bits */
> +   rval = mmc_readl(host, REG_SD_NTSR);
> +   rval |= SDXC_2X_TIMING_MODE;
> +   mmc_writel(host, REG_SD_NTSR, rval);
> +   }
>
> ret = sunxi_mmc_clk_set_phase(host, ios, rate);
> if (ret)
> --
> 2.13.2
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings

[Ulf Hansson]

On 14 July 2017 at 11:40, Chen-Yu Tsai <w...@csie.org> wrote:
> On Fri, Jul 14, 2017 at 5:26 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote:
>> On 14 July 2017 at 08:42, Chen-Yu Tsai <w...@csie.org> wrote:
>>> On the SoCs that introduced the new timing mode for MMC controllers,
>>> both the old (where the clock delays are set in the CCU) and new
>>> (where the clock delays are set in the MMC controller) timing modes
>>> are available, and we have to support them both. However there are
>>> two bits that control which mode is active. One is in the CCU, the
>>> other is in the MMC controller. The settings on both sides must be
>>> the same, or nothing will work.
>>>
>>> The CCU's get/set_phase callbacks return -ENOTSUPP when the new
>>> timing mode is active. This provides a way to know which mode is
>>> active on that side, and we can set the bit on the MMC controller
>>> side accordingly.
>
> Argh... I forgot to update the commit log... :(
>
>>>
>>> Signed-off-by: Chen-Yu Tsai <w...@csie.org>
>>> ---
>>>  drivers/mmc/host/sunxi-mmc.c | 34 ++
>>>  1 file changed, 30 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>>> index 0fb4e4c119e1..56e45c65b52d 100644
>>> --- a/drivers/mmc/host/sunxi-mmc.c
>>> +++ b/drivers/mmc/host/sunxi-mmc.c
>>> @@ -22,6 +22,7 @@
>>>  #include 
>>>
>>>  #include 
>>> +#include 
>>
>> I don't like this. This looks like an SoC specific hack.
>>
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -259,7 +260,7 @@ struct sunxi_mmc_cfg {
>>> /* Does DATA0 needs to be masked while the clock is updated */
>>> bool mask_data0;
>>>
>>> -   bool needs_new_timings;
>>> +   bool has_new_timings;
>>>  };
>>>
>>>  struct sunxi_mmc_host {
>>> @@ -293,6 +294,9 @@ struct sunxi_mmc_host {
>>>
>>> /* vqmmc */
>>> boolvqmmc_enabled;
>>> +
>>> +   /* timings */
>>> +   booluse_new_timings;
>>>  };
>>>
>>>  static int sunxi_mmc_reset_host(struct sunxi_mmc_host *host)
>>> @@ -714,7 +718,7 @@ static int sunxi_mmc_clk_set_phase(struct 
>>> sunxi_mmc_host *host,
>>>  {
>>> int index;
>>>
>>> -   if (!host->cfg->clk_delays)
>>> +   if (host->use_new_timings)
>>> return 0;
>>>
>>> /* determine delays */
>>> @@ -765,6 +769,15 @@ static int sunxi_mmc_clk_set_rate(struct 
>>> sunxi_mmc_host *host,
>>> ios->bus_width == MMC_BUS_WIDTH_8)
>>> clock <<= 1;
>>>
>>> +   if (host->use_new_timings) {
>>> +   ret = sunxi_ccu_set_mmc_timing_mode(host->clk_mmc, true);
>>
>> Can't this be solved through some other generic API/interface?
>
> The old discussion is here: https://lkml.org/lkml/2017/5/5/77
>
> It is possible to piggy back on existing API, but as Maxime mentioned
> back in the discussion, it is confusing.
>
> IIRC Mike said (via Maxime) an SoC specific call was the easy way
> to handle this. I don't think there's anything generic about this.
> Even if you could have a _set_mode callback for the clks, the modes
> would be SoC specific anyway.

Right. But it would benefit that we can keep drivers generic, as they
are using generic APIs/interfaces. I prefer that.

Anyway, let me try to dig up the earlier discussion.

Kind regards
Uffe

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode

[Ulf Hansson]

On 14 July 2017 at 08:42, Chen-Yu Tsai  wrote:
> The register for the "new timing mode" also has bit fields for setting
> output and sample timing phases. According to comments in Allwinner's
> BSP kernel, the default values are good enough.
>
> Keep the default values already in the hardware when setting new timing
> mode, instead of overwriting the whole register.
>
> Fixes: 9a37e53e451e ("mmc: sunxi: Enable the new timings for the A64 MMC
>   controllers")
> Signed-off-by: Chen-Yu Tsai 

It looks like this change doesn't depend on anything else? Do you want
me to pick it up for fixes and adding stable tag?

Kind regards
Uffe

> ---
>  drivers/mmc/host/sunxi-mmc.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index d6fa2214aaae..0fb4e4c119e1 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -793,8 +793,12 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
> *host,
> }
> mmc_writel(host, REG_CLKCR, rval);
>
> -   if (host->cfg->needs_new_timings)
> -   mmc_writel(host, REG_SD_NTSR, SDXC_2X_TIMING_MODE);
> +   if (host->cfg->needs_new_timings) {
> +   /* Don't touch the delay bits */
> +   rval = mmc_readl(host, REG_SD_NTSR);
> +   rval |= SDXC_2X_TIMING_MODE;
> +   mmc_writel(host, REG_SD_NTSR, rval);
> +   }
>
> ret = sunxi_mmc_clk_set_phase(host, ios, rate);
> if (ret)
> --
> 2.13.2
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH] mmc: sunxi: change controller error info to debug level

[Ulf Hansson]

On 16 March 2017 at 14:29, Icenowy Zheng  wrote:
> The controller's errors are usually normal (for example, for MMC or SDIO
> cards, some errors are expected to happen; and for boards without a
> dedicated card detect pin the error info will even flood console and
> hide other normal messages) and hard to understand.
>
> Change their print level to debug, thus it won't be shown to generic
> users.
>
> Signed-off-by: Icenowy Zheng 

For some reason this change didn't enter the mmc patchtracker. However
I have picked it up for next anyway.

Thanks!

Kind regards
Uffe

> ---
>  drivers/mmc/host/sunxi-mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 6ffcd2838272..0391c62cc99f 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -489,7 +489,7 @@ static void sunxi_mmc_dump_errinfo(struct sunxi_mmc_host 
> *host)
>   cmd->opcode == SD_IO_RW_DIRECT))
> return;
>
> -   dev_err(mmc_dev(host->mmc),
> +   dev_dbg(mmc_dev(host->mmc),
> "smc %d err, cmd %d,%s%s%s%s%s%s%s%s%s%s !!\n",
> host->mmc->index, cmd->opcode,
> data ? (data->flags & MMC_DATA_WRITE ? " WR" : " RD") : "",
> --
> 2.12.0
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH RESEND] mmc: sunxi: Check the value returned by clk_round_rate

[Ulf Hansson]

On 23 August 2016 at 10:51, Jean-Francois Moine  wrote:
> clk_round_rate() may return an error. Check it.
>
> Signed-off-by: Jean-Francois Moine 
> Acked-by: Maxime Ripard 

Thanks, applied for next!

For some reason this patch didn't go into the mmc patchtracker,
probably because you have several lists on cc. Future wise I guess
it's better if you have linux-mmc on the *to* list.

Kind regards
Uffe

> ---
> Rebase on linux-next
> ---
>  drivers/mmc/host/sunxi-mmc.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 2ec91ce..142ab3f 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -692,7 +692,8 @@ static int sunxi_mmc_clk_set_phase(struct sunxi_mmc_host 
> *host,
>  static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
>   struct mmc_ios *ios)
>  {
> -   u32 rate, rval, clock = ios->clock;
> +   long rate;
> +   u32 rval, clock = ios->clock;
> int ret;
>
> /* 8 bit DDR requires a higher module clock */
> @@ -701,13 +702,18 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
> *host,
> clock <<= 1;
>
> rate = clk_round_rate(host->clk_mmc, clock);
> -   dev_dbg(mmc_dev(host->mmc), "setting clk to %d, rounded %d\n",
> +   if (rate < 0) {
> +   dev_err(mmc_dev(host->mmc), "error rounding clk to %d: %ld\n",
> +   clock, rate);
> +   return rate;
> +   }
> +   dev_dbg(mmc_dev(host->mmc), "setting clk to %d, rounded %ld\n",
> clock, rate);
>
> /* setting clock rate */
> ret = clk_set_rate(host->clk_mmc, rate);
> if (ret) {
> -   dev_err(mmc_dev(host->mmc), "error setting clk to %d: %d\n",
> +   dev_err(mmc_dev(host->mmc), "error setting clk to %ld: %d\n",
> rate, ret);
> return ret;
> }
> --
> 2.9.3
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH RESEND] mmc: sunxi: Check the value returned by clk_round_rate

[Ulf Hansson]

On 13 August 2016 at 18:01, Jean-Francois Moine  wrote:
> clk_round_rate() may return an error. Check it.
>
> Signed-off-by: Jean-Francois Moine 
> Acked-by: Maxime Ripard 

Please re-spins this as it doesn't apply cleanly due to recent new
sunxi changes.

Kind regards
Uffe

> ---
> This patch was initially sent in a patch series about the MMC new mode,
> but it may be applied independently.
> ---
>  drivers/mmc/host/sunxi-mmc.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 2ee4c21..ba647b7 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -656,7 +656,8 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host 
> *host, u32 oclk_en)
>  static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
>   struct mmc_ios *ios)
>  {
> -   u32 rate, oclk_dly, rval, sclk_dly;
> +   long rate;
> +   u32 oclk_dly, rval, sclk_dly;
> u32 clock = ios->clock;
> int ret;
>
> @@ -666,13 +667,18 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
> *host,
> clock <<= 1;
>
> rate = clk_round_rate(host->clk_mmc, clock);
> -   dev_dbg(mmc_dev(host->mmc), "setting clk to %d, rounded %d\n",
> +   if (rate < 0) {
> +   dev_err(mmc_dev(host->mmc), "error rounding clk to %d: %ld\n",
> +   clock, rate);
> +   return rate;
> +   }
> +   dev_dbg(mmc_dev(host->mmc), "setting clk to %d, rounded %ld\n",
> clock, rate);
>
> /* setting clock rate */
> ret = clk_set_rate(host->clk_mmc, rate);
> if (ret) {
> -   dev_err(mmc_dev(host->mmc), "error setting clk to %d: %d\n",
> +   dev_err(mmc_dev(host->mmc), "error setting clk to %ld: %d\n",
> rate, ret);
> return ret;
> }
> --
> 2.9.2
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 0/3] mmc: sunxi: Support eMMC DDR modes

[Ulf Hansson]

On 29 January 2016 at 18:21, Chen-Yu Tsai  wrote:
> Hi everyone,
>
> This was "mmc: sunxi: Support vqmmc regulator and eMMC DDR modes". vqmmc
> support and DT patches were merged even though it was an RFC series, to
> my suprise.
>
> These are the remaining patches that add eMMC HS-DDR support to sunxi.
>
> Patch 1 adds timing delays for MMC_DDR52 mode.
>
> Patch 2 adds support for 8 bit eMMC DDR52 mode. Under this mode, the
> controller must run at twice the card clock, and different timing delays
> are needed.
>
> Patch 3 enables eMMC HS-DDR for sunxi-mmc.
>
>
> Changes since RFC:
>
>   - Dropped patches that are merged
>
>   - Dropped "mmc: sunxi: Block signal voltage switching (CMD11)".
> According to Ulf, the mmc core won't send this command unless the UHS
> capabilities are set. We don't.
>
>   - Increased f_max to 52 MHz. Clock rate range for 50 MHz timing delay
> also increased to match. See patch 1.
>
>
> Regards
> ChenYu
>
>
> Chen-Yu Tsai (3):
>   mmc: sunxi: Support MMC_DDR52 timing modes
>   mmc: sunxi: Support 8 bit eMMC DDR transfer modes
>   mmc: sunxi: Enable eMMC HS-DDR (MMC_CAP_1_8V_DDR) support
>
>  drivers/mmc/host/sunxi-mmc.c | 42 --
>  1 file changed, 32 insertions(+), 10 deletions(-)
>
> --
> 2.7.0
>

Thanks, applied for next!

Kind regards
Uffe

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH RFC 03/15] mmc: sunxi: Block signal voltage switching (CMD11)

[Ulf Hansson]

On 21 January 2016 at 06:26, Chen-Yu Tsai  wrote:
> Allwinner's mmc controller supports signal voltage switching. This is
> supported in code in Allwinner's kernel. However, publicly available
> boards all tie it to a fixed 3.0/3.3V regulator, with options to tie
> it to 1.8V for eMMC on some.
>
> Since Allwinner's kernel is an ancient 3.4, it is hard to say whether
> adapting it's code to a modern mainline kernel would work. Block signal
> voltage switching until someone has proper hardware to implement and
> test this.
>
> This only affects SD UHS-1 modes, as eMMC switches the voltage directly
> without any signaling.
>
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/mmc/host/sunxi-mmc.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 790f01662b4e..0495ae7da6d6 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -816,6 +816,20 @@ static void sunxi_mmc_request(struct mmc_host *mmc, 
> struct mmc_request *mrq)
> }
> }
>
> +   /*
> +* TODO Support signal voltage switching
> +*
> +* Compared to Allwinner's kernel, recent updates in the mmc core
> +* mean this should be as easy as setting the flags in cmd_val and
> +* imask, and waiting for it to finish. However no boards support
> +* this so this cannot be tested. Block it for now.
> +*/
> +   if (cmd->opcode == SD_SWITCH_VOLTAGE) {
> +   mrq->cmd->error = -EPERM;
> +   mmc_request_done(mmc, mrq);
> +   return;
> +   }

Unless some of the MMC_CAP_UHS* mode is set, this command shouldn't be sent.

So, if you *really* want to protect from this, I think it's better to
clear these caps in the ->probe() function, after mmc_of_parse() has
been called.

> +
> if (cmd->opcode == MMC_GO_IDLE_STATE) {
> cmd_val |= SDXC_SEND_INIT_SEQUENCE;
> imask |= SDXC_COMMAND_DONE;
> --
> 2.7.0.rc3
>

Kind regards
Uffe

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH RFC 01/15] mmc: sunxi: Document host init sequence

[Ulf Hansson]

On 21 January 2016 at 06:26, Chen-Yu Tsai  wrote:
> sunxi_mmc_init_host() originated from Allwinner kernel sources. The
> magic numbers written to various registers was never documented.
>
> Add comments for values found in Allwinner user manuals.
>
> Signed-off-by: Chen-Yu Tsai 

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/sunxi-mmc.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 83de82bceafc..cce5ca540857 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -284,16 +284,28 @@ static int sunxi_mmc_init_host(struct mmc_host *mmc)
> if (sunxi_mmc_reset_host(host))
> return -EIO;
>
> +   /*
> +* Burst 8 transfers, RX trigger level: 7, TX trigger level: 8
> +*
> +* TODO: sun9i has a larger FIFO and supports higher trigger values
> +*/
> mmc_writel(host, REG_FTRGL, 0x20070008);
> +   /* Maximum timeout value */
> mmc_writel(host, REG_TMOUT, 0x);
> +   /* Unmask SDIO interrupt if needed */
> mmc_writel(host, REG_IMASK, host->sdio_imask);
> +   /* Clear all pending interrupts */
> mmc_writel(host, REG_RINTR, 0x);
> +   /* Debug register? undocumented */
> mmc_writel(host, REG_DBGC, 0xdeb);
> +   /* Enable CEATA support */
> mmc_writel(host, REG_FUNS, SDXC_CEATA_ON);
> +   /* Set DMA descriptor list base address */
> mmc_writel(host, REG_DLBA, host->sg_dma);
>
> rval = mmc_readl(host, REG_GCTRL);
> rval |= SDXC_INTERRUPT_ENABLE_BIT;
> +   /* Undocumented, but found in Allwinner code */
> rval &= ~SDXC_ACCESS_DONE_DIRECT;
> mmc_writel(host, REG_GCTRL, rval);
>
> --
> 2.7.0.rc3
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH RFC 04/15] mmc: sunxi: Support vqmmc regulator

[Ulf Hansson]

On 21 January 2016 at 06:26, Chen-Yu Tsai  wrote:
> eMMC chips require 2 power supplies, vmmc for internal logic, and vqmmc
> for driving output buffers. vqmmc also controls signaling voltage. Most
> boards we've seen use the same regulator for both, nevertheless the 2
> have different usages, and should be set separately.
>
> This patch adds support for vqmmc regulator supply, including voltage
> switching. The MMC core can use this to try different signaling voltages
> for eMMC.
>
> Signed-off-by: Chen-Yu Tsai 

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/sunxi-mmc.c | 31 +++
>  1 file changed, 31 insertions(+)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 0495ae7da6d6..4bec87458317 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -256,6 +257,9 @@ struct sunxi_mmc_host {
> struct mmc_request *mrq;
> struct mmc_request *manual_stop_mrq;
> int ferror;
> +
> +   /* vqmmc */
> +   boolvqmmc_enabled;
>  };
>
>  static int sunxi_mmc_reset_host(struct sunxi_mmc_host *host)
> @@ -716,6 +720,16 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
> if (host->ferror)
> return;
>
> +   if (!IS_ERR(mmc->supply.vqmmc)) {
> +   host->ferror = regulator_enable(mmc->supply.vqmmc);
> +   if (host->ferror) {
> +   dev_err(mmc_dev(mmc),
> +   "failed to enable vqmmc\n");
> +   return;
> +   }
> +   host->vqmmc_enabled = true;
> +   }
> +
> host->ferror = sunxi_mmc_init_host(mmc);
> if (host->ferror)
> return;
> @@ -727,6 +741,9 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
> dev_dbg(mmc_dev(mmc), "power off!\n");
> sunxi_mmc_reset_host(host);
> mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
> +   if (!IS_ERR(mmc->supply.vqmmc) && host->vqmmc_enabled)
> +   regulator_disable(mmc->supply.vqmmc);
> +   host->vqmmc_enabled = false;
> break;
> }
>
> @@ -758,6 +775,19 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
> }
>  }
>
> +static int sunxi_mmc_volt_switch(struct mmc_host *mmc, struct mmc_ios *ios)
> +{
> +   /* vqmmc regulator is available */
> +   if (!IS_ERR(mmc->supply.vqmmc))
> +   return mmc_regulator_set_vqmmc(mmc, ios);
> +
> +   /* no vqmmc regulator, assume fixed regulator at 3/3.3V */
> +   if (mmc->ios.signal_voltage == MMC_SIGNAL_VOLTAGE_330)
> +   return 0;
> +
> +   return -EINVAL;
> +}
> +
>  static void sunxi_mmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
>  {
> struct sunxi_mmc_host *host = mmc_priv(mmc);
> @@ -923,6 +953,7 @@ static struct mmc_host_ops sunxi_mmc_ops = {
> .get_ro  = mmc_gpio_get_ro,
> .get_cd  = mmc_gpio_get_cd,
> .enable_sdio_irq = sunxi_mmc_enable_sdio_irq,
> +   .start_signal_voltage_switch = sunxi_mmc_volt_switch,
> .hw_reset= sunxi_mmc_hw_reset,
> .card_busy   = sunxi_mmc_card_busy,
>  };
> --
> 2.7.0.rc3
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH RFC 02/15] mmc: sunxi: Return error on mmc_regulator_set_ocr() fail in .set_ios op

[Ulf Hansson]

On 21 January 2016 at 06:26, Chen-Yu Tsai  wrote:
> Let .set_ios() fail if mmc_regulator_set_ocr() fails to enable and set a
> proper voltage for vmmc.
>
> Signed-off-by: Chen-Yu Tsai 

Thanks, applied for next!

Kind regards
Uffe


> ---
>  drivers/mmc/host/sunxi-mmc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index cce5ca540857..790f01662b4e 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -711,7 +711,10 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
> break;
>
> case MMC_POWER_UP:
> -   mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, ios->vdd);
> +   host->ferror = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc,
> +ios->vdd);
> +   if (host->ferror)
> +   return;
>
> host->ferror = sunxi_mmc_init_host(mmc);
> if (host->ferror)
> --
> 2.7.0.rc3
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH] mmc: sunxi: Fix clk-delay settings

[Ulf Hansson]

On 23 September 2015 at 22:06, Hans de Goede  wrote:
> In recent allwinner kernel sources the mmc clk-delay settings have been
> slightly tweaked, and for sun9i they are completely different then what
> we are using.
>
> This commit brings us in sync with what allwinner does, fixing problems
> accessing sdcards on some A33 devices (and likely others).
>
> For pre sun9i hardware this makes the following changes:
> -At 400Khz change the sample delay from 7 to 0 (introduced in A31 sdk)
> -At 50 Mhz change the sample delay from 5 to 4 (introduced in A23 sdk)
>
> This also drops the clk-delay calculation for clocks > 50 MHz, we do
> not need this as we've: mmc->f_max = 5000, and the delays in the
> old code were not correct (at 100 MHz the delay must be a multiple of 60,
> at 200 MHz a multiple of 120).
>
> Signed-off-by: Hans de Goede 

I assume you want me to take this as a fix? If so, can we point to
what commit it fixes?

Kind regards
Uffe

> ---
>  drivers/mmc/host/sunxi-mmc.c | 53 
> 
>  1 file changed, 39 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index e6226cd..83de82b 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -210,6 +210,16 @@
>  #define SDXC_IDMAC_DES0_CESBIT(30) /* card error summary */
>  #define SDXC_IDMAC_DES0_OWNBIT(31) /* 1-idma owns it, 0-host owns it */
>
> +#define SDXC_CLK_400K  0
> +#define SDXC_CLK_25M   1
> +#define SDXC_CLK_50M   2
> +#define SDXC_CLK_50M_DDR   3
> +
> +struct sunxi_mmc_clk_delay {
> +   u32 output;
> +   u32 sample;
> +};
> +
>  struct sunxi_idma_des {
> u32 config;
> u32 buf_size;
> @@ -229,6 +239,7 @@ struct sunxi_mmc_host {
> struct clk  *clk_mmc;
> struct clk  *clk_sample;
> struct clk  *clk_output;
> +   const struct sunxi_mmc_clk_delay *clk_delays;
>
> /* irq */
> spinlock_t  lock;
> @@ -654,25 +665,19 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
> *host,
>
> /* determine delays */
> if (rate <= 40) {
> -   oclk_dly = 180;
> -   sclk_dly = 42;
> +   oclk_dly = host->clk_delays[SDXC_CLK_400K].output;
> +   sclk_dly = host->clk_delays[SDXC_CLK_400K].sample;
> } else if (rate <= 2500) {
> -   oclk_dly = 180;
> -   sclk_dly = 75;
> +   oclk_dly = host->clk_delays[SDXC_CLK_25M].output;
> +   sclk_dly = host->clk_delays[SDXC_CLK_25M].sample;
> } else if (rate <= 5000) {
> if (ios->timing == MMC_TIMING_UHS_DDR50) {
> -   oclk_dly = 60;
> -   sclk_dly = 120;
> +   oclk_dly = host->clk_delays[SDXC_CLK_50M_DDR].output;
> +   sclk_dly = host->clk_delays[SDXC_CLK_50M_DDR].sample;
> } else {
> -   oclk_dly = 90;
> -   sclk_dly = 150;
> +   oclk_dly = host->clk_delays[SDXC_CLK_50M].output;
> +   sclk_dly = host->clk_delays[SDXC_CLK_50M].sample;
> }
> -   } else if (rate <= 1) {
> -   oclk_dly = 6;
> -   sclk_dly = 24;
> -   } else if (rate <= 2) {
> -   oclk_dly = 3;
> -   sclk_dly = 12;
> } else {
> return -EINVAL;
> }
> @@ -878,6 +883,7 @@ static int sunxi_mmc_card_busy(struct mmc_host *mmc)
>  static const struct of_device_id sunxi_mmc_of_match[] = {
> { .compatible = "allwinner,sun4i-a10-mmc", },
> { .compatible = "allwinner,sun5i-a13-mmc", },
> +   { .compatible = "allwinner,sun9i-a80-mmc", },
> { /* sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(of, sunxi_mmc_of_match);
> @@ -892,6 +898,20 @@ static struct mmc_host_ops sunxi_mmc_ops = {
> .card_busy   = sunxi_mmc_card_busy,
>  };
>
> +static const struct sunxi_mmc_clk_delay sunxi_mmc_clk_delays[] = {
> +   [SDXC_CLK_400K] = { .output = 180, .sample = 180 },
> +   [SDXC_CLK_25M]  = { .output = 180, .sample =  75 },
> +   [SDXC_CLK_50M]  = { .output =  90, .sample = 120 },
> +   [SDXC_CLK_50M_DDR]  = { .output =  60, .sample = 120 },
> +};
> +
> +static const struct sunxi_mmc_clk_delay sun9i_mmc_clk_delays[] = {
> +   [SDXC_CLK_400K] = { .output = 180, .sample = 180 },
> +   [SDXC_CLK_25M]  = { .output = 180, .sample =  75 },
> +   [SDXC_CLK_50M]  = { .output = 150, .sample = 120 },
> +   [SDXC_CLK_50M_DDR]  = { .output =  90, .sample = 120 },
> +};
> +
>  static int sunxi_mmc_resource_request(struct sunxi_mmc_host *host,
>   struct platform_device *pdev)
>  {
> @@ -903,6 +923,11 @@ 

Re: [linux-sunxi] [PATCH v3 1/3] mmc: sunxi: fix timeout in sunxi_mmc_oclk_onoff

[Ulf Hansson]

On 12 August 2015 at 16:49, Hans de Goede hdego...@redhat.com wrote:
 Hi,

 On 08/12/2015 03:29 PM, Michal Suchanek wrote:

 The 250ms timeout is too short.

 On my system enabling the oclk takes under 50ms and disabling slightly
 over 100ms when idle. Under load disabling the clock can take over
 350ms.

 This does not make mmc clock gating look like good option to have on
 sunxi but the system should not crash with mmc clock gating enabled
 nonetheless.

 This patch sets the timeout to 750ms.

 Signed-off-by: Michal Suchanek hramr...@gmail.com

 ---
 v3
   - remove debug message


 Thanks, this one looks good to me:

 Acked-by: Hans de Goede hdego...@redhat.com

 Ulf, can you apply this one please?

 Thanks  Regards,

 Hans


Thanks, applied for next!

Kind regards
Uffe



 v2
   - fix formatting
 ---
   drivers/mmc/host/sunxi-mmc.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
 index 4d3e1ff..a7b7a67 100644
 --- a/drivers/mmc/host/sunxi-mmc.c
 +++ b/drivers/mmc/host/sunxi-mmc.c
 @@ -595,7 +595,7 @@ static irqreturn_t sunxi_mmc_handle_manual_stop(int
 irq, void *dev_id)

   static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32
 oclk_en)
   {
 -   unsigned long expire = jiffies + msecs_to_jiffies(250);
 +   unsigned long expire = jiffies + msecs_to_jiffies(750);
 u32 rval;

 rval = mmc_readl(host, REG_CLKCR);



-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 1/2] mmc: Add support for marking hpi as broken through devicetree

[Ulf Hansson]

On 29 March 2015 at 20:09, Hans de Goede hdego...@redhat.com wrote:
 The eMMC on a tablet I've will stop working / communicating as soon as
 the kernel executes:

 mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
 EXT_CSD_HPI_MGMT, 1,
 card-ext_csd.generic_cmd6_time);

 There seems to be no way to reliable identify eMMC-s which have a broken
 hpi implementation, but at least for eMMC's which are soldered onto a board
 we can work around this by specifying that hpi is broken in devicetree.

Seems like a reasonable approach!


 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  Documentation/devicetree/bindings/mmc/mmc-card.txt | 31 
 ++
  drivers/mmc/core/mmc.c | 10 ++-
  2 files changed, 40 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.txt

 diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.txt 
 b/Documentation/devicetree/bindings/mmc/mmc-card.txt
 new file mode 100644
 index 000..0cc67fb
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/mmc/mmc-card.txt
 @@ -0,0 +1,31 @@
 +mmc-card / eMMC bindings
 +
 +
 +This documents describes the devicetree bindings for a mmc-host controller
 +child node describing a mmc-card / an eMMC, see Use of Function subnodes
 +in mmc.txt
 +
 +Required properties:
 +-compatible : Must be mmc-card
 +-reg: Must be 0

Instead of using a compatible, why can we just use reg = 0?

 +
 +Optional properties:
 +-broken-hpi : Use this to indicate that the mmc-card has a broken hpi
 +  implementation, and that hpi should not be used
 +
 +Example:
 +
 +mmc2 {
 +   pinctrl-names = default;
 +   pinctrl-0 = mmc2_pins_a;
 +   vmmc-supply = reg_vcc3v3;
 +   bus-width = 8;
 +   non-removable;
 +   status = okay;
 +
 +   mmmcard: mmccard@0 {
 +   reg = 0;
 +   compatible = mmc-card;
 +   broken-hpi;
 +   };
 +};
 diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
 index 1d41e85..8d18920 100644
 --- a/drivers/mmc/core/mmc.c
 +++ b/drivers/mmc/core/mmc.c
 @@ -11,6 +11,7 @@
   */

  #include linux/err.h
 +#include linux/of.h
  #include linux/slab.h
  #include linux/stat.h
  #include linux/pm_runtime.h
 @@ -336,6 +337,8 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 
 *ext_csd)
  {
 int err = 0, idx;
 unsigned int part_size;
 +   struct device_node *np = card-dev.of_node;
 +   bool broken_hpi = false;

 /* Version is coded in the CSD_STRUCTURE byte in the EXT_CSD register 
 */
 card-ext_csd.raw_ext_csd_structure = ext_csd[EXT_CSD_STRUCTURE];
 @@ -349,6 +352,9 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 
 *ext_csd)
 }
 }

 +   if (np  of_device_is_compatible(np, mmc-card))
 +   broken_hpi = of_property_read_bool(np, broken-hpi);
 +
 /*
  * The EXT_CSD format is meant to be forward compatible. As long
  * as CSD_STRUCTURE does not change, all values for EXT_CSD_REV
 @@ -494,7 +500,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 
 *ext_csd)
 }

 /* check whether the eMMC card supports HPI */
 -   if (ext_csd[EXT_CSD_HPI_FEATURES]  0x1) {
 +   if (!broken_hpi  (ext_csd[EXT_CSD_HPI_FEATURES]  0x1)) {
 card-ext_csd.hpi = 1;
 if (ext_csd[EXT_CSD_HPI_FEATURES]  0x2)
 card-ext_csd.hpi_cmd = MMC_STOP_TRANSMISSION;
 @@ -1251,6 +1257,8 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
 card-ocr = ocr;
 card-type = MMC_TYPE_MMC;
 card-rca = 1;
 +   /* Also gets done by mmc_add_card, but we need early access */
 +   card-dev.of_node = mmc_of_find_child_device(host, 0);
 memcpy(card-raw_cid, cid, sizeof(card-raw_cid));
 }

 --
 2.3.4


Kind regards
Uffe

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH resend v3 0/2] mmc: Add SDIO function devicetree subnode parsing

[Ulf Hansson]

On 30 June 2014 at 11:07, Hans de Goede hdego...@redhat.com wrote:
 Hi All,

 Here is a resend of 3 of my submission of Sascha Hauer's
 mmc: Add SDIO function devicetree subnode parsing patch.

 Can we please get some movement on these patches, either a review specifying
 why this cannot go upstream, or else queuing it up for next / 3.17 ?

 Changes since v1:
 - Submit as a stand-alone patch-set, rather then as part of a larger oob irq
   support patchset crossing multiple subsystems
 - Add a patch to document the already existing practice of using slot subnodes
 - Split of the dt bindings documentation for sdio-func child nodes into its
   own patch
 - Add a preparation patch, setting slot_no where relevant
 - And finally the Add SDIO function devicetree subnode parsing patch itself
   has been modified to look for the sdio function childnodes under a slot node
   instead of directly under the host node

 Changes since v2:
 - Drop the slot subnodes again, and drop the 2 slot subnodes patches

 Regards,

 Hans

So after quite a delay (sorry about that!!), I decided to apply this
patchset for my next branch.

Only a minor trivial conflict showed up on patch2. Also I took the
liberty to change the prefix of patch 1 into only mmc.

Kind regards
Uffe

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v2 1/4] dt: bindings: mmc: Document the practice of using subnodes for slots

[Ulf Hansson]

On 3 June 2014 03:50, Jaehoon Chung jh80.ch...@samsung.com wrote:
 +Suegnwon Jeon

 On 06/02/2014 05:48 PM, Ulf Hansson wrote:
 On 2 June 2014 10:38, Jaehoon Chung jh80.ch...@samsung.com wrote:
 On 06/02/2014 05:29 PM, Ulf Hansson wrote:
 On 1 June 2014 11:23, Hans de Goede hdego...@redhat.com wrote:
 Hi,


 On 05/31/2014 10:13 PM, Olof Johansson wrote:

 On Sat, May 31, 2014 at 12:03 PM, Hans de Goede hdego...@redhat.com
 wrote:

 The following existing MMC host controller bindings use slot subnodes:

 Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
 Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt

 This commit documents this practice in the standard mmc bindings
 documentation.

 Signed-off-by: Hans de Goede hdego...@redhat.com


 There are today only two drivers that use this kind of binding, dw_mmc
 and the at91 one.


 Correct.


 Neither seems to actually ever have been used with
 more than one slot. I doubt anyone building an exynos-based system
 will ever do a multi-slot solution, and it seems that the at91 driver
 doesn't actually handle more than one slot.

 I'm personally not that excited about complicating the bindings by
 opening up for this -- I would rather work towards removing the
 concept of slots if it's one of those things that are going to remain
 unused. We have actually been talking about reworking the dw_mmc
 binding to remove the slot concept (and simplify the driver by doing
 so).


 I'm fine with removing the slot subnode, I added it because of it being
 brought up in the powerup sequence discussion. I explicitly asked there
 if adding such a subnode level was seen as desirable but nobody
 answered :|

 Anyways, either way works for me. I can do a v3 dropping the slot subnode
 level again. I would really like to move forward with a decision on how-to
 represent non probable info for sdio devices in device nodes. So do you
 have any other remarks other then that the slot subnode should be dropped 
 ?
 And if not can you please review and ack (*) v3 of this patch-set once
 I've send it?

 Chris Ball and Ulf Hansson, what is your take on this, are you willing to
 take this patch set? And do you want it with or without the slot subnodes 
 ?

 I certainly appreciate you working actively on this Hans, I will look
 into the patchset as soon as I can.

 I share Olof's view about the slot nodes, we must not add DT bindings
 that isn't really needed.

 Regarding the slot subnodes; Jaehoon Chung recently posted a patchset
 for adding the parsing of it, intended for dwmmc. I withdraw my ack
 for it, and let's try to go in the other direction instead.

 [PATCHv3 0/4] mmc: fixed the mmc_of_parse for dwmmc.

 Thus I suggest we should clean-up host drivers to support only one
 card per host, and entirely skip the slot concept.

 Well, almost platform is used the only one card per host, although some 
 controller is supported the slot concept.
 But we don't know that controller should be used the multi slot per host, 
 in future.
 So I think we can't skip the slot concept.

 The mmc core only supports one card per host.

 Right, mmc core supports one card per host, but host controller can be 
 supported the multiple slot, right?
 Of course, it should be handled at host controller, not core.

The core needs to be involved as well. How will the core otherwise be
able to tell which card to switch to (which also involves sending
actual CMDs to the card), when sending requests.

I would be surprised if SOCs/boards ever want to use this kind of
configuration - simply because of the bad impact on performance and
latency. Until we have a valid case, I just want us to continue to
ignore this option.

Kind regards
Ulf Hansson


 Adding DT bindings for something that seems unlikely to be supported
 in future, seems like a bad idea. It's better to add it when/if
 needed.
 If some SoC use the multiple slot for dw-mmc controller, we can't prevent to 
 use the multiple slot.
 So i'm not sure that host controller's subnode didn't need to support.
 Right. this is bad idea, i also hope that it will not use the multiple slot 
 at dw-mmc in future.

 To Seungwon,

 how about this?

 Best Regards,
 Jaehoon Chung

 Kind regards
 Uffe


 Best Regards,
 Jaehoon Chung


 Kind regards
 Uffe


 Thanks  Regards,

 Hans


 *) Assuming you don't find any issues


 --
 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
 .



-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com

Re: [linux-sunxi] [PATCH v2 1/4] dt: bindings: mmc: Document the practice of using subnodes for slots

[Ulf Hansson]

On 1 June 2014 11:23, Hans de Goede hdego...@redhat.com wrote:
 Hi,


 On 05/31/2014 10:13 PM, Olof Johansson wrote:

 On Sat, May 31, 2014 at 12:03 PM, Hans de Goede hdego...@redhat.com
 wrote:

 The following existing MMC host controller bindings use slot subnodes:

 Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
 Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt

 This commit documents this practice in the standard mmc bindings
 documentation.

 Signed-off-by: Hans de Goede hdego...@redhat.com


 There are today only two drivers that use this kind of binding, dw_mmc
 and the at91 one.


 Correct.


 Neither seems to actually ever have been used with
 more than one slot. I doubt anyone building an exynos-based system
 will ever do a multi-slot solution, and it seems that the at91 driver
 doesn't actually handle more than one slot.

 I'm personally not that excited about complicating the bindings by
 opening up for this -- I would rather work towards removing the
 concept of slots if it's one of those things that are going to remain
 unused. We have actually been talking about reworking the dw_mmc
 binding to remove the slot concept (and simplify the driver by doing
 so).


 I'm fine with removing the slot subnode, I added it because of it being
 brought up in the powerup sequence discussion. I explicitly asked there
 if adding such a subnode level was seen as desirable but nobody
 answered :|

 Anyways, either way works for me. I can do a v3 dropping the slot subnode
 level again. I would really like to move forward with a decision on how-to
 represent non probable info for sdio devices in device nodes. So do you
 have any other remarks other then that the slot subnode should be dropped ?
 And if not can you please review and ack (*) v3 of this patch-set once
 I've send it?

 Chris Ball and Ulf Hansson, what is your take on this, are you willing to
 take this patch set? And do you want it with or without the slot subnodes ?

I certainly appreciate you working actively on this Hans, I will look
into the patchset as soon as I can.

I share Olof's view about the slot nodes, we must not add DT bindings
that isn't really needed.

Regarding the slot subnodes; Jaehoon Chung recently posted a patchset
for adding the parsing of it, intended for dwmmc. I withdraw my ack
for it, and let's try to go in the other direction instead.

[PATCHv3 0/4] mmc: fixed the mmc_of_parse for dwmmc.

Thus I suggest we should clean-up host drivers to support only one
card per host, and entirely skip the slot concept.

Kind regards
Uffe


 Thanks  Regards,

 Hans


 *) Assuming you don't find any issues

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v2 1/4] dt: bindings: mmc: Document the practice of using subnodes for slots

[Ulf Hansson]

On 2 June 2014 10:38, Jaehoon Chung jh80.ch...@samsung.com wrote:
 On 06/02/2014 05:29 PM, Ulf Hansson wrote:
 On 1 June 2014 11:23, Hans de Goede hdego...@redhat.com wrote:
 Hi,


 On 05/31/2014 10:13 PM, Olof Johansson wrote:

 On Sat, May 31, 2014 at 12:03 PM, Hans de Goede hdego...@redhat.com
 wrote:

 The following existing MMC host controller bindings use slot subnodes:

 Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
 Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt

 This commit documents this practice in the standard mmc bindings
 documentation.

 Signed-off-by: Hans de Goede hdego...@redhat.com


 There are today only two drivers that use this kind of binding, dw_mmc
 and the at91 one.


 Correct.


 Neither seems to actually ever have been used with
 more than one slot. I doubt anyone building an exynos-based system
 will ever do a multi-slot solution, and it seems that the at91 driver
 doesn't actually handle more than one slot.

 I'm personally not that excited about complicating the bindings by
 opening up for this -- I would rather work towards removing the
 concept of slots if it's one of those things that are going to remain
 unused. We have actually been talking about reworking the dw_mmc
 binding to remove the slot concept (and simplify the driver by doing
 so).


 I'm fine with removing the slot subnode, I added it because of it being
 brought up in the powerup sequence discussion. I explicitly asked there
 if adding such a subnode level was seen as desirable but nobody
 answered :|

 Anyways, either way works for me. I can do a v3 dropping the slot subnode
 level again. I would really like to move forward with a decision on how-to
 represent non probable info for sdio devices in device nodes. So do you
 have any other remarks other then that the slot subnode should be dropped ?
 And if not can you please review and ack (*) v3 of this patch-set once
 I've send it?

 Chris Ball and Ulf Hansson, what is your take on this, are you willing to
 take this patch set? And do you want it with or without the slot subnodes ?

 I certainly appreciate you working actively on this Hans, I will look
 into the patchset as soon as I can.

 I share Olof's view about the slot nodes, we must not add DT bindings
 that isn't really needed.

 Regarding the slot subnodes; Jaehoon Chung recently posted a patchset
 for adding the parsing of it, intended for dwmmc. I withdraw my ack
 for it, and let's try to go in the other direction instead.

 [PATCHv3 0/4] mmc: fixed the mmc_of_parse for dwmmc.

 Thus I suggest we should clean-up host drivers to support only one
 card per host, and entirely skip the slot concept.

 Well, almost platform is used the only one card per host, although some 
 controller is supported the slot concept.
 But we don't know that controller should be used the multi slot per host, in 
 future.
 So I think we can't skip the slot concept.

The mmc core only supports one card per host.

Adding DT bindings for something that seems unlikely to be supported
in future, seems like a bad idea. It's better to add it when/if
needed.

Kind regards
Uffe


 Best Regards,
 Jaehoon Chung


 Kind regards
 Uffe


 Thanks  Regards,

 Hans


 *) Assuming you don't find any issues



-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v2 1/4] dt: bindings: mmc: Document the practice of using subnodes for slots

[Ulf Hansson]

On 2 June 2014 10:46, Jaehoon Chung jh80.ch...@samsung.com wrote:
 On 06/02/2014 05:38 PM, Jaehoon Chung wrote:
 On 06/02/2014 05:29 PM, Ulf Hansson wrote:
 On 1 June 2014 11:23, Hans de Goede hdego...@redhat.com wrote:
 Hi,


 On 05/31/2014 10:13 PM, Olof Johansson wrote:

 On Sat, May 31, 2014 at 12:03 PM, Hans de Goede hdego...@redhat.com
 wrote:

 The following existing MMC host controller bindings use slot subnodes:

 Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
 Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt

 This commit documents this practice in the standard mmc bindings
 documentation.

 Signed-off-by: Hans de Goede hdego...@redhat.com


 There are today only two drivers that use this kind of binding, dw_mmc
 and the at91 one.


 Correct.


 Neither seems to actually ever have been used with
 more than one slot. I doubt anyone building an exynos-based system
 will ever do a multi-slot solution, and it seems that the at91 driver
 doesn't actually handle more than one slot.

 I'm personally not that excited about complicating the bindings by
 opening up for this -- I would rather work towards removing the
 concept of slots if it's one of those things that are going to remain
 unused. We have actually been talking about reworking the dw_mmc
 binding to remove the slot concept (and simplify the driver by doing
 so).


 I'm fine with removing the slot subnode, I added it because of it being
 brought up in the powerup sequence discussion. I explicitly asked there
 if adding such a subnode level was seen as desirable but nobody
 answered :|

 Anyways, either way works for me. I can do a v3 dropping the slot subnode
 level again. I would really like to move forward with a decision on how-to
 represent non probable info for sdio devices in device nodes. So do you
 have any other remarks other then that the slot subnode should be dropped ?
 And if not can you please review and ack (*) v3 of this patch-set once
 I've send it?

 Chris Ball and Ulf Hansson, what is your take on this, are you willing to
 take this patch set? And do you want it with or without the slot subnodes ?

 I certainly appreciate you working actively on this Hans, I will look
 into the patchset as soon as I can.

 I share Olof's view about the slot nodes, we must not add DT bindings
 that isn't really needed.

 Regarding the slot subnodes; Jaehoon Chung recently posted a patchset
 for adding the parsing of it, intended for dwmmc. I withdraw my ack
 for it, and let's try to go in the other direction instead.

 [PATCHv3 0/4] mmc: fixed the mmc_of_parse for dwmmc.

 Thus I suggest we should clean-up host drivers to support only one
 card per host, and entirely skip the slot concept.

 Well, almost platform is used the only one card per host, although some 
 controller is supported the slot concept.
 But we don't know that controller should be used the multi slot per host, in 
 future.
 So I think we can't skip the slot concept.
 If we need to change the dw-mmc controller, let me know, plz.
 I want to fix this problem before release the 3.16.
 Actually, i think it can remove the subnode, if ensure not to use multi-slot 
 at dwmmc.

That seems like the best approach. Please try to remove the subnodes
and make use of mmc_of_parse, as is.

Kind regards
Uffe

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v13 2/2] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs

[Ulf Hansson]

On 12 May 2014 15:00, Arend van Spriel ar...@broadcom.com wrote:
 On 05/12/2014 02:04 PM, Hans de Goede wrote:

 From: David Lanzendörferdavid.lanzendoer...@o2s.ch

 The Allwinner sunxi mmc host uses dma in bus-master mode using a built-in
 designware idmac controller, which is identical to the one found in the
 mmc-dw
 hosts. However the rest of the host is not identical to mmc-dw, it deals
 with
 sending stop commands in hardware which makes it significantly different
 from the mmc-dw devices.

 HdG: Various cleanups and fixes.


 Just nitpicking, but usually the above line should be added below the
 original signoff, so:

 Signed-off-by: David Lanzendörferdavid.lanzendoer...@o2s.ch

 [hdego...@redhat.com: various cleanups and fixes]

 Signed-off-by: Hans de Goedehdego...@redhat.com


 As is documented in SubmittingPatches.

 Gr. AvS


This looks good to me, thanks Hans!

I will include this in the next PR I send to Chris, I will also take
the liberty to fixup the commit msg as pointed out by Arend.

Kind regards
Ulf Hansson

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v13 1/2] clk: sunxi: Fixup clk_sunxi_mmc_phase_control to take a clk rather then a hw_clk

[Ulf Hansson]

On 12 May 2014 14:04, Hans de Goede hdego...@redhat.com wrote:
 __clk_get_hw is supposed to be used by clk providers, not clk consumers.

 Signed-off-by: Hans de Goede hdego...@redhat.com

Reviewed-by: Ulf Hansson ulf.hans...@linaro.org

 ---
  drivers/clk/sunxi/clk-sunxi.c | 3 ++-
  include/linux/clk/sunxi.h | 2 +-
  2 files changed, 3 insertions(+), 2 deletions(-)

 diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
 index 59f9040..4cc2b2a 100644
 --- a/drivers/clk/sunxi/clk-sunxi.c
 +++ b/drivers/clk/sunxi/clk-sunxi.c
 @@ -510,11 +510,12 @@ CLK_OF_DECLARE(sun7i_a20_gmac, 
 allwinner,sun7i-a20-gmac-clk,
   * clk_sunxi_mmc_phase_control() - configures MMC clock phase control
   */

 -void clk_sunxi_mmc_phase_control(struct clk_hw *hw, u8 sample, u8 output)
 +void clk_sunxi_mmc_phase_control(struct clk *clk, u8 sample, u8 output)
  {
 #define to_clk_composite(_hw) container_of(_hw, struct clk_composite, 
 hw)
 #define to_clk_factors(_hw) container_of(_hw, struct clk_factors, hw)

 +   struct clk_hw *hw = __clk_get_hw(clk);
 struct clk_composite *composite = to_clk_composite(hw);
 struct clk_hw *rate_hw = composite-rate_hw;
 struct clk_factors *factors = to_clk_factors(rate_hw);
 diff --git a/include/linux/clk/sunxi.h b/include/linux/clk/sunxi.h
 index 1ef5c89..aed28c4 100644
 --- a/include/linux/clk/sunxi.h
 +++ b/include/linux/clk/sunxi.h
 @@ -17,6 +17,6 @@

  #include linux/clk.h

 -void clk_sunxi_mmc_phase_control(struct clk_hw *hw, u8 sample, u8 output);
 +void clk_sunxi_mmc_phase_control(struct clk *clk, u8 sample, u8 output);

  #endif
 --
 1.9.0


-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v12 1/6] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs

[Ulf Hansson]

On 11 May 2014 09:46, Hans de Goede hdego...@redhat.com wrote:
 From: David Lanzendörfer david.lanzendoer...@o2s.ch

 The Allwinner sunxi mmc host uses dma in bus-master mode using a built-in
 designware idmac controller, which is identical to the one found in the mmc-dw
 hosts. However the rest of the host is not identical to mmc-dw, it deals with
 sending stop commands in hardware which makes it significantly different
 from the mmc-dw devices.

 HdG: Various cleanups and fixes.

 Signed-off-by: David Lanzendörfer david.lanzendoer...@o2s.ch
 Signed-off-by: Hans de Goede hdego...@redhat.com

[snip]

 +
 +static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
 + struct mmc_ios *ios)
 +{
 +   u32 rate, oclk_dly, rval, sclk_dly, src_clk;
 +   struct clk_hw *hw = __clk_get_hw(host-clk_mmc);

Hi Hans,

This seems like the wrong approach. But I guess it's related to the
clock phase control API you have been discussing with the clk
maintainer, Mike Turquette!?

__clk_get_hw is supposed to be used by clk providers, not clk consumers.

 +   int ret;
 +
 +   rate = clk_round_rate(host-clk_mmc, ios-clock);
 +   dev_dbg(mmc_dev(host-mmc), setting clk to %d, rounded %d\n,
 +   ios-clock, rate);
 +
 +   /* setting clock rate */
 +   ret = clk_set_rate(host-clk_mmc, rate);
 +   if (ret) {
 +   dev_err(mmc_dev(host-mmc), error setting clk to %d: %d\n,
 +   rate, ret);
 +   return ret;
 +   }
 +
 +   ret = sunxi_mmc_oclk_onoff(host, 0);
 +   if (ret)
 +   return ret;
 +
 +   /* clear internal divider */
 +   rval = mmc_readl(host, REG_CLKCR);
 +   rval = ~0xff;
 +   mmc_writel(host, REG_CLKCR, rval);
 +
 +   /* determine delays */
 +   if (rate = 40) {
 +   oclk_dly = 0;
 +   sclk_dly = 7;
 +   } else if (rate = 2500) {
 +   oclk_dly = 0;
 +   sclk_dly = 5;
 +   } else if (rate = 5000) {
 +   if (ios-timing == MMC_TIMING_UHS_DDR50) {
 +   oclk_dly = 2;
 +   sclk_dly = 4;
 +   } else {
 +   oclk_dly = 3;
 +   sclk_dly = 5;
 +   }
 +   } else {
 +   /* rate  5000 */
 +   oclk_dly = 2;
 +   sclk_dly = 4;
 +   }
 +
 +   src_clk = clk_get_rate(clk_get_parent(host-clk_mmc));
 +   if (src_clk = 3  src_clk = 4) {
 +   if (oclk_dly)
 +   oclk_dly--;
 +   if (sclk_dly)
 +   sclk_dly--;
 +   }
 +
 +   clk_sunxi_mmc_phase_control(hw, sclk_dly, oclk_dly);
 +
 +   return sunxi_mmc_oclk_onoff(host, 1);
 +}
 +

[snip]

Besides the above, I think this looks good!

Kind regards
Ulf Hansson

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v12 1/6] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs

[Ulf Hansson]

On 12 May 2014 13:20, Hans de Goede hdego...@redhat.com wrote:
 Hi,

 On 05/12/2014 11:15 AM, Ulf Hansson wrote:
 On 11 May 2014 09:46, Hans de Goede hdego...@redhat.com wrote:
 From: David Lanzendörfer david.lanzendoer...@o2s.ch

 The Allwinner sunxi mmc host uses dma in bus-master mode using a built-in
 designware idmac controller, which is identical to the one found in the 
 mmc-dw
 hosts. However the rest of the host is not identical to mmc-dw, it deals 
 with
 sending stop commands in hardware which makes it significantly different
 from the mmc-dw devices.

 HdG: Various cleanups and fixes.

 Signed-off-by: David Lanzendörfer david.lanzendoer...@o2s.ch
 Signed-off-by: Hans de Goede hdego...@redhat.com

 [snip]

 +
 +static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
 + struct mmc_ios *ios)
 +{
 +   u32 rate, oclk_dly, rval, sclk_dly, src_clk;
 +   struct clk_hw *hw = __clk_get_hw(host-clk_mmc);

 Hi Hans,

 This seems like the wrong approach. But I guess it's related to the
 clock phase control API you have been discussing with the clk
 maintainer, Mike Turquette!?

 Yes, this is meant as a temporary solution until we get a proper
 clock phase control API.


 __clk_get_hw is supposed to be used by clk providers, not clk consumers.

 +   int ret;
 +
 +   rate = clk_round_rate(host-clk_mmc, ios-clock);
 +   dev_dbg(mmc_dev(host-mmc), setting clk to %d, rounded %d\n,
 +   ios-clock, rate);
 +
 +   /* setting clock rate */
 +   ret = clk_set_rate(host-clk_mmc, rate);
 +   if (ret) {
 +   dev_err(mmc_dev(host-mmc), error setting clk to %d: %d\n,
 +   rate, ret);
 +   return ret;
 +   }
 +
 +   ret = sunxi_mmc_oclk_onoff(host, 0);
 +   if (ret)
 +   return ret;
 +
 +   /* clear internal divider */
 +   rval = mmc_readl(host, REG_CLKCR);
 +   rval = ~0xff;
 +   mmc_writel(host, REG_CLKCR, rval);
 +
 +   /* determine delays */
 +   if (rate = 40) {
 +   oclk_dly = 0;
 +   sclk_dly = 7;
 +   } else if (rate = 2500) {
 +   oclk_dly = 0;
 +   sclk_dly = 5;
 +   } else if (rate = 5000) {
 +   if (ios-timing == MMC_TIMING_UHS_DDR50) {
 +   oclk_dly = 2;
 +   sclk_dly = 4;
 +   } else {
 +   oclk_dly = 3;
 +   sclk_dly = 5;
 +   }
 +   } else {
 +   /* rate  5000 */
 +   oclk_dly = 2;
 +   sclk_dly = 4;
 +   }
 +
 +   src_clk = clk_get_rate(clk_get_parent(host-clk_mmc));
 +   if (src_clk = 3  src_clk = 4) {
 +   if (oclk_dly)
 +   oclk_dly--;
 +   if (sclk_dly)
 +   sclk_dly--;
 +   }
 +
 +   clk_sunxi_mmc_phase_control(hw, sclk_dly, oclk_dly);
 +
 +   return sunxi_mmc_oclk_onoff(host, 1);
 +}
 +

 [snip]

 Besides the above, I think this looks good!

 Thanks!

 Since Mike Turquette has already merged clk_sunxi_mmc_phase_control
 I would like to keep this as is, as I already promised Mike, I can
 safely promise you too: I promise clean this up as soon as the
 clock phase control API has been worked out.

Thanks for promise. :-)

Anyway, I think I would like Mike to confirm this violation is
accepted as a temporary solution. Additionally I would like it to be
commented in the code here, that it's a temporary solution and that it
violates the clk API.

Kind regards
Ulf Hansson


 Regards,

 Hans

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v10 03/15] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs

[Ulf Hansson]

 */
 +   sunxi_mmc_exit_host(host);
 +
 +   return ret;
 +}
 +
 +static int sunxi_mmc_probe(struct platform_device *pdev)
 +{
 +   struct sunxi_mmc_host *host;
 +   struct mmc_host *mmc;
 +   int ret;
 +
 +   mmc = mmc_alloc_host(sizeof(struct sunxi_mmc_host), pdev-dev);
 +   if (!mmc) {
 +   dev_err(pdev-dev, mmc alloc host failed\n);
 +   return -ENOMEM;
 +   }
 +
 +   host = mmc_priv(mmc);
 +   host-mmc = mmc;
 +   spin_lock_init(host-lock);
 +   tasklet_init(host-manual_stop_tasklet,
 +sunxi_mmc_manual_stop_tasklet, (unsigned long)host);
 +
 +   ret = sunxi_mmc_resource_request(host, pdev);
 +   if (ret)
 +   goto error_free_host;
 +
 +   host-sg_cpu = dma_alloc_coherent(pdev-dev, PAGE_SIZE,
 + host-sg_dma, GFP_KERNEL);
 +   if (!host-sg_cpu) {
 +   dev_err(pdev-dev, Failed to allocate DMA descriptor 
 mem\n);
 +   ret = -ENOMEM;
 +   goto error_free_host;
 +   }
 +
 +   mmc-ops= sunxi_mmc_ops;
 +   mmc-max_blk_count  = 8192;
 +   mmc-max_blk_size   = 4096;
 +   mmc-max_segs   = PAGE_SIZE / sizeof(struct sunxi_idma_des);
 +   mmc-max_seg_size   = (1  host-idma_des_size_bits);
 +   mmc-max_req_size   = mmc-max_seg_size * mmc-max_segs;
 +   /* 400kHz ~ 50MHz */
 +   mmc-f_min  =   40;
 +   mmc-f_max  = 5000;
 +   /* available voltages */
 +   if (!IS_ERR(host-vmmc))
 +   mmc-ocr_avail = mmc_regulator_get_ocrmask(host-vmmc);
 +   else
 +   mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
 +
 +   mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED;
 +   mmc-caps2 |= MMC_CAP2_NO_PRESCAN_POWERUP;

Are you sure you can enable this cap for all hosts/cards?

There are potential of breaking eMMC devices which has been powered
during boot and unless you can fully reset/power cycle them.

 +
 +   ret = mmc_of_parse(mmc);
 +   if (ret)
 +   goto error_free_dma;
 +
 +   ret = mmc_add_host(mmc);
 +   if (ret)
 +   goto error_free_dma;
 +
 +   dev_info(pdev-dev, base:0x%p irq:%u\n, host-reg_base, host-irq);
 +   platform_set_drvdata(pdev, mmc);
 +   return 0;
 +
 +error_free_dma:
 +   dma_free_coherent(pdev-dev, PAGE_SIZE, host-sg_cpu, host-sg_dma);
 +error_free_host:
 +   mmc_free_host(mmc);
 +   return ret;
 +}
 +
 +static int sunxi_mmc_remove(struct platform_device *pdev)
 +{
 +   struct mmc_host *mmc = platform_get_drvdata(pdev);
 +   struct sunxi_mmc_host *host = mmc_priv(mmc);
 +
 +   mmc_remove_host(mmc);
 +   sunxi_mmc_exit_host(host);
 +   tasklet_disable(host-manual_stop_tasklet);
 +   dma_free_coherent(pdev-dev, PAGE_SIZE, host-sg_cpu, host-sg_dma);
 +   mmc_free_host(mmc);
 +
 +   return 0;
 +}
 +
 +static struct platform_driver sunxi_mmc_driver = {
 +   .driver = {
 +   .name   = sunxi-mmc,
 +   .owner  = THIS_MODULE,
 +   .of_match_table = of_match_ptr(sunxi_mmc_of_match),
 +   },
 +   .probe  = sunxi_mmc_probe,
 +   .remove = sunxi_mmc_remove,
 +};
 +module_platform_driver(sunxi_mmc_driver);
 +
 +MODULE_DESCRIPTION(Allwinner's SD/MMC Card Controller Driver);
 +MODULE_LICENSE(GPL v2);
 +MODULE_AUTHOR(David Lanzendörfer david.lanzendoer...@o2s.ch);
 +MODULE_ALIAS(platform:sunxi-mmc);
 --
 1.9.0


Kind regards
Ulf Hansson

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v10 03/15] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs

[Ulf Hansson]

[snip]

 On 05/05/2014 02:41 PM, Ulf Hansson wrote:
 +struct sunxi_mmc_host {
 +   struct mmc_host *mmc;
 +   struct regulator *vmmc;

 Instead of having a specific regulator for this driver, please use the
 mmc_regulator_get_supply API.

 We cannot use mmc_regulator_get_supply because for the sunxi mmc controller
 not only vqmmc but also vmmc itself is optional, and mmc_regulator_get_supply
 calls devm_regulator_get rather then devm_regulator_get_optional for vmmc.

Is that because the mmc controller handle the power to the card or
because you have a fixed supply?

Having a fixed regulator supply could easily be set up in DT, which
then also dynamically gives you the ocr mask instead of having a them
hard coded.


 Using mmc_regulator_get_supply would lead to false postive errors being logged
 on 99/100 boards.

I was kind of expecting a response like this. :-) Actually I would
prefer if we could make the API suit drivers like this one as well.

For reference, there are currently a patch being discussed which
relates to this topic.
mmc: core: Improve support for deferred regulators



 +   struct reset_control *reset;
 +
 +   /* IO mapping base */
 +   void __iomem*reg_base;
 +
 +   spinlock_t  lock;
 +   struct tasklet_struct manual_stop_tasklet;

 Any reason why you can't use a threaded IRQ handler instead of a tasklet?

 AFAIK IRQ threaded handlers always have the highest priority. When
 the manual_stop_tasklet runs we disable irqs and start polling to
 recover from an error condition, which is nothing something I want
 todo with the highest priority on the system.

To me, that seems like a good match for a threaded irq handler.

I suppose you could change priority of the kthread that executes the
threaded irq handler, if you need that.

[snip]

 +static void sunxi_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 +{
 +   struct sunxi_mmc_host *host = mmc_priv(mmc);
 +   u32 rval;
 +   s32 err;
 +
 +   /* Set the power state */
 +   switch (ios-power_mode) {
 +   case MMC_POWER_ON:
 +   break;
 +
 +   case MMC_POWER_UP:
 +   if (!IS_ERR(host-vmmc)) {
 +   mmc_regulator_set_ocr(host-mmc, host-vmmc, 
 ios-vdd);
 +   udelay(200);
 +   }
 +
 +   err = sunxi_mmc_init_host(mmc);

 So, sunxi_mmc_init_host() will ungate the clocks - but you shouldn't
 use -set_ios() callback to implement power save.

 Clocks should be ungated at -probe() and gated at -remove().

 If fine grained power save is wanted, I advise you to rework the clock
 handling - and to build it upon runtime PM instead. Typically you
 would do these adaptations:

 1. Besides enabling the clocks at -probe(), also enable runtime PM
 and use the runtime PM auto-suspend feature.
 2. Add pm_runtime_get|put at the proper places in the driver.
 3. Implement the runtime PM callbacks (suspend|resume) and do clock
 gating|ungating from there.

 You may refer to drivers/mmc/host/mmci.c to get an example.

 I'll just move the enable / disable to probe / remove for now.

Seems reasonable!

While you do that, it would be nice to have some understanding whether
the reset sequence, also performed by sunxi_mmc_init_host(), is
connected to clk gating|ungating, or a power cycle. I guess you will
find out during testing. :-)


 +   if (err) {
 +   host-ferror = 1;
 +   return;
 +   }
 +
 +   enable_irq(host-irq);

Just realize that I also think you should move the enable|disable_irq
to -probe|remove().

That will mean you will be better prepared to implement runtime PM
support and thus make it possible to disable irqs during request
inactivity.

 +
 +   dev_dbg(mmc_dev(host-mmc), power on!\n);
 +   host-ferror = 0;
 +   break;
 +
 +   case MMC_POWER_OFF:
 +   dev_dbg(mmc_dev(host-mmc), power off!\n);
 +   disable_irq(host-irq);
 +   sunxi_mmc_exit_host(host);

 See comment above for sunxi_mmc_init_host().

 +   if (!IS_ERR(host-vmmc))
 +   mmc_regulator_set_ocr(host-mmc, host-vmmc, 0);
 +
 +   host-ferror = 0;
 +   break;
 +   }
 +
 +   /* set bus width */
 +   switch (ios-bus_width) {
 +   case MMC_BUS_WIDTH_1:
 +   mci_writel(host, REG_WIDTH, SDXC_WIDTH1);
 +   host-bus_width = 1;
 +   break;
 +   case MMC_BUS_WIDTH_4:
 +   mci_writel(host, REG_WIDTH, SDXC_WIDTH4);
 +   host-bus_width = 4;
 +   break;
 +   case MMC_BUS_WIDTH_8:
 +   mci_writel(host, REG_WIDTH, SDXC_WIDTH8);
 +   host-bus_width = 8;
 +   break;
 +   }
 +
 +   /* set ddr mode */
 +   rval = mci_readl(host, REG_GCTRL);
 +   if (ios-timing == MMC_TIMING_UHS_DDR50) {
 +   rval