Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752121AbdF3Ndb (ORCPT ); Fri, 30 Jun 2017 09:33:31 -0400 Received: from metis.ext.4.pengutronix.de ([92.198.50.35]:41157 "EHLO metis.ext.4.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751668AbdF3Nda (ORCPT ); Fri, 30 Jun 2017 09:33:30 -0400 Date: Fri, 30 Jun 2017 15:33:27 +0200 From: Michael Grzeschik To: Mark Brown Cc: linux-kernel@vger.kernel.org, kernel@pengutronix.de, Philipp Zabel Subject: Re: [PATCH v2] regmap: irq: allow different device for irq chip and regmap Message-ID: <20170630133327.bqjzrt5hecjss725@pengutronix.de> References: <20170622110320.31926-1-m.grzeschik@pengutronix.de> <20170623120043.jgu4i3zbdfraulhc@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mdxonyjxlxcirbbh" Content-Disposition: inline In-Reply-To: <20170623120043.jgu4i3zbdfraulhc@sirena.org.uk> X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-IRC: #ptxdist @freenode X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-Uptime: 15:13:48 up 11 days, 1 min, 14 users, load average: 0.00, 0.02, 0.01 User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: 2001:67c:670:100:5054:ff:fe2a:3aa X-SA-Exim-Mail-From: mgr@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5693 Lines: 140 --mdxonyjxlxcirbbh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 23, 2017 at 01:00:43PM +0100, Mark Brown wrote: > On Thu, Jun 22, 2017 at 01:03:20PM +0200, Michael Grzeschik wrote: >=20 > > If the irq chip device is using the regmap of its parent device or > > a syscon regmap that doesn't have an associated device at all, > > allow the driver to provide its own device. That makes it possible > > to reference the irq controller from other devices running on the > > same regmap. >=20 > I would strongly expect that the regmap for a device would be associated > with the physical device, if it's not that seems likely to create > further problems. How is this happening? >=20 > syscon is one potential thing here but it seems odd for the sort of > hardware that syscon handles to be a good fit for regmap-irq. We have the special case that we use the syscon as the basic driver underneath some subdevices that vary in function. We have six arcnet controllers sitting side by side in an 8 byte offset. And after them we have the next small memory windows for an reset controller and one interrupt controller which the other devices reference. For that scenario the interrupt driver sitting under the "devicefree" syscon node, we have to add our own device node with dev_regmap_add_irq_chip. kmae_conf: syscon@0x09000000 { compatible =3D "syscon", "simple-bus"; bits =3D <32>; reg-io-width =3D <1>; stride =3D <1>; reg =3D <0x09000000 0x20000>; com20020_1@0x09014000 { compatible =3D "smsc,com20020"; reg =3D <0x14000 0x8>; interrupt-parent =3D <&kmae>; interrupts =3D <0 0x4>; resets =3D <&kmae_reset 0 0>; }; com20020_2@0x09014010 { compatible =3D "smsc,com20020"; reg =3D <0x14010 0x8>; interrupt-parent =3D <&kmae>; interrupts =3D <1 0x4>; resets =3D <&kmae_reset 1 0>; }; com20020_3@0x09014020 { compatible =3D "smsc,com20020"; reg =3D <0x14020 0x8>; interrupt-parent =3D <&kmae>; interrupts =3D <2 0x4>; resets =3D <&kmae_reset 2 0>; }; com20020_4@0x09014030 { compatible =3D "smsc,com20020"; reg =3D <0x14030 0x8>; interrupt-parent =3D <&kmae>; interrupts =3D <3 0x4>; resets =3D <&kmae_reset 3 0>; }; com20020_5@0x09014040 { compatible =3D "smsc,com20020"; reg =3D <0x14040 0x8>; interrupt-parent =3D <&kmae>; interrupts =3D <4 0x4>; resets =3D <&kmae_reset 4 0>; }; com20020_6@0x09014050 { compatible =3D "smsc,com20020"; reg =3D <0x14050 0x8>; interrupt-parent =3D <&kmae>; interrupts =3D <5 0x4>; resets =3D <&kmae_reset 5 0>; }; kmae_reset: kmae_reset@0x09014060 { compatible =3D "eae,kmae-reset"; reg =3D <0x14060 0x8>; reset-controller; #reset-cells =3D <1>; }; kmae_irq: kmae_irq@0x09014060 { compatible =3D "eae,kmae-irq"; reg =3D <0x1406c 0x2>; interrupt-controller; #interrupt-cells =3D <2>; interrupt-parent =3D <&gpio1>; interrupts =3D <31 0x4>; gpmc =3D <&gpmc>; }; }; You can imagine this kind of scenarios in various situations where the devi= ce structure is loaded into an FPGA. The simplest way to memory map that packed layout pagewise is by using syscon in that case. Regards, Michael --=20 Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | --mdxonyjxlxcirbbh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEElXvEUs6VPX6mDPT8C+njFXoeLGQFAllWUyQACgkQC+njFXoe LGTfyQ/+LjkSEKlA1cpg3AyP5uVW6J6vZ5EJuHkuO6NCX3Xo8dpZ7Oj5LLg5aiWR Btsam5PzeAahBXV/sKdwdIes/Y9rdYlnZcXH8iiQ/LVwr71G44GVnHGeOIpLqtJP NYpztn1wL6oWnDh/K/sIqcgHhy9Gb2GvBBMOXzyHekAZLYTMBXDjh5NtBoJnocaV m7gV0IegQnIMJRBq2QL9uLEOPwIGdp36HpQXsYGSCHK0XQPCqx8qeqUFQYdVe6/P pRkIJQQ9+eaPlSu/CZt5n3htx+kqBl4CIXkrIjilABrt8UdfozmYW9hAkKV5KyrO oOlQ+olHbjgUHnl8GtJExnTpoc/ChhHhfAEyT3bRAPRqcCjkKmwgP3Dljt0vQ1BX K6khETwOC+zVZddxVsO5311xqyDzmM5TFCMXUSqiHs2cHz8rdkS6LScIp2AIlMdZ /kE2yTOYxrNXoGW+Vk1p4NU23ikNPv5Ubb7Mi1p+VSqr7HTFgFnfVXMd/bEvPGlR y0Oim0+QGEBZYnAokAVD75OnCo74cQMeHo2WpkjkaTF3NdB/9vsaqka9iOOvtdvB eTmx31BbAMOWK0fpv7bCEvWZyPEdkX2EBOTARrH9arX/krqtIPsB+KnOtPE8sQFV EJqwcNKNY+TOkzXI63BgvDTrz26s5yx3GN0UQ5zzdUSqioonEvM= =vM0C -----END PGP SIGNATURE----- --mdxonyjxlxcirbbh--