From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [[PATCH] 8/9] DMA-UART-Driver-for-AST2500 From: Vinod Koul Message-Id: <20181020162624.GC2894@vkoul-mobl> Date: Sat, 20 Oct 2018 21:56:24 +0530 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 List-ID: T24gMTktMTAtMTgsIDEyOjQxLCBzdWRoZWVyLnYgd3JvdGU6Cj4gT24gRnJpLCBPY3QgMTksIDIw MTggYXQgMTA6MzI6MjRBTSArMTEwMCwgQmVuamFtaW4gSGVycmVuc2NobWlkdCB3cm90ZToKPiA+ IE9uIFRodSwgMjAxOC0xMC0xOCBhdCAxNToyNSArMDUzMCwgVmlub2Qgd3JvdGU6Cj4gPiA+IAo+ ID4gPiA+IEl0J3Mgbm90IGEgZG1hZW5naW5lIGRyaXZlci4gSXQncyBhIHNlcmlhbCBVQVJUIGRy aXZlciB0aGF0IGhhcHBlbnMgdG8KPiA+ID4gPiB1c2UgYSBkZWRpY2F0ZWQgRE1BIGVuZ2luZS4K PiA+ID4gCj4gPiA+IFRoZW4gSSBzZWUgbm8gcmVhc29uIGZvciBpdCB0byB1c2UgZG1hZW5naW5l IEFQSXMuIFRoZSBmcmFtZXdvcmsgYWxsb3dzCj4gPiA+IHBlb3BsZSB0byBzaGFyZSBhIGNvbnRy b2xsZXIgZm9yIG1hbnkgY2xpZW50cywgYnV0IGlmIHlvdSBoYXZlIGRlZGljYXRlZAo+ID4gPiBv bmUgdGhlbiB5b3UgbWF5IHVzZSBpdCBkaXJlY3RseQo+ID4gCj4gPiBXZWxsLi4uIHRoZSBlbmdp bmUgaXMgc2hhcmVkIGJ5IGEgZmV3IFVBUlRzLCB0aGV5IGhhdmUgZGVkaWNhdGVkIHJpbmdzCj4g PiBidXQgdGhlcmUncyBhIGNvbW1vbiBzZXQgb2YgcmVncyBmb3IgaW50ZXJydXB0IGhhbmRsaW5n IGV0Yy4KPiA+IAo+ID4gVGhhdCBzYWlkLCBJIHN0aWxsIHRoaW5rIGl0IGNvdWxkIGJlIGNvbnRh aW5lZCB3aXRoaW4gYSBVQVJUIGRyaXZlciwKPiA+IHRoZXJlJ3MgbGl0dGxlIGJlbmVmaXQgaW4g YWRkaW5nIHRoZSBmcmFtZXdvcmsgb3ZlcmhlYWQsIGVzcCBzaW5jZQo+ID4gdGhlc2UgYXJlIHJl YWxseSB3ZWFrIGNvcmVzLCBhbnkgb3ZlcmhlYWQgd2lsbCBiZSBmZWx0Lgo+ID4gCj4gPiBCZW4u Cj4gPiAKPiA+ID4gPiBJdCdzIHVuY2xlYXIgd2hldGhlciBpdCBzaG91bGQgYmUgc3BsaXQgaW50 byB0d28gZHJpdmVycywgb3IganVzdCBoYXZlCj4gPiA+ID4gdGhlIHNlcmlhbCBkcml2ZXIgZGly ZWN0bHkgdXNlIHRoZSBkbWEgZW5naW5lIHNpbmNlIHRoYXQgZW5naW5lIGlzCj4gPiA+ID4gZGVk aWNhdGVkIGluIEhXIHRvIG9ubHkgd29yayBvbiB0aG9zZSBVQVJUcyBhbmQgbm90aGluZyBlbHNl Li4uCj4gPiA+ID4gCj4gPiA+ID4gQ2hlZXJzLAo+ID4gPiA+IEJlbi4KPiAKPiBJbml0aWFsbHkg d2Ugd2FudGVkIHRvIGhhdmUgIGEgc2luZ2xlIGRyaXZlciwKPiBob3dldmVyIHdlIGhhZCBhbiBp bmZvcm1hbCBkaXNjdXNzaW9uIHdpdGggb25lIG9mIHRoZSBtYWludGFpbmVyIAo+IGFuZCBiYXNl ZCBvbiB0aGUgZmVlZGJhY2ssIGZvbGxvd2VkIHRoZSBMaW51eCBETUEgYW5kIFVBUlQgYXJjaGl0 ZWN0dXJlLgo+IAo+IElmIHRoaXMgc2VwZXJhdGUgRE1BLWVuZ2luZSBkcml2ZXIgYWRkcyBtb3Jl IG92ZXJoZWFkIHRoYW4gYmVuaWZpdCwKPiB3ZSB3aWxsIG1lcmdlIHRoZW0gaW50byBhIHNpbmds ZSBVQVJUIGRyaXZlciBhbmQgcmVzdWJtaXR0IHRoZSBwYXRjaGVzLgo+IFZpbm9kLAo+ICAgICAg IGNhbiB0aGlzIGRtYS1jb250cm9sbGVyIGRyaXZlciBzaXQgdW5kZXIgZG1hIHN1YnN5c3RlbT8u Cj4gICAgICAgb3IgYmV0dGVyIHRvIG1vdmUgaXQgdW5kZXIgVUFSVCBmcmFtZXdvcmsuCgoKTXkg YWR2aXNlIHdvdWxkIGJlIHRvIHNlZSB3aGF0IHlvdSBjYW4gZG8gd2l0aCB0aGUgRE1BIElQIGJs b2NrLiBJZiB0aGlzCmNhbi93b3VsZCBiZSB1c2VkIGluIGRpZmZlcmVudCBwbGFjZXMgdGhlbiBp dCB3b3VsZCBtYWtlIHNlbnNlIHRvIGRvIGEKZG1hZW5naW5lIGRyaXZlciBhbmQgc29sdmUgdGhl IHByb2JsZW0gZm9yIGV2ZXJ5b25lLgoKSWYgdGhpcyBpcyBhbHdheXMgZ29pbmcgdG8gYmUgaGlk ZGVuIGJlaGluZCBzZXJpYWwgdGhlbiBtYXliZSBpdCBtYWtlcwpzZW5zZSB0byBiZSBpbnNpZGUg c2VyaWFsIGRyaXZlciBhbmQgbm90IHVzZSBkbWFlbmdpbmUgQVBJcwoKSWYgeW91IGRlY2lkZSB0 byBwcmVmZXIgdGhlIGZvcm1lciBjYXNlLCBwbGVhc2UgbW92ZSBpdCB0byBkbWFlbmdpbmUgYW5k CnJlc3VibWl0IDopCgpIVEgK From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinod Date: Sat, 20 Oct 2018 21:56:24 +0530 Subject: [[PATCH] 8/9] DMA-UART-Driver-for-AST2500 In-Reply-To: <20181019071154.GE13642@Pilot130> 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> Message-ID: <20181020162624.GC2894@vkoul-mobl> List-Id: To: linux-aspeed@lists.ozlabs.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinod Subject: Re: [[PATCH] 8/9] DMA-UART-Driver-for-AST2500 Date: Sat, 20 Oct 2018 21:56:24 +0530 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 Return-path: Content-Disposition: inline In-Reply-To: <20181019071154.GE13642@Pilot130> Sender: linux-kernel-owner@vger.kernel.org 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 List-Id: linux-serial@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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: vkoul@kernel.org (Vinod) Date: Sat, 20 Oct 2018 21:56:24 +0530 Subject: [[PATCH] 8/9] DMA-UART-Driver-for-AST2500 In-Reply-To: <20181019071154.GE13642@Pilot130> 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> Message-ID: <20181020162624.GC2894@vkoul-mobl> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B5D3C67863 for ; Sat, 20 Oct 2018 16:26:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1E12D21582 for ; Sat, 20 Oct 2018 16:26:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="E8QiJ04+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1E12D21582 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727637AbeJUAh1 (ORCPT ); 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