date:20140523

On multicores, an sdio irq handler could be running in parallel to
runtime suspend. In the worst case it could be waiting for the spinlock
held by the runtime suspend. When runtime suspend is complete and the
functional clock (fclk) turned off, the irq handler will continue and
cause a SIGBUS on the first register access.

Acked-by: Balaji T K balaj...@ti.com
Signed-off-by: Andreas Fenkart afenk...@gmail.com

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index dfc593e..aafef29 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -107,6 +107,9 @@
 #define SRD(1  26)
 #define SOFTRESET  (1  1)
 
+/* PSTATE */
+#define DLEV_DAT(x)(1  (20 + (x)))
+
 /* Interrupt masks for IE and ISE register */
 #define CC_EN  (1  0)
 #define TC_EN  (1  1)
@@ -2432,6 +2435,7 @@ static int omap_hsmmc_runtime_suspend(struct device *dev)
 {
struct omap_hsmmc_host *host;
unsigned long flags;
+   int ret = 0;
 
host = platform_get_drvdata(to_platform_device(dev));
omap_hsmmc_context_save(host);
@@ -2443,14 +2447,29 @@ static int omap_hsmmc_runtime_suspend(struct device 
*dev)
/* disable sdio irq handling to prevent race */
OMAP_HSMMC_WRITE(host-base, ISE, 0);
OMAP_HSMMC_WRITE(host-base, IE, 0);
-   OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+
+   if (!(OMAP_HSMMC_READ(host-base, PSTATE)  DLEV_DAT(1))) {
+   /*
+* dat1 line low, pending sdio irq
+* race condition: possible irq handler running on
+* multi-core, abort
+*/
+   dev_dbg(dev, pending sdio irq, abort suspend\n);
+   OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+   OMAP_HSMMC_WRITE(host-base, ISE, CIRQ_EN);
+   OMAP_HSMMC_WRITE(host-base, IE, CIRQ_EN);
+   pm_runtime_mark_last_busy(dev);
+   ret = -EBUSY;
+   goto abort;
+   }
 
WARN_ON(host-flags  HSMMC_WAKE_IRQ_ENABLED);
enable_irq(host-wake_irq);
host-flags |= HSMMC_WAKE_IRQ_ENABLED;
}
+abort:
spin_unlock_irqrestore(host-irq_lock, flags);
-   return 0;
+   return ret;
 }
 
 static int omap_hsmmc_runtime_resume(struct device *dev)
-- 
1.7.10.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

[PATCH v13 3/7] mmc: omap_hsmmc: Extend debugfs by SDIO IRQ handling, runtime state

Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending

Acked-by: Balaji T K balaj...@ti.com
Signed-off-by: Andreas Fenkart afenk...@gmail.com

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0125eea..cfd2bfb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -56,6 +56,7 @@
 #define OMAP_HSMMC_RSP54   0x0118
 #define OMAP_HSMMC_RSP76   0x011C
 #define OMAP_HSMMC_DATA0x0120
+#define OMAP_HSMMC_PSTATE  0x0124
 #define OMAP_HSMMC_HCTL0x0128
 #define OMAP_HSMMC_SYSCTL  0x012C
 #define OMAP_HSMMC_STAT0x0130
@@ -1816,10 +1817,23 @@ static int omap_hsmmc_regs_show(struct seq_file *s, 
void *data)
 {
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+#ifdef CONFIG_PM
+   bool suspended;
+#endif
 
seq_printf(s, mmc%d:\n, mmc-index);
+   seq_printf(s, sdio irq mode\t%s\n,
+  (mmc-caps  MMC_CAP_SDIO_IRQ) ? interrupt : polling);
+
+   if (mmc-caps  MMC_CAP_SDIO_IRQ) {
+   seq_printf(s, sdio irq \t%s\n,
+  (host-flags  HSMMC_SDIO_IRQ_ENABLED) ?  enabled
+  : disabled);
+   }
 
 #ifdef CONFIG_PM
+   suspended = host-dev-power.runtime_status != RPM_ACTIVE;
+   seq_printf(s, runtime state\t%s\n, (suspended ? idle : active));
seq_printf(s, ctx_loss:\t%d\n, host-context_loss);
 #endif
 
@@ -1827,6 +1841,8 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void 
*data)
seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
+   seq_printf(s, PSTATE:\t\t0x%08x\n,
+  OMAP_HSMMC_READ(host-base, PSTATE));
seq_printf(s, HCTL:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, HCTL));
seq_printf(s, SYSCTL:\t\t0x%08x\n,
-- 
1.7.10.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

[PATCH v13 4/7] mmc: omap_hsmmc: enable wakeup event for sdio OMAP4

To detect sdio irqs properly without spurious events,
OMAP4 needs IWE in CON and CTPL, CLKEXTFREE in HCTL to be set

Tested-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Balaji T K balaj...@ti.com

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index cfd2bfb..dfc593e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -94,7 +94,10 @@
 #define BCE(1  1)
 #define FOUR_BIT   (1  1)
 #define HSPE   (1  2)
+#define IWE(1  24)
 #define DDR(1  19)
+#define CLKEXTFREE (1  16)
+#define CTPL   (1  11)
 #define DW8(1  5)
 #define OD 0x1
 #define STAT_CLEAR 0x
@@ -689,6 +692,9 @@ static int omap_hsmmc_context_restore(struct 
omap_hsmmc_host *host)
capa = VS18;
}
 
+   if (host-mmc-caps  MMC_CAP_SDIO_IRQ)
+   hctl |= IWE;
+
OMAP_HSMMC_WRITE(host-base, HCTL,
OMAP_HSMMC_READ(host-base, HCTL) | hctl);
 
@@ -1681,19 +1687,23 @@ static void omap_hsmmc_init_card(struct mmc_host *mmc, 
struct mmc_card *card)
 static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
 {
struct omap_hsmmc_host *host = mmc_priv(mmc);
-   u32 irq_mask;
+   u32 irq_mask, con;
unsigned long flags;
 
spin_lock_irqsave(host-irq_lock, flags);
 
+   con = OMAP_HSMMC_READ(host-base, CON);
irq_mask = OMAP_HSMMC_READ(host-base, ISE);
if (enable) {
host-flags |= HSMMC_SDIO_IRQ_ENABLED;
irq_mask |= CIRQ_EN;
+   con |= CTPL | CLKEXTFREE;
} else {
host-flags = ~HSMMC_SDIO_IRQ_ENABLED;
irq_mask = ~CIRQ_EN;
+   con = ~(CTPL | CLKEXTFREE);
}
+   OMAP_HSMMC_WRITE(host-base, CON, con);
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
 
/*
@@ -1744,6 +1754,8 @@ static int omap_hsmmc_configure_wake_irq(struct 
omap_hsmmc_host *host)
goto err;
}
 
+   OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL) | IWE);
return 0;
 
 err:
-- 
1.7.10.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

[PATCH v13 7/7] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x

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. Code contributions from
Tony Lindgren and Balaji T K balaj...@ti.com

Acked-by: Balaji T K balaj...@ti.com
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 0233ba7..76bf087 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -57,3 +57,56 @@ Examples:
edma 25;
dma-names = tx, rx;
};
+
+[workaround for missing swakeup on am33xx]
+
+This SOC is missing the swakeup line, it will not detect SDIO irq
+while in suspend.
+
+ --
+ | PRCM |
+  --
+   ^ |
+   swakeup | | fclk
+   | v
+   -----   -
+  | card | -- CIRQ --  | hsmmc | -- IRQ --  | CPU |
+   -----   -
+
+In suspend the fclk is off and the module is disfunctional. Even register reads
+will fail. A small logic in the host will request fclk restore, when an
+external event is detected. Once the clock is restored, the host detects the
+event normally. Since am33xx doesn't have this line it never wakes from
+suspend.
+
+The workaround is to reconfigure the dat1 line as a GPIO upon suspend. To make
+this work, we need to set the named pinctrl states default and idle.
+Prepare idle to remux dat1 as a gpio, and default to remux it back as sdio
+dat1. The MMC driver will then toggle between idle and default state during
+runtime.
+
+In summary:
+1. select matching 'compatible' section, see example below.
+2. specify pinctrl states default and idle, sleep is optional.
+3. specify the gpio irq used for detecting sdio irq in suspend
+
+If configuration is incomplete, a warning message is emitted falling back to
+polling. Also check the sdio irq mode in /sys/kernel/debug/mmc0/regs. Mind
+not every application needs SDIO irq, e.g. MMC cards.
+
+   mmc1: mmc@48060100 {
+   compatible = ti,am33xx-hsmmc;
+   ...
+   pinctrl-names = default, idle, sleep
+   pinctrl-0 = mmc1_pins;
+   pinctrl-1 = mmc1_idle;
+   pinctrl-2 = mmc1_sleep;
+   ...
+   interrupts-extended = intc 64 gpio2 28 0;
+   };
+
+   mmc1_idle : pinmux_cirq_pin {
+   pinctrl-single,pins = 
+   0x0f8 0x3f  /* GPIO2_28 */
+   ;
+   };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 760b0ac..1238506 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1752,15 +1752,25 @@ static int omap_hsmmc_configure_wake_irq(struct 
omap_hsmmc_host *host)
 * and need to remux SDIO DAT1 to GPIO for wake-up from idle.
 */
if (host-pdata-controller_flags  OMAP_HSMMC_SWAKEUP_MISSING) {
-   ret = -ENODEV;
-   devm_free_irq(host-dev, host-wake_irq, host);
-   goto err;
+   if (IS_ERR(host-dev-pins-default_state)) {
+   dev_info(host-dev, missing default pinctrl state\n);
+   ret = -EINVAL;
+   goto err_free_irq;
+   }
+
+   if (IS_ERR(host-dev-pins-idle_state)) {
+   dev_info(host-dev, missing idle pinctrl state\n);
+   ret = -EINVAL;
+   goto err_free_irq;
+   }
}
 
OMAP_HSMMC_WRITE(host-base, HCTL,
 OMAP_HSMMC_READ(host-base, HCTL) | IWE);
return 0;
 
+err_free_irq:
+   devm_free_irq(host-dev, host-wake_irq, host);
 err:
dev_warn(host-dev, no SDIO IRQ support, falling back to polling\n);
host-wake_irq = 0;
-- 
1.7.10.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

[PATCH v13 2/7] mmc: omap_hsmmc: Enable SDIO interrupt

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

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

Acked-by: Balaji T K balaj...@ti.com
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ce80561..0233ba7 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -12,6 +12,7 @@ Required properties:
  Should be ti,omap3-hsmmc, for OMAP3 controllers
  Should be ti,omap3-pre-es3-hsmmc for OMAP3 controllers pre ES3.0
  Should be ti,omap4-hsmmc, for OMAP4 controllers
+ Should be ti,am33xx-hsmmc, for AM335x controllers
 - ti,hwmods: Must be mmcn, n is controller instance starting 1
 
 Optional properties:
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index c62d9dd..0125eea 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
@@ -200,6 +202,7 @@ struct omap_hsmmc_host {
int slot_id;
int response_busy;
 #ifdef CONFIG_PM
+   int wake_irq;
int context_loss;
 #endif
int protect_card;
@@ -208,6 +211,9 @@ struct omap_hsmmc_host {
int req_in_progress;
unsigned long   clk_rate;
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_mmc_platform_data  *pdata;
 };
@@ -512,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
-   irq_mask = INT_EN_MASK;
+   irq_mask = ~(BRR_EN | BWR_EN);
 
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
 
+   spin_lock_irqsave(host-irq_lock, flags);

[PATCH v13 1/7] mmc: omap_hsmmc: install dummy pm runtime hooks if !CONFIG_PM_RUNTIME

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

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 272e0ee..c62d9dd 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -199,7 +199,9 @@ struct omap_hsmmc_host {
struct dma_chan *rx_chan;
int slot_id;
int response_busy;
+#ifdef CONFIG_PM
int context_loss;
+#endif
int protect_card;
int reqs_blocked;
int use_reg;
@@ -712,14 +714,8 @@ static void omap_hsmmc_context_save(struct omap_hsmmc_host 
*host)
 
 #else
 
-static int omap_hsmmc_context_restore(struct omap_hsmmc_host *host)
-{
-   return 0;
-}
-
-static void omap_hsmmc_context_save(struct omap_hsmmc_host *host)
-{
-}
+#define omap_hsmmc_context_restore(host)
+#define omap_hsmmc_context_save(host)
 
 #endif
 
@@ -1700,11 +1696,14 @@ static int omap_hsmmc_regs_show(struct seq_file *s, 
void *data)
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
 
-   seq_printf(s, mmc%d:\n ctx_loss:\t%d\n\nregs:\n,
-   mmc-index, host-context_loss);
+   seq_printf(s, mmc%d:\n, mmc-index);
 
-   pm_runtime_get_sync(host-dev);
+#ifdef CONFIG_PM
+   seq_printf(s, ctx_loss:\t%d\n, host-context_loss);
+#endif
 
+   pm_runtime_get_sync(host-dev);
+   seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
seq_printf(s, HCTL:\t\t0x%08x\n,
@@ -2243,6 +2242,7 @@ static int omap_hsmmc_resume(struct device *dev)
 #define omap_hsmmc_resume  NULL
 #endif
 
+#ifdef CONFIG_PM_RUNTIME
 static int omap_hsmmc_runtime_suspend(struct device *dev)
 {
struct omap_hsmmc_host *host;
@@ -2264,6 +2264,10 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
 
return 0;
 }
+#else
+#define omap_hsmmc_runtime_suspend NULL
+#define omap_hsmmc_runtime_resume  NULL
+#endif
 
 static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.suspend= omap_hsmmc_suspend,
-- 
1.7.10.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

[PATCH v13 0/7] mmc: omap_hsmmc: Enable SDIO IRQ

Hi Balaji, Tony, Ulf, all

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 (7):
  mmc: omap_hsmmc: install dummy pm runtime hooks if !CONFIG_PM_RUNTIME
  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  |  309 ++--
 include/linux/platform_data/mmc-omap.h |1 +
 3 files changed, 335 insertions(+), 29 deletions(-)

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

[PATCH v13 6/7] mmc: omap_hsmmc: switch default/idle pinctrl states in runtime hooks

These are predefined states of the driver model. When not present,
as if not set in the device tree, they become no-ops.
Explicitly selecting the default state is not needed since the
device core layer sets pin mux to default state before probe.
This is not the simplest implementation, on AM335x at least, we could
switch to idle at any point in the suspend hook, only the default state
needs to be set before writing to the irq registers or an IRQ might get
lost.

Acked-by: Balaji T K balaj...@ti.com
Signed-off-by: Andreas Fenkart afenk...@gmail.com

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index aafef29..760b0ac 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2008,7 +2008,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
const struct of_device_id *match;
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
-   struct pinctrl *pinctrl;
const struct omap_mmc_of_data *data;
 
match = of_match_device(of_match_ptr(omap_mmc_of_match), pdev-dev);
@@ -2234,11 +2233,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
 
omap_hsmmc_disable_irq(host);
 
-   pinctrl = devm_pinctrl_get_select_default(pdev-dev);
-   if (IS_ERR(pinctrl))
-   dev_warn(pdev-dev,
-   pins are not configured from the driver\n);
-
/*
 * For now, only support SDIO interrupt if we have a separate
 * wake-up interrupt configured from device tree. This is because
@@ -2463,10 +2457,15 @@ static int omap_hsmmc_runtime_suspend(struct device 
*dev)
goto abort;
}
 
+   pinctrl_pm_select_idle_state(dev);
+
WARN_ON(host-flags  HSMMC_WAKE_IRQ_ENABLED);
enable_irq(host-wake_irq);
host-flags |= HSMMC_WAKE_IRQ_ENABLED;
+   } else {
+   pinctrl_pm_select_idle_state(dev);
}
+
 abort:
spin_unlock_irqrestore(host-irq_lock, flags);
return ret;
@@ -2490,9 +2489,14 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
host-flags = ~HSMMC_WAKE_IRQ_ENABLED;
}
 
+   pinctrl_pm_select_default_state(host-dev);
+
+   /* irq lost, if pinmux incorrect */
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, CIRQ_EN);
OMAP_HSMMC_WRITE(host-base, IE, CIRQ_EN);
+   } else {
+   pinctrl_pm_select_default_state(host-dev);
}
spin_unlock_irqrestore(host-irq_lock, flags);
return 0;
-- 
1.7.10.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 1/2] ARM: dts: omap5-clocks.dtsi: add ti,set-rate-parent to dss_dss_clk


On 05/21/2014 03:16 PM, Tomi Valkeinen wrote:

Add ti,set-rate-parent to dss_dss_clk so that the DSS driver can
set the rate.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com


Both patches queued for 3.16, thanks.

-Tero


---
  arch/arm/boot/dts/omap54xx-clocks.dtsi | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi 
b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index d487fdab3921..d44bdaa8fe68 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -851,6 +851,7 @@
clocks = dpll_per_h12x2_ck;
ti,bit-shift = 8;
reg = 0x1420;
+   ti,set-rate-parent;
};

dss_sys_clk: dss_sys_clk {



--
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 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal

2014-05-23 Thread Javier Martinez Canillas

Hello Roger,

On Fri, May 23, 2014 at 10:16 AM, Roger Quadros rog...@ti.com wrote:
 Ezequiel  Javier,

 On 05/22/2014 05:46 PM, Ezequiel Garcia wrote:
 On 22 May 01:51 PM, Javier Martinez Canillas wrote:
 On Thu, May 22, 2014 at 10:12 AM, Roger Quadros rog...@ti.com wrote:
 On 21 May 02:20 PM, Roger Quadros wrote:

 For DT boot:
 - The GPMC controller node should have a chip select (CS) node for each 
 used
   chip select. The CS node must have a child device node for each device
   attached to that chip select. Properties for that child are GPMC 
 agnostic.

   i.e.
  gpmc {
  cs0 {
  nand0 {
  }
  };

  cs1 {
  nor0 {
  }
  }
  ...
  };


 While I agree that the GPMC driver is a bit messy, I'm not sure it's 
 possible
 to go through such a complete devicetree binding re-design (breaking 
 backwards
 compatibility) now that the binding is already in production.

 Why not? especially if the existing bindings are poorly dones. Is anyone 
 using these
 bindings burning the DT into ROM and can't change it when they update the 
 kernel?


 While I do agree that your DT bindings are much better than the
 current ones, there is a policy that DT bindings are an external API
 and once are released with a kernel are set in stone and can't be
 changed.


 Exactly. The DT binding is considered an ABI. Thus, invariant across kernel
 versions. Users can't be coherced into a DTB update after a kernel update.

 That said, I don't really care if you break compatilibity in this case.
 Rather, I'm suggesting that you make sure this change is going to be accepted
 upstream, before doing any more work. The DT maintainers are reluctant to do
 so.

 Appreciate your concern.

 Would be really nice if you can review patches 1-12. They have nothing to do 
 with DT changes.
 Thanks.


Overall your patches looks good to me. But I think it's better to wait
until Tony removes the legacy board files for OMAP2+ since AFAIU at
least the following patches could be dropped or trimmed down when
board files are gone:

[RFC PATCH 04/16] ARM: OMAP2+: gpmc: use platform data to configure CS
space and poplulate
[RFC PATCH 06/16] ARM: OMAP2+: gpmc: add NAND specific setup
[RFC PATCH 07/16] ARM: OMAP2+: nand: Update gpmc_nand_init() to use
generic_gpmc_init()

Patches 1-3 and 5 are independent and can be applied in the meantime
as a preparation for further changes following board files removal.

I really like patches 9-12 since those moves some NAND add-hoc code to
the NAND driver where it really belongs. I think that similar changes
can be made for OneNAND and push the special case handling code from
GPMC driver to drivers/mtd/onenand/omap2.c.

Other devices (nor, ethernet, uart, etc) are already using
gpmc_probe_generic_child() so I hope we can isolate the NAND and
OneNAND specific changes and just use a single probe function for all
child devices and possibly get even need the enum gpmc_omap_type you
are adding on your struct gpmc_omap_cs_data.

So what do you think if as a first step we add the platform data as
you propose with all the commons timings and settings there, move all
the possible code to NAND and OneNAND drivers and try to use a single
configuration function for all child devices?

Then once board files are gone we can do further cleanup in the driver
and then we can discuss about changing the DT bindings. Maybe we can
even change it while keeping backwards compatibility? Although I'm not
sure about the last point I think that at least is worth to discuss
it.

 cheers,
 -roger


Thanks a lot and best regards,
Javier


 On the other side, I guess you will also break bisectability while breaking
 backward compatibility. Doesn't sound very nice.


--
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 3/4] mfd: tps65917: Add driver for the TPS65917 PMIC

