Zang Roy-R61911 | 2 Aug 2010 08:19
Favicon

RE: [PATCH 3/3 v2] mmc: Add ESDHC weird voltage bits workaround


> -----Original Message-----
> From: Anton Vorontsov [mailto:cbouatmailru <at> gmail.com] 
> Sent: Friday, July 30, 2010 15:06 PM
> To: Zang Roy-R61911
> Cc: linux-mmc <at> vger.kernel.org; linuxppc-dev <at> ozlabs.org; 
> akpm <at> linux-foundation.org
> Subject: Re: [PATCH 3/3 v2] mmc: Add ESDHC weird voltage bits 
> workaround
> 
> On Fri, Jul 30, 2010 at 11:52:57AM +0800, Roy Zang wrote:
> > P4080 ESDHC controller does not support 1.8V and 3.0V 
> voltage. but the
> > host controller capabilities register wrongly set the bits.
> > This patch adds the workaround to correct the weird voltage 
> setting bits.
> > 
> > Signed-off-by: Roy Zang <tie-fei.zang <at> freescale.com>
> > ---
> [...]
> > diff --git a/drivers/mmc/host/sdhci-of-core.c 
> b/drivers/mmc/host/sdhci-of-core.c
> > index 0c30242..1f3913d 100644
> > --- a/drivers/mmc/host/sdhci-of-core.c
> > +++ b/drivers/mmc/host/sdhci-of-core.c
> >  <at>  <at>  -164,6 +164,10  <at>  <at>  static int __devinit 
> sdhci_of_probe(struct of_device *ofdev,
> >  	if (sdhci_of_wp_inverted(np))
> >  		host->quirks |= SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
> >  
(Continue reading)

Anton Vorontsov | 2 Aug 2010 08:52
Picon

Re: [PATCH 3/3 v2] mmc: Add ESDHC weird voltage bits workaround

On Mon, Aug 02, 2010 at 02:19:58PM +0800, Zang Roy-R61911 wrote:
[...]
> > For p4080 it will be 'voltage-ranges = <3200 3400>;'. So, with
> > voltage-ranges we can do fine grained VDD control without
> > introducing anything new.
> why not
>                voltage-ranges = <3300 3300>;

Right you are, both will be 3300.

Thanks,

--

-- 
Anton Vorontsov
email: cbouatmailru <at> gmail.com
irc://irc.freenode.net/bd2
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Adrian Hunter | 2 Aug 2010 10:17
Picon

[PATCH] mmc_test: Fix large memory allocation

From 665c12a94bd66a96adfad0b83deb6c6a72fb60e9 Mon Sep 17 00:00:00 2001
From: Adrian Hunter <adrian.hunter <at> nokia.com>
Date: Mon, 2 Aug 2010 11:15:17 +0300
Subject: [PATCH] mmc_test: Fix large memory allocation

- Fix mmc_test_alloc_mem.
- Use nr_free_buffer_pages() instead of sysinfo.totalram to
determine total lowmem pages.
- Change variables containing memory sizes to unsigned long.
- Limit maximum test area size to 128MiB because that is the
maximum MMC high capacity erase size (the maxmium SD allocation
unit size is just 4MiB)

Signed-off-by: Adrian Hunter <adrian.hunter <at> nokia.com>
---
 drivers/mmc/card/mmc_test.c |   76 ++++++++++++++++++++++++++----------------
 1 files changed, 47 insertions(+), 29 deletions(-)

diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index 197f387..5dd8576 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
 <at>  <at>  -16,6 +16,7  <at>  <at> 
 #include <linux/slab.h>

 #include <linux/scatterlist.h>
+#include <linux/swap.h>		/* For nr_free_buffer_pages() */

 #define RESULT_OK		0
 #define RESULT_FAIL		1
(Continue reading)

Luciano Coelho | 2 Aug 2010 10:16
Picon

Re: [PATCH v2 00/20] native support for wl1271 on ZOOM

On Mon, 2010-07-26 at 21:30 +0200, ext John W. Linville wrote:
> On Wed, Jul 21, 2010 at 08:33:34PM +0300, Ohad Ben-Cohen wrote:
> > This patch series adds native support for wl1271 on ZOOM.
> 
> Just for the record, I'm fine with the wl1271 bits here going through
> the omap tree with the rest of the series.

Yeah, I agree.  This is probably the best way to keep things in sync.

--

-- 
Cheers,
Luca.

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Andreas Feuersinger | 2 Aug 2010 15:46
Picon

Re: MX27 libertas_sdio SDIO Interrupts vs available bitrate


Hi Julien!

Julien Boibessot <julien.boibessot <at> free.fr> wrote:
> Andreas Feuersinger a écrit :
> > Everything works except for very bad datarate. So far the mxc_mmc
> > driver does not handle any SDIO interrupts. Could that be the reason
> > for the bad performance? 
> >   
> Definitly !
> (I had the same "problem" on my i.MX27 platform before using SDIO
> interrupts)

thank you! At least I know where to go ;)

