From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x224B6+uWdR5P4GPepsvDDeMgk4uck5B9pvOz+w7DY04ljEV3BPRFMmgWIaEFyzgS4Pkv00YN ARC-Seal: i=1; a=rsa-sha256; t=1517214531; cv=none; d=google.com; s=arc-20160816; b=EuMtufCX3ZJYuri1zpOKJk+BW4Jw4yYe9IHoDzORqxileO1a5ehuD3UzbLgswiQSHb 9rIa0bLrRzxhHYn5UmWSVzR1gFphmN57W+DdIkQ0zvVSaBM5iEcpOUqojoWiYummxE/Z Q9M9OX7yhjV7EAy7uXY+8UZrU40m3h5oSVXGtYpRxRF8nA/bh9dxNXxUC7Bifg8hnBkH UCU+umB7lJNV71/kQZFkmRsRlbRPrU8iZkOLCQlloQ2dwI5du/XJj9QUTdymwUr7BUdV WJv2pgZ9rM0zUbzvXGu2GU7vp5BOgAccGqDdlBz4Xjb/a5Nxyf76CebhXIFZJcJjWquQ 0d6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=from:message-id:cc:to:subject:content-transfer-encoding :mime-version:references:in-reply-to:date:arc-authentication-results; bh=qGol/g+SCBjTCrsUnuWGDySFGtYh3CEdNdTwekNb/9E=; b=HoEAR/ethleNpxXOK1PfQkG4xEI7kDhWViqYqDnu8NiARYELkyEeUfCyoCit2YX48Y FL7vfzck+PcaK/VKZr2nTFgq17h0PqAQRR7IkM+jf8k/PdF4F7nhr2VRg4fwKB4yraxy Ld0lwCtbpzg4vpTmaG/BytlNxHQ3kosEEG/Bi+K5NuUQj/cTdilzOx9h4Xu+sGuhjRfe tlrv2weiuXsFXo41WyBt4gFSgJKX5DZqjeWMmPn25XO/Ce7NZ7Pj0Ihz76vCTGp0dAZO FRrNyNTDtFRtBXARiznAPVeR/FhOFsVtYHE0Hp0m/RuyG3gBnkS8y5v9s622exEAxhA5 HJXA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of icenowy@aosc.io designates 23.83.209.71 as permitted sender) smtp.mailfrom=icenowy@aosc.io Authentication-Results: mx.google.com; spf=pass (google.com: domain of icenowy@aosc.io designates 23.83.209.71 as permitted sender) smtp.mailfrom=icenowy@aosc.io X-Sender-Id: lmn-tzduiowcrqmw|x-authsender|icenowy@aosc.io X-Sender-Id: lmn-tzduiowcrqmw|x-authsender|icenowy@aosc.io X-MC-Relay: Neutral X-MailChannels-SenderId: lmn-tzduiowcrqmw|x-authsender|icenowy@aosc.io X-MailChannels-Auth-Id: lmn-TZDUIOWCRQMW X-Bitter-Befitting: 2f1938456695b5ac_1517214530484_645778963 X-MC-Loop-Signature: 1517214530484:930436118 X-MC-Ingress-Time: 1517214530483 Date: Mon, 29 Jan 2018 16:28:06 +0800 In-Reply-To: <20180129082533.6edmqgbauo6q5dgz@flea.lan> References: <1516695531-23349-1-git-send-email-yong.deng@magewell.com> <20180129082533.6edmqgbauo6q5dgz@flea.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [linux-sunxi] Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI. To: maxime.ripard@free-electrons.com,Maxime Ripard ,Arnd Bergmann ,Linus Walleij CC: 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@vger.kernel.org, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux ARM , "linux-kernel@vger.kernel.org" , linux-sunxi@mailchannels.net Message-Id: <20180129082850.CAAF25C1783@relay.mailchannels.net> From: icenowy@aosc.io X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590370608168306586?= X-GMAIL-MSGID: =?utf-8?q?1590914744426522149?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: ,megous@megous.com,Thomas Petazzoni From: Icenowy Zheng Message-ID: =E4=BA=8E 2018=E5=B9=B41=E6=9C=8829=E6=97=A5 GMT+08:00 =E4=B8=8B=E5=8D=884= :25:33, Maxime Ripard =E5=86=99=E5= =88=B0: >Hi Linus, > >On Sat, Jan 27, 2018 at 05:14:26PM +0100, Linus Walleij wrote: >> > +void sun6i_csi_update_buf_addr(struct sun6i_csi *csi, dma_addr_t >addr) >> > +{ >> > + struct sun6i_csi_dev *sdev =3D sun6i_csi_to_dev(csi); >> > + /* transform physical address to bus address */ >> > + dma_addr_t bus_addr =3D addr - PHYS_OFFSET; >>=20 >> I am sorry if this is an unjustified drive-by comment=2E Maybe you >> have already investigate other ways to do this=2E > >It's definitely not unjustified :) > >> Accessing PHYS_OFFSET directly seems unintuitive and not good >> practice=2E >>=20 >> But normally an dma_addr_t only comes from some function inside >> such as: dma_alloc_coherent() for a contigous >> buffer which is coherent in physical memory, or from some buffer <=3D >> 64KB that is switching ownership between device and CPU explicitly >> with dma_map* or so=2E Did you check with Documentation/DMA-API=2Etxt? > >So, I've discussed this with Arnd a month ago or so, because I'm not >really fond of the current approach but we haven't found better way to >do it yet=2E > >The issue is that all the DMA accesses are done not through the main >AXI bus, but through a separate bus dedicated for memory accesses, >where the RAM is mapped at the address 0=2E So the CPU and DMA devices >have a different mapping for the RAM=2E Maybe we can specify the offset in the DT as it's about how the IP block is integrated to the SoC=2E > >I guess we could address this by using the field dma_pfn_offset that >seems to be used in similar situations=2E However, in DT systems, that >field is filled only with the parent's node dma-ranges property=2E 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=2E > >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=2E > >tl; dr: the DT is not really an option to store that info=2E > >I suggested setting dma_pfn_offset at probe, but Arnd didn't seem too >fond of that approach either at the time=2E > >So, well, I guess we could do better=2E We just have no idea how :) > >Maxime