sdhci-tegra and power-gpios

2012-10-01 Thread Chris Ball 
Hi Stephen, tegra folks,

sdhci-tegra uses a power-gpios property in the DT:

sdhci@c8000400 {
status = okay;
cd-gpios = gpio 69 0; /* gpio PI5 */
wp-gpios = gpio 57 0; /* gpio PH1 */
power-gpios = gpio 70 0; /* gpio PI6 */
bus-width = 4;
};

which it turns on at probe-time in the driver:

plat-power_gpio = of_get_named_gpio(np, power-gpios, 0);
...
if (gpio_is_valid(plat-power_gpio)) {
rc = gpio_request(plat-power_gpio, sdhci_power);
if (rc) {
dev_err(mmc_dev(host-mmc),
failed to allocate power gpio\n);
goto err_power_req;
}
gpio_direction_output(plat-power_gpio, 1);
}

and then leaves on forever.  Seems like this should instead be a fixed
regulator (vmmc-supply) -- the MMC core would handle powering it up and
down as needed, and it's cleaner to let the regulator subsystem handle
power changes like this.  It might save you some power, too.

It's quite easy to set up a regulator and attach it to an MMC node:

vmmc1: fixedregulator@0 {
compatible = regulator-fixed;
regulator-name = fixed-supply;
regulator-min-microvolt = 220;
regulator-max-microvolt = 220;
gpio = gpio 70 0; /* gpio PI6 */
startup-delay-us = 7;
vin-supply = parent_reg;
};
..
sdhci@c8000400 {
status = okay;
cd-gpios = gpio 69 0; /* gpio PI5 */
wp-gpios = gpio 57 0; /* gpio PH1 */
vmmc-supply = vmmc1;
bus-width = 4;
};

Any interest in making this change?  I've asked other drivers
(sdhci-pxav3 and sdhci-spear) to do the same thing (although
they hadn't merged their use of power-gpios yet and tegra has).

Thanks,

- Chris.
-- 
Chris Ball   c...@laptop.org   http://printf.net/
One Laptop Per Child
--
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: sdhci-tegra and power-gpios

2012-10-01 Thread Stephen Warren 
On 10/01/2012 09:15 AM, Chris Ball wrote:
 Hi Stephen, tegra folks,
 
 sdhci-tegra uses a power-gpios property in the DT:
 
 sdhci@c8000400 {
...
 power-gpios = gpio 70 0; /* gpio PI6 */
...
 It's quite easy to set up a regulator and attach it to an MMC node:
...
 sdhci@c8000400 {
...
   vmmc-supply = vmmc1;
...
 Any interest in making this change?

Yes, it's certainly something we should be doing. Most Tegra boards will
only have all the regulators defined in device tree for the first time
in kernel 3.7, and so we've been holding off making any of the client
nodes use regulators because of that. Now that we have all the
regulators defined, I do hope we will quickly move to using them for
SDHCI. Pavan (now CC'd) will hopefully be doing this.
--
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 PATCH 10/13] spi: omap2-mcspi: dma_request_slave_channel() support for DT platforms

2012-10-01 Thread Matt Porter 
On Thu, Sep 27, 2012 at 03:06:34PM +0530, Vinod Koul wrote:
 On Fri, 2012-09-21 at 14:37 -0400, Matt Porter wrote:
  On Fri, Sep 21, 2012 at 08:42:47AM -0700, Tony Lindgren wrote:
   
   Can't we come up with a version of dma_request_slave_channel that works
   both ways for now:
   
 mcspi_dma-dma_rx =
 dma_request_slave_channel_compat(mask, omap_dma_filter_fn, sig,
 master-dev, 
   mcspi_dma-dma_rx_ch_name);
 ... 
   
   Then it's just question of patching away two lines later on rather than
   having to add all this if else to all the drivers first, then patching
   it away again.
  
  I think that something like that is workable with the implementation
  simply checking for of_node to do the right thing.
 Yes, I think it would be better to have common API but underneath two
 implementations in transitional phase.

Ok, I'll implement something for discussion in the v2 series.

-Matt
--
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 PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC

2012-10-01 Thread Matt Porter 
On Thu, Sep 27, 2012 at 03:11:08PM +0530, Vinod Koul wrote:
 On Fri, 2012-09-21 at 19:47 +0100, Russell King - ARM Linux wrote:
  On Fri, Sep 21, 2012 at 10:45:29PM +0530, S, Venkatraman wrote:
   On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter mpor...@ti.com wrote:
The EDMA DMAC has a hardware limitation that prevents supporting
scatter gather lists with any number of segments. Since the EDMA
DMA Engine driver sets the maximum segments to 16, we do the
same.
   
Note: this can be removed once the DMA Engine API supports an
API to query the DMAC's segment limitations.
   
   
   I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch
   suggests. Why don't we have a max_segs property, which when explicitly 
   specified
   in DT, will override the default ?
  
  Why not have a generic way that DMA engine can export these kinds of
  properties?
 We discussed this at KS. I was of opinion that  DMA engine should export
 controller and channel capabilities as part of the channel it returns.
 
 Some folks had an opinion that they already know how to use controller
 so may not be very helpful, but if it is going to help (which I think),
 i have a patch for this :)

Anything you can show at this point? ;) I'd be happy to drop the half-hack
for a real API. If not, I'm going to carry that to v2 atm.

-Matt
--
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] mmc: mxs-mmc: Fix merge issue causing build error

2012-10-01 Thread Marek Vasut 
The following error appeared due to trivial merge problem:

drivers/mmc/host/mxs-mmc.c: In function 'mxs_mmc_enable_sdio_irq':
drivers/mmc/host/mxs-mmc.c:527:3: error: 'struct mxs_mmc_host' has no member 
named 'base'
drivers/mmc/host/mxs-mmc.c:527:3: error: 'struct mxs_mmc_host' has no member 
named 'devid'
make[3]: *** [drivers/mmc/host/mxs-mmc.o] Error 1

This patches corrects the issue.

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Shawn Guo shawn@linaro.org
---
 drivers/mmc/host/mxs-mmc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index bb4c2bf..80d1e6d 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@ -525,7 +525,7 @@ static void mxs_mmc_enable_sdio_irq(struct mmc_host *mmc, 
int enable)
writel(BM_SSP_CTRL0_SDIO_IRQ_CHECK,
   ssp-base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
writel(BM_SSP_CTRL1_SDIO_IRQ_EN,
-  host-base + HW_SSP_CTRL1(host) + STMP_OFFSET_REG_SET);
+  ssp-base + HW_SSP_CTRL1(ssp) + STMP_OFFSET_REG_SET);
} else {
writel(BM_SSP_CTRL0_SDIO_IRQ_CHECK,
   ssp-base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
-- 
1.7.10.4

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