from:"Balaji T K"

Re: [PATCH v3 0/2] omap_hsmmc DT DMA Client support

2013-04-05 Thread Balaji T K


On Wednesday 06 March 2013 07:42 PM, Matt Porter wrote:

Changes since v2:
- dropped skip platform_get_resource_byname() patch
Changes since v1:
- rebase to 3.9-rc1, previous dependencies upstream

This series adds DT DMA Engine Client support to the omap_hsmmc.
It leverages the generic DMA OF helpers and the
dma_request_slave_channel_compat() wrapper to support DMA in
omap_hsmmc on platforms booting via DT. These platforms include
omap2/3/4/5 and am33xx.

These patches were split out from the v5 version of the AM33XX DMA
series and split from the EDMA-specific omap_hsmmc changes.

Matt Porter (2):
   mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
   mmc: omap_hsmmc: add generic DMA request support to the DT binding



Looks good to me
Acked-by: Balaji T K 


  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   26 +++-
  drivers/mmc/host/omap_hsmmc.c  |   10 ++--
  2 files changed, 33 insertions(+), 3 deletions(-)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: omap_hsmmc: clear status flags before starting a new command

2013-08-25 Thread Balaji T K


On Saturday 29 June 2013 11:55 AM, Francesco Lavra wrote:

Commit 1f6b9fa40e76fffaaa0b3bd6a0bfdcf1cdc06efa consolidated writes to
the STAT register in one location, moving them from omap_hsmmc_do_irq()
to omap_hsmmc_irq(). This move has the unwanted side effect that the
controller status flags are potentially cleared after a new command has
been started as a consequence of reading the previous status flags.
This means that if the new command changes the status flags before the
IRQ routine returns, those flags may be cleared without handling the
event which asserted them, and thus missing the event.
Move the writing of the STAT register back in omap_hsmmc_do_irq(),
before handling the status flags which generated the interrupt.

Signed-off-by: Francesco Lavra 


Reviewed and Tested-by: Balaji T K 


---
  drivers/mmc/host/omap_hsmmc.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index eccedc7..301cb7e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1041,6 +1041,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
*host, int status)
}
}

+   OMAP_HSMMC_WRITE(host->base, STAT, status);
if (end_cmd || ((status & CC_EN) && host->cmd))
omap_hsmmc_cmd_done(host, host->cmd);
if ((end_trans || (status & TC_EN)) && host->mrq)
@@ -1060,7 +1061,6 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
omap_hsmmc_do_irq(host, status);

/* Flush posted write */
-   OMAP_HSMMC_WRITE(host->base, STAT, status);
status = OMAP_HSMMC_READ(host->base, STAT);
}



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]

2013-10-01 Thread Balaji T K


Hi Roger,

It has been a while, but I would like to pickup this thread. We have a couple 
of pandaboards used as test setup. These have an SDIO adapter hooked up to 
expansion connector A using MMC2. I have attached the patch file (just ignore 
platform_data stuff). Now on one board it works, but not for the other. I 
suspect a board issue so listing the two types that we use:

PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works
PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope

Any hints for me.


Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you 
isolate
it from your external SDIO adapter?


On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing).



OK, just realized that the expansion connector uses different pads for MMC2. 
However, you still
need to make sure that the other pins (connected to on board WLAN chip) are not 
muxed as MMC2.


I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not 
mistaken(?). Attached are the dmesg logs of the two boards.


Right. WLAN is supposed to use MMC5. But if you don't have Luca's patches, can 
you please ensure that those pins are muxed either as safe mode
or as MMC5? Default seems to be safe mode, but you should cross check.

Also in your patches you have set mmc2-clk to PIN_INPUT_PULLUP
Shouldn't it be PIN_OUTPUT?

Still I have no clue why it works on 4430 and not on 4460. Are you using the 
same bootloader image on both boards?


if you are using vaux1, can you check the voltage levels,

From dmesg you attached,
vaux1 is set to 1.8V on omap4430 and to 2.8V on OMAP4460

4430
[2.425750] VAUX1_6030: 1000 <--> 3000 mV at 1800 mV

4460
[2.244262] VAUX1_6030: 1000 <--> 3000 mV at 2800 mV

Can you also check with MMC_DEBUG enabled for any clues.


cheers,
-roger
--
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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Uninitialized rx_req/tx_req (was: Re: [PATCH v2 2/3] mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case)

2013-09-12 Thread Balaji T K


On Thursday 12 September 2013 06:11 PM, Geert Uytterhoeven wrote:

On Tue, Mar 5, 2013 at 10:13 PM, Matt Porter  wrote:

From: Santosh Shilimkar 

MMC driver probe will abort for DT case because of failed
platform_get_resource_byname() lookup. Fix it by skipping resource
byname lookup for device tree build.

Issue is hidden because hwmod popullates the IO resources which
helps to succeed platform_get_resource_byname() and probe.

Signed-off-by: Santosh Shilimkar 
---
  drivers/mmc/host/omap_hsmmc.c |   28 +++-
  1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e79b12d..8ae1225 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1896,21 +1896,23 @@ static int omap_hsmmc_probe(struct platform_device 
*pdev)

 omap_hsmmc_conf_bus_power(host);

