From: Krzysztof Kozlowski <krzk@kernel.org>
To: Badhri Jagan Sridharan <badhri@google.com>
Cc: Thinh.Nguyen@synopsys.com, gregkh@linuxfoundation.org,
felipe.balbi@linux.intel.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, johnyoun@synopsys.com,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, jameswei@google.com,
stable@kernel.org
Subject: Re: [PATCH v1 1/2] dt-bindings: usb: snps,dwc3: Add property for imod
Date: Wed, 5 Feb 2025 20:35:09 +0100 [thread overview]
Message-ID: <73d4153e-cc03-45ba-ae2e-3b9f4baf7346@kernel.org> (raw)
In-Reply-To: <CAPTae5+xF0B64AhT5fjMU9tcW8cT9smO5eUD=Wpsiw2CKAhDAQ@mail.gmail.com>
On 05/02/2025 19:19, Badhri Jagan Sridharan wrote:
>>>>
>>>>> + during device mode operation. A value of 0 disables the interrupt
>>>>> + throttling logic and interrupts are generated immediately if event
>>>>> + count becomes non-zero. Otherwise, the interrupt is signaled when
>>>>> + all of the following conditons are met which are, EVNT_HANDLER_BUSY
>>>>> + is 0, event count is non-zero and at least 250ns increments of this
>>>>> + value has elapsed since the last time interrupt was de-asserted.
>>>>
>>>> Why is this property of a board? Why different boards would wait
>>>> different amount of time?
>>>
>>> Interrupt moderation allows batch processing of events reported by the
>>> controller.
>>> A very low value of snps,device-mode-intrpt-mod-interval-ns implies
>>> that the controller will interrupt more often to make the host
>>> processor process a smaller set of events Vs a larger value will wake
>>> up the host processor at longer intervals to process events (likely
>>> more). So depending what the board is designed for this can be tuned
>>> to achieve the needed outcome.
>>
>> I do not see dependency on the board. Host has the same CPU always, so
>> it processes with the same speed.
>
> By "host processor", I am referring to the CPU which is scheduling
> the TRBs and responding to the events reported by the Synopsys DWC3
> controller. In a nutshell, the CPU which is driving the Synopsys DWC3
> controller. The Synopsys DWC3 controller could be paired with any CPU
> configuration and therefore is "Host has the same CPU always" a fair
> assumption to be made ?
Not really, this is part of a SoC, so DWC3 controller is always here
fixed per given setup with given CPU. You claim that this is independent
of SoC, but so far arguments do not support that statement. This is
related to given SoC, so no need for this property and you can deduce
everything from SoC.
You push this as a property because you (or vendor) do not want to
upstream your SoC. That's common pattern, seen here many times. BTW,
good counter argument would be to show me patches for upstream DTS users
of this. Actually that would be very easy way to finish discussion...
but there are no patches, right? Why? Because it is not upstream and it
is done for downstream solution. Sorry, no. Develop code how upstream
develops, not downstream.
Best regards,
Krzysztof
next prev parent reply other threads:[~2025-02-05 19:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-02 3:50 [PATCH v1 1/2] dt-bindings: usb: snps,dwc3: Add property for imod Badhri Jagan Sridharan
2025-02-02 3:51 ` [PATCH v1 2/2] usb: dwc3: core: Obtain imod_interval from device tree Badhri Jagan Sridharan
2025-02-04 0:46 ` Thinh Nguyen
2025-02-05 8:39 ` Badhri Jagan Sridharan
2025-02-02 14:11 ` [PATCH v1 1/2] dt-bindings: usb: snps,dwc3: Add property for imod Krzysztof Kozlowski
2025-02-02 19:57 ` Krzysztof Kozlowski
2025-02-05 9:07 ` Badhri Jagan Sridharan
2025-02-05 13:50 ` Krzysztof Kozlowski
2025-02-05 18:19 ` Badhri Jagan Sridharan
2025-02-05 19:35 ` Krzysztof Kozlowski [this message]
2025-02-07 5:15 ` Badhri Jagan Sridharan
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=73d4153e-cc03-45ba-ae2e-3b9f4baf7346@kernel.org \
--to=krzk@kernel.org \
--cc=Thinh.Nguyen@synopsys.com \
--cc=badhri@google.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=felipe.balbi@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jameswei@google.com \
--cc=johnyoun@synopsys.com \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=robh@kernel.org \
--cc=stable@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