* Sebastian Andrzej Siewior [140904 07:56]:
> On 09/04/2014 04:52 PM, Tony Lindgren wrote:
> > Yeah makes sense to me. Thanks for ensuring the bug
> > compability :)
>
> Thanks. What about the ttyOx vs ttySx. Do you want me to add kernel
> line fixup somewhere arch/arm or we ignore this for now?
On 09/04/2014 04:52 PM, Tony Lindgren wrote:
> Yeah makes sense to me. Thanks for ensuring the bug
> compability :)
Thanks. What about the ttyOx vs ttySx. Do you want me to add kernel
line fixup somewhere arch/arm or we ignore this for now? Greg didn't
say anything…
>
> Regards,
>
> Tony
>
* Sebastian Andrzej Siewior [140904 06:46]:
> On 09/03/2014 07:48 PM, Tony Lindgren wrote:
>
> I will check this upper part of this email soon…
>
> > OK. At least it's starting to now sound that the bugs are pretty much
> > the same with 8250 and serial-omap :)
>
> Do you see a reason for not
On 09/03/2014 07:48 PM, Tony Lindgren wrote:
I will check this upper part of this email soon…
> OK. At least it's starting to now sound that the bugs are pretty much
> the same with 8250 and serial-omap :)
Do you see a reason for not posting the entire series again since now I
am bug compatible
On 09/03/2014 07:48 PM, Tony Lindgren wrote:
I will check this upper part of this email soon…
OK. At least it's starting to now sound that the bugs are pretty much
the same with 8250 and serial-omap :)
Do you see a reason for not posting the entire series again since now I
am bug compatible
* Sebastian Andrzej Siewior bige...@linutronix.de [140904 06:46]:
On 09/03/2014 07:48 PM, Tony Lindgren wrote:
I will check this upper part of this email soon…
OK. At least it's starting to now sound that the bugs are pretty much
the same with 8250 and serial-omap :)
Do you see a
On 09/04/2014 04:52 PM, Tony Lindgren wrote:
Yeah makes sense to me. Thanks for ensuring the bug
compability :)
Thanks. What about the ttyOx vs ttySx. Do you want me to add kernel
line fixup somewhere arch/arm or we ignore this for now? Greg didn't
say anything…
Regards,
Tony
* Sebastian Andrzej Siewior bige...@linutronix.de [140904 07:56]:
On 09/04/2014 04:52 PM, Tony Lindgren wrote:
Yeah makes sense to me. Thanks for ensuring the bug
compability :)
Thanks. What about the ttyOx vs ttySx. Do you want me to add kernel
line fixup somewhere arch/arm or we ignore
* Sebastian Andrzej Siewior [140903 09:46]:
> On 09/02/2014 10:15 PM, Tony Lindgren wrote:
> >> - I see to face two kind of "deaths":
> >> - the LED still goes on and off and the uart just does not respond
> >> even if I tell the button print something on the screen (the button
> >>
On 09/02/2014 10:15 PM, Tony Lindgren wrote:
>> - I see to face two kind of "deaths":
>> - the LED still goes on and off and the uart just does not respond
>> even if I tell the button print something on the screen (the button
>> also changes the frequency of the LED so I know that the
On 09/02/2014 10:15 PM, Tony Lindgren wrote:
- I see to face two kind of deaths:
- the LED still goes on and off and the uart just does not respond
even if I tell the button print something on the screen (the button
also changes the frequency of the LED so I know that the button is
* Sebastian Andrzej Siewior bige...@linutronix.de [140903 09:46]:
On 09/02/2014 10:15 PM, Tony Lindgren wrote:
- I see to face two kind of deaths:
- the LED still goes on and off and the uart just does not respond
even if I tell the button print something on the screen (the button
On Tue, Sep 02, 2014 at 01:15:37PM -0700, Tony Lindgren wrote:
> * Sebastian Andrzej Siewior [140902 11:40]:
> > On 09/01/2014 07:47 PM, Sebastian Andrzej Siewior wrote:
> > > Comparing it with serial-omap I see the same thing: I takes approx the
> > > same amount of data until the first one is
* Sebastian Andrzej Siewior [140902 11:40]:
> On 09/01/2014 07:47 PM, Sebastian Andrzej Siewior wrote:
> > Comparing it with serial-omap I see the same thing: I takes approx the
> > same amount of data until the first one is displayed. After a lot of
> > "long" writes which wake the chip up from
On 09/01/2014 07:47 PM, Sebastian Andrzej Siewior wrote:
> Comparing it with serial-omap I see the same thing: I takes approx the
> same amount of data until the first one is displayed. After a lot of
> "long" writes which wake the chip up from idle I manage to freeze both,
> the serial-omap
* Sebastian Reichel [140901 20:06]:
> Hi,
>
> On Mon, Sep 01, 2014 at 07:47:53PM +0200, Sebastian Andrzej Siewior wrote:
> > On 08/29/2014 06:12 PM, Tony Lindgren wrote:
> > > Looks like the paste bug is there for sure, doing off idle and pasting
> > > 240 characters to the console can hang the
* Sebastian Reichel s...@kernel.org [140901 20:06]:
Hi,
On Mon, Sep 01, 2014 at 07:47:53PM +0200, Sebastian Andrzej Siewior wrote:
On 08/29/2014 06:12 PM, Tony Lindgren wrote:
Looks like the paste bug is there for sure, doing off idle and pasting
240 characters to the console can hang
On 09/01/2014 07:47 PM, Sebastian Andrzej Siewior wrote:
Comparing it with serial-omap I see the same thing: I takes approx the
same amount of data until the first one is displayed. After a lot of
long writes which wake the chip up from idle I manage to freeze both,
the serial-omap driver and
* Sebastian Andrzej Siewior bige...@linutronix.de [140902 11:40]:
On 09/01/2014 07:47 PM, Sebastian Andrzej Siewior wrote:
Comparing it with serial-omap I see the same thing: I takes approx the
same amount of data until the first one is displayed. After a lot of
long writes which wake the
On Tue, Sep 02, 2014 at 01:15:37PM -0700, Tony Lindgren wrote:
* Sebastian Andrzej Siewior bige...@linutronix.de [140902 11:40]:
On 09/01/2014 07:47 PM, Sebastian Andrzej Siewior wrote:
Comparing it with serial-omap I see the same thing: I takes approx the
same amount of data until the
Hi,
On Mon, Sep 01, 2014 at 07:47:53PM +0200, Sebastian Andrzej Siewior wrote:
> On 08/29/2014 06:12 PM, Tony Lindgren wrote:
> > Looks like the paste bug is there for sure, doing off idle and pasting
> > 240 characters to the console can hang the UART RX after few attempts,
> > and pasting 16
On 08/29/2014 06:12 PM, Tony Lindgren wrote:
> Looks like the paste bug is there for sure, doing off idle and pasting
> 240 characters to the console can hang the UART RX after few attempts,
> and pasting 16 charactes won't show up at all if the system is idling.
> So you may want to play with
On 08/29/2014 06:12 PM, Tony Lindgren wrote:
Looks like the paste bug is there for sure, doing off idle and pasting
240 characters to the console can hang the UART RX after few attempts,
and pasting 16 charactes won't show up at all if the system is idling.
So you may want to play with that
Hi,
On Mon, Sep 01, 2014 at 07:47:53PM +0200, Sebastian Andrzej Siewior wrote:
On 08/29/2014 06:12 PM, Tony Lindgren wrote:
Looks like the paste bug is there for sure, doing off idle and pasting
240 characters to the console can hang the UART RX after few attempts,
and pasting 16 charactes
On 08/29/2014 06:12 PM, Tony Lindgren wrote:
> Looks like the paste bug is there for sure, doing off idle and pasting
> 240 characters to the console can hang the UART RX after few attempts,
> and pasting 16 charactes won't show up at all if the system is idling.
> So you may want to play with
* Sebastian Andrzej Siewior [140829 02:32]:
> On 08/29/2014 12:54 AM, Tony Lindgren wrote:
> > OK thanks, I'm seeing the same issue as you. And the idlest registers
> > don't show any blockers. Looking at the errata docs, seems like
> > "Usage Note 2.7" in sprz318f.pdf says:
> >
> > Details
On Fri, Aug 29, 2014 at 11:32:36AM +0200, Sebastian Andrzej Siewior wrote:
> On 08/29/2014 12:54 AM, Tony Lindgren wrote:
> > * Sebastian Andrzej Siewior [140828 12:37]:
> >> On 08/28/2014 06:46 PM, Tony Lindgren wrote:
> >>>
> >>> Sounds like there should be some way to clear that state.. I
On 08/29/2014 12:54 AM, Tony Lindgren wrote:
> * Sebastian Andrzej Siewior [140828 12:37]:
>> On 08/28/2014 06:46 PM, Tony Lindgren wrote:
>>>
>>> Sounds like there should be some way to clear that state.. I wonder
>>> if omap-serial.c had something before it's DMA support was removed?
>>
>> Its
On 08/29/2014 12:54 AM, Tony Lindgren wrote:
* Sebastian Andrzej Siewior bige...@linutronix.de [140828 12:37]:
On 08/28/2014 06:46 PM, Tony Lindgren wrote:
Sounds like there should be some way to clear that state.. I wonder
if omap-serial.c had something before it's DMA support was removed?
On Fri, Aug 29, 2014 at 11:32:36AM +0200, Sebastian Andrzej Siewior wrote:
On 08/29/2014 12:54 AM, Tony Lindgren wrote:
* Sebastian Andrzej Siewior bige...@linutronix.de [140828 12:37]:
On 08/28/2014 06:46 PM, Tony Lindgren wrote:
Sounds like there should be some way to clear that state..
* Sebastian Andrzej Siewior bige...@linutronix.de [140829 02:32]:
On 08/29/2014 12:54 AM, Tony Lindgren wrote:
OK thanks, I'm seeing the same issue as you. And the idlest registers
don't show any blockers. Looking at the errata docs, seems like
Usage Note 2.7 in sprz318f.pdf says:
On 08/29/2014 06:12 PM, Tony Lindgren wrote:
Looks like the paste bug is there for sure, doing off idle and pasting
240 characters to the console can hang the UART RX after few attempts,
and pasting 16 charactes won't show up at all if the system is idling.
So you may want to play with that
* Sebastian Andrzej Siewior [140828 12:37]:
> On 08/28/2014 06:46 PM, Tony Lindgren wrote:
> >
> > Sounds like there should be some way to clear that state.. I wonder
> > if omap-serial.c had something before it's DMA support was removed?
>
> Its DMA was removed? Like there was DMA support?
On 08/28/2014 06:46 PM, Tony Lindgren wrote:
>> To use DMA you don't have to enable it in SCR register you can also use
>> the FCR register. The manual says that you can only write this DMA
>> enable bit in the FCR register if the baud clock is not running. And
>> guess what: same thing: I only
* Sebastian Andrzej Siewior [140828 01:24]:
> * Tony Lindgren | 2014-08-27 13:23:14 [-0700]:
> >
> >Do you mean just the OMAP_UART_SCR_DMAMODE_CTL related code, or
> >also the dmaengine calls?
>
> dmaengine calls are unused because up.dma is not assigned. It is
> basically like you wouldn't
* Tony Lindgren | 2014-08-27 13:23:14 [-0700]:
>> which means I just enable DMA mode in UART and disable it. No DMA
>> operations were performed.
>> With this change I see a lost character now and then which means the
>> UART-IP goes into off and loses its context. Good. However I don't see
>>
* Tony Lindgren | 2014-08-27 13:23:14 [-0700]:
which means I just enable DMA mode in UART and disable it. No DMA
operations were performed.
With this change I see a lost character now and then which means the
UART-IP goes into off and loses its context. Good. However I don't see
core off
* Sebastian Andrzej Siewior bige...@linutronix.de [140828 01:24]:
* Tony Lindgren | 2014-08-27 13:23:14 [-0700]:
Do you mean just the OMAP_UART_SCR_DMAMODE_CTL related code, or
also the dmaengine calls?
dmaengine calls are unused because up.dma is not assigned. It is
basically like you
On 08/28/2014 06:46 PM, Tony Lindgren wrote:
To use DMA you don't have to enable it in SCR register you can also use
the FCR register. The manual says that you can only write this DMA
enable bit in the FCR register if the baud clock is not running. And
guess what: same thing: I only *toggle*
* Sebastian Andrzej Siewior bige...@linutronix.de [140828 12:37]:
On 08/28/2014 06:46 PM, Tony Lindgren wrote:
Sounds like there should be some way to clear that state.. I wonder
if omap-serial.c had something before it's DMA support was removed?
Its DMA was removed? Like there was DMA
* Sebastian Andrzej Siewior [140827 12:54]:
> On 08/21/2014 08:44 PM, Tony Lindgren wrote:
> >>> Also, with DMA enabled, looks like omap deeper idle states are
> >>> blocked as the DMA stays reserved. After I commented out the
> >>> DMA info for my console UART, PM started working.
> >>
> >> Hmm.
On 08/21/2014 08:44 PM, Tony Lindgren wrote:
>>> Also, with DMA enabled, looks like omap deeper idle states are
>>> blocked as the DMA stays reserved. After I commented out the
>>> DMA info for my console UART, PM started working.
>>
>> Hmm. This would explain something. This would mean that I
On 08/21/2014 08:44 PM, Tony Lindgren wrote:
Also, with DMA enabled, looks like omap deeper idle states are
blocked as the DMA stays reserved. After I commented out the
DMA info for my console UART, PM started working.
Hmm. This would explain something. This would mean that I should cancel
* Sebastian Andrzej Siewior bige...@linutronix.de [140827 12:54]:
On 08/21/2014 08:44 PM, Tony Lindgren wrote:
Also, with DMA enabled, looks like omap deeper idle states are
blocked as the DMA stays reserved. After I commented out the
DMA info for my console UART, PM started working.
* Sebastian Andrzej Siewior [140821 01:37]:
> On 08/15/2014 11:02 PM, Tony Lindgren wrote:
> > * Sebastian Andrzej Siewior [140815 11:13]:
> >> +#ifdef CONFIG_SERIAL_8250_DMA
> >> + if (pdev->dev.of_node) {
> >> + /*
> >> + * Oh DMA support. If there are no DMA properties in
On 08/15/2014 11:02 PM, Tony Lindgren wrote:
> * Sebastian Andrzej Siewior [140815 11:13]:
>> +#ifdef CONFIG_SERIAL_8250_DMA
>> +if (pdev->dev.of_node) {
>> +/*
>> + * Oh DMA support. If there are no DMA properties in the DT then
>> + * we will fall back to
On 08/15/2014 11:02 PM, Tony Lindgren wrote:
* Sebastian Andrzej Siewior bige...@linutronix.de [140815 11:13]:
+#ifdef CONFIG_SERIAL_8250_DMA
+if (pdev-dev.of_node) {
+/*
+ * Oh DMA support. If there are no DMA properties in the DT then
+ * we will
* Sebastian Andrzej Siewior bige...@linutronix.de [140821 01:37]:
On 08/15/2014 11:02 PM, Tony Lindgren wrote:
* Sebastian Andrzej Siewior bige...@linutronix.de [140815 11:13]:
+#ifdef CONFIG_SERIAL_8250_DMA
+ if (pdev-dev.of_node) {
+ /*
+ * Oh DMA support. If there
* Sebastian Andrzej Siewior [140815 11:13]:
> +#ifdef CONFIG_SERIAL_8250_DMA
> + if (pdev->dev.of_node) {
> + /*
> + * Oh DMA support. If there are no DMA properties in the DT then
> + * we will fall back to a generic DMA channel which does not
> +
This patch adds the required pieces to 8250-OMAP UART driver for DMA
support. The TX burst size is set to 1 so we can send an arbitrary
amount of bytes.
The RX burst is currently set to 48 which means we receive an DMA
interrupt every 48 bytes and have to reprogram everything. Less bytes in
the
This patch adds the required pieces to 8250-OMAP UART driver for DMA
support. The TX burst size is set to 1 so we can send an arbitrary
amount of bytes.
The RX burst is currently set to 48 which means we receive an DMA
interrupt every 48 bytes and have to reprogram everything. Less bytes in
the
* Sebastian Andrzej Siewior bige...@linutronix.de [140815 11:13]:
+#ifdef CONFIG_SERIAL_8250_DMA
+ if (pdev-dev.of_node) {
+ /*
+ * Oh DMA support. If there are no DMA properties in the DT then
+ * we will fall back to a generic DMA channel which does
52 matches
Mail list logo