2014-05-23 Thread Lee Jones

 The TPS65917 chip is a power management IC for Portable Navigation Systems
 and Tablet Computing devices. It contains the following components:
 
   - Regulators.
   - Over Temperature warning and Shut down.
 
 This patch adds support for tps65917 mfd device. At this time only
 the regulator functionality is made available.
 
 Signed-off-by: Keerthy j-keer...@ti.com
 ---
 v3 Changes:
 
   * Header file formating
   * Changed the cache_type to REGCACHE_RBTREE
   * removed unnecessary code
   * Corrected documentation style
   * Added pm_power_off function
 
   v2 Changes:
 
   * Added volatile register check as some of the registers
 in the set are volatile.
 drivers/mfd/Kconfig  |   12 +
   drivers/mfd/Makefile |1 +
   drivers/mfd/tps65917.c   |  594 +
   include/linux/mfd/tps65917.h | 1485 
  ++
   4 files changed, 2092 insertions(+)
   create mode 100644 drivers/mfd/tps65917.c
   create mode 100644 include/linux/mfd/tps65917.h

[...]

 + ret = regmap_read(tps65917-regmap[slave], addr, reg);
 + if (ret)
 + goto err_irq;
 + }i
 What does the read do?  You're not doing anything with the value.
 This pad1 and pad2 stuff is not needed. I will remove this.
 Then why is it in here?
 
 Did you copy this code from somewhere, if so, where?
 
 Okay, I just answered my own question.  There is so much common code
 in between this and palmas, there is no way I'm going to accept this
 driver.  Please merge it in with the palmas driver!
 
 The chip is more like a subset of palmas with lot of register offset changes
 and register bit field changes. Adding this would make it clumsy.
 There could
 be lot of checks. That is why i chose to write a new driver.
 
 Palmas driver already supports palmas variants and tps659038. Merging
 this would mean more and more checks :-/.

Then find an elegant way of representing the variants.  I'm not
prepared to carry that much duplicated code in MFD.  It's already
overladened and in need of an overhaul.  This will exacerbate the
matter.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v13 1/7] mmc: omap_hsmmc: install dummy pm runtime hooks if !CONFIG_PM_RUNTIME

2014-05-23 Thread Balaji T K


On Friday 23 May 2014 02:00 PM, Andreas Fenkart wrote:

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

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 272e0ee..c62d9dd 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -199,7 +199,9 @@ struct omap_hsmmc_host {
struct dma_chan *rx_chan;
int slot_id;
int response_busy;
+#ifdef CONFIG_PM
int context_loss;
+#endif
int protect_card;
int reqs_blocked;
int use_reg;
@@ -712,14 +714,8 @@ static void omap_hsmmc_context_save(struct omap_hsmmc_host 
*host)

  #else

-static int omap_hsmmc_context_restore(struct omap_hsmmc_host *host)
-{
-   return 0;
-}
-
-static void omap_hsmmc_context_save(struct omap_hsmmc_host *host)
-{
-}
+#define omap_hsmmc_context_restore(host)
+#define omap_hsmmc_context_save(host)

  #endif

@@ -1700,11 +1696,14 @@ static int omap_hsmmc_regs_show(struct seq_file *s, 
void *data)
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);

-   seq_printf(s, mmc%d:\n ctx_loss:\t%d\n\nregs:\n,
-   mmc-index, host-context_loss);
+   seq_printf(s, mmc%d:\n, mmc-index);

-   pm_runtime_get_sync(host-dev);
+#ifdef CONFIG_PM
+   seq_printf(s, ctx_loss:\t%d\n, host-context_loss);
+#endif

+   pm_runtime_get_sync(host-dev);
+   seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
seq_printf(s, HCTL:\t\t0x%08x\n,
@@ -2243,6 +2242,7 @@ static int omap_hsmmc_resume(struct device *dev)
  #define omap_hsmmc_resume NULL
  #endif

+#ifdef CONFIG_PM_RUNTIME


AFAIK, omap_hsmmc can build without these changes,
So, I think this patch is not needed.

Let me I know If it is not the case.


  static int omap_hsmmc_runtime_suspend(struct device *dev)
  {
struct omap_hsmmc_host *host;
@@ -2264,6 +2264,10 @@ static int omap_hsmmc_runtime_resume(struct device *dev)

return 0;
  }
+#else
+#define omap_hsmmc_runtime_suspend NULL
+#define omap_hsmmc_runtime_resume  NULL
+#endif

  static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.suspend= omap_hsmmc_suspend,



--
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/omap4: add twd clock to DT


On 05/20/2014 05:49 PM, Tony Lindgren wrote:

* Tero Kristo t-kri...@ti.com [140520 02:01]:

On 05/19/2014 07:27 PM, Tony Lindgren wrote:

* Joachim Eastwood manab...@gmail.com [140519 09:24]:

On 19 May 2014 18:13, Tony Lindgren t...@atomide.com wrote:

* Joachim Eastwood manab...@gmail.com [140518 05:08]:

On 22 April 2014 14:39, Tero Kristo t-kri...@ti.com wrote:

On 04/20/2014 07:22 PM, Gilles Chanteperdrix wrote:


Le 19/04/2014 00:39, Tony Lindgren a écrit :


* Gilles Chanteperdrix gilles.chanteperd...@xenomai.org [140407 13:09]:


Booting Linux 3.14 on Pandaboard currently gets the following
message displayed:

smp_twd: clock not found -2

Define mpu_periphclk as the twd clock in omap4 dts to avoid this.



Tero, care to ack?



Sorry if I did not mail the right people, get_maintainer.pl gave me a
long list, and I did not feel like spamming all these people for such a
small patch. I do not believe Tero was in this list.

Regards.



Yea I don't think this is my expertise area, however the patch looks good to
me, so if you really need it:

Acked-by: Tero Kristo t-kri...@ti.com


Tony, care to add this to your omap 3.16 dt branch?

I am still getting:
[ 0.000152] smp_twd: clock not found -2

So this fix from Gilles would be nice to have.


Best that Tero picks this one up along with the other dt clock changes
he's queueing.


I kinda assumed you would take it since you asked Tero to ack it. But
either way is fine :)


Yes that was before Tero started collecting the dt clock patches :)


I wouldn't say this to be a clock patch as such, this touches the driver
behavior, i.e. registers the correct clock for the driver. That being said,
I can still queue this up with the clock patches if that is what you want.


Yes please go ahead and take this one.

Thanks,

Tony



Ok, thanks, queued for 3.16.

-Tero

--
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 3/4] mfd: tps65917: Add driver for the TPS65917 PMIC

2014-05-23 Thread Keerthy


On Friday 23 May 2014 03:36 PM, Lee Jones wrote:

The TPS65917 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:

  - Regulators.
  - Over Temperature warning and Shut down.

This patch adds support for tps65917 mfd device. At this time only
the regulator functionality is made available.

Signed-off-by: Keerthy j-keer...@ti.com
---
v3 Changes:

  * Header file formating
  * Changed the cache_type to REGCACHE_RBTREE
  * removed unnecessary code
  * Corrected documentation style
  * Added pm_power_off function

  v2 Changes:

  * Added volatile register check as some of the registers
in the set are volatile.
drivers/mfd/Kconfig  |   12 +
  drivers/mfd/Makefile |1 +
  drivers/mfd/tps65917.c   |  594 +
  include/linux/mfd/tps65917.h | 1485 ++
  4 files changed, 2092 insertions(+)
  create mode 100644 drivers/mfd/tps65917.c
  create mode 100644 include/linux/mfd/tps65917.h

[...]


+   ret = regmap_read(tps65917-regmap[slave], addr, reg);
+   if (ret)
+   goto err_irq;
+   }i

What does the read do?  You're not doing anything with the value.

This pad1 and pad2 stuff is not needed. I will remove this.

Then why is it in here?

Did you copy this code from somewhere, if so, where?

Okay, I just answered my own question.  There is so much common code
in between this and palmas, there is no way I'm going to accept this
driver.  Please merge it in with the palmas driver!


The chip is more like a subset of palmas with lot of register offset changes
and register bit field changes. Adding this would make it clumsy.
There could
be lot of checks. That is why i chose to write a new driver.

Palmas driver already supports palmas variants and tps659038. Merging
this would mean more and more checks :-/.

Then find an elegant way of representing the variants.  I'm not
prepared to carry that much duplicated code in MFD.  It's already
overladened and in need of an overhaul.  This will exacerbate the
matter.



Okay. I am working on that.

Regards,
Keerthy
--
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 00/19] Rework OMAP4+ HDMI audio support

2014-05-23 Thread Tomi Valkeinen

On 12/05/14 18:06, Tony Lindgren wrote:
 * Jyri Sarha jsa...@ti.com [140512 02:13]:
 Since RFC version of the patch set: 
 - Split callbacks removal patch away from Integrated ASoC DAI
   component driver implementation patches for easier reading

 This set of patches fixes OMAP4+ HDMI audio. The structure of the
 implementatin looks a bit different than before. Instead of creating a
 driver specific API for a separate ASoC component driver to connect
 to, this implementation integrates an the component driver into the
 HDMI driver.

 The idea is to use an existing ASoC component driver API instead of
 creating a new custom API for each HDMI IP and to avoid splitting the
 driver to half for separate video and audio parts connected with the
 API.

 The new implementation also uses simple-audio-card for a machine
 driver instead of having its own HW specific machine driver.
 
 Can you guys please post this split into the following separate
 parts for the maintainers to merge:
 
 - ASoC changes
 - DSS changes
 - DTS changes
 
 And once those are all in, please post the defconfig changes.

Tony, this series will get delayed until 3.17, but I'd like to merge the
HDMI DMA channel changes to omap4/omap5.dtsi already to 3.16. They are
patches 13 and 15.

Those are very trivial, but I'd rather have acks from you for all the
.dts changes I'll be sending.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH] ARM: dts: AM4372: clk: efuse based crystal frequency detect


