Re: [PATCH 06/12] mmc: omap_hsmmc: remove private DMA API implementation

2012-04-24 Thread Grazvydas Ignotas
On Mon, Apr 23, 2012 at 7:06 PM, Russell King
rmk+ker...@arm.linux.org.uk wrote:
 Remove the private DMA API implementation from omap_hsmmc, making it
 use entirely the DMA engine API.

 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk

Since the driver becomes useless without DMA_ENGINE, we probably want
a 'depends on'?



-- 
Gražvydas
--
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: [RFC 00/12] OMAP DMA engine conversion

2012-04-24 Thread Grazvydas Ignotas
On Wed, Apr 25, 2012 at 2:29 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Wed, Apr 25, 2012 at 01:47:21AM +0300, Grazvydas Ignotas wrote:
 On Tue, Apr 24, 2012 at 7:51 PM, Tony Lindgren t...@atomide.com wrote:
  * Russell King - ARM Linux li...@arm.linux.org.uk [120424 03:42]:
  Here's another patch - for the OMAP NAND driver.
 
  One thing this doesn't do is configure up the source/destination bursts,
  which the old code did:
 
                          omap_set_dma_dest_burst_mode(info-dma_ch,
                                          OMAP_DMA_DATA_BURST_16);
                          omap_set_dma_src_burst_mode(info-dma_ch,
                                          OMAP_DMA_DATA_BURST_16);
 
  Grazvydas, care to give this patch a go?

 Tested-by: Grazvydas Ignotas nota...@gmail.com
 for:
 - SD card connected over transceiver to MMC2
 - touchscreen connected over SPI
 - NAND on GPMC in DMA mode
 Seems to be working just as they did before, except that I'm not sure
 SPI was crossing PIO threshold.

 I think my testing on OMAP4430SDP with the SPI based ethernet should've
 caught anything untoward there.

 For the MMC2, could you say whether this was the hsmmc driver or the
 older omap1/2 driver please?

hsmmc running on OMAP3 pandora.


-- 
Gražvydas
--
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 V2 00/16] omap_hsmmc patches

2011-07-15 Thread Grazvydas Ignotas
On Wed, Jul 13, 2011 at 6:36 PM, Chris Ball c...@laptop.org wrote:
 Hi,

 On Wed, Jul 13 2011, Grazvydas Ignotas wrote:
 it seems this series got lost in time, at least patches 01, 02, 03,
 04, 05, 06, 07, 08, 12 look like valid standalone fixes and
 improvements to me, they don't touch other trees and still apply
 cleanly, so would be good to have.

 Yeah.  I didn't merge them because Tony still has unanswered comments on
 the OMAP side of the patches, and they're submitted as a single patchset.

 I've applied {2, 3, 5, 6, 7, 8, 12} to mmc-next for 3.1 now.  1 doesn't
 apply because the function doesn't exist anymore.  4 doesn't apply
 because iclk doesn't exist anymore.

 If someone wants to look at rebasing the rest of these against mmc-next
 and resubmitting, I think that'd be useful.

Thanks! 1 and 4 seem to be unneeded any more (I was trying them on
linux-next, not noticing it was not updated for a while), and others
have comments pending, so it's all done.


 Thanks,

 - Chris.
 --
 Chris Ball   c...@laptop.org   http://printf.net/
 One Laptop Per Child


-- 
Gražvydas
--
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 V2 00/16] omap_hsmmc patches

2011-07-13 Thread Grazvydas Ignotas
Hello,

it seems this series got lost in time, at least patches 01, 02, 03,
04, 05, 06, 07, 08, 12 look like valid standalone fixes and
improvements to me, they don't touch other trees and still apply
cleanly, so would be good to have.

Chris, can you queue these for upcoming merge window?
These patches are also archived in patchwork here:
https://patchwork.kernel.org/project/linux-omap/list/?archive=bothpage=8


