Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp997160imu; Fri, 4 Jan 2019 10:59:40 -0800 (PST) X-Google-Smtp-Source: ALg8bN53TdtMIye/7qmdMPcVKDsjxSWDrbvbDy497jyUGg8PIAh2xcTdBMN+yqMiKr9qTTicCjNV X-Received: by 2002:a63:d047:: with SMTP id s7mr2585331pgi.311.1546628380490; Fri, 04 Jan 2019 10:59:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546628380; cv=none; d=google.com; s=arc-20160816; b=p2bscjW2cosV3cr6AWEvnpdFpHQepFa52/s5in7ujkFzUmwoLOHK/lNpu2p07d+Nqt 6nU/lAZBgl8R4anC3/nEQwYNplhCgwqb4a+f4EcMvuBA1LKvCMJRI9pKNhAMMzElKoOc M1YWWGd05Ggessdh57Vm9rwqDFWZZ6rEHzdbtZLfRPl845WxAVJm2h2EhlPkQCBaEn/n FPlevwY84bgqAZpKTfI3jJl+4Vz0JOGyXKkNp/jek92PjlZUeWYbPRq9IgQTC2Akshnf F6ESJJBNCTSmL9nhMwykUg/vtSBa9cEVDOzfQbn2ZocwAf8eJaXEz2E14PNoLIZ//U+Q gVEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=jte4cRI44rCIumYRg4kVnngany98CLpIMMnwBSKLfbY=; b=xAoupQ4GFHEXCtfegHyliiG+XUu+FUg3drPpjeoXzCGjGnIyInua+le7qRKTZDCpOW FUOurnU+xchdXxDj1NeyfjM67kVI2F4+pgTYjToXQkvesIDBf9rg/IaKAGl3Sm+TOB4W GXMR7UPrkJXdxAL+jJ3F9lQGHapbauac7QsLV5Q1htdZYcp8jibDnf5x84/45mVlpwAD CHoSvLRtr7mwo7JACD9N08Wm1Z3pEWM4J7vVR10ZqZzbzuM8Blqglo2ZLBdrh0H25H6M B3Aj/1pDMy/vA4/U7IvQlUkY0iQOFIuLGA+6K2+W8IgTxYXBtZae6bWOoOKLztP6/+2d o/hw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NLk2stXI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w189si55367181pfb.151.2019.01.04.10.59.25; Fri, 04 Jan 2019 10:59:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NLk2stXI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726773AbfADRVi (ORCPT + 99 others); Fri, 4 Jan 2019 12:21:38 -0500 Received: from mail.kernel.org ([198.145.29.99]:55488 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726256AbfADRVi (ORCPT ); Fri, 4 Jan 2019 12:21:38 -0500 Received: from localhost (unknown [49.207.53.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DE77A20656; Fri, 4 Jan 2019 17:21:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1546622496; bh=IWRxjqRZMfqkpFR+UMeB7j3ELM39V1FdMr8iK6tZ528=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NLk2stXIkhjFIstnEo966bJqc2knqjTaG8nIJ7zw7Uy7mL8GHS4AfxNlCpK3MvUBK 5Hp4Ux6m1qUtqVZcCOunNNR/la5A94OBz/nQg7vhLcxNgc88ql9vkfkLF4fA8lwGJa UkI4zzs5NKZ5DdaCjsEVhRX9t4KaGsKT7T5VSbLo= Date: Fri, 4 Jan 2019 22:49:53 +0530 From: Vinod Koul To: Long Cheng Cc: Randy Dunlap , Rob Herring , Mark Rutland , Ryder Lee , Sean Wang , Nicolas Boichat , Matthias Brugger , Dan Williams , Greg Kroah-Hartman , Jiri Slaby , Sean Wang , dmaengine@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, srv_heupstream@mediatek.com, Yingjoe Chen , YT Shen , Zhenbao Liu Subject: Re: [PATCH v9 1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support Message-ID: <20190104171953.GQ13372@vkoul-mobl.Dlink> References: <1546395178-8880-1-git-send-email-long.cheng@mediatek.com> <1546395178-8880-2-git-send-email-long.cheng@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1546395178-8880-2-git-send-email-long.cheng@mediatek.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02-01-19, 10:12, Long Cheng wrote: > 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. Is the DMA controller UART specific, can it work with other controllers as well, if so you should get rid of uart name in patch > +#define MTK_UART_APDMA_CHANNELS (CONFIG_SERIAL_8250_NR_UARTS * 2) Why are the channels not coming from DT? > + > +#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*/ space around /* space */ also run checkpatch to check for style errors > +static void mtk_uart_apdma_start_tx(struct mtk_chan *c) > +{ > + unsigned int len, send, left, wpt, d_wpt, tmp; > + int ret; > + > + left = mtk_uart_apdma_read(c, VFF_LEFT_SIZE); > + if (!left) { > + mtk_uart_apdma_write(c, VFF_INT_EN, VFF_TX_INT_EN_B); > + return; > + } > + > + /* Wait 1sec for flush, can't sleep*/ > + ret = readx_poll_timeout(readl, c->base + VFF_FLUSH, tmp, > + tmp != VFF_FLUSH_B, 0, 1000000); > + if (ret) > + dev_warn(c->vc.chan.device->dev, "tx: fail, debug=0x%x\n", > + mtk_uart_apdma_read(c, VFF_DEBUG_STATUS)); > + > + send = min_t(unsigned int, left, c->desc->avail_len); > + wpt = mtk_uart_apdma_read(c, VFF_WPT); > + len = mtk_uart_apdma_read(c, VFF_LEN); > + > + d_wpt = wpt + send; > + if ((d_wpt & VFF_RING_SIZE) >= len) { > + d_wpt = d_wpt - len; > + d_wpt = d_wpt ^ VFF_RING_WRAP; > + } > + mtk_uart_apdma_write(c, VFF_WPT, d_wpt); > + > + c->desc->avail_len -= send; > + > + mtk_uart_apdma_write(c, VFF_INT_EN, VFF_TX_INT_EN_B); > + if (mtk_uart_apdma_read(c, VFF_FLUSH) == 0U) > + mtk_uart_apdma_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 len, wg, rg, cnt; > + > + if ((mtk_uart_apdma_read(c, VFF_VALID_SIZE) == 0U) || > + !d || !vchan_next_desc(&c->vc)) > + return; > + > + len = mtk_uart_apdma_read(c, VFF_LEN); > + rg = mtk_uart_apdma_read(c, VFF_RPT); > + wg = mtk_uart_apdma_read(c, VFF_WPT); > + if ((rg ^ wg) & VFF_RING_WRAP) > + cnt = (wg & VFF_RING_SIZE) + len - (rg & VFF_RING_SIZE); > + else > + cnt = (wg & VFF_RING_SIZE) - (rg & VFF_RING_SIZE); > + > + c->rx_status = cnt; > + mtk_uart_apdma_write(c, VFF_RPT, wg); > + > + list_del(&d->vd.node); > + vchan_cookie_complete(&d->vd); > +} this looks odd, why do you have different rx and tx start routines? > +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 tmp; > + int ret; > + > + pm_runtime_get_sync(mtkd->ddev.dev); > + > + mtk_uart_apdma_write(c, VFF_ADDR, 0); > + mtk_uart_apdma_write(c, VFF_THRE, 0); > + mtk_uart_apdma_write(c, VFF_LEN, 0); > + mtk_uart_apdma_write(c, VFF_RST, VFF_WARM_RST_B); > + > + ret = readx_poll_timeout(readl, c->base + VFF_EN, tmp, > + tmp == 0, 10, 100); > + if (ret) { > + dev_err(chan->device->dev, "dma reset: fail, timeout\n"); > + return ret; > + } register read does reset? > + > + 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); why is the irq not requested in driver probe? > +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_read(c, VFF_RPT) & VFF_RING_SIZE; > + dma_set_residue(txstate, c->rx_status); > + } else if (ret == DMA_COMPLETE && c->cfg.direction == DMA_DEV_TO_MEM) { why set reside when it is complete? also reside can be null, that should be checked as well > +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; > + } we have a macro for this > + > + /* Now allocate and setup the descriptor */ > + d = kzalloc(sizeof(*d), GFP_ATOMIC); > + if (!d) > + return NULL; > + > + /* sglen is 1 */ ? > +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) { fg->direction is deprecated, in fact I have removed all users recently, please do not use this > + unsigned int rx_len = cfg->src_addr_width * 1024; > + > + mtk_uart_apdma_write(c, VFF_ADDR, cfg->src_addr); > + mtk_uart_apdma_write(c, VFF_LEN, rx_len); > + mtk_uart_apdma_write(c, VFF_THRE, VFF_RX_THRE(rx_len)); > + mtk_uart_apdma_write(c, VFF_INT_EN, > + VFF_RX_INT_EN0_B | VFF_RX_INT_EN1_B); > + mtk_uart_apdma_write(c, VFF_RPT, 0); > + mtk_uart_apdma_write(c, VFF_INT_FLAG, VFF_RX_INT_FLAG_CLR_B); > + mtk_uart_apdma_write(c, VFF_EN, VFF_EN_B); why are we writing this here, we are supposed to do that when txn starts! > +static int mtk_uart_apdma_device_resume(struct dma_chan *chan) > +{ > + /* just for check caps pass */ > + return 0; > +} if you do not support this please remove this! > +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", }, where is the binding document for ediatek,mt6577-uart-dma ?? -- ~Vinod