-   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
-   if (!res) {
-   dev_err(mmc_dev(host->mmc), "cannot get DMA TX channel\n");
-   ret = -ENXIO;
-   goto err_irq;
-   }
-   tx_req = res->start;
+   if (!pdev->dev.of_node) {
+   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
+   if (!res) {
+   dev_err(mmc_dev(host->mmc), "cannot get DMA TX 
channel\n");
+   ret = -ENXIO;
+   goto err_irq;
+   }
+   tx_req = res->start;

-   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
-   if (!res) {
-   dev_err(mmc_dev(host->mmc), "cannot get DMA RX channel\n");
-   ret = -ENXIO;
-   goto err_irq;
+   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
+   if (!res) {
+   dev_err(mmc_dev(host->mmc), "cannot get DMA RX 
channel\n");
+   ret = -ENXIO;
+   goto err_irq;
+   }
+   rx_req = res->start;
 }
-   rx_req = res->start;

 dma_cap_zero(mask);
 dma_cap_set(DMA_SLAVE, mask);


Now this is in mainline, I get (gcc 4.1.2):

drivers/mmc/host/omap_hsmmc.c: In function ‘omap_hsmmc_probe’:
drivers/mmc/host/omap_hsmmc.c:1779: warning: ‘rx_req’ may be used
uninitialized in this function
drivers/mmc/host/omap_hsmmc.c:1779: warning: ‘tx_req’ may be used
uninitialized in this function

Indeed, rx_req and tx_req are not initialized in the DT case.

Initializing them to zero is probably not the right fix. Where are the values
supposed to come from in the DT case?

Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 -- Linus Torvalds



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Uninitialized rx_req/tx_req (was: Re: [PATCH v2 2/3] mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case)

2013-09-12 Thread Balaji T K


On Thursday 12 September 2013 06:11 PM, Geert Uytterhoeven wrote:

On Tue, Mar 5, 2013 at 10:13 PM, Matt Porter  wrote:

From: Santosh Shilimkar 

MMC driver probe will abort for DT case because of failed
platform_get_resource_byname() lookup. Fix it by skipping resource
byname lookup for device tree build.

Issue is hidden because hwmod popullates the IO resources which
helps to succeed platform_get_resource_byname() and probe.

Signed-off-by: Santosh Shilimkar 
---
  drivers/mmc/host/omap_hsmmc.c |   28 +++-
  1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e79b12d..8ae1225 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1896,21 +1896,23 @@ static int omap_hsmmc_probe(struct platform_device 
*pdev)

 omap_hsmmc_conf_bus_power(host);

-   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
-   if (!res) {
-   dev_err(mmc_dev(host->mmc), "cannot get DMA TX channel\n");
-   ret = -ENXIO;
-   goto err_irq;
-   }
-   tx_req = res->start;
+   if (!pdev->dev.of_node) {
+   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
+   if (!res) {
+   dev_err(mmc_dev(host->mmc), "cannot get DMA TX 
channel\n");
+   ret = -ENXIO;
+   goto err_irq;
+   }
+   tx_req = res->start;

-   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
-   if (!res) {
-   dev_err(mmc_dev(host->mmc), "cannot get DMA RX channel\n");
-   ret = -ENXIO;
-   goto err_irq;
+   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
+   if (!res) {
+   dev_err(mmc_dev(host->mmc), "cannot get DMA RX 
channel\n");
+   ret = -ENXIO;
+   goto err_irq;
+   }
+   rx_req = res->start;
 }
-   rx_req = res->start;

 dma_cap_zero(mask);
 dma_cap_set(DMA_SLAVE, mask);


Now this is in mainline, I get (gcc 4.1.2):

drivers/mmc/host/omap_hsmmc.c: In function ‘omap_hsmmc_probe’:
drivers/mmc/host/omap_hsmmc.c:1779: warning: ‘rx_req’ may be used
uninitialized in this function
drivers/mmc/host/omap_hsmmc.c:1779: warning: ‘tx_req’ may be used
uninitialized in this function

Indeed, rx_req and tx_req are not initialized in the DT case.

Initializing them to zero is probably not the right fix. Where are the values
supposed to come from in the DT case?


Hi,

rx_req and tx_req are not used in DT case [1].
dma_request_slave_channel is used to get dma info from mmc dt node.

__dma_request_channel is fallback case for non dt boot.

Note __dma_request_channel is called if dma info is not populated in
dts files.

static inline struct dma_chan
*__dma_request_slave_channel_compat(const dma_cap_mask_t *mask,
  dma_filter_fn fn, void *fn_param,
  struct device *dev, char *name)
{
struct dma_chan *chan;

chan = dma_request_slave_channel(dev, name);
if (chan)
return chan;

return __dma_request_channel(mask, fn, fn_param);
}


Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 -- Linus Torvalds



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 14/27] mmc: omap_hsmmc: Move away from using deprecated APIs

2013-10-10 Thread Balaji T K


On Thursday 26 September 2013 08:24 PM, Ulf Hansson wrote:

Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.

This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs. Additional cleanup done for keeping track
suspended state.

Cc: Balaji T K 
Cc: linux-o...@vger.kernel.org
Signed-off-by: Ulf Hansson 


Acked-by: Balaji T K 


---
  drivers/mmc/host/omap_hsmmc.c |   37 +++--
  1 file changed, 3 insertions(+), 34 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6ac63df..eb6fb28 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -170,7 +170,6 @@ struct omap_hsmmc_host {
unsigned intdma_sg_idx;
unsigned char   bus_mode;
unsigned char   power_mode;
-   int suspended;
int irq;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
@@ -1178,9 +1177,6 @@ static irqreturn_t omap_hsmmc_detect(int irq, void 
*dev_id)
struct omap_mmc_slot_data *slot = &mmc_slot(host);
int carddetect;

-   if (host->suspended)
-   return IRQ_HANDLED;
-
sysfs_notify(&host->mmc->class_dev.kobj, NULL, "cover_switch");

if (slot->card_detect)
@@ -1643,11 +1639,6 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void 
*data)
seq_printf(s, "mmc%d:\n ctx_loss:\t%d:%d\n\nregs:\n",
mmc->index, host->context_loss, context_loss);

-   if (host->suspended) {
-   seq_printf(s, "host suspended, can't read registers\n");
-   return 0;
-   }
-
pm_runtime_get_sync(host->dev);

seq_printf(s, "CON:\t\t0x%08x\n",
@@ -2119,23 +2110,12 @@ static void omap_hsmmc_complete(struct device *dev)

  static int omap_hsmmc_suspend(struct device *dev)
  {
-   int ret = 0;
struct omap_hsmmc_host *host = dev_get_drvdata(dev);

if (!host)
return 0;

-   if (host && host->suspended)
-   return 0;
-
pm_runtime_get_sync(host->dev);
-   host->suspended = 1;
-   ret = mmc_suspend_host(host->mmc);
-
-   if (ret) {
-   host->suspended = 0;
-   goto err;
-   }

if (!(host->mmc->pm_flags & MMC_PM_KEEP_POWER)) {
omap_hsmmc_disable_irq(host);
@@ -2145,23 +2125,19 @@ static int omap_hsmmc_suspend(struct device *dev)

if (host->dbclk)
clk_disable_unprepare(host->dbclk);
-err:
+
pm_runtime_put_sync(host->dev);
-   return ret;
+   return 0;
  }

  /* Routine to resume the MMC device */
  static int omap_hsmmc_resume(struct device *dev)
  {
-   int ret = 0;
struct omap_hsmmc_host *host = dev_get_drvdata(dev);

if (!host)
return 0;

-   if (host && !host->suspended)
-   return 0;
-
pm_runtime_get_sync(host->dev);

if (host->dbclk)
@@ -2172,16 +2148,9 @@ static int omap_hsmmc_resume(struct device *dev)

omap_hsmmc_protect_card(host);

-   /* Notify the core to resume the host */
-   ret = mmc_resume_host(host->mmc);
-   if (ret == 0)
-   host->suspended = 0;
-
pm_runtime_mark_last_busy(host->dev);
pm_runtime_put_autosuspend(host->dev);
-
-   return ret;
-
+   return 0;
  }

  #else



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ

2013-09-24 Thread Balaji T K


On Tuesday 24 September 2013 09:10 PM, Tony Lindgren wrote:

* Javier Martinez Canillas  [130924 01:06]:

The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also a GPIO or not,
the HW should be fully configured/enabled as an IRQ if a driver solely
uses IRQ APIs such as request_irq(), and never calls any GPIO-related
APIs. As such, add the missing HW setup to the OMAP GPIO controller's
irq_chip driver.

Since this bypasses the GPIO subsystem we have to ensure that another
caller won't be able to request the same GPIO pin that is used as an
IRQ and set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.


Also please mention the regression that this fixes. So far we know
that smsc911x for tobi and igep boards in mainline, and also the



MMC card detect for omap4 boards.

Hi Tony,

Card detect on omap4 board (sdp and panda) is not based on omap gpio,
so I think this fix is not applicable for omap4.

Card detect line for SD card goes to power IC on OMAP4 panda and SDP.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/3] omap_hsmmc DT DMA Client support

2013-06-17 Thread Balaji T K


On Friday 14 June 2013 11:40 PM, Joel A Fernandes wrote:

Resending on Matt's new email, thanks.

On Fri, Jun 14, 2013 at 1:10 PM, Joel A Fernandes  wrote:

Hi,

On Wed, Mar 6, 2013 at 7:37 AM, Matt Porter  wrote:

On Tue, Mar 05, 2013 at 09:26:01PM +, Arnd Bergmann wrote:

On Tuesday 05 March 2013, Matt Porter wrote:

Changes since v1:
 - rebase to 3.9-rc1, previous dependencies upstream

This series adds DT DMA Engine Client support to the omap_hsmmc.
It leverages the generic DMA OF helpers in -next and the
dma_request_slave_channel_compat() wrapper introduced in the
AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms
booting via DT. These platforms include omap2/3/4/5 and am33xx.

These patches were split out from the v5 version of the AM33XX DMA
series and split from the EDMA-specific omap_hsmmc changes.



The description seems stale, but the patches all look good to me.

I guess they can now get merged in any order.

Acked-by: Arnd Bergmann 


Yes, missed updating that to indicating that those are now in
3.9-rc1.


If there are no more changes, could this patch please be merged in for
3.10 or if not, could Matt please update the description as requested
and repost?


Hi Joel,

  mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case
  mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
got merged in 3.10 rc5

  mmc: omap_hsmmc: add generic DMA request support to the DT binding
should go along with edma dts patch series


Thanks,
Joel


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 09/11] mmc: omap_hsmmc: enhance pinctrl support

2013-06-07 Thread Balaji T K


On Tuesday 04 June 2013 08:16 PM, Tony Lindgren wrote:

* Hebbar Gururaja  [130531 03:19]:

Amend the hsmmc controller to optionally take a pin control handle and
set the state of the pins to:

- "default" on boot, resume and before performing a mmc transfer
- "idle" after initial default, after resume default, and after each
mmc/sd card access
- "sleep" on suspend()

By optionally putting the pins into sleep state in the suspend callback
we can accomplish two things.
- One is to minimize current leakage from pins and thus save power,
- second, we can prevent the IP from driving pins output in an
uncontrolled manner, which may happen if the power domain drops the
domain regulator.

If any of the above pin states are missing in dt, a warning message
about the missing state is displayed.
If certain pin-states are not available, to remove this warning message
pass respective state name with null phandler.


There's a similar patch in the "[RESEND PATCH v2 1/3] mmc: omap_hsmmc:
Enable SDIO IRQ using a GPIO in idle mode" thread. It also makes the
SDIO interrupts to work, so we need to consider that too.



Hi Tony,

I will try to combine both of these and make use of
pinctrl_pm_select_[*]_state helper functions.



We can merge the dynamic pinmuxing parts separately, but they should
be in a separate function like I posted later on in the thread above.

Regards,

Tony


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/5] ARM: dts: am33xx: Add interrupts and memory resources for MMC

2013-06-26 Thread Balaji T K


Hi Joel,

On Wednesday 26 June 2013 06:54 AM, Joel A Fernandes wrote:

From: Joel A Fernandes 

HWMOD irq entries for MMC were removed. We provide the same from DT for MMC.

This fixes issue where memory resource could not be found during probe.
Also, added the reg-offset property to account for the offset from start.

Signed-off-by: Joel A Fernandes 
---
  arch/arm/boot/dts/am33xx.dtsi |   12 
  1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 119f8a9..e0a5741 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -237,6 +237,10 @@
dmas = <&edma 24
&edma 25>;
dma-names = "tx", "rx";
+   interrupts = <64>;
+   interrupt-parent = <&intc>;
+   reg = <0x4806 0x1000>;
+   reg-offset = <0x100>;
status = "disabled";
};

@@ -247,6 +251,10 @@
dmas = <&edma 2
&edma 3>;
dma-names = "tx", "rx";
+   interrupts = <24>;


s/24/28


+   interrupt-parent = <&intc>;
+   reg = <0x481d8000 0x1000>;
+   reg-offset = <0x100>;
status = "disabled";
};

@@ -254,6 +262,10 @@
compatible = "ti,omap3-hsmmc";


compatible should be ti,omap4-hsmmc since omap4 hsmmc IP is re-used in am33xx
and reg-offset property is not needed.
combine this patch with 2/5 ARM: dts: add AM33XX MMC support and please add
your signed-off to that patch.


ti,hwmods = "mmc3";
ti,needs-special-reset;
+   interrupts = <25>;


s/25/29


+   interrupt-parent = <&intc>;
+   reg = <0x4781 0x1000>;
+   reg-offset = <0x100>;
status = "disabled";
};



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] AM33xx: MMC resources from DT without HWMOD data

2013-06-27 Thread Balaji T K


On Thursday 27 June 2013 07:56 PM, Joel A Fernandes wrote:

Hi Benoit,

On Thu, Jun 27, 2013 at 7:03 AM, Benoit Cousson  wrote:

Hi Joel,

On 06/26/2013 05:28 AM, Joel A Fernandes wrote:

On Tue, Jun 25, 2013 at 8:23 PM, Joel A Fernandes  wrote:

From: Joel A Fernandes 

This series is fixes to get MMC working on AM33XX without HWMOD data.
On removal of HWMOD data, interrupt and register properties need to be provided
for the driver to function correctly.


Please don't pull patches authored by me in this series. I have posted
them with my wrong email address by mistake. I will correct my email
during the next repost, after a round of review. Matt's patches in the
series are still good though.


In that case, please repost these in two series to avoid pulling the DTS
files in the MMC tree.


The series has been replaced with the single patch:
"[PATCH v2] ARM: dts: add AM33XX MMC support"
http://marc.info/?l=linux-omap&m=137230403815943&w=2

Some patches were squashed and others dropped in the series resulting
in the single
patch above. This patch should be good to apply

Hi Joel,

Before pushing mmc dts support for am335x, Can you please let me
know if below 2 patches [1] are merged/accepted,
IIRC these patches are needed for MMC to work properly.

I suggest to hold the dts patch until slave_sg_limit gets merged
otherwise it will cause regression in am335x mmc.

[PATCH v4 1/3] dmaengine: add dma_get_slave_sg_limits()
[PATCH v4 2/3] dma: edma: add device_slave_sg_limits() support

[1]
https://groups.google.com/forum/#!topic/linux.kernel/khTTcPtQpag



Thanks,

-Joel


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] AM33xx: MMC resources from DT without HWMOD data

2013-06-28 Thread Balaji T K


On Thursday 27 June 2013 11:38 PM, Fernandes, Joel wrote:

Hi Balaji,






Some patches were squashed and others dropped in the series resulting
in the single patch above. This patch should be good to apply

Hi Joel,

Before pushing mmc dts support for am335x, Can you please let me
know if below 2 patches [1] are merged/accepted,
IIRC these patches are needed for MMC to work properly.

I suggest to hold the dts patch until slave_sg_limit gets merged
otherwise it will cause regression in am335x mmc.

[PATCH v4 1/3] dmaengine: add dma_get_slave_sg_limits()
[PATCH v4 2/3] dma: edma: add device_slave_sg_limits() support


Actually this is an independent regression and is currently worked on by 
Lars-Peter Clausen [1].

Currently not having the MMC DTS merged is also a regression,


No, Right now mmc support is not added to am335x, so it is not really a 
regression

> so I suggest lets take it one

step at a time and get the DTS merged in first. Also there will be overhead of 
reposting this
DTS patch later again which will not change. What do you say?



If it gets enabled via dts, without slave sg limit support,
file read/write will fail, possibly corrupting file system.


Thanks,

-Joel

[1] https://patchwork.kernel.org/patch/2228041/



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: DTS: DRA7: Add TPS659038 PMIC nodes

2013-08-16 Thread Balaji T K


On Thursday 15 August 2013 05:05 AM, Nishanth Menon wrote:

linux-omap, linux-arm-list should also be CCed, Benoit needs to be
addressed for allowing him to merge,

I have not done a proper schematics Vs data manual review yet
(apologies on that), but, a couple of comments:

On 08/13/2013 12:42 AM, Keerthy wrote:

The Patch adds nodes for TPS659038 PMIC for DRA7 boards.

It is based on:
http://comments.gmane.org/gmane.linux.ports.arm.omap/102459.

Documentation:  Documentation/devicetree/bindings/mfd/palmas.txt
Documentation/devicetree/bindings/regulator/palmas-pmic.txt 


Tested on DRA7 Board, 3.11-rc5 plus the above patch-set.

Signed-off-by: Keerthy 
---
  arch/arm/boot/dts/dra7-evm.dts |  118 
  1 file changed, 118 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index b270e24..96f409f 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts




+
+   ldo1_reg: ldo1 {
+   /* LDO1_OUT --> SDIO  */
+   regulator-name = "ldo1";
+   regulator-min-microvolt = 
<180>;
+   regulator-max-microvolt = 
<330>;
+   };
+
+   ldo2_reg: ldo2 {
+   /* VDD_RTCIO */
+   regulator-name = "ldo2";
+   regulator-min-microvolt = 
<330>;
+   regulator-max-microvolt = 
<330>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   ldo3_reg: ldo3 {
+   /* VDDA_1V8 PHYs */
+   regulator-name = "ldo3";
+   regulator-min-microvolt = 
<180>;
+   regulator-max-microvolt = 
<180>;
+   };
+
+   ldo9_reg: ldo9 {
+   /* VDD_RTC */
+   regulator-name = "ldo9";
+   regulator-min-microvolt = 
<100>;
+   regulator-max-microvolt = 
<100>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   ldoln_reg: ldoln {
+   /* VDDA_1v8: PLLs */
+   regulator-name = "ldoln";
+   regulator-min-microvolt = 
<180>;
+   regulator-max-microvolt = 
<180>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   ldousb_reg: ldousb {
+   /* VDDA_3V_USB: VDDA_USBHS33 */
+   regulator-name = "ldousb";
+   regulator-min-microvolt = 
<325>;
+   regulator-max-microvolt = 
<325>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   };
+   };
+   };


Who are using these LDOs? Example SDIO LDO should be linked up with
MMC instance, no? how about the PLLs and PHYs?



ldo1_reg would be linked in follow up patches which enables sd/mmc.




  };

  &i2c2 {





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/3] mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case

2013-03-06 Thread Balaji T K


On Wednesday 06 March 2013 02:43 AM, Matt Porter wrote:

From: Santosh Shilimkar 

MMC driver probe will abort for DT case because of failed
platform_get_resource_byname() lookup. Fix it by skipping resource
byname lookup for device tree build.

Issue is hidden because hwmod popullates the IO resources which
helps to succeed platform_get_resource_byname() and probe.



Hi Matt,
Could you please drop this patch from the current series,
since this patch causes regression on omap3,4 platform
which are not yet dma dt adapted.
It is best to send this patch along with Jon Hunter dma dt series,
which adds dt dma support and mmc dma data. DMA dt series is needed
any way before hwmod cleanup can happen.



Signed-off-by: Santosh Shilimkar 
---
  drivers/mmc/host/omap_hsmmc.c |   28 +++-
  1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e79b12d..8ae1225 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1896,21 +1896,23 @@ static int omap_hsmmc_probe(struct platform_device 
*pdev)

omap_hsmmc_conf_bus_power(host);

-   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
-   if (!res) {
-   dev_err(mmc_dev(host->mmc), "cannot get DMA TX channel\n");
-   ret = -ENXIO;
-   goto err_irq;
-   }
-   tx_req = res->start;
+   if (!pdev->dev.of_node) {
+   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
+   if (!res) {
+   dev_err(mmc_dev(host->mmc), "cannot get DMA TX 
channel\n");
+   ret = -ENXIO;
+   goto err_irq;
+   }
+   tx_req = res->start;

-   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
-   if (!res) {
-   dev_err(mmc_dev(host->mmc), "cannot get DMA RX channel\n");
-   ret = -ENXIO;
-   goto err_irq;
+   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
+   if (!res) {
+   dev_err(mmc_dev(host->mmc), "cannot get DMA RX 
channel\n");
+   ret = -ENXIO;
+   goto err_irq;
+   }
+   rx_req = res->start;
}
-   rx_req = res->start;

dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arm/dts: omap5: Add mmc controller nodes and board data

2012-08-07 Thread Balaji T K

Add OMAP MMC related device tree data for OMAP5.

Signed-off-by: Balaji T K 
---
 arch/arm/boot/dts/omap5-evm.dts |   31 +++
 arch/arm/boot/dts/omap5.dtsi|   31 +++
 2 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 200c39a..7bb0c9d 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -17,4 +17,35 @@
device_type = "memory";
reg = <0x8000 0x4000>; /* 1 GB */
};
+
+   vmmcsd_fixed: fixedregulator-mmcsd {
+   compatible = "regulator-fixed";
+   regulator-name = "vmmcsd_fixed";
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   };
+};
+
+&mmc1 {
+   vmmc-supply = <&vmmcsd_fixed>;
+   bus-width = <4>;
+};
+
+&mmc2 {
+   vmmc-supply = <&vmmcsd_fixed>;
+   bus-width = <8>;
+   ti,non-removable;
+};
+
+&mmc3 {
+   bus-width = <4>;
+   ti,non-removable;
+};
+
+&mmc4 {
+   status = "disabled";
+};
+
+&mmc5 {
+   status = "disabled";
 };
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 57e5270..881d60c 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -180,5 +180,36 @@
ti,hwmods = "uart6";
clock-frequency = <4800>;
};
+
+   mmc1: mmc@4809c000 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc1";
+   ti,dual-volt;
+   ti,needs-special-reset;
+   };
+
+   mmc2: mmc@480b4000 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc2";
+   ti,needs-special-reset;
+   };
+
+   mmc3: mmc@480ad000 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc3";
+   ti,needs-special-reset;
+   };
+
+   mmc4: mmc@480d1000 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc4";
+   ti,needs-special-reset;
+   };
+
+   mmc5: mmc@480d5000 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc5";
+   ti,needs-special-reset;
+   };
};
 };