On 05/14/2014 02:36 PM, Sekhar Nori wrote:

From: Afzal Mohammed af...@ti.com

Currently oscillator frequency is determined based on sysboot settings,
it may not be the case always. To determine it properly, efuse settings
also has to be read. CONTROL_STATUS register holds this information.
Bit 31: if 0, frequency to be determined based on sysboot
if 1, frequency to be determined based on efuse
Bit 29,30 - for efuse detection of frequency
Bit 22,23 - for sysboot detection of frequency

Add clock nodes (mux) to determine oscillator frequency as above.

Signed-off-by: Afzal Mohammed af...@ti.com
Acked-by: Tero Kristo t-kri...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com


Thanks, queued for 3.16.

-Tero


---
  arch/arm/boot/dts/am43xx-clocks.dtsi |   16 
  1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi 
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..71b029c 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -11,6 +11,22 @@
sys_clkin_ck: sys_clkin_ck {
#clock-cells = 0;
compatible = ti,mux-clock;
+   clocks = sysboot_freq_sel_ck, crystal_freq_sel_ck;
+   ti,bit-shift = 31;
+   reg = 0x0040;
+   };
+
+   crystal_freq_sel_ck: crystal_freq_sel_ck {
+   #clock-cells = 0;
+   compatible = ti,mux-clock;
+   clocks = virt_1920_ck, virt_2400_ck, virt_2500_ck, 
virt_2600_ck;
+   ti,bit-shift = 29;
+   reg = 0x0040;
+   };
+
+   sysboot_freq_sel_ck: sysboot_freq_sel_ck@44e10040 {
+   #clock-cells = 0;
+   compatible = ti,mux-clock;
clocks = virt_1920_ck, virt_2400_ck, virt_2500_ck, 
virt_2600_ck;
ti,bit-shift = 22;
reg = 0x0040;



--
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 3/4] mfd: tps65917: Add driver for the TPS65917 PMIC

2014-05-23 Thread Lee Jones

 The TPS65917 chip is a power management IC for Portable Navigation 
 Systems
 and Tablet Computing devices. It contains the following components:
 
   - Regulators.
   - Over Temperature warning and Shut down.
 
 This patch adds support for tps65917 mfd device. At this time only
 the regulator functionality is made available.
 
 Signed-off-by: Keerthy j-keer...@ti.com
 ---
 v3 Changes:
 
   * Header file formating
   * Changed the cache_type to REGCACHE_RBTREE
   * removed unnecessary code
   * Corrected documentation style
   * Added pm_power_off function
 
   v2 Changes:
 
   * Added volatile register check as some of the registers
 in the set are volatile.
 drivers/mfd/Kconfig  |   12 +
   drivers/mfd/Makefile |1 +
   drivers/mfd/tps65917.c   |  594 +
   include/linux/mfd/tps65917.h | 1485 
  ++
   4 files changed, 2092 insertions(+)
   create mode 100644 drivers/mfd/tps65917.c
   create mode 100644 include/linux/mfd/tps65917.h
 [...]
 
 +   ret = regmap_read(tps65917-regmap[slave], addr, reg);
 +   if (ret)
 +   goto err_irq;
 +   }i
 What does the read do?  You're not doing anything with the value.
 This pad1 and pad2 stuff is not needed. I will remove this.
 Then why is it in here?
 
 Did you copy this code from somewhere, if so, where?
 
 Okay, I just answered my own question.  There is so much common code
 in between this and palmas, there is no way I'm going to accept this
 driver.  Please merge it in with the palmas driver!
 
 The chip is more like a subset of palmas with lot of register offset changes
 and register bit field changes. Adding this would make it clumsy.
 There could
 be lot of checks. That is why i chose to write a new driver.
 
 Palmas driver already supports palmas variants and tps659038. Merging
 this would mean more and more checks :-/.
 Then find an elegant way of representing the variants.  I'm not
 prepared to carry that much duplicated code in MFD.  It's already
 overladened and in need of an overhaul.  This will exacerbate the
 matter.
 
 
 Okay. I am working on that.

Thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] ARM: OMAP5+: Support Duty Cycle Correction(DCC)


On 05/16/2014 01:45 PM, Nishanth Menon wrote:

Hi,

This patch series has been carried over in vendor kernel for quiet
few years now.

Unfortunately, it was very recently re-discovered and upstream kernel
is noticed to be broken for OMAP5 1.5GHz - at least we are operating
DPLL at frequency higher than what it was intended to be when CPUFreq
is enabled. Thankfully, with nominal voltage(we dont use AVS yet in
upstream for the mentioned platforms) and margins in trimming, we
have so far not crashed - but I strongly suspect this might be some
boundary case survival.

Verified on the following impacted platforms using 3.15-rc4 based
vendor kernel.

Before:
OMAP5432: http://slexy.org/view/s20cs0qQFg
DRA72x: http://slexy.org/view/s2TXtSa6mH (refused to lock)
DRA75x: http://slexy.org/view/s20AW8MU5c
After:
OMAP5432: http://slexy.org/view/s21iAfWxpu
DRA72x: http://slexy.org/view/s2hwsvGLmC (locks properly)
DRA75x: http://slexy.org/view/s21ehw8WQn

Hopefully, we can get these into some kernel revision in some form.


Thanks, queued for 3.16/ti-clk-drv. Anybody on the delivery feel free to 
yell if you got any complaints.


-Tero



NOTE: Support for 4470(which is the only other platform requiring
DCC) is not present in upstream kernel and there are no plans to
support that SoC, even if it is added at a later point, support can be
extended as needed.

Series based on v3.15-rc5 tag.
Also available on my tree:
https://github.com/nmenon/linux-2.6-playground/
branch:  push/clock/dcc

weblink: 
https://github.com/nmenon/linux-2.6-playground/commits/push/clock/dcc

Verification:
3.15-rc4 based kernel - DRA75x-evm, 72x-evm, OMAP5uevm
3.15-rc5 - OMAP5uEVM(only one supporting 1.5GHz atm)

Andrii Tseglytskyi (1):
   ARM: OMAP5+: dpll: support Duty Cycle Correction(DCC)

Nishanth Menon (2):
   clk: dpll: support OMAP5 MPU DPLL that need special handling for
 higher frequencies
   ARM: dts: OMAP5/DRA7: use omap5-mpu-dpll-clock capable of dealing
 with higher frequencies

  .../devicetree/bindings/clock/ti/dpll.txt  |1 +
  arch/arm/boot/dts/dra7xx-clocks.dtsi   |2 +-
  arch/arm/boot/dts/omap54xx-clocks.dtsi |2 +-
  arch/arm/mach-omap2/dpll3xxx.c |9 +
  drivers/clk/ti/dpll.c  |   21 
  include/linux/clk/ti.h |4 
  6 files changed, 37 insertions(+), 2 deletions(-)

Regards,
Nishanth Menon



--
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: Accessing GPIOs from userspace using recent kernels

2014-05-23 Thread Linus Walleij

Hi Peter,

I think you have already understood from the rest of the conversation that pin
control configuration shall be done in the device tree and not from userspace,
which is a good start.

As shown by Javier many things people sometimes do in userspace should
rather be done in kernelspace, such as controlling LEDs and reading
pushbuttons etc.

On Fri, May 16, 2014 at 12:15 PM, Peter TB Brett pe...@peter-b.co.uk wrote:
 On 2014-05-15 19:54, Javier Martinez Canillas wrote:

 0x5e (PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_sda.hdmi_sda */
 0x12e (PIN_OUTPUT | MUX_MODE5)  /* dispc2_data15 */

 Yes, that's my mistake.  I took the pin control register addresses from the
 OMAP4 documentation and forgot that you have to subtract 0x40 to get the
 correct address for use in the device tree.

 The correct snippet has 0x1e and 0xee.

I find the pinctrl-single hexdigit syntax infinitely complex and confusing,
but it was chosen by its designers. Most drivers use strings to configure
muxing and biasing etc.

 Is what you shared your real change or just an example that does not
 apply to the Pandaboard? Could you please share your complete DTS?


 The attached .dts file sort of works-ish.  It's an ugly hack, but I don't
 have the time to do any more investigation into this now, unfortunately.

 I guess my main question is: if I use /sys/class/gpio/export to export a
 GPIO for userspace control,

Which you should avoid, if possible.

 it would make sense for the kernel to try and
 ensure that the GPIO is actually connected to something!

How should we do that? The physics of that request evades me.

The pin control subsystem will however
refuse to use the pin if it is used for something else.

 The current call chain seems to be: gpiod_export() -- gpiod_request() --
 omap_gpio_request().  Looking at other GPIO drivers, it seems like
 omap_gpio_request() should eventually call pinctrl_request_gpio().  Would be
 useful if someone who knows about OMAP4/gpio/pinctrl could take a look at
 this.

That is Tony Lindgren and the linux-omap mailing list.

Yours,
Linus Walleij
--
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 v13 1/7] mmc: omap_hsmmc: install dummy pm runtime hooks if !CONFIG_PM_RUNTIME

2014-05-23 12:16 GMT+02:00 Balaji T K balaj...@ti.com:
 On Friday 23 May 2014 02:00 PM, Andreas Fenkart wrote:


 +#ifdef CONFIG_PM_RUNTIME


 AFAIK, omap_hsmmc can build without these changes,
 So, I think this patch is not needed.

 Let me I know If it is not the case.

