From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756293Ab3BDQrw (ORCPT ); Mon, 4 Feb 2013 11:47:52 -0500 Received: from devils.ext.ti.com ([198.47.26.153]:43792 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755613Ab3BDQrt (ORCPT ); Mon, 4 Feb 2013 11:47:49 -0500 Date: Mon, 4 Feb 2013 18:47:12 +0200 From: Felipe Balbi To: Sergei Shtylyov CC: , Russell King - ARM Linux , Matt Porter , Linux DaVinci Kernel List , Chris Ball , "Cousson, Benoit" , Arnd Bergmann , Linux Documentation List , Tony Lindgren , Devicetree Discuss , Mark Brown , Linux MMC List , Linux Kernel Mailing List , Rob Herring , Grant Likely , Vinod Koul , Rob Landley , Dan Williams , Linux SPI Devel List , Linux OMAP List , Linux ARM Kernel List Subject: Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common Message-ID: <20130204164712.GB4269@arwen.pp.htv.fi> Reply-To: References: <1359742975-10421-2-git-send-email-mporter@ti.com> <5022f635a527470dbd0be932063e9cd2@DFLE72.ent.ti.com> <20130201184915.GP2244@beef> <510C1D0E.6030401@mvista.com> <20130201185820.GE29898@arwen.pp.htv.fi> <510C2A47.1090607@mvista.com> <20130201205600.GA31762@arwen.pp.htv.fi> <20130201213003.GW2637@n2100.arm.linux.org.uk> <20130204154153.GA18237@arwen.pp.htv.fi> <510FF1A6.403@mvista.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dTy3Mrz/UPE2dbVg" Content-Disposition: inline In-Reply-To: <510FF1A6.403@mvista.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote: > > opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1, > > Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver. >=20 > > Granted, CPPI 4.1 makes some assumptions about the fact that it's > > handling USB tranfers, >=20 > What CPPI 4.1 code makes this assumptions? MUSB DMA driver? Then it's = just HW makes the asumptions > > but nevertheless, the IP can be, and in fact is, > > used with many different DMA engines and driver needs to cope with it. >=20 > What IP, CPPI 4.1 or MUSB? MUSB > > Current DMA abstraction is quite poor, for example there's no way to > > compile support for multiple DMA engines. Code also makes certain, IMO > > unnecessary, assumptions about the underlying DMA engine (abstraction is > > poor, as said above but it we could follow MUSB's programming guide when > > it comes to programming DMA transfers). >=20 > Don't know, I was quite content with the abstraction when writing CPPI= 4.1 > driver for MUSB... look closer. The whole: if (is_cppi()) foo(); else if (is_inventra()) bar(); else if (is_omap_sdma()) baz(); is bogus. > > Considering all of the above, it's far better to use DMA engine and get > > rid of all the mess. >=20 > In my eyes, getting rid of the mess doesn't justify breaking the rules= that > Russell formulated above. MUSB is no PCI, there is no single, standard interface to the DMA engine (unlike Synopsys' dwc-usb3 and dwc-usb2, where we don't use DMA engine), every DMA engine comes with its own set of registers, its own programming model and so forth. --=20 balbi --dTy3Mrz/UPE2dbVg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRD+YQAAoJEIaOsuA1yqREBdEQAIdS03SIpNCILhGxYd5xrVgC pWFFJc/tQ4bWPqyYZsN/emeqBfX2kOlbDOmVw1Uj0V/nkKnPH1TmA7GRVmughaiH R6yKgYlU/2hi0ilqW+DJ/74XCtncdXEmUCFilaxhkyP1npfLN8dmjX7tgHdHwva8 vQHUBs2H5c7+dqGQCTNi3smE4i1dgVeTb+ckP3Ery8IiTZgSFoEoJpLWJACUk39i 4hrAMTuYCYWnxOK/XfRhs+M6qID6VLQTAkxu6ndRHmOEaAuE4KJBU/QmTSfOD7wu Mx3cEPguamEgf4DytrqZpKZ7m5qjB/W+wC30SYVdQtGMihqCDCdFxVGGgMbQj64/ fuiZHftzKwCCY8OJAbVTNPYJ6y/vf8aQl8ft/Fal07c/pdNXhkJA84DHT/1Abo4r /seD8ZAk1iyduKaXFtubmd3Iq27KV6/s0A7hgyQUwkKhN8V+klxGMszvoIjlrTds eO5XfPIx0MMXzKn3gUADMjcKLTNh3GcM/boxzG8/ySacZr+guvWCPnDlXTuQsZFt oSRVPgXOdKy+m+z6AQtsb3LH1QNbuOd1dgVKJYlC7rULeUmgQJCOxsdsaJFg557J ookEDb7W/oYwvKjM7cBpNEYnIlc4PPqBM8XdyImoFlau7FSanv9+6wUhDM6a5UVl jECLvstr45ncnhjrTyg1 =T5H9 -----END PGP SIGNATURE----- --dTy3Mrz/UPE2dbVg-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felipe Balbi Subject: Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common Date: Mon, 4 Feb 2013 18:47:12 +0200 Message-ID: <20130204164712.GB4269@arwen.pp.htv.fi> References: <1359742975-10421-2-git-send-email-mporter@ti.com> <5022f635a527470dbd0be932063e9cd2@DFLE72.ent.ti.com> <20130201184915.GP2244@beef> <510C1D0E.6030401@mvista.com> <20130201185820.GE29898@arwen.pp.htv.fi> <510C2A47.1090607@mvista.com> <20130201205600.GA31762@arwen.pp.htv.fi> <20130201213003.GW2637@n2100.arm.linux.org.uk> <20130204154153.GA18237@arwen.pp.htv.fi> <510FF1A6.403@mvista.com> Reply-To: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dTy3Mrz/UPE2dbVg" Return-path: Content-Disposition: inline In-Reply-To: <510FF1A6.403@mvista.com> Sender: linux-doc-owner@vger.kernel.org To: Sergei Shtylyov Cc: balbi@ti.com, Russell King - ARM Linux , Matt Porter , Linux DaVinci Kernel List , Chris Ball , "Cousson, Benoit" , Arnd Bergmann , Linux Documentation List , Tony Lindgren , Devicetree Discuss , Mark Brown , Linux MMC List , Linux Kernel Mailing List , Rob Herring , Grant Likely , Vinod Koul , Rob Landley , Dan Williams , Linux SPI Devel List , Linux OMAP List Linux List-Id: devicetree@vger.kernel.org --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote: > > opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1, > > Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver. >=20 > > Granted, CPPI 4.1 makes some assumptions about the fact that it's > > handling USB tranfers, >=20 > What CPPI 4.1 code makes this assumptions? MUSB DMA driver? Then it's = just HW makes the asumptions > > but nevertheless, the IP can be, and in fact is, > > used with many different DMA engines and driver needs to cope with it. >=20 > What IP, CPPI 4.1 or MUSB? MUSB > > Current DMA abstraction is quite poor, for example there's no way to > > compile support for multiple DMA engines. Code also makes certain, IMO > > unnecessary, assumptions about the underlying DMA engine (abstraction is > > poor, as said above but it we could follow MUSB's programming guide when > > it comes to programming DMA transfers). >=20 > Don't know, I was quite content with the abstraction when writing CPPI= 4.1 > driver for MUSB... look closer. The whole: if (is_cppi()) foo(); else if (is_inventra()) bar(); else if (is_omap_sdma()) baz(); is bogus. > > Considering all of the above, it's far better to use DMA engine and get > > rid of all the mess. >=20 > In my eyes, getting rid of the mess doesn't justify breaking the rules= that > Russell formulated above. MUSB is no PCI, there is no single, standard interface to the DMA engine (unlike Synopsys' dwc-usb3 and dwc-usb2, where we don't use DMA engine), every DMA engine comes with its own set of registers, its own programming model and so forth. --=20 balbi --dTy3Mrz/UPE2dbVg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRD+YQAAoJEIaOsuA1yqREBdEQAIdS03SIpNCILhGxYd5xrVgC pWFFJc/tQ4bWPqyYZsN/emeqBfX2kOlbDOmVw1Uj0V/nkKnPH1TmA7GRVmughaiH R6yKgYlU/2hi0ilqW+DJ/74XCtncdXEmUCFilaxhkyP1npfLN8dmjX7tgHdHwva8 vQHUBs2H5c7+dqGQCTNi3smE4i1dgVeTb+ckP3Ery8IiTZgSFoEoJpLWJACUk39i 4hrAMTuYCYWnxOK/XfRhs+M6qID6VLQTAkxu6ndRHmOEaAuE4KJBU/QmTSfOD7wu Mx3cEPguamEgf4DytrqZpKZ7m5qjB/W+wC30SYVdQtGMihqCDCdFxVGGgMbQj64/ fuiZHftzKwCCY8OJAbVTNPYJ6y/vf8aQl8ft/Fal07c/pdNXhkJA84DHT/1Abo4r /seD8ZAk1iyduKaXFtubmd3Iq27KV6/s0A7hgyQUwkKhN8V+klxGMszvoIjlrTds eO5XfPIx0MMXzKn3gUADMjcKLTNh3GcM/boxzG8/ySacZr+guvWCPnDlXTuQsZFt oSRVPgXOdKy+m+z6AQtsb3LH1QNbuOd1dgVKJYlC7rULeUmgQJCOxsdsaJFg557J ookEDb7W/oYwvKjM7cBpNEYnIlc4PPqBM8XdyImoFlau7FSanv9+6wUhDM6a5UVl jECLvstr45ncnhjrTyg1 =T5H9 -----END PGP SIGNATURE----- --dTy3Mrz/UPE2dbVg-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felipe Balbi Subject: Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common Date: Mon, 4 Feb 2013 18:47:12 +0200 Message-ID: <20130204164712.GB4269@arwen.pp.htv.fi> References: <1359742975-10421-2-git-send-email-mporter@ti.com> <5022f635a527470dbd0be932063e9cd2@DFLE72.ent.ti.com> <20130201184915.GP2244@beef> <510C1D0E.6030401@mvista.com> <20130201185820.GE29898@arwen.pp.htv.fi> <510C2A47.1090607@mvista.com> <20130201205600.GA31762@arwen.pp.htv.fi> <20130201213003.GW2637@n2100.arm.linux.org.uk> <20130204154153.GA18237@arwen.pp.htv.fi> <510FF1A6.403@mvista.com> Reply-To: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dTy3Mrz/UPE2dbVg" Cc: , Russell King - ARM Linux , Matt Porter , Linux DaVinci Kernel List , Chris Ball , "Cousson, Benoit" , Arnd Bergmann , Linux Documentation List , Tony Lindgren , Devicetree Discuss , Mark Brown , Linux MMC List , Linux Kernel Mailing List , Rob Herring , Grant Likely , Vinod Koul , Rob Landley , Dan Williams , Linux SPI Devel List , Linux OMAP List , Linux ARM Kernel Lis To: Sergei Shtylyov Return-path: Content-Disposition: inline In-Reply-To: <510FF1A6.403@mvista.com> Sender: linux-doc-owner@vger.kernel.org List-Id: linux-spi.vger.kernel.org --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote: > > opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1, > > Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver. >=20 > > Granted, CPPI 4.1 makes some assumptions about the fact that it's > > handling USB tranfers, >=20 > What CPPI 4.1 code makes this assumptions? MUSB DMA driver? Then it's = just HW makes the asumptions > > but nevertheless, the IP can be, and in fact is, > > used with many different DMA engines and driver needs to cope with it. >=20 > What IP, CPPI 4.1 or MUSB? MUSB > > Current DMA abstraction is quite poor, for example there's no way to > > compile support for multiple DMA engines. Code also makes certain, IMO > > unnecessary, assumptions about the underlying DMA engine (abstraction is > > poor, as said above but it we could follow MUSB's programming guide when > > it comes to programming DMA transfers). >=20 > Don't know, I was quite content with the abstraction when writing CPPI= 4.1 > driver for MUSB... look closer. The whole: if (is_cppi()) foo(); else if (is_inventra()) bar(); else if (is_omap_sdma()) baz(); is bogus. > > Considering all of the above, it's far better to use DMA engine and get > > rid of all the mess. >=20 > In my eyes, getting rid of the mess doesn't justify breaking the rules= that > Russell formulated above. MUSB is no PCI, there is no single, standard interface to the DMA engine (unlike Synopsys' dwc-usb3 and dwc-usb2, where we don't use DMA engine), every DMA engine comes with its own set of registers, its own programming model and so forth. --=20 balbi --dTy3Mrz/UPE2dbVg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRD+YQAAoJEIaOsuA1yqREBdEQAIdS03SIpNCILhGxYd5xrVgC pWFFJc/tQ4bWPqyYZsN/emeqBfX2kOlbDOmVw1Uj0V/nkKnPH1TmA7GRVmughaiH R6yKgYlU/2hi0ilqW+DJ/74XCtncdXEmUCFilaxhkyP1npfLN8dmjX7tgHdHwva8 vQHUBs2H5c7+dqGQCTNi3smE4i1dgVeTb+ckP3Ery8IiTZgSFoEoJpLWJACUk39i 4hrAMTuYCYWnxOK/XfRhs+M6qID6VLQTAkxu6ndRHmOEaAuE4KJBU/QmTSfOD7wu Mx3cEPguamEgf4DytrqZpKZ7m5qjB/W+wC30SYVdQtGMihqCDCdFxVGGgMbQj64/ fuiZHftzKwCCY8OJAbVTNPYJ6y/vf8aQl8ft/Fal07c/pdNXhkJA84DHT/1Abo4r /seD8ZAk1iyduKaXFtubmd3Iq27KV6/s0A7hgyQUwkKhN8V+klxGMszvoIjlrTds eO5XfPIx0MMXzKn3gUADMjcKLTNh3GcM/boxzG8/ySacZr+guvWCPnDlXTuQsZFt oSRVPgXOdKy+m+z6AQtsb3LH1QNbuOd1dgVKJYlC7rULeUmgQJCOxsdsaJFg557J ookEDb7W/oYwvKjM7cBpNEYnIlc4PPqBM8XdyImoFlau7FSanv9+6wUhDM6a5UVl jECLvstr45ncnhjrTyg1 =T5H9 -----END PGP SIGNATURE----- --dTy3Mrz/UPE2dbVg-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: balbi@ti.com (Felipe Balbi) Date: Mon, 4 Feb 2013 18:47:12 +0200 Subject: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common In-Reply-To: <510FF1A6.403@mvista.com> References: <1359742975-10421-2-git-send-email-mporter@ti.com> <5022f635a527470dbd0be932063e9cd2@DFLE72.ent.ti.com> <20130201184915.GP2244@beef> <510C1D0E.6030401@mvista.com> <20130201185820.GE29898@arwen.pp.htv.fi> <510C2A47.1090607@mvista.com> <20130201205600.GA31762@arwen.pp.htv.fi> <20130201213003.GW2637@n2100.arm.linux.org.uk> <20130204154153.GA18237@arwen.pp.htv.fi> <510FF1A6.403@mvista.com> Message-ID: <20130204164712.GB4269@arwen.pp.htv.fi> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote: > > opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1, > > Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver. > > > Granted, CPPI 4.1 makes some assumptions about the fact that it's > > handling USB tranfers, > > What CPPI 4.1 code makes this assumptions? MUSB DMA driver? Then it's just HW makes the asumptions > > but nevertheless, the IP can be, and in fact is, > > used with many different DMA engines and driver needs to cope with it. > > What IP, CPPI 4.1 or MUSB? MUSB > > Current DMA abstraction is quite poor, for example there's no way to > > compile support for multiple DMA engines. Code also makes certain, IMO > > unnecessary, assumptions about the underlying DMA engine (abstraction is > > poor, as said above but it we could follow MUSB's programming guide when > > it comes to programming DMA transfers). > > Don't know, I was quite content with the abstraction when writing CPPI 4.1 > driver for MUSB... look closer. The whole: if (is_cppi()) foo(); else if (is_inventra()) bar(); else if (is_omap_sdma()) baz(); is bogus. > > Considering all of the above, it's far better to use DMA engine and get > > rid of all the mess. > > In my eyes, getting rid of the mess doesn't justify breaking the rules that > Russell formulated above. MUSB is no PCI, there is no single, standard interface to the DMA engine (unlike Synopsys' dwc-usb3 and dwc-usb2, where we don't use DMA engine), every DMA engine comes with its own set of registers, its own programming model and so forth. -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: