From: Felipe Balbi <balbi@kernel.org>
To: Rob Herring <robh@kernel.org>
Cc: Heiko Stuebner <heiko@sntech.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
linux-rockchip@lists.infradead.org,
Johan Jonker <jbx6244@gmail.com>,
linux-arm-kernel@lists.infradead.org, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] dt-bindings: usb: rockchip,dwc3: Move RK3399 to its own schema
Date: Fri, 23 Dec 2022 12:34:26 +0200 [thread overview]
Message-ID: <875ye29znx.fsf@balbi.sh> (raw)
In-Reply-To: <CAL_JsqLo4qZRTOu7UR_AN_jHNgiFZp39dsXYwWnD_njyDQfmAA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1498 bytes --]
Rob Herring <robh@kernel.org> writes:
> On Tue, Dec 20, 2022 at 1:37 AM Felipe Balbi <balbi@kernel.org> wrote:
>>
>> Rob Herring <robh@kernel.org> writes:
>>
>> > The rockchip,dwc3.yaml schema defines a single DWC3 node, but the RK3399
>> > uses the discouraged parent wrapper node and child 'generic' DWC3 node.
>>
>> Why discouraged? Splitting those two separate devices (yes, they are
>> separate physical modules) has greatly simplified e.g. power management
>> and encapsulation of the core module.
>
> Sometimes they are separate and that's fine, but often it's just
> different clocks, resets, etc. and that's no different from every
> other block.
Right, then the argument is that all other blocks are not modelling the
HW as they should :)
> If there's wrapper registers or something clearly extra, then I agree
> a wrapper parent node makes sense.
There's always wrapper-specific registers. Some wrappers even add custom
functionality. IIRC Qcom added a HW-based URB "scheduler" or some sort.
> Otherwise, for cases like RK3399, I don't think it does, but we're
> stuck with it now.
>
> Also, we have this pattern pretty much nowhere else and DWC3 is not
> special.
No, it's not. But it could just be the first example of the driver
actually modelling the underlying HW.
In any case, I was just curious with your opinion that this model is
discouraged, as it's not stated anywhere in the kernel's documentation.
Happy holidays
--
balbi
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@kernel.org>
To: Rob Herring <robh@kernel.org>
Cc: Heiko Stuebner <heiko@sntech.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
linux-rockchip@lists.infradead.org,
Johan Jonker <jbx6244@gmail.com>,
linux-arm-kernel@lists.infradead.org, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] dt-bindings: usb: rockchip,dwc3: Move RK3399 to its own schema
Date: Fri, 23 Dec 2022 12:34:26 +0200 [thread overview]
Message-ID: <875ye29znx.fsf@balbi.sh> (raw)
In-Reply-To: <CAL_JsqLo4qZRTOu7UR_AN_jHNgiFZp39dsXYwWnD_njyDQfmAA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]
Rob Herring <robh@kernel.org> writes:
> On Tue, Dec 20, 2022 at 1:37 AM Felipe Balbi <balbi@kernel.org> wrote:
>>
>> Rob Herring <robh@kernel.org> writes:
>>
>> > The rockchip,dwc3.yaml schema defines a single DWC3 node, but the RK3399
>> > uses the discouraged parent wrapper node and child 'generic' DWC3 node.
>>
>> Why discouraged? Splitting those two separate devices (yes, they are
>> separate physical modules) has greatly simplified e.g. power management
>> and encapsulation of the core module.
>
> Sometimes they are separate and that's fine, but often it's just
> different clocks, resets, etc. and that's no different from every
> other block.
Right, then the argument is that all other blocks are not modelling the
HW as they should :)
> If there's wrapper registers or something clearly extra, then I agree
> a wrapper parent node makes sense.
There's always wrapper-specific registers. Some wrappers even add custom
functionality. IIRC Qcom added a HW-based URB "scheduler" or some sort.
> Otherwise, for cases like RK3399, I don't think it does, but we're
> stuck with it now.
>
> Also, we have this pattern pretty much nowhere else and DWC3 is not
> special.
No, it's not. But it could just be the first example of the driver
actually modelling the underlying HW.
In any case, I was just curious with your opinion that this model is
discouraged, as it's not stated anywhere in the kernel's documentation.
Happy holidays
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@kernel.org>
To: Rob Herring <robh@kernel.org>
Cc: Heiko Stuebner <heiko@sntech.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
linux-rockchip@lists.infradead.org,
Johan Jonker <jbx6244@gmail.com>,
linux-arm-kernel@lists.infradead.org, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] dt-bindings: usb: rockchip,dwc3: Move RK3399 to its own schema
Date: Fri, 23 Dec 2022 12:34:26 +0200 [thread overview]
Message-ID: <875ye29znx.fsf@balbi.sh> (raw)
In-Reply-To: <CAL_JsqLo4qZRTOu7UR_AN_jHNgiFZp39dsXYwWnD_njyDQfmAA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1498 bytes --]
Rob Herring <robh@kernel.org> writes:
> On Tue, Dec 20, 2022 at 1:37 AM Felipe Balbi <balbi@kernel.org> wrote:
>>
>> Rob Herring <robh@kernel.org> writes:
>>
>> > The rockchip,dwc3.yaml schema defines a single DWC3 node, but the RK3399
>> > uses the discouraged parent wrapper node and child 'generic' DWC3 node.
>>
>> Why discouraged? Splitting those two separate devices (yes, they are
>> separate physical modules) has greatly simplified e.g. power management
>> and encapsulation of the core module.
>
> Sometimes they are separate and that's fine, but often it's just
> different clocks, resets, etc. and that's no different from every
> other block.
Right, then the argument is that all other blocks are not modelling the
HW as they should :)
> If there's wrapper registers or something clearly extra, then I agree
> a wrapper parent node makes sense.
There's always wrapper-specific registers. Some wrappers even add custom
functionality. IIRC Qcom added a HW-based URB "scheduler" or some sort.
> Otherwise, for cases like RK3399, I don't think it does, but we're
> stuck with it now.
>
> Also, we have this pattern pretty much nowhere else and DWC3 is not
> special.
No, it's not. But it could just be the first example of the driver
actually modelling the underlying HW.
In any case, I was just curious with your opinion that this model is
discouraged, as it's not stated anywhere in the kernel's documentation.
Happy holidays
--
balbi
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-12-23 10:39 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-19 19:10 [PATCH 1/2] dt-bindings: usb: snps,dwc3: Allow power-domains property Rob Herring
2022-12-19 19:10 ` Rob Herring
2022-12-19 19:10 ` Rob Herring
2022-12-19 19:10 ` [PATCH 2/2] dt-bindings: usb: rockchip,dwc3: Move RK3399 to its own schema Rob Herring
2022-12-19 19:10 ` Rob Herring
2022-12-19 19:10 ` Rob Herring
2022-12-20 7:37 ` Felipe Balbi
2022-12-20 7:37 ` Felipe Balbi
2022-12-20 7:37 ` Felipe Balbi
2022-12-20 13:54 ` Rob Herring
2022-12-20 13:54 ` Rob Herring
2022-12-20 13:54 ` Rob Herring
2022-12-23 10:34 ` Felipe Balbi [this message]
2022-12-23 10:34 ` Felipe Balbi
2022-12-23 10:34 ` Felipe Balbi
2022-12-20 7:34 ` [PATCH 1/2] dt-bindings: usb: snps,dwc3: Allow power-domains property Felipe Balbi
2022-12-20 7:34 ` Felipe Balbi
2022-12-20 7:34 ` Felipe Balbi
2022-12-20 14:04 ` Rob Herring
2022-12-20 14:04 ` Rob Herring
2022-12-20 14:04 ` Rob Herring
2022-12-23 10:31 ` Felipe Balbi
2022-12-23 10:31 ` Felipe Balbi
2022-12-23 10:31 ` Felipe Balbi
2022-12-23 11:06 ` Krzysztof Kozlowski
2022-12-23 11:06 ` Krzysztof Kozlowski
2022-12-23 11:06 ` Krzysztof Kozlowski
2022-12-23 23:57 ` Thinh Nguyen
2022-12-23 23:57 ` Thinh Nguyen
2022-12-23 23:57 ` Thinh Nguyen
2022-12-24 17:37 ` Rob Herring
2022-12-24 17:37 ` Rob Herring
2022-12-24 17:37 ` Rob Herring
2022-12-30 8:43 ` Felipe Balbi
2022-12-30 8:43 ` Felipe Balbi
2022-12-30 8:43 ` Felipe Balbi
2022-12-30 16:54 ` Rob Herring
2022-12-30 16:54 ` Rob Herring
2022-12-30 16:54 ` Rob Herring
2022-12-30 17:08 ` Felipe Balbi
2022-12-30 17:08 ` Felipe Balbi
2022-12-30 17:08 ` Felipe Balbi
2023-01-03 18:58 ` Rob Herring
2023-01-03 18:58 ` Rob Herring
2023-01-03 18:58 ` Rob Herring
2023-01-09 19:40 ` Thinh Nguyen
2023-01-09 19:40 ` Thinh Nguyen
2023-01-09 19:40 ` Thinh Nguyen
2023-01-09 20:42 ` Rob Herring
2023-01-09 20:42 ` Rob Herring
2023-01-09 20:42 ` Rob Herring
2023-01-09 21:37 ` Thinh Nguyen
2023-01-09 21:37 ` Thinh Nguyen
2023-01-09 21:37 ` Thinh Nguyen
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=875ye29znx.fsf@balbi.sh \
--to=balbi@kernel.org \
--cc=Thinh.Nguyen@synopsys.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=heiko@sntech.de \
--cc=jbx6244@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=robh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.