if do not guard suspend/resume then I have to add guards in patch 1/7:

 @@ -2200,11 +2346,18 @@ static int omap_hsmmc_suspend(struct device *dev)
 pm_runtime_get_sync(host-dev);

 if (!(host-mmc-pm_flags  MMC_PM_KEEP_POWER)) {
 -   omap_hsmmc_disable_irq(host);
 +   OMAP_HSMMC_WRITE(host-base, ISE, 0);
 +   OMAP_HSMMC_WRITE(host-base, IE, 0);
 +   OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
 OMAP_HSMMC_WRITE(host-base, HCTL,
 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);

here

 +
 if (host-dbclk)
 clk_disable_unprepare(host-dbclk);

 @@ -2230,6 +2383,10 @@ static int omap_hsmmc_resume(struct device *dev)

 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);
 +
 pm_runtime_mark_last_busy(host-dev);
 pm_runtime_put_autosuspend(host-dev);
 return 0;
 @@ -2246,22 +2403,51 @@ static int omap_hsmmc_resume(struct device *dev)
  static int omap_hsmmc_runtime_suspend(struct device *dev)
  {
 struct omap_hsmmc_host *host;
 +   unsigned long flags;

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

 +   spin_lock_irqsave(host-irq_lock, flags);
 +   if ((host-mmc-caps  MMC_CAP_SDIO_IRQ) 
 +   (host-flags  HSMMC_SDIO_IRQ_ENABLED)) {
 +   /* disable sdio irq handling to prevent race */
 +   OMAP_HSMMC_WRITE(host-base, ISE, 0);
 +   OMAP_HSMMC_WRITE(host-base, IE, 0);
 +   OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
 +
 +   WARN_ON(host-flags  HSMMC_WAKE_IRQ_ENABLED);
 +   enable_irq(host-wake_irq);

and here

 +   host-flags |= HSMMC_WAKE_IRQ_ENABLED;
 +   }
 +   spin_unlock_irqrestore(host-irq_lock, flags);
 return 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 v13 3/7] mmc: omap_hsmmc: Extend debugfs by SDIO IRQ handling, runtime state

2014-05-23 Thread Balaji T K


On Friday 23 May 2014 02:00 PM, Andreas Fenkart wrote:

Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending

Acked-by: Balaji T K balaj...@ti.com
Signed-off-by: Andreas Fenkart afenk...@gmail.com

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0125eea..cfd2bfb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -56,6 +56,7 @@
  #define OMAP_HSMMC_RSP54  0x0118
  #define OMAP_HSMMC_RSP76  0x011C
  #define OMAP_HSMMC_DATA   0x0120
+#define OMAP_HSMMC_PSTATE  0x0124
  #define OMAP_HSMMC_HCTL   0x0128
  #define OMAP_HSMMC_SYSCTL 0x012C
  #define OMAP_HSMMC_STAT   0x0130
@@ -1816,10 +1817,23 @@ static int omap_hsmmc_regs_show(struct seq_file *s, 
void *data)
  {
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+#ifdef CONFIG_PM
+   bool suspended;
+#endif

seq_printf(s, mmc%d:\n, mmc-index);
+   seq_printf(s, sdio irq mode\t%s\n,
+  (mmc-caps  MMC_CAP_SDIO_IRQ) ? interrupt : polling);
+
+   if (mmc-caps  MMC_CAP_SDIO_IRQ) {
+   seq_printf(s, sdio irq \t%s\n,
+  (host-flags  HSMMC_SDIO_IRQ_ENABLED) ?  enabled
+  : disabled);
+   }

  #ifdef CONFIG_PM


shouldn't this be CONFIG_PM_RUNTIME ?


+   suspended = host-dev-power.runtime_status != RPM_ACTIVE;
+   seq_printf(s, runtime state\t%s\n, (suspended ? idle : active));


The whole check for runtime status (and check for CONFIG_PM..) can be removed,
since runtime status is available via sysfs

cat /sys/class/mmc_host/mmcX/device/power/runtime_status


seq_printf(s, ctx_loss:\t%d\n, host-context_loss);
  #endif

@@ -1827,6 +1841,8 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void 
*data)
seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
+   seq_printf(s, PSTATE:\t\t0x%08x\n,
+  OMAP_HSMMC_READ(host-base, PSTATE));
seq_printf(s, HCTL:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, HCTL));
seq_printf(s, SYSCTL:\t\t0x%08x\n,



--
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 v13 7/7] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x

2014-05-23 Thread Balaji T K


On Friday 23 May 2014 02:00 PM, Andreas Fenkart wrote:

The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, 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. Code contributions from
Tony Lindgren and Balaji T K balaj...@ti.com

Acked-by: Balaji T K balaj...@ti.com
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 0233ba7..76bf087 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -57,3 +57,56 @@ Examples:
edma 25;
dma-names = tx, rx;
};
+
+[workaround for missing swakeup on am33xx]
+
+This SOC is missing the swakeup line, it will not detect SDIO irq
+while in suspend.
+
+ --
+ | PRCM |
+  --
+   ^ |
+   swakeup | | fclk
+   | v
+   -----   -
+  | card | -- CIRQ --  | hsmmc | -- IRQ --  | CPU |
+   -----   -
+
+In suspend the fclk is off and the module is disfunctional. Even register reads
+will fail. A small logic in the host will request fclk restore, when an
+external event is detected. Once the clock is restored, the host detects the
+event normally. Since am33xx doesn't have this line it never wakes from
+suspend.
+
+The workaround is to reconfigure the dat1 line as a GPIO upon suspend. To make
+this work, we need to set the named pinctrl states default and idle.
+Prepare idle to remux dat1 as a gpio, and default to remux it back as sdio
+dat1. The MMC driver will then toggle between idle and default state during
+runtime.
+
+In summary:
+1. select matching 'compatible' section, see example below.
+2. specify pinctrl states default and idle, sleep is optional.
+3. specify the gpio irq used for detecting sdio irq in suspend
+
+If configuration is incomplete, a warning message is emitted falling back to
+polling. Also check the sdio irq mode in /sys/kernel/debug/mmc0/regs. Mind
+not every application needs SDIO irq, e.g. MMC cards.
+
+   mmc1: mmc@48060100 {
+   compatible = ti,am33xx-hsmmc;
+   ...
+   pinctrl-names = default, idle, sleep
+   pinctrl-0 = mmc1_pins;
+   pinctrl-1 = mmc1_idle;
+   pinctrl-2 = mmc1_sleep;
+   ...
+   interrupts-extended = intc 64 gpio2 28 0;
+   };
+
+   mmc1_idle : pinmux_cirq_pin {
+   pinctrl-single,pins = 
+   0x0f8 0x3f  /* GPIO2_28 */
+   ;
+   };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 760b0ac..1238506 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1752,15 +1752,25 @@ static int omap_hsmmc_configure_wake_irq(struct 
omap_hsmmc_host *host)
 * and need to remux SDIO DAT1 to GPIO for wake-up from idle.
 */
if (host-pdata-controller_flags  OMAP_HSMMC_SWAKEUP_MISSING) {
-   ret = -ENODEV;
-   devm_free_irq(host-dev, host-wake_irq, host);
-   goto err;
+   if (IS_ERR(host-dev-pins-default_state)) {


Rater than introducing #ifdef CONFIG_PM on multiple places,
I think things will simple, if pinctrl_lookup_state is used here
to avoid build error on !CONFIG_PM




+   dev_info(host-dev, missing default pinctrl state\n);
+   ret = -EINVAL;
+   goto err_free_irq;
+   }
+
+   if (IS_ERR(host-dev-pins-idle_state)) {


same here.


+   dev_info(host-dev, missing idle pinctrl state\n);
+   ret = -EINVAL;
+   goto err_free_irq;
+   }
}

OMAP_HSMMC_WRITE(host-base, HCTL,
 OMAP_HSMMC_READ(host-base, HCTL) | IWE);
return 0;

+err_free_irq:
+   devm_free_irq(host-dev, host-wake_irq, host);
  err:
dev_warn(host-dev, no SDIO IRQ support, falling back to polling\n);
host-wake_irq = 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 v3 0/3] ARM: dts: overo: Add panel support

* Tomi Valkeinen tomi.valkei...@ti.com [140523 01:19]:
 On 23/05/14 10:09, Florian Vaussard wrote:
  Hi Tomi,
  
  On 05/20/2014 03:58 PM, Florian Vaussard wrote:
  Hi,
 
  This series enables the DVI and LCD panels present on some of
  the Overo expansion boards.
 
  
  Do you have any more comments on these? If no, do you want to pull them
  through your tree for 3.16, as discussed with Tony?
 
 Yes, I can take these.
 
 Tony, do I have your ack on this series?

Yes please go ahead and queue these:

Acked-by: Tony Lindgren t...@atomide.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] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

* Tobias Jakobi tjak...@math.uni-bielefeld.de [140519 14:19]:
 
 But even if I don't connect via WiFi at all, just boot and let me system
 run with serial console connected, after some time I get a kernel 'WARNING':
 http://www.math.uni-bielefeld.de/~tjakobi/archive/dmesg.1.log

BTW, care to update the bugzilla page with the second warning
in this log?

That's the WARNING: CPU: 1 PID: 0 at kernel/timer.c:1147 that's
at 238 seconds.

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 v3 2/3] ARM: dts: oma3-gta04: Add display support

* Tomi Valkeinen tomi.valkei...@ti.com [140523 01:21]:
 On 08/05/14 23:16, Marek Belisko wrote:
  This patch add support for lcd display on gta04 board. Display control
  is connected to spi (used spi bitbang driver).
  
  Signed-off-by: Marek Belisko ma...@goldelico.com
  ---
   arch/arm/boot/dts/omap3-gta04.dts | 87 
  +++
   1 file changed, 87 insertions(+)
 
 I can take this via my tree.
 
 Tony, can I have your ack on this?

Yes for the whole series:

Acked-by: Tony Lindgren t...@atomide.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 00/19] Rework OMAP4+ HDMI audio support

* Tomi Valkeinen tomi.valkei...@ti.com [140523 04:03]:
 On 12/05/14 18:06, Tony Lindgren wrote:
  * Jyri Sarha jsa...@ti.com [140512 02:13]:
  Since RFC version of the patch set: 
  - Split callbacks removal patch away from Integrated ASoC DAI
component driver implementation patches for easier reading
 
  This set of patches fixes OMAP4+ HDMI audio. The structure of the
  implementatin looks a bit different than before. Instead of creating a
  driver specific API for a separate ASoC component driver to connect
  to, this implementation integrates an the component driver into the
  HDMI driver.
 
  The idea is to use an existing ASoC component driver API instead of
  creating a new custom API for each HDMI IP and to avoid splitting the
  driver to half for separate video and audio parts connected with the
  API.
 
  The new implementation also uses simple-audio-card for a machine
  driver instead of having its own HW specific machine driver.
  
  Can you guys please post this split into the following separate
  parts for the maintainers to merge:
  
  - ASoC changes
  - DSS changes
  - DTS changes
  
  And once those are all in, please post the defconfig changes.
 
 Tony, this series will get delayed until 3.17, but I'd like to merge the
 HDMI DMA channel changes to omap4/omap5.dtsi already to 3.16. They are
 patches 13 and 15.
 
 Those are very trivial, but I'd rather have acks from you for all the
 .dts changes I'll be sending.

