Received: by 2002:ac0:aa62:0:0:0:0:0 with SMTP id w31-v6csp392291ima; Sat, 20 Oct 2018 09:27:32 -0700 (PDT) X-Google-Smtp-Source: ACcGV62UZ+/ckj6n+zorGQ30r71Dx7z4k7YMfnHa1PaLN4+vnx79Foy/fATLv3ZCQdE9PiZ80Q7/ X-Received: by 2002:a17:902:59d2:: with SMTP id d18-v6mr6433843plj.116.1540052852561; Sat, 20 Oct 2018 09:27:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540052852; cv=none; d=google.com; s=arc-20160816; b=HtK3UTItw2+aGQosnijx1nEfmUEQ6sQ3IktYqr7QaPebLiJXRzTFtfop5NMAikckSd F/AF7daOXcdxZe/WYCQuvZWNOtTtCSd1mGsUPVcGYoiHymFfli6obbanp4eMvavAPdvy xmL4JsrKdw0Wt5KqI+zndwKuPJrjKE62jLdfyxJW4K8r2Txowke11bHdooelBs309Zbe 7tlwv6uio/mbUxNNQM93bhHQ2cVZnnarPlt1HGmipMTG18D/9hz94Xv7b25sNdmBNuxd CD3+2oIAxMwNf8ghoSz1RHetSjW5cZBWzEcF60rAJ0M8sa7LyXPzSbJU6sjC3lzbn1G7 Rd4A== 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=aXoYe3L12fdO+O8LCu6n0ArXY+xFob6aZR4Po9gXSl0=; b=n0f8usMTJDwq0sUtNWxaF2Meu4wdFgUBfr3+aiWcUr+CtgzqAWPJ9T60G+BzrD7IjA u87zyoM/KdYoSV53gNCXckBr7tcN8GeXwUdsvoH7OScvWXxU1hWdCnbL/zf7RcAVuUu/ xm3gESUmrY0LQsThWeFlpnnhObe9UCc4us6Nw7tjEqHGWzt2VvPvawubTjRhg5z3zQi8 4QWsbLV7INu8339JVgTm1sSpL1XixZjr8EQ424r9HX5PBt8m4UHslS0W7c/f45nrGlKc qYZcOvvTpV96Axc21ZjtdVsjLHBnlGAZVkqd7DzP+46dnhMSZaiFEjtVp13oQtMkDVF8 bTQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=E8QiJ04+; 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 g11-v6si26981572plp.128.2018.10.20.09.27.01; Sat, 20 Oct 2018 09:27:32 -0700 (PDT) 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=E8QiJ04+; 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 S1727611AbeJUAh1 (ORCPT + 99 others); Sat, 20 Oct 2018 20:37:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:45186 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727485AbeJUAh1 (ORCPT ); Sat, 20 Oct 2018 20:37:27 -0400 Received: from localhost (unknown [109.144.218.90]) (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 755E72157C; Sat, 20 Oct 2018 16:26:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1540052787; bh=+9lQvA3kKmPLDcwdgOmvwuz3IurevflUfdpChJlC9wo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=E8QiJ04+6a1rKaU5EwM5/iw+FEfcUUCpfW9hxWb9tawCUvG8tdDGUpaPY48Rz42lb s129Fbr6qF7WW2bIF9zbRxJlXknXWyt5O4M7mDCKF1dgDw5kETA5efmdfAYCkdHHR4 1ezLdYPsqUhy0bwgnlCgkXf0eb2kAfat2pqMI8vQ= Date: Sat, 20 Oct 2018 21:56:24 +0530 From: Vinod To: "sudheer.v" Cc: Benjamin Herrenschmidt , Rob Herring , Mark Rutland , Greg Kroah-Hartman , Joel Stanley , Andrew Jeffery , Russell King , Dan Williams , Jiri Slaby , Thomas Gleixner , Marc Zyngier , Christian Borntraeger , Michael Moese , Hendrik Brueckner , Kate Stewart , Philippe Ombredanne , dmaengine@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, Sudheer V , ShivahShankar Shakarnarayan rao Subject: Re: [[PATCH] 8/9] DMA-UART-Driver-for-AST2500 Message-ID: <20181020162624.GC2894@vkoul-mobl> References: <1539749466-3912-1-git-send-email-open.sudheer@gmail.com> <1539749466-3912-9-git-send-email-open.sudheer@gmail.com> <20181017060531.GU2400@vkoul-mobl> <351eecd5b1b21893e94f76b34c058c6257b7f837.camel@kernel.crashing.org> <20181018095507.GC2400@vkoul-mobl> <20181019071154.GE13642@Pilot130> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181019071154.GE13642@Pilot130> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19-10-18, 12:41, sudheer.v wrote: > On Fri, Oct 19, 2018 at 10:32:24AM +1100, Benjamin Herrenschmidt wrote: > > On Thu, 2018-10-18 at 15:25 +0530, Vinod wrote: > > > > > > > It's not a dmaengine driver. It's a serial UART driver that happens to > > > > use a dedicated DMA engine. > > > > > > Then I see no reason for it to use dmaengine APIs. The framework allows > > > people to share a controller for many clients, but if you have dedicated > > > one then you may use it directly > > > > Well... the engine is shared by a few UARTs, they have dedicated rings > > but there's a common set of regs for interrupt handling etc. > > > > That said, I still think it could be contained within a UART driver, > > there's little benefit in adding the framework overhead, esp since > > these are really weak cores, any overhead will be felt. > > > > Ben. > > > > > > It's unclear whether it should be split into two drivers, or just have > > > > the serial driver directly use the dma engine since that engine is > > > > dedicated in HW to only work on those UARTs and nothing else... > > > > > > > > Cheers, > > > > Ben. > > Initially we wanted to have a single driver, > however we had an informal discussion with one of the maintainer > and based on the feedback, followed the Linux DMA and UART architecture. > > If this seperate DMA-engine driver adds more overhead than benifit, > we will merge them into a single UART driver and resubmitt the patches. > Vinod, > can this dma-controller driver sit under dma subsystem?. > or better to move it under UART framework. My advise would be to see what you can do with the DMA IP block. If this can/would be used in different places then it would make sense to do a dmaengine driver and solve the problem for everyone. If this is always going to be hidden behind serial then maybe it makes sense to be inside serial driver and not use dmaengine APIs If you decide to prefer the former case, please move it to dmaengine and resubmit :) HTH -- ~Vinod