While trying to enable SDIO handling I look at the mainline kernel
patch for SDIO interrupts in mxcmmc.c.

But in order to apply that I have to port that driver, introduced in
2.6.29 to my 2.6.22 kernel version. 

In the first step I try to get it run without sdio support.
The driver seems to load helper firmware successfully and also real
firmware. After that it stops where the libertas driver says:
"waiting for firmware to boot."

Register status is as follows:
mxcmci_irq:status: <6>BUF_WRITE_RDY |<6>END_CMD_RESP |<6>BUF_UND_RUN
|<6>XBUF_EMPTY |<6>YBUF_EMPTY |<6>

(Continue reading)

kishore kadiyala | 2 Aug 2010 16:33
Picon

Re: [PATCH v6] OMAP4 HSMMC: Adding Card detect support for MMC1 on OMAP4

Andrew,

Can this patch be taken now as there are no comments.

Regards,
Kishore

On Wed, Jul 7, 2010 at 7:42 PM, kishore kadiyala
<kishore.kadiyala <at> ti.com> wrote:
> Adding card detect callback function and card detect configuration
> function for MMC1 Controller.
>
> Card detect configuration function does initial configuration of the
> MMC Control & PullUp-PullDown registers of Phoenix.
>
> For MMC1 Controller, Card detect interrupt source is
> twl6030 and the card detect call back function provides card present/absent
> status by reading MMC Control register.
>
> Signed-off-by: Kishore Kadiyala <kishore.kadiyala <at> ti.com>
> Cc: Tony Lindgren <tony <at> atomide.com>
> Cc: Madhusudhan Chikkature <madhu.cr <at> ti.com>
> Cc: Adrian Hunter <adrian.hunter <at> nokia.com>
> ---
> V5:
>        https://patchwork.kernel.org/patch/106697/
>        https://patchwork.kernel.org/patch/106698/
> V4:
>        http://www.mail-archive.com/linux-mmc <at> vger.kernel.org/msg01958.html
>        http://www.mail-archive.com/linux-mmc <at> vger.kernel.org/msg01949.html
(Continue reading)

Matt Fleming | 2 Aug 2010 16:36
Gravatar

Re: [PATCH] mmc: add SDHCI driver for STM platforms.

On Mon, Aug 02, 2010 at 04:03:30PM +0200, Peppe CAVALLARO wrote:
> Hi Matt,
> 
> > -----Original Message-----
> > From: Matt Fleming [mailto:matt <at> console-pimps.org]
> > Sent: Monday, August 02, 2010 3:41 PM
> > To: Peppe CAVALLARO
> > Cc: Andrew Morton
> > Subject: Re: [PATCH] mmc: add SDHCI driver for STM platforms.
> > 
> > On Fri, Jul 30, 2010 at 04:04:16PM +0200, Peppe CAVALLARO wrote:
> > > Hello!
> > > I wonder if somebody's had some spare moment to review this patch.
> > > Welcome advice and feedback as usual
> > >
> > > Many thanks in advance.
> > >
> > > Best Regards,
> > > Giuseppe
> > 
> > You're best bet is to CC Andrew on mmc patches (which I've now done).
> 
> Thanks for your feedback and sorry if I didn't put Andrew on CC before.
> I'm newer in this mailing list.