OK fine with me:

Acked-by: Tony Lindgren t...@atomide.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: [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal

* Roger Quadros rog...@ti.com [140523 01:17]:
 On 05/22/2014 05:46 PM, Ezequiel Garcia wrote:
  On 22 May 01:51 PM, Javier Martinez Canillas wrote:
  On Thu, May 22, 2014 at 10:12 AM, Roger Quadros rog...@ti.com wrote:
  On 21 May 02:20 PM, Roger Quadros wrote:
  While I agree that the GPMC driver is a bit messy, I'm not sure it's 
  possible
  to go through such a complete devicetree binding re-design (breaking 
  backwards
  compatibility) now that the binding is already in production.
 
  Why not? especially if the existing bindings are poorly dones. Is anyone 
  using these
  bindings burning the DT into ROM and can't change it when they update the 
  kernel?
 
 
  While I do agree that your DT bindings are much better than the
  current ones, there is a policy that DT bindings are an external API
  and once are released with a kernel are set in stone and can't be
  changed.
 
  
  Exactly. The DT binding is considered an ABI. Thus, invariant across kernel
  versions. Users can't be coherced into a DTB update after a kernel update.
  
  That said, I don't really care if you break compatilibity in this case.
  Rather, I'm suggesting that you make sure this change is going to be 
  accepted
  upstream, before doing any more work. The DT maintainers are reluctant to do
  so.
 
 Appreciate your concern.
 
 Would be really nice if you can review patches 1-12. They have nothing to do 
 with DT changes.
 Thanks.

I'm mostly concerned about keeping things working. I think the
only way we can keep things working is to keep support for
the old binding around in addition to the new one. That way
we can update devices one at a time.

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: Accessing GPIOs from userspace using recent kernels

* Linus Walleij linus.wall...@linaro.org [140523 04:36]:
On Fri, May 16, 2014 at 12:15 PM, Peter TB Brett pe...@peter-b.co.uk wrote:
The current call chain seems to be: gpiod_export() -- gpiod_request() --
omap_gpio_request(). Looking at other GPIO drivers, it seems like
omap_gpio_request() should eventually call pinctrl_request_gpio(). Would be
useful if someone who knows about OMAP4/gpio/pinctrl could take a look at
this.

If we do this, we also need a solution to prevent automatic remuxing
of GPIO pins from happending. For wake-up events, some drivers need
to remux a rx pin to GPIO input for the duration of idle, and then
back to device rx pin. This is needed on some other platforms too
AFAIK.

For the drivers needing GPIO wake-up events, request_gpio is done in
the driver after drivers/base/pinctrl.c has already muxed the device
pin to rx. At minimum we would get warnings about reserved pins if
we tried to automatically mux them to GPIO.

We may be able to use some GPIO specific property to prevent
automatic remuxing as we discussed in the #armlinux few days ago.

Related to automatic remuxing of GPIO pins, there are also other
needs for pinctrl and GPIO interaction. We need to remux GPIO output
pins to input + pull + safe_mode to prevent the GPIO pins losing
value briefly during off-idle. That's the gpio errata 1.158 at as
shown at least at [1]. Because the GPIO to pinctrl mapping is
sparse and SoC specific, there's currently now obvious way to do
that. And we would need few new GPIO functions to tell pinctrl
subsystem about the change.

Regards,

Tony

[1]
https://www.gitorious.org/rowboat/kernel/commit/86b15f21298b749a9d8216ff1839d33ad542464e?format=patch
--
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 v13 3/7] mmc: omap_hsmmc: Extend debugfs by SDIO IRQ handling, runtime state

* Balaji T K balaj...@ti.com [140523 05:27]:
 On Friday 23 May 2014 02:00 PM, Andreas Fenkart wrote:
 Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
 state of data lines, incl. SDIO IRQ pending
 
 Acked-by: Balaji T K balaj...@ti.com
 Signed-off-by: Andreas Fenkart afenk...@gmail.com
 
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 0125eea..cfd2bfb 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -56,6 +56,7 @@
   #define OMAP_HSMMC_RSP54   0x0118
   #define OMAP_HSMMC_RSP76   0x011C
   #define OMAP_HSMMC_DATA0x0120
 +#define OMAP_HSMMC_PSTATE   0x0124
   #define OMAP_HSMMC_HCTL0x0128
   #define OMAP_HSMMC_SYSCTL  0x012C
   #define OMAP_HSMMC_STAT0x0130
 @@ -1816,10 +1817,23 @@ static int omap_hsmmc_regs_show(struct seq_file *s, 
 void *data)
   {
  struct mmc_host *mmc = s-private;
  struct omap_hsmmc_host *host = mmc_priv(mmc);
 +#ifdef CONFIG_PM
 +bool suspended;
 +#endif
 
  seq_printf(s, mmc%d:\n, mmc-index);
 +seq_printf(s, sdio irq mode\t%s\n,
 +   (mmc-caps  MMC_CAP_SDIO_IRQ) ? interrupt : polling);
 +
 +if (mmc-caps  MMC_CAP_SDIO_IRQ) {
 +seq_printf(s, sdio irq \t%s\n,
 +   (host-flags  HSMMC_SDIO_IRQ_ENABLED) ?  enabled
 +   : disabled);
 +}
 
   #ifdef CONFIG_PM
 
 shouldn't this be CONFIG_PM_RUNTIME ?
 
 +suspended = host-dev-power.runtime_status != RPM_ACTIVE;
 +seq_printf(s, runtime state\t%s\n, (suspended ? idle : active));
 
 The whole check for runtime status (and check for CONFIG_PM..) can be removed,
 since runtime status is available via sysfs
 
 cat /sys/class/mmc_host/mmcX/device/power/runtime_status
 
  seq_printf(s, ctx_loss:\t%d\n, host-context_loss);
   #endif

Also CONFIG_SYSFS is a bool FYI.

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] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

* Tony Lindgren t...@atomide.com [140523 07:45]:
 * Tobias Jakobi tjak...@math.uni-bielefeld.de [140519 14:19]:
  
  But even if I don't connect via WiFi at all, just boot and let me system
  run with serial console connected, after some time I get a kernel 'WARNING':
  http://www.math.uni-bielefeld.de/~tjakobi/archive/dmesg.1.log
 
 BTW, care to update the bugzilla page with the second warning
 in this log?
 
 That's the WARNING: CPU: 1 PID: 0 at kernel/timer.c:1147 that's
 at 238 seconds.

Also, with Santosh's fix applied, can you also try disabling one
or more of the idle states for cpuidle and see if that helps?

Something like this patch below. If that helps with the WARNING
above you're getting it narrows down the problem down quite a bit.

Regards,

Tony

--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -44,11 +44,13 @@ static struct idle_statedata omap4_idle_data[] = {
.mpu_state = PWRDM_POWER_RET,
.mpu_logic_state = PWRDM_POWER_RET,
},
+#if 0
{
.cpu_state = PWRDM_POWER_OFF,
.mpu_state = PWRDM_POWER_RET,
.mpu_logic_state = PWRDM_POWER_OFF,
},
+#endif
 };
 
 static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
--
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 03/13] ARM: OMAP2+: Remove non working OMAP HDMI audio initialization

This code is not working currently and it can be removed. There is a
conflict in sharing resources with the actual HDMI driver and with
the ASoC HDMI audio DAI driver.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 arch/arm/mach-omap2/devices.c |   28 
 1 file changed, 28 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index e58609b..4bab682 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -330,33 +330,6 @@ static void omap_init_audio(void)
 static inline void omap_init_audio(void) {}
 #endif
 
-#if defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI) || \
-   defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI_MODULE)
-
-static struct platform_device omap_hdmi_audio = {
-   .name   = omap-hdmi-audio,
-   .id = -1,
-};
-
-static void __init omap_init_hdmi_audio(void)
-{
-   struct omap_hwmod *oh;
-   struct platform_device *pdev;
-
-   oh = omap_hwmod_lookup(dss_hdmi);
-   if (!oh)
-   return;
-
-   pdev = omap_device_build(omap-hdmi-audio-dai, -1, oh, NULL, 0);
-   WARN(IS_ERR(pdev),
-Can't build omap_device for omap-hdmi-audio-dai.\n);
-
-   platform_device_register(omap_hdmi_audio);
-}
-#else
-static inline void omap_init_hdmi_audio(void) {}
-#endif
-
 #if defined(CONFIG_SPI_OMAP24XX) || defined(CONFIG_SPI_OMAP24XX_MODULE)
 
 #include linux/platform_data/spi-omap2-mcspi.h
@@ -492,7 +465,6 @@ static int __init omap2_init_devices(void)
 */
omap_init_audio();
omap_init_camera();
-   omap_init_hdmi_audio();
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
-- 
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 01/13] ARM: omap4.dtsi: Add audio related parametes to hdmi node

Adds HDMI audio sDMA properties.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 arch/arm/boot/dts/omap4.dtsi |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 649b5cd..335ed54 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -919,6 +919,8 @@
ti,hwmods = dss_hdmi;
clocks = dss_48mhz_clk, dss_sys_clk;
clock-names = fck, sys_clk;
+   dmas = sdma 76;
+   dma-names = audio_tx;
};
};
};
-- 
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 00/13] Fix OMAP4+ HDMI audio

This patch set fixes the resource sharing problems between
omap-hdmi-dai driver and OMAPDSS HDMI driver. It does it by
registering the OMAP HDMI audio related ASoC drivers from OMAPDSS HDMI
driver. Platform data structs have been added for omap-hdmi-dai and
omap-hdmi-card drivers to pass the information and resources from
OMAPDSS HDMI driver.

The idea of this patch set is to fix HDMI audio for the next release
after it got broken by OMAPDSS DT changes. It does not mean that I
have abandoned the patch set that integrates the omap-hdmi-dai driver
into OMAPDSS HDMI driver. The OMAPDSS side of those patches just had
some dependencies to the recent ASoC side patches that would have
caused problems in the next merge. I'll mail a revised and rebased
version of those patches soon.

Best regards,
Jyri

