From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wolverine02.qualcomm.com ([199.106.114.251]:49435 "EHLO wolverine02.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752680Ab0K1MJh (ORCPT ); Sun, 28 Nov 2010 07:09:37 -0500 Message-ID: <4CF2467B.9070304@codeaurora.org> Date: Sun, 28 Nov 2010 17:39:31 +0530 From: Pavan Kondeti MIME-Version: 1.0 Subject: Re: [PATCH v2] USB: Add MSM USB Device Controller driver References: <20101110021259.GA16558@codeaurora.org> <320241.1412.qm@web180311.mail.gq1.yahoo.com> <4CE6B0E0.2030900@parrot.com> <4CF10EF0.4010309@codeaurora.org> <1290925809.2529.313.camel@helium> In-Reply-To: <1290925809.2529.313.camel@helium> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-arm-msm-owner@vger.kernel.org List-ID: To: David Brownell Cc: Matthieu CASTET , Brian Swetland , "greg@kroah.com" , "linux-usb@vger.kernel.org" , "linux-arm-msm@vger.kernel.org" , Mike Lockwood Hi Dave, On 11/28/2010 12:00 PM, David Brownell wrote: > >> implementing specific hooks needed for MSM. I am relying on >> gadget_is_xxx() macro for MSM specific workarounds. > > NEVER DO THAT from inside controller drivers. Here we are using the macro in ci13xxx_udc core which is included by two gadget controller drivers. > > (If the code isn't specific to the msm silicon, and works on > other vendors' implementations too, it'd misbehave anyway. > > Those calls are for gadget drivers, e.g. to embed knowledge about > controller issues which can't be detected by looking at > what's advertised by the gadget controller device. Using them isn't > encouraged. > > > Controller drivers should see what hardware they're talking to by > actually talking to the chip and detecting any quirks (be they > revision-specific or otherwise). In some cases platform_data will > be the way to package such information. > We need the following hooks/extension in ci13xxx_udc for MSM SoC. 1. MSM USB device controller depends on OTG driver for clocks, Low power mode, and PHY initialization. So udc_probe() must fail if otg_get_transceiver() fails. 2. By default streaming mode is enabled in ci13xxx controller. It has to be disabled due to some known issues. 3. Currently, pull-up is enabled upon gadget driver registration. But we want to enable only upon VBUS presence. also controller must be reset before enabling the pull-up as the controller was in host mode before. 4. Hardware registers should not be accessed in udc_probe() I have started with flags to achieve the above and ended up with following: TRANSCEIVER_IS_REQUIRED: Fail udc_probe() if otg_get_transceiver() == NULL SKIP_RESET_IN_PROBE: avoid resetting the hardware in udc_prob() ENABLE_PULLUP_UPON_VBUS: Enable pull-up upon VBUS RESET_BEFORE_PULLUP: Reset the hardware before pull-up DISABLE_STREAM_MODE: Disable streaming mode A post reset callback to write into special registers after reset I thought introducing this many flags may not be a good idea and used gadget_is_xxx() macro to achieve the same. if tomorrow, some gadget controller wants to fail udc_probe() if otg_get_tranceiver(), they can too OR their gadget_is_xxx() macro. If you say using flags is not _bad_, I will take that approach. Thanks, Pavan -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.