On Fri, May 6, 2011 at 12:13 PM, Adrian Hunter adrian.hun...@nokia.com wrote:
 Hi

 Here is V2 of some patches for omap_hsmmc.

 Changes in V2:

        OMAP: sDMA: descriptor autoloading feature
                - removed the feature entirely as per Tony Lindgren

        mmc: omap_hsmmc: fix few bugs when set the clock divisor
                - added cpu_relax() as per Grazvydas Ignotas

        mmc: omap_hsmmc: fix missing mmc_release_host() in no_off case
                - removed {} as per Sergei Shtylyov

        OMAP: hsmmc: implement clock switcher
                - changed to = threshold as per Grazvydas Ignotas


 Adrian Hunter (6):
      mmc: omap_hsmmc: correct debug report error status mnemonics
      OMAP: board-rm680: set MMC nomux flag
      mmc: omap_hsmmc: ensure pbias configuration is always done
      mmc: omap_hsmmc: fix oops in omap_hsmmc_dma_cb
      OMAP: hsmmc: add platform data for eMMC hardware reset gpio
      mmc: omap_hsmmc: add a hardware reset before initialization

 Andy Shevchenko (8):
      mmc: omap_hsmmc: move hardcoded frequency constants to definition block
      mmc: omap_hsmmc: reduce a bit the error handlers in probe()
      mmc: omap_hsmmc: split duplicate code to calc_divisor() function
      mmc: omap_hsmmc: introduce start_clock and re-use stop_clock
      mmc: omap_hsmmc: fix few bugs when set the clock divisor
      mmc: omap_hsmmc: split same pieces of code to separate functions
      OMAP: hsmmc: implement clock switcher
      mmc: omap_hsmmc: adjust host controller clock in regard to current OPP

 Jarkko Lavinen (1):
      OMAP: hsmmc: Do not mux the slot if non default muxing is already done

 Sudhir Bera (1):
      mmc: omap_hsmmc: fix missing mmc_release_host() in no_off case

  arch/arm/mach-omap2/board-rm680.c     |    1 +
  arch/arm/mach-omap2/hsmmc.c           |  188 +-
  arch/arm/mach-omap2/hsmmc.h           |    2 +
  arch/arm/plat-omap/include/plat/mmc.h |    9 +
  drivers/mmc/host/omap_hsmmc.c         |  353 
 -
  5 files changed, 414 insertions(+), 139 deletions(-)

 Regards
 Adrian

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


-- 
Gražvydas
--
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 13/22] mmc: omap_hsmmc: fix few bugs when set the clock divisor

