From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: David Woodhouse <dwmw2@infradead.org>, Vinod Koul <vinod.koul@intel.com>
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [RFC] DMA initialization for manually created devices
In-Reply-To: <871t61ep6x.fsf@intel.com>
References: <87bn55esm6.fsf@intel.com> <1461068047.3765.97.camel@infradead.org> <871t61ep6x.fsf@intel.com>
User-Agent: Notmuch/0.21+96~g9bbc54b (http://notmuchmail.org) Emacs/25.0.90.3 (x86_64-pc-linux-gnu)
Date: Wed, 20 Apr 2016 13:31:12 +0300
Message-ID: <87inzcbmhb.fsf@intel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3298
Lines: 89

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Hi again,

Felipe Balbi <felipe.balbi@linux.intel.com> writes:
> David Woodhouse <dwmw2@infradead.org> writes:
>> On Tue, 2016-04-19 at 14:38 +0300, Felipe Balbi wrote:
>>>=20
>>> The reason for that I'm using a manually created platform_device and
>>> that misses dev->archdata which the underlying/parent PCI device has.
>>
>> Typically we'd expect you to use the parent device for DMA, as in your
>> second option.
>>
>> That said, we're exploring the option of moving the dma_ops to be a
>> first-class member of 'struct device' instead of hiding it in archdata,
>> and cleaning up the way that it gets initialised for newly-created
>> devices. And at that point we might end up letting it get inherited
>> from the parent so your original code *would* work... but I wouldn't
>> hold your breath for that.
>>
>> Definitely *don't* mess around in archdata.
>
> alright, I'll patch it up to use parent device everywhere, at least for
> now.

reviving this a little bit, it seems like inheritance of DMA bits from
parent is the way to go in the future. Let's consider a dual-role
instance of dwc3:

The peripheral IP is Synopsys' proprietary and gets built into dwc3.ko
which is a child device of a parent dwc3-pci.ko (in case of intel, at
least).

The host side, is regular XHCI, so dwc3.ko creates yet another child
device for xhci-plat.ko. The parent-child tree ends up like so:

dwc3-pci
  |_ dwc3
     |_ xhci-plat

dma for dwc3.ko is simple(-ish), instead of dma_alloc_coherent(dev,
....), we just replace that with dma_alloc_coherent(dev->parent, ...).

As for XHCI, which is a generic device also used directly by PCI
devices, the problem is more peculiar.

For dwc3's xHCI, we would have to call
dma_alloc_coherent(dev->parent->parent,  ...), but that would break
regular, non-dwc3 XHCI blocks which have direct access to the pci
device.

So, for dwc3.ko, I've fixed this with [1], however, if I remove copying
of DMA bits from parent to child, xhci-plat.ko will regress. Any hints
for this particular situation ?

The solution, IMO, is to either automatic copying of parent's DMA bits
to child by the time it's registered, or make DMA API search the device
parent tree until it finds a parent with a suitable DMA configuration.

[1] https://marc.info/?l=3Dlinux-usb&m=3D146107237232681&w=3D2

=2D-=20
balbi

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJXF1pwAAoJEIaOsuA1yqREGSwP/jt4wQnQA60PzhSXWSH9sHjZ
iMxXvIhFPHsBEibB6rMqzCL3lpx9VS1M3cbRSLZ1AMdpRttKgGoU4iFvuZ7xYzRc
ej4oA19jeQiUh4dNHWdmd/4NBhprW41Oa/esNxPsXYuFbdgQc2drMVW/baALXCAp
bAKvSAKL5qGmtIa9y/vvM3S1Smn3btRzA5pBtjNKaMHo0K8MpnvS4gL7ih9rR7HZ
DPvhb+mapVNYKtmosF7xpVOFcTfX3tzwCHJD4eqnnmo0A+oPbjKE8xKxhgqAzwfH
YDYTVGSt8NZYpIvU27gqRPg1M4oJ9gLJu3MfR5rEF9wuuj4AyV3TGJ5ILAzaaJvR
GDe1zpzO37zAcaoMcNx/E/q7xgK2xMUMNWfBHnZllqGkVYlUxjN5TBTUIHs6P1EB
d6LdJYYxsVK5Q7sGzxr+PB2c+/nHIaXnyJVkAHeKBS4wVvLUMkX2mwtt8ljPVlgr
10qrODSDm0Xqrd13BMBBGlZ3aDhUlfLXeaO4pFeVN+oas4UTS2TRX4ubmLVM1m2T
O+bins4GD+u7P/8SuNYEKQOKOKCF84wpl7vCol0e3RtJn2qt4lStng8Z4WL2fu81
iDqOdqR7KFM3WdCX4ZO9W3gjBfsAypICNm/XxdwNKLwTbywLUxSuK36pI29kPJPP
Ohcd93S3Quh7VKSgE1pV
=Vrdb
-----END PGP SIGNATURE-----
--=-=-=--