From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x226AKfIF0Hn5BeZHo0i+845IRg5M8ach1ggbBgCQtSI1N7Em+4dD18ULipM+NjHg9W/wVkes ARC-Seal: i=1; a=rsa-sha256; t=1517298892; cv=none; d=google.com; s=arc-20160816; b=EXdDwo09oGDNYvKvj3tUWKP1/mmsMCxqwdXDMSGn4PNpJeI/vhmvF8RMJPKesyy8TG 1NFQjaX6XcoicK1gi7xTvAjtPU5j9f90Ou2E0/5Rus3ls1b25/DJdzgPF+1BXU3BwQYp 5GugYav0CneKd2SijksTKOoLnIcTTehabAxnYSF1lT81guQuVlun/pVtORuvxIAwwtRf lGJ5GVce30+BENG2aw/UGuS3q98g3Pqd7diF5IisIHNEOTnxbCpEXPM1IdaRAsvm+Vro J9wfOgWldGiymZKichN6vMe/ox04qf7qRXMnHSZfxV02hoV6o+C9rRun74Z8/PfcYMA2 TA3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=5aEkeBJo5n2S49cMVz0go9K3OYwb6re6t9Pap2faGio=; b=qfakgWuK53h283pSFs+yPc52CC8uLzHNsbyMPb1ohgQCouXjfBDsyzZm60IEvjOa5c rKAZm4ajoGC9nDawSy395g9osNYJSNDeGOsYvs92CAz/TYEdTbzjn8v7s3h2WtxR23R1 XoeKnsXrY0xyNhuI5PnX3Utbj4z6yShmGo+dsLILzMTmL1qEf9kCuNAHGiasroeJdC96 VDkQCRI5e934S6ZO8us5fgjd0V0MSu+OVLTrgfr3U1q8pVY3ODbVmzDUDRVVLySIVA6d ThsyJIZP1pmoroPe4rABCVU0iWS/g5MmN7/qbrIMCwQhC8JzxjTXyIi6OtbKwJTogyuA rPWw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of maxime.ripard@free-electrons.com designates 62.4.15.54 as permitted sender) smtp.mailfrom=maxime.ripard@free-electrons.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of maxime.ripard@free-electrons.com designates 62.4.15.54 as permitted sender) smtp.mailfrom=maxime.ripard@free-electrons.com Date: Tue, 30 Jan 2018 08:54:41 +0100 From: Maxime Ripard To: Arnd Bergmann Cc: Linus Walleij , Yong Deng , Mauro Carvalho Chehab , Rob Herring , Mark Rutland , Chen-Yu Tsai , "David S. Miller" , Greg Kroah-Hartman , Hans Verkuil , Randy Dunlap , Stanimir Varbanov , Hugues Fruchet , Yannick Fertre , Philipp Zabel , Benjamin Gaignard , Ramesh Shanmugasundaram , Sakari Ailus , Rick Chang , Linux Media Mailing List , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux ARM , "linux-kernel@vger.kernel.org" , linux-sunxi , megous@megous.com, Thomas Petazzoni Subject: Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI. Message-ID: <20180130075441.rqxzkwero6sdfak6@flea.lan> References: <1516695531-23349-1-git-send-email-yong.deng@magewell.com> <20180129082533.6edmqgbauo6q5dgz@flea.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="efe3fivtyyp4bqw2" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590370608168306586?= X-GMAIL-MSGID: =?utf-8?q?1591003203230400880?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: --efe3fivtyyp4bqw2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Jan 29, 2018 at 03:34:02PM +0100, Arnd Bergmann wrote: > On Mon, Jan 29, 2018 at 10:25 AM, Linus Walleij > wrote: > > On Mon, Jan 29, 2018 at 9:25 AM, Maxime Ripard > > wrote: > >> On Sat, Jan 27, 2018 at 05:14:26PM +0100, Linus Walleij wrote: > >> However, in DT systems, that > >> field is filled only with the parent's node dma-ranges property. In > >> our case, and since the DT parenthood is based on the "control" bus, > >> and not the "data" bus, our parent node would be the AXI bus, and not > >> the memory bus that enforce those constraints. > >> > >> And other devices doing DMA through regular DMA accesses won't have > >> that mapping, so we definitely shouldn't enforce it for all the > >> devices there, but only the one connected to the separate memory bus. > >> > >> tl; dr: the DT is not really an option to store that info. > >> > >> I suggested setting dma_pfn_offset at probe, but Arnd didn't seem too > >> fond of that approach either at the time. > >> > >> So, well, I guess we could do better. We just have no idea how :) > > > > Usually of Arnd cannot suggest something smart, neither can I :( > > > > If some aspect of the memory layout of the system *really* doesn't > > fit into DT because of the assumptions that DT is doing about > > how systems work, we have a problem. > > > > Is the problem that DT's model assumes that devices have one and > > only one data port to the system memory, and that is how it > > populates the Linux devices? > > > > I guess, if nothing else works, I would use auxdata in the board file. > > It is our definitive last resort when DT doesn't hold. > > > > I.e. I would go into struct of_dev_auxdata > > (from ) and add a > > dma_pfn_offset field that gets set into the device's dma_pfn_offset > > in drivers/of/platform.c overriding anything else and use that to hammer > > it down in the boardfile. > > > > But I bet some DT people are going to have other ideas. >=20 > At one point we had discussed adding a 'dma-masters' property that > lists all the buses on which a device can be a dma master, and > the respective properties of those masters (iommu, coherency, > offset, ...). > > IIRC at the time we decided that we could live without that complexity, > but perhaps we cannot. Are you talking about this ? https://elixir.free-electrons.com/linux/latest/source/Documentation/devicet= ree/bindings/dma/dma.txt#L41 It doesn't seem to be related to that issue to me. And in our particular cases, all the devices are DMA masters, the RAM is just mapped to another address. > Another local hack that we can do here is to have two separate > device nodes and let the device driver bind to one device and then > look up the other one through a phandle to look up a platform_device > for it, which it can then use with the DMA mapping interface. We have multiple devices doing that, a couple of them already merged (mostly on the display side). I'd rather not do that. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --efe3fivtyyp4bqw2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE0VqZU19dR2zEVaqr0rTAlCFNr3QFAlpwJMAACgkQ0rTAlCFN r3TQZg//Xz2uAhCJJkmDsZ3teD3rSn6GiiwjVnZoKdNcILTtEqGHCkwPM0D1PyOp eoKHDjBH/o2BoGp9aXtyAiWiXVgHsFCjvUxX24bTDizd+BKBcqKx+1VVqPn1lfcB 1+Fq0R5GMFFH+m+ubVRmKS182bdz9LZcKoqM1kINQiBumEfLOwSD96WqCBc0lVvb LunE+TUKWFBjZVeW+JsmCrjpT00SXccnlKG9yKh11ZJkmnOY2hVnh6usd1hvttQq JUN2H8CdP/q1c0CLLx9o+3dgTuKpYS/P8Elza0ujnxBO7395YQSs5k8Nn2Ct4VsL qs5Hd27qC1d4HYwKiROyX+oa9Vh4X0nUi7t7ebdIVMqOJ/yUaJ3bY24/8DBb/RM9 tRgumkd8iQZ0hX+QSfLqtmwiBuYeVSQ4Fq0CnyTIT1BciZ18MIjgVMqbypSOyX9i 4I/DRAYXOR4kdUYEiDeQib+XNsahBmeQI2IZbJI3f0qLbjn5sZRCYaaHPqG3Hk2u wlOcRNjFrxe4pDLw79ST9DFGOh0D0tbCax16riHNgxTyksVhETBQQweIwn5hi0a0 alEKVBnIi4X8vIceeBYQhjYYEn7j6pHgYc96VCiC/n0NYbazXe6j3qrvLfBhwHMa fG2osde5Sub0hrWGfqpB/lA431ZQAHKf1xiCvJ9QQXViLjqBmSA= =Iq2u -----END PGP SIGNATURE----- --efe3fivtyyp4bqw2--