I'm sorry, I dropped the linux-mmc mailing list when I replied to your
mail! My bad.

> > What is devm_stm_pad_claim()? I can't find this function in linus'
> > tree, or in -next, or in Andrew's -mm series. Where is this function
(Continue reading)

Peppe CAVALLARO | 2 Aug 2010 17:00

RE: [PATCH] mmc: add SDHCI driver for STM platforms.

Hi Matt,

> -----Original Message-----
> From: Matt Fleming [mailto:matt <at> console-pimps.org]
> Sent: Monday, August 02, 2010 4:37 PM
> To: Peppe CAVALLARO
> Cc: Andrew Morton; linux-mmc <at> vger.kernel.org
> Subject: Re: [PATCH] mmc: add SDHCI driver for STM platforms.
> 
> On Mon, Aug 02, 2010 at 04:03:30PM +0200, Peppe CAVALLARO wrote:
> > Hi Matt,
> >
> > > -----Original Message-----
> > > From: Matt Fleming [mailto:matt <at> console-pimps.org]
> > > Sent: Monday, August 02, 2010 3:41 PM
> > > To: Peppe CAVALLARO
> > > Cc: Andrew Morton
> > > Subject: Re: [PATCH] mmc: add SDHCI driver for STM platforms.
> > >
> > > On Fri, Jul 30, 2010 at 04:04:16PM +0200, Peppe CAVALLARO wrote:
> > > > Hello!
> > > > I wonder if somebody's had some spare moment to review this patch.
> > > > Welcome advice and feedback as usual
> > > >
> > > > Many thanks in advance.
> > > >
> > > > Best Regards,
> > > > Giuseppe
> > >
> > > You're best bet is to CC Andrew on mmc patches (which I've now done).
(Continue reading)

Ohad Ben-Cohen | 2 Aug 2010 17:59

Re: [PATCH v2 00/20] native support for wl1271 on ZOOM

On Mon, Aug 2, 2010 at 6:12 PM, Vitaly Wool <vitalywool <at> gmail.com> wrote:
> Also, specifically to 12xx, I'd like to see REF_CLOCK moved on and
> have this set by platform too (I haven't found anything like that in
> the patches but maybe I've overlooked that).

Check out patch no. 9:

http://www.spinics.net/lists/arm-kernel/msg93836.html

>
> Thanks,
>   Vitaly
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ohad Ben-Cohen | 2 Aug 2010 18:40

Re: [PATCH v2 00/20] native support for wl1271 on ZOOM

Hi Vitaly,

On Mon, Aug 2, 2010 at 7:19 PM, Vitaly Wool <vitalywool <at> gmail.com> wrote:
> On Mon, Aug 2, 2010 at 5:59 PM, Ohad Ben-Cohen <ohad <at> wizery.com> wrote:
>>
>> Check out patch no. 9:
>
> sorry for the confusion. However, I guess if the platform doesn't
> supply this value, we'll just consider it 0? Without any warning,
> right?
>
> The problem is, we can't really distinguish between this field not set
> and value zero, and that means something is wrong with the design. The
> easiest way is probably changing the clock ids to start with 1.

I don't think it's a huge deal as adding new devices on board files is
anyway something that is done carefully and not so often. Btw, we have
this kind of mechanism in other locations of the kernel as well and it
doesn't seem to be problematic (e.g. spi->chip_select, spi->mode,
spi->irq, ...).

Having said that I don't mind applying your proposal either and
pushing those defines by 1 in the driver. Luca what do you think ?

Thanks,
Ohad.

>
> Thanks,
>   Vitaly
(Continue reading)


Gmane