Populate OF_DEV_AUXDATA with desired device name expected by
davinci_mmc driver. Without this clk_get of davinci_mmc DT driver
fails.
Signed-off-by: Manjunathappa, Prakash
Cc: linux-mmc@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: davinci-linux-ope
Add DT entry for MMC. Also add entry for pinmux information.
Tested:
1) Without GPIO card detection and EDMA support as DT support for
GPIO and EDMA are yet come.
2) By creating/deleting files and mounting/unmounting the partition.
Signed-off-by: Manjunathappa, Prakash
Cc: linux-mmc@vger.kerne
Adds device tree support for davinci_mmc. Also add binding documentation.
As of now in non-dma PIO mode and without GPIO card_detect/write_protect
option because of dependencies on EDMA and GPIO module DT support.
Signed-off-by: Manjunathappa, Prakash
Reviewed-by: Mark Rutland
Cc: linux-mmc@vger
Stop getting controller IP version via platform data, instead derive it
from platform_device_id table.
Signed-off-by: Manjunathappa, Prakash
---
Suppose to be v1 but got added later to this series.
drivers/mmc/host/davinci_mmc.c| 17 -
include/linux/platform_data/m
Patch set adds DT support for davinci_mmc driver and is
verified on da850-evm without card_detect/write_protect and
EDMA support. Also takecare to derive controller IP version from
platform_device_id table, remove version specification in pdata.
DT patches depends on below patches under review:
1)
Remove specifying mmc controller IP version information via platform
data, instead specify device name so that driver derives it from
platform_device_id table. Also change the clock node name to match
the changed dev_id.
Tested on da850-evm to make sure driver loads without clk_get failures.
Signe
On 02/15/2013 02:09 PM, Alim Akhtar wrote:
> Hi Sachin,
>
> On Thu, Feb 14, 2013 at 8:55 PM, Sachin Kamat wrote:
>> On 07/02/2013, Sachin Kamat wrote:
>>> Added compatibility string for Exynos4412 SoC.
>>>
>>> Cc: Thomas Abraham
>>> Signed-off-by: Sachin Kamat
>>
>> Any comments on this patch?
Hi Sachin,
On Thu, Feb 14, 2013 at 8:55 PM, Sachin Kamat wrote:
> On 07/02/2013, Sachin Kamat wrote:
>> Added compatibility string for Exynos4412 SoC.
>>
>> Cc: Thomas Abraham
>> Signed-off-by: Sachin Kamat
>
> Any comments on this patch?
>
>> ---
>> drivers/mmc/host/dw_mmc-exynos.c |2 ++
Hi,
On Thu, Feb 14 2013, Johan Rudholm wrote:
> 2013/2/14 Fabio Estevam :
>> Commit 3714f4315354 (mmc: sdhci: update signal voltage switch code)
>> changed the
>> type of the second parameter of sdhci_do_start_signal_voltage_switch(), from
>> "struct mmc_ios *ios" to "int signal_voltage" which cau
Basically all drivers can have sdhci_ops struct const, but almost none do so.
This patch constifies all sdhci_ops struct declarations where possible.
The patch was auto-generated with the following coccinelle semantic patch:
//
@r1@
identifier ops;
identifier fld;
@@
ops.fld = ...;
@disable opt
All users of the sdhci_ops struct in the sdhci core already treat it as const.
The sdhci-pltfm code itself never actually looks at the ops field of the
sdhci_pltfm_data struct and merely passes it on to the sdhci core, so make we
can make it const in the sdhci_pltfm_data struct as well. This allows
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 patch also makes the sdhci_pltfm_data declarations const where po
On Thursday 14 February 2013, Guennadi Liakhovetski wrote:
> On Thu, 14 Feb 2013, Magnus Damm wrote:
> > On Thu, Feb 14, 2013 at 5:28 PM, Guennadi Liakhovetski
> > > My take on this is the following: having N optionally available on
> > > different IP-versions features, I'd rather have N DT propert
On 07/02/2013, Sachin Kamat wrote:
> Added compatibility string for Exynos4412 SoC.
>
> Cc: Thomas Abraham
> Signed-off-by: Sachin Kamat
Any comments on this patch?
> ---
> drivers/mmc/host/dw_mmc-exynos.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/
On Thursday 14 February 2013 04:13 PM, Jan Lübbe wrote:
On Wed, 2013-01-30 at 10:07 +0100, Jan Luebbe wrote:
If the CD/WP-GPIOs are not provided by the SoC's GPIO controller,
we need to handle the case where omap_hsmmc is probed earlier than
the GPIO controller chosen in the device tree.
Fix th
Hi,
2013/2/14 Fabio Estevam :
> Commit 3714f4315354 (mmc: sdhci: update signal voltage switch code) changed
> the
> type of the second parameter of sdhci_do_start_signal_voltage_switch(), from
> "struct mmc_ios *ios" to "int signal_voltage" which causes the following build
> warning:
>
> drivers/
Commit 3714f4315354 (mmc: sdhci: update signal voltage switch code) changed the
type of the second parameter of sdhci_do_start_signal_voltage_switch(), from
"struct mmc_ios *ios" to "int signal_voltage" which causes the following build
warning:
drivers/mmc/host/sdhci.c:2044:2: warning: initializ
On 12 February 2013 04:24, Jingoo Han wrote:
> Use devm_clk_get() rather than clk_get() to make cleanup paths
> more simple.
>
> Signed-off-by: Jingoo Han
> ---
> Changes since v1:
> - modified the commit message
>
> drivers/mmc/host/sdhci-s3c.c | 17 ++---
> 1 files changed, 2 ins
Hi Ulf,
On Thu, Feb 14, 2013 at 8:33 AM, Ulf Hansson wrote:
> No. Fixup shall be done in SDHCI instead. Otherwise other host drivers
> will break instead.
Do you mean like this?
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1675,7 +1675,7 @@ static void sdhci_enable_sdio_ir
On 14 February 2013 09:05, Marek Szyprowski wrote:
>
> On 2/13/2013 12:35 PM, Mark Brown wrote:
>>
>> On Wed, Feb 13, 2013 at 08:45:56AM +0100, Guennadi Liakhovetski wrote:
>> > On Wed, 13 Feb 2013, Marek Szyprowski wrote:
>>
>> > > BTW, mmc_regulator_get_ocrmask() won't work with continuous range
On Thu, Feb 14, 2013 at 09:05:43AM +0100, Marek Szyprowski wrote:
> 1. mmc_regulator_get_ocrmask() works only with regulators which support
> regulator_count_voltages() and regulator_list_voltage(). Recently
> support for
> continuous regulators have been merged. Such regulators doesn't provide
>
On Wed, 2013-01-30 at 10:07 +0100, Jan Luebbe wrote:
> If the CD/WP-GPIOs are not provided by the SoC's GPIO controller,
> we need to handle the case where omap_hsmmc is probed earlier than
> the GPIO controller chosen in the device tree.
>
> Fix this by checking the return value of of_get_named_g
On 14 February 2013 03:14, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Since commit 3714f4315354 (mmc: sdhci: update signal voltage switch code) the
> second argument of start_signal_voltage_switch has 'int signal_voltage' type,
> so update mmc core and the mmc host struct definition according
Hi Magnus
On Thu, 14 Feb 2013, Magnus Damm wrote:
> Hi Guennadi,
>
> [Added Laurent to CC]
>
> On Thu, Feb 14, 2013 at 5:28 PM, Guennadi Liakhovetski
> wrote:
> > On Thu, 14 Feb 2013, Magnus Damm wrote:
> >
> >> On Thu, Feb 14, 2013 at 10:59 AM, Simon Horman wrote:
> >> > On Thu, Feb 14, 2013
Hi Guennadi,
[Added Laurent to CC]
On Thu, Feb 14, 2013 at 5:28 PM, Guennadi Liakhovetski
wrote:
> On Thu, 14 Feb 2013, Magnus Damm wrote:
>
>> On Thu, Feb 14, 2013 at 10:59 AM, Simon Horman wrote:
>> > On Thu, Feb 14, 2013 at 10:42:21AM +0900, Magnus Damm wrote:
>> >> On Thu, Feb 14, 2013 at 1
On Thu, 14 Feb 2013, Magnus Damm wrote:
> On Thu, Feb 14, 2013 at 10:59 AM, Simon Horman wrote:
> > On Thu, Feb 14, 2013 at 10:42:21AM +0900, Magnus Damm wrote:
> >> On Thu, Feb 14, 2013 at 12:59 AM, Guennadi Liakhovetski
> >> wrote:
> >> > On Thu, 7 Feb 2013, Simon Horman wrote:
> >> >
> >> >>
On 2/13/2013 12:35 PM, Mark Brown wrote:
On Wed, Feb 13, 2013 at 08:45:56AM +0100, Guennadi Liakhovetski wrote:
> On Wed, 13 Feb 2013, Marek Szyprowski wrote:
> > BTW, mmc_regulator_get_ocrmask() won't work with continuous range
regulators.
> This seems like a problem, that has to be fixed...
27 matches
Mail list logo