-- 
1.7.5.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFT] regulator: pbias: Convert to use regmap helper functions

2014-03-06 Thread Balaji T K


On Thursday 06 March 2014 06:40 PM, Axel Lin wrote:

This patch converts this driver to use the regmap helper functions provided by
regulator core.

This fixes a few issues in current implementation:

1) In original code, the set voltage does not check max_uV,
which means if request max_uV < 180, it will still set the voltage
to 180.

2) The is_enable implementation is wrong in some cases:
e.g. for pbias_mmc_omap5: emable_mask is : BIT(27) | BIT(25) | BIT(26)
However, pbias_regulator_enable() only sets BIT(26) | BIT(22) bits.
So is_enable always return false in this case.

Signed-off-by: Axel Lin 
---
Hi Balaji,
I don't have this h/w, so please test if it works.


Hi Axel,

There were few issues when I tried using regmap helper,
will check on this.

Thanks and Regards,
Balaji T K


Regards,
Axel
  drivers/regulator/pbias-regulator.c | 86 ++---
  1 file changed, 23 insertions(+), 63 deletions(-)

diff --git a/drivers/regulator/pbias-regulator.c 
b/drivers/regulator/pbias-regulator.c
index ded3b35..f25c91e 100644
--- a/drivers/regulator/pbias-regulator.c
+++ b/drivers/regulator/pbias-regulator.c
@@ -38,85 +38,41 @@ struct pbias_reg_info {
  struct pbias_regulator_data {
struct regulator_desc desc;
void __iomem *pbias_addr;
-   unsigned int pbias_reg;
struct regulator_dev *dev;
struct regmap *syscon;
const struct pbias_reg_info *info;
int voltage;
  };

-static int pbias_regulator_set_voltage(struct regulator_dev *dev,
-   int min_uV, int max_uV, unsigned *selector)
+static int pbias_regulator_list_voltage(struct regulator_dev *rdev,
+   unsigned int selector)
  {
-   struct pbias_regulator_data *data = rdev_get_drvdata(dev);
-   const struct pbias_reg_info *info = data->info;
-   int ret, vmode;
-
-   if (min_uV <= 180)
-   vmode = 0;
-   else if (min_uV > 180)
-   vmode = info->vmode;
-
-   ret = regmap_update_bits(data->syscon, data->pbias_reg,
-   info->vmode, vmode);
-
-   return ret;
-}
-
-static int pbias_regulator_get_voltage(struct regulator_dev *rdev)
-{
-   struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
-   const struct pbias_reg_info *info = data->info;
-   int value, voltage;
-
-   regmap_read(data->syscon, data->pbias_reg, &value);
-   value &= info->vmode;
-
-   voltage = value ? 300 : 180;
-
-   return voltage;
+   switch (selector) {
+   case 0:
+   return 180;
+   case 1:
+   return 300;
+   default:
+   return -EINVAL;
+   }
  }

  static int pbias_regulator_enable(struct regulator_dev *rdev)
  {
struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
const struct pbias_reg_info *info = data->info;
-   int ret;
-
-   ret = regmap_update_bits(data->syscon, data->pbias_reg,
-   info->enable_mask, info->enable);
-
-   return ret;
-}
-
-static int pbias_regulator_disable(struct regulator_dev *rdev)
-{
-   struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
-   const struct pbias_reg_info *info = data->info;
-   int ret;
-
-   ret = regmap_update_bits(data->syscon, data->pbias_reg,
-   info->enable_mask, 0);
-   return ret;
-}
-
-static int pbias_regulator_is_enable(struct regulator_dev *rdev)
-{
-   struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
-   const struct pbias_reg_info *info = data->info;
-   int value;
-
-   regmap_read(data->syscon, data->pbias_reg, &value);

-   return (value & info->enable_mask) == info->enable_mask;
+   return regmap_update_bits(data->syscon, rdev->desc->enable_reg,
+ info->enable_mask, info->enable);
  }

  static struct regulator_ops pbias_regulator_voltage_ops = {
-   .set_voltage= pbias_regulator_set_voltage,
-   .get_voltage= pbias_regulator_get_voltage,
-   .enable = pbias_regulator_enable,
-   .disable= pbias_regulator_disable,
-   .is_enabled = pbias_regulator_is_enable,
+   .list_voltage = pbias_regulator_list_voltage,
+   .get_voltage_sel = regulator_get_voltage_sel_regmap,
+   .set_voltage_sel = regulator_set_voltage_sel_regmap,
+   .enable = pbias_regulator_enable,
+   .disable = regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
  };

  static const struct pbias_reg_info pbias_mmc_omap2430 = {
@@ -192,6 +148,7 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
if (IS_ERR(syscon))
return PTR_ERR(syscon);

+   cfg.r

Re: [PATCH V2 2/2] ARM: dts: omap3-ldp: fix mmc configuration

2014-02-20 Thread Balaji T K


On Friday 14 February 2014 11:15 AM, Nishanth Menon wrote:

MMC1 is the only MMC interface available on the platform. Further,
since the platform is based on older revision of SoC which is not
capable of doing multi-block reads, mark it with compatibility for the
same and add pinmux to ensure that all relevant pins are configured
for non-MMC boot mode.

Signed-off-by: Nishanth Menon 


looks good to me
Acked-by: Balaji T K 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH/RFC] dmaengine: omap-dma: split header file

2014-01-24 Thread Balaji T K

To Resolve build failure seen with sh-allmodconfig:
include/linux/omap-dma.h:171:8: error: expected identifier before numeric 
constant
make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1
due to CCR redefinition, move dmaengine consumer specific function to 
omap-dmaengine.h

Tested-by: Geert Uytterhoeven 
Signed-off-by: Balaji T K 
---
 drivers/mmc/host/omap_hsmmc.c  |2 +-
 include/linux/omap-dma.h   |   19 +--
 include/linux/omap-dmaengine.h |   21 +
 3 files changed, 23 insertions(+), 19 deletions(-)
 create mode 100644 include/linux/omap-dmaengine.h

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index dbd32ad..2f57e36 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 7af25a9..6aa97e5 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -1,23 +1,6 @@
-/*
- * OMAP DMA Engine support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
 #ifndef __LINUX_OMAP_DMA_H
 #define __LINUX_OMAP_DMA_H
-
-struct dma_chan;
-
-#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
-bool omap_dma_filter_fn(struct dma_chan *, void *);
-#else
-static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
-{
-   return false;
-}
-#endif
+#include 
 
 /*
  *  Legacy OMAP DMA handling defines and functions
diff --git a/include/linux/omap-dmaengine.h b/include/linux/omap-dmaengine.h
new file mode 100644
index 000..2b0b6aa
--- /dev/null
+++ b/include/linux/omap-dmaengine.h
@@ -0,0 +1,21 @@
+/*
+ * OMAP DMA Engine support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __LINUX_OMAP_DMAENGINE_H
+#define __LINUX_OMAP_DMAENGINE_H
+
+struct dma_chan;
+
+#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
+bool omap_dma_filter_fn(struct dma_chan *, void *);
+#else
+static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
+{
+   return false;
+}
+#endif
+#endif /* __LINUX_OMAP_DMAENGINE_H */
-- 
1.7.5.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH/RFC] dmaengine: omap-dma: split header file

2014-01-24 Thread Balaji T K


On Friday 24 January 2014 10:21 PM, Balaji T K wrote:

To Resolve build failure seen with sh-allmodconfig:
 include/linux/omap-dma.h:171:8: error: expected identifier before numeric 
constant
 make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1
due to CCR redefinition, move dmaengine consumer specific function to 
omap-dmaengine.h

Tested-by: Geert Uytterhoeven 


s/Tested-by/Reported-by


Signed-off-by: Balaji T K 
---
  drivers/mmc/host/omap_hsmmc.c  |2 +-
  include/linux/omap-dma.h   |   19 +--
  include/linux/omap-dmaengine.h |   21 +
  3 files changed, 23 insertions(+), 19 deletions(-)
  create mode 100644 include/linux/omap-dmaengine.h

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index dbd32ad..2f57e36 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -31,7 +31,7 @@
  #include 
  #include 
  #include 
-#include 
+#include 
  #include 
  #include 
  #include 
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 7af25a9..6aa97e5 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -1,23 +1,6 @@
-/*
- * OMAP DMA Engine support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
  #ifndef __LINUX_OMAP_DMA_H
  #define __LINUX_OMAP_DMA_H
-
-struct dma_chan;
-
-#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
-bool omap_dma_filter_fn(struct dma_chan *, void *);
-#else
-static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
-{
-   return false;
-}
-#endif
+#include 

  /*
   *  Legacy OMAP DMA handling defines and functions
diff --git a/include/linux/omap-dmaengine.h b/include/linux/omap-dmaengine.h
new file mode 100644
index 000..2b0b6aa
--- /dev/null
+++ b/include/linux/omap-dmaengine.h
@@ -0,0 +1,21 @@
+/*
+ * OMAP DMA Engine support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __LINUX_OMAP_DMAENGINE_H
+#define __LINUX_OMAP_DMAENGINE_H
+
+struct dma_chan;
+
+#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
+bool omap_dma_filter_fn(struct dma_chan *, void *);
+#else
+static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
+{
+   return false;
+}
+#endif
+#endif /* __LINUX_OMAP_DMAENGINE_H */



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt on AM335x