2011-05-05 Thread Grazvydas Ignotas
On Thu, May 5, 2011 at 2:51 PM, Adrian Hunter adrian.hun...@nokia.com wrote:
 From: Andy Shevchenko ext-andriy.shevche...@nokia.com

 There are two pieces of code which similar, but not the same. Each of them
 contains a bug.

 The SYSCTL register should be read before write in the
 omap_hsmmc_context_restore() to remain the state of the reserved bits.

 Before set the clock divisor and DTO bits the value from the SYSCTL register
 should be masked properly. We were lucky to have no problems with DTO bits. 
 So,
 make sure we have clear DTO bits properly in the omap_hsmmc_set_ios().

 Additionally get rid of msleep(1). The actual time rare higher than 30us on
 OMAP 3630.

 The result pieces of code are split to omap_hsmmc_set_clock() function.

 Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com
 Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
 ---
  drivers/mmc/host/omap_hsmmc.c |   59 +++-
  1 files changed, 28 insertions(+), 31 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index ae6d204..3c76911 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -619,6 +619,32 @@ static u16 calc_divisor(struct mmc_ios *ios)
        return dsor;
  }

 +static void omap_hsmmc_set_clock(struct omap_hsmmc_host *host)
 +{
 +       struct mmc_ios *ios = host-mmc-ios;
 +       unsigned long regval;
 +       unsigned long timeout;
 +
 +       dev_dbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
 +
 +       omap_hsmmc_stop_clock(host);
 +
 +       regval = OMAP_HSMMC_READ(host-base, SYSCTL);
 +       regval = regval  ~(CLKD_MASK | DTO_MASK);
 +       regval = regval | (calc_divisor(ios)  6) | (DTO  16);
 +       OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
 +       OMAP_HSMMC_WRITE(host-base, SYSCTL,
 +               OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
 +
 +       /* Wait till the ICS bit is set */
 +       timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
 +       while ((OMAP_HSMMC_READ(host-base, SYSCTL)  ICS) != ICS
 +                time_before(jiffies, timeout))
 +               ;

Since you are busywaiting now, cpu_relax() is advisable I guess.
--
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 19/22] OMAP: hsmmc: implement clock switcher

2011-05-05 Thread Grazvydas Ignotas
On Thu, May 5, 2011 at 2:51 PM, Adrian Hunter adrian.hun...@nokia.com wrote:
 From: Andy Shevchenko ext-andriy.shevche...@nokia.com

 There are 3 new platform data methods which should help us to do a clock
 switching when notification is happened or request is started.

 The purpose of the patch is to avoid high frequency of MMC controller on low
 OPPs due to an HW bug in OMAP 3630.

 The algorithm:
  - the PM governor switches the clock of L3 (and therefore L4) bus on demand
  - the MMC controller clock should follow the change

 We have considered two OPPs for L3/L4 bus. Thus, we have corresponding flow:
  - OPP1 - OPP2 (in case of abort - OPP1)
  - OPP2 - OPP1 (in case of abort - OPP2)

 During idle the MMC gates functional clock and we don't care about the
 frequency. Most important to get proper solution when notification comes 
 during
 request. Then:
  - in case of OPP1 - OPP2 we update frequency limit and it will be used for
   new coming requests (it assumes the current frequency of the controller is
   lower then new one)
  - otherwise we wait until no device has used higher frequency then upcoming
   one

 Known issues and limitations:
  - originally a clock notifier was used for the core L4 iclk but for upstream
   Adrian changed to a cpufreq notifier where we assume OPP1 below 400MHz and
   OPP2 above 400MHz

 Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com
 Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
 ---
  arch/arm/mach-omap2/hsmmc.c           |  180 
 -
  arch/arm/plat-omap/include/plat/mmc.h |    8 ++
  2 files changed, 187 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
 index 6b97fae..34cba89 100644
 --- a/arch/arm/mach-omap2/hsmmc.c
 +++ b/arch/arm/mach-omap2/hsmmc.c

snip

 +
 +static int hsmmc_clk_notifier(struct notifier_block *nb, unsigned long event,
 +                             void *data)
 +{
 +       struct cpufreq_freqs *freqs = data;
 +       unsigned int threshold = 40; /* between opp1 and opp2 */
 +
 +       switch (event) {
 +       case CPUFREQ_PRECHANGE:
 +               if (freqs-new  threshold  freqs-old  threshold) {

What if we go from 40 to, say, 20?

 +                       /* opp2 - opp1 */
 +                       hsmmc_max_freq = HSMMC_MAX_FREQ  1;
 +
 +                       /* Timeout is 1 sec */
 +                       if (!wait_event_timeout(hsmmc_max_freq_wq,
 +                                               hsmmc_max_freq_ok(),
 +                                               msecs_to_jiffies(1000)))
 +                               pr_err(MMC violates maximum frequency 
 +                                      constraint\n);
 +               }
 +               break;
 +       case CPUFREQ_POSTCHANGE:
 +               if (freqs-old  threshold  freqs-new  threshold) {

Same here, you could go from 20 to 40 and then 60 and code
would never notice it.

 +                       /* opp1 - opp2 */
 +                       hsmmc_max_freq = HSMMC_MAX_FREQ;
 +               }
--
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 11/15] wireless: wl1271: introduce platform device support

2010-07-09 Thread Grazvydas Ignotas
On Fri, Jul 9, 2010 at 11:32 AM, Ohad Ben-Cohen o...@wizery.com wrote:
 Hi Roger,

 On Fri, Jul 9, 2010 at 11:12 AM, Roger Quadros roger.quad...@nokia.com 
 wrote:
 You are already
 creating a new platform device for wl1271_sdio just to pass platform_data

 With the new approach, I can remove this platform device altogether,
 and completely rely on the sdio function device for driver probing (as
 it was before). I just need to add this little support of delivering
 small bits of platform data - the mechanism should be simple and
 generic, and would considerably simplify the driver.

 I think this case is specific to wl1271.

 Yes, it is.

wl1251 also has this issue. In fact it's even worse there as it's
missing all SDIO registers and cannot be probed at all.. Those devices
are not plug n play at all.
--
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 04/15] mmc: support embedded data field in mmc_host

2010-07-06 Thread Grazvydas Ignotas
On Tue, Jul 6, 2010 at 3:37 AM, Ohad Ben-Cohen o...@wizery.com wrote:
 From: Ohad Ben-Cohen oh...@ti.com

 Add support to set/get mmc_host private embedded
 data.

 This is needed to allow software to dynamically
 create (and remove) SDIO functions which represents
 embedded SDIO devices.

 Typically, it will be used to set the context of
 a driver that is creating a new SDIO function
 (and would then expect to be able to get that context
 back upon creation of the new sdio func).

 Signed-off-by: Ohad Ben-Cohen oh...@ti.com
 ---
  drivers/mmc/core/Kconfig |    8 
  include/linux/mmc/host.h |   16 
  2 files changed, 24 insertions(+), 0 deletions(-)

 diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
 index bb22ffd..ab27eb3 100644
 --- a/drivers/mmc/core/Kconfig
 +++ b/drivers/mmc/core/Kconfig
 @@ -16,3 +16,11 @@ config MMC_UNSAFE_RESUME

          This option sets a default which can be overridden by the
          module parameter removable=0 or removable=1.
 +
 +config MMC_EMBEDDED_SDIO
 +       boolean MMC embedded SDIO device support
 +       help
 +         If you say Y here, support will be added for embedded SDIO
 +         devices (e.g. hardwired embedded WLAN SDIO devices).
 +         Such devices require software support for emulating
 +         card detect events.
 diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
 index f65913c..9a48486 100644
 --- a/include/linux/mmc/host.h
 +++ b/include/linux/mmc/host.h
 @@ -209,6 +209,10 @@ struct mmc_host {
        struct led_trigger      *led;           /* activity led */
  #endif

 +#ifdef CONFIG_MMC_EMBEDDED_SDIO
 +       void                    *embedded_data;
 +#endif
 +

Hm, do we really need a Kconfig option just for a single pointer? It
only saves sizeof(void *) bytes per host, but adds rather confusing
config option for users and some ifdef complexity.
--
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 0/3] add non-standard SDIO card support

2010-06-29 Thread Grazvydas Ignotas
This is my attempt to make SDIO interfaced TI WL1251 wifi chip usable
on mainline kernels. It's driver has already been merged several releases
back, but the problem is current SDIO core can't detect the card because
it's not following SDIO standards and does not have any required SDIO
registers. Currenty attempting to use this chip only results in several
pages of complains about invalid register data from SDIO core.
WL1251 is used on various HTC devices and Pandora handheld at least.

People wanting to use this are forced to use forked trees or patches.
My solution to this problem is to add new MMC quirk that will tell SDIO
core not to access any SDIO registers and rely on host's init_card
callback instead, which is now responsible for filling card related
structures for SDIO core to function. Patches 2 and 3 set up the card
for pandora, similar method could be used for MSM too.

Only patches 2,3 depend on each other, so patch 1 can be merged separately.

Grazvydas Ignotas (3):
  sdio: allow non-standard SDIO cards
  omap_hsmmc: add init_card pass-through callback
  omap: pandora: pass information about wl1251 to SDIO core

 arch/arm/mach-omap2/board-omap3pandora.c |   16 +
 arch/arm/mach-omap2/hsmmc.c  |1 +
 arch/arm/mach-omap2/hsmmc.h  |4 +++
 arch/arm/plat-omap/include/plat/mmc.h|2 +
 drivers/mmc/core/sdio.c  |   36 +-
 drivers/mmc/host/omap_hsmmc.c|   10 
 include/linux/mmc/card.h |2 +
 7 files changed, 65 insertions(+), 6 deletions(-)

--
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/3] sdio: allow non-standard SDIO cards

