* [PATCH v2 1/6] mmc: add define for R1 response without CRC
From: Wolfram Sang @ 2016-09-19 12:49 UTC (permalink / raw)
To: linux-mmc; +Cc: linux-renesas-soc, Simon Horman, Dirk Behme, Wolfram Sang
In-Reply-To: <20160919124921.8172-1-wsa+renesas@sang-engineering.com>
The core uses it for polling. Give drivers a proper define handle this
case like for other response types.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
include/linux/mmc/core.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index b01e77de1a74de..4caee099b63a28 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -55,6 +55,9 @@ struct mmc_command {
#define MMC_RSP_R6 (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE)
#define MMC_RSP_R7 (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE)
+/* Can be used by core to poll after switch to MMC HS mode */
+#define MMC_RSP_R1_NO_CRC (MMC_RSP_PRESENT|MMC_RSP_OPCODE)
+
#define mmc_resp_type(cmd) ((cmd)->flags & (MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY|MMC_RSP_OPCODE))
/*
--
2.9.3
^ permalink raw reply related
* [PATCH v2 5/6] arm64: dts: r8a7795: salvator: enable on-board eMMC
From: Wolfram Sang @ 2016-09-19 12:49 UTC (permalink / raw)
To: linux-mmc; +Cc: linux-renesas-soc, Simon Horman, Dirk Behme, Wolfram Sang
In-Reply-To: <20160919124921.8172-1-wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 8964b1ea3cea69..7780d02f716a34 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -62,6 +62,24 @@
clock-frequency = <24576000>;
};
+ reg_1p8v: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
vcc_sdhi0: regulator-vcc-sdhi0 {
compatible = "regulator-fixed";
@@ -246,6 +264,18 @@
power-source = <1800>;
};
+ sdhi2_pins: sd2 {
+ groups = "sdhi2_data8", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <3300>;
+ };
+
+ sdhi2_pins_uhs: sd2 {
+ groups = "sdhi2_data8", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <1800>;
+ };
+
sdhi3_pins: sd3 {
groups = "sdhi3_data4", "sdhi3_ctrl";
function = "sdhi3";
@@ -398,6 +428,19 @@
status = "okay";
};
+&sdhi2 {
+ /* used for on-board 8bit eMMC */
+ pinctrl-0 = <&sdhi2_pins>;
+ pinctrl-1 = <&sdhi2_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_1p8v>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
&sdhi3 {
pinctrl-0 = <&sdhi3_pins>;
pinctrl-1 = <&sdhi3_pins_uhs>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/6] mmc: rtsx_usb: use new macro for R1 without CRC
From: Wolfram Sang @ 2016-09-19 12:49 UTC (permalink / raw)
To: linux-mmc; +Cc: linux-renesas-soc, Simon Horman, Dirk Behme, Wolfram Sang
In-Reply-To: <20160919124921.8172-1-wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
drivers/mmc/host/rtsx_usb_sdmmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c b/drivers/mmc/host/rtsx_usb_sdmmc.c
index 6c71fc9f76c7ec..4106295527b9d0 100644
--- a/drivers/mmc/host/rtsx_usb_sdmmc.c
+++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
@@ -324,7 +324,7 @@ static void sd_send_cmd_get_rsp(struct rtsx_usb_sdmmc *host,
case MMC_RSP_R1:
rsp_type = SD_RSP_TYPE_R1;
break;
- case MMC_RSP_R1 & ~MMC_RSP_CRC:
+ case MMC_RSP_R1_NO_CRC:
rsp_type = SD_RSP_TYPE_R1 | SD_NO_CHECK_CRC7;
break;
case MMC_RSP_R1B:
--
2.9.3
^ permalink raw reply related
* [PATCH v2 0/6] tmio: add support for eMMC with 8 bit bus width
From: Wolfram Sang @ 2016-09-19 12:49 UTC (permalink / raw)
To: linux-mmc; +Cc: linux-renesas-soc, Simon Horman, Dirk Behme, Wolfram Sang
This series enables SDHI instances on R-Car Gen3 to access eMMC with 8 bit bus
width. I think the patch descriptions speak for themselves.
I decided to not protect this new feature with a flag because it needs
specifically to be enabled by setting the bus width to 8. No legacy platform
does that.
Note that I decided to use the pattern that pinctrl-0 is 3.3v and
pinctrl-1 is 1.8v, although the eMMC is fixed at 1.8v. I tried a few ways to
only use pinctrl-0 being 1.8v here, but they all ended up to be confusing for
users IMO, so I sticked to the most consistent solution after all.
Changes since V1:
* merged the two distinct series (drivers + DTS) into one: patches 1-4 are for
Ulf, I will ping Simon for patches 5+6 when the time is ready.
* DTS now contains 'non-removable' and we have a software workaround for now.
These patches are based on top of Simon's sdr104-v7 patches but they apply to
current mmc/next as well. A branch can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/topic/sdhi-8bit-emmc
Please review, comment, apply...
Wolfram
Wolfram Sang (6):
mmc: add define for R1 response without CRC
mmc: rtsx_pci: use new macro for R1 without CRC
mmc: rtsx_usb: use new macro for R1 without CRC
mmc: tmio: add eMMC support
arm64: dts: r8a7795: salvator: enable on-board eMMC
arm64: dts: r8a7796: salvator: enable on board eMMC
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 43 +++++++++++++++++++++
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 44 +++++++++++++++++++++-
drivers/mmc/host/rtsx_pci_sdmmc.c | 2 +-
drivers/mmc/host/rtsx_usb_sdmmc.c | 2 +-
drivers/mmc/host/tmio_mmc.h | 3 ++
drivers/mmc/host/tmio_mmc_pio.c | 38 +++++++++++++------
include/linux/mmc/core.h | 3 ++
7 files changed, 120 insertions(+), 15 deletions(-)
--
2.9.3
^ permalink raw reply
* RE: [PATCH v6 0/9] Replay Protected Memory Block (RPMB) subsystem
From: Winkler, Tomas @ 2016-09-19 12:17 UTC (permalink / raw)
To: Greg Kroah-Hartman, Ulf Hansson, Hunter, Adrian, James Bottomley,
Martin K . Petersen, Vinayak Holikatti, Andy Lutomirski,
Arve Hj?nnev?g, Michael Ryleev, Joao Pinto, Christoph Hellwig,
Yaniv Gardi
Cc: Avri Altman, linux-kernel@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-scsi@vger.kernel.org
In-Reply-To: <1473772984-17562-1-git-send-email-tomas.winkler@intel.com>
\
> Subject: [PATCH v6 0/9] Replay Protected Memory Block (RPMB) subsystem
>
>
> Few storage technologies such is EMMC, UFS, and NVMe support RPMB
> hardware partition with common protocol and frame layout.
> The RPMB partition cannot be accessed via standard block layer, but by a set
> of specific commands: WRITE, READ, GET_WRITE_COUNTER, and
> PROGRAM_KEY.
> Such a partition provides authenticated and replay protected access, hence
> suitable as a secure storage.
>
> The RPMB layer aims to provide in-kernel API for Trusted Execution
> Environment (TEE) devices that are capable to securely compute block frame
> signature. In case a TEE device wish to store a replay protected data, it
> creates an RPMB frame with requested data and computes HMAC of the
> frame, then it requests the storage device via RPMB layer to store the data.
>
> The layer provides two APIs, for rpmb_req_cmd() for issuing one of RPMB
> specific commands and rpmb_seq_cmd() for issuing of raw RPMB protocol
> frames, which is close to the functionality provided by emmc multi ioctl
> interface.
>
> A TEE driver can claim the RPMB interface, for example, via
> class_interface_register ().
>
> A storage device registers its RPMB hardware (eMMC) partition or RPMB W-
> LUN (UFS) with the RPMB layer providing an implementation for
> rpmb_seq_cmd() handler. The interface enables sending sequence of RPMB
> standard frames.
>
> A parallel user space API is provided via /dev/rpmbX character device with
> two IOCTL commands.
> Simplified one, RPMB_IOC_REQ_CMD, were read result cycles is performed
> by the framework on behalf the user and second, RPMB_IOC_SEQ_CMD
> where the whole RPMB sequence, including RESULT_READ is supplied by the
> caller.
> The latter is intended for easier adjusting of the applications that use
> MMC_IOC_MULTI_CMD ioctl, such as
> https://android.googlesource.com/trusty/app/storage/
>
> There is a also sample tool under tools/rpmb/ directory that exercises these
> interfaces and a simulation device that implements the device part.
>
> The code is also available from:
>
> https://github.com/tomasbw/linux-mei.git rpmb
>
Greg, can you please check if this series has addressed all your comments.
Are there are any more items that preventing it from merging?
Thanks
Tomas
^ permalink raw reply
* Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]
From: Ulf Hansson @ 2016-09-19 10:10 UTC (permalink / raw)
To: Alan Stern; +Cc: Ritesh Raj Sarraf, USB list, linux-mmc
In-Reply-To: <Pine.LNX.4.44L0.1609172131120.698-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
On 18 September 2016 at 03:42, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
> On Sat, 17 Sep 2016, Ritesh Raj Sarraf wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> Hello Alan,
>>
>>
>> On Fri, 2016-09-16 at 17:40 -0400, Alan Stern wrote:
>> > We're still getting runtime suspends, but now at 2-second intervals.
>> > This is partly because the driver isn't calling
>> > pm_runtime_mark_last_busy(), but there may be more to it. The 2-second
>> > period is the default autosuspend timeout for USB devices. However, I
>> > don't see the activity that rtsx_usb_get_card_status() should produce
>> > when rtsx_usb_suspend() runs; I don't know why not.
>> >
>> > We're also getting occasional I/O attempts while the device is
>> > suspended. They must be on some other pathway, not the one fixed by
>> > the patch above. Let's see if we can find out just where they come
>> > from.
>> >
>> > Ritesh, please try applying this patch on top of the previous one. It
>> > will produce output in the kernel log whenever these bad I/O attempts
>> > occur. Also, enable dynamic debugging for the rtsx_usb driver:
>> >
>>
>> Please find links to the usbmon trace and the kernel trace.
>>
>> https://people.debian.org/~rrs/tmp/4.8.0-rc6ulf1alan1+.kern.log
>> https://people.debian.org/~rrs/tmp/usb-4.8.0-rc6ulf1alan1+.log.gz
>
> Well, this is pretty clear:
>
> Sep 17 15:55:52 learner kernel: CPU: 1 PID: 535 Comm: rtsx_usb_ms_1 Tainted: G U 4.8.0-rc6ulf1alan1+ #19
> Sep 17 15:55:52 learner kernel: Hardware name: LENOVO 20344/INVALID, BIOS 96CN31WW(V1.17) 07/21/2015
> Sep 17 15:55:52 learner kernel: 0000000000000000 ffffffff81314be5 ffff8802476746c0 0000000002400000
> Sep 17 15:55:52 learner kernel: ffffffffa016f719 00000000523bec00 ffff88025f255780 ffff88024feff600
> Sep 17 15:55:52 learner kernel: 0000000000018080 0000000000000000 ffff88025f258080 ffffffff815a0e60
> Sep 17 15:55:52 learner kernel: Call Trace:
> Sep 17 15:55:52 learner kernel: [<ffffffff81314be5>] ? dump_stack+0x7d/0xb8
> Sep 17 15:55:52 learner kernel: [<ffffffffa016f719>] ? usb_hcd_submit_urb+0x3c9/0xad0 [usbcore]
> Sep 17 15:55:52 learner kernel: [<ffffffff815a0e60>] ? _raw_spin_lock_irqsave+0x20/0x47
> Sep 17 15:55:52 learner kernel: [<ffffffff810d5c8b>] ? lock_timer_base.isra.24+0x7b/0xa0
> Sep 17 15:55:52 learner kernel: [<ffffffff810d5d59>] ? try_to_del_timer_sync+0x49/0x60
> Sep 17 15:55:52 learner kernel: [<ffffffffa017180d>] ? usb_start_wait_urb+0x5d/0x140 [usbcore]
> Sep 17 15:55:52 learner kernel: [<ffffffffa00ee2be>] ? rtsx_usb_send_cmd+0x5e/0x80 [rtsx_usb]
> Sep 17 15:55:52 learner kernel: [<ffffffffa00ee4a7>] ? rtsx_usb_read_register+0x67/0xb0 [rtsx_usb]
> Sep 17 15:55:52 learner kernel: [<ffffffffa0b15ac1>] ? rtsx_usb_detect_ms_card+0x61/0xe0 [rtsx_usb_ms]
> Sep 17 15:55:52 learner kernel: [<ffffffffa0b15a60>] ? rtsx_usb_ms_set_param+0x770/0x770 [rtsx_usb_ms]
> Sep 17 15:55:52 learner kernel: [<ffffffff8108ee0d>] ? kthread+0xbd/0xe0
> Sep 17 15:55:52 learner kernel: [<ffffffff81024741>] ? __switch_to+0x2b1/0x6a0
> Sep 17 15:55:52 learner kernel: [<ffffffff815a118f>] ? ret_from_fork+0x1f/0x40
> Sep 17 15:55:52 learner kernel: [<ffffffff8108ed50>] ? kthread_create_on_node+0x180/0x180
>
> This is the rtsx_usb_detect_ms_card() routine in
> drivers/memstick/host/rtsx_usb_ms.c, which runs as a kthread. It
> doesn't do any runtime PM. So it looks like the bug is present in both
> the MMC and MemoryStick interfaces.
I think the problem is even worse in the MemoryStick case, as the
memstick core doesn't help with runtime PM. I am pretty sure there are
other cases when the MemoryStick driver accesses the usb device
without first runtime resuming it.
Of course we could start simple an fix the bug observed above and see
if that solves the reported problem. Alan, do you want to post to
patch or you want me?
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: mmc: dw_mmc: log spamming
From: Tobias Jakobi @ 2016-09-19 10:00 UTC (permalink / raw)
To: Jaehoon Chung, sw0312.kim; +Cc: Ulf Hansson, linux-mmc@vger.kernel.org
In-Reply-To: <5d370fba-e4ec-d70a-a949-a955e86d61b1@samsung.com>
Hey Jaehoon,
Jaehoon Chung wrote:
> Hi Tobias,
>
> On 09/19/2016 04:41 PM, Tobias Jakobi wrote:
>> Hello Jaehoon,
>>
>>
>> Jaehoon Chung wrote:
>>> Hi Tobias,
>>>
>>> CC'd mmc mailing.
>>>
>>> On 09/19/2016 10:03 AM, Seung-Woo Kim wrote:
>>>> Hello Jaehoon,
>>>>
>>>> On 2016년 09월 19일 09:32, Jaehoon Chung wrote:
>>>>> Hi Tobias,
>>>>>
>>>>> On 09/16/2016 02:29 AM, Tobias Jakobi wrote:
>>>>>> Hello everyone,
>>>>>>
>>>>>> I'm experiencing massive kernel log spamming by dw_mmc, the commit that
>>>>>> causes this is the following one.
>>>>>>
>>>>>> 65257a0deed5aee66b4e3708944f0be62a64cabc
>>>>>>
>>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=65257a0deed5aee66b4e3708944f0be62a64cabc
>>>>>>
>>>>>> I've briefly checked the commit and I think the rationale behind
>>>>>> removing the check is incorrect. While MMC_CLKGATE was certainly
>>>>>> removed, runtime PM has "replaced" it (the commit
>>>>>> 9eadcc0581a8ccaf4c2378aa1c193fb164304f1d even mentions this).
>>>>>>
>>>>>> This is on an Exynos4412 board, kernel is 4.8-rc6. Nothing is connected
>>>>>> to the eMMC connector.
>>>>>
>>>>> Thanks for reporting this.
>>>>>
>>>>> Seung-Woo, Could you check your patch? I will also check this.
>>>
>>> Did you test after reverting this commit? or previous version is working fine?
>> yes, reverting the commit fixes the log spamming. I'm aware though that
>> the check is more of less broken (undefined behaviour because of
>> bit-shifting with large values), so I have also tried the following
>> thing: Just checking against 'div' instead of 'clock << div'. Anyway,
>> this also works for me.
>>
>>
>>> Which exynos4412 board do you use? I think it's related with "broken-cd".
>>> (If you can share which board and dts you are using, we can check in more detail.)
>> This is an Odroid-X2 board.
>>
>
> When i have checked on odroid-u3, it's reproduced very easy.
good to hear! I also worry that I'm the only one with these issues on
the X2. :)
Anyway, do you seen any other message on the U3 that are related to the
eMMC. I'm asking because I have also experience some warning/error from
the regulator subsystem:
> Sep 15 17:19:56 chidori kernel: [ 4.976690] vddf_emmc_2.85V: voltage operation not allowed
> Sep 15 17:19:56 chidori kernel: [ 4.995417] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 400000Hz, actual 396825HZ div = 63)
I'm sending you a patch shortly which fixes the warning, but I'm not
sure if this is the right approach. Maybe you can take a look?
>>> As you mentioned, you didn't insert the eMMC card on board.
>>> Then it should be polling whether card is inserted/removed. (If broken-cd is set...)
>> I can check the callstack leading to dw_mci_setup_bus() I guess. Would
>> that should make it easier for you guys to understand where the issue
>> originates from?
>
> Not need to share the callstack. Because i understood what is problem.
> But checking 'div' instead of 'clock << div' should also have the unexpected behavior.
Why is that? If I understood the initial problem correctly, then
shifting with 'div' produces undefined behaviour since we don't know an
upper bound for it. That's not the case if we just compare old and new
divisor.
> If needs to fix, i want to go ahead the correct way at this time.
> Anyway, thanks for reporting this!
Also thanks, and let me know if I can test anything else.
With best wishes,
Tobias
> Best Regards,
> Jaehoon Chung
>
>>
>>
>>> I think it's not related with runtime PM.
>>>
>>> Best Regards,
>>> Jaehoon Chung
>>
>> WIth best wishes,
>> Tobias
>>
>>
>>
>>
>>>> Ok, I will check on Exynos4412 SpC boards.
>>>>
>>>> By the way, to check no condition case, when I posted after v2[1], I
>>>> checked with Exynos5422 and Exynos5433 SoC boards and they didn't show
>>>> duplicated log, so I agreed not to check condition for logging.
>>>>
>>>> [1] https://patchwork.kernel.org/patch/9182469/
>>>>
>>>> Best Regards,
>>>> - Seung-Woo Kim
>>>>
>>>>>
>>>>> Best Regards,
>>>>> Jaehoon Chung
>>>>>
>>>>>>
>>>>>> With best wishes,
>>>>>> Tobias
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH 0/4] tmio: add support for eMMC with 8 bit bus width
From: Ulf Hansson @ 2016-09-19 10:00 UTC (permalink / raw)
To: Wolfram Sang
Cc: Geert Uytterhoeven, Wolfram Sang, Linux MMC List, Linux-Renesas,
Simon Horman, Dirk Behme
In-Reply-To: <20160919080045.GA1409@katana>
On 19 September 2016 at 10:00, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Thu, Sep 15, 2016 at 01:52:26PM +0200, Geert Uytterhoeven wrote:
>> Hi Wolfram,
>>
>> On Wed, Sep 14, 2016 at 7:05 PM, Wolfram Sang
>> <wsa+renesas@sang-engineering.com> wrote:
>> > The DTS changes for R-Car Gen3 will come via a seperate series. Note that
>> > 'non-removable' is not supported yet because of Runtime PM issues. It seems we
>> > need to overhaul Runtime PM handling for other reasons as well, so I suggest
>> > the basic support goes in like this and DTS do not use 'non-removable' for now.
>>
>> DT describes the hardware, not current limitations of the software.
>> Hence IMHO you should add the "non-removable" property to the DTS, and
>> work around its non-functioning in software.
>
> @Ulf: Would you accept such a workaround for a while?
With some comments about why, yes!
Br
Uffe
>
> diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
> index f21c92ec7121cc..5ab8af294f7c40 100644
> --- a/drivers/mmc/host/tmio_mmc_pio.c
> +++ b/drivers/mmc/host/tmio_mmc_pio.c
> @@ -1154,6 +1154,10 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
> !mmc_card_is_removable(mmc) ||
> mmc->slot.cd_irq >= 0);
>
> + /* Workaround for NONREMOVABLE until we fix RuntimePM handling */
> + if (pdata->flags & TMIO_MMC_MIN_RCAR2)
> + _host->native_hotplug = true;
> +
> if (tmio_mmc_clk_enable(_host) < 0) {
> mmc->f_max = pdata->hclk;
> mmc->f_min = mmc->f_max / 512;
>
^ permalink raw reply
* Re: [PATCH] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led
From: Ulf Hansson @ 2016-09-19 9:24 UTC (permalink / raw)
To: Alan Stern
Cc: linux-mmc, Ritesh Raj Sarraf, USB list, Micky Ching, Roger Tseng,
Wei WANG
In-Reply-To: <Pine.LNX.4.44L0.1609172219100.1716-100000@netrider.rowland.org>
On 18 September 2016 at 04:30, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Sat, 17 Sep 2016, Ulf Hansson wrote:
>
>> Each access of the parent device (usb device) needs to be done in runtime
>> resumed state. Currently this isn't case while changing the leds, so let's
>> add pm_runtime_get_sync() and pm_runtime_put() around these calls.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> ---
>>
>> While discussing an issue[1] related to runtime PM, I found out that this
>> minor change at least improves the behavior that has been observed.
>>
>> [1]
>> http://www.spinics.net/lists/linux-usb/msg144634.html
>>
>> ---
>> drivers/mmc/host/rtsx_usb_sdmmc.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c b/drivers/mmc/host/rtsx_usb_sdmmc.c
>> index 6c71fc9..a59c7fa 100644
>> --- a/drivers/mmc/host/rtsx_usb_sdmmc.c
>> +++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
>> @@ -1314,6 +1314,7 @@ static void rtsx_usb_update_led(struct work_struct *work)
>> container_of(work, struct rtsx_usb_sdmmc, led_work);
>> struct rtsx_ucr *ucr = host->ucr;
>>
>> + pm_runtime_get_sync(sdmmc_dev(host));
>> mutex_lock(&ucr->dev_mutex);
>>
>> if (host->led.brightness == LED_OFF)
>> @@ -1322,6 +1323,7 @@ static void rtsx_usb_update_led(struct work_struct *work)
>> rtsx_usb_turn_on_led(ucr);
>>
>> mutex_unlock(&ucr->dev_mutex);
>> + pm_runtime_put(sdmmc_dev(host));
>> }
>> #endif
>
> The missing aspect here is that this won't stop the parent USB device
> from going into autosuspend every 2 seconds and then resuming shortly
> afterward. There are two ways of preventing this:
>
> Call usb_mark_last_busy() at appropriate places.
>
> Enable autosuspend for the sdmmc device.
>
> The second approach would also prevent the sdmmc device from going into
> autosuspend as soon as the LED update is finished. Maybe that's okay,
> but if going into suspend is a lightweight procedure then you may want
> to prevent it.
>
We can for sure enable autosuspend for the sdmmc device, although as
soon as an SD card will be detected the rtsx driver will increase the
runtime PM usage count. The count is decreased when the card is
removed (or failed to be initialized), thus runtime suspend is
prevented as long as there is a functional card inserted.
I am wondering what you think would be a good autosuspend timeout in
this case? It seems to me that the only thing the rtsx driver really
care about is to tell the parent device that it needs to be runtime
resumed during a certain timeframe, more or less it would like to
inherit the parents settings.
Other mmc hosts, not being usb-mmc devices, are using an autosuspend
timeout of ~50-100ms but that doesn't seem like good value here,
right?
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH 0/4] tmio: add support for eMMC with 8 bit bus width
From: Wolfram Sang @ 2016-09-19 8:00 UTC (permalink / raw)
To: Geert Uytterhoeven, Ulf Hansson
Cc: Wolfram Sang, Linux MMC List, Linux-Renesas, Simon Horman,
Dirk Behme
In-Reply-To: <CAMuHMdX7GygtuA43=+HFFOyMGt=x1b2UTQBUojqedSfcRmSxjQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]
On Thu, Sep 15, 2016 at 01:52:26PM +0200, Geert Uytterhoeven wrote:
> Hi Wolfram,
>
> On Wed, Sep 14, 2016 at 7:05 PM, Wolfram Sang
> <wsa+renesas@sang-engineering.com> wrote:
> > The DTS changes for R-Car Gen3 will come via a seperate series. Note that
> > 'non-removable' is not supported yet because of Runtime PM issues. It seems we
> > need to overhaul Runtime PM handling for other reasons as well, so I suggest
> > the basic support goes in like this and DTS do not use 'non-removable' for now.
>
> DT describes the hardware, not current limitations of the software.
> Hence IMHO you should add the "non-removable" property to the DTS, and
> work around its non-functioning in software.
@Ulf: Would you accept such a workaround for a while?
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index f21c92ec7121cc..5ab8af294f7c40 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -1154,6 +1154,10 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
!mmc_card_is_removable(mmc) ||
mmc->slot.cd_irq >= 0);
+ /* Workaround for NONREMOVABLE until we fix RuntimePM handling */
+ if (pdata->flags & TMIO_MMC_MIN_RCAR2)
+ _host->native_hotplug = true;
+
if (tmio_mmc_clk_enable(_host) < 0) {
mmc->f_max = pdata->hclk;
mmc->f_min = mmc->f_max / 512;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* Re: [RESEND PATCH v7 2/2] sdhci-of-arasan: Set controller to test mode when xlnx,fails-without-test-cd is present
From: Adrian Hunter @ 2016-09-19 7:51 UTC (permalink / raw)
To: Zach Brown
Cc: robh+dt, ulf.hansson, mark.rutland, linux-mmc, devicetree,
linux-kernel, michal.simek, soren.brinkmann, linux-arm-kernel
In-Reply-To: <1474038102-20937-2-git-send-email-zach.brown@ni.com>
On 16/09/16 18:01, Zach Brown wrote:
> The sdhci controller on xilinx zynq devices will not function unless
> the CD bit is provided. http://www.xilinx.com/support/answers/61064.html
> In cases where it is impossible to provide the CD bit in hardware,
> setting the controller to test mode and then setting inserted to true
> will get the controller to function without the CD bit.
>
> When the device has the property xlnx,fails-without-test-cd the driver
> changes the controller to test mode and sets test inserted to true to
> make the controller function.
>
> Signed-off-by: Zach Brown <zach.brown@ni.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 27 ++++++++++++++++++++++++++-
> drivers/mmc/host/sdhci.h | 2 ++
> 2 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index 33601a8..da8e40a 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -26,6 +26,7 @@
> #include <linux/phy/phy.h>
> #include <linux/regmap.h>
> #include "sdhci-pltfm.h"
> +#include <linux/of.h>
>
> #define SDHCI_ARASAN_CLK_CTRL_OFFSET 0x2c
> #define SDHCI_ARASAN_VENDOR_REGISTER 0x78
> @@ -98,6 +99,10 @@ struct sdhci_arasan_data {
>
> struct regmap *soc_ctl_base;
> const struct sdhci_arasan_soc_ctl_map *soc_ctl_map;
> + unsigned int quirks; /* Arasan deviations from spec */
> +
> +/* Controller does not have CD wired and will not function normally without */
> +#define SDHCI_ARASAN_QUIRK_FORCE_CDTEST BIT(0)
> };
>
> static const struct sdhci_arasan_soc_ctl_map rk3399_soc_ctl_map = {
> @@ -245,12 +250,27 @@ static void sdhci_arasan_hs400_enhanced_strobe(struct mmc_host *mmc,
> writel(vendor, host->ioaddr + SDHCI_ARASAN_VENDOR_REGISTER);
> }
>
> +void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
> +{
> + u8 ctrl;
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
> +
> + sdhci_reset(host, mask);
> +
> + if (sdhci_arasan->quirks & SDHCI_ARASAN_QUIRK_FORCE_CDTEST) {
> + ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
> + ctrl |= SDHCI_CTRL_CDTEST_INS | SDHCI_CTRL_CDTEST_EN;
> + sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
> + }
> +}
> +
> static struct sdhci_ops sdhci_arasan_ops = {
> .set_clock = sdhci_arasan_set_clock,
> .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> .get_timeout_clock = sdhci_arasan_get_timeout_clock,
> .set_bus_width = sdhci_set_bus_width,
> - .reset = sdhci_reset,
> + .reset = sdhci_arasan_reset,
> .set_uhs_signaling = sdhci_set_uhs_signaling,
> };
>
> @@ -545,6 +565,7 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
> struct sdhci_host *host;
> struct sdhci_pltfm_host *pltfm_host;
> struct sdhci_arasan_data *sdhci_arasan;
> + struct device_node *np = pdev->dev.of_node;
>
> host = sdhci_pltfm_init(pdev, &sdhci_arasan_pdata,
> sizeof(*sdhci_arasan));
> @@ -599,6 +620,10 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
> }
>
> sdhci_get_of_property(pdev);
> +
> + if (of_property_read_bool(np, "xlnx,fails-without-test-cd"))
> + sdhci_arasan->quirks |= SDHCI_ARASAN_QUIRK_FORCE_CDTEST;
> +
> pltfm_host->clk = clk_xin;
>
> if (of_device_is_compatible(pdev->dev.of_node,
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index a2bc9e1..c722cd2 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -84,6 +84,8 @@
> #define SDHCI_CTRL_ADMA32 0x10
> #define SDHCI_CTRL_ADMA64 0x18
> #define SDHCI_CTRL_8BITBUS 0x20
> +#define SDHCI_CTRL_CDTEST_INS 0x40
> +#define SDHCI_CTRL_CDTEST_EN 0x80
>
> #define SDHCI_POWER_CONTROL 0x29
> #define SDHCI_POWER_ON 0x01
>
^ permalink raw reply
* Re: mmc: dw_mmc: log spamming
From: Jaehoon Chung @ 2016-09-19 7:54 UTC (permalink / raw)
To: Tobias Jakobi, sw0312.kim; +Cc: Ulf Hansson, linux-mmc@vger.kernel.org
In-Reply-To: <57DF96C3.7050706@math.uni-bielefeld.de>
Hi Tobias,
On 09/19/2016 04:41 PM, Tobias Jakobi wrote:
> Hello Jaehoon,
>
>
> Jaehoon Chung wrote:
>> Hi Tobias,
>>
>> CC'd mmc mailing.
>>
>> On 09/19/2016 10:03 AM, Seung-Woo Kim wrote:
>>> Hello Jaehoon,
>>>
>>> On 2016년 09월 19일 09:32, Jaehoon Chung wrote:
>>>> Hi Tobias,
>>>>
>>>> On 09/16/2016 02:29 AM, Tobias Jakobi wrote:
>>>>> Hello everyone,
>>>>>
>>>>> I'm experiencing massive kernel log spamming by dw_mmc, the commit that
>>>>> causes this is the following one.
>>>>>
>>>>> 65257a0deed5aee66b4e3708944f0be62a64cabc
>>>>>
>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=65257a0deed5aee66b4e3708944f0be62a64cabc
>>>>>
>>>>> I've briefly checked the commit and I think the rationale behind
>>>>> removing the check is incorrect. While MMC_CLKGATE was certainly
>>>>> removed, runtime PM has "replaced" it (the commit
>>>>> 9eadcc0581a8ccaf4c2378aa1c193fb164304f1d even mentions this).
>>>>>
>>>>> This is on an Exynos4412 board, kernel is 4.8-rc6. Nothing is connected
>>>>> to the eMMC connector.
>>>>
>>>> Thanks for reporting this.
>>>>
>>>> Seung-Woo, Could you check your patch? I will also check this.
>>
>> Did you test after reverting this commit? or previous version is working fine?
> yes, reverting the commit fixes the log spamming. I'm aware though that
> the check is more of less broken (undefined behaviour because of
> bit-shifting with large values), so I have also tried the following
> thing: Just checking against 'div' instead of 'clock << div'. Anyway,
> this also works for me.
>
>
>> Which exynos4412 board do you use? I think it's related with "broken-cd".
>> (If you can share which board and dts you are using, we can check in more detail.)
> This is an Odroid-X2 board.
>
When i have checked on odroid-u3, it's reproduced very easy.
>
>> As you mentioned, you didn't insert the eMMC card on board.
>> Then it should be polling whether card is inserted/removed. (If broken-cd is set...)
> I can check the callstack leading to dw_mci_setup_bus() I guess. Would
> that should make it easier for you guys to understand where the issue
> originates from?
Not need to share the callstack. Because i understood what is problem.
But checking 'div' instead of 'clock << div' should also have the unexpected behavior.
If needs to fix, i want to go ahead the correct way at this time.
Anyway, thanks for reporting this!
Best Regards,
Jaehoon Chung
>
>
>> I think it's not related with runtime PM.
>>
>> Best Regards,
>> Jaehoon Chung
>
> WIth best wishes,
> Tobias
>
>
>
>
>>> Ok, I will check on Exynos4412 SpC boards.
>>>
>>> By the way, to check no condition case, when I posted after v2[1], I
>>> checked with Exynos5422 and Exynos5433 SoC boards and they didn't show
>>> duplicated log, so I agreed not to check condition for logging.
>>>
>>> [1] https://patchwork.kernel.org/patch/9182469/
>>>
>>> Best Regards,
>>> - Seung-Woo Kim
>>>
>>>>
>>>> Best Regards,
>>>> Jaehoon Chung
>>>>
>>>>>
>>>>> With best wishes,
>>>>> Tobias
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>
>
^ permalink raw reply
* Re: mmc: dw_mmc: log spamming
From: Tobias Jakobi @ 2016-09-19 7:41 UTC (permalink / raw)
To: Jaehoon Chung, sw0312.kim; +Cc: Ulf Hansson, linux-mmc@vger.kernel.org
In-Reply-To: <6dd25843-3852-b059-4c42-6c720887db38@samsung.com>
Hello Jaehoon,
Jaehoon Chung wrote:
> Hi Tobias,
>
> CC'd mmc mailing.
>
> On 09/19/2016 10:03 AM, Seung-Woo Kim wrote:
>> Hello Jaehoon,
>>
>> On 2016년 09월 19일 09:32, Jaehoon Chung wrote:
>>> Hi Tobias,
>>>
>>> On 09/16/2016 02:29 AM, Tobias Jakobi wrote:
>>>> Hello everyone,
>>>>
>>>> I'm experiencing massive kernel log spamming by dw_mmc, the commit that
>>>> causes this is the following one.
>>>>
>>>> 65257a0deed5aee66b4e3708944f0be62a64cabc
>>>>
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=65257a0deed5aee66b4e3708944f0be62a64cabc
>>>>
>>>> I've briefly checked the commit and I think the rationale behind
>>>> removing the check is incorrect. While MMC_CLKGATE was certainly
>>>> removed, runtime PM has "replaced" it (the commit
>>>> 9eadcc0581a8ccaf4c2378aa1c193fb164304f1d even mentions this).
>>>>
>>>> This is on an Exynos4412 board, kernel is 4.8-rc6. Nothing is connected
>>>> to the eMMC connector.
>>>
>>> Thanks for reporting this.
>>>
>>> Seung-Woo, Could you check your patch? I will also check this.
>
> Did you test after reverting this commit? or previous version is working fine?
yes, reverting the commit fixes the log spamming. I'm aware though that
the check is more of less broken (undefined behaviour because of
bit-shifting with large values), so I have also tried the following
thing: Just checking against 'div' instead of 'clock << div'. Anyway,
this also works for me.
> Which exynos4412 board do you use? I think it's related with "broken-cd".
> (If you can share which board and dts you are using, we can check in more detail.)
This is an Odroid-X2 board.
> As you mentioned, you didn't insert the eMMC card on board.
> Then it should be polling whether card is inserted/removed. (If broken-cd is set...)
I can check the callstack leading to dw_mci_setup_bus() I guess. Would
that should make it easier for you guys to understand where the issue
originates from?
> I think it's not related with runtime PM.
>
> Best Regards,
> Jaehoon Chung
WIth best wishes,
Tobias
>> Ok, I will check on Exynos4412 SpC boards.
>>
>> By the way, to check no condition case, when I posted after v2[1], I
>> checked with Exynos5422 and Exynos5433 SoC boards and they didn't show
>> duplicated log, so I agreed not to check condition for logging.
>>
>> [1] https://patchwork.kernel.org/patch/9182469/
>>
>> Best Regards,
>> - Seung-Woo Kim
>>
>>>
>>> Best Regards,
>>> Jaehoon Chung
>>>
>>>>
>>>> With best wishes,
>>>> Tobias
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
^ permalink raw reply
* Re: mmc: dw_mmc: log spamming
From: Jaehoon Chung @ 2016-09-19 7:33 UTC (permalink / raw)
To: sw0312.kim; +Cc: Tobias Jakobi, Ulf Hansson, linux-mmc@vger.kernel.org
In-Reply-To: <57DF396E.9050503@samsung.com>
Hi Tobias,
CC'd mmc mailing.
On 09/19/2016 10:03 AM, Seung-Woo Kim wrote:
> Hello Jaehoon,
>
> On 2016년 09월 19일 09:32, Jaehoon Chung wrote:
>> Hi Tobias,
>>
>> On 09/16/2016 02:29 AM, Tobias Jakobi wrote:
>>> Hello everyone,
>>>
>>> I'm experiencing massive kernel log spamming by dw_mmc, the commit that
>>> causes this is the following one.
>>>
>>> 65257a0deed5aee66b4e3708944f0be62a64cabc
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=65257a0deed5aee66b4e3708944f0be62a64cabc
>>>
>>> I've briefly checked the commit and I think the rationale behind
>>> removing the check is incorrect. While MMC_CLKGATE was certainly
>>> removed, runtime PM has "replaced" it (the commit
>>> 9eadcc0581a8ccaf4c2378aa1c193fb164304f1d even mentions this).
>>>
>>> This is on an Exynos4412 board, kernel is 4.8-rc6. Nothing is connected
>>> to the eMMC connector.
>>
>> Thanks for reporting this.
>>
>> Seung-Woo, Could you check your patch? I will also check this.
Did you test after reverting this commit? or previous version is working fine?
Which exynos4412 board do you use? I think it's related with "broken-cd".
(If you can share which board and dts you are using, we can check in more detail.)
As you mentioned, you didn't insert the eMMC card on board.
Then it should be polling whether card is inserted/removed. (If broken-cd is set...)
I think it's not related with runtime PM.
Best Regards,
Jaehoon Chung
>
> Ok, I will check on Exynos4412 SpC boards.
>
> By the way, to check no condition case, when I posted after v2[1], I
> checked with Exynos5422 and Exynos5433 SoC boards and they didn't show
> duplicated log, so I agreed not to check condition for logging.
>
> [1] https://patchwork.kernel.org/patch/9182469/
>
> Best Regards,
> - Seung-Woo Kim
>
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> With best wishes,
>>> Tobias
>>>
>>>
>>>
>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led
From: Alan Stern @ 2016-09-18 2:30 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc-u79uwXL29TY76Z2rM5mHXA, Ritesh Raj Sarraf, USB list,
Micky Ching, Roger Tseng, Wei WANG
In-Reply-To: <1474107278-3271-1-git-send-email-ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Sat, 17 Sep 2016, Ulf Hansson wrote:
> Each access of the parent device (usb device) needs to be done in runtime
> resumed state. Currently this isn't case while changing the leds, so let's
> add pm_runtime_get_sync() and pm_runtime_put() around these calls.
>
> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>
> While discussing an issue[1] related to runtime PM, I found out that this
> minor change at least improves the behavior that has been observed.
>
> [1]
> http://www.spinics.net/lists/linux-usb/msg144634.html
>
> ---
> drivers/mmc/host/rtsx_usb_sdmmc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c b/drivers/mmc/host/rtsx_usb_sdmmc.c
> index 6c71fc9..a59c7fa 100644
> --- a/drivers/mmc/host/rtsx_usb_sdmmc.c
> +++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
> @@ -1314,6 +1314,7 @@ static void rtsx_usb_update_led(struct work_struct *work)
> container_of(work, struct rtsx_usb_sdmmc, led_work);
> struct rtsx_ucr *ucr = host->ucr;
>
> + pm_runtime_get_sync(sdmmc_dev(host));
> mutex_lock(&ucr->dev_mutex);
>
> if (host->led.brightness == LED_OFF)
> @@ -1322,6 +1323,7 @@ static void rtsx_usb_update_led(struct work_struct *work)
> rtsx_usb_turn_on_led(ucr);
>
> mutex_unlock(&ucr->dev_mutex);
> + pm_runtime_put(sdmmc_dev(host));
> }
> #endif
The missing aspect here is that this won't stop the parent USB device
from going into autosuspend every 2 seconds and then resuming shortly
afterward. There are two ways of preventing this:
Call usb_mark_last_busy() at appropriate places.
Enable autosuspend for the sdmmc device.
The second approach would also prevent the sdmmc device from going into
autosuspend as soon as the LED update is finished. Maybe that's okay,
but if going into suspend is a lightweight procedure then you may want
to prevent it.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]
From: Alan Stern @ 2016-09-18 1:42 UTC (permalink / raw)
To: Ritesh Raj Sarraf; +Cc: Ulf Hansson, USB list, linux-mmc
In-Reply-To: <1474112525.11383.3.camel@researchut.com>
On Sat, 17 Sep 2016, Ritesh Raj Sarraf wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello Alan,
>
>
> On Fri, 2016-09-16 at 17:40 -0400, Alan Stern wrote:
> > We're still getting runtime suspends, but now at 2-second intervals.
> > This is partly because the driver isn't calling
> > pm_runtime_mark_last_busy(), but there may be more to it. The 2-second
> > period is the default autosuspend timeout for USB devices. However, I
> > don't see the activity that rtsx_usb_get_card_status() should produce
> > when rtsx_usb_suspend() runs; I don't know why not.
> >
> > We're also getting occasional I/O attempts while the device is
> > suspended. They must be on some other pathway, not the one fixed by
> > the patch above. Let's see if we can find out just where they come
> > from.
> >
> > Ritesh, please try applying this patch on top of the previous one. It
> > will produce output in the kernel log whenever these bad I/O attempts
> > occur. Also, enable dynamic debugging for the rtsx_usb driver:
> >
>
> Please find links to the usbmon trace and the kernel trace.
>
> https://people.debian.org/~rrs/tmp/4.8.0-rc6ulf1alan1+.kern.log
> https://people.debian.org/~rrs/tmp/usb-4.8.0-rc6ulf1alan1+.log.gz
Well, this is pretty clear:
Sep 17 15:55:52 learner kernel: CPU: 1 PID: 535 Comm: rtsx_usb_ms_1 Tainted: G U 4.8.0-rc6ulf1alan1+ #19
Sep 17 15:55:52 learner kernel: Hardware name: LENOVO 20344/INVALID, BIOS 96CN31WW(V1.17) 07/21/2015
Sep 17 15:55:52 learner kernel: 0000000000000000 ffffffff81314be5 ffff8802476746c0 0000000002400000
Sep 17 15:55:52 learner kernel: ffffffffa016f719 00000000523bec00 ffff88025f255780 ffff88024feff600
Sep 17 15:55:52 learner kernel: 0000000000018080 0000000000000000 ffff88025f258080 ffffffff815a0e60
Sep 17 15:55:52 learner kernel: Call Trace:
Sep 17 15:55:52 learner kernel: [<ffffffff81314be5>] ? dump_stack+0x7d/0xb8
Sep 17 15:55:52 learner kernel: [<ffffffffa016f719>] ? usb_hcd_submit_urb+0x3c9/0xad0 [usbcore]
Sep 17 15:55:52 learner kernel: [<ffffffff815a0e60>] ? _raw_spin_lock_irqsave+0x20/0x47
Sep 17 15:55:52 learner kernel: [<ffffffff810d5c8b>] ? lock_timer_base.isra.24+0x7b/0xa0
Sep 17 15:55:52 learner kernel: [<ffffffff810d5d59>] ? try_to_del_timer_sync+0x49/0x60
Sep 17 15:55:52 learner kernel: [<ffffffffa017180d>] ? usb_start_wait_urb+0x5d/0x140 [usbcore]
Sep 17 15:55:52 learner kernel: [<ffffffffa00ee2be>] ? rtsx_usb_send_cmd+0x5e/0x80 [rtsx_usb]
Sep 17 15:55:52 learner kernel: [<ffffffffa00ee4a7>] ? rtsx_usb_read_register+0x67/0xb0 [rtsx_usb]
Sep 17 15:55:52 learner kernel: [<ffffffffa0b15ac1>] ? rtsx_usb_detect_ms_card+0x61/0xe0 [rtsx_usb_ms]
Sep 17 15:55:52 learner kernel: [<ffffffffa0b15a60>] ? rtsx_usb_ms_set_param+0x770/0x770 [rtsx_usb_ms]
Sep 17 15:55:52 learner kernel: [<ffffffff8108ee0d>] ? kthread+0xbd/0xe0
Sep 17 15:55:52 learner kernel: [<ffffffff81024741>] ? __switch_to+0x2b1/0x6a0
Sep 17 15:55:52 learner kernel: [<ffffffff815a118f>] ? ret_from_fork+0x1f/0x40
Sep 17 15:55:52 learner kernel: [<ffffffff8108ed50>] ? kthread_create_on_node+0x180/0x180
This is the rtsx_usb_detect_ms_card() routine in
drivers/memstick/host/rtsx_usb_ms.c, which runs as a kthread. It
doesn't do any runtime PM. So it looks like the bug is present in both
the MMC and MemoryStick interfaces.
Alan Stern
^ permalink raw reply
* Your (Email Address) Outlook exceeded
From: Kaitlin Schneekloth @ 2016-09-17 15:37 UTC (permalink / raw)
Your (Email Address) Outlook exceeded its storage limit. https://docs.google.com/forms/d/e/1FAIpQLSdtc96pXFgZ5LIOEaRYQaBOvX0ae7kS_RpTukKOq7eI4RASQw/viewform (FILL) and Click on Submit to get more space or you wont be able to send Mail.
^ permalink raw reply
* RE: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option
From: Chris Brandt @ 2016-09-17 13:38 UTC (permalink / raw)
To: Ulf Hansson
Cc: Geert Uytterhoeven, Wolfram Sang, Sergei Shtylyov, Simon Horman,
linux-mmc, Linux-Renesas
In-Reply-To: <CAPDyKFqBToUrSbErWrc+zV-WX29Dj5dm+XzWMCfBgOiEtoG8Jg@mail.gmail.com>
On 9/17/2016, Ulf Hansson wrote:
> > I'm assuming I'll have to do the same for MMC (sh_mmcif.c) once I get to
> that driver (I need to find my MMC PLUS card first for testing).
>
> Okay!
>
> Kind regards
> Uffe
Just FYI,
For the eMMC case, I decided not to modify sh_mmcif.c to add the OCR and instead just create a 3.3 fixed regulator in the DT.
The reason is that if someone is using eMMC for their file system, they are probably using external RAM (since block data needs to be copied out of eMMC into RAM before they can be executed). So the extra RAM needed for the regular DT is not really an issue.
However, the people using SDHI are using it for SDIO for Wifi modules and they are the ones with the slimmed down RAM systems. So for them, removing the regulator DT will help squeeze their system into 3MB or 5MB of in-chip system RAM.
Chris
^ permalink raw reply
* Re: xHCI problem? [was Re: Erratic USB device behavior and device loss]
From: Ritesh Raj Sarraf @ 2016-09-17 11:42 UTC (permalink / raw)
To: Alan Stern; +Cc: Ulf Hansson, USB list, linux-mmc
In-Reply-To: <Pine.LNX.4.44L0.1609161729340.1657-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hello Alan,
On Fri, 2016-09-16 at 17:40 -0400, Alan Stern wrote:
> We're still getting runtime suspends, but now at 2-second intervals.
> This is partly because the driver isn't calling
> pm_runtime_mark_last_busy(), but there may be more to it. The 2-second
> period is the default autosuspend timeout for USB devices. However, I
> don't see the activity that rtsx_usb_get_card_status() should produce
> when rtsx_usb_suspend() runs; I don't know why not.
>
> We're also getting occasional I/O attempts while the device is
> suspended. They must be on some other pathway, not the one fixed by
> the patch above. Let's see if we can find out just where they come
> from.
>
> Ritesh, please try applying this patch on top of the previous one. It
> will produce output in the kernel log whenever these bad I/O attempts
> occur. Also, enable dynamic debugging for the rtsx_usb driver:
>
Please find links to the usbmon trace and the kernel trace.
https://people.debian.org/~rrs/tmp/4.8.0-rc6ulf1alan1+.kern.log
https://people.debian.org/~rrs/tmp/usb-4.8.0-rc6ulf1alan1+.log.gz
Thanks.
> echo 'module rtsx_usb =p' >/sys/kernel/debug/dynamic_debug/control
>
> before starting the test. (You may need to mount a debugfs filesystem
> on /sys/kernel/debug first.)
>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/core/hcd.c
> ===================================================================
> --- usb-4.x.orig/drivers/usb/core/hcd.c
> +++ usb-4.x/drivers/usb/core/hcd.c
> @@ -1647,6 +1647,8 @@ int usb_hcd_submit_urb (struct urb *urb,
> status = map_urb_for_dma(hcd, urb, mem_flags);
> if (likely(status == 0)) {
> status = hcd->driver->urb_enqueue(hcd, urb,
> mem_flags);
> + if (status == -EHOSTUNREACH)
> + dump_stack();
> if (unlikely(status))
> unmap_urb_for_dma(hcd, urb);
> }
>
- --
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJX3SwNAAoJEKY6WKPy4XVpMaYQAK3p/meduq2SLRKjcLuher/+
U6W0+6t1MJmNLZgArqEYLprGQs8dboDUVuYdOkpDyjsL3oRVc2RFRhKP4n5uyeqf
UOyyJC/Dn8JpW5abQPdQOi8/zeY019P1MPKd/lAvjs+MXOdRvOluwne3KGeVJzrc
nWNt9YMZCvxscbXjJVqNWFh8utg6BVVoJ72sqkHYL6N+cWKwKb4QphgNXbhoPQq3
K7KwsBywQHty/Wf4TXB6n8z/6zR6uNHQjaveboUvidkMhWXYFSVag6ba6ZOsAyoL
nPWvowTTKO3snKh2AzHhJEzgky2EXMoxG5+GzA3nBA9suAapxuS7tTSt5YAShupv
at1FASeb8kyZ7vt3Srq7WQN7OIlER9zvVvapENJHwqATnHAQ+35h+7o1CrZLjDyF
UB5qKWOOQlFmiEfjjs15bLumBQqA4vX7JvYqJxNX7AtOPUXZHvs85eX7S4s18TZ7
OYO5JkS0xcLD6HMvuxzwO+UDS5DYknwma8gAPvHg1mX8QQMOPNkbnd7Igt9kjhMR
ZioeP0xLyyUGwjGErQpzgQwHlk5bMQhQ4iiOxi4nz4aCWLCs2YwzojfwtfDxSYnV
rCSjWEAanG3eRP7iPBtbdrbFmWsjSsavopXXlLPNYDjBjnpm2/IcyIlC/dTKKYJz
0rkc0hreSRuSDMPxbkfV
=d/iL
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [GIT PULL] MMC fixes for v.4.8 rc7
From: Ulf Hansson @ 2016-09-17 10:40 UTC (permalink / raw)
To: Linus Torvalds, linux-mmc, linux-kernel@vger.kernel.org; +Cc: Adrian Hunter
Hi Linus,
Here are some mmc fixes intended for v4.8 rc7. They are based on v4.8-rc6.
Details are as usual found in the signed tag. Please pull this in!
Kind regards
Ulf Hansson
The following changes since commit 9395452b4aab7bc2475ef8935b4a4fb99d778d70:
Linux 4.8-rc6 (2016-09-11 20:02:25 -0700)
are available in the git repository at:
git://git.linaro.org/people/ulf.hansson/mmc.git tags/mmc-v4.8-rc6
for you to fetch changes up to df804d5e27490151da1ce9f216031a31352203e6:
mmc: omap: Initialize dma_slave_config to avoid random data in it's
fields (2016-09-14 13:59:33 +0200)
----------------------------------------------------------------
MMC host:
- omap/omap_hsmmc: Initialize dma_slave_config to avoid random data
- sdhci-st: Handle interconnect clock
----------------------------------------------------------------
Lee Jones (2):
dt-bindings: mmc: sdhci-st: Mention the discretionary "icn" clock
mmc: sdhci-st: Handle interconnect clock
Peter Ujfalusi (2):
mmc: omap_hsmmc: Initialize dma_slave_config to avoid random data
mmc: omap: Initialize dma_slave_config to avoid random data in it's fields
Documentation/devicetree/bindings/mmc/sdhci-st.txt | 2 +-
drivers/mmc/host/omap.c | 18 ++++++++++--------
drivers/mmc/host/omap_hsmmc.c | 16 ++++++++--------
drivers/mmc/host/sdhci-st.c | 15 ++++++++++++++-
4 files changed, 33 insertions(+), 18 deletions(-)
^ permalink raw reply
* [PATCH] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led
From: Ulf Hansson @ 2016-09-17 10:14 UTC (permalink / raw)
To: linux-mmc, Ulf Hansson
Cc: Ritesh Raj Sarraf, Alan Stern, USB list, Micky Ching, Roger Tseng,
Wei WANG
Each access of the parent device (usb device) needs to be done in runtime
resumed state. Currently this isn't case while changing the leds, so let's
add pm_runtime_get_sync() and pm_runtime_put() around these calls.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
While discussing an issue[1] related to runtime PM, I found out that this
minor change at least improves the behavior that has been observed.
[1]
http://www.spinics.net/lists/linux-usb/msg144634.html
---
drivers/mmc/host/rtsx_usb_sdmmc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c b/drivers/mmc/host/rtsx_usb_sdmmc.c
index 6c71fc9..a59c7fa 100644
--- a/drivers/mmc/host/rtsx_usb_sdmmc.c
+++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
@@ -1314,6 +1314,7 @@ static void rtsx_usb_update_led(struct work_struct *work)
container_of(work, struct rtsx_usb_sdmmc, led_work);
struct rtsx_ucr *ucr = host->ucr;
+ pm_runtime_get_sync(sdmmc_dev(host));
mutex_lock(&ucr->dev_mutex);
if (host->led.brightness == LED_OFF)
@@ -1322,6 +1323,7 @@ static void rtsx_usb_update_led(struct work_struct *work)
rtsx_usb_turn_on_led(ucr);
mutex_unlock(&ucr->dev_mutex);
+ pm_runtime_put(sdmmc_dev(host));
}
#endif
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 2/5] mmc: bcm2835-sdhost: Add new driver for the internal SD controller.
From: Ulf Hansson @ 2016-09-17 10:02 UTC (permalink / raw)
To: Eric Anholt
Cc: Gerd Hoffmann, linux-rpi-kernel,
linux-arm-kernel@lists.infradead.org, linux-mmc, Stephen Warren,
Lee Jones, open list
In-Reply-To: <877falaq1q.fsf@eliezer.anholt.net>
On 9 September 2016 at 20:25, Eric Anholt <eric@anholt.net> wrote:
> Gerd Hoffmann <kraxel@redhat.com> writes:
>
>> On Mi, 2016-08-31 at 14:58 +0200, Ulf Hansson wrote:
>>> On 22 June 2016 at 13:42, Gerd Hoffmann <kraxel@redhat.com> wrote:
>>> > From: Eric Anholt <eric@anholt.net>
>>> >
>>> > The 2835 has two SD controllers: The Arasan SDHCI controller that we
>>> > currently use, and a custom SD controller. The custom one runs faster
>>> >
>>> > The code was originally written by Phil Elwell in the downstream
>>> > Rasbperry Pi tree, and I did a major cleanup on it (+319, -707 lines
>>> > out of the original 2055) for inclusion.
>>> >
>>> > Signed-off-by: Eric Anholt <eric@anholt.net>
>>>
>>> Apologize for the delay!
>>
>> No problem, I was on summer vacation anyway ...
>>
>>> Could you start by providing some more information about the driver
>>> and the controller in change in the change log please.
>>
>> Eric? I don't know much more than what the commit message above says.
>>
>> Beside the speedup mentioned above driving the sdcard with the custom sd
>> controller allows to use the sdhci (handled by sdhci-iproc) to be used
>> for the wifi on the rpi3.
>
> Maybe just add that we need both controllers in order to do both wifi
> and SD card? I don't know exactly what Ulf wants to see here.
Some toplevel description of the controller. Like what speed modes it
supports, can it do SD/SDIO/eMMC and so forth.
>
>>> > +static void bcm2835_sdhost_set_power(struct bcm2835_host *host, bool on)
>>> > +{
>>> > + bcm2835_sdhost_write(host, on ? 1 : 0, SDVDD);
>>>
>>> What exactly does this power on/off?
>>
>> Dunno. Eric?
>
> Note: I don't know much about SD, so I'm just trying to play oracle for
> you all here.
>
> VDD bit 0 (POWER_ON) starts the power-on setup cycle by the sdhost once
> power is already supplied to the card by some other means. In the
> SDHOST docs they assume you're going to use GPIO to control SD card
> power, but for Raspberry Pi they just have the SD Card's VDD always on.
> It's unclear to me what's controlling power to the Pi3 wifi/BT's SD
> client, but I don't have specs to it.
Very useful information, could we fold something like this in as
comment in the code!?
>
> Note that after you've set POWER_ON to 0, you can also set bit 1
> (CLOCK_OFF) to 1 to turn off the clock to the power-on FSM.
Ditto.
>
>>> > + /* Need to send CMD12 if -
>>> > + * a) open-ended multiblock transfer (no CMD23)
>>> > + * b) error in multiblock transfer
>>> > + */
>>> > + if (host->mrq->stop && (data->error || !host->use_sbc)) {
>>> > + if (bcm2835_sdhost_send_command(host, host->mrq->stop)) {
>>> > + /* No busy, so poll for completion */
>>> > + if (!host->use_busy)
>>>
>>> This looks a bit weird. Can you explain why this is needed?
>>
>> Eric, any clue? Some hardware bug workaround?
>> Have a pointer to hardware specs?
>
> Would no-CMD23 transfers mean that data->blocks was 0 to mean
> indefinite? That's the only mention of CMD12 in the spec -- when you've
> set HBLC to 0, you need to CMD12 or CMD52 when you're done with the
> transfer.
Perhaps you are right, although the comments above is weird.
The driver should check if it's a request with R1B response, as to
find out when to care about busy detection. I have feeling that there
might be some odd things going on in this driver related to this. I
could be wrong through.
I advised Gerd to have a look how MMC_CAP_WAIT_WHILE_BUSY is working,
so perhaps Gerd can figure this out when he understands that part
better!?
>
>>> > +static void bcm2835_sdhost_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>>> > +{
>>>
>>> I don't find any place where you control power to the card here. Don't
>>> you need to do that?
>>
>> Eric?
>
> It looks like the card is always powered. Do you mean something else by
> power (like bringing up the FSM)? Is there something else needed in
> set_ios()?
As you told me above, you are using an external regulator to power the
card (VDD). And it seems like in this particular case this is always
powered on.
Still, my recommendation is to model this as a regulator, as it would
prevent you from hard-coding the so called mmc->ocr_mask_avail.
Instead that mask can be fetched by checking the supported voltage
levels from the regulators.
Please have a look at mmc_regulator_get_supply() and
mmc_regulator_set_ocr(), those helpers are really convenient to use.
You should be using the "vmmc" regulator for this purpose.
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v3 1/2] Documentation: mmc: sdhci-of-arasan: add description of power domain
From: Heiko Stuebner @ 2016-09-17 9:57 UTC (permalink / raw)
To: Ulf Hansson
Cc: Ziyuan Xu, Rob Herring, devicetree@vger.kernel.org,
open list:ARM/Rockchip SoC..., linux-mmc, Shawn Lin,
Doug Anderson, zhangqing
In-Reply-To: <CAPDyKFo6332LYwLk8xBz8aNQiLC+FEc5-1yY-jHPMm2ReXC=bQ@mail.gmail.com>
Am Samstag, 17. September 2016, 11:09:15 CEST schrieb Ulf Hansson:
> On 17 September 2016 at 11:01, Heiko Stuebner <heiko@sntech.de> wrote:
> > Hi,
> >
> > Am Samstag, 17. September 2016, 10:32:49 CEST schrieb Ziyuan Xu:
> >> Add power domain as a optional property for sdhci-of-arasan, which can
> >> be turned off in the so-called unused condition, such as suspend and
> >> remove. Aim to lower power requirements.
> >>
> >> Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
> >>
> >> Acked-by: Rob Herring <robh@kernel.org>
> >
> > Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> >
> > @Ulf: I guess you'll take this binding change through the mmc tree and
> > I'll
> > pick up the devicetree change.
>
> Ideally the documentation and DT change should go together, so I think
> it's better for you to pick up both.
I was more thinking about future conflicts with possible other changes during
the 4.9 cycle. We have -rc7 now, so arm-soc is pretty off limits for new
changes thus the binding change would only land in time for 4.10 and may cause
conflicts then.
> I intend to ack it, although it would be nice with some more
> information as I requested, in the change-log first.
I guess we'll just wait until you are comfortable with the change and decide
then through which trees it should go :-)
Heiko
> >> ---
> >>
> >> Changes in v3:
> >> - fix a typo
> >> - add Rob's ack-tag
> >>
> >> Changes in v2:
> >> - fix a typo
> >> - add an example code for power-domain
> >>
> >> Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 7 ++++++-
> >> 1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> >> b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt index
> >> 3404afa..eb84d29 100644
> >> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> >> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> >> @@ -1,12 +1,14 @@
> >>
> >> Device Tree Bindings for the Arasan SDHCI Controller
> >>
> >> - The bindings follow the mmc[1], clock[2], interrupt[3] and phy[4]
> >> bindings. + The bindings follow the mmc[1], clock[2], interrupt[3],
> >> phy[4]
> >> and power + domain[5] bindings.
> >>
> >> Only deviations are documented here.
> >>
> >> [1] Documentation/devicetree/bindings/mmc/mmc.txt
> >> [2] Documentation/devicetree/bindings/clock/clock-bindings.txt
> >> [3]
> >> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> >>
> >> [4] Documentation/devicetree/bindings/phy/phy-bindings.txt
> >> + [5] Documentation/devicetree/bindings/power/power_domain.txt
> >>
> >> Required Properties:
> >> - compatible: Compatibility string. One of:
> >> @@ -36,6 +38,8 @@ Optional Properties:
> >> - #clock-cells: If specified this should be the value <0>. With this
> >>
> >> property in place we will export a clock representing the Card Clock.
> >> This
> >> clock is expected to be consumed by our PHY. You must also specify + -
> >> power-domains: A phandle and PM domain as specifier defined by bindings +
> >>
> >> of the power controller specified by phandle.
> >>
> >> Example:
> >> sdhci@e0100000 {
> >>
> >> @@ -71,5 +75,6 @@ Example:
> >> phys = <&emmc_phy>;
> >> phy-names = "phy_arasan";
> >> #clock-cells = <0>;
> >>
> >> + power-domains = <&power RK3399_PD_EMMC>;
> >>
> >> status = "disabled";
> >>
> >> };
^ permalink raw reply
* Re: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option
From: Ulf Hansson @ 2016-09-17 9:12 UTC (permalink / raw)
To: Chris Brandt
Cc: Geert Uytterhoeven, Wolfram Sang, Sergei Shtylyov, Simon Horman,
linux-mmc, Linux-Renesas
In-Reply-To: <SG2PR06MB11655A641475D2E08A5A3DDC8AFE0@SG2PR06MB1165.apcprd06.prod.outlook.com>
On 13 September 2016 at 17:59, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> Hello Uffe
>
> Thank you for your reply.
>
> On 9/13/2016, Ulf Hansson wrote:
>> Because, if you have an external regulator feeding the mmc with power you
>> should set it up and use it.
>
> But in many board designs, there is no control over the regulator supply (or you would rather have your bootloader do that, not the kernel).
>
> So what this patch is doing is setting it to a default of 3.3v (for just this SoC) and if someone wants to add a regulator in the board's DT file, that will override the ocr_mask set by the driver.
That's perfectly okay to me! I just wanted to get clear picture of
*why* this change was needed.
>
>
> I'm assuming I'll have to do the same for MMC (sh_mmcif.c) once I get to that driver (I need to find my MMC PLUS card first for testing).
Okay!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v3 1/2] Documentation: mmc: sdhci-of-arasan: add description of power domain
From: Ulf Hansson @ 2016-09-17 9:09 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Ziyuan Xu, Rob Herring, devicetree@vger.kernel.org,
open list:ARM/Rockchip SoC..., linux-mmc, Shawn Lin,
Doug Anderson, zhangqing
In-Reply-To: <1516490.mHlkLq5CeM@phil>
On 17 September 2016 at 11:01, Heiko Stuebner <heiko@sntech.de> wrote:
> Hi,
>
> Am Samstag, 17. September 2016, 10:32:49 CEST schrieb Ziyuan Xu:
>> Add power domain as a optional property for sdhci-of-arasan, which can
>> be turned off in the so-called unused condition, such as suspend and
>> remove. Aim to lower power requirements.
>>
>> Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
>>
>> Acked-by: Rob Herring <robh@kernel.org>
>
> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
>
> @Ulf: I guess you'll take this binding change through the mmc tree and I'll
> pick up the devicetree change.
Ideally the documentation and DT change should go together, so I think
it's better for you to pick up both.
I intend to ack it, although it would be nice with some more
information as I requested, in the change-log first.
Kind regards
Uffe
>
>
> Heiko
>
>> ---
>>
>> Changes in v3:
>> - fix a typo
>> - add Rob's ack-tag
>>
>> Changes in v2:
>> - fix a typo
>> - add an example code for power-domain
>>
>> Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt index
>> 3404afa..eb84d29 100644
>> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> @@ -1,12 +1,14 @@
>> Device Tree Bindings for the Arasan SDHCI Controller
>>
>> - The bindings follow the mmc[1], clock[2], interrupt[3] and phy[4]
>> bindings. + The bindings follow the mmc[1], clock[2], interrupt[3], phy[4]
>> and power + domain[5] bindings.
>> Only deviations are documented here.
>>
>> [1] Documentation/devicetree/bindings/mmc/mmc.txt
>> [2] Documentation/devicetree/bindings/clock/clock-bindings.txt
>> [3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>> [4] Documentation/devicetree/bindings/phy/phy-bindings.txt
>> + [5] Documentation/devicetree/bindings/power/power_domain.txt
>>
>> Required Properties:
>> - compatible: Compatibility string. One of:
>> @@ -36,6 +38,8 @@ Optional Properties:
>> - #clock-cells: If specified this should be the value <0>. With this
>> property in place we will export a clock representing the Card Clock. This
>> clock is expected to be consumed by our PHY. You must also specify + -
>> power-domains: A phandle and PM domain as specifier defined by bindings +
>> of the power controller specified by phandle.
>>
>> Example:
>> sdhci@e0100000 {
>> @@ -71,5 +75,6 @@ Example:
>> phys = <&emmc_phy>;
>> phy-names = "phy_arasan";
>> #clock-cells = <0>;
>> + power-domains = <&power RK3399_PD_EMMC>;
>> status = "disabled";
>> };
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox