Re: Regression for non-eMMC cards with commit fa550189?

[Ulf Hansson]

Hi Tony,

This patch changes the sequence of how the host drivers set_ios
function gets called during probe.

Before:
1. mmc_power_off
2. mmc_power_up

Now:
1. mmc_power_up

My guess is then; the omap driver set_ios function requires that
mmc_power_off is called before a mmc_power_up.
Hopefully this requirement can be removed and fixed in the host driver somehow.

Please get back to me if you need some more assistance around this matter.

Kind regards
Ulf Hansson


On 28 May 2012 21:21, Tony Lindgren t...@atomide.com wrote:
 Hi Ulf  Chris,

 Looks like commit fa550189 (mmc: core: Prevent eMMC VCC supply to be
 cut from late init) causes MMC card to stop working at least with
 n8x0 using drivers/mmc/host/omap.c. The card(s) on it are not eMMC.

 Reverting fa550189 makes things work again. Any ideas what could
 be causing this?

 No debug output from MMC_DEBUG, looks like commands won't even
 get started?

 Regards,

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

Re: [PATCH 2/4] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode

[Ulf Hansson]

;
 +   }
 +

Hi Tony/Andreas,

I belive a pm_runtime_get_sync would be needed here, outside the
spinlock ofcourse. Before returning from this function, obviusly
return the references by a pm_runtime_put* in some form.

Then you will be able to remove the active_pinmux variable entirely,
since you know the runtime callbacks is the only place were you need
to handle the gpio irq enable|disable.