2013-10-18 Thread Balaji T K


On Friday 18 October 2013 11:50 AM, NeilBrown wrote:

On Sat,  5 Oct 2013 13:17:09 +0200 Andreas Fenkart  wrote:


The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, while in runtime
suspend, standard detection of the module block otherwise.

Signed-off-by: Andreas Fenkart 

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 1136e6b..146f3ad 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
  ti,needs-special-reset: Requires a special softreset sequence
  ti,needs-special-hs-handling: HSMMC IP needs special setting for handling 
High Speed
  ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
-SDIO irq while in suspend. Fallback to polling. Affected chips are
-am335x,
+SDIO irq while in suspend. The workaround is to reconfigure the dat1 line as a
+GPIO upon suspend. Beyond this option and the GPIO config, you also need to set
+named pinctrl states "default", "active" and "idle ", see example below.  The
+MMC driver will then then toggle between default and idle during the runtime
+Affected chips are am335x,

  --
  | PRCM |
@@ -49,3 +52,24 @@ Example:
vmmc-supply = <&vmmc>; /* phandle to regulator node */
ti,non-removable;
};
+
+[am335x with with gpio for sdio irq]
+
+   mmc1_cirq_pin: pinmux_cirq_pin {
+   pinctrl-single,pins = <
+   0x0f8 0x3f  /* MMC0_DAT1 as GPIO2_28 */
+   >;
+   };
+
+   mmc1: mmc@4806 {
+   ti,non-removable;
+   bus-width = <4>;
+   vmmc-supply = <&ldo2_reg>;
+   vmmc_aux-supply = <&vmmc>;
+   ti,quirk-swakeup-missing;
+   pinctrl-names = "default", "active", "idle";
+   pinctrl-0 = <&mmc1_pins>;
+   pinctrl-1 = <&mmc1_pins>;
+   pinctrl-2 = <&mmc1_cirq_pin>;
+   ti,cirq-gpio = <&gpio3 28 0>;
+   };



hi,
  I've been trying to get SD irq to work on my  OMAP3 DM3730.
I seems to need the magic to catch interrupts while FCLK is off, as
the only way I can get it to work at the moment is to keep FCLK on.

I discovered your patch and tried it out, but it doesn't seem to work for me.

I have a Libertas WIFI chip attached to the second mmc (which is sometimes
called mmc1, and sometimes mmc2 - very confusing!).
I added:
mmc2_cirq_pin: pinmux_cirq_pin {
pinctrl-single,pins = <
0x012e (PIN_INPUT_PULLUP | MUX_MODE4)   /* MMC2_DAT1 as 
GPIO5_5 */
>;
};

and

&mmc2 {
ti,quirk-swakeup-missing;
pinctrl-names = "default", "active", "idle";
pinctrl-0 = <&mmc2_pins>;
pinctrl-1 = <&mmc2_pins>;
pinctrl-2 = <&mmc2_cirq_pin>;
ti,cirq-gpio = <&gpio5 5 0>; /* GPIO133 = 128+5 */
};

to my dts file but it doesn't make any apparent difference.

Any idea what I might be doing wrong?
(the base kernel I am applying patches to is from 8th Oct,
  commit 0e7a3ed04f0cd4311096d691888f88569310ee6c)

BTW,
  - with the default polling, I get about 1Mb/sec with iperf
  - with sd-irq enabled and FCLK kept on the whole time, I get 4Mb/sec
  - with sd-irq enable, FCLK kept on, and the 5ms polling also
running, I get over 5Mb/sec!
Still much less than the 40Mb/sec that I would like to get...


(removing svenk...@ti.com)

Hi,

Can you check if you have bus-width property set ?
bus-width = <4>;

Thanks and Regards,
Balaji T K


Thanks,
NeilBrown



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts

2013-10-18 Thread Balaji T K


On Friday 11 October 2013 09:31 PM, Tony Lindgren wrote:

* Linus Walleij  [131011 09:05]:

On Fri, Oct 11, 2013 at 5:43 PM, Tony Lindgren  wrote:

* Linus Walleij  [131011 03:40]:

On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros  wrote:


The register handling is fine. But how do we deal with resource handling?
e.g. the block that has the deep-core registers might need to be clocked or 
powered
before the registers can be accessed.


Yeah I saw this in the code there.

In this case it seems syscon-type regmap access can be used to
read/write the registers, so maybe the pin controller also need to
  get a handle on some clock etc?


Uhh, let's not go there.. The resource availability needs to be
handled transparently in regmap code and the reg provider hardware
module driver using runtime PM.


OK we can surely discuss this with broonie, it makes sense to
have regmap be able to do its deed transparently.


Yes I think so too. Sounds like we need callbacks for the runtime PM
checks to the "register provider" driver. Hwo knows, maybe those
features are there already :)



Hi Tony,

Any conclusion on using regmap for omap control module non-mux registers ?

Thanks and Regards,
Balaji T K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts

2013-10-18 Thread Balaji T K


On Friday 18 October 2013 09:05 PM, Tony Lindgren wrote:

* Balaji T K  [131018 00:41]:


Any conclusion on using regmap for omap control module non-mux registers ?


I don't think anybody has even started looking into a SCM driver
yet considering there are tons of other issues to sort out.

If you're thinking about implementing the MMC PBIAS driver, I would
just implement it as a standalone driver. It seems that the PBIAS
interface to the MMC driver can be just regulator framework.


Hi Tony,

I am testing pbias regulator, Just thinking whether it should be
using regmap api or direct readl/writel



Then when we have the SCM driver available, this driver can be
updated to coordinate things with the core SCM driver.


Do you see regmap getting used for the SCM driver ?

Thanks and Regards,
Balaji T K



Regards,

Tony


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts

2013-10-11 Thread Balaji T K


On Friday 11 October 2013 09:06 PM, Tony Lindgren wrote:

What the pin control driver should do is control the pins. Whether the registers
are spread out in the entire IO-memory does not matter. We did have one system
which placed the IO-muxing together with each peripheral (!) and I did
still want
that to be handled by a single pinctrl driver picking out windows to all these
IO-ranges.

Things like the PRM which has (my guess) a gazillion registers related to its
deep-core SoC stuff should be handled by things like
drivers/mfd/syscon.c, which means it is dead simple for some other driver
using "just this one register" in that range to get a handle at it and poke it
using syscon_node_to_regmap() (just derference an ampersand ref)
syscon_regmap_lookup_by_compatible() (use a compatible string)
all returning a regmap * that you can use to poke these registers.


The register handling is fine. But how do we deal with resource handling?
e.g. the block that has the deep-core registers might need to be clocked or 
powered
before the registers can be accessed.


Right, that's the key issue here. The register access would have to be 
conditional
based on the hardware modules PM state. Otherwise we'll have hard to trace hangs
and oopses.


Hi Tony,

How are the clocks/power state currently handled in case of omap4_pmx_core,
omap4_pmx_wkup register access via pinctrl-single ?

Thanks and Regards,
Balaji T K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt on AM335x

2013-10-15 Thread Balaji T K


Thanks Andreas for the patch,

On Saturday 05 October 2013 04:47 PM, Andreas Fenkart wrote:

The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, while in runtime
suspend, standard detection of the module block otherwise.

Signed-off-by: Andreas Fenkart 

@@ -2293,23 +2440,66 @@ static int omap_hsmmc_resume(struct device *dev)
  static int omap_hsmmc_runtime_suspend(struct device *dev)
  {
struct omap_hsmmc_host *host;
+   unsigned long flags;
+   int ret = 0;

host = platform_get_drvdata(to_platform_device(dev));
omap_hsmmc_context_save(host);
dev_dbg(dev, "disabled\n");

-   return 0;
+   if (host->flags & HSMMC_SWAKEUP_QUIRK) {
+   spin_lock_irqsave(&host->irq_lock, flags);
+   OMAP_HSMMC_WRITE(host->base, ISE, 0);
+   OMAP_HSMMC_WRITE(host->base, IE, 0);
+   OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
+   spin_unlock_irqrestore(&host->irq_lock, flags);
+
+   ret = pinctrl_select_state(host->pinctrl, host->idle);
+   if (ret < 0)
+   dev_warn(mmc_dev(host->mmc), "Unable to select idle 
pinmux\n");
+
+   enable_irq(mmc_slot(host).sdio_irq);
+   }
+
+   spin_lock_irqsave(&host->irq_lock, flags);
+   /* infinite loop, if irq not cleared in omap_hsmmc_enable_sdio_irq */
+   host->flags |= HSMMC_RUNTIME_SUSPENDED;


Can you provide more details about the infinite loop and how it will get 
recovered.


+   spin_unlock_irqrestore(&host->irq_lock, flags);
+
+   return ret;
  }

  static int omap_hsmmc_runtime_resume(struct device *dev)
  {
struct omap_hsmmc_host *host;
+   unsigned long flags;
+   int ret = 0;

host = platform_get_drvdata(to_platform_device(dev));
omap_hsmmc_context_restore(host);
dev_dbg(dev, "enabled\n");

-   return 0;
+   spin_lock_irqsave(&host->irq_lock, flags);
+   /* infinite loop, if irq not cleared in omap_hsmmc_enable_sdio_irq */
+   host->flags &= ~HSMMC_RUNTIME_SUSPENDED;
+   spin_unlock_irqrestore(&host->irq_lock, flags);
+
+   if (host->flags & HSMMC_SWAKEUP_QUIRK) {
+   disable_irq(mmc_slot(host).sdio_irq);
+
+   ret = pinctrl_select_state(host->pinctrl, host->active);
+   if (ret < 0)
+   dev_warn(mmc_dev(host->mmc), "Unable to select active 
pinmux\n");
+
+   spin_lock_irqsave(&host->irq_lock, flags);
+   if (host->flags & HSMMC_SDIO_IRQ_ENABLED) {
+   OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
+   OMAP_HSMMC_WRITE(host->base, ISE, CIRQ_EN);
+   OMAP_HSMMC_WRITE(host->base, IE, CIRQ_EN);
+   }
+   spin_unlock_irqrestore(&host->irq_lock, flags);
+   }
+   return ret;
  }

  static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
diff --git a/include/linux/platform_data/mmc-omap.h 
b/include/linux/platform_data/mmc-omap.h
index 2bf1b30..fd5fff5 100644
--- a/include/linux/platform_data/mmc-omap.h
+++ b/include/linux/platform_data/mmc-omap.h
@@ -115,6 +115,7 @@ struct omap_mmc_platform_data {

int switch_pin; /* gpio (card detect) */
int gpio_wp;/* gpio (write protect) */
+   int gpio_cirq;  /* gpio (card irq) */

int (*set_bus_mode)(struct device *dev, int slot, int bus_mode);
int (*set_power)(struct device *dev, int slot,
@@ -145,6 +146,9 @@ struct omap_mmc_platform_data {
int card_detect_irq;
int (*card_detect)(struct device *dev, int slot);

+   /* SDIO IRQs */
+   int sdio_irq;
+
unsigned int ban_openended:1;

} slots[OMAP_MMC_MAX_SLOTS];



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements

2014-04-22 Thread Balaji T K


On Monday 21 April 2014 11:02 PM, Felipe Balbi wrote:

Hi,

On Wed, Mar 26, 2014 at 07:04:45PM -0500, Felipe Balbi wrote:

this series lets us access the newer registers introduced
back in OMAP4 which give us some valid information about
the OMAP HSMMC IP like max block size, support for ADMA,
support for Retention.

Right now, only setting max_blk_size correctly as supporting
ADMA and Retention will take a lot of work.

Tested on OMAP5 uEVM.

Felipe Balbi (5):
   mmc: host: omap_hsmmc: pass host as an argument
   mmc: host: omap_hsmmc: add reg_offset field
   mmc: host: omap_hsmmc: introduce new accessor functions
   mmc: host: omap_hsmmc: switch over to new accessors
   mmc: host: omap_hsmmc: set max_blk_size correctly


Got mislead by your reply to this series, about the alternative way of
reading memory size from CAPA register



this has been here for almost a month, any comments ?



Do you see any performance impact with this series ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements

2014-04-24 Thread Balaji T K


On Thursday 27 March 2014 05:34 AM, Felipe Balbi wrote:

Hi,

this series lets us access the newer registers introduced
back in OMAP4 which give us some valid information about
the OMAP HSMMC IP like max block size, support for ADMA,
support for Retention.


"Support for Retention" looks interesting, can you shed more lights
on it



Right now, only setting max_blk_size correctly as supporting
ADMA and Retention will take a lot of work.

Tested on OMAP5 uEVM.

Felipe Balbi (5):
   mmc: host: omap_hsmmc: pass host as an argument
   mmc: host: omap_hsmmc: add reg_offset field
   mmc: host: omap_hsmmc: introduce new accessor functions
   mmc: host: omap_hsmmc: switch over to new accessors
   mmc: host: omap_hsmmc: set max_blk_size correctly

  drivers/mmc/host/omap_hsmmc.c | 291 ++
  1 file changed, 182 insertions(+), 109 deletions(-)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements

2014-04-24 Thread Balaji T K


On Thursday 24 April 2014 08:09 PM, Felipe Balbi wrote:

On Thu, Apr 24, 2014 at 08:01:19PM +0530, Balaji T K wrote:

On Thursday 27 March 2014 05:34 AM, Felipe Balbi wrote:

Hi,

this series lets us access the newer registers introduced
back in OMAP4 which give us some valid information about
the OMAP HSMMC IP like max block size, support for ADMA,
support for Retention.


"Support for Retention" looks interesting, can you shed more lights on
it


HWINFO has a bit (bit 6) which tells you whether retention is supported,
it's in all TRMs since OMAP3630 or so.

"6 RERETMODE   Retention mode generic parameter
This bit field indicates whether the
retention mode is supported using the
pin PIRFFRET.

0x0: Retention mode disabled
0x1: Retention mode enabled"



I have seen that but just wondering how the driver can make use of it :-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/5] mmc: host: omap_hsmmc: introduce new accessor functions

2014-04-24 Thread Balaji T K


On Thursday 27 March 2014 05:34 AM, Felipe Balbi wrote:

we introduce new accessors which provide for register
access with and without offsets.

This is just to make sure newer versions of the IP
can access the new registers prepended at the beginning
of the address space.

Signed-off-by: Felipe Balbi 
---
  drivers/mmc/host/omap_hsmmc.c | 36 
  1 file changed, 36 insertions(+)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d46f768..e596c6a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -211,6 +211,42 @@ struct omap_hsmmc_host {
struct  omap_mmc_platform_data  *pdata;
  };

+static inline int _omap_hsmmc_read(struct omap_hsmmc_host *host,
+   u32 reg, bool offset)
+{
+   return readl(host->base + reg + (offset ? host->reg_offset : 0));
+}
+
+static inline void _omap_hsmmc_write(struct omap_hsmmc_host *host,
+   u32 reg, u32 val, bool offset)
+{
+   writel(val, host->base + reg + (offset ? host->reg_offset : 0));
+}
+
+static inline int omap_hsmmc_read_offset(struct omap_hsmmc_host *host,


I think you can rename this function as just omap_hsmmc_read
(removing _offset suffix)


+   u32 reg)
+{
+   return _omap_hsmmc_read(host, reg, true);
+}
+
+static inline void omap_hsmmc_write_offset(struct omap_hsmmc_host *host,


and this one as omap_hsmmc_write since this version of read/write is most often
used, the one with no_offset might be used less often.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements

2014-04-24 Thread Balaji T K


On Tuesday 22 April 2014 09:18 PM, Felipe Balbi wrote:

Hi,

On Tue, Apr 22, 2014 at 09:00:12PM +0530, Balaji T K wrote:

On Monday 21 April 2014 11:02 PM, Felipe Balbi wrote:

Hi,

On Wed, Mar 26, 2014 at 07:04:45PM -0500, Felipe Balbi wrote:

this series lets us access the newer registers introduced
back in OMAP4 which give us some valid information about
the OMAP HSMMC IP like max block size, support for ADMA,
support for Retention.

Right now, only setting max_blk_size correctly as supporting
ADMA and Retention will take a lot of work.

Tested on OMAP5 uEVM.

Felipe Balbi (5):
   mmc: host: omap_hsmmc: pass host as an argument
   mmc: host: omap_hsmmc: add reg_offset field
   mmc: host: omap_hsmmc: introduce new accessor functions
   mmc: host: omap_hsmmc: switch over to new accessors
   mmc: host: omap_hsmmc: set max_blk_size correctly


Got mislead by your reply to this series, about the alternative way of
reading memory size from CAPA register


sure, we can do that if you prefer, I just felt I wouldn't touch

> platforms I can't really test :-s

I think so, since those 3 newer registers are not documented for all platforms.
Not sure whether it is valid in those cases where it is not documented.

Since capa register has these info and can be
applied uniformly across all paltforms, I feel reading capa register is the
way to go. Do you still think there is a need for new api with no offset ?




this has been here for almost a month, any comments ?



Do you see any performance impact with this series ?


in the normal case ? no... it helps only with large transfers



Do you have the numbers ?
Is it for read or write,
how large should the transfer size be ?

I couldn't get any performance improvements with this patch series,
Could you please share your test setup, may be I am missing something.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Multiple CCR definitions

2014-01-17 Thread Balaji T K


On Friday 17 January 2014 12:09 AM, Nishanth Menon wrote:

+linux-omap as well.

On Thu, Jan 16, 2014 at 7:07 AM, Geert Uytterhoeven
 wrote:

On Tue, Sep 10, 2013 at 11:05 PM, Linux Kernel Mailing List
 wrote:

 mmc: omap_hsmmc: use the generic config for omap2plus devices

 OMAP's hs_mmc driver is used for MMC controller operation on many
 omap2plus SoCs (OMAP2430, OMAP3, 4, 5 and AM335x).

 Considering that the device tree entries are already present for these,
 allow the driver to be built using the config ARCH_OMAP2PLUS rather
 than individually adding a config for each SoC to enable the
 support.

 Use COMPILE_TEST to enable the build for other platforms.

 Signed-off-by: Amarinder Bindra 
 Cc: Ezequiel Garcia 
 Cc: Nishanth Menon 
 Acked-by: Felipe Balbi 
 Acked-by: Balaji T K 
 Signed-off-by: Chris Ball 
---
  drivers/mmc/host/Kconfig |6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 84102bc..b8ce939 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -284,11 +284,11 @@ config MMC_OMAP

  config MMC_OMAP_HS
 tristate "TI OMAP High Speed Multimedia Card Interface support"
-   depends on SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4
+   depends on ARCH_OMAP2PLUS || COMPILE_TEST


sh-allmodconfig (http://kisskb.ellerman.id.au/kisskb/buildresult/10477672/):
include/linux/omap-dma.h:171:8: error: expected identifier before
numeric constant
make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1

It fails because sh #defines "CCR", which is one of the enum values in
include/linux/omap-dma.h.

I expect a similar failure on blackfin, which also has #define CCR.

Possible solutions:
   1. Rename CCR in sh/bfin to e.g. SH_CCR resp. BF_CCR.
   2. Use "depends on ARCH_OMAP2PLUS || (COMPILE_TEST && ARM)


omap-dma.h will be needed until all OMAPs are converted to DT only boot.
So depends on ARCH_OMAP2PLUS || (COMPILE_TEST && ARM) looks good to me


   3. Stop using include/linux/omap-dma.h, as it says:

  *  Legacy OMAP DMA handling defines and functions
  *
  *  NOTE: Do not use these any longer.
  *
  *  Use the generic dmaengine functions as defined in
  *  include/linux/dmaengine.h.




Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 -- Linus Torvalds

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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFT] regulator: pbias: Convert to use regmap helper functions

2014-03-07 Thread Balaji T K


On Thursday 06 March 2014 06:40 PM, Axel Lin wrote:

This patch converts this driver to use the regmap helper functions provided by
regulator core.

This fixes a few issues in current implementation:

1) In original code, the set voltage does not check max_uV,
which means if request max_uV < 180, it will still set the voltage
to 180.



Hi Axel,

May be I am not getting your logic here, why would max_uV be less than min_uV

The intention was to set vmode to 0 for any voltage request lesser than 1.8V.
With regmap conversion, set voltage of 0V will become invalid. However
since pbias is not set to 0V anywhere, I think it shouldn't be an issue.
Will test and confirm.


Thanks and Regards
Balaji T K


2) The is_enable implementation is wrong in some cases:
e.g. for pbias_mmc_omap5: emable_mask is : BIT(27) | BIT(25) | BIT(26)
However, pbias_regulator_enable() only sets BIT(26) | BIT(22) bits.
So is_enable always return false in this case.

Signed-off-by: Axel Lin 
---
Hi Balaji,
I don't have this h/w, so please test if it works.
Regards,
Axel
  drivers/regulator/pbias-regulator.c | 86 ++---
  1 file changed, 23 insertions(+), 63 deletions(-)

diff --git a/drivers/regulator/pbias-regulator.c 
b/drivers/regulator/pbias-regulator.c
index ded3b35..f25c91e 100644
--- a/drivers/regulator/pbias-regulator.c
+++ b/drivers/regulator/pbias-regulator.c
@@ -38,85 +38,41 @@ struct pbias_reg_info {
  struct pbias_regulator_data {
struct regulator_desc desc;
void __iomem *pbias_addr;
-   unsigned int pbias_reg;
struct regulator_dev *dev;
struct regmap *syscon;
const struct pbias_reg_info *info;
int voltage;
  };

-static int pbias_regulator_set_voltage(struct regulator_dev *dev,
-   int min_uV, int max_uV, unsigned *selector)
+static int pbias_regulator_list_voltage(struct regulator_dev *rdev,
+   unsigned int selector)
  {
-   struct pbias_regulator_data *data = rdev_get_drvdata(dev);
-   const struct pbias_reg_info *info = data->info;
-   int ret, vmode;
-
-   if (min_uV <= 180)
-   vmode = 0;
-   else if (min_uV > 180)
-   vmode = info->vmode;
-
-   ret = regmap_update_bits(data->syscon, data->pbias_reg,
-   info->vmode, vmode);
-
-   return ret;
-}
-
-static int pbias_regulator_get_voltage(struct regulator_dev *rdev)
-{
-   struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
-   const struct pbias_reg_info *info = data->info;
-   int value, voltage;
-
-   regmap_read(data->syscon, data->pbias_reg, &value);
-   value &= info->vmode;
-
-   voltage = value ? 300 : 180;
-
-   return voltage;
+   switch (selector) {
+   case 0:
+   return 180;
+   case 1:
+   return 300;
+   default:
+   return -EINVAL;
+   }
  }

  static int pbias_regulator_enable(struct regulator_dev *rdev)
  {
struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
const struct pbias_reg_info *info = data->info;
-   int ret;
-
-   ret = regmap_update_bits(data->syscon, data->pbias_reg,
-   info->enable_mask, info->enable);
-
-   return ret;
-}
-
-static int pbias_regulator_disable(struct regulator_dev *rdev)
-{
-   struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
-   const struct pbias_reg_info *info = data->info;
-   int ret;
-
-   ret = regmap_update_bits(data->syscon, data->pbias_reg,
-   info->enable_mask, 0);
-   return ret;
-}
-
-static int pbias_regulator_is_enable(struct regulator_dev *rdev)
-{
-   struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
-   const struct pbias_reg_info *info = data->info;
-   int value;
-
-   regmap_read(data->syscon, data->pbias_reg, &value);

-   return (value & info->enable_mask) == info->enable_mask;
+   return regmap_update_bits(data->syscon, rdev->desc->enable_reg,
+ info->enable_mask, info->enable);
  }

  static struct regulator_ops pbias_regulator_voltage_ops = {
-   .set_voltage= pbias_regulator_set_voltage,
-   .get_voltage= pbias_regulator_get_voltage,
-   .enable = pbias_regulator_enable,
-   .disable= pbias_regulator_disable,
-   .is_enabled = pbias_regulator_is_enable,
+   .list_voltage = pbias_regulator_list_voltage,
+   .get_voltage_sel = regulator_get_voltage_sel_regmap,
+   .set_voltage_sel = regulator_set_voltage_sel_regmap,
+   .enable = pbias_regulator_enable,
+   .disable = regulator_disable_regmap,
+   .is_enabled = regula

Re: [PATCH 2/3] regulator: pbias: Convert to use regmap helper functions

2014-03-07 Thread Balaji T K


On Friday 07 March 2014 09:13 PM, Axel Lin wrote:

This patch converts this driver to use the regmap helper functions provided by
regulator core.

Signed-off-by: Axel Lin 


Acked-by: Balaji T K 


---
  drivers/regulator/pbias-regulator.c | 74 ++---
  1 file changed, 19 insertions(+), 55 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] regulator: pbias: Convert to use regulator_[enable|is_enabled]_regmap

2014-03-07 Thread Balaji T K


On Friday 07 March 2014 09:20 PM, Axel Lin wrote:

Since commit ca5d1b3524b4d
"regulator: helpers: Modify helpers enabling multi-bit control",
we can set enable_val setting for device that use multiple bits for control
when using regmap enable/disable/bypass ops.

Signed-off-by: Axel Lin 
---
Note:
This patch depends on below commit which is only in regulator tree now:
http://git.kernel.org/cgit/linux/kernel/git/broonie/regulator.git/commit/?h=topic/enable

I sent this for reveiw and test now.
if it works, I'll resend it once 3.5-rc1 is released.

Hi,

I tested this series with above dependent commit and it works as excepted
So you can add my,
Tested-by: Balaji T K 

Thanks for doing regmap conversion, now pbias driver looks as minimal as 
possible.



  drivers/regulator/pbias-regulator.c | 25 +++--
  1 file changed, 3 insertions(+), 22 deletions(-)

diff --git a/drivers/regulator/pbias-regulator.c 
b/drivers/regulator/pbias-regulator.c
index 6d38be3..708ddbb 100644
--- a/drivers/regulator/pbias-regulator.c
+++ b/drivers/regulator/pbias-regulator.c
@@ -49,33 +49,13 @@ static const unsigned int pbias_volt_table[] = {
300
  };

-static int pbias_regulator_enable(struct regulator_dev *rdev)
-{
-   struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
-   const struct pbias_reg_info *info = data->info;
-
-   return regmap_update_bits(data->syscon, rdev->desc->enable_reg,
- info->enable_mask, info->enable);
-}
-
-static int pbias_regulator_is_enable(struct regulator_dev *rdev)
-{
-   struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
-   const struct pbias_reg_info *info = data->info;
-   int value;
-
-   regmap_read(data->syscon, rdev->desc->enable_reg, &value);
-
-   return (value & info->enable_mask) == info->enable;
-}
-
  static struct regulator_ops pbias_regulator_voltage_ops = {
.list_voltage = regulator_list_voltage_table,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
.set_voltage_sel = regulator_set_voltage_sel_regmap,
-   .enable = pbias_regulator_enable,
+   .enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
-   .is_enabled = pbias_regulator_is_enable,
+   .is_enabled = regulator_is_enabled_regmap,
  };

  static const struct pbias_reg_info pbias_mmc_omap2430 = {
@@ -180,6 +160,7 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
drvdata[data_idx].desc.vsel_mask = info->vmode;
drvdata[data_idx].desc.enable_reg = res->start;
drvdata[data_idx].desc.enable_mask = info->enable_mask;
+   drvdata[data_idx].desc.enable_val = info->enable;

cfg.init_data = pbias_matches[idx].init_data;
cfg.driver_data = &drvdata[data_idx];



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] regulator: pbias: Fix is_enabled callback implementation

2014-03-07 Thread Balaji T K


On Friday 07 March 2014 09:11 PM, Axel Lin wrote:

The is_enabled implementation is wrong in some cases:
e.g. for pbias_mmc_omap5: emable_mask is : BIT(27) | BIT(25) | BIT(26)

Hi Axel,

s/emable_mask/enable_mask


However, pbias_regulator_enable() only sets BIT(26) | BIT(22) bits.


You mixed up enable_mask of omap5 with .enable of omap4 :-)
above comment should be
"However, pbias_regulator_enable() only sets BIT(27) | BIT(26) bits"
Other than that
Acked-by: Balaji T K 


So is_enabled callback will always return false in this case.
Fix the logic to compare the register value with info->enable rather than
info->enable_mask.

Signed-off-by: Axel Lin 
---
  drivers/regulator/pbias-regulator.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/pbias-regulator.c 
b/drivers/regulator/pbias-regulator.c
index ded3b35..d89a1d8 100644
--- a/drivers/regulator/pbias-regulator.c
+++ b/drivers/regulator/pbias-regulator.c
@@ -108,7 +108,7 @@ static int pbias_regulator_is_enable(struct regulator_dev 
*rdev)

regmap_read(data->syscon, data->pbias_reg, &value);

-   return (value & info->enable_mask) == info->enable_mask;
+   return (value & info->enable_mask) == info->enable;
  }

  static struct regulator_ops pbias_regulator_voltage_ops = {



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 1/2] mmc: omap_hsmmc: Add support for quirky omap3 hsmmc controller

2014-02-18 Thread Balaji T K


On Friday 14 February 2014 11:15 AM, Nishanth Menon wrote:

When device is booted using devicetree, platforms impacted by Erratum
2.1.1.128 is not detected easily in the mmc driver. This erratum
indicates that the module cannot do multi-block transfers. Platforms
such as LDP which use OMAP3 ES revision prior to ES3.0 are impacted by
this.

Provide a new compatible property "ti,omap3-pre-es3-hsmmc" to allow
driver to determine if driver needs to implement quirks associated
with the specific module version (primarily because the IP revision
information is not sufficient for the same).

Signed-off-by: Nishanth Menon 


looks good to me
Acked-by: Balaji T K 


---
Changes since v1:
- new compatible flag as suggested by Tony which contains
  the relevant controller flag to work around the erratum

V1: https://patchwork.kernel.org/patch/3514851/

  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |1 +
  drivers/mmc/host/omap_hsmmc.c  |   26 +---
  2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 8c8908a..ce80561 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -10,6 +10,7 @@ Required properties:
  - compatible:
   Should be "ti,omap2-hsmmc", for OMAP2 controllers
   Should be "ti,omap3-hsmmc", for OMAP3 controllers
+ Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0
   Should be "ti,omap4-hsmmc", for OMAP4 controllers
  - ti,hwmods: Must be "mmc", n is controller instance starting 1

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 575f9cc..390f421 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -192,6 +192,11 @@ struct omap_hsmmc_host {
struct  omap_mmc_platform_data  *pdata;
  };

+struct omap_mmc_of_data {
+   u32 reg_offset;
+   u8 controller_flags;
+};
+
  static int omap_hsmmc_card_detect(struct device *dev, int slot)
  {
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -1678,18 +1683,29 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc)
  #endif

  #ifdef CONFIG_OF
-static u16 omap4_reg_offset = 0x100;
+static const struct omap_mmc_of_data omap3_pre_es3_mmc_of_data = {
+   /* See 35xx errata 2.1.1.128 in SPRZ278F */
+   .controller_flags = OMAP_HSMMC_BROKEN_MULTIBLOCK_READ,
+};
+
+static const struct omap_mmc_of_data omap4_mmc_of_data = {
+   .reg_offset = 0x100,
+};

  static const struct of_device_id omap_mmc_of_match[] = {
{
.compatible = "ti,omap2-hsmmc",
},
{
+   .compatible = "ti,omap3-pre-es3-hsmmc",
+   .data = &omap3_pre_es3_mmc_of_data,
+   },
+   {
.compatible = "ti,omap3-hsmmc",
},
{
.compatible = "ti,omap4-hsmmc",
-   .data = &omap4_reg_offset,
+   .data = &omap4_mmc_of_data,
},
{},
  };
@@ -1759,6 +1775,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
struct pinctrl *pinctrl;
+   const struct omap_mmc_of_data *data;

match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev);
if (match) {
@@ -1768,8 +1785,9 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
return PTR_ERR(pdata);

if (match->data) {
-   const u16 *offsetp = match->data;
-   pdata->reg_offset = *offsetp;
+   data = match->data;
+   pdata->reg_offset = data->reg_offset;
+   pdata->controller_flags |= data->controller_flags;
}
}




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH/RFC] dmaengine: omap-dma: split header file

