From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Rob Herring <robh@kernel.org>, Baruch Siach <baruch@tkos.co.il>
Cc: Felipe Balbi <balbi@kernel.org>,
Kishon Vijay Abraham I <kishon@ti.com>,
Vinod Koul <vkoul@kernel.org>, Andy Gross <agross@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Balaji Prakash J <bjagadee@codeaurora.org>,
Kathiravan T <kathirav@codeaurora.org>,
Jack Pham <jackp@codeaurora.org>,
Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v2 4/6] usb: dwc3: reference clock period configuration
Date: Fri, 13 Aug 2021 19:52:03 +0000 [thread overview]
Message-ID: <53784e58-6da4-ad61-6b9e-46697fb3d695@synopsys.com> (raw)
In-Reply-To: <YRarmizUtzIunV1P@robh.at.kernel.org>
Rob Herring wrote:
> On Wed, Aug 04, 2021 at 05:22:27PM +0300, Baruch Siach wrote:
>> Hi Felipe,
>>
>> On Wed, Aug 04 2021, Felipe Balbi wrote:
>>> Baruch Siach <baruch@tkos.co.il> writes:
>>>> @@ -1371,6 +1398,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
>>>> &dwc->hsphy_interface);
>>>> device_property_read_u32(dev, "snps,quirk-frame-length-adjustment",
>>>> &dwc->fladj);
>>>> + device_property_read_u32(dev, "snps,ref-clock-period",
>>>> + &dwc->ref_clk_per);
>>>
>>> I wonder if it would make more sense to pass an actual clock reference
>>> here. If valid, then reconfigure the period to the value returned by
>>> clk_get_rate(). It would avoid yet another DT binding. If we make the
>>> clock optional, then we won't affect any other platforms. The clock
>>> itself could be a regular fixed clock node.
>>
>> Thinh Nguyen asked to add a dedicated DT property. He explained that
>> clk_get_rate() does not work for PCI hosted dwc3. This is the most
>> complete summary of the discussion:
>>
>> https://urldefense.com/v3/__https://lore.kernel.org/r/c797e9cb-cae6-c0b6-5714-169c2ad79d32@synopsys.com__;!!A4F2R9G_pg!Nh6rqp_aOd8XIvqELvDRQe5ooZf13UZKwmn9lWcRgdbyMKpTMzL8HasrB1X2Ojvumo8g$
>
> PCI devices can have DT nodes with clock properties too. Or use the
> VID/PID to infer the frequency. Or use 'clock-frequency' property.
>
> It boils down to we have lots of standard properties for clocks and
> clock configuration, so custom properties are a NAK.
>
Do we have DT node for the PCI device before discovering the device from
PCI bus enumeration? I don't think we can find the clock properties from
its configuration space. For our HAPS devices, we can't use VID/PID to
infer the frequency since our phy and ref clock may change.
Does "clock-frequency" mean ref clock? If so, let's use that?
Thanks,
Thinh
next prev parent reply other threads:[~2021-08-13 19:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-04 14:05 [PATCH v2 1/6] dt-bindings: phy: qcom,qmp: Add IPQ6018 USB3 PHY Baruch Siach
2021-08-04 14:05 ` [PATCH v2 2/6] phy: qcom-qmp: add USB3 PHY support for IPQ6018 Baruch Siach
2021-08-06 13:05 ` Vinod Koul
2021-08-04 14:05 ` [PATCH v2 3/6] dt-bindings: usb: dwc3: add reference clock period Baruch Siach
2021-08-13 17:22 ` Rob Herring
2021-08-04 14:05 ` [PATCH v2 4/6] usb: dwc3: reference clock period configuration Baruch Siach
2021-08-04 14:11 ` Felipe Balbi
2021-08-04 14:22 ` Baruch Siach
2021-08-04 14:30 ` Felipe Balbi
2021-08-09 22:13 ` Thinh Nguyen
2021-08-13 17:27 ` Rob Herring
2021-08-13 19:52 ` Thinh Nguyen [this message]
2021-08-04 14:05 ` [PATCH v2 5/6] dt-bindings: usb: qcom,dwc3: add binding for IPQ6018 Baruch Siach
2021-08-13 17:28 ` Rob Herring
2021-08-04 14:05 ` [PATCH v2 6/6] arm64: qcom: ipq6018: add usb3 DT description Baruch Siach
2021-08-06 13:05 ` [PATCH v2 1/6] dt-bindings: phy: qcom,qmp: Add IPQ6018 USB3 PHY Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53784e58-6da4-ad61-6b9e-46697fb3d695@synopsys.com \
--to=thinh.nguyen@synopsys.com \
--cc=agross@kernel.org \
--cc=balbi@kernel.org \
--cc=baruch@tkos.co.il \
--cc=bjagadee@codeaurora.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jackp@codeaurora.org \
--cc=kathirav@codeaurora.org \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=robh@kernel.org \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).