From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: linux-next: manual merge of the arm-soc tree with the i2c-embedded tree Date: Wed, 18 Jul 2012 10:59:37 +0100 Message-ID: <20120718095937.GB22739@opensource.wolfsonmicro.com> References: <5003FB7C.4030509@linaro.org> <20120717130650.GB27595@sirena.org.uk> <500568D9.10805@linaro.org> <20120717133550.GC4477@opensource.wolfsonmicro.com> <50057058.2060002@linaro.org> <20120717142222.GE4477@opensource.wolfsonmicro.com> <50057C1A.80606@linaro.org> <20120717152001.GF4477@opensource.wolfsonmicro.com> <20120718053341.GA4009@S2100-06.ap.freescale.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+pHx0qQiF2pBVqBT" Return-path: Content-Disposition: inline In-Reply-To: <20120718053341.GA4009@S2100-06.ap.freescale.net> Sender: linux-next-owner@vger.kernel.org To: Shawn Guo Cc: Lee Jones , Stephen Rothwell , Linus Walleij , devicetree-discuss@lists.ozlabs.org, Wolfram Sang , linux-kernel@vger.kernel.org, Deepak Saxena , linux-next@vger.kernel.org, Alessandro Rubini , linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org --+pHx0qQiF2pBVqBT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 18, 2012 at 01:33:42PM +0800, Shawn Guo wrote: > I have an IP block getting different FIFO size on different IMX SoCs. > We could introduce a new compatible string for driver to figure it out, > but I think the simpler way is just have the data encoded in device > tree. In any case DT is not completely limited in encoding board > specific data. Today, we have IO region and interrupt number of > hardware blocks encoded in DT, and to me, FIFO size could just be > another aspect of hardware block we could choose to encode in DT. So, this is part of the problem with encoding the description of the SoC into the DT - we're not doing a good job of splitting out the silicon description from the board specific description which is not a triumph for maintainability since it means that we end up needing to modify the DT for every board using the silicon if we want to use the new feature (assuming people maintain binary compatibility with old DTs, which we don't do a good job at either even for established DT architectures). It's not the using device tree bit that creates concern for me here, it's the fact that the board and silicon aren't being separated. --+pHx0qQiF2pBVqBT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQBoj1AAoJEBus8iNuMP3dKsoP/jz7hlUOFJ+Hq5WtbuQwHWj3 lPVHrs2rkZzb5CEXnnJ2YdfnwouEhYtoH/SxypUSlxOa8nFqjH5ZwF3Sil5IS8RC cYgOT6Olkt684XwtTx6J2Q40MpY0gVCCOCKfbnc1lp6t3mnySNtSEuwYJGWAaeps UgC3IqNrC0Vi86+vIETuJ1JU8JVpjwVuko0OD0KRpyckbnPkNpTM90kKi7DlsKI1 gyvxWpDp8no0liclfb67osBPXz75Q1okzU6G5Iz2N3VWz0Tj/aHOS8JMQ7ZXWBQI FcAqHPMxGeq6Ez22HPUMeJ4hcRwFGWutPFgbsepCfU+qZy6UbiMfWTIOmuHF35tW QkEqTWgtpJNlzSegueiiGpR4KUKtSOLU2+qBVEAH46RXIbm7iPnepi1v5vka2b0i Pq1OeYXyFtkVIfg5vg0bnPXsuZ0bJDkcyA/i1Cfc3Iq2lkNv57CUh+dOXjW4y38b qcXxNwy7hPewbe5dn10hyZkeUj0Gs2sFJn4upMNWdKh/f7XwHAWac+nP4BvTLRCJ z7L2jeSq+Ldi1OMcGkB0i07dsaI0AGhip1ynSxJY1c+ohhwt5RUbhnXKmIZy+7PX vANGifd39Jv5vvYdVsjupm5eEdPiNmDqboS7RI0NCQPVNw9WsKv6jFwW/0jGHdvr 00gtjLoGNXqK3QPT3D0d =HT/j -----END PGP SIGNATURE----- --+pHx0qQiF2pBVqBT--