From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Rae Date: Mon, 26 Jan 2015 09:44:14 -0800 Subject: [U-Boot] [PATCH 2/4] usb: add 'bcm_udc_otg' support In-Reply-To: <201501241247.08414.marex@denx.de> References: <1421793730-8179-1-git-send-email-srae@broadcom.com> <201501220805.53148.marex@denx.de> <54C2DDBF.7010007@broadcom.com> <201501241247.08414.marex@denx.de> Message-ID: <54C67CEE.7030207@broadcom.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 15-01-24 03:47 AM, Marek Vasut wrote: > On Saturday, January 24, 2015 at 12:48:15 AM, Steve Rae wrote: >> On 15-01-21 11:05 PM, Marek Vasut wrote: >>> On Tuesday, January 20, 2015 at 11:42:08 PM, Steve Rae wrote: >>>> Implement the UDC support for the USB OTG interface. >>>> >>>> Signed-off-by: Steve Rae >>>> --- >>> >>> General question -- this bcm controller you're adding here isn't by >>> any chance a DWC2 controller, or is it ? There's already a driver >>> for DWC2 in drivers/usb/gadget/s3c_udc_otg.c . This driver should really >>> be properly renamed though ;-/ >>> >>> If this is not DWC2, do you know what controller this is please ? >> >> yes -- it is a DWC2.... >> >> So, I have had a quick look at the s3c_udc_otg*.c code.... >> >> First observation is that there is a completely different philosophy in >> the implementation. For example, the the interrupt handler routine(s), >> Broadcom is using #defines (sysmap.h which BTW are autogenerated by our >> Device Team) whereas "S3C" is using a "s3c_usbotg_reg" structure for the >> 'address' and #defines for the 'data/masks'. I'm not suggesting that one >> is better than the other, they are just different. > > Hi! > > The later is accepted by U-Boot as the preferred way, so the s3c is doing > things right. > >> So, how do we proceed? > > At this point, the Altera SoCFPGA and Samsung Exynos both use this s3c > driver to operate the DWC2 core in gadget mode. It should be trivial to > add support for the boardcom SoC, just follow the Altera example. > > I would like to avoid situation where we have two drivers for a single > IP block. > >> - is the ultimate goal to get to a proper gadget driver for DWC2? (I >> don't really know enough about this yet, so I apologize for these >> questions....) > > Yes, but we already have one to my knowledge. > >> - is the "S3C" code a proper 'gadget' driver and/or is it a better >> starting point to get to a gadget driver? > > Yes, and it's thoroughly tested already. > >> - I don't have enough time right now to really investigate the existing >> "S3C" and implement it on our board(s); they are significantly different >> and it looks like it will take a lot of effort - is there someone (Denx >> or community) that could assist me? > > Sure, just start asking the questions. > >> - Could we continue to review this patchset and accept it; then >> establish a team to provide a "DWC2 gadget" that could be used going >> forward? > > No, unless there's a convincing technical argument that the currently > mainline DWC2 gadget driver (the s3c one) can absolutelly not be used > for the broadcom SoC, I want to avoid having two drivers for the same > IP core in mainline, sorry. > > [...] > > Sorry, at this point I have to push back a little. OK -- Thanks for this information.... Steve > > Best regards, > Marek Vasut >