2010-06-29 Thread Grazvydas Ignotas
There are some chips (like TI WL12xx series) that can be interfaced
over SDIO but don't support the SDIO specification, meaning that they
are missing CIA (Common I/O Area) with all it's registers. Current
Linux SDIO implementation relies on those registers to identify and
configure the card, so non-standard cards can not function and cause
lots of warnings from the core when it reads invalid data from
non-existent registers.

After this patch, init_card() host callback can now set new quirk
MMC_QUIRK_NONSTD_SDIO, which means that SDIO core should not try to
access any standard SDIO registers and rely on init_card() to fill all
SDIO structures instead. As those cards are usually embedded chips,
all the required information can be obtained from machine board files
by the host driver when it's called through init_card() callback.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/mmc/core/sdio.c  |   36 ++--
 include/linux/mmc/card.h |2 ++
 2 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index b9dee28..cb66833 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -62,13 +62,19 @@ static int sdio_init_func(struct mmc_card *card, unsigned 
int fn)
 
func-num = fn;
 
-   ret = sdio_read_fbr(func);
-   if (ret)
-   goto fail;
+   if (!(card-quirks  MMC_QUIRK_NONSTD_SDIO)) {
+   ret = sdio_read_fbr(func);
+   if (ret)
+   goto fail;
 
-   ret = sdio_read_func_cis(func);
-   if (ret)
-   goto fail;
+   ret = sdio_read_func_cis(func);
+   if (ret)
+   goto fail;
+   } else {
+   func-vendor = func-card-cis.vendor;
+   func-device = func-card-cis.device;
+   func-max_blksize = func-card-cis.blksize;
+   }
 
card-sdio_func[fn - 1] = func;
 
@@ -321,6 +327,23 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 
ocr,
goto remove;
}
 
+   if (card-quirks  MMC_QUIRK_NONSTD_SDIO) {
+   /*
+* This is non-standard SDIO device, meaning it doesn't
+* have any CIA (Common I/O area) registers present.
+* It's host's responsibility to fill cccr and cis
+* structures in init_card().
+*/
+   mmc_set_clock(host, card-cis.max_dtr);
+
+   if (card-cccr.high_speed) {
+   mmc_card_set_highspeed(card);
+   mmc_set_timing(card-host, MMC_TIMING_SD_HS);
+   }
+
+   goto finish;
+   }
+
/*
 * Read the common registers.
 */
