Re: advanced LED controllers
On Mon, Mar 2, 2015 at 6:21 PM, Pavel Machek pa...@ucw.cz wrote: On Wed 2015-02-25 18:06:07, Alexandre Courbot wrote: On Wed, Feb 25, 2015 at 5:25 PM, Geert Uytterhoeven ge...@linux-m68k.org wrote: CC linux-gpio, as this looks like the LED equivalent of bulk gpio? Indeed. The LED core could implement something similar to gpiod_set_array() to allow several LEDs to be set in one call. If the controller supports it, it would then set all the LEDs at once, otherwise the core would apply the values serially. In leds-gpio.c, this multiple LED setting could be implemented by a single call to gpiod_set_array() and the right thing would happen. Actually, there are two issues: some controlles can set all LEDs at once, and some can program pwm level smoothly using given program (and handle multiple leds in the process). In any case, that would be handled at the controller level and should work with a function similar to gpiod_set_array(), wouldn't it? -- 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] ASoC: omap-pcm: Allow only formats with 1, 2, and 4 byte physical size
On Tue, Mar 03, 2015 at 01:41:21PM +0200, Peter Ujfalusi wrote:
On 03/03/2015 01:28 PM, Jyri Sarha wrote:
sDMA support only transfer elements with 1, 2, and 4 byte physical
size. Initialize the pcm driver accordingly.
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Jyri Sarha jsa...@ti.com
---
sound/soc/omap/omap-pcm.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index f4b05bc..e49ee23 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -39,7 +39,7 @@
#define pcm_omap1510() 0
#endif
-static const struct snd_pcm_hardware omap_pcm_hardware = {
+static struct snd_pcm_hardware omap_pcm_hardware = {
.info = SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_MMAP_VALID |
SNDRV_PCM_INFO_INTERLEAVED |
@@ -53,6 +53,24 @@ static const struct snd_pcm_hardware omap_pcm_hardware =
{
.buffer_bytes_max = 128 * 1024,
};
+/* sDMA supports only 1, 2, and 4 byte transfer elements. */
+static void omap_pcm_limit_supported_formats(void)
+{
+ int i;
+
+ for (i = 0; i SNDRV_PCM_FORMAT_LAST; i++) {
+ switch (snd_pcm_format_physical_width(i)) {
+ case 8:
+ case 16:
+ case 32:
+ omap_pcm_hardware.formats |= (1LL i);
+ break;
+ default:
+ break;
+ }
+ }
+}
+
I wonder why these are set in a loop instead of setting formats statically
and why this is needed after commit 60e21d287344 (ASoC: omap: Don't set
unused struct snd_pcm_hardware fields)?
--
Jarkko
--
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 2/6] mmc: omap_hsmmc: use slot-gpio functions to manage read-only pin directly
The indirection via omap_hsmmc_get_ro and omap_hsmmc_get_wp is
redundant. Also dropped setting gpio_wp to EINVAL since platform date
is read-only
Untested: no device with ro pin was available, but change is fairly
simple
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2276d58..77ad471 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -234,8 +234,6 @@ struct omap_hsmmc_host {
int card_detect_irq;
int (*card_detect)(struct device *dev);
- int (*get_ro)(struct device *dev);
-
};
struct omap_mmc_of_data {
@@ -252,13 +250,6 @@ static int omap_hsmmc_card_detect(struct device *dev)
return mmc_gpio_get_cd(host-mmc);
}
-static int omap_hsmmc_get_wp(struct device *dev)
-{
- struct omap_hsmmc_host *host = dev_get_drvdata(dev);
-
- return mmc_gpio_get_ro(host-mmc);
-}
-
static int omap_hsmmc_get_cover_state(struct device *dev)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -455,12 +446,9 @@ static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
}
if (gpio_is_valid(pdata-gpio_wp)) {
- host-get_ro = omap_hsmmc_get_wp;
ret = mmc_gpio_request_ro(mmc, pdata-gpio_wp);
if (ret)
return ret;
- } else {
- pdata-gpio_wp = -EINVAL;
}
return 0;
@@ -1637,15 +1625,6 @@ static int omap_hsmmc_get_cd(struct mmc_host *mmc)
return host-card_detect(host-dev);
}
-static int omap_hsmmc_get_ro(struct mmc_host *mmc)
-{
- struct omap_hsmmc_host *host = mmc_priv(mmc);
-
- if (!host-get_ro)
- return -ENOSYS;
- return host-get_ro(host-dev);
-}
-
static void omap_hsmmc_init_card(struct mmc_host *mmc, struct mmc_card *card)
{
struct omap_hsmmc_host *host = mmc_priv(mmc);
@@ -1811,7 +1790,7 @@ static struct mmc_host_ops omap_hsmmc_ops = {
.request = omap_hsmmc_request,
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
- .get_ro = omap_hsmmc_get_ro,
+ .get_ro = mmc_gpio_get_ro,
.init_card = omap_hsmmc_init_card,
.enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] mmc: omap_hsmmc: simplify cover/card detect logic
These patches are trying to clean up the cover/card detect logic. Mobile phones (some) have no card detect pin, but can detect if the cover is removed. The purpose is the same; detect if card is being added/removed, but the details differ. When the cover is removed, it does not mean the card is gone. But it might, since it is accessible now. It's like a warning. All the driver does is to limit write access to the card, see protect_card flag. In contrast, card detect notifies us after the fact, e.g. card is gone, card is inserted. While cover detect is only used by one platform (rx51), it complicates the card detect logic. By separating the code paths they both become easier to understand and maintain Patches have been tested by reverting: 95bebb5696ab 'mmc: omap_hsmmc: use mmc_of_parse to parse common mmc configuration' otherwise gpio detection is handled by mmc_of_parse compile tested OMAP2: CONFIG_MACH_OMAP2_TUSB6010=y CONFIG_MACH_OMAP3_BEAGLE=y CONFIG_MACH_DEVKIT8000=y CONFIG_MACH_OMAP_LDP=y CONFIG_MACH_OMAP3530_LV_SOM=y CONFIG_MACH_OMAP3_TORPEDO=y CONFIG_MACH_OVERO=y CONFIG_MACH_OMAP3517EVM=y CONFIG_MACH_CRANEBOARD=y CONFIG_MACH_OMAP3_PANDORA=y CONFIG_MACH_TOUCHBOOK=y CONFIG_MACH_OMAP_3430SDP=y CONFIG_MACH_NOKIA_N810=y CONFIG_MACH_NOKIA_N810_WIMAX=y CONFIG_MACH_NOKIA_N8X0=y CONFIG_MACH_NOKIA_RX51=y CONFIG_MACH_CM_T35=y CONFIG_MACH_CM_T3517=y CONFIG_MACH_CM_T3730=y CONFIG_MACH_SBC3530=y CONFIG_MACH_TI8168EVM=y CONFIG_MACH_TI8148EVM=y Andreas Fenkart (6): mmc: omap_hsmmc: remove unused fields from struct omap_hsmmc_host mmc: omap_hsmmc: use slot-gpio functions to manage read-only pin directly mmc: omap_hsmmc: use distinctive code paths for cover / card detect logic ARM: OMAP2: HSMMC: platform_data: explicit gpio_cover / gpio_cd fields mmc: omap_hsmmc: simplify card/cover detect isr mmc: omap_hsmmc: use generic slot-gpio isr to manage card detect pin arch/arm/mach-omap2/hsmmc.c | 33 + drivers/mmc/host/omap_hsmmc.c| 80 +--- include/linux/platform_data/hsmmc-omap.h | 6 +-- 3 files changed, 48 insertions(+), 71 deletions(-) -- 2.1.4 -- 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 1/6] mmc: omap_hsmmc: remove unused fields from struct omap_hsmmc_host
addon to: 09108968b7b72b6083a3bfc8f8259a74ed57255e
mmc: omap_hsmmc: remove prepare/complete system suspend support
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 8d87e08..2276d58 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -222,10 +222,6 @@ struct omap_hsmmc_host {
struct omap_hsmmc_next next_data;
struct omap_hsmmc_platform_data*pdata;
- /* To handle board related suspend/resume functionality for MMC */
- int (*suspend)(struct device *dev);
- int (*resume)(struct device *dev);
-
/* return MMC cover switch state, can be NULL if not supported.
*
* possible return values:
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] mmc: omap_hsmmc: simplify card/cover detect isr
strip the card dectet logic from cover detect isr and vice versa
the generic mmc_gpio_cd_irqt isr, uses 200ms on removal/insertion,
hence that should be fine here as well
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 27 +++
1 file changed, 3 insertions(+), 24 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ed68e55..4f6fbe5 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1239,21 +1239,11 @@ static void omap_hsmmc_protect_card(struct
omap_hsmmc_host *host)
static irqreturn_t omap_hsmmc_cover_irq(int irq, void *dev_id)
{
struct omap_hsmmc_host *host = dev_id;
- int carddetect;
sysfs_notify(host-mmc-class_dev.kobj, NULL, cover_switch);
- if (host-card_detect) {
- carddetect = host-card_detect(host-dev);
- } else {
- omap_hsmmc_protect_card(host);
- carddetect = -ENOSYS;
- }
-
- if (carddetect)
- mmc_detect_change(host-mmc, (HZ * 200) / 1000);
- else
- mmc_detect_change(host-mmc, (HZ * 50) / 1000);
+ omap_hsmmc_protect_card(host);
+ mmc_detect_change(host-mmc, (HZ * 200) / 1000);
return IRQ_HANDLED;
}
@@ -1263,19 +1253,8 @@ static irqreturn_t omap_hsmmc_cover_irq(int irq, void
*dev_id)
static irqreturn_t omap_hsmmc_detect(int irq, void *dev_id)
{
struct omap_hsmmc_host *host = dev_id;
- int carddetect;
-
- if (host-card_detect)
- carddetect = host-card_detect(host-dev);
- else {
- omap_hsmmc_protect_card(host);
- carddetect = -ENOSYS;
- }
- if (carddetect)
- mmc_detect_change(host-mmc, (HZ * 200) / 1000);
- else
- mmc_detect_change(host-mmc, (HZ * 50) / 1000);
+ mmc_detect_change(host-mmc, (HZ * 200) / 1000);
return IRQ_HANDLED;
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] mmc: omap_hsmmc: use distinctive code paths for cover / card detect logic
Mobile phones (some) have no card detect pin, but can detect if the
cover is removed. The purpose is the same; detect if card is being
added/removed, but the details differ.
When the cover is removed, it does not mean the card is gone. But it
might, since it is accessible now. It's like a warning. All the driver
does is to limit write access to the card, see protect_card flag.
In contrast, card detect notifies us after the fact, e.g.
card is gone, card is inserted. We can't take precautions, but we can
rely on those events, -- the card is really gone, or do scan the card.
To summarize there is not much code sharing between cover and card
detect, it only increases confusion. By splitting, both will be
simplified in a followup patch.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 56 +--
1 file changed, 38 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 77ad471..38239fb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -230,9 +230,6 @@ struct omap_hsmmc_host {
*/
int (*get_cover_state)(struct device *dev);
- /* Card detection IRQs */
- int card_detect_irq;
-
int (*card_detect)(struct device *dev);
};
@@ -422,6 +419,7 @@ static inline int omap_hsmmc_have_reg(void)
#endif
static irqreturn_t omap_hsmmc_detect(int irq, void *dev_id);
+static irqreturn_t omap_hsmmc_cover_irq(int irq, void *dev_id);
static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
struct omap_hsmmc_host *host,
@@ -429,20 +427,20 @@ static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
{
int ret;
- if (gpio_is_valid(pdata-switch_pin)) {
- if (pdata-cover)
- host-get_cover_state =
- omap_hsmmc_get_cover_state;
- else
- host-card_detect = omap_hsmmc_card_detect;
- host-card_detect_irq =
- gpio_to_irq(pdata-switch_pin);
- mmc_gpio_set_cd_isr(mmc, omap_hsmmc_detect);
+ if (pdata-cover gpio_is_valid(pdata-switch_pin)) {
ret = mmc_gpio_request_cd(mmc, pdata-switch_pin, 0);
if (ret)
return ret;
- } else {
- pdata-switch_pin = -EINVAL;
+
+ host-get_cover_state = omap_hsmmc_get_cover_state;
+ mmc_gpio_set_cd_isr(mmc, omap_hsmmc_cover_irq);
+ } else if (!pdata-cover gpio_is_valid(pdata-switch_pin)) {
+ ret = mmc_gpio_request_cd(mmc, pdata-switch_pin, 0);
+ if (ret)
+ return ret;
+
+ host-card_detect = omap_hsmmc_card_detect;
+ mmc_gpio_set_cd_isr(mmc, omap_hsmmc_detect);
}
if (gpio_is_valid(pdata-gpio_wp)) {
@@ -1236,15 +1234,37 @@ static void omap_hsmmc_protect_card(struct
omap_hsmmc_host *host)
}
/*
- * irq handler to notify the core about card insertion/removal
+ * irq handler when (cell-phone) cover is mounted/removed
*/
-static irqreturn_t omap_hsmmc_detect(int irq, void *dev_id)
+static irqreturn_t omap_hsmmc_cover_irq(int irq, void *dev_id)
{
struct omap_hsmmc_host *host = dev_id;
int carddetect;
sysfs_notify(host-mmc-class_dev.kobj, NULL, cover_switch);
+ if (host-card_detect) {
+ carddetect = host-card_detect(host-dev);
+ } else {
+ omap_hsmmc_protect_card(host);
+ carddetect = -ENOSYS;
+ }
+
+ if (carddetect)
+ mmc_detect_change(host-mmc, (HZ * 200) / 1000);
+ else
+ mmc_detect_change(host-mmc, (HZ * 50) / 1000);
+ return IRQ_HANDLED;
+}
+
+/*
+ * irq handler to notify the core about card insertion/removal
+ */
+static irqreturn_t omap_hsmmc_detect(int irq, void *dev_id)
+{
+ struct omap_hsmmc_host *host = dev_id;
+ int carddetect;
+
if (host-card_detect)
carddetect = host-card_detect(host-dev);
else {
@@ -2164,9 +2184,9 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
if (ret 0)
goto err_slot_name;
}
- if (host-card_detect_irq host-get_cover_state) {
+ if (host-get_cover_state) {
ret = device_create_file(mmc-class_dev,
- dev_attr_cover_switch);
+dev_attr_cover_switch);
if (ret 0)
goto err_slot_name;
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] ARM: OMAP2: HSMMC: platform_data: explicit gpio_cover / gpio_cd fields
Cover detection and card detection are not equivalent, cover detection
is like a warning that something might happen (cover removed, card is
accessible), card detection a notification that something has happened.
You could use both in parallel.
Technically this is not possible, since there is only one gpio for both
and a 'cover' flag to indicate either or. With this commit we push that
de-multiplexing of that gpio + flag out of the driver into the platform
specific init code.
It's not pushed down into omap2_hsmmc_info which is used to initialize
the platform data, since we would have to go over all board files
and set the new gpio_cover pin to -EINVAL. That would be dangerous
since '0' is a valid pin number.
FYI: only board-rx51 uses cover_only detection
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
arch/arm/mach-omap2/hsmmc.c | 33
drivers/mmc/host/omap_hsmmc.c| 11 ++-
include/linux/platform_data/hsmmc-omap.h | 6 ++
3 files changed, 33 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index dc6e79c..0e54aac 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -150,9 +150,13 @@ static int nop_mmc_set_power(struct device *dev, int
power_on, int vdd)
static inline void omap_hsmmc_mux(struct omap_hsmmc_platform_data
*mmc_controller, int controller_nr)
{
- if (gpio_is_valid(mmc_controller-switch_pin)
- (mmc_controller-switch_pin OMAP_MAX_GPIO_LINES))
- omap_mux_init_gpio(mmc_controller-switch_pin,
+ if (gpio_is_valid(mmc_controller-gpio_cd)
+ (mmc_controller-gpio_cd OMAP_MAX_GPIO_LINES))
+ omap_mux_init_gpio(mmc_controller-gpio_cd,
+ OMAP_PIN_INPUT_PULLUP);
+ if (gpio_is_valid(mmc_controller-gpio_cover)
+ (mmc_controller-gpio_cover OMAP_MAX_GPIO_LINES))
+ omap_mux_init_gpio(mmc_controller-gpio_cover,
OMAP_PIN_INPUT_PULLUP);
if (gpio_is_valid(mmc_controller-gpio_wp)
(mmc_controller-gpio_wp OMAP_MAX_GPIO_LINES))
@@ -250,15 +254,20 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
mmc-internal_clock = !c-ext_clock;
mmc-reg_offset = 0;
- mmc-switch_pin = c-gpio_cd;
+ if (c-cover_only) {
+ /* detect if mobile phone cover removed */
+ mmc-gpio_cd = -EINVAL;
+ mmc-gpio_cover = c-gpio_cd;
+ } else {
+ /* card detect pin on the mmc socket itself */
+ mmc-gpio_cd = c-gpio_cd;
+ mmc-gpio_cover = -EINVAL;
+ }
mmc-gpio_wp = c-gpio_wp;
mmc-remux = c-remux;
mmc-init_card = c-init_card;
- if (c-cover_only)
- mmc-cover = 1;
-
if (c-nonremovable)
mmc-nonremovable = 1;
@@ -358,7 +367,15 @@ void omap_hsmmc_late_init(struct omap2_hsmmc_info *c)
if (!mmc_pdata)
continue;
- mmc_pdata-switch_pin = c-gpio_cd;
+ if (c-cover_only) {
+ /* detect if mobile phone cover removed */
+ mmc_pdata-gpio_cd = -EINVAL;
+ mmc_pdata-gpio_cover = c-gpio_cd;
+ } else {
+ /* card detect pin on the mmc socket itself */
+ mmc_pdata-gpio_cd = c-gpio_cd;
+ mmc_pdata-gpio_cover = -EINVAL;
+ }
mmc_pdata-gpio_wp = c-gpio_wp;
res = omap_device_register(pdev);
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 38239fb..ed68e55 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -427,15 +427,15 @@ static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
{
int ret;
- if (pdata-cover gpio_is_valid(pdata-switch_pin)) {
- ret = mmc_gpio_request_cd(mmc, pdata-switch_pin, 0);
+ if (gpio_is_valid(pdata-gpio_cover)) {
+ ret = mmc_gpio_request_cd(mmc, pdata-gpio_cover, 0);
if (ret)
return ret;
host-get_cover_state = omap_hsmmc_get_cover_state;
mmc_gpio_set_cd_isr(mmc, omap_hsmmc_cover_irq);
- } else if (!pdata-cover gpio_is_valid(pdata-switch_pin)) {
- ret = mmc_gpio_request_cd(mmc, pdata-switch_pin, 0);
+ } else if (gpio_is_valid(pdata-gpio_cd)) {
+ ret = mmc_gpio_request_cd(mmc, pdata-gpio_cd, 0);
if (ret)
return ret;
@@ -1932,7 +1932,8 @@ static struct omap_hsmmc_platform_data
*of_get_hsmmc_pdata(struct device *dev)
if (of_find_property(np, ti,dual-volt, NULL))
pdata-controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
-
[PATCH 6/6] mmc: omap_hsmmc: use generic slot-gpio isr to manage card detect pin
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4f6fbe5..0c3368e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -418,7 +418,6 @@ static inline int omap_hsmmc_have_reg(void)
#endif
-static irqreturn_t omap_hsmmc_detect(int irq, void *dev_id);
static irqreturn_t omap_hsmmc_cover_irq(int irq, void *dev_id);
static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
@@ -440,7 +439,6 @@ static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
return ret;
host-card_detect = omap_hsmmc_card_detect;
- mmc_gpio_set_cd_isr(mmc, omap_hsmmc_detect);
}
if (gpio_is_valid(pdata-gpio_wp)) {
@@ -1247,17 +1245,6 @@ static irqreturn_t omap_hsmmc_cover_irq(int irq, void
*dev_id)
return IRQ_HANDLED;
}
-/*
- * irq handler to notify the core about card insertion/removal
- */
-static irqreturn_t omap_hsmmc_detect(int irq, void *dev_id)
-{
- struct omap_hsmmc_host *host = dev_id;
-
- mmc_detect_change(host-mmc, (HZ * 200) / 1000);
- return IRQ_HANDLED;
-}
-
static void omap_hsmmc_dma_callback(void *param)
{
struct omap_hsmmc_host *host = param;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC: omap-pcm: Allow only formats with 1, 2, and 4 byte physical size
On 03/03/2015 02:22 PM, Jarkko Nikula wrote:
On Tue, Mar 03, 2015 at 01:41:21PM +0200, Peter Ujfalusi wrote:
On 03/03/2015 01:28 PM, Jyri Sarha wrote:
sDMA support only transfer elements with 1, 2, and 4 byte physical
size. Initialize the pcm driver accordingly.
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Jyri Sarha jsa...@ti.com
---
sound/soc/omap/omap-pcm.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index f4b05bc..e49ee23 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -39,7 +39,7 @@
#define pcm_omap1510() 0
#endif
-static const struct snd_pcm_hardware omap_pcm_hardware = {
+static struct snd_pcm_hardware omap_pcm_hardware = {
.info = SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_MMAP_VALID |
SNDRV_PCM_INFO_INTERLEAVED |
@@ -53,6 +53,24 @@ static const struct snd_pcm_hardware omap_pcm_hardware =
{
.buffer_bytes_max = 128 * 1024,
};
+/* sDMA supports only 1, 2, and 4 byte transfer elements. */
+static void omap_pcm_limit_supported_formats(void)
+{
+ int i;
+
+ for (i = 0; i SNDRV_PCM_FORMAT_LAST; i++) {
+ switch (snd_pcm_format_physical_width(i)) {
+ case 8:
+ case 16:
+ case 32:
+ omap_pcm_hardware.formats |= (1LL i);
+ break;
+ default:
+ break;
+ }
+ }
+}
+
I wonder why these are set in a loop instead of setting formats statically
omap-pcm as such can work with any formats which has 1, 2 or 4 bytes layout in
memory (and not only S16_LE, S32_LE).
sDMA can not handle 3byte words so we can not handle those with omap-pcm. In
contrast eDMA for example can handle 1, 2, 3 and 4 w/o issue.
and why this is needed after commit 60e21d287344 (ASoC: omap: Don't set
unused struct snd_pcm_hardware fields)?
Hrm, interesting. We also have:
2d38df128321 (ASoC: generic-dmaengine-pcm: Prepare formats mask for valid
physical sample sizes)
Which does the same thing for the generic dmaengine pcm users.
Actually the information from the omap_pcm_hardware is copied to runtime.hw
via snd_soc_set_runtime_hwparams() call, so it is not ignored.
We need this masking to be done here since the omap-pcm is still mostly custom
code and do not plug easily to the generic code (ie, not at all).
--
Péter
--
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] ASoC: omap-pcm: Allow only formats with 1, 2, and 4 byte physical size
On 03/03/2015 02:22 PM, Jarkko Nikula wrote:
On Tue, Mar 03, 2015 at 01:41:21PM +0200, Peter Ujfalusi wrote:
On 03/03/2015 01:28 PM, Jyri Sarha wrote:
sDMA support only transfer elements with 1, 2, and 4 byte physical
size. Initialize the pcm driver accordingly.
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Jyri Sarha jsa...@ti.com
---
sound/soc/omap/omap-pcm.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index f4b05bc..e49ee23 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -39,7 +39,7 @@
#define pcm_omap1510()0
#endif
-static const struct snd_pcm_hardware omap_pcm_hardware = {
+static struct snd_pcm_hardware omap_pcm_hardware = {
.info = SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_MMAP_VALID |
SNDRV_PCM_INFO_INTERLEAVED |
@@ -53,6 +53,24 @@ static const struct snd_pcm_hardware omap_pcm_hardware = {
.buffer_bytes_max = 128 * 1024,
};
+/* sDMA supports only 1, 2, and 4 byte transfer elements. */
+static void omap_pcm_limit_supported_formats(void)
+{
+ int i;
+
+ for (i = 0; i SNDRV_PCM_FORMAT_LAST; i++) {
+ switch (snd_pcm_format_physical_width(i)) {
+ case 8:
+ case 16:
+ case 32:
+ omap_pcm_hardware.formats |= (1LL i);
+ break;
+ default:
+ break;
+ }
+ }
+}
+
I wonder why these are set in a loop instead of setting formats statically
and why this is needed after commit 60e21d287344 (ASoC: omap: Don't set
unused struct snd_pcm_hardware fields)?
Hmmm, interesting. The the problem I was trying to solve was read
error: Cannot allocate memory when trying to play S24_3LE format. With
this patch the error is more informative:
aplay: set_params:1233: Sample format non available
Available formats:
- S16_LE
- S24_LE
- S32_LE
So the comment of commit 60e21d287344 is not entirely true, as far as I
understand.
Best regards,
Jyri
--
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/8] ARM OMAP2+ GPMC: fixes and bus children
Robert, On 26/02/15 16:45, Robert ABEL wrote: These are the changes I proposed in three separate patchsets #([1], [2], [3]) rebased to 3.19 as well as new changes for little bugs I noticed while preparing this patchset. 1. DEBUG was undefined in source code -- remove offending lines 2. add capability to have busses as children of the GPMC and multiple devices on a bus. See [2] for an example DTS syntax. 3. debug output was unaligned -- align it 4. output for copy-pasting to DTS had erroneous timing outputs and made it hard to copy-paste -- correct timing values, add comments as DTS comments. 5. WAITMONITORINGTIME is expressed as GPMC_CLK cycles for all accesses. GPMCFCLKDIVIDER is used as a divider, so it must always be programmed. 6. GPMCFCLKDIVIDER is calculated according to WAITMONITORINGTIME for asynchronous accesses inside the driver -- asynchronous accesses now completely decoupled from gpmc,sync-clk-ps. 7. WAITMONITORINGTIME was being programmed/shown in GPMC_FCLK cycles instead of GPMC_CLK cycles -- add clock domain information where necessary. 8. Calculated values for WAITMONITORINGTIME and CLKACTIVATIONTIME that were outside the defined range would not raise an error. DEVICESIZE, ATTACHEDDEVICEPAGELENGTH, WAITMONITORINGTIME and CLKACTIVATIONTIME would not be marked as incorrect on DTS output. -- Fix all of these. [1]: https://lkml.org/lkml/2015/2/12/495 [2]: https://lkml.org/lkml/2015/2/16/337 [3]: https://lkml.org/lkml/2015/2/24/609 I'm OK with this version. Tony, after you ACK these I will queue them for v4.1. cheers, -roger Robert ABEL (9): ARM OMAP2+ GPMC: don't undef DEBUG ARM OMAP2+ GPMC: add bus children ARM OMAP2+ GPMC: fix debug output alignment ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER ARM OMAP2+ GPMC: calculate GPMCFCLKDIVIDER based on WAITMONITORINGTIME ARM OMAP2+ GPMC: fix WAITMONITORINGTIME divider bug ARM OMAP2+ GPMC: fix programming/showing reserved timing parameters arch/arm/mach-omap2/gpmc-nand.c| 17 +- arch/arm/mach-omap2/gpmc-onenand.c | 4 +- arch/arm/mach-omap2/usb-tusb6010.c | 4 +- drivers/memory/Makefile| 2 + drivers/memory/omap-gpmc.c | 313 + include/linux/omap-gpmc.h | 2 +- 6 files changed, 265 insertions(+), 77 deletions(-) -- 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/8] ARM OMAP2+ GPMC: fixes and bus children
Robert, On 26/02/15 16:45, Robert ABEL wrote: These are the changes I proposed in three separate patchsets #([1], [2], [3]) rebased to 3.19 as well as new changes for little bugs I noticed while preparing this patchset. 1. DEBUG was undefined in source code -- remove offending lines 2. add capability to have busses as children of the GPMC and multiple devices on a bus. See [2] for an example DTS syntax. 3. debug output was unaligned -- align it 4. output for copy-pasting to DTS had erroneous timing outputs and made it hard to copy-paste -- correct timing values, add comments as DTS comments. 5. WAITMONITORINGTIME is expressed as GPMC_CLK cycles for all accesses. GPMCFCLKDIVIDER is used as a divider, so it must always be programmed. 6. GPMCFCLKDIVIDER is calculated according to WAITMONITORINGTIME for asynchronous accesses inside the driver -- asynchronous accesses now completely decoupled from gpmc,sync-clk-ps. 7. WAITMONITORINGTIME was being programmed/shown in GPMC_FCLK cycles instead of GPMC_CLK cycles -- add clock domain information where necessary. 8. Calculated values for WAITMONITORINGTIME and CLKACTIVATIONTIME that were outside the defined range would not raise an error. DEVICESIZE, ATTACHEDDEVICEPAGELENGTH, WAITMONITORINGTIME and CLKACTIVATIONTIME would not be marked as incorrect on DTS output. -- Fix all of these. [1]: https://lkml.org/lkml/2015/2/12/495 [2]: https://lkml.org/lkml/2015/2/16/337 [3]: https://lkml.org/lkml/2015/2/24/609 I'm OK with this version. Tony, after you ACK these I will queue them for v4.1. cheers, -roger Robert ABEL (9): ARM OMAP2+ GPMC: don't undef DEBUG ARM OMAP2+ GPMC: add bus children ARM OMAP2+ GPMC: fix debug output alignment ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER ARM OMAP2+ GPMC: calculate GPMCFCLKDIVIDER based on WAITMONITORINGTIME ARM OMAP2+ GPMC: fix WAITMONITORINGTIME divider bug ARM OMAP2+ GPMC: fix programming/showing reserved timing parameters arch/arm/mach-omap2/gpmc-nand.c| 17 +- arch/arm/mach-omap2/gpmc-onenand.c | 4 +- arch/arm/mach-omap2/usb-tusb6010.c | 4 +- drivers/memory/Makefile| 2 + drivers/memory/omap-gpmc.c | 313 + include/linux/omap-gpmc.h | 2 +- 6 files changed, 265 insertions(+), 77 deletions(-) -- 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/10] initial clkdev cleanups
On Mon, 2015-03-02 at 13:50 -0800, Stephen Boyd wrote: On 03/02/15 09:05, Russell King - ARM Linux wrote: Here's some initial clkdev cleanups. These are targetted for the next merge window, and while the initial patches can be merged independently, I'd prefer to keep the series together as further work on solving the problems which unique struct clk's has introduced is needed. I'm also killing a chunk of seemingly unused code in the omap3isp driver. Lastly, I'm introducing a clkdev_create() helper, which combines the clkdev_alloc() + clkdev_add() pattern which keeps cropping up. We already have a solution to that problem with clk_register_clkdev(). Andy has done some work to make clk_register_clkdev() return a struct clk_lookup pointer[1]. Maybe we can do that instead of introducing a new clkdev_create() function. There is some benefit to having a new function though so that we can avoid a flag day, although it looks like the flag day is small in this case so it might not actually matter. [1] https://www.marc.info/?l=linux-kernelm=142469226512289 Agree with Stephen, why should we have the second function doing the same? Just name changing? I think you may just incorporate that patch into your series. -- Andy Shevchenko andriy.shevche...@intel.com Intel Finland Oy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] ARM OMAP2+ GPMC: add bus children
Hi Robert, On 27/02/15 17:08, Robert Abel wrote: Hi Roger, On Fri, Feb 27, 2015 at 11:24 AM, Roger Quadros rog...@ti.com wrote: + /* is child a common bus? */ + if (of_match_node(of_default_bus_match_table, child)) + /* create children and other common bus children */ + if (of_platform_populate(child, of_default_bus_match_table, NULL, pdev-dev)) + goto err_child_fail; this would print failed to create gpmc child but we have already created the gpmc child in the first of_platform_device_create() call. A more appropriate message would be failed to populate all children of child-name Also do you want to return failure? it will result in of_node_put() of the child and another print message about probing gpmc child %s failed in gpmc_probe_dt(). IMO if the GPMC node's child was created fine then we shouldn't return error. As of_platform_populate _always_ return 0 no matter what, the only way to reach that message is if probing the child failed. GPMCs child is already probed. It is the child's child we are talking about in of_platform_populate. As I cannot see into the future when of_platform_populate might actually be changed to return meaningful codes, we shouldn't try to foresee what the actual problem might be today either. This is a battle for another day. If that is the case then I'd rather not check for return value of of_platform_populate(). Failure in populating GPMC child's children is already out of scope of GPMC driver. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] ARM OMAP2+ GPMC: fixes and bus children
Hi Roger, On Tue, Mar 3, 2015 at 1:55 PM, Roger Quadros rog...@ti.com wrote: I'm OK with this version. Tony, after you ACK these I will queue them for v4.1. Please use v4 of my patches. The DTS output has been changed and the comments have their colon. Regards, Robert -- 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/9] N900 Modem Speech Support
Hi! This patchset contains the missing speech data support for the Nokia N900 modem. Userland access goes via /dev/cmt_speech. The API is implemented in libcmtspeechdata, which is used by ofono and the freesmartphone.org project. Apart from that the device is also used by the phone binaries distributed with Maemo. So while this is a new userland ABI for the mainline kernel it has been tested in the wild for some years. Simple Testing of the API can be done by checking out libcmtspeechdata [0], building the test tool and executing it. The tool will loop back audio data received from the caller. Tested-by: Pavel Machek pa...@ucw.cz Audio is borken on 4.0-rc1 on n900 mainline, so I used pulseaudio remote for a test. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: USB DMA IRQ issue
On Sat, Feb 28, 2015 at 3:57 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Sat, Feb 28, 2015 at 10:39:49PM +0100, Yegor Yefremov wrote:
On Tue, Feb 24, 2015 at 5:36 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Feb 05, 2015 at 12:19:23PM +0100, Yegor Yefremov wrote:
I have a problem with my am335x based board and USB.
Kernel: Linux version 3.18.1 (YegorYefremov@development1) (gcc version
4.9.2 (Buildroot 2015.02-git-00797-gf1b07c0) ) #1 SMP Thu Jan 15
15:31:27 CET 2015
I took two devices and equipped them with USB WLAN cards: Bus 001
Device 003: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless
Adapter. One device as AP and another as client. Client makes
permanent ping to AP. And from time to time I start nuttcp session.
After 2-3 days I get following errors:
2-3 days ? oh man... :-)
Here's one thing to try. Can you do some variable size pingtest ?
Something like below should do ?
random()
{
size=$(dd if=/dev/urandom count=1 2/dev/null|cksum|
cut -f1 -d |tr '-' '\0')
size=$(expr $size % 6)
}
num=$1
if [ -z $num ]
then
num=1
fi
while ! ifconfig usb0 /dev/null 21; do
printf waiting for usb0\n
sleep 1;
done
ifconfig usb0 192.168.2.14
for i in $(seq 1 $num); do
random
printf %d: \t pinging with size %-27d $i $size
if ! ping -c 6 192.168.2.15 -s $size -q -i 0 /dev/null 21; then
printf FAILED\n
break
fi
printf PASSED\n
done
Still haven't tried your test, but have seen this interesting
patch/proposal http://e2e.ti.com/support/arm/sitara_arm/f/791/t/404743.
Seems to be somehow related.
patch makes sense. If you can make sure it really solves your problem
then send it as a proper patch on top of my testing/next, I'd be glad.
FYI, the patch is posted here
http://marc.info/?l=linux-usbm=142526223500889w=2.
At some point, I'll just split dma callback into dedicated rx and tx
callbacks to avoid confusion in the future.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] media: omap3isp: remove unused clkdev
Hi Laurent, On Tue, Mar 03, 2015 at 02:39:14AM +0200, Laurent Pinchart wrote: Hi Russell, On Monday 02 March 2015 23:54:35 Russell King - ARM Linux wrote: (Combining replies...) On Tue, Mar 03, 2015 at 12:53:37AM +0200, Sakari Ailus wrote: Hi Laurent and Russell, On Tue, Mar 03, 2015 at 12:33:44AM +0200, Laurent Pinchart wrote: Sakari, does it conflict with the omap3isp DT support ? If so, how would you prefer to resolve the conflict ? Russell, would it be fine to merge this through Mauro's tree ? As other changes will depend on this, I'd prefer not to. The whole make clk_get() return a unique struct clk wasn't well tested, and several places broke - and currently clk_add_alias() is broken as a result of that. I'm trying to get to the longer term solution, where clkdev internally uses a struct clk_hw pointer rather than a struct clk pointer, and I want to clean stuff up first. If omap3isp needs to keep this code, then so be it - I'll come up with a different patch improving its use of clkdev instead. I'm totally fine with removing clkdev from the omap3isp driver if that's easier for you, I'm just concerned about the merge conflict that will result. There actually appears to be one more dependency, so four patches in total. What we could also do is to rebase the omap3isp DT support set on top of Russell's single patch. This way there probably would be no merge conflict, assuming the patches are exactly the same, and you have no other patches changing the omap3isp driver. Alternatively we could postpone the DT support for the omap3isp, but I'd rather want to avoid that. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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/4] usb: phy: twl4030: make runtime pm more reliable.
On Mon, 2 Mar 2015 22:03:59 +0100 Pavel Machek pa...@ucw.cz wrote: Hi! + status_changed = + (twl-linkstat == OMAP_MUSB_VBUS_VALID || +twl-linkstat == OMAP_MUSB_ID_GROUND) + != + (status == OMAP_MUSB_VBUS_VALID || +status == OMAP_MUSB_ID_GROUND); twl-linkstat = status; ... @@ -768,6 +770,10 @@ static int twl4030_usb_remove(struct platform_device *pdev) /* disable complete OTG block */ twl4030_usb_clear_bits(twl, POWER_CTRL, POWER_CTRL_OTG_ENAB); + + if (twl-linkstat == OMAP_MUSB_VBUS_VALID || + twl-linkstat == OMAP_MUSB_ID_GROUND) + pm_runtime_put_noidle(twl-dev); pm_runtime_mark_last_busy(twl-dev); inline function returning (x == OMAP_MUSB_VBUS_VALID || x == OMAP_MUSB_ID_GROUND) would really help readability here. Thanks, Pavel Good idea. I've done that. The function is called cable_present(). Thanks, NeilBrown pgpbO85e0cIau.pgp Description: OpenPGP digital signature
Re: [PATCH 08/15] twl4030_charger: distinguish between USB current and 'AC' current
On Mon, 2 Mar 2015 22:05:10 +0100 Pavel Machek pa...@ucw.cz wrote:
Hi!
The twl4030 charger has two current sources, 'USB' and 'AC' (which is
really DC of course...).
If 'AC' is providing current, we should set the current limit
differently to when it isn't (and so USB is used).
So split 'cur' into 'usb_cur' and 'ac_cur' and use accordingly.
Now we must review the current setting on any interrupt or USB
event which might indicate that the charger-source has changed.
Signed-off-by: NeilBrown ne...@suse.de
@@ -103,7 +104,9 @@ struct twl4030_bci {
/* ichg values in uA. If any are 'large', we set CGAIN to
ichg/_cur values
* '1' which doubles the range for half the precision.
*/
- int ichg_eoc, ichg_lo, ichg_hi, cur;
+ int ichg_eoc, ichg_lo, ichg_hi;
+ int usb_cur, ac_cur;
+ /* If VAC exceeds 4.5V (MADC 11) and ac is enabled, set current
+* for 'ac'
/*
* If AC voltage exceeds 4.5V (MADC 11) and AC is enabled, set current
* for 'ac'.
Acked-by: Pavel Machek pa...@ucw.cz
Thanks - I made those changes, or something much like them.
NeilBrown
pgpIpeDsG7pEg.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/4] usb: phy: twl4030: allow charger to see usb current draw limits.
On Mon, 2 Mar 2015 22:03:55 +0100 Pavel Machek pa...@ucw.cz wrote:
On Tue 2015-02-24 14:40:37, NeilBrown wrote:
The charger needs to know when a USB gadget has been enumerated
and what the agreed maximum current was so that it can adjust
charging accordingly.
So define a set_power() function to record the permitted
draw, and pass a pointer to that when sending USB_EVENT_ENUMERATED
notification.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/phy/phy-twl4030-usb.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 97c59074233f..023fe150c7a1 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -163,6 +163,11 @@ struct twl4030_usb {
enum omap_musb_vbus_id_status linkstat;
boolvbus_supplied;
+ /* Permitted vbus draw - only meaningful after
add in mA?
+* USB_EVENT_ENUMERATED
+*/
+ unsignedvbus_draw;
+
struct delayed_work id_workaround_work;
Yes. I make it 'unsigned int' too.
Thanks,
NeilBrown
pgpnzygiI3oWb.pgp
Description: OpenPGP digital signature
[PATCH 2/2] pinctrl: Introduce TI IOdelay configuration driver
SoC family such as DRA7 family of processors have, in addition
to the regular muxing of pins (as done by pinctrl-single), an
additional hardware module called IODelay which is also expected to be
configured. This IODelay module has it's own register space that is
independent of the control module.
It is advocated strongly in TI's official documentation considering
the existing design of the DRA7 family of processors during mux or
IODelay reconfiguration, there is a potential for a significant glitch
which may cause functional impairment to certain hardware. It is
hence recommended to do as little of muxing as absolutely necessary
without I/O isolation (which can only be done in initial stages of
bootloader).
NOTE: with the system wide I/O isolation scheme present in DRA7 SoC
family, it is not reasonable to do stop all I/O operations for every
such pad configuration scheme. So, we will let it glitch when used in
this mode.
Even with the above limitation, certain functionality such as MMC has
mandatory need for IODelay reconfiguration requirements, depending on
speed of transfer. In these cases, with careful examination of usecase
involved, the expected glitch can be controlled such that it does not
impact functionality.
In short, IODelay module support as a padconf driver being introduced
here is not expected to do SoC wide I/O Isolation and is meant for
a limited subset of IODelay configuration requirements that need to
be dynamic and whose glitchy behavior will not cause functionality
failure for that interface.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/pinctrl/Kconfig | 11 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/pinctrl-ti-iodelay.c | 963 ++
include/dt-bindings/pinctrl/dra.h|6 +
4 files changed, 981 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-ti-iodelay.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ee9f44ad7f02..8e463d75fbb2 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -160,6 +160,17 @@ config PINCTRL_TEGRA_XUSB
select PINCONF
select PINMUX
+config PINCTRL_TI_IODELAY
+ bool TI IODelay Module pinconf driver
+ depends on OF
+ select PINCONF
+ select GENERIC_PINCONF
+ select REGMAP_MMIO
+ help
+ Say Y here to support Texas Instruments' IODelay pinconf driver.
+ IODelay module is used for the DRA7 SoC family. This driver is in
+ addition to PINCTRL_SINGLE which controls the mux.
+
config PINCTRL_TZ1090
bool Toumaz Xenif TZ1090 pin control driver
depends on SOC_TZ1090
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 0475206dd600..e441cd71aedf 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_PINCTRL_TEGRA30) += pinctrl-tegra30.o
obj-$(CONFIG_PINCTRL_TEGRA114) += pinctrl-tegra114.o
obj-$(CONFIG_PINCTRL_TEGRA124) += pinctrl-tegra124.o
obj-$(CONFIG_PINCTRL_TEGRA_XUSB) += pinctrl-tegra-xusb.o
+obj-$(CONFIG_PINCTRL_TI_IODELAY) += pinctrl-ti-iodelay.o
obj-$(CONFIG_PINCTRL_TZ1090) += pinctrl-tz1090.o
obj-$(CONFIG_PINCTRL_TZ1090_PDC) += pinctrl-tz1090-pdc.o
obj-$(CONFIG_PINCTRL_U300) += pinctrl-u300.o
diff --git a/drivers/pinctrl/pinctrl-ti-iodelay.c
b/drivers/pinctrl/pinctrl-ti-iodelay.c
new file mode 100644
index ..e4c6e25a781c
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-ti-iodelay.c
@@ -0,0 +1,963 @@
+/*
+ * Support for configuration of IO Delay module found on Texas Instruments SoCs
+ * such as DRA7
+ *
+ * Copyright (C) 2015 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+#include linux/err.h
+#include linux/init.h
+#include linux/io.h
+#include linux/list.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/of.h
+#include linux/pinctrl/pinconf-generic.h
+#include linux/pinctrl/pinconf.h
+#include linux/pinctrl/pinctrl.h
+#include linux/regmap.h
+#include linux/slab.h
+
+#define IODELAY_REG_NAME_LEN ((sizeof(u32) * 2) + 3)
+#define DRIVER_NAMEti-io-delay
+/* Should I change this? Abuse? */
+#define IODELAY_MUX_PINS_NAME pinctrl-single,pins
+
+/* Device tree match, populated later */
+static const struct of_device_id ti_iodelay_of_match[];
+
+/**
+ * struct ti_iodelay_conf_vals - Description of each configuration parameters.
+ * @offset:Configuration register offset
+ * @a_delay: Agnostic Delay (in ps)
+ * @g_delay: Gnostic Delay (in ps)
+ */
+struct ti_iodelay_conf_vals {
+ u16 offset;
+ u16 a_delay;
+ u16 g_delay;
+};
+
+/**
+ * struct ti_iodelay_reg_data - Describes the registers for the IOdelay
instance
+ * @signature_mask:Conf reg-
Re: [PATCH 07/15] twl4030_charger: allow fine control of charger current.
On Mon, 2 Mar 2015 22:05:01 +0100 Pavel Machek pa...@ucw.cz wrote: Hi! + /* ichg values in uA. If any are 'large', we set CGAIN to +* '1' which doubles the range for half the precision. +*/ + int ichg_eoc, ichg_lo, ichg_hi, cur; We should really get uA_t. Maybe. 32bits allows for 4000A, which should be plenty... I made it unsigned int. [Plus, this is not kernel comment style, but...] Fixed + /* For ichg_eoc, reg value must be 100000, we only +* set the in high nibble. +*/ Confused. High nibble is 0xf0, right? does this help? /* * For ichg_eoc, the hardware only supports reg values matching * 100000, and requires the be stored in the high nibble * of TWL4030_BCIMFTH8 */ + /* And finally, set the current. This is stored in +* two registers. */ + reg = ua2regval(bci-cur, cgain); + /* we have only 10 bit */ bits @@ -562,6 +698,14 @@ static int __init twl4030_bci_probe(struct platform_device *pdev) if (!pdata) pdata = twl4030_bci_parse_dt(pdev-dev); + bci-ichg_eoc = 80100; /* Stop charging when current drops to here */ + bci-ichg_lo = 241000; /* low threshold */ Low + bci-ichg_hi = 50; /* High threshold */ Acked-by: Pavel Machek pa...@ucw.cz Thanks again! NeilBrown pgp0d5hnlrrkh.pgp Description: OpenPGP digital signature
Re: [Gta04-owner] [PATCH 3/4] usb: phy: twl4030: add support for reading restore on ID pin.
Am 04.03.2015 um 07:35 schrieb NeilBrown ne...@suse.de:
On Mon, 2 Mar 2015 22:04:31 +0100 Pavel Machek pa...@ucw.cz wrote:
Hi!
The twl4030 phy can measure, with low precision, the
resistance-to-ground of the ID pin.
Add a function to read the value, and export the result
via sysfs.
If the read fails, which it does sometimes, try again in 50msec.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/phy/phy-twl4030-usb.c | 63
+
1 file changed, 63 insertions(+)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 023fe150c7a1..759950898df9 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -374,6 +374,56 @@ static void twl4030_i2c_access(struct twl4030_usb
*twl, int on)
}
}
+enum twl4030_id_status {
+ TWL4030_GROUND,
+ TWL4030_102K,
+ TWL4030_200K,
+ TWL4030_440K,
+ TWL4030_FLOATING,
+ TWL4030_ID_UNKNOWN,
+};
+static char *twl4030_id_names[] = {
+ ground,
+ 102k,
+ 200k,
+ 440k,
New /sys files should be documented somewhere...?
Preferably with the code...
Does it make sense to change 440k - 440KOhm?
Interesting question. I prefer to avoid including units in files - bare
numbers is better. But there is no number to match floating unless I spell
it out as infinity, and wouldn't be helpful.
Certainly K would be preferred over k“,
The international standard for kilo = 1000 is a lower case k.
While it is (non-standard) to use K for 1024:
http://en.wikipedia.org/wiki/Kilobyte
So I would keep the string constants lower case to avoid this potential
confusion.
and given that I have ground
and floating, it is more consistent to include the Ohm
These are really names, not measures of resistance. The data sheet calls
them:
ID_RES_FLOAT (or sometimes ID_FLOAT)
ID_RES_440K
ID_RES_200K
ID_RES_102K
ID_GND(or sometimes ID_RES_GND)
So using those names is defensible.
I think I'll change them all to upper case, but leave out the Ohm.
My justification is consistency with the data sheet.
Plus I guess you need to update Documentation/
I guess I'll need to give in to this eventually :-)
Acked-by: Pavel Machek pa...@ucw.cz
Thanks,
NeilBrown
___
Gta04-owner mailing list
gta04-ow...@goldelico.com
http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
--
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 4/4] usb: phy: twl4030: test ID resistance to see if charger is present.
On Mon, 2 Mar 2015 22:04:44 +0100 Pavel Machek pa...@ucw.cz wrote:
On Tue 2015-02-24 14:40:37, NeilBrown wrote:
If an 'A' plug is inserted, ID should be pulled to ground.
If a 'B' plug, then ID should be floating.
If an Accessory Charger Adapter is inserted, then ID will
be neither grounded nor floating. In this case tell the
USB subsystem that it is an A plug, and the battery
charging subsystem that it is a charger.
Fortunately, this will treat the Openmoko charger (and
other similar chargers) as a charger.
Signed-off-by: NeilBrown ne...@suse.de
I guess signed-off-by should be real name, so I'd add a space..
This is how I always sign-off my name (2858 times in git log) so I don't
think I'll change it now.
Acked-by: Pavel Machek pa...@ucw.cz
Thanks.
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -596,9 +596,31 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
struct twl4030_usb *twl = _twl;
enum omap_musb_vbus_id_status status;
bool status_changed = false;
+ bool found_charger = false;
status = twl4030_usb_linkstat(twl);
+ if (status == OMAP_MUSB_ID_GROUND ||
+ status == OMAP_MUSB_VBUS_VALID) {
+ /* We should check the resistance on the ID pin.
+* If not a Ground or Floating, then this is
+* likely a charger
charger., and I guess kernel comments should have /* on separate line.
Yep.
So it will draw .5A from the charger? 1A? 2A?
Pavel
That is up to the charger driver. The phy just detects what is there, it
doesn't decide what to do with it.
Thanks,
NeilBrown
pgpJgxw0afmzg.pgp
Description: OpenPGP digital signature
Re: [PATCH 11/15] twl4030_charger: enable manual enable/disable of usb charging.
On Mon, 2 Mar 2015 22:03:42 +0100 Pavel Machek pa...@ucw.cz wrote:
On Tue 2015-02-24 15:33:52, NeilBrown wrote:
'off' or 'auto' to
/sys/class/power/twl4030_usb/mode
will now enable or disable charging from USB port. Normally this is
enabled on 'plug' and disabled on 'unplug'.
Unplug will still disable charging. 'plug' will only enable it if
'auto' if selected.
This should go to Documentation/
You mean in Documentation/ABI/stable I guess??
That strikes me as a failed experiment - there is hardly anything there.
I'd be very happy to put the documentation with the code if there was some
mechanism to automatically extract it. But I really see little value in
Documentation/ABI.
Or did you mean somewhere else?
Signed-off-by: NeilBrown ne...@suse.de
Conflicts:
drivers/power/twl4030_charger.c
Is it supposed to be here?
ah, no. Gone now. Thanks.
diff --git a/drivers/power/twl4030_charger.c
b/drivers/power/twl4030_charger.c
index 01090a440583..19e8dbb1303e 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -107,6 +107,9 @@ struct twl4030_bci {
int ichg_eoc, ichg_lo, ichg_hi;
int usb_cur, ac_cur;
boolac_is_active;
+ int usb_mode; /* charging mode requested */
+#defineCHARGE_OFF 0
+#defineCHARGE_AUTO 1
unsigned long event;
};
@@ -377,6 +380,8 @@ static int twl4030_charger_enable_usb(struct
twl4030_bci *bci, bool enable)
{
int ret;
n + if (bci-usb_mode == CHARGE_OFF)
+ enable = false;
Sometimes, you use = false and sometimes = 0 when assigning to bools...
I found a fixed a few - thanks.
@@ -629,6 +634,54 @@ static int twl4030_bci_usb_ncb(struct notifier_block
*nb, unsigned long val,
return NOTIFY_OK;
}
+/*
+ * sysfs charger enabled store
+ */
+static char *modes[] = { off, auto };
I'd move this before the comment. Or better near struct twl4030_bci.
Makes sense. Done. Thanks.
+static DEVICE_ATTR(mode, 0644, twl4030_bci_mode_show,
+ twl4030_bci_mode_store);
+
static int twl4030_charger_get_current(void)
{
int curr;
@@ -799,6 +852,7 @@ static int __init twl4030_bci_probe(struct
platform_device *pdev)
bci-usb_cur = 50; /* 500mA */
else
bci-usb_cur = 10; /* 100mA */
+ bci-usb_mode = CHARGE_AUTO;
bci-dev = pdev-dev;
bci-irq_chg = platform_get_irq(pdev, 0);
@@ -885,6 +939,8 @@ static int __init twl4030_bci_probe(struct
platform_device *pdev)
twl4030_charger_update_current(bci);
if (device_create_file(bci-usb.dev, dev_attr_max_current))
dev_warn(pdev-dev, could not create sysfs file\n);
+ if (device_create_file(bci-usb.dev, dev_attr_mode))
+ dev_warn(pdev-dev, could not create sysfs file\n);
if (device_create_file(bci-ac.dev, dev_attr_max_current))
dev_warn(pdev-dev, could not create sysfs file\n);
@@ -917,6 +973,7 @@ static int __exit twl4030_bci_remove(struct
platform_device *pdev)
device_remove_file(bci-usb.dev, dev_attr_max_current);
device_remove_file(bci-ac.dev, dev_attr_max_current);
+ device_remove_file(bci-usb.dev, dev_attr_mode);
move the line above for consistency with create?
Yep.
Acked-by: Pavel Machek pa...@ucw.cz
Thanks a lot!
NeilBrown
pgpcgY61j9ce8.pgp
Description: OpenPGP digital signature
Re: [PATCH 3/4] usb: phy: twl4030: add support for reading restore on ID pin.
On Mon, 2 Mar 2015 22:04:31 +0100 Pavel Machek pa...@ucw.cz wrote:
Hi!
The twl4030 phy can measure, with low precision, the
resistance-to-ground of the ID pin.
Add a function to read the value, and export the result
via sysfs.
If the read fails, which it does sometimes, try again in 50msec.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/phy/phy-twl4030-usb.c | 63
+
1 file changed, 63 insertions(+)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 023fe150c7a1..759950898df9 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -374,6 +374,56 @@ static void twl4030_i2c_access(struct twl4030_usb
*twl, int on)
}
}
+enum twl4030_id_status {
+ TWL4030_GROUND,
+ TWL4030_102K,
+ TWL4030_200K,
+ TWL4030_440K,
+ TWL4030_FLOATING,
+ TWL4030_ID_UNKNOWN,
+};
+static char *twl4030_id_names[] = {
+ ground,
+ 102k,
+ 200k,
+ 440k,
New /sys files should be documented somewhere...?
Preferably with the code...
Does it make sense to change 440k - 440KOhm?
Interesting question. I prefer to avoid including units in files - bare
numbers is better. But there is no number to match floating unless I spell
it out as infinity, and wouldn't be helpful.
Certainly K would be preferred over k, and given that I have ground
and floating, it is more consistent to include the Ohm
These are really names, not measures of resistance. The data sheet calls
them:
ID_RES_FLOAT (or sometimes ID_FLOAT)
ID_RES_440K
ID_RES_200K
ID_RES_102K
ID_GND(or sometimes ID_RES_GND)
So using those names is defensible.
I think I'll change them all to upper case, but leave out the Ohm.
My justification is consistency with the data sheet.
Plus I guess you need to update Documentation/
I guess I'll need to give in to this eventually :-)
Acked-by: Pavel Machek pa...@ucw.cz
Thanks,
NeilBrown
pgpAdjFjGRGQh.pgp
Description: OpenPGP digital signature
Re: [PATCH 01/10] media: omap3isp: remove unused clkdev
Hi Russell, On Mon, Mar 02, 2015 at 11:54:35PM +, Russell King - ARM Linux wrote: (Combining replies...) On Tue, Mar 03, 2015 at 12:53:37AM +0200, Sakari Ailus wrote: Hi Laurent and Russell, On Tue, Mar 03, 2015 at 12:33:44AM +0200, Laurent Pinchart wrote: Sakari, does it conflict with the omap3isp DT support ? If so, how would you prefer to resolve the conflict ? Russell, would it be fine to merge this through Mauro's tree ? As other changes will depend on this, I'd prefer not to. The whole make clk_get() return a unique struct clk wasn't well tested, and several places broke - and currently clk_add_alias() is broken as a result of that. I'm trying to get to the longer term solution, where clkdev internally uses a struct clk_hw pointer rather than a struct clk pointer, and I want to clean stuff up first. If omap3isp needs to keep this code, then so be it - I'll come up with a different patch improving its use of clkdev instead. I discussed this with Laurent and the two options we thought are - You provide a stable branch on which I can rebase the patches, in order to avoid a merge conflict or - We ignore the conflict and let Stephen Rothwell handle it. The conflict itself is relatively simple to resolve. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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
rmk's taking it easy for a while
For those who haven't read my post on google+, here's the news. Today, I had my impacted wisdom teeth out under a general anaesthetic. This means that I'm not going to be feeling right for a while, and I'm going to be taking things easy probably for the rest of this week. I'm on quite a high dosage of painkillers and anti-inflamatories, so whether I'm going to be doing anything kernel related is going to depend very much on how I feel day to day. Not only that, but eating a decent diet is going to be a problem for a while. What does this mean? Don't expect me to be responsive or coherent for a while as I struggle to get back to something resembling normality. I might tinker with a few patches, I might post some series, and if I do, do /not/ take that as a sign I'm back to normal - that'll probably be an attempt to relieve some of the boredom. Thanks. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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 0/2] pinctrl: Introduce support for iodelay module in TI SoCs
Hi, SoCs such as DRA7 family from Texas Instruments also include a highly configurable hardware block called the IOdelay block. This block allows very specific custom fine tuning for electrical characteristics of IO pins that are necessary for functionality and device lifetime requirements. IODelay module exists on it's own register space with registers allocated for various pins. A set of values (derived from either automated tools OR from device datasheet) is then computed on a per-chip basis(to account for die specific variations) to generate a set of delay parameters that are programmed to one or more registers for the delay path of the io line. This is used in specific instances such as MMC to achieve high-throughput modes, and most pins dont usually need tweaking functionality provided by this driver. Even though this kind of operates similar to a pinctrl model, functionally, it is a characteristics tuning which does not completely fit the standard pinconf model either. In addition to the regular pin muxing modes supported by the pinctrl-single, additional configuration for this block for specific pins may also be mandatory in certain cases. Series based on v4.0-rc1 Nishanth Menon (2): pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration pinctrl: Introduce TI IOdelay configuration driver .../bindings/pinctrl/ti,iodelay-pinctrl.txt| 86 ++ drivers/pinctrl/Kconfig| 11 + drivers/pinctrl/Makefile |1 + drivers/pinctrl/pinctrl-ti-iodelay.c | 963 include/dt-bindings/pinctrl/dra.h |6 + 5 files changed, 1067 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/ti,iodelay-pinctrl.txt create mode 100644 drivers/pinctrl/pinctrl-ti-iodelay.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] mmc: sdio: support switching to 1-bit before turning off clocks
* NeilBrown ne...@suse.de [150223 18:47]:
According to section 7.1.2 of
http://www.sandisk.com/media/File/OEM/Manuals/SD_SDIO_specsv1.pdf
In the case where the interrupt mechanism is used to wake the host while
the card is in a low power state (i.e. no clocks), Both the card and the
host shall be placed into the 1-bit SD mode prior to stopping the clock.
This is particularly important for the Marvell libertas wifi chip
in the GTA04. While in 4-bit mode it will only signal an interrupt
when the clock is running (which is why setting CLKEXTFREE is
important).
In 1-bit mode, the interrupt is asynchronous (explained in OMAP3
TRM description of the CIRQ flag to MMCHS_STAT:
In 1-bit mode, interrupt source is asynchronous (can be a source of
asynchronous wakeup).
In 4-bit mode, interrupt source is sampled during the interrupt
cycle.
)
It is awkward to simply set 1-bit mode in -runtime_suspend
as that will call mmc_set_ios which calls ops-set_ios(),
which will likely call pm_runtime_get_sync(), on the device that
is currently suspending. This deadlocks.
So:
- create a work_struct to schedule setting of 1-bit mode
- introduce an 'sdio_narrowed' state flag which transitions:
0 (normal) - 1 (convert to 1-bit pending) -
2 (have switch to 1-bit mode) - 0 (normal)
- create a function mmc_sdio_want_no_clocks() which can be called
when the driver wants to turn off clocks (presumably after an
idle timeout). This either succeeds (in 1-bit mode) or fails
and schedules the work to switch to 1-bit mode.
- when the host is claimed, if sdio_narrowed is 2, restore the
4-bit bus
- When the host is released, if sdio_narrowed is 1, then some
caller other than our worker claimed the host first, so
clear sdio_narrowed.
This all allows a graceful and race-free switch to 1-bit mode
before switching off the clocks, if SDIO interrupts are enabled.
A host should call mmc_sdio_want_no_clocks() when about to turn off
clocks if sdio interrupts are enabled, and the -disable() function
should not use a timeout (pm_runtime_put_autosuspend) if
-sdio_narrowed is 2.
Wow! A mystery finally solved for why libertas_sdio using devices
like overo won't work for the wakeirqs.. The interface has to be
in 1-bit mode for libertas to produce any SDIO interrupts..
Below is a patch enabling some more SDIO wakeirqs. Seems to work
on overo now too :) So tor the whole series, please feel free to
add:
Tested-by: Tony Lindgren t...@atomide.com
8 ---
From: Tony Lindgren t...@atomide.com
Date: Thu, 26 Feb 2015 16:16:03 -0800
Subject: [PATCH] ARM: dts: Fix omap3 SDIO wakeirqs for devices using
sdio_libertas
Turns out the the MMC interface needs to be in 1-bit mode for the
libertas card to send any SDIO interrupts as pointed out by
NeilBrown ne...@suse.de. Now that the MMC framework is getting
fixed for setting 1-bit mode for idle, we can enable SDIO wakeirqs
for libertas using devices too.
Cc: Andreas Fenkart afenk...@gmail.com
Cc: Ash Charles a...@gumstix.com
Cc: Florian Vaussard florian.vauss...@epfl.ch
Cc: NeilBrown n...@brown.name
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -367,6 +367,7 @@
};
mmc2 {
+ interrupts-extended = intc 86 omap3_pmx_core 0x12e;
vmmc-supply = vaux4;
bus-width = 4;
ti,non-removable;
--- a/arch/arm/boot/dts/omap3-overo-base.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-base.dtsi
@@ -185,6 +185,7 @@
mmc2 {
pinctrl-names = default;
pinctrl-0 = mmc2_pins;
+ interrupts-extended = intc 86 omap3_pmx_core 0x12e;
vmmc-supply = w3cbw003c_npoweron;
vqmmc-supply = w3cbw003c_bt_nreset;
vmmc_aux-supply = w3cbw003c_wifi_nreset;
--
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 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration
SoCs such as DRA7 family from Texas Instruments also include a highly
configurable hardware block called the IOdelay block. This block
allows very specific custom fine tuning for electrical characteristics
of IO pins.
In addition to the regular pin muxing modes supported by the
pinctrl-single, additional configuration for this block for specific
pins may also be mandatory in certain cases.
It is advocated strongly in TI's official documentation considering
the existing design of the DRA7 family of processors, which during mux
or IODelay reconfiguration, has a potential for a significant glitch
which may cause functional impairment to certain hardware. It is hence
recommended to do as little of muxing as absolutely necessary without
IO isolation (which can only be done in initial stages of bootloader).
Even with the above limitation, certain functionality such as MMC may
mandate the need of IODelay reconfiguration depending on speed of
transfer. Hence, introduce a new binding to facilitate programming the
same.
Signed-off-by: Nishanth Menon n...@ti.com
---
.../bindings/pinctrl/ti,iodelay-pinctrl.txt| 86
1 file changed, 86 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/ti,iodelay-pinctrl.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/ti,iodelay-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/ti,iodelay-pinctrl.txt
new file mode 100644
index ..e12f4e5a3f25
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/ti,iodelay-pinctrl.txt
@@ -0,0 +1,86 @@
+Texas Instruments I/O Delay module configuration pinctrl definition
+
+Used in conjunction with
Documentation/devicetree/bindings/pinctrl/ti,omap-pinctrl.txt
+
+Required Properties:
+- compatible: Should be:
+ ti,dra7-iodelay - I/O delay configuration for DRA7
+- reg - must be the register address range of IODelay module
+- #address-cells = 1;
+- #size-cells = 0;
+
+Important note: Use of ti,dra7-iodelay compatible definition need to be
+carefully evaluated due to the expectation of glitch during configuration.
+
+Example:
+
+dra7_iodelay_core: padconf@4844a000 {
+ compatible = ti,dra7-iodelay;
+ reg = 0x4844a000 0x0d1c;
+ #address-cells = 1;
+ #size-cells = 0;
+};
+
+Configuration definition follows similar model as the pinctrl-single:
+The groups of pin configuration are defined under pinctrl-single,pins
+
+dra7_iodelay_core {
+ mmc2_iodelay_3v3_conf: mmc2_iodelay_3v3_conf {
+ pinctrl-single,pins =
+ 0x18c (A_DELAY(0) | G_DELAY(120)) /*
CFG_GPMC_A19_IN */
+ 0x1a4 (A_DELAY(265) | G_DELAY(360)) /*
CFG_GPMC_A20_IN */
+ 0x1b0 (A_DELAY(0) | G_DELAY(120)) /*
CFG_GPMC_A21_IN */
+ 0x1bc (A_DELAY(0) | G_DELAY(120)) /*
CFG_GPMC_A22_IN */
+ 0x1c8 (A_DELAY(287) | G_DELAY(420)) /*
CFG_GPMC_A23_IN */
+ 0x1d4 (A_DELAY(144) | G_DELAY(240)) /*
CFG_GPMC_A24_IN */
+ 0x1e0 (A_DELAY(0) | G_DELAY(0)) /*
CFG_GPMC_A25_IN */
+ 0x1ec (A_DELAY(120) | G_DELAY(0)) /*
CFG_GPMC_A26_IN */
+ 0x1f8 (A_DELAY(120) | G_DELAY(180)) /*
CFG_GPMC_A27_IN */
+ 0x360 (A_DELAY(0) | G_DELAY(0)) /*
CFG_GPMC_CS1_IN */
+ ;
+ };
+};
+
+Usage in conjunction with pinctrl single:
+
+For a complete description of the pins both the regular muxing as well as the
+iodelay configuration is necessary. For example:
+
+dra7_pmx_core {
+ mmc2_pins_default: mmc2_pins_default {
+ pinctrl-single,pins =
+ 0x9c (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a23.mmc2_clk */
+ 0xb0 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_cs1.mmc2_cmd */
+ 0xa0 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a24.mmc2_dat0 */
+ 0xa4 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a25.mmc2_dat1 */
+ 0xa8 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a26.mmc2_dat2 */
+ 0xac (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a27.mmc2_dat3 */
+ 0x8c (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a19.mmc2_dat4 */
+ 0x90 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a20.mmc2_dat5 */
+ 0x94 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a21.mmc2_dat6 */
+ 0x98 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a22.mmc2_dat7 */
+ ;
+ };
+};
+
+dra7_iodelay_core {
+ mmc2_iodelay_3v3_conf: mmc2_iodelay_3v3_conf {
+ pinctrl-single,pins =
+ 0x18c (A_DELAY(0) | G_DELAY(120)) /*
CFG_GPMC_A19_IN */
+ 0x1a4
Re: [PATCH 3/4] mmc: sdio: support switching to 1-bit before turning off clocks
On Tue, 3 Mar 2015 14:53:55 -0800 Tony Lindgren t...@atomide.com wrote:
* NeilBrown ne...@suse.de [150223 18:47]:
According to section 7.1.2 of
http://www.sandisk.com/media/File/OEM/Manuals/SD_SDIO_specsv1.pdf
In the case where the interrupt mechanism is used to wake the host while
the card is in a low power state (i.e. no clocks), Both the card and the
host shall be placed into the 1-bit SD mode prior to stopping the clock.
This is particularly important for the Marvell libertas wifi chip
in the GTA04. While in 4-bit mode it will only signal an interrupt
when the clock is running (which is why setting CLKEXTFREE is
important).
In 1-bit mode, the interrupt is asynchronous (explained in OMAP3
TRM description of the CIRQ flag to MMCHS_STAT:
In 1-bit mode, interrupt source is asynchronous (can be a source of
asynchronous wakeup).
In 4-bit mode, interrupt source is sampled during the interrupt
cycle.
)
It is awkward to simply set 1-bit mode in -runtime_suspend
as that will call mmc_set_ios which calls ops-set_ios(),
which will likely call pm_runtime_get_sync(), on the device that
is currently suspending. This deadlocks.
So:
- create a work_struct to schedule setting of 1-bit mode
- introduce an 'sdio_narrowed' state flag which transitions:
0 (normal) - 1 (convert to 1-bit pending) -
2 (have switch to 1-bit mode) - 0 (normal)
- create a function mmc_sdio_want_no_clocks() which can be called
when the driver wants to turn off clocks (presumably after an
idle timeout). This either succeeds (in 1-bit mode) or fails
and schedules the work to switch to 1-bit mode.
- when the host is claimed, if sdio_narrowed is 2, restore the
4-bit bus
- When the host is released, if sdio_narrowed is 1, then some
caller other than our worker claimed the host first, so
clear sdio_narrowed.
This all allows a graceful and race-free switch to 1-bit mode
before switching off the clocks, if SDIO interrupts are enabled.
A host should call mmc_sdio_want_no_clocks() when about to turn off
clocks if sdio interrupts are enabled, and the -disable() function
should not use a timeout (pm_runtime_put_autosuspend) if
-sdio_narrowed is 2.
Wow! A mystery finally solved for why libertas_sdio using devices
like overo won't work for the wakeirqs.. The interface has to be
in 1-bit mode for libertas to produce any SDIO interrupts..
Below is a patch enabling some more SDIO wakeirqs. Seems to work
on overo now too :) So tor the whole series, please feel free to
add:
Tested-by: Tony Lindgren t...@atomide.com
Thanks a lot!
8 ---
From: Tony Lindgren t...@atomide.com
Date: Thu, 26 Feb 2015 16:16:03 -0800
Subject: [PATCH] ARM: dts: Fix omap3 SDIO wakeirqs for devices using
sdio_libertas
Turns out the the MMC interface needs to be in 1-bit mode for the
libertas card to send any SDIO interrupts as pointed out by
NeilBrown ne...@suse.de. Now that the MMC framework is getting
fixed for setting 1-bit mode for idle, we can enable SDIO wakeirqs
for libertas using devices too.
Cc: Andreas Fenkart afenk...@gmail.com
Cc: Ash Charles a...@gumstix.com
Cc: Florian Vaussard florian.vauss...@epfl.ch
Cc: NeilBrown n...@brown.name
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -367,6 +367,7 @@
};
mmc2 {
+ interrupts-extended = intc 86 omap3_pmx_core 0x12e;
vmmc-supply = vaux4;
bus-width = 4;
ti,non-removable;
I had
+ interrupts-extended = intc 86 gpio5 5 0; /* GPIO_133 */
+ pinctrl-names = default, idle;
+ pinctrl-0 = mmc2_pins;
+ pinctrl-1 = mmc2_cirq_pin;
together with
+ mmc2_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE4)
+ ;
+ };
+
and a longer definition for mmc2_pins.
Is that one line reconfigure the pin on demand? How does that work?
Thanks,
NeilBrown
pgpJ6LLS5NdnN.pgp
Description: OpenPGP digital signature
Re: [PATCH 0/6] mmc: omap_hsmmc: simplify cover/card detect logic
On Tue, 3 Mar 2015 13:28:12 +0100 Andreas Fenkart afenk...@gmail.com wrote: These patches are trying to clean up the cover/card detect logic. Mobile phones (some) have no card detect pin, but can detect if the cover is removed. The purpose is the same; detect if card is being added/removed, but the details differ. When the cover is removed, it does not mean the card is gone. But it might, since it is accessible now. It's like a warning. All the driver does is to limit write access to the card, see protect_card flag. In contrast, card detect notifies us after the fact, e.g. card is gone, card is inserted. While cover detect is only used by one platform (rx51), it complicates the card detect logic. By separating the code paths they both become easier to understand and maintain Patches have been tested by reverting: 95bebb5696ab 'mmc: omap_hsmmc: use mmc_of_parse to parse common mmc configuration' otherwise gpio detection is handled by mmc_of_parse Wouldn't it make more sense to put this core in mmc/core rather than in just one host controller? That way it would be available to all hosts, and you wouldn't need to revert that patch. NeilBrown pgplTpnSDXJsy.pgp Description: OpenPGP digital signature
Re: [PATCH 0/9] N900 Modem Speech Support
On Monday 02 March 2015 21:51:48 Sebastian Reichel wrote: Hi, On Mon, Mar 02, 2015 at 08:05:31PM +0100, Pali Rohár wrote: On Monday 02 March 2015 05:38:50 Sebastian Reichel wrote: This patchset contains the missing speech data support for the Nokia N900 modem. [...] Hello, do you have also DT patches? Or no DT changes are needed? No DT changes are needed. The DT already contains the n900-modem endpoint (look for compatible = nokia,n900-modem), which is handled by drivers/hsi/clients/nokia-modem.c. The nokia-modem driver currently takes care of gpios, irqs, pinctrl and loads ssi-protocol. After this patchset it also loads cmt-speech. Is this cmt_speech version one from linux-n900 git tree? or it is new or modified? The first 3 patches are from linux-n900 git tree, the other patches are cleanups and fixups for mainline. Some of those are partly available in the linux-n900 git tree. -- Sebastian Maybe in this case you can add my Tested-By as I tested code from linux-n900 git tree more times also with (modified) Maemo system. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 08/10] ARM: orion: use clkdev_create()
Dear Russell King,
On Mon, 02 Mar 2015 17:06:42 +, Russell King wrote:
clkdev_create() is a shorter way to write clkdev_alloc() followed by
clkdev_add(). Use this instead.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/plat-orion/common.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index f5b00f41c4f6..2235081a04ee 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -28,11 +28,7 @@
void __init orion_clkdev_add(const char *con_id, const char *dev_id,
struct clk *clk)
{
- struct clk_lookup *cl;
-
- cl = clkdev_alloc(clk, con_id, dev_id);
- if (cl)
- clkdev_add(cl);
+ clkdev_create(clk, con_id, %s, dev_id);
}
/* Create clkdev entries for all orion platforms except kirkwood.
Looks good, but instead of having orion_clkdev_add() being just an
alias for clkdev_create(), what about going ahead and simply reoving
orion_clkdev_add() entirely? Something like the below patch (not even
compile tested) :
diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 0d1a892..ec00183 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -109,28 +109,28 @@ static void __init dove_clk_init(void)
gephy = dove_register_gate(gephy, tclk, CLOCK_GATING_BIT_GIGA_PHY);
ge = dove_register_gate(ge, gephy, CLOCK_GATING_BIT_GBE);
- orion_clkdev_add(NULL, orion_spi.0, tclk);
- orion_clkdev_add(NULL, orion_spi.1, tclk);
- orion_clkdev_add(NULL, orion_wdt, tclk);
- orion_clkdev_add(NULL, mv64xxx_i2c.0, tclk);
-
- orion_clkdev_add(NULL, orion-ehci.0, usb0);
- orion_clkdev_add(NULL, orion-ehci.1, usb1);
- orion_clkdev_add(NULL, mv643xx_eth_port.0, ge);
- orion_clkdev_add(NULL, sata_mv.0, sata);
- orion_clkdev_add(0, pcie, pex0);
- orion_clkdev_add(1, pcie, pex1);
- orion_clkdev_add(NULL, sdhci-dove.0, sdio0);
- orion_clkdev_add(NULL, sdhci-dove.1, sdio1);
- orion_clkdev_add(NULL, orion_nand, nand);
- orion_clkdev_add(NULL, cafe1000-ccic.0, camera);
- orion_clkdev_add(NULL, mvebu-audio.0, i2s0);
- orion_clkdev_add(NULL, mvebu-audio.1, i2s1);
- orion_clkdev_add(NULL, mv_crypto, crypto);
- orion_clkdev_add(NULL, dove-ac97, ac97);
- orion_clkdev_add(NULL, dove-pdma, pdma);
- orion_clkdev_add(NULL, MV_XOR_NAME .0, xor0);
- orion_clkdev_add(NULL, MV_XOR_NAME .1, xor1);
+ clkdev_create(tclk, NULL, %s, orion_spi.0);
+ clkdev_create(tclk, NULL, %s, orion_spi.1);
+ clkdev_create(tclk, NULL, %s, orion_wdt);
+ clkdev_create(tclk, NULL, %s, mv64xxx_i2c.0);
+
+ clkdev_create(usb0, NULL, %s, orion-ehci.0);
+ clkdev_create(usb1, NULL, %s, orion-ehci.1);
+ clkdev_create(ge, NULL, %s, mv643xx_eth_port.0);
+ clkdev_create(sata, NULL, %s, sata_mv.0);
+ clkdev_create(pex0, 0, %s, pcie);
+ clkdev_create(pex1, 1, %s, pcie);
+ clkdev_create(sdio0, NULL, %s, sdhci-dove.0);
+ clkdev_create(sdio1, NULL, %s, sdhci-dove.1);
+ clkdev_create(nand, NULL, %s, orion_nand);
+ clkdev_create(camera, NULL, %s, cafe1000-ccic.0);
+ clkdev_create(i2s0, NULL, %s, mvebu-audio.0);
+ clkdev_create(i2s1, NULL, %s, mvebu-audio.1);
+ clkdev_create(crypto, NULL, %s, mv_crypto);
+ clkdev_create(ac97, NULL, %s, dove-ac97);
+ clkdev_create(pdma, NULL, %s, dove-pdma);
+ clkdev_create(xor0, NULL, %s, MV_XOR_NAME .0);
+ clkdev_create(xor1, NULL, %s, MV_XOR_NAME .1);
}
/*
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index f5b00f4..6ac3549 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -24,31 +24,20 @@
#include mach/bridge-regs.h
#include plat/common.h
-/* Create a clkdev entry for a given device/clk */
-void __init orion_clkdev_add(const char *con_id, const char *dev_id,
-struct clk *clk)
-{
- struct clk_lookup *cl;
-
- cl = clkdev_alloc(clk, con_id, dev_id);
- if (cl)
- clkdev_add(cl);
-}
-
/* Create clkdev entries for all orion platforms except kirkwood.
Kirkwood has gated clocks for some of its peripherals, so creates
its own clkdev entries. For all the other orion devices, create
clkdev entries to the tclk. */
void __init orion_clkdev_init(struct clk *tclk)
{
- orion_clkdev_add(NULL, orion_spi.0, tclk);
- orion_clkdev_add(NULL, orion_spi.1, tclk);
- orion_clkdev_add(NULL, MV643XX_ETH_NAME .0, tclk);
- orion_clkdev_add(NULL, MV643XX_ETH_NAME .1, tclk);
- orion_clkdev_add(NULL, MV643XX_ETH_NAME .2, tclk);
- orion_clkdev_add(NULL, MV643XX_ETH_NAME .3, tclk);
- orion_clkdev_add(NULL, orion_wdt, tclk);
-
Re: [PATCH 2/8] ARM OMAP2+ GPMC: add bus children
Hi Roger, On Tue, Mar 3, 2015 at 11:09 AM, Roger Quadros rog...@ti.com wrote: If that is the case then I'd rather not check for return value of of_platform_populate(). Failure in populating GPMC child's children is already out of scope of GPMC driver. Well, I'd rather leave it in for now. If something *does* break in the future, the user will at least get a message about it. Regards, Robert -- 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] ASoC: omap-pcm: Allow only formats with 1, 2, and 4 byte physical size
sDMA support only transfer elements with 1, 2, and 4 byte physical
size. Initialize the pcm driver accordingly.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
sound/soc/omap/omap-pcm.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index f4b05bc..e49ee23 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -39,7 +39,7 @@
#define pcm_omap1510() 0
#endif
-static const struct snd_pcm_hardware omap_pcm_hardware = {
+static struct snd_pcm_hardware omap_pcm_hardware = {
.info = SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_MMAP_VALID |
SNDRV_PCM_INFO_INTERLEAVED |
@@ -53,6 +53,24 @@ static const struct snd_pcm_hardware omap_pcm_hardware = {
.buffer_bytes_max = 128 * 1024,
};
+/* sDMA supports only 1, 2, and 4 byte transfer elements. */
+static void omap_pcm_limit_supported_formats(void)
+{
+ int i;
+
+ for (i = 0; i SNDRV_PCM_FORMAT_LAST; i++) {
+ switch (snd_pcm_format_physical_width(i)) {
+ case 8:
+ case 16:
+ case 32:
+ omap_pcm_hardware.formats |= (1LL i);
+ break;
+ default:
+ break;
+ }
+ }
+}
+
/* this may get called several times by oss emulation */
static int omap_pcm_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
@@ -235,6 +253,7 @@ static struct snd_soc_platform_driver omap_soc_platform = {
int omap_pcm_platform_register(struct device *dev)
{
+ omap_pcm_limit_supported_formats();
return devm_snd_soc_register_platform(dev, omap_soc_platform);
}
EXPORT_SYMBOL_GPL(omap_pcm_platform_register);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC: omap-pcm: Allow only formats with 1, 2, and 4 byte physical size
On 03/03/2015 01:28 PM, Jyri Sarha wrote:
sDMA support only transfer elements with 1, 2, and 4 byte physical
size. Initialize the pcm driver accordingly.
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Jyri Sarha jsa...@ti.com
---
sound/soc/omap/omap-pcm.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index f4b05bc..e49ee23 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -39,7 +39,7 @@
#define pcm_omap1510() 0
#endif
-static const struct snd_pcm_hardware omap_pcm_hardware = {
+static struct snd_pcm_hardware omap_pcm_hardware = {
.info = SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_MMAP_VALID |
SNDRV_PCM_INFO_INTERLEAVED |
@@ -53,6 +53,24 @@ static const struct snd_pcm_hardware omap_pcm_hardware = {
.buffer_bytes_max = 128 * 1024,
};
+/* sDMA supports only 1, 2, and 4 byte transfer elements. */
+static void omap_pcm_limit_supported_formats(void)
+{
+ int i;
+
+ for (i = 0; i SNDRV_PCM_FORMAT_LAST; i++) {
+ switch (snd_pcm_format_physical_width(i)) {
+ case 8:
+ case 16:
+ case 32:
+ omap_pcm_hardware.formats |= (1LL i);
+ break;
+ default:
+ break;
+ }
+ }
+}
+
/* this may get called several times by oss emulation */
static int omap_pcm_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
@@ -235,6 +253,7 @@ static struct snd_soc_platform_driver omap_soc_platform =
{
int omap_pcm_platform_register(struct device *dev)
{
+ omap_pcm_limit_supported_formats();
return devm_snd_soc_register_platform(dev, omap_soc_platform);
}
EXPORT_SYMBOL_GPL(omap_pcm_platform_register);
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 6/6] ARM: dts: am335x-boneblack: Use new binding for HDMI
On 02/03/15 19:42, Russell King - ARM Linux wrote: On Mon, Mar 02, 2015 at 07:08:39PM +0200, Tomi Valkeinen wrote: On 02/03/15 18:06, Russell King - ARM Linux wrote: This is missing the output of tda998x. It should have two ports, input and output, output going to hdmi-connector. We don't have that kind of level of modelling in DRM right now - as far as DRM is concerned, the tda998x is both the encoder _and_ the connector since it supplies both functionalities. That's fine, but these are DT bindings which should reflect the hardware, not the SW stack. I still don't buy your argument. The principle is right, but I think you're taking it too far. snip When we say DT should follow the hardware we're not talking about making DT be an alternative to the hardware's schematic. I agree, and that's not what I'm suggesting. We should only model HW in the DT when it makes sense, when it gives us something. A HDMI connector can have (at least) two functionalities that the driver for it may need to handle: HPD and +5V. On some SoCs/boards those are handled by the HDMI encoder, but I have boards where they are not. So we need to have the data somewhere, and a HDMI connector node at the end of the video path is a logical choice. The HDMI connector node is also a good place for a symbolic name which can be shown to the user. In this particular board, the HDMI encoder handles the HPD and the +5V is always enabled, so there's no strict need to have the HDMI connector node. However, I still feel it's better to have the HDMI connector in .dts: 1) It's not said that a HDMI encoder always has a HDMI connector as the next component. The next component could be a integrated panel, needing a specific driver and there's no HDMI connector at all. Or there could be something else, as is the case on some OMAP boards which have an ESD protection chip (that requires controlling, i.e. a driver) between the encoder and the connector. 2) I like that the beginning and the end of the video pipeline are clearly defined. A video pipeline starts at a display controller, and ends at a panel or a connector. This makes it easier to understand the .dts as you know what to expect. In the SW side these mean that every encoder (or whatever is doing this stuff) should be able to handle any component after the encoder, be it a connector, panel or something else. If we allow leaving out the connector node, the code also needs to handle the case when there's nothing after the encoder, which probably means fabricating some connector data (at least if and when DRM can handle arbitrary video pipelines). But as I said earlier, we can do just fine without the HDMI connector node on boards where the connector just works. We can handle that in the drivers with some extra code. So if people think it's a big chore to add the connectors and don't see the benefit in them (and they don't want the symbolic labels that could be added there), I'm fine with having them optional. Tomi signature.asc Description: OpenPGP digital signature
[PATCH] rtc: OMAP: Add external 32k clock feature
Add external 32k clock feature. The internal clock will be gated during suspend.
Hence make use of the external 32k clock so that rtc is functional accross
suspend/resume.
Signed-off-by: Keerthy j-keer...@ti.com
---
Tested on DRA7-EVM.
drivers/rtc/rtc-omap.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 8e5851a..4f803ca 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -107,6 +107,8 @@
/* OMAP_RTC_OSC_REG bit fields: */
#define OMAP_RTC_OSC_32KCLK_EN BIT(6)
+#define OMAP_RTC_OSC_OSC32K_GZ BIT(4)
+#define OMAP_RTC_OSC_EXT_32K BIT(3)
/* OMAP_RTC_IRQWAKEEN bit fields: */
#define OMAP_RTC_IRQWAKEEN_ALARM_WAKEENBIT(1)
@@ -120,6 +122,7 @@
struct omap_rtc_device_type {
bool has_32kclk_en;
+ bool has_osc_ext_32k;
bool has_kicker;
bool has_irqwakeen;
bool has_pmic_mode;
@@ -446,6 +449,7 @@ static const struct omap_rtc_device_type
omap_rtc_default_type = {
static const struct omap_rtc_device_type omap_rtc_am3352_type = {
.has_32kclk_en = true,
+ .has_osc_ext_32k = true,
.has_kicker = true,
.has_irqwakeen = true,
.has_pmic_mode = true,
@@ -543,7 +547,16 @@ static int __init omap_rtc_probe(struct platform_device
*pdev)
if (rtc-type-has_32kclk_en) {
reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
rtc_writel(rtc, OMAP_RTC_OSC_REG,
- reg | OMAP_RTC_OSC_32KCLK_EN);
+ reg | OMAP_RTC_OSC_32KCLK_EN);
+ }
+
+ /* Enable External clock as the source */
+
+ if (rtc-type-has_osc_ext_32k) {
+ rtc_writel(rtc, OMAP_RTC_OSC_REG,
+ (OMAP_RTC_OSC_EXT_32K |
+ rtc_read(rtc, OMAP_RTC_OSC_REG))
+ (~OMAP_RTC_OSC_OSC32K_GZ));
}
/* clear old status */
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
