On 05/29/2015 03:06 PM, Eric Anholt wrote:
> We're currently using a fixed frequency clock specified in the DT, so
> enabling is a no-op. However, the RPi firmware-based clocks driver
> can actually disable unused clocks, so when switching to use it we
> ended up losing our MMC clock once all devi
On 01/15/2015 09:12 AM, Tomeu Vizoso wrote:
Signed-off-by: Tomeu Vizoso
Ah, having read the explanation in the next patch, I think ...
diff --git a/Documentation/devicetree/bindings/mmc/mmc,pwrseq-simple.txt
b/Documentation/devicetree/bindings/mmc/mmc,pwrseq-simple.txt
+- delay : delay t
On 01/15/2015 09:12 AM, Tomeu Vizoso wrote:
Signed-off-by: Tomeu Vizoso
Some explanation of why such a delay might be useful would be ... useful!
--
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
On 12/14/2014 09:48 PM, Tim Kryger wrote:
On Sat, Dec 13, 2014 at 11:22 PM, Bjorn Andersson wrote:
...
Or simply; what is vmmc (in the code) supposed to represent?
Hi Bjorn,
VMMC is the supply that delivers power out to the SD card itself (aka VDD).
It is not the internal power rail/power
On 11/05/2014 12:00 AM, Scott Branden wrote:
> On 14-11-04 08:59 PM, Stephen Warren wrote:
>> On 10/30/2014 12:36 AM, Scott Branden wrote:
>>> Add a verify option to driver to print out an error message if a
>>> potential back to back write could cause a clock domain
On 11/05/2014 12:02 AM, Scott Branden wrote:
> On 14-11-04 09:00 PM, Stephen Warren wrote:
>> On 10/30/2014 12:36 AM, Scott Branden wrote:
>>> SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 is missing and needed for this
>>> controller.
>>
>> This seems fine, althou
On 11/04/2014 11:55 PM, Scott Branden wrote:
> On 14-11-04 08:57 PM, Stephen Warren wrote:
>> On 10/30/2014 12:36 AM, Scott Branden wrote:
>>> The bcm2835 has clock domain issues when back to back writes to certain
>>> registers are written. The existing driver w
On 10/30/2014 12:36 AM, Scott Branden wrote:
> SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 is missing and needed for this controller.
This seems fine, although any explanation of why this quirk is needed
would be useful.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of
On 10/30/2014 12:36 AM, Scott Branden wrote:
> Add a verify option to driver to print out an error message if a
> potential back to back write could cause a clock domain issue.
> index f8c450a..11af27f 100644
> +#ifdef CONFIG_MMC_SDHCI_BCM2835_VERIFY_WORKAROUND
> + struct sdhci_pltfm_host *pl
On 10/30/2014 12:36 AM, Scott Branden wrote:
> The bcm2835 has clock domain issues when back to back writes to certain
> registers are written. The existing driver works around this issue with
> udelay. A more efficient method is to store the 8 and 16 bit writes
> to the registers affected and th
On 10/30/2014 12:36 AM, Scott Branden wrote:
> Make the shift calculations consistent rather than having different
> implementations to calculate the same thing.
> diff --git a/drivers/mmc/host/sdhci-bcm2835.c
> b/drivers/mmc/host/sdhci-bcm2835.c
> +#define REG_OFFSET_IN_BITS(reg) ((reg) << 3 &
On 10/30/2014 12:36 AM, Scott Branden wrote:
> Add a verify option to driver to print out an error message if a
> potential back to back write could cause a clock domain issue.
> diff --git a/drivers/mmc/host/sdhci-bcm2835.c
> b/drivers/mmc/host/sdhci-bcm2835.c
> static inline void bcm2835_sdhc
On 10/15/2014 10:43 AM, Scott Branden wrote:
> Added quirk SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 present in controller.
> Removed udelay in write ops by using shadow registers for 16 bit
> accesses to 32-bit registers (where necessary).
> Optimized 32-bit operations when doing 8/16 register accesses.
On 10/14/2014 08:01 PM, Scott Branden wrote:
> Added quirk SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 present in controller.
> Removed udelay in write ops by using shadow registers for 16 bit
> accesses to 32-bit registers (where necessary).
> Optimized 32-bit operations when doing 8/16 register accesses.
From: Stephen Warren
As soon as the CD IRQ is requested, it can trigger, since it's an
externally controlled event. If it does, delayed_work host->detect will
be scheduled.
Many host controller probe()s are roughly structured as:
*_probe() {
host = sdhci_pltfm_init();
mmc_of_pa
From: Stephen Warren
As soon as the CD IRQ is requested, it can trigger, since it's an
externally controlled event. If it does, delayed_work host->detect will
be scheduled.
Many host controller probe()s are roughly structured as:
*_probe() {
host = sdhci_pltfm_init();
mmc_of_pa
On 09/18/2014 12:49 AM, Adrian Hunter wrote:
On 09/18/2014 08:25 AM, Adrian Hunter wrote:
On 09/17/2014 10:57 PM, Stephen Warren wrote:
On 09/17/2014 01:55 PM, Ulf Hansson wrote:
On 12 September 2014 19:18, Stephen Warren wrote:
From: Stephen Warren
As soon as the CD IRQ is requested, it
On 09/17/2014 11:25 PM, Adrian Hunter wrote:
On 09/17/2014 10:57 PM, Stephen Warren wrote:
On 09/17/2014 01:55 PM, Ulf Hansson wrote:
On 12 September 2014 19:18, Stephen Warren wrote:
From: Stephen Warren
As soon as the CD IRQ is requested, it can trigger, since it's an
exter
On 09/17/2014 01:55 PM, Ulf Hansson wrote:
On 12 September 2014 19:18, Stephen Warren wrote:
From: Stephen Warren
As soon as the CD IRQ is requested, it can trigger, since it's an
externally controlled event. If it does, delayed_work host->detect will
be scheduled.
Many host co
From: Stephen Warren
As soon as the CD IRQ is requested, it can trigger, since it's an
externally controlled event. If it does, delayed_work host->detect will
be scheduled.
Many host controller probe()s are roughly structured as:
*_probe() {
host = sdhci_pltfm_init();
mmc_of_pa
On 09/11/2014 04:03 PM, Stephen Warren wrote:
Running Fedora rawhides's 3.17.0-0.rc4.git2.1.fc22.armv7hl kernel on
Jetson TK1 (an ARM board containing Tegra SoC), I see the following
during boot most times the Tegra SDHCI driver defers probe for the SD slot:
(and indeed I can reproduc
Running Fedora rawhides's 3.17.0-0.rc4.git2.1.fc22.armv7hl kernel on
Jetson TK1 (an ARM board containing Tegra SoC), I see the following
during boot most times the Tegra SDHCI driver defers probe for the SD slot:
[8.377719] sdhci-tegra 700b0400.sdhci: Got CD GPIO #170.
[8.377780] sdhci
On 06/19/2014 06:28 AM, Russell King - ARM Linux wrote:
> On Mon, Jun 16, 2014 at 02:17:30PM +0200, Ulf Hansson wrote:
>> Anyway, we did get some folks to test the patches and was thus fairly
>> confident that we could merge them. Chris asked me to try to collect
>> them in a PR for him, so I did.
On 06/16/2014 03:55 PM, Russell King - ARM Linux wrote:
> On Mon, Jun 16, 2014 at 01:56:16PM -0400, Matt Porter wrote:
>> Since 5d01b7684b7e "mmc: simplify SDHCI Kconfig dependencies",
>> MMC_SDHCI_PLTFM is no longer selected by the BCM Kona SDHCI
>> driver which is enabled in this defconfig. This
From: Stephen Warren
Following 5d01b7684b7e "mmc: simplify SDHCI Kconfig dependencies",
SDHCI drivers that use MMC_SDHCI_PLTFM no longer select it, but
instead depend on it. This means that multi_v7_defconfig no longer
selects it, and hence many SDHCI drivers are no longer enabled.
On 05/23/2014 02:29 AM, Michael Olbrich wrote:
> On Thu, May 22, 2014 at 01:23:27PM -0600, Stephen Warren wrote:
>> On 05/22/2014 12:21 PM, Sascha Hauer wrote:
>>> On Thu, May 22, 2014 at 10:16:35AM -0600, Stephen Warren wrote:
>>>> On 05/22/2014 09:30 AM, Sa
On 05/23/2014 03:23 AM, Sascha Hauer wrote:
...
> Speaking of which my preferred solution is another one. As a bootloader
> developer it really annoys me that I don't have the possibility to tell
> the kernel to boot a particular device. What I really want to do is to
> pass a devicetree phandle to
On 05/22/2014 12:21 PM, Sascha Hauer wrote:
> On Thu, May 22, 2014 at 10:16:35AM -0600, Stephen Warren wrote:
>> On 05/22/2014 09:30 AM, Sascha Hauer wrote:
>>> Hi all,
>>>
>>> The wish to have persistent MMC block device names for passing a suitable
>>
On 05/22/2014 09:30 AM, Sascha Hauer wrote:
> Hi all,
>
> The wish to have persistent MMC block device names for passing a suitable
> root=/dev/mmcblkX option came up several times already and has been discussed
> at least in these threads:
>
> http://lists.infradead.org/pipermail/linux-arm-kerne
h the driver does not support yet.
What's the status of patches 1 and 2 in this series? I assumed they'd be
applied to the MMC tree. I've had them applied to my local development
tree for a while now, so in case this helps:
Tested-by: Stephen Warren
Acked-by: Stephen Warren
(I th
and BT support for CuBox.
>
> The questions over how to handle these devices were never properly settled,
> so I recommend against merging patch 34 onwards. As for the rest, I'm not
> planning on any further work, so it may be a good idea for people to
> consider testing them wi
On 04/23/2014 01:08 PM, Russell King wrote:
> Signed-off-by: Russell King
A patch description would be useful so I can work out why...
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> config MMC_SDHCI
> - tristate "Secure Digital Host Controller Interface support"
> -
On 04/16/2014 05:08 PM, Andrew Bresticker wrote:
> VDDIO_SDMMC3 is the VQMMC (I/O) supply, not the VMMC (core) supply,
> for the SD slot on Venice2.
I've applied this (one patch) to Tegra's for-3.16/dt branch.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a
On 04/15/2014 06:29 PM, Andrew Bresticker wrote:
>> sdhci@0,700b0600 {
>> status = "okay";
>> bus-width = <8>;
>> + vqmmc-supply = <&vddio_1v8>;
>
> It turns out this bit isn't needed as the initialization failures are
> instead due to +3V3_RUN
On 04/14/2014 07:42 PM, Andrew Bresticker wrote:
> VDDIO_SDMMC3 is the VQMMC supply, not the VMMC supply, for the SD
> slot. Add 1.8V_VDDIO as the VQMMC supply for the eMMC.
Is there documentation re: what vmmc-supply and vqmmc-supply actually
refer to? I looked a long while ago and couldn't find
On 04/14/2014 07:42 PM, Andrew Bresticker wrote:
> If regulator_get_optional() returns EPROBE_DEFER, it indicates
> that the regulator may show up later (e.g. the DT property is
> present but the corresponding regulator may not have probed).
> Instead of continuing without the regulator, return EPR
On 04/14/2014 07:42 PM, Andrew Bresticker wrote:
> Tegra SDHCI controllers, by default, report a base clock frequency
> of 208Mhz in SDHCI_CAPABILTIES which may or may not be equal to the
> actual base clock frequency.
Some explanation of why this "may or may not be equal to the actual base
clock
On 04/01/2014 02:35 PM, ste...@agner.ch wrote:
> From: Stefan Agner
>
> By using the SD/MMC host device ID as a starting point for block
> device numbering, one can reliably predict the first block device
> name (at least for the first controller).
That's not true. There's no guarantee that a de
tless detecting accesses to this register and
> manually setting the SDHCI_WRITE_PROTECT as it has no effect.
>
> This means that the whole of tegra_sdhci_readl() can be removed and
> we can use the builtin sdhci readl functionality here.
Acked-by: Stephen Warren
> =-DO NOT APP
From: Stephen Warren
Tegra124's MMC controller is very similar to earlier SoC generations,
and can be supported by the same driver.
However, there are some non-backwards-compatible HW differences, and
hence a new DT compatible value must be used to describe the HW. This
patch updates the d
On 12/19/2013 02:05 AM, Dong Aisheng wrote:
> On Thu, Dec 19, 2013 at 7:00 AM, Stephen Warren wrote:
>> On 12/18/2013 03:27 PM, Stephen Warren wrote:
>>> From: Stephen Warren
>>>
>>> In mmc_do_calc_max_discard(), if only a single erase block can be
>&g
On 12/19/2013 02:01 AM, Adrian Hunter wrote:
> On 19/12/13 01:00, Stephen Warren wrote:
>> On 12/18/2013 03:27 PM, Stephen Warren wrote:
>>> From: Stephen Warren
>>>
>>> In mmc_do_calc_max_discard(), if only a single erase block can be
>>> discarde
On 12/19/2013 01:39 AM, Dong Aisheng wrote:
> On Thu, Dec 19, 2013 at 6:27 AM, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> In mmc_do_calc_max_discard(), if only a single erase block can be
>> discarded within the host controller's timeout, don'
On 12/18/2013 03:27 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> In mmc_do_calc_max_discard(), if only a single erase block can be
> discarded within the host controller's timeout, don't allow discard
> operations at all.
>
> Previously, the code allowed s
From: Stephen Warren
In mmc_do_calc_max_discard(), if only a single erase block can be
discarded within the host controller's timeout, don't allow discard
operations at all.
Previously, the code allowed sector-at-a-time discard (rather than
erase-block-at-a-time), which was chroni
On 12/17/2013 08:32 PM, Dong Aisheng wrote:
> On Wed, Dec 18, 2013 at 1:27 AM, Stephen Warren wrote:
>> On 12/17/2013 02:25 AM, Dong Aisheng wrote:
>>> Hi Stephen,
>>>
>>> On Sat, Dec 14, 2013 at 6:43 AM, Stephen Warren
>>> wrote:
>>>> On
On 12/18/2013 04:08 AM, Adrian Hunter wrote:
> On 17/12/13 20:02, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> In mmc_do_calc_max_discard(), if any value has been assigned to qty,
>> that value must have passed the timeout checks in the loop. Hence,
>> q
From: Stephen Warren
In mmc_do_calc_max_discard(), if any value has been assigned to qty,
that value must have passed the timeout checks in the loop. Hence,
qty is the maximum number of erase blocks that fit within the timeout,
not the first value that does not fit into the timeout. In turn
On 12/17/2013 02:25 AM, Dong Aisheng wrote:
> Hi Stephen,
>
> On Sat, Dec 14, 2013 at 6:43 AM, Stephen Warren wrote:
>> On one of my eMMC devices, I see the following results from calling
>> mmc_do_calc_max_discard() with various parameters:
>>
>> [3.0572
On 12/13/2013 03:43 PM, Stephen Warren wrote:
> On one of my eMMC devices, I see the following results from calling
> mmc_do_calc_max_discard() with various parameters:
>
> [3.057263] MMC_DISCARD_ARG max_discard 1
> [3.057266] MMC_ERASE_ARG max_discard 4096
> [3.05
From: Stephen Warren
Tegra124's MMC controller is very similar to earlier SoC generations,
and can be supported by the same driver.
However, there are some non-backwards-compatible HW differences, and
hence a new DT compatible value must be used to describe the HW. This
patch updates the d
On one of my eMMC devices, I see the following results from calling
mmc_do_calc_max_discard() with various parameters:
[3.057263] MMC_DISCARD_ARG max_discard 1
[3.057266] MMC_ERASE_ARG max_discard 4096
[3.057267] MMC_TRIM_ARGmax_discard 1
This causes mmc_calc_max_discard() to re
From: Stephen Warren
Tegra124's MMC controller is very similar to earlier SoC generations,
and can be supported by the same driver.
However, there are some non-backwards-compatible HW differences, and
hence a new DT compatible value must be used to describe the HW. This
patch updates the d
From: Stephen Warren
Tegra124's MMC controller is very similar to earlier SoC generations,
and can be supported by the same driver.
However, there are some non-backwards-compatible HW differences, and
hence a new DT compatible value must be used to describe the HW. This
patch updates the d
When I run "shutdown -h now" in next-20131030, I get a hung task.
git bisect shows that the first problem that shows up is due to 35a8fca
"mmc: sdhci: Turn tuning timeout timer into delayed work", which yields
the following crash immediately that poweroff happens:
> [ 76.314514] BUG: scheduling
On 09/22/2013 08:38 PM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> On embedded devices, there is often a combination of removable mmc
> devices (e.g. MMC/SD cards) and hard wired ones (e.g. eMMC).
> Depending on the hardware configuration, the 'mmcblkN' node might
> change if the removable de
On 09/20/2013 10:37 AM, Dirk Behme wrote:
> Am 20.09.2013 18:05, schrieb Stephen Warren:
>> On 09/18/2013 11:22 PM, Dirk Behme wrote:
>> ...
>>> If you have an embedded system were you just care a little about boot
>>> time you don't want to do anything like U
On 09/20/2013 12:30 AM, Chaiken, Alison wrote:
> Stephen Warren writes:
>> Patches to make mmc block devices have static names have been proposed
>> in the past and rejected. I think the main reason is that the block
>> device names are (or can be) dynamic, so anything that as
On 09/18/2013 11:22 PM, Dirk Behme wrote:
...
> If you have an embedded system were you just care a little about boot
> time you don't want to do anything like U-Boot's "part uuid" every time
> you boot. Or even worse, you just have a minimalistic boot loader (e.g.
> U-Boot's SPL) which doesn't kno
On 09/17/2013 02:00 AM, Axel Lin wrote:
> This avoid duplicated implementation.
Acked-by: Stephen Warren
--
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.
On 09/18/2013 11:01 AM, Dirk Behme wrote:
> Am 18.09.2013 17:17, schrieb Stephen Warren:
>> On 09/17/2013 12:04 PM, Fabio Estevam wrote:
>>> Hi Dirk,
>>>
>>> I have adapted your patch at:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-
On 09/17/2013 12:04 PM, Fabio Estevam wrote:
> Hi Dirk,
>
> I have adapted your patch at:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
>
> and tested it on 3.12-rc1 on a mx6qsabresd board.
>
> Do you have plans to submit it? Maybe as a RFC?
>
> It solves the mmc
On 09/14/2013 06:30 AM, Tomasz Figa wrote:
...
> Just as a side note, correct name is Synopsys, not Synopsis. There are
> multiple places around Documentation/devicetree where this typo is
> present[1]. Should we consider correcting this or the typo will have
> to stay?
>
> [1] git grep -i synopsi
On 09/09/2013 09:33 AM, dingu...@altera.com wrote:
> From: Dinh Nguyen
>
> Add bindings for SD/MMC for SOCFPGA.
> diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
> b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
> +* Altera SOCFPGA specific extensions to the
On 08/23/2013 05:01 PM, Dinh Nguyen wrote:
> On Fri, 2013-08-23 at 16:29 -0600, Stephen Warren wrote:
>> On 08/23/2013 09:44 AM, dingu...@altera.com wrote:
>>> From: Dinh Nguyen
>>>
>>> Add bindings for SD/MMC for SOCFPGA.
>>
>>> diff --git
On 08/23/2013 09:44 AM, dingu...@altera.com wrote:
> From: Dinh Nguyen
>
> Add bindings for SD/MMC for SOCFPGA.
> diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
> b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
> +* altr,sysmgr: Should be the phandle to the
On 08/21/2013 01:48 PM, Dinh Nguyen wrote:
> On Fri, 2013-08-16 at 16:36 -0600, Stephen Warren wrote:
>> On 08/14/2013 10:48 AM, dingu...@altera.com wrote:
>>> From: Dinh Nguyen
>>>
>>> Add bindings for SD/MMC for SOCFPGA.
>>
>>> diff --git
On 08/14/2013 10:48 AM, dingu...@altera.com wrote:
> From: Dinh Nguyen
>
> Add bindings for SD/MMC for SOCFPGA.
> diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
> b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
> +* altr,sysmgr: Should be the phandle to the
On 08/13/2013 11:29 PM, Olof Johansson wrote:
> On Mon, Aug 12, 2013 at 05:15:01PM -0600, Stephen Warren wrote:
>> On 08/08/2013 04:55 PM, dingu...@altera.com wrote:
>>> From: Dinh Nguyen
>>>
>>> Remove the "samsung" in "samsung,dw-mshc-c
On 08/13/2013 02:17 PM, Dinh Nguyen wrote:
> On Tue, 2013-08-13 at 14:10 -0600, Stephen Warren wrote:
>> On 08/13/2013 01:58 PM, Dinh Nguyen wrote:
>>> On Tue, 2013-08-13 at 13:52 -0600, Stephen Warren wrote:
>>>> On 08/12/2013 09:49 AM, dingu...@altera.com
On 08/13/2013 01:58 PM, Dinh Nguyen wrote:
> On Tue, 2013-08-13 at 13:52 -0600, Stephen Warren wrote:
>> On 08/12/2013 09:49 AM, dingu...@altera.com wrote:
>>> From: Dinh Nguyen
>>>
>>> Add bindings for SD/MMC for SOCFPGA.
>>> Add "syscon" to
etree/bindings/mmc/socfpga-dw-mshc.txt
I think it's reasonable to define one binding as being based on another
plus some additions, so, the binding,
Acked-by: Stephen Warren
> +Example:
> + dwmmc0@ff704000 {
> + compatible = "altr,socfpga-dw-mshc",
On 08/08/2013 04:55 PM, dingu...@altera.com wrote:
> From: Dinh Nguyen
>
> Remove the "samsung" in "samsung,dw-mshc-ciu-div",
> "samsung,dw-mshc-sdr-timing",
> and "samsung,dw-mshc-ddr-timing". These characteristics are not applicable to
> just Samsung platforms, but to any platform that uses th
On 08/09/2013 04:41 PM, Dinh Nguyen wrote:
> On Fri, 2013-08-09 at 15:00 -0600, Stephen Warren wrote:
>> On 08/08/2013 05:10 PM, Dinh Nguyen wrote:
>>> On Thu, 2013-08-08 at 15:13 -0600, Stephen Warren wrote:
>> ...
>>>> Why is there a need to directly
On 08/08/2013 05:10 PM, Dinh Nguyen wrote:
> On Thu, 2013-08-08 at 15:13 -0600, Stephen Warren wrote:
...
>> Why is there a need to directly represent the divider anywhere? The
>> driver can find the rate of the input clock, and I assume it knows what
>> rate it wants the cloc
On 08/08/2013 02:54 PM, Dinh Nguyen wrote:
> On Thu, 2013-08-08 at 14:37 -0600, Stephen Warren wrote:
>> On 08/08/2013 02:32 PM, Dinh Nguyen wrote:
>>> On Thu, 2013-08-08 at 14:14 -0600, Stephen Warren wrote:
>>>> On 08/05/2013 02:43 PM, dingu...@altera.com
On 08/08/2013 02:32 PM, Dinh Nguyen wrote:
> On Thu, 2013-08-08 at 14:14 -0600, Stephen Warren wrote:
>> On 08/05/2013 02:43 PM, dingu...@altera.com wrote:
>>> From: Dinh Nguyen
>>>
>>> Add bindings for SD/MMC for SOCFPGA.
>>> Add "syscon&q
On 08/05/2013 02:43 PM, dingu...@altera.com wrote:
> From: Dinh Nguyen
>
> Add bindings for SD/MMC for SOCFPGA.
> Add "syscon" to the "altr,sys-mgr" binding.
> diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
> b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
>
On 07/29/2013 12:20 AM, Guennadi Liakhovetski wrote:
> Hi Stephen
>
> On Fri, 26 Jul 2013, Stephen Warren wrote:
>
>> On 07/26/2013 02:23 PM, Guennadi Liakhovetski wrote:
>>> Hi Stephen
>>>
>>> On Fri, 26 Jul 2013, Stephen Warren wrote:
>>&
On 07/29/2013 07:30 AM, Guennadi Liakhovetski wrote:
> On Mon, 29 Jul 2013, Pawel Moll wrote:
>
>> On Mon, 2013-07-29 at 13:05 +0100, Guennadi Liakhovetski wrote:
>>> No, that's exactly the problem. We absolutely do not want to write
>>> compatible="vendor,soc-v1"; in a .dts file for SoC v2 just
On 07/26/2013 02:23 PM, Guennadi Liakhovetski wrote:
> Hi Stephen
>
> On Fri, 26 Jul 2013, Stephen Warren wrote:
>
>> On 07/26/2013 09:51 AM, Guennadi Liakhovetski wrote:
>>> Add DT properties for UHS SDR12, SDR25, SDR50, SDR104 and DDR50 modes and
>>> for su
On 07/26/2013 02:44 PM, Dinh Nguyen wrote:
> On Fri, 2013-07-26 at 14:02 -0600, Stephen Warren wrote:
>> On 07/26/2013 01:33 PM, Dinh Nguyen wrote:
>>> On Fri, 2013-07-26 at 11:24 -0600, Stephen Warren wrote:
>>>> On 07/25/2013 04:04 PM, dingu...@altera.com
On 07/26/2013 01:33 PM, Dinh Nguyen wrote:
> On Fri, 2013-07-26 at 11:24 -0600, Stephen Warren wrote:
>> On 07/25/2013 04:04 PM, dingu...@altera.com wrote:
>>> From: Dinh Nguyen
>>>
>>> Add bindings for SD/MMC for SOCFPGA.
>>> Add "syscon
On 07/25/2013 04:04 PM, dingu...@altera.com wrote:
> From: Dinh Nguyen
>
> Add bindings for SD/MMC for SOCFPGA.
> Add "syscon" to the "altr,sys-mgr" binding.
> diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
> b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
>
On 07/26/2013 09:51 AM, Guennadi Liakhovetski wrote:
> Add DT properties for UHS SDR12, SDR25, SDR50, SDR104 and DDR50 modes and
> for supported by the host in DDR mode VccQ values. Adding them to DT will
> automatically enable respective MMC host capabilities.
> diff --git a/Documentation/devicet
On 07/24/2013 02:09 AM, Steffen Trumtrar wrote:
> Hi!
>
> Embedded devices often use multiple SD/MMC devices as boot/rootfs disks.
> Some of them are removable, some not. If the removable cards are not
> present, but are probed before the non-removable ones, the indexing
> scheme changes. This mak
ve is expected to fail by returning
> -ENODEV.
>
> This patch adds the proper check for the pointer before calling it.
Tested-by: Stephen Warren
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
Mo
It looks like commit 7628774 "mmc: core: Handle card shutdown from
mmc_bus" causes a crash during "reboot" at least on Tegra platforms. The
issue appears to be in:
> static void mmc_bus_shutdown(struct device *dev)
> {
> struct mmc_driver *drv = to_mmc_driver(dev->driver);
> struct mmc
On 06/11/2013 05:33 PM, Scott Wood wrote:
> I get the following lockdump output on p2020rdb using
> v3.10-rc5-43-g34376a5. While it's not particularly polite for the
> esdhc driver to be calling OF functions while holding another lock which
> can be acquired from interrupt context, why is devtree_
On 06/09/2013 02:14 PM, Simon Baatz wrote:
> Signed-off-by: Simon Baatz
Tested-by: Stephen Warren
(On Seaboard/Springbank board, i.e. Tegra20)
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> +err_parse_dt:
> err_power_req:
> err_alloc_tegra_h
On 06/05/2013 01:01 AM, Linus Walleij wrote:
> On Tue, Jun 4, 2013 at 2:05 PM, Heiko Stübner wrote:
...
>> The only problem is the pull stuff mentioned above that is either pull up or
>> down without the driver having knowledge about it. And generic_pinconf only
>> knows about them separately righ
On 05/08/2013 11:55 PM, Christian Daudt wrote:
> Add SDHCI driver for the Broadcom 281xx SoCs. Also
> add bindings for it into bcm281xx dts files.
> Still missing:
> - power managemement
> diff --git a/drivers/mmc/host/sdhci-bcm-kona.c
> b/drivers/mmc/host/sdhci-bcm-kona.c
> + /*
> + *
On 03/11/2013 02:44 PM, Stephen Warren wrote:
> In order to convert the Tegra MMC driver to using mmc_of_parse(), some
> bugs in the Tegra device-tree content need to be fixed first; it's
> currently wrong but unused, and mmc_of_parse() causes that data to be
> used for the firs
t.
>
> This patch also makes the sdhci_pltfm_data declarations const where possible.
The Tegra parts of the series,
Acked-by: Stephen Warren
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
On 03/12/2013 04:52 AM, Lars-Peter Clausen wrote:
> The sdhci_pltfm_data struct is never modified within the sdhci_pltfm module.
> So
> make the pdata parameter to sdhci_pltfm_init and sdhci_pltfm_register const.
> This allows drivers to declare their sdhci_pltfm_data struct as const.
>
> This pa
From: Joseph Lo
Updating the sdhci-tegra driver to use mmc_of_parse to support standard
MMC DT bindings. Then we can remove the redundant code that already support
in generic MMC core.
Signed-off-by: Joseph Lo
Tested-by: Thierry Reding
Signed-off-by: Stephen Warren
---
Chris, this patch
In order to convert the Tegra MMC driver to using mmc_of_parse(), some
bugs in the Tegra device-tree content need to be fixed first; it's
currently wrong but unused, and mmc_of_parse() causes that data to be
used for the first time.
On 03/08/2013 09:27 PM, Kevin Liu wrote:
> 2013/3/9 Stephen Warren :
>> On 03/07/2013 09:52 PM, Kevin Liu wrote:
>>> commit 6c56e7a0 provide a function mmc_of_parse for standard MMC
>>> device-tree binding parser centrally. So just call it with
>>&g
n 03/08/2013 09:24 PM, Kevin Liu wrote:
> 2013/3/9 Stephen Warren :
>> On 03/08/2013 08:07 AM, Kevin Liu wrote:
>>> commit 6c56e7a0 provide a function mmc_of_parse for standard MMC
>>> device-tree binding parser centrally. So just call it with
>>&g
On 03/07/2013 09:52 PM, Kevin Liu wrote:
> commit 6c56e7a0 provide a function mmc_of_parse for standard MMC
> device-tree binding parser centrally. So just call it with
> sdhci_get_of_property together in sdhci_pltfm_register.
BTW, this patch seems to do two unrelated things; firstly it changes th
1 - 100 of 209 matches
Mail list logo