@@ -376,6 +399,7 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 
ocr,
if (err)
goto remove;
 
+finish:
if (!oldcard)
host-card = card;
return 0;
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index d02d2c6..cbc745c 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -101,6 +101,8 @@ struct mmc_card {
 #define MMC_QUIRK_LENIENT_FN0  (10)  /* allow SDIO FN0 writes 
outside of the VS CCCR range */
 #define MMC_QUIRK_BLKSZ_FOR_BYTE_MODE (11)   /* use func-cur_blksize */
/* for byte mode */
+#define MMC_QUIRK_NONSTD_SDIO  (12)  /* non-standard SDIO card 
attached */
+   /* (missing CIA registers) */
 
u32 raw_cid[4]; /* raw card CID */
u32 raw_csd[4]; /* raw card CSD */
-- 
1.6.3.3

--
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/3] omap_hsmmc: add init_card pass-through callback

2010-06-29 Thread Grazvydas Ignotas
This will allow us to set up special cards in machine drivers just
after they are detected by MMC core.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 arch/arm/plat-omap/include/plat/mmc.h |2 ++
 drivers/mmc/host/omap_hsmmc.c |   10 ++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/mmc.h 
b/arch/arm/plat-omap/include/plat/mmc.h
index c835f1e..9b89ec6 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -122,6 +122,8 @@ struct omap_mmc_platform_data {
/* Call back after enabling / disabling regulators */
void (*after_set_reg)(struct device *dev, int slot,
  int power_on, int vdd);
+   /* if we have special card, init it using this callback */
+   void (*init_card)(struct mmc_card *card);
 
/* return MMC cover switch state, can be NULL if not supported.
 *
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b032828..e8eb39e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1598,6 +1598,14 @@ static int omap_hsmmc_get_ro(struct mmc_host *mmc)
return mmc_slot(host).get_ro(host-dev, 0);
 }
 
+static void omap_hsmmc_init_card(struct mmc_host *mmc, struct mmc_card *card)
+{
+   struct omap_hsmmc_host *host = mmc_priv(mmc);
+
+   if (mmc_slot(host).init_card)
+   mmc_slot(host).init_card(card);
+}
+
 static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
 {
u32 hctl, capa, value;
@@ -1869,6 +1877,7 @@ static const struct mmc_host_ops omap_hsmmc_ops = {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
+   .init_card = omap_hsmmc_init_card,
/* NYET -- enable_sdio_irq */
 };
 
@@ -1879,6 +1888,7 @@ static const struct mmc_host_ops omap_hsmmc_ps_ops = {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
+   .init_card = omap_hsmmc_init_card,
/* NYET -- enable_sdio_irq */
 };
 
-- 
1.6.3.3

--
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 3/3] omap: pandora: pass wl1251 information to SDIO core

2010-06-29 Thread Grazvydas Ignotas
Pandora has TI WL1251 attached on MMC3, which is non-standard SDIO chip.
Make use MMC_QUIRK_NONSTD_SDIO to tell SDIO core about it.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 arch/arm/mach-omap2/board-omap3pandora.c |   16 
 arch/arm/mach-omap2/hsmmc.c  |1 +
 arch/arm/mach-omap2/hsmmc.h  |4 
 3 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3pandora.c 
b/arch/arm/mach-omap2/board-omap3pandora.c
index db06dc9..ebbfb49 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -29,6 +29,7 @@
 #include linux/input.h
 #include linux/input/matrix_keypad.h
 #include linux/gpio_keys.h
+#include linux/mmc/card.h
 
 #include asm/mach-types.h
 #include asm/mach/arch.h
@@ -227,6 +228,20 @@ static struct platform_device pandora_dss_device = {
},
 };
 
+static void pandora_wl1251_init_card(struct mmc_card *card)
+{
+   /*
+* We have TI wl1251 attached to MMC3. Pass this information to
+* SDIO core because it can't be probed by normal methods.
+*/
+   card-quirks |= MMC_QUIRK_NONSTD_SDIO;
+   card-cccr.wide_bus = 1;
+   card-cis.vendor = 0x104c;
+   card-cis.device = 0x9066;
+   card-cis.blksize = 512;
+   card-cis.max_dtr = 2000;
+}
+
 static struct omap2_hsmmc_info omap3pandora_mmc[] = {
{
.mmc= 1,
@@ -248,6 +263,7 @@ static struct omap2_hsmmc_info omap3pandora_mmc[] = {
.wires  = 4,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
+   .init_card  = pandora_wl1251_init_card,
},
{}  /* Terminator */
 };
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 1ef54b0..c8f647b 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -268,6 +268,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info 
*controllers)
mmc-slots[0].gpio_wp = c-gpio_wp;
 
