On Fri, 16 Mar 2012, Paul Gortmaker wrote:
> Just a heads up that the commit below is causing build failures in linux-next:
>
> drivers/mmc/host/tmio_mmc_pio.c:343:11: error: 'struct tmio_mmc_host' has no
> member named 'native_hotplug'
> drivers/mmc/host/tmio_mmc_pio.c:969:12: error: 'struct tm
The driver should not try to switch to 1.8V when the SD 3.0 host
controller does not have any UHS capabilities bits set (SDR50, DDR50
or SDR104). See page 72 of "SD Specifications Part A2 SD Host
Controller Simplified Specification Version 3.00" under
"1.8V Signaling Enable". Instead of setting SDR
Just a heads up that the commit below is causing build failures in linux-next:
drivers/mmc/host/tmio_mmc_pio.c:343:11: error: 'struct tmio_mmc_host' has no
member named 'native_hotplug'
drivers/mmc/host/tmio_mmc_pio.c:969:12: error: 'struct tmio_mmc_host' has no
member named 'native_hotplug'
mak
Hi,
On Fri, Mar 09 2012, Magnus Damm wrote:
> On Fri, Mar 9, 2012 at 6:16 PM, Guennadi Liakhovetski
> wrote:
>> Currently if a platform wants to implement a non-standard card-detection
>> method, it would need to call tmio_mmc_cd_wakeup(), which is an inline
>> function, calling mmc_detect_change
Hi,
On Fri, Mar 16 2012, Bastian Hecht wrote:
> Some boards need a preliminary setup stage to prepare the sdhi
> controller.
>
> Signed-off-by: Bastian Hecht
> ---
> drivers/mmc/host/sh_mobile_sdhi.c | 13 +
> include/linux/mmc/sh_mobile_sdhi.h |4
> 2 files changed, 17 i
Some boards need a preliminary setup stage to prepare the sdhi
controller.
Signed-off-by: Bastian Hecht
---
drivers/mmc/host/sh_mobile_sdhi.c | 13 +
include/linux/mmc/sh_mobile_sdhi.h |4
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sh
Hi
Thank you for your reply. I has taken me a while to figure out what you
meant, but I believe I have added a sdhci_dumpregs(host) to the place
where CMD24 is issued with a -110 return error.
Hi:
-110 is the timeout problem.
You can dump the esdhc registers if you want to debug into this is
On Fri, Mar 16, 2012 at 7:21 PM, Felipe Balbi wrote:
> On Fri, Mar 16, 2012 at 07:08:57PM +0530, Venkatraman S wrote:
>> From: Balaji T K
>>
>> Enable Auto-CMD12 for multi block read/write on HSMMC
>> Tested on OMAP4430, OMAP3430 and OMAP2430 SDP
>>
>> Signed-off-by: Balaji T K
>> Signed-off-by:
On Fri, Mar 16, 2012 at 07:08:57PM +0530, Venkatraman S wrote:
> From: Balaji T K
>
> Enable Auto-CMD12 for multi block read/write on HSMMC
> Tested on OMAP4430, OMAP3430 and OMAP2430 SDP
>
> Signed-off-by: Balaji T K
> Signed-off-by: Venkatraman S
> ---
> drivers/mmc/host/omap_hsmmc.c | 16
From: Balaji T K
OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset.
Addng the offset to platform_device resource structure
increments the start address for every insmod operation.
MMC command fails on re-insertion as module due to incorrect register base.
Fix this by updating the ioremap
From: Felipe Balbi
this will delete some boilerplate code, no functional
changes.
Signed-off-by: Felipe Balbi
Signed-off-by: Venkatraman S
---
drivers/mmc/host/omap_hsmmc.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/d
From: Felipe Balbi
if we put probe() on __init section, that will never
work for multiple module insertions/removals.
In order to make it work properly, move probe to
__devinit section and use platform_driver_register()
instead of platform_driver_probe().
Signed-off-by: Felipe Balbi
Signed-off
From: Felipe Balbi
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically decreases indentation level, drop unneded
dereferences and drop unneded accesses to the platform_device
structure.
Signed-off-by: Felipe Balbi
Signed-off-by: Venkatraman S
---
drivers/mmc/host/omap_h
From: Balaji T K
call context save api after enabling runtime pm
to make sure register access in context save api happens with clk enabled.
Signed-off-by: Balaji T K
Signed-off-by: Venkatraman S
Cc: stable
---
drivers/mmc/host/omap_hsmmc.c |4 ++--
1 file changed, 2 insertions(+), 2 dele
From: Balaji T K
pm_runtime_put_sync instead of autosuspend pm runtime API
because iounmap(host->base) follows immediately.
Reported-by: Rajendra Nayak
Signed-off-by: Balaji T K
Signed-off-by: Venkatraman S
Cc: stable
---
drivers/mmc/host/omap_hsmmc.c |3 +--
1 file changed, 1 insertion
On Thu, Mar 15, 2012 at 8:42 PM, Shubhrajyoti wrote:
> On Thursday 15 March 2012 08:03 PM, Venkatraman S wrote:
>> From: Balaji T K
>>
>> call context save api after enabling runtime pm
>> to make sure register access in context save api
> If I am not mistaken the api would
> store the number o
From: Balaji T K
Add Dual data rate support for omap_hsmmc
Signed-off-by: Balaji T K
Signed-off-by: Venkatraman S
---
drivers/mmc/host/omap_hsmmc.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index a9ffd70..d682c5e
From: Balaji T K
Enable Auto-CMD12 for multi block read/write on HSMMC
Tested on OMAP4430, OMAP3430 and OMAP2430 SDP
Signed-off-by: Balaji T K
Signed-off-by: Venkatraman S
---
drivers/mmc/host/omap_hsmmc.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a
Chris,
Here are a group of fixes posted by Felipe and Balaji for the
OMAP hsmmc driver in the past few days.
I've rebased them to the lastest mmc-next and posted them
here again. These have also been tested on OMAP4 development platform.
Please feel to apply directly or pull if that's conve
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
> On Thu, Mar 15, 2012 at 06:23:32PM +, Arnd Bergmann wrote:
> >
> > * we want to get rid of arch/arm/mach-ux500/board-mop500-sdi.c
> > * the sdi0_configure() and mop500_sdi0_vdd_handler() functions
> > need to be moved somewhere in
On Friday 16 March 2012, Linus Walleij wrote:
> On Thu, Mar 15, 2012 at 9:58 PM, Arnd Bergmann wrote:
> > [Per]
> >> The stedma40 filter function is not really specific for ux500. ux500
> >> use stedma40 but it should be possible to replace this DMA.IP with
> >> some other DMA-controller. This is
Hi,
On Thu, Mar 08 2012, Chris Ball wrote:
>> Guennadi Liakhovetski (10):
>> mmc: simplify mmc_cd_gpio_request() by removing two parameters
>> mmc: tmio: calculate the native hotplug condition only once
>> mmc: tmio_mmc: support the generic MMC GPIO card hotplug helper
>> mmc: sh_mobile_sd
Purely cosmetic readability improvement, no functional change.
Signed-off-by: Guennadi Liakhovetski
---
include/linux/mmc/sh_mmcif.h | 21 +
1 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/include/linux/mmc/sh_mmcif.h b/include/linux/mmc/sh_mmcif.h
index b36
On Fri, Mar 16, 2012 at 04:02:16PM +0530, S, Venkatraman wrote:
> On Thu, Mar 15, 2012 at 8:34 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Mar 15, 2012 at 08:03:42PM +0530, Venkatraman S wrote:
> >> From: Balaji T K
> >>
> >> OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset.
> >> Add
On Thu, Mar 15, 2012 at 8:34 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Mar 15, 2012 at 08:03:42PM +0530, Venkatraman S wrote:
>> From: Balaji T K
>>
>> OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset.
>> Addng the offset to platform_device resource structure
>> increments the start addr
Hi Chris
On Thu, 15 Mar 2012, Chris Ball wrote:
> Hi Guennadi,
>
> On Fri, Mar 09 2012, Guennadi Liakhovetski wrote:
> > Currently if a platform wants to implement a non-standard card-detection
> > method, it would need to call tmio_mmc_cd_wakeup(), which is an inline
> > function, calling mmc_d
On 03/16/2012 09:53 AM, Russell King wrote:
On Fri, Mar 16, 2012 at 09:48:07AM +0100, Ulf Hansson wrote:
Although, right know I would vote for having a more active maintainer
for MMCI; please no offense Russell, I realize that your are fully
occupied with a lot of other cool stuff. I think Linus
Hi Girish,
On 03/16/2012 04:49 AM, Girish K S wrote:
On 14 March 2012 20:53, Ulf Hansson wrote:
Hi Girish and Chris,
I noticed that this has been pushed for 3.3, I think we need to make a
revert of it asap if possible.
I were unfortunately not able to review this patch earlier but it has iss
On Thu, Mar 15, 2012 at 9:58 PM, Arnd Bergmann wrote:
> [Per]
>> The stedma40 filter function is not really specific for ux500. ux500
>> use stedma40 but it should be possible to replace this DMA.IP with
>> some other DMA-controller. This is board specific configuration. You
>> should not need to
On Fri, Mar 16, 2012 at 09:48:07AM +0100, Ulf Hansson wrote:
> Although, right know I would vote for having a more active maintainer
> for MMCI; please no offense Russell, I realize that your are fully
> occupied with a lot of other cool stuff. I think Linus could play a
> great role in this;
On Thu, Mar 15, 2012 at 12:22:04PM +0100, Lothar Waßmann wrote:
...
> An intermediate solution could be using OF_DEV_AUXDATA to pass a
> platform_data struct that may contain a MAC address set up by the
> platform code.
>
+1
--
Regards,
Shawn
--
To unsubscribe from this list: send the line "unsu
Hi Russell,
On 03/15/2012 06:30 PM, Russell King wrote:
On Thu, Mar 15, 2012 at 03:30:36PM +0100, Linus Walleij wrote:
From: Linus Walleij
So since this driver is crucial for us (as in ST-Ericsson)
to have actively maintained, and since it is marked orphaned
I will assume maintainership for it
On Fri, Mar 16, 2012 at 03:48:13PM +0800, Lothar Waßmann wrote:
> Hi,
>
> Dong Aisheng writes:
> > On Thu, Mar 15, 2012 at 07:22:04PM +0800, Lothar Waßmann wrote:
> [...]
> > My proposal is only set the fixed part(first two octets) in board dts file,
> > each board knows it's value, and read the l
Hi,
Dong Aisheng writes:
> On Thu, Mar 15, 2012 at 07:22:04PM +0800, Lothar Waßmann wrote:
[...]
> My proposal is only set the fixed part(first two octets) in board dts file,
> each board knows it's value, and read the left 4 octets from OCOTP
> dynamically.
>
The OUI part is three bytes, not two
34 matches
Mail list logo