Kind regards
Ulf Hansson

 +   host-sdio_irq_en = (enable != 0) ? true : false;
 +
 +   if (host-active_pinmux) { /* register access fails without fclk */
 +   irq_mask = OMAP_HSMMC_READ(host-base, ISE);
 +   if (enable)
 +   irq_mask |= CIRQ_EN;
 +   else
 +   irq_mask = ~CIRQ_EN;
 +   OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
 +
 +   if (!host-req_in_progress)
 +   OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
 +
 +   /*
 +* evtl. need to flush posted write
 +* OMAP_HSMMC_READ(host-base, IE);
 +*/
 +   }
 +
 +   if ((mmc_slot(host).sdio_irq)) {
 +   if (enable) {
 +   enable_irq(mmc_slot(host).sdio_irq);
 +   } else {
 +   /* _nosync, see mmc_signal_sdio_irq */
 +   disable_irq_nosync(mmc_slot(host).sdio_irq);
 +   }
 +   }
 +
 +   spin_unlock_irqrestore(host-irq_lock, flags);
 +}
 +
  static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
  {
 u32 hctl, capa, value;
 @@ -1606,7 +1709,7 @@ static const struct mmc_host_ops omap_hsmmc_ops = {
 .get_cd = omap_hsmmc_get_cd,
 .get_ro = omap_hsmmc_get_ro,
 .init_card = omap_hsmmc_init_card,
 -   /* NYET -- enable_sdio_irq */
 +   .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
  };

  #ifdef CONFIG_DEBUG_FS
 @@ -1710,6 +1813,7 @@ static struct omap_mmc_platform_data 
 *of_get_hsmmc_pdata(struct device *dev)
 pdata-nr_slots = 1;
 pdata-slots[0].switch_pin = cd_gpio;
 pdata-slots[0].gpio_wp = wp_gpio;
 +   pdata-slots[0].gpio_cirq = of_get_named_gpio(np, ti,cirq-gpio, 0);

 if (of_find_property(np, ti,non-removable, NULL)) {
 pdata-slots[0].nonremovable = true;
 @@ -1802,6 +1906,8 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 host-dma_ch= -1;
 host-irq   = irq;
 host-slot_id   = 0;
 +   host-sdio_irq_en = false;
 +   host-active_pinmux = true;
 host-mapbase   = res-start + pdata-reg_offset;
 host-base  = ioremap(host-mapbase, SZ_4K);
 host-power_mode = MMC_POWER_OFF;
 @@ -1955,6 +2061,29 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 pdata-resume = omap_hsmmc_resume_cdirq;
 }

 +   if ((mmc_slot(host).sdio_irq)) {
 +   /* prevent auto-enabling of IRQ */
 +   irq_set_status_flags(mmc_slot(host).sdio_irq, IRQ_NOAUTOEN);
 +   ret = request_irq(mmc_slot(host).sdio_irq, omap_hsmmc_cirq,
 + IRQF_TRIGGER_LOW | IRQF_ONESHOT,
 + mmc_hostname(mmc), host);
 +   if (ret) {
 +   dev_dbg(mmc_dev(host-mmc),
 +   Unable to grab MMC SDIO IRQ\n);
 +   goto err_irq_sdio;
 +   }
 +
 +   /*
 +* sdio_irq is managed with ref count
 +* - omap_hsmmc_enable_sdio_irq will +1/-1
 +* - pm_suspend/pm_resume will +1/-1
 +* only when sdio irq is enabled AND module will go to runtime
 +* suspend the ref count will drop to zero and the irq is
 +* effectively enabled. starting with ref count equal 2
 +*/
 +   disable_irq(mmc_slot(host).sdio_irq);
 +   }
 +
 omap_hsmmc_disable_irq(host);

 pinctrl = devm_pinctrl_get_select_default(pdev-dev);
 @@ -1962,6 +2091,19 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 dev_warn(pdev-dev,
 pins are not configured from the driver\n);

 +   /*
 +* For now, only support SDIO interrupt if we are doing
 +* muxing of dat1 when booted with DT. This is because the
 +* supposedly the wake-up events for CTPL don't work from deeper
 +* idle states. And we don't want to add new legacy mux platform
 +* init code callbacks any longer as we are moving to DT based
 +* booting anyways.
 +*/
 +   if (match) {
 +   if (!IS_ERR(pinctrl)  mmc_slot(host).sdio_irq)
 +   mmc-caps |= MMC_CAP_SDIO_IRQ;
 +   }
 +
 omap_hsmmc_protect_card(host);

 mmc_add_host(mmc);
 @@ -1986,6 +2128,9 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev

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

[Ulf Hansson]

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 balaj...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
 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
-- 
1.7.9.5

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

[PATCH 13/27] mmc: omap: Remove redundant suspend and resume callbacks

[Ulf Hansson]

Suspend and resume of cards are handled by the protocol layer and
consequently the mmc_suspend|resume_host APIs are marked as deprecated.

While moving away from using the deprecated APIs, there are nothing
left to be done for the suspend and resume callbacks, so remove them.

Cc: Jarkko Lavinen jarkko.lavi...@nokia.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
 drivers/mmc/host/omap.c |   53 ---
 1 file changed, 53 deletions(-)

diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index b94f38e..0b10a90 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -128,7 +128,6 @@ struct mmc_omap_slot {
 
 struct mmc_omap_host {
int initialized;
-   int suspended;
struct mmc_request *mrq;
struct mmc_command *cmd;
struct mmc_data *   data;
@@ -1513,61 +1512,9 @@ static int mmc_omap_remove(struct platform_device *pdev)
return 0;
 }
 
-#ifdef CONFIG_PM
-static int mmc_omap_suspend(struct platform_device *pdev, pm_message_t mesg)
-{
-   int i, ret = 0;
-   struct mmc_omap_host *host = platform_get_drvdata(pdev);
-
-   if (host == NULL || host-suspended)
-   return 0;
-
-   for (i = 0; i  host-nr_slots; i++) {
-   struct mmc_omap_slot *slot;
-
-   slot = host-slots[i];
-   ret = mmc_suspend_host(slot-mmc);
-   if (ret  0) {
-   while (--i = 0) {
-   slot = host-slots[i];
-   mmc_resume_host(slot-mmc);
-   }
-   return ret;
-   }
-   }
-   host-suspended = 1;
-   return 0;
-}
-
-static int mmc_omap_resume(struct platform_device *pdev)
-{
-   int i, ret = 0;
-   struct mmc_omap_host *host = platform_get_drvdata(pdev);
-
-   if (host == NULL || !host-suspended)
-   return 0;
-
-   for (i = 0; i  host-nr_slots; i++) {
-   struct mmc_omap_slot *slot;
-   slot = host-slots[i];
-   ret = mmc_resume_host(slot-mmc);
-   if (ret  0)
-   return ret;
-
-   host-suspended = 0;
-   }
-   return 0;
-}
-#else
-#define mmc_omap_suspend   NULL
-#define mmc_omap_resumeNULL
-#endif
-
 static struct platform_driver mmc_omap_driver = {
.probe  = mmc_omap_probe,
.remove = mmc_omap_remove,
-   .suspend= mmc_omap_suspend,
-   .resume = mmc_omap_resume,
.driver = {
.name   = DRIVER_NAME,
.owner  = THIS_MODULE,
-- 
1.7.9.5

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

Re: [PATCH V3] ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume

[Ulf Hansson]

On 15 November 2013 23:03, Kevin Hilman khil...@linaro.org wrote:
 Tony Lindgren t...@atomide.com writes:

 * Nishanth Menon n...@ti.com [131115 05:30]:
 On 11/15/2013 02:07 AM, Paul Walmsley wrote:
  On Thu, 14 Nov 2013, Nishanth Menon wrote:
 
  OMAP device hooks around suspend|resume_noirq ensures that hwmod
  devices are forced to idle using omap_device_idle/enable as part of
  the last stage of suspend activity.
 
  For a device such as i2c who uses autosuspend, it is possible to enter
  the suspend path with dev-power.runtime_status = RPM_ACTIVE.
 
  As part of the suspend flow, the generic runtime logic would increment
  it's dev-power.disable_depth to 1. This should prevent further
  pm_runtime_get_sync from succeeding once the runtime_status has been
  set to RPM_SUSPENDED.
 
  Now, as part of the suspend_noirq handler in omap_device, we force the
  following: if the device status is !suspended, we force the device
  to idle using omap_device_idle (clocks are cut etc..). This ensures
  that from a hardware perspective, the device is suspended. However,
  runtime_status is left to be active.
 
  *if* an operation is attempted after this point to
  pm_runtime_get_sync, runtime framework depends on runtime_status to
  indicate accurately the device status, and since it sees it to be
  ACTIVE, it assumes the module is functional and returns a non-error
  value. As a result the user will see pm_runtime_get succeed, however a
  register access will crash due to the lack of clocks.
 
  To prevent this from happening, we should ensure that runtime_status
  exactly indicates the device status. As a result of this change
  any further calls to pm_runtime_get* would return -EACCES (since
  disable_depth is 1). On resume, we restore the clocks and runtime
  status exactly as we suspended with. These operations are not expected
  to fail as we update the states after the core runtime framework has
  suspended itself and restore before the core runtime framework has
  resumed.
 
  Reported-by: J Keerthy j-keer...@ti.com
  Signed-off-by: Nishanth Menon n...@ti.com
  Acked-by: Rajendra Nayak rna...@ti.com
  Acked-by: Kevin Hilman khil...@linaro.org

Hi Kevin,

I am wondering if OMAP would benefit from letting the PM core allow
runtime suspends during system suspend, which is not the case as of
now.

My impression is that it could simplify OMAP drivers and the power
domain, but it would be interesting to hear your opinion in this. It
somewhat touches this patch. I guess.

The reason for bringing this up here, is that I wanted to highlight
that we are at the moment discussing the following RFC on the linux-pm
mailing list:

[RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend.

Kind regards
Ulf Hansson

 
  Looks reasonable to me.  Looks like this should be considered for -stable
  - Nishanth, what do you think?

 Every product kernel since 3.4 needed to be hacked (we have hacked in
 different ways so far) to work around this (since we never spend time
 digging deeper :( ), So, I do agree with your view that a -stable tag
 will be most beneficial.

 
  Tony or Kevin, do you want to take this one, or want me to?

 I can take it unless you have other fixes pending right now.

 This version looks good to me.

 Reviewed-by: Kevin Hilman khil...@linaro.org

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

Re: [PATCH v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.

[Ulf Hansson]

On 18 November 2013 08:53, Andreas Fenkart afenk...@gmail.com 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, the GPIO will only wake
 the module from suspend, SDIO irq detection will still happen through the
 IP block.

 Idea of remuxing the pins by Tony Lindgren as well as the implementation
 of omap_hsmmc_pin_init.

 Signed-off-by: Andreas Fenkart afenk...@gmail.com

 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;
 +   };
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 6b0ec55..b94ab08 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -36,6 +36,7 @@
  #include linux/mmc/core.h
  #include linux/mmc/mmc.h
  #include linux/io.h
 +#include linux/irq.h
  #include linux/gpio.h
  #include linux/regulator/consumer.h
  #include linux/pinctrl/consumer.h
 @@ -213,11 +214,32 @@ struct omap_hsmmc_host {
 int req_in_progress;
 int flags;
  #define HSMMC_SDIO_IRQ_ENABLED (1  0)/* SDIO irq enabled */
 +#define HSMMC_SWAKEUP_QUIRK(1  1)
 +#define HSMMC_CIRQ_GPIO_ENABLED (1  2)

 struct omap_hsmmc_next  next_data;
 +   struct pinctrl  *pinctrl;
 +   struct pinctrl_state*fixed, *active, *idle;
 struct  omap_mmc_platform_data  *pdata;
  };

 +static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
 +{
 +   struct omap_hsmmc_host *host = dev_id;
 +   unsigned long flags;
 +
 +   spin_lock_irqsave(host-irq_lock, flags);
 +   if (host-flags  HSMMC_CIRQ_GPIO_ENABLED) {
 +   disable_irq_nosync(mmc_slot(host).sdio_irq);
 +   host-flags = ~HSMMC_CIRQ_GPIO_ENABLED;
 +   }
 +   spin_unlock_irqrestore(host-irq_lock, flags);
 +
 +   pm_request_resume(host-dev); /* no use counter */

In the case were you are not waking up from system suspend, but from
runtime suspend, you likely want to signal the SDIO irq as soon as
possible. Then you should use mmc_signal_sdio_irq instead.

In the other case, when waking up from system suspend, you should be
able to completely rely on that the mmc_sdio_resume from the core
layer, will handle the IRQ.

Kind regards
Ulf Hansson

 +
 +   return IRQ_HANDLED;
 +}
 +
  static int omap_hsmmc_card_detect(struct device *dev, int slot)
  {
 struct omap_hsmmc_host *host = dev_get_drvdata(dev);
 @@ -452,10 +474,25 @@ static int omap_hsmmc_gpio_init(struct 
 omap_mmc_platform_data *pdata)
 } else
 pdata-slots[0].gpio_wp = -EINVAL;

 +   if (gpio_is_valid(pdata-slots[0].gpio_cirq)) {
 +   pdata-slots[0].sdio_irq =
 +   gpio_to_irq(pdata-slots[0].gpio_cirq);
 +   ret = gpio_request_one(pdata-slots[0].gpio_cirq, 
 GPIOF_DIR_IN,
 +  sdio_cirq);
 +   if (ret)
 +   goto err_free_ro;
 +
 +   } else {
 +   pdata-slots[0].gpio_cirq = -EINVAL

Re: [PATCH v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.

[Ulf Hansson]

On 19 November 2013 14:37, Andreas Fenkart afenk...@gmail.com wrote:
 Hi Ulf,

 2013/11/19 Ulf Hansson ulf.hans...@linaro.org:
 On 18 November 2013 08:53, Andreas Fenkart afenk...@gmail.com wrote:


 +static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
 +{
 +   struct omap_hsmmc_host *host = dev_id;
 +   unsigned long flags;
 +
 +   spin_lock_irqsave(host-irq_lock, flags);
 +   if (host-flags  HSMMC_CIRQ_GPIO_ENABLED) {
 +   disable_irq_nosync(mmc_slot(host).sdio_irq);
 +   host-flags = ~HSMMC_CIRQ_GPIO_ENABLED;
 +   }
 +   spin_unlock_irqrestore(host-irq_lock, flags);
 +
 +   pm_request_resume(host-dev); /* no use counter */

 In the case were you are not waking up from system suspend, but from
 runtime suspend, you likely want to signal the SDIO irq as soon as
 possible. Then you should use mmc_signal_sdio_irq instead.

 That was my intention first as well, and previous patches worked that way.
 SDIO IRQ while in pm_suspend is a rare event, compard to SDIO irq
 while in pm_active state.

 cat /proc/interrupts
CPU0
  80:  68349  INTC  64  mmc0
 236:   4352  GPIO  28  mmc0

 Here the Wifi module is just connected, not being pinged or iperf
 running. So the benefit will not be as big as you imagine.

You are right.


 On the other side the optimisations is not without problems, while in
 pm_suspend the functional clock is off and you must not access the
 registers of the module.

 But this is exactly whapt happens when you call mmc_signal_sdio_irq,
 it will call back into the drivers omap_hsmmc_enable_sdio_irq trying to
 disable the SDIO irq. So you must add special state machines there.

Yes, it will be somewhat complicated - I guess.


 After all it's doable but error prone, and I consider not worth the troubles
 for no noticeable speedup.

 Also have a look here, Balaji T K had a similar remark to yours
 http://www.spinics.net/lists/linux-omap/msg99832.html

Thanks, I should have looked that first. :-)

Kind regards
Ulf Hansson



 In the other case, when waking up from system suspend, you should be
 able to completely rely on that the mmc_sdio_resume from the core
 layer, will handle the IRQ.

 Kind regards
 Ulf Hansson

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

Re: [RFC PATCH v3 1/8] mmc: omap_hsmmc: use devm_regulator API

[Ulf Hansson]

On 21 November 2013 15:20, Balaji T K balaj...@ti.com wrote:
 Use devm_regulator API, while at it use
 devm_regulator_get_optional for optional vmmc_aux supply

 Signed-off-by: Balaji T K balaj...@ti.com
 ---
  drivers/mmc/host/omap_hsmmc.c |6 ++
  1 files changed, 2 insertions(+), 4 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index dbd32ad..1eb4350 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -316,7 +316,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
 *host)
 struct regulator *reg;
 int ocr_value = 0;

 -   reg = regulator_get(host-dev, vmmc);
 +   reg = devm_regulator_get(host-dev, vmmc);
 if (IS_ERR(reg)) {
 dev_err(host-dev, vmmc regulator missing\n);
 return PTR_ERR(reg);
 @@ -336,7 +336,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
 *host)
 }

 /* Allow an aux regulator */
 -   reg = regulator_get(host-dev, vmmc_aux);
 +   reg = devm_regulator_get_optional(host-dev, vmmc_aux);
 host-vcc_aux = IS_ERR(reg) ? NULL : reg;

 /* For eMMC do not power off when not in sleep state */
 @@ -366,8 +366,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
 *host)

  static void omap_hsmmc_reg_put(struct omap_hsmmc_host *host)
  {
 -   regulator_put(host-vcc);
 -   regulator_put(host-vcc_aux);
 mmc_slot(host).set_power = NULL;
  }

While you are touching this code I would suggest to convert to
mmc_regulator_get_supply instead. That mean the vmmc_aux change name
to vqmmc though, so you need to adapt for this as well then.

Kind regards
Ulf Hansson


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

Re: [RFC PATCH v3 2/8] mmc: omap_hsmmc: handle vcc and vcc_aux independently

[Ulf Hansson]

On 21 November 2013 15:20, Balaji T K balaj...@ti.com wrote:
 handle vcc and vcc_aux independently to reduce indent.

 Signed-off-by: Balaji T K balaj...@ti.com
 ---
  drivers/mmc/host/omap_hsmmc.c |   54 
 +++--
  1 files changed, 25 insertions(+), 29 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 1eb4350..342be25 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -286,11 +286,12 @@ static int omap_hsmmc_set_power(struct device *dev, int 
 slot, int power_on,
  * chips/cards need an interface voltage rail too.
  */
 if (power_on) {
 -   ret = mmc_regulator_set_ocr(host-mmc, host-vcc, vdd);
 +   if (host-vcc)
 +   ret = mmc_regulator_set_ocr(host-mmc, host-vcc, 
 vdd);
 /* Enable interface voltage rail, if needed */
 if (ret == 0  host-vcc_aux) {
 ret = regulator_enable(host-vcc_aux);
 -   if (ret  0)
 +   if (ret  0  host-vcc)
 ret = mmc_regulator_set_ocr(host-mmc,
 host-vcc, 0);
 }
 @@ -298,7 +299,7 @@ static int omap_hsmmc_set_power(struct device *dev, int 
 slot, int power_on,
 /* Shut down the rail */
 if (host-vcc_aux)
 ret = regulator_disable(host-vcc_aux);
 -   if (!ret) {
 +   if (host-vcc) {
 /* Then proceed to shut down the local regulator */
 ret = mmc_regulator_set_ocr(host-mmc,
 host-vcc, 0);
 @@ -318,10 +319,10 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
 *host)

 reg = devm_regulator_get(host-dev, vmmc);
 if (IS_ERR(reg)) {
 -   dev_err(host-dev, vmmc regulator missing\n);
 +   dev_err(host-dev, unable to get vmmc regulator %ld\n,
 +   PTR_ERR(reg));
 return PTR_ERR(reg);
 } else {
 -   mmc_slot(host).set_power = omap_hsmmc_set_power;
 host-vcc = reg;
 ocr_value = mmc_regulator_get_ocrmask(reg);
 if (!mmc_slot(host).ocr_mask) {
 @@ -334,31 +335,26 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
 *host)
 return -EINVAL;
 }
 }
 +   }
 +   mmc_slot(host).set_power = omap_hsmmc_set_power;

 -   /* Allow an aux regulator */
 -   reg = devm_regulator_get_optional(host-dev, vmmc_aux);
 -   host-vcc_aux = IS_ERR(reg) ? NULL : reg;
 +   /* Allow an aux regulator */
 +   reg = devm_regulator_get_optional(host-dev, vmmc_aux);
 +   host-vcc_aux = IS_ERR(reg) ? NULL : reg;

 -   /* For eMMC do not power off when not in sleep state */
 -   if (mmc_slot(host).no_regulator_off_init)
 -   return 0;
 -   /*
 -   * UGLY HACK:  workaround regulator framework bugs.
 -   * When the bootloader leaves a supply active, it's
 -   * initialized with zero usecount ... and we can't
 -   * disable it without first enabling it.  Until the
 -   * framework is fixed, we need a workaround like this
 -   * (which is safe for MMC, but not in general).
 -   */

The above problem is handled by the mmc core layer. I certainly think
you shall adopt your code to it.

Kind regards
Ulf Hansson

 -   if (regulator_is_enabled(host-vcc)  0 ||
 -   (host-vcc_aux  regulator_is_enabled(host-vcc_aux))) {
 -   int vdd = ffs(mmc_slot(host).ocr_mask) - 1;
 +   /* For eMMC do not power off when not in sleep state */
 +   if (mmc_slot(host).no_regulator_off_init)
 +   return 0;
 +   /*
 +* To disable boot_on regulator, enable regulator
 +* to increase usecount and then disable it.
 +*/
 +   if ((host-vcc  regulator_is_enabled(host-vcc)  0) ||
 +   (host-vcc_aux  regulator_is_enabled(host-vcc_aux))) {
 +   int vdd = ffs(mmc_slot(host).ocr_mask) - 1;

 -   mmc_slot(host).set_power(host-dev, host-slot_id,
 -1, vdd);
 -   mmc_slot(host).set_power(host-dev, host-slot_id,
 -0, 0);
 -   }
 +   mmc_slot(host).set_power(host-dev, host-slot_id, 1, vdd);
 +   mmc_slot(host).set_power(host-dev, host-slot_id, 0, 0);
 }

 return 0;
 --
 1.7.5.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-mmc in
 the body of a message to majord...@vger.kernel.org
 More

Re: [RFC PATCH v3 2/8] mmc: omap_hsmmc: handle vcc and vcc_aux independently

[Ulf Hansson]

On 10 December 2013 12:48, Balaji T K balaj...@ti.com wrote:
 On Tuesday 10 December 2013 04:39 PM, Ulf Hansson wrote:

 On 21 November 2013 15:20, Balaji T K balaj...@ti.com wrote:

 handle vcc and vcc_aux independently to reduce indent.

 Signed-off-by: Balaji T K balaj...@ti.com
 ---
   drivers/mmc/host/omap_hsmmc.c |   54
 +++--
   1 files changed, 25 insertions(+), 29 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c
 b/drivers/mmc/host/omap_hsmmc.c
 index 1eb4350..342be25 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -286,11 +286,12 @@ static int omap_hsmmc_set_power(struct device *dev,
 int slot, int power_on,
   * chips/cards need an interface voltage rail too.
   */
  if (power_on) {
 -   ret = mmc_regulator_set_ocr(host-mmc, host-vcc, vdd);
 +   if (host-vcc)
 +   ret = mmc_regulator_set_ocr(host-mmc, host-vcc,
 vdd);
  /* Enable interface voltage rail, if needed */
  if (ret == 0  host-vcc_aux) {
  ret = regulator_enable(host-vcc_aux);
 -   if (ret  0)
 +   if (ret  0  host-vcc)
  ret = mmc_regulator_set_ocr(host-mmc,
  host-vcc, 0);
  }
 @@ -298,7 +299,7 @@ static int omap_hsmmc_set_power(struct device *dev,
 int slot, int power_on,
  /* Shut down the rail */
  if (host-vcc_aux)
  ret = regulator_disable(host-vcc_aux);
 -   if (!ret) {
 +   if (host-vcc) {
  /* Then proceed to shut down the local regulator
 */
  ret = mmc_regulator_set_ocr(host-mmc,
  host-vcc, 0);
 @@ -318,10 +319,10 @@ static int omap_hsmmc_reg_get(struct
 omap_hsmmc_host *host)

  reg = devm_regulator_get(host-dev, vmmc);
  if (IS_ERR(reg)) {
 -   dev_err(host-dev, vmmc regulator missing\n);
 +   dev_err(host-dev, unable to get vmmc regulator %ld\n,
 +   PTR_ERR(reg));
  return PTR_ERR(reg);
  } else {
 -   mmc_slot(host).set_power = omap_hsmmc_set_power;
  host-vcc = reg;
  ocr_value = mmc_regulator_get_ocrmask(reg);
  if (!mmc_slot(host).ocr_mask) {
 @@ -334,31 +335,26 @@ static int omap_hsmmc_reg_get(struct
 omap_hsmmc_host *host)
  return -EINVAL;
  }
  }
 +   }
 +   mmc_slot(host).set_power = omap_hsmmc_set_power;

 -   /* Allow an aux regulator */
 -   reg = devm_regulator_get_optional(host-dev, vmmc_aux);
 -   host-vcc_aux = IS_ERR(reg) ? NULL : reg;
 +   /* Allow an aux regulator */
 +   reg = devm_regulator_get_optional(host-dev, vmmc_aux);
 +   host-vcc_aux = IS_ERR(reg) ? NULL : reg;

 -   /* For eMMC do not power off when not in sleep state */
 -   if (mmc_slot(host).no_regulator_off_init)
 -   return 0;
 -   /*
 -   * UGLY HACK:  workaround regulator framework bugs.
 -   * When the bootloader leaves a supply active, it's
 -   * initialized with zero usecount ... and we can't
 -   * disable it without first enabling it.  Until the
 -   * framework is fixed, we need a workaround like this
 -   * (which is safe for MMC, but not in general).
 -   */


 The above problem is handled by the mmc core layer. I certainly think
 you shall adopt your code to it.

 Hi Ulf,

 how about optional vqmmc, omap_hsmmc does call mmc_regulator_set_ocr for
 vmmc
 Am I missing something?

Hi Balaji,

Sorry for being to vague, let me elaborate.

1. Before omap_hsmmc_probe returns, it invokes mmc_add_host().

2. mmc_add_host() - mmc_start_host() -  mmc_power_up().

3. mmc_power_up() invokes the host driver's .set_ios() callback, to
makes sure boot-on regulators are kept enabled. Otherwise the
late_initcall, regulator_init_complete() will potentially cut power
for unused regulators.

This is important because there are SoCs that are only capable of
power cycling the VCC regulator but not VCCQ. According to the eMMC
spec, we must not cut VCC without sending the SLEEP cmd first.
Obviously, since we prevent VCC from being cut, we need to prevent
VCCQ from being cut as well.

Normally a .set_ios() function's invokes mmc_regulator_set_ocr() for
the VCC regulator. VCCQ (vmmc_aux) is handled by directly using the
regulator API (I guess we could invent an API similar to
mmc_regulator_set_ocr() but for VCCQ, but that is a future task).

So, from a host driver perspective you could add a local variable to
cache the enabled

Re: [PATCH 6/9] mmc: omap_hsmmc: Enable SDIO interrupt

[Ulf Hansson]

On 24 March 2014 15:59, Andreas Fenkart afenk...@gmail.com wrote:
 Hi,

 2014-03-24 13:43 GMT+01:00 Ulf Hansson ulf.hans...@linaro.org:
 On 21 March 2014 17:17, Balaji T K balaj...@ti.com wrote:
 From: Andreas Fenkart afenk...@gmail.com

 There have been various patches floating around for enabling
 the SDIO IRQ for hsmmc, but none of them ever got merged.

 Probably the reason for not merging the SDIO interrupt patches
 has been the lack of wake-up path for SDIO on some omaps that
 has also needed remuxing the SDIO DAT1 line to a GPIO making
 the patches complex.

 This patch adds the minimal SDIO IRQ support to hsmmc for
 omaps that do have the wake-up path. For those omaps, the
 DAT1 line need to have the wake-up enable bit set, and the
 wake-up interrupt is the same as for the MMC controller.

 This patch has been tested on am3730 es1.2 with mwifiex
 connected to MMC3 with mwifiex waking to Ethernet traffic
 from off-idle mode. Note that for omaps that do not have
 the SDIO wake-up path, this patch will not work for idle
 modes and further patches for remuxing DAT1 to GPIO are
 needed.

 Based on earlier patches [1][2] by David Vrabel
 david.vra...@csr.com, Steve Sakoman st...@sakoman.com
 and Andreas Fenkart afenk...@gmail.com with the SDIO IRQ
 handing improved following how sdhci.c is doing it.

 For now, only support SDIO interrupt if we are booted with
 a separate wake-irq configued via device tree. This is
 because omaps need the wake-irq for idle states, and some
 omaps need special quirks. And we don't want to add new
 legacy mux platform init code callbacks any longer as we
 are moving to DT based booting anyways.

 To use it, you need to specify the wake-irq using the
 interrupts-extended property.

 [1] 
 http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
 [2] http://comments.gmane.org/gmane.linux.kernel.mmc/20446

 Signed-off-by: Andreas Fenkart afenk...@gmail.com
 Signed-off-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Balaji T K balaj...@ti.com
 ---
  drivers/mmc/host/omap_hsmmc.c  |  207 
 ++--
  include/linux/platform_data/mmc-omap.h |1 +
  2 files changed, 196 insertions(+), 12 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 38a75bc..0275e0a 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -29,6 +29,7 @@
  #include linux/timer.h
  #include linux/clk.h
  #include linux/of.h
 +#include linux/of_irq.h
  #include linux/of_gpio.h
  #include linux/of_device.h
  #include linux/omap-dma.h
 @@ -36,6 +37,7 @@
  #include linux/mmc/core.h
  #include linux/mmc/mmc.h
  #include linux/io.h
 +#include linux/irq.h
  #include linux/gpio.h
  #include linux/regulator/consumer.h
  #include linux/pinctrl/consumer.h
 @@ -106,6 +108,7 @@
  #define TC_EN  (1  1)
  #define BWR_EN (1  4)
  #define BRR_EN (1  5)
 +#define CIRQ_EN(1  8)
  #define ERR_EN (1  15)
  #define CTO_EN (1  16)
  #define CCRC_EN(1  17)
 @@ -140,7 +143,6 @@
  #define VDD_3V0300 /* 30 uV */
  #define VDD_165_195(ffs(MMC_VDD_165_195) - 1)

 -#define AUTO_CMD23 (1  1)/* Auto CMD23 support */
  /*
   * One controller can have multiple slots, like on some omap boards using
   * omap.c controller driver. Luckily this is not currently done on any 
 known
 @@ -194,6 +196,7 @@ struct omap_hsmmc_host {
 u32 sysctl;
 u32 capa;
 int irq;
 +   int wake_irq;
 int use_dma, dma_ch;
 struct dma_chan *tx_chan;
 struct dma_chan *rx_chan;
 @@ -206,6 +209,11 @@ struct omap_hsmmc_host {
 int req_in_progress;
 unsigned long   clk_rate;
 unsigned intflags;
 +#define HSMMC_RUNTIME_SUSPENDED (1  0)
 +#define AUTO_CMD23 (1  1)/* Auto CMD23 support */

 merge conflict here? I do not use HSMMC_RUNTIME_SUSPEND anymore
 and of course, neither do I define AUTO_CMD23. :-)

 +#define HSMMC_SWAKEUP_QUIRK(1  2)
 +#define HSMMC_SDIO_IRQ_ENABLED (1  3)/* SDIO irq enabled */
 +#define HSMMC_WAKE_IRQ_ENABLED (1  4)
 struct omap_hsmmc_next  next_data;
 struct  omap_mmc_platform_data  *pdata;
  };
 @@ -510,27 +518,40 @@ static void omap_hsmmc_stop_clock(struct 
 omap_hsmmc_host *host)
  static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
   struct mmc_command *cmd)
  {
 -   unsigned int irq_mask;
 +   u32 irq_mask = INT_EN_MASK;
 +   unsigned long flags;

 if (host-use_dma)
 -   irq_mask = INT_EN_MASK  ~(BRR_EN | BWR_EN);
 -   else

Re: [PATCH 6/9] mmc: omap_hsmmc: Enable SDIO interrupt

[Ulf Hansson]

On 24 March 2014 17:34, Andreas Fenkart afenk...@gmail.com wrote:
 2014-03-24 17:02 GMT+01:00 Ulf Hansson ulf.hans...@linaro.org:
 On 24 March 2014 15:59, Andreas Fenkart afenk...@gmail.com wrote:
 Hi,

 2014-03-24 13:43 GMT+01:00 Ulf Hansson ulf.hans...@linaro.org:
 On 21 March 2014 17:17, Balaji T K balaj...@ti.com wrote:
 From: Andreas Fenkart afenk...@gmail.com

 There have been various patches floating around for enabling
 the SDIO IRQ for hsmmc, but none of them ever got merged.

 Probably the reason for not merging the SDIO interrupt patches
 has been the lack of wake-up path for SDIO on some omaps that
 has also needed remuxing the SDIO DAT1 line to a GPIO making
 the patches complex.

 This patch adds the minimal SDIO IRQ support to hsmmc for
 omaps that do have the wake-up path. For those omaps, the
 DAT1 line need to have the wake-up enable bit set, and the
 wake-up interrupt is the same as for the MMC controller.

 This patch has been tested on am3730 es1.2 with mwifiex
 connected to MMC3 with mwifiex waking to Ethernet traffic
 from off-idle mode. Note that for omaps that do not have
 the SDIO wake-up path, this patch will not work for idle
 modes and further patches for remuxing DAT1 to GPIO are
 needed.

 Based on earlier patches [1][2] by David Vrabel
 david.vra...@csr.com, Steve Sakoman st...@sakoman.com
 and Andreas Fenkart afenk...@gmail.com with the SDIO IRQ
 handing improved following how sdhci.c is doing it.

 For now, only support SDIO interrupt if we are booted with
 a separate wake-irq configued via device tree. This is
 because omaps need the wake-irq for idle states, and some
 omaps need special quirks. And we don't want to add new
 legacy mux platform init code callbacks any longer as we
 are moving to DT based booting anyways.

 To use it, you need to specify the wake-irq using the
 interrupts-extended property.

 [1] 
 http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
 [2] http://comments.gmane.org/gmane.linux.kernel.mmc/20446

 Signed-off-by: Andreas Fenkart afenk...@gmail.com
 Signed-off-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Balaji T K balaj...@ti.com
 ---
  drivers/mmc/host/omap_hsmmc.c  |  207 
 ++--
  include/linux/platform_data/mmc-omap.h |1 +
  2 files changed, 196 insertions(+), 12 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 38a75bc..0275e0a 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -29,6 +29,7 @@
  #include linux/timer.h
  #include linux/clk.h
  #include linux/of.h
 +#include linux/of_irq.h
  #include linux/of_gpio.h
  #include linux/of_device.h
  #include linux/omap-dma.h
 @@ -36,6 +37,7 @@
  #include linux/mmc/core.h
  #include linux/mmc/mmc.h
  #include linux/io.h
 +#include linux/irq.h
  #include linux/gpio.h
  #include linux/regulator/consumer.h
  #include linux/pinctrl/consumer.h
 @@ -106,6 +108,7 @@
  #define TC_EN  (1  1)
  #define BWR_EN (1  4)
  #define BRR_EN (1  5)
 +#define CIRQ_EN(1  8)
  #define ERR_EN (1  15)
  #define CTO_EN (1  16)
  #define CCRC_EN(1  17)
 @@ -140,7 +143,6 @@
  #define VDD_3V0300 /* 30 uV */
  #define VDD_165_195(ffs(MMC_VDD_165_195) - 1)

 -#define AUTO_CMD23 (1  1)/* Auto CMD23 support */
  /*
   * One controller can have multiple slots, like on some omap boards using
   * omap.c controller driver. Luckily this is not currently done on any 
 known
 @@ -194,6 +196,7 @@ struct omap_hsmmc_host {
 u32 sysctl;
 u32 capa;
 int irq;
 +   int wake_irq;
 int use_dma, dma_ch;
 struct dma_chan *tx_chan;
 struct dma_chan *rx_chan;
 @@ -206,6 +209,11 @@ struct omap_hsmmc_host {
 int req_in_progress;
 unsigned long   clk_rate;
 unsigned intflags;
 +#define HSMMC_RUNTIME_SUSPENDED (1  0)
 +#define AUTO_CMD23 (1  1)/* Auto CMD23 support */

 merge conflict here? I do not use HSMMC_RUNTIME_SUSPEND anymore
 and of course, neither do I define AUTO_CMD23. :-)

 +#define HSMMC_SWAKEUP_QUIRK(1  2)
 +#define HSMMC_SDIO_IRQ_ENABLED (1  3)/* SDIO irq enabled */
 +#define HSMMC_WAKE_IRQ_ENABLED (1  4)
 struct omap_hsmmc_next  next_data;
 struct  omap_mmc_platform_data  *pdata;
  };
 @@ -510,27 +518,40 @@ static void omap_hsmmc_stop_clock(struct 
 omap_hsmmc_host *host)
  static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
   struct mmc_command *cmd)
  {
 -   unsigned int irq_mask;
 +   u32 irq_mask = INT_EN_MASK

Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core

[Ulf Hansson]

 @@ -182,6 +183,8 @@ struct platform_device *of_device_alloc(struct 
 device_node *np,
 else
 of_device_make_bus_id(dev-dev);

 +   of_clk_register_runtime_pm_clocks(np, dev-dev);
 +

What about other device than platform devices? Could we handle the DT
binding at driver core at probe instead?

Kind regards
Ulf Hansson


 return dev;
  }
  EXPORT_SYMBOL(of_device_alloc);
 diff --git a/include/linux/of_clk.h b/include/linux/of_clk.h
 new file mode 100644
 index ..b9b15614e39b
 --- /dev/null
 +++ b/include/linux/of_clk.h
 @@ -0,0 +1,18 @@
 +#ifndef _LINUX_OF_CLK_H
 +#define _LINUX_OF_CLK_H
 +
 +struct device_node;
 +struct device;
 +
 +#if defined(CONFIG_OF)  defined(CONFIG_COMMON_CLK)
 +int of_clk_register_runtime_pm_clocks(struct device_node *np,
 + struct device *dev);
 +#else
 +static inline int of_clk_register_runtime_pm_clocks(struct device_node *np,
 +   struct device *dev)
 +{
 +   return 0;
 +}
 +#endif /* CONFIG_OF  CONFIG_COMMON_CLK */
 +
 +#endif /* _LINUX_OF_CLK_H */
 --
 1.7.9.5

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

Re: [PATCH 0/6] PM / clock_ops: Add helpers combining generic runtime and generic clock PM

[Ulf Hansson]

On 24 April 2014 12:26, Geert Uytterhoeven geert+rene...@glider.be wrote:
 Several platform support codes combine pm_generic_runtime_suspend() and
 pm_clk_suspend(), resp. pm_clk_resume() and pm_generic_runtime_resume() in
 their .runtime_suspend resp. .runtime_resume callbacks.

 Create helpers to consolidate.

   - [1/6] PM / clock_ops: Add helpers combining generic runtime and generic
   clock PM

How about adding the code from the above patch into the generic power
domain instead?

   - [2/6] ARM: davinci: Use generic runtime and clock helpers
   - [3/6] ARM: keystone: Use generic runtime and clock helpers
   - [4/6] ARM: omap: Use generic runtime and clock helpers
   - [5/6] drivers: sh: Use generic runtime and clock helpers

Then convert the above power domains implementations to the generic
power domain? Would that work?

Kind regards
Ulf Hansson

   - [6/6] of/clk: Use generic runtime and clock helpers

 Patches 5 and 6 have dependencies (listed in the individual patches),
 but they can be postponed and handled later.

 Thanks!

 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-pm 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-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core

[Ulf Hansson]

 Normally I don't think it's a good idea to automatically manage
 clocks from PM core or any other place but from the driver (and
 possibly the subsystem).

 The reason is simply that we hide things that normally is supposed to
 be handled by the driver. Typically a cross SOC driver should work
 fine both with and without a pm_domain. It should also not rely on
 CONFIG_PM_RUNTIME.

[Snip]


 +static int of_clk_register(struct device *dev, struct clk *clk)
 +{
 +   int error;
 +
 +   if (!dev-pm_domain) {
 +   error = pm_clk_create(dev);
 +   if (error)
 +   return error;
 +
 +   dev-pm_domain = of_clk_pm_domain;


 I am concerned about how this will work in conjunction with the
 generic power domain.

 A device can't reside in more than one pm_domain; thus I think it
 would be better to always use the generic power domain and not have a
 specific one for clocks. Typically the genpd should invoke
 pm_clk_resume|suspend from it's runtime PM callbacks.


 I'm not sure about this. A typical use case would be to gate clocks ASAP and
 then wait until device is idle long enough to consider turning off the power
 domain worthwhile. Also sometimes we may want to gate the clocks, but
 prevent power domain from being powered off to retain hardware state (e.g.
 because there is no way to read it and restore later).

So, in principle you prefer to have driver's handle clock gating to
save power from their runtime PM callbacks, instead of from the power
domain, right? Just to clarify, that's my view as well.

Kind regards
Ulf Hansson


 I believe, though, that for devices that are not inside a controllable power
 domain, this might be a good solution.

 Best regards,
 Tomasz
--
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

Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core

[Ulf Hansson]

 Hi Geert,

Some more review comments.

 +
 +
 +#ifdef CONFIG_PM_RUNTIME
 +
 +static int of_clk_pm_runtime_suspend(struct device *dev)
 +{
 +   int ret;
 +
 +   ret = pm_generic_runtime_suspend(dev);
 +   if (ret)
 +   return ret;
 +
 +   ret = pm_clk_suspend(dev);

What about slow clocks? Those aren't handled with pm_clk_suspend().

 +   if (ret) {
 +   pm_generic_runtime_resume(dev);
 +   return ret;
 +   }
 +
 +   return 0;
 +}
 +
 +static int of_clk_pm_runtime_resume(struct device *dev)
 +{
 +   pm_clk_resume(dev);

What about slow clocks? Those aren't handled with pm_clk_resume().

 +   return pm_generic_runtime_resume(dev);
 +}
 +
 +static struct dev_pm_domain of_clk_pm_domain = {
 +   .ops = {
 +   .runtime_suspend = of_clk_pm_runtime_suspend,
 +   .runtime_resume = of_clk_pm_runtime_resume,

Drivers/subsystems may invoke pm_runtime_force_suspend|resume() from
some of their system PM callbacks, which requires the runtime PM
callbacks to be defined for CONFIG_PM instead of CONFIG_PM_RUNTIME, I
believe that should be changed here as well.

 +   USE_PLATFORM_PM_SLEEP_OPS

What about other buses beside the platfrom bus. Certainly we need to
handle devices attached to any other subsystem type as well.

Kind regards
Ulf Hansson
--
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

Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core

[Ulf Hansson]

On 2 May 2014 16:35, Geert Uytterhoeven ge...@linux-m68k.org wrote:
 Hi Ulf,

 On Fri, May 2, 2014 at 10:56 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 +static int of_clk_pm_runtime_suspend(struct device *dev)
 +{
 +   int ret;
 +
 +   ret = pm_generic_runtime_suspend(dev);
 +   if (ret)
 +   return ret;
 +
 +   ret = pm_clk_suspend(dev);

 What about slow clocks? Those aren't handled with pm_clk_suspend().

 How are slow clocks handled?

clk_prepare|unprepare - these functions may sleep.

Kind regards
Ulf Hansson


 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

Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core

[Ulf Hansson]

On 2 May 2014 16:58, Geert Uytterhoeven ge...@linux-m68k.org wrote:
 Hi Ulf, Tomasz,

 On Fri, May 2, 2014 at 10:13 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 +static int of_clk_register(struct device *dev, struct clk *clk)
 +{
 +   int error;
 +
 +   if (!dev-pm_domain) {
 +   error = pm_clk_create(dev);
 +   if (error)
 +   return error;
 +
 +   dev-pm_domain = of_clk_pm_domain;


 I am concerned about how this will work in conjunction with the
 generic power domain.

 A device can't reside in more than one pm_domain; thus I think it
 would be better to always use the generic power domain and not have a
 specific one for clocks. Typically the genpd should invoke
 pm_clk_resume|suspend from it's runtime PM callbacks.

 I'm not sure about this. A typical use case would be to gate clocks ASAP and
 then wait until device is idle long enough to consider turning off the power
 domain worthwhile. Also sometimes we may want to gate the clocks, but
 prevent power domain from being powered off to retain hardware state (e.g.
 because there is no way to read it and restore later).

 So, in principle you prefer to have driver's handle clock gating to
 save power from their runtime PM callbacks, instead of from the power
 domain, right? Just to clarify, that's my view as well.

 If there's both a gate clock and a power domain, and the driver's Runtime PM
 callbacks handle clock gating, who's handling the power domain?

This is my view, not sure everybody agrees :-)

1. If you have a hardware power domain you need to implement a
pm_domain (preferably use the generic power domain).

2. If you don't have a hardware power domain, but still cares about
having a centralized solution for dev_pm_qos - you may use the generic
power domain, since it supports this.

3. If none of the above, you don't need a pm_domain at all.

Kind regards
Ulf Hansson


 Gr{oetje,eeting}s,

 Geert (still trying to fit all pieces of the
 puzzle together)

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

Re: [PATCH v2 1/6] mmc: omap_hsmmc: use devm_clk_get

[Ulf Hansson]

On 9 May 2014 18:46, Balaji T K balaj...@ti.com wrote:
 With devm_clk_get conversion clk_put can be removed in clean up path

 Signed-off-by: Balaji T K balaj...@ti.com
 ---
  drivers/mmc/host/omap_hsmmc.c |   15 ---
  1 files changed, 4 insertions(+), 11 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index b4de63b..b8ae7ee 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -1922,7 +1922,7 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)

 spin_lock_init(host-irq_lock);

 -   host-fclk = clk_get(pdev-dev, fck);
 +   host-fclk = devm_clk_get(pdev-dev, fck);
 if (IS_ERR(host-fclk)) {
 ret = PTR_ERR(host-fclk);
 host-fclk = NULL;
 @@ -1941,7 +1941,7 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)

 omap_hsmmc_context_save(host);

 -   host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
 +   host-dbclk = devm_clk_get(pdev-dev, mmchsdb_fck);
 /*
  * MMC can still work without debounce clock.
  */
 @@ -1949,7 +1949,6 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 host-dbclk = NULL;
 } else if (clk_prepare_enable(host-dbclk) != 0) {
 dev_warn(mmc_dev(host-mmc), Failed to enable debounce 
 clk\n);
 -   clk_put(host-dbclk);
 host-dbclk = NULL;

You should use the IS_ERR macro, no need to reset dbclk to NULL.

 }

 @@ -2105,11 +2104,8 @@ err_irq:
 dma_release_channel(host-rx_chan);
 pm_runtime_put_sync(host-dev);
 pm_runtime_disable(host-dev);
 -   clk_put(host-fclk);
 -   if (host-dbclk) {
 +   if (host-dbclk)

Use IS_ERR instead.

 clk_disable_unprepare(host-dbclk);
 -   clk_put(host-dbclk);
 -   }
  err1:
 iounmap(host-base);
 mmc_free_host(mmc);
 @@ -2144,11 +2140,8 @@ static int omap_hsmmc_remove(struct platform_device 
 *pdev)

 pm_runtime_put_sync(host-dev);
 pm_runtime_disable(host-dev);
 -   clk_put(host-fclk);
 -   if (host-dbclk) {
 +   if (host-dbclk)

Use IS_ERR instead.

 clk_disable_unprepare(host-dbclk);
 -   clk_put(host-dbclk);
 -   }

 omap_hsmmc_gpio_free(host-pdata);
 iounmap(host-base);
 --
 1.7.5.4


Kind regards
Ulf Hansson
--
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

Re: [PATCH v2 1/6] mmc: omap_hsmmc: use devm_clk_get

[Ulf Hansson]

On 12 May 2014 15:33, Balaji T K balaj...@ti.com wrote:
 On Monday 12 May 2014 02:03 PM, Ulf Hansson wrote:

 On 9 May 2014 18:46, Balaji T K balaj...@ti.com wrote:

 With devm_clk_get conversion clk_put can be removed in clean up path

 Signed-off-by: Balaji T K balaj...@ti.com
 ---
   drivers/mmc/host/omap_hsmmc.c |   15 ---
   1 files changed, 4 insertions(+), 11 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c
 b/drivers/mmc/host/omap_hsmmc.c
 index b4de63b..b8ae7ee 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -1922,7 +1922,7 @@ static int omap_hsmmc_probe(struct platform_device
 *pdev)

  spin_lock_init(host-irq_lock);

 -   host-fclk = clk_get(pdev-dev, fck);
 +   host-fclk = devm_clk_get(pdev-dev, fck);
  if (IS_ERR(host-fclk)) {
  ret = PTR_ERR(host-fclk);
  host-fclk = NULL;
 @@ -1941,7 +1941,7 @@ static int omap_hsmmc_probe(struct platform_device
 *pdev)

  omap_hsmmc_context_save(host);

 -   host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
 +   host-dbclk = devm_clk_get(pdev-dev, mmchsdb_fck);
  /*
   * MMC can still work without debounce clock.
   */
 @@ -1949,7 +1949,6 @@ static int omap_hsmmc_probe(struct platform_device
 *pdev)
  host-dbclk = NULL;
  } else if (clk_prepare_enable(host-dbclk) != 0) {
  dev_warn(mmc_dev(host-mmc), Failed to enable debounce
 clk\n);
 -   clk_put(host-dbclk);
  host-dbclk = NULL;


 You should use the IS_ERR macro, no need to reset dbclk to NULL.


 Agreed, IS_ERR macro usage deserves patch on its own.
 will create separate patch on top of this series.

Or you just update this patch, since it would touch there very same
piece of code. :-)

Kind regards
Ulf Hansson
--
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

Re: [PATCH v2] mmc: omap: Use DIV_ROUND_UP instead of open coded

[Ulf Hansson]

On 3 May 2014 03:07, Axel Lin axel@ingics.com wrote:
 Also uses NSEC_PER_SEC and USEC_PER_SEC instead of hard-coded value.
 This makes the intention more clear.

 Signed-off-by: Axel Lin axel@ingics.com

Thanks Axel!

Will include this patch in the next PR to Chris.

Kind regards
Ulf Hansson

 ---
  drivers/mmc/host/omap.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

 diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
 index 5c2e58b..81974ec 100644
 --- a/drivers/mmc/host/omap.c
 +++ b/drivers/mmc/host/omap.c
 @@ -177,7 +177,7 @@ static void mmc_omap_fclk_offdelay(struct mmc_omap_slot 
 *slot)
 unsigned long tick_ns;

 if (slot != NULL  slot-host-fclk_enabled  slot-fclk_freq  0) {
 -   tick_ns = (10 + slot-fclk_freq - 1) / 
 slot-fclk_freq;
 +   tick_ns = DIV_ROUND_UP(NSEC_PER_SEC, slot-fclk_freq);
 ndelay(8 * tick_ns);
 }
  }
 @@ -435,7 +435,7 @@ static void mmc_omap_send_stop_work(struct work_struct 
 *work)
 struct mmc_data *data = host-stop_data;
 unsigned long tick_ns;

 -   tick_ns = (10 + slot-fclk_freq - 1)/slot-fclk_freq;
 +   tick_ns = DIV_ROUND_UP(NSEC_PER_SEC, slot-fclk_freq);
 ndelay(8*tick_ns);

 mmc_omap_start_command(host, data-stop);
 @@ -477,7 +477,7 @@ mmc_omap_send_abort(struct mmc_omap_host *host, int 
 maxloops)
 u16 stat = 0;

 /* Sending abort takes 80 clocks. Have some extra and round up */
 -   timeout = (120*100 + slot-fclk_freq - 1)/slot-fclk_freq;
 +   timeout = DIV_ROUND_UP(120 * USEC_PER_SEC, slot-fclk_freq);
 restarts = 0;
 while (restarts  maxloops) {
 OMAP_MMC_WRITE(host, STAT, 0x);
 @@ -677,8 +677,8 @@ mmc_omap_xfer_data(struct mmc_omap_host *host, int write)
 if (n  host-buffer_bytes_left)
 n = host-buffer_bytes_left;

 -   nwords = n / 2;
 -   nwords += n  1; /* handle odd number of bytes to transfer */
 +   /* Round up to handle odd number of bytes to transfer */
 +   nwords = DIV_ROUND_UP(n, 2);

 host-buffer_bytes_left -= n;
 host-total_bytes_left -= n;
 --
 1.8.3.2



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

Re: [PATCH v11 0/6] mmc: omap_hsmmc: Enable SDIO IRQ

[Ulf Hansson]

On 11 May 2014 13:28, Andreas Fenkart afenk...@gmail.com wrote:
 Hi Balaji, Tony, all

 v12
 - drop !CONFIG_OF compile break only exists when
   #undef CONFIG_OF after include headers 1/7(Sebastian Reichel)
 - do not emit falling back to polling if wake_irq not specified
   since MMC does not need it, and it might confuse users
   only emit if pinmux default/idle is not present or claiming
   the irq failed 2/7(Balaji)
 - dropped out-of-tree patches 6/7(Balaji)
 - mention ti,am33xx-hsmmc compatible section in bindings
   documentation 1/5

Hi Andreas,

It seems like we are ready to merge this patchset - I will include it
in the next PR I send to Chris.

Kind regards
Ulf Hansson
--
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

Re: [PATCH v2 0/6] mmc: omap_hsmmc: convert to use devm_* and fixes

[Ulf Hansson]

On 9 May 2014 18:46, Balaji T K balaj...@ti.com wrote:
 v2:
 use devm_ioremap_resource
 add cmd23 multiblock read/write fix

 Balaji T K (6):
   mmc: omap_hsmmc: use devm_clk_get
   mmc: omap_hsmmc: use devm_request_irq
   mmc: omap_hsmmc: use devm_request_threaded_irq
   mmc: omap_hsmmc: use devm_ioremap_resource
   mmc: omap_hsmmc: fix cmd23 multiblock read/write
   mmc: omap_hsmmc: split omap-dma header file

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


Thanks Balaji,

I will include this patchset in the next PR I send to Chris.

Kind regards
Ulf Hansson

 --
 1.7.5.4

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

Re: [PATCH] mmc: omap_hsmmc: use IS_ERR macro for error checking

[Ulf Hansson]

On 15 May 2014 15:23, Balaji T K balaj...@ti.com wrote:
 Debounce clock is optional, use IS_ERR macro instead of NULL pointer check.

 Signed-off-by: Balaji T K balaj...@ti.com

Thanks Balaji,

I will include this in the next PR I send to Chris.

Kind regards
Ulf Hansson
--
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

Re: [PATCH 0/4] randconfig fixes for mmc

[Ulf Hansson]

On 5 June 2014 23:14, Arnd Bergmann a...@arndb.de wrote:
 Hi Chris, Ulf,

 These are small fixes from my randconfig testing, almost all for
 older bugs, please apply to a tree you see appropriate.

Thanks Arnd!

Applied for fixes.

Kind regards
Uffe


 Arnd

 Arnd Bergmann (4):
   mmc: atmel-mci: incude asm/cacheclush.h
   mmc: mvsdio: avoid compiler warning
   mmc: omap: don't select TPS65010
   mmc: simplify SDHCI Kconfig dependencies

  drivers/mmc/host/Kconfig | 10 --
  drivers/mmc/host/atmel-mci.c |  1 +
  drivers/mmc/host/mvsdio.c|  2 +-
  3 files changed, 6 insertions(+), 7 deletions(-)

 --
 1.8.3.2

 Cc: Ludovic Desroches ludovic.desroc...@atmel.com
 Cc: Nicolas Pitre n...@fluxnic.net
 Cc: Chris Ball ch...@printf.net
 Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
 Cc: Jason Cooper ja...@lakedaemon.net
 Cc: Andrew Lunn and...@lunn.ch
 Cc: linux-...@vger.kernel.org
 Cc: linux-omap@vger.kernel.org
 Cc: Jarkko Nikula jarkko.nik...@bitmer.com
--
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

Re: [PATCH v14 0/6] mmc: omap_hsmmc: Enable SDIO IRQ

[Ulf Hansson]

On 29 May 2014 10:27, Andreas Fenkart afenk...@gmail.com wrote:
 Hi Balaji, Tony, Ulf, all

 v14
 - drop all ifdef/endif introduced by v13
 -- rely on pinctrl_lookup_state to prevent ifdef CONFIG_PM
 -- benefit: all code is compile tested no matter the configuration
 -- drawback: require wake_irq/pinctrl configuration even when
runtime suspend is not configured
 - drop runtime state from debugfs output
 - rebased onto current mmc-next 06732b84b4cf

Thanks! Applied for next.

Kind regards
Ulf Hansson


 v13
 - fix compile breaks if !CONFIG_PM
 - additional patch: install dummy pm runtime hooks if !CONFIG_PM_RUNTIME

 v12
 - drop !CONFIG_OF compile break only exists when
   #undef CONFIG_OF after include headers 1/7(Sebastian Reichel)
 - do not emit falling back to polling if wake_irq not specified
   since MMC does not need it, and it might confuse users
   only emit if pinmux default/idle is not present or claiming
   the irq failed 2/7(Balaji)
 - dropped out-of-tree patches 6/7(Balaji)
 - mention ti,am33xx-hsmmc compatible section in bindings
   documentation 1/5

 v11
 - split !CONFIG_OF compile break into separate patch
 - enable IWE/CLKEXTFREE in CON/HCTL register needed for omap4
 - '' vs '' in omap_hsmmc_resume, 1/5 (Andreas Müller)
 - #define DLEV_DAT instead of BIT(21) 2/5 (Balaji)
 - pinctrl_pm_select_default_state() removed, 4/5 (Balaji)
 - drop _irqsave/_irqrestore from omap_hsmmc_wake_irq handler since it
   can't be preempted by same priority omap_hsmmc_irq handler 1/5(Joel 
 Fernandes)
 - replace devres_open_group by explicit devm_free calls 1/5 (Balaji)
 - disable_irq_nosync wake_irq since we handle it thread safe 1/5 (Balaji)
 - drop 'gpio_dat1' pinctrl states and rework documentation 5/5 (Balaji)

 v10
 - bug fix on multi-core, untested
 - incorporated changes from Balaji
 - use devres / RAII mechanism to configure wake_up /
   sdio irq capabilities
 - drop pinctrl state 'active'
   rely on driver-model states 'default', 'idle'
 - add specific 'gpio_dat1' state for am335x SWAKEUP hack
 - reorganized patches; +1 patch multi-core bugfix / +1 for pinctrl
 - rebased 455c6fdbd21916 / cherry-picks from mmc-next

 v9
 - extended comment about why wake-irq is needed
 - drop double '(' ')' around card_detect_irq
 - drop final '.' in in subject line of patch

 v8
 - rebased on top of Tony Lindgrent...@atomide.com changes
   - improved changelog describing the earlier work
   - improved wakeup irq setup
   - works for am3730 es platform now
 - my changes on top:
   - compile tested with #undef CONFIG_OF
   - disable wake_irq in handler to prevent infinite loop
   - fixed typo and added comment about wake-irq

 v7
 - rebase on 3.14.0-rc3-49726-g77e15ec
 - split omap_hsmmc_pin_init due to regression on omap-3730 platform

 v6
 - rebase on Linux 3.13-rc3
 - reformatting debugfs

 v5
 - fix compile error introduced by last minute one line fix

 v4:
 - switch to interrupts-extended format
 - drop ti,swakeup-missing flag convert to comaptible section

 v3:
 - removed gpio_irq from platform_data

 v2:
 - incorparated changes as suggested by reviewers
 - simplified workaround for am335x, gpio will now only wake
   the module from runtime suspend, not handle the sdio irq
   itself

 Andreas Fenkart (6):
   mmc: omap_hsmmc: Enable SDIO interrupt
   mmc: omap_hsmmc: Extend debugfs by SDIO IRQ handling, runtime state
   mmc: omap_hsmmc: enable wakeup event for sdio OMAP4
   mmc: omap_hsmmc: abort runtime suspend if pending sdio irq detected
   mmc: omap_hsmmc: switch default/idle pinctrl states in runtime hooks
   mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on
 AM335x

  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   54 
  drivers/mmc/host/omap_hsmmc.c  |  283 
 ++--
  include/linux/platform_data/mmc-omap.h |1 +
  3 files changed, 317 insertions(+), 21 deletions(-)

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

Re: [PATCH 0/5] MMC cleanup of dev_pm_ops and .owner

[Ulf Hansson]

On 12 August 2014 18:14, Peter Griffin peter.grif...@linaro.org wrote:
 This series cleans up a few platform drivers in how they are declaring there
 dev_pm_ops structs, and gets rid of a few now redundant #else conditions.

 Also it removes the .owner field of drivers which use module_platform_driver
 api to register themselves, as this field gets overwritten.

 Peter Griffin (5):
   mmc: remove .owner field for drivers using module_platform_driver
   mmc: dw_mmc-pci: Remove superflous #else condition on CONFIG_PM_SLEEP
   mmc: dw_mmc-pltfm: Remove superflous #else condition on
 CONFIG_PM_SLEEP
   mmc: sdhci-pci: Use SET_RUNTIME_PM_OPS macro to set runtime pm
 callbacks
   mmc: sdhci-acpi.c: Use SET_RUNTIME_PM_OPS macro to set runtime pm
 callbacks

Thanks! Applied for next!

Kind regards
Uffe


  drivers/mmc/host/dw_mmc-pci.c  |  3 ---
  drivers/mmc/host/dw_mmc-pltfm.c|  3 ---
  drivers/mmc/host/jz4740_mmc.c  |  1 -
  drivers/mmc/host/moxart-mmc.c  |  1 -
  drivers/mmc/host/mxcmmc.c  |  1 -
  drivers/mmc/host/mxs-mmc.c |  1 -
  drivers/mmc/host/omap.c|  1 -
  drivers/mmc/host/omap_hsmmc.c  |  1 -
  drivers/mmc/host/pxamci.c  |  1 -
  drivers/mmc/host/rtsx_pci_sdmmc.c  |  1 -
  drivers/mmc/host/rtsx_usb_sdmmc.c  |  1 -
  drivers/mmc/host/s3cmci.c  |  1 -
  drivers/mmc/host/sdhci-acpi.c  | 11 ++-
  drivers/mmc/host/sdhci-bcm-kona.c  |  1 -
  drivers/mmc/host/sdhci-bcm2835.c   |  1 -
  drivers/mmc/host/sdhci-cns3xxx.c   |  1 -
  drivers/mmc/host/sdhci-dove.c  |  1 -
  drivers/mmc/host/sdhci-esdhc-imx.c |  1 -
  drivers/mmc/host/sdhci-msm.c   |  1 -
  drivers/mmc/host/sdhci-of-arasan.c |  1 -
  drivers/mmc/host/sdhci-of-esdhc.c  |  1 -
  drivers/mmc/host/sdhci-of-hlwd.c   |  1 -
  drivers/mmc/host/sdhci-pci.c   | 11 ++-
  drivers/mmc/host/sdhci-pxav2.c |  1 -
  drivers/mmc/host/sdhci-pxav3.c |  1 -
  drivers/mmc/host/sdhci-s3c.c   |  1 -
  drivers/mmc/host/sdhci-sirf.c  |  1 -
  drivers/mmc/host/sdhci-spear.c |  1 -
  drivers/mmc/host/sdhci-tegra.c |  1 -
  drivers/mmc/host/sh_mmcif.c|  1 -
  drivers/mmc/host/sh_mobile_sdhi.c  |  1 -
  drivers/mmc/host/sunxi-mmc.c   |  1 -
  32 files changed, 4 insertions(+), 52 deletions(-)

 --
 1.9.1

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

Re: [PATCH] mmc: omap_hsmmc: Add small delay after enabling power

[Ulf Hansson]

On 11 September 2014 16:11, Stefan Roese s...@denx.de wrote:
 From: Thorsten Einsbein thorsten.eisb...@head-acoustics.de

 On the TAO3530 (OMAP3530 based) we noticed that some SD cards are not
 detected reliably upon bootup (timeout). Especially the SanDisk Ultra
 8GiB seems to be problematic here. The SanDisk Extreme also has this
 problem on this platform, but not that often. A Samsung 8 GiB type 6
 doesn't show this problem at all.

 This patch now adds a short delay after enabling the power on the slot.
 With this delay all cards are detected reliably.

Is this delay related to regulator ramp up/down time? Then I think it
maybe should be a part of the regulator code/DT.

Kind regards
Uffe


 Signed-off-by: Thorsten Einsbein thorsten.eisb...@head-acoustics.de
 Signed-off-by: Stefan Roese s...@denx.de
 Cc: Ulf Hansson ulf.hans...@linaro.org
 Cc: Balaji T K balaj...@ti.com
 ---
  drivers/mmc/host/omap_hsmmc.c | 4 
  1 file changed, 4 insertions(+)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 9656726..62ff0a7 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -335,6 +335,10 @@ static int omap_hsmmc_set_power(struct device *dev, int 
 slot, int power_on,
 ret = mmc_regulator_set_ocr(host-mmc,
 host-vcc, 0);
 }
 +
 +   dev_dbg(host-dev, omap_hsmmc_set_power: wait a little (slot 
 %d)\n,
 +   slot);
 +   msleep(5);
 } else {
 /* Shut down the rail */
 if (host-vcc_aux)
 --
 2.1.0

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

Re: [PATCH] MAINTAINERS: omap_hsmmc: remove myself from MAINTAINERS

[Ulf Hansson]

On 17 September 2014 19:20, Balaji T K balaji...@gmail.com wrote:
 As I won't be able to maintain omap_hsmmc driver

 Signed-off-by: Balaji T K balaji...@gmail.com

Sorry to see you go Balaji. Thanks for all your support!

Patch applied for next.

Kind regards
Uffe

 ---
  MAINTAINERS | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/MAINTAINERS b/MAINTAINERS
 index 5e7866a..b296e43 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -6540,10 +6540,9 @@ S:   Maintained
  F: drivers/mmc/host/omap.c

  OMAP HS MMC SUPPORT
 -M: Balaji T K balaj...@ti.com
  L: linux-...@vger.kernel.org
  L: linux-omap@vger.kernel.org
 -S: Maintained
 +S: Orphan
  F: drivers/mmc/host/omap_hsmmc.c

  OMAP RANDOM NUMBER GENERATOR SUPPORT
 --
 1.9.1

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

Re: [PATCH 0/6] unshare and simplify omap_hsmmc platform struct

[Ulf Hansson]

On 22 September 2014 13:55, Andreas Fenkart afenk...@gmail.com wrote:
 mmci and omap_hsmmc share very little fields in the platform

mmci? Should be omap right?

I noticed the similar typo for one of the patches as well.

Kind regards
Uffe

 struct. unsharing significantly simplifies the omap_hsmmc driver

 Andreas Fenkart (6):
   omap_hsmmc: unshare platform data struct with mmci driver
   omap_hsmmc: remove unused callbacks from platform data struct
   omap_hsmmc: remove unused fields in platform_data
   omap_hsmmc: remove unused get_context_loss_count callback
   omap_hsmmc: remove un-initialized callbacks from platform data
   omap_hsmmc: remove un-initialized get_cover_state callback

  arch/arm/mach-omap2/hsmmc.c|  61 ++
  arch/arm/mach-omap2/hsmmc.h|  10 --
  arch/arm/mach-omap2/mmc.h  |   6 +-
  .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |   6 +-
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   6 +-
  drivers/mmc/host/omap_hsmmc.c  | 133 
 +++--
  include/linux/platform_data/hsmmc-omap.h   | 103 
  7 files changed, 142 insertions(+), 183 deletions(-)
  create mode 100644 include/linux/platform_data/hsmmc-omap.h

 --
 2.1.0

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

Re: [PATCH v2 0/9] unshare and simplify omap_hsmmc platform struct

[Ulf Hansson]

On 29 September 2014 11:32, Andreas Fenkart afenk...@gmail.com wrote:
 v2:
 - replace erroneous mmci by omap1/2
 - add description to all patches
 - full compile check with:
 CONFIG_MACH_OMAP3_BEAGLE=y
 CONFIG_MACH_DEVKIT8000=y
 CONFIG_MACH_OMAP_LDP=y
 CONFIG_MACH_OMAP3530_LV_SOM=y
 CONFIG_MACH_OMAP3_TORPEDO=y
 CONFIG_MACH_OVERO=y
 CONFIG_MACH_OMAP3517EVM=y
 CONFIG_MACH_CRANEBOARD=y
 CONFIG_MACH_OMAP3_PANDORA=y
 CONFIG_MACH_TOUCHBOOK=y
 CONFIG_MACH_OMAP_3430SDP=y
 CONFIG_MACH_NOKIA_RX51=y
 CONFIG_MACH_CM_T35=y
 CONFIG_MACH_CM_T3517=y
 CONFIG_MACH_CM_T3730=y
 CONFIG_MACH_SBC3530=y
 - reorganized and added more patches, hence no blank ack added


 Andreas Fenkart (9):
   omap_hsmmc: use separate platform data for ompa3 and omap 1/2 driver
   omap_hsmmc: remove unused fields in platform_data
   omap_hsmmc: remove un-initialized callbacks from platform data
   omap_hsmmc: remove un-ready power_saving field in omap2_hsmmc_info
   omap_hsmmc: remove unused get_context_loss_count callback
   omap_hsmmc: remove unnecessary omap_hsmmc_slot_data indirection
   omap_hsmmc: pass mmc_priv struct to gpio init / free
   omap_hsmmc: Remove unnecessary callbacks from platform data
   omap_hsmmc: remove unused slot_id parameter

  arch/arm/mach-omap2/board-rx51-peripherals.c   |   4 +-
  arch/arm/mach-omap2/hsmmc.c| 155 +--
  arch/arm/mach-omap2/hsmmc.h|   9 +-
  arch/arm/mach-omap2/mmc.h  |   6 +-
  .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |   6 +-
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   6 +-
  drivers/mmc/host/omap_hsmmc.c  | 282 
 ++---
  include/linux/platform_data/hsmmc-omap.h   |  88 +++
  8 files changed, 299 insertions(+), 257 deletions(-)
  create mode 100644 include/linux/platform_data/hsmmc-omap.h

 --
 2.1.0


Thanks! Applied for next!

Kind regards
Uffe
--
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

Re: [PATCH v2 0/9] unshare and simplify omap_hsmmc platform struct

[Ulf Hansson]

On 3 October 2014 15:00, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 29 September 2014 11:32, Andreas Fenkart afenk...@gmail.com wrote:
 v2:
 - replace erroneous mmci by omap1/2
 - add description to all patches
 - full compile check with:
 CONFIG_MACH_OMAP3_BEAGLE=y
 CONFIG_MACH_DEVKIT8000=y
 CONFIG_MACH_OMAP_LDP=y
 CONFIG_MACH_OMAP3530_LV_SOM=y
 CONFIG_MACH_OMAP3_TORPEDO=y
 CONFIG_MACH_OVERO=y
 CONFIG_MACH_OMAP3517EVM=y
 CONFIG_MACH_CRANEBOARD=y
 CONFIG_MACH_OMAP3_PANDORA=y
 CONFIG_MACH_TOUCHBOOK=y
 CONFIG_MACH_OMAP_3430SDP=y
 CONFIG_MACH_NOKIA_RX51=y
 CONFIG_MACH_CM_T35=y
 CONFIG_MACH_CM_T3517=y
 CONFIG_MACH_CM_T3730=y
 CONFIG_MACH_SBC3530=y
 - reorganized and added more patches, hence no blank ack added


 Andreas Fenkart (9):
   omap_hsmmc: use separate platform data for ompa3 and omap 1/2 driver
   omap_hsmmc: remove unused fields in platform_data
   omap_hsmmc: remove un-initialized callbacks from platform data
   omap_hsmmc: remove un-ready power_saving field in omap2_hsmmc_info
   omap_hsmmc: remove unused get_context_loss_count callback
   omap_hsmmc: remove unnecessary omap_hsmmc_slot_data indirection
   omap_hsmmc: pass mmc_priv struct to gpio init / free
   omap_hsmmc: Remove unnecessary callbacks from platform data
   omap_hsmmc: remove unused slot_id parameter

  arch/arm/mach-omap2/board-rx51-peripherals.c   |   4 +-
  arch/arm/mach-omap2/hsmmc.c| 155 +--
  arch/arm/mach-omap2/hsmmc.h|   9 +-
  arch/arm/mach-omap2/mmc.h  |   6 +-
  .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |   6 +-
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   6 +-
  drivers/mmc/host/omap_hsmmc.c  | 282 
 ++---
  include/linux/platform_data/hsmmc-omap.h   |  88 +++
  8 files changed, 299 insertions(+), 257 deletions(-)
  create mode 100644 include/linux/platform_data/hsmmc-omap.h

 --
 2.1.0


 Thanks! Applied for next!

As you know, these had some issues for omap2. I have dropped them from
next branch, they will have to be considered for 3.19 instead.

Kind regards
Uffe
--
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

Re: [PATCH v4 00/10] ARM: OMAP1/2+: MMC: separate platform data for mmc and mmc hs driver

[Ulf Hansson]

On 8 November 2014 15:33, Andreas Fenkart afenk...@gmail.com wrote:
 v4:
 - rework patch descriptions
 - dropped patch removing unused defines in mach-omap2/mmc.h
 - rebase 3.18.0-rc3
 - compile test omap1 and omap2

 compile tested
 OMAP1:
 CONFIG_MACH_OMAP_INNOVATOR=y
 CONFIG_MACH_OMAP_H2=y
 CONFIG_MACH_OMAP_H3=y
 CONFIG_MACH_HERALD=y
 CONFIG_MACH_OMAP_OSK=y
 CONFIG_MACH_OMAP_PERSEUS2=y
 CONFIG_MACH_OMAP_FSAMPLE=y
 CONFIG_MACH_VOICEBLUE=y
 CONFIG_MACH_OMAP_PALMTE=y
 CONFIG_MACH_OMAP_PALMZ71=y
 CONFIG_MACH_OMAP_PALMTT=y
 CONFIG_MACH_SX1=y
 CONFIG_MACH_NOKIA770=y
 CONFIG_MACH_AMS_DELTA=y
 CONFIG_MACH_OMAP_GENERIC=y

 OMAP2:
 CONFIG_MACH_OMAP2_TUSB6010=y
 CONFIG_MACH_OMAP3_BEAGLE=y
 CONFIG_MACH_DEVKIT8000=y
 CONFIG_MACH_OMAP_LDP=y
 CONFIG_MACH_OMAP3530_LV_SOM=y
 CONFIG_MACH_OMAP3_TORPEDO=y
 CONFIG_MACH_OVERO=y
 CONFIG_MACH_OMAP3517EVM=y
 CONFIG_MACH_CRANEBOARD=y
 CONFIG_MACH_OMAP3_PANDORA=y
 CONFIG_MACH_TOUCHBOOK=y
 CONFIG_MACH_OMAP_3430SDP=y
 CONFIG_MACH_NOKIA_N810=y
 CONFIG_MACH_NOKIA_N810_WIMAX=y
 CONFIG_MACH_NOKIA_N8X0=y
 CONFIG_MACH_NOKIA_RX51=y
 CONFIG_MACH_CM_T35=y
 CONFIG_MACH_CM_T3517=y
 CONFIG_MACH_CM_T3730=y
 CONFIG_MACH_SBC3530=y
 CONFIG_MACH_TI8168EVM=y
 CONFIG_MACH_TI8148EVM=y

 Andreas Fenkart (10):
   ARM: OMAP2: MMC: include mmc-omap platform header directly
   ARM: OMAP1/2+: MMC: separate platform data for mmc and mmc hs driver
   omap_hsmmc: remove unused fields in platform_data
   omap_hsmmc: remove un-initialized callbacks from platform data
   omap_hsmmc: remove never read power_saving field in omap2_hsmmc_info
   omap_hsmmc: remove unused get_context_loss_count callback
   omap_hsmmc: remove unnecessary omap_hsmmc_slot_data indirection
   omap_hsmmc: pass mmc_priv struct to gpio init / free
   omap_hsmmc: Remove unnecessary callbacks from platform data
   omap_hsmmc: remove unused slot_id parameter

  arch/arm/mach-omap2/board-n8x0.c   |   2 +
  arch/arm/mach-omap2/board-rx51-peripherals.c   |   4 +-
  arch/arm/mach-omap2/hsmmc.c| 158 +---
  arch/arm/mach-omap2/hsmmc.h|   9 +-
  arch/arm/mach-omap2/mmc.h  |  10 -
  arch/arm/mach-omap2/omap4-common.c |   1 -
  arch/arm/mach-omap2/omap_hwmod_2430_data.c |   4 +-
  .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |   8 +-
  arch/arm/mach-omap2/omap_hwmod_33xx_data.c |   1 -
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   8 +-
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   4 +-
  arch/arm/mach-omap2/omap_hwmod_54xx_data.c |   4 +-
  arch/arm/mach-omap2/omap_hwmod_7xx_data.c  |   4 +-
  drivers/mmc/host/omap_hsmmc.c  | 282 
 ++---
  include/linux/platform_data/hsmmc-omap.h   |  90 +++
  include/linux/platform_data/mmc-omap.h |  27 --
  16 files changed, 312 insertions(+), 304 deletions(-)
  create mode 100644 include/linux/platform_data/hsmmc-omap.h

 --
 2.1.1


Thanks! Applied for next.

Kind regards
Uffe
--
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

Re: [PATCH 0/3] mmc: omap_hsmmc: make more use of mmc library functionality

[Ulf Hansson]

On 8 November 2014 00:52, NeilBrown ne...@suse.de wrote:
 omap_hsmmc currently duplicates some work that can be done for
 it by common code, and consequently does not benefit from extra
 functionality in that common code.

 In particular, mmc_of_parse and the slot-gpio library are not used.

 This set of patches allows omap_hsmmc to use that common
 functionality, and benefit from any extra devicetree parsing
 that it performs.

 The one awkward part of this change is that omap_hsmmc has an
 interrupt handler for 'card detect' which does more than the
 common code.
 I see three options:
  1 - move that functionality into common code
  2 - discard that functionality
  3 - allow the common code to be configured to use a device-specific
  card detect interrupt.

 This series implements '3'.  I suspect a mix of '1' and '2' would
 be a better choice but I know no of the history or justification
 for those differences.

 My preference would be for this series to be applied (if there are
 no other issues) and if there are opinions about effecting '1' or '2',
 they can be done with subsequent patches.

 Thanks,
 NeilBrown


I like the looks of this patchset, but it needs a rebase.

Kind regards
Uffe


 ---

 NeilBrown (3):
   mmc: omap_hsmmc: remove prepare/complete system suspend support.
   mmc: omap_hsmmc: use slot-gpio library for gpio support.
   mmc: omap_hsmmc: use mmc_of_parse to parse common mmc configuration.


  drivers/mmc/core/slot-gpio.c   |   21 
  drivers/mmc/host/omap_hsmmc.c  |  158 
 +---
  include/linux/mmc/slot-gpio.h  |2
  include/linux/platform_data/mmc-omap.h |4 -
  4 files changed, 47 insertions(+), 138 deletions(-)

 --
 Signature

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

Re: [PATCH 0/3] mmc: omap_hsmmc: make more use of mmc library functionality

[Ulf Hansson]

 Thanks.  What should I rebase against?  Is 3.18-rc sufficient or is there
 some other tree I should work against?

 Thanks,
 NeilBrown


git://git.linaro.org/people/ulf.hansson/mmc.git

Kind regards
Uffe
--
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

Re: [PATCH 2/3] ARM: edma: Rename header file for dmaengine filter function definition

[Ulf Hansson]

On 27 November 2014 at 11:41, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 Rename the include/linux/edma.h to include/linux/edma-dmaengine.h

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com

For the mmc parts:

Acked-by: Ulf Hansson ulf.hans...@linaro.org

 ---
  arch/arm/common/edma.c |  2 +-
  drivers/mmc/host/davinci_mmc.c |  3 +--
  drivers/spi/spi-davinci.c  |  2 +-
  include/linux/edma-dmaengine.h | 29 +
  include/linux/edma.h   | 29 -
  sound/soc/davinci/edma-pcm.c   |  2 +-
  6 files changed, 33 insertions(+), 34 deletions(-)
  create mode 100644 include/linux/edma-dmaengine.h
  delete mode 100644 include/linux/edma.h

 diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
 index 5662a872689b..bac677e65c76 100644
 --- a/arch/arm/common/edma.c
 +++ b/arch/arm/common/edma.c
 @@ -25,7 +25,7 @@
  #include linux/platform_device.h
  #include linux/io.h
  #include linux/slab.h
 -#include linux/edma.h
 +#include linux/edma-dmaengine.h
  #include linux/dma-mapping.h
  #include linux/of_address.h
  #include linux/of_device.h
 diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
 index 1625f908dc70..47323662c818 100644
 --- a/drivers/mmc/host/davinci_mmc.c
 +++ b/drivers/mmc/host/davinci_mmc.c
 @@ -32,12 +32,11 @@
  #include linux/delay.h
  #include linux/dmaengine.h
  #include linux/dma-mapping.h
 -#include linux/edma.h
 +#include linux/edma-dmaengine.h
  #include linux/mmc/mmc.h
  #include linux/of.h
  #include linux/of_device.h

 -#include linux/platform_data/edma.h
  #include linux/platform_data/mmc-davinci.h

  /*
 diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
 index b3707badb1e5..d61b7cdb2deb 100644
 --- a/drivers/spi/spi-davinci.c
 +++ b/drivers/spi/spi-davinci.c
 @@ -27,7 +27,7 @@
  #include linux/clk.h
  #include linux/dmaengine.h
  #include linux/dma-mapping.h
 -#include linux/edma.h
 +#include linux/edma-dmaengine.h
  #include linux/of.h
  #include linux/of_device.h
  #include linux/of_gpio.h
 diff --git a/include/linux/edma-dmaengine.h b/include/linux/edma-dmaengine.h
 new file mode 100644
 index ..8a2602809a77
 --- /dev/null
 +++ b/include/linux/edma-dmaengine.h
 @@ -0,0 +1,29 @@
 +/*
 + * TI EDMA DMA engine driver
 + *
 + * Copyright 2012 Texas Instruments
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License as
 + * published by the Free Software Foundation version 2.
 + *
 + * This program is distributed as is WITHOUT ANY WARRANTY of any
 + * kind, whether express or implied; without even the implied warranty
 + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +#ifndef __LINUX_EDMA_DMAENGINE_H
 +#define __LINUX_EDMA_DMAENGINE_H
 +
 +struct dma_chan;
 +
 +#if defined(CONFIG_TI_EDMA) || defined(CONFIG_TI_EDMA_MODULE)
 +bool edma_filter_fn(struct dma_chan *, void *);
 +#else
 +static inline bool edma_filter_fn(struct dma_chan *chan, void *param)
 +{
 +   return false;
 +}
 +#endif
 +
 +#endif
 diff --git a/include/linux/edma.h b/include/linux/edma.h
 deleted file mode 100644
 index a1307e7827e8..
 --- a/include/linux/edma.h
 +++ /dev/null
 @@ -1,29 +0,0 @@
 -/*
 - * TI EDMA DMA engine driver
 - *
 - * Copyright 2012 Texas Instruments
 - *
 - * This program is free software; you can redistribute it and/or
 - * modify it under the terms of the GNU General Public License as
 - * published by the Free Software Foundation version 2.
 - *
 - * This program is distributed as is WITHOUT ANY WARRANTY of any
 - * kind, whether express or implied; without even the implied warranty
 - * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 - * GNU General Public License for more details.
 - */
 -#ifndef __LINUX_EDMA_H
 -#define __LINUX_EDMA_H
 -
 -struct dma_chan;
 -
 -#if defined(CONFIG_TI_EDMA) || defined(CONFIG_TI_EDMA_MODULE)
 -bool edma_filter_fn(struct dma_chan *, void *);
 -#else
 -static inline bool edma_filter_fn(struct dma_chan *chan, void *param)
 -{
 -   return false;
 -}
 -#endif
 -
 -#endif
 diff --git a/sound/soc/davinci/edma-pcm.c b/sound/soc/davinci/edma-pcm.c
 index 59e588abe54b..873c8a090427 100644
 --- a/sound/soc/davinci/edma-pcm.c
 +++ b/sound/soc/davinci/edma-pcm.c
 @@ -23,7 +23,7 @@
  #include sound/pcm_params.h
  #include sound/soc.h
  #include sound/dmaengine_pcm.h
 -#include linux/edma.h
 +#include linux/edma-dmaengine.h

  #include edma-pcm.h

 --
 2.1.3

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

Re: [PATCH] ARM / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

[Ulf Hansson]

On 6 December 2014 at 03:50, Rafael J. Wysocki r...@rjwysocki.net wrote:
 From: Rafael J. Wysocki rafael.j.wyso...@intel.com

 After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
 selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
 depending on CONFIG_PM_RUNTIME may now be changed to depend on
 CONFIG_PM.

 Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere in the code under
 arch/arm/ (the defconfig files will be modified later).

 Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
 ---

 Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
 PM_SLEEP is selected) which is only in linux-next at the moment (via the
 linux-pm tree).

 Please let me know if it is OK to take this one into linux-pm.

 ---
  arch/arm/kernel/perf_event.c   |2 +-
  arch/arm/mach-davinci/pm_domain.c  |2 +-
  arch/arm/mach-keystone/pm_domain.c |2 +-
  arch/arm/mach-omap1/pm_bus.c   |4 ++--
  arch/arm/mach-omap2/io.c   |2 +-
  arch/arm/mach-omap2/omap_device.c  |2 +-
  6 files changed, 7 insertions(+), 7 deletions(-)

There are a bunch of Kconfig options that selects/depends on
PM_RUNTIME. I suppose you should change them into PM as well.

Kind regards
Uffe
--
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

Re: [PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc

[Ulf Hansson]

On 3 December 2014 at 00:42, Doug Anderson diand...@chromium.org wrote:
 Bing Zhao at Marvell found a problem with dw_mmc where interrupts
 weren't firing sometimes.  He tracked it down to a read-modify-write
 problem with the INTMASK.  These patches fix the problem.

 Note: I've picked up a  1-year old series here to make another
 attempt at landing it upstream.  These patches have been in shipping
 Chromebooks for the last year.  Note that v3 to v4 has no changes
 other than a rebase and a small commit message update.

 The first two patches extend the init_card() mechanism of MMC core
 to actually be called for all card types, not just SDIO.  That could
 be applied any time and should fix at least one longstanding bug
 (untested).

 The third patch is a cleanup patch to use init_card() to move things
 around a bit so we don't need to handle SDIO cards in such a strange
 place.  On earlier versions of this patch Seungwon brought up a few
 points which I have _not_ addressed.  See
 https://patchwork.kernel.org/patch/3049071/.  Other than talk of
 cards with out of band interrupts maybe being able to gate their
 clocks, he wanted to use MMC_QUIRK_BROKEN_CLK_GATING.  I didn't do
 that because of the ordering of init_card() and when the quirks are
 set.  Some users of init_card() like pandora_wl1251_init_card() rely
 on it being called very early in the process.
 pandora_wl1251_init_card() hardcodes a vendor and device and thus need
 to be called super early.  On the other hand the code that adds quirks
 _reads_ the vendor and device.  It can't possibly move before
 init_card().  If folks are willing to take an additional host op of
 init_card_late() I can certainly go that way, though.

 The fourth patch is (I think) reviewed and ready to go assuming the
 other two land.

I have queued this up for 3.20. It was a bit hard to follow the
updated the revisions, please don't send patches in-reply-to for
future sets.

In v5, I don't find a patch 1/4. Anyway, I have taken patch 2-4.

Kind regards
Uffe


 Changes in v5:
 - Split fixup to pandora_wl1251_init_card() into its own patch.

 Changes in v3:
 - Add fixup to pandora_wl1251_init_card().

 Changes in v2:
 - mmc core change new for this version.
 - Fixed | to .
 - intmask_lock renamed to irq_lock

 Doug Anderson (4):
   ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO only
   mmc: core: Support the optional init_card() callback for MMC and SD
   mmc: dw_mmc: Cleanup disable of low power mode w/ SDIO interrupts
   mmc: dw_mmc: Protect read-modify-write of INTMASK with a lock

  arch/arm/mach-omap2/board-omap3pandora.c | 14 +++---
  drivers/mmc/core/mmc.c   |  6 +++
  drivers/mmc/core/sd.c|  7 ++-
  drivers/mmc/host/dw_mmc.c| 80 
 +++-
  drivers/mmc/host/dw_mmc.h|  1 +
  include/linux/mmc/dw_mmc.h   |  6 +++
  6 files changed, 74 insertions(+), 40 deletions(-)

 --
 2.2.0.rc0.207.ga3a616c

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

Re: [PATCH 2/3] mmc: omap_hsmmc: use slot-gpio library for gpio support.

[Ulf Hansson]

On 11 December 2014 at 22:43, NeilBrown ne...@suse.de wrote:
 Using the common code removes some code duplication, and
 makes it easier to switch to using mmc_of_parse() which
 will remove more duplication.

 As hsmmc has a slightly different interrupt service routine
 for card-detect, enhance slot-gpio to allow an alternate
 routine to be provided.

 Signed-off-by: NeilBrown ne...@suse.de
 ---
  drivers/mmc/core/slot-gpio.c  |   24 ++-
  drivers/mmc/host/omap_hsmmc.c |   67 
 +
  include/linux/mmc/slot-gpio.h |2 +
  3 files changed, 39 insertions(+), 54 deletions(-)

I like the looks of this patch, still I want the mmc core parts to be
separated into it's own patch. Can you please split this up.

Kind regards
Uffe


 diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
 index 69bbf2adb329..f56323f5a996 100644
 --- a/drivers/mmc/core/slot-gpio.c
 +++ b/drivers/mmc/core/slot-gpio.c
 @@ -23,6 +23,7 @@ struct mmc_gpio {
 struct gpio_desc *cd_gpio;
 bool override_ro_active_level;
 bool override_cd_active_level;
 +   irqreturn_t (*cd_gpio_isr)(int irq, void *dev_id);
 char *ro_label;
 char cd_label[0];
  };
 @@ -156,8 +157,10 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
 irq = -EINVAL;

 if (irq = 0) {
 +   if (ctx-cd_gpio_isr == NULL)
 +   ctx-cd_gpio_isr = mmc_gpio_cd_irqt;
 ret = devm_request_threaded_irq(host-class_dev, irq,
 -   NULL, mmc_gpio_cd_irqt,
 +   NULL, ctx-cd_gpio_isr,
 IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | 
 IRQF_ONESHOT,
 ctx-cd_label, host);
 if (ret  0)
 @@ -171,6 +174,25 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
  }
  EXPORT_SYMBOL(mmc_gpiod_request_cd_irq);

 +/* Register an alternate interrupt service routine for
 + * the card-detect GPIO.
 + */
 +int mmc_gpio_request_cd_isr(struct mmc_host *host,
 +   irqreturn_t (*isr)(int irq, void *dev_id))
 +{
 +   struct mmc_gpio *ctx;
 +   int ret;
 +
 +   ret = mmc_gpio_alloc(host);
 +   if (ret  0)
 +   return ret;
 +   ctx = host-slot.handler_priv;
 +   if (ctx-cd_gpio_isr)
 +   return -EBUSY;
 +   ctx-cd_gpio_isr = isr;
 +   return 0;
 +}
 +
  /**
   * mmc_gpio_request_cd - request a gpio for card-detection
   * @host: mmc host
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 537cba8f1de1..32514b648e3c 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -36,6 +36,7 @@
  #include linux/mmc/host.h
  #include linux/mmc/core.h
  #include linux/mmc/mmc.h
 +#include linux/mmc/slot-gpio.h
  #include linux/io.h
  #include linux/irq.h
  #include linux/gpio.h
 @@ -251,28 +252,22 @@ static void omap_hsmmc_start_dma_transfer(struct 
 omap_hsmmc_host *host);
  static int omap_hsmmc_card_detect(struct device *dev)
  {
 struct omap_hsmmc_host *host = dev_get_drvdata(dev);
 -   struct omap_hsmmc_platform_data *mmc = host-pdata;

 -   /* NOTE: assumes card detect signal is active-low */
 -   return !gpio_get_value_cansleep(mmc-switch_pin);
 +   return mmc_gpio_get_cd(host-mmc);
  }

  static int omap_hsmmc_get_wp(struct device *dev)
  {
 struct omap_hsmmc_host *host = dev_get_drvdata(dev);
 -   struct omap_hsmmc_platform_data *mmc = host-pdata;

 -   /* NOTE: assumes write protect signal is active-high */
 -   return gpio_get_value_cansleep(mmc-gpio_wp);
 +   return mmc_gpio_get_ro(host-mmc);
  }

  static int omap_hsmmc_get_cover_state(struct device *dev)
  {
 struct omap_hsmmc_host *host = dev_get_drvdata(dev);
 -   struct omap_hsmmc_platform_data *mmc = host-pdata;

 -   /* NOTE: assumes card detect signal is active-low */
 -   return !gpio_get_value_cansleep(mmc-switch_pin);
 +   return mmc_gpio_get_cd(host-mmc);
  }

  #ifdef CONFIG_REGULATOR
 @@ -439,7 +434,10 @@ static inline int omap_hsmmc_have_reg(void)

  #endif

 -static int omap_hsmmc_gpio_init(struct omap_hsmmc_host *host,
 +static irqreturn_t omap_hsmmc_detect(int irq, void *dev_id);
 +
 +static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
 +   struct omap_hsmmc_host *host,
 struct omap_hsmmc_platform_data *pdata)
  {
 int ret;
 @@ -452,46 +450,26 @@ static int omap_hsmmc_gpio_init(struct omap_hsmmc_host 
 *host,
 host-card_detect = omap_hsmmc_card_detect;
 host-card_detect_irq =
 gpio_to_irq(pdata-switch_pin);
 -   ret = gpio_request(pdata-switch_pin, mmc_cd);
 +   ret = mmc_gpio_request_cd_isr(mmc, omap_hsmmc_detect);
 if (ret)
 return ret;
 -  

Re: [PATCH 1/3] mmc: omap_hsmmc: remove prepare/complete system suspend support.

[Ulf Hansson]

On 11 December 2014 at 22:43, NeilBrown ne...@suse.de wrote:
 The only function of these 'prepare' and 'complete' is to
 disable the 'card detect' irq during suspend.

 The commit which added this,
 commit a48ce884d5819d5df2cf1139ab3c43f8e9e419b3
 mmc: omap_hsmmc: Introduce omap_hsmmc_prepare/complete

 justified it by the need to avoid the registration of new devices
 during suspend.
 However mmc_pm_notify will set -rescan_disable in the 'prepare'
 stage and clear it in the 'complete' stage, so no card detection
 will actually happen.
 Also the interrupt will be disabled before final suspend as part
 of common suspend processing.

 So this disabling of the interrupt is unnecessary, and interferes
 with a transition to using common code for card-detect management.

 Cc: Felipe Balbi ba...@ti.com
 Cc: Venkatraman S svenk...@ti.com
 Cc: Chris Ball c...@laptop.org
 Signed-off-by: NeilBrown ne...@suse.de

Thanks! Queued for 3.20.

Kind regards
Uffe

 ---
  drivers/mmc/host/omap_hsmmc.c  |   50 
 
  include/linux/platform_data/mmc-omap.h |4 ---
  2 files changed, 54 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 7c71dcdcba8b..537cba8f1de1 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -275,31 +275,6 @@ static int omap_hsmmc_get_cover_state(struct device *dev)
 return !gpio_get_value_cansleep(mmc-switch_pin);
  }

 -#ifdef CONFIG_PM
 -
 -static int omap_hsmmc_suspend_cdirq(struct device *dev)
 -{
 -   struct omap_hsmmc_host *host = dev_get_drvdata(dev);
 -
 -   disable_irq(host-card_detect_irq);
 -   return 0;
 -}
 -
 -static int omap_hsmmc_resume_cdirq(struct device *dev)
 -{
 -   struct omap_hsmmc_host *host = dev_get_drvdata(dev);
 -
 -   enable_irq(host-card_detect_irq);
 -   return 0;
 -}
 -
 -#else
 -
 -#define omap_hsmmc_suspend_cdirq   NULL
 -#define omap_hsmmc_resume_cdirqNULL
 -
 -#endif
 -
  #ifdef CONFIG_REGULATOR

  static int omap_hsmmc_set_power(struct device *dev, int power_on, int vdd)
 @@ -2234,8 +2209,6 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 Unable to grab MMC CD IRQ\n);
 goto err_irq_cd;
 }
 -   host-suspend = omap_hsmmc_suspend_cdirq;
 -   host-resume = omap_hsmmc_resume_cdirq;
 }

 omap_hsmmc_disable_irq(host);
 @@ -2322,25 +2295,6 @@ static int omap_hsmmc_remove(struct platform_device 
 *pdev)
  }

  #ifdef CONFIG_PM
 -static int omap_hsmmc_prepare(struct device *dev)
 -{
 -   struct omap_hsmmc_host *host = dev_get_drvdata(dev);
 -
 -   if (host-suspend)
 -   return host-suspend(dev);
 -
 -   return 0;
 -}
 -
 -static void omap_hsmmc_complete(struct device *dev)
 -{
 -   struct omap_hsmmc_host *host = dev_get_drvdata(dev);
 -
 -   if (host-resume)
 -   host-resume(dev);
 -
 -}
 -
  static int omap_hsmmc_suspend(struct device *dev)
  {
 struct omap_hsmmc_host *host = dev_get_drvdata(dev);
 @@ -2398,8 +2352,6 @@ static int omap_hsmmc_resume(struct device *dev)
  }

  #else
 -#define omap_hsmmc_prepare NULL
 -#define omap_hsmmc_completeNULL
  #define omap_hsmmc_suspend NULL
  #define omap_hsmmc_resume  NULL
  #endif
 @@ -2484,8 +2436,6 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
  static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
 .suspend= omap_hsmmc_suspend,
 .resume = omap_hsmmc_resume,
 -   .prepare= omap_hsmmc_prepare,
 -   .complete   = omap_hsmmc_complete,
 .runtime_suspend = omap_hsmmc_runtime_suspend,
 .runtime_resume = omap_hsmmc_runtime_resume,
  };
 diff --git a/include/linux/platform_data/mmc-omap.h 
 b/include/linux/platform_data/mmc-omap.h
 index 5c188f4e9bec..929469291406 100644
 --- a/include/linux/platform_data/mmc-omap.h
 +++ b/include/linux/platform_data/mmc-omap.h
 @@ -31,10 +31,6 @@ struct omap_mmc_platform_data {
 void (*cleanup)(struct device *dev);
 void (*shutdown)(struct device *dev);

 -   /* To handle board related suspend/resume functionality for MMC */
 -   int (*suspend)(struct device *dev, int slot);
 -   int (*resume)(struct device *dev, int slot);
 -
 /* Return context loss count due to PM states changing */
 int (*get_context_loss_count)(struct device *dev);



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

Re: [PATCH 2a/3] mmc: core: Allow host driver to provide isr for card-detect interrupts.

[Ulf Hansson]

On 20 December 2014 at 00:07, NeilBrown ne...@suse.de wrote:
 One of the reasons omap_hsmmc doesn't use the slot-gpio library
 is that it has some non-standard functionality in the card-detect
 interrupt service routine.

 To make it possible for omap_hsmmc (and maybe others) to be converted
 to use slot-gpio, add 'mmc_gpio_request_cd_isr' which provide an
 alternate isr to be register by the slot-gpio code.

 Signed-off-by: NeilBrown ne...@suse.de
 ---
  drivers/mmc/core/slot-gpio.c  |   24 +++-
  include/linux/mmc/slot-gpio.h |2 ++
  2 files changed, 25 insertions(+), 1 deletion(-)

 This and following are the result of splitting the previous
 '2/3' into to patches: core and omap_hsmmc as requested.

 NeilBrown


 diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
 index 69bbf2adb329..f56323f5a996 100644
 --- a/drivers/mmc/core/slot-gpio.c
 +++ b/drivers/mmc/core/slot-gpio.c
 @@ -23,6 +23,7 @@ struct mmc_gpio {
 struct gpio_desc *cd_gpio;
 bool override_ro_active_level;
 bool override_cd_active_level;
 +   irqreturn_t (*cd_gpio_isr)(int irq, void *dev_id);
 char *ro_label;
 char cd_label[0];
  };
 @@ -156,8 +157,10 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
 irq = -EINVAL;

 if (irq = 0) {
 +   if (ctx-cd_gpio_isr == NULL)

Please change to:
if (!ctx-cd_gpio_isr)

 +   ctx-cd_gpio_isr = mmc_gpio_cd_irqt;
 ret = devm_request_threaded_irq(host-class_dev, irq,
 -   NULL, mmc_gpio_cd_irqt,
 +   NULL, ctx-cd_gpio_isr,
 IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | 
 IRQF_ONESHOT,
 ctx-cd_label, host);
 if (ret  0)
 @@ -171,6 +174,25 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
  }
  EXPORT_SYMBOL(mmc_gpiod_request_cd_irq);

 +/* Register an alternate interrupt service routine for
 + * the card-detect GPIO.
 + */
 +int mmc_gpio_request_cd_isr(struct mmc_host *host,
 +   irqreturn_t (*isr)(int irq, void *dev_id))
 +{
 +   struct mmc_gpio *ctx;
 +   int ret;
 +
 +   ret = mmc_gpio_alloc(host);
 +   if (ret  0)
 +   return ret;
 +   ctx = host-slot.handler_priv;
 +   if (ctx-cd_gpio_isr)
 +   return -EBUSY;
 +   ctx-cd_gpio_isr = isr;
 +   return 0;
 +}

I decided to queue those patchsets I recently posted which simplifies
the slot-gpio API. Please re-base this patch on top of my next branch.

Moreover, I actually wonder whether we need to add this API at all.
After my changes, all you need to do from your host driver -probe(),
is to assign your isr routine to ctx-cd_gpio_isr.

 +
  /**
   * mmc_gpio_request_cd - request a gpio for card-detection
   * @host: mmc host
 diff --git a/include/linux/mmc/slot-gpio.h b/include/linux/mmc/slot-gpio.h
 index e56fa24c9322..9e55db60deb0 100644
 --- a/include/linux/mmc/slot-gpio.h
 +++ b/include/linux/mmc/slot-gpio.h
 @@ -28,6 +28,8 @@ int mmc_gpiod_request_cd(struct mmc_host *host, const char 
 *con_id,
  int mmc_gpiod_request_ro(struct mmc_host *host, const char *con_id,
  unsigned int idx, bool override_active_level,
  unsigned int debounce, bool *gpio_invert);
 +int mmc_gpio_request_cd_isr(struct mmc_host *host,
 +   irqreturn_t (*isr)(int irq, void *dev_id));
  void mmc_gpiod_free_cd(struct mmc_host *host);
  void mmc_gpiod_request_cd_irq(struct mmc_host *host);




Kind regards
Uffe
--
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

Re: [PATCH 2a/3] mmc: core: Allow host driver to provide isr for card-detect interrupts.

[Ulf Hansson]

On 23 December 2014 at 09:48, NeilBrown ne...@suse.de wrote:
 On Mon, 22 Dec 2014 16:35:40 +0100 Ulf Hansson ulf.hans...@linaro.org wrote:

 On 20 December 2014 at 00:07, NeilBrown ne...@suse.de wrote:
  One of the reasons omap_hsmmc doesn't use the slot-gpio library
  is that it has some non-standard functionality in the card-detect
  interrupt service routine.
 
  To make it possible for omap_hsmmc (and maybe others) to be converted
  to use slot-gpio, add 'mmc_gpio_request_cd_isr' which provide an
  alternate isr to be register by the slot-gpio code.
 
  Signed-off-by: NeilBrown ne...@suse.de
  ---
   drivers/mmc/core/slot-gpio.c  |   24 +++-
   include/linux/mmc/slot-gpio.h |2 ++
   2 files changed, 25 insertions(+), 1 deletion(-)
 
  This and following are the result of splitting the previous
  '2/3' into to patches: core and omap_hsmmc as requested.
 
  NeilBrown
 
 
  diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
  index 69bbf2adb329..f56323f5a996 100644
  --- a/drivers/mmc/core/slot-gpio.c
  +++ b/drivers/mmc/core/slot-gpio.c
  @@ -23,6 +23,7 @@ struct mmc_gpio {
  struct gpio_desc *cd_gpio;
  bool override_ro_active_level;
  bool override_cd_active_level;
  +   irqreturn_t (*cd_gpio_isr)(int irq, void *dev_id);
  char *ro_label;
  char cd_label[0];
   };
  @@ -156,8 +157,10 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
  irq = -EINVAL;
 
  if (irq = 0) {
  +   if (ctx-cd_gpio_isr == NULL)

 Please change to:
 if (!ctx-cd_gpio_isr)

 will do (though I personally prefer the explicit NULL :-).


  +   ctx-cd_gpio_isr = mmc_gpio_cd_irqt;
  ret = devm_request_threaded_irq(host-class_dev, irq,
  -   NULL, mmc_gpio_cd_irqt,
  +   NULL, ctx-cd_gpio_isr,
  IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | 
  IRQF_ONESHOT,
  ctx-cd_label, host);
  if (ret  0)
  @@ -171,6 +174,25 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
   }
   EXPORT_SYMBOL(mmc_gpiod_request_cd_irq);
 
  +/* Register an alternate interrupt service routine for
  + * the card-detect GPIO.
  + */
  +int mmc_gpio_request_cd_isr(struct mmc_host *host,
  +   irqreturn_t (*isr)(int irq, void *dev_id))
  +{
  +   struct mmc_gpio *ctx;
  +   int ret;
  +
  +   ret = mmc_gpio_alloc(host);
  +   if (ret  0)
  +   return ret;
  +   ctx = host-slot.handler_priv;
  +   if (ctx-cd_gpio_isr)
  +   return -EBUSY;
  +   ctx-cd_gpio_isr = isr;
  +   return 0;
  +}

 I decided to queue those patchsets I recently posted which simplifies
 the slot-gpio API. Please re-base this patch on top of my next branch.

 OK.


 Moreover, I actually wonder whether we need to add this API at all.
 After my changes, all you need to do from your host driver -probe(),
 is to assign your isr routine to ctx-cd_gpio_isr.

 'struct mmc_gpio' is local to slot-gpio.c, so code in other files cannot
 access the members directly.

You are right. I don't think they should.

Let's add the API instead, but rename it to something like
mmc_gpio_set_cd_isr().

Kind regards
Uffe


 If you want to move it to include/linux/mmc/host.h and change
   void *handler_priv;
 to
   struct mmc_gpio *gpios;

 or similar, then I'll happily update it directly.
 What do you think?

 NeilBrown



  +
   /**
* mmc_gpio_request_cd - request a gpio for card-detection
* @host: mmc host
  diff --git a/include/linux/mmc/slot-gpio.h b/include/linux/mmc/slot-gpio.h
  index e56fa24c9322..9e55db60deb0 100644
  --- a/include/linux/mmc/slot-gpio.h
  +++ b/include/linux/mmc/slot-gpio.h
  @@ -28,6 +28,8 @@ int mmc_gpiod_request_cd(struct mmc_host *host, const 
  char *con_id,
   int mmc_gpiod_request_ro(struct mmc_host *host, const char *con_id,
   unsigned int idx, bool override_active_level,
   unsigned int debounce, bool *gpio_invert);
  +int mmc_gpio_request_cd_isr(struct mmc_host *host,
  +   irqreturn_t (*isr)(int irq, void *dev_id));
   void mmc_gpiod_free_cd(struct mmc_host *host);
   void mmc_gpiod_request_cd_irq(struct mmc_host *host);
 
 
 

 Kind regards
 Uffe

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

Re: [PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc

[Ulf Hansson]

On 19 December 2014 at 20:02, Doug Anderson diand...@chromium.org wrote:
 Ulf,

 On Fri, Dec 19, 2014 at 2:17 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 3 December 2014 at 00:42, Doug Anderson diand...@chromium.org wrote:
 Bing Zhao at Marvell found a problem with dw_mmc where interrupts
 weren't firing sometimes.  He tracked it down to a read-modify-write
 problem with the INTMASK.  These patches fix the problem.

 Note: I've picked up a  1-year old series here to make another
 attempt at landing it upstream.  These patches have been in shipping
 Chromebooks for the last year.  Note that v3 to v4 has no changes
 other than a rebase and a small commit message update.

 The first two patches extend the init_card() mechanism of MMC core
 to actually be called for all card types, not just SDIO.  That could
 be applied any time and should fix at least one longstanding bug
 (untested).

 The third patch is a cleanup patch to use init_card() to move things
 around a bit so we don't need to handle SDIO cards in such a strange
 place.  On earlier versions of this patch Seungwon brought up a few
 points which I have _not_ addressed.  See
 https://patchwork.kernel.org/patch/3049071/.  Other than talk of
 cards with out of band interrupts maybe being able to gate their
 clocks, he wanted to use MMC_QUIRK_BROKEN_CLK_GATING.  I didn't do
 that because of the ordering of init_card() and when the quirks are
 set.  Some users of init_card() like pandora_wl1251_init_card() rely
 on it being called very early in the process.
 pandora_wl1251_init_card() hardcodes a vendor and device and thus need
 to be called super early.  On the other hand the code that adds quirks
 _reads_ the vendor and device.  It can't possibly move before
 init_card().  If folks are willing to take an additional host op of
 init_card_late() I can certainly go that way, though.

 The fourth patch is (I think) reviewed and ready to go assuming the
 other two land.

 I have queued this up for 3.20.

 Thanks!


 It was a bit hard to follow the
 updated the revisions, please don't send patches in-reply-to for
 future sets.

 Very strange.  I didn't send out anything in-reply-to other than what
 git-send-email usually does.  I believe I had:

 [0] - no in reply to.
  [1] - in reply to [0]
  [2] - in reply to [0]
  [3] - in reply to [0]
  [4] - in reply to [0]

That's good. As long as there are no in-reply to previous versions of
patches/patchsets.

I am using gmails web-based client so it could very well be that it
does some magic, which I am not yet aware of.


 Is there some other way you'd prefer?

 Looking full headers in https://patchwork.kernel.org/patch/5425241/,
 I confirm it is in-reply-to
 1417563767-32181-1-git-send-email-diand...@chromium.org.  Patchwork
 doesn't keep cover letters, but you can see at
 http://www.spinics.net/lists/linux-mmc/msg29699.html) that there is
 no in-reply-to.

 I'm more than happy to adjust my workflow if you can give me some
 specifics.  Thanks!  :)


 In v5, I don't find a patch 1/4. Anyway, I have taken patch 2-4.

 Ah, maybe because it wasn't sent to linux-mmc?  I messed that up and
 will try to do better in the future.  Sorry.  :(  You were in the To
 line, though.  You can see at
 https://patchwork.kernel.org/patch/5425241/.

 Do you want me to repost it and CC linux-mmc with Tony's Ack?

I suggest you have a look at my next branch and to verify that I
haven't screwed things up. If so, either I should drop the patches and
you make a resend or if it's possible to just send an incremental path
on top?

Kind regards
Uffe


 ---

 Note: patchwork seems to find all my patches:

 pwclient list -w diand...@chromium.org -p 

 5425241 New  [v5,1/4] ARM: OMAP2+: Make sure
 pandora_wl1251_init_card() applies to SDIO only
 5425291 New  [v5,1/4] ARM: OMAP2+: Make sure
 pandora_wl1251_init_card() applies to SDIO only
 5425311 New  [v5,1/4] ARM: OMAP2+: Make sure
 pandora_wl1251_init_card() applies to SDIO only
 5425231 New  [v5,2/4] mmc: core: Support the optional
 init_card() callback for MMC and SD
 5425301 New  [v5,2/4] mmc: core: Support the optional
 init_card() callback for MMC and SD
 5425271 New  [v5,3/4] mmc: dw_mmc: Cleanup disable of low
 power mode w/ SDIO interrupts
 5425281 New  [v5,3/4] mmc: dw_mmc: Cleanup disable of low
 power mode w/ SDIO interrupts
 5425251 New  [v5,4/4] mmc: dw_mmc: Protect read-modify-write
 of INTMASK with a lock
 5425261 New  [v5,4/4] mmc: dw_mmc: Protect read-modify-write
 of INTMASK with a lock
--
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

Re: [PATCH 1/3] mmc: core: Allow host driver to provide isr for card-detect interrupts.

[Ulf Hansson]

On 24 December 2014 at 22:20, NeilBrown ne...@suse.de wrote:
 One of the reasons omap_hsmmc doesn't use the slot-gpio library
 is that it has some non-standard functionality in the card-detect
 interrupt service routine.

 To make it possible for omap_hsmmc (and maybe others) to be converted
 to use slot-gpio, add 'mmc_gpio_set_cd_isr' which provides an
 alternate isr to be registered by the slot-gpio code.

 Signed-off-by: NeilBrown ne...@suse.de
 ---
  drivers/mmc/core/slot-gpio.c  |   20 +++-
  include/linux/mmc/slot-gpio.h |2 ++
  2 files changed, 21 insertions(+), 1 deletion(-)

 diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
 index 1a3edbd47719..1826b25a2a40 100644
 --- a/drivers/mmc/core/slot-gpio.c
 +++ b/drivers/mmc/core/slot-gpio.c
 @@ -25,6 +25,7 @@ struct mmc_gpio {
 struct gpio_desc *cd_gpio;
 bool override_ro_active_level;
 bool override_cd_active_level;
 +   irqreturn_t (*cd_gpio_isr)(int irq, void *dev_id);
 char *ro_label;
 char cd_label[0];
  };
 @@ -136,8 +137,10 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
 irq = -EINVAL;

 if (irq = 0) {
 +   if (!ctx-cd_gpio_isr)
 +   ctx-cd_gpio_isr = mmc_gpio_cd_irqt;
 ret = devm_request_threaded_irq(host-parent, irq,
 -   NULL, mmc_gpio_cd_irqt,
 +   NULL, ctx-cd_gpio_isr,
 IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | 
 IRQF_ONESHOT,
 ctx-cd_label, host);
 if (ret  0)
 @@ -151,6 +154,21 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
  }
  EXPORT_SYMBOL(mmc_gpiod_request_cd_irq);

 +/* Register an alternate interrupt service routine for
 + * the card-detect GPIO.
 + */
 +int mmc_gpio_set_cd_isr(struct mmc_host *host,
 +   irqreturn_t (*isr)(int irq, void *dev_id))
 +{
 +   struct mmc_gpio *ctx;
 +
 +   ctx = host-slot.handler_priv;
 +   if (ctx-cd_gpio_isr)
 +   return -EBUSY;
 +   ctx-cd_gpio_isr = isr;
 +   return 0;

I feel this is a bit more complex than what's needed.
How about just assigning -cd_gpio_isr() callback, without checking
it's value first and then make mmc_gpio_set_cd_isr() a void function?

 +}
 +
  /**
   * mmc_gpio_request_cd - request a gpio for card-detection
   * @host: mmc host
 diff --git a/include/linux/mmc/slot-gpio.h b/include/linux/mmc/slot-gpio.h
 index 4a36d6954631..4faf41c9a77a 100644
 --- a/include/linux/mmc/slot-gpio.h
 +++ b/include/linux/mmc/slot-gpio.h
 @@ -26,6 +26,8 @@ int mmc_gpiod_request_cd(struct mmc_host *host, const char 
 *con_id,
  int mmc_gpiod_request_ro(struct mmc_host *host, const char *con_id,
  unsigned int idx, bool override_active_level,
  unsigned int debounce, bool *gpio_invert);
 +int mmc_gpio_set_cd_isr(struct mmc_host *host,
 +   irqreturn_t (*isr)(int irq, void *dev_id));
  void mmc_gpiod_request_cd_irq(struct mmc_host *host);

  #endif


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

Re: [PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc

[Ulf Hansson]

On 2 January 2015 at 18:11, Tony Lindgren t...@atomide.com wrote:
 * Doug Anderson diand...@chromium.org [150102 09:09]:
 Ulf,

 On Tue, Dec 30, 2014 at 2:29 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
  In v5, I don't find a patch 1/4. Anyway, I have taken patch 2-4.
 
  Ah, maybe because it wasn't sent to linux-mmc?  I messed that up and
  will try to do better in the future.  Sorry.  :(  You were in the To
  line, though.  You can see at
  https://patchwork.kernel.org/patch/5425241/.
 
  Do you want me to repost it and CC linux-mmc with Tony's Ack?
 
  I suggest you have a look at my next branch and to verify that I
  haven't screwed things up. If so, either I should drop the patches and
  you make a resend or if it's possible to just send an incremental path
  on top?

 The patches that landed look good to me, but I think you might break
 omap3pandora's WiFi until you land patch #1 in the series.  It has
 Tony's Ack so I think he intends for you to land it in your tree.

 [v5,1/4] ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO 
 only

 Yes please pick that one up too to avoid breakage. The changes to the
 mach-omap2/board-*.c files are only minimal fixes, so it should not
 conflict with anything I'll be applying.

Tony, Doug,

I have picked it up from the arm patch tracker and applied it for my
next branch. I have put it prior the following patch:
mmc: core: Support the optional init_card() callback for MMC and SD.

Kind regards
Uffe


 Regards,

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

Re: How to manage SDIO interrupts with a runtime power managed host.

[Ulf Hansson]

On 27 January 2015 at 12:47, NeilBrown ne...@suse.de wrote:

 The (libertas) wifi chip in my GTA04 is connected to an OMAP3 HS_MMC port as
 an SDIO card.

 When I configure it (via devicetree) to respond to the SD interrupt line
 (rather than polling for SD interrupts) it doesn't work well at all.

 After lots of experimenting and beating my head against a brick wall I have
 finally discovered why.

 According to section 7.1.2 of

 http://www.sandisk.com/media/File/OEM/Manuals/SD_SDIO_specsv1.pdf

 In the case where the interrupt mechanism is used to wake the host while
 the card is in a low power state (i.e. no clocks), Both the card and the
 host shall be placed into the 1-bit SD mode prior to stopping the clock.

 The omap_hsmmc driver doesn't appear to be aware of this requirement (and I
 cannot see that other host drivers are either). It will turn off the clocks
 for a 4-bit device without first switching to 1-bit.

I guess the reason to why this isn't implemented in host drivers is
either because such behaviour for SDIO cards hasn't been observed
(that's my case) or that it's kept as hacks in out of tree patches.


 (The mmc core does switch to 1-bit mode for system suspend, but not for
 runtime suspend).

 This requirement exactly explains my observations.  The chip is configured
 for 4-bit mode, and once pm_runtime turns the clocks off, interrupts stop
 being delivered.  Note that the reconfigure DAT1 as a GPIO magic is properly
 configured.  When something else wakes the chip, the GPIO interrupt handler
 will sometimes run in the small window between the clocks coming back and
 the DAT1 pin being configured back to the default setting.

Have you really investigated that it's not the GPIO IRQ that's not
been properly configured?


 If I configure the chip as using a 1-bit wide interface, it works perfectly.
 In this configuration it is significantly faster than 4-bit polled mode, but
 somewhat slower than 4-bit interrupt mode with runtime_pm disabled.

Okay, so it seems like your assumption is correct. We need a way to
switch to 1-bit when host drivers is about to enter runtime PM suspend
state.


 I'm open for suggestions on how best to fix this.
 I tried putting code into the pm_runtime_{suspend,resume} callbacks in
 omap_hsmmc.c to switch the bus width, but that doesn't work.  The callbacks
 aren't allowed to sleep, and telling the card to use the new bus width is a
 sleeping operation.

They are allowed to sleep unless the have set pm_runtime_irq_safe(). I
don't think any of the mmc drivers are configured as such.


 I imagine I could possibly do something similar to MMC_CLKGATE to switch to
 1-bit mode after some idle time, and have the pm_runtime_suspend abort if it
 is still in 4-bit mode.  Would that be a good idea?

I would prefer not.

I don't like the MMC_CLKGATE thing, since it just add complexity to
the mmc core for things that I think should be handled through runtime
PM instead.

 Would it make sense to get mmc_gate_clock to switch bus width (if it is an
 SDIO card with interrupts enabled) rather than having a separate timeout
 thing?

That will hit performance for each and every SDIO request. To me this
is not an option.

Kind regards
Uffe
--
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

Re: [PATCH 3/3] mmc: omap_hsmmc: switch to 1-bit before turning off clocks if interrupts expected.

[Ulf Hansson]

On 28 January 2015 at 00:35, NeilBrown ne...@suse.de wrote:
 According to section 7.1.2 of

 http://www.sandisk.com/media/File/OEM/Manuals/SD_SDIO_specsv1.pdf

 In the case where the interrupt mechanism is used to wake the host while
 the card is in a low power state (i.e. no clocks), Both the card and the
 host shall be placed into the 1-bit SD mode prior to stopping the clock.


 This is particularly important for the Marvell libertas wifi chip
 in the GTA04.  While in 4-bit mode it will only signal an interrupt
 when the clock is running (which is why setting CLKEXTFREE is
 important).
 In 1-bit mode, the interrupt is asynchronous (explained in OMAP3
 TRM description of the CIRQ flag to MMCHS_STAT:

   In 1-bit mode, interrupt source is asynchronous (can be a source of
   asynchronous wakeup).
   In 4-bit mode, interrupt source is sampled during the interrupt
   cycle.

 )

 We cannot simply set 1-bit mode in omap_hsmmc_runtime_suspend
 as that is called under a spinlock, and setting 1-bit mode requires
 a sleeping call to the card.

 So:
  - use a work_struct to schedule setting of 1-bit mode
  - intro a 'force_narrow' state flag which transitions:
  0 - NARROW_PENDING - NARROW_FORCED - 0
  - have omap_hsmmc_runtime_suspend fail if interrupts are expected
but bus is not in 1-bit mode.  When it fails it schedules
the work to change the width. and sets NARROW_PENDING
  - when the host is claimed, if NARROW_FORCED is set, restore the
4-bit bus
  - When the host is released (disable_fclk), if NARROW_FORCED,
then suspend immediately, no autosuspend.  If NARROW_PENDING,
clear that flag as the device has obviously just been used.

I can't give you more detailed comment about this patch(set) yet. Need
to think a bit more first.

Anyway, I have one concern, see comment below.


 This all allows a graceful and race-free switch to 1-bit mode
 before switching off the clocks, if interrupts are enabled.

 With this, I can use my libertas wifi with a 4-bit bus, with
 interrupts and runtime power-management enabled, and get around
 14Mb/sec throughput (which is the best I've seen).

 Signed-off-by: NeilBrown n...@brown.name
 ---
  drivers/mmc/host/omap_hsmmc.c |   55 
 -
  1 file changed, 53 insertions(+), 2 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index f84cfb01716d..91ddebbec8a3 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -214,6 +214,10 @@ struct omap_hsmmc_host {
 int reqs_blocked;
 int use_reg;
 int req_in_progress;
 +   int force_narrow;
 +#define NARROW_PENDING 1
 +#define NARROW_FORCED  2
 +   struct work_struct  width_work;
 unsigned long   clk_rate;
 unsigned intflags;
  #define AUTO_CMD23 (1  0)/* Auto CMD23 support */
 @@ -1778,12 +1782,43 @@ static void omap_hsmmc_conf_bus_power(struct 
 omap_hsmmc_host *host)
 set_sd_bus_power(host);
  }

 +static void omap_hsmmc_width_work(struct work_struct *work)
 +{
 +   struct omap_hsmmc_host *host = container_of(work,
 +   struct omap_hsmmc_host,
 +   width_work);
 +   atomic_t noblock;
 +
 +   atomic_set(noblock, 1);
 +   if (__mmc_claim_host(host-mmc, noblock)) {
 +   /* Device active again */
 +   host-force_narrow = 0;
 +   return;
 +   }
 +   if (host-force_narrow != NARROW_PENDING) {
 +   /* Someone claimed and released before we got here */
 +   mmc_release_host(host-mmc);
 +   return;
 +   }
 +   if (sdio_disable_wide(host-mmc-card) == 0)
 +   host-force_narrow = NARROW_FORCED;
 +   else
 +   host-force_narrow = 0;
 +   mmc_release_host(host-mmc);
 +}
 +
  static int omap_hsmmc_enable_fclk(struct mmc_host *mmc)
  {
 struct omap_hsmmc_host *host = mmc_priv(mmc);

 pm_runtime_get_sync(host-dev);

 +   if (host-force_narrow == NARROW_FORCED) {
 +   if (sdio_enable_4bit_bus(mmc-card)  0)
 +   mmc_set_bus_width(mmc, MMC_BUS_WIDTH_4);
 +   host-force_narrow = 0;
 +   }
 +
 return 0;
  }

 @@ -1791,8 +1826,13 @@ static int omap_hsmmc_disable_fclk(struct mmc_host 
 *mmc)
  {
 struct omap_hsmmc_host *host = mmc_priv(mmc);

 -   pm_runtime_mark_last_busy(host-dev);
 -   pm_runtime_put_autosuspend(host-dev);
 +   if (host-force_narrow == NARROW_FORCED) {
 +   pm_runtime_put_sync(host-dev);
 +   } else {
 +   host-force_narrow = 0;
 +   pm_runtime_mark_last_busy(host-dev);
 +   pm_runtime_put_autosuspend(host-dev);
 +   }

 return 0;
  }
 @@ 

Re: [PATCH 0/3] Convert omap_hsmmc to use common devicetree parsing code.

[Ulf Hansson]

On 12 January 2015 at 20:23, NeilBrown ne...@suse.de wrote:
 This is another resend with mmc_gpio_set_cd_isr() now returning
 void and being EXPORTed.

 I included
 WARN_ON(ctx-cd_gpio_isr);
 to guard against misuse.

 My goal is to get omap_hsmmc to use the common code for parsing of,
 particularly so that I can set cap-power-off-card, which omap_hsmmc
 doesn't explicitly report.

 Thanks,
 NeilBrown

 P.S. Sorry for delay - I've been travelling.

 ---

 NeilBrown (3):
   mmc: core: Allow host driver to provide isr for card-detect interrupts.
   mmc: omap_hsmmc: use slot-gpio library for gpio support.
   mmc: omap_hsmmc: use mmc_of_parse to parse common mmc configuration.


  drivers/mmc/core/slot-gpio.c  |   18 +++
  drivers/mmc/host/omap_hsmmc.c |  100 
 +
  include/linux/mmc/slot-gpio.h |2 +
  3 files changed, 40 insertions(+), 80 deletions(-)



Thanks! Applied for next.

Kind regards
Uffe
--
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

Re: [PATCH] ARM: OMAP2: HSMMC: explicit fields to declare cover/card detect pin

[Ulf Hansson]

On 20 March 2015 at 15:53, Andreas Fenkart afenk...@gmail.com wrote:
 board-rx51 has no card detect pin in the mmc slot, but can detect that
 the (cell-phone) cover has been removed and the card is accessible.
 The semantics between cover/card detect differ, the gpio on the slot
 informs you after the card has been removed, cover removal does not
 necessarily mean that the card has been removed.
 This means different code paths are necessary. To complete this we
 also want different fields in the platform data for cover and card
 detect. This separation is not pushed all the way down into struct
 omap2_hsmmc_info which is used to initialize the platform data.
 If we did that we had to go over all board files and set the new
 gpio_cod pin to -EINVAL. If we forget one board or some out-of-tree
 archicture forgets that the default '0' is used which is a valid pin
 number.

 Signed-off-by: Andreas Fenkart afenk...@gmail.com

Tony, are you fine with this change? I believe I should take it
through my mmc tree due to that I have other omap_hsmmc patches
already queued.

Kind regards
Uffe

 ---
  arch/arm/mach-omap2/hsmmc.c  | 33 
 
  drivers/mmc/host/omap_hsmmc.c| 11 ++-
  include/linux/platform_data/hsmmc-omap.h |  6 ++
  3 files changed, 33 insertions(+), 17 deletions(-)

 diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
 index dc6e79c..9a8611a 100644
 --- a/arch/arm/mach-omap2/hsmmc.c
 +++ b/arch/arm/mach-omap2/hsmmc.c
 @@ -150,9 +150,13 @@ static int nop_mmc_set_power(struct device *dev, int 
 power_on, int vdd)
  static inline void omap_hsmmc_mux(struct omap_hsmmc_platform_data
   *mmc_controller, int controller_nr)
  {
 -   if (gpio_is_valid(mmc_controller-switch_pin) 
 -   (mmc_controller-switch_pin  OMAP_MAX_GPIO_LINES))
 -   omap_mux_init_gpio(mmc_controller-switch_pin,
 +   if (gpio_is_valid(mmc_controller-gpio_cd) 
 +   (mmc_controller-gpio_cd  OMAP_MAX_GPIO_LINES))
 +   omap_mux_init_gpio(mmc_controller-gpio_cd,
 +  OMAP_PIN_INPUT_PULLUP);
 +   if (gpio_is_valid(mmc_controller-gpio_cod) 
 +   (mmc_controller-gpio_cod  OMAP_MAX_GPIO_LINES))
 +   omap_mux_init_gpio(mmc_controller-gpio_cod,
OMAP_PIN_INPUT_PULLUP);
 if (gpio_is_valid(mmc_controller-gpio_wp) 
 (mmc_controller-gpio_wp  OMAP_MAX_GPIO_LINES))
 @@ -250,15 +254,20 @@ static int __init omap_hsmmc_pdata_init(struct 
 omap2_hsmmc_info *c,
 mmc-internal_clock = !c-ext_clock;
 mmc-reg_offset = 0;

 -   mmc-switch_pin = c-gpio_cd;
 +   if (c-cover_only) {
 +   /* detect if mobile phone cover removed */
 +   mmc-gpio_cd = -EINVAL;
 +   mmc-gpio_cod = c-gpio_cd;
 +   } else {
 +   /* card detect pin on the mmc socket itself */
 +   mmc-gpio_cd = c-gpio_cd;
 +   mmc-gpio_cod = -EINVAL;
 +   }
 mmc-gpio_wp = c-gpio_wp;

 mmc-remux = c-remux;
 mmc-init_card = c-init_card;

 -   if (c-cover_only)
 -   mmc-cover = 1;
 -
 if (c-nonremovable)
 mmc-nonremovable = 1;

 @@ -358,7 +367,15 @@ void omap_hsmmc_late_init(struct omap2_hsmmc_info *c)
 if (!mmc_pdata)
 continue;

 -   mmc_pdata-switch_pin = c-gpio_cd;
 +   if (c-cover_only) {
 +   /* detect if mobile phone cover removed */
 +   mmc_pdata-gpio_cd = -EINVAL;
 +   mmc_pdata-gpio_cod = c-gpio_cd;
 +   } else {
 +   /* card detect pin on the mmc socket itself */
 +   mmc_pdata-gpio_cd = c-gpio_cd;
 +   mmc_pdata-gpio_cod = -EINVAL;
 +   }
 mmc_pdata-gpio_wp = c-gpio_wp;

 res = omap_device_register(pdev);
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 053cd38..265391f 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -427,15 +427,15 @@ static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
  {
 int ret;

 -   if (pdata-cover  gpio_is_valid(pdata-switch_pin)) {
 -   ret = mmc_gpio_request_cd(mmc, pdata-switch_pin, 0);
 +   if (gpio_is_valid(pdata-gpio_cod)) {
 +   ret = mmc_gpio_request_cd(mmc, pdata-gpio_cod, 0);
 if (ret)
 return ret;

 host-get_cover_state = omap_hsmmc_get_cover_state;
 mmc_gpio_set_cd_isr(mmc, omap_hsmmc_cover_irq);
 -   } else if (!pdata-cover  gpio_is_valid(pdata-switch_pin)) {
 -   ret = mmc_gpio_request_cd(mmc, pdata-switch_pin, 0);
 +   } else if (gpio_is_valid(pdata-gpio_cd)) {
 +   ret = 

Re: [PATCH 6/6] mmc: omap_hsmmc: use generic slot-gpio isr to manage card detect pin

[Ulf Hansson]

On 3 March 2015 at 13:28, Andreas Fenkart afenk...@gmail.com wrote:
 Signed-off-by: Andreas Fenkart afenk...@gmail.com

Thanks! Applied.

Kind regards
Uffe


 ---
  drivers/mmc/host/omap_hsmmc.c | 13 -
  1 file changed, 13 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 4f6fbe5..0c3368e 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -418,7 +418,6 @@ static inline int omap_hsmmc_have_reg(void)

  #endif

 -static irqreturn_t omap_hsmmc_detect(int irq, void *dev_id);
  static irqreturn_t omap_hsmmc_cover_irq(int irq, void *dev_id);

  static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
 @@ -440,7 +439,6 @@ static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
 return ret;

 host-card_detect = omap_hsmmc_card_detect;
 -   mmc_gpio_set_cd_isr(mmc, omap_hsmmc_detect);
 }

 if (gpio_is_valid(pdata-gpio_wp)) {
 @@ -1247,17 +1245,6 @@ static irqreturn_t omap_hsmmc_cover_irq(int irq, void 
 *dev_id)
 return IRQ_HANDLED;
  }

 -/*
 - * irq handler to notify the core about card insertion/removal
 - */
 -static irqreturn_t omap_hsmmc_detect(int irq, void *dev_id)
 -{
 -   struct omap_hsmmc_host *host = dev_id;
 -
 -   mmc_detect_change(host-mmc, (HZ * 200) / 1000);
 -   return IRQ_HANDLED;
 -}
 -
  static void omap_hsmmc_dma_callback(void *param)
  {
 struct omap_hsmmc_host *host = param;
 --
 2.1.4

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

Re: [PATCH 5/6] mmc: omap_hsmmc: simplify card/cover detect isr

[Ulf Hansson]

On 3 March 2015 at 13:28, Andreas Fenkart afenk...@gmail.com wrote:
 strip the card dectet logic from cover detect isr and vice versa
 the generic mmc_gpio_cd_irqt isr, uses 200ms on removal/insertion,
 hence that should be fine here as well

 Signed-off-by: Andreas Fenkart afenk...@gmail.com

Thanks! Applied.

Kind regards
Uffe

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

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index ed68e55..4f6fbe5 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -1239,21 +1239,11 @@ static void omap_hsmmc_protect_card(struct 
 omap_hsmmc_host *host)
  static irqreturn_t omap_hsmmc_cover_irq(int irq, void *dev_id)
  {
 struct omap_hsmmc_host *host = dev_id;
 -   int carddetect;

 sysfs_notify(host-mmc-class_dev.kobj, NULL, cover_switch);

 -   if (host-card_detect) {
 -   carddetect = host-card_detect(host-dev);
 -   } else {
 -   omap_hsmmc_protect_card(host);
 -   carddetect = -ENOSYS;
 -   }
 -
 -   if (carddetect)
 -   mmc_detect_change(host-mmc, (HZ * 200) / 1000);
 -   else
 -   mmc_detect_change(host-mmc, (HZ * 50) / 1000);
 +   omap_hsmmc_protect_card(host);
 +   mmc_detect_change(host-mmc, (HZ * 200) / 1000);
 return IRQ_HANDLED;
  }

 @@ -1263,19 +1253,8 @@ static irqreturn_t omap_hsmmc_cover_irq(int irq, void 
 *dev_id)
  static irqreturn_t omap_hsmmc_detect(int irq, void *dev_id)
  {
 struct omap_hsmmc_host *host = dev_id;
 -   int carddetect;
 -
 -   if (host-card_detect)
 -   carddetect = host-card_detect(host-dev);
 -   else {
 -   omap_hsmmc_protect_card(host);
 -   carddetect = -ENOSYS;
 -   }

 -   if (carddetect)
 -   mmc_detect_change(host-mmc, (HZ * 200) / 1000);
 -   else
 -   mmc_detect_change(host-mmc, (HZ * 50) / 1000);
 +   mmc_detect_change(host-mmc, (HZ * 200) / 1000);
 return IRQ_HANDLED;
  }

 --
 2.1.4

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

Re: [PATCH] ARM: OMAP2: HSMMC: explicit fields to declare cover/card detect pin

[Ulf Hansson]

On 20 March 2015 at 15:53, Andreas Fenkart afenk...@gmail.com wrote:
 board-rx51 has no card detect pin in the mmc slot, but can detect that
 the (cell-phone) cover has been removed and the card is accessible.
 The semantics between cover/card detect differ, the gpio on the slot
 informs you after the card has been removed, cover removal does not
 necessarily mean that the card has been removed.
 This means different code paths are necessary. To complete this we
 also want different fields in the platform data for cover and card
 detect. This separation is not pushed all the way down into struct
 omap2_hsmmc_info which is used to initialize the platform data.
 If we did that we had to go over all board files and set the new
 gpio_cod pin to -EINVAL. If we forget one board or some out-of-tree
 archicture forgets that the default '0' is used which is a valid pin
 number.

 Signed-off-by: Andreas Fenkart afenk...@gmail.com

Thanks! Applied.

Kind regards
Uffe

 ---
  arch/arm/mach-omap2/hsmmc.c  | 33 
 
  drivers/mmc/host/omap_hsmmc.c| 11 ++-
  include/linux/platform_data/hsmmc-omap.h |  6 ++
  3 files changed, 33 insertions(+), 17 deletions(-)

 diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
 index dc6e79c..9a8611a 100644
 --- a/arch/arm/mach-omap2/hsmmc.c
 +++ b/arch/arm/mach-omap2/hsmmc.c
 @@ -150,9 +150,13 @@ static int nop_mmc_set_power(struct device *dev, int 
 power_on, int vdd)
  static inline void omap_hsmmc_mux(struct omap_hsmmc_platform_data
   *mmc_controller, int controller_nr)
  {
 -   if (gpio_is_valid(mmc_controller-switch_pin) 
 -   (mmc_controller-switch_pin  OMAP_MAX_GPIO_LINES))
 -   omap_mux_init_gpio(mmc_controller-switch_pin,
 +   if (gpio_is_valid(mmc_controller-gpio_cd) 
 +   (mmc_controller-gpio_cd  OMAP_MAX_GPIO_LINES))
 +   omap_mux_init_gpio(mmc_controller-gpio_cd,
 +  OMAP_PIN_INPUT_PULLUP);
 +   if (gpio_is_valid(mmc_controller-gpio_cod) 
 +   (mmc_controller-gpio_cod  OMAP_MAX_GPIO_LINES))
 +   omap_mux_init_gpio(mmc_controller-gpio_cod,
OMAP_PIN_INPUT_PULLUP);
 if (gpio_is_valid(mmc_controller-gpio_wp) 
 (mmc_controller-gpio_wp  OMAP_MAX_GPIO_LINES))
 @@ -250,15 +254,20 @@ static int __init omap_hsmmc_pdata_init(struct 
 omap2_hsmmc_info *c,
 mmc-internal_clock = !c-ext_clock;
 mmc-reg_offset = 0;

 -   mmc-switch_pin = c-gpio_cd;
 +   if (c-cover_only) {
 +   /* detect if mobile phone cover removed */
 +   mmc-gpio_cd = -EINVAL;
 +   mmc-gpio_cod = c-gpio_cd;
 +   } else {
 +   /* card detect pin on the mmc socket itself */
 +   mmc-gpio_cd = c-gpio_cd;
 +   mmc-gpio_cod = -EINVAL;
 +   }
 mmc-gpio_wp = c-gpio_wp;

 mmc-remux = c-remux;
 mmc-init_card = c-init_card;

 -   if (c-cover_only)
 -   mmc-cover = 1;
 -
 if (c-nonremovable)
 mmc-nonremovable = 1;

 @@ -358,7 +367,15 @@ void omap_hsmmc_late_init(struct omap2_hsmmc_info *c)
 if (!mmc_pdata)
 continue;

 -   mmc_pdata-switch_pin = c-gpio_cd;
 +   if (c-cover_only) {
 +   /* detect if mobile phone cover removed */
 +   mmc_pdata-gpio_cd = -EINVAL;
 +   mmc_pdata-gpio_cod = c-gpio_cd;
 +   } else {
 +   /* card detect pin on the mmc socket itself */
 +   mmc_pdata-gpio_cd = c-gpio_cd;
 +   mmc_pdata-gpio_cod = -EINVAL;
 +   }
 mmc_pdata-gpio_wp = c-gpio_wp;

 res = omap_device_register(pdev);
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 053cd38..265391f 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -427,15 +427,15 @@ static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
  {
 int ret;

 -   if (pdata-cover  gpio_is_valid(pdata-switch_pin)) {
 -   ret = mmc_gpio_request_cd(mmc, pdata-switch_pin, 0);
 +   if (gpio_is_valid(pdata-gpio_cod)) {
 +   ret = mmc_gpio_request_cd(mmc, pdata-gpio_cod, 0);
 if (ret)
 return ret;

 host-get_cover_state = omap_hsmmc_get_cover_state;
 mmc_gpio_set_cd_isr(mmc, omap_hsmmc_cover_irq);
 -   } else if (!pdata-cover  gpio_is_valid(pdata-switch_pin)) {
 -   ret = mmc_gpio_request_cd(mmc, pdata-switch_pin, 0);
 +   } else if (gpio_is_valid(pdata-gpio_cd)) {
 +   ret = mmc_gpio_request_cd(mmc, pdata-gpio_cd, 0);
 if (ret)
 return ret;

 @@ -1932,7 +1932,8 @@ 

Re: [PATCH 0/2] Remove mmc_host enable/disable methods.

[Ulf Hansson]

On 25 March 2015 at 22:43, NeilBrown n...@brown.name wrote:
 Only omap_hsmmc uses enable and disable, and this seems
 to be largely for historical reasons and is no longer
 necessary.

 I have tested these patches with an OMAP3 with an
 uSD card on mmc0 and a wifi SDIO device on mmc1.

 NeilBrown


 ---

 NeilBrown (2):
   mmc: omap_hsmmc: stop using .enable and .disable method.
   mmc: remove enable/disable methods.


  drivers/mmc/core/core.c   |5 -
  drivers/mmc/host/omap_hsmmc.c |   24 +++-
  include/linux/mmc/host.h  |6 --
  3 files changed, 3 insertions(+), 32 deletions(-)

 --

Applied both patches (the later version of patch 1). Also I took the
liberty to update the commit messages.

If you care about my comments for patch1, let's deal with that as new
separate cleanup-patch.

Thanks!

Kind regards
Uffe
--
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

Re: [PATCH 2/4] mmc: core: allow non-blocking form of mmc_claim_host

[Ulf Hansson]

On 23 March 2015 at 10:58, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 24 February 2015 at 03:42, NeilBrown ne...@suse.de wrote:
 Change the handling for the 'abort' flag so that if
 it is set, but we can claim the host, then do the claim,
 rather than aborting.

 When the abort is async this just means that a race between aborting
 an allowing a claim is resolved slightly differently.  Any
 code must already be able to handle 'abort' being set just as the host
 is claimed.

 This allows extra functionality.  If __mmc_claim_host() is called
 with an 'abort' pointer which is initialized to '1', it will effect a
 non-blocking 'claim'.

 Signed-off-by: NeilBrown n...@brown.name
 ---
  drivers/mmc/core/core.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
 index 23f10f72e5f3..541c8903dc6b 100644
 --- a/drivers/mmc/core/core.c
 +++ b/drivers/mmc/core/core.c
 @@ -912,10 +912,11 @@ int __mmc_claim_host(struct mmc_host *host, atomic_t 
 *abort)
 spin_lock_irqsave(host-lock, flags);
 }
 set_current_state(TASK_RUNNING);
 -   if (!stop) {
 +   if (!host-claimed || host-claimer == current) {

 This seems risky in that regards that it will change the behaviour for
 the sdio_irq_thread(). Did you check that?

 I guess we could change the sdio_irq_thread() to read it's
 sdio_irq_thread_abort value before trying to claim the host?

Ah, that won't work. Since we may be spinning to claim the host and
the abort value may change dynamically during this time.

Another option would be to re-invent mmc_try_claim_host(). Which we
removed in commit:
b83e867026ca (mmc: core: remove dead function mmc_try_claim_host)

Kind regards
Uffe
--
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

Re: [PATCH] mmc: omap_hsmmc: add hibernation support

[Ulf Hansson]

On 27 February 2015 at 12:24,  grygorii.stras...@linaro.org wrote:
 From: Russ Dill russ.d...@ti.com

 Setting a dev_pm_ops suspend/resume pair but not a set of
 hibernation functions means those pm functions will not be
 called upon hibernation.
 Fix this by using SET_SYSTEM_SLEEP_PM_OPS, which appropriately
 assigns the suspend and hibernation handlers and move
 omap_hsmmc_x callbacks under CONFIG_PM_SLEEP to avoid build warnings.

 Signed-off-by: Russ Dill russ.d...@ti.com
 [grygorii.stras...@linaro.org: rebased on top of K4.0]
 Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org

Applied, thanks!

Kind regards
Uffe


 ---

 original patch: 
 https://github.com/russdill/linux/commit/2ea98def0717f0918426c2004122c63d52cff1b4

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

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index f84cfb0..9cc1ea3 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -2236,7 +2236,7 @@ static int omap_hsmmc_remove(struct platform_device 
 *pdev)
 return 0;
  }

 -#ifdef CONFIG_PM
 +#ifdef CONFIG_PM_SLEEP
  static int omap_hsmmc_suspend(struct device *dev)
  {
 struct omap_hsmmc_host *host = dev_get_drvdata(dev);
 @@ -2292,10 +2292,6 @@ static int omap_hsmmc_resume(struct device *dev)
 pm_runtime_put_autosuspend(host-dev);
 return 0;
  }
 -
 -#else
 -#define omap_hsmmc_suspend NULL
 -#define omap_hsmmc_resume  NULL
  #endif

  static int omap_hsmmc_runtime_suspend(struct device *dev)
 @@ -2376,8 +2372,7 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
  }

  static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
 -   .suspend= omap_hsmmc_suspend,
 -   .resume = omap_hsmmc_resume,
 +   SET_SYSTEM_SLEEP_PM_OPS(omap_hsmmc_suspend, omap_hsmmc_resume)
 .runtime_suspend = omap_hsmmc_runtime_suspend,
 .runtime_resume = omap_hsmmc_runtime_resume,
  };
 --
 1.9.1

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

Re: [PATCH 0/6] mmc: omap_hsmmc: simplify cover/card detect logic

[Ulf Hansson]

On 3 March 2015 at 13:28, Andreas Fenkart afenk...@gmail.com wrote:
 These patches are trying to clean up the cover/card detect logic.

   Mobile phones (some) have no card detect pin, but
   can detect if the cover is removed. The purpose is the
   same; detect if card is being added/removed, but the
   details differ.
   When the cover is removed, it does not mean the card is
   gone. But it might, since it is accessible now. It's like
   a warning. All the driver does is to limit write access to
   the card, see protect_card flag. In contrast, card detect
   notifies us after the fact, e.g. card is gone, card is
   inserted.

 While cover detect is only used by one platform (rx51), it
 complicates the card detect logic. By separating the code
 paths they both become easier to understand and maintain

 Patches have been tested by reverting: 95bebb5696ab
 'mmc: omap_hsmmc: use mmc_of_parse to parse common mmc configuration'
 otherwise gpio detection is handled by mmc_of_parse

 compile tested
 OMAP2:
 CONFIG_MACH_OMAP2_TUSB6010=y
 CONFIG_MACH_OMAP3_BEAGLE=y
 CONFIG_MACH_DEVKIT8000=y
 CONFIG_MACH_OMAP_LDP=y
 CONFIG_MACH_OMAP3530_LV_SOM=y
 CONFIG_MACH_OMAP3_TORPEDO=y
 CONFIG_MACH_OVERO=y
 CONFIG_MACH_OMAP3517EVM=y
 CONFIG_MACH_CRANEBOARD=y
 CONFIG_MACH_OMAP3_PANDORA=y
 CONFIG_MACH_TOUCHBOOK=y
 CONFIG_MACH_OMAP_3430SDP=y
 CONFIG_MACH_NOKIA_N810=y
 CONFIG_MACH_NOKIA_N810_WIMAX=y
 CONFIG_MACH_NOKIA_N8X0=y
 CONFIG_MACH_NOKIA_RX51=y
 CONFIG_MACH_CM_T35=y
 CONFIG_MACH_CM_T3517=y
 CONFIG_MACH_CM_T3730=y
 CONFIG_MACH_SBC3530=y
 CONFIG_MACH_TI8168EVM=y
 CONFIG_MACH_TI8148EVM=y

 Andreas Fenkart (6):
   mmc: omap_hsmmc: remove unused fields from struct omap_hsmmc_host
   mmc: omap_hsmmc: use slot-gpio functions to manage read-only pin
 directly
   mmc: omap_hsmmc: use distinctive code paths for cover / card detect
 logic
   ARM: OMAP2: HSMMC: platform_data: explicit gpio_cover / gpio_cd fields
   mmc: omap_hsmmc: simplify card/cover detect isr
   mmc: omap_hsmmc: use generic slot-gpio isr to manage card detect pin

  arch/arm/mach-omap2/hsmmc.c  | 33 +
  drivers/mmc/host/omap_hsmmc.c| 80 
 +---
  include/linux/platform_data/hsmmc-omap.h |  6 +--
  3 files changed, 48 insertions(+), 71 deletions(-)

 --
 2.1.4


Applied patch 1-3, thanks!

If I get an ack for patch 4 (ARM) and can take them all through my tree.

Kind regards
Uffe
--
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

Re: [PATCH 1/2] mmc: omap_hsmmc: stop using .enable and .disable method.

[Ulf Hansson]

On 26 March 2015 at 02:18, NeilBrown ne...@suse.de wrote:
 On Thu, 26 Mar 2015 08:43:37 +1100 NeilBrown n...@brown.name wrote:

 enable and disable are only used to get and put
 runtime pm references.  .set_ios already does this
 itself, and other drivers just do it in set_ios
 and .request without using enable/disable.

 So add pm_runtime get/put to omap_hsmmc_request(),
 and discard the enable/disable methods.

 Signed-off-by: NeilBrown n...@brown.name

 Sorry, that patch wasn't much good.  This one I have really tested properly
 and checked that the 'put' match the 'get's and  that the device to regularly
 go to sleep as expected.

 NeilBrown


 From: NeilBrown n...@brown.name
 Date: Thu, 26 Mar 2015 08:28:43 +1100
 Subject: [PATCH] mmc: omap_hsmmc: stop using .enable and .disable method.

 enable and disable are only used to get and put
 runtime pm references.  .set_ios already does this
 itself, and other drivers just do it in set_ios
 and .request without using enable/disable.

 So add pm_runtime get/put to omap_hsmmc_request(),
 and discard the enable/disable methods.

 Signed-off-by: NeilBrown n...@brown.name

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index f84cfb01716d..2cb81538a612 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -882,6 +882,8 @@ static void omap_hsmmc_request_done(struct 
 omap_hsmmc_host *host, struct mmc_req
 return;
 host-mrq = NULL;
 mmc_request_done(host-mmc, mrq);
 +   pm_runtime_mark_last_busy(host-dev);
 +   pm_runtime_put_autosuspend(host-dev);
  }

How about adding a function like this:

_omap_hsmmc_request_done(struct omap_hsmmc_host *host, struct mmc_req)
{
  mmc_request_done(host-mmc, mrq);
  pm_runtime_mark_last_busy(host-dev);
  pm_runtime_put_autosuspend(host-dev);
}

Then just invoke it from those places were needed?


  /*
 @@ -1305,6 +1307,8 @@ static void omap_hsmmc_dma_callback(void *param)

 host-mrq = NULL;
 mmc_request_done(host-mmc, mrq);
 +   pm_runtime_mark_last_busy(host-dev);
 +   pm_runtime_put_autosuspend(host-dev);
 }
  }

 @@ -1537,6 +1541,7 @@ static void omap_hsmmc_request(struct mmc_host *mmc, 
 struct mmc_request *req)

 BUG_ON(host-req_in_progress);
 BUG_ON(host-dma_ch != -1);
 +   pm_runtime_get_sync(host-dev);
 if (host-protect_card) {
 if (host-reqs_blocked  3) {
 /*
 @@ -1553,6 +1558,8 @@ static void omap_hsmmc_request(struct mmc_host *mmc, 
 struct mmc_request *req)
 req-data-error = -EBADF;
 req-cmd-retries = 0;
 mmc_request_done(mmc, req);
 +   pm_runtime_mark_last_busy(host-dev);
 +   pm_runtime_put_autosuspend(host-dev);
 return;
 } else if (host-reqs_blocked)
 host-reqs_blocked = 0;
 @@ -1566,6 +1573,8 @@ static void omap_hsmmc_request(struct mmc_host *mmc, 
 struct mmc_request *req)
 req-data-error = err;
 host-mrq = NULL;
 mmc_request_done(mmc, req);
 +   pm_runtime_mark_last_busy(host-dev);
 +   pm_runtime_put_autosuspend(host-dev);
 return;
 }
 if (req-sbc  !(host-flags  AUTO_CMD23)) {
 @@ -1778,25 +1787,6 @@ static void omap_hsmmc_conf_bus_power(struct 
 omap_hsmmc_host *host)
 set_sd_bus_power(host);
  }

 -static int omap_hsmmc_enable_fclk(struct mmc_host *mmc)
 -{
 -   struct omap_hsmmc_host *host = mmc_priv(mmc);
 -
 -   pm_runtime_get_sync(host-dev);
 -
 -   return 0;
 -}
 -
 -static int omap_hsmmc_disable_fclk(struct mmc_host *mmc)
 -{
 -   struct omap_hsmmc_host *host = mmc_priv(mmc);
 -
 -   pm_runtime_mark_last_busy(host-dev);
 -   pm_runtime_put_autosuspend(host-dev);
 -
 -   return 0;
 -}
 -
  static int omap_hsmmc_multi_io_quirk(struct mmc_card *card,
  unsigned int direction, int blk_size)
  {
 @@ -1808,8 +1798,6 @@ static int omap_hsmmc_multi_io_quirk(struct mmc_card 
 *card,
  }

  static struct mmc_host_ops omap_hsmmc_ops = {
 -   .enable = omap_hsmmc_enable_fclk,
 -   .disable = omap_hsmmc_disable_fclk,
 .post_req = omap_hsmmc_post_req,
 .pre_req = omap_hsmmc_pre_req,
 .request = omap_hsmmc_request,

Finally, I think you have forgotten to deal with pm_runtime_get|put*()
in omap_hsmmc_enable_sdio_irq().

Kind regards
Uffe
--
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

Re: [PATCH 1/2] mmc: omap_hsmmc: stop using .enable and .disable method.

[Ulf Hansson]

On 26 March 2015 at 08:38, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 26 March 2015 at 02:18, NeilBrown ne...@suse.de wrote:
 On Thu, 26 Mar 2015 08:43:37 +1100 NeilBrown n...@brown.name wrote:

 enable and disable are only used to get and put
 runtime pm references.  .set_ios already does this
 itself, and other drivers just do it in set_ios
 and .request without using enable/disable.

 So add pm_runtime get/put to omap_hsmmc_request(),
 and discard the enable/disable methods.

 Signed-off-by: NeilBrown n...@brown.name

 Sorry, that patch wasn't much good.  This one I have really tested properly
 and checked that the 'put' match the 'get's and  that the device to regularly
 go to sleep as expected.

 NeilBrown


 From: NeilBrown n...@brown.name
 Date: Thu, 26 Mar 2015 08:28:43 +1100
 Subject: [PATCH] mmc: omap_hsmmc: stop using .enable and .disable method.

 enable and disable are only used to get and put
 runtime pm references.  .set_ios already does this
 itself, and other drivers just do it in set_ios
 and .request without using enable/disable.

 So add pm_runtime get/put to omap_hsmmc_request(),
 and discard the enable/disable methods.

 Signed-off-by: NeilBrown n...@brown.name

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index f84cfb01716d..2cb81538a612 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -882,6 +882,8 @@ static void omap_hsmmc_request_done(struct 
 omap_hsmmc_host *host, struct mmc_req
 return;
 host-mrq = NULL;
 mmc_request_done(host-mmc, mrq);
 +   pm_runtime_mark_last_busy(host-dev);
 +   pm_runtime_put_autosuspend(host-dev);
  }

 How about adding a function like this:

 _omap_hsmmc_request_done(struct omap_hsmmc_host *host, struct mmc_req)
 {
   mmc_request_done(host-mmc, mrq);
   pm_runtime_mark_last_busy(host-dev);
   pm_runtime_put_autosuspend(host-dev);
 }

 Then just invoke it from those places were needed?


  /*
 @@ -1305,6 +1307,8 @@ static void omap_hsmmc_dma_callback(void *param)

 host-mrq = NULL;
 mmc_request_done(host-mmc, mrq);
 +   pm_runtime_mark_last_busy(host-dev);
 +   pm_runtime_put_autosuspend(host-dev);
 }
  }

 @@ -1537,6 +1541,7 @@ static void omap_hsmmc_request(struct mmc_host *mmc, 
 struct mmc_request *req)

 BUG_ON(host-req_in_progress);
 BUG_ON(host-dma_ch != -1);
 +   pm_runtime_get_sync(host-dev);
 if (host-protect_card) {
 if (host-reqs_blocked  3) {
 /*
 @@ -1553,6 +1558,8 @@ static void omap_hsmmc_request(struct mmc_host *mmc, 
 struct mmc_request *req)
 req-data-error = -EBADF;
 req-cmd-retries = 0;
 mmc_request_done(mmc, req);
 +   pm_runtime_mark_last_busy(host-dev);
 +   pm_runtime_put_autosuspend(host-dev);
 return;
 } else if (host-reqs_blocked)
 host-reqs_blocked = 0;
 @@ -1566,6 +1573,8 @@ static void omap_hsmmc_request(struct mmc_host *mmc, 
 struct mmc_request *req)
 req-data-error = err;
 host-mrq = NULL;
 mmc_request_done(mmc, req);
 +   pm_runtime_mark_last_busy(host-dev);
 +   pm_runtime_put_autosuspend(host-dev);
 return;
 }
 if (req-sbc  !(host-flags  AUTO_CMD23)) {
 @@ -1778,25 +1787,6 @@ static void omap_hsmmc_conf_bus_power(struct 
 omap_hsmmc_host *host)
 set_sd_bus_power(host);
  }

 -static int omap_hsmmc_enable_fclk(struct mmc_host *mmc)
 -{
 -   struct omap_hsmmc_host *host = mmc_priv(mmc);
 -
 -   pm_runtime_get_sync(host-dev);
 -
 -   return 0;
 -}
 -
 -static int omap_hsmmc_disable_fclk(struct mmc_host *mmc)
 -{
 -   struct omap_hsmmc_host *host = mmc_priv(mmc);
 -
 -   pm_runtime_mark_last_busy(host-dev);
 -   pm_runtime_put_autosuspend(host-dev);
 -
 -   return 0;
 -}
 -
  static int omap_hsmmc_multi_io_quirk(struct mmc_card *card,
  unsigned int direction, int blk_size)
  {
 @@ -1808,8 +1798,6 @@ static int omap_hsmmc_multi_io_quirk(struct mmc_card 
 *card,
  }

  static struct mmc_host_ops omap_hsmmc_ops = {
 -   .enable = omap_hsmmc_enable_fclk,
 -   .disable = omap_hsmmc_disable_fclk,
 .post_req = omap_hsmmc_post_req,
 .pre_req = omap_hsmmc_pre_req,
 .request = omap_hsmmc_request,

 Finally, I think you have forgotten to deal with pm_runtime_get|put*()
 in omap_hsmmc_enable_sdio_irq().

No, _me_ totally forgot that SDIO IRQ is a special case and from the
above mentioned function we mustn't deal with runtime PM, since that
function is executed in IRQ context. :-)

Also, since omap's runtime PM -suspend() callback disables regular
SDIO IRQS and enables wakeups, this case is already covered. Please
ignore my comment above and sorry for the noise

Re: [PATCH 3/4] mmc: sdio: support switching to 1-bit before turning off clocks

[Ulf Hansson]

On 24 February 2015 at 03:42, NeilBrown ne...@suse.de wrote:
 According to section 7.1.2 of

 http://www.sandisk.com/media/File/OEM/Manuals/SD_SDIO_specsv1.pdf

 In the case where the interrupt mechanism is used to wake the host while
 the card is in a low power state (i.e. no clocks), Both the card and the
 host shall be placed into the 1-bit SD mode prior to stopping the clock.

 This is particularly important for the Marvell libertas wifi chip
 in the GTA04.  While in 4-bit mode it will only signal an interrupt
 when the clock is running (which is why setting CLKEXTFREE is
 important).
 In 1-bit mode, the interrupt is asynchronous (explained in OMAP3
 TRM description of the CIRQ flag to MMCHS_STAT:

   In 1-bit mode, interrupt source is asynchronous (can be a source of
   asynchronous wakeup).
   In 4-bit mode, interrupt source is sampled during the interrupt
   cycle.

 )

 It is awkward to simply set 1-bit mode in -runtime_suspend
 as that will call mmc_set_ios which calls ops-set_ios(),
 which will likely call pm_runtime_get_sync(), on the device that
 is currently suspending.  This deadlocks.

 So:
  - create a work_struct to schedule setting of 1-bit mode
  - introduce an 'sdio_narrowed' state flag which transitions:
  0 (normal) - 1 (convert to 1-bit pending) -
  2 (have switch to 1-bit mode) - 0 (normal)
  - create a function mmc_sdio_want_no_clocks() which can be called
when the driver wants to turn off clocks (presumably after an
idle timeout).  This either succeeds (in 1-bit mode) or fails
and schedules the work to switch to 1-bit mode.
  - when the host is claimed, if sdio_narrowed is 2, restore the
4-bit bus
  - When the host is released, if sdio_narrowed is 1, then some
caller other  than our worker claimed the host first, so
clear sdio_narrowed.

 This all allows a graceful and race-free switch to 1-bit mode
 before switching off the clocks, if SDIO interrupts are enabled.

 A host should call mmc_sdio_want_no_clocks() when about to turn off
 clocks if sdio interrupts are enabled, and the -disable() function
 should not use a timeout (pm_runtime_put_autosuspend) if
 -sdio_narrowed is 2.

 Signed-off-by: NeilBrown n...@brown.name

Hi Neil,

Thanks for sending this patchset, and sorry for the delay in response.

Overall I like the approach taken in this patchset, though I have some
questions see below.

 ---
  drivers/mmc/core/core.c  |   18 ++
  drivers/mmc/core/sdio.c  |   42 +-
  include/linux/mmc/core.h |2 ++
  include/linux/mmc/host.h |2 ++
  4 files changed, 59 insertions(+), 5 deletions(-)

 diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
 index 541c8903dc6b..0258fdf1a03d 100644
 --- a/drivers/mmc/core/core.c
 +++ b/drivers/mmc/core/core.c
 @@ -921,8 +921,14 @@ int __mmc_claim_host(struct mmc_host *host, atomic_t 
 *abort)
 wake_up(host-wq);
 spin_unlock_irqrestore(host-lock, flags);
 remove_wait_queue(host-wq, wait);
 -   if (host-ops-enable  !stop  host-claim_cnt == 1)
 -   host-ops-enable(host);
 +   if (!stop  host-claim_cnt == 1) {
 +   if (host-ops-enable)
 +   host-ops-enable(host);
 +   if (atomic_read(host-sdio_narrowed) == 2) {
 +   sdio_enable_4bit_bus(host-card);
 +   atomic_set(host-sdio_narrowed, 0);
 +   }
 +   }
 return stop;
  }

 @@ -941,8 +947,12 @@ void mmc_release_host(struct mmc_host *host)

 WARN_ON(!host-claimed);

 -   if (host-ops-disable  host-claim_cnt == 1)
 -   host-ops-disable(host);
 +   if (host-claim_cnt == 1) {
 +   if (atomic_read(host-sdio_narrowed) == 1)
 +   atomic_set(host-sdio_narrowed, 0);
 +   if (host-ops-disable)
 +   host-ops-disable(host);
 +   }

As omap_hsmmc in currently the only user of the
host_ops-enable|disable() callbacks, I wonder if this approach will
work race-free for those hosts that don't implement these callbacks?

Also, I was kind of hoping that we should be able to remove these
host_ops callbacks, when omap_hsmmc has moved away from using them. Do
you think that can be done?

Within this context, I am also reviewing Adrian Hunter's patchset
around periodic re-tuning [1] and to me, you guys are sharing a
similar issue.

The host driver's runtime PM suspend callback needs to be able to
notify the mmc core to take some specific actions, and in a
race-free manner.

I wonder whether we could have one common solution to that? Do you
think this approach will work for Adrian's periodic re-tuning as
well?


 spin_lock_irqsave(host-lock, flags);
 if (--host-claim_cnt) {
 diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
 index 5bc6c7dbbd60..9761e4d5f49b 100644
 --- a/drivers/mmc/core/sdio.c
 +++ b/drivers/mmc/core/sdio.c
 @@ 

Re: [PATCH 1/4] mmc: core: fold mmc_set_bus_width calls into sdio_enable_4bit_bus.

[Ulf Hansson]

On 24 February 2015 at 03:42, NeilBrown ne...@suse.de wrote:
 Every call to sdio_enable_4bit_bus is followed (on success) but a call

/s /but / by

 to mmc_set_bus_width().

 To simplify the code, include those calls directly in
 sdio_enable_4bit_bus().

 Signed-off-by: NeilBrown n...@brown.name

Nice cleanup! Applied for next with the above minor change.

Kind regards
Uffe

 ---
  drivers/mmc/core/sdio.c |   32 
  1 file changed, 12 insertions(+), 20 deletions(-)

 diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
 index ce6cc47206b0..5bc6c7dbbd60 100644
 --- a/drivers/mmc/core/sdio.c
 +++ b/drivers/mmc/core/sdio.c
 @@ -293,19 +293,22 @@ static int sdio_enable_4bit_bus(struct mmc_card *card)
 int err;

 if (card-type == MMC_TYPE_SDIO)
 -   return sdio_enable_wide(card);
 -
 -   if ((card-host-caps  MMC_CAP_4_BIT_DATA) 
 -   (card-scr.bus_widths  SD_SCR_BUS_WIDTH_4)) {
 +   err = sdio_enable_wide(card);
 +   else if ((card-host-caps  MMC_CAP_4_BIT_DATA) 
 +(card-scr.bus_widths  SD_SCR_BUS_WIDTH_4)) {
 err = mmc_app_set_bus_width(card, MMC_BUS_WIDTH_4);
 if (err)
 return err;
 +   err = sdio_enable_wide(card);
 +   if (err = 0)
 +   mmc_app_set_bus_width(card, MMC_BUS_WIDTH_1);
 } else
 return 0;

 -   err = sdio_enable_wide(card);
 -   if (err = 0)
 -   mmc_app_set_bus_width(card, MMC_BUS_WIDTH_1);
 +   if (err  0) {
 +   mmc_set_bus_width(card-host, MMC_BUS_WIDTH_4);
 +   err = 0;
 +   }

 return err;
  }
 @@ -547,13 +550,8 @@ static int mmc_sdio_init_uhs_card(struct mmc_card *card)
 /*
  * Switch to wider bus (if supported).
  */
 -   if (card-host-caps  MMC_CAP_4_BIT_DATA) {
 +   if (card-host-caps  MMC_CAP_4_BIT_DATA)
 err = sdio_enable_4bit_bus(card);
 -   if (err  0) {
 -   mmc_set_bus_width(card-host, MMC_BUS_WIDTH_4);
 -   err = 0;
 -   }
 -   }

 /* Set the driver strength for the card */
 sdio_select_driver_type(card);
 @@ -803,9 +801,7 @@ try_again:
  * Switch to wider bus (if supported).
  */
 err = sdio_enable_4bit_bus(card);
 -   if (err  0)
 -   mmc_set_bus_width(card-host, MMC_BUS_WIDTH_4);
 -   else if (err)
 +   if (err)
 goto remove;
 }
  finish:
 @@ -983,10 +979,6 @@ static int mmc_sdio_resume(struct mmc_host *host)
 } else if (mmc_card_keep_power(host)  mmc_card_wake_sdio_irq(host)) 
 {
 /* We may have switched to 1-bit mode during suspend */
 err = sdio_enable_4bit_bus(host-card);
 -   if (err  0) {
 -   mmc_set_bus_width(host, MMC_BUS_WIDTH_4);
 -   err = 0;
 -   }
 }

 if (!err  host-sdio_irqs) {


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

Re: [PATCH 2/4] mmc: core: allow non-blocking form of mmc_claim_host

[Ulf Hansson]

On 24 February 2015 at 03:42, NeilBrown ne...@suse.de wrote:
 Change the handling for the 'abort' flag so that if
 it is set, but we can claim the host, then do the claim,
 rather than aborting.

 When the abort is async this just means that a race between aborting
 an allowing a claim is resolved slightly differently.  Any
 code must already be able to handle 'abort' being set just as the host
 is claimed.

 This allows extra functionality.  If __mmc_claim_host() is called
 with an 'abort' pointer which is initialized to '1', it will effect a
 non-blocking 'claim'.

 Signed-off-by: NeilBrown n...@brown.name
 ---
  drivers/mmc/core/core.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
 index 23f10f72e5f3..541c8903dc6b 100644
 --- a/drivers/mmc/core/core.c
 +++ b/drivers/mmc/core/core.c
 @@ -912,10 +912,11 @@ int __mmc_claim_host(struct mmc_host *host, atomic_t 
 *abort)
 spin_lock_irqsave(host-lock, flags);
 }
 set_current_state(TASK_RUNNING);
 -   if (!stop) {
 +   if (!host-claimed || host-claimer == current) {

This seems risky in that regards that it will change the behaviour for
the sdio_irq_thread(). Did you check that?

I guess we could change the sdio_irq_thread() to read it's
sdio_irq_thread_abort value before trying to claim the host?

 host-claimed = 1;
 host-claimer = current;
 host-claim_cnt += 1;
 +   stop = 0;
 } else
 wake_up(host-wq);
 spin_unlock_irqrestore(host-lock, flags);



Kind regards
Uffe
--
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

Re: [PATCH 0/5] PM / clock_ops: provide default runtime ops and cleanup users

[Ulf Hansson]

On 23 April 2015 at 10:33, Rajendra Nayak rna...@codeaurora.org wrote:
 Most users of PM clocks do the exact same thing in runtime callbacks.
 Provide default callbacks and cleanup the existing users (keystone/davinci
 /omap1/sh)

 Rajendra Nayak (5):
   PM / clock_ops: Provide default runtime ops to users
   arm: keystone: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
   arm: omap1: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
   arm: davinci: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
   drivers: sh: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS

  arch/arm/mach-davinci/pm_domain.c  | 32 +-
  arch/arm/mach-keystone/pm_domain.c | 33 +-
  arch/arm/mach-omap1/pm_bus.c   | 37 ++
  drivers/base/power/clock_ops.c | 38 ++
  drivers/sh/pm_runtime.c| 47 
 ++
  include/linux/pm_clock.h   | 10 
  6 files changed, 54 insertions(+), 143 deletions(-)

I guess you don't need more acks/reviewed by for this patchset. Still,
and also for my own reference.

Acked-by: Ulf Hansson ulf.hans...@linaro.org

Kind regards
Uffe
--
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

Re: [PATCH] mmc: core: add missing pm event in mmc_pm_notify to fix hib restore

[Ulf Hansson]

On 23 April 2015 at 12:43,  grygorii.stras...@linaro.org wrote:
 From: Grygorii Strashko grygorii.stras...@linaro.org

 The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
 as result mmc_rescan() could be scheduled and executed at
 late hibernation restore stages when MMC device is suspended
 already - which, in turn, will lead to system crash on TI dra7-evm board:

 WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 
 l3_interrupt_handler+0x258/0x374()
 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data 
 Access in User mode during Functional access

 Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify().

 Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org

Huh, that was an old bug you found. :-)

I have applied it for fixes and added the below fixes tag.

Fixes: 4c2ef25fe0b8 (mmc: fix all hangs related to mmc/sd card
insert/removal during suspend/resume)

Thanks and kind regards!
Uffe

 ---
  drivers/mmc/core/core.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
 index c296bc0..92e7671 100644
 --- a/drivers/mmc/core/core.c
 +++ b/drivers/mmc/core/core.c
 @@ -2651,6 +2651,7 @@ int mmc_pm_notify(struct notifier_block *notify_block,
 switch (mode) {
 case PM_HIBERNATION_PREPARE:
 case PM_SUSPEND_PREPARE:
 +   case PM_RESTORE_PREPARE:
 spin_lock_irqsave(host-lock, flags);
 host-rescan_disable = 1;
 spin_unlock_irqrestore(host-lock, flags);
 --
 1.9.1

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

Re: [PATCH 0/3] Introduce SET_NOIRQ_SYSTEM_SLEEP_PM_OPS and use it

[Ulf Hansson]

On 27 April 2015 at 20:24,  grygorii.stras...@linaro.org wrote:
 From: Grygorii Strashko grygorii.stras...@linaro.org

 While working on suspend-to-disk functionality on TI dra7-evm (DRA7xx SoC)
 i've found that the most common problem I have to dial with is absence
 of corresponding PM callbacks in drivers and, in particular, noirq callbacks.
 So, I've fixed one driver first
 commit 6248015d6867 ARM: omap-device: add missed callback for 
 suspend-to-disk
 but then found another one which need to be fixed too (omap_l3_noc.c).
 At this moment I decided to make my life easier and added new macro
 SET_NOIRQ_SYSTEM_SLEEP_PM_OPS using the same approach as for the existing
 SET_SYSTEM_SLEEP_PM_OPS macro.

 SET_NOIRQ_SYSTEM_SLEEP_PM_OPS: defined for CONFIG_PM_SLEEP and
 assigns -suspend_noirq, -freeze_noirq and -poweroff_noirq to the same
 function. Vice versa happens for -resume_noirq, -thaw_noirq and
 -restore_noirq.

 Further two patches reuse this newly introduced macro.

 SET_NOIRQ_SYSTEM_SLEEP_PM_OPS, defined for CONFIG_PM_SLEEP, will
 point -suspend_noirq, -freeze_noirq and -poweroff_noirq to the same
 function. Vice versa happens for -resume_noirq, -thaw_noirq and
 -restore_noirq.

 Cc: Tony Lindgren t...@atomide.com
 Cc: Nishanth Menon n...@ti.com
 Cc: Kevin Hilman khil...@linaro.org
 Cc: Santosh Shilimkar ssant...@kernel.org

 Grygorii Strashko (3):
   PM / Sleep: Add macro to define common noirq system PM callbacks
   bus: omap_l3_noc: add missed callbacks for suspend-to-disk
   ARM: omap-device: use SET_NOIRQ_SYSTEM_SLEEP_PM_OPS

  arch/arm/mach-omap2/omap_device.c |  7 ++-
  drivers/bus/omap_l3_noc.c |  4 ++--
  include/linux/pm.h| 12 
  3 files changed, 16 insertions(+), 7 deletions(-)

 --
 1.9.1


For the patchset.

Reviewed-by: Ulf Hansson ulf.hans...@linaro.org

Kind regards
Uffe
--
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

Re: [PATCH 05/13] mmc: omap_hsmmc: Support for deferred probing when requesting DMA channels

[Ulf Hansson]

On 26 May 2015 at 15:26, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 Switch to use ma_request_slave_channel_compat_reason() to request the DMA

I guess it should be dma_request_slave_... huh, that was a long name. :-)

 channels. In case of error, return the error code we received including
 -EPROBE_DEFER

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 CC: Ulf Hansson ulf.hans...@linaro.org

With the minor change above.

Acked-by: Ulf Hansson ulf.hans...@linaro.org

Kind regards
Uffe

 ---
  drivers/mmc/host/omap_hsmmc.c | 22 ++
  1 file changed, 10 insertions(+), 12 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 57bb85930f81..d252478391ee 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -2088,23 +2088,21 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 dma_cap_zero(mask);
 dma_cap_set(DMA_SLAVE, mask);

 -   host-rx_chan =
 -   dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
 -rx_req, pdev-dev, rx);
 +   host-rx_chan = dma_request_slave_channel_compat_reason(mask,
 +   omap_dma_filter_fn, rx_req, pdev-dev, 
 rx);

 -   if (!host-rx_chan) {
 +   if (IS_ERR(host-rx_chan)) {
 dev_err(mmc_dev(host-mmc), unable to obtain RX DMA engine 
 channel %u\n, rx_req);
 -   ret = -ENXIO;
 +   ret = PTR_ERR(host-rx_chan);
 goto err_irq;
 }

 -   host-tx_chan =
 -   dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
 -tx_req, pdev-dev, tx);
 +   host-tx_chan = dma_request_slave_channel_compat_reason(mask,
 +   omap_dma_filter_fn, tx_req, pdev-dev, 
 tx);

 -   if (!host-tx_chan) {
 +   if (IS_ERR(host-tx_chan)) {
 dev_err(mmc_dev(host-mmc), unable to obtain TX DMA engine 
 channel %u\n, tx_req);
 -   ret = -ENXIO;
 +   ret = PTR_ERR(host-tx_chan);
 goto err_irq;
 }

 @@ -2166,9 +2164,9 @@ err_slot_name:
 if (host-use_reg)
 omap_hsmmc_reg_put(host);
  err_irq:
 -   if (host-tx_chan)
 +   if (!IS_ERR_OR_NULL(host-tx_chan))
 dma_release_channel(host-tx_chan);
 -   if (host-rx_chan)
 +   if (!IS_ERR_OR_NULL(host-rx_chan))
 dma_release_channel(host-rx_chan);
 pm_runtime_put_sync(host-dev);
 pm_runtime_disable(host-dev);
 --
 2.3.5

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

Re: [PATCH 07/13] mmc: davinci_mmc: Support for deferred probing when requesting DMA channels

[Ulf Hansson]

On 26 May 2015 at 15:26, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 Switch to use ma_request_slave_channel_compat_reason() to request the DMA
 channels. Only fall back to pio mode if the error code returned is not
 -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 CC: Ulf Hansson ulf.hans...@linaro.org

Acked-by: Ulf Hansson ulf.hans...@linaro.org

Kind regards
Uffe

 ---
  drivers/mmc/host/davinci_mmc.c | 26 +++---
  1 file changed, 15 insertions(+), 11 deletions(-)

 diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
 index b2b3f8bbfd8c..df81e4e2f662 100644
 --- a/drivers/mmc/host/davinci_mmc.c
 +++ b/drivers/mmc/host/davinci_mmc.c
 @@ -530,20 +530,20 @@ static int __init davinci_acquire_dma_channels(struct 
 mmc_davinci_host *host)
 dma_cap_zero(mask);
 dma_cap_set(DMA_SLAVE, mask);

 -   host-dma_tx =
 -   dma_request_slave_channel_compat(mask, edma_filter_fn,
 -   host-txdma, mmc_dev(host-mmc), tx);
 -   if (!host-dma_tx) {
 +   host-dma_tx = dma_request_slave_channel_compat_reason(mask,
 +   edma_filter_fn, host-txdma,
 +   mmc_dev(host-mmc), tx);
 +   if (IS_ERR(host-dma_tx)) {
 dev_err(mmc_dev(host-mmc), Can't get dma_tx channel\n);
 -   return -ENODEV;
 +   return PTR_ERR(host-dma_tx);
 }

 -   host-dma_rx =
 -   dma_request_slave_channel_compat(mask, edma_filter_fn,
 -   host-rxdma, mmc_dev(host-mmc), rx);
 -   if (!host-dma_rx) {
 +   host-dma_rx = dma_request_slave_channel_compat_reason(mask,
 +   edma_filter_fn, host-rxdma,
 +   mmc_dev(host-mmc), rx);
 +   if (IS_ERR(host-dma_rx)) {
 dev_err(mmc_dev(host-mmc), Can't get dma_rx channel\n);
 -   r = -ENODEV;
 +   r = PTR_ERR(host-dma_rx);
 goto free_master_write;
 }

 @@ -1307,8 +1307,12 @@ static int __init davinci_mmcsd_probe(struct 
 platform_device *pdev)
 host-mmc_irq = irq;
 host-sdio_irq = platform_get_irq(pdev, 1);

 -   if (host-use_dma  davinci_acquire_dma_channels(host) != 0)
 +   if (host-use_dma) {
 +   ret = davinci_acquire_dma_channels(host);
 +   if (ret == -EPROBE_DEFER)
 +   goto out;
 host-use_dma = 0;
 +   }

 /* REVISIT:  someday, support IRQ-driven card detection.  */
 mmc-caps |= MMC_CAP_NEEDS_POLL;
 --
 2.3.5

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

Re: [PATCH 04/13] mmc: omap_hsmmc: No need to check DMA channel validity at module remove

[Ulf Hansson]

On 26 May 2015 at 15:25, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 The driver will not probe without valid DMA channels so no need to check
 if they are valid when the module is removed.

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 CC: Ulf Hansson ulf.hans...@linaro.org

Acked-by: Ulf Hansson ulf.hans...@linaro.org

Kind regards
Uffe

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

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 2cd828f42151..57bb85930f81 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -2190,10 +2190,8 @@ static int omap_hsmmc_remove(struct platform_device 
 *pdev)
 if (host-use_reg)
 omap_hsmmc_reg_put(host);

 -   if (host-tx_chan)
 -   dma_release_channel(host-tx_chan);
 -   if (host-rx_chan)
 -   dma_release_channel(host-rx_chan);
 +   dma_release_channel(host-tx_chan);
 +   dma_release_channel(host-rx_chan);

 pm_runtime_put_sync(host-dev);
 pm_runtime_disable(host-dev);
 --
 2.3.5

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

Re: [PATCH 5/5] mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq

[Ulf Hansson]

On 14 May 2015 at 01:36, Tony Lindgren t...@atomide.com wrote:
 We can now use generic wakeirq handling and remove the custom handling
 for the wake-up interrupts.

 Signed-off-by: Tony Lindgren t...@atomide.com

Rafael, if you are fine with it, please take this one through your
linux-pm tree.

Acked-by: Ulf Hansson ulf.hans...@linaro.org

Kind regards
Uffe

 ---
  drivers/mmc/host/omap_hsmmc.c | 51 
 +++
  1 file changed, 8 insertions(+), 43 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 9df2b68..5fbf4d8 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -43,6 +43,7 @@
  #include linux/regulator/consumer.h
  #include linux/pinctrl/consumer.h
  #include linux/pm_runtime.h
 +#include linux/pm_wakeirq.h
  #include linux/platform_data/hsmmc-omap.h

  /* OMAP HSMMC Host Controller Registers */
 @@ -218,7 +219,6 @@ struct omap_hsmmc_host {
 unsigned intflags;
  #define AUTO_CMD23 (1  0)/* Auto CMD23 support */
  #define HSMMC_SDIO_IRQ_ENABLED (1  1)/* SDIO irq enabled */
 -#define HSMMC_WAKE_IRQ_ENABLED (1  2)
 struct omap_hsmmc_next  next_data;
 struct  omap_hsmmc_platform_data*pdata;

 @@ -1117,22 +1117,6 @@ static irqreturn_t omap_hsmmc_irq(int irq, void 
 *dev_id)
 return IRQ_HANDLED;
  }

 -static irqreturn_t omap_hsmmc_wake_irq(int irq, void *dev_id)
 -{
 -   struct omap_hsmmc_host *host = dev_id;
 -
 -   /* cirq is level triggered, disable to avoid infinite loop */
 -   spin_lock(host-irq_lock);
 -   if (host-flags  HSMMC_WAKE_IRQ_ENABLED) {
 -   disable_irq_nosync(host-wake_irq);
 -   host-flags = ~HSMMC_WAKE_IRQ_ENABLED;
 -   }
 -   spin_unlock(host-irq_lock);
 -   pm_request_resume(host-dev); /* no use counter */
 -
 -   return IRQ_HANDLED;
 -}
 -
  static void set_sd_bus_power(struct omap_hsmmc_host *host)
  {
 unsigned long i;
 @@ -1665,7 +1649,6 @@ static void omap_hsmmc_enable_sdio_irq(struct mmc_host 
 *mmc, int enable)

  static int omap_hsmmc_configure_wake_irq(struct omap_hsmmc_host *host)
  {
 -   struct mmc_host *mmc = host-mmc;
 int ret;

 /*
 @@ -1677,11 +1660,7 @@ static int omap_hsmmc_configure_wake_irq(struct 
 omap_hsmmc_host *host)
 if (!host-dev-of_node || !host-wake_irq)
 return -ENODEV;

 -   /* Prevent auto-enabling of IRQ */
 -   irq_set_status_flags(host-wake_irq, IRQ_NOAUTOEN);
 -   ret = devm_request_irq(host-dev, host-wake_irq, omap_hsmmc_wake_irq,
 -  IRQF_TRIGGER_LOW | IRQF_ONESHOT,
 -  mmc_hostname(mmc), host);
 +   ret = dev_pm_request_wake_irq(host-dev, host-wake_irq, NULL, 0, 
 NULL);
 if (ret) {
 dev_err(mmc_dev(host-mmc), Unable to request wake IRQ\n);
 goto err;
 @@ -1718,7 +1697,7 @@ static int omap_hsmmc_configure_wake_irq(struct 
 omap_hsmmc_host *host)
 return 0;

  err_free_irq:
 -   devm_free_irq(host-dev, host-wake_irq, host);
 +   dev_pm_free_wake_irq(host-dev);
  err:
 dev_warn(host-dev, no SDIO IRQ support, falling back to polling\n);
 host-wake_irq = 0;
 @@ -2007,6 +1986,7 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 omap_hsmmc_ops.multi_io_quirk = omap_hsmmc_multi_io_quirk;
 }

 +   device_init_wakeup(pdev-dev, true);
 pm_runtime_enable(host-dev);
 pm_runtime_get_sync(host-dev);
 pm_runtime_set_autosuspend_delay(host-dev, MMC_AUTOSUSPEND_DELAY);
 @@ -2147,6 +2127,7 @@ err_slot_name:
 if (host-use_reg)
 omap_hsmmc_reg_put(host);
  err_irq:
 +   device_init_wakeup(pdev-dev, false);
 if (host-tx_chan)
 dma_release_channel(host-tx_chan);
 if (host-rx_chan)
 @@ -2178,6 +2159,7 @@ static int omap_hsmmc_remove(struct platform_device 
 *pdev)

 pm_runtime_put_sync(host-dev);
 pm_runtime_disable(host-dev);
 +   device_init_wakeup(pdev-dev, false);
 if (host-dbclk)
 clk_disable_unprepare(host-dbclk);

 @@ -2204,11 +2186,6 @@ static int omap_hsmmc_suspend(struct device *dev)
 OMAP_HSMMC_READ(host-base, HCTL)  ~SDBP);
 }

 -   /* do not wake up due to sdio irq */
 -   if ((host-mmc-caps  MMC_CAP_SDIO_IRQ) 
 -   !(host-mmc-pm_flags  MMC_PM_WAKE_SDIO_IRQ))
 -   disable_irq(host-wake_irq);
 -
 if (host-dbclk)
 clk_disable_unprepare(host-dbclk);

 @@ -2233,11 +2210,6 @@ static int omap_hsmmc_resume(struct device *dev)
 omap_hsmmc_conf_bus_power(host);

 omap_hsmmc_protect_card(host);
 -
 -   if ((host-mmc-caps  MMC_CAP_SDIO_IRQ) 
 -   !(host-mmc-pm_flags  MMC_PM_WAKE_SDIO_IRQ))
 -   enable_irq(host-wake_irq

Re: [PATCH] mmc: omap_hsmmc: Update driver to support without regulators

[Ulf Hansson]

[...]

 Hi Ulf,

 Just to clarify do you have an issue with this patch or in general
 you rather nothave !CONFIG_REGULATOR supported? If its the latter
 then wouldit be better to remove the !CONFIG_REGULATOR portion from
 this driver all together.

I don't like this patch as is, as it seems like you are replacing the
VMMC regulator that actually exist in HW by parsing a DT property.

I think mmc_of_parse_voltage() shall *only* be used when the OCR mask
(-ocr_avail) can't be fetched by using a regulator. Typically that's
when the VMMC voltage levels are managed within the mmc controller
itself.

I don't have a strong opinion on how you solve that, but I guess you
have two options.

1.
Make sure the driver can be build and used both for CONFIG_REGULATOR
and !CONFIG_REGULATOR. What you need to take care of then, is to
assign the -ocr_avail mask to a default value in the case when it
can't be fetched from a regulator. Most mmc drivers has some kind of
fall-back mechanism like this.

For those SoC where you need/can control the VMMC regulator, make sure
those enables CONFIG_REGULATOR to get the proper behaviour by
omap_hsmmc.

2.
Force omap_hsmmc to be build with CONFIG_REGULATOR.

Kind regards
Uffe
--
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

Re: [PATCH 1/1 linux-next] mmc: omap: use for_each_sg() for scatterlist parsing

[Ulf Hansson]

On 16 June 2015 at 21:15, Fabian Frederick f...@skynet.be wrote:
 See Documentation/DMA-API.txt - Part Id

 Signed-off-by: Fabian Frederick f...@skynet.be

Thanks, applied!

Kind regards
Uffe

 ---
 This is untested.

  drivers/mmc/host/omap.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

 diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
 index 68dd6c7..70dcf07 100644
 --- a/drivers/mmc/host/omap.c
 +++ b/drivers/mmc/host/omap.c
 @@ -948,6 +948,7 @@ mmc_omap_prepare_data(struct mmc_omap_host *host, struct 
 mmc_request *req)
  {
 struct mmc_data *data = req-data;
 int i, use_dma = 1, block_size;
 +   struct scatterlist *sg;
 unsigned sg_len;

 host-data = data;
 @@ -972,8 +973,8 @@ mmc_omap_prepare_data(struct mmc_omap_host *host, struct 
 mmc_request *req)
 sg_len = (data-blocks == 1) ? 1 : data-sg_len;

 /* Only do DMA for entire blocks */
 -   for (i = 0; i  sg_len; i++) {
 -   if ((data-sg[i].length % block_size) != 0) {
 +   for_each_sg(data-sg, sg, sg_len, i) {
 +   if ((sg-length % block_size) != 0) {
 use_dma = 0;
 break;
 }
 --
 2.4.2

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

Re: [PATCH 0/3] omap_hsmmc: Fix card enumeration failure on

[Ulf Hansson]

On 16 June 2015 at 12:37, Vignesh R vigne...@ti.com wrote:

 Hi,

 When using omap_hsmmc driver, if sd-card repeatedly plug unplugged
 multiple times quickly, card enumeration stops after few iterations.
 This can be easily reproduced on DRA74X EVM which uses omap_hsmmc driver.
 This patch series addresses the above problem. The first patch fixes irq
 handler to report all DTOs to mmc-core. Second patch adds handling for
 BADA, DEB and CEB interrupts. The last patch introduces driver specific
 card detect irq handler to cleanup pending requests before card removal.

 Tested on DRA74X amd DRA72X and AM437X-GP EVMs, by repeated intense
 plug/unplug iterations.


 Kishon Vijay Abraham I (1):
   mmc: host: omap_hsmmc: Fix DTO and DCRC handling

 Vignesh R (2):
   mmc: host: omap_hsmmc: Handle BADA, DEB and CEB interrupts
   mmc: host: omap_hsmmc: Add custom card detect irq handler

  drivers/mmc/host/omap_hsmmc.c | 84 ---
  1 file changed, 78 insertions(+), 6 deletions(-)

 --
 2.4.1


I have applied patch1 and patch 2 for fixes. Regarding patch 3, let's
give Andreas some more time to comment.

Thanks and sorry for the delay!

Kind regards
Uffe
--
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

Re: [PATCH] mmc: omap_hsmmc: Update driver to support without regulators

[Ulf Hansson]

On 14 July 2015 at 21:29, Franklin S Cooper Jr fcoo...@ti.com wrote:
 From: Roger Quadros rog...@ti.com

 Update driver to support without regulators.

 Without this patch boards that do not enable regulator config options will
 fail to boot with a kernel panic.

I guess that's because the rootfs is mounted on the card that doesn't
get detected, right?


 Signed-off-by: Roger Quadros rog...@ti.com
 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 Signed-off-by: Franklin S Cooper Jr fcoo...@ti.com
 ---
  Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt |  2 ++
  drivers/mmc/host/omap_hsmmc.c   | 14 ++
  2 files changed, 12 insertions(+), 4 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
 b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 index 76bf087..2408e87 100644
 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 @@ -22,6 +22,8 @@ ti,dual-volt: boolean, supports dual voltage cards
  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
 +voltage-ranges: Specify the voltage range supported if regulator framework
 +isn't enabled.
  dmas: List of DMA specifiers with the controller specific format
  as described in the generic DMA client binding. A tx and rx
  specifier is required.
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index b2b411d..16c870f 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -1551,10 +1551,13 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc, 
 struct mmc_ios *ios)
 if (ios-power_mode != host-power_mode) {
 switch (ios-power_mode) {
 case MMC_POWER_OFF:
 -   mmc_pdata(host)-set_power(host-dev, 0, 0);
 +   if (host-use_reg)
 +   mmc_pdata(host)-set_power(host-dev, 0, 0);
 break;
 case MMC_POWER_UP:
 -   mmc_pdata(host)-set_power(host-dev, 1, ios-vdd);
 +   if (host-use_reg)
 +   mmc_pdata(host)-set_power(host-dev, 1,
 +  ios-vdd);
 break;
 case MMC_POWER_ON:
 do_send_init_stream = 1;
 @@ -2082,10 +2085,13 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 if (ret)
 goto err_irq;
 host-use_reg = 1;
 +   mmc-ocr_avail = mmc_pdata(host)-ocr_mask;
 +   } else {
 +   ret = mmc_of_parse_voltage(pdev-dev.of_node, 
 mmc-ocr_avail);
 +   if (ret)
 +   goto err_irq;
 }

 -   mmc-ocr_avail = mmc_pdata(host)-ocr_mask;
 -
 omap_hsmmc_disable_irq(host);

 /*
 --
 1.9.1

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

No, I don't like this patch. If your board have regulators which can
be used to find out the voltage levels, we shall use them. We shall
not use DT to workaround this.

So, perhaps the Kconfig section for omap_hsmmc should select
CONFIG_REGULATOR (and friends)?

Kind regards
Uffe
--
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

Re: [PATCH v2 07/11] mmc: host: omap_hsmmc: add tuning support

[Ulf Hansson]

On 25 August 2015 at 11:05, Kishon Vijay Abraham I kis...@ti.com wrote:
 From: Balaji T K balaj...@ti.com

 MMC tuning procedure is required to support SD card
 UHS1-SDR104 mode and EMMC HS200 mode.

 The tuning function omap_execute_tuning() will only
 be called by the MMC/SD core if the corresponding
 speed modes are supported by the OMAP silicon which
 is set in the mmc host caps field.

 Signed-off-by: Balaji T K balaj...@ti.com
 Signed-off-by: Viswanath Puttagunta vi...@ti.com
 Signed-off-by: Sourav Poddar sourav.pod...@ti.com
 [kis...@ti.com : cleanup the tuning sequence]
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
  drivers/mmc/host/omap_hsmmc.c |  234 
 -
  1 file changed, 232 insertions(+), 2 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index c042b91..43485c3 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -18,6 +18,7 @@
  #include linux/module.h
  #include linux/init.h
  #include linux/kernel.h
 +#include linux/slab.h
  #include linux/debugfs.h
  #include linux/dmaengine.h
  #include linux/seq_file.h
 @@ -49,6 +50,7 @@
  /* OMAP HSMMC Host Controller Registers */
  #define OMAP_HSMMC_SYSSTATUS   0x0014
  #define OMAP_HSMMC_CON 0x002C
 +#define OMAP_HSMMC_DLL 0x0034
  #define OMAP_HSMMC_SDMASA  0x0100
  #define OMAP_HSMMC_BLK 0x0104
  #define OMAP_HSMMC_ARG 0x0108
 @@ -66,6 +68,7 @@
  #define OMAP_HSMMC_ISE 0x0138
  #define OMAP_HSMMC_AC120x013C
  #define OMAP_HSMMC_CAPA0x0140
 +#define OMAP_HSMMC_CAPA2   0x0144

  #define VS18   (1  26)
  #define VS30   (1  25)
 @@ -114,6 +117,7 @@

  /* AC12 */
  #define AC12_V1V8_SIGEN(1  19)
 +#define AC12_SCLK_SEL  (1  23)
  #define AC12_UHSMC_MASK(7  16)
  #define AC12_UHSMC_SDR12   (0  16)
  #define AC12_UHSMC_SDR25   (1  16)
 @@ -122,6 +126,18 @@
  #define AC12_UHSMC_DDR50   (4  16)
  #define AC12_UHSMC_RES (0x7  16)

 +/* DLL */
 +#define DLL_SWT(1  20)
 +#define DLL_FORCE_SR_C_SHIFT   13
 +#define DLL_FORCE_SR_C_MASK0x7f
 +#define DLL_FORCE_VALUE(1  12)
 +#define DLL_CALIB  (1  1)
 +
 +#define MAX_PHASE_DELAY0x7c
 +
 +/* CAPA2 */
 +#define CAPA2_TSDR50   (1  13)
 +
  /* Interrupt masks for IE and ISE register */
  #define CC_EN  (1  0)
  #define TC_EN  (1  1)
 @@ -202,6 +218,7 @@ struct omap_hsmmc_host {
 int vqmmc_enabled;
 resource_size_t mapbase;
 spinlock_t  irq_lock; /* Prevent races with irq handler */
 +   struct completion   buf_ready;
 unsigned intdma_len;
 unsigned intdma_sg_idx;
 unsigned char   bus_mode;
 @@ -229,6 +246,9 @@ struct omap_hsmmc_host {
 struct omap_hsmmc_next  next_data;
 struct  omap_hsmmc_platform_data*pdata;

 +   u32 *tuning_data;
 +   int tuning_size;
 +
 /* return MMC cover switch state, can be NULL if not supported.
  *
  * possible return values:
 @@ -245,8 +265,39 @@ struct omap_mmc_of_data {
 u8 controller_flags;
  };

 +static const u8 ref_tuning_4bits[] = {
 +   0xff, 0x0f, 0xff, 0x00, 0xff, 0xcc, 0xc3, 0xcc,
 +   0xc3, 0x3c, 0xcc, 0xff, 0xfe, 0xff, 0xfe, 0xef,
 +   0xff, 0xdf, 0xff, 0xdd, 0xff, 0xfb, 0xff, 0xfb,
 +   0xbf, 0xff, 0x7f, 0xff, 0x77, 0xf7, 0xbd, 0xef,
 +   0xff, 0xf0, 0xff, 0xf0, 0x0f, 0xfc, 0xcc, 0x3c,
 +   0xcc, 0x33, 0xcc, 0xcf, 0xff, 0xef, 0xff, 0xee,
 +   0xff, 0xfd, 0xff, 0xfd, 0xdf, 0xff, 0xbf, 0xff,
 +   0xbb, 0xff, 0xf7, 0xff, 0xf7, 0x7f, 0x7b, 0xde,
 +};
 +
 +static const u8 ref_tuning_8bits[] = {
 +   0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00, 0x00,
 +   0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc, 0xcc,
 +   0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff, 0xff,
 +   0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee, 0xff,
 +   0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd, 0xdd,
 +   0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff, 0xbb,
 +   0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff, 0xff,
 +   0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee, 0xff,
 +   0xff, 0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00,
 +   0x00, 0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc,
 +   0xcc, 0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff,
 +   0xff, 0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee,
 +   0xff, 0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd,
 +   0xdd, 0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff,
 +   0xbb, 0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff,
 +   0xff, 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee,
 +};

These bit patterns already exists in the mmc core as a part of the
mmc_send_tuning() API.

 +
  static void 

Re: [PATCH v2 16/16] mmc: host: omap_hsmmc: use mmc_of_parse_voltage to get ocr_avail

[Ulf Hansson]

On 3 August 2015 at 14:26, Kishon Vijay Abraham I kis...@ti.com wrote:
 From: Roger Quadros rog...@ti.com

 For platforms that doesn't have explicit regulator control in MMC,
 populate voltage-ranges in MMC device tree node and use
 mmc_of_parse_voltage to get ocr_avail

I don't like this.

If we are able to fetch the OCR mask via an external regulator, that
shall be done.

I think the mmc_of_parse_voltage() API and the corresponding DT
binding it parses, should be used for those HW when we don't have an
external regulator to use. For example if the MMC controller itself
somehow controls the voltage levels. Is that really the case for you?

Kind regards
Uffe


 Signed-off-by: Roger Quadros rog...@ti.com
 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 Signed-off-by: Franklin S Cooper Jr fcoo...@ti.com
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |2 ++
  drivers/mmc/host/omap_hsmmc.c  |9 -
  2 files changed, 10 insertions(+), 1 deletion(-)

 diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
 b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 index 76bf087..2408e87 100644
 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 @@ -22,6 +22,8 @@ ti,dual-volt: boolean, supports dual voltage cards
  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
 +voltage-ranges: Specify the voltage range supported if regulator framework
 +isn't enabled.
  dmas: List of DMA specifiers with the controller specific format
  as described in the generic DMA client binding. A tx and rx
  specifier is required.
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 15973f1..d884d8f 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -2184,7 +2184,13 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 goto err_irq;
 }

 -   mmc-ocr_avail = mmc_pdata(host)-ocr_mask;
 +   if (!mmc_pdata(host)-ocr_mask) {
 +   ret = mmc_of_parse_voltage(pdev-dev.of_node, 
 mmc-ocr_avail);
 +   if (ret)
 +   goto err_parse_voltage;
 +   } else {
 +   mmc-ocr_avail = mmc_pdata(host)-ocr_mask;
 +   }

 omap_hsmmc_disable_irq(host);

 @@ -2224,6 +2230,7 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)

  err_slot_name:
 mmc_remove_host(mmc);
 +err_parse_voltage:
 omap_hsmmc_reg_put(host);
  err_irq:
 device_init_wakeup(pdev-dev, false);
 --
 1.7.9.5

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

Re: [PATCH 01/11] mmc: omap: fix error return code

[Ulf Hansson]

On 23 August 2015 at 02:11, Julia Lawall julia.law...@lip6.fr wrote:
 Return a negative error code on failure.

 A simplified version of the semantic match that finds this problem is as
 follows: (http://coccinelle.lip6.fr/)

 // smpl
 @@
 identifier ret; expression e1,e2;
 @@
 (
 if (\(ret  0\|ret != 0\))
  { ... return ret; }
 |
 ret = 0
 )
 ... when != ret = e1
 when != ret
 *if(...)
 {
   ... when != ret = e2
   when forall
  return ret;
 }
 // /smpl

 Signed-off-by: Julia Lawall julia.law...@lip6.fr

Thanks, applied for next!

Kind regards
Uffe


 ---
  drivers/mmc/host/omap.c |4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
 index 70dcf07..b763b11 100644
 --- a/drivers/mmc/host/omap.c
 +++ b/drivers/mmc/host/omap.c
 @@ -1420,8 +1420,10 @@ static int mmc_omap_probe(struct platform_device *pdev)
 host-reg_shift = (mmc_omap7xx() ? 1 : 2);

 host-mmc_omap_wq = alloc_workqueue(mmc_omap, 0, 0);
 -   if (!host-mmc_omap_wq)
 +   if (!host-mmc_omap_wq) {
 +   ret = -ENOMEM;
 goto err_plat_cleanup;
 +   }

 for (i = 0; i  pdata-nr_slots; i++) {
 ret = mmc_omap_new_slot(host, i);

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

Re: [PATCH v2 16/16] mmc: host: omap_hsmmc: use "mmc_of_parse_voltage" to get ocr_avail

[Ulf Hansson]

On 11 November 2015 at 11:26, Roger Quadros <rog...@ti.com> wrote:
> Hi,
>
> On 25/08/15 17:50, Ulf Hansson wrote:
>> On 3 August 2015 at 14:26, Kishon Vijay Abraham I <kis...@ti.com> wrote:
>>> From: Roger Quadros <rog...@ti.com>
>>>
>>> For platforms that doesn't have explicit regulator control in MMC,
>>> populate voltage-ranges in MMC device tree node and use
>>> mmc_of_parse_voltage to get ocr_avail
>>
>> I don't like this.
>>
>> If we are able to fetch the OCR mask via an external regulator, that
>> shall be done.
>
> Agreed.
>>
>> I think the mmc_of_parse_voltage() API and the corresponding DT
>> binding it parses, should be used for those HW when we don't have an
>> external regulator to use. For example if the MMC controller itself
>> somehow controls the voltage levels. Is that really the case for you?
>
> What shall be done if there is no software control of the external regulator
> and it is fixed at a certain voltage?

I think you can model that as a so called fixed regulator.

Kind regards
Uffe
--
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

Re: All OMAP platforms: MMC is broken

[Ulf Hansson]

On 7 October 2015 at 17:52, Tony Lindgren <t...@atomide.com> wrote:
> * Ulf Hansson <ulf.hans...@linaro.org> [151007 06:46]:
>> On 7 October 2015 at 15:26, Tony Lindgren <t...@atomide.com> wrote:
>> >> > Good idea, how about something like the following? AFAIK that's the
>> >> > only .config option needed as MFD_SYSCON is selected by Kconfig
>> >> > already.
>>
>> Similar to MFD_SYSCON, why don't we have REGULATOR_PBIAS to be
>> selected when omap_hsmmc is being used?
>>
>> It seems like that should also be a patch for the rc, right!?
>
> Well selecting CONFIG_REGULATOR is still optional and force selecting
> drivers usually leads into randconfig build issues sooner or later.
> And we'd like to make everything into loadable modules eventually.

I am not sure I get your point. Perhaps I was too vague in what I suggested.

Unless we express the dependencies via Kconfig files (or perhaps via
updated defconfigs), how do you expect build/boot automated tools to
handle this?

*People* can of course manually poll a README to learn about new
dependencies for each new kernel version, but me personally would
prefer if don't have to.

>
> We could print a warning during MMC1 probe if REGULATOR_PBIAS
> is not selected and attempt to continue probing?

No thanks, it would sprinkle drivers with ugly code :-). I would also
expect that we would get warnings even when we shouldn't, especially
as a cross SoC/board driver may have different dependencies.

To me REGULATOR_PBIAS is a dependency required by a certain SoC/board
when MMC_OMAP_HS is selected. Isn't such dependency easiest dealt with
from SoC/board Kconfig files? Llike for example in the OMAP2 case,
arch/arm/mach-omap2/Kconfig.

Kind regards
Uffe
--
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

Re: All OMAP platforms: MMC is broken

[Ulf Hansson]

On 7 October 2015 at 15:26, Tony Lindgren  wrote:
> * Russell King - ARM Linux  [151007 05:50]:
>> On Tue, Oct 06, 2015 at 08:37:11AM -0700, Tony Lindgren wrote:
>> > * Russell King - ARM Linux  [151006 08:04]:
>> > > On Tue, Oct 06, 2015 at 02:44:25AM -0700, Tony Lindgren wrote:
>> > > >
>> > > > Hmm DT-based boot finds the MMC card for LDP, dmesg below from DT boot 
>> > > > [1].
>> > > > Looks like you're on on -rc4 and not -rc3. My guess is that MMC is not
>> > > > working for you with DT-based booting because you don't seem to have
>> > > > CONFIG_REGULATOR_PBIAS in your seed config for. Care to try enabling 
>> > > > that
>> > > > for both your omap3 and omap4 seed config files?
>> > >
>> > > This is precisely the kind of crap I'm objecting to.  New kernel versions
>> > > come along, and things break because people add extra Kconfig symbols 
>> > > that
>> > > previous versions did not rely upon - and there's no communication of
>> > > what's required for new kernel versions.
>> > >
>> > > This stuff needs documenting, so that people are aware what changes they
>> > > need to make - please put something in Documentation/arm/OMAP which
>> > > tracks what new additions are required to the Kconfig to keep things
>> > > working.
>> >
>> > Good idea, how about something like the following? AFAIK that's the
>> > only .config option needed as MFD_SYSCON is selected by Kconfig
>> > already.

Similar to MFD_SYSCON, why don't we have REGULATOR_PBIAS to be
selected when omap_hsmmc is being used?

It seems like that should also be a patch for the rc, right!?

>>
>> Right, that resolves the issue.  Now, what's the story on the revert
>> and the other patch - have they already been taken for -rc kernels?

Great!

>
> Not yet, I was waiting for the confirmation from you. I've now posted the
> revert with proper description and the fix so Ulf can pick them up and
> merged as regression fixes for the -rc series:

I am on it!

>
> http://marc.info/?l=linux-omap=144422416621373=2
> http://marc.info/?l=linux-omap=144422416921375=2

Russell, may I add your tested by tag for these?

Again, thanks!

Kind regards
Uffe
--
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

Re: [PATCH 1/2] Revert "mmc: host: omap_hsmmc: use regulator_is_enabled to find pbias status"

[Ulf Hansson]

On 7 October 2015 at 15:22, Tony Lindgren  wrote:
> This reverts commit c55d7a0553643a7e8f120688b82b594471084d3c.
>
> Without reverting this commit we get "unbalanced disables for pbias_mmc_omap4"
> errors on omap4430. It seems that 4430 and 4460 behave in a different way for
> the PBIAS regulator registers and until that has been debugged further we
> cannot rely on the regulator status registers in hardare on 4430.
>
> Fixes: 7d607f917008 ("mmc: host: omap_hsmmc: use
> devm_regulator_get_optional() for vmmc")
> Cc: Felipe Balbi 
> Cc: Kishon Vijay Abraham I 
> Cc: Nishanth Menon 
> Cc: Russell King 
> Signed-off-by: Tony Lindgren 

Thanks, applied for fixes!

Kind regards
Uffe

> ---
>  drivers/mmc/host/omap_hsmmc.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 781e4db3..ae3a2b9 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -182,6 +182,7 @@ struct omap_hsmmc_host {
> struct  clk *fclk;
> struct  clk *dbclk;
> struct  regulator   *pbias;
> +   boolpbias_enabled;
> void__iomem *base;
> int vqmmc_enabled;
> resource_size_t mapbase;
> @@ -328,20 +329,22 @@ static int omap_hsmmc_set_pbias(struct omap_hsmmc_host 
> *host, bool power_on,
> return ret;
> }
>
> -   if (!regulator_is_enabled(host->pbias)) {
> +   if (host->pbias_enabled == 0) {
> ret = regulator_enable(host->pbias);
> if (ret) {
> dev_err(host->dev, "pbias reg enable fail\n");
> return ret;
> }
> +   host->pbias_enabled = 1;
> }
> } else {
> -   if (regulator_is_enabled(host->pbias)) {
> +   if (host->pbias_enabled == 1) {
> ret = regulator_disable(host->pbias);
> if (ret) {
> dev_err(host->dev, "pbias reg disable 
> fail\n");
> return ret;
> }
> +   host->pbias_enabled = 0;
> }
> }
>
> @@ -2053,6 +2056,7 @@ static int omap_hsmmc_probe(struct platform_device 
> *pdev)
> host->base  = base + pdata->reg_offset;
> host->power_mode = MMC_POWER_OFF;
> host->next_data.cookie = 1;
> +   host->pbias_enabled = 0;
> host->vqmmc_enabled = 0;
>
> ret = omap_hsmmc_gpio_init(mmc, host, pdata);
> --
> 2.1.4
>
--
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

Re: [PATCH 2/2] mmc: host: omap_hsmmc: Fix MMC for omap3 legacy booting

[Ulf Hansson]

On 7 October 2015 at 15:22, Tony Lindgren  wrote:
> Starting with commit 7d607f917008 ("mmc: host: omap_hsmmc: use
> devm_regulator_get_optional() for vmmc") MMC on omap3 stopped working
> for legacy booting.
>
> This is because legacy booting sets up some of the resource in the
> platform init code, and for optional regulators always seem to
> return -EPROBE_DEFER for the legacy booting.
>
> Let's fix the issue by checking for device tree based booting for
> now. Then when omap3 boots in device tree only mode, this patch
> can be just reverted.
>
> Fixes: 7d607f917008 ("mmc: host: omap_hsmmc: use
> devm_regulator_get_optional() for vmmc")
> Cc: Felipe Balbi 
> Cc: Kishon Vijay Abraham I 
> Cc: Nishanth Menon 
> Cc: Russell King 
> Signed-off-by: Tony Lindgren 

Thanks, applied for fixes!

Kind regards
Uffe

> ---
>  drivers/mmc/host/omap_hsmmc.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index ae3a2b9..7fb0753 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -478,7 +478,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
> *host)
> mmc->supply.vmmc = devm_regulator_get_optional(host->dev, "vmmc");
> if (IS_ERR(mmc->supply.vmmc)) {
> ret = PTR_ERR(mmc->supply.vmmc);
> -   if (ret != -ENODEV)
> +   if ((ret != -ENODEV) && host->dev->of_node)
> return ret;
> dev_dbg(host->dev, "unable to get vmmc regulator %ld\n",
> PTR_ERR(mmc->supply.vmmc));
> @@ -493,7 +493,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
> *host)
> mmc->supply.vqmmc = devm_regulator_get_optional(host->dev, 
> "vmmc_aux");
> if (IS_ERR(mmc->supply.vqmmc)) {
> ret = PTR_ERR(mmc->supply.vqmmc);
> -   if (ret != -ENODEV)
> +   if ((ret != -ENODEV) && host->dev->of_node)
> return ret;
> dev_dbg(host->dev, "unable to get vmmc_aux regulator %ld\n",
> PTR_ERR(mmc->supply.vqmmc));
> @@ -503,7 +503,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
> *host)
> host->pbias = devm_regulator_get_optional(host->dev, "pbias");
> if (IS_ERR(host->pbias)) {
> ret = PTR_ERR(host->pbias);
> -   if (ret != -ENODEV)
> +   if ((ret != -ENODEV) && host->dev->of_node)
> return ret;
> dev_dbg(host->dev, "unable to get pbias regulator %ld\n",
> PTR_ERR(host->pbias));
> --
> 2.1.4
>
--
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

Re: All OMAP platforms: MMC is broken

[Ulf Hansson]

On 6 October 2015 at 11:44, Tony Lindgren  wrote:
> * Russell King - ARM Linux  [151006 02:04]:
>> On Mon, Oct 05, 2015 at 07:38:13PM +0100, Russell King - ARM Linux wrote:
>> > On Mon, Oct 05, 2015 at 10:11:56AM -0700, Tony Lindgren wrote:
>> > > * Tony Lindgren  [151005 07:57]:
>> > > > * Tony Lindgren  [151005 07:44]:
>> > > > > * Tony Lindgren  [151005 04:28]:
>> > > > >
>> > > > > Based on some tests it seems that the duovero unpaired regulator 
>> > > > > usage
>> > > > > is fixed by reverting:
>> > > > >
>> > > > > c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to
>> > > > > find pbias status")
>> > > >
>> > > > With commit c55d7a055364 my guess is that the PBIAS regulator is
>> > > > already on from an earlier MMC probe and getting re-enabled when
>> > > > a deferred probe happens?
>> > >
>> > > Unless somebody has a better fix in mind for the above, I suggest
>> > > we revert it for the -rc kernel.
>> >
>> > Let me try reverting that in my build tree, and...
>> >
>> > > > > And it seems that omap3 legacy MMC is broken earlier in the
>> > > > > series with:
>> > > > >
>> > > > > 7d607f917008 ("mmc: host: omap_hsmmc: use
>> > > > > devm_regulator_get_optional() for vmmc")
>> > > > >
>> > > > > This one does not cleanly revert so have not yet tried reverting
>> > > > > it.
>> > > >
>> > > > And with commit 7d607f917008 I'm guessing we can't return an
>> > > > error if the PBIAS regulator does not exist as that's not there
>> > > > for the legacy booting.
>> > >
>> > > For omap3 legacy booting, we keep getting -EPROBE_DEFER for
>> > > all the optional regulators.
>> > >
>> > > Something like the following might be the minimal fix for the -rc
>> > > cycle?
>> >
>> > applying this patch.  If that gets things going again, then we
>> > _definitely_ should get both of these to Linus ASAP.  The breakage
>> > has been around far too long already.
>>
>> Last night's build shows that this fixes the non-DT LDP3430 booting, but
>> DT-based LDP3430 and SDP4430 both remain broken for the same reason -
>> neither can find their SD cards.
>
> Hmm DT-based boot finds the MMC card for LDP, dmesg below from DT boot [1].
> Looks like you're on on -rc4 and not -rc3. My guess is that MMC is not
> working for you with DT-based booting because you don't seem to have
> CONFIG_REGULATOR_PBIAS in your seed config for. Care to try enabling that
> for both your omap3 and omap4 seed config files?
>
>> We're at -rc4.  That means we're could be only three weeks away from 4.3
>> being released, and DT OMAP has yet to boot _once_ here.
>>
>> What I find *totally* unacceptable is the lack of reaction from the MMC
>> and TI people: it's just like "we'll break your crap, and we'll ignore
>> reports of regressions."  That is *not* acceptable in any shape or form,
>> and people who do this _should_ have their future patches ignored until
>> they demonstrate that they understand the need to not break stuff.
>>
>> I'm at the point of suggesting that there should be a moritorium on all
>> OMAP related development for 4.4: delay all development to 4.5, and have
>> 4.4 as a pure bug-fixing _only_ cycle for OMAP.  If 4.3 is released and
>> OMAP is still broken, then I don't think there's an option on that.
>>
>> Maybe the idea that development work won't hit mainline for another 4
>> months will help focus the minds on not breaking stuff and then ignoring
>> regression reports.
>
> I'm thinking along the same lines. In general, I do not and will not
> apply any patches that are not fixes until all critical regressions are
> out of the way. So not applying anything new for v4.4 until these MMC
> regressions are fixed for v4.3.
>

Tony, Russell - just wanted to say thanks for putting a big effort in
fixing this. I was expecting support from Kishon, but I guess he's
busy.

Unfortunate, I don't have any of the hardware that fails, otherwise I
would of course be helping out more. The only thing I can think of is
to revert the entire patchset I picked up for 4.3 from Kishon for the
omap_hsmmc driver, but then I am not sure if that would cause other
issues...

Kind regards
Uffe
--
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

Re: [PATCH v3 13/15] mmc: host: omap_hsmmc: use regulator_is_enabled to find pbias status

[Ulf Hansson]

On 27 August 2015 at 14:47, Kishon Vijay Abraham I kis...@ti.com wrote:
 Hi Uffe,

 On Thursday 27 August 2015 06:12 PM, Ulf Hansson wrote:
 On 27 August 2015 at 14:41, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 27 August 2015 at 11:14, Kishon Vijay Abraham I kis...@ti.com wrote:
 Use regulator_is_enabled of pbias regulator to find pbias regulator
 status instead of maintaining a custom bookkeeping
 pbias_enabled variable.

 Doesn't this cause a problem for the scenario when the initial state
 of the regulator is enabled?

 Patch 11 of this series mmc: host: omap_hsmmc: don't use -set_power to
 set initial regulator state disables the pbias regulator if the initial
 state of the regulator is enabled.


Got it, thanks!

[...]

Kind regards
Uffe
--
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

Re: [PATCH v3 13/15] mmc: host: omap_hsmmc: use regulator_is_enabled to find pbias status

[Ulf Hansson]

On 27 August 2015 at 14:41, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 27 August 2015 at 11:14, Kishon Vijay Abraham I kis...@ti.com wrote:
 Use regulator_is_enabled of pbias regulator to find pbias regulator
 status instead of maintaining a custom bookkeeping
 pbias_enabled variable.

 Doesn't this cause a problem for the scenario when the initial state
 of the regulator is enabled?

 Both in the sense that you will increase the enable count for it

/s/will/won't

 (potentially it may then become disabled when you need it enabled) but
 also from a enable/disable imbalance point of view.

 Kind regards
 Uffe


 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 Tested-by: Tony Lindgren t...@atomide.com
 ---
  drivers/mmc/host/omap_hsmmc.c |8 ++--
  1 file changed, 2 insertions(+), 6 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 5a5946a..4cd7a58 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -182,7 +182,6 @@ struct omap_hsmmc_host {
 struct  clk *fclk;
 struct  clk *dbclk;
 struct  regulator   *pbias;
 -   boolpbias_enabled;
 void__iomem *base;
 int vqmmc_enabled;
 resource_size_t mapbase;
 @@ -330,22 +329,20 @@ static int omap_hsmmc_set_pbias(struct omap_hsmmc_host 
 *host, bool power_on,
 return ret;
 }

 -   if (host-pbias_enabled == 0) {
 +   if (!regulator_is_enabled(host-pbias)) {
 ret = regulator_enable(host-pbias);
 if (ret) {
 dev_err(host-dev, pbias reg enable 
 fail\n);
 return ret;
 }
 -   host-pbias_enabled = 1;
 }
 } else {
 -   if (host-pbias_enabled == 1) {
 +   if (regulator_is_enabled(host-pbias)) {
 ret = regulator_disable(host-pbias);
 if (ret) {
 dev_err(host-dev, pbias reg disable 
 fail\n);
 return ret;
 }
 -   host-pbias_enabled = 0;
 }
 }

 @@ -2081,7 +2078,6 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 host-base  = base + pdata-reg_offset;
 host-power_mode = MMC_POWER_OFF;
 host-next_data.cookie = 1;
 -   host-pbias_enabled = 0;
 host-vqmmc_enabled = 0;

 ret = omap_hsmmc_gpio_init(mmc, host, pdata);
 --
 1.7.9.5

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

Re: [PATCH v3 00/15] omap_hsmmc: regulator usage cleanup and fixes

[Ulf Hansson]

On 27 August 2015 at 11:13, Kishon Vijay Abraham I kis...@ti.com wrote:
 This patch series does the following
 *) Uses devm_regulator_get_optional() for vmmc and then removes the
CONFIG_REGULATOR check altogether.
 *) return on -EPROBE_DEFER and any other fatal errors
 *) enable/disable vmmc_aux regulator based on prior state

 Changes from v2:
 *) rebased to mmc -next branch
 *) dropped using mmc_of_parse_voltage to get ocr_avail patch.

 Changes from v1:
 *) return on -EPROBE_DEFER and other fatal errors. (Don't return only
if the return value is -ENODEV)
 *) Remove the beagle x15 dts patch. It can be part of a different
series.
 *) Avoid using regulator_is_enabled for vqmmc since if the regulator
is shared and the other users are not using regulator_is_enabled
then there can be unbalanced regulator_enable/regulator_disable

 I've pushed this patch series to
 git://git.ti.com/linux-phy/linux-phy.git mmc_for-next

 Please note the branch also has the pbias fixes [1].
 [1] - https://lkml.org/lkml/2015/7/27/358

 This series is in preparation for implementing the voltage switch
 sequence so that UHS cards can be supported.

 Did basic read/write test in J6, J6 Eco, Beagle-x15, AM437x EVM,
 Beaglebone black, OMAP5 uEVM, OMAP4 PANDA and OMAP3gle xm.

 Kishon Vijay Abraham I (15):
   mmc: host: omap_hsmmc: use devm_regulator_get_optional() for vmmc
   mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get
   mmc: host: omap_hsmmc: cleanup omap_hsmmc_reg_get()
   mmc: host: omap_hsmmc: use the ocrmask provided by the vmmc regulator
   mmc: host: omap_hsmmc: use mmc_host's vmmc and vqmmc
   mmc: host: omap_hsmmc: remove unnecessary pbias set_voltage
   mmc: host: omap_hsmmc: return error if any of the regulator APIs fail
   mmc: host: omap_hsmmc: add separate functions for enable/disable
 supply
   mmc: host: omap_hsmmc: add separate function to set pbias
   mmc: host: omap_hsmmc: avoid pbias regulator enable on power off
   mmc: host: omap_hsmmc: don't use -set_power to set initial regulator
 state
   mmc: host: omap_hsmmc: enable/disable vmmc_aux regulator based on
 previous state
   mmc: host: omap_hsmmc: use regulator_is_enabled to find pbias status
   mmc: host: omap_hsmmc: use ios-vdd for setting vmmc voltage
   mmc: host: omap_hsmmc: remove CONFIG_REGULATOR check

  drivers/mmc/host/omap_hsmmc.c |  326 
 +++--
  1 file changed, 212 insertions(+), 114 deletions(-)

 --
 1.7.9.5


Thanks, applied for next!

Kind regards
Uffe
--
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

Re: [PATCH v3 13/15] mmc: host: omap_hsmmc: use regulator_is_enabled to find pbias status

[Ulf Hansson]

On 27 August 2015 at 11:14, Kishon Vijay Abraham I kis...@ti.com wrote:
 Use regulator_is_enabled of pbias regulator to find pbias regulator
 status instead of maintaining a custom bookkeeping
 pbias_enabled variable.

Doesn't this cause a problem for the scenario when the initial state
of the regulator is enabled?

Both in the sense that you will increase the enable count for it
(potentially it may then become disabled when you need it enabled) but
also from a enable/disable imbalance point of view.

Kind regards
Uffe


 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 Tested-by: Tony Lindgren t...@atomide.com
 ---
  drivers/mmc/host/omap_hsmmc.c |8 ++--
  1 file changed, 2 insertions(+), 6 deletions(-)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 5a5946a..4cd7a58 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -182,7 +182,6 @@ struct omap_hsmmc_host {
 struct  clk *fclk;
 struct  clk *dbclk;
 struct  regulator   *pbias;
 -   boolpbias_enabled;
 void__iomem *base;
 int vqmmc_enabled;
 resource_size_t mapbase;
 @@ -330,22 +329,20 @@ static int omap_hsmmc_set_pbias(struct omap_hsmmc_host 
 *host, bool power_on,
 return ret;
 }

 -   if (host-pbias_enabled == 0) {
 +   if (!regulator_is_enabled(host-pbias)) {
 ret = regulator_enable(host-pbias);
 if (ret) {
 dev_err(host-dev, pbias reg enable fail\n);
 return ret;
 }
 -   host-pbias_enabled = 1;
 }
 } else {
 -   if (host-pbias_enabled == 1) {
 +   if (regulator_is_enabled(host-pbias)) {
 ret = regulator_disable(host-pbias);
 if (ret) {
 dev_err(host-dev, pbias reg disable 
 fail\n);
 return ret;
 }
 -   host-pbias_enabled = 0;
 }
 }

 @@ -2081,7 +2078,6 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 host-base  = base + pdata-reg_offset;
 host-power_mode = MMC_POWER_OFF;
 host-next_data.cookie = 1;
 -   host-pbias_enabled = 0;
 host-vqmmc_enabled = 0;

 ret = omap_hsmmc_gpio_init(mmc, host, pdata);
 --
 1.7.9.5

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

Re: [PATCH v3 0/2] regulator: Fix pbias regulator enable

[Ulf Hansson]

On 4 September 2015 at 14:00, Kishon Vijay Abraham I  wrote:
> vsel_reg and enable_reg of the pbias regulator descriptor should actually
> have the offset from syscon.
>
> However after
> "ARM: dts: : add minimal l4 bus layout with control module
> support"
> vsel_reg and enable_reg started to have the absolute address because
> of address translation that happens due to pbias node made as the
> child node of syscon. This breaks the pbias regulator enable.
>
> This series adds the 'offset' to be populated in vsel_reg and enable_reg
> in the pbias driver itself.
>
> Changes from v2:
> *) Squashed all the dt patches into a single patch
>
> Changes from v1:
> *) Fixed Tony's review comments on adding a 'comment' for adding offset in
>the driver and adding a warning for using platform_get_resource.
> *) Added Tony's Acked-by.
>
> Tested these patches against mmc -next in omap4 panda, omap3 beagle xm,
> dra72 and omap5 uevm
>
> Kishon Vijay Abraham I (2):
>   regulator: pbias: program pbias register offset in pbias driver
>   ARM: dts: : use "ti,pbias-" compatible
> string for pbias
>
>  .../bindings/regulator/pbias-regulator.txt |7 ++-
>  arch/arm/boot/dts/dra7.dtsi|2 +-
>  arch/arm/boot/dts/omap2430.dtsi|2 +-
>  arch/arm/boot/dts/omap3.dtsi   |2 +-
>  arch/arm/boot/dts/omap4.dtsi   |2 +-
>  arch/arm/boot/dts/omap5.dtsi   |2 +-
>  drivers/regulator/pbias-regulator.c|   56 
> +---
>  7 files changed, 61 insertions(+), 12 deletions(-)
>
> --
> 1.7.9.5
>

Okay, just to be clear on the way forward. I spoked with Mark Brown
offlist, and he will/has picked up the regulator patch and will send
it as fix for the 4.3 rc[n].

Regarding the ARM patch here, I guess Tony might as well handle it and
send through arm-soc, especially since the regression won't be fixed
within my mmc tree anyway.

So, I am going to leave my next branch as is - and thus relying on
that the regression for OMAP will be fixed in some the 4.3 rc[n].

Kind regards
Uffe
--
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

Re: [PATCH v2 0/6] regulator: Fix pbias regulator enable

[Ulf Hansson]

+Olof

On 3 September 2015 at 08:50, Kishon Vijay Abraham I  wrote:
> vsel_reg and enable_reg of the pbias regulator descriptor should actually
> have the offset from syscon.
>
> However after
> "ARM: dts: : add minimal l4 bus layout with control module
> support"
> vsel_reg and enable_reg started to have the absolute address because
> of address translation that happens due to pbias node made as the
> child node of syscon. This breaks the pbias regulator enable.
>
> This series adds the 'offset' to be populated in vsel_reg and enable_reg
> in the pbias driver itself.
>
> Changes from v1:
> *) Fixed Tony's review comments on adding a 'comment' for adding offset in
>the driver and adding a warning for using platform_get_resource.
> *) Added Tony's Acked-by.
>
> Tested these patches against mmc -next in omap4 panda, omap3 beagle xm,
> dra72 and omap5 uevm
>
> Kishon Vijay Abraham I (6):
>   regulator: pbias: program pbias register offset in pbias driver
>   ARM: dts: dra7: use "ti,pbias-dra7" compatible string for pbias
>   ARM: dts: omap243x: use "ti,pbias-omap2" compatible string for pbias
>   ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias
>   ARM: dts: omap4: use "ti,pbias-omap4" compatible string for pbias
>   ARM: dts: omap5: use "ti,pbias-omap5" compatible string for pbias
>
>  .../bindings/regulator/pbias-regulator.txt |7 ++-
>  arch/arm/boot/dts/dra7.dtsi|2 +-
>  arch/arm/boot/dts/omap2430.dtsi|2 +-
>  arch/arm/boot/dts/omap3.dtsi   |2 +-
>  arch/arm/boot/dts/omap4.dtsi   |2 +-
>  arch/arm/boot/dts/omap5.dtsi   |2 +-
>  drivers/regulator/pbias-regulator.c|   56 
> +---
>  7 files changed, 61 insertions(+), 12 deletions(-)
>
> --
> 1.7.9.5
>

I have recently queued another patchset [1] for the mmc omap driver
for 4.3 through my mmc tree for which Olof Johansson reported a
regression [2] for Panda ES with multi_v7_defconfig.

Kishon, could you please clarify if $subject patchset solves that
regression reported by Olof? Or perhaps Olof can run a test?

Finally, perhaps it's better if we queue this through my mmc tree
since we would then be able to avoid the regression - if I put
$subject patchset before [1], right? Then I need an ack from Mark for
the regulator patch.
Please tell me if you guys prefer another way.

Kind regards
Uffe

[1]
http://permalink.gmane.org/gmane.linux.kernel/2027789

[2]
http://www.spinics.net/lists/linux-mmc/msg33146.html
--
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

Re: [PATCH v2 00/16] omap_hsmmc: regulator usage cleanup and fixes

[Ulf Hansson]

On 3 August 2015 at 14:26, Kishon Vijay Abraham I kis...@ti.com wrote:
 Changes from v1:
 *) return on -EPROBE_DEFER and other fatal errors. (Don't return only
if the return value is -ENODEV)
 *) Remove the beagle x15 dts patch. It can be part of a different
series.
 *) Avoid using regulator_is_enabled for vqmmc since if the regulator
is shared and the other users are not using regulator_is_enabled
then there can be unbalanced regulator_enable/regulator_disable

 This patch series does the following
 *) Uses devm_regulator_get_optional() for vmmc and then removes the
CONFIG_REGULATOR check altogether.
 *) return on -EPROBE_DEFER and any other fatal errors
 *) enable/disable vmmc_aux regulator based on prior state

 I've pushed this patch series to
 git://git.ti.com/linux-phy/linux-phy.git mmc_regulator_cleanup_fixes_v2

 Please note the branch also has the pbias fixes [1]  [2].
 [1] - https://lkml.org/lkml/2015/7/27/358
 [2] - https://lkml.org/lkml/2015/7/27/391

 This series is in preparation for implementing the voltage switch
 sequence so that UHS cards can be supported.

 Did basic read/write test in J6, J6 Eco, Beagle-x15, AM437x EVM,
 Beaglebone black, OMAP5 uEVM and OMAP4 PANDA.

 Kishon Vijay Abraham I (15):
   mmc: host: omap_hsmmc: use devm_regulator_get_optional() for vmmc
   mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get
   mmc: host: omap_hsmmc: cleanup omap_hsmmc_reg_get()
   mmc: host: omap_hsmmc: use the ocrmask provided by the vmmc regulator
   mmc: host: omap_hsmmc: use mmc_host's vmmc and vqmmc
   mmc: host: omap_hsmmc: remove unnecessary pbias set_voltage
   mmc: host: omap_hsmmc: return error if any of the regulator APIs fail
   mmc: host: omap_hsmmc: add separate functions for enable/disable
 supply
   mmc: host: omap_hsmmc: add separate function to set pbias
   mmc: host: omap_hsmmc: avoid pbias regulator enable on power off
   mmc: host: omap_hsmmc: don't use -set_power to set initial regulator
 state
   mmc: host: omap_hsmmc: enable/disable vmmc_aux regulator based on
 previous state
   mmc: host: omap_hsmmc: use regulator_is_enabled to find pbias status
   mmc: host: omap_hsmmc: use ios-vdd for setting vmmc voltage
   mmc: host: omap_hsmmc: remove CONFIG_REGULATOR check

 Roger Quadros (1):
   mmc: host: omap_hsmmc: use mmc_of_parse_voltage to get ocr_avail

  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |2 +
  drivers/mmc/host/omap_hsmmc.c  |  340 
 +---
  2 files changed, 224 insertions(+), 118 deletions(-)

 --
 1.7.9.5


I tried to apply this on top of my next branch, but it didn't work.
Could you please rebase and send a v3!?
While you do that, please add Tony's tested-by tag as well.

Kind regards
Uffe
--
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

Re: [PATCH v9 0/4] Allow USB devices to remain runtime-suspended when sleeping

[Ulf Hansson]

On 5 October 2015 at 16:45, Tomeu Vizoso <tomeu.viz...@collabora.com> wrote:
> Hi,
>
> this is v9 of an attempt to make it easier for devices to remain in
> runtime PM when the system goes to sleep, mainly to reduce the time
> spent resuming devices.
>
> For this, we interpret the absence of all PM callback implementations as
> it being safe to do direct_complete, so their ancestors aren't prevented
> from remaining runtime-suspended.
>
> Additionally, the prepare() callback of USB devices will return 1 if
> runtime PM is enabled and the current wakeup settings are correct.
>
> With these changes, a uvcvideo device (for example) stays in runtime
> suspend when the system goes to sleep and is left in that state when the
> system resumes, not delaying it unnecessarily.
>
> Thanks,
>
> Tomeu
>
> Changes in v9:
> - Add docs noting the need for the device lock to be held before calling
>   device_is_bound()
> - Add docs noting the need for the device lock to be held before calling
>   dev_pm_domain_set()
> - Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf.
> - Rename from device_check_pm_callbacks to device_pm_check_callbacks to
>   follow with the naming convention of existing API.
> - Re-add calling to device_pm_check_callbacks from device registration
>   and when updating the PM domain of a device.
>
> Changes in v8:
> - Add device_is_bound()
> - Add dev_pm_domain_set() and update code to use it
> - Move no_pm_callbacks field into CONFIG_PM_SLEEP
> - Call device_check_pm_callbacks only after a device is bound or unbound
>
> Changes in v7:
> - Reduce indentation by adding a label in device_prepare()
>
> Changes in v6:
> - Add stub for !CONFIG_PM.
> - Move implementation of device_check_pm_callbacks to power/main.c as it
>   doesn't belong to CONFIG_PM_SLEEP.
> - Take dev->power.lock before modifying flag.
>
> Changes in v5:
> - Check for all dev_pm_ops instances associated to a device, updating a
>   no_pm_callbacks flag at the times when that could change.
>
> Tomeu Vizoso (4):
>   device core: add device_is_bound()
>   PM / Domains: add setter for dev.pm_domain
>   PM / sleep: Go direct_complete if driver has no callbacks
>   USB / PM: Allow USB devices to remain runtime-suspended when sleeping
>
>  arch/arm/mach-omap2/omap_device.c |  7 ---
>  drivers/acpi/acpi_lpss.c  |  5 +++--
>  drivers/acpi/device_pm.c  |  5 +++--
>  drivers/base/dd.c | 21 +++--
>  drivers/base/power/clock_ops.c|  5 +++--
>  drivers/base/power/common.c   | 24 
>  drivers/base/power/domain.c   |  6 --
>  drivers/base/power/main.c | 35 +++
>  drivers/base/power/power.h|  3 +++
>  drivers/gpu/vga/vga_switcheroo.c  | 10 +-
>  drivers/misc/mei/pci-me.c |  5 +++--
>  drivers/misc/mei/pci-txe.c|  5 +++--
>  drivers/usb/core/port.c   |  6 ++
>  drivers/usb/core/usb.c| 11 ++-
>  include/linux/device.h|  2 ++
>  include/linux/pm.h|  1 +
>  include/linux/pm_domain.h |  3 +++
>  17 files changed, 131 insertions(+), 23 deletions(-)
>
> --
> 2.4.3
>

This looks good to me, for the series you may add:

Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org>

Kind regards
Uffe
--
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

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Ulf Hansson]

On 8 December 2015 at 01:32, Tony Lindgren <t...@atomide.com> wrote:
> * Ulf Hansson <ulf.hans...@linaro.org> [151207 16:20]:
>> +Linus
>>
>> On 7 December 2015 at 23:54, Tony Lindgren <t...@atomide.com> wrote:
>> > Commit ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array API")
>> > changed the handling MMC power sequence so GPIOs no longer are optional.
>> >
>> > This broke SDIO WLAN at least for omap5 that can't yet use the reset GPIOs
>> > with pwrseq_simple as a wait is needed after enabling the SDIO device.
>>
>> Can you elaborate on this. Did it break omap5 or not? :-)
>
> Yes it broke WLAN for omap5 that I just got fixed.. It only uses the clocks
> art of the pwrseq currently because of the delay needed.
>
>> Also, I am interested to know more about the waiting period you need.
>> I assume that's because of the HW's characteristic?
>
> At least TI wl12xx and Marvell 8787 need a delay after enabling the the WLAN.
>
>> Why can't we have that being described in DT and then make
>> pwrseq_simple *wait* if needed?
>
> We can, but I'm thinking that we might be better off adding support for
> regulators to pwrseq. Both TI wl12xx and Marvell 8787 get power from the
> battery, and probably have an integrated regulator.

Sounds very reasonable! Perhaps some of the delays can be handled
within the context of the regulator then!?

>
> Also, the delay and the power up sequencey can be more complicated than what
> we currently support. In the 8787 case, pdn pin needs to be asserted for 300ms
> after power pins are stable and while reset is held high.

I am for sure open to extend pwrseq_simple, please go ahead!

The initial version provided a proof of concept and the
infrastructure. I expect and want people to extend it to suit their
HWs.

If we at some point find that pwrseq_simple starts to become too
complex, we may add another pwrseq type with a corresponding new
compatible string.

[...]

Kind regards
Uffe
--
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

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Ulf Hansson]

+Linus

On 7 December 2015 at 23:54, Tony Lindgren  wrote:
> Commit ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array API")
> changed the handling MMC power sequence so GPIOs no longer are optional.
>
> This broke SDIO WLAN at least for omap5 that can't yet use the reset GPIOs
> with pwrseq_simple as a wait is needed after enabling the SDIO device.

Can you elaborate on this. Did it break omap5 or not? :-)

Also, I am interested to know more about the waiting period you need.
I assume that's because of the HW's characteristic?

Why can't we have that being described in DT and then make
pwrseq_simple *wait* if needed?

>
> Let's fix the problem by allocating the GPIO values array during init
> depending on the optional GPIOs found.

Certainly it shall be optional! I wonder how I could let that patch
slip through, my bad!

Thanks for fixing this!

>
> Note that depending on the board specific configuration, some of the GPIOs
> can be permanently set up with pulls, so we want to keep pwrseq_simple
> GPIOs optional.
>
> Cc: Javier Martinez Canillas 
> Signed-off-by: Tony Lindgren 
> ---
>  drivers/mmc/core/pwrseq_simple.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
>
> --- a/drivers/mmc/core/pwrseq_simple.c
> +++ b/drivers/mmc/core/pwrseq_simple.c
> @@ -24,6 +24,7 @@ struct mmc_pwrseq_simple {
> bool clk_enabled;
> struct clk *ext_clk;
> struct gpio_descs *reset_gpios;
> +   int *values;
>  };
>
>  static void mmc_pwrseq_simple_set_gpios_value(struct mmc_pwrseq_simple 
> *pwrseq,
> @@ -31,13 +32,15 @@ static void mmc_pwrseq_simple_set_gpios_value(struct 
> mmc_pwrseq_simple *pwrseq,
>  {
> int i;
> struct gpio_descs *reset_gpios = pwrseq->reset_gpios;
> -   int values[reset_gpios->ndescs];

I would prefer if we don't need to keep this memory on the heap.

Can't we instead keep a local copy of the reset_gpios->ndesc and when
pwrseq->reset_gpios doesn't exist use a default value?

> +
> +   if (!reset_gpios || !reset_gpios->ndescs)
> +   return;
>
> for (i = 0; i < reset_gpios->ndescs; i++)
> -   values[i] = value;
> +   pwrseq->values[i] = value;
>
> gpiod_set_array_value_cansleep(reset_gpios->ndescs, reset_gpios->desc,
> -  values);
> +  pwrseq->values);
>  }
>
>  static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
> @@ -84,6 +87,7 @@ static void mmc_pwrseq_simple_free(struct mmc_host *host)
> if (!IS_ERR(pwrseq->ext_clk))
> clk_put(pwrseq->ext_clk);
>
> +   kfree(pwrseq->values);
> kfree(pwrseq);
>  }
>
> @@ -111,12 +115,20 @@ struct mmc_pwrseq *mmc_pwrseq_simple_alloc(struct 
> mmc_host *host,
> goto free;
> }
>
> -   pwrseq->reset_gpios = gpiod_get_array(dev, "reset", GPIOD_OUT_HIGH);
> +   pwrseq->reset_gpios = gpiod_get_array_optional(dev, "reset",
> +  GPIOD_OUT_HIGH);
> if (IS_ERR(pwrseq->reset_gpios)) {

The original code also considered -ENOSYS, as that's the return code
you get when CONFIG_GPIOLIB is unset, I think we need that as well.

Although, perhaps it's more correct that the gpiolib API returns NULL
instead of ERR_PTR(-ENOSYS)?

I have added Linus, to see if he has any comments on this.

> ret = PTR_ERR(pwrseq->reset_gpios);
> goto clk_put;
> }
>
> +   if (pwrseq->reset_gpios && pwrseq->reset_gpios->ndescs) {
> +   pwrseq->values = kzalloc(pwrseq->reset_gpios->ndescs *
> +sizeof(int), GFP_KERNEL);
> +   if (!pwrseq->values)
> +   goto clk_put;

This will leak a gpio cookie as it needs a gpiod_put_array().

> +   }
> +
> pwrseq->pwrseq.ops = _pwrseq_simple_ops;
>
> return >pwrseq;
> --
> 2.6.2
>

One final comment, gpiod_put_array() doesn't deal with NULL pointers.
You need to check that in mmc_pwrseq_simple_free().

Kind regards
Uffe
--
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

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Ulf Hansson]

On 18 December 2015 at 17:14, Tony Lindgren <t...@atomide.com> wrote:
> * Ulf Hansson <ulf.hans...@linaro.org> [151207 16:20]:
>> +Linus
>>
>> On 7 December 2015 at 23:54, Tony Lindgren <t...@atomide.com> wrote:
>> > Commit ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array API")
>> > changed the handling MMC power sequence so GPIOs no longer are optional.
>> >
>> > This broke SDIO WLAN at least for omap5 that can't yet use the reset GPIOs
>> > with pwrseq_simple as a wait is needed after enabling the SDIO device.
>>
>> Can you elaborate on this. Did it break omap5 or not? :-)
>
> Ulf, is this patch queued for v4.4 as a regression fix? I don't see it
> in Linux next or mainline trees?

Ohh, I guess there where some misunderstanding. I made a bunch of
comments on your patch as well, so I have been expecting a new
version.

Sorry if that was unclear!

Kind regards
Uffe
--
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

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Ulf Hansson]

On 18 December 2015 at 23:31, Tony Lindgren <t...@atomide.com> wrote:
> * Ulf Hansson <ulf.hans...@linaro.org> [151218 14:20]:
>> On 18 December 2015 at 17:14, Tony Lindgren <t...@atomide.com> wrote:
>> > * Ulf Hansson <ulf.hans...@linaro.org> [151207 16:20]:
>> >> +Linus
>> >>
>> >> On 7 December 2015 at 23:54, Tony Lindgren <t...@atomide.com> wrote:
>> >> > Commit ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array 
>> >> > API")
>> >> > changed the handling MMC power sequence so GPIOs no longer are optional.
>> >> >
>> >> > This broke SDIO WLAN at least for omap5 that can't yet use the reset 
>> >> > GPIOs
>> >> > with pwrseq_simple as a wait is needed after enabling the SDIO device.
>> >>
>> >> Can you elaborate on this. Did it break omap5 or not? :-)
>> >
>> > Ulf, is this patch queued for v4.4 as a regression fix? I don't see it
>> > in Linux next or mainline trees?
>>
>> Ohh, I guess there where some misunderstanding. I made a bunch of
>> comments on your patch as well, so I have been expecting a new
>> version.
>
> Well this $subject patch was intended as a regression fix for v4.4-rc cycle.
> All the other things discussed are not fixes but new features instead.
>
>> Sorry if that was unclear!
>
> I think this patch should be still fine as is, care to take a look again?

No, the patch have issues that needs to be fixed.
http://www.spinics.net/lists/linux-mmc/msg34399.html

Kind regards
Uffe
--
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

Re: [PATCH] mmc: omap_hsmmc: No need to check DMA channel validity at module remove

[Ulf Hansson]

On 3 November 2015 at 12:37, Peter Ujfalusi <peter.ujfal...@ti.com> wrote:
> The driver will not probe without valid DMA channels so no need to check
> if they are valid when the module is removed.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
> CC: Ulf Hansson <ulf.hans...@linaro.org>

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/omap_hsmmc.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index f70e52b05648..712c74fd0401 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2262,10 +2262,8 @@ static int omap_hsmmc_remove(struct platform_device 
> *pdev)
> pm_runtime_get_sync(host->dev);
> mmc_remove_host(host->mmc);
>
> -   if (host->tx_chan)
> -   dma_release_channel(host->tx_chan);
> -   if (host->rx_chan)
> -   dma_release_channel(host->rx_chan);
> +   dma_release_channel(host->tx_chan);
> +   dma_release_channel(host->rx_chan);
>
> pm_runtime_put_sync(host->dev);
> pm_runtime_disable(host->dev);
> --
> 2.6.2
>
--
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