On Thu, Apr 4, 2013 at 12:06 AM, Alexey Pelykh wrote:
>
> Is it possible to check behavior on 3.0-3.2 kernels?
We use 3.2 on pandora as production kernel and it doesn't have this
issue that 3.9 had. 3.2 serial PM code is vastly different from what's
in later ones though.
>
> On Wed, Apr 3, 2013
Hi Paul,
Is it possible to check behavior on 3.0-3.2 kernels?
On Wed, Apr 3, 2013 at 11:57 PM, Paul Walmsley wrote:
> Hi Alexey,
>
> On Wed, 3 Apr 2013, Alexey Pelykh wrote:
>
>> But, since we've found the issue, I suggest that we should look at it
>> closer, especially since at this moment only
Hi Alexey,
On Wed, 3 Apr 2013, Alexey Pelykh wrote:
> But, since we've found the issue, I suggest that we should look at it
> closer, especially since at this moment only you can reproduce it.
Well probably no one else is testing it :-)
> As far as I understand, but I may be wrong, this comment
Hi,
On Wed, Apr 3, 2013 at 12:19 AM, Alexey Pelykh wrote:
>
> But, since we've found the issue, I suggest that we should look at it
> closer, especially since at this moment only you can reproduce it. As
FWIW I was also affected by it, maybe because my console is on UART3
and that is on differen
Hi
On Wed, Apr 3, 2013 at 11:21 PM, Paul Walmsley wrote:
> Hi,
>
> On Wed, 3 Apr 2013, Alexey Pelykh wrote:
>
>> But, since we've found the issue, I suggest that we should look at it
>> closer, especially since at this moment only you can reproduce it. As
>> far as I understand, but I may be wron
Hi,
On Wed, 3 Apr 2013, Alexey Pelykh wrote:
> But, since we've found the issue, I suggest that we should look at it
> closer, especially since at this moment only you can reproduce it. As
> far as I understand, but I may be wrong,
> this comment is wrong, since if to specify
> OMAP_UART_SCR_RX_T
On Wed, 3 Apr 2013, Alexey Pelykh wrote:
> I've submitted patch that should remove this regression
Thanks, indeed it does. So the revert patch that I sent at the beginning
of this thread is now mooted.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body
I've submitted patch that should remove this regression
On Wed, Apr 3, 2013 at 6:55 PM, Alexey Pelykh wrote:
> Paul,
>
> Should I start a new email chain with that patch or add it here?
>
> On Wed, Apr 3, 2013 at 12:19 AM, Alexey Pelykh
> wrote:
>> Hi Paul,
>>
>> No problem, I'll prepare patch
Paul,
Should I start a new email chain with that patch or add it here?
On Wed, Apr 3, 2013 at 12:19 AM, Alexey Pelykh wrote:
> Hi Paul,
>
> No problem, I'll prepare patch in next 24 hours and will send in ASAP.
>
> But, since we've found the issue, I suggest that we should look at it
> closer, e
Hi Paul,
No problem, I'll prepare patch in next 24 hours and will send in ASAP.
But, since we've found the issue, I suggest that we should look at it
closer, especially since at this moment only you can reproduce it. As
far as I understand, but I may be wrong,
this comment is wrong, since if to s
On Mon, 1 Apr 2013, Alexey Pelykh wrote:
> Paul, can you please try to comment out change related to Rx line
> (granulation one). That's only Rx line related change in the patch.
Yes, looks like simply reverting the commit 1776fd059c40 ("OMAP/serial:
Fix incorrect Rx FIFO threshold setting, LSR
Paul, can you please try to comment out change related to Rx line
(granulation one). That's only Rx line related change in the patch.
On Mon, Apr 1, 2013 at 8:09 PM, Paul Walmsley wrote:
> On Mon, 1 Apr 2013, Alexey Pelykh wrote:
>
>> Please, correct me if I'm wrong, you're experiencing issues on
On Mon, 1 Apr 2013, Alexey Pelykh wrote:
> Please, correct me if I'm wrong, you're experiencing issues on Tx, or
> Rx direction? You've said that characters are echoed incorrectly, but
> haven't mentioned in what direction issue appears?
The problem seems to be on the Rx path. If I 'cat' a file,
Paul,
Please, correct me if I'm wrong, you're experiencing issues on Tx, or
Rx direction? You've said that characters are echoed incorrectly, but
haven't mentioned in what direction issue appears?
For reference, I'll quote TI DM3730 Rev.R TRM:
TRM page 2953, LSR_REG
Bit #5: TX_FIFO_E
0x0 Transmit
On Mon, Apr 1, 2013 at 1:19 PM, Paul Walmsley wrote:
> cc Kevin, Felipe
>
> Hi
>
> On Mon, 1 Apr 2013, Alexey Pelykh wrote:
>
>> On Mon, Apr 1, 2013 at 12:13 PM, Paul Walmsley wrote:
>> > On Mon, 1 Apr 2013, Alexey Pelykh wrote:
>> >
>> >> Actually, I've tested my patch on DM3730,
>> >
>> > What
cc Kevin, Felipe
Hi
On Mon, 1 Apr 2013, Alexey Pelykh wrote:
> On Mon, Apr 1, 2013 at 12:13 PM, Paul Walmsley wrote:
> > On Mon, 1 Apr 2013, Alexey Pelykh wrote:
> >
> >> Actually, I've tested my patch on DM3730,
> >
> > What board, bootloader, and test steps did you use? Can you post a dmesg?
Hi,
On Mon, Apr 1, 2013 at 12:13 PM, Paul Walmsley wrote:
> Hi
>
> On Mon, 1 Apr 2013, Alexey Pelykh wrote:
>
>> Actually, I've tested my patch on DM3730,
>
> What board, bootloader, and test steps did you use? Can you post a dmesg?
I've used LogicPD Torpedo Wireless SoM + DevKit board. Bootloa
Hi
On Mon, 1 Apr 2013, Alexey Pelykh wrote:
> Actually, I've tested my patch on DM3730,
What board, bootloader, and test steps did you use? Can you post a dmesg?
> and, at least, can prove that original settings of UART are incorrect
> according to TRM of processor.
The TRM could be buggy o
Actually, I've tested my patch on DM3730, and, at least, can prove
that original settings of UART are incorrect according to TRM of
processor. What settings of UART you were using to reproduce issue?
I'd like to kindly ask you to describe your test environment, since
I've never experiences issues t
This reverts commit 1776fd059c40907297d6c26c51876575d63fd9e2.
Commit 1776fd059c40 causes UART sluggishness on the OMAP37xx EVM.
This can be demonstrated by pasting in a ten-character string, like
"ff", at the serial console. The string will be echoed back
two to three characters at a tim
20 matches
Mail list logo
