Re: [PATCH v3 0/5] mmc: Add access to RPMB partition
On 11/19/2012 07:12 PM, Krishna Konda wrote: On Sat, 2012-11-17 at 18:12 -0500, Chris Ball wrote: I've merged this to mmc-next for 3.8 now; thanks to everyone who Acked. If you have any userspace sample code that could be added to mmc-utils to show how the interface can be used, feel free to send a patch. Thanks, - Chris. Thanks Chris. Currently we dont have anything mmc-utils for using this interface. Hi, I have a test program I'll integrate in mmc-utils. Regards, Loic
Sony memory stick pro duo is not recognized
Hi, I'd like to report a problem. I was following information provided here: https://wiki.ubuntu.com/Bugs/Upstream/kernel Thanks. [1.] One line summary of the problem: Sony memory stick pro duo is not recognized [2.] Full description of the problem/report: I'm using Ubuntu 12.10 x64 on a Acer 5755G laptop. When I insert my Sony memory stick pro duo (with a memory stick duo adaptor) memory card nothing happens. It does work in Windows 7 on the same laptop. SD cards work in Ubuntu too with this card reader. (SD Host controller: Broadcom Corporation NetXtreme BCM57765 Memory Card Reader (rev 10)) [3.] Tags: kernel, sdhci-pci driver [4.] Kernel version (from /proc/version): Linux version 3.7.0-030700rc6-generic (apw@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201211162135 SMP Sat Nov 17 02:36:34 UTC 2012 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) n/a [6.] A small shell script or example program which triggers the problem (if possible) n/a [7.] Environment: lsb_release -rd: Description:Ubuntu 12.10 Release:12.10 [7.1.] Software (add the output of the ver_linux script here) /usr/src/linux-headers-3.7.0-030700rc6/scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux ultraviolence 3.7.0-030700rc6-generic #201211162135 SMP Sat Nov 17 02:36:34 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Gnu C 4.7 Gnu make 3.81 binutils 2.22.90.20120924 util-linux from package #translated from Hungarian for this bug report mount support module-init-tools 3.16 e2fsprogs 1.42.5 pcmciautils 018 PPP 2.4.5 Linux C Library 2.15 Dynamic linker (ldd) 2.15 Procps 3.3.3 Net-tools 1.60 Kbd 1.15.3 Sh-utils 8.13 Modules Loaded nls_iso8859_1 mmc_block parport_pc ppdev bnep rfcomm binfmt_misc snd_hda_codec_hdmi snd_hda_codec_realtek coretemp kvm_intel kvm ghash_clmulni_intel aesni_intel ablk_helper snd_hda_intel cryptd lrw snd_hda_codec aes_x86_64 xts snd_hwdep snd_pcm gf128mul uvcvideo snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device lib80211_crypt_tkip microcode videobuf2_core videodev wl nouveau videobuf2_vmalloc snd i915 soundcore snd_page_alloc videobuf2_memops mei ttm drm_kms_helper drm psmouse btusb lpc_ich i2c_algo_bit joydev serio_raw acer_wmi bluetooth lib80211 sparse_keymap mxm_wmi mac_hid video lp parport wmi hid_generic hid_logitech_dj usbhid hid sdhci_pci sdhci tg3 [7.2.] Processor information (from /proc/cpuinfo): cat /proc/cpuinfo processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 42 model name: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz stepping: 7 microcode: 0x25 cpu MHz: 800.000 cache size: 6144 KB physical id: 0 siblings: 8 core id: 0 cpu cores: 4 apicid: 0 initial apicid: 0 fpu: yes fpu_exception: yes cpuid level: 13 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips: 4389.95 clflush size: 64 cache_alignment: 64 address sizes: 36 bits physical, 48 bits virtual power management: (7 more cores) [7.3.] Module information (from /proc/modules): cat /proc/modules nls_iso8859_1 12714 0 - Live 0x mmc_block 27391 0 - Live 0x parport_pc 32867 0 - Live 0x ppdev 17114 0 - Live 0x bnep 18400 2 - Live 0x rfcomm 47923 12 - Live 0x binfmt_misc 17541 1 - Live 0x snd_hda_codec_hdmi 37116 1 - Live 0x snd_hda_codec_realtek 79808 1 - Live 0x coretemp 13555 0 - Live 0x kvm_intel 137787 0 - Live 0x kvm 441559 1 kvm_intel, Live 0x ghash_clmulni_intel 13260 0 - Live 0x aesni_intel 55496 0 - Live 0x ablk_helper 13598 1 aesni_intel, Live 0x snd_hda_intel 38522 5 - Live 0x cryptd 20531 3 ghash_clmulni_intel,aesni_intel,ablk_helper, Live 0x lrw 13324 1 aesni_intel, Live 0x snd_hda_codec 140413 3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel, Live 0x aes_x86_64 17256 1 aesni_intel, Live 0x xts 12952 1 aesni_intel, Live 0x snd_hwdep 17765 1 snd_hda_codec, Live 0x snd_pcm 102478 4
Re: [PATCH v2] mmc: sdhci: apply voltage range check only for non-fixed regulators
On 11/13/2012 10:23 PM, Philip Rakity wrote: Hi Marek, Is the regulator dedicated ? or is it shared ? Is it used for eMMC ? If it cannot be turned off -- then just don't list it in the regulators list for vmmc. If it CAN be turned off then need to get back to you. It is dedicated to eMMC device and can be turned off. Patch mmc: sdhci: apply voltage range check only for non-fixed regulators restored sdhci to working state after merging the regulator fix. However there are lots of error messages from sdhci driver: s3c-sdhci s3c-sdhci.0: could not set regulator OCR (-1) The only remaining problem is sdhci driver operation with dummy regulator. Right now it simply fails to initialize if dummy regulator is enabled. Do you have any idea how to fix it properly? Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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: UHS-I voltage switching on OLPC XO-1.75
Hi! 2012/11/18 Daniel Drake d...@laptop.org: On Fri, Nov 2, 2012 at 8:35 AM, Johan Rudholm jrudh...@gmail.com wrote: Good question. I’d guess that mmc_power_off/up does not work as expected here, that the card is not at all power cycled. Before going further on the find a way to quirk it route, there is something else we could look into. According to our hardware engineers, the external SD card power has been always-on until now. It is actually controlled by our embedded controller, separate from the CPU. In a test firmware, I can now control the SD card power via our OLPC EC interface, I call into that from mmc_power_up and mmc_power_down. And, with your hacky patch to make the voltage switch failure detection work, this fixes it: it tries 10 times at 1.8v then falls back to 3.3 successfully. No more problems with the power cycle. Ah, great! Then we know what the issue was at least. Then I guess that this code did not work with your driver: host-ios.clock = 0; mmc_set_ios(host); so with my original patch ([RFC/PATCH,v2] mmc: core: Fixup signal voltage switch), the clock was actually never stopped during the signal voltage switch? I guess this will need some further investigation also. So we have the option of fixing it that way: if we can fix the voltage switch failure detection, we could implement a custom vmmc regulator driver that uses our EC interface to enable and disable the SD power appropriately, solving our ability to power cycle. Being able to power cycle the SD-card might also come in handy in other situations, perhaps if a poor SD-card misbehaves in some way? SD-cards have no reset cord like eMMCs, so being able to power cycle the card feels like a good thing. On the other hand, we may have a good basis to add a quirk, triggered by the device tree, for when the hardware physically does not have 1.8v capabilities. This also seems proper, if we know we can't get 1.8V, then we shouldn't even try for it. In this way the detection will also be faster (no 10 retries). I'm also curious if there is a 3rd option. It seems like in the case of our SoC, the SoC design mandates that the SD card power is separate from the SDHCI interface - requiring either a GPIO or some other mechanism (e.g. OLPC EC) to be able to control it. I'm wondering if this is the same for all sdhci-pxa devices. And the same for all sdhci devices? Maybe the SDHCI specs would help here, but I guess they aren't public. If this is the case, the driver could have another heuristic: if there is no vmmc regulator, there is no way of cutting the card power, therefore we could avoid even trying 1.8v on the basis that we know we can't recover if things go wrong. So the driver could for instance drop the MMC_CAP_UHS_DDR50 cap if there is no way to power cycle the card? I think that sounds reasonable and according to spec, although also a little bit hard since there probably are cards out there that never require a power cycle to perform a proper voltage switch? Kind regards, Johan -- 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: FW: [PATCH v2] mmc: sdhci: apply voltage range check only for non-fixed regulators
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
Hello,
On 11/14/2012 8:11 AM, Kevin Liu wrote:
From: linux-mmc-ow...@vger.kernel.org
[mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Chris Ball
Sent: Tuesday, November 13, 2012 10:14 PM
To: Marek Szyprowski
Cc: linux-ker...@vger.kernel.org; linux-mmc@vger.kernel.org; Kyungmin
Park; Mark Brown; Liam Girdwood; Philip Rakity
Subject: Re: [PATCH v2] mmc: sdhci: apply voltage range check only for
non-fixed regulators
Hi,
On Tue, Nov 13 2012, Marek Szyprowski wrote:
On Tue, Nov 13 2012, Marek Szyprowski wrote:
Fixed regulators cannot change their voltage, so disable all voltage
range checking for them, otherwise the driver fails to operate with
fixed regulators. Up to now it worked only by luck, because
regulator_is_supported_voltage() function returned incorrect values.
Commit regulator: fix voltage check in
regulator_is_supported_voltage()
fixed that function and now additional check is needed for fixed
regulators.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/mmc/host/sdhci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index c7851c0..6f6534e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2923,7 +2923,7 @@ int sdhci_add_host(struct sdhci_host *host)
regulator_enable(host-vmmc);
#ifdef CONFIG_REGULATOR
- if (host-vmmc) {
+ if (host-vmmc regulator_count_voltages(host-vmmc) 1) {
ret = regulator_is_supported_voltage(host-vmmc, 330,
330);
if ((ret = 0) || (!(caps[0] SDHCI_CAN_VDD_330)))
Thanks for the longer explanation. I'm still missing something,
though;
what's wrong with running the check as it was with the new regulator
code?
(I haven't tried it yet.)
#ifdef CONFIG_REGULATOR
if (host-vmmc) {
ret = regulator_is_supported_voltage(host-vmmc,
330,
330);
if ((ret = 0) || (!(caps[0] SDHCI_CAN_VDD_330)))
caps[0] = ~SDHCI_CAN_VDD_330;
ret = regulator_is_supported_voltage(host-vmmc,
300,
300);
if ((ret = 0) || (!(caps[0] SDHCI_CAN_VDD_300)))
caps[0] = ~SDHCI_CAN_VDD_300;
ret = regulator_is_supported_voltage(host-vmmc,
180,
180);
if ((ret = 0) || (!(caps[0] SDHCI_CAN_VDD_180)))
caps[0] = ~SDHCI_CAN_VDD_180;
}
#endif /* CONFIG_REGULATOR */
The point is to remove unsupported voltages, so if someone sets up a
fixed regulator at 330, all of the other caps are disabled. Why
wouldn't that work without this change, and how are we supposed to
remove those caps on a fixed regulator after your patchset?
Thanks, sorry if I'm missing something obvious,
On our boards eMMC is connected to fixed 2.8V regulator, what results
in
clearing all available voltages and fail. The same situation is when
one
enable dummy regulator and try to use sdhci with it. My patch fixes
this
and restores sdhci to working state as it was before (before fixing
regulator regulator_is_supported_voltage() function and earlier when
MMC_BROKEN_VOLATGE capability was used).
I see. Sounds like a separate bug -- Philip (or anyone else), any
idea how we should be treating eMMCs with a fixed voltage here?
I think we should check the voltage range rather than the voltage
point accoring to the spec.
Otherwise some valid voltage like 2.8v will be discarded by mistake.
My below old patch aim to fix this issue.
How do you think?
-Original Message-
From: Kevin Liu [mailto:keyuan@gmail.com]
Sent: Friday, September 28, 2012 3:56 PM
To: linux-mmc@vger.kernel.org; c...@laptop.org; pie...@ossman.eu;
ulf.hans...@linaro.org; Zhangfei Gao
Cc: Haojian Zhuang; Chao Xie; Philip Rakity; Kevin Liu; Jialing Fu
Subject: [PATCH v5 03/13] mmc: sdhci: use regulator min/max voltage
range according to spec
From: Kevin Liu kl...@marvell.com
For regulator vmmc/vmmcq, use voltage range as below
3.3v/3.0v: (2.7v, 3.6v)
1.8v: (1.7v, 1.95v)
Original code use the specific value which may fail in regulator
driver if it does NOT support the specific voltage.
Signed-off-by: Jialing Fu j...@marvell.com
Signed-off-by: Kevin Liu kl...@marvell.com
Tested-by: Marek Szyprowski m.szyprow...@samsung.com
This patch restores sdhci devices to working state on Samsung boards
(tested on GONI and UniversalC210) after merging regulator: fix voltage
check in regulator_is_supported_voltage() patch to v3.7-rc6 (commit
f0f98b19e23d4426ca185e3d4ca80e6aff5ef51b). Would be great to have it
merged before the final v3.7 is out.
[GIT PULL v2] at91: fixes for 3.7-rc7
Arnd, Olof, Just for the record, I do not want to put pressure at a such late time in the 3.7-rc process. So, I just reworked that pull-request because the previous one was wrong: - wrong patch content (DT nodes with wrong size) - not all tags in patches (Jean-Christophe and Arnd tags were missing...) Just to start from a sane base if I have to rebase this work for 3.8, I let you know that I have updated this tag... The following changes since commit 641f3ce64b050961d454a0716bb6dbf528315aac: ARM: at91/usbh: fix overcurrent gpio setup (2012-11-16 10:46:29 +0100) are available in the git repository at: git://github.com/at91linux/linux-at91.git tags/at91-fixes for you to fetch changes up to 6a342d1ee6ff7d5b3e5a0665457f1772e7fe640a: ARM: at91/dts: add nodes for atmel hsmci controllers for atmel boards (2012-11-20 09:51:07 +0100) Add entries for enabling the use of sd/mmc driver on AT91. Those entries where missing for device tree use on these platforms. Ludovic Desroches (3): ARM: at91: add clocks for DT entries ARM: at91/dts: add nodes for atmel hsmci controllers for atmel SOCs ARM: at91/dts: add nodes for atmel hsmci controllers for atmel boards arch/arm/boot/dts/at91sam9260.dtsi | 9 + arch/arm/boot/dts/at91sam9263.dtsi | 18 ++ arch/arm/boot/dts/at91sam9263ek.dts | 10 ++ arch/arm/boot/dts/at91sam9g20ek_2mmc.dts| 12 arch/arm/boot/dts/at91sam9g20ek_common.dtsi | 9 + arch/arm/boot/dts/at91sam9g25ek.dts | 18 ++ arch/arm/boot/dts/at91sam9g45.dtsi | 18 ++ arch/arm/boot/dts/at91sam9m10g45ek.dts | 19 +++ arch/arm/boot/dts/at91sam9n12.dtsi | 9 + arch/arm/boot/dts/at91sam9n12ek.dts | 9 + arch/arm/boot/dts/at91sam9x5.dtsi | 18 ++ arch/arm/mach-at91/at91sam9260.c| 1 + arch/arm/mach-at91/at91sam9263.c| 2 ++ arch/arm/mach-at91/at91sam9g45.c| 2 ++ arch/arm/mach-at91/at91sam9n12.c| 1 + arch/arm/mach-at91/at91sam9x5.c | 2 ++ 16 files changed, 157 insertions(+) Bye, -- Nicolas Ferre -- 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 4/4] mmc: dw-mmc: remove complier warning
On 20/11/12 01:40, Jaehoon Chung wrote: Hi James, This patch has already merged with Arnd's patch. He also sent the same patch. Ah yes :-) Thanks James Best Regards, Jaehoon Chung On 11/19/2012 09:53 PM, James Hogan wrote: On 19/11/12 12:23, James Hogan wrote: On 08/11/12 08:35, Jaehoon Chung wrote: drivers/mmc/host/dw_mmc.c: In function 'dw_mci_prepare_command': drivers/mmc/host/dw_mmc.c:256:37: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/mmc/host/dw_mmc.c: In function 'dw_mci_set_ios': drivers/mmc/host/dw_mmc.c:805:37: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/mmc/host/dw_mmc.c: In function 'dw_mci_init_slot': drivers/mmc/host/dw_mmc.c:1849:37: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/mmc/host/dw_mmc.c: In function 'dw_mci_parse_dt': drivers/mmc/host/dw_mmc.c:2049:37: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] drivers/mmc/host/dw_mmc.c: In function 'dw_mci_probe': drivers/mmc/host/dw_mmc.c:2095:37: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Acked-by: James Hogan james.ho...@imgtec.com Chris: Is it okay to get this patch into v3.7? Thanks James -- 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 1/2] mmc: Remove redundant null check before kfree in sdio_bus.c
kfree on a null pointer is a no-op. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/mmc/core/sdio_bus.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c index 6bf6879..fdcf9e3 100644 --- a/drivers/mmc/core/sdio_bus.c +++ b/drivers/mmc/core/sdio_bus.c @@ -258,8 +258,7 @@ static void sdio_release_func(struct device *dev) sdio_free_func_cis(func); - if (func-info) - kfree(func-info); + kfree(func-info); kfree(func); } -- 1.7.4.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
[PATCH 2/2] mmc: Remove redundant null check before kfree in bus.c
kfree on a null pointer is a no-op. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/mmc/core/bus.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c index 9b68933..420cb67 100644 --- a/drivers/mmc/core/bus.c +++ b/drivers/mmc/core/bus.c @@ -225,8 +225,7 @@ static void mmc_release_card(struct device *dev) sdio_free_common_cis(card); - if (card-info) - kfree(card-info); + kfree(card-info); kfree(card); } -- 1.7.4.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] mmc: dw_mmc: enable controller interrupt before calling mmc_start_host
Hi Yuvaraj,
On 20/11/12 05:35, Yuvaraj Kumar wrote:
Its not sufficient.In my case, sdio_reset command was submitted to
dw_mmc controller before interrupts are enabled.
By looking at your log,it seems something wrong with frequency set by
your U-boot.
I'm not using U-boot, I'm booting with JTAG. In any case it works if I
revert your patch so I think the clocks are fine. I'll continue
debugging it and see if I can figure out what's happening.
Cheers
James
Best Regards
Yuvaraj
On Mon, Nov 19, 2012 at 6:50 PM, James Hogan james.ho...@imgtec.com wrote:
On 19/11/12 13:01, Yuvaraj CD wrote:
As mmc_start_host is getting called before enabling the dw_mmc controller
interrupt, there is a problem of missing the SDMMC_INT_CMD_DONE for the
very first command sent by the sdio_reset.
This problem occurs only when we disable MMC debugging i.e, MMC_DEBUG [=n].
Hence this patch enables the dw_mmc controller interrupt before
mmc_start_host.
Signed-off-by: Yuvaraj CD yuvaraj...@samsung.com
Hi Yuvaraj,
I get the following errors after this patch is applied
(2da1d7f2948900cd50d38643db39f790edb3cc96, merged in v3.7-rc5) and the
driver doesn't work as a result. Reverting it fixes the problem.
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 30Hz, actual
298922HZ div = 167)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 20Hz, actual
199680HZ div = 250)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 195765Hz, actual
195764HZ div = 255)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 40Hz, actual
399360HZ div = 125)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 30Hz, actual
298922HZ div = 167)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 20Hz, actual
199680HZ div = 250)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 195765Hz, actual
195764HZ div = 255)
mmc0: error -110 whilst initialising SD card
The interrupts are already cleared and disabled at the beginning of the
probe function, so is the following sufficient (after reverting your
patch) to fix the problem you've been observing?
Thanks
James
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index ec9b5a8..2be9899 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2266,7 +2266,6 @@ int dw_mci_probe(struct dw_mci *host)
* Enable interrupts for command done, data over, data empty, card
det,
* receive ready and error such as transmit, receive timeout, crc
error
*/
- mci_writel(host, RINTSTS, 0x);
mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER |
SDMMC_INT_TXDR | SDMMC_INT_RXDR |
DW_MCI_ERROR_FLAGS | SDMMC_INT_CD);
---
drivers/mmc/host/dw_mmc.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a23af77..729c031 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2233,6 +2233,21 @@ int dw_mci_probe(struct dw_mci *host)
else
host-num_slots = ((mci_readl(host, HCON) 1) 0x1F) + 1;
+ /*
+* Enable interrupts for command done, data over, data empty, card
det,
+* receive ready and error such as transmit, receive timeout, crc
error
+*/
+ mci_writel(host, RINTSTS, 0x);
+ mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER |
+ SDMMC_INT_TXDR | SDMMC_INT_RXDR |
+ DW_MCI_ERROR_FLAGS | SDMMC_INT_CD);
+ mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE); /* Enable mci
interrupt */
+
+ dev_info(host-dev, DW MMC controller at irq %d,
+%d bit host data width,
+%u deep fifo\n,
+host-irq, width, fifo_size);
+
/* We need at least one slot to succeed */
for (i = 0; i host-num_slots; i++) {
ret = dw_mci_init_slot(host, i);
@@ -2262,20 +2277,6 @@ int dw_mci_probe(struct dw_mci *host)
else
host-data_offset = DATA_240A_OFFSET;
- /*
-* Enable interrupts for command done, data over, data empty, card
det,
-* receive ready and error such as transmit, receive timeout, crc
error
-*/
- mci_writel(host, RINTSTS, 0x);
- mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER |
- SDMMC_INT_TXDR | SDMMC_INT_RXDR |
- DW_MCI_ERROR_FLAGS | SDMMC_INT_CD);
- mci_writel(host, CTRL,
Re: FW: [PATCH v2] mmc: sdhci: apply voltage range check only for non-fixed regulators
Hello,
On 11/20/2012 9:59 AM, Kevin Liu wrote:
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
Hello,
On 11/14/2012 8:11 AM, Kevin Liu wrote:
From: linux-mmc-ow...@vger.kernel.org
[mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Chris Ball
Sent: Tuesday, November 13, 2012 10:14 PM
To: Marek Szyprowski
Cc: linux-ker...@vger.kernel.org; linux-mmc@vger.kernel.org; Kyungmin
Park; Mark Brown; Liam Girdwood; Philip Rakity
Subject: Re: [PATCH v2] mmc: sdhci: apply voltage range check only for
non-fixed regulators
Hi,
On Tue, Nov 13 2012, Marek Szyprowski wrote:
On Tue, Nov 13 2012, Marek Szyprowski wrote:
Fixed regulators cannot change their voltage, so disable all voltage
range checking for them, otherwise the driver fails to operate with
fixed regulators. Up to now it worked only by luck, because
regulator_is_supported_voltage() function returned incorrect values.
Commit regulator: fix voltage check in
regulator_is_supported_voltage()
fixed that function and now additional check is needed for fixed
regulators.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/mmc/host/sdhci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index c7851c0..6f6534e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2923,7 +2923,7 @@ int sdhci_add_host(struct sdhci_host *host)
regulator_enable(host-vmmc);
#ifdef CONFIG_REGULATOR
- if (host-vmmc) {
+ if (host-vmmc regulator_count_voltages(host-vmmc) 1) {
ret = regulator_is_supported_voltage(host-vmmc, 330,
330);
if ((ret = 0) || (!(caps[0] SDHCI_CAN_VDD_330)))
Thanks for the longer explanation. I'm still missing something,
though;
what's wrong with running the check as it was with the new regulator
code?
(I haven't tried it yet.)
#ifdef CONFIG_REGULATOR
if (host-vmmc) {
ret = regulator_is_supported_voltage(host-vmmc,
330,
330);
if ((ret = 0) || (!(caps[0] SDHCI_CAN_VDD_330)))
caps[0] = ~SDHCI_CAN_VDD_330;
ret = regulator_is_supported_voltage(host-vmmc,
300,
300);
if ((ret = 0) || (!(caps[0] SDHCI_CAN_VDD_300)))
caps[0] = ~SDHCI_CAN_VDD_300;
ret = regulator_is_supported_voltage(host-vmmc,
180,
180);
if ((ret = 0) || (!(caps[0] SDHCI_CAN_VDD_180)))
caps[0] = ~SDHCI_CAN_VDD_180;
}
#endif /* CONFIG_REGULATOR */
The point is to remove unsupported voltages, so if someone sets up a
fixed regulator at 330, all of the other caps are disabled. Why
wouldn't that work without this change, and how are we supposed to
remove those caps on a fixed regulator after your patchset?
Thanks, sorry if I'm missing something obvious,
On our boards eMMC is connected to fixed 2.8V regulator, what results
in
clearing all available voltages and fail. The same situation is when
one
enable dummy regulator and try to use sdhci with it. My patch fixes
this
and restores sdhci to working state as it was before (before fixing
regulator regulator_is_supported_voltage() function and earlier when
MMC_BROKEN_VOLATGE capability was used).
I see. Sounds like a separate bug -- Philip (or anyone else), any
idea how we should be treating eMMCs with a fixed voltage here?
I think we should check the voltage range rather than the voltage
point accoring to the spec.
Otherwise some valid voltage like 2.8v will be discarded by mistake.
My below old patch aim to fix this issue.
How do you think?
-Original Message-
From: Kevin Liu [mailto:keyuan@gmail.com]
Sent: Friday, September 28, 2012 3:56 PM
To: linux-mmc@vger.kernel.org; c...@laptop.org; pie...@ossman.eu;
ulf.hans...@linaro.org; Zhangfei Gao
Cc: Haojian Zhuang; Chao Xie; Philip Rakity; Kevin Liu; Jialing Fu
Subject: [PATCH v5 03/13] mmc: sdhci: use regulator min/max voltage
range according to spec
From: Kevin Liu kl...@marvell.com
For regulator vmmc/vmmcq, use voltage range as below
3.3v/3.0v: (2.7v, 3.6v)
1.8v: (1.7v, 1.95v)
Original code use the specific value which may fail in regulator
driver if it does NOT support the specific voltage.
Signed-off-by: Jialing Fu j...@marvell.com
Signed-off-by: Kevin Liu kl...@marvell.com
Tested-by: Marek Szyprowski m.szyprow...@samsung.com
This patch restores sdhci devices to working state on Samsung boards
(tested on GONI and UniversalC210) after merging regulator: fix voltage
check in regulator_is_supported_voltage() patch to v3.7-rc6 (commit
f0f98b19e23d4426ca185e3d4ca80e6aff5ef51b). Would be great
Re: FW: [PATCH v2] mmc: sdhci: apply voltage range check only for non-fixed regulators
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
Hello,
On 11/20/2012 9:59 AM, Kevin Liu wrote:
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
Hello,
On 11/14/2012 8:11 AM, Kevin Liu wrote:
From: linux-mmc-ow...@vger.kernel.org
[mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Chris Ball
Sent: Tuesday, November 13, 2012 10:14 PM
To: Marek Szyprowski
Cc: linux-ker...@vger.kernel.org; linux-mmc@vger.kernel.org; Kyungmin
Park; Mark Brown; Liam Girdwood; Philip Rakity
Subject: Re: [PATCH v2] mmc: sdhci: apply voltage range check only
for
non-fixed regulators
Hi,
On Tue, Nov 13 2012, Marek Szyprowski wrote:
On Tue, Nov 13 2012, Marek Szyprowski wrote:
Fixed regulators cannot change their voltage, so disable all
voltage
range checking for them, otherwise the driver fails to operate
with
fixed regulators. Up to now it worked only by luck, because
regulator_is_supported_voltage() function returned incorrect
values.
Commit regulator: fix voltage check in
regulator_is_supported_voltage()
fixed that function and now additional check is needed for fixed
regulators.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/mmc/host/sdhci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index c7851c0..6f6534e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2923,7 +2923,7 @@ int sdhci_add_host(struct sdhci_host *host)
regulator_enable(host-vmmc);
#ifdef CONFIG_REGULATOR
- if (host-vmmc) {
+ if (host-vmmc regulator_count_voltages(host-vmmc) 1) {
ret = regulator_is_supported_voltage(host-vmmc,
330,
330);
if ((ret = 0) || (!(caps[0] SDHCI_CAN_VDD_330)))
Thanks for the longer explanation. I'm still missing something,
though;
what's wrong with running the check as it was with the new
regulator
code?
(I haven't tried it yet.)
#ifdef CONFIG_REGULATOR
if (host-vmmc) {
ret = regulator_is_supported_voltage(host-vmmc,
330,
330);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_330)))
caps[0] = ~SDHCI_CAN_VDD_330;
ret = regulator_is_supported_voltage(host-vmmc,
300,
300);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_300)))
caps[0] = ~SDHCI_CAN_VDD_300;
ret = regulator_is_supported_voltage(host-vmmc,
180,
180);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_180)))
caps[0] = ~SDHCI_CAN_VDD_180;
}
#endif /* CONFIG_REGULATOR */
The point is to remove unsupported voltages, so if someone sets up
a
fixed regulator at 330, all of the other caps are disabled.
Why
wouldn't that work without this change, and how are we supposed to
remove those caps on a fixed regulator after your patchset?
Thanks, sorry if I'm missing something obvious,
On our boards eMMC is connected to fixed 2.8V regulator, what
results
in
clearing all available voltages and fail. The same situation is when
one
enable dummy regulator and try to use sdhci with it. My patch fixes
this
and restores sdhci to working state as it was before (before fixing
regulator regulator_is_supported_voltage() function and earlier when
MMC_BROKEN_VOLATGE capability was used).
I see. Sounds like a separate bug -- Philip (or anyone else), any
idea how we should be treating eMMCs with a fixed voltage here?
I think we should check the voltage range rather than the voltage
point accoring to the spec.
Otherwise some valid voltage like 2.8v will be discarded by mistake.
My below old patch aim to fix this issue.
How do you think?
-Original Message-
From: Kevin Liu [mailto:keyuan@gmail.com]
Sent: Friday, September 28, 2012 3:56 PM
To: linux-mmc@vger.kernel.org; c...@laptop.org; pie...@ossman.eu;
ulf.hans...@linaro.org; Zhangfei Gao
Cc: Haojian Zhuang; Chao Xie; Philip Rakity; Kevin Liu; Jialing Fu
Subject: [PATCH v5 03/13] mmc: sdhci: use regulator min/max voltage
range according to spec
From: Kevin Liu kl...@marvell.com
For regulator vmmc/vmmcq, use voltage range as below
3.3v/3.0v: (2.7v, 3.6v)
1.8v: (1.7v, 1.95v)
Original code use the specific value which may fail in regulator
driver if it does NOT support the specific voltage.
Signed-off-by: Jialing Fu j...@marvell.com
Signed-off-by: Kevin Liu kl...@marvell.com
Tested-by: Marek Szyprowski m.szyprow...@samsung.com
This patch restores sdhci devices to working state
Re: FW: [PATCH v2] mmc: sdhci: apply voltage range check only for non-fixed regulators
Hello,
On 11/20/2012 12:36 PM, Kevin Liu wrote:
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
On 11/20/2012 9:59 AM, Kevin Liu wrote:
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
On 11/14/2012 8:11 AM, Kevin Liu wrote:
From: linux-mmc-ow...@vger.kernel.org
[mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Chris Ball
Sent: Tuesday, November 13, 2012 10:14 PM
To: Marek Szyprowski
Cc: linux-ker...@vger.kernel.org; linux-mmc@vger.kernel.org; Kyungmin
Park; Mark Brown; Liam Girdwood; Philip Rakity
Subject: Re: [PATCH v2] mmc: sdhci: apply voltage range check only
for non-fixed regulators
On Tue, Nov 13 2012, Marek Szyprowski wrote:
On Tue, Nov 13 2012, Marek Szyprowski wrote:
Fixed regulators cannot change their voltage, so disable all
voltage
range checking for them, otherwise the driver fails to operate
with
fixed regulators. Up to now it worked only by luck, because
regulator_is_supported_voltage() function returned incorrect
values.
Commit regulator: fix voltage check in
regulator_is_supported_voltage()
fixed that function and now additional check is needed for fixed
regulators.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/mmc/host/sdhci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index c7851c0..6f6534e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2923,7 +2923,7 @@ int sdhci_add_host(struct sdhci_host *host)
regulator_enable(host-vmmc);
#ifdef CONFIG_REGULATOR
- if (host-vmmc) {
+ if (host-vmmc regulator_count_voltages(host-vmmc) 1) {
ret = regulator_is_supported_voltage(host-vmmc,
330,
330);
if ((ret = 0) || (!(caps[0] SDHCI_CAN_VDD_330)))
Thanks for the longer explanation. I'm still missing something,
though;
what's wrong with running the check as it was with the new
regulator
code?
(I haven't tried it yet.)
#ifdef CONFIG_REGULATOR
if (host-vmmc) {
ret = regulator_is_supported_voltage(host-vmmc,
330,
330);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_330)))
caps[0] = ~SDHCI_CAN_VDD_330;
ret = regulator_is_supported_voltage(host-vmmc,
300,
300);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_300)))
caps[0] = ~SDHCI_CAN_VDD_300;
ret = regulator_is_supported_voltage(host-vmmc,
180,
180);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_180)))
caps[0] = ~SDHCI_CAN_VDD_180;
}
#endif /* CONFIG_REGULATOR */
The point is to remove unsupported voltages, so if someone sets up
a
fixed regulator at 330, all of the other caps are disabled.
Why
wouldn't that work without this change, and how are we supposed to
remove those caps on a fixed regulator after your patchset?
Thanks, sorry if I'm missing something obvious,
On our boards eMMC is connected to fixed 2.8V regulator, what
results
in
clearing all available voltages and fail. The same situation is when
one
enable dummy regulator and try to use sdhci with it. My patch fixes
this
and restores sdhci to working state as it was before (before fixing
regulator regulator_is_supported_voltage() function and earlier when
MMC_BROKEN_VOLATGE capability was used).
I see. Sounds like a separate bug -- Philip (or anyone else), any
idea how we should be treating eMMCs with a fixed voltage here?
I think we should check the voltage range rather than the voltage
point accoring to the spec.
Otherwise some valid voltage like 2.8v will be discarded by mistake.
My below old patch aim to fix this issue.
How do you think?
-Original Message-
From: Kevin Liu [mailto:keyuan@gmail.com]
Sent: Friday, September 28, 2012 3:56 PM
To: linux-mmc@vger.kernel.org; c...@laptop.org; pie...@ossman.eu;
ulf.hans...@linaro.org; Zhangfei Gao
Cc: Haojian Zhuang; Chao Xie; Philip Rakity; Kevin Liu; Jialing Fu
Subject: [PATCH v5 03/13] mmc: sdhci: use regulator min/max voltage
range according to spec
From: Kevin Liu kl...@marvell.com
For regulator vmmc/vmmcq, use voltage range as below
3.3v/3.0v: (2.7v, 3.6v)
1.8v: (1.7v, 1.95v)
Original code use the specific value which may fail in regulator
driver if it does NOT support the specific voltage.
Signed-off-by: Jialing Fu j...@marvell.com
Signed-off-by: Kevin Liu kl...@marvell.com
Tested-by: Marek Szyprowski m.szyprow...@samsung.com
This patch restores sdhci devices to
Re: [PATCH v3] regulator: treat regulators with constant volatage as fixed
Hello,
On 11/14/2012 3:01 AM, Mark Brown wrote:
On Tue, Nov 13, 2012 at 10:49:37AM +0100, Marek Szyprowski wrote:
+ if (rdev-constraints-valid_ops_mask REGULATOR_CHANGE_VOLTAGE) {
+ if (rdev-desc-n_voltages)
+ return rdev-desc-n_voltages;
+ else
+ return -EINVAL;
+ } else {
+ return 1;
+ }
Hrm, now I can read the logic I'm not convinced this is a good idea.
This will report that we have an available voltage for devices which
don't know their voltage (things like battery supplies often do this as
the voltage is unregulated) and it will mean that we are doing something
different for the case where there's only one voltage (reporting the
restricted count instead of the physically supported count).
I think we want a regulator_can_change_voltage() or possibly a count
function (though I can't see any use cases except this) which answers
the question directly instead of layering on top of this function.
Right, regulator_can_change_voltage() sounds much better than my hacky
approach. The first client would be probably sdhci/mmc driver, as
'can_change_voltage' check sounds much more appropriate than counting
available voltage values.
I will prepare patches soon.
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
--
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: FW: [PATCH v2] mmc: sdhci: apply voltage range check only for non-fixed regulators
Hi, On Tue, Nov 20 2012, Marek Szyprowski wrote: Subject: [PATCH v5 03/13] mmc: sdhci: use regulator min/max voltage range according to spec From: Kevin Liu kl...@marvell.com For regulator vmmc/vmmcq, use voltage range as below 3.3v/3.0v: (2.7v, 3.6v) 1.8v: (1.7v, 1.95v) Original code use the specific value which may fail in regulator driver if it does NOT support the specific voltage. Signed-off-by: Jialing Fu j...@marvell.com Signed-off-by: Kevin Liu kl...@marvell.com Tested-by: Marek Szyprowski m.szyprow...@samsung.com This patch restores sdhci devices to working state on Samsung boards (tested on GONI and UniversalC210) after merging regulator: fix voltage check in regulator_is_supported_voltage() patch to v3.7-rc6 (commit f0f98b19e23d4426ca185e3d4ca80e6aff5ef51b). Would be great to have it merged before the final v3.7 is out. Marek, thanks a lot for the verification! And your patch mmc: sdhci: apply voltage range check only for non-fixed regulators (commit d5b5205f2d480a47863dda0772d2d9dc47c2b51b, which has been merged in mmc-next) can be reverted if this patch merged? Yes, it can be replaced with it, although there is still an issue that need to be resolved somehow. Right now SDHCI driver fails to initialize if support for dummy regulator is enabled. Then I think the dummy issue can be resolved with your patch merged and if you can just update your patch from regulator_count_voltages(host-vmmc) 1 to regulator_count_voltages(host-vmmc) 0 to let fix regulator work. regulator_count_voltages() returns 1 for both fixed regulators and for virtual dummy regulator, so the above change makes no sense. However I was so focused on fixing the 2.8V supply case that I missed the fact that my mmc: sdhci: apply voltage range check only for non-fixed regulators patch also fixed the dummy regulator case. The conclusion is that applying both patches should finally fix the regulator issues with for the Samsung boards (2.8V supply for eMMC) and 'dummy-regulators' cases. Thanks, I've pushed v5 of mmc: sdhci: use regulator min/max voltage range according to spec to mmc-next for 3.7 with Marek's Tested-by now. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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: FW: [PATCH v2] mmc: sdhci: apply voltage range check only for non-fixed regulators
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
Hello,
On 11/20/2012 12:36 PM, Kevin Liu wrote:
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
On 11/20/2012 9:59 AM, Kevin Liu wrote:
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
On 11/14/2012 8:11 AM, Kevin Liu wrote:
From: linux-mmc-ow...@vger.kernel.org
[mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Chris Ball
Sent: Tuesday, November 13, 2012 10:14 PM
To: Marek Szyprowski
Cc: linux-ker...@vger.kernel.org; linux-mmc@vger.kernel.org;
Kyungmin
Park; Mark Brown; Liam Girdwood; Philip Rakity
Subject: Re: [PATCH v2] mmc: sdhci: apply voltage range check only
for non-fixed regulators
On Tue, Nov 13 2012, Marek Szyprowski wrote:
On Tue, Nov 13 2012, Marek Szyprowski wrote:
Fixed regulators cannot change their voltage, so disable all
voltage
range checking for them, otherwise the driver fails to operate
with
fixed regulators. Up to now it worked only by luck, because
regulator_is_supported_voltage() function returned incorrect
values.
Commit regulator: fix voltage check in
regulator_is_supported_voltage()
fixed that function and now additional check is needed for
fixed
regulators.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/mmc/host/sdhci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c
b/drivers/mmc/host/sdhci.c
index c7851c0..6f6534e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2923,7 +2923,7 @@ int sdhci_add_host(struct sdhci_host
*host)
regulator_enable(host-vmmc);
#ifdef CONFIG_REGULATOR
- if (host-vmmc) {
+ if (host-vmmc regulator_count_voltages(host-vmmc) 1)
{
ret = regulator_is_supported_voltage(host-vmmc,
330,
330);
if ((ret = 0) || (!(caps[0] SDHCI_CAN_VDD_330)))
Thanks for the longer explanation. I'm still missing something,
though;
what's wrong with running the check as it was with the new
regulator
code?
(I haven't tried it yet.)
#ifdef CONFIG_REGULATOR
if (host-vmmc) {
ret =
regulator_is_supported_voltage(host-vmmc,
330,
330);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_330)))
caps[0] = ~SDHCI_CAN_VDD_330;
ret =
regulator_is_supported_voltage(host-vmmc,
300,
300);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_300)))
caps[0] = ~SDHCI_CAN_VDD_300;
ret =
regulator_is_supported_voltage(host-vmmc,
180,
180);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_180)))
caps[0] = ~SDHCI_CAN_VDD_180;
}
#endif /* CONFIG_REGULATOR */
The point is to remove unsupported voltages, so if someone sets
up
a
fixed regulator at 330, all of the other caps are disabled.
Why
wouldn't that work without this change, and how are we supposed
to
remove those caps on a fixed regulator after your patchset?
Thanks, sorry if I'm missing something obvious,
On our boards eMMC is connected to fixed 2.8V regulator, what
results
in
clearing all available voltages and fail. The same situation is
when
one
enable dummy regulator and try to use sdhci with it. My patch
fixes
this
and restores sdhci to working state as it was before (before
fixing
regulator regulator_is_supported_voltage() function and earlier
when
MMC_BROKEN_VOLATGE capability was used).
I see. Sounds like a separate bug -- Philip (or anyone else), any
idea how we should be treating eMMCs with a fixed voltage here?
I think we should check the voltage range rather than the voltage
point accoring to the spec.
Otherwise some valid voltage like 2.8v will be discarded by mistake.
My below old patch aim to fix this issue.
How do you think?
-Original Message-
From: Kevin Liu [mailto:keyuan@gmail.com]
Sent: Friday, September 28, 2012 3:56 PM
To: linux-mmc@vger.kernel.org; c...@laptop.org; pie...@ossman.eu;
ulf.hans...@linaro.org; Zhangfei Gao
Cc: Haojian Zhuang; Chao Xie; Philip Rakity; Kevin Liu; Jialing Fu
Subject: [PATCH v5 03/13] mmc: sdhci: use regulator min/max voltage
range according to spec
From: Kevin Liu kl...@marvell.com
For regulator vmmc/vmmcq, use voltage range as below
3.3v/3.0v: (2.7v, 3.6v)
1.8v: (1.7v, 1.95v)
Original code use the specific value which may fail in regulator
driver if
Re: FW: [PATCH v2] mmc: sdhci: apply voltage range check only for non-fixed regulators
Hello,
On 11/20/2012 3:14 PM, Kevin Liu wrote:
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
Hello,
On 11/20/2012 12:36 PM, Kevin Liu wrote:
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
On 11/20/2012 9:59 AM, Kevin Liu wrote:
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
On 11/14/2012 8:11 AM, Kevin Liu wrote:
From: linux-mmc-ow...@vger.kernel.org
[mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Chris Ball
Sent: Tuesday, November 13, 2012 10:14 PM
To: Marek Szyprowski
Cc: linux-ker...@vger.kernel.org; linux-mmc@vger.kernel.org;
Kyungmin
Park; Mark Brown; Liam Girdwood; Philip Rakity
Subject: Re: [PATCH v2] mmc: sdhci: apply voltage range check only
for non-fixed regulators
On Tue, Nov 13 2012, Marek Szyprowski wrote:
On Tue, Nov 13 2012, Marek Szyprowski wrote:
Fixed regulators cannot change their voltage, so disable all
voltage
range checking for them, otherwise the driver fails to operate
with
fixed regulators. Up to now it worked only by luck, because
regulator_is_supported_voltage() function returned incorrect
values.
Commit regulator: fix voltage check in
regulator_is_supported_voltage()
fixed that function and now additional check is needed for
fixed
regulators.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/mmc/host/sdhci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c
b/drivers/mmc/host/sdhci.c
index c7851c0..6f6534e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2923,7 +2923,7 @@ int sdhci_add_host(struct sdhci_host
*host)
regulator_enable(host-vmmc);
#ifdef CONFIG_REGULATOR
- if (host-vmmc) {
+ if (host-vmmc regulator_count_voltages(host-vmmc) 1)
{
ret = regulator_is_supported_voltage(host-vmmc,
330,
330);
if ((ret = 0) || (!(caps[0] SDHCI_CAN_VDD_330)))
Thanks for the longer explanation. I'm still missing something,
though;
what's wrong with running the check as it was with the new
regulator
code?
(I haven't tried it yet.)
#ifdef CONFIG_REGULATOR
if (host-vmmc) {
ret =
regulator_is_supported_voltage(host-vmmc,
330,
330);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_330)))
caps[0] = ~SDHCI_CAN_VDD_330;
ret =
regulator_is_supported_voltage(host-vmmc,
300,
300);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_300)))
caps[0] = ~SDHCI_CAN_VDD_300;
ret =
regulator_is_supported_voltage(host-vmmc,
180,
180);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_180)))
caps[0] = ~SDHCI_CAN_VDD_180;
}
#endif /* CONFIG_REGULATOR */
The point is to remove unsupported voltages, so if someone sets
up
a
fixed regulator at 330, all of the other caps are disabled.
Why
wouldn't that work without this change, and how are we supposed
to
remove those caps on a fixed regulator after your patchset?
Thanks, sorry if I'm missing something obvious,
On our boards eMMC is connected to fixed 2.8V regulator, what
results
in
clearing all available voltages and fail. The same situation is
when
one
enable dummy regulator and try to use sdhci with it. My patch
fixes
this
and restores sdhci to working state as it was before (before
fixing
regulator regulator_is_supported_voltage() function and earlier
when
MMC_BROKEN_VOLATGE capability was used).
I see. Sounds like a separate bug -- Philip (or anyone else), any
idea how we should be treating eMMCs with a fixed voltage here?
I think we should check the voltage range rather than the voltage
point accoring to the spec.
Otherwise some valid voltage like 2.8v will be discarded by mistake.
My below old patch aim to fix this issue.
How do you think?
-Original Message-
From: Kevin Liu [mailto:keyuan@gmail.com]
Sent: Friday, September 28, 2012 3:56 PM
To: linux-mmc@vger.kernel.org; c...@laptop.org; pie...@ossman.eu;
ulf.hans...@linaro.org; Zhangfei Gao
Cc: Haojian Zhuang; Chao Xie; Philip Rakity; Kevin Liu; Jialing Fu
Subject: [PATCH v5 03/13] mmc: sdhci: use regulator min/max voltage
range according to spec
From: Kevin Liu kl...@marvell.com
For regulator vmmc/vmmcq, use voltage range as below
3.3v/3.0v: (2.7v, 3.6v)
1.8v: (1.7v, 1.95v)
Original code use the
Re: FW: [PATCH v2] mmc: sdhci: apply voltage range check only for non-fixed regulators
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
Hello,
On 11/20/2012 3:14 PM, Kevin Liu wrote:
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
Hello,
On 11/20/2012 12:36 PM, Kevin Liu wrote:
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
On 11/20/2012 9:59 AM, Kevin Liu wrote:
2012/11/20 Marek Szyprowski m.szyprow...@samsung.com:
On 11/14/2012 8:11 AM, Kevin Liu wrote:
From: linux-mmc-ow...@vger.kernel.org
[mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Chris
Ball
Sent: Tuesday, November 13, 2012 10:14 PM
To: Marek Szyprowski
Cc: linux-ker...@vger.kernel.org; linux-mmc@vger.kernel.org;
Kyungmin
Park; Mark Brown; Liam Girdwood; Philip Rakity
Subject: Re: [PATCH v2] mmc: sdhci: apply voltage range check
only
for non-fixed regulators
On Tue, Nov 13 2012, Marek Szyprowski wrote:
On Tue, Nov 13 2012, Marek Szyprowski wrote:
Fixed regulators cannot change their voltage, so disable
all
voltage
range checking for them, otherwise the driver fails to
operate
with
fixed regulators. Up to now it worked only by luck, because
regulator_is_supported_voltage() function returned
incorrect
values.
Commit regulator: fix voltage check in
regulator_is_supported_voltage()
fixed that function and now additional check is needed for
fixed
regulators.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/mmc/host/sdhci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c
b/drivers/mmc/host/sdhci.c
index c7851c0..6f6534e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2923,7 +2923,7 @@ int sdhci_add_host(struct sdhci_host
*host)
regulator_enable(host-vmmc);
#ifdef CONFIG_REGULATOR
- if (host-vmmc) {
+ if (host-vmmc regulator_count_voltages(host-vmmc)
1)
{
ret = regulator_is_supported_voltage(host-vmmc,
330,
330);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_330)))
Thanks for the longer explanation. I'm still missing
something,
though;
what's wrong with running the check as it was with the new
regulator
code?
(I haven't tried it yet.)
#ifdef CONFIG_REGULATOR
if (host-vmmc) {
ret =
regulator_is_supported_voltage(host-vmmc,
330,
330);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_330)))
caps[0] = ~SDHCI_CAN_VDD_330;
ret =
regulator_is_supported_voltage(host-vmmc,
300,
300);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_300)))
caps[0] = ~SDHCI_CAN_VDD_300;
ret =
regulator_is_supported_voltage(host-vmmc,
180,
180);
if ((ret = 0) || (!(caps[0]
SDHCI_CAN_VDD_180)))
caps[0] = ~SDHCI_CAN_VDD_180;
}
#endif /* CONFIG_REGULATOR */
The point is to remove unsupported voltages, so if someone
sets
up
a
fixed regulator at 330, all of the other caps are
disabled.
Why
wouldn't that work without this change, and how are we
supposed
to
remove those caps on a fixed regulator after your patchset?
Thanks, sorry if I'm missing something obvious,
On our boards eMMC is connected to fixed 2.8V regulator, what
results
in
clearing all available voltages and fail. The same situation
is
when
one
enable dummy regulator and try to use sdhci with it. My patch
fixes
this
and restores sdhci to working state as it was before (before
fixing
regulator regulator_is_supported_voltage() function and
earlier
when
MMC_BROKEN_VOLATGE capability was used).
I see. Sounds like a separate bug -- Philip (or anyone else),
any
idea how we should be treating eMMCs with a fixed voltage here?
I think we should check the voltage range rather than the voltage
point accoring to the spec.
Otherwise some valid voltage like 2.8v will be discarded by
mistake.
My below old patch aim to fix this issue.
How do you think?
-Original Message-
From: Kevin Liu [mailto:keyuan@gmail.com]
Sent: Friday, September 28, 2012 3:56 PM
To: linux-mmc@vger.kernel.org; c...@laptop.org; pie...@ossman.eu;
ulf.hans...@linaro.org; Zhangfei Gao
Cc: Haojian Zhuang; Chao Xie; Philip Rakity; Kevin Liu; Jialing
Fu
Re: [PATCH v1] mmc: fix async request mechanism for sequential read scenarios
Hello,
On 11/19/2012 11:34 PM, Per Förlin wrote:
if (host-areq) {
+ if (!areq)
+ mmc_prefetch_init(host-areq,
+ host-areq-mrq-completion);
mmc_wait_for_req_done(host, host-areq-mrq);
+ if (!areq) {
+ mmc_prefetch_start(host-areq, false);
+ if (mmc_prefetch_pending(host-areq))
+ return NULL;
In this case, mmc thread may be unblocked because done() arrived for
current request and not because new request notification. In such a case
we would like the done request to be handled before fetching the new
request.
I agree. We wake up and there is no pending new request execution should
proceed normally by handling the completed request.
In my code is_done_rcv flag used along with is_new_req flag in
order to differentiate the reason for mmc thread awake.
In my patch the return value of mmc_prefetch_pending() specifies if thee is a
pending request.what should happen.
If both current request is done and mmc_prefetch_pending is done at the same
time I see there is a problem with my patch. There needs to be a flag to
indicate if current request is done.
There is race between done() and NEW_REQUEST events, also when we got
both of them, the order is to complete current and then to fetch new.
I understand your motivation and idea for re-structure the patch. It is
still not clear for me how exactly mmc thread will be awaken on new
request notification in your version, but I have another problem:
mmc_request_fn() is called and it calls complete(mq-prefetch_completion) which
wakes up the current thread.
My patch is just an example. The intention is to make the patch cleaner. But I
may have missed some of the HPI aspects.
Is it the lack of functions wrappers that you are using in your example?
It's fine to skip the functions wrappers if it makes no sense.
What I want to avoid is to create new functions for data_req_start and
data_req_wait.
I would rather add this to the existing functions in core.c and keep changes in
block.c and the flow minimal.
As I understand your example, you mean to implement generic logic on
core/core.c level by using wrapper functions and leave final
implementation for MMC to card/queue.c and for SDIO layer to
card/..sdio.. (I'm not too familiar with sdio protocol implementation).
Well, it is make a lot of sense.
I still have plans to add pre/post/async support in the SDIO framework too
but I have not got to it.
I would be nice to add your NEW_REQ feature along with the other mmc-async
features, to make it usable from SDIO.
But the devil is in details - there is a lot of work in
mmc_wait_for_data_req_done(), done() callback and also error handling
changes for card/block.c
Things in core.c could be re-used in the SDIO case. In block.c there are only
FS specific implementation not relevant for SDIO.
Do you think, that wait_event() API used not suits the same semantic as
completion API?
The waiting mechanims may be wait_event or completion.
I'm not in favor of using both. Better to replace completion with wait_event if
you prefer.
I'm fine with wait_event() (block request transfers) combined with completion
(for other transfer), as long as the core.c API is intact. I don't see a reason
for a new start_data_req()
mmc_start_req() is only used by the mmc block transfers.
The main idea is to change start_req() waiting point
(mmc_wait_for_data_req_done() function) in such way that external events
(in the MMC case it is coming from block layer) may awake MMC context
from waiting for current request. This is done by change the original
mmc_start_req() function and not changing its signature of mmc_start_req().
May I ask you to see [PATCH v2] patch? I think that is is no change in
core.c API (by core.c API you mean all functions from core.h?).
Also to use new request feature of core.c one need to implement
notification similar to mmc_request_fn() and I do not see difficulties
to do it from SDIO.
Making a test case in mmc_test.c is a good way to stress test the feature (e.g.
random timing of incoming new requests) and it will show how the API works too.
BR
Per
My main concern is to avoid adding new API to core.c in order to add the
NEW_REQ feature. My patch is an example of changes to be done in core.c without
adding new functions.
We would like to have a generic capability to handle additional events,
such as HPI/stop flow, in addition to the NEW_REQUEST notification.
Therefore, an event mechanism seems to be a better design than completion.
I've looked at SDIO code and from what I can understand, right now SDIO
is not using async request mechanism and works from 'wait_for_cmd()`
level. This means that such work as exposing MMC core API's is major
change and definitely should be separate design and implementation
effort, while my current patch right now will fix mmc
Re: [RFC PATCH 3.7.0-rc4 0/4] introduce of_simple_module_id_table macro
On Fri, 16 Nov 2012 13:21:08 +, Srinivas KANDAGATLA
srinivas.kandaga...@st.com wrote:
From: Srinivas Kandagatla srinivas.kandaga...@st.com
This patch series introduces of_simple_module_id_table macro and as an example
uses this macro in 3 files.
Most of the device tree supported drivers have of_device_id table setup with
single compatible entry, this use-case is very simple and common.
#ifdef CONFIG_OF
static struct of_device_id xxx_of_match[] = {
{ .compatible = yyy,zzz },
{ },
};
MODULE_DEVICE_TABLE(of, xxx_of_match);
#endif
This patch adds a macro for this simple type of device table.
Other subsystems like pm, platform, have similar macros in kernel for
simplest cases.
Now the user can just replace the above code with
of_simple_module_id_table(xxx_of_match, yyy,zzz);
There are more than 200+ hits for this type of pattern in the current kernel.
While I like the reduction in lines of source code, I'm not so fond of
the form. There is no easy way to extend the syntax for multiple
entries and it doesn't cover the frequently present .data field. Can you
think of a way to do this that can take a variable number of table
entries?
g.
--
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: [GIT PULL] at91: fixes for 3.7-rc7
On Mon, Nov 19, 2012 at 6:29 PM, Nicolas Ferre nicolas.fe...@atmel.com wrote: If you do not take it for 3.7, maybe we will have to queue these patches on top of our AT91 pinctrl work (on Linus Walleij side), so, you do need to queue this one for the moment... Tell me what the outcome is, if I should merge some stuff on top of my pinctrl tree just send me the patches... Yours, Linus Walleij -- 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 0/5] mmc: Add access to RPMB partition
On Tue, 2012-11-20 at 09:25 +0100, Loic PALLARDY wrote: I have a test program I'll integrate in mmc-utils. Regards, Loic Loic/Linus/Chris, I think the IOCTL is not complete in terms of handling the RPMB requests. Here is why I think that is - let me know your opinion There are four request types that are needed to be supported - two under read category and two under write. They are Reads --- 1. Read Write Counter 2. Authenticated data read Writes --- 1. Provision RPMB key (though it might be done in a secure environment) 2. Authenticated data read While its given that the rpmb data frames are going to have that information encoded in it and the frames will be generated by a secure piece of code, the request types can be classified as above. The ioctl interface to do this but currently that does the following 1. Switch partition 2. Set block count 3. One command - whatever is passed in by the userspace application. So here are the set of commands that need to happen in a rpmb read operation 1. Switch partition 2. Set block count 3. Write data frame - CMD25 to write the rpmb data frame 4. Set block count 5. Read the data - CMD18 to do the actual read I am guessing that you would expect the userspace application too call into the ioctl twice to take care of the 4 5 and that might not be an issue if there was no request processed for mmcqd i.e. no other process/thread claims the host. But if that were to happen, then the rpmb operation will fail - please let me know if this assumption or my understanding of the spec is wrong. Similarly for rpmb write operation, these are the step involved 1. Switch partition 2. Set block count 3. Write data frame - CMD25 to write the rpmb data frame with data 4. Set block count 5. Read the data - CMD25 to write rpmb data frame indicating that rpmb result register is about to be read 6. Set block count 7. Read rpmb result - CMD18 to read the rpmb result register In the case of write, there are an additional two commands compared to reads. Since all of these needs to be done in one shot, I believe the current ioctl is not sufficient and this can be handled in the following ways 1. Extend the current ioctl to handle both cases 2. Add a new ioctl cmd for rpmb requests Personally I think adding another ioctl is a better way to do this since the current ioctl will get cumbersome and technically the rpmb requests are different kind of requests that need to be done atomically. I am coding this up as a separate ioctl but before I post the patch, I wanted feedback on this approach. -- Thanks, Krishna Konda --- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation --- -- 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 v1] mmc: fix async request mechanism for sequential read scenarios
Correction inside
On Tue, November 20, 2012 6:26 pm, Konstantin Dorfman wrote:
Hello,
On 11/19/2012 11:34 PM, Per Förlin wrote:
if (host-areq) {
+ if (!areq)
+ mmc_prefetch_init(host-areq,
+
host-areq-mrq-completion);
mmc_wait_for_req_done(host, host-areq-mrq);
+ if (!areq) {
+ mmc_prefetch_start(host-areq, false);
+ if (mmc_prefetch_pending(host-areq))
+ return NULL;
In this case, mmc thread may be unblocked because done() arrived for
current request and not because new request notification. In such a
case
we would like the done request to be handled before fetching the new
request.
I agree. We wake up and there is no pending new request execution
should proceed normally by handling the completed request.
In my code is_done_rcv flag used along with is_new_req flag in
order to differentiate the reason for mmc thread awake.
In my patch the return value of mmc_prefetch_pending() specifies if
thee is a pending request.what should happen.
If both current request is done and mmc_prefetch_pending is done at the
same time I see there is a problem with my patch. There needs to be a
flag to indicate if current request is done.
There is race between done() and NEW_REQUEST events, also when we got
both of them, the order is to complete current and then to fetch new.
I understand your motivation and idea for re-structure the patch. It
is
still not clear for me how exactly mmc thread will be awaken on new
request notification in your version, but I have another problem:
mmc_request_fn() is called and it calls
complete(mq-prefetch_completion) which wakes up the current thread.
My patch is just an example. The intention is to make the patch
cleaner. But I may have missed some of the HPI aspects.
Is it the lack of functions wrappers that you are using in your
example?
It's fine to skip the functions wrappers if it makes no sense.
What I want to avoid is to create new functions for data_req_start and
data_req_wait.
I would rather add this to the existing functions in core.c and keep
changes in block.c and the flow minimal.
As I understand your example, you mean to implement generic logic on
core/core.c level by using wrapper functions and leave final
implementation for MMC to card/queue.c and for SDIO layer to
card/..sdio.. (I'm not too familiar with sdio protocol
implementation).
Well, it is make a lot of sense.
I still have plans to add pre/post/async support in the SDIO
framework too but I have not got to it.
I would be nice to add your NEW_REQ feature along with the other
mmc-async features, to make it usable from SDIO.
But the devil is in details - there is a lot of work in
mmc_wait_for_data_req_done(), done() callback and also error handling
changes for card/block.c
Things in core.c could be re-used in the SDIO case. In block.c there
are only FS specific implementation not relevant for SDIO.
Do you think, that wait_event() API used not suits the same semantic
as
completion API?
The waiting mechanims may be wait_event or completion.
I'm not in favor of using both. Better to replace completion with
wait_event if you prefer.
I'm fine with wait_event() (block request transfers) combined with
completion (for other transfer), as long as the core.c API is intact. I
don't see a reason for a new start_data_req()
mmc_start_req() is only used by the mmc block transfers.
The main idea is to change start_req() waiting point
(mmc_wait_for_data_req_done() function) in such way that external events
(in the MMC case it is coming from block layer) may awake MMC context
from waiting for current request. This is done by change the original
mmc_start_req() function and not changing its signature of
mmc_start_req().
May I ask you to see [PATCH v2] patch? I think that is is no change in
core.c API (by core.c API you mean all functions from core.h?).
[PATCH v3] mmc: fix async request mechanism for sequential read scenarios
Also to use new request feature of core.c one need to implement
notification similar to mmc_request_fn() and I do not see difficulties
to do it from SDIO.
Making a test case in mmc_test.c is a good way to stress test the
feature (e.g. random timing of incoming new requests) and it will show
how the API works too.
BR
Per
My main concern is to avoid adding new API to core.c in order to add
the NEW_REQ feature. My patch is an example of changes to be done in
core.c without adding new functions.
We would like to have a generic capability to handle additional
events,
such as HPI/stop flow, in addition to the NEW_REQUEST notification.
Therefore, an event mechanism seems to be a better design than
completion.
I've looked at SDIO code and from what I can understand, right now
SDIO
is not using async request mechanism and works from 'wait_for_cmd()`
level. This means that such
Re: [GIT PULL] at91: fixes for 3.7-rc7
On 19:47 Tue 20 Nov , Linus Walleij wrote: On Mon, Nov 19, 2012 at 6:29 PM, Nicolas Ferre nicolas.fe...@atmel.com wrote: If you do not take it for 3.7, maybe we will have to queue these patches on top of our AT91 pinctrl work (on Linus Walleij side), so, you do need to queue this one for the moment... Tell me what the outcome is, if I should merge some stuff on top of my pinctrl tree just send me the patches... I send you the pull with few patch for pinctrl Best Regards, J. -- 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: dw_mmc: enable controller interrupt before calling mmc_start_host
Hi All,
Well, i didn't find the James's error message.
But i confused about the clock value.
Bus speed : 9984Hz
request : 20Hz
Div : 250
If bus_speed is divided with div, then actual value should be 399360Hz.
But this log is produced 199680Hz. What's wrong?
I think this message can be confused to debug.
Best Regards,
Jaehoon Chung
On 11/20/2012 06:39 PM, James Hogan wrote:
Hi Yuvaraj,
On 20/11/12 05:35, Yuvaraj Kumar wrote:
Its not sufficient.In my case, sdio_reset command was submitted to
dw_mmc controller before interrupts are enabled.
By looking at your log,it seems something wrong with frequency set by
your U-boot.
I'm not using U-boot, I'm booting with JTAG. In any case it works if I
revert your patch so I think the clocks are fine. I'll continue
debugging it and see if I can figure out what's happening.
Cheers
James
Best Regards
Yuvaraj
On Mon, Nov 19, 2012 at 6:50 PM, James Hogan james.ho...@imgtec.com wrote:
On 19/11/12 13:01, Yuvaraj CD wrote:
As mmc_start_host is getting called before enabling the dw_mmc controller
interrupt, there is a problem of missing the SDMMC_INT_CMD_DONE for the
very first command sent by the sdio_reset.
This problem occurs only when we disable MMC debugging i.e, MMC_DEBUG [=n].
Hence this patch enables the dw_mmc controller interrupt before
mmc_start_host.
Signed-off-by: Yuvaraj CD yuvaraj...@samsung.com
Hi Yuvaraj,
I get the following errors after this patch is applied
(2da1d7f2948900cd50d38643db39f790edb3cc96, merged in v3.7-rc5) and the
driver doesn't work as a result. Reverting it fixes the problem.
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 30Hz, actual
298922HZ div = 167)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 20Hz, actual
199680HZ div = 250)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 195765Hz, actual
195764HZ div = 255)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 40Hz, actual
399360HZ div = 125)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 30Hz, actual
298922HZ div = 167)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 20Hz, actual
199680HZ div = 250)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 195765Hz, actual
195764HZ div = 255)
mmc0: error -110 whilst initialising SD card
The interrupts are already cleared and disabled at the beginning of the
probe function, so is the following sufficient (after reverting your
patch) to fix the problem you've been observing?
Thanks
James
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index ec9b5a8..2be9899 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2266,7 +2266,6 @@ int dw_mci_probe(struct dw_mci *host)
* Enable interrupts for command done, data over, data empty, card
det,
* receive ready and error such as transmit, receive timeout, crc
error
*/
- mci_writel(host, RINTSTS, 0x);
mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER |
SDMMC_INT_TXDR | SDMMC_INT_RXDR |
DW_MCI_ERROR_FLAGS | SDMMC_INT_CD);
---
drivers/mmc/host/dw_mmc.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a23af77..729c031 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2233,6 +2233,21 @@ int dw_mci_probe(struct dw_mci *host)
else
host-num_slots = ((mci_readl(host, HCON) 1) 0x1F) +
1;
+ /*
+* Enable interrupts for command done, data over, data empty, card
det,
+* receive ready and error such as transmit, receive timeout, crc
error
+*/
+ mci_writel(host, RINTSTS, 0x);
+ mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER
|
+ SDMMC_INT_TXDR | SDMMC_INT_RXDR |
+ DW_MCI_ERROR_FLAGS | SDMMC_INT_CD);
+ mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE); /* Enable mci
interrupt */
+
+ dev_info(host-dev, DW MMC controller at irq %d,
+%d bit host data width,
+%u deep fifo\n,
+host-irq, width, fifo_size);
+
/* We need at least one slot to succeed */
for (i = 0; i host-num_slots; i++) {
ret = dw_mci_init_slot(host, i);
@@ -2262,20 +2277,6 @@ int dw_mci_probe(struct dw_mci *host)
else
host-data_offset = DATA_240A_OFFSET;
- /*
-* Enable interrupts for command
Re: [GIT PULL v2] at91: fixes for 3.7-rc7
Hi, On Tue, Nov 20, 2012 at 09:59:27AM +0100, Nicolas Ferre wrote: Arnd, Olof, Just for the record, I do not want to put pressure at a such late time in the 3.7-rc process. So, I just reworked that pull-request because the previous one was wrong: - wrong patch content (DT nodes with wrong size) - not all tags in patches (Jean-Christophe and Arnd tags were missing...) Just to start from a sane base if I have to rebase this work for 3.8, I let you know that I have updated this tag... The following changes since commit 641f3ce64b050961d454a0716bb6dbf528315aac: ARM: at91/usbh: fix overcurrent gpio setup (2012-11-16 10:46:29 +0100) are available in the git repository at: git://github.com/at91linux/linux-at91.git tags/at91-fixes The new patches seem to belong in an at91/dt branch, not in a fixes one. I can pull in the previous fixes branch as an at91/fixes-non-critical for 3.8 if you want. There's no need to rebase them for this, is there? What is the pinctrl dependency that you are talking about, are some of these patches needed as prerequisites for pinctrl changes or the other way around? Sorry if I've missed more elaborate emails on this and are asking repeat questions. ;) -Olof -- 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
