Hi,
On 03/20/2014 02:20 PM, Kishon Vijay Abraham I wrote:
Hi,
On Thursday 20 March 2014 07:52 AM, Chanwoo Choi wrote:
Hi,
On 03/19/2014 09:08 PM, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 18 March 2014 05:34 PM, Chanwoo Choi wrote:
This patch remove unnecessary function call in
Beaglebone Board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
(b) NAND Device
Series is rebased on following tree for OMAP DT
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
:omap-for-v3.15/dt
*changes v1 - v2*
[PATCH v2 1/2] created new DTS for memory-capes based on following feedbacks
http://www.spinics.net/lists/linux-omap/msg104348.html from
Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
am437x-gp-evm board.
(1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
(a) By dynamically driving following
Hi,
On Thursday 20 March 2014 12:26 PM, Chanwoo Choi wrote:
Hi,
On 03/20/2014 02:20 PM, Kishon Vijay Abraham I wrote:
Hi,
On Thursday 20 March 2014 07:52 AM, Chanwoo Choi wrote:
Hi,
On 03/19/2014 09:08 PM, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 18 March 2014 05:34 PM, Chanwoo
This patch refactors elm_load_syndrome() to make it scalable for newer
ECC schemes by removing scheme specific macros (like ECC_BYTES*xx),
and instead using ECC control information passed during elm_config.
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/devices/elm.c | 18
ELM hardware engine is used by BCH ecc-schemes for detecting and locating ECC
errors. This patch adds the following checks for ELM hardware engine:
- ELM internal buffers are of 1K,
so it cannot process data with ecc-step-size 1K.
- ELM engine can execute upto maximum of 8 threads in
ELM hardware can process up to maximum of 8 hannels in parallel for
ECC error detection. Currently the number of channels getting configured for
processing is static determined by macro ERROR_VECTOR_MAX. However, the actual
number of channels that need to be processed is the ECC step number.
This
*changes v7 - v8*
Incorporated feedbacks from Brian Norris computersforpe...@gmail.com
- renamed ecc_step_bytes - ecc_syndrome_size
*changes v6 - v7*
Incorporated feedbacks from Ezequiel Garcia ezequiel.gar...@free-electrons.com
- using dev_err() instead of pr_err()
- moved un-related
use omap-elm as DRIVER_NAME
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/devices/elm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/devices/elm.c
index 26df41f..1fd4a0f 100644
--- a/drivers/mtd/devices/elm.c
+++
From: Gupta, Pekon
Subject: [PATCH v8 0/4] mtd: devices: elm: add checks ELM H/W constrains,
driver code cleanup
Sorry, sent to the wrong list.. was intended for linux-mtd list
Please ignore the whole series.
with regards, pekon
--
To unsubscribe from this list: send the line unsubscribe
On Sunday 23 February 2014, Thomas Gleixner wrote:
--- tip.orig/arch/arm/mach-omap1/ams-delta-fiq.c
+++ tip/arch/arm/mach-omap1/ams-delta-fiq.c
@@ -44,13 +44,10 @@ static unsigned int irq_counter[16];
static irqreturn_t deferred_fiq(int irq, void *dev_id)
{
- struct irq_desc
it wasn't used by anything, just remove it.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index c79d3e6..b092d3d 100644
---
UART IRQ Identification bitfield is 3
bits long (bits 3:1) but current mask only
masks 2 bits. Fix it.
Signed-off-by: Felipe Balbi ba...@ti.com
---
include/uapi/linux/serial_reg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/serial_reg.h
LDISCs shouldn't call tty-ops-write() from within
-write_wakeup().
-write_wakeup() is called with port lock taken and
IRQs disabled, tty-ops-write() will try to acquire
the same port lock and we will deadlock.
Reviewed-by: Peter Hurley pe...@hurleysoftware.com
Reported-by: Huang Shijie
This reverts commit 0324a821029e1f54e7a7f8fed48693cfce42dc0e.
That commit tried to fix a deadlock problem when using
hci_ldisc, but it turns out the bug was in hci_ldsic
all along where it was calling -write() from within
-write_wakeup() callback.
The problem is that -write_wakeup() was called
From: Huang Shijie b32...@freescale.com
The Documentation/serial/driver tells us:
---
start_tx(port)
Start transmitting characters.
Locking: port-lock taken.
Interrupts: locally disabled.
nobody passes a DTR_gpio to this driver, so
this code is not necessary.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 39 ---
1 file changed, 39 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
just using helper function to remove some duplicated
code a bit. While at that, also move allocation of
struct uart_omap_port higher in the code so that
we return much earlier in case of no memory.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 32
this will make sure gpio gets freed automatically
when this device is destroyed.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
this way we can remove one pointer declaration.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 6831425..d041060
cleanup only, no functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index db5d90b..6831425 100644
---
per CodingStyle we should have those braces, no
functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index
Hi,
On Thu, Mar 20, 2014 at 02:30:04PM -0500, Felipe Balbi wrote:
From: Huang Shijie b32...@freescale.com
The Documentation/serial/driver tells us:
---
start_tx(port)
Start transmitting characters.
Locking: port-lock taken.
Hi Felipe,
LDISCs shouldn't call tty-ops-write() from within
-write_wakeup().
-write_wakeup() is called with port lock taken and
IRQs disabled, tty-ops-write() will try to acquire
the same port lock and we will deadlock.
Reviewed-by: Peter Hurley pe...@hurleysoftware.com
Reported-by:
On Thu, Mar 20, 2014 at 12:40:40PM -0700, Marcel Holtmann wrote:
Hi Felipe,
LDISCs shouldn't call tty-ops-write() from within
-write_wakeup().
-write_wakeup() is called with port lock taken and
IRQs disabled, tty-ops-write() will try to acquire
the same port lock and we will
Quoting Tero Kristo (2014-03-05 05:10:17)
Ping.
Mike, any feedback on this?
Hi Tero,
Have you seen Sylwester's approach[1]? I prefer it since it is more
device-oriented and less centralized. The clock consumer enumerates
the default parent or rate of a consumed clock. This can be made to
Hi folks,
I've been toying with the idea of removing
drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
ungly copy of 8250 driver.
The original concern was wrt suspend/resume but I think it'd be a far
better approach to implement runtime PM in 8250 and write a rather small
On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
Hi folks,
I've been toying with the idea of removing
drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
ungly copy of 8250 driver.
The original concern was wrt suspend/resume but I think it'd be a far
better
On Thu, 2014-03-20 at 18:52 -0500, Felipe Balbi wrote:
Hi folks,
I've been toying with the idea of removing
drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
ungly copy of 8250 driver.
The original concern was wrt suspend/resume but I think it'd be a far
better
Hi,
On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote:
On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
Hi folks,
I've been toying with the idea of removing
drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
ungly copy of 8250 driver.
The
On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote:
Hi,
On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote:
On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
Hi folks,
I've been toying with the idea of removing
drivers/tty/serial/omap-serial.c since
On Thu, Mar 20, 2014 at 08:37:29PM -0500, Felipe Balbi wrote:
On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote:
Hi,
On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote:
On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
Hi folks,
I've been toying
On Thu, Mar 20, 2014 at 9:36 PM, Greg KH gre...@linuxfoundation.org wrote:
On Thu, Mar 20, 2014 at 08:37:29PM -0500, Felipe Balbi wrote:
On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote:
Hi,
On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote:
On Thu, Mar 20, 2014 at
On Thu, Mar 20, 2014 at 09:45:42PM -0500, Robert Nelson wrote:
On Thu, Mar 20, 2014 at 9:36 PM, Greg KH gre...@linuxfoundation.org wrote:
On Thu, Mar 20, 2014 at 08:37:29PM -0500, Felipe Balbi wrote:
On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote:
Hi,
On Thu, Mar 20,
From: Dave Gerlach d-gerl...@ti.com
Do not reset GPIO5 at boot-up because GPIO5_7 is used
on AM437x GP-EVM to control VTT regulators on DDR3.
Without this some GP-EVM boards will fail to boot because
of DDR3 corruption.
Reported-by: Nishanth Menon n...@ti.com
Tested-by: Nishanth Menon
On Fri, Mar 21, 2014 at 10:50:13AM +0530, Lokesh Vutla wrote:
From: Dave Gerlach d-gerl...@ti.com
Do not reset GPIO5 at boot-up because GPIO5_7 is used
on AM437x GP-EVM to control VTT regulators on DDR3.
Without this some GP-EVM boards will fail to boot because
of DDR3 corruption.
37 matches
Mail list logo