Jyri Sarha (13):
  ARM: omap4.dtsi: Add audio related parametes to hdmi node
  ARM: omap5.dtsi: Add audio related parameters to hdmi node
  ARM: OMAP2+: Remove non working OMAP HDMI audio initialization
  OMAPDSS: hdmi_wp: Add function for getting hdmi_wp physical base
address
  OMAPDSS: hdmi_audio: Add hdmi_audio.c for registering HDMI audio
support
  ASoC: omap-hdmi-dai: Add platform data struct for omap-hdmi-dai
driver
  ASoC: omap-hdmi-card: Add platform data stuct for omap-hdmi-card
driver
  ASoC: omap-hdmi: Changes for registeing the driver from OMAPDSS
  ASoC: omap-hdmi-card: Changes for registeing the driver from OMAPDSS
  OMAPDSS: hdmi4: Register HDMI audio ASoC drivers from HDMI driver
  OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value
  OMAPDSS: hdmi5: Register HDMI audio ASoC drivers from HDMI driver
  ASoC: omap: Add Kconfig option for OMAP5 HDMI audio

 arch/arm/boot/dts/omap4.dtsi   |2 +
 arch/arm/boot/dts/omap5.dtsi   |2 +
 arch/arm/mach-omap2/devices.c  |   28 -
 drivers/video/fbdev/omap2/dss/Makefile |2 +-
 drivers/video/fbdev/omap2/dss/hdmi.h   |   17 -
 drivers/video/fbdev/omap2/dss/hdmi4.c  |   15 +
 drivers/video/fbdev/omap2/dss/hdmi5.c  |   15 +
 drivers/video/fbdev/omap2/dss/hdmi_audio.c |   92 
 drivers/video/fbdev/omap2/dss/hdmi_wp.c|6 ++
 include/sound/omap-hdmi-card-pdata.h   |   28 +
 include/sound/omap-hdmi-dai-pdata.h|   31 ++
 sound/soc/omap/Kconfig |   13 +++-
 sound/soc/omap/omap-hdmi-card.c|   20 --
 sound/soc/omap/omap-hdmi.c |   65 +---
 14 files changed, 253 insertions(+), 83 deletions(-)
 create mode 100644 drivers/video/fbdev/omap2/dss/hdmi_audio.c
 create mode 100644 include/sound/omap-hdmi-card-pdata.h
 create mode 100644 include/sound/omap-hdmi-dai-pdata.h

-- 
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 07/13] ASoC: omap-hdmi-card: Add platform data stuct for omap-hdmi-card driver

The names of the needed ASoC component drivers need to be passed to
the omap-hdmi-card driver for it to find them.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 include/sound/omap-hdmi-card-pdata.h |   28 
 1 file changed, 28 insertions(+)
 create mode 100644 include/sound/omap-hdmi-card-pdata.h

diff --git a/include/sound/omap-hdmi-card-pdata.h 
b/include/sound/omap-hdmi-card-pdata.h
new file mode 100644
index 000..f70495b
--- /dev/null
+++ b/include/sound/omap-hdmi-card-pdata.h
@@ -0,0 +1,28 @@
+/*
+ * omap-hdmi-card-pdata.h
+ *
+ * Platform data for OMAP ALSA SoC card driver for HDMI audio on OMAP4+
+ * processors.
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Authors: Jyri Sarha jsa...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#ifndef __OMAP_HDMI_CARD_PDATA_H__
+#define __OMAP_HDMI_CARD_PDATA_H__
+
+struct asoc_omap_hdmi_card_pdata {
+   const char *cpudai_name;
+   const char *codec_name;
+};
+
+#endif
-- 
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 05/13] OMAPDSS: hdmi_audio: Add hdmi_audio.c for registering HDMI audio support

HDMI audio is implemented using ASoC component drivers. The drivers
were earlier registered from under mach-omap2 but that code had
problems with sharing the HDMI resources. This commit adds functions
for registering the ASoC drivers needed for HDMI audio from HDMI
driver itself.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 drivers/video/fbdev/omap2/dss/Makefile |2 +-
 drivers/video/fbdev/omap2/dss/hdmi.h   |   12 
 drivers/video/fbdev/omap2/dss/hdmi_audio.c |   92 
 3 files changed, 105 insertions(+), 1 deletion(-)
 create mode 100644 drivers/video/fbdev/omap2/dss/hdmi_audio.c

diff --git a/drivers/video/fbdev/omap2/dss/Makefile 
b/drivers/video/fbdev/omap2/dss/Makefile
index 390ab74..7ea2d7c 100644
--- a/drivers/video/fbdev/omap2/dss/Makefile
+++ b/drivers/video/fbdev/omap2/dss/Makefile
@@ -11,7 +11,7 @@ omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o
 omapdss-$(CONFIG_OMAP2_DSS_SDI) += sdi.o
 omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o
 omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_common.o hdmi_wp.o hdmi_pll.o \
-   hdmi_phy.o
+   hdmi_phy.o hdmi_audio.o
 omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi4_core.o
 omapdss-$(CONFIG_OMAP5_DSS_HDMI) += hdmi5.o hdmi5_core.o
 ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h 
b/drivers/video/fbdev/omap2/dss/hdmi.h
index f644bc8..3ddb5f8 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -434,6 +434,18 @@ int hdmi_parse_lanes_of(struct platform_device *pdev, 
struct device_node *ep,
struct hdmi_phy_data *phy);
 
 #if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) || 
defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+struct hdmi_audio_data {
+   struct platform_device *cpudai_pdev;
+   struct platform_device *codec_pdev;
+   struct platform_device *card_pdev;
+};
+
+int hdmi_audio_register(struct platform_device *pdev,
+   struct hdmi_audio_data *data,
+   struct omap_dss_device *hdmi,
+   struct hdmi_wp_data *wp);
+void hdmi_audio_unregister(struct hdmi_audio_data *data);
+
 int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n, u32 *cts);
 int hdmi_wp_audio_enable(struct hdmi_wp_data *wp, bool enable);
 int hdmi_wp_audio_core_req_enable(struct hdmi_wp_data *wp, bool enable);
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_audio.c 
b/drivers/video/fbdev/omap2/dss/hdmi_audio.c
new file mode 100644
index 000..2a485f7
--- /dev/null
+++ b/drivers/video/fbdev/omap2/dss/hdmi_audio.c
@@ -0,0 +1,92 @@
+/*
+ * OMAP4+ HDMI audio
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated
+ *
+ * Authors: Jyri Sarha jsa...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/err.h
+#include linux/string.h
+#include linux/platform_device.h
+#include linux/of_dma.h
+#include linux/dmaengine.h
+#include sound/omap-hdmi-dai-pdata.h
+#include sound/omap-hdmi-card-pdata.h
+
+#include hdmi.h
+
+static struct asoc_omap_hdmi_dai_pdata dai_pdata;
+struct asoc_omap_hdmi_card_pdata card_pdata;
+
+int hdmi_audio_register(struct platform_device *pdev,
+   struct hdmi_audio_data *data,
+   struct omap_dss_device *hdmi,
+   struct hdmi_wp_data *wp)
+{
+   struct device_node *np = pdev-dev.of_node;
+   struct device *dev = pdev-dev;
+   struct dma_chan *dma_ch;
+   struct resource *res;
+
+   dai_pdata.dssdev = hdmi;
+   dai_pdata.dma_addr = hdmi_wp_get_phys_addr(wp) + HDMI_WP_AUDIO_DATA;
+
+   dma_ch = of_dma_request_slave_channel(np, audio_tx);
+   if (IS_ERR(dma_ch)) {
+   dev_info(dev, Could not get dma request channel from dts.\n);
+   /* Revert to hard coding. The DMA req channel is the
+  same on all supported hw. */
+   dai_pdata.dma_req = 76;
+   } else {
+   dai_pdata.dma_req = dma_ch-chan_id;
+   /* We only peeked the chan_id for pdata and let dai
+  driver take the DMA channel. */
+   dma_release_channel(dma_ch);
+   }
+
+   data-cpudai_pdev =
+   platform_device_register_data(dev, omap-hdmi-audio-dai, 0,
+ dai_pdata, sizeof(dai_pdata));
+   if (IS_ERR(data-cpudai_pdev))
+   return PTR_ERR(data-cpudai_pdev);
+
+   data-codec_pdev =
+   platform_device_register_data(dev, hdmi-audio-codec,
+

[PATCH 12/13] OMAPDSS: hdmi5: Register HDMI audio ASoC drivers from HDMI driver

The registering is best done here to share the resources owned by OMAPDSS
HDMI driver with ASoC DAI and platform drivers.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 drivers/video/fbdev/omap2/dss/hdmi5.c |   15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c 
b/drivers/video/fbdev/omap2/dss/hdmi5.c
index c468b9e..1ba387b 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi5.c
@@ -57,6 +57,9 @@ static struct {
struct clk *sys_clk;
struct regulator *vdda_reg;
 
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+   struct hdmi_audio_data audio;
+#endif
bool core_enabled;
 
struct omap_dss_device output;
@@ -761,6 +764,15 @@ static int omapdss_hdmihw_probe(struct platform_device 
*pdev)
 
hdmi_init_output(pdev);
 
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+   r = hdmi_audio_register(pdev, hdmi.audio, hdmi.output, hdmi.wp);
+   if (r) {
+   DSSERR(Registering HDMI audio failed\n);
+   hdmi_uninit_output(pdev);
+   pm_runtime_disable(pdev-dev);
+   return r;
+   }
+#endif
dss_debugfs_create_file(hdmi, hdmi_dump_regs);
 
return 0;
@@ -768,6 +780,9 @@ static int omapdss_hdmihw_probe(struct platform_device 
*pdev)
 
 static int __exit omapdss_hdmihw_remove(struct platform_device *pdev)
 {
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+   hdmi_audio_unregister(hdmi.audio);
+#endif
hdmi_uninit_output(pdev);
 
pm_runtime_disable(pdev-dev);
-- 
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 11/13] OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value

The OMAP5 HDMI audio implementation needs HDMI_AUDIO_LAYOUT_6CH in
hdmi_core_audio_layout enum. I found the correct value from ti-linux
3.8 tree.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 drivers/video/fbdev/omap2/dss/hdmi.h |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h 
b/drivers/video/fbdev/omap2/dss/hdmi.h
index 3ddb5f8..c9efc92 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -159,7 +159,8 @@ enum hdmi_audio_blk_strt_end_sig {
 
 enum hdmi_core_audio_layout {
HDMI_AUDIO_LAYOUT_2CH = 0,
-   HDMI_AUDIO_LAYOUT_8CH = 1
+   HDMI_AUDIO_LAYOUT_8CH = 1,
+   HDMI_AUDIO_LAYOUT_6CH = 2
 };
 
 enum hdmi_core_cts_mode {
-- 
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 04/13] OMAPDSS: hdmi_wp: Add function for getting hdmi_wp physical base address

The hdmi_wp physical base address is needed for hdmi audio dma.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 drivers/video/fbdev/omap2/dss/hdmi.h|2 ++
 drivers/video/fbdev/omap2/dss/hdmi_wp.c |6 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h 
b/drivers/video/fbdev/omap2/dss/hdmi.h
index fbee078..f644bc8 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -341,6 +341,7 @@ struct hdmi_core_infoframe_avi {
 
 struct hdmi_wp_data {
void __iomem *base;
+   phys_addr_t phys_base;
 };
 
 struct hdmi_pll_data {
@@ -410,6 +411,7 @@ void hdmi_wp_video_config_timing(struct hdmi_wp_data *wp,
 void hdmi_wp_init_vid_fmt_timings(struct hdmi_video_format *video_fmt,
struct omap_video_timings *timings, struct hdmi_config *param);
 int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp);
+phys_addr_t hdmi_wp_get_phys_addr(struct hdmi_wp_data *wp);
 
 /* HDMI PLL funcs */
 int hdmi_pll_enable(struct hdmi_pll_data *pll, struct hdmi_wp_data *wp);
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_wp.c 
b/drivers/video/fbdev/omap2/dss/hdmi_wp.c
index a16a190..bee6df3 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_wp.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_wp.c
@@ -264,6 +264,7 @@ int hdmi_wp_init(struct platform_device *pdev, struct 
hdmi_wp_data *wp)
temp_res.end = temp_res.start + WP_SIZE - 1;
res = temp_res;
}
+   wp-phys_base = res-start;
 
wp-base = devm_ioremap(pdev-dev, res-start, resource_size(res));
if (!wp-base) {
@@ -273,3 +274,8 @@ int hdmi_wp_init(struct platform_device *pdev, struct 
hdmi_wp_data *wp)
 
return 0;
 }
+
+phys_addr_t hdmi_wp_get_phys_addr(struct hdmi_wp_data *wp)
+{
+   return wp-phys_base;
+}
-- 
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/13] ASoC: omap: Add Kconfig option for OMAP5 HDMI audio

Adds SND_OMAP_SOC_OMAP5_HDMI config option for OMAP5 HDMI audio support.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 sound/soc/omap/Kconfig |   13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index d44463a..697e1b8 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -101,7 +101,7 @@ config SND_OMAP_SOC_OMAP_ABE_TWL6040
  - PandaBoardES (4460)
 
 config SND_OMAP_SOC_OMAP_HDMI
-   tristate SoC Audio support for Texas Instruments OMAP HDMI
+   tristate SoC Audio support for Texas Instruments OMAP4 HDMI
depends on SND_OMAP_SOC  OMAP4_DSS_HDMI  OMAP2_DSS
select SND_OMAP_SOC_HDMI
select SND_SOC_HDMI_CODEC
@@ -110,6 +110,17 @@ config SND_OMAP_SOC_OMAP_HDMI
  Say Y if you want to add support for SoC HDMI audio on Texas 
Instruments
  OMAP4 chips
 
+
+config SND_OMAP_SOC_OMAP5_HDMI
+   tristate SoC Audio support for Texas Instruments OMAP5 HDMI
+   depends on SND_OMAP_SOC  OMAP5_DSS_HDMI  OMAP2_DSS
+   select SND_OMAP_SOC_HDMI
+   select SND_SOC_HDMI_CODEC
+   select OMAP5_DSS_HDMI_AUDIO
+   help
+ Say Y if you want to add support for SoC HDMI audio on Texas 
Instruments
+ OMAP5 chips
+
 config SND_OMAP_SOC_OMAP3_PANDORA
tristate SoC Audio support for OMAP3 Pandora
depends on TWL4030_CORE  SND_OMAP_SOC  MACH_OMAP3_PANDORA
-- 
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 02/13] ARM: omap5.dtsi: Add audio related parameters to hdmi node

Adds HDMI audio sDMA properties.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 32c02ce..279a9c7 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -937,6 +937,8 @@
ti,hwmods = dss_hdmi;
clocks = dss_48mhz_clk, dss_sys_clk;
clock-names = fck, sys_clk;
+   dmas = sdma 76;
+   dma-names = audio_tx;
};
};
};
-- 
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 06/13] ASoC: omap-hdmi-dai: Add platform data struct for omap-hdmi-dai driver

