Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754183AbcDAL7G (ORCPT ); Fri, 1 Apr 2016 07:59:06 -0400 Received: from mga02.intel.com ([134.134.136.20]:43136 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751513AbcDAL7E (ORCPT ); Fri, 1 Apr 2016 07:59:04 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,427,1455004800"; d="asc'?scan'208";a="949560109" From: Felipe Balbi To: Grygorii Strashko , "Thang Q. Nguyen" Cc: Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm@lists.infradead.org, Arnd Bergmann , "Karicheri\, Muralidharan" , Peter Ujfalusi , Phong Vo , Loc Ho , patches , Santosh Shilimkar , "Ben Dooks \(embedded platforms\)" Subject: Re: [PATCH v3 2/2] usb:dwc3: pass arch data to xhci-hcd child In-Reply-To: <56FE54DB.5000201@ti.com> References: <1457594332-7490-1-git-send-email-tqnguyen@apm.com> <1457594332-7490-3-git-send-email-tqnguyen@apm.com> <87mvpgi02f.fsf@intel.com> <56FBDA0D.4030507@ti.com> <87egashxz8.fsf@intel.com> <87k2kjgjjf.fsf@intel.com> <56FD3D2F.8070501@ti.com> <871t6pahg8.fsf@intel.com> <56FE4378.3030205@ti.com> <87shz58wbw.fsf@intel.com> <56FE54DB.5000201@ti.com> User-Agent: Notmuch/0.21+96~g9bbc54b (http://notmuchmail.org) Emacs/25.0.90.3 (x86_64-pc-linux-gnu) Date: Fri, 01 Apr 2016 14:57:07 +0300 Message-ID: <878u0x8ru4.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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4007 Lines: 111 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Grygorii Strashko writes: > On 04/01/2016 01:20 PM, Felipe Balbi wrote: >>=20 >> Hi, >>=20 >> Grygorii Strashko writes: >>>> if of_dma_configure() does what you want, why don't you just stick it = in >>>> dwc3-keystone.c and let the driver continue to copy things for now ? >>>> Something like below, perhaps ? >>>> >>> >>> I know (and i have patch to fix that which I'm going to send) that DMA = config >>> in dwc3-keystone.c is not correct and we are good till now just >>> because dwc3_keystone is not used for DMA operations directly. >>> >>> Now about xhci and friends: >>> dwc3_keystone *is created* from DT : of_platform_device_create() -> of_= platform_device_create_pdata() -> of_dma_configure() >>> |- dwc3 *is created* from DT : of_platform_device_create() -> of_platfo= rm_device_create_pdata() -> of_dma_configure() >>> |- [1] *creates* xhci dev manually : DMA configuration copied manua= lly in dwc3_host_init() >>> |- [2] *creates* usb_gadget dev manually: DMA configuration copied = manually in usb_add_gadget_udc_release() >>> |- *creates* usb_udc dev manually : not used for DMA operations dir= ectly (as I've checked) >>> >>> Now cases [1] & [2] introduces failures, because DMA configuration is n= ot complete for >>> these devices. >>=20 >> right, then we just copy whatever's missing, right ? Until there's a >> generic way of copying these bits, I want to avoid introducing any of_* >> specific methodologies and prefer to have the manual copy. > > Sry, I've found no other way (right now) to fix it, except by using of_dm= a_configure() > which will do all work in DT case (including calling of arch specific cal= lbacks). > [it might be unsafe to just copy archdata, for example, as it might(will = for arm) > contain pointers]=20 > >>=20 >>> I can confirm that if I fix [1] & [2] as above USB Device/Dual modes wi= ll start >>> working on K2E. > > Above is for 4.1 kernel > >>=20 >> cool, I'd be happy to take both patches ;-) >>=20 > > ok. And seems gadget case is fixed already > commit 7ace8fc8219e4cbbfd5b4790390d9a01a2541cdf > Author: Yoshihiro Shimoda > Date: Mon Jul 13 18:10:05 2015 +0900 > > usb: gadget: udc: core: Fix argument of dma_map_single for IOMMU >=20=20=20=20=20 > The dma_map_single and dma_unmap_single should set "gadget->dev.paren= t" > instead of "&gadget->dev" in the first argument because the parent has > a udc controller's device pointer. > Otherwise, iommu functions are not called in ARM environment. >=20=20=20=20=20 > Signed-off-by: Yoshihiro Shimoda > Signed-off-by: Felipe Balbi > > Above actually means that DMA configuration code can be dropped from > usb_add_gadget_udc_release() completely. Right?: true, but now I'm not sure what's better: copy all necessary bits from parent or just pass the parent device to all DMA API. Anybody to shed a light here ? =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW/mIUAAoJEIaOsuA1yqREb10P/iZJZ3FlrYT+5JQrq9zTH8kx p7YDQHLpFiGUoUllEqXIXyWvaMQo1LO+emVthCQailmWlj4QU/FPsf/XFrLZXqr3 DQPbOvK6qffiR9H7OWV7939HBJzu4l+TLzR5GGdV7cCxJFnBNPIYn3mGrR6a+sPx TLqA9vaOiOZT1z8QbnNZA9qu+DPemHt+GJ9y/sCOq1NHw/wd+CHXJjtBeon6197e trOghzIEDLfbI3cWRw+FGCG6BQfwpTOuKTYc72bsBnMGTAICK+1iXS8gU2sZQCIS ZPqKHkVb96306DxBoziMEyLF/hyNcF0NHRys3Rrxdu8QY+SSGkNf4r4sk5gXL6/L WV9nEpuc+wDklKDQUTYN0bczzOTFcmlsnuxz1ADuYpYDMScK95bL5qPV+mWKNn4u 6hZ5SurGw+oEH+DgPlkpPuvCUN+QV50JBG9y3/IuqfsNjptKeJ4OID1NXySI2wci j575vuQSvRgrGJ/e8vZ5rsq2JPm6pZuvZnvZ5ucip9adgtFL3m76ElRjDYTaYyKD ELJCna5OKjX7r509h11Pe2DGZIksJ5kDwBr0+3mkdULIm0mM3MllA6SscgImhV69 1COKFpZ3cMw9W330MUDCT0ATk/S88dGG8j9LSOCDcudk5eoc32kWYieDNeyncZIY vAzL0tz1tVT64BUcDFfQ =G1DB -----END PGP SIGNATURE----- --=-=-=--