2014-02-04 Thread Balaji T K


On Friday 24 January 2014 10:21 PM, Balaji T K wrote:

To Resolve build failure seen with sh-allmodconfig:
 include/linux/omap-dma.h:171:8: error: expected identifier before numeric 
constant
 make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1
due to CCR redefinition, move dmaengine consumer specific function to 
omap-dmaengine.h

Tested-by: Geert Uytterhoeven 
Signed-off-by: Balaji T K 

Hi Russell,

Ping,
If this patch looks OK, I can drop RFC and post as Patch, let me know.

Thanks and Regards,
Balaji T K


---
  drivers/mmc/host/omap_hsmmc.c  |2 +-
  include/linux/omap-dma.h   |   19 +--
  include/linux/omap-dmaengine.h |   21 +
  3 files changed, 23 insertions(+), 19 deletions(-)
  create mode 100644 include/linux/omap-dmaengine.h

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index dbd32ad..2f57e36 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -31,7 +31,7 @@
  #include 
  #include 
  #include 
-#include 
+#include 
  #include 
  #include 
  #include 
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 7af25a9..6aa97e5 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -1,23 +1,6 @@
-/*
- * OMAP DMA Engine support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
  #ifndef __LINUX_OMAP_DMA_H
  #define __LINUX_OMAP_DMA_H
-
-struct dma_chan;
-
-#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
-bool omap_dma_filter_fn(struct dma_chan *, void *);
-#else
-static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
-{
-   return false;
-}
-#endif
+#include 

  /*
   *  Legacy OMAP DMA handling defines and functions
diff --git a/include/linux/omap-dmaengine.h b/include/linux/omap-dmaengine.h
new file mode 100644
index 000..2b0b6aa
--- /dev/null
+++ b/include/linux/omap-dmaengine.h
@@ -0,0 +1,21 @@
+/*
+ * OMAP DMA Engine support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __LINUX_OMAP_DMAENGINE_H
+#define __LINUX_OMAP_DMAENGINE_H
+
+struct dma_chan;
+
+#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
+bool omap_dma_filter_fn(struct dma_chan *, void *);
+#else
+static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
+{
+   return false;
+}
+#endif
+#endif /* __LINUX_OMAP_DMAENGINE_H */



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 0/2] omap_hsmmc DT DMA Client support

