* Grygorii Strashko | 2015-12-12 10:30:10 [+0200]:
>git://git.ti.com/~gragst/ti-linux-kernel/gragsts-ti-linux-kernel.git
sucked in, thanks.
Sebastian
--
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
* Grygorii Strashko | 2015-10-15 19:33:43 [+0300]:
>Hi Thomas,
>
>On 10/13/2015 09:33 PM, Thomas Gleixner wrote:
>>Grygorii,
>>
>>On Tue, 13 Oct 2015, Grygorii Strashko wrote:
>>>I'd very appreciate for any advice of how to better proceed with your
>>>request.
>>> - I can try to apply and re-sen
* Bjorn Helgaas | 2015-12-04 12:46:19 [-0600]:
>The backtrace might be OK (maybe slightly overkill), but all the
>stack addresses are certainly irrelevant and distracting. We only
>need enough to recognize the problem. I don't think the modules list
>is relevant either.
I would shorten it to th
On 11/06/2015 08:59 PM, Grygorii Strashko wrote:
> Hi Sebastian,
Hi Grygorii,
> - IRQF_NO_THREAD is the first considered option for such kind of issues.
> But: Now in LKML there are ~60 occurrences of IRQF_NO_THREAD - most of
> them are used by Arch code. And It's only used by 6 drivers (driv
On 11/05/2015 07:43 PM, Grygorii Strashko wrote:
> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> index 6589e7e..31460f4 100644
> --- a/drivers/pci/host/pci-dra7xx.c
> +++ b/drivers/pci/host/pci-dra7xx.c
> @@ -302,8 +302,30 @@ static int __init dra7xx_add_pcie_port(str
One downside with this approach is that latency sensitive protocols that
transfer less than 48 bytes will have to wait 250ms to complete.
Is there maybe a user interface where one could set small or bulk transfers?
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250_omap.c |
: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index c43f74c53cd9..a407757dcecc 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial
counter so userpace
has a clue that we lost bytes.
Cc: Greg Kroah-Hartman
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250_omap.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250
RX-DMA completly on probe.
The rx_dma_broken assignment on probe could be removed once we working
pause function in omap-dma.
Cc:
Signed-off-by: Sebastian Andrzej Siewior
---
v1…v2:
- disable RX-DMA right on boot
drivers/tty/serial/8250/8250_omap.c | 14 +-
1 file changed, 13
On 08/11/2015 12:06 PM, Russell King - ARM Linux wrote:
> I think what people need to learn is that an API in the kernel which
> returns an int _can_ fail - it returns an int so it _can_ return an
> error code. If it _can_ return an error code, there _will_ be
> implementations which _do_.
>
> If
On 08/10/2015 01:54 PM, Peter Ujfalusi wrote:
>> diff --git a/drivers/tty/serial/8250/8250_omap.c
>> b/drivers/tty/serial/8250/8250_omap.c
>> index 0340ee6ba970..07a11e0935e4 100644
>> --- a/drivers/tty/serial/8250/8250_omap.c
>> @@ -769,7 +771,9 @@ static void omap_8250_rx_dma_flush(struct uart_8
On 08/08/2015 02:28 AM, Peter Hurley wrote:
>> diff --git a/drivers/tty/serial/8250/8250_omap.c
>> b/drivers/tty/serial/8250/8250_omap.c
>> index 0340ee6ba970..07a11e0935e4 100644
>> --- a/drivers/tty/serial/8250/8250_omap.c
>> +++ b/drivers/tty/serial/8250/8250_omap.c
>> @@ -769,7 +771,9 @@ stati
: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250_omap.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 0340ee6ba970..07a11e0935e4 100644
--- a/drivers/tty/serial/8250/8250_omap.c
#1 is something that can go stable and disables RX-DMA should it
notice that it does not work.
#2 adds the anotation as suggest by Russell.
#3 adds the missing feature to omap-dma so dmaengine_pause() works. Once
this is merged, the warning from #1 disappears.
--
To unsubscribe from this lis
-off-by: Sebastian Andrzej Siewior
---
include/linux/dmaengine.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 8ad9a4e839f6..4eac4716bded 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -825,7
MA_MEM_TO_DEV not allowed.
- clear pause on terminate_all. Otherwise pause() + terminate_all()
will keep the pause bit set and we can't pause the following
transfer.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/dma/omap-dma.c | 122 +++
* Russell King - ARM Linux | 2015-08-07 17:26:48 [+0100]:
>On Fri, Aug 07, 2015 at 05:36:05PM +0200, Sebastian Andrzej Siewior wrote:
>> +/*
>> + * We do not allow DMA_MEM_TO_DEV transfers to be paused.
>> + * According to RMK the OMAP ha
On 08/07/2015 06:07 PM, Peter Hurley wrote:
>> If we look at what 8250-dma.c is doing:
>>
>> if (dma->rx_running) {
>> dmaengine_pause(dma->rxchan);
>>
>> It's 8250-dma.c which is silently _ignoring_ the return code, failing
>> to check that the operation it
On 08/07/2015 05:29 PM, Russell King - ARM Linux wrote:
> On Fri, Aug 07, 2015 at 11:08:48AM -0400, Peter Hurley wrote:
>> [ + Greg KH ]
>>
>> On 08/07/2015 09:57 AM, Russell King - ARM Linux wrote:
>>> As it is something that the driver has _not_ supported, you are clearly
>>> adding a feature to
erwise pause() + terminate_all()
will keep the pause bit set and we can't pause the following
transfer.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/dma/omap-dma.c | 107 +
1 file changed, 73 insertions(+), 34 deletions(-)
diff --git a/drivers
On 08/07/2015 03:22 PM, Russell King - ARM Linux wrote:
> On Fri, Aug 07, 2015 at 12:36:14PM +0200, Sebastian Andrzej Siewior wrote:
>> On 08/07/2015 11:44 AM, Peter Ujfalusi wrote:
>>> with a short testing audio did not broke (the only user of pause/resume)
>>> Some com
On 08/07/2015 03:17 PM, Russell King - ARM Linux wrote:
> On Fri, Aug 07, 2015 at 02:35:45PM +0200, Sebastian Andrzej Siewior wrote:
>> On 08/07/2015 12:55 PM, Russell King - ARM Linux wrote:
>>> On Fri, Aug 07, 2015 at 10:41:57AM +0200, Sebastian Andrzej Siewior wrote:
>&
correctly I
tested this on am335x-evm and dra7-evm by I the time I posted the
patches. I agree that dra7 support was not the best back then but I am
almost sure that I had vanilla running for testing.
But I don't insist on the stable tag. Consider it
On 08/07/2015 12:55 PM, Russell King - ARM Linux wrote:
> On Fri, Aug 07, 2015 at 10:41:57AM +0200, Sebastian Andrzej Siewior wrote:
>> This DMA driver is used by 8250-omap on DRA7-evm. There is one
>> requirement that is to pause a transfer. This is currently used on the RX
On 08/07/2015 11:44 AM, Peter Ujfalusi wrote:
> On 08/07/2015 11:41 AM, Sebastian Andrzej Siewior wrote:
>> This DMA driver is used by 8250-omap on DRA7-evm. There is one
>> requirement that is to pause a transfer. This is currently used on the RX
>> side. It is possible tha
r because it does only pause +
terminate.
Cc:
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/dma/omap-dma.c | 54 ++
1 file changed, 41 insertions(+), 13 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index
On 08/06/2015 02:31 PM, Sebastian Andrzej Siewior wrote:
Hi Peter,
>> I'll look at/test this this weekend, ok?
>
> Sure. I'm currently re-spinning the patches so have everything in
> proper pieces. While at it I will take a look at x_char.
So now that I actually l
On 08/06/2015 02:27 PM, Peter Hurley wrote:
> Hi Sebastian,
Hi Peter,
> On 08/04/2015 07:58 AM, Sebastian Andrzej Siewior wrote:
>> On 08/03/2015 09:32 PM, Peter Hurley wrote:
>>
>>>> You mean a function in 8250-dma API which does what I did just here
>>>
On 08/03/2015 09:32 PM, Peter Hurley wrote:
>> You mean a function in 8250-dma API which does what I did just here
>> with the wait_event() and the wake_up in the callback? That way I could
>> move the termios_wait into the dma struct instead of keeping in the
>> omap specific part. I am also not
On 08/03/2015 06:34 PM, Peter Hurley wrote:
> Hi Sebastian,
Hi Peter,
>> struct old_serial_port {
>> diff --git a/drivers/tty/serial/8250/8250_omap.c
>> b/drivers/tty/serial/8250/8250_omap.c
>> index d9a37191a1ae..12249125a218 100644
>> --- a/drivers/tty/serial/8250/8250_omap.c
>> +++ b/drivers
* Peter Hurley | 2015-07-30 20:51:10 [-0400]:
>Hi John,
Hi Peter,
>I was never really a fan of the deferred set_termios();
>I think it's more appropriate to wait for tx dma to
>complete in omap_8250_set_termios().
So you want something like this? This was only compile + boot tested
(without trig
On 07/27/2015 02:50 PM, Linus Walleij wrote:
> Patch applied.
thanks.
>
> Now this question appear in my head:
>
> Is drivers/gpio full of stuff that will not work with the -RT kernel,
> and is this a change that should be done mutatis mutandis on
> all the GPIO drivers?
I described two call pa
sers of gpiod_set_debounce() / gpio_set_debounce()
looks low but still this is not good.
Acked-by: Javier Martinez Canillas
Acked-by: Santosh Shilimkar
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpio/gpio-omap.c | 82
1 file changed, 41 insertions
On 07/09/2015 11:46 PM, Pavel Machek wrote:
> On Thu 2015-07-09 23:39:22, Pavel Machek wrote:
>> Hi!
Hi,
>>
>> sysfs should contain one value per file. This one has at least two,
>> with nice english sentence as a bonus.
>>
>> root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-
On 06/30/2015 08:45 AM, Linus Walleij wrote:
> This doesn't apply to the current development tree.
it has been pointed out to me.
> Can you rebase this patch in Torvalds' HEAD, add Javier's ACK
> and resend?
I will do it once I'm done roasted :)
> Please put me on the To: line, I have no time t
On 06/30/2015 12:55 PM, Grygorii Strashko wrote:
> Hi Sebastian, All,
Hi Grygorii,
> The problem here is that OMAPs code implemented using PM runtime based
> approach and PM runtime is used everywhere. We don't see warnings form
> other drivers just because their HW IRQ handlers forced to be threa
sers of gpiod_set_debounce() / gpio_set_debounce()
looks low but still this is not good.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpio/gpio-omap.c | 78 +++
1 file changed, 39 insertions(+), 39 deletions(-)
--- a/drivers/gpio/gpio-omap.c
+++ b/drive
pler like using just request_irq() instead the
chain handler like it is doing now.
So lets try that.
Fixes: ca8bb4aefb93 ("serial: 8250: Revert "tty: serial: 8250_core:
read only RX if there is something in the FIFO"")
Tested-by: Tony Lindgren
Signed-off-by: Sebast
On 04/12/2015 02:23 AM, Nishanth Menon wrote:
>> I think for the moment we should just freeze omap-serial and let
>> most of userspace catch up first; a lot of the official and
>> unofficial vender support is still stuck in 3.14. By the time,
>> 3.19+ is de rigueur we'll hopefully have figured out
Hi Shawn,
On Fri, Mar 13, 2015 at 11:29:32AM +0800, Shawn Guo wrote:
> We did not add a DT property for it, because there was already enough
> info (clock configuration) in DT for kernel to figure it out.
Correct. My understanding is whatever can be figured out without DT should
be done that way.
On 2015-02-17 14:01:04 [-0800], Stephen Boyd wrote:
> diff =
> --- arch/arm/mach-imx/mach-imx6q.c
> +++ /tmp/cocci-output-11792-b62223-mach-imx6q.c
> @@ -211,7 +211,6 @@ static void __init imx6q_1588_init(void)
>* set bit IOMUXC_GPR1[21]. Or the PTP clock must be from pad
>* (exte
On 02/16/2015 09:54 AM, Javier Martinez Canillas wrote:
> Hello Sebastian,
Hello Javier,
> Right, those are bugs regardless of PREEMPT_RT or not as you said.
> I'll add it to my TODO list, thanks for finding those.
Thanks.
> Acked-by: Javier Martinez Canillas
>
> Best regards,
> Javier
Sebas
at relies on it. Therefore the Omap fix is
reverted for now.
Fixes: 0aa525d11859 ("tty: serial: 8250_core: read only RX if there is
something in the FIFO")
Reported-By: Nicolas Schichan
Debuged-By: Peter Hurley
Signed-off-by: Sebastian Andrzej Siewior
---
* Russell King - ARM Linux | 2
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250.h | 1 +
drivers/tty/serial/8250/8250_core.c | 10 --
drivers/tty/serial/8250/8250_omap.c | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty
On 02/12/2015 08:55 PM, Peter Hurley wrote:
> On 02/12/2015 02:23 PM, Sebastian Andrzej Siewior wrote:
>> * Peter Hurley | 2015-02-12 11:32:04 [-0500]:
>>
>>> That said, I don't think serial8250_do_startup() is really doing that much
>>> for OMAP h/w star
* Peter Hurley | 2015-02-12 11:32:04 [-0500]:
>That said, I don't think serial8250_do_startup() is really doing that much
>for OMAP h/w startup; open-coding what omap_8250 really needs is probably
>< 10 loc.
10 loc? I have a few more. serial8250_clear_fifos(),
serial_link_irq_chain() aren't expor
sers of gpiod_set_debounce() / gpio_set_debounce()
looks low but still this is not good.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpio/gpio-omap.c | 78
1 file changed, 39 insertions(+), 39 deletions(-)
diff --git a/drivers/gpio/gpio-o
On 02/11/2015 09:42 PM, Peter Hurley wrote:
>> Reverting makes sense to me if it has caused a regression. Maybe Sebastian
>> can update his patch to do this based on some quirk flag instead?
>
> That's fine with me. There's a 'bugs' field in struct 8250_uart_port and
> UART_BUG_* defines in 8250/
On 02/10/2015 12:34 AM, Peter Hurley wrote:
> The "too much work" message means serial8250_handle_irq() is returning 0,
> ie., not handled. Which in turn means IIR indicates no interrupt is pending
> (UART_IIR_NO_INT == 1).
The OMAP UART for instance have two possible TX-IRQ handling. The
default
This patch invokes add_preferred_console() with ttyS based on ttyO
arguments if the user didn't specify it on its own. This ensures that
the user will see the kernel booting on his serial console in case he
forgot to update the command line.
Signed-off-by: Sebastian Andrzej Siewior
---
On 12/11/2014 09:34 PM, Nicolae Rosia wrote:
> Hello,
Hi,
> Any updates on this series? I don't see it applied in [1] or [2].
I manage to freeze am335x-evm with those patches and I think Vignesh
is looking into this.
> Regards,
> Nicolae Rosia
Sebastian
--
To unsubscribe from this list: send
On 12/01/2014 05:38 PM, Tony Lindgren wrote:
> * One Thousand Gnomes [141201 06:11]:
>>> Well the nightmare userspace switch from ttyS to ttyO few years ago is
>>> something we want to avoid.. I think the best solution would be to make
>>> serial-omap.c transparently provide support for ttyO using
On 12/01/2014 10:53 AM, Vignesh R wrote:
> Hi Sebastian,
Hi Vignesh,
> I fixed the issue that was triggering the WARN_ON(). I think it would be
> better if you tested these patches, before I posted them on the
> mainline. I don't want to clutter the list with too main versions. Here
> is the link
* Sebastian Andrzej Siewior | 2014-11-26 23:01:46 [+0100]:
>Technically speaking this is not required. If both are enabled then the
>Maikefile order says that 8250 one wins, the second is never probed.
>
>If we choose to enable 8250_omap via defconfig then one might get suppris
stead ttyOx.
This patch _tries_ to bring this to the users' attention by not showing
the serial-omap driver once the 8250 one is enabled. So the user might
choose to use the help text which says that this driver (8250_omap)
uses ttySx instead ttyOx.
Signed-off-by: Sebastian Andrzej Siewior
---
On 11/06/2014 09:35 PM, Tony Lindgren wrote:
> The pinctrl change in this patch and the wake-up events are a separate
> issue.
So this patch can go in and wake-up issue will be fixed once the
infrastructure is there. No misunderstanding here?
> Tony
>
Sebastian
--
To unsubscribe from this list:
On 11/24/2014 01:16 PM, Vignesh R wrote:
> I have tried running both IIO and TSC at the same time. But I have never
> seen WARN_ON() even after running for close to 30 min. Can you send me
> the exact script, so that it will be easy to reproduce?
Sure thing.
- one shell
evtest /dev/input/
* Vignesh R | 2014-11-14 10:37:25 [+0530]:
>This series of patches fix TSC defects related to lag in touchscreen
>performance and cursor jump at touch release. The lag was result of
>udelay in TSC interrupt handler. Cursor jump due to false pen-up event.
>The patches implement Advisory 1.0.31 in s
On 11/21/2014 02:10 PM, Richard Cochran wrote:
> On the BB white using the LCD4 cape and the shipped debian kernel, the
> cursor *does* jump away, but not as often or as far as on the custom
> design I was working with.
This sounds like the ADC is still sampling while the input data becomes
inval
On 11/05/2014 08:43 PM, Lennart Sorensen wrote:
> I managed to get something dma related on uart3. But it isn't happy:
>
> [ 95.577401] DMA misaligned error with device 53
> repeated many times.
>
> I wonder if the dma support isn't quite working for the omap572x yet in
> this tree (ti's 3.12.
On 11/06/2014 08:15 PM, Nishanth Menon wrote:
> sounds good to me *IF* omap8250_enable_wakeup (wakeirq handling) is
> the way we want to continue doing things for daisychain? -> Tony, can
> you comment?
> http://marc.info/?l=linux-omap&m=141222144402707&w=2
>
> I wonder if wakeirq explicit handlin
-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250_omap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 57a8b1241b85..1681875f2996 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/ser
On 11/06/2014 04:14 AM, Greg KH wrote:
> I've now applied the patches here that I could, if I have missed any,
> please let me know and resend.
Thank you Greg. I pulled your tty-testing and it seems to work on
am335x-evm/dra7-evm.
Tony, if you could please take the two .dts files then the series
On 11/05/2014 05:20 PM, Lennart Sorensen wrote:
> On Wed, Nov 05, 2014 at 10:33:15AM -0500, Lennart Sorensen wrote:
>> Two systems ran 16 hours each so far with no issues. Pushed 170MB of
>> data through the pair of serial ports on one system at 230400.
>
> The console on uart3 doesn't appear to
On 11/05/2014 02:15 AM, Lennart Sorensen wrote:
> Well 4 hours running with multiple reboots (our testsuite reboots every
> 30 minutes to test the watchdog). So far it has only lost 70 bytes out
> of 40MB of data sent between uart7 and uart8 (and we are pretty sure
> the serial test has a small bu
On 11/04/2014 06:02 PM, Lennart Sorensen wrote:
>
> According to the manual the DMA channels for UART7 to 10 are:
>
> uart7: 144 145
> uart8: 146 147
> uart9: 148 149
> uart10: 150 151
>
> Might as well add those too. We have uart 7 and 8 in use on our board
> so I am about to go test it.
M
On 11/04/2014 12:44 PM, Vignesh R wrote:
> I ran following commands
> $ evtest /dev/input/touchscreen0 &
> (with heavy item on touchscreen)
> and
> $ cat /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage4_en
> (in a busy loop)
> I tried above experiment on my board but I didn't hit any p
On 10/27/2014 08:02 PM, Griffis, Brad wrote:
> On 10/27/2014 12:34 PM, Sebastian Andrzej Siewior wrote:
>> Do we really need #3 (and then #4)? Given the complexity we have already, is
>> there any benefit by decreasing this value?
>
> I specifically requested we add t
On 10/27/2014 12:08 PM, Vignesh R wrote:
> This series of patches fix TSC defects related to lag in touchscreen
I will try to look this in the next few days. Do we really need #3 (and
then #4)? Given the complexity we have already, is there any benefit by
decreasing this value? Would someone want
ch up and we endup with a crash as follows:
good, Thanks.
Acked-by: Sebastian Andrzej Siewior
Sebastian
--
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
On 10/21/2014 06:23 PM, Nishanth Menon wrote:
>
> The final solution is to transition off to use 8250 driver and no
> dependency on console structures and move away from omap-serial driver,
> hence no major cleanups are done for this driver.
So the shiny new driver works for you, is this what you
* Tony Lindgren | 2014-10-02 09:43:39 [-0700]:
>Looks good to me. For the patches that do not yet have my acks, please
>feel free to add:
>
>Reviewed-by: Tony Lindgren
>Tested-by: Tony Lindgren
Thanks.
>It's probably best that I queue the .dts changes separately though
>to avoid pointless merge
* Frans Klaver | 2014-09-30 10:44:16 [+0200]:
>On Mon, Sep 29, 2014 at 12:30:43PM +0200, Frans Klaver wrote:
>> On Mon, Sep 29, 2014 at 11:54:40AM +0200, Sebastian Andrzej Siewior wrote:
>> > For your "too much work for irq" problem: Could you add trace_printk()
>
Cc: devicet...@vger.kernel.org
Reviewed-by: Tony Lindgren
Tested-by: Tony Lindgren
Signed-off-by: Sebastian Andrzej Siewior
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index
d DMA only interrupt
routine.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250_omap.c | 71 +
1 file changed, 71 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 650054
Cc: devicet...@vger.kernel.org
Reviewed-by: Tony Lindgren
Tested-by: Tony Lindgren
Signed-off-by: Sebastian Andrzej Siewior
---
arch/arm/boot/dts/dra7.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index
ck changes in
the default IRQ handler :)
Cc: Heikki Krogerus
Cc: Peter Hurley
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250.h | 2 ++
drivers/tty/serial/8250/8250_core.c | 6 ++--
drivers/tty/serial/8250/8250_omap.c | 55 +
f8314620 051b3013 491ed416 (44792204)
because serial8250_console_setup() is already gone.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty
dgren
Tested-by: Tony Lindgren
Tested-by: Frans Klaver
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250_omap.c | 914
drivers/tty/serial/8250/Kconfig | 9 +
drivers/tty/serial/8250/Makefile| 1 +
3 files changed, 924 i
next invocation of serial8250_start_tx()
succeed then the dma_tx_err flag along with the THRI bit is removed and
DMA only usage may continue.
Reviewed-by: Tony Lindgren
Tested-by: Tony Lindgren
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250.h | 1 +
drivers/tty/serial/825
Frans reworded the two comments with better English for better
understanding. His review hit the mailing list after the patch got
applied so here is an incremental update.
Reported-by: Frans Klaver
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250_core.c | 4 ++--
1
t RPM" via __stop_tx(). Should it been filed then in the
start_tx() path we should program the DMA transfer and remove the error
flag and the THRI bit.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250_omap.c | 144
inc
patch provides callbacks for custom TX/RX DMA implementation. If
there are not setup / used, then the default (current) implementation is
used.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250.h | 3 +++
drivers/tty/serial/8250/8250_core.c | 11 ---
drivers
in the driver
in startup.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250_omap.c | 96 +
1 file changed, 96 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 5f183d197dfa
e for the TX side.
*Now* we learn about the RX status based on our bookkeeping and don't
need dmaengine_tx_status() for this anymore.
Cc: vinod.k...@intel.com
Reviewed-by: Tony Lindgren
Tested-by: Tony Lindgren
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/serial/8250/8250.
scenario described.
Cc: vinod.k...@intel.com
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/dma/edma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7b65633f495e..123f578d6dd3 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma
The queue is getting smaller. The highlights of v9…v10
- the DMA stall Frans Klaver reported which popped up in yocto is gone. It
also seems that the "ack the err-irq even if nothing happened" in EDMA
can be dropped.
- the RX- and TX-DMA callbacks are now OMAP-only and no "bugs" flags are
int
* Peter Hurley | 2014-09-17 08:20:41 [-0400]:
>> So I connected my am335x-evm
>> with beagle board xm because both of them have an old fashion UART
>> connector (instead those uart-to-usb). Both configured with HW-Flow and
>> I haven't seen the function invoked but I saw "port->icount.overrun"
>>
* Frans Klaver | 2014-09-29 11:46:20 [+0200]:
>On Wed, Sep 10, 2014 at 09:29:57PM +0200, Sebastian Andrzej Siewior wrote:
>> +/*
>> + * This two wrapper ensure, that enable_runtime_pm_tx() can be called more
>> than
>
>These two wrappers ensure that enabl
* Frans Klaver | 2014-09-29 11:38:23 [+0200]:
>threshold
fixed
>> +/*
>> + * It claims to be 16C750 compatible however it is a little different.
>> + * It has EFR and has no FCR7_64byte bit. The AFE (which it claims to
>> + * have) is enabled via EFR instead of MCR. The type is se
* Frans Klaver | 2014-09-29 11:26:06 [+0200]:
>On Wed, Sep 10, 2014 at 09:30:08PM +0200, Sebastian Andrzej Siewior wrote:
>> There is nothing to do for RPM in the RX path. If the HW goes off then it
>> won't assert the DMA line and the transfer won't happen. So we hope t
* Frans Klaver | 2014-09-29 10:50:42 [+0200]:
>This version fixes the console things for us. It also increases the
>amount of data we can push over the serial port. If I push the data
>towards our requirements, we're not there yet. I get the "too much work
>for irq" notice still. However, I don't
* Peter Ujfalusi | 2014-09-20 00:29:01 [+0300]:
>mask 800 means URXEVT0 (UART0 rx), 400 is UTXEVT0 (UART0 tx) events.
>But it is clear that my theory was not even close to what's going on.
>Do you have some tool which can be used to reproduce this issue?
The latest uart patch set is at
* Frans Klaver | 2014-09-22 11:28:54 [+0200]:
>I guess then we'd still have to answer the question why the yocto build
>calls set_termios() so often, but that's not on you then. Did you notice
>it even changing settings? We might want to fix this even if the kernel
>should be able to cope.
could
* Peter Hurley | 2014-09-25 07:31:32 [-0400]:
>I just verified that GNU readline6 uses ioctl(TCSETSW, ...) to do the
>set_termios
>(which is the ioctl that libc should use for tcsetattr(TCSADRAIN)).
>
>Maybe this userspace is using a readline()-alike that has a bug by not using
>the
>correct tcs
* Sebastian Andrzej Siewior | 2014-09-24 09:53:46 [+0200]:
>* Peter Hurley | 2014-09-23 13:03:51 [-0400]:
>
>>But DMA is cheating if the UART driver's tx_empty() method is saying the
>>transmitter is empty while TX DMA is still running.
>This shouldn't be the cas
* Heikki Krogerus | 2014-09-22 10:46:05 [+0300]:
>Well, there are no other SoCs at the moment that would need it, and
>it's actually possible that there never will be. So yes, just handle
>that also in the omap specific code.
Okay. So let me move the irq routine and the workarounds into omap then
* Frans Klaver | 2014-09-22 11:28:54 [+0200]:
>
>Wow, thanks for your work here. This does indeed sound hard to trap.
>
>I guess then we'd still have to answer the question why the yocto build
>calls set_termios() so often, but that's not on you then. Did you notice
>it even changing settings? We
* Peter Hurley | 2014-09-23 13:03:51 [-0400]:
>readline() does this; it 'saves' the caller's termios, sets termios
>for non-canonical reads, reads one char, and 'restores' the caller's
>termios.
interresting, thanks. I guess I would need to opimize this a little so
the baudrate isn't going to 0 a
* Frans Klaver | 2014-09-17 12:28:12 [+0200]:
>- Bone Black: Yocto poky, core-image-minimal
> Login, "less file" locks up, doesn't show anything. I can exit using
> Ctrl-C.
So I have the same with my and the serial-omap driver. No difference
here. The trace looks like this:
| -0 [
1 - 100 of 437 matches
Mail list logo
