Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756327AbdIHOhO (ORCPT ); Fri, 8 Sep 2017 10:37:14 -0400 Received: from mail.free-electrons.com ([62.4.15.54]:52203 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755880AbdIHOhL (ORCPT ); Fri, 8 Sep 2017 10:37:11 -0400 Date: Fri, 8 Sep 2017 16:37:10 +0200 From: Maxime Ripard To: =?iso-8859-1?B?QnL8bnMs?= Stefan Cc: "linux-sunxi@googlegroups.com" , "devicetree@vger.kernel.org" , "dmaengine@vger.kernel.org" , Vinod Koul , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Chen-Yu Tsai , Rob Herring , Code Kipper , Andre Przywara Subject: Re: [PATCH 05/10] dmaengine: sun6i: Move number of pchans/vchans/request to device struct Message-ID: <20170908143710.rhz6x3i776zrhbzo@flea.lan> References: <20170903224100.17893-1-stefan.bruens@rwth-aachen.de> <20170903224100.17893-6-stefan.bruens@rwth-aachen.de> <20170904074355.niloziky42aki7bg@flea> <3533197.81BdoSVRz8@sbruens-linux> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i5qul5ppysoi43r7" Content-Disposition: inline In-Reply-To: <3533197.81BdoSVRz8@sbruens-linux> User-Agent: NeoMutt/20170714 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3294 Lines: 85 --i5qul5ppysoi43r7 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 04, 2017 at 02:30:59PM +0000, Br=FCns, Stefan wrote: > On Montag, 4. September 2017 09:43:55 CEST Maxime Ripard wrote: > > On Mon, Sep 04, 2017 at 12:40:56AM +0200, Stefan Br=FCns wrote: > > > Preparatory patch: If the same compatible is used for different SoCs = which > > > have a common register layout, but different number of channels, the > > > channel count can no longer be stored in the config. Store it in the > > > device structure instead. > > >=20 > > > Signed-off-by: Stefan Br=FCns > >=20 > > As stated already, we already are going to have a different > > compatible, and this is not something that will change from one > > instance to the other. Having code is therefore: > > A) Making the code more complex > > B) For no particular reason. >=20 > If the dma channel count (which is a standard dma binding, likely for a= =20 > reason) goes into the devicetree, it has to be moved out of the config. > > The R40 (which has register manuals available) has the same register layo= ut as=20 > the A64, but *does* have a different channel count. So you think it is a = good=20 > idea to introduce a new compatible again? >=20 > If you had been half as picky when merging the H3 and A83T support, we wo= uld=20 > not have this mess now. >=20 > There is also the H6, where there is no register manual available yet, bu= t I =20 > bet it has the H3 (and A64, H5, R40) register layout, but unlikely the sa= me=20 > number of DMA channels *and* the same number of ports. The thing is that this kind of things usually grow organically until you can't just add a simple if case any more. I'm sorry you were at the tipping point, but I'm sure you also understand that adding more to the mess until the next one shows up isn't viable either. That being said, thinking a bit more on that one, if you add to the binding that we need to have both the current SoC compatible (to workaround any variation / bugs we might encounter in the future) and the "generation" one (to avoid adding one for each new IP), plus the mandatory dma-channels / dma-requests properties, that would work for me. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --i5qul5ppysoi43r7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJZsqsVAAoJEBx+YmzsjxAg5lwP/1NM3BKsC+biAcayiv3LsUTp FMiOu6HGOyOY66MWMvXXDL9OUyK3o1uE+1T2BNp1OoPwCU5w9WP1kF6F5k5JwdEm 95up+NEbHiwgwT73/QcckODnOzZzKG2/0GGnJzPugrMJjKmVRC2AzEPSOPnwS95B dNAN0kz21aaQA9iFaauBYSnthykrHD8l/XXAx4q1A45wk5C/VP0zT9dtPWwK0ACR WgivqD3Zc/vHoPfsacKbNW9pJITQn0eRrM+iHByH4x+8ZvhNveFxifzrV69JBIvg y/9Q195Ai7DsGcTY3MlxNrG3mebAg/JKqXeCCn9tPYlrnUqLyDD/YwBbFCizbe/M jWqSlGTVnLo1NRriqQTK/8eGLefR9ZN5VlWlHXP5dbRMIRNLMsG/kFNOiBO8R10p Hz3tsgORYHYdGtLTA225SDhBMt+BOPa0vDSqzBxQfA63NsfAnpOqE7HBs4yDjy9E afeUN8uTZPz7usI2f3MkRWTzN18ol8iKM84qGhrca6x9duti+cDHvmzRiaXUOKH0 jEuUGpXz/s+Ht6Br4HXU02Ajdu+RkuWD+8jDPBcIUIBKj9PXFKIOYoPkE3PXRZHq 9lUmdUS4hLL4W6ahTbLuMyiR0go/DKZ0xJsDrhL9KvalEe0Rl20rbwNHG534b2Jh daIuXZN8NFLnYxShlN+g =OUsa -----END PGP SIGNATURE----- --i5qul5ppysoi43r7--