Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752011AbdLKWrK (ORCPT ); Mon, 11 Dec 2017 17:47:10 -0500 Received: from mail-out.m-online.net ([212.18.0.10]:44184 "EHLO mail-out.m-online.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751657AbdLKWrI (ORCPT ); Mon, 11 Dec 2017 17:47:08 -0500 X-Auth-Info: 8LkzeTqZLvislnv/tlyin+jL23zle0eaZH3/TwSybFE= Date: Mon, 11 Dec 2017 23:46:57 +0100 From: Lukasz Majewski To: Hartley Sweeten Cc: Alexander Sverdlin , Arnd Bergmann , "arndbergmann@gmail.com" , "Russell King" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Olof Johansson , "Linus Walleij" Subject: Re: [PATCH v4 5/5] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative Message-ID: <20171211234657.5482b40f@jawa> In-Reply-To: References: <20171116232239.16823-1-lukma@denx.de> <20171130235140.12243-1-lukma@denx.de> <20171130235140.12243-6-lukma@denx.de> <20171211223941.744be82f@jawa> Organization: denx.de X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/ot.qQi.Gn6FHD=8FnP9SRv+"; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4725 Lines: 150 --Sig_/ot.qQi.Gn6FHD=8FnP9SRv+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Hartley, > On Monday, December 11, 2017 2:40 PM, Lukasz Majewski wrote: > > Hi Hartley, > > =20 > >> On Thursday, November 30, 2017 4:52 PM, Lukasz Majewski wrote: =20 > >>> > >>> The BK3 board is a derivative of the ts72xx reference design. =20 > >>=20 > >> Lukasz, > >>=20 > >> I was just reviewing the other TS-72xx boards and noticed this: > >>=20 > >> > >> =20 > >>> +/* BK3 specific defines */ > >>> +#define BK3_CPLDVER_PHYS_BASE 0x23400000 > >>> +#define BK3_CPLDVER_VIRT_BASE 0xfebfd000 > >>> +#define BK3_CPLDVER_SIZE 0x00001000 > >>> + =20 > >>=20 > >> > >> =20 > >>> +static struct map_desc bk3_io_desc[] __initdata =3D { > >>> + { > >>> + .virtual =3D BK3_CPLDVER_VIRT_BASE, > >>> + .pfn =3D > >>> __phys_to_pfn(BK3_CPLDVER_PHYS_BASE), > >>> + .length =3D BK3_CPLDVER_SIZE, > >>> + .type =3D MT_DEVICE, > >>> + } > >>> +}; > >>> + =20 > >>=20 > >> This register appears to be common to all the TS-72xx boards. =20 > > > > The CPLD was used on the reference ts-72xx boards, but support for > > it seems to not be present in the mainline kernel. =20 >=20 > The CPLD is not directly called out but some parts of it are > supported in the mainline kernel. >=20 > The RTC index and data registers are chip selected by the CPLD and > Watchdog is in the CPLD. Also, the model number, options, and > options2 registers are in the CPLD. >=20 > There are a couple other registers in the CPLD that are not currently > present in mainline. Some aren't because I haven't figured a good way > to utilize them (the COM2 RS485 registers and the PC/104 memory/IO > spaces) or they simply have not been necessary yet (the two status > registers). There are a couple listed in the manuals that are > specific to the TS-7260 that also have not been added. >=20 > Basically, anything in the EP93xx CS1 or CS2 memory region is in or > controlled by the CPLD. >=20 > > Do you have a ts72xx board with CPLD embedded? Is any of your > > design using it? =20 >=20 > I have a stock TS-7300 board. >=20 > > My another concern - is it safe to perform IO mapping on memory > > regions which are not used / specified? =20 >=20 > The mapping is safe. If there is nothing at the address you just read > back the static state (noise) of the bus and writing doesn't do > anything. Ok. >=20 > > When I do a single ts72xx mapping - for all boards - then we may > > end up with some mappings which are not needed. =20 >=20 > True, but it's harmless and it keeps the platform init code cleaner. I will add all the mappings. >=20 > > With the code as it is - I only map regions which are already used > > on relevant boards. =20 >=20 > Yes, but this register in particular exists in the CPLD on all the > TS-72xx boards. >=20 > >> I don't think Arnd has pulled the series yet. Would you mind > >> renaming the defines and rebasing this patch? =20 > > > > If needed I can resend the patch series, or prepare a single fix > > patch. No problem. =20 >=20 > Fixing it after Arnd merges your series is fine. I just wanted to > make sure it was pointed out. I've checked a few minutes ago and it seems like arm-soc hasn't been pulled to for-next. I may resend the whole series. >=20 > BTW, is there a reason the BK3 board needs this register mapped? It > was mapped in the Technologic Systems 2.4, 2.6, and 3.x kernels but I > never found anything that used it. It is used to check the version. BK3 has some CPLD modifications and it is important to know which version we do have as the board is already deployed for some time in the field. > Of course the stock boards > probably always had the same revision in the CPLD, the BK3 board > might have multiple revisions... Yes, correct. >=20 > Hartley Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de --Sig_/ot.qQi.Gn6FHD=8FnP9SRv+ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAlovCuEACgkQAR8vZIA0 zr2WcAgA3wy7l+qZ6+vSje1Zk0xV4f7K5MooqZOebbrpj+slthidF07IdhJ2mgdN J4AQD6EB1zZSfZrbzCfw49bg9blT8C1vV8VdwkJ37jrse5JaEumVHssDr9i2Cyuh qnXwL5dzl9EVEzMNSigmETKzQ5J+81b1WEICvGjRmLlW6TAsv9rIBk4zeJo1ntDw fsROh8jfaXjgMlLmsMgYj17moh8SQM7v/UYz6vNJZojRw6yshubFIPEK+O1foXex WTVaAnYIZyGPc1jZU/PcFGbQQwVJfXt2FZzfmy0jpPt1ZCeGULjGgJDlvN9qIbuQ AR/h5xboLfAMObBkYp7TE1943kJG0w== =IH2J -----END PGP SIGNATURE----- --Sig_/ot.qQi.Gn6FHD=8FnP9SRv+--