On Sat, Oct 06, 2012 at 04:49:56PM +0100, Alan Cox wrote:
> On Sat, 06 Oct 2012 13:45:47 +0100
> Russell King wrote:
>
> > This allows drivers (such as OMAP serial) to allocate and free their
> > transmit buffers in a sane manner, rather than working around the
> > buffer allocation provided by s
On Sat, 6 Oct 2012 08:40:52 -0700, Tony Lindgren wrote:
> * Nicolas Pitre [121006 08:33]:
>> On Sat, 6 Oct 2012, Tony Lindgren wrote:
>>
>> > * Marc Zyngier [121006 03:19]:
>> >
>> > > If so, that indicates some side effect of the safe_svcmode_maskall
>> > > macro,
>> > > and I suspect the "mo
* Marc Zyngier [121006 03:19]:
>
> If so, that indicates some side effect of the safe_svcmode_maskall macro,
> and I suspect the "movs pc, lr" bit.
>
> Can you try the attached patch? It basically falls back to the previous
> behaviour if not entered in HYP mode.
...
> diff --git a/arch/arm/inc
On Sat, 6 Oct 2012 13:38:03 +0100
Russell King - ARM Linux wrote:
> Hi,
>
> This series of patches fixes multiple flow control issues with the OMAP
> serial driver, and prepares the driver for DMA engine conversion. We
> require hardware assisted flow control to work properly for DMA support
>
On Sat, 06 Oct 2012 13:45:47 +0100
Russell King wrote:
> This allows drivers (such as OMAP serial) to allocate and free their
> transmit buffers in a sane manner, rather than working around the
> buffer allocation provided by serial_core.
I think this just illustrates how broken the serial_core
On Sat, Oct 06, 2012 at 11:32:16AM -0400, Nicolas Pitre wrote:
> On Sat, 6 Oct 2012, Tony Lindgren wrote:
> > * Marc Zyngier [121006 03:19]:
> >
> > > If so, that indicates some side effect of the safe_svcmode_maskall macro,
> > > and I suspect the "movs pc, lr" bit.
> > >
> > > Can you try the
* Nicolas Pitre [121006 08:33]:
> On Sat, 6 Oct 2012, Tony Lindgren wrote:
>
> > * Marc Zyngier [121006 03:19]:
> >
> > > If so, that indicates some side effect of the safe_svcmode_maskall macro,
> > > and I suspect the "movs pc, lr" bit.
> > >
> > > Can you try the attached patch? It basicall
Another issue:
serial_omap_set_termios()
{
...
/* FIFOs and DMA Settings */
/* FCR can be changed only when the
* baud clock is not running
* DLL_REG and DLH_REG set to 0.
*/
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
serial_ou
On Sat, 6 Oct 2012, Tony Lindgren wrote:
> * Marc Zyngier [121006 03:19]:
>
> > If so, that indicates some side effect of the safe_svcmode_maskall macro,
> > and I suspect the "movs pc, lr" bit.
> >
> > Can you try the attached patch? It basically falls back to the previous
> > behaviour if not
On Sat, 6 Oct 2012 10:06:00 -0400 (EDT), Nicolas Pitre
wrote:
> On Sat, 6 Oct 2012, Marc Zyngier wrote:
>
>> Hi Tony,
>>
>> On Fri, 5 Oct 2012 13:08:22 -0700, Tony Lindgren
>> wrote:
>> > Hi,
>> >
>> > * Marc Zyngier [120907 10:04]:
>> >> From: Dave Martin
>> >>
>> >> This patch does two th
* Nicolas Pitre [121006 07:07]:
> On Sat, 6 Oct 2012, Marc Zyngier wrote:
> >
> > If so, that indicates some side effect of the safe_svcmode_maskall macro,
> > and I suspect the "movs pc, lr" bit.
>
> That would be surprizing if the "movs pc, lr" was to blame. This should
> work on all archite
Hi,
* Marc Zyngier [121006 03:19]:
>
> If you compiled for v6 only, we can safely exclude __hyp_stub_install, and
> I assume that you get past the decompressor.
Yes, by default it's v6 + v7, but making it v6 only did not help.
> If so, that indicates some side effect of the safe_svcmode_maska
Another potential bug - in serial_omap_set_termios() there is this:
if (up->use_dma) {
serial_out(up, UART_TI752_TLR, 0);
up->scr |= UART_FCR_TRIGGER_4;
} else {
/* Set receive FIFO threshold to 1 byte */
up->fcr &= ~O
On Sat, Oct 06, 2012 at 01:38:03PM +0100, Russell King - ARM Linux wrote:
> Hi,
>
> This series of patches fixes multiple flow control issues with the OMAP
> serial driver, and prepares the driver for DMA engine conversion. We
> require hardware assisted flow control to work properly for DMA supp
On Sat, 6 Oct 2012, Marc Zyngier wrote:
> Hi Tony,
>
> On Fri, 5 Oct 2012 13:08:22 -0700, Tony Lindgren wrote:
> > Hi,
> >
> > * Marc Zyngier [120907 10:04]:
> >> From: Dave Martin
> >>
> >> This patch does two things:
> >>
> >> * Ensure that asynchronous aborts are masked at kernel entry
OMAP_UART_SYSC_RESET and OMAP_UART_FIFO_CLR are unused, remove them.
Signed-off-by: Russell King
---
arch/arm/plat-omap/include/plat/omap-serial.h |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/includ
struct uart_omap_port and struct uart_omap_dma, and associated
definitions are private to the driver, so there's no point them sitting
in an include file under arch/arm. Move them into the driver itself.
Signed-off-by: Russell King
---
arch/arm/plat-omap/include/plat/omap-serial.h | 87 --
Signed-off-by: Russell King
---
drivers/tty/serial/omap-serial.c | 49 +-
1 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 6054fc8..a5482da 100644
--- a/drivers/tty/seri
Rather than working around serial_core, use the newly provided buffer
allocation API to allow a saner method to manage this buffer.
Signed-off-by: Russell King
---
drivers/tty/serial/omap-serial.c | 38 +-
1 files changed, 29 insertions(+), 9 deletions(-)
d
This allows drivers (such as OMAP serial) to allocate and free their
transmit buffers in a sane manner, rather than working around the
buffer allocation provided by serial_core.
Signed-off-by: Russell King
---
drivers/tty/serial/serial_core.c | 23 ---
include/linux/serial_
Simplify:
- set ECB
...
- LCR mode A
- clear TCRTLR
- LCR mode B
- clear ECB
- set ECB and update other bits
- LCR mode A
- update XONANY
to:
- set ECB
...
- LCR mode B
- set ECB and update othe
Take advantage of the switch to mode B for accessing the TCR register,
and move the xon/xoff configuration there. This allows further
simplication of this sequence.
Signed-off-by: Russell King
---
drivers/tty/serial/omap-serial.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletio
We always setup the TCR register in the software flow control path,
and when hardware flow control is enabled. Remove this redundant
setup, and place it before we setup any hardware flow control.
Signed-off-by: Russell King
---
drivers/tty/serial/omap-serial.c | 25 ++---
We have the sequence:
- LCR mode B
- write EFR with ECB clear
- LCR mode normal
- LCR mode B
- write EFR with ECB clear
This can be simplified to just two writes:
- LCR mode B
- write EFR with ECB clear
Signed-off-by: Russell King
---
driv
There's really no reason to read back these registers while setting
the termios modes, provided we keep our cached copies up to date.
Remove these readbacks.
This has the benefit that we know that the EFR_ECB and MCR_TCRTLR
bits will always be clear, so we don't need to keep masking these
bits thr
Signed-off-by: Russell King
---
drivers/tty/serial/omap-serial.c | 109 ++
1 files changed, 51 insertions(+), 58 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index cc1a907..b6f8b88 100644
--- a/drivers/tty/seri
Signed-off-by: Russell King
---
drivers/tty/serial/omap-serial.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index ab5a5e0..cc1a907 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/se
When the UART device has hardware flow control enabled, it ignores the
MCR RTS bit in the MCR register, and keeps RTS asserted as long as we
continue to read characters from the UART receiver FIFO. This means
that when the TTY buffers become full, the UART doesn't tell the remote
end to stop sendi
Add two callbacks for hardware assisted flow control; we need to know
when the tty layers want us to stop and restart due to their buffer
levels.
Call a driver specific throttle/unthrottle function if and only if the
driver indicates that it is using an enabled hardware assisted flow
control metho
Ports which are handling h/w flow control in hardware must not have
their RTS state altered depending on the tty's hardware-stopped state.
Avoid this additional logic when setting the termios state.
Signed-off-by: Russell King
---
drivers/tty/serial/serial_core.c |7 +++
include/linux/se
Ports which are capable of handling s/w flow control in hardware to
know when the s/w flow control termios settings are changed. Add a
flag to allow the low level serial drivers to indicate that they
support this, and these changes should be propagated to them.
Signed-off-by: Russell King
---
d
This is to make the following change more clear.
Signed-off-by: Russell King
---
drivers/tty/serial/serial_core.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index a21dc8e..95e6e32 10
Nothing was clearing the UART_MCR_XONANY bit, so once the ixany
mode gets set, there's no possibility to disable it. Clear this
bit when IXANY mode is cleared.
Signed-off-by: Russell King
---
drivers/tty/serial/omap-serial.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --gi
There is nothing which clears the auto RTS/CTS bits, so once hardware
flow control gets enabled, there's no possibility to disable it.
So, clear these bits when CRTSCTS is cleared.
Signed-off-by: Russell King
---
drivers/tty/serial/omap-serial.c |7 +++
1 files changed, 7 insertions(+),
There's no need to re-read EFR after we've recently written it; the
register is a configuration register which doesn't change its value
without us writing to it.
Removing this re-reading avoids the possibility that we end up with
up->efr having the ECB bit set, which should only be temporarily set
c538d20c7f (and maybe previous commits) broke set_mctrl() by making
it only capable of setting bits in the MCR register. This prevents
software controlled flow control and modem control line manipulation
via TIOCMSET/TIOCMBIC from working correctly.
Signed-off-by: Russell King
---
drivers/tty/s
The MCR TCRTLR bit can only be changed when ECB is set in the EFR.
Unfortunately, several places were trying to alter this bit while ECB
was clear:
- serial_omap_configure_xonxoff() was attempting to clear the bit after
explicitly clearing the ECB bit.
- serial_omap_set_termios() was trying the
The SCD (special character detect) bit enables comparisons with XOFF2,
which we do not program. As the XOFF2 character remains unprogrammed,
there's little point enabling this feature along with its associated
interrupt. Remove this.
Signed-off-by: Russell King
---
drivers/tty/serial/omap-seri
This makes ixoff control whether the XON/XOFF characters are
transmitted, and ixon control whether XON/XOFF are actioned when
received. This is as required by the POSIX specification.
Signed-off-by: Russell King
---
arch/arm/plat-omap/include/plat/omap-serial.h |4 ++--
drivers/tty/serial/o
Hi,
This series of patches fixes multiple flow control issues with the OMAP
serial driver, and prepares the driver for DMA engine conversion. We
require hardware assisted flow control to work properly for DMA support
otherwise we have no way to properly pause the transmitter.
This is generated a
On Thu, Sep 20, 2012 at 06:08:03PM +0200, Jean Pihet wrote:
> Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat
> API to the new PM QoS API.
> Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY
> class of PM QoS. The resulting MPU constraints are used by
Hi Tony,
On Fri, 5 Oct 2012 13:08:22 -0700, Tony Lindgren wrote:
> Hi,
>
> * Marc Zyngier [120907 10:04]:
>> From: Dave Martin
>>
>> This patch does two things:
>>
>> * Ensure that asynchronous aborts are masked at kernel entry.
>> The bootloader should be masking these anyway, but thi
2012/10/5 Javier Martinez Canillas :
> On Fri, Oct 5, 2012 at 10:10 AM, Thomas Petazzoni
> wrote:
>>
>> On Fri, 5 Oct 2012 09:32:07 +0200, Javier Martinez Canillas wrote:
>>
>>> As Enric said, u-boot has SPL and NAND support for IGEP since
>>> v2012.10-rc1. I just tried kernel a 3.6 with u-boot v2
43 matches
Mail list logo