Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752043AbbHNTlT (ORCPT ); Fri, 14 Aug 2015 15:41:19 -0400 Received: from smtprelay.synopsys.com ([198.182.47.9]:46012 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750703AbbHNTlR convert rfc822-to-8bit (ORCPT ); Fri, 14 Aug 2015 15:41:17 -0400 From: John Youn To: Yunzhi Li , John Youn , "jwerner@chromium.org" , "dianders@chromium.org" CC: "huangtao@rock-chips.com" , "cf@rock-chips.com" , "hl@rock-chips.com" , "wulf@rock-chips.com" , "gregory.herrero@intel.com" , "linux-rockchip@lists.infradead.org" , Greg Kroah-Hartman , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v1 1/3] usb: dwc2: reset AHB hclk domain before init Thread-Topic: [PATCH v1 1/3] usb: dwc2: reset AHB hclk domain before init Thread-Index: AQHQ1AtYMMVWzUHw2kK+pG1YmrjVMg== Date: Fri, 14 Aug 2015 19:41:13 +0000 Message-ID: <2B3535C5ECE8B5419E3ECBE300772909017528F2F9@US01WEMBX2.internal.synopsys.com> References: <1439279787-26674-1-git-send-email-lyz@rock-chips.com> <2B3535C5ECE8B5419E3ECBE300772909017528DC44@US01WEMBX2.internal.synopsys.com> <55CD6078.8010502@rock-chips.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.9.139.24] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2696 Lines: 70 On 8/13/2015 8:29 PM, Yunzhi Li wrote: > > > 在 2015/8/14 8:09, John Youn 写道: >> On 8/11/2015 12:57 AM, Yunzhi Li wrote: >>> We initiate dwc2 usb controller in BIOS, when kernel driver >>> start-up we should reset AHB hclk domain to reset all AHB >>> interface registers to default. Without this the FIFO value >>> setting might be incorrect because calculating FIFO size need the >>> power-on value of GRXFSIZ/GNPTXFSIZ/HPTXFSIZ registers. >>> >>> This patch could avoid warnning massage like in rk3288 platform: >>> [ 2.074764] dwc2 ff580000.usb: 256 invalid for >>> host_perio_tx_fifo_size. Check HW configuration. >>> >>> ...... >> I didn't receive the other two patches in this series so I was >> confused about where the "ahb_reset" was coming from when I >> replied to your other patch. >> >> I see you changed the name and documented the DT so never mind. >> >> Another thing is that there probably shouldn't be a debug >> message on the IS_ERR condition since that is the common case >> and of no interest to other platforms. >> >> The other two resets you added aren't used by the driver >> anywhere right? Maybe those should be left out until they are. >> >> John >> > Hi John , > > Here is the other two patches : > https://patchwork.kernel.org/patch/6989541/ > https://patchwork.kernel.org/patch/6989531/ > > ahb_reset is hreset_n signal of dwc2 IP. Our rk3288 SoC implement > connect this signal to a special > register in clock ang reset unit (CRU) module, set this register will > reset dwc2 control and status registers(CSR) > to default value. You could find more info in < Hi Speed On-TheGo (OTG) Databook 3.10a>> > 4.4.1 System Clock and Reset Signals. > > Our problem is that dwc2_get_hwparams() reads fifo size registers and > reguards it as the power-on reset value, > then dwc2_set_param_host_perio_tx_fifo_size() will check this value and > make sure the new fifo size value is no bigger > than the power-on reset value. But we init and set these fifo registers > in BIOS, so here hw->xxx_fifo_size is not the > real power-on reset vaule. So we hope to reset CSR before > dwc2_get_hwparams(). > > I have another ideal: we might use GRSTCTL.CSftRst instead of hreset_n > to reset dwc2 CSR. Yes, please try doing that before calling dwc2_get_hwparams(). Maybe by calling dwc2_core_reset(). If that works for you, I think it would be better. John -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/