* Re: [PATCH v10] dmaengine: Add MOXA ART DMA engine driver [not found] ` <1381155034-11254-1-git-send-email-jonas.jensen@gmail.com> @ 2013-10-07 15:12 ` Mark Rutland [not found] ` <20131007151212.GF15365-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> 0 siblings, 1 reply; 3+ messages in thread From: Mark Rutland @ 2013-10-07 15:12 UTC (permalink / raw) To: Jonas Jensen Cc: devicetree, linux@arm.linux.org.uk, arnd@arndb.de, vinod.koul@intel.com, linux-kernel@vger.kernel.org, arm@kernel.org, djbw@fb.com, linux-arm-kernel@lists.infradead.org [adding devicetree] On Mon, Oct 07, 2013 at 03:10:34PM +0100, Jonas Jensen wrote: > The MOXA ART SoC has a DMA controller capable of offloading expensive > memory operations, such as large copies. This patch adds support for > the controller including four channels. Two of these are used to > handle MMC copy on the UC-7112-LX hardware. The remaining two can be > used in a future audio driver or client application. > > Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com> > --- > > Notes: > Changes since v9: > > 1. reorder probe path, also move dma_async_device_register() to happen after devm_request_irq() > > Applies to next-20130927 > > .../devicetree/bindings/dma/moxa,moxart-dma.txt | 19 + > drivers/dma/Kconfig | 7 + > drivers/dma/Makefile | 1 + > drivers/dma/moxart-dma.c | 651 +++++++++++++++++++++ > 4 files changed, 678 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt > create mode 100644 drivers/dma/moxart-dma.c > > diff --git a/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt b/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt > new file mode 100644 > index 0000000..79facce > --- /dev/null > +++ b/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt > @@ -0,0 +1,19 @@ > +MOXA ART DMA Controller > + > +See dma.txt first > + > +Required properties: > + > +- compatible : Must be "moxa,moxart-dma" Sorry I didn't notice this previously, but "moxa" isn't in Documentation/devicetree/bindings/vendor-prefixes.txt (despite several bindings using it). Could you cook up a separate patch to add an entry for Moxa, please? Also, given the SoC is called "ART" it's a shame that we're calling this "moxa,moxart-dma" rather than "moxa,art-dma". We already have precedent for "moxart" in bindings though, so changing that's likely to lead to more problems. > +- reg : Should contain registers location and length > +- interrupts : Should contain the interrupt number Sorry for yet more pendantry, but could we instead have: - interrupts: Should contain an interrupt-specifier for the sole interrupt generated by the device. > +- #dma-cells : Should be 1, a single cell holding a line request number > + > +Example: > + > + dma: dma@90500000 { > + compatible = "moxa,moxart-dma"; > + reg = <0x90500080 0x40>; > + interrupts = <24 0>; > + #dma-cells = <1>; > + }; Otherwise I think the binding looks OK. Thanks, Mark ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <20131007151212.GF15365-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>]
* Re: [PATCH v10] dmaengine: Add MOXA ART DMA engine driver [not found] ` <20131007151212.GF15365-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> @ 2013-10-08 9:53 ` Jonas Jensen 2013-10-08 12:55 ` Mark Rutland 0 siblings, 1 reply; 3+ messages in thread From: Jonas Jensen @ 2013-10-08 9:53 UTC (permalink / raw) To: Mark Rutland Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, djbw-b10kYP2dOMg@public.gmane.org, arnd-r2nGTMty4D4@public.gmane.org, linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA On 7 October 2013 17:12, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote: > Sorry I didn't notice this previously, but "moxa" isn't in > Documentation/devicetree/bindings/vendor-prefixes.txt (despite several > bindings using it). Could you cook up a separate patch to add an entry > for Moxa, please? Yes, I'll submit a separate patch. > Also, given the SoC is called "ART" it's a shame that we're calling this > "moxa,moxart-dma" rather than "moxa,art-dma". We already have precedent > for "moxart" in bindings though, so changing that's likely to lead to > more problems. Sorry about that, I think the "moxart" contraction was suggested and has been sticky ever since. It's at least a little appropriate because the physical chip text reads "MOXA ART" (photo): https://lh4.googleusercontent.com/-A-2FXDrObU8/UMcMc_K2vEI/AAAAAAAABwg/ldaLZ7ps1P4/w1331-h998-no/UC-7112-LX-picture4.jpg Currently three drivers in linux-next use the name with accompanying device tree bindings. Considering the amount of patches required, can we keep the name, please? > Sorry for yet more pendantry, but could we instead have: > > - interrupts: Should contain an interrupt-specifier for the sole > interrupt generated by the device. Fixed in v11. Regards, Jonas -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v10] dmaengine: Add MOXA ART DMA engine driver 2013-10-08 9:53 ` Jonas Jensen @ 2013-10-08 12:55 ` Mark Rutland 0 siblings, 0 replies; 3+ messages in thread From: Mark Rutland @ 2013-10-08 12:55 UTC (permalink / raw) To: Jonas Jensen Cc: devicetree@vger.kernel.org, linux@arm.linux.org.uk, arnd@arndb.de, vinod.koul@intel.com, linux-kernel@vger.kernel.org, arm@kernel.org, djbw@fb.com, linux-arm-kernel@lists.infradead.org On Tue, Oct 08, 2013 at 10:53:36AM +0100, Jonas Jensen wrote: > On 7 October 2013 17:12, Mark Rutland <mark.rutland@arm.com> wrote: > > Sorry I didn't notice this previously, but "moxa" isn't in > > Documentation/devicetree/bindings/vendor-prefixes.txt (despite several > > bindings using it). Could you cook up a separate patch to add an entry > > for Moxa, please? > > Yes, I'll submit a separate patch. Cheers. > > > Also, given the SoC is called "ART" it's a shame that we're calling this > > "moxa,moxart-dma" rather than "moxa,art-dma". We already have precedent > > for "moxart" in bindings though, so changing that's likely to lead to > > more problems. > > Sorry about that, I think the "moxart" contraction was suggested and > has been sticky ever since. > > It's at least a little appropriate because the physical chip text > reads "MOXA ART" (photo): > > https://lh4.googleusercontent.com/-A-2FXDrObU8/UMcMc_K2vEI/AAAAAAAABwg/ldaLZ7ps1P4/w1331-h998-no/UC-7112-LX-picture4.jpg > > Currently three drivers in linux-next use the name with accompanying > device tree bindings. > Considering the amount of patches required, can we keep the name, please? Yeah, I think we have to keep it. It's not objectively wrong, and we have other contractions (e.g. vexpress) in bindings. It just looks a bit more odd than the others due to the repetition of "moxa". There's no benefit to be had changing it now. > > > Sorry for yet more pendantry, but could we instead have: > > > > - interrupts: Should contain an interrupt-specifier for the sole > > interrupt generated by the device. > > Fixed in v11. Sounds good. Cheers, Mark. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-10-08 12:55 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <1381151633-8576-1-git-send-email-jonas.jensen@gmail.com> [not found] ` <1381155034-11254-1-git-send-email-jonas.jensen@gmail.com> 2013-10-07 15:12 ` [PATCH v10] dmaengine: Add MOXA ART DMA engine driver Mark Rutland [not found] ` <20131007151212.GF15365-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> 2013-10-08 9:53 ` Jonas Jensen 2013-10-08 12:55 ` Mark Rutland
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).