mmc-slots[0].remux = c-remux;
+   mmc-slots[0].init_card = c-init_card;
 
if (c-cover_only)
mmc-slots[0].cover = 1;
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 36f0ba8..1fe6f01 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -6,6 +6,8 @@
  * published by the Free Software Foundation.
  */
 
+struct mmc_card;
+
 struct omap2_hsmmc_info {
u8  mmc;/* controller 1/2/3 */
u8  wires;  /* 1/4/8 wires */
@@ -23,6 +25,8 @@ struct omap2_hsmmc_info {
int ocr_mask;   /* temporary HACK */
/* Remux (pad configuation) when powering on/off */
void (*remux)(struct device *dev, int slot, int power_on);
+   /* init some special card */
+   void (*init_card)(struct mmc_card *card);
 };
 
 #if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
-- 
1.6.3.3

--
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: + sdio-add-new-function-for-raw-read-after-write-operation.patch added to -mm tree

2010-05-20 Thread Grazvydas Ignotas
Here is updated version that addresses your comments (removes BUG()
and improves argument name).

--
From: Grazvydas Ignotas nota...@gmail.com
Subject: sdio: add new function for RAW (Read after Write) operation

SDIO specification allows RAW (Read after Write) operation using
IO_RW_DIRECT command (CMD52) by setting the RAW bit. This operation is
similar to ordinary read/write commands, except that both write and read
are performed using single command/response pair. The Linux SDIO layer
already supports this internally, only external function is missing for
drivers to make use, which is added by this patch.

This type of command is required to implement proper power save mode
support in wl1251 wifi driver.

Android has similar patch for G1 in it's tree for the same reason:

http://android.git.kernel.org/?p=kernel/common.git;a=commitdiff;h=74a47786f6ecbe6c1cf9fb15efe6a968451deb52

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/mmc/core/sdio_io.c|   30 ++
 include/linux/mmc/sdio_func.h |3 +++
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
index ff27c8c..0f687cd 100644
--- a/drivers/mmc/core/sdio_io.c
+++ b/drivers/mmc/core/sdio_io.c
@@ -406,6 +406,36 @@ void sdio_writeb(struct sdio_func *func, u8 b, unsigned 
int addr, int *err_ret)
 EXPORT_SYMBOL_GPL(sdio_writeb);
 
 /**
+ * sdio_writeb_readb - write and read a byte from SDIO function
+ * @func: SDIO function to access
+ * @write_byte: byte to write
+ * @addr: address to write to
+ * @err_ret: optional status value from transfer
+ *
+ * Performs a RAW (Read after Write) operation as defined by SDIO spec -
+ * single byte is written to address space of a given SDIO function and
+ * response is read back from the same address, both using single request.
+ * If there is a problem with the operation, 0xff is returned and
+ * @err_ret will contain the error code.
+ */
+u8 sdio_writeb_readb(struct sdio_func *func, u8 write_byte,
+   unsigned int addr, int *err_ret)
+{
+   int ret;
+   u8 val;
+
+   ret = mmc_io_rw_direct(func-card, 1, func-num, addr,
+   write_byte, val);
+   if (err_ret)
+   *err_ret = ret;
+   if (ret)
+   val = 0xff;
+
+   return val;
+}
+EXPORT_SYMBOL_GPL(sdio_writeb_readb);
+
+/**
  * sdio_memcpy_fromio - read a chunk of memory from a SDIO function
  * @func: SDIO function to access
  * @dst: buffer to store the data
diff --git a/include/linux/mmc/sdio_func.h b/include/linux/mmc/sdio_func.h
index c6c0cce..31baaf8 100644
--- a/include/linux/mmc/sdio_func.h
+++ b/include/linux/mmc/sdio_func.h
@@ -145,6 +145,9 @@ extern void sdio_writew(struct sdio_func *func, u16 b,
 extern void sdio_writel(struct sdio_func *func, u32 b,
unsigned int addr, int *err_ret);
 
+extern u8 sdio_writeb_readb(struct sdio_func *func, u8 write_byte,
+   unsigned int addr, int *err_ret);
+
 extern int sdio_memcpy_toio(struct sdio_func *func, unsigned int addr,
void *src, int count);
 extern int sdio_writesb(struct sdio_func *func, unsigned int addr,
-- 
1.6.3.3

--
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] sdio: add new function for RAW (Read after Write) operation

2010-05-15 Thread Grazvydas Ignotas
On Sat, May 15, 2010 at 3:02 AM, Dmitry Shmidt dimitr...@google.com wrote:
 Hi Andrew,

 wl1251 has some HW problem for ELP register that demands to do
 something like write during read in order
 not to loose bits from this register during simple read.
 Fortunately it was enough just to add low 8 bits previous register
 value to the cmd.args during read operation
 and SD Controller will behave as needed. And it was tested on real
 wl1251 device that is used in G1 and MyTouch.

 However, patch author for some reason is using WRITE operation instead of 
 READ.
 ret = mmc_io_rw_direct(func-card, 1, func-num, addr, b, val);
 1 means WRITE

 Maybe in case of wl1251 HW it is not important - to write during read,
 or to read during write, but the problem in wl1251 was during ELP
 register READ operation, so I do not understand why author used WRITE
 flag.

Well like you said, 'wl1251 [...] demands to do something like write
during read', and SDIO spec provides exactly this functionality with
the RAW flag (quoting SDIO spec):

If this bit [RAW] is set to 1 and the R/W flag is set to 1, then the
command shall read the value of the register after the write. This is
useful to allow writing to a control register and reading the status
at the same address.

If you pass WRITE flag and a pointer for read value to
mmc_io_rw_direct(), it sets the R/W and RAW bits in the CMD52 request.
According to my tests wl1251 actually ignores both R/W and RAW flags,
but by the looks of it it is expecting the RAW request. With my patch
we can add a function that both conforms the SDIO spec and suits
wl1251 hardware.

Does that make sense to you?
--
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] sdio: add new function for RAW (Read after Write) operation

2010-05-15 Thread Grazvydas Ignotas
On Sat, May 15, 2010 at 7:25 PM, Dmitry Shmidt dimitr...@google.com wrote:
 Hi Grazvydas,

 You are right.
 mmc_io_rw_direct() implementation doesn't check R/W flag and returns
 data if out != NULL.
 So if SDIO spec demands WRITE flag and wl1251 ignores it anyway,
 then we should use WRITE.
 You function name is slightly confusing I would say, but I am fine
 with the patch.

I found it a bit hard to find a fitting name that would be similar to
other SDIO function names so I'm open to suggestions. Few other names:

sdio_read_after_write_b
sdio_rawb

Maybe our kernel veteran Andrew can suggest us something? :-)
--
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] sdio: add new function for RAW (Read after Write) operation

2010-05-14 Thread Grazvydas Ignotas
Hi Kalle,

On Wed, Apr 28, 2010 at 12:18 AM, Grazvydas Ignotas nota...@gmail.com wrote:
 SDIO specification allows RAW (Read after Write) operation using
 IO_RW_DIRECT command (CMD52) by setting the RAW bit. This operation is
 similar to ordinary read/write commands, except that both write and read
 are performed using single command/response pair. The Linux SDIO layer
 already supports this internaly, only external function is missing for
 drivers to make use, which is added by this patch.

 This type of command is required to implement proper power save mode
 support in wl1251 wifi driver.

As wl1251 maintainer, can you confirm this is needed for wl1251 driver
to function in SDIO mode? Perhaps this could help convince Andrew to
merge this patch. Without this the chip is having problems leaving ELP
mode. Android has similar patch for G1 in it's tree for the same
reason:

http://android.git.kernel.org/?p=kernel/common.git;a=commitdiff;h=74a47786f6ecbe6c1cf9fb15efe6a968451deb52


 Signed-off-by: Grazvydas Ignotas nota...@gmail.com
 ---
  drivers/mmc/core/sdio_io.c    |   31 +++
  include/linux/mmc/sdio_func.h |    3 +++
  2 files changed, 34 insertions(+), 0 deletions(-)

 diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
 index ff27c8c..3f681be 100644
 --- a/drivers/mmc/core/sdio_io.c
 +++ b/drivers/mmc/core/sdio_io.c
 @@ -406,6 +406,37 @@ void sdio_writeb(struct sdio_func *func, u8 b, unsigned 
 int addr, int *err_ret)
  EXPORT_SYMBOL_GPL(sdio_writeb);

  /**
 + *     sdio_writeb_readb - write and read a byte from SDIO function
 + *     @func: SDIO function to access
 + *     @b: byte to write
 + *     @addr: address to write to
 + *     @err_ret: optional status value from transfer
 + *
 + *     Performs a RAW (Read after Write) operation as defined by SDIO spec -
 + *     single byte is written to address space of a given SDIO function and
 + *     response is read back from the same address, both using single 
 request.
 + *     If there is a problem with the operation, 0xff is returned and
 + *     @err_ret will contain the error code.
 + */
 +u8 sdio_writeb_readb(struct sdio_func *func, u8 b,
 +       unsigned int addr, int *err_ret)
 +{
 +       int ret;
 +       u8 val;
 +
 +       BUG_ON(!func);
 +
 +       ret = mmc_io_rw_direct(func-card, 1, func-num, addr, b, val);
 +       if (err_ret)
 +               *err_ret = ret;
 +       if (ret)
 +               val = 0xff;
 +
 +       return val;
 +}
 +EXPORT_SYMBOL_GPL(sdio_writeb_readb);
 +
 +/**
  *     sdio_memcpy_fromio - read a chunk of memory from a SDIO function
  *     @func: SDIO function to access
  *     @dst: buffer to store the data
 diff --git a/include/linux/mmc/sdio_func.h b/include/linux/mmc/sdio_func.h
 index c6c0cce..8974b19 100644
 --- a/include/linux/mmc/sdio_func.h
 +++ b/include/linux/mmc/sdio_func.h
 @@ -145,6 +145,9 @@ extern void sdio_writew(struct sdio_func *func, u16 b,
  extern void sdio_writel(struct sdio_func *func, u32 b,
        unsigned int addr, int *err_ret);

 +extern u8 sdio_writeb_readb(struct sdio_func *func, u8 b,
 +       unsigned int addr, int *err_ret);
 +
  extern int sdio_memcpy_toio(struct sdio_func *func, unsigned int addr,
        void *src, int count);
  extern int sdio_writesb(struct sdio_func *func, unsigned int addr,
 --
 1.6.3.3


--
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] sdio: add new function for RAW (Read after Write) operation

2010-04-27 Thread Grazvydas Ignotas
SDIO specification allows RAW (Read after Write) operation using
IO_RW_DIRECT command (CMD52) by setting the RAW bit. This operation is
similar to ordinary read/write commands, except that both write and read
are performed using single command/response pair. The Linux SDIO layer
already supports this internaly, only external function is missing for
drivers to make use, which is added by this patch.

This type of command is required to implement proper power save mode
support in wl1251 wifi driver.

Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
 drivers/mmc/core/sdio_io.c|   31 +++
 include/linux/mmc/sdio_func.h |3 +++
 2 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
index ff27c8c..3f681be 100644
--- a/drivers/mmc/core/sdio_io.c
+++ b/drivers/mmc/core/sdio_io.c
@@ -406,6 +406,37 @@ void sdio_writeb(struct sdio_func *func, u8 b, unsigned 
int addr, int *err_ret)
 EXPORT_SYMBOL_GPL(sdio_writeb);
 
 /**
+ * sdio_writeb_readb - write and read a byte from SDIO function
+ * @func: SDIO function to access
+ * @b: byte to write
+ * @addr: address to write to
+ * @err_ret: optional status value from transfer
+ *
+ * Performs a RAW (Read after Write) operation as defined by SDIO spec -
+ * single byte is written to address space of a given SDIO function and
+ * response is read back from the same address, both using single request.
+ * If there is a problem with the operation, 0xff is returned and
+ * @err_ret will contain the error code.
+ */
+u8 sdio_writeb_readb(struct sdio_func *func, u8 b,
+   unsigned int addr, int *err_ret)
+{
+   int ret;
+   u8 val;
+
+   BUG_ON(!func);
+
+   ret = mmc_io_rw_direct(func-card, 1, func-num, addr, b, val);
+   if (err_ret)
+   *err_ret = ret;
+   if (ret)
+   val = 0xff;
+
+   return val;
+}
+EXPORT_SYMBOL_GPL(sdio_writeb_readb);
+
+/**
  * sdio_memcpy_fromio - read a chunk of memory from a SDIO function
  * @func: SDIO function to access
  * @dst: buffer to store the data
diff --git a/include/linux/mmc/sdio_func.h b/include/linux/mmc/sdio_func.h
index c6c0cce..8974b19 100644
--- a/include/linux/mmc/sdio_func.h
+++ b/include/linux/mmc/sdio_func.h
@@ -145,6 +145,9 @@ extern void sdio_writew(struct sdio_func *func, u16 b,
 extern void sdio_writel(struct sdio_func *func, u32 b,
unsigned int addr, int *err_ret);
 
+extern u8 sdio_writeb_readb(struct sdio_func *func, u8 b,
+   unsigned int addr, int *err_ret);
+
 extern int sdio_memcpy_toio(struct sdio_func *func, unsigned int addr,
void *src, int count);
 extern int sdio_writesb(struct sdio_func *func, unsigned int addr,
-- 
1.6.3.3

--
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