Re: [PATCH v2] DT: mmc: sh_mmcif: document R8A779[34] support
[CC: Ulrich, Geert] On Wed, Aug 12, 2015 at 01:38:02PM +0300, Sergei Shtylyov wrote: > Hello. > > On 8/12/2015 3:59 AM, Simon Horman wrote: > > >>Renesas R8A7794 SoC also has the MMCIF controller... > > >>Signed-off-by: Sergei Shtylyov > > >This new compat string looks good to me. > > >Acked-by: Simon Horman > >Thank you. I've messed up the subject, so need to re-post. > > >>--- > >>The patch is against Ulf Hansson's 'mmc.git' repo's 'next' branch plus the > >>patch I posted earlier today... > >> > >>Changes in version 2: > >>- deferred R8A7793 support to the patch posted earlier by Ulrich Hecht; > > >Perhaps it would be best to co-ordinate the R8A7793 and R8A7794 > >changes to avoid tedious conflicts. > >I thought about taking out Ulrich's binding patch and re-posting it >along with this one but finally decided not to ruin his series. Do you >mean that I should have posted his patch along with mine? I mean we sould talk about this to come up with a plan that makes things easy for the maintainer to pick up the compat strings for the R8A7793 and R8A7794. -- 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
Re: [PATCH v2] DT: mmc: sh_mmcif: fix "compatible" property text
On Wed, Aug 12, 2015 at 01:41:40PM +0300, Sergei Shtylyov wrote:
> On 8/12/2015 3:56 AM, Simon Horman wrote:
>
> >>The "compatible" property text contradicts even the example given in the
> >>MMCIF
> >>binding document itself; moreover, the Renesas MMCIF driver only matches on
> >>the generic "compatible" string and doesn't look for the SoC specific
> >>strings
> >>at all. Thus describe "renesas,sh-mmcif" as a fallback value.
>
> >>Fixes: b4c27763d749 ("mmc: sh_mmcif: Document DT bindings")
> >>Signed-off-by: Sergei Shtylyov
>
> >I don't believe this file is the appropriate place to describe
> >best-practice for the ordering of compatible strings which must surely be
> >documented elsewhere.
>
>Where? I have no idea what you mean...
>And let me reiterate: this text is *wrong* and needs to be fixed anyway.
The document lists the acceptable compat strings for the driver.
Some are currently implemented by the driver. Some are not.
This provides a mechanism for enhancing the driver while maintaining
compatibility with existing DT blobs.
The document does not describe the way to order the compat strings, which I
believe is a more generic issue as many drivers have more and less specific
compat strings to describe hardware which is compatible with each other. To
some extent I believe it is up to the user, that is the person writing DT
files, to understand what the hardware they are dealing with is compatible
with. And to some extent I believe the ordering is a best-practice that
ought to be described in a high-level document if it is not already.
Your proposed update assumes that all past and future hardware handled by
current and future versions of the driver will be compatible with
"renesas,sh-mmcif". How can you possibly know that is true?
> >>---
> >>The patch is against Ulf Hansson's 'mmc.git' repo's 'fixes' and 'next'
> >>branches.
> >>
> >>Changes in version 2:
> >>- kept the SoC specific "compatible" property values mandatory and made the
> >> generic string a fallback.
> >>
> >> Documentation/devicetree/bindings/mmc/renesas,mmcif.txt |2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >>Index: mmc/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> >>===
> >>--- mmc.orig/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> >>+++ mmc/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> >>@@ -10,7 +10,7 @@ Required properties:
> >>- "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs
> >>- "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs
> >>- "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs
> >>- - "renesas,sh-mmcif" for the generic MMCIF
> >>+ followed by "renesas,sh-mmcif".
> >>
> >> - clocks: reference to the functional clock
>
> MBR, Sergei
>
--
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
Re: [PATCH v2] DT: mmc: sh_mmcif: document R8A779[34] support
On Wed, Aug 12, 2015 at 01:57:45AM +0300, Sergei Shtylyov wrote: > Renesas R8A7794 SoC also has the MMCIF controller... > > Signed-off-by: Sergei Shtylyov This new compat string looks good to me. Acked-by: Simon Horman > > --- > The patch is against Ulf Hansson's 'mmc.git' repo's 'next' branch plus the > patch I posted earlier today... > > Changes in version 2: > - deferred R8A7793 support to the patch posted earlier by Ulrich Hecht; Perhaps it would be best to co-ordinate the R8A7793 and R8A7794 changes to avoid tedious conflicts. > - fixed typo in the changelog. > > Documentation/devicetree/bindings/mmc/renesas,mmcif.txt |1 + > 1 file changed, 1 insertion(+) > > Index: mmc/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt > === > --- mmc.orig/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt > +++ mmc/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt > @@ -10,6 +10,7 @@ Required properties: > - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs > - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs > - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs > + - "renesas,mmcif-r8a7794" for the MMCIF found in r8a7794 SoCs >followed by "renesas,sh-mmcif". > > - clocks: reference to the functional clock > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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
Re: [PATCH v2] DT: mmc: sh_mmcif: fix "compatible" property text
Hi Sergei,
On Wed, Aug 12, 2015 at 01:37:28AM +0300, Sergei Shtylyov wrote:
> The "compatible" property text contradicts even the example given in the MMCIF
> binding document itself; moreover, the Renesas MMCIF driver only matches on
> the generic "compatible" string and doesn't look for the SoC specific strings
> at all. Thus describe "renesas,sh-mmcif" as a fallback value.
>
> Fixes: b4c27763d749 ("mmc: sh_mmcif: Document DT bindings")
> Signed-off-by: Sergei Shtylyov
I don't believe this file is the appropriate place to describe
best-practice for the ordering of compatible strings which must surely be
documented elsewhere.
> ---
> The patch is against Ulf Hansson's 'mmc.git' repo's 'fixes' and 'next'
> branches.
>
> Changes in version 2:
> - kept the SoC specific "compatible" property values mandatory and made the
> generic string a fallback.
>
> Documentation/devicetree/bindings/mmc/renesas,mmcif.txt |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: mmc/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> ===
> --- mmc.orig/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> +++ mmc/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> @@ -10,7 +10,7 @@ Required properties:
> - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs
> - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs
> - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs
> - - "renesas,sh-mmcif" for the generic MMCIF
> + followed by "renesas,sh-mmcif".
>
> - clocks: reference to the functional clock
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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
Re: [PATCH v4 7/8] ARM: shmobile: r8a7790: Set maximum frequencies for SDHI clocks
Hi Morimoto-san, On Tue, Jul 07, 2015 at 01:19:55AM +, Kuninori Morimoto wrote: > > Hi Simon > > > Morimoto-san, > > > > could you find some time to review this patch? > > Sorry, I had forgot about this, I sent Acked-by mail. > But, I guess Ben will send v5 patch Thanks. Ben, I'm happy to take this patch now or after you repost it. Let me know which is best for you. -- 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
Re: [PATCH v4 7/8] ARM: shmobile: r8a7790: Set maximum frequencies for SDHI clocks
Morimoto-san, could you find some time to review this patch? On Tue, Jun 30, 2015 at 05:57:16PM +0100, Ben Hutchings wrote: > Taken from the datasheet. > > Signed-off-by: Ben Hutchings > --- > arch/arm/boot/dts/r8a7790.dtsi | 4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi > index 4bb2f4c17321..618b38938b24 100644 > --- a/arch/arm/boot/dts/r8a7790.dtsi > +++ b/arch/arm/boot/dts/r8a7790.dtsi > @@ -490,6 +490,7 @@ > reg = <0 0xee10 0 0x328>; > interrupts = <0 165 IRQ_TYPE_LEVEL_HIGH>; > clocks = <&mstp3_clks R8A7790_CLK_SDHI0>; > + max-frequency = <15600>; > dmas = <&dmac1 0xcd>, <&dmac1 0xce>; > dma-names = "tx", "rx"; > status = "disabled"; > @@ -500,6 +501,7 @@ > reg = <0 0xee12 0 0x328>; > interrupts = <0 166 IRQ_TYPE_LEVEL_HIGH>; > clocks = <&mstp3_clks R8A7790_CLK_SDHI1>; > + max-frequency = <15600>; > dmas = <&dmac1 0xc9>, <&dmac1 0xca>; > dma-names = "tx", "rx"; > status = "disabled"; > @@ -510,6 +512,7 @@ > reg = <0 0xee14 0 0x100>; > interrupts = <0 167 IRQ_TYPE_LEVEL_HIGH>; > clocks = <&mstp3_clks R8A7790_CLK_SDHI2>; > + max-frequency = <9750>; > dmas = <&dmac1 0xc1>, <&dmac1 0xc2>; > dma-names = "tx", "rx"; > status = "disabled"; > @@ -520,6 +523,7 @@ > reg = <0 0xee16 0 0x100>; > interrupts = <0 168 IRQ_TYPE_LEVEL_HIGH>; > clocks = <&mstp3_clks R8A7790_CLK_SDHI3>; > + max-frequency = <9750>; > dmas = <&dmac1 0xd3>, <&dmac1 0xd4>; > dma-names = "tx", "rx"; > status = "disabled"; > -- > 2.1.4 > > > > -- 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
Re: [PATCH v2 0/6] UHS-I support for sh_mobile_sdhi
On Thu, Jun 11, 2015 at 12:57:57AM +0100, Ben Hutchings wrote:
> On Wed, 2015-06-10 at 11:16 +0200, Ulf Hansson wrote:
> > On 10 June 2015 at 01:21, Ben Hutchings
> > wrote:
> > > This series adds support for UHS-I in sh_mobile_sdhi, partly implemented
> > > in tmio_mmc. This does not yet include tuning for SDR-104, but SDR-50 now
> > > works on the R8A7790 Lager board and another development board.
> > >
> > > The pfc block needs to be reconfigured from 3.3V to 1.8V signalling on
> > > the pins wired to the SD card. This is supported by adding separate
> > > functions for 1.8V signalling in sh-pfc ("sdhi0_1v8" etc.). I expect
> > > that several SH SoCs have this capability, but I only have the R8A7790
> > > data sheet so I only implemented it for that one.
> > >
> > > Changes since v1:
> > > - Reword commit message for "mmc: tmio: Add UHS-I mode support"
> > > - Make sh_mobile_sdhi_start_signal_voltage_switch() succeed if asked
> > > to switch to 3.3V and the regulator or pinctrl or pinctrl state is
> > > missing
> > > - Drop change to mmcif clock on Lager
> > > - Correct original author for sdhi clock changes on Lager
> > >
> > > Changes since the RFC:
> > > - Replace the 'regulator' devices for signal voltage switching with
> > > pinctrl functions and states
> > > - Drop 'mmc: sh_mobile_sdhi: Add actual clock rate support' as it's
> > > redundant
> > > - Use a switch statement in sh_mobile_sdhi_start_signal_voltage_switch()
> > > - Fix subject prefix for the DT changes
> > >
> > > Ben.
> > >
> > > Ben Hutchings (5):
> > > mmc: tmio: Add UHS-I mode support
> > > pinctrl: sh-pfc: Add set_mux operation to struct sh_pfc_function
> > > pinctrl: sh-pfc: r8a7790: Add separate functions for SDHI 1.8V
> > > operation
> > > mmc: sh_mobile_sdhi: Add UHS-I mode support
> > > ARM: shmobile: lager: Enable UHS-I SDR-50
> > >
> > > Ian Molton (1):
> > > ARM: shmobile: lager: Set clock rates for SDHI
> > >
> > > arch/arm/boot/dts/r8a7790-lager.dts | 24 +++--
> > > drivers/mmc/host/sh_mobile_sdhi.c| 60 +++
> > > drivers/mmc/host/tmio_mmc.h | 3 ++
> > > drivers/mmc/host/tmio_mmc_pio.c | 31
> > > drivers/pinctrl/sh-pfc/core.c| 2 +-
> > > drivers/pinctrl/sh-pfc/core.h| 1 +
> > > drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 70
> > > +---
> > > drivers/pinctrl/sh-pfc/pinctrl.c | 4 +++
> > > drivers/pinctrl/sh-pfc/sh_pfc.h | 10 +-
> > > 9 files changed, 197 insertions(+), 8 deletions(-)
> > >
> > > --
> > > 2.1.4
> > >
> >
> > Hi Ben,
> >
> > I have looked at the mmc patches, those looks good to me. Regarding
> > the pinctrl and ARM patches, I suppose these can be taken through
> > their respective trees and I can take the mmc patches?
>
> The problem with that is that I think the device tree change will cause
> a regression if it's applied without the driver changes. I would much
> prefer if I could get the pinctrl and device tree changes acked by the
> respective maintainers to go through the MMC tree. (I should probably
> have said that up front.)
Hi Ben,
I may be misunderstanding the above, if so I apologise, but I would
strongly prefer to avoid an arrangement where the kernel and device tree
blob (DTS/DTSI -> DTB) need to be upgrade in lock-step as this tends not to
lead to a good experience for users. My preference would be to maintain
backwards and forwards compatibility and if appropriate schedule removal of
such compatibility.
> > BTW, I noticed that the pinctrl maintainer wasn't in the to-field, you
> > may need to repost.
>
> I have the relevant _list_ (linux-gpio) in cc and thought that would be
> sufficient, but maybe not, so cc'ing this message.
Thanks. I have also CCed Laurent who has done extensive work on sh-pfc.
--
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
Re: [PATCH 6/6] ARM: shmobile: lager: Enable UHS-I SDR-50
On Mon, May 25, 2015 at 04:00:11AM +, Kuninori Morimoto wrote:
>
> Hi Simon
>
> > On Sun, May 17, 2015 at 01:39:44AM +0100, Ben Hutchings wrote:
> > > Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,2}.
> > >
> > > Signed-off-by: Ben Hutchings
> > > ---
> > > None of the states includes the CD pins, as they can't be allocated both
> > > through pinctrl and as GPIOs. But the Lager manual shows these signals
> > > being pulled up to the same variable voltage as the other signals. This
> > > might possibly lead to spurious card detect interrupts after switching
> > > to 1.8V signalling.
> >
> > Morimoto-san,
> >
> > I would appreciate your opinion on this change.
>
> Ben will send new version patch set if my understanding is correct
Thanks, got it.
--
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
Re: [PATCH 6/6] ARM: shmobile: lager: Enable UHS-I SDR-50
[CC Morimoto-san]
On Sun, May 17, 2015 at 01:39:44AM +0100, Ben Hutchings wrote:
> Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,2}.
>
> Signed-off-by: Ben Hutchings
> ---
> None of the states includes the CD pins, as they can't be allocated both
> through pinctrl and as GPIOs. But the Lager manual shows these signals
> being pulled up to the same variable voltage as the other signals. This
> might possibly lead to spurious card detect interrupts after switching
> to 1.8V signalling.
Morimoto-san,
I would appreciate your opinion on this change.
Thanks.
> arch/arm/boot/dts/r8a7790-lager.dts | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
> b/arch/arm/boot/dts/r8a7790-lager.dts
> index 343ec0ccc8df..5584e835d0f5 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -314,11 +314,21 @@
> renesas,function = "sdhi0";
> };
>
> + sdhi0_pins_1v8: sd0_1v8 {
> + renesas,groups = "sdhi0_data4", "sdhi0_ctrl";
> + renesas,function = "sdhi0_1v8";
> + };
> +
> sdhi2_pins: sd2 {
> renesas,groups = "sdhi2_data4", "sdhi2_ctrl";
> renesas,function = "sdhi2";
> };
>
> + sdhi2_pins_1v8: sd2_1v8 {
> + renesas,groups = "sdhi2_data4", "sdhi2_ctrl";
> + renesas,function = "sdhi2_1v8";
> + };
> +
> mmc1_pins: mmc1 {
> renesas,groups = "mmc1_data8", "mmc1_ctrl";
> renesas,function = "mmc1";
> @@ -491,7 +501,8 @@
>
> &sdhi0 {
> pinctrl-0 = <&sdhi0_pins>;
> - pinctrl-names = "default";
> + pinctrl-1 = <&sdhi0_pins_1v8>;
> + pinctrl-names = "default", "1v8";
>
> assigned-clocks = <&mstp3_clks R8A7790_CLK_SDHI0>;
> assigned-clock-rates = <15600>;
> @@ -499,12 +510,14 @@
> vmmc-supply = <&vcc_sdhi0>;
> vqmmc-supply = <&vccq_sdhi0>;
> cd-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>;
> + sd-uhs-sdr50;
> status = "okay";
> };
>
> &sdhi2 {
> pinctrl-0 = <&sdhi2_pins>;
> - pinctrl-names = "default";
> + pinctrl-1 = <&sdhi2_pins_1v8>;
> + pinctrl-names = "default", "1v8";
>
> assigned-clocks = <&mstp3_clks R8A7790_CLK_SDHI2>;
> assigned-clock-rates = <9750>;
> @@ -512,6 +525,7 @@
> vmmc-supply = <&vcc_sdhi2>;
> vqmmc-supply = <&vccq_sdhi2>;
> cd-gpios = <&gpio3 22 GPIO_ACTIVE_LOW>;
> + sd-uhs-sdr50;
> status = "okay";
> };
>
> --
> 1.7.10.4
>
>
>
--
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
Re: [PATCH 0/3 v6] mmc: sh_mmcif: add parent clk support
Hi Morimoto-san, On Mon, May 25, 2015 at 12:24:59AM +, Kuninori Morimoto wrote: > > Hi Simon, Ulf > > > > Kuninori Morimoto (5): > > > 1) mmc: sh_mmcif: add sh_mmcif_host_to_dev() macro and use it. > > > 2) mmc: sh_mmcif: use sh_mmcif_xxx prefix for all functions > > > 3) mmc: sh_mmcif: calculate best clock with parent clock > > > 4) ARM: shmobile: r8a7790: add MMCIF max-frequency > > > 5) ARM: shmobile: r8a7791: add MMCIF max-frequency > (snip) > > Thanks, applied patch 1->3. I leave 4->5 to Simon. > > Thank you Ulf. > Simon, please check 4) 5) > > Best regards > --- > Kuninori Morimoto > On Mon, May 25, 2015 at 12:38:08AM +, Kuninori Morimoto wrote: > > Hi Simon > > > > Thanks, applied patch 1->3. I leave 4->5 to Simon. > > > > Thanks Ulf. > > > > Morimoto-san, can I confirm that I should go ahead and queue up 4->5 ? > > Thank you for your help. > Yes, please. you don't need to care about 1) - 3) for 4) - 5) patches. > Thanks, I have queued up 5 & 5 for v4.2. -- 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
Re: [PATCH 0/3 v6] mmc: sh_mmcif: add parent clk support
On Fri, May 22, 2015 at 04:01:06PM +0200, Ulf Hansson wrote: > On 14 May 2015 at 09:20, Kuninori Morimoto > wrote: > > > > Hi Ulf, Simon > > > > These patches are v6 of sh_mmcif clock support. > > > > 1) - 2) : cleanup patches > > 3) : v6 patch for clk > > 4) - 5) : DTS patch > > > > Simon > > > > 1) - 3) only : driver uses default clock > > 4) - 5) only : driver uses it, but it is updated to default clock > > 1) - 5) all : it uses new method > > > > so, you can check 4) - 5) without thinking about 1) - 3). > > > > Kuninori Morimoto (5): > > 1) mmc: sh_mmcif: add sh_mmcif_host_to_dev() macro and use it. > > 2) mmc: sh_mmcif: use sh_mmcif_xxx prefix for all functions > > 3) mmc: sh_mmcif: calculate best clock with parent clock > > 4) ARM: shmobile: r8a7790: add MMCIF max-frequency > > 5) ARM: shmobile: r8a7791: add MMCIF max-frequency > > > > Documentation/devicetree/bindings/mmc/renesas,mmcif.txt | 3 ++ > > arch/arm/boot/dts/r8a7790.dtsi | 2 + > > arch/arm/boot/dts/r8a7791.dtsi | 1 + > > drivers/mmc/host/sh_mmcif.c | 220 > > +--- > > 4 files changed, 161 insertions(+), 65 deletions(-) > > Thanks, applied patch 1->3. I leave 4->5 to Simon. Thanks Ulf. Morimoto-san, can I confirm that I should go ahead and queue up 4->5 ? -- 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
Re: [RFC PATCH 4/7] ARM: shmobile: r8a7790: Add nodes for pfc SD voltage regulators
Hi Ben,
thanks for your patch-set.
On Thu, Apr 30, 2015 at 01:31:54PM +0100, Ben Hutchings wrote:
> Signed-off-by: Ben Hutchings
> ---
> arch/arm/boot/dts/r8a7790.dtsi | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
> index 4bb2f4c17321..23e826153a9d 100644
> --- a/arch/arm/boot/dts/r8a7790.dtsi
> +++ b/arch/arm/boot/dts/r8a7790.dtsi
> @@ -483,6 +483,23 @@
> pfc: pfc@e606 {
> compatible = "renesas,pfc-r8a7790";
> reg = <0 0xe606 0 0x250>;
> +
> + vccq_ref_sdhi0: sd-regulator@0 {
> + compatible = "renesas,pfc-r8a7790-sd-regulator";
I'm a little confused. What is "renesas,pfc-r8a7790-sd-regulator"?
It suspect that it should at least be documented under
Documentation/devicetree/bindings/
> + status = "disabled";
> + };
> + vccq_ref_sdhi1: sd-regulator@1 {
> + compatible = "renesas,pfc-r8a7790-sd-regulator";
> + status = "disabled";
> + };
> + vccq_ref_sdhi2: sd-regulator@2 {
> + compatible = "renesas,pfc-r8a7790-sd-regulator";
> + status = "disabled";
> + };
> + vccq_ref_sdhi3: sd-regulator@3 {
> + compatible = "renesas,pfc-r8a7790-sd-regulator";
> + status = "disabled";
> + };
> };
>
> sdhi0: sd@ee10 {
> @@ -490,6 +507,7 @@
> reg = <0 0xee10 0 0x328>;
> interrupts = <0 165 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&mstp3_clks R8A7790_CLK_SDHI0>;
> + vqmmc-ref-supply = <&vccq_ref_sdhi0>;
> dmas = <&dmac1 0xcd>, <&dmac1 0xce>;
> dma-names = "tx", "rx";
> status = "disabled";
> @@ -500,6 +518,7 @@
> reg = <0 0xee12 0 0x328>;
> interrupts = <0 166 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&mstp3_clks R8A7790_CLK_SDHI1>;
> + vqmmc-ref-supply = <&vccq_ref_sdhi1>;
> dmas = <&dmac1 0xc9>, <&dmac1 0xca>;
> dma-names = "tx", "rx";
> status = "disabled";
> @@ -510,6 +529,7 @@
> reg = <0 0xee14 0 0x100>;
> interrupts = <0 167 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&mstp3_clks R8A7790_CLK_SDHI2>;
> + vqmmc-ref-supply = <&vccq_ref_sdhi2>;
> dmas = <&dmac1 0xc1>, <&dmac1 0xc2>;
> dma-names = "tx", "rx";
> status = "disabled";
> @@ -520,6 +540,7 @@
> reg = <0 0xee16 0 0x100>;
> interrupts = <0 168 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&mstp3_clks R8A7790_CLK_SDHI3>;
> + vqmmc-ref-supply = <&vccq_ref_sdhi3>;
> dmas = <&dmac1 0xd3>, <&dmac1 0xd4>;
> dma-names = "tx", "rx";
> status = "disabled";
> --
> 1.7.10.4
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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
Re: [PATCH] mmc: sh_mobile_sdhi: remove sh_mobile_sdhi_info v2
On Mon, Mar 16, 2015 at 05:34:50PM +0100, Arnd Bergmann wrote:
> On Monday 16 March 2015 08:53:40 Kuninori Morimoto wrote:
> > From: Kuninori Morimoto
> >
> > 84f11d5b1f2abc0e22895b7e12e037f0ec03caeb
> > (mmc: sh_mobile_sdhi: remove sh_mobile_sdhi_info)
> > replaced sh_mobile_sdhi_info to tmio_mmc_data, but it was missing
> > to replace board-ape6evm / board-mackerel.
> > Kernel build will be failed without this patch.
> >
> > >> arch/arm/mach-shmobile/board-ape6evm.c:176:21: error: \
> > variable 'sdhi0_pdata' has initializer but incomplete type
> > static const struct sh_mobile_sdhi_info sdhi0_pdata __initconst = {
> > ^
> > >> arch/arm/mach-shmobile/board-ape6evm.c:177:2: error: \
> > unknown field 'tmio_flags' specified in initializer
> > .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE,
> > ^
> > ...
> >
> > Signed-off-by: Kuninori Morimoto
> >
>
> Acked-by: Arnd Bergmann
Acked-by: Simon Horman
--
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
Re: Possible regression in next-20150306 due to "mmc: tmio: Fix PIO mode with CONFIG_HIGHMEM"
On Tue, Mar 10, 2015 at 11:13:38AM +0100, Ulf Hansson wrote:
> On 7 March 2015 at 07:09, Simon Horman wrote:
> > Hi Kobayashi-san, Hi All,
> >
> > I have noticed what appears to be a regression in next-20150306. Using
> > shmobile_defconfig I am unable to boot the koelsch or lager boards to
> > user-space. However, if I revert be7de0b8a90a0b06d ("mmc: tmio: Fix PIO
> > mode with CONFIG_HIGHMEM") then all seems well.
>
> Simon, thanks for testing and reporting!
>
> I decided to drop the above commit from my next branch. Let's see if
> Kobayashi-san comes back with an updated patch, later on.
Thanks, I appreciate it.
--
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
Re: Possible regression in next-20150306 due to "mmc: tmio: Fix PIO mode with CONFIG_HIGHMEM"
On Tue, Mar 10, 2015 at 11:27:29AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Tue, Mar 10, 2015 at 8:29 AM, Simon Horman wrote:
> > On Sat, Mar 07, 2015 at 03:09:20PM +0900, Simon Horman wrote:
> >> I have noticed what appears to be a regression in next-20150306. Using
> >> shmobile_defconfig I am unable to boot the koelsch or lager boards to
> >> user-space. However, if I revert be7de0b8a90a0b06d ("mmc: tmio: Fix PIO
>
> What happens exactly?
I am seeing a NULL pointer dereference which seems to be coming from
tmio_mmc_start_dma.
http://permalink.gmane.org/gmane.linux.ports.sh.devel/44533
Digging a little further it seems the problem is occurring at or around the
following code, where according to my calculations 1333c is the address
reported in the boot log:
static void tmio_mmc_start_dma_rx(struct tmio_mmc_host *host)
{
struct scatterlist *sg = host->sg_ptr, *sg_tmp;
13338: e590501cldr r5, [r0, #28]
dma_cookie_t cookie;
int ret, i;
bool aligned = true, multiple = true;
unsigned int align = (1 << host->pdata->alignment_shift) - 1;
for_each_sg(sg, sg_tmp, host->sg_len, i) {
1333c: e3a0a000mov sl, #0
struct dma_async_tx_descriptor *desc = NULL;
struct dma_chan *chan = host->chan_rx;
dma_cookie_t cookie;
int ret, i;
bool aligned = true, multiple = true;
unsigned int align = (1 << host->pdata->alignment_shift) - 1;
13340: e5938020ldr r8, [r3, #32]
I wonder if host->sg_ptr is NULL.
The patch in question updates tmio_mmc_init_sg() and tmio_mmc_next_sg()
such that host->sg_ptr is no longer assigned by those functions. Perhaps
some further updates are required to handle the DMA case?
> >> mode with CONFIG_HIGHMEM") then all seems well.
> >
> > Apologies, I seem to have messed up the commit id.
> > It should be 5da0e63e268dc5120
>
> I can't seem to reproduce this on koelsch. I tried next-20150306,
> renesas-drivers-2015-03-09-v4.0-rc3, and my local tree based on the latter.
After reading the above I noticed that I had a micro SD card present in
the relevant slot on my koelsch board. I have now checked that without that
card present the problem does not seem to manifiest.
--
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
Re: Possible regression in next-20150306 due to "mmc: tmio: Fix PIO mode with CONFIG_HIGHMEM"
On Sat, Mar 07, 2015 at 03:09:20PM +0900, Simon Horman wrote:
> Hi Kobayashi-san, Hi All,
>
> I have noticed what appears to be a regression in next-20150306. Using
> shmobile_defconfig I am unable to boot the koelsch or lager boards to
> user-space. However, if I revert be7de0b8a90a0b06d ("mmc: tmio: Fix PIO
> mode with CONFIG_HIGHMEM") then all seems well.
Apologies, I seem to have messed up the commit id.
It should be 5da0e63e268dc5120
>
> The log that I see from a koelsch boot is as follows:
>
> Unable to handle kernel NULL pointer dereference at virtual address 0008
> pgd = c0004000
> [0008] *pgd=
> Internal error: Oops: 5 [#1] SMP ARM
> CPU: 0 PID: 577 Comm: kworker/u4:2 Tainted: GW
> 4.0.0-rc2-next-20150306 #1529
> Hardware name: Generic R8A7791 (Flattened Device Tree)
> Workqueue: kmmcd mmc_rescan
> task: eea91580 ti: ee10 task.ti: ee10
> PC is at tmio_mmc_start_dma+0xbc/0x43c
> LR is at tmio_mmc_request+0x1e4/0x498
> pc : []lr : []psr: 2113
> sp : ee101cc0 ip : ee101d00 fp : ee101cfc
> r10: r9 : 0088 r8 : 0001
> r7 : ee9a42b8 r6 : 0001 r5 : r4 : ee0bb6c0
> r3 : 0001 r2 : r1 : ee101da0 r0 :
> Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 10c5307d Table: 4000406a DAC: 0015
> Process kworker/u4:2 (pid: 577, stack limit = 0xee100210)
> Stack: (0xee101cc0 to 0xee102000)
> 1cc0: 0004 6113 0088 ee249b40 ee101cfc ee0bb400 ee101da0 ee101dd0
> 1ce0: ee0bb6c0 0001 0088 ee249b40 ee101d24 ee101d00 c035e538 c035f840
> 1d00: ee101dd0 ee0bb400 ee101de0 0008 ee101da0 ee249b40 ee101d3c ee101d28
> 1d20: c034c98c c035e360 ee0bb400 ee101dd0 ee101d64 ee101d40 c034d06c c034c888
> 1d40: 0001 ee2191b4 ee219000 0008 ee101da0 ee101e2c ee101d68
> 1d60: c035500c c034d034 ee101dc8 0033
> 1d80: 00b5 ee101da0 ee101dd0
> 1da0: 05f5e100 0008 0001 0200
> 1dc0: ee101dd0 0001 ee101df8 ee101d6c ee101da0
> 1de0: ee101de8 ee101de8 c034c9d0 ef5bd922 0b40
> 1e00: 0008 ee219000 ee0bb400 0020
> 1e20: ee101e5c ee101e30 c0353ec4 c0354f10 ee101db8 ee219000 ee0bb400
> 1e40: ee101e6c 0020 ee101eac ee101e60 c03543bc c0353ea4
> 1e60: 00ff8000 01aa 134b4753 44303847 10210076 0400ca00 c0ff8000
> 1e80: ee101eac ee0bb400 c050da08 c050da18 ee0bb610 0088
> 1ea0: ee101ecc ee101eb0 c0354a6c c0354248 c050da18 00ff8000 ee0bb610 ee0bb400
> 1ec0: ee101eec ee101ed0 c034ee68 c03549c0 eea7c600 ee830400 ee837b00
> 1ee0: ee101f2c ee101ef0 c0037d04 c034ebe8 eea7c600 ee830400
> 1f00: ee830414 eea7c600 ee830400 eea7c618 ee830414 ee830400 0088
> 1f20: ee101f5c ee101f30 c0038190 c0037b24 eea91580 eea07940 eea7c600
> 1f40: c0037e70 ee101fac ee101f60 c003cb48 c0037e7c
> 1f60: ee101f5c eea7c600 ee101f78 ee101f78
> 1f80: ee101f88 ee101f88 eea07940 c003ca58
> 1fa0: ee101fb0 c000ec00 c003ca64
> 1fc0:
> 1fe0: 0013 f763e3f6 17bf7af2
> Backtrace:
> [] (tmio_mmc_start_dma) from []
> (tmio_mmc_request+0x1e4/0x498)
> r10:ee249b40 r9:0088 r8:0001 r7:ee0bb6c0 r6:ee101dd0 r5:ee101da0
> r4:ee0bb400
> [] (tmio_mmc_request) from []
> (mmc_start_request+0x110/0x124)
> r10:ee249b40 r8:ee101da0 r7:0008 r6:ee101de0 r5:ee0bb400 r4:ee101dd0
> [] (mmc_start_request) from []
> (mmc_wait_for_req+0x44/0x13c)
> r5:ee101dd0 r4:ee0bb400
> [] (mmc_wait_for_req) from []
> (mmc_app_send_scr+0x108/0x168)
> r8:ee101da0 r7:0008 r6:ee219000 r5: r4:ee2191b4 r3:0001
> [] (mmc_app_send_scr) from []
> (mmc_sd_setup_card+0x2c/0x378)
> r10:0020 r8: r7: r6: r5:ee0bb400 r4:ee219000
> [] (mmc_sd_setup_card) from []
> (mmc_sd_init_card+0x180/0x5e0)
> r10:0020 r8: r7:ee101e6c r6: r5:ee0bb400 r4:ee219000
> [] (mmc_sd_init_card) from [] (mmc_attach_sd+0xb8/0x148)
> r10: r9:0088 r8:ee0bb610 r7:c050da18 r6:c050da08 r5:
> r4:ee0bb400
> [] (mmc_attach_sd) from [] (mmc_rescan+0x28c/0x2fc)
> r5:ee0bb400 r4:ee0bb610
> [] (mmc_rescan) from [] (process_one_work+0x1ec/0x324)
> r7: r6:ee837b00 r5:ee830400 r4:eea7c600
> [] (process_one_work) from []
Possible regression in next-20150306 due to "mmc: tmio: Fix PIO mode with CONFIG_HIGHMEM"
Hi Kobayashi-san, Hi All,
I have noticed what appears to be a regression in next-20150306. Using
shmobile_defconfig I am unable to boot the koelsch or lager boards to
user-space. However, if I revert be7de0b8a90a0b06d ("mmc: tmio: Fix PIO
mode with CONFIG_HIGHMEM") then all seems well.
The log that I see from a koelsch boot is as follows:
Unable to handle kernel NULL pointer dereference at virtual address 0008
pgd = c0004000
[0008] *pgd=
Internal error: Oops: 5 [#1] SMP ARM
CPU: 0 PID: 577 Comm: kworker/u4:2 Tainted: GW
4.0.0-rc2-next-20150306 #1529
Hardware name: Generic R8A7791 (Flattened Device Tree)
Workqueue: kmmcd mmc_rescan
task: eea91580 ti: ee10 task.ti: ee10
PC is at tmio_mmc_start_dma+0xbc/0x43c
LR is at tmio_mmc_request+0x1e4/0x498
pc : []lr : []psr: 2113
sp : ee101cc0 ip : ee101d00 fp : ee101cfc
r10: r9 : 0088 r8 : 0001
r7 : ee9a42b8 r6 : 0001 r5 : r4 : ee0bb6c0
r3 : 0001 r2 : r1 : ee101da0 r0 :
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5307d Table: 4000406a DAC: 0015
Process kworker/u4:2 (pid: 577, stack limit = 0xee100210)
Stack: (0xee101cc0 to 0xee102000)
1cc0: 0004 6113 0088 ee249b40 ee101cfc ee0bb400 ee101da0 ee101dd0
1ce0: ee0bb6c0 0001 0088 ee249b40 ee101d24 ee101d00 c035e538 c035f840
1d00: ee101dd0 ee0bb400 ee101de0 0008 ee101da0 ee249b40 ee101d3c ee101d28
1d20: c034c98c c035e360 ee0bb400 ee101dd0 ee101d64 ee101d40 c034d06c c034c888
1d40: 0001 ee2191b4 ee219000 0008 ee101da0 ee101e2c ee101d68
1d60: c035500c c034d034 ee101dc8 0033
1d80: 00b5 ee101da0 ee101dd0
1da0: 05f5e100 0008 0001 0200
1dc0: ee101dd0 0001 ee101df8 ee101d6c ee101da0
1de0: ee101de8 ee101de8 c034c9d0 ef5bd922 0b40
1e00: 0008 ee219000 ee0bb400 0020
1e20: ee101e5c ee101e30 c0353ec4 c0354f10 ee101db8 ee219000 ee0bb400
1e40: ee101e6c 0020 ee101eac ee101e60 c03543bc c0353ea4
1e60: 00ff8000 01aa 134b4753 44303847 10210076 0400ca00 c0ff8000
1e80: ee101eac ee0bb400 c050da08 c050da18 ee0bb610 0088
1ea0: ee101ecc ee101eb0 c0354a6c c0354248 c050da18 00ff8000 ee0bb610 ee0bb400
1ec0: ee101eec ee101ed0 c034ee68 c03549c0 eea7c600 ee830400 ee837b00
1ee0: ee101f2c ee101ef0 c0037d04 c034ebe8 eea7c600 ee830400
1f00: ee830414 eea7c600 ee830400 eea7c618 ee830414 ee830400 0088
1f20: ee101f5c ee101f30 c0038190 c0037b24 eea91580 eea07940 eea7c600
1f40: c0037e70 ee101fac ee101f60 c003cb48 c0037e7c
1f60: ee101f5c eea7c600 ee101f78 ee101f78
1f80: ee101f88 ee101f88 eea07940 c003ca58
1fa0: ee101fb0 c000ec00 c003ca64
1fc0:
1fe0: 0013 f763e3f6 17bf7af2
Backtrace:
[] (tmio_mmc_start_dma) from []
(tmio_mmc_request+0x1e4/0x498)
r10:ee249b40 r9:0088 r8:0001 r7:ee0bb6c0 r6:ee101dd0 r5:ee101da0
r4:ee0bb400
[] (tmio_mmc_request) from []
(mmc_start_request+0x110/0x124)
r10:ee249b40 r8:ee101da0 r7:0008 r6:ee101de0 r5:ee0bb400 r4:ee101dd0
[] (mmc_start_request) from [] (mmc_wait_for_req+0x44/0x13c)
r5:ee101dd0 r4:ee0bb400
[] (mmc_wait_for_req) from [] (mmc_app_send_scr+0x108/0x168)
r8:ee101da0 r7:0008 r6:ee219000 r5: r4:ee2191b4 r3:0001
[] (mmc_app_send_scr) from [] (mmc_sd_setup_card+0x2c/0x378)
r10:0020 r8: r7: r6: r5:ee0bb400 r4:ee219000
[] (mmc_sd_setup_card) from []
(mmc_sd_init_card+0x180/0x5e0)
r10:0020 r8: r7:ee101e6c r6: r5:ee0bb400 r4:ee219000
[] (mmc_sd_init_card) from [] (mmc_attach_sd+0xb8/0x148)
r10: r9:0088 r8:ee0bb610 r7:c050da18 r6:c050da08 r5:
r4:ee0bb400
[] (mmc_attach_sd) from [] (mmc_rescan+0x28c/0x2fc)
r5:ee0bb400 r4:ee0bb610
[] (mmc_rescan) from [] (process_one_work+0x1ec/0x324)
r7: r6:ee837b00 r5:ee830400 r4:eea7c600
[] (process_one_work) from [] (worker_thread+0x320/0x43c)
r10: r9:0088 r8:ee830400 r7:ee830414 r6:eea7c618 r5:ee830400
r4:eea7c600
[] (worker_thread) from [] (kthread+0xf0/0x104)
r10: r9: r8: r7:c0037e70 r6:eea7c600 r5:
r4:eea07940 r3:eea91580
[] (kthread) from [] (ret_from_fork+0x14/0x34)
r7: r6: r5:c003ca58 r4:eea07940
Code: e358 1a41 e353 0a3f (e5953008)
---[ end trace 73e31bceec8a1115 ]---
Unable to handle kernel paging request at virtual address ffec
pgd = c0004000
[ffec] *pgd=6f7fd821, *pte=, *pp
Re: [PATCH/RFC] mmc: sh_mmcif: Add exclusion between cmd and interrupt
Hi all and in particular Sergei,
elsewhere in this thread Sergei indicated that he felt that
the spin lock around reading host->wait_for in sh_mmcif_irqt() doesn't
"seem to have much sense here, as the read is already atomic."
My initial reaction was that remark was correct. However, Kaneko-san
has done some further analysis which I would now like to share. My
apologies if in advance if I have misinterpreted that analysis.
On Sun, Feb 15, 2015 at 11:46:46PM +0900, Yoshihiro Kaneko wrote:
> From: Kouichi Tomita
>
> A command end interrupt should not be processed between command issue
> and setting of wait_for flag. It expects already the flag to be set.
> Therefore the exclusive control was added.
>
> Signed-off-by: Kouichi Tomita
> Signed-off-by: Yoshihiro Kaneko
> ---
>
> This patch is based on next branch of Chris Ball's mmc tree.
>
> drivers/mmc/host/sh_mmcif.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index 7d9d6a3..e5d0b42 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -875,6 +875,7 @@ static void sh_mmcif_start_cmd(struct sh_mmcif_host *host,
> struct mmc_command *cmd = mrq->cmd;
> u32 opc = cmd->opcode;
> u32 mask;
> + unsigned long flags;
>
> switch (opc) {
> /* response busy check */
> @@ -909,10 +910,12 @@ static void sh_mmcif_start_cmd(struct sh_mmcif_host
> *host,
> /* set arg */
> sh_mmcif_writel(host->addr, MMCIF_CE_ARG, cmd->arg);
> /* set cmd */
We could get an interrupt here.
> + spin_lock_irqsave(&host->lock, flags);
> sh_mmcif_writel(host->addr, MMCIF_CE_CMD_SET, opc);
>
> host->wait_for = MMCIF_WAIT_FOR_CMD;
> schedule_delayed_work(&host->timeout_work, host->timeout);
> + spin_unlock_irqrestore(&host->lock, flags);
> }
>
> static void sh_mmcif_stop_cmd(struct sh_mmcif_host *host,
> @@ -1171,6 +1174,12 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
> struct sh_mmcif_host *host = dev_id;
> struct mmc_request *mrq;
> bool wait = false;
> + unsigned long flags;
> + int wait_work;
> +
> + spin_lock_irqsave(&host->lock, flags);
> + wait_work = host->wait_for;
> + spin_unlock_irqrestore(&host->lock, flags);
>
> cancel_delayed_work_sync(&host->timeout_work);
And without the locking that this patch proposes if an interrupt did occur
at the point noted above then we may cancel work that has not yet been
scheduled. And furthermore the work will subsequently be scheduled and
never canceled.
> @@ -1188,7 +1197,7 @@ static irqreturn_t sh_mmcif_irqt(int irq, void *dev_id)
>* All handlers return true, if processing continues, and false, if the
>* request has to be completed - successfully or not
>*/
> - switch (host->wait_for) {
> + switch (wait_work) {
And without the locking proposed by this patch if an interrupt occurred
at the point annotated above then host->wait_for may be read before it
is set by sh_mmcif_start_cmd().
> case MMCIF_WAIT_FOR_REQUEST:
> /* We're too late, the timeout has already kicked in */
> mutex_unlock(&host->thread_lock);
--
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
Re: [PATCH/RFC] mmc: sh_mmcif: Increase MMCIF clock rate to 97.5MHz
On Thu, Nov 13, 2014 at 01:34:13AM +, Kuninori Morimoto wrote: > > Hi Simon > > > you are correct in assuming that this patch came from the BSP. > > > > Is your opinion that a) changing the clock rate is good but > > b) it needs to be done using a standard method? > > > > If so, is the main change required to use a standard binding string > > rather than "renesas,clk-rate"? Is the driver change above needed at all? > > I'm not 100% understand, but, maybe these settings are required for > MMC/SHDI's good performance. > I guess we can use CCF method for it ? That does sound like an idea worth investigating. I wonder what the best way is to move this forwards. -- 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
Re: [PATCH/RFC] mmc: sh_mmcif: Increase MMCIF clock rate to 97.5MHz
On Thu, Nov 13, 2014 at 12:15:58AM +, Kuninori Morimoto wrote:
>
> Hi Kaneko-san
>
> > From: Shinobu Uehara
> >
> > Signed-off-by: Shinobu Uehara
> > Signed-off-by: Yoshihiro Kaneko
> > ---
> (snip)
> > + if (np && !of_property_read_u32(np, "renesas,clk-rate", &clk_rate)) {
> > + if (clk_rate) {
> > + ret = clk_set_rate(host->hclk, clk_rate);
> > + if (ret < 0)
> > + dev_err(&pdev->dev,
> > + "cannot set clock rate: %d\n", ret);
> > + }
> > + }
>
> I guess this is came from BSP, and you have similar
> bindings on sh_mobile_sdhi.c too.
> But, we need to use "standard" method, not BSP original
Hi Morimoto-san,
you are correct in assuming that this patch came from the BSP.
Is your opinion that a) changing the clock rate is good but
b) it needs to be done using a standard method?
If so, is the main change required to use a standard binding string
rather than "renesas,clk-rate"? Is the driver change above needed at all?
--
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
Re: [PATCH 0/3] ARM: shmobile: Remove unnecessary MMC options
On Wed, Oct 29, 2014 at 03:09:36PM +0100, Geert Uytterhoeven wrote: > Hi Simon, Magnus, > > This patch series, sent before by Morimoto-san, removes unnecessary MMC > options > from the DTS files that are already set automatically by the driver, based on > the compatible property value. Note that these options were never added on > r8a7791, which gained SDHI device nodes later than the three affected SoCs. > > Thanks for applying! Thanks, I have queued these up. -- 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
Re: [PATCH 5/6 v4] ARM: shmobile: remove MMC_CAP2_NO_MULTI_READ from lager
On Mon, Sep 08, 2014 at 11:46:32PM -0700, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> sh_mobile_sdhi cares multiblock read bug.
> remove MMC_CAP2_NO_MULTI_READ flag from board code
>
> Signed-off-by: Kuninori Morimoto
Acked-by: Simon Horman
> ---
> v3 -> v4
>
> - no change
>
> arch/arm/mach-shmobile/board-lager.c |2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/board-lager.c
> b/arch/arm/mach-shmobile/board-lager.c
> index e1d8215..f5a98e2 100644
> --- a/arch/arm/mach-shmobile/board-lager.c
> +++ b/arch/arm/mach-shmobile/board-lager.c
> @@ -630,7 +630,6 @@ static void __init lager_add_rsnd_device(void)
> static struct sh_mobile_sdhi_info sdhi0_info __initdata = {
> .tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
> MMC_CAP_POWER_OFF_CARD,
> - .tmio_caps2 = MMC_CAP2_NO_MULTI_READ,
> .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT |
> TMIO_MMC_WRPROTECT_DISABLE,
> };
> @@ -644,7 +643,6 @@ static struct resource sdhi0_resources[] __initdata = {
> static struct sh_mobile_sdhi_info sdhi2_info __initdata = {
> .tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
> MMC_CAP_POWER_OFF_CARD,
> - .tmio_caps2 = MMC_CAP2_NO_MULTI_READ,
> .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT |
> TMIO_MMC_WRPROTECT_DISABLE,
> };
> --
> 1.7.9.5
>
--
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
Re: [PATCH 4/6 v4] ARM: shmobile: remove MMC_CAP2_NO_MULTI_READ from koelsch
On Mon, Sep 08, 2014 at 11:46:10PM -0700, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> sh_mobile_sdhi cares multiblock read bug.
> remove MMC_CAP2_NO_MULTI_READ flag from board code
>
> Signed-off-by: Kuninori Morimoto
Acked-by: Simon Horman
> ---
> v3 -> v4
>
> - no change
>
> arch/arm/mach-shmobile/board-koelsch.c |3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/board-koelsch.c
> b/arch/arm/mach-shmobile/board-koelsch.c
> index b7d5bc7..126a8b4 100644
> --- a/arch/arm/mach-shmobile/board-koelsch.c
> +++ b/arch/arm/mach-shmobile/board-koelsch.c
> @@ -331,7 +331,6 @@ SDHI_REGULATOR(2, RCAR_GP_PIN(7, 19), RCAR_GP_PIN(2, 26));
> static struct sh_mobile_sdhi_info sdhi0_info __initdata = {
> .tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
> MMC_CAP_POWER_OFF_CARD,
> - .tmio_caps2 = MMC_CAP2_NO_MULTI_READ,
> .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT,
> };
>
> @@ -344,7 +343,6 @@ static struct resource sdhi0_resources[] __initdata = {
> static struct sh_mobile_sdhi_info sdhi1_info __initdata = {
> .tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
> MMC_CAP_POWER_OFF_CARD,
> - .tmio_caps2 = MMC_CAP2_NO_MULTI_READ,
> .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT,
> };
>
> @@ -357,7 +355,6 @@ static struct resource sdhi1_resources[] __initdata = {
> static struct sh_mobile_sdhi_info sdhi2_info __initdata = {
> .tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
> MMC_CAP_POWER_OFF_CARD,
> - .tmio_caps2 = MMC_CAP2_NO_MULTI_READ,
> .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT |
> TMIO_MMC_WRPROTECT_DISABLE,
> };
> --
> 1.7.9.5
>
--
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
Re: [PATCH 0/7 v3] mmc: remove MMC_CAP2_NO_MULTI_READ flags
On Mon, Sep 08, 2014 at 07:45:46PM -0700, Kuninori Morimoto wrote: > > Hi Simon > > > > Kuninori Morimoto (7): > > > mmc: add .multi_io_quirk callback for multi I/O HW bug > > > mmc: use .multi_io_quirk on omap_hsmmc > > > mmc: use .multi_io_quirk on tmio_mmc > > > mmc: use .multi_io_quirk on sh_mobile > > > ARM: shmobile: remove MMC_CAP2_NO_MULTI_READ from koelsch > > > ARM: shmobile: remove MMC_CAP2_NO_MULTI_READ from lager > > > > Hi Morimoto-san, > > > > could you let me know about the dependencies for the above two patches? > > These have deep dependencies. > "ARM: shmobile: remove xxx" patches are based on 1) - 4) patches, > and, it is required to last patch. Thanks, I understand. -- 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
Re: [PATCH 0/7 v3] mmc: remove MMC_CAP2_NO_MULTI_READ flags
On Tue, Sep 02, 2014 at 07:08:02PM -0700, Kuninori Morimoto wrote: > > Hi Ulf, Chris, and Simon > > These are v3 patches of removing MMC_CAP2_NO_MULTI_READ from mmc. > > Simon > 5) and 6) are for sh-arm patches. > Can you check it ? > > Kuninori Morimoto (7): > mmc: add .multi_io_quirk callback for multi I/O HW bug > mmc: use .multi_io_quirk on omap_hsmmc > mmc: use .multi_io_quirk on tmio_mmc > mmc: use .multi_io_quirk on sh_mobile > ARM: shmobile: remove MMC_CAP2_NO_MULTI_READ from koelsch > ARM: shmobile: remove MMC_CAP2_NO_MULTI_READ from lager Hi Morimoto-san, could you let me know about the dependencies for the above two patches? > mmc: remove MMC_CAP2_NO_MULTI_READ flags > > arch/arm/mach-shmobile/board-koelsch.c |3 --- > arch/arm/mach-shmobile/board-lager.c |2 -- > drivers/mmc/card/block.c | 13 + > drivers/mmc/host/omap_hsmmc.c | 17 - > drivers/mmc/host/sh_mobile_sdhi.c | 20 +++- > drivers/mmc/host/tmio_mmc_pio.c| 13 + > include/linux/mfd/tmio.h |4 > include/linux/mmc/host.h |8 +++- > 8 files changed, 68 insertions(+), 12 deletions(-) > > Best regards > --- > Kuninori Morimoto > -- 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
Re: [PATCH 1/5 v2] mmc: shmobile: add renesas,sdhi-rcar-gen1/gen2 in DT compatible
On Tue, Aug 05, 2014 at 06:48:42PM -0700, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> This patch adds DT compatible for Renesas R-Car Gen1/Gen2.
> Current driver has SoC level .compatible
> (r8a7778/r8a7779/r8a7790/r8a7791),
> but these can be match as generation level.
Is this compatibility explicitly documented anywhere?
> Signed-off-by: Kuninori Morimoto
> ---
> v1 -> v2
>
> - update tmio_mmc.txt
>
> Documentation/devicetree/bindings/mmc/tmio_mmc.txt |2 ++
> drivers/mmc/host/sh_mobile_sdhi.c |2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> index 6a2a116..51c05cf 100644
> --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> @@ -11,6 +11,8 @@ optional bindings can be used.
>
> Required properties:
> - compatible:"renesas,sdhi-shmobile" - a generic sh-mobile SDHI unit
> + "renesas,sdhi-rcar-gen1" - a generic R-Car Gen1 SDHI unit
> + "renesas,sdhi-rcar-gen2" - a generic R-Car Gen2 SDHI unit
> "renesas,sdhi-sh7372" - SDHI IP on SH7372 SoC
> "renesas,sdhi-sh73a0" - SDHI IP on SH73A0 SoC
> "renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC
> diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
> b/drivers/mmc/host/sh_mobile_sdhi.c
> index 91058da..cb3bb39 100644
> --- a/drivers/mmc/host/sh_mobile_sdhi.c
> +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> @@ -64,8 +64,10 @@ static const struct of_device_id sh_mobile_sdhi_of_match[]
> = {
> { .compatible = "renesas,sdhi-sh73a0", .data =
> &sh_mobile_sdhi_of_cfg[0], },
> { .compatible = "renesas,sdhi-r8a73a4", .data =
> &sh_mobile_sdhi_of_cfg[0], },
> { .compatible = "renesas,sdhi-r8a7740", .data =
> &sh_mobile_sdhi_of_cfg[0], },
> + { .compatible = "renesas,sdhi-rcar-gen1", .data =
> &of_rcar_gen1_compatible, },
> { .compatible = "renesas,sdhi-r8a7778", .data =
> &of_rcar_gen1_compatible, },
> { .compatible = "renesas,sdhi-r8a7779", .data =
> &of_rcar_gen1_compatible, },
> + { .compatible = "renesas,sdhi-rcar-gen2", .data =
> &of_rcar_gen2_compatible, },
> { .compatible = "renesas,sdhi-r8a7790", .data =
> &of_rcar_gen2_compatible, },
> { .compatible = "renesas,sdhi-r8a7791", .data =
> &of_rcar_gen2_compatible, },
> {},
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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
Re: [PATCH 0/10 v2] mmc: tmio: fixup patches
On Thu, Jul 31, 2014 at 01:27:15PM +0900, カオ ミン ヒェップ wrote: > Hi Simon-san > > On 07/31/2014 11:30 AM, Simon Horman wrote: > >Hi Hiep-san, > > > >On Thu, Jul 31, 2014 at 10:52:08AM +0900, カオ ミン ヒェップ wrote: > >>Hi Morimoto-san, Simon-san > >> > >>On 07/29/2014 05:42 PM, Kuninori Morimoto wrote: > >>>Hi Chris, Simon > >>> > >>>These are v2 of fixup patches for mmc tmio/shmobile. > >>>I tesed these patches on my environment. > >>>I'm very happy if someone test these patches. > >>I have just tested these series on Lager. if remove CONFIG_HIGHMEM from > >>config file, > >>They are good at SDHI and MMC on my environment. > >Could you provided a Tested-by tag? > Tested-by: Nguyen Xuan Nui > Reported-by: Hiep Cao Minh Thanks. Chris, would you consider taking this series? > >>>Kuninori Morimoto (4): > >>> mmc: tmio: care about DMA tx/rx addr offset > >>> mmc: tmio: remove Renesas specific #ifdef > >>> mmc: tmio: remove SCLKEN bit setting from tmio_mmc_set_clock() > >>> mmc: tmio: ensure that the clock has been stopped before set_clock > >>> > >>>Shinobu Uehara (6): > >>> mmc: block: add block number limitation flag for multiple block read > >>> mmc: tmio: clear error IRQ status > >>> mmc: tmio: control multiple block transfer mode > >>> mmc: tmio: add TMIO_MMC_SDIO_STATUS_QUIRK > >>> mmc: tmio: check ILL_FUNC instead of CBSY > >>> mmc: tmio: add actual clock support as option > >>> > >>> arch/arm/mach-shmobile/board-koelsch.c |6 ++--- > >>> arch/arm/mach-shmobile/board-lager.c |4 ++-- > >>> drivers/mmc/card/block.c | 19 +-- > >>> drivers/mmc/host/sh_mobile_sdhi.c | 26 ++--- > >>> drivers/mmc/host/tmio_mmc_dma.c|8 +++ > >>> drivers/mmc/host/tmio_mmc_pio.c| 40 > >>> +--- > >>> include/linux/mfd/tmio.h | 22 ++ > >>> include/linux/mmc/host.h |3 +++ > >>> 8 files changed, 110 insertions(+), 18 deletions(-) > >>> > >>> > >>> > >>Best regards, > >>Cao Minh Hiep. > >> > >>-- > >>To unsubscribe from this list: send the line "unsubscribe linux-sh" in > >>the body of a message to majord...@vger.kernel.org > >>More majordomo info at http://vger.kernel.org/majordomo-info.html > >> > >-- > >To unsubscribe from this list: send the line "unsubscribe linux-sh" in > >the body of a message to majord...@vger.kernel.org > >More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > -- 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
Re: [PATCH 0/10 v2] mmc: tmio: fixup patches
Hi Hiep-san, On Thu, Jul 31, 2014 at 10:52:08AM +0900, カオ ミン ヒェップ wrote: > Hi Morimoto-san, Simon-san > > On 07/29/2014 05:42 PM, Kuninori Morimoto wrote: > >Hi Chris, Simon > > > >These are v2 of fixup patches for mmc tmio/shmobile. > >I tesed these patches on my environment. > >I'm very happy if someone test these patches. > I have just tested these series on Lager. if remove CONFIG_HIGHMEM from > config file, > They are good at SDHI and MMC on my environment. Could you provided a Tested-by tag? > >Kuninori Morimoto (4): > > mmc: tmio: care about DMA tx/rx addr offset > > mmc: tmio: remove Renesas specific #ifdef > > mmc: tmio: remove SCLKEN bit setting from tmio_mmc_set_clock() > > mmc: tmio: ensure that the clock has been stopped before set_clock > > > >Shinobu Uehara (6): > > mmc: block: add block number limitation flag for multiple block read > > mmc: tmio: clear error IRQ status > > mmc: tmio: control multiple block transfer mode > > mmc: tmio: add TMIO_MMC_SDIO_STATUS_QUIRK > > mmc: tmio: check ILL_FUNC instead of CBSY > > mmc: tmio: add actual clock support as option > > > > arch/arm/mach-shmobile/board-koelsch.c |6 ++--- > > arch/arm/mach-shmobile/board-lager.c |4 ++-- > > drivers/mmc/card/block.c | 19 +-- > > drivers/mmc/host/sh_mobile_sdhi.c | 26 ++--- > > drivers/mmc/host/tmio_mmc_dma.c|8 +++ > > drivers/mmc/host/tmio_mmc_pio.c| 40 > > +--- > > include/linux/mfd/tmio.h | 22 ++ > > include/linux/mmc/host.h |3 +++ > > 8 files changed, 110 insertions(+), 18 deletions(-) > > > > > > > > Best regards, > Cao Minh Hiep. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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
Re: [PATCH 0/10 v2] mmc: tmio: fixup patches
On Tue, Jul 29, 2014 at 01:42:33AM -0700, Kuninori Morimoto wrote: > Hi Chris, Simon > > These are v2 of fixup patches for mmc tmio/shmobile. > I tesed these patches on my environment. > I'm very happy if someone test these patches. Acked-by: Simon Horman > > Kuninori Morimoto (4): > mmc: tmio: care about DMA tx/rx addr offset > mmc: tmio: remove Renesas specific #ifdef > mmc: tmio: remove SCLKEN bit setting from tmio_mmc_set_clock() > mmc: tmio: ensure that the clock has been stopped before set_clock > > Shinobu Uehara (6): > mmc: block: add block number limitation flag for multiple block read > mmc: tmio: clear error IRQ status > mmc: tmio: control multiple block transfer mode > mmc: tmio: add TMIO_MMC_SDIO_STATUS_QUIRK > mmc: tmio: check ILL_FUNC instead of CBSY > mmc: tmio: add actual clock support as option > > arch/arm/mach-shmobile/board-koelsch.c |6 ++--- > arch/arm/mach-shmobile/board-lager.c |4 ++-- > drivers/mmc/card/block.c | 19 +-- > drivers/mmc/host/sh_mobile_sdhi.c | 26 ++--- > drivers/mmc/host/tmio_mmc_dma.c|8 +++ > drivers/mmc/host/tmio_mmc_pio.c| 40 > +--- > include/linux/mfd/tmio.h | 22 ++ > include/linux/mmc/host.h |3 +++ > 8 files changed, 110 insertions(+), 18 deletions(-) > -- 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
Re: [PATCH] tmio_mmc_pio: prevent endless loop in tmio_mmc_set_clock()
On Tue, May 13, 2014 at 04:09:57PM +0400, Sergei Shtylyov wrote: > Hello. > > On 05/13/2014 05:38 AM, Simon Horman wrote: > > >>I've spent a couple of days with the driver just hanging due to me > >>forgetting > >>to specify the external crystal frequency, so that clk_get_rate() returned 0 > >>and thus the loop in tmio_mmc_set_clock() never ended. I don't think that's > >>an > >>acceptable behavior, so I suggest that the minimum frequency is checked for > >>0 > >>in tmio_mmc_host_probe(). > > >>Signed-off-by: Sergei Shtylyov > > >My suggestion is to update tmio_mmc_host_probe() so that it always exits, > >perhaps returning an error if appropriate. > >Did you mean tmio_mmc_set_clock()? Sorry for the cut-and-paste error. Yes, that is what I meant. -- 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
Re: [PATCH] tmio_mmc_pio: prevent endless loop in tmio_mmc_set_clock()
On Sun, May 04, 2014 at 02:19:29AM +0400, Sergei Shtylyov wrote:
> I've spent a couple of days with the driver just hanging due to me forgetting
> to specify the external crystal frequency, so that clk_get_rate() returned 0
> and thus the loop in tmio_mmc_set_clock() never ended. I don't think that's an
> acceptable behavior, so I suggest that the minimum frequency is checked for 0
> in tmio_mmc_host_probe().
>
> Signed-off-by: Sergei Shtylyov
My suggestion is to update tmio_mmc_host_probe() so that it always exits,
perhaps returning an error if appropriate.
>
> ---
> The patch is against Chris Ball's 'mmc.git' repo's 'master' branch.
>
> drivers/mmc/host/tmio_mmc_pio.c |9 +
> 1 file changed, 9 insertions(+)
>
> Index: mmc/drivers/mmc/host/tmio_mmc_pio.c
> ===
> --- mmc.orig/drivers/mmc/host/tmio_mmc_pio.c
> +++ mmc/drivers/mmc/host/tmio_mmc_pio.c
> @@ -1044,6 +1044,15 @@ int tmio_mmc_host_probe(struct tmio_mmc_
> }
>
> /*
> + * Check the sanity of mmc->f_min to prevent tmio_mmc_set_clock() from
> + * looping forever...
> + */
> + if (mmc->f_min == 0) {
> + ret = -EINVAL;
> + goto pm_disable;
> + }
> +
> + /*
>* There are 4 different scenarios for the card detection:
>* 1) an external gpio irq handles the cd (best for power savings)
>* 2) internal sdhi irq handles the cd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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
Re: mmc: sh_mobile_sdhi: DT update for R-Car
On Wed, Feb 12, 2014 at 06:47:35PM +0900, Simon Horman wrote: > On Thu, Jan 30, 2014 at 09:30:20PM -0800, Kuninori Morimoto wrote: > > Hi Chris, Simon > > > > These are v2 of updates code for R-Car. > > I separated v1 patches into for mmc, and for SH-ARM. > > This is "mmc" part patches. > > > > Kuninori Morimoto (4): > > mmc: SDHI: tidyup sh_mobile_sdhi_of_match position > > mmc: SDHI: update sh_mobile_sdhi_of_data for r8a7778 > > mmc: SDHI: update sh_mobile_sdhi_of_data for r8a7779 > > mmc: SDHI: update sh_mobile_sdhi_of_data for r8a7790 > > > > drivers/mmc/host/sh_mobile_sdhi.c | 41 > > + > > 1 file changed, 28 insertions(+), 13 deletions(-) > > ) > > To aid other developers I have pushed these > in the topic/r-car-sdhi branch of my renesas tree. > > To be clear, I am not picking these patches up, > that is Chris's domain. Also, for the entire series: Acked-by: Simon Horman -- 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
Re: mmc: sh_mobile_sdhi: DT update for R-Car
On Thu, Jan 30, 2014 at 09:30:20PM -0800, Kuninori Morimoto wrote: > Hi Chris, Simon > > These are v2 of updates code for R-Car. > I separated v1 patches into for mmc, and for SH-ARM. > This is "mmc" part patches. > > Kuninori Morimoto (4): > mmc: SDHI: tidyup sh_mobile_sdhi_of_match position > mmc: SDHI: update sh_mobile_sdhi_of_data for r8a7778 > mmc: SDHI: update sh_mobile_sdhi_of_data for r8a7779 > mmc: SDHI: update sh_mobile_sdhi_of_data for r8a7790 > > drivers/mmc/host/sh_mobile_sdhi.c | 41 > + > 1 file changed, 28 insertions(+), 13 deletions(-) > ) To aid other developers I have pushed these in the topic/r-car-sdhi branch of my renesas tree. To be clear, I am not picking these patches up, that is Chris's domain. -- 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
Re: [PATCH 5/4] mmc: SDHI: update sh_mobile_sdhi_of_data for r8a7791
On Tue, Feb 11, 2014 at 09:35:50PM -0800, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> This patch updates r8a7791 DT data to have SoC specific settings.
>
> Signed-off-by: Kuninori Morimoto
Acked-by: Simon Horman
> ---
> >> Chris
>
> I add this patch to my previous
> "Re: mmc: sh_mobile_sdhi: DT update for R-Car" patch-set as [5/4]
> Please let me know if you want re-send these patch-set again
>
> drivers/mmc/host/sh_mobile_sdhi.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
> b/drivers/mmc/host/sh_mobile_sdhi.c
> index 1622b03..d54169f 100644
> --- a/drivers/mmc/host/sh_mobile_sdhi.c
> +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> @@ -65,6 +65,7 @@ static const struct of_device_id sh_mobile_sdhi_of_match[]
> = {
> { .compatible = "renesas,sdhi-r8a7778", .data =
> &of_rcar_gen1_compatible, },
> { .compatible = "renesas,sdhi-r8a7779", .data =
> &of_rcar_gen1_compatible, },
> { .compatible = "renesas,sdhi-r8a7790", .data =
> &of_rcar_gen2_compatible, },
> + { .compatible = "renesas,sdhi-r8a7791", .data =
> &of_rcar_gen2_compatible, },
> {},
> };
> MODULE_DEVICE_TABLE(of, sh_mobile_sdhi_of_match);
> --
> 1.7.9.5
>
--
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
Re: [PATCH] ARM: shmobile: bockw: use wp-gpios instead of WP pin
On Mon, Feb 03, 2014 at 05:32:08PM -0800, Kuninori Morimoto wrote: > > Hi Simon > > > > Latest Renesas Chip has some SDHI channels and the WP pin > > > availability depends on its channel or HW implementation. > > > Thus, this patch decides new policy whch indicates > > > WP is disabled as default. > > > But, we can use wp-gpios property to enable it as > > > other method. > > > > > > Signed-off-by: Kuninori Morimoto > > > --- > > > Simon > > > > > > This was included on v1 patch series, > > > but no relationship with mmc part patches. > > > > So I could take this patch into the renesas tree now? > > Yes, I guess so Thanks, I have queued this up. > > # my PC broken this morning somehow... Ouch -- 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
Re: [PATCH 2/3] mmc: sh-mmcif: add DMA SG synchronisation
On Fri, Jan 31, 2014 at 12:54:29PM +0100, Guennadi Liakhovetski wrote:
> According to the DMA API data has to be synchronised before starting
> a DMA transfer to device and after completing a DMA transfer from device.
>
> Signed-off-by: Guennadi Liakhovetski
Acked-by: Simon Horman
> ---
> drivers/mmc/host/sh_mmcif.c | 18 ++
> 1 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index d032b08..902780c 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -345,6 +345,8 @@ static void sh_mmcif_start_dma_tx(struct sh_mmcif_host
> *host)
>DMA_TO_DEVICE);
> if (ret > 0) {
> host->dma_active = true;
> + dma_sync_sg_for_device(chan->device->dev, sg, data->sg_len,
> +DMA_TO_DEVICE);
> desc = dmaengine_prep_slave_sg(chan, sg, ret,
> DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> }
> @@ -1118,14 +1120,14 @@ static bool sh_mmcif_end_cmd(struct sh_mmcif_host
> *host)
> time = wait_for_completion_interruptible_timeout(&host->dma_complete,
>host->timeout);
>
> - if (data->flags & MMC_DATA_READ)
> - dma_unmap_sg(host->chan_rx->device->dev,
> - data->sg, data->sg_len,
> - DMA_FROM_DEVICE);
> - else
> - dma_unmap_sg(host->chan_tx->device->dev,
> - data->sg, data->sg_len,
> - DMA_TO_DEVICE);
> + if (data->flags & MMC_DATA_READ) {
> + struct device *dev = host->chan_rx->device->dev;
> + dma_unmap_sg(dev, data->sg, data->sg_len, DMA_FROM_DEVICE);
> + dma_sync_sg_for_cpu(dev, data->sg, data->sg_len,
> DMA_FROM_DEVICE);
> + } else {
> + struct device *dev = host->chan_tx->device->dev;
> + dma_unmap_sg(dev, data->sg, data->sg_len, DMA_TO_DEVICE);
> + }
>
> if (host->sd_error) {
> dev_err(host->mmc->parent,
> --
> 1.7.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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
Re: [PATCH 1/3] mmc: tmio-mmc: add DMA SG synchronisation
On Fri, Jan 31, 2014 at 12:54:19PM +0100, Guennadi Liakhovetski wrote:
> According to the DMA API data has to be synchronised before starting
> a DMA transfer to device and after completing a DMA transfer from device.
>
> Signed-off-by: Guennadi Liakhovetski
Acked-by: Simon Horman
> ---
> drivers/mmc/host/tmio_mmc_dma.c | 21 -
> 1 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/host/tmio_mmc_dma.c b/drivers/mmc/host/tmio_mmc_dma.c
> index 65edb4a..a997b94 100644
> --- a/drivers/mmc/host/tmio_mmc_dma.c
> +++ b/drivers/mmc/host/tmio_mmc_dma.c
> @@ -168,9 +168,12 @@ static void tmio_mmc_start_dma_tx(struct tmio_mmc_host
> *host)
> }
>
> ret = dma_map_sg(chan->device->dev, sg, host->sg_len, DMA_TO_DEVICE);
> - if (ret > 0)
> + if (ret > 0) {
> + dma_sync_sg_for_device(chan->device->dev, sg, host->sg_len,
> +DMA_TO_DEVICE);
> desc = dmaengine_prep_slave_sg(chan, sg, ret,
> DMA_MEM_TO_DEV, DMA_CTRL_ACK);
> + }
>
> if (desc) {
> cookie = dmaengine_submit(desc);
> @@ -247,14 +250,14 @@ static void tmio_mmc_tasklet_fn(unsigned long arg)
> if (!host->data)
> goto out;
>
> - if (host->data->flags & MMC_DATA_READ)
> - dma_unmap_sg(host->chan_rx->device->dev,
> - host->sg_ptr, host->sg_len,
> - DMA_FROM_DEVICE);
> - else
> - dma_unmap_sg(host->chan_tx->device->dev,
> - host->sg_ptr, host->sg_len,
> - DMA_TO_DEVICE);
> + if (host->data->flags & MMC_DATA_READ) {
> + struct device *dev = host->chan_rx->device->dev;
> + dma_unmap_sg(dev, host->sg_ptr, host->sg_len, DMA_FROM_DEVICE);
> + dma_sync_sg_for_cpu(dev, host->sg_ptr, host->sg_len,
> DMA_FROM_DEVICE);
> + } else {
> + struct device *dev = host->chan_tx->device->dev;
> + dma_unmap_sg(dev, host->sg_ptr, host->sg_len, DMA_TO_DEVICE);
> + }
>
> tmio_mmc_do_data_irq(host);
> out:
> --
> 1.7.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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
Re: mmc: sh_mobile_sdhi: DT update for R-Car
On Thu, Jan 30, 2014 at 09:30:20PM -0800, Kuninori Morimoto wrote: > Hi Chris, Simon > > These are v2 of updates code for R-Car. > I separated v1 patches into for mmc, and for SH-ARM. > This is "mmc" part patches. > > Kuninori Morimoto (4): > mmc: SDHI: tidyup sh_mobile_sdhi_of_match position > mmc: SDHI: update sh_mobile_sdhi_of_data for r8a7778 > mmc: SDHI: update sh_mobile_sdhi_of_data for r8a7779 > mmc: SDHI: update sh_mobile_sdhi_of_data for r8a7790 > > drivers/mmc/host/sh_mobile_sdhi.c | 41 > + I agree with Sergei that patches 2 and 3 could be consolidated, but I also don't feel strongly about it, so please use your best judgement there. Acked-by: Simon Horman -- 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
Re: [PATCH] ARM: shmobile: bockw: use wp-gpios instead of WP pin
On Thu, Jan 30, 2014 at 09:39:40PM -0800, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> Latest Renesas Chip has some SDHI channels and the WP pin
> availability depends on its channel or HW implementation.
> Thus, this patch decides new policy whch indicates
> WP is disabled as default.
> But, we can use wp-gpios property to enable it as
> other method.
>
> Signed-off-by: Kuninori Morimoto
> ---
> Simon
>
> This was included on v1 patch series,
> but no relationship with mmc part patches.
So I could take this patch into the renesas tree now?
>
> arch/arm/boot/dts/r8a7778-bockw-reference.dts |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/r8a7778-bockw-reference.dts
> b/arch/arm/boot/dts/r8a7778-bockw-reference.dts
> index bb62c7a..06cda19 100644
> --- a/arch/arm/boot/dts/r8a7778-bockw-reference.dts
> +++ b/arch/arm/boot/dts/r8a7778-bockw-reference.dts
> @@ -17,6 +17,7 @@
> /dts-v1/;
> #include "r8a7778.dtsi"
> #include
> +#include
>
> / {
> model = "bockw";
> @@ -84,7 +85,7 @@
>
> sdhi0_pins: sd0 {
> renesas,groups = "sdhi0_data4", "sdhi0_ctrl",
> - "sdhi0_cd", "sdhi0_wp";
> + "sdhi0_cd";
> renesas,function = "sdhi0";
> };
>
> @@ -101,6 +102,7 @@
> vmmc-supply = <&fixedregulator3v3>;
> bus-width = <4>;
> status = "okay";
> + wp-gpios = <&gpio3 18 GPIO_ACTIVE_HIGH>;
> };
>
> &hspi0 {
> --
> 1.7.9.5
>
--
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
Re: mmc: sh_mobile_sdhi: DT update for R-Car
On Thu, Jan 30, 2014 at 09:36:06PM -0800, Kuninori Morimoto wrote: > Hi Simon > > These are v2 of updates code for R-Car. > I separated v1 patches into for mmc, and for SH-ARM. > This is "SH-ARM" part patches. > > These need my previous mmc part patches. Thanks Morimoto-san, could you please repost these patches once the driver patches are present in an rc release? Thanks -- 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
Re: mmc: sh_mobile_sdhi: DT update for R-Car
On Wed, Jan 29, 2014 at 11:08:00PM -0800, Kuninori Morimoto wrote: > > Hi Simon, Chris > > > Previously I was somewhat ambivalent to this but experience has shown me > > that taking shmobile patches through my tree is best. The reason is that it > > reduces (eliminates?) merge conflicts. Conflicts that have to be resolved by > > third parties, such as Linus. And we want to make the lives of those people > > as easy as possible. > > > > So please make sure that the patches are split up such that there are > > patches for the driver and patches for shmobile. Ideally post them in > > separate series but if you prefer they can go in a single series. But > > regardless please note that the driver patches are for the driver > > maintainer to pick up and the shmobile patches are for me. > > Thank you ! > OK, I will do my best > > I would like to get Chris's review > before sending v2 patch if possible. That is fine by me :) -- 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
Re: mmc: sh_mobile_sdhi: DT update for R-Car
On Wed, Jan 29, 2014 at 09:38:02PM -0800, Kuninori Morimoto wrote: > > Hi Chris, Simon > > > These patches updates code for R-Car. > > Basically, these clarifies chip dependent settings > > inside driver, and, removed unneeded settings from dtsi file. > > These are based on latest linus/master branch > > (ba635f8cd20ebc7bddf1eb8e1f4eae28a034e916) > > > > Kuninori Morimoto (4): > > mmc: SDHI: tidyup sh_mobile_sdhi_of_match position > > mmc: SDHI: updata sh_mobile_sdhi_of_data for r8a7778 > > mmc: SDHI: updata sh_mobile_sdhi_of_data for r8a7779 > > mmc: SDHI: updata sh_mobile_sdhi_of_data for r8a7790 > > > > arch/arm/boot/dts/r8a7778-bockw-reference.dts |4 ++- > > arch/arm/boot/dts/r8a7778.dtsi|6 > > arch/arm/boot/dts/r8a7779.dtsi|8 - > > arch/arm/boot/dts/r8a7790.dtsi|4 --- > > drivers/mmc/host/sh_mobile_sdhi.c | 41 > > + > > 5 files changed, 31 insertions(+), 32 deletions(-) > > These patches modify both mmc driver and sh-arm. > Should I separate these ? > Or Chris can apply these with Simon's Ack ? > > Basically, modify both files are the best way, > but it is possible to separate Hi Morimoto-san, Previously I was somewhat ambivalent to this but experience has shown me that taking shmobile patches through my tree is best. The reason is that it reduces (eliminates?) merge conflicts. Conflicts that have to be resolved by third parties, such as Linus. And we want to make the lives of those people as easy as possible. So please make sure that the patches are split up such that there are patches for the driver and patches for shmobile. Ideally post them in separate series but if you prefer they can go in a single series. But regardless please note that the driver patches are for the driver maintainer to pick up and the shmobile patches are for me. I hope this clarifies things for you. Thanks -- 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
Re: [PATCH] mmc: tmio: fixup compile error
On Tue, Jan 07, 2014 at 05:33:51PM -0800, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> This patch fixup below compile error
>
> ${LINUX}/drivers/mmc/host/tmio_mmc.c: In function 'tmio_mmc_probe':
> ${LINUX}/drivers/mmc/host/tmio_mmc.c:93:35: \
> error: 'res_ctl' undeclared (first use in this function)
> ${LINUX}/drivers/mmc/host/tmio_mmc.c:93:35: \
> note: each undeclared identifier is reported only \
> once for each function it appears in
>
> Reported-by: Arnd Bergmann
> Signed-off-by: Kuninori Morimoto
Acked-by: Simon Horman
> ---
> >> Chris
> This is needed on mmc-next branch.
>
> drivers/mmc/host/tmio_mmc.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
> index 8a781e2..1900abb 100644
> --- a/drivers/mmc/host/tmio_mmc.c
> +++ b/drivers/mmc/host/tmio_mmc.c
> @@ -90,7 +90,7 @@ static int tmio_mmc_probe(struct platform_device *pdev)
> return -EINVAL;
>
> /* SD control register space size is 0x200, 0x400 for bus_shift=1 */
> - pdata->bus_shift = resource_size(res_ctl) >> 10;
> + pdata->bus_shift = resource_size(res) >> 10;
> pdata->flags |= TMIO_MMC_HAVE_HIGH_REG;
>
> ret = tmio_mmc_host_probe(&host, pdev, pdata);
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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
Re: [PATCH 08/12] mmc: sh_mobile_sdhi: Convert to clk_prepare/unprepare
On Wed, Dec 11, 2013 at 09:25:09PM -0500, Chris Ball wrote: > Hi Laurent, > > On Wed, Dec 11 2013, Laurent Pinchart wrote: > >> I'm sorry about the delay -- it's in mmc-next for 3.14 now. > > > > Thanks a lot and sorry about shouting. Don't worry about the delay, I only > > wanted to make sure the patch would get in v3.14. > > No worries, it was deserved yelling. :-) > > > [PATCH v3 1/3] mmc: sh_mmcif: Factorize DMA channel request and > > configuration > > code > > [PATCH v3 2/3] mmc: sh_mmcif: Fix compilation warning on 64-bit platforms > > These two are in mmc-next now too. (I usually wait for someone with > SH hardware to ACK, but I understand that Guennadi's not around as > much anymore.) I believe I can provide such Acks going forwards. -- 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
Re: [PATCH 0/4] mmc: tmio/SDHI fixup patches
On Thu, Dec 12, 2013 at 12:26:42AM -0800, Kuninori Morimoto wrote: > > Hi Chris, Simon > > > > Now, our new board would like to use sh_mobile_sdhi driver, > > > then, it is expecting sh_mobile_sdhi use regulator. > > > But, this regulator is based on GPIO driver, > > > and GPIO driver probe timing is after sh_mobile_sdhi. > > > So, sh_mobile_sdhi (= tmio_mmc_pio) use default ocr_avail, > > > and it doesn't work for us. > > > #1 patch returns -EPROBE_DEFER in such case. > > > it changes tmio_mmc_host_probe() behavior, but > > > in my check, tmio_mmc_pio driver user is sh_mobile_sdhi/tmio-mmc only, > > > and, current user has no conflict by this patch. > > > > > > sh_mobile_sdhi/tmio-mmc is very similar, but, have some difference. > > > #2 - #4 cares such case. > > > > > > These were part of "SDHI support for r8a7790" patch set, > > > but was separated > > > > Sorry for the delay, I've pushed all four patches to mmc-next for > > 3.14. Thanks, > > Chris > Thank you for your hard work about this. > > Simon > Lager SDHI needs these patches. > Can you use this branch ? > If yes, I can re-send patches. Hi Chris, is it possible for you to provide a branch with stable git commit ids that I can use as a base? I'm happy to use mmc-next if you think it is appropriate. -- 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
Re: [PATCH 0/16] ARM: shmobile: SDHI support for r8a7790
On Wed, Nov 20, 2013 at 09:20:10PM -0800, Kuninori Morimoto wrote: > > Hi Simon > > > > > > These are v2 of SDHI support for r8a7790. > > > > > > > > > > Kuninori Morimoto (2): > > > > > ARM: shmobile: lager: add gpio/fixed regulator for SDHI > > > > > ARM: shmobile: lager: add SDHI0/2 support > > > > > > > > > > arch/arm/mach-shmobile/board-lager.c | 149 > > > > > +- > > > > > > > > Hi Morimoto-san, > > > > > > > > I assume that these two patches depend on at least > > > > some of the first 14 patches. Is that correct? > > > > > > Compile itself is not depend on first 14 patches, > > > but, it doesn't work correctly without these patches. > > > So, yes, it depend on 14 patches. > > > > What is the run-time effect of these 2 patches without the other 14. > > Is it > > > > a) Things get worse and will only get better with the other 14 patches or; > > b) Things stay the same and will get better with the other 14 patches? > > > > In the case of b I am inclined to queue these patches up once/if > > Chris has indicated that the other 14 patches are ok. > > > > In the case of a I would like to wait and queue up these patches > > on top of the other 14 patches once/if they are available in a > > stable branch. > > Thank you. I think b) > But, my current plan is that I will re-send these patches > again in good-timing (when I can indicate the necessary branch). > I guess it doesn't have complex relationship. > What do you think ? Sure, that is fine for me. -- 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
Re: [PATCH 0/16] ARM: shmobile: SDHI support for r8a7790
On Sun, Nov 17, 2013 at 11:42:02PM -0800, Kuninori Morimoto wrote: > > Hi Simon > > > > These are v2 of SDHI support for r8a7790. > > > > > > Kuninori Morimoto (2): > > > ARM: shmobile: lager: add gpio/fixed regulator for SDHI > > > ARM: shmobile: lager: add SDHI0/2 support > > > > > > arch/arm/mach-shmobile/board-lager.c | 149 > > > +- > > > > Hi Morimoto-san, > > > > I assume that these two patches depend on at least > > some of the first 14 patches. Is that correct? > > Compile itself is not depend on first 14 patches, > but, it doesn't work correctly without these patches. > So, yes, it depend on 14 patches. What is the run-time effect of these 2 patches without the other 14. Is it a) Things get worse and will only get better with the other 14 patches or; b) Things stay the same and will get better with the other 14 patches? In the case of b I am inclined to queue these patches up once/if Chris has indicated that the other 14 patches are ok. In the case of a I would like to wait and queue up these patches on top of the other 14 patches once/if they are available in a stable branch. -- 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
Re: [PATCH 0/16] ARM: shmobile: SDHI support for r8a7790
On Thu, Nov 14, 2013 at 05:53:21PM -0800, Kuninori Morimoto wrote: > > Hi Simon > > These are v2 of SDHI support for r8a7790. > > Kuninori Morimoto (2): > ARM: shmobile: lager: add gpio/fixed regulator for SDHI > ARM: shmobile: lager: add SDHI0/2 support > > arch/arm/mach-shmobile/board-lager.c | 149 > +- Hi Morimoto-san, I assume that these two patches depend on at least some of the first 14 patches. Is that correct? -- 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
Re: [PATCH] mmc: sh_mmcif: Get rid of MMC_BLOCK dependency
On Thu, Oct 10, 2013 at 07:45:45AM +0900, Magnus Damm wrote: > From: Magnus Damm > > It seems like sh_mmcif.c now is the only MMC driver depending on MMC_BLOCK, > the hardware is not special in any way so rework the Kconfig dependency to > be less special. > > Signed-off-by: Magnus Damm Reviewed-by: Simon Horman > --- > > drivers/mmc/host/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- 0001/drivers/mmc/host/Kconfig > +++ work/drivers/mmc/host/Kconfig 2013-10-08 18:03:17.0 +0900 > @@ -588,7 +588,7 @@ config MMC_DW_PCI > > config MMC_SH_MMCIF > tristate "SuperH Internal MMCIF support" > - depends on MMC_BLOCK && (SUPERH || ARCH_SHMOBILE) > + depends on SUPERH || ARCH_SHMOBILE > help > This selects the MMC Host Interface controller (MMCIF). > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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
Re: [PATCH 5/6] ARM: shmobile: ape6evm: disable MMCIF Command Completion Signal
On Wed, Jul 10, 2013 at 09:21:16PM +0200, Guennadi Liakhovetski wrote:
> MMCIF on r8a73a4 doesn't support Command Completion Signal, a platform
> parameter has to be added to disable it on ape6evm.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
> arch/arm/mach-shmobile/board-ape6evm.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/board-ape6evm.c
> b/arch/arm/mach-shmobile/board-ape6evm.c
> index e9e2108e..96a6994 100644
> --- a/arch/arm/mach-shmobile/board-ape6evm.c
> +++ b/arch/arm/mach-shmobile/board-ape6evm.c
> @@ -77,6 +77,7 @@ static struct sh_mmcif_plat_data mmcif0_pdata = {
> .caps = MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
> .slave_id_tx= SHDMA_SLAVE_MMCIF0_TX,
> .slave_id_rx= SHDMA_SLAVE_MMCIF0_RX,
> + .ccs_unsupported = true,
> };
>
> static struct resource mmcif0_resources[] = {
Thanks, I have queued up the following for v3.13.
From: Guennadi Liakhovetski
ARM: shmobile: ape6evm: disable MMCIF Command Completion Signal
MMCIF on r8a73a4 doesn't support Command Completion Signal, a platform
parameter has to be added to disable it on ape6evm.
Signed-off-by: Guennadi Liakhovetski
Signed-off-by: Simon Horman
---
arch/arm/mach-shmobile/board-ape6evm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-shmobile/board-ape6evm.c
b/arch/arm/mach-shmobile/board-ape6evm.c
index 02be420..0365d2e 100644
--- a/arch/arm/mach-shmobile/board-ape6evm.c
+++ b/arch/arm/mach-shmobile/board-ape6evm.c
@@ -162,6 +162,7 @@ static struct regulator_consumer_supply
vcc_sdhi1_consumers[] =
/* MMCIF */
static const struct sh_mmcif_plat_data mmcif0_pdata __initconst = {
.caps = MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
+ .ccs_unsupported = true,
};
static const struct resource mmcif0_resources[] __initconst = {
--
1.8.4
--
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
Re: [PATCH 4/6] ARM: shmobile: kzm9g: disable MMCIF Command Completion Signal
On Wed, Jul 10, 2013 at 09:21:15PM +0200, Guennadi Liakhovetski wrote:
> MMCIF on sh73a0 doesn't support Command Completion Signal, a platform
> parameter has to be added to disable it on kzm9g.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
> arch/arm/mach-shmobile/board-kzm9g.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/board-kzm9g.c
> b/arch/arm/mach-shmobile/board-kzm9g.c
> index 165483c..7ec26a5 100644
> --- a/arch/arm/mach-shmobile/board-kzm9g.c
> +++ b/arch/arm/mach-shmobile/board-kzm9g.c
> @@ -365,6 +365,7 @@ static struct resource sh_mmcif_resources[] = {
> static struct sh_mmcif_plat_data sh_mmcif_platdata = {
> .ocr= MMC_VDD_165_195,
> .caps = MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
> + .ccs_unsupported = true,
> .slave_id_tx= SHDMA_SLAVE_MMCIF_TX,
> .slave_id_rx= SHDMA_SLAVE_MMCIF_RX,
> };
> --
> 1.7.2.5
Thanks, I have queued this up for v3.13.
--
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
Re: [PATCH 6/6] ARM: shmobile: lager: disable MMCIF Command Completion Signal, add CLK_CTRL2
On Wed, Jul 10, 2013 at 09:21:17PM +0200, Guennadi Liakhovetski wrote: > MMCIF on r8a7790 doesn't support Command Completion Signal, but it does > implement a CE_CLK_CTRL2 register. Platform parameters have to be added to > account for these features on lager. > > Signed-off-by: Guennadi Liakhovetski Thanks, I have queued this up for v3.13. -- 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
Re: [PATCH 3/6] ARM: shmobile: armadillo800eva: disable MMCIF Command Completion Signal
On Wed, Jul 10, 2013 at 09:21:14PM +0200, Guennadi Liakhovetski wrote:
> MMCIF on r8a7740 doesn't support Command Completion Signal, a platform
> parameter has to be added to disable it on armadillo800eva.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
> arch/arm/mach-shmobile/board-armadillo800eva.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c
> b/arch/arm/mach-shmobile/board-armadillo800eva.c
> index 41ff7d65..3cb006b 100644
> --- a/arch/arm/mach-shmobile/board-armadillo800eva.c
> +++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
> @@ -778,6 +778,7 @@ static struct sh_mmcif_plat_data sh_mmcif_plat = {
> .caps = MMC_CAP_4_BIT_DATA |
> MMC_CAP_8_BIT_DATA |
> MMC_CAP_NONREMOVABLE,
> + .ccs_unsupported = true,
> .slave_id_tx= SHDMA_SLAVE_MMCIF_TX,
> .slave_id_rx= SHDMA_SLAVE_MMCIF_RX,
> };
Thanks, I have queued this up for v3.13.
--
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
Re: [PATCH 3/6] ARM: shmobile: armadillo800eva: disable MMCIF Command Completion Signal
On Wed, Jul 10, 2013 at 09:21:14PM +0200, Guennadi Liakhovetski wrote:
> MMCIF on r8a7740 doesn't support Command Completion Signal, a platform
> parameter has to be added to disable it on armadillo800eva.
>
> Signed-off-by: Guennadi Liakhovetski
Thanks, I have queued this up for v3.13.
> ---
> arch/arm/mach-shmobile/board-armadillo800eva.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c
> b/arch/arm/mach-shmobile/board-armadillo800eva.c
> index 41ff7d65..3cb006b 100644
> --- a/arch/arm/mach-shmobile/board-armadillo800eva.c
> +++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
> @@ -778,6 +778,7 @@ static struct sh_mmcif_plat_data sh_mmcif_plat = {
> .caps = MMC_CAP_4_BIT_DATA |
> MMC_CAP_8_BIT_DATA |
> MMC_CAP_NONREMOVABLE,
> + .ccs_unsupported = true,
> .slave_id_tx= SHDMA_SLAVE_MMCIF_TX,
> .slave_id_rx= SHDMA_SLAVE_MMCIF_RX,
> };
> --
> 1.7.2.5
>
--
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
Re: [PATCH] ARM: shmobile: update SDHI DT compatibility string to the - format
On Thu, Sep 05, 2013 at 01:29:33PM +0100, Chris Ball wrote:
> Hi,
>
> On Thu, Sep 05 2013, Simon Horman wrote:
> >> > Ok, the "no real products" is an assumption, that Laurent and Simon kind
> >> > of agreed upon, so, I'm using it here to avoid having to carry old
> >> > compatibility strings with us around. If anyone has other information -
> >> > please shout. Otherwise, I think, it would be the easiest for Chris to
> >> > ack
> >> > this and for Simon to pull this via the ARM tree for late 3.12 (possibly,
> >> > post -rc1) inclusion.
> >
> > Thanks, I believe that is a good plan.
> >
> > Chris, could we get an Ack?
>
> Acked-by: Chris Ball
Thanks, and sorry for the delay.
I have queued up the following, And I will push it either in the next
half hour or some time next week - I have to jump on a plane shortly.
Guennadi, it seems that SDHI (and MMCIF) support form
armadillo800eva-reference never made it into my tree. And I have dropped
r8a7740.dtsi changes from the patch below accordingly. Would you care to
repost that series with the compatibility string updated?
From: Guennadi Liakhovetski
[PATCH] ARM: shmobile: update SDHI DT compatibility string to the -
format
Currently DT compatibility strings of both types can be found in the kernel
sources: - and -, whereas a unique format should be
followed and the former one is preferred. This patch converts the SDHI
MMC driver and its users to the common standard. This is safe for now, since
ATM no real products are using this driver with DT.
Signed-off-by: Guennadi Liakhovetski
Acked-by: Chris Ball
[Removed r8a7740.dtsi portion as it is not applicable]
Signed-off-by: Simon Horman
---
Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 17 ++---
arch/arm/boot/dts/r8a73a4.dtsi | 6 +++---
arch/arm/boot/dts/r8a7790.dtsi | 8
arch/arm/boot/dts/sh73a0.dtsi | 6 +++---
drivers/mmc/host/sh_mobile_sdhi.c | 16
5 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index df204e1..6a2a116 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -9,12 +9,15 @@ compulsory and any optional properties, common to all SD/MMC
drivers, as
described in mmc.txt, can be used. Additionally the following tmio_mmc-specific
optional bindings can be used.
+Required properties:
+- compatible: "renesas,sdhi-shmobile" - a generic sh-mobile SDHI unit
+ "renesas,sdhi-sh7372" - SDHI IP on SH7372 SoC
+ "renesas,sdhi-sh73a0" - SDHI IP on SH73A0 SoC
+ "renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC
+ "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
+ "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
+ "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
+ "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
+
Optional properties:
- toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
-
-When used with Renesas SDHI hardware, the following compatibility strings
-configure various model-specific properties:
-
-"renesas,sh7372-sdhi": (default) compatible with SH7372
-"renesas,r8a7740-sdhi":compatible with R8A7740: certain MMC/SD
commands have to
- wait for the interface to become idle.
diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 6c26caa..658fcc5 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -193,7 +193,7 @@
};
sdhi0: sdhi@ee10 {
- compatible = "renesas,r8a73a4-sdhi";
+ compatible = "renesas,sdhi-r8a73a4";
reg = <0 0xee10 0 0x100>;
interrupt-parent = <&gic>;
interrupts = <0 165 4>;
@@ -202,7 +202,7 @@
};
sdhi1: sdhi@ee12 {
- compatible = "renesas,r8a73a4-sdhi";
+ compatible = "renesas,sdhi-r8a73a4";
reg = <0 0xee12 0 0x100>;
interrupt-parent = <&gic>;
interrupts = <0 166 4>;
@@ -211,7 +211,7 @@
};
sdhi2: sdhi@ee14 {
- compatible = "renesas,r8a73a4-sdhi";
+ compatible = "renesas,sdhi-r8a73a4";
reg = <0 0xee14 0 0x100>;
interrupt-parent = <&gic>;
interrupts = <0 167 4>;
diff --git a/arch/arm/boot/dts
Re: [PATCH] ARM: shmobile: update SDHI DT compatibility string to the - format
On Fri, Aug 30, 2013 at 01:47:21AM +0200, Laurent Pinchart wrote:
> Hi Guennadi,
>
> Thank you for the patch.
>
> On Thursday 29 August 2013 17:14:49 Guennadi Liakhovetski wrote:
> > Currently DT compatibility strings of both types can be found in the kernel
> > sources: - and -, whereas a unique format should be
> > followed and the former one is preferred. This patch converts the SDHI
> > MMC driver and its users to the common standard. This is safe for now, since
> > ATM no real products are using this driver with DT.
> >
> > Signed-off-by: Guennadi Liakhovetski
>
> Acked-by: Laurent Pinchart
>
> > ---
> >
> > Ok, the "no real products" is an assumption, that Laurent and Simon kind
> > of agreed upon, so, I'm using it here to avoid having to carry old
> > compatibility strings with us around. If anyone has other information -
> > please shout. Otherwise, I think, it would be the easiest for Chris to ack
> > this and for Simon to pull this via the ARM tree for late 3.12 (possibly,
> > post -rc1) inclusion.
Thanks, I believe that is a good plan.
Chris, could we get an Ack?
> >
> > Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 17 ++---
> > arch/arm/boot/dts/r8a73a4.dtsi |6 +++---
> > arch/arm/boot/dts/r8a7740.dtsi |4 ++--
> > arch/arm/boot/dts/r8a7790.dtsi |8
> > arch/arm/boot/dts/sh73a0.dtsi |6 +++---
> > drivers/mmc/host/sh_mobile_sdhi.c | 16
> > 6 files changed, 30 insertions(+), 27 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt index df204e1..6a2a116
> > 100644
> > --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> > @@ -9,12 +9,15 @@ compulsory and any optional properties, common to all
> > SD/MMC drivers, as described in mmc.txt, can be used. Additionally the
> > following tmio_mmc-specific optional bindings can be used.
> >
> > +Required properties:
> > +- compatible: "renesas,sdhi-shmobile" - a generic sh-mobile SDHI unit
> > + "renesas,sdhi-sh7372" - SDHI IP on SH7372 SoC
> > + "renesas,sdhi-sh73a0" - SDHI IP on SH73A0 SoC
> > + "renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC
> > + "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
> > + "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
> > + "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
> > + "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
> > +
> > Optional properties:
> > - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
> > -
> > -When used with Renesas SDHI hardware, the following compatibility strings
> > -configure various model-specific properties:
> > -
> > -"renesas,sh7372-sdhi": (default) compatible with SH7372
> > -"renesas,r8a7740-sdhi":compatible with R8A7740: certain MMC/SD commands
> > have to - wait for the interface to become idle.
> > diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
> > index b0511b1..cc7211b 100644
> > --- a/arch/arm/boot/dts/r8a73a4.dtsi
> > +++ b/arch/arm/boot/dts/r8a73a4.dtsi
> > @@ -236,7 +236,7 @@
> > };
> >
> > sdhi0: sdhi@ee10 {
> > - compatible = "renesas,r8a73a4-sdhi";
> > + compatible = "renesas,sdhi-r8a73a4";
> > reg = <0 0xee10 0 0x100>;
> > interrupt-parent = <&gic>;
> > interrupts = <0 165 4>;
> > @@ -245,7 +245,7 @@
> > };
> >
> > sdhi1: sdhi@ee12 {
> > - compatible = "renesas,r8a73a4-sdhi";
> > + compatible = "renesas,sdhi-r8a73a4";
> > reg = <0 0xee12 0 0x100>;
> > interrupt-parent = <&gic>;
> > interrupts = <0 166 4>;
> > @@ -254,7 +254,7 @@
> > };
> >
> > sdhi2: sdhi@ee14 {
> > - compatible = "renesas,r8a73a4-sdhi";
> > + compatible = "renesas,sdhi-r8a73a4";
> > reg = <0 0xee14 0 0x100>;
> > interrupt-parent = <&gic>;
> > interrupts = <0 167 4>;
> > diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
> > index 8fc4a5d..c4992b5 100644
> > --- a/arch/arm/boot/dts/r8a7740.dtsi
> > +++ b/arch/arm/boot/dts/r8a7740.dtsi
> > @@ -155,7 +155,7 @@
> > };
> >
> > sdhi0: sdhi@e685 {
> > - compatible = "renesas,r8a7740-sdhi";
> > + compatible = "renesas,sdhi-r8a7740";
> > reg = <0xe685 0x100>;
> > interrupt-parent = <&gic>;
> > interrupts = <0 117 4
> > @@ -167,7 +167,7 @@
> > };
> >
> > sdhi1: sdhi@e686 {
> > - compatible = "renesas,r8a7740-sdhi";
> > + compatible = "renesas,sdhi-r8a7740";
> > reg = <0xe686 0x100>;
> > interrupt-parent = <&gic>;
Re: [PATCH/RFC 2/2] ARM: shmobile: kzm9g: support DDR50 mode with 1.8V VccQ on MMCIF
On Fri, Jul 26, 2013 at 05:51:32PM +0200, Guennadi Liakhovetski wrote: > MMCIF on sh73a0 supports the UHS DDR50 mode and on the kzm9g board it can > be used with MMC VccQ = 1.8V. This patch enables them. > > Signed-off-by: Guennadi Liakhovetski > --- > > This patch is correct AFAICS, but pointless on kzm9g, because (at least on > my board) th eMMC chip, installed on the board and connected to MMCIF > doesn't support DDR, so, it cannot be enabled. This patch is therefore > more of an example how these flags shall be used, than a real use case. If > it is decided to apply it, it can be applied even before patch 1/2, it > just won't have any effect at all. Thanks, understood. At this point I prefer not to apply it as it doesn't have any effect. I am more than happy to discuss this further if others would like it applied. > > arch/arm/boot/dts/sh73a0-kzm9g-reference.dts |1 + > arch/arm/boot/dts/sh73a0.dtsi|1 + > 2 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts > b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts > index b99e890..d90de01 100644 > --- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts > +++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts > @@ -191,6 +191,7 @@ > > bus-width = <8>; > vmmc-supply = <®_1p8v>; > + ddr-1v8; > status = "okay"; > }; > > diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi > index 86e79fe..1146be8 100644 > --- a/arch/arm/boot/dts/sh73a0.dtsi > +++ b/arch/arm/boot/dts/sh73a0.dtsi > @@ -186,6 +186,7 @@ > interrupts = <0 140 0x4 > 0 141 0x4>; > reg-io-width = <4>; > + uhs-ddr50; > status = "disabled"; > }; > > -- > 1.7.2.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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
Re: [PATCH] dmaengine: shdma: fix a build failure on platforms with no DMA support
On Mon, Jul 22, 2013 at 07:39:07PM -0700, Olof Johansson wrote: > On Tue, Jul 16, 2013 at 10:20:41AM +0900, Simon Horman wrote: > > On Wed, Jul 10, 2013 at 11:09:12AM +0900, Simon Horman wrote: > > > From: Guennadi Liakhovetski > > > > > > On platforms with no support for the shdma dmaengine driver build is > > > currently failing with > > > > > > drivers/built-in.o: In function `sh_mobile_sdhi_probe': > > > drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference > > > to`shdma_chan_filter' > > > > > > Fix the breakage by defining shdma_chan_filter to NULL in such > > > configurations. > > > > > > Signed-off-by: Guennadi Liakhovetski > > > [horms+rene...@verge.net.au: Apply change to shdma-base.h instead of > > > sh_dma.h] > > > Signed-off-by: Simon Horman > > > --- > > > include/linux/shdma-base.h | 4 > > > 1 file changed, 4 insertions(+) > > > > > > > > Hi Vinod, > > > > > > please consider this fix from Guennadi for v3.11 which I have rebased on > > > top of > > > next-20130709. It fixes a build problem on a number of shmobile defconfigs > > > including bockw. > > > > Ping. > > > > Would it be appropriate for me to take this change through my tree? > > It seems to resolve a regression in v3.11-rc1. > > I'll take it through arm-soc since there's no response from Vinod. I've > applied it in the fixes branch we have. Thanks! Very much appreciated. -- 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
[PATCH fix for v3.11 (repost)] dmaengine: shdma: fix a build failure on platforms with no DMA support
From: Guennadi Liakhovetski On platforms with no support for the shdma dmaengine driver build is currently failing with drivers/built-in.o: In function `sh_mobile_sdhi_probe': drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference to`shdma_chan_filter' Fix the breakage by defining shdma_chan_filter to NULL in such configurations. Signed-off-by: Guennadi Liakhovetski [horms+rene...@verge.net.au: Apply change to shdma-base.h instead of sh_dma.h] Signed-off-by: Simon Horman --- include/linux/shdma-base.h | 4 1 file changed, 4 insertions(+) Hi Vinod, please consider this fix from Guennadi for v3.11 which I have rebased on top of next-20130709. It fixes a build problem on a number of shmobile defconfigs including bockw. Alternatively, I would be happy to take this through the renesas tree. I posted this patch last week but I'm wondering if you missed it somehow. This patch resolves a regression in v3.11-rc1. diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h index 382cf71..5b1c984 100644 --- a/include/linux/shdma-base.h +++ b/include/linux/shdma-base.h @@ -124,6 +124,10 @@ void shdma_chan_remove(struct shdma_chan *schan); int shdma_init(struct device *dev, struct shdma_dev *sdev, int chan_num); void shdma_cleanup(struct shdma_dev *sdev); +#if IS_ENABLED(CONFIG_SH_DMAE_BASE) bool shdma_chan_filter(struct dma_chan *chan, void *arg); +#else +#define shdma_chan_filter NULL +#endif #endif -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
Re: [PATCH v4 5/7] mmc: SDHI: add DT compatibility strings for further SoCs
On Wed, Jul 10, 2013 at 10:18:35AM +0900, Simon Horman wrote:
> On Tue, Jul 09, 2013 at 06:06:00PM +0900, Magnus Damm wrote:
> > On Tue, Jul 9, 2013 at 4:43 PM, Guennadi Liakhovetski
> > wrote:
> > > Add further OF compatibility strings to the SDHI driver to be able to
> > > precisely control driver's behaviour on each of them.
> > >
> > > Signed-off-by: Guennadi Liakhovetski
> > > ---
> > >
> > > v4:
> > > 1. added r8a7778 and r8a7779 per Morimoto-san's request
> > > 2. sh* and r8a* entries now sorted alphabetically
> >
> > This looks good to me, thanks.
> >
> > Acked-by: Magnus Damm
>
> Thanks, I have queued this up for v3.12 in the dt branch.
> It should appear in renesas-next-20130710
Reviewing this, I now think that it should got through the MMC tree.
Chris, could you consider the patch below?
From: Guennadi Liakhovetski
mmc: SDHI: add DT compatibility strings for further SoCs
Add further OF compatibility strings to the SDHI driver to be able to
precisely control driver's behaviour on each of them.
Signed-off-by: Guennadi Liakhovetski
Acked-by: Magnus Damm
Acked-by: Simon Horman
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index ebea749..afa1bba 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -129,7 +129,12 @@ static const struct sh_mobile_sdhi_ops sdhi_ops = {
static const struct of_device_id sh_mobile_sdhi_of_match[] = {
{ .compatible = "renesas,shmobile-sdhi" },
{ .compatible = "renesas,sh7372-sdhi" },
+ { .compatible = "renesas,sh73a0-sdhi", .data =
&sh_mobile_sdhi_of_cfg[0], },
+ { .compatible = "renesas,r8a73a4-sdhi", .data =
&sh_mobile_sdhi_of_cfg[0], },
{ .compatible = "renesas,r8a7740-sdhi", .data =
&sh_mobile_sdhi_of_cfg[0], },
+ { .compatible = "renesas,r8a7778-sdhi", .data =
&sh_mobile_sdhi_of_cfg[0], },
+ { .compatible = "renesas,r8a7779-sdhi", .data =
&sh_mobile_sdhi_of_cfg[0], },
+ { .compatible = "renesas,r8a7790-sdhi", .data =
&sh_mobile_sdhi_of_cfg[0], },
{},
};
MODULE_DEVICE_TABLE(of, sh_mobile_sdhi_of_match);
--
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
Re: [PATCH] dmaengine: shdma: fix a build failure on platforms with no DMA support
On Wed, Jul 10, 2013 at 11:09:12AM +0900, Simon Horman wrote: > From: Guennadi Liakhovetski > > On platforms with no support for the shdma dmaengine driver build is > currently failing with > > drivers/built-in.o: In function `sh_mobile_sdhi_probe': > drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference > to`shdma_chan_filter' > > Fix the breakage by defining shdma_chan_filter to NULL in such > configurations. > > Signed-off-by: Guennadi Liakhovetski > [horms+rene...@verge.net.au: Apply change to shdma-base.h instead of sh_dma.h] > Signed-off-by: Simon Horman > --- > include/linux/shdma-base.h | 4 > 1 file changed, 4 insertions(+) > > Hi Vinod, > > please consider this fix from Guennadi for v3.11 which I have rebased on top > of > next-20130709. It fixes a build problem on a number of shmobile defconfigs > including bockw. Ping. Would it be appropriate for me to take this change through my tree? It seems to resolve a regression in v3.11-rc1. > diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h > index 382cf71..5b1c984 100644 > --- a/include/linux/shdma-base.h > +++ b/include/linux/shdma-base.h > @@ -124,6 +124,10 @@ void shdma_chan_remove(struct shdma_chan *schan); > int shdma_init(struct device *dev, struct shdma_dev *sdev, > int chan_num); > void shdma_cleanup(struct shdma_dev *sdev); > +#if IS_ENABLED(CONFIG_SH_DMAE_BASE) > bool shdma_chan_filter(struct dma_chan *chan, void *arg); > +#else > +#define shdma_chan_filter NULL > +#endif > > #endif > -- > 1.8.2.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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
[PATCH] dmaengine: shdma: fix a build failure on platforms with no DMA support
From: Guennadi Liakhovetski On platforms with no support for the shdma dmaengine driver build is currently failing with drivers/built-in.o: In function `sh_mobile_sdhi_probe': drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference to`shdma_chan_filter' Fix the breakage by defining shdma_chan_filter to NULL in such configurations. Signed-off-by: Guennadi Liakhovetski [horms+rene...@verge.net.au: Apply change to shdma-base.h instead of sh_dma.h] Signed-off-by: Simon Horman --- include/linux/shdma-base.h | 4 1 file changed, 4 insertions(+) Hi Vinod, please consider this fix from Guennadi for v3.11 which I have rebased on top of next-20130709. It fixes a build problem on a number of shmobile defconfigs including bockw. diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h index 382cf71..5b1c984 100644 --- a/include/linux/shdma-base.h +++ b/include/linux/shdma-base.h @@ -124,6 +124,10 @@ void shdma_chan_remove(struct shdma_chan *schan); int shdma_init(struct device *dev, struct shdma_dev *sdev, int chan_num); void shdma_cleanup(struct shdma_dev *sdev); +#if IS_ENABLED(CONFIG_SH_DMAE_BASE) bool shdma_chan_filter(struct dma_chan *chan, void *arg); +#else +#define shdma_chan_filter NULL +#endif #endif -- 1.8.2.1 -- 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
Re: [PATCH] dmaengine: shdma: fix a build failure on platforms with no DMA support
On Mon, Jul 08, 2013 at 12:51:14PM +0530, Vinod Koul wrote: > On Mon, Jul 08, 2013 at 12:52:16AM -0700, Olof Johansson wrote: > > On Thu, Jul 4, 2013 at 9:53 PM, Vinod Koul wrote: > > > On Wed, Jun 19, 2013 at 09:32:18PM +0200, Guennadi Liakhovetski wrote: > > >> Hi Vinod > > >> > > >> On Wed, 19 Jun 2013, Kevin Hilman wrote: > > >> > > >> > On Thu, May 30, 2013 at 7:44 PM, Simon Horman > > >> > wrote: > > >> > > > >> > [...] > > >> > > > >> > > thanks for this. I will wait for a refresh (as we discussed earlier > > >> > > today). > > >> > > Can I confirm that this is a fix for v3.10? If so, could ou note > > >> > > that when you post your revised patch? > > >> > > > >> > Any progress on this patch? > > >> > > > >> > The SH-mobile defconfigs are still all failing in linux-next. > > >> > > >> In > > >> > > >> https://patchwork.kernel.org/patch/2640061/ > > > And you havent CC maintainers on this patch, so I dont have it! > > >> > > >> I proposed a simple immediate fix for this problem. Arnd at the same time > > >> developed an alternative solution: > > >> > > >> https://patchwork.kernel.org/patch/2644121/ > > >> https://patchwork.kernel.org/patch/2644111/ > > > Reading these patches I agree with Arnd that client drivers should not > > > depend on > > > dma slave drivers. Existing issue need to be fixed > > > > > > Arnd, Have you merged these changes? > > > > Looks like we now have breakage in linux-next for this again (new > > breakage due to the header file move being applied by you on Friday, > > Vinod? Are you planning on sending the code in for 3.11? If not, you > > shouldn't apply patches right now). > Well they were already in my tree since 18th June. (tree was rebased to fixup > for > pull on friday) and now these are in Linus's tree. > > Can we have a fix for breakage for now sent to linus for now and then address > the > proper way to do this? That is my preferred approach. I will repost the patch at the link https://patchwork.kernel.org/patch/2640061/ above, rebased for the header file rename. Vinod, can you take things from there? -- 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
Re: [PATCH v4 5/7] mmc: SDHI: add DT compatibility strings for further SoCs
On Tue, Jul 09, 2013 at 06:06:00PM +0900, Magnus Damm wrote: > On Tue, Jul 9, 2013 at 4:43 PM, Guennadi Liakhovetski > wrote: > > Add further OF compatibility strings to the SDHI driver to be able to > > precisely control driver's behaviour on each of them. > > > > Signed-off-by: Guennadi Liakhovetski > > --- > > > > v4: > > 1. added r8a7778 and r8a7779 per Morimoto-san's request > > 2. sh* and r8a* entries now sorted alphabetically > > This looks good to me, thanks. > > Acked-by: Magnus Damm Thanks, I have queued this up for v3.12 in the dt branch. It should appear in renesas-next-20130710 -- 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
Re: [PATCH v3 5/7] mmc: SDHI: add DT compatibility strings for further SoCs
On Tue, Jul 09, 2013 at 06:02:00PM -0700, Kuninori Morimoto wrote:
>
> Hi Simon
>
> > > > diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
> > > > b/drivers/mmc/host/sh_mobile_sdhi.c
> > > > index cc4c872..b58c1a9 100644
> > > > --- a/drivers/mmc/host/sh_mobile_sdhi.c
> > > > +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> > > > @@ -130,6 +130,9 @@ static const struct of_device_id
> > > > sh_mobile_sdhi_of_match[] = {
> > > > { .compatible = "renesas,shmobile-sdhi" },
> > > > { .compatible = "renesas,sh7372-sdhi" },
> > > > { .compatible = "renesas,r8a7740-sdhi", .data =
> > > > &sh_mobile_sdhi_of_cfg[0], },
> > > > + { .compatible = "renesas,sh73a0-sdhi", .data =
> > > > &sh_mobile_sdhi_of_cfg[0], },
> > > > + { .compatible = "renesas,r8a73a4-sdhi", .data =
> > > > &sh_mobile_sdhi_of_cfg[0], },
> > > > + { .compatible = "renesas,r8a7790-sdhi", .data =
> > > > &sh_mobile_sdhi_of_cfg[0], },
> > > > {},
> > >
> > > According to HW people, latest Renesas chip needs
> > > "TMIO_MMC_HAS_IDLE_WAIT".
> > > Could you plase add r8a7778 / r8a7779 here ?
> > >
> > > # or we can use common compatible name for it ?
> >
> > Hi Guennadi,
> >
> > could you please address Morimoto-san's review?
>
> He did it on
>
> Subject: [PATCH v4 5/7] mmc: SDHI: add DT compatibility strings for further
> SoCs
> Date: Tue, 9 Jul 2013 09:43:40 +0200 (CEST)
Thanks for pointing that out. Somehow I missed it.
--
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
Re: [PATCH v4 5/7] mmc: SDHI: add DT compatibility strings for further SoCs
On Tue, Jul 09, 2013 at 06:06:00PM +0900, Magnus Damm wrote: > On Tue, Jul 9, 2013 at 4:43 PM, Guennadi Liakhovetski > wrote: > > Add further OF compatibility strings to the SDHI driver to be able to > > precisely control driver's behaviour on each of them. > > > > Signed-off-by: Guennadi Liakhovetski > > --- > > > > v4: > > 1. added r8a7778 and r8a7779 per Morimoto-san's request > > 2. sh* and r8a* entries now sorted alphabetically > > This looks good to me, thanks. > > Acked-by: Magnus Damm Thanks, I have queued this up for v3.12 in the soc branch. It should appear in renesas-next-20130710 -- 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
Re: [PATCH v3 5/7] mmc: SDHI: add DT compatibility strings for further SoCs
On Mon, Jul 08, 2013 at 11:09:07PM -0700, Kuninori Morimoto wrote:
>
> Hi Guennadi
>
> > diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
> > b/drivers/mmc/host/sh_mobile_sdhi.c
> > index cc4c872..b58c1a9 100644
> > --- a/drivers/mmc/host/sh_mobile_sdhi.c
> > +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> > @@ -130,6 +130,9 @@ static const struct of_device_id
> > sh_mobile_sdhi_of_match[] = {
> > { .compatible = "renesas,shmobile-sdhi" },
> > { .compatible = "renesas,sh7372-sdhi" },
> > { .compatible = "renesas,r8a7740-sdhi", .data =
> > &sh_mobile_sdhi_of_cfg[0], },
> > + { .compatible = "renesas,sh73a0-sdhi", .data =
> > &sh_mobile_sdhi_of_cfg[0], },
> > + { .compatible = "renesas,r8a73a4-sdhi", .data =
> > &sh_mobile_sdhi_of_cfg[0], },
> > + { .compatible = "renesas,r8a7790-sdhi", .data =
> > &sh_mobile_sdhi_of_cfg[0], },
> > {},
>
> According to HW people, latest Renesas chip needs "TMIO_MMC_HAS_IDLE_WAIT".
> Could you plase add r8a7778 / r8a7779 here ?
>
> # or we can use common compatible name for it ?
Hi Guennadi,
could you please address Morimoto-san's review?
--
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
Re: [PATCH v2] dmaengine: shdma: fix a build failure on platforms with no DMA support
On Fri, May 31, 2013 at 04:51:52PM +0200, Arnd Bergmann wrote:
> On Friday 31 May 2013 05:01:31 Guennadi Liakhovetski wrote:
> > On platforms with no support for the shdma dmaengine driver build is
> > currently failing with
> >
> > drivers/built-in.o: In function `sh_mobile_sdhi_probe':
> > drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference
> > to`shdma_chan_filter'
> >
> > Fix the breakage by defining shdma_chan_filter to NULL in such
> > configurations.
> >
> > Signed-off-by: Guennadi Liakhovetski
>
> Sorry, I saw your patch too late and already spent some time doing a
> different one.
>
> > diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> > index b64d6be..1fd8a20 100644
> > --- a/include/linux/sh_dma.h
> > +++ b/include/linux/sh_dma.h
> > @@ -99,6 +99,10 @@ struct sh_dmae_pdata {
> > #define CHCR_TE0x0002
> > #define CHCR_IE0x0004
> >
> > +#if IS_ENABLED(CONFIG_SH_DMAE_BASE)
> > bool shdma_chan_filter(struct dma_chan *chan, void *arg);
> > +#else
> > +#define shdma_chan_filter NULL
> > +#endif
>
> I still think that this is not the right solution, or at least not
> complete: No slave driver should care about which dma-engine it is
> connected to. You have already done most of the necessary conversion,
> so it would be straightforward to also pass the filter function
> pointer to the sdhi driver along with the data that gets passed into
> it.
Hi Arnd, Hi Guennadi,
It seems to me that the solution above, though not particularly generic,
is sufficient as according to Guennadi SHDMA users cannot use other DMA
drivers[1]. The change above also has the merit of being rather small.
[1] https://patchwork.kernel.org/patch/2644101/
With that reasoning I would like to provide:
Acked-by: Simon Horman
--
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
Re: [PATCH] dmaengine: shdma: fix a build failure on platforms with no DMA support
On Thu, May 30, 2013 at 11:23:13AM -0500, Dan Murphy wrote:
> On 05/30/2013 11:02 AM, Guennadi Liakhovetski wrote:
> > On platforms with no support for the shdma dmaengine driver build is
> > currently failing with
> >
> > drivers/built-in.o: In function `sh_mobile_sdhi_probe':
> > drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference
> > to`shdma_chan_filter'
> >
> > Fix the breakage by defining shdma_chan_filter to NULL in such
> > configurations.
> >
> > Signed-off-by: Guennadi Liakhovetski
> > ---
> >
> > This is for "next." Compile-tested only. I'll test it on hardware next
> > week, but I don't think it shall break anything.
> >
> > include/linux/sh_dma.h |4
> > 1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> > index b64d6be..1fd8a20 100644
> > --- a/include/linux/sh_dma.h
> > +++ b/include/linux/sh_dma.h
> > @@ -99,6 +99,10 @@ struct sh_dmae_pdata {
> > #define CHCR_TE0x0002
> > #define CHCR_IE0x0004
> >
> > +#if IS_ENABLED(CONFIG_SH_DMAE)
> > bool shdma_chan_filter(struct dma_chan *chan, void *arg);
> > +#else
> > +#define shdma_chan_filter NULL
> Would this not be better as a
> #else
> static inline bool shdma_chan_filter(struct dma_chan *chan, void *arg)
> {
> return false;
> }
> #endif
>
> Otherwise runtime will call a NULL pointer
>
> > +#endif
> >
> > #endif
Hi Guennadi,
thanks for this. I will wait for a refresh (as we discussed earlier today).
Can I confirm that this is a fix for v3.10? If so, could ou note
that when you post your revised patch?
Thanks
--
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
Re: [PATCH v5 03/13] mmc: provide a standard MMC device-tree binding parser centrally
On Sun, Feb 17, 2013 at 04:52:16PM +0900, Simon Horman wrote: > On Sat, Feb 16, 2013 at 05:58:25PM +0100, Sascha Hauer wrote: > > Hi Guennadi, > > > > On Sat, Feb 16, 2013 at 04:21:16PM +0100, Guennadi Liakhovetski wrote: > > > MMC defines a number of standard DT bindings. Having each driver parse > > > them individually adds code redundancy and is error prone. Provide a > > > standard function to unify the parsing. After all drivers are converted > > > to using it instead of their own parsers, this function can be integrated > > > into mmc_alloc_host(). > > > > > > Signed-off-by: Guennadi Liakhovetski > > > --- > > > > > > v5: > > > > > > 1. fix an uninitialised variable warning. Note, I don't actually know, > > > whether this will fix the error, reported by the kbuild test robot. None > > > of my compilers reports an error there, at most, I've got a warning with > > > one of them, and, surprisingly, it is gone after this change. > > > Surprisingly, because I only add the bus_width initialisation in the > > > error > > > case - exactly as it actually has to be done. In the success case it is > > > assigned set by the function. But the compiler cannot know that! > > > > Maybe the build robot builds with devicetree disabled? In this case > > of_property_read_u32_array expands to a static inline function and the > > compiler indeed knows that &bus_width is unitialized. It also knows that > > this function always returns an error, so what you did below should > > silence the compiler. > > It seems so. The configuration that flagged the error was atngw100_defconfig. > > ARCH=avr32 make atngw100_defconfig > grep USE_OF .config > [nothing] In that vein I managed to reproduce the warning using ap4evb_defconfig and then enabled MMC. I have also verified that v5 does not produce the same warning. I chose this as I don't have a avr32 cross-compile environment but I do have one for ARM and I know that ap4evb doesn't use DT. I will update topic/mmc with v5. -- 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
Re: [PATCH v5 03/13] mmc: provide a standard MMC device-tree binding parser centrally
On Sat, Feb 16, 2013 at 05:58:25PM +0100, Sascha Hauer wrote: > Hi Guennadi, > > On Sat, Feb 16, 2013 at 04:21:16PM +0100, Guennadi Liakhovetski wrote: > > MMC defines a number of standard DT bindings. Having each driver parse > > them individually adds code redundancy and is error prone. Provide a > > standard function to unify the parsing. After all drivers are converted > > to using it instead of their own parsers, this function can be integrated > > into mmc_alloc_host(). > > > > Signed-off-by: Guennadi Liakhovetski > > --- > > > > v5: > > > > 1. fix an uninitialised variable warning. Note, I don't actually know, > > whether this will fix the error, reported by the kbuild test robot. None > > of my compilers reports an error there, at most, I've got a warning with > > one of them, and, surprisingly, it is gone after this change. > > Surprisingly, because I only add the bus_width initialisation in the error > > case - exactly as it actually has to be done. In the success case it is > > assigned set by the function. But the compiler cannot know that! > > Maybe the build robot builds with devicetree disabled? In this case > of_property_read_u32_array expands to a static inline function and the > compiler indeed knows that &bus_width is unitialized. It also knows that > this function always returns an error, so what you did below should > silence the compiler. It seems so. The configuration that flagged the error was atngw100_defconfig. ARCH=avr32 make atngw100_defconfig grep USE_OF .config [nothing] -- 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
Re: [PATCH v4 03/13] mmc: provide a standard MMC device-tree binding parser centrally
On Sat, Feb 16, 2013 at 10:54:36AM +, Arnd Bergmann wrote:
> On Saturday 16 February 2013, Simon Horman wrote:
> > > +void mmc_of_parse(struct mmc_host *host)
> > > +{
> > > + struct device_node *np;
> > > + u32 bus_width;
> > > + bool explicit_inv_wp, gpio_inv_wp = false;
> > > + enum of_gpio_flags flags;
> > > + int len, ret, gpio;
> > > +
> > > + if (!host->parent || !host->parent->of_node)
> > > + return;
> > > +
> > > + np = host->parent->of_node;
> > > +
> > > + /* "bus-width" is translated to MMC_CAP_*_BIT_DATA flags */
> > > + if (of_property_read_u32_array(np, "bus-width", &bus_width, 1) < 0)
> > > + dev_dbg(host->parent,
> > > + "\"bus-width\" property is missing, assuming 1
> > > bit.\n");
> > > +
> > > + switch (bus_width) {
> >
> > kbuild tells me that gcc thinks that bus_width is used without being
> > initialised here. Assuming that of_property_read_u32_array always
> > initialises bus_width if it returns zero then perhaps it would be worth
> > considering using uninitialized_var().
>
> I think this is a false positive that I encountered before and that should be
> gone
> with gcc-4.7 or higher when using -O2 instead of -Os. I have a patch to
> disable
> -Wmaybe-uninitialized when builing with -Os. If that gets rid of the warning,
> I'd prefer not annotating it here.
>
> There was some discussion about removing uninitialized_var() recently after it
> was found to hide some real bugs.
Thanks. I agree that using uninitialized_var() may not be the best idea.
--
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
Re: [PATCH v4 03/13] mmc: provide a standard MMC device-tree binding parser centrally
On Fri, Feb 15, 2013 at 04:13:52PM +0100, Guennadi Liakhovetski wrote:
> MMC defines a number of standard DT bindings. Having each driver parse
> them individually adds code redundancy and is error prone. Provide a
> standard function to unify the parsing. After all drivers are converted
> to using it instead of their own parsers, this function can be integrated
> into mmc_alloc_host().
>
> Cc: Markus Pargmann
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> v4: make the bus-width property optional to match a recent change to
> mmc.txt, use of_property_read_bool() to obtain a boolean value of a DT
> property, add comments.
>
> drivers/mmc/core/host.c | 108
> ++
> include/linux/mmc/host.h |1 +
> 2 files changed, 109 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index ee2e16b..daa2ed1 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -15,6 +15,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -23,6 +25,7 @@
>
> #include
> #include
> +#include
>
> #include "core.h"
> #include "host.h"
> @@ -295,6 +298,111 @@ static inline void mmc_host_clk_sysfs_init(struct
> mmc_host *host)
> #endif
>
> /**
> + * mmc_of_parse() - parse host's device-tree node
> + * @host: host, whose node should be parsed.
> + *
> + * To keep the rest of the MMC subsystem unaware of the fact, whether DT has
> + * been used to to instantiate and configure this host instance or not, we
> + * parse the properties and set respective generic mmc-host flags and
> + * parameters.
> + */
> +void mmc_of_parse(struct mmc_host *host)
> +{
> + struct device_node *np;
> + u32 bus_width;
> + bool explicit_inv_wp, gpio_inv_wp = false;
> + enum of_gpio_flags flags;
> + int len, ret, gpio;
> +
> + if (!host->parent || !host->parent->of_node)
> + return;
> +
> + np = host->parent->of_node;
> +
> + /* "bus-width" is translated to MMC_CAP_*_BIT_DATA flags */
> + if (of_property_read_u32_array(np, "bus-width", &bus_width, 1) < 0)
> + dev_dbg(host->parent,
> + "\"bus-width\" property is missing, assuming 1 bit.\n");
> +
> + switch (bus_width) {
kbuild tells me that gcc thinks that bus_width is used without being
initialised here. Assuming that of_property_read_u32_array always
initialises bus_width if it returns zero then perhaps it would be worth
considering using uninitialized_var().
> + case 8:
> + host->caps |= MMC_CAP_8_BIT_DATA;
> + /* Hosts, capable of 8-bit transfers can also do 4 bits */
> + case 4:
> + host->caps |= MMC_CAP_4_BIT_DATA;
> + break;
> + case 1:
> + break;
> + default:
> + dev_err(host->parent,
> + "Invalid \"bus-width\" value %ud!\n", bus_width);
> + }
> +
> + /* f_max is obtained from the optional "max-frequency" property */
> + of_property_read_u32_array(np, "max-frequency", &host->f_max, 1);
> +
> + /*
> + * Configure CD and WP pins. They are both by default active low to
> + * match the SDHCI spec. If GPIOs are provided for CD and / or WP, the
> + * mmc-gpio helpers are used to attach, configure and use them. If
> + * polarity inversion is specified in DT, one of MMC_CAP2_CD_ACTIVE_HIGH
> + * and MMC_CAP2_RO_ACTIVE_HIGH capability-2 flags is set. If the
> + * "broken-cd" property is provided, the MMC_CAP_NEEDS_POLL capability
> + * is set. If the "non-removable" property is found, the
> + * MMC_CAP_NONREMOVABLE capability is set and no card-detection
> + * configuration is performed.
> + */
> +
> + /* Parse Card Detection */
> + if (of_find_property(np, "non-removable", &len)) {
> + host->caps |= MMC_CAP_NONREMOVABLE;
> + } else {
> + bool explicit_inv_cd, gpio_inv_cd = false;
> +
> + explicit_inv_cd = of_property_read_bool(np, "cd-inverted");
> +
> + if (of_find_property(np, "broken-cd", &len))
> + host->caps |= MMC_CAP_NEEDS_POLL;
> +
> + gpio = of_get_named_gpio_flags(np, "cd-gpios", 0, &flags);
> + if (gpio_is_valid(gpio)) {
> + if (!(flags & OF_GPIO_ACTIVE_LOW))
> + gpio_inv_cd = true;
> +
> + ret = mmc_gpio_request_cd(host, gpio);
> + if (ret < 0)
> + dev_err(host->parent,
> + "Failed to request CD GPIO #%d: %d!\n",
> + gpio, ret);
> + else
> + dev_info(host->parent, "Got CD GPIO #%d.\n",
> + gpio);
> + }
> +
> + if (explicit_inv_cd ^ gpio_inv_cd)
> +
Re: [PATCH v4 00/13] mmc: core and driver DT and related development
On Fri, Feb 15, 2013 at 04:13:49PM +0100, Guennadi Liakhovetski wrote: > This is v4 of a patch-series, extending mmc subsystem device-tree usage > and adding more advanced DT capabilities to sh_mmcif and sh_mobile_sdhi / > tmio_mmc drivers. Changes since v3 are described in respective patches. > Thanks to all who commented on v3. Hi, I do not expect this code to go through the renesas tree. However, in order to provide a basis for work on renesas SoCs I have added this patch to the topic/mmc topic branch in the reneas tree on kernel.org and merged it into topic/all+next. In other words, I am not picking this series up to merge it or add it to linux-next, rather I am storing it for reference. -- 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
Re: [PATCH v3 06/13] mmc: tmio-mmc: define device-tree bindings
On Thu, Feb 14, 2013 at 11:09:06AM +0900, Magnus Damm wrote: > On Thu, Feb 14, 2013 at 10:59 AM, Simon Horman wrote: > > On Thu, Feb 14, 2013 at 10:42:21AM +0900, Magnus Damm wrote: > >> On Thu, Feb 14, 2013 at 12:59 AM, Guennadi Liakhovetski > >> wrote: > >> > On Thu, 7 Feb 2013, Simon Horman wrote: > >> > > >> >> On Wed, Feb 06, 2013 at 10:24:20PM +, Arnd Bergmann wrote: > >> >> > On Wednesday 06 February 2013, Guennadi Liakhovetski wrote: > >> >> > > +* Toshiba Mobile IO SD/MMC controller > >> >> > > + > >> >> > > +The tmio-mmc driver doesn't probe its devices actively, instead > >> >> > > its binding to > >> >> > > +devices is managed by either MFD drivers or by the sh_mobile_sdhi > >> >> > > platform > >> >> > > +driver. Those drivers supply the tmio-mmc driver with platform > >> >> > > data, that either > >> >> > > +describe hardware capabilities, known to them, or are obtained by > >> >> > > them from > >> >> > > +their own platform data or from their DT information. In the > >> >> > > latter case all > >> >> > > +compulsory and any optional properties, common to all SD/MMC > >> >> > > drivers, as > >> >> > > +described in mmc.txt, should or can be used. Additionally the > >> >> > > following optional > >> >> > > +bindings can be used. They set respective TMIO_MMC_* flags. > >> >> > > + > >> >> > > +Optional properties: > >> >> > > +- toshiba,mmc-wrprotect-disable: set > >> >> > > TMIO_MMC_WRPROTECT_DISABLE flag > >> >> > > +- toshiba,mmc-blksz-2bytes : set TMIO_MMC_BLKSZ_2BYTES > >> >> > > +- toshiba,mmc-has-idle-wait: set TMIO_MMC_HAS_IDLE_WAIT > >> >> > > >> >> > Please write the binding in a way that does not refer to a specific > >> >> > implementation in Linux: The binding should describe the hardware > >> >> > independent of details in the driver. In particular, I think you > >> >> > should not refer to the TMIO_MMC_BLKSZ_2BYTES etc macros but describe > >> >> > in text what the flags are about. > >> >> > > >> >> > Regarding the toshiba,mmc-wrprotect-disable property, would it be > >> >> > enough to just check the presence of the wp-gpios property? > >> >> > > >> >> > TMIO_MMC_BLKSZ_2BYTES seems to be set unconditionally in > >> >> > sh_mobile_sdhi_probe and nowhere else, so I'd assume we don't > >> >> > actually need to provide this here, but can keep that knowledge > >> >> > implicit based on whether we're talking to sh_mobile_sdhi > >> >> > or another tmio_mmc variant. > >> > > >> > Can do that, yes. > >> > > >> >> > For the other last one, is that actually board specific, or just > >> >> > a feature of a given chip? If we can tell by the SoC, then I'd > >> >> > suggest using separate "compatible" properties instead, and > >> >> > put a bitmask of features into the .data field of the of match > >> >> > table. For all I can tell, SH7372 does not set it, while SH73A0, > >> >> > R8A7740 and R8A7779 always do. > >> >> > >> >> My understanding is that TMIO_MMC_HAS_IDLE_WAIT can be set based > >> >> on the SoC in use. > >> > > >> > So far TMIO_MMC_HAS_IDLE_WAIT is set on > >> > > >> > board-kzm9g.c (sh73a0 / AG5) > >> > board-ag5evm.c (sh73a0 / AG5) > >> > board-armadillo800eva.c (r8a7740 / A1) > >> > board-kota2.c (sh73a0 / AG5) > >> > board-marzen.c (r8a7779 / H1) > >> > > >> > and isn't set on > >> > > >> > board-ap4evb.c (sh7372 / ap4) > >> > board-bonito.c (r8a7740 / a1, SDHI isn't used) > >> > board-mackerel.c (sh7372 / ap4) > >> > > >> > So, shall we use a compatible property for this and drop this property? > >> > We > >> > can add later at any time, if needed, which is better, than defining > >> > something redundant. OTOH I seem to remember, that using SoC-version from > &
Re: [PATCH v3 06/13] mmc: tmio-mmc: define device-tree bindings
On Thu, Feb 14, 2013 at 10:42:21AM +0900, Magnus Damm wrote: > On Thu, Feb 14, 2013 at 12:59 AM, Guennadi Liakhovetski > wrote: > > On Thu, 7 Feb 2013, Simon Horman wrote: > > > >> On Wed, Feb 06, 2013 at 10:24:20PM +, Arnd Bergmann wrote: > >> > On Wednesday 06 February 2013, Guennadi Liakhovetski wrote: > >> > > +* Toshiba Mobile IO SD/MMC controller > >> > > + > >> > > +The tmio-mmc driver doesn't probe its devices actively, instead its > >> > > binding to > >> > > +devices is managed by either MFD drivers or by the sh_mobile_sdhi > >> > > platform > >> > > +driver. Those drivers supply the tmio-mmc driver with platform data, > >> > > that either > >> > > +describe hardware capabilities, known to them, or are obtained by > >> > > them from > >> > > +their own platform data or from their DT information. In the latter > >> > > case all > >> > > +compulsory and any optional properties, common to all SD/MMC drivers, > >> > > as > >> > > +described in mmc.txt, should or can be used. Additionally the > >> > > following optional > >> > > +bindings can be used. They set respective TMIO_MMC_* flags. > >> > > + > >> > > +Optional properties: > >> > > +- toshiba,mmc-wrprotect-disable: set > >> > > TMIO_MMC_WRPROTECT_DISABLE flag > >> > > +- toshiba,mmc-blksz-2bytes : set TMIO_MMC_BLKSZ_2BYTES > >> > > +- toshiba,mmc-has-idle-wait: set TMIO_MMC_HAS_IDLE_WAIT > >> > > >> > Please write the binding in a way that does not refer to a specific > >> > implementation in Linux: The binding should describe the hardware > >> > independent of details in the driver. In particular, I think you > >> > should not refer to the TMIO_MMC_BLKSZ_2BYTES etc macros but describe > >> > in text what the flags are about. > >> > > >> > Regarding the toshiba,mmc-wrprotect-disable property, would it be > >> > enough to just check the presence of the wp-gpios property? > >> > > >> > TMIO_MMC_BLKSZ_2BYTES seems to be set unconditionally in > >> > sh_mobile_sdhi_probe and nowhere else, so I'd assume we don't > >> > actually need to provide this here, but can keep that knowledge > >> > implicit based on whether we're talking to sh_mobile_sdhi > >> > or another tmio_mmc variant. > > > > Can do that, yes. > > > >> > For the other last one, is that actually board specific, or just > >> > a feature of a given chip? If we can tell by the SoC, then I'd > >> > suggest using separate "compatible" properties instead, and > >> > put a bitmask of features into the .data field of the of match > >> > table. For all I can tell, SH7372 does not set it, while SH73A0, > >> > R8A7740 and R8A7779 always do. > >> > >> My understanding is that TMIO_MMC_HAS_IDLE_WAIT can be set based > >> on the SoC in use. > > > > So far TMIO_MMC_HAS_IDLE_WAIT is set on > > > > board-kzm9g.c (sh73a0 / AG5) > > board-ag5evm.c (sh73a0 / AG5) > > board-armadillo800eva.c (r8a7740 / A1) > > board-kota2.c (sh73a0 / AG5) > > board-marzen.c (r8a7779 / H1) > > > > and isn't set on > > > > board-ap4evb.c (sh7372 / ap4) > > board-bonito.c (r8a7740 / a1, SDHI isn't used) > > board-mackerel.c (sh7372 / ap4) > > > > So, shall we use a compatible property for this and drop this property? We > > can add later at any time, if needed, which is better, than defining > > something redundant. OTOH I seem to remember, that using SoC-version from > > the "compatible" property was considered by someone inappropriate. Magnus, > > what do you think? > > I prefer you to use a hardware-block version compatible suffix instead > of SoC suffix. > > This since we have more SoCs than actual hardware block > configurations. Using the list above, how many configurations would we > have? > > Actually, forcing the drivers to be updated for each new SoC sounds > like a pretty terrible idea. Wouldn't that be against one of the > merits of using DT? Also, don't you have enough interesting work piled > up already? =) > > Basically, I can't see any point in adding an extra unnecessary need > for updating the drivers when there is no real functional change. My understanding is that the discussion is about the details of bindings that are required for SDHI to function when brought up using DT on a variety of boards. Not exciting new work. In particular how to set TMIO_MMC_HAS_IDLE_WAIT via DT. -- 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
Re: [PATCH v3 06/13] mmc: tmio-mmc: define device-tree bindings
On Wed, Feb 06, 2013 at 10:24:20PM +, Arnd Bergmann wrote: > On Wednesday 06 February 2013, Guennadi Liakhovetski wrote: > > +* Toshiba Mobile IO SD/MMC controller > > + > > +The tmio-mmc driver doesn't probe its devices actively, instead its > > binding to > > +devices is managed by either MFD drivers or by the sh_mobile_sdhi platform > > +driver. Those drivers supply the tmio-mmc driver with platform data, that > > either > > +describe hardware capabilities, known to them, or are obtained by them from > > +their own platform data or from their DT information. In the latter case > > all > > +compulsory and any optional properties, common to all SD/MMC drivers, as > > +described in mmc.txt, should or can be used. Additionally the following > > optional > > +bindings can be used. They set respective TMIO_MMC_* flags. > > + > > +Optional properties: > > +- toshiba,mmc-wrprotect-disable: set TMIO_MMC_WRPROTECT_DISABLE > > flag > > +- toshiba,mmc-blksz-2bytes : set TMIO_MMC_BLKSZ_2BYTES > > +- toshiba,mmc-has-idle-wait: set TMIO_MMC_HAS_IDLE_WAIT > > Please write the binding in a way that does not refer to a specific > implementation in Linux: The binding should describe the hardware > independent of details in the driver. In particular, I think you > should not refer to the TMIO_MMC_BLKSZ_2BYTES etc macros but describe > in text what the flags are about. > > Regarding the toshiba,mmc-wrprotect-disable property, would it be > enough to just check the presence of the wp-gpios property? > > TMIO_MMC_BLKSZ_2BYTES seems to be set unconditionally in > sh_mobile_sdhi_probe and nowhere else, so I'd assume we don't > actually need to provide this here, but can keep that knowledge > implicit based on whether we're talking to sh_mobile_sdhi > or another tmio_mmc variant. > > For the other last one, is that actually board specific, or just > a feature of a given chip? If we can tell by the SoC, then I'd > suggest using separate "compatible" properties instead, and > put a bitmask of features into the .data field of the of match > table. For all I can tell, SH7372 does not set it, while SH73A0, > R8A7740 and R8A7779 always do. My understanding is that TMIO_MMC_HAS_IDLE_WAIT can be set based on the SoC in use. -- 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
Re: [PATCH/RFC v2 06/11] mmc: tmio-mmc: define device-tree bindings
On Wed, Jan 23, 2013 at 04:32:33PM +0100, Guennadi Liakhovetski wrote: > Define device-tree bindings for the tmio-mmc driver to be able to specify > parameters, currently provided in platform data. > > Cc: Magnus Damm > Signed-off-by: Guennadi Liakhovetski > --- > > Please, comment on this one, since it is defining an ABI > > Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 19 +++ > 1 files changed, 19 insertions(+), 0 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mmc/tmio_mmc.txt > > diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt > b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt > new file mode 100644 > index 000..dd8decd > --- /dev/null > +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt > @@ -0,0 +1,19 @@ > +* Toshiba Mobile IO SD/MMC controller > + > +The tmio-mmc driver doesn't probe its devices actively, instead its binding > to > +devices is managed by either MFD drivers or by the sh_mobile_sdhi platform > +driver. Those drivers supply the tmio-mmc driver with platform data, that > either > +describe hardware capabilities, known to them, or are obtained by them from > +their own platform data or from their DT information. In the latter case all > +compulsory and any optional properties, common to all SD/MMC drivers, as > +described in mmc.txt, should or can be used. Additionally the following > optional > +bindings can be used. They set either respective TMIO_MMC_* flags or > MMC_CAP_* > +capabilities. > + > +Optional properties: > +- toshiba,mmc-wrprotect-disable : set TMIO_MMC_WRPROTECT_DISABLE flag > +- toshiba,mmc-blksz-2bytes : set TMIO_MMC_BLKSZ_2BYTES > +- toshiba,mmc-cap-sdio-irq : SDIO IRQ signalling should be used, if > + supported by the hardware, i.e. set MMC_CAP_SDIO_IRQ if > + TMIO_MMC_SDIO_IRQ is also set > +- toshiba,mmc-has-idle-wait : set TMIO_MMC_HAS_IDLE_WAIT FWIW, TMIO_MMC_HAS_IDLE_WAIT appears to be required for SDHI0 to function on the Marzen board. As I have been doing some work on bring up the Marzen board using DT I am very happy to see these new bindings. -- 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
Re: [PATCH] mmc: sh_mobile_sdhi: fix clock frequency printing
On Wed, Nov 28, 2012 at 10:24:13AM +0100, Guennadi Liakhovetski wrote: > During its probing the SDHI driver prints out the clock frequency, but > does it wrongly, always reporting 0Hz. Use the MMC host frequency value > to fix this issue. > > Signed-off-by: Guennadi Liakhovetski Reviewed-by: Simon Horman > --- > drivers/mmc/host/sh_mobile_sdhi.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/mmc/host/sh_mobile_sdhi.c > b/drivers/mmc/host/sh_mobile_sdhi.c > index 22ac8e7..d6ff853 100644 > --- a/drivers/mmc/host/sh_mobile_sdhi.c > +++ b/drivers/mmc/host/sh_mobile_sdhi.c > @@ -248,7 +248,7 @@ static int __devinit sh_mobile_sdhi_probe(struct > platform_device *pdev) > dev_info(&pdev->dev, "%s base at 0x%08lx clock rate %u MHz\n", >mmc_hostname(host->mmc), (unsigned long) >(platform_get_resource(pdev, IORESOURCE_MEM, 0)->start), > - mmc_data->hclk / 100); > + host->mmc->f_max / 100); > > return ret; > > -- > 1.7.2.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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
Re: [PATCH] mmc: sh_mmcif: remove unneeded clock connection ID
On Wed, Nov 28, 2012 at 10:24:27AM +0100, Guennadi Liakhovetski wrote:
> MMCIF only uses one clock, all ARM and SuperH platforms register MMCIF
> clock lookup entries with no connection ID, hence it can be dropped in
> the driver too.
>
> Signed-off-by: Guennadi Liakhovetski
Reviewed-by: Simon Horman
> ---
> drivers/mmc/host/sh_mmcif.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index d25bc97..358295e 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -1310,7 +1310,6 @@ static int __devinit sh_mmcif_probe(struct
> platform_device *pdev)
> struct sh_mmcif_plat_data *pd = pdev->dev.platform_data;
> struct resource *res;
> void __iomem *reg;
> - char clk_name[8];
>
> irq[0] = platform_get_irq(pdev, 0);
> irq[1] = platform_get_irq(pdev, 1);
> @@ -1360,11 +1359,10 @@ static int __devinit sh_mmcif_probe(struct
> platform_device *pdev)
> pm_runtime_enable(&pdev->dev);
> host->power = false;
>
> - snprintf(clk_name, sizeof(clk_name), "mmc%d", pdev->id);
> - host->hclk = clk_get(&pdev->dev, clk_name);
> + host->hclk = clk_get(&pdev->dev, NULL);
> if (IS_ERR(host->hclk)) {
> ret = PTR_ERR(host->hclk);
> - dev_err(&pdev->dev, "cannot get clock \"%s\": %d\n", clk_name,
> ret);
> + dev_err(&pdev->dev, "cannot get clock: %d\n", ret);
> goto eclkget;
> }
> ret = sh_mmcif_clk_update(host);
> --
> 1.7.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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
Re: [PATCH] mmc: sh_mobile_sdhi: remove unneeded clock connection ID
On Wed, Nov 28, 2012 at 10:24:21AM +0100, Guennadi Liakhovetski wrote:
> SDHI only uses one clock, all ARM and SuperH platform register SDHI clock
> lookup entries with no connection ID, hence it can be dropped in the
> driver too.
>
> Signed-off-by: Guennadi Liakhovetski
Reviewed-by: Simon Horman
> ---
> drivers/mmc/host/sh_mobile_sdhi.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
> b/drivers/mmc/host/sh_mobile_sdhi.c
> index 0bdc146..22ac8e7 100644
> --- a/drivers/mmc/host/sh_mobile_sdhi.c
> +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> @@ -123,7 +123,6 @@ static int __devinit sh_mobile_sdhi_probe(struct
> platform_device *pdev)
> struct tmio_mmc_data *mmc_data;
> struct sh_mobile_sdhi_info *p = pdev->dev.platform_data;
> struct tmio_mmc_host *host;
> - char clk_name[8];
> int irq, ret, i = 0;
> bool multiplexed_isr = true;
>
> @@ -144,11 +143,10 @@ static int __devinit sh_mobile_sdhi_probe(struct
> platform_device *pdev)
> }
> }
>
> - snprintf(clk_name, sizeof(clk_name), "sdhi%d", pdev->id);
> - priv->clk = clk_get(&pdev->dev, clk_name);
> + priv->clk = clk_get(&pdev->dev, NULL);
> if (IS_ERR(priv->clk)) {
> - dev_err(&pdev->dev, "cannot get clock \"%s\"\n", clk_name);
> ret = PTR_ERR(priv->clk);
> + dev_err(&pdev->dev, "cannot get clock: %d\n", ret);
> goto eclkget;
> }
>
> --
> 1.7.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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
Re: [PATCH] ARM: shmobile: fix MMCIF IRQ assignment on kzm9g
On Wed, Sep 19, 2012 at 11:08:52PM +0200, Guennadi Liakhovetski wrote: > Hi Simon > > On Wed, 19 Sep 2012, Simon Horman wrote: > > > On Wed, Sep 19, 2012 at 12:52:26AM +0200, Guennadi Liakhovetski wrote: > > > Error and operation IRQs are swapped in kzm9g platform data, this patch > > > fixes their order. The only problem this bug causes is the confusing IRQ > > > count in /proc/interrupts output, otherwise functionality is unaffected, > > > since the driver doesn't really differentiate between the two IRQs. > > > > > > Signed-off-by: Guennadi Liakhovetski > > > > Thanks Guennadi, > > > > as it happens I merged a very similar (same?) patch into the > > fixes branch of my renesas tree yesterday. It has been accepted > > by the arm-soc people and should appear in 3.6. > > Good, just wondering what about ag5evm, it does seem to have the same > problem. As mentioned before, this is just a "cosmetic" fix, so, up to you > to decide when and how and if you'd like to fix it. Good point. Could you prepare a patch just for ag5evm for me to queue up? -- 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
Re: [PATCH] ARM: shmobile: fix MMCIF IRQ assignment on kzm9g
On Wed, Sep 19, 2012 at 12:52:26AM +0200, Guennadi Liakhovetski wrote: > Error and operation IRQs are swapped in kzm9g platform data, this patch > fixes their order. The only problem this bug causes is the confusing IRQ > count in /proc/interrupts output, otherwise functionality is unaffected, > since the driver doesn't really differentiate between the two IRQs. > > Signed-off-by: Guennadi Liakhovetski Thanks Guennadi, as it happens I merged a very similar (same?) patch into the fixes branch of my renesas tree yesterday. It has been accepted by the arm-soc people and should appear in 3.6. -- 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
[PATCH] mmc: sh_mmcif: mmc->f_max heuristic
In 930f152cc9998388031af577843baae572ac8ab6 ("mmc: sh_mmcif: mmc->f_max
should be half of the bus clock") I changed the setting of mmc->f_max from
the bus clock to half the bus clock based on the manual for the sh7372 SoC.
Inspection of sh_mmcif_clock_control() reveals that it relies on
mmc->f_max being set to the bus speed in order to enable the supplementary
clock, a feature that is only known to exist on the sh7757 SoC.
Armed with this information implement the following heuristic for setting
mmc->f_max:
* Use bus clock if the supplementary clock feature is present
- Confirmed in the documentation of the sh7757 SoC.
* Use half the bus clock otherwise
- As per the documentation for the sh7372, sh7724 and R8A7740 SoCs.
Reported-by: Magnus Damm
Cc: Guennadi Liakhovetski
Cc: Chris Brandt
Signed-off-by: Simon Horman
---
Regression information:
It seems likely that this resolves a regression for the sh7757lcr which was
introduced by 930f152cc9998388031af577843baae572ac8ab6 ("mmc: sh_mmcif:
mmc->f_max should be half of the bus clock"). However, although I have the
hardware in question I am unsure how to exercise the code to test if there
is a problem or not.
930f152cc9998388031af577843baae572ac8ab6 was added between the 3.3 and 3.4.
Dependency information:
This patch is based on Guennadi Liakhovetski's recent series
"[PATCH 0/5 v4] mmc: sh_mmcif: clock and power updates". It should
be trivial to rebase it on 3.5-rc3.
---
drivers/mmc/host/sh_mmcif.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 204bced..04b14d0 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -450,7 +450,11 @@ static void sh_mmcif_clock_control(struct sh_mmcif_host
*host, unsigned int clk)
if (!clk)
return;
- if (p->sup_pclk && clk == host->clk)
+ /* clk == host->clk implies that p->sup_pclk is non-zero
+* as otherwise the maximum value of clk is host->clk / 2
+* as per the value of host->mmc->f_max
+*/
+ if (clk == host->clk)
sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL, CLK_SUP_PCLK);
else
sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL, CLK_CLEAR &
@@ -913,10 +917,11 @@ static void sh_mmcif_request(struct mmc_host *mmc, struct
mmc_request *mrq)
static int sh_mmcif_clk_update(struct sh_mmcif_host *host)
{
int ret = clk_enable(host->hclk);
+ struct sh_mmcif_plat_data *p = host->pd->dev.platform_data;
if (!ret) {
host->clk = clk_get_rate(host->hclk);
- host->mmc->f_max = host->clk / 2;
+ host->mmc->f_max = p->sup_pclk ? host->clk : host->clk / 2;
host->mmc->f_min = host->clk / 512;
}
--
1.7.10.2.484.gcd07cc5
--
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
Re: [PATCH] mmc: sh_mmcif: mmc->f_max heuristic
On Thu, Jun 21, 2012 at 07:11:42AM -0700, Brandt, Chris wrote:
> > At least for the sh7757 and sh7372.
> Also for the sh7724 (ie, only the sh7757 can run at full bus speed by setting
> CLKDIV=0xF which no other part canyet)
Thanks.
> But, with this new patch applied:
>
> > if (!ret) {
> > host->clk = clk_get_rate(host->hclk);
> > - host->mmc->f_max = host->clk / 2;
> > + host->mmc->f_max = p->sup_pclk ? host->clk : host->clk / 2;
> > host->mmc->f_min = host->clk / 512;
> > }
>
> Then there's no need to check for p->sup_pclk in sh_mmcif_clock_control()
> because if (clk == host->clk) then p->sup_pclk can be assumed to be set.
>
> - if (p->sup_pclk && clk == host->clk)
> + if (clk == host->clk)
> sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL, CLK_SUP_PCLK);
> else
> sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL, CLK_CLEAR &
> ((fls(DIV_ROUND_UP(host->clk,
> clk) - 1) - 1) << 16));
>
>
> But, that's probably more along the lines of driver cleanup I guess.
Thanks, I'll add that.
--
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
Re: [PATCH] mmc: sh_mmcif: mmc->f_max heuristic
On Wed, Jun 20, 2012 at 07:56:44AM -0700, Brandt, Chris wrote: > > I would be very happy if someone with access to > > the documentation could shed some further light on this. > > According to the SH7757 manual, setting the CLKDIV[3:0] in the CE_CLK_CTRL > register 0xF selects Pck as the bus clock frequency. So, unlike other devices > where Pck/2 (CLKDIV[3:0]=0) is the max bus speed, the SH7757 can run at Pck > when CLKDIV=0xF. Thanks Chris, please correct me if I am wrong, but that seems to indicate the heuristic is correct. At least for the sh7757 and sh7372. -- 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
Re: [PATCH] mmc: sh_mmcif: mmc->f_max heuristic
On Wed, Jun 20, 2012 at 08:49:38AM +0200, Guennadi Liakhovetski wrote:
> Hi Simon
>
> Thanks for addressing this issue.
>
> On Wed, 20 Jun 2012, Simon Horman wrote:
>
> > In 930f152cc9998388031af577843baae572ac8ab6 ("mmc: sh_mmcif: mmc->f_max
> > should be half of the bus clock") I changed the setting of mmc->f_max from
> > the bus clock to half the bus clock based on the manual for the sh7372 SoC.
> >
> > Inspection of sh_mmcif_clock_control() reveals that it relies on
> > mmc->f_max being set to the bus speed in order to enable the supplementary
> > clock, a feature that does not exist on the sh7372.
> >
> > Armed with this information implement the following heuristic for setting
> > mmc->f_max:
> >
> > * Use bus clock if the supplementary clock feature is present
> > - Assumed to work on the sh7757lcr board, the only board present
> > in the tree which has the feature.
>
> To be able to better understand this change: do we have access to the
> sh7757 documentation and does it actually explain how the CLK_SUP_PCLK bit
> in MMCIF_CE_CLK_CTRL functions? Does it actually set the MMC bus clock to
> be equal to the host clock?
My understanding is that neither Magnus nor I have access to the
documentation for the sh7757. Thus we could only infer things from
examining the source code. I would be very happy if someone with access to
the documentation could shed some further light on this. In particular,
I would be happy if this heuristic was shown not to be necessary. But
in lieu of access to the documentation I think this patch is reasonable.
--
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
Re: [PATCH 2/5 v4] mmc: sh_mmcif: fix clock management
On Wed, Jun 20, 2012 at 08:41:42AM +0200, Guennadi Liakhovetski wrote:
> On Wed, 20 Jun 2012, Simon Horman wrote:
>
> > Hi Guennadi,
> >
> > On Wed, Jun 13, 2012 at 03:37:19PM +0200, Guennadi Liakhovetski wrote:
> > > Regardless, whether the MMC bus clock is the same, as the PM clock on this
> > > specific interface, it has to be managed separately. Its proper management
> > > should also include enabling and disabling of the clock, whenever the
> > > interface is becoming active or going idle respectively.
> > >
> > > Signed-off-by: Guennadi Liakhovetski
> > > ---
> > > drivers/mmc/host/sh_mmcif.c | 46
> > > +-
> > > 1 files changed, 23 insertions(+), 23 deletions(-)
> > >
> > > diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> > > index d6ffb05..6a93b04 100644
> > > --- a/drivers/mmc/host/sh_mmcif.c
> > > +++ b/drivers/mmc/host/sh_mmcif.c
> > > @@ -942,6 +942,7 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc,
> > > struct mmc_ios *ios)
> > > }
> > > if (host->power) {
> > > pm_runtime_put(&host->pd->dev);
> > > + clk_disable(host->hclk);
> > > host->power = false;
> > > if (p->down_pwr && ios->power_mode == MMC_POWER_OFF)
> > > p->down_pwr(host->pd);
> > > @@ -954,6 +955,7 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc,
> > > struct mmc_ios *ios)
> > > if (!host->power) {
> > > if (p->set_pwr)
> > > p->set_pwr(host->pd, ios->power_mode);
> > > + clk_enable(host->hclk);
> > > pm_runtime_get_sync(&host->pd->dev);
> > > host->power = true;
> > > sh_mmcif_sync_reset(host);
> > > @@ -1278,22 +1280,11 @@ static int __devinit sh_mmcif_probe(struct
> > > platform_device *pdev)
> > > host->addr = reg;
> > > host->timeout = 1000;
> > >
> > > - snprintf(clk_name, sizeof(clk_name), "mmc%d", pdev->id);
> > > - host->hclk = clk_get(&pdev->dev, clk_name);
> > > - if (IS_ERR(host->hclk)) {
> > > - dev_err(&pdev->dev, "cannot get clock \"%s\"\n", clk_name);
> > > - ret = PTR_ERR(host->hclk);
> > > - goto eclkget;
> > > - }
> > > - clk_enable(host->hclk);
> > > - host->clk = clk_get_rate(host->hclk);
> > > host->pd = pdev;
> > >
> > > spin_lock_init(&host->lock);
> > >
> > > mmc->ops = &sh_mmcif_ops;
> > > - mmc->f_max = host->clk / 2;
> > > - mmc->f_min = host->clk / 512;
> > > if (pd->ocr)
> > > mmc->ocr_avail = pd->ocr;
> > > mmc->caps = MMC_CAP_MMC_HIGHSPEED;
> > > @@ -1305,18 +1296,30 @@ static int __devinit sh_mmcif_probe(struct
> > > platform_device *pdev)
> > > mmc->max_blk_count = mmc->max_req_size / mmc->max_blk_size;
> > > mmc->max_seg_size = mmc->max_req_size;
> > >
> > > - sh_mmcif_sync_reset(host);
> > > platform_set_drvdata(pdev, host);
> > >
> > > pm_runtime_enable(&pdev->dev);
> > > host->power = false;
> > >
> > > + snprintf(clk_name, sizeof(clk_name), "mmc%d", pdev->id);
> > > + host->hclk = clk_get(&pdev->dev, clk_name);
> > > + if (IS_ERR(host->hclk)) {
> > > + ret = PTR_ERR(host->hclk);
> > > + dev_err(&pdev->dev, "cannot get clock \"%s\": %d\n", clk_name,
> > > ret);
> > > + goto eclkget;
> > > + }
> > > + clk_enable(host->hclk);
> > > + host->clk = clk_get_rate(host->hclk);
> > > + mmc->f_max = host->clk / 2;
> > > + mmc->f_min = host->clk / 512;
> > > +
> > > ret = pm_runtime_resume(&pdev->dev);
> > > if (ret < 0)
> > > goto eresume;
> > >
> > > INIT_DELAYED_WORK(&host->timeout_work, mmcif_timeout_work);
> > >
> > > + sh_mmcif_sync_reset(host);
> > > sh_mmcif_writel(host->addr, MMCIF_CE_INT_MASK, MASK_ALL);
> > >
> > > ret = request_threaded_irq(irq[0], sh_mmcif_intr, sh_mmcif_irqt, 0,
> > > "sh_mmc:error", host);
> > > @@ -1330,6 +1333,7 @@ static int __devinit sh_mmcif_probe(struct
> > > platform_device *pdev)
> > > goto ereqirq1;
> > > }
> > >
> > > + clk_disable(host->hclk);
> > > ret = mmc_add_host(mmc);
> > > if (ret < 0)
> > > goto emmcaddh;
> >
> > Could you clarify the purpose of two hunks above.
> > They seem to move code down in sh_mmcif_probe().
> > Is this related to the call to pm_runtime_enable() ?
>
> The sh_mmcif_sync_reset() call accesses the hardware so it only makes
> sense after the hardware has been resumed. Moving the clk_enable() call
> down improves consistency by grouping clock and runtime PM code together
> during probe() similar to other paths.
Thanks.
Reviewed-by: Simon Horman
--
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
Re: [PATCH 5/5 v4] mmc: sh_mmcif: add regulator support
On Wed, Jun 20, 2012 at 08:38:27AM +0200, Guennadi Liakhovetski wrote:
> On Wed, 20 Jun 2012, Simon Horman wrote:
>
> > Hi Guennadi,
> >
> > On Wed, Jun 13, 2012 at 03:37:31PM +0200, Guennadi Liakhovetski wrote:
> > > Add regulator support to the sh_mmcif driver, but also preserve the
> > > current
> > > power-callback.
> > >
> > > Signed-off-by: Guennadi Liakhovetski
> > > ---
> > >
> > > v4: update to the new mmc_regulator_get_supply() function
> > >
> > > drivers/mmc/host/sh_mmcif.c | 38 +++---
> > > 1 files changed, 31 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> > > index 4680276..204bced 100644
> > > --- a/drivers/mmc/host/sh_mmcif.c
> > > +++ b/drivers/mmc/host/sh_mmcif.c
> > > @@ -923,10 +923,22 @@ static int sh_mmcif_clk_update(struct sh_mmcif_host
> > > *host)
> > > return ret;
> > > }
> > >
> > > +static void sh_mmcif_set_power(struct sh_mmcif_host *host, struct
> > > mmc_ios *ios)
> > > +{
> > > + struct sh_mmcif_plat_data *pd = host->pd->dev.platform_data;
> > > + struct mmc_host *mmc = host->mmc;
> > > +
> > > + if (pd->set_pwr)
> > > + pd->set_pwr(host->pd, ios->power_mode != MMC_POWER_OFF);
> > > + if (!IS_ERR(mmc->supply.vmmc))
> > > + /* Errors ignored... */
> > > + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc,
> > > + ios->power_mode ? ios->vdd : 0);
> > > +}
> > > +
> > > static void sh_mmcif_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> > > {
> > > struct sh_mmcif_host *host = mmc_priv(mmc);
> > > - struct sh_mmcif_plat_data *p = host->pd->dev.platform_data;
> > > unsigned long flags;
> > >
> > > spin_lock_irqsave(&host->lock, flags);
> > > @@ -944,6 +956,7 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc,
> > > struct mmc_ios *ios)
> > > sh_mmcif_request_dma(host, host->pd->dev.platform_data);
> > > host->card_present = true;
> > > }
> > > + sh_mmcif_set_power(host, ios);
> > > } else if (ios->power_mode == MMC_POWER_OFF || !ios->clock) {
> > > /* clock stop */
> > > sh_mmcif_clock_control(host, 0);
> > > @@ -957,8 +970,8 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc,
> > > struct mmc_ios *ios)
> > > pm_runtime_put(&host->pd->dev);
> > > clk_disable(host->hclk);
> > > host->power = false;
> > > - if (p->set_pwr && ios->power_mode == MMC_POWER_OFF)
> > > - p->set_pwr(host->pd, 0);
> > > + if (ios->power_mode == MMC_POWER_OFF)
> > > + sh_mmcif_set_power(host, ios);
> > > }
> > > host->state = STATE_IDLE;
> > > return;
> > > @@ -966,8 +979,6 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc,
> > > struct mmc_ios *ios)
> > >
> > > if (ios->clock) {
> > > if (!host->power) {
> > > - if (p->set_pwr)
> > > - p->set_pwr(host->pd, ios->power_mode);
> > > sh_mmcif_clk_update(host);
> > > pm_runtime_get_sync(&host->pd->dev);
> > > host->power = true;
> >
> > It is unclear to me how this hunk relates to the description of the
> > change in the changelog.
>
> Right, it is probably not very obvious. We could extend the description
> with something like:
>
> Also note, that the card power is not switched off during clock gating
> periods, hence there's no need to power it on every time the card is
> re-activated.
Thanks, that would make things much clearer.
Reviewed-by: Simon Horman
--
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
Re: [PATCH 4/5 v4] mmc: sh_mmcif: remove redundant .down_pwr() callback
On Wed, Jun 20, 2012 at 08:19:26AM +0200, Guennadi Liakhovetski wrote: > Hi Simon > > On Wed, 20 Jun 2012, Simon Horman wrote: > > > On Wed, Jun 13, 2012 at 03:37:27PM +0200, Guennadi Liakhovetski wrote: > > > >From the original version of sh_mmcif the .set_pwr() callback has only > > > >been > > > used to turn the card's power on, and the .down_pwr() callback has been > > > used to turn it off. .set_pwr() can be used for both these tasks, which is > > > also how it is implemented by the only user of this API: the SH7724 ecovec > > > board. > > > > > > Signed-off-by: Guennadi Liakhovetski > > > > Reviewed-by: Simon Horman > > > > Do you also intend to post patches for the following? > > > > * Remove mmcif_down_pwr from ecovec > > * Remove down_pwr from struct sh_mmcif_plat_data > > Sure, since these patches depend on each other we have to make sure this > one gets applied first. The other two then can be applied in their time, > they do not affect the functionality any more. Thanks, I agree entirely. -- 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
Re: [PATCH] mmc: sh_mmcif: Support MMC_SLEEP_AWAKE command
On Wed, Jun 13, 2012 at 09:39:56AM +0200, Laurent Pinchart wrote: > Hi Simon, > > On Wednesday 13 June 2012 10:12:01 Simon Horman wrote: > > On Tue, Jun 12, 2012 at 10:56:09PM +0200, Laurent Pinchart wrote: > > > The MMC_SLEEP_AWAKE and SD_IO_SEND_OP_COND commands share the same > > > opcode. SD_IO_SEND_OP_COND isn't supported by the SH MMCIF, but > > > MMC_SLEEP_AWAKE is. Discriminate between the two commands using the > > > command flags, and reject SD_IO_SEND_OP_COND only. > > > > > > Signed-off-by: Laurent Pinchart > > > --- > > > > > > drivers/mmc/host/sh_mmcif.c | 14 -- > > > 1 files changed, 4 insertions(+), 10 deletions(-) > > > > > > Not supporting the MMC_SLEEP_AWAKE command makes system suspend fail if an > > > MMC or eMMC device supporting sleep/wake is connected. The issue has been > > > first noticed on the Armadillo 800 EVA board. > > > > Hi Laurent, > > > > Do you have a test-case for this? > > echo mem > /sys/power/state on Armadillo 800 EVA was my test case. It failed > without the patch, and succeeds with it. I'm not having much luck with or without your patch. # echo mem > /sys/power/state echo: write error: No such device I am using 3.5-rc3. With the armadillo default config + EXT3 + SUSPEND. Perhaps I am missing some options? > > Also, did you check to make sure that the Mackerel still works? > > Yes it still works. However, I have no way to test the MMC_SLEEP_AWAKE > command > on the Mackerel board, as my MMC card doesn't support it (on the Armadillo > the > eMMC chip supports the MMC_SLEEP_AWAKE command). > > BTW, I wonder whether the current implementation is really the best one. If > the hardware doesn't support SD/SDIO commands, instead of intercepting > commands and rejecting the ones used by SD/SDIO at probe time, wouldn't it be > better for host drivers to tell that they don't support SD and/or SDIO using > flags in the mmc_host structure ? I don't have any strong thoughts on this but your approach does sound interesting. -- 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
[PATCH] mmc: sh_mmcif: mmc->f_max heuristic
In 930f152cc9998388031af577843baae572ac8ab6 ("mmc: sh_mmcif: mmc->f_max
should be half of the bus clock") I changed the setting of mmc->f_max from
the bus clock to half the bus clock based on the manual for the sh7372 SoC.
Inspection of sh_mmcif_clock_control() reveals that it relies on
mmc->f_max being set to the bus speed in order to enable the supplementary
clock, a feature that does not exist on the sh7372.
Armed with this information implement the following heuristic for setting
mmc->f_max:
* Use bus clock if the supplementary clock feature is present
- Assumed to work on the sh7757lcr board, the only board present
in the tree which has the feature.
* Use half the bus clock otherwise
- As per the documentation for the sh7372 SoC.
Reported-by: Magnus Damm
Cc: Guennadi Liakhovetski
Signed-off-by: Simon Horman
---
Regression information:
It seems likely that this resolves a regression for the sh7757lcr which was
introduced by 930f152cc9998388031af577843baae572ac8ab6 ("mmc: sh_mmcif:
mmc->f_max should be half of the bus clock"). However, although I have the
hardware in question I am unsure how to exercise the code to test if there
is a problem or not.
930f152cc9998388031af577843baae572ac8ab6 was added between the 3.3 and 3.4.
Dependency information:
This patch is based on Guennadi Liakhovetski's recent series
"[PATCH 0/5 v4] mmc: sh_mmcif: clock and power updates". It should
be trivial to rebase it on 3.5-rc3.
---
drivers/mmc/host/sh_mmcif.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index f0f518b..dfcfe83 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -919,10 +919,11 @@ static void sh_mmcif_request(struct mmc_host *mmc, struct
mmc_request *mrq)
static int sh_mmcif_clk_update(struct sh_mmcif_host *host)
{
int ret = clk_enable(host->hclk);
+ struct sh_mmcif_plat_data *p = host->pd->dev.platform_data;
if (!ret) {
host->clk = clk_get_rate(host->hclk);
- host->mmc->f_max = host->clk / 2;
+ host->mmc->f_max = p->sup_pclk ? host->clk : host->clk / 2;
host->mmc->f_min = host->clk / 512;
}
--
1.7.10.2.484.gcd07cc5
--
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
Re: [PATCH 3/5 v4] mmc: sh_mmcif: re-read the clock frequency every time the clock is turned on
On Wed, Jun 13, 2012 at 03:37:23PM +0200, Guennadi Liakhovetski wrote: > With aggressive clock gating the clock can be disabled during interface > inactivity. During this time its frequency can be changed by another its > user. Therefore when the interface is activated again and the clock is > re-enabled, its frequency has to be re-read. > > Signed-off-by: Guennadi Liakhovetski Reviewed-by: Simon Horman -- 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
Re: [PATCH 2/5 v4] mmc: sh_mmcif: fix clock management
Hi Guennadi,
On Wed, Jun 13, 2012 at 03:37:19PM +0200, Guennadi Liakhovetski wrote:
> Regardless, whether the MMC bus clock is the same, as the PM clock on this
> specific interface, it has to be managed separately. Its proper management
> should also include enabling and disabling of the clock, whenever the
> interface is becoming active or going idle respectively.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
> drivers/mmc/host/sh_mmcif.c | 46 +-
> 1 files changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index d6ffb05..6a93b04 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -942,6 +942,7 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc, struct
> mmc_ios *ios)
> }
> if (host->power) {
> pm_runtime_put(&host->pd->dev);
> + clk_disable(host->hclk);
> host->power = false;
> if (p->down_pwr && ios->power_mode == MMC_POWER_OFF)
> p->down_pwr(host->pd);
> @@ -954,6 +955,7 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc, struct
> mmc_ios *ios)
> if (!host->power) {
> if (p->set_pwr)
> p->set_pwr(host->pd, ios->power_mode);
> + clk_enable(host->hclk);
> pm_runtime_get_sync(&host->pd->dev);
> host->power = true;
> sh_mmcif_sync_reset(host);
> @@ -1278,22 +1280,11 @@ static int __devinit sh_mmcif_probe(struct
> platform_device *pdev)
> host->addr = reg;
> host->timeout = 1000;
>
> - snprintf(clk_name, sizeof(clk_name), "mmc%d", pdev->id);
> - host->hclk = clk_get(&pdev->dev, clk_name);
> - if (IS_ERR(host->hclk)) {
> - dev_err(&pdev->dev, "cannot get clock \"%s\"\n", clk_name);
> - ret = PTR_ERR(host->hclk);
> - goto eclkget;
> - }
> - clk_enable(host->hclk);
> - host->clk = clk_get_rate(host->hclk);
> host->pd = pdev;
>
> spin_lock_init(&host->lock);
>
> mmc->ops = &sh_mmcif_ops;
> - mmc->f_max = host->clk / 2;
> - mmc->f_min = host->clk / 512;
> if (pd->ocr)
> mmc->ocr_avail = pd->ocr;
> mmc->caps = MMC_CAP_MMC_HIGHSPEED;
> @@ -1305,18 +1296,30 @@ static int __devinit sh_mmcif_probe(struct
> platform_device *pdev)
> mmc->max_blk_count = mmc->max_req_size / mmc->max_blk_size;
> mmc->max_seg_size = mmc->max_req_size;
>
> - sh_mmcif_sync_reset(host);
> platform_set_drvdata(pdev, host);
>
> pm_runtime_enable(&pdev->dev);
> host->power = false;
>
> + snprintf(clk_name, sizeof(clk_name), "mmc%d", pdev->id);
> + host->hclk = clk_get(&pdev->dev, clk_name);
> + if (IS_ERR(host->hclk)) {
> + ret = PTR_ERR(host->hclk);
> + dev_err(&pdev->dev, "cannot get clock \"%s\": %d\n", clk_name,
> ret);
> + goto eclkget;
> + }
> + clk_enable(host->hclk);
> + host->clk = clk_get_rate(host->hclk);
> + mmc->f_max = host->clk / 2;
> + mmc->f_min = host->clk / 512;
> +
> ret = pm_runtime_resume(&pdev->dev);
> if (ret < 0)
> goto eresume;
>
> INIT_DELAYED_WORK(&host->timeout_work, mmcif_timeout_work);
>
> + sh_mmcif_sync_reset(host);
> sh_mmcif_writel(host->addr, MMCIF_CE_INT_MASK, MASK_ALL);
>
> ret = request_threaded_irq(irq[0], sh_mmcif_intr, sh_mmcif_irqt, 0,
> "sh_mmc:error", host);
> @@ -1330,6 +1333,7 @@ static int __devinit sh_mmcif_probe(struct
> platform_device *pdev)
> goto ereqirq1;
> }
>
> + clk_disable(host->hclk);
> ret = mmc_add_host(mmc);
> if (ret < 0)
> goto emmcaddh;
Could you clarify the purpose of two hunks above.
They seem to move code down in sh_mmcif_probe().
Is this related to the call to pm_runtime_enable() ?
> @@ -1348,9 +1352,10 @@ ereqirq1:
> ereqirq0:
> pm_runtime_suspend(&pdev->dev);
> eresume:
> - pm_runtime_disable(&pdev->dev);
> clk_disable(host->hclk);
> + clk_put(host->hclk);
> eclkget:
> + pm_runtime_disable(&pdev->dev);
> mmc_free_host(mmc);
> ealloch:
> iounmap(reg);
> @@ -1363,6 +1368,7 @@ static int __devexit sh_mmcif_remove(struct
> platform_device *pdev)
> int irq[2];
>
> host->dying = true;
> + clk_enable(host->hclk);
> pm_runtime_get_sync(&pdev->dev);
>
> dev_pm_qos_hide_latency_limit(&pdev->dev);
> @@ -1388,9 +1394,9 @@ static int __devexit sh_mmcif_remove(struct
> platform_device *pdev)
>
> platform_set_drvdata(pdev, NULL);
>
> - clk_disable(host->hclk);
> mmc_free_host(host->mmc);
> pm_runtime_put_sync(&pdev->dev);
> + clk_disable(host->hclk);
> pm_runtime_disable(&pdev->dev);
>
Re: [PATCH 5/5 v4] mmc: sh_mmcif: add regulator support
Hi Guennadi,
On Wed, Jun 13, 2012 at 03:37:31PM +0200, Guennadi Liakhovetski wrote:
> Add regulator support to the sh_mmcif driver, but also preserve the current
> power-callback.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> v4: update to the new mmc_regulator_get_supply() function
>
> drivers/mmc/host/sh_mmcif.c | 38 +++---
> 1 files changed, 31 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index 4680276..204bced 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -923,10 +923,22 @@ static int sh_mmcif_clk_update(struct sh_mmcif_host
> *host)
> return ret;
> }
>
> +static void sh_mmcif_set_power(struct sh_mmcif_host *host, struct mmc_ios
> *ios)
> +{
> + struct sh_mmcif_plat_data *pd = host->pd->dev.platform_data;
> + struct mmc_host *mmc = host->mmc;
> +
> + if (pd->set_pwr)
> + pd->set_pwr(host->pd, ios->power_mode != MMC_POWER_OFF);
> + if (!IS_ERR(mmc->supply.vmmc))
> + /* Errors ignored... */
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc,
> + ios->power_mode ? ios->vdd : 0);
> +}
> +
> static void sh_mmcif_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> {
> struct sh_mmcif_host *host = mmc_priv(mmc);
> - struct sh_mmcif_plat_data *p = host->pd->dev.platform_data;
> unsigned long flags;
>
> spin_lock_irqsave(&host->lock, flags);
> @@ -944,6 +956,7 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc, struct
> mmc_ios *ios)
> sh_mmcif_request_dma(host, host->pd->dev.platform_data);
> host->card_present = true;
> }
> + sh_mmcif_set_power(host, ios);
> } else if (ios->power_mode == MMC_POWER_OFF || !ios->clock) {
> /* clock stop */
> sh_mmcif_clock_control(host, 0);
> @@ -957,8 +970,8 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc, struct
> mmc_ios *ios)
> pm_runtime_put(&host->pd->dev);
> clk_disable(host->hclk);
> host->power = false;
> - if (p->set_pwr && ios->power_mode == MMC_POWER_OFF)
> - p->set_pwr(host->pd, 0);
> + if (ios->power_mode == MMC_POWER_OFF)
> + sh_mmcif_set_power(host, ios);
> }
> host->state = STATE_IDLE;
> return;
> @@ -966,8 +979,6 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc, struct
> mmc_ios *ios)
>
> if (ios->clock) {
> if (!host->power) {
> - if (p->set_pwr)
> - p->set_pwr(host->pd, ios->power_mode);
> sh_mmcif_clk_update(host);
> pm_runtime_get_sync(&host->pd->dev);
> host->power = true;
It is unclear to me how this hunk relates to the description of the
change in the changelog.
> @@ -1251,6 +1262,19 @@ static void mmcif_timeout_work(struct work_struct
> *work)
> mmc_request_done(host->mmc, mrq);
> }
>
> +static void sh_mmcif_init_ocr(struct sh_mmcif_host *host)
> +{
> + struct sh_mmcif_plat_data *pd = host->pd->dev.platform_data;
> + struct mmc_host *mmc = host->mmc;
> +
> + mmc_regulator_get_supply(mmc);
> +
> + if (!mmc->ocr_avail)
> + mmc->ocr_avail = pd->ocr;
> + else if (pd->ocr)
> + dev_warn(mmc_dev(mmc), "Platform OCR mask is ignored\n");
> +}
> +
> static int __devinit sh_mmcif_probe(struct platform_device *pdev)
> {
> int ret = 0, irq[2];
> @@ -1298,8 +1322,8 @@ static int __devinit sh_mmcif_probe(struct
> platform_device *pdev)
> spin_lock_init(&host->lock);
>
> mmc->ops = &sh_mmcif_ops;
> - if (pd->ocr)
> - mmc->ocr_avail = pd->ocr;
> + sh_mmcif_init_ocr(host);
> +
> mmc->caps = MMC_CAP_MMC_HIGHSPEED;
> if (pd->caps)
> mmc->caps |= pd->caps;
> --
> 1.7.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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
Re: [PATCH 1/5 v4] mmc: sh_mmcif: simplify and use meaningful label names in error-handling
On Wed, Jun 13, 2012 at 03:37:15PM +0200, Guennadi Liakhovetski wrote:
> A check for NULL platform data can be conveniently made in the very
> beginning of probing. Replace numbered error-handling labels in .probe()
> with meaningful names to make any future reorganisation simpler.
>
> Signed-off-by: Guennadi Liakhovetski
Reviewed-by: Simon Horman
> ---
> drivers/mmc/host/sh_mmcif.c | 41 -
> 1 files changed, 20 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index e32da11..d6ffb05 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -1241,11 +1241,16 @@ static int __devinit sh_mmcif_probe(struct
> platform_device *pdev)
> int ret = 0, irq[2];
> struct mmc_host *mmc;
> struct sh_mmcif_host *host;
> - struct sh_mmcif_plat_data *pd;
> + struct sh_mmcif_plat_data *pd = pdev->dev.platform_data;
> struct resource *res;
> void __iomem *reg;
> char clk_name[8];
>
> + if (!pd) {
> + dev_err(&pdev->dev, "sh_mmcif plat data error.\n");
> + return -ENXIO;
> + }
> +
> irq[0] = platform_get_irq(pdev, 0);
> irq[1] = platform_get_irq(pdev, 1);
> if (irq[0] < 0 || irq[1] < 0) {
> @@ -1262,16 +1267,11 @@ static int __devinit sh_mmcif_probe(struct
> platform_device *pdev)
> dev_err(&pdev->dev, "ioremap error.\n");
> return -ENOMEM;
> }
> - pd = pdev->dev.platform_data;
> - if (!pd) {
> - dev_err(&pdev->dev, "sh_mmcif plat data error.\n");
> - ret = -ENXIO;
> - goto clean_up;
> - }
> +
> mmc = mmc_alloc_host(sizeof(struct sh_mmcif_host), &pdev->dev);
> if (!mmc) {
> ret = -ENOMEM;
> - goto clean_up;
> + goto ealloch;
> }
> host= mmc_priv(mmc);
> host->mmc = mmc;
> @@ -1283,7 +1283,7 @@ static int __devinit sh_mmcif_probe(struct
> platform_device *pdev)
> if (IS_ERR(host->hclk)) {
> dev_err(&pdev->dev, "cannot get clock \"%s\"\n", clk_name);
> ret = PTR_ERR(host->hclk);
> - goto clean_up1;
> + goto eclkget;
> }
> clk_enable(host->hclk);
> host->clk = clk_get_rate(host->hclk);
> @@ -1313,7 +1313,7 @@ static int __devinit sh_mmcif_probe(struct
> platform_device *pdev)
>
> ret = pm_runtime_resume(&pdev->dev);
> if (ret < 0)
> - goto clean_up2;
> + goto eresume;
>
> INIT_DELAYED_WORK(&host->timeout_work, mmcif_timeout_work);
>
> @@ -1322,17 +1322,17 @@ static int __devinit sh_mmcif_probe(struct
> platform_device *pdev)
> ret = request_threaded_irq(irq[0], sh_mmcif_intr, sh_mmcif_irqt, 0,
> "sh_mmc:error", host);
> if (ret) {
> dev_err(&pdev->dev, "request_irq error (sh_mmc:error)\n");
> - goto clean_up3;
> + goto ereqirq0;
> }
> ret = request_threaded_irq(irq[1], sh_mmcif_intr, sh_mmcif_irqt, 0,
> "sh_mmc:int", host);
> if (ret) {
> dev_err(&pdev->dev, "request_irq error (sh_mmc:int)\n");
> - goto clean_up4;
> + goto ereqirq1;
> }
>
> ret = mmc_add_host(mmc);
> if (ret < 0)
> - goto clean_up5;
> + goto emmcaddh;
>
> dev_pm_qos_expose_latency_limit(&pdev->dev, 100);
>
> @@ -1341,20 +1341,19 @@ static int __devinit sh_mmcif_probe(struct
> platform_device *pdev)
> sh_mmcif_readl(host->addr, MMCIF_CE_VERSION) & 0x);
> return ret;
>
> -clean_up5:
> +emmcaddh:
> free_irq(irq[1], host);
> -clean_up4:
> +ereqirq1:
> free_irq(irq[0], host);
> -clean_up3:
> +ereqirq0:
> pm_runtime_suspend(&pdev->dev);
> -clean_up2:
> +eresume:
> pm_runtime_disable(&pdev->dev);
> clk_disable(host->hclk);
> -clean_up1:
> +eclkget:
> mmc_free_host(mmc);
> -clean_up:
> - if (reg)
> - iounmap(reg);
It looks like this if (reg) was redundant: reg was always non-NULL if
this path is executed. Good riddance :)
> +ealloch:
> + iounmap(reg);
> return ret;
> }
--
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
Re: [PATCH 4/5 v4] mmc: sh_mmcif: remove redundant .down_pwr() callback
On Wed, Jun 13, 2012 at 03:37:27PM +0200, Guennadi Liakhovetski wrote: > >From the original version of sh_mmcif the .set_pwr() callback has only been > used to turn the card's power on, and the .down_pwr() callback has been > used to turn it off. .set_pwr() can be used for both these tasks, which is > also how it is implemented by the only user of this API: the SH7724 ecovec > board. > > Signed-off-by: Guennadi Liakhovetski Reviewed-by: Simon Horman Do you also intend to post patches for the following? * Remove mmcif_down_pwr from ecovec * Remove down_pwr from struct sh_mmcif_plat_data -- 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
Re: [PATCH v2] mmc: tmio: Don't access hardware registers after stopping clocks
On Wed, Jun 13, 2012 at 09:11:13PM -0700, Kuninori Morimoto wrote: > > Laurent Pinchart wrote: > > > > The tmio_mmc_set_ios() function configures the MMC power, clock and bus > > width. When the mmc core requests the driver to power off the card, we > > inform runtime PM, that the controller can be suspended. This can lead > > to the MSTP clock being turned off. > > > > Writing to any 16-bit hardware registers with the MSTP clock off leads > > to timeouts and errors being printed to the kernel log. This can occur > > both when stopping the MMC clock and when configuring the bus width. > > > > To fix this, stop the MMC clock before calling put_runtime_pm(), and > > skip bus width configuration when power is off. > > > > Signed-off-by: Laurent Pinchart > > --- > > This patch solved kzm9g MicroSD hang-up issue. > > Tested-by: Kuninori Morimoto Yes, it solves that issue for me too. Tested-by: Simon Horman -- 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
Re: [PATCH v2] mmc: tmio: Don't access hardware registers after stopping clocks
On Tue, Jun 12, 2012 at 11:29:35PM +0200, Laurent Pinchart wrote: > The tmio_mmc_set_ios() function configures the MMC power, clock and bus > width. When the mmc core requests the driver to power off the card, we > inform runtime PM, that the controller can be suspended. This can lead > to the MSTP clock being turned off. > > Writing to any 16-bit hardware registers with the MSTP clock off leads > to timeouts and errors being printed to the kernel log. This can occur > both when stopping the MMC clock and when configuring the bus width. > > To fix this, stop the MMC clock before calling put_runtime_pm(), and > skip bus width configuration when power is off. > > Signed-off-by: Laurent Pinchart Hi Laurent, could you let me know if there is a (simple :) way for me to exercise this? > --- > drivers/mmc/host/tmio_mmc_pio.c | 18 ++ > 1 files changed, 10 insertions(+), 8 deletions(-) -- 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
Re: [PATCH] mmc: sh_mmcif: Support MMC_SLEEP_AWAKE command
On Tue, Jun 12, 2012 at 10:56:09PM +0200, Laurent Pinchart wrote: > The MMC_SLEEP_AWAKE and SD_IO_SEND_OP_COND commands share the same > opcode. SD_IO_SEND_OP_COND isn't supported by the SH MMCIF, but > MMC_SLEEP_AWAKE is. Discriminate between the two commands using the > command flags, and reject SD_IO_SEND_OP_COND only. > > Signed-off-by: Laurent Pinchart > --- > drivers/mmc/host/sh_mmcif.c | 14 -- > 1 files changed, 4 insertions(+), 10 deletions(-) > > Not supporting the MMC_SLEEP_AWAKE command makes system suspend fail if an MMC > or eMMC device supporting sleep/wake is connected. The issue has been first > noticed on the Armadillo 800 EVA board. Hi Laurent, Do you have a test-case for this? Also, did you check to make sure that the Mackerel still works? -- 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
