Re: [PATCH 2/2] extcon: Fix extcon_cable_get_state() from getting old state after notification
Hi Roger,
On 07/06/2015 11:46 PM, Roger Quadros wrote:
> Currently the extcon code notifiers the interested listeners
> before it updates the extcon state with the new state.
> This will cause the listeners that use extcon_cable_get_state()
> to get the stale state and loose the new state.
>
> Fix this by first changing the extcon state variable and then
> notifying listeners.
>
> Signed-off-by: Roger Quadros
> ---
> drivers/extcon/extcon.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
Applied it.
Thanks,
Chanwoo Choi
>
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index 868c6e2..26d1e1e 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -275,19 +275,25 @@ int extcon_update_state(struct extcon_dev *edev, u32
> mask, u32 state)
> spin_lock_irqsave(&edev->lock, flags);
>
> if (edev->state != ((edev->state & ~mask) | (state & mask))) {
> + u32 old_state;
> +
> if (check_mutually_exclusive(edev, (edev->state & ~mask) |
> (state & mask))) {
> spin_unlock_irqrestore(&edev->lock, flags);
> return -EPERM;
> }
>
> + old_state = edev->state;
> + edev->state &= ~mask;
> + edev->state |= state & mask;
> +
> for (index = 0; index < edev->max_supported; index++) {
> - if (is_extcon_changed(edev->state, state, index,
> &attached))
> - raw_notifier_call_chain(&edev->nh[index],
> attached, edev);
> + if (is_extcon_changed(old_state, edev->state, index,
> + &attached))
> + raw_notifier_call_chain(&edev->nh[index],
> + attached, edev);
> }
>
> - edev->state &= ~mask;
> - edev->state |= state & mask;
>
> /* This could be in interrupt handler */
> prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] extcon: fix hang and extcon_get/set_cable_state().
Hi Roger,
I add minor comment about code clean.
After I modified it by myself, I applied it on extcon-fixes.
Best Regards,
Chanwoo Choi
On 07/07/2015 10:06 PM, Roger Quadros wrote:
> Users of find_cable_index_by_name() will cause a kernel hang
> as the while loop counter is never incremented and end condition
> is never reached.
>
> extcon_get_cable_state() and extcon_set_cable_state() are broken
> because they use cable index instead of cable id. This causes
> the first cable state (cable.0) to be always invalid in sysfs
> or extcon_get_cable_state() users.
>
> Introduce a new function find_cable_id_by_name() that fixes
> both of the above issues.
>
> Fixes: commit 73b6ecdb93e8 ("extcon: Redefine the unique id of supported
> external connectors without 'enum extcon' type")
> Cc: Greg Kroah-Hartman
> Signed-off-by: Roger Quadros
> ---
> drivers/extcon/extcon.c | 38 +-
> 1 file changed, 29 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index 76157ab..987dd3c 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -124,22 +124,34 @@ static int find_cable_index_by_id(struct extcon_dev
> *edev, const unsigned int id
> return -EINVAL;
> }
>
> -static int find_cable_index_by_name(struct extcon_dev *edev, const char
> *name)
> +static int find_cable_id_by_name(struct extcon_dev *edev, const char *name)
> {
> - unsigned int id = EXTCON_NONE;
> + unsigned int id = -EINVAL;
> int i = 0;
>
> - if (edev->max_supported == 0)
> - return -EINVAL;
> -
> - /* Find the the number of extcon cable */
> + /* Find the id of extcon cable */
> while (extcon_name[i]) {
> if (!strncmp(extcon_name[i], name, CABLE_NAME_MAX)) {
> id = i;
> break;
> }
> +
Remove blank line.
> + i++;
> }
>
> + return id;
> +};
> +
> +static int find_cable_index_by_name(struct extcon_dev *edev, const char
> *name)
> +{
> + unsigned int id = EXTCON_NONE;
> +
> + if (edev->max_supported == 0)
> + return -EINVAL;
> +
> + /* Find the the number of extcon cable */
> + id = find_cable_id_by_name(edev, name);
> +
> if (id == EXTCON_NONE)
> return -EINVAL;
>
> @@ -228,9 +240,11 @@ static ssize_t cable_state_show(struct device *dev,
> struct extcon_cable *cable = container_of(attr, struct extcon_cable,
> attr_state);
>
> + int i = cable->cable_index;
> +
> return sprintf(buf, "%d\n",
> extcon_get_cable_state_(cable->edev,
> -cable->cable_index));
> +
> cable->edev->supported_cable[i]));
> }
>
> /**
> @@ -341,6 +355,9 @@ int extcon_get_cable_state_(struct extcon_dev *edev,
> const unsigned int id)
> {
> int index;
>
> + if (id == EXTCON_NONE)
> + return -EINVAL;
> +
This if statement don't be necessary.
Instead, I check the error value on extcon_get_cable_state() by checking the
return value of find_cable_id_by_name().
> index = find_cable_index_by_id(edev, id);
> if (index < 0)
> return index;
> @@ -361,7 +378,7 @@ EXPORT_SYMBOL_GPL(extcon_get_cable_state_);
> */
> int extcon_get_cable_state(struct extcon_dev *edev, const char *cable_name)
> {
> - return extcon_get_cable_state_(edev, find_cable_index_by_name
> + return extcon_get_cable_state_(edev, find_cable_id_by_name
> (edev, cable_name));
I modified it as following:
unsigned int id;
id = find_cable_id_by_name(edev, cable_name);
if (id < 0)
return id;
return extcon_get_cable_state_(edev, id);
> }
> EXPORT_SYMBOL_GPL(extcon_get_cable_state);
> @@ -380,6 +397,9 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
> unsigned int id,
> u32 state;
> int index;
>
> + if (id == EXTCON_NONE)
> + return -EINVAL;
> +
ditto.
> index = find_cable_index_by_id(edev, id);
> if (index < 0)
> return index;
> @@ -404,7 +424,7 @@ EXPORT_SYMBOL_GPL(extcon_set_cable_state_);
> int extcon_set_cable_state(struct extcon_dev *edev,
> const char *cable_name, bool cable_state)
> {
> - return extcon_set_cable_state_(edev, find_cable_index_by_name
> + return extcon_set_cable_state_(edev, find_cable_id_by_name
> (edev, cable_name), cable_state);
ditto.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] serial: 8250: omap: restore registers on shutdown
Hi John,
On 07/30/2015 06:54 PM, John Ogness wrote:
> If DMA is active during a shutdown, a delayed restore of the
> registers may be pending. The restore must be performed after
> the DMA is stopped, otherwise the delayed restore remains
> pending and will fire upon the first DMA TX complete of a
> totally different serial session.
>
> Signed-off-by: John Ogness
> ---
> drivers/tty/serial/8250/8250_omap.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_omap.c
> b/drivers/tty/serial/8250/8250_omap.c
> index 5b39892..25f6255 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -657,9 +657,15 @@ static void omap_8250_shutdown(struct uart_port *port)
> up->ier = 0;
> serial_out(up, UART_IER, 0);
>
> - if (up->dma)
> + if (up->dma) {
> serial8250_release_dma(up);
>
> + if (priv->delayed_restore) {
> + priv->delayed_restore = 0;
> + omap8250_restore_regs(up);
> + }
I was never really a fan of the deferred set_termios();
I think it's more appropriate to wait for tx dma to
complete in omap_8250_set_termios().
Regards,
Peter Hurley
> + }
> +
> /*
>* Disable break condition and FIFOs
>*/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] serial: 8250: unlock port for uart_write_wakeup()
On 07/30/2015 07:15 PM, Peter Hurley wrote: > On 07/30/2015 06:54 PM, John Ogness wrote: >> uart_write_wakeup() should be called without holding the port lock. >> Otherwise a possible recursive spinlock issue can occur, such as >> the following callchain: >> >> 8250_core.c:serial8250_tx_chars() - called with port locked >> serial_core.c:uart_write_wakeup() >> tty_io.c:tty_wakeup() >>st_core.c:st_tty_wakeup() >> st_core.c:st_tx_wakeup() >> st_core.c:st_int_write() >> serial_core.c:uart_write() - locks port > > NAK. > > This is a bug in the N_TI_WL line discipline, specifically in the > st_tx_wakeup() function, which cannot perform the write synchronously. > > This is a common line discipline bug, and typically fixed by performing > the wakeup operations from a kworker instead. Also, seriously consider if you want to use that TI line discipline at all. If you're using it only for bluetooth w/ kernel bluetooth stack, you don't need btwilink + st_drv anyway. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] serial: 8250: move rx_running out of the bitfield
On 07/30/2015 06:54 PM, John Ogness wrote:
> That bitfield is modified by read + or + write operation. If someone
> sets any of the other two bits it might render the lock useless.
Good catch.
Let's just make all of the fields not bitfield though.
Regards,
Peter Hurley
> Signed-off-by: John Ogness
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/tty/serial/8250/8250.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
> index c43f74c..78f5e3a 100644
> --- a/drivers/tty/serial/8250/8250.h
> +++ b/drivers/tty/serial/8250/8250.h
> @@ -44,7 +44,7 @@ struct uart_8250_dma {
>
> unsigned char tx_running:1;
> unsigned char tx_err: 1;
> - unsigned char rx_running:1;
> + unsigned char rx_running;
> };
>
> struct old_serial_port {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] serial: 8250: unlock port for uart_write_wakeup()
On 07/30/2015 06:54 PM, John Ogness wrote: > uart_write_wakeup() should be called without holding the port lock. > Otherwise a possible recursive spinlock issue can occur, such as > the following callchain: > > 8250_core.c:serial8250_tx_chars() - called with port locked > serial_core.c:uart_write_wakeup() > tty_io.c:tty_wakeup() >st_core.c:st_tty_wakeup() > st_core.c:st_tx_wakeup() > st_core.c:st_int_write() > serial_core.c:uart_write() - locks port NAK. This is a bug in the N_TI_WL line discipline, specifically in the st_tx_wakeup() function, which cannot perform the write synchronously. This is a common line discipline bug, and typically fixed by performing the wakeup operations from a kworker instead. Regards, Peter Hurley -- 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/3] serial: 8250: move rx_running out of the bitfield
That bitfield is modified by read + or + write operation. If someone
sets any of the other two bits it might render the lock useless.
Signed-off-by: John Ogness
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index c43f74c..78f5e3a 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -44,7 +44,7 @@ struct uart_8250_dma {
unsigned char tx_running:1;
unsigned char tx_err: 1;
- unsigned char rx_running:1;
+ unsigned char rx_running;
};
struct old_serial_port {
--
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 3/3] serial: 8250: omap: restore registers on shutdown
If DMA is active during a shutdown, a delayed restore of the
registers may be pending. The restore must be performed after
the DMA is stopped, otherwise the delayed restore remains
pending and will fire upon the first DMA TX complete of a
totally different serial session.
Signed-off-by: John Ogness
---
drivers/tty/serial/8250/8250_omap.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 5b39892..25f6255 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -657,9 +657,15 @@ static void omap_8250_shutdown(struct uart_port *port)
up->ier = 0;
serial_out(up, UART_IER, 0);
- if (up->dma)
+ if (up->dma) {
serial8250_release_dma(up);
+ if (priv->delayed_restore) {
+ priv->delayed_restore = 0;
+ omap8250_restore_regs(up);
+ }
+ }
+
/*
* Disable break condition and FIFOs
*/
--
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 1/3] serial: 8250: unlock port for uart_write_wakeup()
uart_write_wakeup() should be called without holding the port lock.
Otherwise a possible recursive spinlock issue can occur, such as
the following callchain:
8250_core.c:serial8250_tx_chars() - called with port locked
serial_core.c:uart_write_wakeup()
tty_io.c:tty_wakeup()
st_core.c:st_tty_wakeup()
st_core.c:st_tx_wakeup()
st_core.c:st_int_write()
serial_core.c:uart_write() - locks port
Signed-off-by: John Ogness
---
drivers/tty/serial/8250/8250_core.c |6 +-
drivers/tty/serial/8250/8250_omap.c |6 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 37fff12..5ac2425 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1559,8 +1559,12 @@ void serial8250_tx_chars(struct uart_8250_port *up)
}
} while (--count > 0);
- if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
+ /* do not hold lock for call to uart_write_wakeup() */
+ spin_unlock(&port->lock);
uart_write_wakeup(port);
+ spin_lock(&port->lock);
+ }
DEBUG_INTR("THRE...");
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index d75a66c..5b39892 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -861,8 +861,12 @@ static void omap_8250_dma_tx_complete(void *param)
omap8250_restore_regs(p);
}
- if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
+ /* do not hold lock for call to uart_write_wakeup() */
+ spin_unlock(&p->port.lock);
uart_write_wakeup(&p->port);
+ spin_lock(&p->port.lock);
+ }
if (!uart_circ_empty(xmit) && !uart_tx_stopped(&p->port)) {
int ret;
--
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 0/3] serial: 8250: fix locking/race/cleanup issues
This patch series addresses some locking, race condition, and cleanup issues identified with the 8250 serial driver on omap boards. John Ogness (3): serial: 8250: unlock port for uart_write_wakeup() serial: 8250: move rx_running out of the bitfield serial: 8250: omap: restore registers on shutdown drivers/tty/serial/8250/8250.h |2 +- drivers/tty/serial/8250/8250_core.c |6 +- drivers/tty/serial/8250/8250_omap.c | 14 -- 3 files changed, 18 insertions(+), 4 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
Re: [PATCH stable/v4.0] ARM: OMAP3: Fix booting with thumb2 kernel
On Thu, Jul 30, 2015 at 03:27:54PM -0500, Kevin Hilman wrote:
> Hi Greg,
>
> On Fri, Jul 10, 2015 at 10:28 AM, Kevin Hilman wrote:
> > From: Tony Lindgren
> >
> > We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:
> >
> > Internal error: Oops: 8005 [#1] SMP THUMB2
> > ...
> > [] (_raw_spin_unlock_irqrestore) from []
> > (omap3_enter_idle_bm+0xc5/0x178)
> > [] (omap3_enter_idle_bm) from []
> > (cpuidle_enter_state+0x77/0x27c)
> > [] (cpuidle_enter_state) from []
> > (cpu_startup_entry+0x155/0x23c)
> > [] (cpu_startup_entry) from []
> > (start_kernel+0x32f/0x338)
> > [] (start_kernel) from [<8000807f>] (0x8000807f)
> >
> > The power management related assembly on omaps needs to interact with
> > ARM mode bootrom code, so we need to keep most of the related assembly
> > in ARM mode.
> >
> > Turns out this error is because of missing ENDPROC for assembly code
> > as suggested by Stephen Boyd . Let's fix the
> > problem by adding ENDPROC in two places to sleep34xx.S.
> >
> > Let's also remove the now duplicate custom code for mode switching.
> > This has been unnecessary since commit 6ebbf2ce437b ("ARM: convert
> > all "mov.* pc, reg" to "bx reg" for ARMv6+").
> >
> > And let's also remove the comments about local variables, they are
> > now just confusing after the ENDPROC.
> >
> > The reason why ENDPROC makes a difference is it sets .type and then
> > the compiler knows what to do with the thumb bit as explained at:
> >
> > https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
> >
> > Reported-by: Kevin Hilman
> > Tested-by: Kevin Hilman
> > Signed-off-by: Tony Lindgren
> > (cherry picked from commit d8a50941c91a68da202aaa96a3dacd471ea9c693)
> > Cc: # v4.0+
> > Signed-off-by: Kevin Hilman
>
> This one seems to be missing in v4.0.9, though it was submitted ~10
> days before. I missed noticing it was not present in the stable queue
> because I've been on vacation.
>
> I know you mentioned you were wrapping up v4.0, but any chance of this
> being included?
There isn't going to be any more 4.0-stable releases, sorry, so it
doesn't really matter as everyone should be on 4.1 by now :)
thanks,
greg k-h
--
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 stable/v4.0] ARM: OMAP3: Fix booting with thumb2 kernel
Hi Greg,
On Fri, Jul 10, 2015 at 10:28 AM, Kevin Hilman wrote:
> From: Tony Lindgren
>
> We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:
>
> Internal error: Oops: 8005 [#1] SMP THUMB2
> ...
> [] (_raw_spin_unlock_irqrestore) from []
> (omap3_enter_idle_bm+0xc5/0x178)
> [] (omap3_enter_idle_bm) from []
> (cpuidle_enter_state+0x77/0x27c)
> [] (cpuidle_enter_state) from []
> (cpu_startup_entry+0x155/0x23c)
> [] (cpu_startup_entry) from []
> (start_kernel+0x32f/0x338)
> [] (start_kernel) from [<8000807f>] (0x8000807f)
>
> The power management related assembly on omaps needs to interact with
> ARM mode bootrom code, so we need to keep most of the related assembly
> in ARM mode.
>
> Turns out this error is because of missing ENDPROC for assembly code
> as suggested by Stephen Boyd . Let's fix the
> problem by adding ENDPROC in two places to sleep34xx.S.
>
> Let's also remove the now duplicate custom code for mode switching.
> This has been unnecessary since commit 6ebbf2ce437b ("ARM: convert
> all "mov.* pc, reg" to "bx reg" for ARMv6+").
>
> And let's also remove the comments about local variables, they are
> now just confusing after the ENDPROC.
>
> The reason why ENDPROC makes a difference is it sets .type and then
> the compiler knows what to do with the thumb bit as explained at:
>
> https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
>
> Reported-by: Kevin Hilman
> Tested-by: Kevin Hilman
> Signed-off-by: Tony Lindgren
> (cherry picked from commit d8a50941c91a68da202aaa96a3dacd471ea9c693)
> Cc: # v4.0+
> Signed-off-by: Kevin Hilman
This one seems to be missing in v4.0.9, though it was submitted ~10
days before. I missed noticing it was not present in the stable queue
because I've been on vacation.
I know you mentioned you were wrapping up v4.0, but any chance of this
being included?
Thanks,
Kevin
--
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
OMAP baseline test results for v4.2-rc4
Here are some basic OMAP test results for Linux v4.2-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.2-rc4/20150730100856/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-stk-om44, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.2-rc3 (52721d9d3334c1cb1f76219a161084094ec634dc)): text data bsstotal kernel +819 +640 +883 omap1_defconfig +819 +960 +915 omap1_defconfig_1510innovator_only +851 +640 +915 omap1_defconfig_5912osk_only +99 +1280 +227 multi_v7_defconfig +35600 +356 omap2plus_defconfig +79200 +792 omap2plus_defconfig_2430sdp_only +35600 +356 omap2plus_defconfig_am33xx_only +445200+4452 omap2plus_defconfig_am43xx_only +35600 +356 omap2plus_defconfig_cpupm +35600 +356 omap2plus_defconfig_dra7xx_only -470 -32 -79 omap2plus_defconfig_n800_multi_omap2xxx -22800 -228 omap2plus_defconfig_n800_only_a +54000 +540 omap2plus_defconfig_no_pm +35600 +356 omap2plus_defconfig_omap2_4_only +35600 +356
OMAP baseline test results for v4.2-rc3
Here are some basic OMAP test results for Linux v4.2-rc3. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.2-rc3/20150728081114/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-stk-om44, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.2-rc2 (bc0195aad0daa2ad5b0d76cce22b167bc3435590)): text data bsstotal kernel +609 +2240 +833 omap1_defconfig +609 +1920 +801 omap1_defconfig_1510innovator_only +609 +2240 +833 omap1_defconfig_5912osk_only +70200 +702 multi_v7_defconfig +150 +1280 +278 omap2plus_defconfig +241 +960 +337 omap2plus_defconfig_2430sdp_only +150 +1280 +278 omap2plus_defconfig_am33xx_only +382 +1280 +510 omap2plus_defconfig_am43xx_only +150 +1280 +278 omap2plus_defconfig_cpupm +146 +1280 +274 omap2plus_defconfig_dra7xx_only +213 +960 +309 omap2plus_defconfig_n800_multi_omap2xxx +4100 +41 omap2plus_defconfig_n800_only_a +182 +1280 +310 omap2plus_defconfig_no_pm +146 +1280 +274 omap2plus_defconfig_omap2_4_only +146 +1280 +274
cpuidle results in ethernet degredation ?
Hello, I hope some will have some idea: I am using iperf to check bandwidth and I see that with small tcp windows in the test there is always high degredation in performance compared to version without cpuidle. I've noticed that C3 state (core inactive) is entered several times during the test, which might explaing this degredation. With bug tcp windows it works well (why ?) I would like to ask if there is any idea what I can do to overcome this issue so that there will be no degredation in performance? Thank you, Ran -- 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/27] Export I2C and OF module aliases in missing drivers
Hello Dmitry, Thanks a lot for your feedback. On 07/30/2015 06:37 PM, Dmitry Torokhov wrote: > On Thu, Jul 30, 2015 at 09:35:17AM -0700, Dmitry Torokhov wrote: >> Hi Javier, >> >> On Thu, Jul 30, 2015 at 06:18:25PM +0200, Javier Martinez Canillas wrote: >>> Hello, >>> >>> Short version: >>> >>> This series add the missing MODULE_DEVICE_TABLE() for OF and I2C tables >>> to export that information so modules have the correct aliases built-in >>> and autoloading works correctly. >>> >>> Longer version: >>> >>> Currently it's mandatory for I2C drivers to have an I2C device ID table >>> regardless if the device was registered using platform data or OF. This >>> is because the I2C core needs an I2C device ID table for two reasons: >>> >>> 1) Match the I2C client with a I2C device ID so a struct i2c_device_id >>>is passed to the I2C driver probe() function. >>> >>> 2) Export the module aliases from the I2C device ID table so userspace >>>can auto-load the correct module. This is because i2c_device_uevent >>>always reports a MODALIAS of the form i2c:name>. >> >> Why are we not fixing this? We emit specially carved uevent for >> ACPI-based devices, why not the same for OF? Platform bus does this... > > Ah, now I see the 27/27 patch. I think it is exactly what we need. And Yes, patch 27/27 is needed but the problem is as I explained before that there are drivers relying on the current behavior. The item c) in the list of issues that I mentioned. So those drivers need to be fixed before that patch is merged... > probably for SPI bus as well. > Yes, I didn't mention SPI because the cover letter became too long already but it does indeed have the same issue and I discussed this with Mark already some time ago [0]. Once I2C uevent report is fixed, I plan to do the same for SPI. > Thanks. > [0]: https://lkml.org/lkml/2014/9/11/458 Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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/27] Export I2C and OF module aliases in missing drivers
On Thu, Jul 30, 2015 at 09:35:17AM -0700, Dmitry Torokhov wrote: > Hi Javier, > > On Thu, Jul 30, 2015 at 06:18:25PM +0200, Javier Martinez Canillas wrote: > > Hello, > > > > Short version: > > > > This series add the missing MODULE_DEVICE_TABLE() for OF and I2C tables > > to export that information so modules have the correct aliases built-in > > and autoloading works correctly. > > > > Longer version: > > > > Currently it's mandatory for I2C drivers to have an I2C device ID table > > regardless if the device was registered using platform data or OF. This > > is because the I2C core needs an I2C device ID table for two reasons: > > > > 1) Match the I2C client with a I2C device ID so a struct i2c_device_id > >is passed to the I2C driver probe() function. > > > > 2) Export the module aliases from the I2C device ID table so userspace > >can auto-load the correct module. This is because i2c_device_uevent > >always reports a MODALIAS of the form i2c:name>. > > Why are we not fixing this? We emit specially carved uevent for > ACPI-based devices, why not the same for OF? Platform bus does this... Ah, now I see the 27/27 patch. I think it is exactly what we need. And probably for SPI bus as well. Thanks. -- Dmitry -- 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/27] Export I2C and OF module aliases in missing drivers
Hi Javier, On Thu, Jul 30, 2015 at 06:18:25PM +0200, Javier Martinez Canillas wrote: > Hello, > > Short version: > > This series add the missing MODULE_DEVICE_TABLE() for OF and I2C tables > to export that information so modules have the correct aliases built-in > and autoloading works correctly. > > Longer version: > > Currently it's mandatory for I2C drivers to have an I2C device ID table > regardless if the device was registered using platform data or OF. This > is because the I2C core needs an I2C device ID table for two reasons: > > 1) Match the I2C client with a I2C device ID so a struct i2c_device_id >is passed to the I2C driver probe() function. > > 2) Export the module aliases from the I2C device ID table so userspace >can auto-load the correct module. This is because i2c_device_uevent >always reports a MODALIAS of the form i2c:name>. Why are we not fixing this? We emit specially carved uevent for ACPI-based devices, why not the same for OF? Platform bus does this... Thanks. -- Dmitry -- 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/27] Export I2C and OF module aliases in missing drivers
Hello, Short version: This series add the missing MODULE_DEVICE_TABLE() for OF and I2C tables to export that information so modules have the correct aliases built-in and autoloading works correctly. Longer version: Currently it's mandatory for I2C drivers to have an I2C device ID table regardless if the device was registered using platform data or OF. This is because the I2C core needs an I2C device ID table for two reasons: 1) Match the I2C client with a I2C device ID so a struct i2c_device_id is passed to the I2C driver probe() function. 2) Export the module aliases from the I2C device ID table so userspace can auto-load the correct module. This is because i2c_device_uevent always reports a MODALIAS of the form i2c:name>. Lee Jones posted a patch series [0] to solve 1) by allowing the I2C drivers to have a probe() function that does not get a i2c_device_id. The problem is that his series didn't take into account 2) so if that was merged and the I2C ID table is removed from all the drivers that don't needed it, module auto-loading will break for those. But even now there are many I2C drivers were module auto-loading is not working because of the fact that the I2C core always reports the MODALIAS as i2c:name> and many developers didn't expect this. I've identified I2C drivers with 3 types of different issues: a) Those that have an i2c_table but are not exported. The match works and the correct i2c_device_id is passed on probe but since the ID table is not exported, module auto-load won't work. b) Those that have a of_table but are not exported. This is currently not an issue since even when the of_table is used to match the dev with the driver, an OF modalias is not reported by the I2C core. But if the I2C core is changed to report the MODALIAS of the form of:N*T*C as it's made by other subsystems, then module auto-load will break for these drivers. c) Those that don't have a of_table but should since are OF drivers with DT bindings doc for them. Since the I2C core does not report a OF modalias and since i2c_device_match() fallbacks to match the device part of the compatible string with the I2C device ID table, many OF drivers don't have an of_table to match. After all having a I2C device ID table is mandatory so it works without a of_table. So, in order to not make mandatory to have a I2C device ID table, at least a) and b) needs to be addressed, this series does that. c) should be fixed too since it seems wrong that a driver with a DT binding document, does not have a OF table and export it to modules. Also stripping the vendor part from the compatible string to match with the I2C devices ID table and reporting only the device name to user-space doesn't seem to be correct. I've identified at least two drivers that have the same name on their I2C device ID table so the manufacturer prefix is important. But I've not tried to fix c) yet since that is not so easy to automate due drivers not having all the information (i.e: the device name can match a documented compatible string device part but without the vendor prefix is hard to tell). I split the changes so the patches in this series are independent and can be picked individually by subsystem maintainers. Patch #27 changes the logic of i2c_device_uevent() to report an OF modalias if the device was registered using OF. But this patch is included in the series only as an RFC for illustration purposes since changing that without fixing c) will break module auto-loading for the drivers of devices registered with OF but that don't have a of_match_table. Although arguably, those drivers were relying on the assumption that a MODALIAS=i2c: would always be reported even for the OF case which is not the true on other subsystems. [0]: https://lkml.org/lkml/2014/8/28/283 Best regards, Javier Javier Martinez Canillas (27): mfd: stw481x: Export I2C module alias information spi: xcomm: Export I2C module alias information iio: Export I2C module alias information in missing drivers [media] Export I2C module alias information in missing drivers macintosh: therm_windtunnel: Export I2C module alias information misc: eeprom: Export I2C module alias information in missing drivers Input: Export I2C module alias information in missing drivers power: Export I2C module alias information in missing drivers i2c: core: Export I2C module alias information in dummy driver backlight: tosa: Export I2C module alias information [media] staging: media: lirc: Export I2C module alias information usb: phy: isp1301: Export I2C module alias information ALSA: ppc: keywest: Export I2C module alias information hwmon: (nct7904) Export I2C module alias information regulator: fan53555: Export I2C module alias information mfd: Export OF module alias information in missing drivers iio: Export OF module alias information in missing drivers hwmon: (g762) Export OF module alias information extcon: Expor
[PATCH 16/27] mfd: Export OF module alias information in missing drivers
The I2C core always reports the MODALIAS uevent as "i2c:
---
drivers/mfd/rt5033.c | 1 +
drivers/mfd/tps65217.c | 1 +
drivers/mfd/tps65218.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
index db395a6c52bc..d60f91619c4a 100644
--- a/drivers/mfd/rt5033.c
+++ b/drivers/mfd/rt5033.c
@@ -124,6 +124,7 @@ static const struct of_device_id rt5033_dt_match[] = {
{ .compatible = "richtek,rt5033", },
{ }
};
+MODULE_DEVICE_TABLE(of, rt5033_dt_match);
static struct i2c_driver rt5033_driver = {
.driver = {
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index bc455feb42be..55add0453ae9 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -156,6 +156,7 @@ static const struct of_device_id tps65217_of_match[] = {
{ .compatible = "ti,tps65217", .data = (void *)TPS65217 },
{ /* sentinel */ },
};
+MODULE_DEVICE_TABLE(of, tps65217_of_match);
static int tps65217_probe(struct i2c_client *client,
const struct i2c_device_id *ids)
diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index cb38d725250f..80b9dc363cd8 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -211,6 +211,7 @@ static const struct of_device_id of_tps65218_match_table[]
= {
{ .compatible = "ti,tps65218", },
{}
};
+MODULE_DEVICE_TABLE(of, of_tps65218_match_table);
static int tps65218_probe(struct i2c_client *client,
const struct i2c_device_id *ids)
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 27/27] i2c: (RFC, don't apply) report OF style modalias when probing using DT
An I2C driver that supports both OF and legacy platforms, will have both a OF and I2C ID table. This means that when built as a module, the aliases will be filled from both tables but currently always an alias of the form i2c: is reported, e.g: $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias i2c:maxtouch So if a device is probed by matching its compatible string, udev can get a MODALIAS uevent env var that doesn't match with one of the valid aliases so the module won't be auto-loaded. This patch changes the I2C core to report a OF related MODALIAS uevent (of:N*T*C) env var instead so the module can be auto-loaded and also report the correct alias using sysfs: $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias of:NtrackpadTCatmel,maxtouch Signed-off-by: Javier Martinez Canillas --- drivers/i2c/i2c-core.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 92dddfeb3f39..c0668c2ed9da 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -489,6 +489,10 @@ static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env) struct i2c_client *client = to_i2c_client(dev); int rc; + rc = of_device_uevent_modalias(dev, env); + if (rc != -ENODEV) + return rc; + rc = acpi_device_uevent_modalias(dev, env); if (rc != -ENODEV) return rc; @@ -726,6 +730,10 @@ show_modalias(struct device *dev, struct device_attribute *attr, char *buf) struct i2c_client *client = to_i2c_client(dev); int len; + len = of_device_get_modalias(dev, buf, PAGE_SIZE - 1); + if (len != -ENODEV) + return len; + len = acpi_device_modalias(dev, buf, PAGE_SIZE -1); if (len != -ENODEV) return len; -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND] ARM: dts: dra7: workaround UART module disable errata
Add "ti,dra742-uart" to the compatible list so the driver
workaround for UART module disable errata is enabled.
This does not break backward compatibility as existing DTBs
should continue to work with newer kernels albeit without the
capability to idle the UART module when DMA is used.
Acked-by: Tony Lindgren
Signed-off-by: Sekhar Nori
---
Earlier sent as part of the series:
http://www.spinics.net/lists/linux-omap/msg120005.html
resending for applying through tty tree with
Tony's ack included.
arch/arm/boot/dts/dra7.dtsi | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8f1e25bcecbd..49940e516f0f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -397,7 +397,7 @@
};
uart1: serial@4806a000 {
- compatible = "ti,omap4-uart";
+ compatible = "ti,dra742-uart", "ti,omap4-uart";
reg = <0x4806a000 0x100>;
interrupts-extended = <&crossbar_mpu GIC_SPI 67
IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "uart1";
@@ -408,7 +408,7 @@
};
uart2: serial@4806c000 {
- compatible = "ti,omap4-uart";
+ compatible = "ti,dra742-uart", "ti,omap4-uart";
reg = <0x4806c000 0x100>;
interrupts = ;
ti,hwmods = "uart2";
@@ -419,7 +419,7 @@
};
uart3: serial@4802 {
- compatible = "ti,omap4-uart";
+ compatible = "ti,dra742-uart", "ti,omap4-uart";
reg = <0x4802 0x100>;
interrupts = ;
ti,hwmods = "uart3";
@@ -430,7 +430,7 @@
};
uart4: serial@4806e000 {
- compatible = "ti,omap4-uart";
+ compatible = "ti,dra742-uart", "ti,omap4-uart";
reg = <0x4806e000 0x100>;
interrupts = ;
ti,hwmods = "uart4";
@@ -441,7 +441,7 @@
};
uart5: serial@48066000 {
- compatible = "ti,omap4-uart";
+ compatible = "ti,dra742-uart", "ti,omap4-uart";
reg = <0x48066000 0x100>;
interrupts = ;
ti,hwmods = "uart5";
@@ -452,7 +452,7 @@
};
uart6: serial@48068000 {
- compatible = "ti,omap4-uart";
+ compatible = "ti,dra742-uart", "ti,omap4-uart";
reg = <0x48068000 0x100>;
interrupts = ;
ti,hwmods = "uart6";
@@ -463,7 +463,7 @@
};
uart7: serial@4842 {
- compatible = "ti,omap4-uart";
+ compatible = "ti,dra742-uart", "ti,omap4-uart";
reg = <0x4842 0x100>;
interrupts = ;
ti,hwmods = "uart7";
@@ -472,7 +472,7 @@
};
uart8: serial@48422000 {
- compatible = "ti,omap4-uart";
+ compatible = "ti,dra742-uart", "ti,omap4-uart";
reg = <0x48422000 0x100>;
interrupts = ;
ti,hwmods = "uart8";
@@ -481,7 +481,7 @@
};
uart9: serial@48424000 {
- compatible = "ti,omap4-uart";
+ compatible = "ti,dra742-uart", "ti,omap4-uart";
reg = <0x48424000 0x100>;
interrupts = ;
ti,hwmods = "uart9";
@@ -490,7 +490,7 @@
};
uart10: serial@4ae2b000 {
- compatible = "ti,omap4-uart";
+ compatible = "ti,dra742-uart", "ti,omap4-uart";
reg = <0x4ae2b000 0x100>;
interrupts = ;
ti,hwmods = "uart10";
--
2.4.4.408.g16da57c
--
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/7] ARM: dts: MMC fixes for DRA7 based boards
Miscellaneous fixes in dts files for MMC device tree nodes. Did basic read/write test in J6, J6 Eco and Beagle-x15 Balaji T K (1): ARM: dts: dra7-evm: add evm_3v3_sd regulator Kishon Vijay Abraham I (5): ARM: dts: dra72-evm: add evm_3v3_sd regulator ARM: dts: dra72-evm: Set max clock frequency of MMC1 and MMC2 ARM: dts: am57xx-beagle-x15: mmc1: remove redundant pbias-supply property ARM: dts: dra7-evm: Fix spurious card insert/removal interrupt ARM: dts: dra72-evm: Fix spurious card insert/removal interrupt Nishanth Menon (1): ARM: dts: dra7-evm: Add MMCSD card removal GPIO arch/arm/boot/dts/am57xx-beagle-x15.dts |1 - arch/arm/boot/dts/dra7-evm.dts | 18 +- arch/arm/boot/dts/dra72-evm.dts | 16 ++-- 3 files changed, 31 insertions(+), 4 deletions(-) -- 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 1/7] ARM: dts: dra72-evm: add evm_3v3_sd regulator
Add a node for evm_3v3_sd using pcf which feeds on to mmc vdd.
Update mapping for vmmc-supply and vmmc_aux-supply.
evm_3v3_sd supplies to SD card vdd, and ldo1 to sdcard i/o lines.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra72-evm.dts | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 8037384..3998d37 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -30,6 +30,15 @@
regulator-max-microvolt = <330>;
};
+ evm_3v3_sd: fixedregulator-sd {
+ compatible = "regulator-fixed";
+ regulator-name = "evm_3v3_sd";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ enable-active-high;
+ gpio = <&pcf_gpio_21 5 GPIO_ACTIVE_HIGH>;
+ };
+
extcon_usb1: extcon_usb1 {
compatible = "linux,extcon-usb-gpio";
id-gpio = <&pcf_gpio_21 1 GPIO_ACTIVE_HIGH>;
@@ -491,8 +500,8 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins_default>;
-
- vmmc-supply = <&ldo1_reg>;
+ vmmc-supply = <&evm_3v3_sd>;
+ vmmc_aux-supply = <&ldo1_reg>;
bus-width = <4>;
/*
* SDCD signal is not being used here - using the fact that GPIO 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 4/7] ARM: dts: dra7-evm: Add MMCSD card removal GPIO
From: Nishanth Menon
SDMMC Card Detect can be used over default GPIO map.
Reported-by: Yan Liu
Signed-off-by: Nishanth Menon
Signed-off-by: Sekhar Nori
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7-evm.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 1e0c88e..25f0a00 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -474,6 +474,11 @@
vmmc-supply = <&evm_3v3_sd>;
vmmc_aux-supply = <&ldo1_reg>;
bus-width = <4>;
+ /*
+* SDCD signal is not being used here - using the fact that GPIO mode
+* is always hardwired.
+*/
+ cd-gpios = <&gpio6 27 0>;
};
&mmc2 {
--
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 2/7] ARM: dts: dra7-evm: add evm_3v3_sd regulator
From: Balaji T K
Add a node for evm_3v3_sd using onboard pcf GPIO expander which feeds
on to mmc vdd.
Update mapping for vmmc-supply and vmmc_aux-supply.
evm_3v3_sd supplies to SD card vdd, and ldo1 to sdcard i/o lines.
Signed-off-by: Balaji T K
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7-evm.dts | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 096f68b..1e0c88e 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -19,6 +19,15 @@
reg = <0x8000 0x6000>; /* 1536 MB */
};
+ evm_3v3_sd: fixedregulator-sd {
+ compatible = "regulator-fixed";
+ regulator-name = "evm_3v3_sd";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ enable-active-high;
+ gpio = <&pcf_gpio_21 5 GPIO_ACTIVE_HIGH>;
+ };
+
mmc2_3v3: fixedregulator-mmc2 {
compatible = "regulator-fixed";
regulator-name = "mmc2_3v3";
@@ -462,7 +471,8 @@
&mmc1 {
status = "okay";
- vmmc-supply = <&ldo1_reg>;
+ vmmc-supply = <&evm_3v3_sd>;
+ vmmc_aux-supply = <&ldo1_reg>;
bus-width = <4>;
};
--
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 7/7] ARM: dts: dra72-evm: Fix spurious card insert/removal interrupt
ldo1_reg in addition to being connected to the io lines is also connected to the card detect line. On card removal, omap_hsmmc driver does a regulator_disable causing card detect line to be pulled down. This raises a card insertion interrupt and once the MMC core detects there is no card inserted, it does a regulator disable which again raises a card insertion interrupt. This happens in a loop causing infinite MMC interrupts. Fix it by making ldo1_reg as always_on. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/boot/dts/dra72-evm.dts |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts index c5d8e7d..45f11a0 100644 --- a/arch/arm/boot/dts/dra72-evm.dts +++ b/arch/arm/boot/dts/dra72-evm.dts @@ -295,6 +295,7 @@ regulator-name = "ldo1"; regulator-min-microvolt = <180>; regulator-max-microvolt = <330>; + regulator-always-on; regulator-boot-on; }; -- 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 3/7] ARM: dts: dra72-evm: Set max clock frequency of MMC1 and MMC2
MMC1 supports SDR104 and MMC2 supports HS200 both of which requires
192MHz clock. Set the maximum operating clock frequency to 192 MHz.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra72-evm.dts |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 3998d37..c5d8e7d 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -508,6 +508,7 @@
* is a viable alternative
*/
cd-gpios = <&gpio6 27 0>;
+ max-frequency = <19200>;
};
&mmc2 {
@@ -519,6 +520,7 @@
vmmc-supply = <&evm_3v3>;
bus-width = <8>;
ti,non-removable;
+ max-frequency = <19200>;
};
&dra7_pmx_core {
--
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 5/7] ARM: dts: am57xx-beagle-x15: mmc1: remove redundant pbias-supply property
pbias-supply is initialized in dra7.dtsi. Remove redundant initialization of pbias-supply from MMC1 dt node in am57xx-beagle-x15.dts Signed-off-by: Kishon Vijay Abraham I --- arch/arm/boot/dts/am57xx-beagle-x15.dts |1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts index d0db5c5..daf4f17 100644 --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts @@ -579,7 +579,6 @@ pinctrl-0 = <&mmc1_pins_default>; vmmc-supply = <&ldo1_reg>; - pbias-supply = <&pbias_mmc_reg>; bus-width = <4>; cd-gpios = <&gpio6 27 0>; /* gpio 219 */ }; -- 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 6/7] ARM: dts: dra7-evm: Fix spurious card insert/removal interrupt
ldo1_reg in addition to being connected to the io lines is also connected to the card detect line. On card removal, omap_hsmmc driver does a regulator_disable causing card detect line to be pulled down. This raises a card insertion interrupt and once the MMC core detects there is no card inserted, it does a regulator disable which again raises a card insertion interrupt. This happens in a loop causing infinite MMC interrupts. Fix it by making ldo1_reg as always_on. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/boot/dts/dra7-evm.dts |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index 25f0a00..a6c82e5 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -358,6 +358,7 @@ regulator-name = "ldo1"; regulator-min-microvolt = <180>; regulator-max-microvolt = <330>; + regulator-always-on; regulator-boot-on; }; -- 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/11] omap_hsmmc: voltage switching and tuning
Patch series implements voltage switching and tuning for omap_hsmmc driver. Did basic read/write test in J6, J6 Eco, Beagle-x15, AM437x EVM, Beaglebone black, OMAP5 uEVM and OMAP4 PANDA. Balaji T K (2): mmc: host: omap_hsmmc: add voltage switch support for UHS SD card mmc: host: omap_hsmmc: add tuning support Kishon Vijay Abraham I (8): mmc: host: omap_hsmmc: Support pbias and vmmc_aux to switch to 1.8v mmc: host: omap_hsmmc: separate setting voltage capabilities from bus power mmc: host: omap_hsmmc: program HCTL based on signal_voltage set by mmc core mmc: host: omap_hsmmc: set clk rate to the max frequency mmc: host: omap_hsmmc: set timing in the UHSMS field mmc: host: omap_hsmmc: Workaround for errata id i802 mmc: host: omap_hsmmc: Allow io voltage switch even for fixed vdd mmc: host: omap_hsmmc: remove incorrect voltage switch sequence Mugunthan V N (1): mmc: host: omap_hsmmc: add software timer when timeout greater than hardware capablility drivers/mmc/host/omap_hsmmc.c | 670 + 1 file changed, 547 insertions(+), 123 deletions(-) -- 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/11] mmc: host: omap_hsmmc: separate setting voltage capabilities from bus power
Added a separate function to set the voltage capabilities of the host
controller. Voltage capabilities should be set only once during
controller initialization but bus power can be changed every time there
is a voltage switch and whenever a different card is inserted.
This allows omap_hsmmc_conf_bus_power to be invoked every time there
is a voltage switch.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 09e949f..2dfef11 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1812,25 +1812,34 @@ err:
return ret;
}
+static void omap_hsmmc_set_capabilities(struct omap_hsmmc_host *host)
+{
+ u32 val;
+
+ val = OMAP_HSMMC_READ(host->base, CAPA);
+
+ /* Only MMC1 supports 3.0V */
+ if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT)
+ val |= (VS30 | VS18);
+ else
+ val |= VS18;
+
+ OMAP_HSMMC_WRITE(host->base, CAPA, val);
+}
+
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
{
- u32 hctl, capa, value;
+ u32 hctl, value;
/* Only MMC1 supports 3.0V */
- if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
+ if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT)
hctl = SDVS30;
- capa = VS30 | VS18;
- } else {
+ else
hctl = SDVS18;
- capa = VS18;
- }
value = OMAP_HSMMC_READ(host->base, HCTL) & ~SDVS_MASK;
OMAP_HSMMC_WRITE(host->base, HCTL, value | hctl);
- value = OMAP_HSMMC_READ(host->base, CAPA);
- OMAP_HSMMC_WRITE(host->base, CAPA, value | capa);
-
/* Set SD bus power bit */
set_sd_bus_power(host);
}
@@ -2133,6 +2142,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
mmc->pm_caps |= mmc_pdata(host)->pm_caps;
+ omap_hsmmc_set_capabilities(host);
omap_hsmmc_conf_bus_power(host);
if (!pdev->dev.of_node) {
--
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 03/11] mmc: host: omap_hsmmc: program HCTL based on signal_voltage set by mmc core
HCTL is now set based on ios.signal_voltage set by mmc core and not
hardcoded to 3V0 if OMAP_HSMMC_SUPPORTS_DUAL_VOLT is set. If
OMAP_HSMMC_SUPPORTS_DUAL_VOLT is set, it means HCTL can be set to either
3V0 or 1V8. And it should be set to 3V0 or 1V8 depending on
ios.signal_voltage.
Also it is now set on power mode status being changed to MMC_POWER_ON.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2dfef11..306e5c0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -228,6 +228,7 @@ struct omap_mmc_of_data {
};
static void omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host);
+static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host, int iov);
static int omap_hsmmc_card_detect(struct device *dev)
{
@@ -1665,6 +1666,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
mmc_pdata(host)->set_power(host->dev, 1, ios->vdd);
break;
case MMC_POWER_ON:
+ omap_hsmmc_conf_bus_power(host, ios->signal_voltage);
do_send_init_stream = 1;
break;
}
@@ -1827,17 +1829,12 @@ static void omap_hsmmc_set_capabilities(struct
omap_hsmmc_host *host)
OMAP_HSMMC_WRITE(host->base, CAPA, val);
}
-static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
+static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host, int iov)
{
u32 hctl, value;
- /* Only MMC1 supports 3.0V */
- if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT)
- hctl = SDVS30;
- else
- hctl = SDVS18;
-
value = OMAP_HSMMC_READ(host->base, HCTL) & ~SDVS_MASK;
+ hctl = (iov == MMC_SIGNAL_VOLTAGE_180) ? SDVS18 : SDVS30;
OMAP_HSMMC_WRITE(host->base, HCTL, value | hctl);
/* Set SD bus power bit */
@@ -2143,7 +2140,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
mmc->pm_caps |= mmc_pdata(host)->pm_caps;
omap_hsmmc_set_capabilities(host);
- omap_hsmmc_conf_bus_power(host);
if (!pdev->dev.of_node) {
res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
@@ -2318,6 +2314,7 @@ static int omap_hsmmc_suspend(struct device *dev)
static int omap_hsmmc_resume(struct device *dev)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
+ struct mmc_ios *ios;
if (!host)
return 0;
@@ -2327,8 +2324,9 @@ static int omap_hsmmc_resume(struct device *dev)
if (host->dbclk)
clk_prepare_enable(host->dbclk);
+ ios = &host->mmc->ios;
if (!(host->mmc->pm_flags & MMC_PM_KEEP_POWER))
- omap_hsmmc_conf_bus_power(host);
+ omap_hsmmc_conf_bus_power(host, ios->signal_voltage);
omap_hsmmc_protect_card(host);
pm_runtime_mark_last_busy(host->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 05/11] mmc: host: omap_hsmmc: set clk rate to the max frequency
Set the clock rate of the functional clock to the max frequency
that is passed to the driver either using pdata or dt.
Also remove unnecessary setting of host->fclk to NULL.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e960b5c..0452a8b 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2219,7 +2219,12 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->fclk = devm_clk_get(&pdev->dev, "fck");
if (IS_ERR(host->fclk)) {
ret = PTR_ERR(host->fclk);
- host->fclk = NULL;
+ goto err1;
+ }
+
+ ret = clk_set_rate(host->fclk, mmc->f_max);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to set clock to %d\n", mmc->f_max);
goto err1;
}
--
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/11] mmc: host: omap_hsmmc: add voltage switch support for UHS SD card
From: Balaji T K
UHS sd card i/o data line can operate at 3V and 1.8V on UHS speed
modes. Add support for signal voltage switch and check for card_busy.
Signed-off-by: Balaji T K
Signed-off-by: Sourav Poddar
[kis...@ti.com : cleanup the voltage switch sequence]
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 129 +
1 file changed, 129 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 306e5c0..e960b5c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -112,6 +112,9 @@
/* PSTATE */
#define DLEV_DAT(x)(1 << (20 + (x)))
+/* AC12 */
+#define AC12_V1V8_SIGEN(1 << 19)
+
/* Interrupt masks for IE and ISE register */
#define CC_EN (1 << 0)
#define TC_EN (1 << 1)
@@ -151,6 +154,12 @@
#define VDD_1V8180 /* 18 uV */
#define VDD_3V0300 /* 30 uV */
#define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
+#define VDD_30_31 (ffs(MMC_VDD_30_31) - 1)
+
+#define CON_CLKEXTFREE (1 << 16)
+#define CON_PADEN (1 << 15)
+#define PSTATE_CLEV(1 << 24)
+#define PSTATE_DLEV(0xF << 20)
/*
* One controller can have multiple slots, like on some omap boards using
@@ -1851,6 +1860,124 @@ static int omap_hsmmc_multi_io_quirk(struct mmc_card
*card,
return blk_size;
}
+static int omap_hsmmc_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios)
+{
+ struct omap_hsmmc_host *host;
+ u32 val = 0;
+ int ret = 0;
+
+ host = mmc_priv(mmc);
+
+ if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_330) {
+ val = OMAP_HSMMC_READ(host->base, CAPA);
+ if (!(val & VS30))
+ return -EOPNOTSUPP;
+
+ omap_hsmmc_conf_bus_power(host, ios->signal_voltage);
+
+ val = OMAP_HSMMC_READ(host->base, AC12);
+ val &= ~AC12_V1V8_SIGEN;
+ OMAP_HSMMC_WRITE(host->base, AC12, val);
+
+ ret = mmc_pdata(host)->set_power(host->dev, 1, VDD_30_31);
+ if (ret) {
+ dev_dbg(mmc_dev(host->mmc), "failed to switch to 3v\n");
+ return ret;
+ }
+
+ dev_dbg(mmc_dev(host->mmc), " i/o voltage switch to 3V\n");
+ } else if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_180) {
+ val = OMAP_HSMMC_READ(host->base, CAPA);
+ if (!(val & VS18))
+ return -EOPNOTSUPP;
+
+ omap_hsmmc_conf_bus_power(host, ios->signal_voltage);
+
+ val = OMAP_HSMMC_READ(host->base, AC12);
+ val |= AC12_V1V8_SIGEN;
+ OMAP_HSMMC_WRITE(host->base, AC12, val);
+
+ ret = mmc_pdata(host)->set_power(host->dev, 1, VDD_165_195);
+ if (ret < 0) {
+ dev_dbg(mmc_dev(host->mmc), "failed to switch 1.8v\n");
+ return ret;
+ }
+ } else {
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
+}
+
+static int omap_hsmmc_card_busy_low(struct omap_hsmmc_host *host)
+{
+ u32 val;
+ unsigned long timeout;
+
+ val = OMAP_HSMMC_READ(host->base, CON);
+ val &= ~CON_CLKEXTFREE;
+ val |= CON_PADEN;
+ OMAP_HSMMC_WRITE(host->base, CON, val);
+
+ timeout = jiffies + msecs_to_jiffies(1);
+ do {
+ val = OMAP_HSMMC_READ(host->base, PSTATE);
+ if (!(val & (PSTATE_CLEV | PSTATE_DLEV)))
+ return true;
+
+ usleep_range(100, 200);
+ } while (!time_after(jiffies, timeout));
+
+ dev_err(mmc_dev(host->mmc), "timeout : i/o low 0x%x\n", val);
+
+ return false;
+}
+
+static int omap_hsmmc_card_busy_high(struct omap_hsmmc_host *host)
+{
+ u32 val;
+ unsigned long timeout;
+
+ val = OMAP_HSMMC_READ(host->base, CON);
+ val |= CLKEXTFREE;
+ OMAP_HSMMC_WRITE(host->base, CON, val);
+
+ timeout = jiffies + msecs_to_jiffies(1);
+ do {
+ val = OMAP_HSMMC_READ(host->base, PSTATE);
+ if ((val & PSTATE_CLEV) && (val & PSTATE_DLEV)) {
+ val = OMAP_HSMMC_READ(host->base, CON);
+ val &= ~(CON_CLKEXTFREE | CON_PADEN);
+ OMAP_HSMMC_WRITE(host->base, CON, val);
+ return false;
+ }
+
+ usleep_range(100, 200);
+ } while (!time_after(jiffies, timeout));
+
+ dev_err(mmc_dev(host->mmc), "timeout : i/o high 0x%x\n", val);
+
+ return true;
+}
+
+static int omap_hsmmc_card_busy(struct mmc_host *mmc)
+{
+ struct omap_hsmmc_host *host;
+ u32 val;
+ int ret;
+
+ host
[PATCH 09/11] mmc: host: omap_hsmmc: Allow io voltage switch even for fixed vdd
Now that vmmc regulator is made optional, do not bail out if vmmc regulator is not found. Signed-off-by: Kishon Vijay Abraham I --- drivers/mmc/host/omap_hsmmc.c |7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 96dd406..26010a3 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -434,13 +434,6 @@ static int omap_hsmmc_set_power(struct device *dev, int power_on, int iov) struct mmc_host *mmc = host->mmc; int ret = 0; - /* -* If we don't see a Vcc regulator, assume it's a fixed -* voltage always-on regulator. -*/ - if (!mmc->supply.vmmc) - return 0; - if (mmc_pdata(host)->before_set_reg) mmc_pdata(host)->before_set_reg(dev, power_on, iov); -- 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/11] mmc: host: omap_hsmmc: set timing in the UHSMS field
Add a separate function to set the UHSMS field to one
of SDR104, SDR50, DDR50, SDR25 or SDR12 depending on the
inserted SD card. This is required for
tuning to succeed in the case of SDR104/HS200 or SDR50.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0452a8b..e0bd8df 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -114,6 +114,13 @@
/* AC12 */
#define AC12_V1V8_SIGEN(1 << 19)
+#define AC12_UHSMC_MASK(7 << 16)
+#define AC12_UHSMC_SDR12 (0 << 16)
+#define AC12_UHSMC_SDR25 (1 << 16)
+#define AC12_UHSMC_SDR50 (2 << 16)
+#define AC12_UHSMC_SDR104 (3 << 16)
+#define AC12_UHSMC_DDR50 (4 << 16)
+#define AC12_UHSMC_RES (0x7 << 16)
/* Interrupt masks for IE and ISE register */
#define CC_EN (1 << 0)
@@ -198,6 +205,7 @@ struct omap_hsmmc_host {
unsigned intdma_sg_idx;
unsigned char bus_mode;
unsigned char power_mode;
+ unsigned char timing;
int suspended;
u32 con;
u32 hctl;
@@ -1658,6 +1666,41 @@ static void omap_hsmmc_request(struct mmc_host *mmc,
struct mmc_request *req)
omap_hsmmc_start_command(host, req->cmd, req->data);
}
+static void omap_hsmmc_set_timing(struct omap_hsmmc_host *host)
+{
+ u32 val;
+ struct mmc_ios *ios = &host->mmc->ios;
+
+ omap_hsmmc_stop_clock(host);
+
+ val = OMAP_HSMMC_READ(host->base, AC12);
+ val &= ~AC12_UHSMC_MASK;
+ switch (ios->timing) {
+ case MMC_TIMING_UHS_SDR104:
+ case MMC_TIMING_MMC_HS200:
+ val |= AC12_UHSMC_SDR104;
+ break;
+ case MMC_TIMING_UHS_DDR50:
+ val |= AC12_UHSMC_DDR50;
+ break;
+ case MMC_TIMING_UHS_SDR50:
+ val |= AC12_UHSMC_SDR50;
+ break;
+ case MMC_TIMING_UHS_SDR25:
+ val |= AC12_UHSMC_SDR25;
+ break;
+ case MMC_TIMING_UHS_SDR12:
+ val |= AC12_UHSMC_SDR12;
+ break;
+ default:
+ val |= AC12_UHSMC_RES;
+ break;
+ }
+ OMAP_HSMMC_WRITE(host->base, AC12, val);
+
+ omap_hsmmc_start_clock(host);
+}
+
/* Routine to configure clock values. Exposed API to core */
static void omap_hsmmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
@@ -1706,6 +1749,11 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
omap_hsmmc_set_clock(host);
+ if (ios->timing != host->timing) {
+ omap_hsmmc_set_timing(host);
+ host->timing = ios->timing;
+ }
+
if (do_send_init_stream)
send_init_stream(host);
@@ -2194,6 +2242,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->mapbase = res->start + pdata->reg_offset;
host->base = base + pdata->reg_offset;
host->power_mode = MMC_POWER_OFF;
+ host->timing= 0;
host->next_data.cookie = 1;
ret = omap_hsmmc_gpio_init(mmc, host, pdata);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/11] mmc: host: omap_hsmmc: remove incorrect voltage switch sequence
ios->vdd is set only in mmc_power_up and mmc_power_off and not in
mmc_select_voltage as mentioned in the code comment. This seems to be
legacy code that has been carried for a long time without being
tested.
This will be replaced with a proper voltage switch sequence and
populated in start_signal_voltage_switch ops to be used by
mmc core for switching voltages.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 81 -
1 file changed, 81 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 26010a3..6b02c7c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1325,69 +1325,6 @@ static void set_sd_bus_power(struct omap_hsmmc_host
*host)
}
}
-/*
- * Switch MMC interface voltage ... only relevant for MMC1.
- *
- * MMC2 and MMC3 use fixed 1.8V levels, and maybe a transceiver.
- * The MMC2 transceiver controls are used instead of DAT4..DAT7.
- * Some chips, like eMMC ones, use internal transceivers.
- */
-static int omap_hsmmc_switch_opcond(struct omap_hsmmc_host *host, int vdd)
-{
- u32 reg_val = 0;
- int ret;
-
- /* Disable the clocks */
- pm_runtime_put_sync(host->dev);
- if (host->dbclk)
- clk_disable_unprepare(host->dbclk);
-
- /* Turn the power off */
- ret = mmc_pdata(host)->set_power(host->dev, 0, 0);
-
- /* Turn the power ON with given VDD 1.8 or 3.0v */
- if (!ret)
- ret = mmc_pdata(host)->set_power(host->dev, 1, vdd);
- pm_runtime_get_sync(host->dev);
- if (host->dbclk)
- clk_prepare_enable(host->dbclk);
-
- if (ret != 0)
- goto err;
-
- OMAP_HSMMC_WRITE(host->base, HCTL,
- OMAP_HSMMC_READ(host->base, HCTL) & SDVSCLR);
- reg_val = OMAP_HSMMC_READ(host->base, HCTL);
-
- /*
-* If a MMC dual voltage card is detected, the set_ios fn calls
-* this fn with VDD bit set for 1.8V. Upon card removal from the
-* slot, omap_hsmmc_set_ios sets the VDD back to 3V on MMC_POWER_OFF.
-*
-* Cope with a bit of slop in the range ... per data sheets:
-* - "1.8V" for vdds_mmc1/vdds_mmc1a can be up to 2.45V max,
-*but recommended values are 1.71V to 1.89V
-* - "3.0V" for vdds_mmc1/vdds_mmc1a can be up to 3.5V max,
-*but recommended values are 2.7V to 3.3V
-*
-* Board setup code shouldn't permit anything very out-of-range.
-* TWL4030-family VMMC1 and VSIM regulators are fine (avoiding the
-* middle range) but VSIM can't power DAT4..DAT7 at more than 3V.
-*/
- if ((1 << vdd) <= MMC_VDD_23_24)
- reg_val |= SDVS18;
- else
- reg_val |= SDVS30;
-
- OMAP_HSMMC_WRITE(host->base, HCTL, reg_val);
- set_sd_bus_power(host);
-
- return 0;
-err:
- dev_err(mmc_dev(host->mmc), "Unable to switch operating voltage\n");
- return ret;
-}
-
/* Protect the card while the cover is open */
static void omap_hsmmc_protect_card(struct omap_hsmmc_host *host)
{
@@ -1799,24 +1736,6 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
omap_hsmmc_set_bus_width(host);
- if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
- /* Only MMC1 can interface at 3V without some flavor
-* of external transceiver; but they all handle 1.8V.
-*/
- if ((OMAP_HSMMC_READ(host->base, HCTL) & SDVSDET) &&
- (ios->vdd == DUAL_VOLT_OCR_BIT)) {
- /*
-* The mmc_select_voltage fn of the core does
-* not seem to set the power_mode to
-* MMC_POWER_UP upon recalculating the voltage.
-* vdd 1.8v.
-*/
- if (omap_hsmmc_switch_opcond(host, ios->vdd) != 0)
- dev_dbg(mmc_dev(host->mmc),
- "Switch operation failed\n");
- }
- }
-
omap_hsmmc_set_clock(host);
if (ios->timing != host->timing) {
--
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/11] mmc: host: omap_hsmmc: Workaround for errata id i802
According to errata i802, DCRC error interrupts
(MMCHS_STAT[21] DCRC=0x1) can occur during the tuning procedure.
The DCRC interrupt, occurs when the last tuning block fails
(the last ratio tested). The delay from CRC check until the
interrupt is asserted is bigger than the delay until assertion
of the tuning end flag. Assertion of tuning end flag is what
masks the interrupts. Because of this race, an erroneous DCRC
interrupt occurs.
The suggested workaround is to disable DCRC interrupts during
the tuning procedure which is implemented here.
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Sekhar Nori
---
drivers/mmc/host/omap_hsmmc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index dcfa92e..96dd406 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -656,8 +656,17 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host,
is_tuning = (cmd->opcode == MMC_SEND_TUNING_BLOCK) ||
(cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200);
- if (!is_tuning && host->use_dma)
+ if (is_tuning) {
+ /*
+* OMAP5/DRA74X/DRA72x Errata i802:
+* DCRC error interrupts (MMCHS_STAT[21] DCRC=0x1) can occur
+* during the tuning procedure. So disable it during the
+* tuning procedure.
+*/
+ irq_mask &= ~DCRC_EN;
+ } else if (host->use_dma) {
irq_mask &= ~(BRR_EN | BWR_EN);
+ }
/* Disable timeout for erases */
if (cmd->opcode == MMC_ERASE)
--
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/11] mmc: host: omap_hsmmc: add software timer when timeout greater than hardware capablility
From: Mugunthan V N
DRA7 Errata No i834: When using high speed HS200 and SDR104
cards, the functional clock for MMC module will be 192MHz.
At this frequency, the maximum obtainable timeout (DTO =0xE)
in hardware is (1/192MHz)*2^27 = 700ms. Commands taking longer
than 700ms will be affected by this small window frame and
will be timing out frequently even without a genune timeout
from the card. Workarround for this errata is use a software
timer instead of hardware timer to provide the delay requested
by the upper layer
So adding a software timer as a work around for the errata.
Instead of using software timeout only for larger delays requested
when using HS200/SDR104 cards which results in hardware and
software timer race conditions, so move all the timeout request
to use software timer when HS200/SDR104 card is connected and
use hardware timer when other type cards are connected.
Also start the software timer after queueing to DMA to ensure
we are more likely to expire within correct limits. To be ever
more sure that we won't expire this soft timer too early, we're
adding a 100ns slack to the data timeout requested by the
upper layer.
Signed-off-by: Mugunthan V N
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 71 +++--
1 file changed, 69 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6b02c7c..3a02f86 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -168,6 +168,7 @@
#define ACNE (1 << 0)
#define MMC_AUTOSUSPEND_DELAY 100
+#define MMC_SOFT_TIMER_SLACK 100 /* ns */
#define MMC_TIMEOUT_MS 20 /* 20 mSec */
#define MMC_TIMEOUT_US 2 /* 2 micro Sec */
#define OMAP_MMC_MIN_CLOCK 40
@@ -245,6 +246,10 @@ struct omap_hsmmc_host {
struct omap_hsmmc_next next_data;
struct omap_hsmmc_platform_data*pdata;
+ struct timer_list timer;
+ unsigned long data_timeout;
+ unsigned intneed_i834_errata:1;
+
u32 *tuning_data;
int tuning_size;
@@ -661,8 +666,8 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host,
irq_mask &= ~(BRR_EN | BWR_EN);
}
- /* Disable timeout for erases */
- if (cmd->opcode == MMC_ERASE)
+ /* Disable timeout for erases or when using software timeout */
+ if (cmd->opcode == MMC_ERASE || host->need_i834_errata)
irq_mask &= ~DTO_EN;
spin_lock_irqsave(&host->irq_lock, flags);
@@ -752,6 +757,22 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
OMAP_HSMMC_WRITE(host->base, HCTL, regval);
}
+ /*
+* DRA7 Errata No i834: When using high speed HS200 and SDR104
+* cards, the functional clock for MMC module will be 192MHz.
+* At this frequency, the maximum obtainable timeout (DTO =0xE)
+* in hardware is (1/192MHz)*2^27 = 700ms. Commands taking longer
+* than 700ms will be affected by this small window frame and
+* will be timing out frequently even without a genune timeout
+* from the card. Workarround for this errata is use a software
+* timer instead of hardware timer to provide the delay requested
+* by the upper layer
+*/
+ if (ios->clock == 19200)
+ host->need_i834_errata = true;
+ else
+ host->need_i834_errata = false;
+
omap_hsmmc_start_clock(host);
}
@@ -1298,6 +1319,16 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
int status;
status = OMAP_HSMMC_READ(host->base, STAT);
+
+ /*
+* During a successful bulk data transfer command-completion
+* interrupt and transfer-completion interrupt will be generated,
+* but software-timeout timer should be deleted only on non-CC
+* interrupts (transfer complete or error)
+*/
+ if (host->need_i834_errata && (status & (~CC_EN)))
+ del_timer(&host->timer);
+
while (status & (INT_EN_MASK | CIRQ_EN)) {
if (host->req_in_progress)
omap_hsmmc_do_irq(host, status);
@@ -1312,6 +1343,13 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static void omap_hsmmc_soft_timeout(unsigned long data)
+{
+ struct omap_hsmmc_host *host = (struct omap_hsmmc_host *)data;
+
+ hsmmc_command_incomplete(host, -ETIMEDOUT, 0);
+}
+
static void set_sd_bus_power(struct omap_hsmmc_host *host)
{
unsigned long i;
@@ -1513,6 +1551,22 @@ static void set_data_timeout(struct omap_hsmmc_host
*host,
if (clkd == 0)
clkd = 1;
+ if (host->need_i834_errata) {
+ unsigned long delta;
+
+ delta = (timeout_clks /
[PATCH 07/11] mmc: host: omap_hsmmc: add tuning support
From: Balaji T K
MMC tuning procedure is required to support SD card
UHS1-SDR104 mode and EMMC HS200 mode.
The tuning function omap_execute_tuning() will only
be called by the MMC/SD core if the corresponding
speed modes are supported by the OMAP silicon which
is set in the mmc host "caps" field.
Signed-off-by: Balaji T K
Signed-off-by: Viswanath Puttagunta
Signed-off-by: Sourav Poddar
[kis...@ti.com : cleanup the tuning sequence]
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 234 -
1 file changed, 232 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e0bd8df..dcfa92e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -49,6 +50,7 @@
/* OMAP HSMMC Host Controller Registers */
#define OMAP_HSMMC_SYSSTATUS 0x0014
#define OMAP_HSMMC_CON 0x002C
+#define OMAP_HSMMC_DLL 0x0034
#define OMAP_HSMMC_SDMASA 0x0100
#define OMAP_HSMMC_BLK 0x0104
#define OMAP_HSMMC_ARG 0x0108
@@ -66,6 +68,7 @@
#define OMAP_HSMMC_ISE 0x0138
#define OMAP_HSMMC_AC120x013C
#define OMAP_HSMMC_CAPA0x0140
+#define OMAP_HSMMC_CAPA2 0x0144
#define VS18 (1 << 26)
#define VS30 (1 << 25)
@@ -114,6 +117,7 @@
/* AC12 */
#define AC12_V1V8_SIGEN(1 << 19)
+#define AC12_SCLK_SEL (1 << 23)
#define AC12_UHSMC_MASK(7 << 16)
#define AC12_UHSMC_SDR12 (0 << 16)
#define AC12_UHSMC_SDR25 (1 << 16)
@@ -122,6 +126,18 @@
#define AC12_UHSMC_DDR50 (4 << 16)
#define AC12_UHSMC_RES (0x7 << 16)
+/* DLL */
+#define DLL_SWT(1 << 20)
+#define DLL_FORCE_SR_C_SHIFT 13
+#define DLL_FORCE_SR_C_MASK0x7f
+#define DLL_FORCE_VALUE(1 << 12)
+#define DLL_CALIB (1 << 1)
+
+#define MAX_PHASE_DELAY0x7c
+
+/* CAPA2 */
+#define CAPA2_TSDR50 (1 << 13)
+
/* Interrupt masks for IE and ISE register */
#define CC_EN (1 << 0)
#define TC_EN (1 << 1)
@@ -201,6 +217,7 @@ struct omap_hsmmc_host {
void__iomem *base;
resource_size_t mapbase;
spinlock_t irq_lock; /* Prevent races with irq handler */
+ struct completion buf_ready;
unsigned intdma_len;
unsigned intdma_sg_idx;
unsigned char bus_mode;
@@ -228,6 +245,9 @@ struct omap_hsmmc_host {
struct omap_hsmmc_next next_data;
struct omap_hsmmc_platform_data*pdata;
+ u32 *tuning_data;
+ int tuning_size;
+
/* return MMC cover switch state, can be NULL if not supported.
*
* possible return values:
@@ -244,8 +264,39 @@ struct omap_mmc_of_data {
u8 controller_flags;
};
+static const u8 ref_tuning_4bits[] = {
+ 0xff, 0x0f, 0xff, 0x00, 0xff, 0xcc, 0xc3, 0xcc,
+ 0xc3, 0x3c, 0xcc, 0xff, 0xfe, 0xff, 0xfe, 0xef,
+ 0xff, 0xdf, 0xff, 0xdd, 0xff, 0xfb, 0xff, 0xfb,
+ 0xbf, 0xff, 0x7f, 0xff, 0x77, 0xf7, 0xbd, 0xef,
+ 0xff, 0xf0, 0xff, 0xf0, 0x0f, 0xfc, 0xcc, 0x3c,
+ 0xcc, 0x33, 0xcc, 0xcf, 0xff, 0xef, 0xff, 0xee,
+ 0xff, 0xfd, 0xff, 0xfd, 0xdf, 0xff, 0xbf, 0xff,
+ 0xbb, 0xff, 0xf7, 0xff, 0xf7, 0x7f, 0x7b, 0xde,
+};
+
+static const u8 ref_tuning_8bits[] = {
+ 0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00, 0x00,
+ 0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc, 0xcc,
+ 0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff, 0xff,
+ 0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee, 0xff,
+ 0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd, 0xdd,
+ 0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff, 0xbb,
+ 0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff, 0xff,
+ 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee, 0xff,
+ 0xff, 0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00,
+ 0x00, 0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc,
+ 0xcc, 0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff,
+ 0xff, 0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee,
+ 0xff, 0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd,
+ 0xdd, 0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff,
+ 0xbb, 0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff,
+ 0xff, 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee,
+};
+
static void omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host);
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host, int iov);
+static void omap_hsmmc_disable_tuning(struct omap_hsmmc_host *host);
static int omap_hsmmc_card_detect(struct device *dev)
{
@@ -600,8 +651,12 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host,
{
u32 irq_mask = INT_EN_MASK;
unsigned long flags;
+ bool is_tuning;
[PATCH 01/11] mmc: host: omap_hsmmc: Support vmmc_aux to switch to 1.8v
Add support for vmmc_aux to switch to 1.8v. Also use "iov" instead of
"vdd" to indicate io voltage. This is in preparation for adding support
for io signal voltage switch.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 47 +++--
1 file changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6d52873..09e949f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -243,10 +243,11 @@ static int omap_hsmmc_get_cover_state(struct device *dev)
return mmc_gpio_get_cd(host->mmc);
}
-static int omap_hsmmc_enable_supply(struct mmc_host *mmc)
+static int omap_hsmmc_enable_supply(struct mmc_host *mmc, int iov)
{
int ret;
struct mmc_ios *ios = &mmc->ios;
+ int uvoltage;
if (mmc->supply.vmmc) {
ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, ios->vdd);
@@ -255,7 +256,24 @@ static int omap_hsmmc_enable_supply(struct mmc_host *mmc)
}
/* Enable interface voltage rail, if needed */
- if (mmc->supply.vqmmc && !regulator_is_enabled(mmc->supply.vqmmc)) {
+ if (mmc->supply.vqmmc) {
+ if (regulator_is_enabled(mmc->supply.vqmmc)) {
+ ret = regulator_disable(mmc->supply.vqmmc);
+ if (ret) {
+ dev_err(mmc_dev(mmc),
+ "vmmc_aux reg disable failed\n");
+ goto err_vqmmc;
+ }
+ }
+
+ uvoltage = (iov == VDD_165_195) ? VDD_1V8 : VDD_3V0;
+ ret = regulator_set_voltage(mmc->supply.vqmmc, uvoltage,
+ uvoltage);
+ if (ret) {
+ dev_err(mmc_dev(mmc), "vmmc_aux set voltage failed\n");
+ goto err_vqmmc;
+ }
+
ret = regulator_enable(mmc->supply.vqmmc);
if (ret) {
dev_err(mmc_dev(mmc), "vmmc_aux reg enable failed\n");
@@ -304,22 +322,19 @@ err_set_ocr:
}
static int omap_hsmmc_set_pbias(struct omap_hsmmc_host *host, bool power_on,
- int vdd)
+ int iov)
{
int ret;
+ int uvoltage;
if (!host->pbias)
return 0;
if (power_on) {
- if (vdd <= VDD_165_195)
- ret = regulator_set_voltage(host->pbias, VDD_1V8,
- VDD_1V8);
- else
- ret = regulator_set_voltage(host->pbias, VDD_3V0,
- VDD_3V0);
- if (ret < 0) {
- dev_err(host->dev, "pbias set voltage fail\n");
+ uvoltage = (iov <= VDD_165_195) ? VDD_1V8 : VDD_3V0;
+ ret = regulator_set_voltage(host->pbias, uvoltage, uvoltage);
+ if (ret) {
+ dev_err(host->dev, "pbias set voltage failed\n");
return ret;
}
@@ -343,7 +358,7 @@ static int omap_hsmmc_set_pbias(struct omap_hsmmc_host
*host, bool power_on,
return 0;
}
-static int omap_hsmmc_set_power(struct device *dev, int power_on, int vdd)
+static int omap_hsmmc_set_power(struct device *dev, int power_on, int iov)
{
struct omap_hsmmc_host *host =
platform_get_drvdata(to_platform_device(dev));
@@ -358,7 +373,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
power_on, int vdd)
return 0;
if (mmc_pdata(host)->before_set_reg)
- mmc_pdata(host)->before_set_reg(dev, power_on, vdd);
+ mmc_pdata(host)->before_set_reg(dev, power_on, iov);
ret = omap_hsmmc_set_pbias(host, false, 0);
if (ret)
@@ -378,11 +393,11 @@ static int omap_hsmmc_set_power(struct device *dev, int
power_on, int vdd)
* chips/cards need an interface voltage rail too.
*/
if (power_on) {
- ret = omap_hsmmc_enable_supply(mmc);
+ ret = omap_hsmmc_enable_supply(mmc, iov);
if (ret)
return ret;
- ret = omap_hsmmc_set_pbias(host, true, vdd);
+ ret = omap_hsmmc_set_pbias(host, true, iov);
if (ret)
goto err_set_voltage;
} else {
@@ -392,7 +407,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
power_on, int vdd)
}
if (mmc_pdata(host)->after_set_reg)
- mmc_pdata(host)->after_set_reg(dev, power_on, vdd);
+ mmc_pdata(host)->after_set_reg(dev, power_on, iov);
return 0;
--
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 m
Re: [PATCH v4 04/46] staging: emxx_udc: add ep capabilities support
On 07/29/2015 05:20 PM, Felipe Balbi wrote:
> On Mon, Jul 27, 2015 at 11:16:14AM +0200, Robert Baldyga wrote:
>> Convert endpoint configuration to new capabilities model.
>>
>> Fixed typo in "epc-nulk" to "epc-bulk".
>>
>> Signed-off-by: Robert Baldyga
>> ---
>> drivers/staging/emxx_udc/emxx_udc.c | 60
>> ++---
>> 1 file changed, 29 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/staging/emxx_udc/emxx_udc.c
>> b/drivers/staging/emxx_udc/emxx_udc.c
>> index 3b7aa36..0d64bee 100644
>> --- a/drivers/staging/emxx_udc/emxx_udc.c
>> +++ b/drivers/staging/emxx_udc/emxx_udc.c
>> @@ -3153,36 +3153,33 @@ static const struct usb_gadget_ops nbu2ss_gadget_ops
>> = {
>> .ioctl = nbu2ss_gad_ioctl,
>> };
>>
>> -static const char g_ep0_name[] = "ep0";
>> -static const char g_ep1_name[] = "ep1-bulk";
>> -static const char g_ep2_name[] = "ep2-bulk";
>> -static const char g_ep3_name[] = "ep3in-int";
>> -static const char g_ep4_name[] = "ep4-iso";
>> -static const char g_ep5_name[] = "ep5-iso";
>> -static const char g_ep6_name[] = "ep6-bulk";
>> -static const char g_ep7_name[] = "ep7-bulk";
>> -static const char g_ep8_name[] = "ep8in-int";
>> -static const char g_ep9_name[] = "ep9-iso";
>> -static const char g_epa_name[] = "epa-iso";
>> -static const char g_epb_name[] = "epb-bulk";
>> -static const char g_epc_name[] = "epc-nulk";
>> -static const char g_epd_name[] = "epdin-int";
>> -
>> -static const char *gp_ep_name[NUM_ENDPOINTS] = {
>> -g_ep0_name,
>> -g_ep1_name,
>> -g_ep2_name,
>> -g_ep3_name,
>> -g_ep4_name,
>> -g_ep5_name,
>> -g_ep6_name,
>> -g_ep7_name,
>> -g_ep8_name,
>> -g_ep9_name,
>> -g_epa_name,
>> -g_epb_name,
>> -g_epc_name,
>> -g_epd_name,
>> +static const struct {
>> +const char *name;
>> +const struct usb_ep_caps caps;
>> +} ep_info[NUM_ENDPOINTS] = {
>> +#define EP_INFO(_name, _type, _dir) \
>> +{ \
>> +.name = _name, \
>> +.caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
>> +USB_EP_CAPS_DIR_ ## _dir), \
>> +}
>> +
>> +EP_INFO("ep0", CONTROL, ALL),
>> +EP_INFO("ep1-bulk", BULK, ALL),
>> +EP_INFO("ep2-bulk", BULK, ALL),
>> +EP_INFO("ep3in-int",INT,IN),
>> +EP_INFO("ep4-iso", INT,ALL),
>> +EP_INFO("ep5-iso", ISO,ALL),
>> +EP_INFO("ep6-bulk", ISO,ALL),
>> +EP_INFO("ep7-bulk", BULK, ALL),
>> +EP_INFO("ep8in-int",INT,IN),
>> +EP_INFO("ep9-iso", ISO,ALL),
>> +EP_INFO("epa-iso", ISO,ALL),
>> +EP_INFO("epb-bulk", BULK, ALL),
>> +EP_INFO("epc-bulk", BULK, ALL),
>> +EP_INFO("epdin-int",INT,IN),
>
> IMO, this is pointless obfuscation. It just makes it a pain to grep
> source around. Why don't you have UDC drivers initialize the 1-bit flags
> directly ?
>
Do you mean something like this? It just makes it a pain to scroll this
source ;)
static const struct {
const char *name;
const struct usb_ep_caps caps;
} ep_info[NUM_ENDPOINTS] = {
{
.name = "ep0",
.caps = {
.type_control = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = "ep1-bulk",
.caps = {
.type_bulk = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = "ep2-bulk",
.caps = {
.type_bulk = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = "ep3in-int",
.caps = {
.type_int = true,
.dir_in = true,
},
},
{
.name = "ep4-iso",
.caps = {
.type_iso = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = "ep5-iso",
.caps = {
.type_iso = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = "ep6-bulk",
.caps = {
.type_bulk = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = "ep7-bulk",
.caps = {
.type_bulk = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = "ep8in-int",
.caps = {
