* [PATCH v4 0/2] add uart DMA function
From: Long Cheng @ 2018-12-10 2:57 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland
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 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: mt2701: add uart APDMA to device tree
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 50 ++
drivers/dma/mediatek/8250_mtk_dma.c | 830 +++++++++++++++++++++++++++++
drivers/dma/mediatek/Kconfig | 11 +
drivers/dma/mediatek/Makefile | 1 +
4 files changed, 892 insertions(+)
create mode 100644 drivers/dma/mediatek/8250_mtk_dma.c
--
1.7.9.5
^ permalink raw reply
* [PATCH v3 2/2] serial: 8250: Rate limit serial port rx interrupts during input overruns
From: Darwin Dingel @ 2018-12-09 22:29 UTC (permalink / raw)
To: gregkh, jslaby, andriy.shevchenko, robh
Cc: chris.packham, linux-serial, linux-kernel, Darwin Dingel
When a serial port gets faulty or gets flooded with inputs, its interrupt
handler starts to work double time to get the characters to the workqueue
for the tty layer to handle them. When this busy time on the serial/tty
subsystem happens during boot, where it is also busy on the userspace
trying to initialise, some processes can continuously get preempted
and will be on hold until the interrupts subside.
The fix is to backoff on processing received characters for a specified
amount of time when an input overrun is seen (received a new character
before the previous one is processed). This only stops receive and will
continue to transmit characters to serial port. After the backoff period
is done, it receive will be re-enabled. This is optional and will only
be enabled by setting 'overrun-throttle-ms' in the dts.
Signed-off-by: Darwin Dingel <darwin.dingel@alliedtelesis.co.nz>
---
Notes:
Changelog
v1->v2:
- Separated dts binding to another patch
v2->v3:
- Fixed commit message and reviewed-by fields
drivers/tty/serial/8250/8250_core.c | 25 +++++++++++++++++++++++++
drivers/tty/serial/8250/8250_fsl.c | 23 ++++++++++++++++++++++-
drivers/tty/serial/8250/8250_of.c | 5 +++++
include/linux/serial_8250.h | 4 ++++
4 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index 94f3e1c64490..189ab1212d9a 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -942,6 +942,21 @@ static struct uart_8250_port *serial8250_find_match_or_unused(struct uart_port *
return NULL;
}
+static void serial_8250_overrun_backoff_work(struct work_struct *work)
+{
+ struct uart_8250_port *up =
+ container_of(to_delayed_work(work), struct uart_8250_port,
+ overrun_backoff);
+ struct uart_port *port = &up->port;
+ unsigned long flags;
+
+ spin_lock_irqsave(&port->lock, flags);
+ up->ier |= UART_IER_RLSI | UART_IER_RDI;
+ up->port.read_status_mask |= UART_LSR_DR;
+ serial_out(up, UART_IER, up->ier);
+ spin_unlock_irqrestore(&port->lock, flags);
+}
+
/**
* serial8250_register_8250_port - register a serial port
* @up: serial port template
@@ -1056,6 +1071,16 @@ int serial8250_register_8250_port(struct uart_8250_port *up)
ret = 0;
}
}
+
+ /* Initialise interrupt backoff work if required */
+ if (up->overrun_backoff_time_ms > 0) {
+ uart->overrun_backoff_time_ms = up->overrun_backoff_time_ms;
+ INIT_DELAYED_WORK(&uart->overrun_backoff,
+ serial_8250_overrun_backoff_work);
+ } else {
+ uart->overrun_backoff_time_ms = 0;
+ }
+
mutex_unlock(&serial_mutex);
return ret;
diff --git a/drivers/tty/serial/8250/8250_fsl.c b/drivers/tty/serial/8250/8250_fsl.c
index 6640a4c7ddd1..bb9571eed275 100644
--- a/drivers/tty/serial/8250/8250_fsl.c
+++ b/drivers/tty/serial/8250/8250_fsl.c
@@ -45,8 +45,29 @@ int fsl8250_handle_irq(struct uart_port *port)
lsr = orig_lsr = up->port.serial_in(&up->port, UART_LSR);
- if (lsr & (UART_LSR_DR | UART_LSR_BI))
+ /* Process incoming characters first */
+ if ((lsr & (UART_LSR_DR | UART_LSR_BI)) &&
+ (up->ier & (UART_IER_RLSI | UART_IER_RDI))) {
lsr = serial8250_rx_chars(up, lsr);
+ }
+
+ /* Stop processing interrupts on input overrun */
+ if ((orig_lsr & UART_LSR_OE) && (up->overrun_backoff_time_ms > 0)) {
+ unsigned long delay;
+
+ up->ier = port->serial_in(port, UART_IER);
+ if (up->ier & (UART_IER_RLSI | UART_IER_RDI)) {
+ port->ops->stop_rx(port);
+ } else {
+ /* Keep restarting the timer until
+ * the input overrun subsides.
+ */
+ cancel_delayed_work(&up->overrun_backoff);
+ }
+
+ delay = msecs_to_jiffies(up->overrun_backoff_time_ms);
+ schedule_delayed_work(&up->overrun_backoff, delay);
+ }
serial8250_modem_status(up);
diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
index 877fd7f8a8ed..a1a85805d010 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -240,6 +240,11 @@ static int of_platform_serial_probe(struct platform_device *ofdev)
if (of_property_read_bool(ofdev->dev.of_node, "auto-flow-control"))
port8250.capabilities |= UART_CAP_AFE;
+ if (of_property_read_u32(ofdev->dev.of_node,
+ "overrun-throttle-ms",
+ &port8250.overrun_backoff_time_ms) != 0)
+ port8250.overrun_backoff_time_ms = 0;
+
ret = serial8250_register_8250_port(&port8250);
if (ret < 0)
goto err_dispose;
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index 18e21427bce4..5a655ba8d273 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -134,6 +134,10 @@ struct uart_8250_port {
void (*dl_write)(struct uart_8250_port *, int);
struct uart_8250_em485 *em485;
+
+ /* Serial port overrun backoff */
+ struct delayed_work overrun_backoff;
+ u32 overrun_backoff_time_ms;
};
static inline struct uart_8250_port *up_to_u8250p(struct uart_port *up)
--
2.19.2
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: serial: 8250: Add rate limit for serial port input overruns
From: Darwin Dingel @ 2018-12-09 22:27 UTC (permalink / raw)
To: gregkh, robh+dt
Cc: chris.packham, linux-serial, devicetree, linux-kernel,
Darwin Dingel
When a serial port continuously experiences input overrun from
(1) continuous receive characters from remote and or (2) hardware
issues, its interrupt handler can preempt other tasks especially
when the system is busy (ie. boot up period). This can cause other
tasks to get starved of processing time from the CPU.
When this dts binding is enabled and input overrun on the serial port
is detected, serial port receive will be throttled to give some breathing
room for processing other tasks. Value provided will be in milliseconds.
&serial0{
overrun-throttle-ms = <500>;
};
Signed-off-by: Darwin Dingel <darwin.dingel@alliedtelesis.co.nz>
---
Notes:
Changelog
v1->v2:
- Separated dts binding to another patch
v2->v3:
- Fixed commit message and reviewed-by fields
Documentation/devicetree/bindings/serial/8250.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index aeb6db4e35c3..da50321da34d 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -51,6 +51,7 @@ Optional properties:
- tx-threshold: Specify the TX FIFO low water indication for parts with
programmable TX FIFO thresholds.
- resets : phandle + reset specifier pairs
+- overrun-throttle-ms : how long to pause uart rx when input overrun is encountered.
Note:
* fsl,ns16550:
--
2.19.2
^ permalink raw reply related
* Re: [GIT PULL] TTY/Serial fixes for 4.20-rc6
From: pr-tracker-bot @ 2018-12-09 18:50 UTC (permalink / raw)
To: Greg KH
Cc: Linus Torvalds, Jiri Slaby, Stephen Rothwell, Andrew Morton,
linux-kernel, linux-serial
In-Reply-To: <20181209111717.GA9735@kroah.com>
The pull request you sent on Sun, 9 Dec 2018 12:17:17 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-4.20-rc6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/822b7683fff11f152e74c404b3d915f6e5b13698
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-rc6
From: Greg KH @ 2018-12-09 11:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jiri Slaby, Stephen Rothwell, Andrew Morton, linux-kernel,
linux-serial
The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad:
Linux 4.20-rc2 (2018-11-11 17:12:31 -0600)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-4.20-rc6
for you to fetch changes up to dada6a43b0402eba438a17ac86fdc64ac56a4607:
kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var() (2018-12-06 15:59:07 +0100)
----------------------------------------------------------------
TTY driver fixes for 4.20-rc6
Here are three small tty driver fixes for 4.20-rc6
Nothing major, just some bug fixes for reported issues. Full details
are in the shortlog.
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Chanho Park (1):
tty: do not set TTY_IO_ERROR flag if console port
Macpaul Lin (1):
kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var()
Peter Shih (1):
tty: serial: 8250_mtk: always resume the device in probe.
drivers/tty/serial/8250/8250_mtk.c | 16 +++++++---------
drivers/tty/serial/kgdboc.c | 4 ++--
drivers/tty/tty_port.c | 3 ++-
3 files changed, 11 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 1/2] dmaengine: 8250_mtk_dma: add Mediatek uart DMA support
From: kbuild test robot @ 2018-12-09 5:07 UTC (permalink / raw)
Cc: kbuild-all, Vinod Koul, Rob Herring, Mark Rutland,
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: <1544168842-13860-2-git-send-email-long.cheng@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 2530 bytes --]
Hi Long,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc5 next-20181207]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Long-Cheng/add-uart-DMA-function/20181208-201933
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sh
All errors (new ones prefixed by >>):
In file included from include/linux/device.h:23:0,
from include/linux/dmaengine.h:20,
from drivers/dma/mediatek/8250_mtk_dma.c:10:
>> drivers/dma/mediatek/8250_mtk_dma.c:828:21: error: 'mtk_dma_runtime_suspend' undeclared here (not in a function); did you mean '__pm_runtime_suspend'?
SET_RUNTIME_PM_OPS(mtk_dma_runtime_suspend,
^
include/linux/pm.h:354:21: note: in definition of macro 'SET_RUNTIME_PM_OPS'
.runtime_suspend = suspend_fn, \
^~~~~~~~~~
>> drivers/dma/mediatek/8250_mtk_dma.c:829:7: error: 'mtk_dma_runtime_resume' undeclared here (not in a function); did you mean 'mtk_dma_device_resume'?
mtk_dma_runtime_resume, NULL)
^
include/linux/pm.h:355:20: note: in definition of macro 'SET_RUNTIME_PM_OPS'
.runtime_resume = resume_fn, \
^~~~~~~~~
drivers/dma/mediatek/8250_mtk_dma.c:164:13: warning: 'mtk_dma_clk_disable' defined but not used [-Wunused-function]
static void mtk_dma_clk_disable(struct mtk_dmadev *mtkd)
^~~~~~~~~~~~~~~~~~~
drivers/dma/mediatek/8250_mtk_dma.c:151:12: warning: 'mtk_dma_clk_enable' defined but not used [-Wunused-function]
static int mtk_dma_clk_enable(struct mtk_dmadev *mtkd)
^~~~~~~~~~~~~~~~~~
vim +828 drivers/dma/mediatek/8250_mtk_dma.c
825
826 static const struct dev_pm_ops mtk_dma_pm_ops = {
827 SET_SYSTEM_SLEEP_PM_OPS(mtk_dma_suspend, mtk_dma_resume)
> 828 SET_RUNTIME_PM_OPS(mtk_dma_runtime_suspend,
> 829 mtk_dma_runtime_resume, NULL)
830 };
831
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 50415 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/10] mailbox: Support blocking transfers in atomic context
From: Jassi Brar @ 2018-12-09 1:20 UTC (permalink / raw)
To: Greg KH
Cc: Devicetree List, Mikko Perttunen, mliljeberg, Mikko Perttunen,
talho, Thierry Reding, linux-serial, jslaby, linux-tegra, ppessi,
Jon Hunter, linux-arm-kernel
In-Reply-To: <20181208085016.GA20795@kroah.com>
On Sat, Dec 8, 2018 at 2:50 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Sat, Dec 08, 2018 at 11:21:41AM +0530, Jassi Brar wrote:
> > On Fri, Dec 7, 2018 at 11:50 AM Mikko Perttunen <cyndis@kapsi.fi> wrote:
> > >
> > > On 07/12/2018 11.26, Jassi Brar wrote:
> > > >> I thought that I could also mitigate 2) by busy looping in the TCU driver,
> > > >> but it turns out that that doesn't work. The reason is that since we are
> > > >> in atomic context with all interrupts disabled, the mailbox won't ever
> > > >> consume any new characters, so the read pointer in the circular buffer
> > > >> won't increment, leaving me with no condition upon which to loop that
> > > >> would work.
> > > >>
> > > > So you want to be able to rely on an emulated console (running on a
> > > > totally different subsystem) to dump development-phase early-boot
> > > > logs? At the cost of legitimizing busy looping in atomic context - one
> > > > random driver messing up the api for ever. Maybe you could have the
> > > > ring buffer in some shmem and only pass the number of valid characters
> > > > in it, to the remote?
> > > >
> > >
> > > I would like to note that this is the one and only console interface
> > > that exists on these systems, for both development phase and production.
> > > Other UARTs are not externally accessible on the systems, or they are
> > > comparatively difficult to access as they aren't intended to be used as
> > > consoles in the system design.
> >
> > > The combination of hardware and firmware
> > > implementing the console is black box from software's point of view
> > > (similarly to any other UART HW). The interface has also been fixed at
> > > an early system design phase, as there are many operating systems
> > > running on these boards, each with their own drivers.
> > >
> > That is the saddest part - someone, who writes test cases for the h/w
> > team and with almost no knowledge of how OSes work, decides how the
> > firmware is going to work and calls it done. Then the Linux is left to
> > deal with the mess as we "can't do anything about it".
>
> That is totally normal, and is how hardware has been almost _always_
> been designed and implemented. Nothing new here at all, it's just the
> life us kernel developers get used to very quickly as it is our job to
> make that hardware work and appear to userspace as something sane and
> universal.
>
Hardware yes, we can't really change much after the fact.
In this case the issue arises from the firmware - TCU's mailbox
protocol implementation. Which usually is just another image loaded
onto the remote master during cold-boot, and should actually be not
that hard to fix/change. Even if other OSes (really?) have adapted, a
pushback right now will help fix atleast the next version, otherwise
the api designer will never know what s/he is doing wrong.
Anyways, thanks for chiming in. I will pull the patchset.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 01/10] mailbox: Support blocking transfers in atomic context
From: Greg KH @ 2018-12-08 8:50 UTC (permalink / raw)
To: Jassi Brar
Cc: Devicetree List, Mikko Perttunen, mliljeberg, Mikko Perttunen,
talho, Thierry Reding, linux-serial, jslaby, linux-tegra, ppessi,
Jon Hunter, linux-arm-kernel
In-Reply-To: <CABb+yY3_uWv1YVxXxjgygPemBZraCTAXNyXT9G4aTMZv1t7d0g@mail.gmail.com>
On Sat, Dec 08, 2018 at 11:21:41AM +0530, Jassi Brar wrote:
> On Fri, Dec 7, 2018 at 11:50 AM Mikko Perttunen <cyndis@kapsi.fi> wrote:
> >
> > On 07/12/2018 11.26, Jassi Brar wrote:
> > >> I thought that I could also mitigate 2) by busy looping in the TCU driver,
> > >> but it turns out that that doesn't work. The reason is that since we are
> > >> in atomic context with all interrupts disabled, the mailbox won't ever
> > >> consume any new characters, so the read pointer in the circular buffer
> > >> won't increment, leaving me with no condition upon which to loop that
> > >> would work.
> > >>
> > > So you want to be able to rely on an emulated console (running on a
> > > totally different subsystem) to dump development-phase early-boot
> > > logs? At the cost of legitimizing busy looping in atomic context - one
> > > random driver messing up the api for ever. Maybe you could have the
> > > ring buffer in some shmem and only pass the number of valid characters
> > > in it, to the remote?
> > >
> >
> > I would like to note that this is the one and only console interface
> > that exists on these systems, for both development phase and production.
> > Other UARTs are not externally accessible on the systems, or they are
> > comparatively difficult to access as they aren't intended to be used as
> > consoles in the system design.
>
> > The combination of hardware and firmware
> > implementing the console is black box from software's point of view
> > (similarly to any other UART HW). The interface has also been fixed at
> > an early system design phase, as there are many operating systems
> > running on these boards, each with their own drivers.
> >
> That is the saddest part - someone, who writes test cases for the h/w
> team and with almost no knowledge of how OSes work, decides how the
> firmware is going to work and calls it done. Then the Linux is left to
> deal with the mess as we "can't do anything about it".
That is totally normal, and is how hardware has been almost _always_
been designed and implemented. Nothing new here at all, it's just the
life us kernel developers get used to very quickly as it is our job to
make that hardware work and appear to userspace as something sane and
universal.
Sorry,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 01/10] mailbox: Support blocking transfers in atomic context
From: Jassi Brar @ 2018-12-08 6:09 UTC (permalink / raw)
To: Thierry Reding
Cc: Devicetree List, Greg KH, mliljeberg, Mikko Perttunen, talho,
linux-serial, jslaby, linux-tegra, ppessi, Jon Hunter,
linux-arm-kernel
In-Reply-To: <20181207113245.GA30719@ulmo>
On Fri, Dec 7, 2018 at 5:02 PM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Thu, Dec 06, 2018 at 11:56:25PM -0600, Jassi Brar wrote:
> > On Thu, Nov 29, 2018 at 9:23 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > >
> > > On Wed, Nov 28, 2018 at 11:23:36PM -0600, Jassi Brar wrote:
> > > > On Wed, Nov 28, 2018 at 3:43 AM Jon Hunter <jonathanh@nvidia.com> wrote:
> > > > >
> > > > >
> > > > > On 12/11/2018 15:18, Thierry Reding wrote:
> > > > > > From: Thierry Reding <treding@nvidia.com>
> > > > > >
> > > > > > The mailbox framework supports blocking transfers via completions for
> > > > > > clients that can sleep. In order to support blocking transfers in cases
> > > > > > where the transmission is not permitted to sleep, add a new ->flush()
> > > > > > callback that controller drivers can implement to busy loop until the
> > > > > > transmission has been completed. This will automatically be called when
> > > > > > available and interrupts are disabled for clients that request blocking
> > > > > > transfers.
> > > > > >
> > > > > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > > > > ---
> > > > > > drivers/mailbox/mailbox.c | 8 ++++++++
> > > > > > include/linux/mailbox_controller.h | 4 ++++
> > > > > > 2 files changed, 12 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
> > > > > > index 674b35f402f5..0eaf21259874 100644
> > > > > > --- a/drivers/mailbox/mailbox.c
> > > > > > +++ b/drivers/mailbox/mailbox.c
> > > > > > @@ -267,6 +267,14 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
> > > > > > unsigned long wait;
> > > > > > int ret;
> > > > > >
> > > > > > + if (irqs_disabled() && chan->mbox->ops->flush) {
> > > > > > + ret = chan->mbox->ops->flush(chan, chan->cl->tx_tout);
> > > > > > + if (ret < 0)
> > > > > > + tx_tick(chan, ret);
> > > > > > +
> > > > > > + return ret;
> > > > > > + }
> > > > >
> > > > > It seems to me that if mbox_send_message() is called from an atomic
> > > > > context AND tx_block is true, then if 'flush' is not populated this
> > > > > should be an error condition as we do not wish to call
> > > > > wait_for_completion from an atomic context.
> > > > >
> > > > > I understand that there is some debate about adding such flush support,
> > > > > but irrespective of the above change, it seems to me that if the
> > > > > mbox_send_message() can be called from an atomic context (which it
> > > > > appears to), then it should be detecting if someone is trying to do so
> > > > > with 'tx_block' set as this should be an error.
> > > > >
> > > > Layers within kernel space have to trust each other. A badly written
> > > > client can break the consumer in so many ways, we can not catch every
> > > > possibility.
> > > >
> > > > > Furthermore, if the underlying mailbox driver can support sending a
> > > > > message from an atomic context and busy wait until it is done, surely
> > > > > the mailbox framework should provide a means to support this?
> > > > >
> > > > Being able to put the message on bus in atomic context is a feature -
> > > > which we do support. But busy-waiting in a loop is not a feature, and
> > > > we don't want to encourage that.
> > >
> > > I agree that in generally busy-waiting is a bad idea and shouldn't be
> > > encouraged. However, I also think that an exception proves the rule. If
> > > you look at the console drivers in drivers/tty/serial, all of them will
> > > busy loop prior to or after sending a character. This is pretty much
> > > part of the API and as such busy-looping is very much a feature.
> > >
> > > The reason why this is done is because on one hand we have an atomic
> > > context and on the other hand we want to make sure that all characters
> > > actually make it to the console when we print them.
> > >
> > > As an example how this can break, I've taken your suggestion to
> > > implement a producer/consumer mode in the TCU driver where the console
> > > write function will just stash characters into a circular buffer and a
> > > work queue will then use mbox_send_message() to drain the circular
> > > buffer. While this does work on the surface, I was able to concern both
> > > of the issues that I was concerned about: 1) it is easy to overflow the
> > > circular buffer by just dumping enough data at once to the console and
> > > 2) when a crash happens, everything in the kernel stops, including the
> > > consumer workqueue that is supposed to drain the circular buffer and
> > > flush messages to the TCU. The result is that, in my particular case,
> > > the boot log will just stop at a random place in the middle of messages
> > > from much earlier in the boot because the TCU hasn't caught up yet and
> > > there's a lot of characters still in the circular buffer.
> > >
> > > Now, 1) can be mitigated by increasing the circular buffer size. A value
> > > that seems to give reliably good results in 2 << CONFIG_LOG_BUF_SHIFT.
> > >
> > Yes please.
>
> As I explained elsewhere, I actually went and implemented this. But
> given the nature of buffering, this ends up making the TCU completely
> useless as a console because in case of a crash, the system will stop
> working with a large number of characters still stuck in the buffer.
> And that's especially bad in case of a crash because those last
> characters that get stuck in the buffer are the most relevant ones
> because they contain the stack dump.
>
I don't question the utility of TCU. I just wonder if mailbox api
should provide a backdoor for atomic busy-wait in order to support a
sub-optimal hw+fw design.
> > > I thought that I could also mitigate 2) by busy looping in the TCU driver,
> > > but it turns out that that doesn't work. The reason is that since we are
> > > in atomic context with all interrupts disabled, the mailbox won't ever
> > > consume any new characters, so the read pointer in the circular buffer
> > > won't increment, leaving me with no condition upon which to loop that
> > > would work.
> > >
> > So you want to be able to rely on an emulated console (running on a
> > totally different subsystem) to dump development-phase early-boot
> > logs? At the cost of legitimizing busy looping in atomic context - one
> > random driver messing up the api for ever. Maybe you could have the
> > ring buffer in some shmem and only pass the number of valid characters
> > in it, to the remote?
>
> First of all, this is not about development-phase early-boot messages.
> We're talking about the system console here. This is what everyone will
> want to be using when developing on this device. Sure at some point you
> may end up with a system that works and you can have the console on the
> network or an attached display or whatever, but even then you may still
> want to attach to the console if you ever run into issues where the
> system doesn't come up.
>
> Secondly, I don't understand why you think this is an emulated console.
>
It is emulated/virtual because Linux doesn't put characters on a
physical bus. The data is simply handed forward to a remote entity.
> Lastly, I don't understand why you think we're messing up the API here.
> The proposal in this series doesn't even change any of the API, but it
> makes it aware of the state of interrupts internally so that it can do
> the right thing depending on the call stack. The other proposal, in v3,
> is more explicit in that it adds new API to flush the mailbox. The new
> API is completely optional and I even offered to document it as being
> discouraged because it involves busy looping. At the same time it does
> solve a real problem and it doesn't impact any existing mailbox drivers
> nor any of their users (because it is completely opt-in).
>
The 'flush' api is going to have no use other than implement
busy-waits. I am afraid people are simply going to take it easy and
copy the busy-waits from the test/verification codes.
"discouraging" seldom works because the developer comes with the
failproof excuse "the h/w doesn't provide any other way". Frankly I
would like to push back on such designs.
Anyways, let us add the new 'flush' api.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 01/10] mailbox: Support blocking transfers in atomic context
From: Jassi Brar @ 2018-12-08 5:51 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Devicetree List, Greg KH, mliljeberg, Mikko Perttunen, talho,
Thierry Reding, linux-serial, jslaby, linux-tegra, ppessi,
Jon Hunter, linux-arm-kernel
In-Reply-To: <4f7a4211-47ee-1114-0974-a3b402178106@kapsi.fi>
On Fri, Dec 7, 2018 at 11:50 AM Mikko Perttunen <cyndis@kapsi.fi> wrote:
>
> On 07/12/2018 11.26, Jassi Brar wrote:
> >> I thought that I could also mitigate 2) by busy looping in the TCU driver,
> >> but it turns out that that doesn't work. The reason is that since we are
> >> in atomic context with all interrupts disabled, the mailbox won't ever
> >> consume any new characters, so the read pointer in the circular buffer
> >> won't increment, leaving me with no condition upon which to loop that
> >> would work.
> >>
> > So you want to be able to rely on an emulated console (running on a
> > totally different subsystem) to dump development-phase early-boot
> > logs? At the cost of legitimizing busy looping in atomic context - one
> > random driver messing up the api for ever. Maybe you could have the
> > ring buffer in some shmem and only pass the number of valid characters
> > in it, to the remote?
> >
>
> I would like to note that this is the one and only console interface
> that exists on these systems, for both development phase and production.
> Other UARTs are not externally accessible on the systems, or they are
> comparatively difficult to access as they aren't intended to be used as
> consoles in the system design.
> The combination of hardware and firmware
> implementing the console is black box from software's point of view
> (similarly to any other UART HW). The interface has also been fixed at
> an early system design phase, as there are many operating systems
> running on these boards, each with their own drivers.
>
That is the saddest part - someone, who writes test cases for the h/w
team and with almost no knowledge of how OSes work, decides how the
firmware is going to work and calls it done. Then the Linux is left to
deal with the mess as we "can't do anything about it".
^ permalink raw reply
* Re: [RFC][PATCHv2 3/4] serial: introduce uart_port locking helpers
From: Sergey Senozhatsky @ 2018-12-08 3:12 UTC (permalink / raw)
To: Petr Mladek, Steven Rostedt, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-kernel, Daniel Wang, Peter Zijlstra, Andrew Morton,
Linus Torvalds, Alan Cox, Peter Feiner, linux-serial,
Sergey Senozhatsky, Sergey Senozhatsky
In-Reply-To: <20181016050428.17966-4-sergey.senozhatsky@gmail.com>
On (10/16/18 14:04), Sergey Senozhatsky wrote:
[..]
> - The first entry point is console ->write() callback, which we call
> from printk(). A possible deadlock scenario there is:
>
> CPU0
> <NMI>
> spin_lock_irqsave(&port->lock, flags) << deadlock
> serial_foo_write()
> call_console_drivers()
> console_unlock()
> console_flush_on_panic()
> panic()
> <NMI/>
> spin_lock_irqsave(&port->lock, flags)
> serial_foo_write()
> call_console_drivers()
> console_unlock()
> printk()
> ...
[..]
> - The rest (of entry points) requires a bit different handling.
> Let's take a look at the following backtrace:
>
> CPU0
> <IRQ>
> spin_lock_irqsave(&port->lock, flags) << deadlock
> serial_foo_write()
> call_console_drivers()
> console_unlock()
> printk()
> __queue_work()
> tty_flip_buffer_push()
> spin_lock_irqsave(&port->lock, flags)
> serial_foo_handle_IRQ()
> <IRQ/>
>
> Serial drivers invoke tons of core kernel functions - WQ, MM, etc. All
> of which may printk() in various cases. So we can't really just
> "remove those printk-s". The simples way to address this seems to be
> PRINTK_SAFE_CONTEXT_MASK.
serial/UART and printk guys, sorry to bother you, do you hate this
idea of removing console_driver->CORE KERNEL->printk->console_driver
deadlock path? Or is there any chance we can move forward?
-ss
^ permalink raw reply
* Re: [PATCH v3 12/15] dt-bindings: serial: Document RDA Micro UART
From: Rob Herring @ 2018-12-07 23:41 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: olof, arnd, tglx, jason, marc.zyngier, daniel.lezcano, gregkh,
jslaby, afaerber, linux-arm-kernel, linux-kernel, devicetree,
linux-serial, amit.kucheria, linus.walleij, zhao_steven,
overseas.sales
In-Reply-To: <20181128135106.9255-13-manivannan.sadhasivam@linaro.org>
On Wed, Nov 28, 2018 at 07:21:03PM +0530, Manivannan Sadhasivam wrote:
> From: Andreas Färber <afaerber@suse.de>
>
> Add an initial binding for the UART in RDA Micro RDA8810PL SoC.
>
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../bindings/serial/rda,8810pl-uart.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt
>
> diff --git a/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt b/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt
> new file mode 100644
> index 000000000000..ee03116d7415
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt
> @@ -0,0 +1,15 @@
> +RDA Micro UART
> +
> +Required properties:
> +- compatible : "rda,8810pl-uart" for RDA8810PL SoCs.
> +- reg : Offset and length of the register set for the device.
> +- interrupts : Should contain UART interrupt.
Uarts generally need a clock.
> +
> +
> +Example:
> +
> + uart2: serial@20a90000 {
> + compatible = "rda,8810pl-uart";
> + reg = <0x20a90000 0x1000>;
> + interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
> + };
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v3 09/15] dt-bindings: timer: Document RDA8810PL SoC timer
From: Rob Herring @ 2018-12-07 23:39 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: olof, arnd, tglx, jason, marc.zyngier, daniel.lezcano, gregkh,
jslaby, afaerber, linux-arm-kernel, linux-kernel, devicetree,
linux-serial, amit.kucheria, linus.walleij, zhao_steven,
overseas.sales
In-Reply-To: <20181128135106.9255-10-manivannan.sadhasivam@linaro.org>
On Wed, Nov 28, 2018 at 07:21:00PM +0530, Manivannan Sadhasivam wrote:
> Document RDA Micro RDA8810PL SoC timer.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../bindings/timer/rda,8810pl-timer.txt | 21 +++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/timer/rda,8810pl-timer.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/rda,8810pl-timer.txt b/Documentation/devicetree/bindings/timer/rda,8810pl-timer.txt
> new file mode 100644
> index 000000000000..06cc2b00be12
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/rda,8810pl-timer.txt
> @@ -0,0 +1,21 @@
> +RDA Micro RDA8810PL Timer
> +
> +Required properties:
> +- compatible : "rda,8810pl-timer"
> +- reg : Offset and length of the register set for the device.
> +- interrupts : Should contain the interrupts.
How many?
> +- interrupt-names : Valid names are: "hwtimer", "ostimer".
It's more than just valid names, but rather must be those 2 strings.
> + See ../resource-names.txt
> +
> +Example:
> +
> + apb@20900000 {
> + compatible = "simple-bus";
> + ...
> + timer@10000 {
> + compatible = "rda,8810pl-timer";
> + reg = <0x10000 0x1000>;
> + interrupts = <16 IRQ_TYPE_LEVEL_HIGH>,
> + <17 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "hwtimer", "ostimer";
> + };
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v3 04/15] dt-bindings: interrupt-controller: Document RDA8810PL intc
From: Rob Herring @ 2018-12-07 23:38 UTC (permalink / raw)
Cc: olof, arnd, robh+dt, tglx, jason, marc.zyngier, daniel.lezcano,
gregkh, jslaby, afaerber, linux-arm-kernel, linux-kernel,
devicetree, linux-serial, amit.kucheria, linus.walleij,
zhao_steven, overseas.sales, Manivannan Sadhasivam
In-Reply-To: <20181128135106.9255-5-manivannan.sadhasivam@linaro.org>
On Wed, 28 Nov 2018 19:20:55 +0530, Manivannan Sadhasivam wrote:
> Document interrupt controller in RDA Micro RDA8810PL SoC.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../interrupt-controller/rda,8810pl-intc.txt | 61 +++++++++++++++++++
> 1 file changed, 61 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/rda,8810pl-intc.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 02/15] dt-bindings: arm: Document RDA8810PL and reference boards
From: Rob Herring @ 2018-12-07 23:37 UTC (permalink / raw)
Cc: olof, arnd, robh+dt, tglx, jason, marc.zyngier, daniel.lezcano,
gregkh, jslaby, afaerber, linux-arm-kernel, linux-kernel,
devicetree, linux-serial, amit.kucheria, linus.walleij,
zhao_steven, overseas.sales, Manivannan Sadhasivam
In-Reply-To: <20181128135106.9255-3-manivannan.sadhasivam@linaro.org>
On Wed, 28 Nov 2018 19:20:53 +0530, Manivannan Sadhasivam wrote:
> From: Andreas Färber <afaerber@suse.de>
>
> Add bindings for RDA Micro RDA8810PL SoC and below reference boards:
>
> 1. Orange Pi 2G-IoT - http://www.orangepi.org/OrangePi2GIOT/
> 2. Orange Pi i96 - https://www.96boards.org/product/orangepi-i96/
>
> Cc: overseas.sales@unisoc.com
> Cc: zhao_steven@263.net
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> Documentation/devicetree/bindings/arm/rda.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/rda.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 01/15] dt-bindings: Add RDA Micro vendor prefix
From: Rob Herring @ 2018-12-07 23:35 UTC (permalink / raw)
Cc: olof, arnd, robh+dt, tglx, jason, marc.zyngier, daniel.lezcano,
gregkh, jslaby, afaerber, linux-arm-kernel, linux-kernel,
devicetree, linux-serial, amit.kucheria, linus.walleij,
zhao_steven, overseas.sales, Manivannan Sadhasivam
In-Reply-To: <20181128135106.9255-2-manivannan.sadhasivam@linaro.org>
On Wed, 28 Nov 2018 19:20:52 +0530, Manivannan Sadhasivam wrote:
> From: Andreas Färber <afaerber@suse.de>
>
> Add vendor prefix for RDA Micro which now merged into Unisoc
> Communications Inc.
>
> Cc: overseas.sales@unisoc.com
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/3] tty/serial: Add RISC-V SBI earlycon support
From: Palmer Dabbelt @ 2018-12-07 18:45 UTC (permalink / raw)
To: Greg KH
Cc: anup, jslaby, aou, atish.patra, Christoph Hellwig, robh,
linux-riscv, linux-kernel, linux-serial
In-Reply-To: <20181205095846.GA9847@kroah.com>
On Wed, 05 Dec 2018 01:58:46 PST (-0800), Greg KH wrote:
> On Tue, Dec 04, 2018 at 07:25:05PM +0530, Anup Patel wrote:
>> In RISC-V, the M-mode runtime firmware provide SBI calls for
>> debug prints. This patch adds earlycon support using RISC-V
>> SBI console calls. To enable it, just pass "earlycon=sbi" in
>> kernel parameters.
>>
>> Signed-off-by: Anup Patel <anup@brainfault.org>
>
> This makes more sense to take through the riscv tree, so feel free to
> add:
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> to it and take it that way.
It should be in my for-next now.
Thanks!
^ permalink raw reply
* Re: [PATCH 0/3] RISC-V SBI earlycon
From: Palmer Dabbelt @ 2018-12-07 18:30 UTC (permalink / raw)
To: Greg KH
Cc: jslaby, aou, atish.patra, Christoph Hellwig, robh, linux-riscv,
linux-kernel, linux-serial, anup
In-Reply-To: <20181204135507.3706-1-anup@brainfault.org>
On Tue, 04 Dec 2018 05:55:04 PST (-0800), anup@brainfault.org wrote:
> This patchset adds RISC-V SBI earlycon and removes RISC-V EARLY_PRINTK.
>
> We should use earlycon over existing EARLY_PRINTK for SBI console because:
> 1. It's a more generic way of implementing early console for debugging
> 2. Current RISC-V EARLY_PRINTK is a compile-time option whereas earlycon
> is enabled at run-time via kernel parameters.
> 3. To use earlycon with SBI, we have to pass "earlycon=sbi" in kernel
> parameters. If earlycon kernel parameter is not provided then kernel
> boots much faster which is very useful in real-world RISC-V deployments.
>
> The patchset is tested on QEMU virt machine. It is based on Linux-4.20-rc5
> and can be found at riscv_earlycon_v1 branch of:
> https://github.com/avpatel/linux.git
>
> Anup Patel (3):
> tty/serial: Add RISC-V SBI earlycon support
> RISC-V: defconfig: Enable RISC-V SBI earlycon support
> RISC-V: Remove EARLY_PRINTK support
>
> arch/riscv/Kconfig.debug | 2 --
> arch/riscv/configs/defconfig | 1 +
> arch/riscv/kernel/setup.c | 28 -------------------------
> drivers/tty/serial/Kconfig | 12 +++++++++++
> drivers/tty/serial/Makefile | 1 +
> drivers/tty/serial/earlycon-riscv-sbi.c | 28 +++++++++++++++++++++++++
> 6 files changed, 42 insertions(+), 30 deletions(-)
> create mode 100644 drivers/tty/serial/earlycon-riscv-sbi.c
I'm adding these to my for-next.
Thanks!
^ permalink raw reply
* Re: [PATCH 3/3] RISC-V: Remove EARLY_PRINTK support
From: Palmer Dabbelt @ 2018-12-07 18:30 UTC (permalink / raw)
Cc: Greg KH, jslaby, aou, atish.patra, Christoph Hellwig, robh,
linux-riscv, linux-kernel, linux-serial, anup
In-Reply-To: <20181204135507.3706-4-anup@brainfault.org>
On Tue, 04 Dec 2018 05:55:07 PST (-0800), anup@brainfault.org wrote:
> The EARLY_PRINTK using SBI console calls is not required
> any more because we now have RISC-V SBI support in generic
> earlycon framework.
>
> Signed-off-by: Anup Patel <anup@brainfault.org>
> ---
> arch/riscv/Kconfig.debug | 2 --
> arch/riscv/kernel/setup.c | 28 ----------------------------
> 2 files changed, 30 deletions(-)
>
> diff --git a/arch/riscv/Kconfig.debug b/arch/riscv/Kconfig.debug
> index c5a72f17c469..e69de29bb2d1 100644
> --- a/arch/riscv/Kconfig.debug
> +++ b/arch/riscv/Kconfig.debug
> @@ -1,2 +0,0 @@
> -config EARLY_PRINTK
> - def_bool y
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index 2c290e6aaa6e..fc8006a042eb 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -35,31 +35,9 @@
> #include <asm/sections.h>
> #include <asm/pgtable.h>
> #include <asm/smp.h>
> -#include <asm/sbi.h>
> #include <asm/tlbflush.h>
> #include <asm/thread_info.h>
>
> -#ifdef CONFIG_EARLY_PRINTK
> -static void sbi_console_write(struct console *co, const char *buf,
> - unsigned int n)
> -{
> - int i;
> -
> - for (i = 0; i < n; ++i) {
> - if (buf[i] == '\n')
> - sbi_console_putchar('\r');
> - sbi_console_putchar(buf[i]);
> - }
> -}
> -
> -struct console riscv_sbi_early_console_dev __initdata = {
> - .name = "early",
> - .write = sbi_console_write,
> - .flags = CON_PRINTBUFFER | CON_BOOT | CON_ANYTIME,
> - .index = -1
> -};
> -#endif
> -
> #ifdef CONFIG_DUMMY_CONSOLE
> struct screen_info screen_info = {
> .orig_video_lines = 30,
> @@ -219,12 +197,6 @@ static void __init setup_bootmem(void)
>
> void __init setup_arch(char **cmdline_p)
> {
> -#if defined(CONFIG_EARLY_PRINTK)
> - if (likely(early_console == NULL)) {
> - early_console = &riscv_sbi_early_console_dev;
> - register_console(early_console);
> - }
> -#endif
> *cmdline_p = boot_command_line;
>
> parse_early_param();
Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
^ permalink raw reply
* Re: [PATCH 2/3] RISC-V: defconfig: Enable RISC-V SBI earlycon support
From: Palmer Dabbelt @ 2018-12-07 18:30 UTC (permalink / raw)
Cc: Greg KH, jslaby, aou, atish.patra, Christoph Hellwig, robh,
linux-riscv, linux-kernel, linux-serial, anup
In-Reply-To: <20181204135507.3706-3-anup@brainfault.org>
On Tue, 04 Dec 2018 05:55:06 PST (-0800), anup@brainfault.org wrote:
> This patch enables RISC-V SBI earlycon support in default defconfig
> so that we can use "earlycon=sbi" in kernel parameters for early
> debug prints.
>
> Signed-off-by: Anup Patel <anup@brainfault.org>
> ---
> arch/riscv/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
> index ef4f15df9adf..f399659d3b8d 100644
> --- a/arch/riscv/configs/defconfig
> +++ b/arch/riscv/configs/defconfig
> @@ -46,6 +46,7 @@ CONFIG_INPUT_MOUSEDEV=y
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_OF_PLATFORM=y
> +CONFIG_SERIAL_EARLYCON_RISCV_SBI=y
> CONFIG_HVC_RISCV_SBI=y
> # CONFIG_PTP_1588_CLOCK is not set
> CONFIG_DRM=y
Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
^ permalink raw reply
* Re: [PATCH 1/3] tty/serial: Add RISC-V SBI earlycon support
From: Palmer Dabbelt @ 2018-12-07 18:30 UTC (permalink / raw)
Cc: Greg KH, jslaby, aou, atish.patra, Christoph Hellwig, robh,
linux-riscv, linux-kernel, linux-serial, anup
In-Reply-To: <20181204135507.3706-2-anup@brainfault.org>
On Tue, 04 Dec 2018 05:55:05 PST (-0800), anup@brainfault.org wrote:
> In RISC-V, the M-mode runtime firmware provide SBI calls for
> debug prints. This patch adds earlycon support using RISC-V
> SBI console calls. To enable it, just pass "earlycon=sbi" in
> kernel parameters.
>
> Signed-off-by: Anup Patel <anup@brainfault.org>
> ---
> drivers/tty/serial/Kconfig | 12 +++++++++++
> drivers/tty/serial/Makefile | 1 +
> drivers/tty/serial/earlycon-riscv-sbi.c | 28 +++++++++++++++++++++++++
> 3 files changed, 41 insertions(+)
> create mode 100644 drivers/tty/serial/earlycon-riscv-sbi.c
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 32886c304641..287bb41ac814 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -85,6 +85,18 @@ config SERIAL_EARLYCON_ARM_SEMIHOST
> with "earlycon=smh" on the kernel command line. The console is
> enabled when early_param is processed.
>
> +config SERIAL_EARLYCON_RISCV_SBI
> + bool "Early console using RISC-V SBI"
> + depends on RISCV
> + select SERIAL_CORE
> + select SERIAL_CORE_CONSOLE
> + select SERIAL_EARLYCON
> + help
> + Support for early debug console using RISC-V SBI. This enables
> + the console before standard serial driver is probed. This is enabled
> + with "earlycon=sbi" on the kernel command line. The console is
> + enabled when early_param is processed.
> +
> config SERIAL_SB1250_DUART
> tristate "BCM1xxx on-chip DUART serial support"
> depends on SIBYTE_SB1xxx_SOC=y
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index daac675612df..3ce26ce08616 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_SERIAL_CORE) += serial_core.o
>
> obj-$(CONFIG_SERIAL_EARLYCON) += earlycon.o
> obj-$(CONFIG_SERIAL_EARLYCON_ARM_SEMIHOST) += earlycon-arm-semihost.o
> +obj-$(CONFIG_SERIAL_EARLYCON_RISCV_SBI) += earlycon-riscv-sbi.o
>
> # These Sparc drivers have to appear before others such as 8250
> # which share ttySx minor node space. Otherwise console device
> diff --git a/drivers/tty/serial/earlycon-riscv-sbi.c b/drivers/tty/serial/earlycon-riscv-sbi.c
> new file mode 100644
> index 000000000000..e1a551aae336
> --- /dev/null
> +++ b/drivers/tty/serial/earlycon-riscv-sbi.c
> @@ -0,0 +1,28 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * RISC-V SBI based earlycon
> + *
> + * Copyright (C) 2018 Anup Patel <anup@brainfault.org>
> + */
> +#include <linux/kernel.h>
> +#include <linux/console.h>
> +#include <linux/init.h>
> +#include <linux/serial_core.h>
> +#include <asm/sbi.h>
> +
> +static void sbi_console_write(struct console *con,
> + const char *s, unsigned int n)
> +{
> + int i;
> +
> + for (i = 0; i < n; ++i)
> + sbi_console_putchar(s[i]);
> +}
> +
> +static int __init early_sbi_setup(struct earlycon_device *device,
> + const char *opt)
> +{
> + device->con->write = sbi_console_write;
> + return 0;
> +}
> +EARLYCON_DECLARE(sbi, early_sbi_setup);
Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
^ permalink raw reply
* Re: [PATCH v2 01/10] mailbox: Support blocking transfers in atomic context
From: Greg KH @ 2018-12-07 15:39 UTC (permalink / raw)
To: Thierry Reding
Cc: Devicetree List, Jassi Brar, mliljeberg, Mikko Perttunen, talho,
linux-serial, jslaby, linux-tegra, ppessi, Jon Hunter,
linux-arm-kernel
In-Reply-To: <20181207113245.GA30719@ulmo>
On Fri, Dec 07, 2018 at 12:32:45PM +0100, Thierry Reding wrote:
> Greg,
>
> any ideas on how we can move forward here? For reasons given elsewhere
> in this thread I understand that there is no way to make the console
> code run in non-atomic context. Have you ever run into a case where the
> console driver couldn't busy-loop? Were there any solutions to this?
I don't know of any such cases, hardware sucks at times, and we just
have to deal with getting it to work by doing stuff like this :(
> I've looked through quite a few drivers and they all end up with a busy
> loop, waiting for the transmission FIFO to become empty. There are also
> a few implementations for hypervisors that call back into some firmware
> in order to send the characters, but I expect those to do the busy
> looping in the firmware.
busy loops are ok here, as you point out.
> Perhaps the most prominent case that I came across and that is quite
> similar to this discussion is netconsole. There's a lot of code in the
> network layer that exists only to allow using a network device for
> outputting a console. I don't think the changes to the mailbox
> framework are anywhere near as complicated.
Neither do I, I have no objection to your changes at all.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 01/10] mailbox: Support blocking transfers in atomic context
From: Thierry Reding @ 2018-12-07 11:32 UTC (permalink / raw)
To: Jassi Brar, Greg KH
Cc: Devicetree List, mliljeberg, Mikko Perttunen, talho, linux-serial,
jslaby, linux-tegra, ppessi, Jon Hunter, linux-arm-kernel
In-Reply-To: <CABb+yY1G+6MQmrSeZvOXnuREB87+DYHGxNu1tBb9W6apizLtGw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 10848 bytes --]
On Thu, Dec 06, 2018 at 11:56:25PM -0600, Jassi Brar wrote:
> On Thu, Nov 29, 2018 at 9:23 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Wed, Nov 28, 2018 at 11:23:36PM -0600, Jassi Brar wrote:
> > > On Wed, Nov 28, 2018 at 3:43 AM Jon Hunter <jonathanh@nvidia.com> wrote:
> > > >
> > > >
> > > > On 12/11/2018 15:18, Thierry Reding wrote:
> > > > > From: Thierry Reding <treding@nvidia.com>
> > > > >
> > > > > The mailbox framework supports blocking transfers via completions for
> > > > > clients that can sleep. In order to support blocking transfers in cases
> > > > > where the transmission is not permitted to sleep, add a new ->flush()
> > > > > callback that controller drivers can implement to busy loop until the
> > > > > transmission has been completed. This will automatically be called when
> > > > > available and interrupts are disabled for clients that request blocking
> > > > > transfers.
> > > > >
> > > > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > > > ---
> > > > > drivers/mailbox/mailbox.c | 8 ++++++++
> > > > > include/linux/mailbox_controller.h | 4 ++++
> > > > > 2 files changed, 12 insertions(+)
> > > > >
> > > > > diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
> > > > > index 674b35f402f5..0eaf21259874 100644
> > > > > --- a/drivers/mailbox/mailbox.c
> > > > > +++ b/drivers/mailbox/mailbox.c
> > > > > @@ -267,6 +267,14 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
> > > > > unsigned long wait;
> > > > > int ret;
> > > > >
> > > > > + if (irqs_disabled() && chan->mbox->ops->flush) {
> > > > > + ret = chan->mbox->ops->flush(chan, chan->cl->tx_tout);
> > > > > + if (ret < 0)
> > > > > + tx_tick(chan, ret);
> > > > > +
> > > > > + return ret;
> > > > > + }
> > > >
> > > > It seems to me that if mbox_send_message() is called from an atomic
> > > > context AND tx_block is true, then if 'flush' is not populated this
> > > > should be an error condition as we do not wish to call
> > > > wait_for_completion from an atomic context.
> > > >
> > > > I understand that there is some debate about adding such flush support,
> > > > but irrespective of the above change, it seems to me that if the
> > > > mbox_send_message() can be called from an atomic context (which it
> > > > appears to), then it should be detecting if someone is trying to do so
> > > > with 'tx_block' set as this should be an error.
> > > >
> > > Layers within kernel space have to trust each other. A badly written
> > > client can break the consumer in so many ways, we can not catch every
> > > possibility.
> > >
> > > > Furthermore, if the underlying mailbox driver can support sending a
> > > > message from an atomic context and busy wait until it is done, surely
> > > > the mailbox framework should provide a means to support this?
> > > >
> > > Being able to put the message on bus in atomic context is a feature -
> > > which we do support. But busy-waiting in a loop is not a feature, and
> > > we don't want to encourage that.
> >
> > I agree that in generally busy-waiting is a bad idea and shouldn't be
> > encouraged. However, I also think that an exception proves the rule. If
> > you look at the console drivers in drivers/tty/serial, all of them will
> > busy loop prior to or after sending a character. This is pretty much
> > part of the API and as such busy-looping is very much a feature.
> >
> > The reason why this is done is because on one hand we have an atomic
> > context and on the other hand we want to make sure that all characters
> > actually make it to the console when we print them.
> >
> > As an example how this can break, I've taken your suggestion to
> > implement a producer/consumer mode in the TCU driver where the console
> > write function will just stash characters into a circular buffer and a
> > work queue will then use mbox_send_message() to drain the circular
> > buffer. While this does work on the surface, I was able to concern both
> > of the issues that I was concerned about: 1) it is easy to overflow the
> > circular buffer by just dumping enough data at once to the console and
> > 2) when a crash happens, everything in the kernel stops, including the
> > consumer workqueue that is supposed to drain the circular buffer and
> > flush messages to the TCU. The result is that, in my particular case,
> > the boot log will just stop at a random place in the middle of messages
> > from much earlier in the boot because the TCU hasn't caught up yet and
> > there's a lot of characters still in the circular buffer.
> >
> > Now, 1) can be mitigated by increasing the circular buffer size. A value
> > that seems to give reliably good results in 2 << CONFIG_LOG_BUF_SHIFT.
> >
> Yes please.
As I explained elsewhere, I actually went and implemented this. But
given the nature of buffering, this ends up making the TCU completely
useless as a console because in case of a crash, the system will stop
working with a large number of characters still stuck in the buffer.
And that's especially bad in case of a crash because those last
characters that get stuck in the buffer are the most relevant ones
because they contain the stack dump.
> > I thought that I could also mitigate 2) by busy looping in the TCU driver,
> > but it turns out that that doesn't work. The reason is that since we are
> > in atomic context with all interrupts disabled, the mailbox won't ever
> > consume any new characters, so the read pointer in the circular buffer
> > won't increment, leaving me with no condition upon which to loop that
> > would work.
> >
> So you want to be able to rely on an emulated console (running on a
> totally different subsystem) to dump development-phase early-boot
> logs? At the cost of legitimizing busy looping in atomic context - one
> random driver messing up the api for ever. Maybe you could have the
> ring buffer in some shmem and only pass the number of valid characters
> in it, to the remote?
First of all, this is not about development-phase early-boot messages.
We're talking about the system console here. This is what everyone will
want to be using when developing on this device. Sure at some point you
may end up with a system that works and you can have the console on the
network or an attached display or whatever, but even then you may still
want to attach to the console if you ever run into issues where the
system doesn't come up.
Secondly, I don't understand why you think this is an emulated console.
The way that this works is that there's a microprocessor in the system
that interacts with other microprocessors via shared mailboxes to
receive log messages. That microprocessor collects these log messages
and outputs them on a physical UART via multiplexed streams. The host
system can connect to that physical UART and demultiplex these streams
to get the individual log messages from each of the components in the
system.
Lastly, I don't understand why you think we're messing up the API here.
The proposal in this series doesn't even change any of the API, but it
makes it aware of the state of interrupts internally so that it can do
the right thing depending on the call stack. The other proposal, in v3,
is more explicit in that it adds new API to flush the mailbox. The new
API is completely optional and I even offered to document it as being
discouraged because it involves busy looping. At the same time it does
solve a real problem and it doesn't impact any existing mailbox drivers
nor any of their users (because it is completely opt-in).
While I can somewhat relate to your reluctance to extend the API, I do
not see a way around it. Sure, you could decide that this is something
that Linux just won't support, but that would be a first. I'm not aware
of any cases where a concious decision was ever made not to support a
feature because it didn't fit into any existing frameworks. Typically
we deal with this by improving things so that we can support the
additional use-cases. It's really one of the strong points of Linux.
I'm open to any suggestions on how this could be done better. You had
already suggested the ring buffer and I did go and implement it, but it
only confirmed the concerns that I've had with it all along. I realize
that at this point I may be blind to other obvious solutions, but I've
done my best to come up with alternatives and none of them work. If you
have any other ideas, please do share them and I will investigate.
> > http://patchwork.ozlabs.org/project/linux-tegra/list/?series=78477
> >
> > The difference to the earlier versions is that the flushing is now
> > explicit. I think this combines the best of both worlds. On one hand it
> > makes the mechanism completely opt-in, so nothing gets hidden in the
> > regular functions. On the other hand, it allows clients to make use of
> > this functionality very explicitly. A client that doesn't call the
> > mbox_flush() function will just not busy-loop. But clients that need to
> > make sure messages are flushed in atomic contexts can now do that. Does
> > that sound like a more acceptable solution to you? We could even go and
> > add documentation to mbox_flush() that it should only be used under
> > special circumstances.
> >
> > If you still think that's a bad idea, do you have any other suggestions
> > on how to move forward?
> >
> It would help if other maintainers chime in if a subsystem should
> support busy-wait in atomic context for a one-off driver.
Just as an additional note: it's not the driver that actually requires
the busy looping, it's the use-case (i.e. the consumer). The driver is
working perfectly fine with interrupts enabled, it's just that in the
particular use-case of the console that we have no way of detecting if
or when an interrupt occurred.
Greg,
any ideas on how we can move forward here? For reasons given elsewhere
in this thread I understand that there is no way to make the console
code run in non-atomic context. Have you ever run into a case where the
console driver couldn't busy-loop? Were there any solutions to this?
I've looked through quite a few drivers and they all end up with a busy
loop, waiting for the transmission FIFO to become empty. There are also
a few implementations for hypervisors that call back into some firmware
in order to send the characters, but I expect those to do the busy
looping in the firmware.
Perhaps the most prominent case that I came across and that is quite
similar to this discussion is netconsole. There's a lot of code in the
network layer that exists only to allow using a network device for
outputting a console. I don't think the changes to the mailbox
framework are anywhere near as complicated.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 2/2] arm: dts: mt2701: add uart APDMA to device tree
From: Long Cheng @ 2018-12-07 7:47 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland
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: <1544168842-13860-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..a59728b 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";
};
@@ -378,6 +381,38 @@
status = "disabled";
};
+ 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>;
+ };
+
uart0: serial@11002000 {
compatible = "mediatek,mt2712-uart",
"mediatek,mt6577-uart";
@@ -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 v3 1/2] dmaengine: 8250_mtk_dma: add Mediatek uart DMA support
From: Long Cheng @ 2018-12-07 7:47 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland
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: <1544168842-13860-1-git-send-email-long.cheng@mediatek.com>
In DMA engine framework, add 8250 mtk dma to support it.
Signed-off-by: Long Cheng <long.cheng@mediatek.com>
---
drivers/dma/mediatek/8250_mtk_dma.c | 847 +++++++++++++++++++++++++++++++++++
drivers/dma/mediatek/Kconfig | 11 +
drivers/dma/mediatek/Makefile | 1 +
3 files changed, 859 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..a2db9ec
--- /dev/null
+++ b/drivers/dma/mediatek/8250_mtk_dma.c
@@ -0,0 +1,847 @@
+// 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_APDMA_DEFAULT_REQUESTS 127
+#define MTK_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_DMA_RING_SIZE 0xffffU
+/* invert this bit when wrap ring head again*/
+#define MTK_DMA_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_dmadev {
+ struct dma_device ddev;
+ void __iomem *mem_base[MTK_APDMA_CHANNELS];
+ spinlock_t lock; /* dma dev lock */
+ struct tasklet_struct task;
+ struct list_head pending;
+ struct clk *clk;
+ unsigned int dma_requests;
+ bool support_33bits;
+ unsigned int dma_irq[MTK_APDMA_CHANNELS];
+ struct mtk_chan *ch[MTK_APDMA_CHANNELS];
+};
+
+struct mtk_chan {
+ struct virt_dma_chan vc;
+ struct list_head node;
+ struct dma_slave_config cfg;
+ void __iomem *base;
+ struct mtk_dma_desc *desc;
+
+ bool stop;
+ bool requested;
+
+ unsigned int rx_status;
+};
+
+struct mtk_dma_sg {
+ dma_addr_t addr;
+ unsigned int en; /* number of elements (24-bit) */
+ unsigned int fn; /* number of frames (16-bit) */
+};
+
+struct mtk_dma_desc {
+ struct virt_dma_desc vd;
+ enum dma_transfer_direction dir;
+
+ unsigned int sglen;
+ struct mtk_dma_sg sg[0];
+
+ unsigned int len;
+};
+
+static inline struct mtk_dmadev *to_mtk_dma_dev(struct dma_device *d)
+{
+ return container_of(d, struct mtk_dmadev, ddev);
+}
+
+static inline struct mtk_chan *to_mtk_dma_chan(struct dma_chan *c)
+{
+ return container_of(c, struct mtk_chan, vc.chan);
+}
+
+static inline struct mtk_dma_desc *to_mtk_dma_desc
+ (struct dma_async_tx_descriptor *t)
+{
+ return container_of(t, struct mtk_dma_desc, vd.tx);
+}
+
+static void mtk_dma_chan_write(struct mtk_chan *c,
+ unsigned int reg, unsigned int val)
+{
+ writel(val, c->base + reg);
+}
+
+static unsigned int mtk_dma_chan_read(struct mtk_chan *c, unsigned int reg)
+{
+ return readl(c->base + reg);
+}
+
+static void mtk_dma_desc_free(struct virt_dma_desc *vd)
+{
+ struct dma_chan *chan = vd->tx.chan;
+ struct mtk_chan *c = to_mtk_dma_chan(chan);
+
+ kfree(c->desc);
+ c->desc = NULL;
+}
+
+static int mtk_dma_clk_enable(struct mtk_dmadev *mtkd)
+{
+ int ret;
+
+ ret = clk_prepare_enable(mtkd->clk);
+ if (ret) {
+ dev_err(mtkd->ddev.dev, "Couldn't enable the clock\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static void mtk_dma_clk_disable(struct mtk_dmadev *mtkd)
+{
+ clk_disable_unprepare(mtkd->clk);
+}
+
+static void mtk_dma_tx_flush(struct dma_chan *chan)
+{
+ struct mtk_chan *c = to_mtk_dma_chan(chan);
+
+ if (mtk_dma_chan_read(c, VFF_FLUSH) == 0U)
+ mtk_dma_chan_write(c, VFF_FLUSH, VFF_FLUSH_B);
+}
+
+static void mtk_dma_tx_write(struct dma_chan *chan)
+{
+ struct mtk_chan *c = to_mtk_dma_chan(chan);
+ unsigned int txcount = c->desc->len;
+ unsigned int len, send, left, wpt, wrap;
+
+ len = mtk_dma_chan_read(c, VFF_LEN);
+
+ while ((left = mtk_dma_chan_read(c, VFF_LEFT_SIZE)) > 0U) {
+ if (c->desc->len == 0U)
+ break;
+ send = min_t(unsigned int, left, c->desc->len);
+ wpt = mtk_dma_chan_read(c, VFF_WPT);
+ wrap = wpt & MTK_DMA_RING_WRAP ? 0U : MTK_DMA_RING_WRAP;
+
+ if ((wpt & (len - 1U)) + send < len)
+ mtk_dma_chan_write(c, VFF_WPT, wpt + send);
+ else
+ mtk_dma_chan_write(c, VFF_WPT,
+ ((wpt + send) & (len - 1U))
+ | wrap);
+
+ c->desc->len -= send;
+ }
+
+ if (txcount != c->desc->len) {
+ mtk_dma_chan_write(c, VFF_INT_EN, VFF_TX_INT_EN_B);
+ mtk_dma_tx_flush(chan);
+ }
+}
+
+static void mtk_dma_start_tx(struct mtk_chan *c)
+{
+ if (mtk_dma_chan_read(c, VFF_LEFT_SIZE) == 0U)
+ mtk_dma_chan_write(c, VFF_INT_EN, VFF_TX_INT_EN_B);
+ else
+ mtk_dma_tx_write(&c->vc.chan);
+
+ c->stop = false;
+}
+
+static void mtk_dma_get_rx_size(struct mtk_chan *c)
+{
+ unsigned int rx_size = mtk_dma_chan_read(c, VFF_LEN);
+ unsigned int rdptr, wrptr, wrreg, rdreg, count;
+
+ rdreg = mtk_dma_chan_read(c, VFF_RPT);
+ wrreg = mtk_dma_chan_read(c, VFF_WPT);
+ rdptr = rdreg & MTK_DMA_RING_SIZE;
+ wrptr = wrreg & MTK_DMA_RING_SIZE;
+ count = ((rdreg ^ wrreg) & MTK_DMA_RING_WRAP) ?
+ (wrptr + rx_size - rdptr) : (wrptr - rdptr);
+
+ c->rx_status = count;
+
+ mtk_dma_chan_write(c, VFF_RPT, wrreg);
+}
+
+static void mtk_dma_start_rx(struct mtk_chan *c)
+{
+ struct dma_chan *chan = &c->vc.chan;
+ struct mtk_dmadev *mtkd = to_mtk_dma_dev(chan->device);
+ struct mtk_dma_desc *d = c->desc;
+
+ if (mtk_dma_chan_read(c, VFF_VALID_SIZE) == 0U)
+ return;
+
+ if (d && vchan_next_desc(&c->vc)) {
+ mtk_dma_get_rx_size(c);
+ list_del(&d->vd.node);
+ vchan_cookie_complete(&d->vd);
+ } else {
+ spin_lock(&mtkd->lock);
+ if (list_empty(&mtkd->pending))
+ list_add_tail(&c->node, &mtkd->pending);
+ spin_unlock(&mtkd->lock);
+ tasklet_schedule(&mtkd->task);
+ }
+}
+
+static void mtk_dma_reset(struct mtk_chan *c)
+{
+ struct mtk_dmadev *mtkd = to_mtk_dma_dev(c->vc.chan.device);
+ u32 status;
+ int ret;
+
+ mtk_dma_chan_write(c, VFF_ADDR, 0);
+ mtk_dma_chan_write(c, VFF_THRE, 0);
+ mtk_dma_chan_write(c, VFF_LEN, 0);
+ mtk_dma_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");
+ return;
+ }
+
+ if (c->cfg.direction == DMA_DEV_TO_MEM)
+ mtk_dma_chan_write(c, VFF_RPT, 0);
+ else if (c->cfg.direction == DMA_MEM_TO_DEV)
+ mtk_dma_chan_write(c, VFF_WPT, 0);
+
+ if (mtkd->support_33bits)
+ mtk_dma_chan_write(c, VFF_4G_SUPPORT, VFF_4G_SUPPORT_CLR_B);
+}
+
+static void mtk_dma_stop(struct mtk_chan *c)
+{
+ u32 status;
+ int ret;
+
+ mtk_dma_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_dma_chan_read(c, VFF_DEBUG_STATUS));
+
+ /*set stop as 1 -> wait until en is 0 -> set stop as 0*/
+ mtk_dma_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_dma_chan_read(c, VFF_DEBUG_STATUS));
+
+ mtk_dma_chan_write(c, VFF_STOP, VFF_STOP_CLR_B);
+ mtk_dma_chan_write(c, VFF_INT_EN, VFF_INT_EN_CLR_B);
+
+ if (c->cfg.direction == DMA_DEV_TO_MEM)
+ mtk_dma_chan_write(c, VFF_INT_FLAG, VFF_RX_INT_FLAG_CLR_B);
+ else
+ mtk_dma_chan_write(c, VFF_INT_FLAG, VFF_TX_INT_FLAG_CLR_B);
+
+ c->stop = true;
+}
+
+/*
+ * This callback schedules all pending channels. We could be more
+ * clever here by postponing allocation of the real DMA channels to
+ * this point, and freeing them when our virtual channel becomes idle.
+ *
+ * We would then need to deal with 'all channels in-use'
+ */
+static void mtk_dma_sched(unsigned long data)
+{
+ struct mtk_dmadev *mtkd = (struct mtk_dmadev *)data;
+ struct virt_dma_desc *vd;
+ struct mtk_chan *c;
+ unsigned long flags;
+ LIST_HEAD(head);
+
+ spin_lock_irq(&mtkd->lock);
+ list_splice_tail_init(&mtkd->pending, &head);
+ spin_unlock_irq(&mtkd->lock);
+
+ if (!list_empty(&head)) {
+ c = list_first_entry(&head, struct mtk_chan, node);
+
+ spin_lock_irqsave(&c->vc.lock, flags);
+ if (c->cfg.direction == DMA_DEV_TO_MEM) {
+ list_del_init(&c->node);
+ mtk_dma_start_rx(c);
+ } else if (c->cfg.direction == DMA_MEM_TO_DEV) {
+ vd = vchan_next_desc(&c->vc);
+ c->desc = to_mtk_dma_desc(&vd->tx);
+ list_del_init(&c->node);
+ mtk_dma_start_tx(c);
+ }
+ spin_unlock_irqrestore(&c->vc.lock, flags);
+ }
+}
+
+static int mtk_dma_alloc_chan_resources(struct dma_chan *chan)
+{
+ struct mtk_dmadev *mtkd = to_mtk_dma_dev(chan->device);
+ struct mtk_chan *c = to_mtk_dma_chan(chan);
+ int ret = -EBUSY;
+
+ pm_runtime_get_sync(mtkd->ddev.dev);
+
+ if (!mtkd->ch[chan->chan_id]) {
+ c->base = mtkd->mem_base[chan->chan_id];
+ mtkd->ch[chan->chan_id] = c;
+ ret = 1;
+ }
+ c->requested = false;
+ mtk_dma_reset(c);
+
+ return ret;
+}
+
+static void mtk_dma_free_chan_resources(struct dma_chan *chan)
+{
+ struct mtk_dmadev *mtkd = to_mtk_dma_dev(chan->device);
+ struct mtk_chan *c = to_mtk_dma_chan(chan);
+
+ if (c->requested) {
+ c->requested = false;
+ free_irq(mtkd->dma_irq[chan->chan_id], chan);
+ }
+
+ tasklet_kill(&mtkd->task);
+ tasklet_kill(&c->vc.task);
+
+ c->base = NULL;
+ mtkd->ch[chan->chan_id] = NULL;
+ vchan_free_chan_resources(&c->vc);
+
+ pm_runtime_put_sync(mtkd->ddev.dev);
+}
+
+static enum dma_status mtk_dma_tx_status(struct dma_chan *chan,
+ dma_cookie_t cookie,
+ struct dma_tx_state *txstate)
+{
+ struct mtk_chan *c = to_mtk_dma_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_dma_chan_read(c, VFF_RPT)
+ & MTK_DMA_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;
+}
+
+static struct dma_async_tx_descriptor *mtk_dma_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_dma_chan(chan);
+ struct scatterlist *sgent;
+ struct mtk_dma_desc *d;
+ struct mtk_dma_sg *sg;
+ unsigned int size, i, j, en;
+
+ en = 1;
+
+ 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) + sglen * sizeof(d->sg[0]), GFP_ATOMIC);
+ if (!d)
+ return NULL;
+
+ d->dir = dir;
+
+ j = 0;
+ for_each_sg(sgl, sgent, sglen, i) {
+ d->sg[j].addr = sg_dma_address(sgent);
+ d->sg[j].en = en;
+ d->sg[j].fn = sg_dma_len(sgent) / en;
+ j++;
+ }
+
+ d->sglen = j;
+
+ if (dir == DMA_MEM_TO_DEV) {
+ for (size = i = 0; i < d->sglen; i++) {
+ sg = &d->sg[i];
+ size += sg->en * sg->fn;
+ }
+ d->len = size;
+ }
+
+ return vchan_tx_prep(&c->vc, &d->vd, tx_flags);
+}
+
+static void mtk_dma_issue_pending(struct dma_chan *chan)
+{
+ struct mtk_chan *c = to_mtk_dma_chan(chan);
+ struct virt_dma_desc *vd;
+ struct mtk_dmadev *mtkd;
+ unsigned long flags;
+
+ spin_lock_irqsave(&c->vc.lock, flags);
+ if (c->cfg.direction == DMA_DEV_TO_MEM) {
+ mtkd = to_mtk_dma_dev(chan->device);
+ if (vchan_issue_pending(&c->vc) && !c->desc) {
+ vd = vchan_next_desc(&c->vc);
+ c->desc = to_mtk_dma_desc(&vd->tx);
+ }
+ } 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_dma_desc(&vd->tx);
+ mtk_dma_start_tx(c);
+ }
+ }
+ spin_unlock_irqrestore(&c->vc.lock, flags);
+}
+
+static irqreturn_t mtk_dma_rx_interrupt(int irq, void *dev_id)
+{
+ struct dma_chan *chan = (struct dma_chan *)dev_id;
+ struct mtk_chan *c = to_mtk_dma_chan(chan);
+ unsigned long flags;
+
+ spin_lock_irqsave(&c->vc.lock, flags);
+ mtk_dma_chan_write(c, VFF_INT_FLAG, VFF_RX_INT_FLAG_CLR_B);
+
+ mtk_dma_start_rx(c);
+
+ spin_unlock_irqrestore(&c->vc.lock, flags);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t mtk_dma_tx_interrupt(int irq, void *dev_id)
+{
+ struct dma_chan *chan = (struct dma_chan *)dev_id;
+ struct mtk_dmadev *mtkd = to_mtk_dma_dev(chan->device);
+ struct mtk_chan *c = to_mtk_dma_chan(chan);
+ struct mtk_dma_desc *d = c->desc;
+ unsigned long flags;
+
+ spin_lock_irqsave(&c->vc.lock, flags);
+ if (d->len != 0U) {
+ list_add_tail(&c->node, &mtkd->pending);
+ tasklet_schedule(&mtkd->task);
+ } else {
+ list_del(&d->vd.node);
+ vchan_cookie_complete(&d->vd);
+ }
+ spin_unlock_irqrestore(&c->vc.lock, flags);
+
+ mtk_dma_chan_write(c, VFF_INT_FLAG, VFF_TX_INT_FLAG_CLR_B);
+
+ return IRQ_HANDLED;
+}
+
+static int mtk_dma_slave_config(struct dma_chan *chan,
+ struct dma_slave_config *cfg)
+{
+ struct mtk_chan *c = to_mtk_dma_chan(chan);
+ struct mtk_dmadev *mtkd = to_mtk_dma_dev(c->vc.chan.device);
+ int ret;
+
+ c->cfg = *cfg;
+
+ if (cfg->direction == DMA_DEV_TO_MEM) {
+ unsigned int rx_len = cfg->src_addr_width * 1024;
+
+ mtk_dma_chan_write(c, VFF_ADDR, cfg->src_addr);
+ mtk_dma_chan_write(c, VFF_LEN, rx_len);
+ mtk_dma_chan_write(c, VFF_THRE, VFF_RX_THRE(rx_len));
+ mtk_dma_chan_write(c,
+ VFF_INT_EN, VFF_RX_INT_EN0_B
+ | VFF_RX_INT_EN1_B);
+ mtk_dma_chan_write(c, VFF_INT_FLAG, VFF_RX_INT_FLAG_CLR_B);
+ mtk_dma_chan_write(c, VFF_EN, VFF_EN_B);
+
+ if (!c->requested) {
+ c->requested = true;
+ ret = request_irq(mtkd->dma_irq[chan->chan_id],
+ mtk_dma_rx_interrupt,
+ IRQF_TRIGGER_NONE,
+ KBUILD_MODNAME, chan);
+ if (ret < 0) {
+ dev_err(chan->device->dev, "Can't request rx dma IRQ\n");
+ return -EINVAL;
+ }
+ }
+ } else if (cfg->direction == DMA_MEM_TO_DEV) {
+ unsigned int tx_len = cfg->dst_addr_width * 1024;
+
+ mtk_dma_chan_write(c, VFF_ADDR, cfg->dst_addr);
+ mtk_dma_chan_write(c, VFF_LEN, tx_len);
+ mtk_dma_chan_write(c, VFF_THRE, VFF_TX_THRE(tx_len));
+ mtk_dma_chan_write(c, VFF_INT_FLAG, VFF_TX_INT_FLAG_CLR_B);
+ mtk_dma_chan_write(c, VFF_EN, VFF_EN_B);
+
+ if (!c->requested) {
+ c->requested = true;
+ ret = request_irq(mtkd->dma_irq[chan->chan_id],
+ mtk_dma_tx_interrupt,
+ IRQF_TRIGGER_NONE,
+ KBUILD_MODNAME, chan);
+ if (ret < 0) {
+ dev_err(chan->device->dev, "Can't request tx dma IRQ\n");
+ return -EINVAL;
+ }
+ }
+ }
+
+ if (mtkd->support_33bits)
+ mtk_dma_chan_write(c, VFF_4G_SUPPORT, VFF_4G_SUPPORT_B);
+
+ if (mtk_dma_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_dma_terminate_all(struct dma_chan *chan)
+{
+ struct mtk_chan *c = to_mtk_dma_chan(chan);
+ unsigned long flags;
+
+ spin_lock_irqsave(&c->vc.lock, flags);
+ list_del_init(&c->node);
+ mtk_dma_stop(c);
+ spin_unlock_irqrestore(&c->vc.lock, flags);
+
+ return 0;
+}
+
+static int mtk_dma_device_pause(struct dma_chan *chan)
+{
+ /* just for check caps pass */
+ return -EINVAL;
+}
+
+static int mtk_dma_device_resume(struct dma_chan *chan)
+{
+ /* just for check caps pass */
+ return -EINVAL;
+}
+
+static void mtk_dma_free(struct mtk_dmadev *mtkd)
+{
+ tasklet_kill(&mtkd->task);
+ 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);
+ devm_kfree(mtkd->ddev.dev, c);
+ }
+}
+
+static const struct of_device_id mtk_uart_dma_match[] = {
+ { .compatible = "mediatek,mt6577-uart-dma", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mtk_uart_dma_match);
+
+static int mtk_apdma_probe(struct platform_device *pdev)
+{
+ struct mtk_dmadev *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;
+
+ for (i = 0; i < MTK_APDMA_CHANNELS; i++) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ if (!res)
+ return -ENODEV;
+ mtkd->mem_base[i] = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(mtkd->mem_base[i]))
+ return PTR_ERR(mtkd->mem_base[i]);
+ }
+
+ for (i = 0; i < MTK_APDMA_CHANNELS; i++) {
+ 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);
+ return -EINVAL;
+ }
+ }
+
+ mtkd->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(mtkd->clk)) {
+ dev_err(&pdev->dev, "No clock specified\n");
+ return PTR_ERR(mtkd->clk);
+ }
+
+ if (of_property_read_bool(pdev->dev.of_node, "dma-33bits")) {
+ dev_info(&pdev->dev, "Support dma 33bits\n");
+ mtkd->support_33bits = true;
+ }
+
+ if (mtkd->support_33bits)
+ rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(33));
+ else
+ rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+ if (rc)
+ return rc;
+
+ dma_cap_set(DMA_SLAVE, mtkd->ddev.cap_mask);
+ mtkd->ddev.device_alloc_chan_resources = mtk_dma_alloc_chan_resources;
+ mtkd->ddev.device_free_chan_resources = mtk_dma_free_chan_resources;
+ mtkd->ddev.device_tx_status = mtk_dma_tx_status;
+ mtkd->ddev.device_issue_pending = mtk_dma_issue_pending;
+ mtkd->ddev.device_prep_slave_sg = mtk_dma_prep_slave_sg;
+ mtkd->ddev.device_config = mtk_dma_slave_config;
+ mtkd->ddev.device_pause = mtk_dma_device_pause;
+ mtkd->ddev.device_resume = mtk_dma_device_resume;
+ mtkd->ddev.device_terminate_all = mtk_dma_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);
+ INIT_LIST_HEAD(&mtkd->pending);
+
+ spin_lock_init(&mtkd->lock);
+ tasklet_init(&mtkd->task, mtk_dma_sched, (unsigned long)mtkd);
+
+ mtkd->dma_requests = MTK_APDMA_DEFAULT_REQUESTS;
+ if (of_property_read_u32(pdev->dev.of_node,
+ "dma-requests", &mtkd->dma_requests)) {
+ dev_info(&pdev->dev,
+ "Missing dma-requests property, using %u.\n",
+ MTK_APDMA_DEFAULT_REQUESTS);
+ }
+
+ for (i = 0; i < MTK_APDMA_CHANNELS; i++) {
+ c = devm_kzalloc(mtkd->ddev.dev, sizeof(*c), GFP_KERNEL);
+ if (!c)
+ goto err_no_dma;
+
+ c->vc.desc_free = mtk_dma_desc_free;
+ vchan_init(&c->vc, &mtkd->ddev);
+ INIT_LIST_HEAD(&c->node);
+ }
+
+ 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_dma_free(mtkd);
+ return rc;
+}
+
+static int mtk_apdma_remove(struct platform_device *pdev)
+{
+ struct mtk_dmadev *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_dma_free(mtkd);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int mtk_dma_suspend(struct device *dev)
+{
+ struct mtk_dmadev *mtkd = dev_get_drvdata(dev);
+
+ if (!pm_runtime_suspended(dev))
+ mtk_dma_clk_disable(mtkd);
+
+ return 0;
+}
+
+static int mtk_dma_resume(struct device *dev)
+{
+ int ret;
+ struct mtk_dmadev *mtkd = dev_get_drvdata(dev);
+
+ if (!pm_runtime_suspended(dev)) {
+ ret = mtk_dma_clk_enable(mtkd);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int mtk_dma_runtime_suspend(struct device *dev)
+{
+ struct mtk_dmadev *mtkd = dev_get_drvdata(dev);
+
+ mtk_dma_clk_disable(mtkd);
+
+ return 0;
+}
+
+static int mtk_dma_runtime_resume(struct device *dev)
+{
+ int ret;
+ struct mtk_dmadev *mtkd = dev_get_drvdata(dev);
+
+ ret = mtk_dma_clk_enable(mtkd);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops mtk_dma_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(mtk_dma_suspend, mtk_dma_resume)
+ SET_RUNTIME_PM_OPS(mtk_dma_runtime_suspend,
+ mtk_dma_runtime_resume, NULL)
+};
+
+static struct platform_driver mtk_dma_driver = {
+ .probe = mtk_apdma_probe,
+ .remove = mtk_apdma_remove,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .pm = &mtk_dma_pm_ops,
+ .of_match_table = of_match_ptr(mtk_uart_dma_match),
+ },
+};
+
+module_platform_driver(mtk_dma_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..bef436e 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
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ help
+ Support for the UART DMA engine found on MediaTek MTK SoCs.
+ when 8250 mtk uart 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
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