* [PATCH] Revert "serial: 8250: Default SERIAL_OF_PLATFORM to SERIAL_8250"
From: Florian Fainelli @ 2018-12-21 4:27 UTC (permalink / raw)
To: linux-vger
Cc: linux-serial, mpe, arnd, gregkh, linux, benh, paulus,
linuxppc-dev, Florian Fainelli, Jiri Slaby, Nishanth Menon,
Tony Lindgren, Vignesh R, Lokesh Vutla, Michael Moese, open list
In-Reply-To: <20181220173844.GA5838@roeck-us.net>
This reverts commit 6d11023c345e369bcb9d5a68b271764e362c1f6e ("serial:
8250: Default SERIAL_OF_PLATFORM to SERIAL_8250") since that breaks at
least mpc8544ds (PowerPC) using arch/powerpc/kernel/legacy_serial.c.
See https://lkml.org/lkml/2018/12/5/1491 for discussion and analysis
Fixes: 6d11023c345e ("serial: 8250: Default SERIAL_OF_PLATFORM to SERIAL_8250")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/tty/serial/8250/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index d7737dca0e48..15c2c5463835 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -484,7 +484,6 @@ config SERIAL_8250_PXA
config SERIAL_OF_PLATFORM
tristate "Devicetree based probing for 8250 ports"
depends on SERIAL_8250 && OF
- default SERIAL_8250
help
This option is used for all 8250 compatible serial ports that
are probed through devicetree, including Open Firmware based
--
2.19.1
^ permalink raw reply related
* Re: [GIT PULL] TTY/Serial fixes for 4.20-rc8
From: pr-tracker-bot @ 2018-12-20 16:10 UTC (permalink / raw)
To: Greg KH
Cc: Linus Torvalds, Jiri Slaby, Stephen Rothwell, Andrew Morton,
linux-kernel, linux-serial
In-Reply-To: <20181220123910.GA18277@kroah.com>
The pull request you sent on Thu, 20 Dec 2018 13:39:10 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-4.20-rc8
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bfd7bd5b49c84aac9068bff7635e94ce038475ec
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* [GIT PULL] TTY/Serial fixes for 4.20-rc8
From: Greg KH @ 2018-12-20 12:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jiri Slaby, Stephen Rothwell, Andrew Morton, linux-kernel,
linux-serial
The following changes since commit 40e020c129cfc991e8ab4736d2665351ffd1468d:
Linux 4.20-rc6 (2018-12-09 15:31:00 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-4.20-rc8
for you to fetch changes up to 3c9dc275dba1124c1e16e7037226038451286813:
Revert "serial: 8250: Fix clearing FIFOs in RS485 mode again" (2018-12-17 16:18:29 +0100)
----------------------------------------------------------------
TTY/Serial fix for 4.20-rc8
Here is a single fix, a revert, for the 8250 serial driver to resolve a
reported problem. There was some attempted patches to fix the issue,
but people are arguing about them, so reverting the patch to revert back
to the 4.19 and older behavior is the best thing to do at this late in
the release cycle.
The revert has been in linux-next with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Paul Burton (1):
Revert "serial: 8250: Fix clearing FIFOs in RS485 mode again"
drivers/tty/serial/8250/8250_port.c | 29 +++++------------------------
1 file changed, 5 insertions(+), 24 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 0/4] serial: uartps: Driver updates
From: Maarten Brock @ 2018-12-20 11:04 UTC (permalink / raw)
To: Michal Simek
Cc: linux-kernel, monstr, Greg Kroah-Hartman, Shubhrajyoti Datta,
Jiri Slaby, linux-serial, linux-arm-kernel, linux-serial-owner
In-Reply-To: <be121f63-fe03-8b50-54e5-24865d856e56@xilinx.com>
On 2018-12-20 07:52, Michal Simek wrote:
> Hi,
>
> On 19. 12. 18 19:40, Maarten Brock wrote:
>> Hello Michal,
>>
>> On 2018-12-18 13:18, Michal Simek wrote:
>>> Hi,
>>>
>>> I am sending 4 patches in series to fix some issues we found.
>>> Patches were sent separately but I have been asked to send them in
>>> serial that's why I am also adding cover letter to explain this v2
>>> version.
>>>
>>> Thanks,
>>> Michal
>>
>> I'm wondering why, when reading the linux-serial mailing list, I can
>> only see this cover letter.
>> Are you perhaps using a different To/Cc for the actual patches? And if
>> so, is that on purpose?
>>
>
> I have checked linux-serial mailing list and I see all of them there.
> https://www.spinics.net/lists/linux-serial/
>
> Individual here.
> https://www.spinics.net/lists/linux-serial/msg32919.html
> https://www.spinics.net/lists/linux-serial/msg32916.html
> https://www.spinics.net/lists/linux-serial/msg32917.html
> https://www.spinics.net/lists/linux-serial/msg32918.html
>
> Also I see linux-serial@ in CC in all emails I have sent.
>
> Thanks,
> Michal
Thanks, I see them there too. But the odd thing is that I did not
receive
them in my mailbox. And I had noticed this before that I was missing
your
posts following a cover letter.
I normally do receive other peoples patches after a cover letter.
Maarten
^ permalink raw reply
* Re: [PATCH v2 0/4] serial: uartps: Driver updates
From: Michal Simek @ 2018-12-20 6:52 UTC (permalink / raw)
To: Maarten Brock, Michal Simek
Cc: linux-kernel, monstr, Greg Kroah-Hartman, Shubhrajyoti Datta,
Jiri Slaby, linux-serial, linux-arm-kernel, linux-serial-owner
In-Reply-To: <06bcd18cb2e0e81d3051ef6305139d40@vanmierlo.com>
Hi,
On 19. 12. 18 19:40, Maarten Brock wrote:
> Hello Michal,
>
> On 2018-12-18 13:18, Michal Simek wrote:
>> Hi,
>>
>> I am sending 4 patches in series to fix some issues we found.
>> Patches were sent separately but I have been asked to send them in
>> serial that's why I am also adding cover letter to explain this v2
>> version.
>>
>> Thanks,
>> Michal
>
> I'm wondering why, when reading the linux-serial mailing list, I can
> only see this cover letter.
> Are you perhaps using a different To/Cc for the actual patches? And if
> so, is that on purpose?
>
I have checked linux-serial mailing list and I see all of them there.
https://www.spinics.net/lists/linux-serial/
Individual here.
https://www.spinics.net/lists/linux-serial/msg32919.html
https://www.spinics.net/lists/linux-serial/msg32916.html
https://www.spinics.net/lists/linux-serial/msg32917.html
https://www.spinics.net/lists/linux-serial/msg32918.html
Also I see linux-serial@ in CC in all emails I have sent.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH] tty: serial: qcom_geni_serial: Fix UART hang
From: Doug Anderson @ 2018-12-19 23:01 UTC (permalink / raw)
To: Evan Green; +Cc: Ryan Case, Greg Kroah-Hartman, Jiri Slaby, LKML, linux-serial
In-Reply-To: <CAE=gft4=gK5Ge_BOMN4dov=b978dXbTBZ2KPDuGxCP=CvgLd2A@mail.gmail.com>
Hi,
On Wed, Dec 19, 2018 at 2:12 PM Evan Green <evgreen@chromium.org> wrote:
>
> On Wed, Dec 19, 2018 at 12:34 PM Ryan Case <ryandcase@chromium.org> wrote:
> >
> > If a serial console write occured while a UART transmit command was
> > waiting for a done signal then no further data would be sent until
> > something new kicked the system into gear. If there is already data
> > waiting in the circular buffer we must re-enable the tx watermark so we
> > receive the expected interrupts.
> >
> > Signed-off-by: Ryan Case <ryandcase@chromium.org>
> > ---
> >
> > drivers/tty/serial/qcom_geni_serial.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
> > index 0c93beb69e73..a694a47747c7 100644
> > --- a/drivers/tty/serial/qcom_geni_serial.c
> > +++ b/drivers/tty/serial/qcom_geni_serial.c
> > @@ -442,6 +442,7 @@ static void qcom_geni_serial_console_write(struct console *co, const char *s,
> > bool locked = true;
> > unsigned long flags;
> > u32 geni_status;
> > + u32 irq_en;
> >
> > WARN_ON(co->index < 0 || co->index >= GENI_UART_CONS_PORTS);
> >
> > @@ -476,6 +477,13 @@ static void qcom_geni_serial_console_write(struct console *co, const char *s,
> > * has been sent, in which case we need to look for done first.
> > */
> > qcom_geni_serial_poll_tx_done(uport);
> > +
> > + if (uart_circ_chars_pending(&uport->state->xmit)) {
> > + irq_en = readl_relaxed(uport->membase +
> > + SE_GENI_M_IRQ_EN);
> > + writel_relaxed(irq_en | M_TX_FIFO_WATERMARK_EN,
> > + uport->membase + SE_GENI_M_IRQ_EN);
>
> The _relaxed part of it has always been weird to me, but I guess we
> fought that battle awhile ago with this driver and lost.
>
> I suppose the only real danger with relaxed would be if you could get
> yourself into some sort of tight loop or idle where the CPU's write
> queue never flushes, but you needed it to in order to proceed. This
> probably could never happen, especially with locks around consoles and
> uart ports that act as barriers.
Yeah. IMO we should go through and remove all the "_relaxed" from
this driver until someone can prove that it's important for
performance. ...but I think that's for a future patch to do.
-Doug
^ permalink raw reply
* Re: [PATCH] tty: serial: qcom_geni_serial: Fix UART hang
From: Evan Green @ 2018-12-19 22:12 UTC (permalink / raw)
To: ryandcase; +Cc: gregkh, jslaby, Doug Anderson, linux-kernel, linux-serial
In-Reply-To: <20181219203353.172335-1-ryandcase@chromium.org>
On Wed, Dec 19, 2018 at 12:34 PM Ryan Case <ryandcase@chromium.org> wrote:
>
> If a serial console write occured while a UART transmit command was
> waiting for a done signal then no further data would be sent until
> something new kicked the system into gear. If there is already data
> waiting in the circular buffer we must re-enable the tx watermark so we
> receive the expected interrupts.
>
> Signed-off-by: Ryan Case <ryandcase@chromium.org>
> ---
>
> drivers/tty/serial/qcom_geni_serial.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
> index 0c93beb69e73..a694a47747c7 100644
> --- a/drivers/tty/serial/qcom_geni_serial.c
> +++ b/drivers/tty/serial/qcom_geni_serial.c
> @@ -442,6 +442,7 @@ static void qcom_geni_serial_console_write(struct console *co, const char *s,
> bool locked = true;
> unsigned long flags;
> u32 geni_status;
> + u32 irq_en;
>
> WARN_ON(co->index < 0 || co->index >= GENI_UART_CONS_PORTS);
>
> @@ -476,6 +477,13 @@ static void qcom_geni_serial_console_write(struct console *co, const char *s,
> * has been sent, in which case we need to look for done first.
> */
> qcom_geni_serial_poll_tx_done(uport);
> +
> + if (uart_circ_chars_pending(&uport->state->xmit)) {
> + irq_en = readl_relaxed(uport->membase +
> + SE_GENI_M_IRQ_EN);
> + writel_relaxed(irq_en | M_TX_FIFO_WATERMARK_EN,
> + uport->membase + SE_GENI_M_IRQ_EN);
The _relaxed part of it has always been weird to me, but I guess we
fought that battle awhile ago with this driver and lost.
I suppose the only real danger with relaxed would be if you could get
yourself into some sort of tight loop or idle where the CPU's write
queue never flushes, but you needed it to in order to proceed. This
probably could never happen, especially with locks around consoles and
uart ports that act as barriers.
Reviewed-by: Evan Green <evgreen@chromium.org>
^ permalink raw reply
* [PATCH] tty: serial: qcom_geni_serial: Fix UART hang
From: Ryan Case @ 2018-12-19 20:33 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: Evan Green, Doug Anderson, linux-kernel, linux-serial, Ryan Case
If a serial console write occured while a UART transmit command was
waiting for a done signal then no further data would be sent until
something new kicked the system into gear. If there is already data
waiting in the circular buffer we must re-enable the tx watermark so we
receive the expected interrupts.
Signed-off-by: Ryan Case <ryandcase@chromium.org>
---
drivers/tty/serial/qcom_geni_serial.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index 0c93beb69e73..a694a47747c7 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -442,6 +442,7 @@ static void qcom_geni_serial_console_write(struct console *co, const char *s,
bool locked = true;
unsigned long flags;
u32 geni_status;
+ u32 irq_en;
WARN_ON(co->index < 0 || co->index >= GENI_UART_CONS_PORTS);
@@ -476,6 +477,13 @@ static void qcom_geni_serial_console_write(struct console *co, const char *s,
* has been sent, in which case we need to look for done first.
*/
qcom_geni_serial_poll_tx_done(uport);
+
+ if (uart_circ_chars_pending(&uport->state->xmit)) {
+ irq_en = readl_relaxed(uport->membase +
+ SE_GENI_M_IRQ_EN);
+ writel_relaxed(irq_en | M_TX_FIFO_WATERMARK_EN,
+ uport->membase + SE_GENI_M_IRQ_EN);
+ }
}
__qcom_geni_serial_console_write(uport, s, count);
--
2.20.1.415.g653613c723-goog
^ permalink raw reply related
* Re: [PATCH] tty: serial: qcom_geni_serial: Fix wrap around of TX buffer
From: Matthias Kaehlcke @ 2018-12-19 19:04 UTC (permalink / raw)
To: Evan Green
Cc: gregkh, jslaby, linux-serial, linux-kernel, msavaliy, ryandcase,
Doug Anderson
In-Reply-To: <CAE=gft7BV=M4wpk304yhDV11ddNJSFGDYu8TRW3WOtDPLrRmnQ@mail.gmail.com>
On Wed, Dec 19, 2018 at 10:49:26AM -0800, Evan Green wrote:
> On Wed, Dec 19, 2018 at 10:17 AM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > Before commit a1fee899e5bed ("tty: serial: qcom_geni_serial: Fix
> > softlock") the size of TX transfers was limited to the TX FIFO size,
> > and wrap arounds of the UART circular buffer were split into two
> > transfers. With the commit wrap around are allowed within a transfer.
> > The TX FIFO of the geni serial port uses a word size of 4 bytes. In
> > case of a circular buffer wrap within a transfer the driver currently
> > may write an incomplete word to the FIFO, with some bytes containing
> > data from the circular buffer and others being zero. Since the
> > transfer isn't completed yet the zero bytes are sent as if they were
> > actual data.
> >
> > Handle wrap arounds of the TX buffer properly and ensure that words
> > written to the TX FIFO always contain valid data (unless the transfer
> > is completed).
> >
> > Fixes: a1fee899e5bed ("tty: serial: qcom_geni_serial: Fix softlock")
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
>
> Oh nice, so this did end up being your problem with corrupt
> characters?
Yes
> Strange though, I still would have expected this bug to
> result in inserted serial characters, rather than edited ones.
You are right here, initially I interpreted that some bytes changed,
but actually we observed inserted bytes, and later missing ones at the
end of the transfer.
> Either way, this looks good to me.
>
> Reviewed-by: Evan Green <evgreen@chromium.org>
Thanks!
^ permalink raw reply
* Re: [PATCH] tty: serial: qcom_geni_serial: Fix wrap around of TX buffer
From: Ryan Case @ 2018-12-19 18:53 UTC (permalink / raw)
To: Evan Green
Cc: mka, Greg Kroah-Hartman, Jiri Slaby, linux-serial, linux-kernel,
msavaliy, Doug Anderson
In-Reply-To: <CAE=gft7BV=M4wpk304yhDV11ddNJSFGDYu8TRW3WOtDPLrRmnQ@mail.gmail.com>
On Wed, Dec 19, 2018 at 10:50 AM Evan Green <evgreen@chromium.org> wrote:
>
> On Wed, Dec 19, 2018 at 10:17 AM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > Before commit a1fee899e5bed ("tty: serial: qcom_geni_serial: Fix
> > softlock") the size of TX transfers was limited to the TX FIFO size,
> > and wrap arounds of the UART circular buffer were split into two
> > transfers. With the commit wrap around are allowed within a transfer.
> > The TX FIFO of the geni serial port uses a word size of 4 bytes. In
> > case of a circular buffer wrap within a transfer the driver currently
> > may write an incomplete word to the FIFO, with some bytes containing
> > data from the circular buffer and others being zero. Since the
> > transfer isn't completed yet the zero bytes are sent as if they were
> > actual data.
> >
> > Handle wrap arounds of the TX buffer properly and ensure that words
> > written to the TX FIFO always contain valid data (unless the transfer
> > is completed).
> >
> > Fixes: a1fee899e5bed ("tty: serial: qcom_geni_serial: Fix softlock")
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
>
> Oh nice, so this did end up being your problem with corrupt
> characters? Strange though, I still would have expected this bug to
> result in inserted serial characters, rather than edited ones.
> Either way, this looks good to me.
>
> Reviewed-by: Evan Green <evgreen@chromium.org>
UART bluetooth firmware downloads consistently working for me again.
Tested-by: Ryan Case <ryandcase@chromium.org>
^ permalink raw reply
* Re: [PATCH] tty: serial: qcom_geni_serial: Fix wrap around of TX buffer
From: Evan Green @ 2018-12-19 18:49 UTC (permalink / raw)
To: mka
Cc: gregkh, jslaby, linux-serial, linux-kernel, msavaliy, ryandcase,
Doug Anderson
In-Reply-To: <20181219181747.118278-1-mka@chromium.org>
On Wed, Dec 19, 2018 at 10:17 AM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> Before commit a1fee899e5bed ("tty: serial: qcom_geni_serial: Fix
> softlock") the size of TX transfers was limited to the TX FIFO size,
> and wrap arounds of the UART circular buffer were split into two
> transfers. With the commit wrap around are allowed within a transfer.
> The TX FIFO of the geni serial port uses a word size of 4 bytes. In
> case of a circular buffer wrap within a transfer the driver currently
> may write an incomplete word to the FIFO, with some bytes containing
> data from the circular buffer and others being zero. Since the
> transfer isn't completed yet the zero bytes are sent as if they were
> actual data.
>
> Handle wrap arounds of the TX buffer properly and ensure that words
> written to the TX FIFO always contain valid data (unless the transfer
> is completed).
>
> Fixes: a1fee899e5bed ("tty: serial: qcom_geni_serial: Fix softlock")
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Oh nice, so this did end up being your problem with corrupt
characters? Strange though, I still would have expected this bug to
result in inserted serial characters, rather than edited ones.
Either way, this looks good to me.
Reviewed-by: Evan Green <evgreen@chromium.org>
^ permalink raw reply
* Re: [PATCH v2 0/4] serial: uartps: Driver updates
From: Maarten Brock @ 2018-12-19 18:40 UTC (permalink / raw)
To: Michal Simek
Cc: monstr, linux-serial-owner, Greg Kroah-Hartman,
Shubhrajyoti Datta, linux-kernel, linux-serial, Jiri Slaby,
linux-arm-kernel
In-Reply-To: <cover.1545135519.git.michal.simek@xilinx.com>
Hello Michal,
On 2018-12-18 13:18, Michal Simek wrote:
> Hi,
>
> I am sending 4 patches in series to fix some issues we found.
> Patches were sent separately but I have been asked to send them in
> serial that's why I am also adding cover letter to explain this v2
> version.
>
> Thanks,
> Michal
I'm wondering why, when reading the linux-serial mailing list, I can
only see this cover letter.
Are you perhaps using a different To/Cc for the actual patches? And if
so, is that on purpose?
Kind regards,
Maarten
^ permalink raw reply
* [PATCH] tty: serial: qcom_geni_serial: Fix wrap around of TX buffer
From: Matthias Kaehlcke @ 2018-12-19 18:17 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-serial, linux-kernel, Mukesh Kumar Savaliya, Ryan Case,
Douglas Anderson, Evan Green, Matthias Kaehlcke
Before commit a1fee899e5bed ("tty: serial: qcom_geni_serial: Fix
softlock") the size of TX transfers was limited to the TX FIFO size,
and wrap arounds of the UART circular buffer were split into two
transfers. With the commit wrap around are allowed within a transfer.
The TX FIFO of the geni serial port uses a word size of 4 bytes. In
case of a circular buffer wrap within a transfer the driver currently
may write an incomplete word to the FIFO, with some bytes containing
data from the circular buffer and others being zero. Since the
transfer isn't completed yet the zero bytes are sent as if they were
actual data.
Handle wrap arounds of the TX buffer properly and ensure that words
written to the TX FIFO always contain valid data (unless the transfer
is completed).
Fixes: a1fee899e5bed ("tty: serial: qcom_geni_serial: Fix softlock")
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
drivers/tty/serial/qcom_geni_serial.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index cf7a95e339ad9..2ee2d3286a6b4 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -744,7 +744,7 @@ static void qcom_geni_serial_handle_tx(struct uart_port *uport, bool done,
avail *= port->tx_bytes_pw;
tail = xmit->tail;
- chunk = min3(avail, pending, (size_t)(UART_XMIT_SIZE - tail));
+ chunk = min(avail, pending);
if (!chunk)
goto out_write_wakeup;
@@ -766,19 +766,21 @@ static void qcom_geni_serial_handle_tx(struct uart_port *uport, bool done,
memset(buf, 0, ARRAY_SIZE(buf));
tx_bytes = min_t(size_t, remaining, port->tx_bytes_pw);
- for (c = 0; c < tx_bytes ; c++)
- buf[c] = xmit->buf[tail + c];
+
+ for (c = 0; c < tx_bytes ; c++) {
+ buf[c] = xmit->buf[tail++];
+ tail &= UART_XMIT_SIZE - 1;
+ }
iowrite32_rep(uport->membase + SE_GENI_TX_FIFOn, buf, 1);
i += tx_bytes;
- tail += tx_bytes;
uport->icount.tx += tx_bytes;
remaining -= tx_bytes;
port->tx_remaining -= tx_bytes;
}
- xmit->tail = tail & (UART_XMIT_SIZE - 1);
+ xmit->tail = tail;
/*
* The tx fifo watermark is level triggered and latched. Though we had
--
2.20.0.405.gbc1bbc6f85-goog
^ permalink raw reply related
* Re: [PATCH v2 1/2] dt-bindings: serial: sh-sci: Document r8a774a1 bindings
From: Geert Uytterhoeven @ 2018-12-19 10:19 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Geert Uytterhoeven,
Simon Horman, open list:SERIAL DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Chris Paterson, Biju Das,
Linux-Renesas
In-Reply-To: <1545213985-30341-2-git-send-email-fabrizio.castro@bp.renesas.com>
On Wed, Dec 19, 2018 at 11:06 AM Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> RZ/G2M (R8A774A1) SoC also has the R-Car Gen3 compatible SCIF and
> HSCIF ports, so document the SoC specific bindings. While at it,
> update the RZ/G1 and RZ/G2 family specific strings description as
> outdated.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 resend 2/2] dt-bindings: serial: sh-sci: Document r8a774c0 bindings
From: Fabrizio Castro @ 2018-12-19 10:06 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Fabrizio Castro, Rob Herring, Mark Rutland, Geert Uytterhoeven,
Simon Horman, linux-serial, devicetree, linux-kernel,
Chris Paterson, Biju Das, linux-renesas-soc
In-Reply-To: <1545213985-30341-1-git-send-email-fabrizio.castro@bp.renesas.com>
RZ/G2E (R8A774C0) SoC also has the R-Car Gen3 compatible SCIF and
HSCIF ports, so document the SoC specific bindings.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Rob Herring <robh@kernel.org>
---
v1->v2:
* Fixed title according to Geert's comment
Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index 21526e8..20232ad 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -26,6 +26,8 @@ Required properties:
- "renesas,hscif-r8a77470" for R8A77470 (RZ/G1C) HSCIF compatible UART.
- "renesas,scif-r8a774a1" for R8A774A1 (RZ/G2M) SCIF compatible UART.
- "renesas,hscif-r8a774a1" for R8A774A1 (RZ/G2M) HSCIF compatible UART.
+ - "renesas,scif-r8a774c0" for R8A774C0 (RZ/G2E) SCIF compatible UART.
+ - "renesas,hscif-r8a774c0" for R8A774C0 (RZ/G2E) HSCIF compatible UART.
- "renesas,scif-r8a7778" for R8A7778 (R-Car M1) SCIF compatible UART.
- "renesas,scif-r8a7779" for R8A7779 (R-Car H1) SCIF compatible UART.
- "renesas,scif-r8a7790" for R8A7790 (R-Car H2) SCIF compatible UART.
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: serial: sh-sci: Document r8a774a1 bindings
From: Fabrizio Castro @ 2018-12-19 10:06 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Fabrizio Castro, Rob Herring, Mark Rutland, Geert Uytterhoeven,
Simon Horman, linux-serial, devicetree, linux-kernel,
Chris Paterson, Biju Das, linux-renesas-soc
In-Reply-To: <1545213985-30341-1-git-send-email-fabrizio.castro@bp.renesas.com>
RZ/G2M (R8A774A1) SoC also has the R-Car Gen3 compatible SCIF and
HSCIF ports, so document the SoC specific bindings. While at it,
update the RZ/G1 and RZ/G2 family specific strings description as
outdated.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
---
v1->v2:
* Prepended "dt-bindings: " to the title
.../devicetree/bindings/serial/renesas,sci-serial.txt | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index e52e16c..21526e8 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -24,6 +24,8 @@ Required properties:
- "renesas,hscif-r8a7745" for R8A7745 (RZ/G1E) HSCIF compatible UART.
- "renesas,scif-r8a77470" for R8A77470 (RZ/G1C) SCIF compatible UART.
- "renesas,hscif-r8a77470" for R8A77470 (RZ/G1C) HSCIF compatible UART.
+ - "renesas,scif-r8a774a1" for R8A774A1 (RZ/G2M) SCIF compatible UART.
+ - "renesas,hscif-r8a774a1" for R8A774A1 (RZ/G2M) HSCIF compatible UART.
- "renesas,scif-r8a7778" for R8A7778 (R-Car M1) SCIF compatible UART.
- "renesas,scif-r8a7779" for R8A7779 (R-Car H1) SCIF compatible UART.
- "renesas,scif-r8a7790" for R8A7790 (R-Car H2) SCIF compatible UART.
@@ -61,13 +63,13 @@ Required properties:
- "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART.
- "renesas,scifb-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFB compatible UART.
- "renesas,rcar-gen1-scif" for R-Car Gen1 SCIF compatible UART,
- - "renesas,rcar-gen2-scif" for R-Car Gen2 SCIF compatible UART,
- - "renesas,rcar-gen3-scif" for R-Car Gen3 SCIF compatible UART,
- - "renesas,rcar-gen2-scifa" for R-Car Gen2 SCIFA compatible UART,
- - "renesas,rcar-gen2-scifb" for R-Car Gen2 SCIFB compatible UART,
+ - "renesas,rcar-gen2-scif" for R-Car Gen2 and RZ/G1 SCIF compatible UART,
+ - "renesas,rcar-gen3-scif" for R-Car Gen3 and RZ/G2 SCIF compatible UART,
+ - "renesas,rcar-gen2-scifa" for R-Car Gen2 and RZ/G1 SCIFA compatible UART,
+ - "renesas,rcar-gen2-scifb" for R-Car Gen2 and RZ/G1 SCIFB compatible UART,
- "renesas,rcar-gen1-hscif" for R-Car Gen1 HSCIF compatible UART,
- - "renesas,rcar-gen2-hscif" for R-Car Gen2 HSCIF compatible UART,
- - "renesas,rcar-gen3-hscif" for R-Car Gen3 HSCIF compatible UART,
+ - "renesas,rcar-gen2-hscif" for R-Car Gen2 and RZ/G1 HSCIF compatible UART,
+ - "renesas,rcar-gen3-hscif" for R-Car Gen3 and RZ/G2 HSCIF compatible UART,
- "renesas,scif" for generic SCIF compatible UART.
- "renesas,scifa" for generic SCIFA compatible UART.
- "renesas,scifb" for generic SCIFB compatible UART.
--
2.7.4
^ permalink raw reply related
* [PATCH v2 resend 0/2] RZ/G2[EM] SCIF and HSCIF documentation
From: Fabrizio Castro @ 2018-12-19 10:06 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Fabrizio Castro, Rob Herring, Mark Rutland, Geert Uytterhoeven,
Simon Horman, linux-serial, devicetree, linux-kernel,
Chris Paterson, Biju Das, linux-renesas-soc
Hello Greg,
as promised I am resending the SCIF and HSCIF dt-bindings related
patches for the RZ/G2M and RZ/G2E.
This series applies on top of next-20181219.
Thanks,
Fab
Fabrizio Castro (2):
dt-bindings: serial: sh-sci: Document r8a774a1 bindings
dt-bindings: serial: sh-sci: Document r8a774c0 bindings
.../devicetree/bindings/serial/renesas,sci-serial.txt | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
--
2.7.4
^ permalink raw reply
* RE: [PATCH v2] dt-bindings: serial: sh-sci: Document r8a774c0 bindings
From: Fabrizio Castro @ 2018-12-19 9:46 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Geert Uytterhoeven, Simon Horman, Rob Herring, Mark Rutland,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Chris Paterson, Biju Das,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <20181219072535.GA28473@kroah.com>
Hello Greg,
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Sent: 19 December 2018 07:26
> To: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Subject: Re: [PATCH v2] dt-bindings: serial: sh-sci: Document r8a774c0 bindings
>
> On Tue, Dec 18, 2018 at 12:03:10PM +0000, Fabrizio Castro wrote:
> > RZ/G2E (R8A774C0) SoC also has the R-Car Gen3 compatible SCIF and
> > HSCIF ports, so document the SoC specific bindings.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > ---
> > v1->v2:
> > * Fixed title according to Geert's comment
> >
> > This patch depends on:
> > https://patchwork.kernel.org/patch/10565543/
>
> I don't have that patch in my tree, so can you please resend all of the
> pending patches that you need applied so that I can? Including this one
> too.
No problems, I'll resend both, and I'll prepend "dt-bindings:" to the title of the other patch as well.
Thanks,
Fab
>
> thanks,
>
> greg k-h
[https://www2.renesas.eu/media/email/unicef.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: serial: sh-sci: Document r8a774c0 bindings
From: Greg Kroah-Hartman @ 2018-12-19 7:25 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Geert Uytterhoeven, Simon Horman, Rob Herring, Mark Rutland,
linux-serial, devicetree, linux-kernel, Chris Paterson, Biju Das,
linux-renesas-soc
In-Reply-To: <1545134590-22510-1-git-send-email-fabrizio.castro@bp.renesas.com>
On Tue, Dec 18, 2018 at 12:03:10PM +0000, Fabrizio Castro wrote:
> RZ/G2E (R8A774C0) SoC also has the R-Car Gen3 compatible SCIF and
> HSCIF ports, so document the SoC specific bindings.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> v1->v2:
> * Fixed title according to Geert's comment
>
> This patch depends on:
> https://patchwork.kernel.org/patch/10565543/
I don't have that patch in my tree, so can you please resend all of the
pending patches that you need applied so that I can? Including this one
too.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v6 1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support
From: Randy Dunlap @ 2018-12-19 3:12 UTC (permalink / raw)
To: Long Cheng, Vinod Koul, Rob Herring, Mark Rutland, Ryder Lee
Cc: devicetree, Sean Wang, srv_heupstream, Greg Kroah-Hartman,
Sean Wang, linux-kernel, YT Shen, dmaengine, linux-mediatek,
linux-serial, Jiri Slaby, Matthias Brugger, Yingjoe Chen,
Dan Williams, linux-arm-kernel
In-Reply-To: <1545186022-3712-2-git-send-email-long.cheng@mediatek.com>
Hi,
A few small corrections...
On 12/18/18 6:20 PM, Long Cheng wrote:
> diff --git a/drivers/dma/mediatek/Kconfig b/drivers/dma/mediatek/Kconfig
> index 27bac0b..2c082c9 100644
> --- a/drivers/dma/mediatek/Kconfig
> +++ b/drivers/dma/mediatek/Kconfig
> @@ -1,4 +1,15 @@
>
> +config DMA_MTK_UART
> + tristate "MediaTek SoCs APDMA support for UART"
> + depends on OF && SERIAL_8250_MT6577
> + select DMA_ENGINE
> + select DMA_VIRTUAL_CHANNELS
> + help
> + Support for the UART DMA engine found on MediaTek MTK SoCs.
> + when SERIAL_8250_MT6577 is enabled, and if you want to using DMA,
When to use DMA,
> + you can enable the config. the DMA engine just only be used
The DMA engine can only be used
> + with MediaTek SoCs.
> +
cheers,
--
~Randy
^ permalink raw reply
* [PATCH v6 2/2] arm: dts: mt2712: add uart APDMA to device tree
From: Long Cheng @ 2018-12-19 2:20 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland, Ryder Lee
Cc: Matthias Brugger, Dan Williams, Greg Kroah-Hartman, Jiri Slaby,
Sean Wang, Sean Wang, dmaengine, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, linux-serial, srv_heupstream,
Yingjoe Chen, YT Shen, Long Cheng
In-Reply-To: <1545186022-3712-1-git-send-email-long.cheng@mediatek.com>
1. add uart APDMA controller device node
2. add uart 0/1/2/3/4/5 DMA function
Signed-off-by: Long Cheng <long.cheng@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 50 +++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 976d92a..be1a22a 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -300,6 +300,9 @@
interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
clocks = <&baud_clk>, <&sys_clk>;
clock-names = "baud", "bus";
+ dmas = <&apdma 10
+ &apdma 11>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -369,6 +372,38 @@
(GIC_CPU_MASK_RAW(0x13) | IRQ_TYPE_LEVEL_HIGH)>;
};
+ apdma: dma-controller@11000400 {
+ compatible = "mediatek,mt2712-uart-dma",
+ "mediatek,mt6577-uart-dma";
+ reg = <0 0x11000400 0 0x80>,
+ <0 0x11000480 0 0x80>,
+ <0 0x11000500 0 0x80>,
+ <0 0x11000580 0 0x80>,
+ <0 0x11000600 0 0x80>,
+ <0 0x11000680 0 0x80>,
+ <0 0x11000700 0 0x80>,
+ <0 0x11000780 0 0x80>,
+ <0 0x11000800 0 0x80>,
+ <0 0x11000880 0 0x80>,
+ <0 0x11000900 0 0x80>,
+ <0 0x11000980 0 0x80>;
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 105 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 106 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 107 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 108 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 109 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 110 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 111 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 112 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 113 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 114 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&pericfg CLK_PERI_AP_DMA>;
+ clock-names = "apdma";
+ #dma-cells = <1>;
+ };
+
auxadc: adc@11001000 {
compatible = "mediatek,mt2712-auxadc";
reg = <0 0x11001000 0 0x1000>;
@@ -385,6 +420,9 @@
interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_LOW>;
clocks = <&baud_clk>, <&sys_clk>;
clock-names = "baud", "bus";
+ dmas = <&apdma 0
+ &apdma 1>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -395,6 +433,9 @@
interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_LOW>;
clocks = <&baud_clk>, <&sys_clk>;
clock-names = "baud", "bus";
+ dmas = <&apdma 2
+ &apdma 3>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -405,6 +446,9 @@
interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_LOW>;
clocks = <&baud_clk>, <&sys_clk>;
clock-names = "baud", "bus";
+ dmas = <&apdma 4
+ &apdma 5>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -415,6 +459,9 @@
interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_LOW>;
clocks = <&baud_clk>, <&sys_clk>;
clock-names = "baud", "bus";
+ dmas = <&apdma 6
+ &apdma 7>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -629,6 +676,9 @@
interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_LOW>;
clocks = <&baud_clk>, <&sys_clk>;
clock-names = "baud", "bus";
+ dmas = <&apdma 8
+ &apdma 9>;
+ dma-names = "tx", "rx";
status = "disabled";
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v6 1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support
From: Long Cheng @ 2018-12-19 2:20 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland, Ryder Lee
Cc: Matthias Brugger, Dan Williams, Greg Kroah-Hartman, Jiri Slaby,
Sean Wang, Sean Wang, dmaengine, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, linux-serial, srv_heupstream,
Yingjoe Chen, YT Shen, Long Cheng
In-Reply-To: <1545186022-3712-1-git-send-email-long.cheng@mediatek.com>
In DMA engine framework, add 8250 uart dma to support MediaTek uart.
If MediaTek uart enabled(SERIAL_8250_MT6577), and want to improve
the performance, can enable the function.
Signed-off-by: Long Cheng <long.cheng@mediatek.com>
---
drivers/dma/mediatek/8250_mtk_dma.c | 694 +++++++++++++++++++++++++++++++++++
drivers/dma/mediatek/Kconfig | 11 +
drivers/dma/mediatek/Makefile | 1 +
3 files changed, 706 insertions(+)
create mode 100644 drivers/dma/mediatek/8250_mtk_dma.c
diff --git a/drivers/dma/mediatek/8250_mtk_dma.c b/drivers/dma/mediatek/8250_mtk_dma.c
new file mode 100644
index 0000000..c4090f2
--- /dev/null
+++ b/drivers/dma/mediatek/8250_mtk_dma.c
@@ -0,0 +1,694 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek 8250 DMA driver.
+ *
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Long Cheng <long.cheng@mediatek.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/dmaengine.h>
+#include <linux/dma-mapping.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/list.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_dma.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/pm_runtime.h>
+#include <linux/iopoll.h>
+
+#include "../virt-dma.h"
+
+#define MTK_UART_APDMA_CHANNELS (CONFIG_SERIAL_8250_NR_UARTS * 2)
+
+#define VFF_EN_B BIT(0)
+#define VFF_STOP_B BIT(0)
+#define VFF_FLUSH_B BIT(0)
+#define VFF_4G_SUPPORT_B BIT(0)
+#define VFF_RX_INT_EN0_B BIT(0) /*rx valid size >= vff thre*/
+#define VFF_RX_INT_EN1_B BIT(1)
+#define VFF_TX_INT_EN_B BIT(0) /*tx left size >= vff thre*/
+#define VFF_WARM_RST_B BIT(0)
+#define VFF_RX_INT_FLAG_CLR_B (BIT(0) | BIT(1))
+#define VFF_TX_INT_FLAG_CLR_B 0
+#define VFF_STOP_CLR_B 0
+#define VFF_FLUSH_CLR_B 0
+#define VFF_INT_EN_CLR_B 0
+#define VFF_4G_SUPPORT_CLR_B 0
+
+/* interrupt trigger level for tx */
+#define VFF_TX_THRE(n) ((n) * 7 / 8)
+/* interrupt trigger level for rx */
+#define VFF_RX_THRE(n) ((n) * 3 / 4)
+
+#define MTK_UART_APDMA_RING_SIZE 0xffffU
+/* invert this bit when wrap ring head again*/
+#define MTK_UART_APDMA_RING_WRAP 0x10000U
+
+#define VFF_INT_FLAG 0x00
+#define VFF_INT_EN 0x04
+#define VFF_EN 0x08
+#define VFF_RST 0x0c
+#define VFF_STOP 0x10
+#define VFF_FLUSH 0x14
+#define VFF_ADDR 0x1c
+#define VFF_LEN 0x24
+#define VFF_THRE 0x28
+#define VFF_WPT 0x2c
+#define VFF_RPT 0x30
+/*TX: the buffer size HW can read. RX: the buffer size SW can read.*/
+#define VFF_VALID_SIZE 0x3c
+/*TX: the buffer size SW can write. RX: the buffer size HW can write.*/
+#define VFF_LEFT_SIZE 0x40
+#define VFF_DEBUG_STATUS 0x50
+#define VFF_4G_SUPPORT 0x54
+
+struct mtk_uart_apdmadev {
+ struct dma_device ddev;
+ struct clk *clk;
+ bool support_33bits;
+ unsigned int dma_irq[MTK_UART_APDMA_CHANNELS];
+};
+
+struct mtk_uart_apdma_desc {
+ struct virt_dma_desc vd;
+
+ unsigned int avail_len;
+};
+
+struct mtk_chan {
+ struct virt_dma_chan vc;
+ struct dma_slave_config cfg;
+ void __iomem *base;
+ struct mtk_uart_apdma_desc *desc;
+
+ bool requested;
+
+ unsigned int rx_status;
+};
+
+static inline struct mtk_uart_apdmadev *
+to_mtk_uart_apdma_dev(struct dma_device *d)
+{
+ return container_of(d, struct mtk_uart_apdmadev, ddev);
+}
+
+static inline struct mtk_chan *to_mtk_uart_apdma_chan(struct dma_chan *c)
+{
+ return container_of(c, struct mtk_chan, vc.chan);
+}
+
+static inline struct mtk_uart_apdma_desc *to_mtk_uart_apdma_desc
+ (struct dma_async_tx_descriptor *t)
+{
+ return container_of(t, struct mtk_uart_apdma_desc, vd.tx);
+}
+
+static void mtk_uart_apdma_chan_write(struct mtk_chan *c,
+ unsigned int reg, unsigned int val)
+{
+ writel(val, c->base + reg);
+}
+
+static unsigned int
+mtk_uart_apdma_chan_read(struct mtk_chan *c, unsigned int reg)
+{
+ return readl(c->base + reg);
+}
+
+static void mtk_uart_apdma_desc_free(struct virt_dma_desc *vd)
+{
+ struct dma_chan *chan = vd->tx.chan;
+ struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
+
+ kfree(c->desc);
+ c->desc = NULL;
+}
+
+static void mtk_uart_apdma_start_tx(struct mtk_chan *c)
+{
+ unsigned int txcount = c->desc->avail_len;
+ unsigned int len, send, left, wpt, wrap;
+
+ if (mtk_uart_apdma_chan_read(c, VFF_LEFT_SIZE) == 0U) {
+ mtk_uart_apdma_chan_write(c, VFF_INT_EN, VFF_TX_INT_EN_B);
+ } else {
+ len = mtk_uart_apdma_chan_read(c, VFF_LEN);
+
+ while (((left = mtk_uart_apdma_chan_read(c,
+ VFF_LEFT_SIZE)) > 0U)
+ && (c->desc->avail_len != 0U)) {
+ send = min_t(unsigned int, left, c->desc->avail_len);
+ wpt = mtk_uart_apdma_chan_read(c, VFF_WPT);
+ wrap = wpt & MTK_UART_APDMA_RING_WRAP ?
+ 0U : MTK_UART_APDMA_RING_WRAP;
+
+ if ((wpt & (len - 1U)) + send < len)
+ mtk_uart_apdma_chan_write(c,
+ VFF_WPT, wpt + send);
+ else
+ mtk_uart_apdma_chan_write(c, VFF_WPT,
+ ((wpt + send) & (len - 1U))
+ | wrap);
+
+ c->desc->avail_len -= send;
+ }
+
+ if (txcount != c->desc->avail_len) {
+ mtk_uart_apdma_chan_write(c,
+ VFF_INT_EN, VFF_TX_INT_EN_B);
+ if (mtk_uart_apdma_chan_read(c,
+ VFF_FLUSH) == 0U)
+ mtk_uart_apdma_chan_write(c,
+ VFF_FLUSH, VFF_FLUSH_B);
+ }
+ }
+}
+
+static void mtk_uart_apdma_start_rx(struct mtk_chan *c)
+{
+ struct mtk_uart_apdma_desc *d = c->desc;
+ unsigned int rx_len, wg, rg, count;
+
+ if (mtk_uart_apdma_chan_read(c, VFF_VALID_SIZE) == 0U)
+ return;
+
+ if (d && vchan_next_desc(&c->vc)) {
+ rx_len = mtk_uart_apdma_chan_read(c, VFF_LEN);
+ rg = mtk_uart_apdma_chan_read(c, VFF_RPT);
+ wg = mtk_uart_apdma_chan_read(c, VFF_WPT);
+ count = ((rg ^ wg) & MTK_UART_APDMA_RING_WRAP) ?
+ ((wg & MTK_UART_APDMA_RING_SIZE) +
+ rx_len - (rg & MTK_UART_APDMA_RING_SIZE)) :
+ ((wg & MTK_UART_APDMA_RING_SIZE) -
+ (rg & MTK_UART_APDMA_RING_SIZE));
+
+ c->rx_status = count;
+ mtk_uart_apdma_chan_write(c, VFF_RPT, wg);
+
+ list_del(&d->vd.node);
+ vchan_cookie_complete(&d->vd);
+ }
+}
+
+static irqreturn_t mtk_uart_apdma_irq_handler(int irq, void *dev_id)
+{
+ struct dma_chan *chan = (struct dma_chan *)dev_id;
+ struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
+ struct mtk_uart_apdma_desc *d;
+ unsigned long flags;
+
+ spin_lock_irqsave(&c->vc.lock, flags);
+ switch (c->cfg.direction) {
+ case DMA_DEV_TO_MEM:
+ mtk_uart_apdma_chan_write(c,
+ VFF_INT_FLAG, VFF_RX_INT_FLAG_CLR_B);
+ mtk_uart_apdma_start_rx(c);
+ break;
+ case DMA_MEM_TO_DEV:
+ d = c->desc;
+
+ mtk_uart_apdma_chan_write(c,
+ VFF_INT_FLAG, VFF_TX_INT_FLAG_CLR_B);
+
+ if (d->avail_len != 0U) {
+ mtk_uart_apdma_start_tx(c);
+ } else {
+ list_del(&d->vd.node);
+ vchan_cookie_complete(&d->vd);
+ }
+ break;
+ default:
+ break;
+ }
+ spin_unlock_irqrestore(&c->vc.lock, flags);
+
+ return IRQ_HANDLED;
+}
+
+static int mtk_uart_apdma_alloc_chan_resources(struct dma_chan *chan)
+{
+ struct mtk_uart_apdmadev *mtkd = to_mtk_uart_apdma_dev(chan->device);
+ struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
+ u32 status;
+ int ret = -EBUSY;
+
+ pm_runtime_get_sync(mtkd->ddev.dev);
+
+ mtk_uart_apdma_chan_write(c, VFF_ADDR, 0);
+ mtk_uart_apdma_chan_write(c, VFF_THRE, 0);
+ mtk_uart_apdma_chan_write(c, VFF_LEN, 0);
+ mtk_uart_apdma_chan_write(c, VFF_RST, VFF_WARM_RST_B);
+
+ ret = readx_poll_timeout(readl,
+ c->base + VFF_EN,
+ status, status == 0, 10, 100);
+ if (ret) {
+ dev_err(c->vc.chan.device->dev,
+ "dma reset: fail, timeout\n");
+ goto exit;
+ }
+
+ if (!c->requested) {
+ c->requested = true;
+ ret = request_irq(mtkd->dma_irq[chan->chan_id],
+ mtk_uart_apdma_irq_handler,
+ IRQF_TRIGGER_NONE,
+ KBUILD_MODNAME, chan);
+ if (ret < 0) {
+ dev_err(chan->device->dev, "Can't request dma IRQ\n");
+ return -EINVAL;
+ }
+ }
+
+ if (mtkd->support_33bits)
+ mtk_uart_apdma_chan_write(c,
+ VFF_4G_SUPPORT, VFF_4G_SUPPORT_CLR_B);
+
+exit:
+ return ret;
+}
+
+static void mtk_uart_apdma_free_chan_resources(struct dma_chan *chan)
+{
+ struct mtk_uart_apdmadev *mtkd = to_mtk_uart_apdma_dev(chan->device);
+ struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
+
+ if (c->requested) {
+ c->requested = false;
+ free_irq(mtkd->dma_irq[chan->chan_id], chan);
+ }
+
+ tasklet_kill(&c->vc.task);
+
+ vchan_free_chan_resources(&c->vc);
+
+ pm_runtime_put_sync(mtkd->ddev.dev);
+}
+
+static enum dma_status mtk_uart_apdma_tx_status(struct dma_chan *chan,
+ dma_cookie_t cookie,
+ struct dma_tx_state *txstate)
+{
+ struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
+ enum dma_status ret;
+ unsigned long flags;
+
+ if (!txstate)
+ return DMA_ERROR;
+
+ ret = dma_cookie_status(chan, cookie, txstate);
+ spin_lock_irqsave(&c->vc.lock, flags);
+ if (ret == DMA_IN_PROGRESS) {
+ c->rx_status = mtk_uart_apdma_chan_read(c, VFF_RPT)
+ & MTK_UART_APDMA_RING_SIZE;
+ dma_set_residue(txstate, c->rx_status);
+ } else if (ret == DMA_COMPLETE && c->cfg.direction == DMA_DEV_TO_MEM) {
+ dma_set_residue(txstate, c->rx_status);
+ } else {
+ dma_set_residue(txstate, 0);
+ }
+ spin_unlock_irqrestore(&c->vc.lock, flags);
+
+ return ret;
+}
+
+/*
+ * dmaengine_prep_slave_single will call the function. and sglen is 1.
+ * 8250 uart using one ring buffer, and deal with one sg.
+ */
+static struct dma_async_tx_descriptor *mtk_uart_apdma_prep_slave_sg
+ (struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sglen, enum dma_transfer_direction dir,
+ unsigned long tx_flags, void *context)
+{
+ struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
+ struct mtk_uart_apdma_desc *d;
+
+ if ((dir != DMA_DEV_TO_MEM) &&
+ (dir != DMA_MEM_TO_DEV)) {
+ dev_err(chan->device->dev, "bad direction\n");
+ return NULL;
+ }
+
+ /* Now allocate and setup the descriptor */
+ d = kzalloc(sizeof(*d), GFP_ATOMIC);
+ if (!d)
+ return NULL;
+
+ /* sglen is 1 */
+ d->avail_len = sg_dma_len(sgl);
+
+ return vchan_tx_prep(&c->vc, &d->vd, tx_flags);
+}
+
+static void mtk_uart_apdma_issue_pending(struct dma_chan *chan)
+{
+ struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
+ struct virt_dma_desc *vd;
+ unsigned long flags;
+
+ spin_lock_irqsave(&c->vc.lock, flags);
+ if (c->cfg.direction == DMA_DEV_TO_MEM) {
+ if (vchan_issue_pending(&c->vc) && !c->desc) {
+ vd = vchan_next_desc(&c->vc);
+ c->desc = to_mtk_uart_apdma_desc(&vd->tx);
+ mtk_uart_apdma_start_rx(c);
+ }
+ } else if (c->cfg.direction == DMA_MEM_TO_DEV) {
+ if (vchan_issue_pending(&c->vc) && !c->desc) {
+ vd = vchan_next_desc(&c->vc);
+ c->desc = to_mtk_uart_apdma_desc(&vd->tx);
+ mtk_uart_apdma_start_tx(c);
+ }
+ }
+ spin_unlock_irqrestore(&c->vc.lock, flags);
+}
+
+static int mtk_uart_apdma_slave_config(struct dma_chan *chan,
+ struct dma_slave_config *cfg)
+{
+ struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
+ struct mtk_uart_apdmadev *mtkd =
+ to_mtk_uart_apdma_dev(c->vc.chan.device);
+
+ c->cfg = *cfg;
+
+ if (cfg->direction == DMA_DEV_TO_MEM) {
+ unsigned int rx_len = cfg->src_addr_width * 1024;
+
+ mtk_uart_apdma_chan_write(c, VFF_ADDR, cfg->src_addr);
+ mtk_uart_apdma_chan_write(c, VFF_LEN, rx_len);
+ mtk_uart_apdma_chan_write(c, VFF_THRE, VFF_RX_THRE(rx_len));
+ mtk_uart_apdma_chan_write(c,
+ VFF_INT_EN, VFF_RX_INT_EN0_B
+ | VFF_RX_INT_EN1_B);
+ mtk_uart_apdma_chan_write(c, VFF_RPT, 0);
+ mtk_uart_apdma_chan_write(c,
+ VFF_INT_FLAG, VFF_RX_INT_FLAG_CLR_B);
+ mtk_uart_apdma_chan_write(c, VFF_EN, VFF_EN_B);
+ } else if (cfg->direction == DMA_MEM_TO_DEV) {
+ unsigned int tx_len = cfg->dst_addr_width * 1024;
+
+ mtk_uart_apdma_chan_write(c, VFF_ADDR, cfg->dst_addr);
+ mtk_uart_apdma_chan_write(c, VFF_LEN, tx_len);
+ mtk_uart_apdma_chan_write(c, VFF_THRE, VFF_TX_THRE(tx_len));
+ mtk_uart_apdma_chan_write(c, VFF_WPT, 0);
+ mtk_uart_apdma_chan_write(c,
+ VFF_INT_FLAG, VFF_TX_INT_FLAG_CLR_B);
+ mtk_uart_apdma_chan_write(c, VFF_EN, VFF_EN_B);
+ }
+
+ if (mtkd->support_33bits)
+ mtk_uart_apdma_chan_write(c, VFF_4G_SUPPORT, VFF_4G_SUPPORT_B);
+
+ if (mtk_uart_apdma_chan_read(c, VFF_EN) != VFF_EN_B) {
+ dev_err(chan->device->dev,
+ "config dma dir[%d] fail\n", cfg->direction);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int mtk_uart_apdma_terminate_all(struct dma_chan *chan)
+{
+ struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
+ unsigned long flags;
+ u32 status;
+ int ret;
+
+ spin_lock_irqsave(&c->vc.lock, flags);
+
+ mtk_uart_apdma_chan_write(c, VFF_FLUSH, VFF_FLUSH_CLR_B);
+ /* Wait for flush */
+ ret = readx_poll_timeout(readl,
+ c->base + VFF_FLUSH,
+ status,
+ (status & VFF_FLUSH_B) != VFF_FLUSH_B,
+ 10, 100);
+ if (ret)
+ dev_err(c->vc.chan.device->dev,
+ "dma stop: polling FLUSH fail, DEBUG=0x%x\n",
+ mtk_uart_apdma_chan_read(c, VFF_DEBUG_STATUS));
+
+ /*set stop as 1 -> wait until en is 0 -> set stop as 0*/
+ mtk_uart_apdma_chan_write(c, VFF_STOP, VFF_STOP_B);
+ ret = readx_poll_timeout(readl,
+ c->base + VFF_EN,
+ status, status == 0, 10, 100);
+ if (ret)
+ dev_err(c->vc.chan.device->dev,
+ "dma stop: polling VFF_EN fail, DEBUG=0x%x\n",
+ mtk_uart_apdma_chan_read(c, VFF_DEBUG_STATUS));
+
+ mtk_uart_apdma_chan_write(c, VFF_STOP, VFF_STOP_CLR_B);
+ mtk_uart_apdma_chan_write(c, VFF_INT_EN, VFF_INT_EN_CLR_B);
+
+ switch (c->cfg.direction) {
+ case DMA_DEV_TO_MEM:
+ mtk_uart_apdma_chan_write(c,
+ VFF_INT_FLAG, VFF_RX_INT_FLAG_CLR_B);
+ break;
+ case DMA_MEM_TO_DEV:
+ mtk_uart_apdma_chan_write(c,
+ VFF_INT_FLAG, VFF_TX_INT_FLAG_CLR_B);
+ break;
+ default:
+ break;
+ }
+
+ spin_unlock_irqrestore(&c->vc.lock, flags);
+
+ return 0;
+}
+
+static int mtk_uart_apdma_device_pause(struct dma_chan *chan)
+{
+ /* just for check caps pass */
+ return 0;
+}
+
+static int mtk_uart_apdma_device_resume(struct dma_chan *chan)
+{
+ /* just for check caps pass */
+ return 0;
+}
+
+static void mtk_uart_apdma_free(struct mtk_uart_apdmadev *mtkd)
+{
+ while (list_empty(&mtkd->ddev.channels) == 0) {
+ struct mtk_chan *c = list_first_entry(&mtkd->ddev.channels,
+ struct mtk_chan, vc.chan.device_node);
+
+ list_del(&c->vc.chan.device_node);
+ tasklet_kill(&c->vc.task);
+ }
+}
+
+static const struct of_device_id mtk_uart_apdma_match[] = {
+ { .compatible = "mediatek,mt6577-uart-dma", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mtk_uart_apdma_match);
+
+static int mtk_uart_apdma_probe(struct platform_device *pdev)
+{
+ struct mtk_uart_apdmadev *mtkd;
+ struct resource *res;
+ struct mtk_chan *c;
+ unsigned int i;
+ int rc;
+
+ mtkd = devm_kzalloc(&pdev->dev, sizeof(*mtkd), GFP_KERNEL);
+ if (!mtkd)
+ return -ENOMEM;
+
+ mtkd->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(mtkd->clk)) {
+ dev_err(&pdev->dev, "No clock specified\n");
+ rc = PTR_ERR(mtkd->clk);
+ goto err_no_dma;
+ }
+
+ if (of_property_read_bool(pdev->dev.of_node, "dma-33bits")) {
+ dev_info(&pdev->dev, "Support dma 33bits\n");
+ mtkd->support_33bits = true;
+ }
+
+ rc = dma_set_mask_and_coherent(&pdev->dev,
+ DMA_BIT_MASK(32 | mtkd->support_33bits));
+ if (rc)
+ goto err_no_dma;
+
+ dma_cap_set(DMA_SLAVE, mtkd->ddev.cap_mask);
+ mtkd->ddev.device_alloc_chan_resources =
+ mtk_uart_apdma_alloc_chan_resources;
+ mtkd->ddev.device_free_chan_resources =
+ mtk_uart_apdma_free_chan_resources;
+ mtkd->ddev.device_tx_status = mtk_uart_apdma_tx_status;
+ mtkd->ddev.device_issue_pending = mtk_uart_apdma_issue_pending;
+ mtkd->ddev.device_prep_slave_sg = mtk_uart_apdma_prep_slave_sg;
+ mtkd->ddev.device_config = mtk_uart_apdma_slave_config;
+ mtkd->ddev.device_pause = mtk_uart_apdma_device_pause;
+ mtkd->ddev.device_resume = mtk_uart_apdma_device_resume;
+ mtkd->ddev.device_terminate_all = mtk_uart_apdma_terminate_all;
+ mtkd->ddev.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE);
+ mtkd->ddev.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE);
+ mtkd->ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+ mtkd->ddev.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
+ mtkd->ddev.dev = &pdev->dev;
+ INIT_LIST_HEAD(&mtkd->ddev.channels);
+
+ for (i = 0; i < MTK_UART_APDMA_CHANNELS; i++) {
+ c = devm_kzalloc(mtkd->ddev.dev, sizeof(*c), GFP_KERNEL);
+ if (!c) {
+ rc = -ENODEV;
+ goto err_no_dma;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ if (!res) {
+ rc = -ENODEV;
+ goto err_no_dma;
+ }
+
+ c->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(c->base)) {
+ rc = PTR_ERR(c->base);
+ goto err_no_dma;
+ }
+ c->requested = false;
+ c->vc.desc_free = mtk_uart_apdma_desc_free;
+ vchan_init(&c->vc, &mtkd->ddev);
+
+ mtkd->dma_irq[i] = platform_get_irq(pdev, i);
+ if ((int)mtkd->dma_irq[i] < 0) {
+ dev_err(&pdev->dev, "failed to get IRQ[%d]\n", i);
+ rc = -EINVAL;
+ goto err_no_dma;
+ }
+ }
+
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_set_active(&pdev->dev);
+
+ rc = dma_async_device_register(&mtkd->ddev);
+ if (rc)
+ goto rpm_disable;
+
+ platform_set_drvdata(pdev, mtkd);
+
+ if (pdev->dev.of_node) {
+ /* Device-tree DMA controller registration */
+ rc = of_dma_controller_register(pdev->dev.of_node,
+ of_dma_xlate_by_chan_id,
+ mtkd);
+ if (rc)
+ goto dma_remove;
+ }
+
+ return rc;
+
+dma_remove:
+ dma_async_device_unregister(&mtkd->ddev);
+rpm_disable:
+ pm_runtime_disable(&pdev->dev);
+err_no_dma:
+ mtk_uart_apdma_free(mtkd);
+ return rc;
+}
+
+static int mtk_uart_apdma_remove(struct platform_device *pdev)
+{
+ struct mtk_uart_apdmadev *mtkd = platform_get_drvdata(pdev);
+
+ if (pdev->dev.of_node)
+ of_dma_controller_free(pdev->dev.of_node);
+
+ pm_runtime_disable(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
+
+ dma_async_device_unregister(&mtkd->ddev);
+ mtk_uart_apdma_free(mtkd);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int mtk_uart_apdma_suspend(struct device *dev)
+{
+ struct mtk_uart_apdmadev *mtkd = dev_get_drvdata(dev);
+
+ if (!pm_runtime_suspended(dev))
+ clk_disable_unprepare(mtkd->clk);
+
+ return 0;
+}
+
+static int mtk_uart_apdma_resume(struct device *dev)
+{
+ int ret;
+ struct mtk_uart_apdmadev *mtkd = dev_get_drvdata(dev);
+
+ if (!pm_runtime_suspended(dev)) {
+ ret = clk_prepare_enable(mtkd->clk);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+#ifdef CONFIG_PM
+static int mtk_uart_apdma_runtime_suspend(struct device *dev)
+{
+ struct mtk_uart_apdmadev *mtkd = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(mtkd->clk);
+
+ return 0;
+}
+
+static int mtk_uart_apdma_runtime_resume(struct device *dev)
+{
+ int ret;
+ struct mtk_uart_apdmadev *mtkd = dev_get_drvdata(dev);
+
+ ret = clk_prepare_enable(mtkd->clk);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+#endif /* CONFIG_PM */
+
+static const struct dev_pm_ops mtk_uart_apdma_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(mtk_uart_apdma_suspend, mtk_uart_apdma_resume)
+ SET_RUNTIME_PM_OPS(mtk_uart_apdma_runtime_suspend,
+ mtk_uart_apdma_runtime_resume, NULL)
+};
+
+static struct platform_driver mtk_uart_apdma_driver = {
+ .probe = mtk_uart_apdma_probe,
+ .remove = mtk_uart_apdma_remove,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .pm = &mtk_uart_apdma_pm_ops,
+ .of_match_table = of_match_ptr(mtk_uart_apdma_match),
+ },
+};
+
+module_platform_driver(mtk_uart_apdma_driver);
+
+MODULE_DESCRIPTION("MediaTek UART APDMA Controller Driver");
+MODULE_AUTHOR("Long Cheng <long.cheng@mediatek.com>");
+MODULE_LICENSE("GPL v2");
+
diff --git a/drivers/dma/mediatek/Kconfig b/drivers/dma/mediatek/Kconfig
index 27bac0b..2c082c9 100644
--- a/drivers/dma/mediatek/Kconfig
+++ b/drivers/dma/mediatek/Kconfig
@@ -1,4 +1,15 @@
+config DMA_MTK_UART
+ tristate "MediaTek SoCs APDMA support for UART"
+ depends on OF && SERIAL_8250_MT6577
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ help
+ Support for the UART DMA engine found on MediaTek MTK SoCs.
+ when SERIAL_8250_MT6577 is enabled, and if you want to using DMA,
+ you can enable the config. the DMA engine just only be used
+ with MediaTek SoCs.
+
config MTK_HSDMA
tristate "MediaTek High-Speed DMA controller support"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/dma/mediatek/Makefile b/drivers/dma/mediatek/Makefile
index 6e778f8..2f2efd9 100644
--- a/drivers/dma/mediatek/Makefile
+++ b/drivers/dma/mediatek/Makefile
@@ -1 +1,2 @@
+obj-$(CONFIG_DMA_MTK_UART) += 8250_mtk_dma.o
obj-$(CONFIG_MTK_HSDMA) += mtk-hsdma.o
--
1.7.9.5
^ permalink raw reply related
* [PATCH v6 0/2] add uart DMA function
From: Long Cheng @ 2018-12-19 2:20 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland, Ryder Lee
Cc: Matthias Brugger, Dan Williams, Greg Kroah-Hartman, Jiri Slaby,
Sean Wang, Sean Wang, dmaengine, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, linux-serial, srv_heupstream,
Yingjoe Chen, YT Shen, Long Cheng
In Mediatek SOCs, the uart can support DMA function.
Base on DMA engine formwork, we add the DMA code to support uart. And put the code under drivers/dma.
This series contains document bindings, Kconfig to control the function enable or not,
device tree including interrupt and dma device node, the code of UART DM
Changes compared to v5:
-move 'requst irqs' to alloc channel
-remove tasklet.
Changes compared to v4:
-modify Kconfig depends on.
Changes compared to v3:
-fix CONFIG_PM, will cause build fail
Changes compared to v2:
-remove unimportant parameters
-instead of cookie, use APIs of virtual channel.
-use of_dma_xlate_by_chan_id.
Changes compared to v1:
-mian revised file, 8250_mtk_dma.c
--parameters renamed for standard
--remove atomic operation
Long Cheng (2):
dmaengine: 8250_mtk_dma: add MediaTek uart DMA support
arm: dts: mt2712: add uart APDMA to device tree
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 50 +++
drivers/dma/mediatek/8250_mtk_dma.c | 694 +++++++++++++++++++++++++++++
drivers/dma/mediatek/Kconfig | 11 +
drivers/dma/mediatek/Makefile | 1 +
4 files changed, 756 insertions(+)
create mode 100644 drivers/dma/mediatek/8250_mtk_dma.c
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH] Revert "serial: 8250: Fix clearing FIFOs in RS485 mode again"
From: Marek Vasut @ 2018-12-19 0:12 UTC (permalink / raw)
To: Ezequiel Garcia, Paul Burton
Cc: linux-serial@vger.kernel.org, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, Paul Burton, Daniel Jedrychowski,
linux-mips@vger.kernel.org, stable, Ezequiel Garcia
In-Reply-To: <61a3177f-4e8d-fc51-1e81-95af3baab3a8@denx.de>
On 12/17/2018 06:20 PM, Marek Vasut wrote:
> On 12/17/2018 05:30 PM, Ezequiel Garcia wrote:
>> On Sun, 16 Dec 2018 at 19:35, Paul Burton <paul.burton@mips.com> wrote:
>>>
>>> Hi Ezequiel,
>>>
>>> On Sun, Dec 16, 2018 at 07:28:22PM -0300, Ezequiel Garcia wrote:
>>>> On Sun, 16 Dec 2018 at 19:24, Paul Burton <paul.burton@mips.com> wrote:
>>>>> This helps, but it only addresses one part of one of the 4 reasons I
>>>>> listed as motivation for my revert. For example serial8250_do_shutdown()
>>>>> also clearly intends to disable the FIFOs.
>>>>>
>>>>
>>>> OK. So, let's fix that :-)
>>>
>>> I already did, or at least tried to, on Thursday [1].
>>>
>>>> By all means, it would be really nice to push forward and fix the garbage
>>>> issue on JZ4780, as well as the transmission issue on AM335x.
>>>>
>>>> AM335x is a wildly popular platform, and it's not funny to break it.
>>>
>>> Well, clearly not if it was broken in v4.10 & only just fixed..? And
>>> from Marek's commit message the patch in v4.10 doesn't break the whole
>>> system just RS485.
>>>
>>
>> Careful here. It's naive to consider v4.10 as old in this context.
>>
>> AM335x is used in hundreds of thousands of products, probably
>> "industrial" products.
>> Manufacturers don't always follow the kernel, and it's entirely
>> likely that they notice a regression only when developing a new product,
>> or when rebasing on top of a newer longterm kernel.
>>
>> Then again, I don't have any details about what is Marek's original fix
>> actually fixing.
>>
>> Marek: could you please post the test case that you used to validate your fix?
>> I can't find that anywhere.
>
> I can't share the testcase itself because it has no license and I didn't
> write it, but I can tell you what it's doing. (I'll check if I can share
> the testcase verbatim too, I just sent an email to the author)
>
> The test spawns two threads, one sending , one receiving. The sending
> thread sends 8 bytes of data from /dev/ttyS4 , the receiving thread
> receives the data on /dev/ttyS2 and compares the pattern. The port
> settings is B1000000 8N1 with rs485conf.flags set to SER_RS485_ENABLED
> and SER_RS485_RTS_AFTER_SEND. Sometimes the received data do not match
> the sent data, but rather look as if one character was left over from
> the previous transmission in the FIFO.
>
> Those two UARTs are connected together by two wires, without any real
> RS485 hardware to minimize the hardware complexity (it's easy to
> implement that on the pocketbeagle, which is the cheap option here).
Test code is below . On the pocketbeagle, connect SPI0:CLK with U4:TX
and SPI0:MISO with U4:RX , apply the DT patch below and run the example.
It'll fail after a few iterations.
#include <errno.h>
#include <fcntl.h>
#include <string.h>
#include <termios.h>
#include <unistd.h>
#include <iostream>
#include <iomanip>
#include <atomic>
#include <thread>
#include <linux/serial.h>
#include <sys/ioctl.h>
std::atomic<bool> running{true};
int set_interface_attribs (int fd, int speed, int parity)
{
struct termios tty;
memset (&tty, 0, sizeof tty);
if (tcgetattr (fd, &tty) != 0)
{
std::cerr << "Error from tcgetattr" << std::endl;
return -1;
}
cfsetospeed (&tty, speed);
cfsetispeed (&tty, speed);
tty.c_cflag = (tty.c_cflag & ~CSIZE) | CS8;
tty.c_iflag &= ~IGNBRK;
tty.c_lflag = 0;
tty.c_oflag = 0;
tty.c_cc[VMIN] = 8;
tty.c_cc[VTIME] = 0;
tty.c_iflag &= ~(IXON | IXOFF | IXANY);
tty.c_cflag |= (CLOCAL | CREAD);
tty.c_cflag &= ~(PARENB | PARODD);
tty.c_cflag |= parity;
tty.c_cflag &= ~CSTOPB;
tty.c_cflag &= ~CRTSCTS;
if (tcsetattr (fd, TCSANOW, &tty) != 0)
{
std::cerr << "Error from tcsetattr" << std::endl;
return -1;
}
return 0;
}
void enable_rts(int fd, int rts)
{
struct serial_rs485 rs485conf;
if (rts) {
rs485conf.flags = SER_RS485_ENABLED ;
rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
rs485conf.flags &= ~(SER_RS485_RTS_ON_SEND);
rs485conf.delay_rts_before_send = 0;
rs485conf.delay_rts_after_send = 0;
} else {
rs485conf.flags = 0 ;
}
if (ioctl( fd, TIOCSRS485, &rs485conf) < 0){
std::cerr << "Cannot set device in RS485 mode" << std::endl;
}
}
void output_function(int fd)
{
while(running) {
write (fd, "asdfghjk", 8);
usleep (20000);
}
}
void input_function(int fd)
{
char buf [100];
size_t count=0;
std::cout << std::unitbuf;
while(running){
int n = read (fd, buf, sizeof buf);
if( (n >0) && (buf[0] != 'a') ){
std::cout << "\nunexpected receive! " << std::string(buf,8) <<
std::endl;
running = false;
} else {
++count;
if(count%100 == 0){
std::cout << "\r" << std::setw(8) << count << " possibly ok";
}
}
}
}
int main(int argc, char** argv)
{
std::string in_port = "/dev/ttyS2";
std::string out_port = "/dev/ttyS4";
int c, rts = 1;
while ((c = getopt (argc, argv, "i:o:r")) != -1)
{
switch (c)
{
case 'i':
in_port = std::string(optarg);
break;
case 'o':
out_port = std::string(optarg);
break;
case 'r':
rts = 0;
break;
case '?':
return 1;
default:
break;
}
}
std::cout << "opening output " << out_port << std::endl;
int outfd = open ( out_port.c_str(), O_RDWR | O_NOCTTY | O_SYNC);
if (outfd < 0)
{
std::cerr << "Could not open " << out_port << std::endl;
return 1;
}
std::cout << "opening input " << in_port << std::endl;
int infd = open ( in_port.c_str(), O_RDWR | O_NOCTTY | O_SYNC);
if (infd < 0)
{
std::cerr << "Could not open " << in_port << std::endl;
return 1;
}
set_interface_attribs (infd, B1000000, 0);
set_interface_attribs (outfd, B1000000, 0);
enable_rts(outfd, rts);
enable_rts(infd, rts);
std::thread in(input_function, infd);
std::thread out(output_function, outfd);
in.join();
out.join();
close(infd);
close(outfd);
}
diff --git a/arch/arm/boot/dts/am335x-pocketbeagle.dts
b/arch/arm/boot/dts/am335x-pocketbeagle.dts
index 62fe5cab9fae..d9b8f09920a6 100644
--- a/arch/arm/boot/dts/am335x-pocketbeagle.dts
+++ b/arch/arm/boot/dts/am335x-pocketbeagle.dts
@@ -92,15 +92,6 @@
>;
};
- spi0_pins: pinmux-spi0-pins {
- pinctrl-single,pins = <
- AM33XX_IOPAD(0x950, PIN_INPUT_PULLUP |
MUX_MODE0) /* (A17) spi0_sclk.spi0_sclk */
- AM33XX_IOPAD(0x954, PIN_INPUT_PULLUP |
MUX_MODE0) /* (B17) spi0_d0.spi0_d0 */
- AM33XX_IOPAD(0x958, PIN_INPUT_PULLUP |
MUX_MODE0) /* (B16) spi0_d1.spi0_d1 */
- AM33XX_IOPAD(0x95c, PIN_INPUT_PULLUP |
MUX_MODE0) /* (A16) spi0_cs0.spi0_cs0 */
- >;
- };
-
spi1_pins: pinmux-spi1-pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x964, PIN_INPUT_PULLUP |
MUX_MODE4) /* (C18) eCAP0_in_PWM0_out.spi1_sclk */
@@ -126,6 +117,13 @@
>;
};
+ uart2_pins: pinmux-uart2-pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x950, PIN_INPUT | MUX_MODE1)
/* spi0_sclk.uart2_rxd */
+ AM33XX_IOPAD(0x954, PIN_OUTPUT | MUX_MODE1)
/* spi0_d0.uart2_txd */
+ >;
+ };
+
uart4_pins: pinmux-uart4-pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x870, PIN_INPUT_PULLUP |
MUX_MODE6) /* (T17) gpmc_wait0.uart4_rxd */
@@ -199,6 +197,13 @@
status = "okay";
};
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+
+ status = "okay";
+};
+
&uart4 {
pinctrl-names = "default";
pinctrl-0 = <&uart4_pins>;
--
Best regards,
Marek Vasut
^ permalink raw reply related
* Re: [PATCH v2] dt-bindings: serial: sh-sci: Document r8a774c0 bindings
From: Rob Herring @ 2018-12-18 17:48 UTC (permalink / raw)
Cc: Geert Uytterhoeven, Simon Horman, Greg Kroah-Hartman,
Mark Rutland, Fabrizio Castro, linux-serial, devicetree,
linux-kernel, Chris Paterson, Biju Das, linux-renesas-soc
In-Reply-To: <1545134590-22510-1-git-send-email-fabrizio.castro@bp.renesas.com>
On Tue, 18 Dec 2018 12:03:10 +0000, Fabrizio Castro wrote:
> RZ/G2E (R8A774C0) SoC also has the R-Car Gen3 compatible SCIF and
> HSCIF ports, so document the SoC specific bindings.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> v1->v2:
> * Fixed title according to Geert's comment
>
> This patch depends on:
> https://patchwork.kernel.org/patch/10565543/
>
> Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox