* 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
>
Se
* 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 p
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 [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
> >> also
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 bu
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 di
* 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 i
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
* 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 U
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 cha
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
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 [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 When
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 wonde
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 D
* 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?
Yea
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 *to
* 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 have
* 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
>> cor
* 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 shou
* 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 t
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
* 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 RX
26 matches
Mail list logo