Provide the means to pass OMAPDSS HDMI resources over to omap-hdmi-dai
driver when the OMAPDSS driver registers the DAI driver.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 include/sound/omap-hdmi-dai-pdata.h |   31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 include/sound/omap-hdmi-dai-pdata.h

diff --git a/include/sound/omap-hdmi-dai-pdata.h 
b/include/sound/omap-hdmi-dai-pdata.h
new file mode 100644
index 000..337c859
--- /dev/null
+++ b/include/sound/omap-hdmi-dai-pdata.h
@@ -0,0 +1,31 @@
+/*
+ * omap-hdmi-dai-pdata.h
+ *
+ * Platform data for OMAP ALSA SoC DAI driver for HDMI audio on OMAP4+
+ * processors.
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Authors: Jyri Sarha jsa...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#ifndef __OMAP_HDMI_DAI_PDATA_H__
+#define __OMAP_HDMI_DAI_PDATA_H__
+
+struct omap_dss_device;
+
+struct asoc_omap_hdmi_dai_pdata {
+   struct omap_dss_device *dssdev;
+   dma_addr_t dma_addr;
+   unsigned int dma_req;
+};
+
+#endif
-- 
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 09/13] ASoC: omap-hdmi-card: Changes for registeing the driver from OMAPDSS

The old OMAP HDMI audio registering from arch/arm/mach-omap2/devices.c
was broken. The new approach is to register the drivers from OMAPDSS HDMI
driver. The commit does the necessary changes for this approach.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 sound/soc/omap/omap-hdmi-card.c |   20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/sound/soc/omap/omap-hdmi-card.c b/sound/soc/omap/omap-hdmi-card.c
index f649fe8..56c0055 100644
--- a/sound/soc/omap/omap-hdmi-card.c
+++ b/sound/soc/omap/omap-hdmi-card.c
@@ -26,15 +26,13 @@
 #include sound/soc.h
 #include asm/mach-types.h
 #include video/omapdss.h
+#include sound/omap-hdmi-card-pdata.h
 
 #define DRV_NAME omap-hdmi-audio
 
 static struct snd_soc_dai_link omap_hdmi_dai = {
.name = HDMI,
.stream_name = HDMI,
-   .cpu_dai_name = omap-hdmi-audio-dai,
-   .platform_name = omap-hdmi-audio-dai,
-   .codec_name = hdmi-audio-codec,
.codec_dai_name = hdmi-hifi,
 };
 
@@ -47,14 +45,28 @@ static struct snd_soc_card snd_soc_omap_hdmi = {
 
 static int omap_hdmi_probe(struct platform_device *pdev)
 {
+   struct device *dev = pdev-dev;
+   struct asoc_omap_hdmi_card_pdata *pdata = dev-platform_data;
struct snd_soc_card *card = snd_soc_omap_hdmi;
int ret;
 
+   if (!pdata) {
+   dev_err(dev, No platform data, bailing out\n);
+   return -ENODEV;
+   }
+
card-dev = pdev-dev;
 
+   omap_hdmi_dai.cpu_dai_name =
+   devm_kstrdup(dev, pdata-cpudai_name, GFP_KERNEL);
+   omap_hdmi_dai.platform_name =
+   devm_kstrdup(dev, pdata-cpudai_name, GFP_KERNEL);
+   omap_hdmi_dai.codec_name =
+   devm_kstrdup(dev, pdata-codec_name, GFP_KERNEL);
+
ret = snd_soc_register_card(card);
if (ret) {
-   dev_err(pdev-dev, snd_soc_register_card failed (%d)\n, ret);
+   dev_err(dev, snd_soc_register_card failed (%d)\n, ret);
card-dev = NULL;
return ret;
}
-- 
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 10/13] OMAPDSS: hdmi4: Register HDMI audio ASoC drivers from HDMI driver

The registering is best done here to share the resources owned by OMAPDSS
HDMI driver with ASoC DAI and platform drivers.

Signed-off-by: Jyri Sarha jsa...@ti.com
---
 drivers/video/fbdev/omap2/dss/hdmi4.c |   15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c 
b/drivers/video/fbdev/omap2/dss/hdmi4.c
index 626aad2..62ad1d9 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -52,6 +52,9 @@ static struct {
struct clk *sys_clk;
struct regulator *vdda_hdmi_dac_reg;
 
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+   struct hdmi_audio_data audio;
+#endif
bool core_enabled;
 
struct omap_dss_device output;
@@ -736,6 +739,15 @@ static int omapdss_hdmihw_probe(struct platform_device 
*pdev)
 
hdmi_init_output(pdev);
 
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+   r = hdmi_audio_register(pdev, hdmi.audio, hdmi.output, hdmi.wp);
+   if (r) {
+   DSSERR(Registering HDMI audio failed\n);
+   hdmi_uninit_output(pdev);
+   pm_runtime_disable(pdev-dev);
+   return r;
+   }
+#endif
dss_debugfs_create_file(hdmi, hdmi_dump_regs);
 
return 0;
@@ -743,6 +755,9 @@ static int omapdss_hdmihw_probe(struct platform_device 
*pdev)
 
 static int __exit omapdss_hdmihw_remove(struct platform_device *pdev)
 {
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+   hdmi_audio_unregister(hdmi.audio);
+#endif
hdmi_uninit_output(pdev);
 
pm_runtime_disable(pdev-dev);
-- 
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 08/13] ASoC: omap-hdmi: Changes for registeing the driver from OMAPDSS