Re: [PATCH] mmc: omap_hsmmc: clear status flags before starting a new command

Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]

Re: Uninitialized rx_req/tx_req (was: Re: [PATCH v2 2/3] mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case)

Re: Uninitialized rx_req/tx_req (was: Re: [PATCH v2 2/3] mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case)

Re: [PATCH 14/27] mmc: omap_hsmmc: Move away from using deprecated APIs

Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ

Re: [PATCH v2 0/3] omap_hsmmc DT DMA Client support

Re: [PATCH 09/11] mmc: omap_hsmmc: enhance pinctrl support

Re: [PATCH 3/5] ARM: dts: am33xx: Add interrupts and memory resources for MMC

Re: [PATCH 0/5] AM33xx: MMC resources from DT without HWMOD data

Re: [PATCH 0/5] AM33xx: MMC resources from DT without HWMOD data

Re: [PATCH] ARM: DTS: DRA7: Add TPS659038 PMIC nodes

Re: [PATCH v2 2/3] mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case

[PATCH] arm/dts: omap5: Add mmc controller nodes and board data

Re: [PATCH RFT] regulator: pbias: Convert to use regmap helper functions

Re: [PATCH V2 2/2] ARM: dts: omap3-ldp: fix mmc configuration

[PATCH/RFC] dmaengine: omap-dma: split header file

Re: [PATCH/RFC] dmaengine: omap-dma: split header file

Re: [PATCH v3 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt on AM335x

Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts

Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts

Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts

Re: [PATCH v3 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt on AM335x

Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements

Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements

Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements

Re: [PATCH 3/5] mmc: host: omap_hsmmc: introduce new accessor functions

Re: [PATCH 0/5] mmc: host: omap_hsmmc: a few improvements

Re: Multiple CCR definitions

Re: [PATCH RFT] regulator: pbias: Convert to use regmap helper functions

Re: [PATCH 2/3] regulator: pbias: Convert to use regmap helper functions

Re: [PATCH 3/3] regulator: pbias: Convert to use regulator_[enable|is_enabled]_regmap

Re: [PATCH 1/3] regulator: pbias: Fix is_enabled callback implementation

Re: [PATCH V2 1/2] mmc: omap_hsmmc: Add support for quirky omap3 hsmmc controller

Re: [PATCH/RFC] dmaengine: omap-dma: split header file

36 matches

Site Navigation

Mail list logo

Footer information