Re: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
On Thu, Oct 11, 2012 at 1:21 PM, Sourav sourav.pod...@ti.com wrote: If you have any pointers on how to test hardware flow control, I will like to do that on my beagle board. If you can find some board with BT chip connected to UART, that would be a good test as they usually have flow control lines connected and can run at high bitrates. I think some EVM or Zoom boards have BT chips. -- GraÅžvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
Hi Kevin, On Wednesday 10 October 2012 11:59 PM, Kevin Hilman wrote: Hi Sourav, Sourav sourav.pod...@ti.com writes: [...] Boot Tested this patch series against v3.6 tag(applied cleanly) on panda board and PM tested(hitting off in Idle and suspend) on omap3630 based beagle board. Note, I also tested the patches against the current master but only after rebasing, since the current master includes serial patches from Felipe Balbi[1]. [1] https://lkml.org/lkml/2012/8/24/139 Tested-by: Sourav Poddar sourav.pod...@ti.com Did you test flow control after off-mode transitons? Russell indicated that the context save/restore is not saving important bits related to HW flow control, so I suspect some more testing, specifically of flow control after off-mode is needed. Kevin The testing done was without any flow control enabled. I will try to figure out how to do a hardware flow control testing and see the status after the off mode. ~Sourav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
On Thu, Oct 11, 2012 at 03:13:43PM +0530, Sourav wrote: Hi Kevin, On Wednesday 10 October 2012 11:59 PM, Kevin Hilman wrote: Hi Sourav, Sourav sourav.pod...@ti.com writes: [...] Boot Tested this patch series against v3.6 tag(applied cleanly) on panda board and PM tested(hitting off in Idle and suspend) on omap3630 based beagle board. Note, I also tested the patches against the current master but only after rebasing, since the current master includes serial patches from Felipe Balbi[1]. [1] https://lkml.org/lkml/2012/8/24/139 Tested-by: Sourav Poddar sourav.pod...@ti.com Did you test flow control after off-mode transitons? Russell indicated that the context save/restore is not saving important bits related to HW flow control, so I suspect some more testing, specifically of flow control after off-mode is needed. Kevin The testing done was without any flow control enabled. So, as the patch set is about fixing the flow control stuff, would you say that your testing without flow control enabled has much value? I will try to figure out how to do a hardware flow control testing and see the status after the off mode. It's software flow control which isn't properly restored... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
Hi Russell, On Thursday 11 October 2012 03:24 PM, Russell King - ARM Linux wrote: On Thu, Oct 11, 2012 at 03:13:43PM +0530, Sourav wrote: Hi Kevin, On Wednesday 10 October 2012 11:59 PM, Kevin Hilman wrote: Hi Sourav, Sourav sourav.pod...@ti.com writes: [...] Boot Tested this patch series against v3.6 tag(applied cleanly) on panda board and PM tested(hitting off in Idle and suspend) on omap3630 based beagle board. Note, I also tested the patches against the current master but only after rebasing, since the current master includes serial patches from Felipe Balbi[1]. [1] https://lkml.org/lkml/2012/8/24/139 Tested-by: Sourav Poddar sourav.pod...@ti.com Did you test flow control after off-mode transitons? Russell indicated that the context save/restore is not saving important bits related to HW flow control, so I suspect some more testing, specifically of flow control after off-mode is needed. Kevin The testing done was without any flow control enabled. So, as the patch set is about fixing the flow control stuff, would you say that your testing without flow control enabled has much value? True. I missed that point while doing the testing. Sorry for that. I further looked into it and saw some two options in my minicom settings(Hardware Flow Control/ Software Flow Control) Which I am thinking are the ones used to enable the flow control ? and they are both set to NO. I already enable software flow control and did the testing on beagle, where things are working fine after off mode. But if I enable hardware flow control, the teraterm does not allow me to load my fs and uImage from mmc. If you have any pointers on how to test hardware flow control, I will like to do that on my beagle board. Thanks, Sourav I will try to figure out how to do a hardware flow control testing and see the status after the off mode. It's software flow control which isn't properly restored... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
On Thu, Oct 11, 2012 at 03:51:00PM +0530, Sourav wrote: True. I missed that point while doing the testing. Sorry for that. I further looked into it and saw some two options in my minicom settings(Hardware Flow Control/ Software Flow Control) Which I am thinking are the ones used to enable the flow control ? and they are both set to NO. I already enable software flow control and did the testing on beagle, where things are working fine after off mode. But if I enable hardware flow control, the teraterm does not allow me to load my fs and uImage from mmc. If you have any pointers on how to test hardware flow control, I will like to do that on my beagle board. Okay, it sounds like I need to do a teach-in on flow control... First, hardware flow control. Hardware flow control is operated by two signals: RTS and CTS. In conventional setups, CTS is an input to the transmitter, and controls whether the transmitter may start the transmission of a new character. If CTS is deasserted, the transmitter will stop after the completion of the previous character. When hardware flow control is disabled, the transmitter ignores this signal. RTS is an output, and is generally used to control the remote transmitter. (There are setups where RTS means something else, but the kernel doesn't support other schemes directly.) RTS is asserted when either hardware flow control is disabled, or there is sufficient space to receive more characters from the remote end. This is a symetrical setup, so that two UARTs connected together using this scheme will have the RTS of one connected to the CTS of the other. This way, each can signal whether characters should be transmitted. So, in minicom, when hardware flow control is disabled, your hosts transmitter will ignore the state of the CTS signal, and will hold its RTS asserted. If hardware flow control in minicom is enabled, then that tells the kernel (and possibly hardware) to take note of the CTS signal, and pause transmission when CTS is deasserted. It will also cause the RTS signal to be manipulated according to available buffer space on the receive side. Obviously minicom will try to ensure that any characters received are displayed as quickly as possible, so it's unlikely that the receive side will fill up. When you're logged into a system via a serial line, the hardware flow control state is controlled by the CRTSCTS termios flag. That can be seen and manipulated by stty. stty -a to see all flags. stty -crtscts to disable, stty crtscts to enable. Now, for software flow control. It operates in the same way as above, but instead of a hardware signal reporting the state, characters are embedded into the stream. In normal situations, these characters are the standard ^Q (noramlly XON) and ^S (XOFF) characters. You'll find that works in gnome-terminals, xterms, and many places because it's part of the standard terminal interface. You can type these characters into minicom with or without software flow control disabled; it just passes them through unmodified. When software flow control is enabled, and the tty receive buffers start to fill up, the kernel will queue a high-priority XOFF character for the UART to transmit to the remote end. Once the tty buffers have emptied sufficiently, it will queue a high-priority XON character. If software flow control is disabled, it will ignore this. When hardware assisted software flow control is enabled, this will be done by the hardware itself in response to the UART FIFO filling up and emptying. For the target, software flow control has more configuration options: ixon: controls whether the transmitter starts/stops on reception of xon/xoff characters ixoff: controls the generation of xon/xoff characters ixany: permits any received character (including xon) to restart transmission stop char: sets the xoff character to the specified character start char: sets the xon character to the specified character xon and xoff default to ^Q and ^S respectively, there's no need to 'initialize' them prior to use. So, to enable software flow control (which is probably already enabled on the target): stty ixon ixoff and then you can type ^S and ^Q into minicom to stop/start the target's transmit output. Finally, to make the target's input buffer fill up, arrange for the target not to read from the controlling tty at all. sleep 120 will do that for two minutes, after which the input will be gobbled up by the shell (which it'll try to interpret as commands.) So, probably better to do: sleep 120; echo Finished; cat /dev/null instead, and then send lots of data, and check whether the transmission stops, whether the right xon/xoff characters are transmitted, and whether any overrun errors are reported. Going the other way, you can suspend minicom (^a z) and then arrange for the target to send lots of data, and again check
Re: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
Hi Sourav, On 10/11/2012 05:21 AM, Sourav wrote: [snip] I already enable software flow control and did the testing on beagle, where things are working fine after off mode. But if I enable hardware flow control, the teraterm does not allow me to load my fs and uImage from mmc. If you have any pointers on how to test hardware flow control, I will like to do that on my beagle board. For h/w flow control, you need to check if the CTS and RTS signals are being brought out to the serial header on the beagle-board. Looking at the schematics for the 3430 beagle board, it appears that only the UART RX and TX signals are available on the serial header. Therefore, I don't believe you can test h/w flow control using the console with that board. I do see that you can access all the UART2 signals (RX/TX/CTS/RTS) via the expansion connector on the beagle. However, to connect to a serial port on a PC you need to have a voltage level-shifter in-between. There are some companies out there that make them [1], but you need to make sure you have one that can support a 1.8V input. Cheers Jon [1] http://elinux.org/RS232_Level_Shifter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
Hi Sourav, Sourav sourav.pod...@ti.com writes: [...] Boot Tested this patch series against v3.6 tag(applied cleanly) on panda board and PM tested(hitting off in Idle and suspend) on omap3630 based beagle board. Note, I also tested the patches against the current master but only after rebasing, since the current master includes serial patches from Felipe Balbi[1]. [1] https://lkml.org/lkml/2012/8/24/139 Tested-by: Sourav Poddar sourav.pod...@ti.com Did you test flow control after off-mode transitons? Russell indicated that the context save/restore is not saving important bits related to HW flow control, so I suspect some more testing, specifically of flow control after off-mode is needed. 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
Re: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
Hi,
On Saturday 06 October 2012 06:08 PM, 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
otherwise we have no way to properly pause the transmitter.
This is generated against v3.6, and has been developed mainly by testing
on the OMAP4430 SDP platform.
Flow control seems to be really broken in the OMAP serial driver as things
stand today. It just about works with software flow control because the
generic serial core layer is inserting those characters, but only when the
legacy DMA support is not being used. Otherwise, flow control is
completely non-functional.
Issues identified in the OMAP serial driver are:
- set_mctrl() can only assert modem control lines, once asserted it
is not possible to deassert them.
- IXOFF controls sending of XON/XOFF characters, not the reception of
these sequences.
- IXON controls the recognition of XON/XOFF characters, not the transmission
of the same.
- Wrong bitmasks for hardware assisted software flow control. Bit 2
in EFR enables sending of XON2/XOFF2 which are never set.
- No point comparing received characters against XOFF2 ('special character
detect') as XOFF2 is not set.
- Fix multiple places where bits 6 and 5 of MCR are attempted to be
altered, but because EFR ECB is unset, these bits remain unaffected.
This effectively prevents us accessing the right XON/XOFF/TCR/TLR
registers.
- Remove unnecessary read-backs of EFR/MCR/LCR registers - these registers
don't change beneath us, they are configuration registers which hold their
values. Not only does this simplify the code, but it makes it more
readable, and more importantly ensures that we work from a consistent
state where -efr never has ECB set, and -mcr never has the TCRTLR
bit set.
- Fix disablement of hardware flow control and IXANY modes; once enabled
these could never be disabled because nothing in the code ever clears
these configuration bits.
Once that lot is fixed, these patches expand serial_core to permit hardware
assisted flow control by:
- adding throttle/unthrottle callbacks into low level serial drivers,
which allow them to take whatever action is necessary with hardware
assisted flow control to throttle the remote end. In the case of
OMAP serial, this means disabling the RX interrupts so that the FIFO
fills to the watermark.
We then have a number of cleanups to the OMAP serial code to make the
set_termios() function clearer and less prone to the kinds of mistakes
identified above. This results in a great simplification of the flow
control configuration code.
The OMAP serial driver hacks around with the transmit buffer allocation;
lets clean that up so that drivers can cleanly allocate their transmitter
buffer using coherent memory if that's what they desire.
Finally, the last few patches clean up the plat/omap-serial.h header file,
moving most of its contents into the OMAP serial driver itself. Most of
this is private to the OMAP serial driver and should never have been
shared with anything else.
I have omitted to include the conversion of the transmit paths to DMA
engine. Even with all the above fixed, it has issues when DMA transmit
is in progress, and a program issues a TCSETS call (as `less' does after
it has written its prompt.) At the moment, this causes lots of junk to
be emitted from the serial port when issuing `dmesg | less' which sometimes
brings the port to a complete halt.
As the OMAP DMA hardware does not have a clean pause when performing a
MEM-DEV transfer (it discards its FIFO) I do not see a solution to this,
which probably means that we can _not_ ever support transmit DMA on OMAP
platforms.
This means the xmit buffer allocation patches are not that useful unless
a solution to that can be found.
Now, the remaining question is, how much of this patch set do we think
about merging, and when. Given that flow control in this driver has been
broken for a very long time, and no one has apparantly noticed, I don't
think there's any urgency to this, so given its size, my preference would
be to queue it up for the next merge window. The thing that would worry
me about applying some of the initial patches is that they may change
the behaviour today and make any problems here more visible.
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Boot Tested this patch series against v3.6 tag(applied cleanly) on panda
board and
PM tested(hitting off in Idle and suspend) on omap3630 based beagle board.
Note, I also tested the patches against the current master but only
after rebasing, since the current master includes serial patches from
Felipe Balbi[1].
[1] https://lkml.org/lkml/2012/8/24/139
[RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
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 against v3.6, and has been developed mainly by testing
on the OMAP4430 SDP platform.
Flow control seems to be really broken in the OMAP serial driver as things
stand today. It just about works with software flow control because the
generic serial core layer is inserting those characters, but only when the
legacy DMA support is not being used. Otherwise, flow control is
completely non-functional.
Issues identified in the OMAP serial driver are:
- set_mctrl() can only assert modem control lines, once asserted it
is not possible to deassert them.
- IXOFF controls sending of XON/XOFF characters, not the reception of
these sequences.
- IXON controls the recognition of XON/XOFF characters, not the transmission
of the same.
- Wrong bitmasks for hardware assisted software flow control. Bit 2
in EFR enables sending of XON2/XOFF2 which are never set.
- No point comparing received characters against XOFF2 ('special character
detect') as XOFF2 is not set.
- Fix multiple places where bits 6 and 5 of MCR are attempted to be
altered, but because EFR ECB is unset, these bits remain unaffected.
This effectively prevents us accessing the right XON/XOFF/TCR/TLR
registers.
- Remove unnecessary read-backs of EFR/MCR/LCR registers - these registers
don't change beneath us, they are configuration registers which hold their
values. Not only does this simplify the code, but it makes it more
readable, and more importantly ensures that we work from a consistent
state where -efr never has ECB set, and -mcr never has the TCRTLR
bit set.
- Fix disablement of hardware flow control and IXANY modes; once enabled
these could never be disabled because nothing in the code ever clears
these configuration bits.
Once that lot is fixed, these patches expand serial_core to permit hardware
assisted flow control by:
- adding throttle/unthrottle callbacks into low level serial drivers,
which allow them to take whatever action is necessary with hardware
assisted flow control to throttle the remote end. In the case of
OMAP serial, this means disabling the RX interrupts so that the FIFO
fills to the watermark.
We then have a number of cleanups to the OMAP serial code to make the
set_termios() function clearer and less prone to the kinds of mistakes
identified above. This results in a great simplification of the flow
control configuration code.
The OMAP serial driver hacks around with the transmit buffer allocation;
lets clean that up so that drivers can cleanly allocate their transmitter
buffer using coherent memory if that's what they desire.
Finally, the last few patches clean up the plat/omap-serial.h header file,
moving most of its contents into the OMAP serial driver itself. Most of
this is private to the OMAP serial driver and should never have been
shared with anything else.
I have omitted to include the conversion of the transmit paths to DMA
engine. Even with all the above fixed, it has issues when DMA transmit
is in progress, and a program issues a TCSETS call (as `less' does after
it has written its prompt.) At the moment, this causes lots of junk to
be emitted from the serial port when issuing `dmesg | less' which sometimes
brings the port to a complete halt.
As the OMAP DMA hardware does not have a clean pause when performing a
MEM-DEV transfer (it discards its FIFO) I do not see a solution to this,
which probably means that we can _not_ ever support transmit DMA on OMAP
platforms.
This means the xmit buffer allocation patches are not that useful unless
a solution to that can be found.
Now, the remaining question is, how much of this patch set do we think
about merging, and when. Given that flow control in this driver has been
broken for a very long time, and no one has apparantly noticed, I don't
think there's any urgency to this, so given its size, my preference would
be to queue it up for the next merge window. The thing that would worry
me about applying some of the initial patches is that they may change
the behaviour today and make any problems here more visible.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
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 support
otherwise we have no way to properly pause the transmitter.
This is generated against v3.6, and has been developed mainly by testing
on the OMAP4430 SDP platform.
Flow control seems to be really broken in the OMAP serial driver as things
stand today. It just about works with software flow control because the
generic serial core layer is inserting those characters, but only when the
legacy DMA support is not being used. Otherwise, flow control is
completely non-functional.
Issues identified in the OMAP serial driver are:
- set_mctrl() can only assert modem control lines, once asserted it
is not possible to deassert them.
- IXOFF controls sending of XON/XOFF characters, not the reception of
these sequences.
- IXON controls the recognition of XON/XOFF characters, not the transmission
of the same.
- Wrong bitmasks for hardware assisted software flow control. Bit 2
in EFR enables sending of XON2/XOFF2 which are never set.
- No point comparing received characters against XOFF2 ('special character
detect') as XOFF2 is not set.
- Fix multiple places where bits 6 and 5 of MCR are attempted to be
altered, but because EFR ECB is unset, these bits remain unaffected.
This effectively prevents us accessing the right XON/XOFF/TCR/TLR
registers.
- Remove unnecessary read-backs of EFR/MCR/LCR registers - these registers
don't change beneath us, they are configuration registers which hold their
values. Not only does this simplify the code, but it makes it more
readable, and more importantly ensures that we work from a consistent
state where -efr never has ECB set, and -mcr never has the TCRTLR
bit set.
- Fix disablement of hardware flow control and IXANY modes; once enabled
these could never be disabled because nothing in the code ever clears
these configuration bits.
Once that lot is fixed, these patches expand serial_core to permit hardware
assisted flow control by:
- adding throttle/unthrottle callbacks into low level serial drivers,
which allow them to take whatever action is necessary with hardware
assisted flow control to throttle the remote end. In the case of
OMAP serial, this means disabling the RX interrupts so that the FIFO
fills to the watermark.
We then have a number of cleanups to the OMAP serial code to make the
set_termios() function clearer and less prone to the kinds of mistakes
identified above. This results in a great simplification of the flow
control configuration code.
The OMAP serial driver hacks around with the transmit buffer allocation;
lets clean that up so that drivers can cleanly allocate their transmitter
buffer using coherent memory if that's what they desire.
Finally, the last few patches clean up the plat/omap-serial.h header file,
moving most of its contents into the OMAP serial driver itself. Most of
this is private to the OMAP serial driver and should never have been
shared with anything else.
I have omitted to include the conversion of the transmit paths to DMA
engine. Even with all the above fixed, it has issues when DMA transmit
is in progress, and a program issues a TCSETS call (as `less' does after
it has written its prompt.) At the moment, this causes lots of junk to
be emitted from the serial port when issuing `dmesg | less' which sometimes
brings the port to a complete halt.
As the OMAP DMA hardware does not have a clean pause when performing a
MEM-DEV transfer (it discards its FIFO) I do not see a solution to this,
which probably means that we can _not_ ever support transmit DMA on OMAP
platforms.
This means the xmit buffer allocation patches are not that useful unless
a solution to that can be found.
Now, the remaining question is, how much of this patch set do we think
about merging, and when. Given that flow control in this driver has been
broken for a very long time, and no one has apparantly noticed, I don't
think there's any urgency to this, so given its size, my preference would
be to queue it up for the next merge window. The thing that would worry
me about applying some of the initial patches is that they may change
the behaviour today and make any problems here more visible.
I'll add another point to this: serial_omap_restore_context() makes no
attempt to restore neither the protected bits in the MCR register nor
the contents of the TCR and TLR registers. So, hardware assisted flow
control probably won't work at all well after a context loss event.
When I work out how to test this, I'll see about cooking up yet another
fix to this driver.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
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 = ~OMAP_UART_FCR_RX_FIFO_TRIG_MASK;
up-fcr |= (0x1 OMAP_UART_FCR_RX_FIFO_TRIG_SHIFT);
}
Is that:
up-scr |= UART_FCR_TRIGGER_4;
line really correct? It looks wrong to be using a FCR register mask with
something that ends up in the OMAP SCR register...
I'm beginning to wonder how many of the workarounds which have been
applied to this driver, particularly those to do with FIFO triggers and
idle stuff are actually down to the horribly broken and buggy set_termios
code. I'm coming to the conclusion that all those workarounds should be
removed, and we start again from a clean slate with a properly written
driver which observes the register access rules - thereby ensuring that
the correct values get written to the registers that we expect them to.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
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_out(up, UART_DLL, 0);
serial_out(up, UART_DLM, 0);
serial_out(up, UART_LCR, 0);
...
serial_out(up, UART_FCR, up-fcr);
...
}
serial_omap_restore_context()
{
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B); /* Config B mode */
serial_out(up, UART_DLL, up-dll);
serial_out(up, UART_DLM, up-dlh);
serial_out(up, UART_LCR, 0x0); /* Operational mode */
serial_out(up, UART_IER, up-ier);
serial_out(up, UART_FCR, up-fcr);
}
Either the comment is wrong, or the code in serial_omap_restore_context()
is wrong; they can't both be right. Please can someone let me know which
is the right version so we can fix that inconsistency.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
On Sat, 6 Oct 2012 13:38:03 +0100 Russell King - ARM Linux li...@arm.linux.org.uk 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 otherwise we have no way to properly pause the transmitter. All the generic parts Acked-by: Alan Cox a...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
