* Re: [PATCH v7 04/37] dt-bindings: interrupt-controller: Add header for Renesas SH3/4 INTC.
From: Krzysztof Kozlowski @ 2024-04-04 6:07 UTC (permalink / raw)
To: Yoshinori Sato, linux-sh
Cc: Damien Le Moal, Niklas Cassel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
David Airlie, Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Thomas Gleixner, Bjorn Helgaas,
Lorenzo Pieralisi, Krzysztof Wilczyński, Greg Kroah-Hartman,
Jiri Slaby, Magnus Damm, Daniel Lezcano, Rich Felker,
John Paul Adrian Glaubitz, Lee Jones, Helge Deller,
Heiko Stuebner, Shawn Guo, Sebastian Reichel, Chris Morgan,
Linus Walleij, Arnd Bergmann, David Rientjes, Hyeonggon Yoo,
Vlastimil Babka, Baoquan He, Andrew Morton, Guenter Roeck,
Kefeng Wang, Stephen Rothwell, Javier Martinez Canillas, Guo Ren,
Azeem Shaikh, Max Filippov, Jonathan Corbet, Jacky Huang,
Herve Codina, Manikanta Guntupalli, Anup Patel, Biju Das,
Uwe Kleine-König, Sam Ravnborg, Sergey Shtylyov,
Laurent Pinchart, linux-ide, devicetree, linux-kernel,
linux-renesas-soc, linux-clk, dri-devel, linux-pci, linux-serial,
linux-fbdev
In-Reply-To: <d50827196f7e1201bb9a62656fb04223a8989f1d.1712205900.git.ysato@users.sourceforge.jp>
On 04/04/2024 06:59, Yoshinori Sato wrote:
> Renesas SH7751 Interrupt controller priority register define.
>
> Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Nothing improved, still NAK.
This is a friendly reminder during the review process.
It seems my or other reviewer's previous comments were not fully
addressed. Maybe the feedback got lost between the quotes, maybe you
just forgot to apply it. Please go back to the previous discussion and
either implement all requested changes or keep discussing them.
Thank you.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RESEND v7 04/37] dt-bindings: interrupt-controller: Add header for Renesas SH3/4 INTC.
From: Krzysztof Kozlowski @ 2024-04-04 6:08 UTC (permalink / raw)
To: Yoshinori Sato, linux-sh
Cc: Damien Le Moal, Niklas Cassel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
David Airlie, Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Thomas Gleixner, Bjorn Helgaas,
Lorenzo Pieralisi, Krzysztof Wilczyński, Greg Kroah-Hartman,
Jiri Slaby, Magnus Damm, Daniel Lezcano, Rich Felker,
John Paul Adrian Glaubitz, Lee Jones, Helge Deller,
Heiko Stuebner, Shawn Guo, Sebastian Reichel, Chris Morgan,
Linus Walleij, Arnd Bergmann, David Rientjes, Hyeonggon Yoo,
Vlastimil Babka, Baoquan He, Andrew Morton, Guenter Roeck,
Kefeng Wang, Stephen Rothwell, Javier Martinez Canillas, Guo Ren,
Azeem Shaikh, Max Filippov, Jonathan Corbet, Jacky Huang,
Herve Codina, Manikanta Guntupalli, Anup Patel, Biju Das,
Uwe Kleine-König, Sam Ravnborg, Sergey Shtylyov,
Laurent Pinchart, linux-ide, devicetree, linux-kernel,
linux-renesas-soc, linux-clk, dri-devel, linux-pci, linux-serial,
linux-fbdev
In-Reply-To: <d50827196f7e1201bb9a62656fb04223a8989f1d.1712207606.git.ysato@users.sourceforge.jp>
On 04/04/2024 07:14, Yoshinori Sato wrote:
> Renesas SH7751 Interrupt controller priority register define.
>
> Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
I got two 37-patchsets...
Anyway, this also did not improve. NAK.
This is a friendly reminder during the review process.
It seems my or other reviewer's previous comments were not fully
addressed. Maybe the feedback got lost between the quotes, maybe you
just forgot to apply it. Please go back to the previous discussion and
either implement all requested changes or keep discussing them.
Thank you.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: usb: Add the binding example for the Genesys Logic GL3523 hub
From: Krzysztof Kozlowski @ 2024-04-04 6:12 UTC (permalink / raw)
To: Anand Moon
Cc: Rob Herring, Greg Kroah-Hartman, Krzysztof Kozlowski,
Conor Dooley, Icenowy Zheng, Neil Armstrong, linux-amlogic,
Conor Dooley, linux-usb, devicetree, linux-kernel
In-Reply-To: <CANAwSgSftb3KkXvzNyGGixVtK8SWcOYjxO9WWpLt-B3mf_B6tg@mail.gmail.com>
On 04/04/2024 06:27, Anand Moon wrote:
> Hi Krzysztof,
>
> On Tue, 12 Dec 2023 at 18:47, Anand Moon <linux.amoon@gmail.com> wrote:
>>
>> Hi Krzysztof,
>>
>> On Tue, 12 Dec 2023 at 18:39, Krzysztof Kozlowski
>> <krzysztof.kozlowski@linaro.org> wrote:
>>>
>>> On 12/12/2023 13:51, Anand Moon wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On Tue, 12 Dec 2023 at 17:22, Krzysztof Kozlowski
>>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>>
>>>>> On 12/12/2023 12:37, Anand Moon wrote:
>>>>>>
>>>>>> Here is the list of warnings I observed with this patch
>>>>>>
>>>>>> DTC_CHK Documentation/devicetree/bindings/usb/nvidia,tegra186-xusb.example.dtb
>>>>>> /home/amoon/mainline/linux-amlogic-6.y-devel/Documentation/devicetree/bindings/usb/usb-device.example.dtb:
>>>>>> hub@1: 'vdd-supply' is a required property
>>>>>
>>>>> You always require the property, but it is not valid for some devices.
>>>>> Just require it only where it is applicable (in if:then: clause).
>>>>>
>>>> I had already done this check many times before.
>>>
>>> I don't ask you to check. I ask you to change the code.
>>>
>> I have tried this and it's not working for me.
>>
>>>> my v6 original patch was doing the same and it passed all the tests
>>>> but since I updated the required field it not parsing correctly.
>>>
>>> Your original v6 patch was different. I don't understand what you are
>>> trying to achieve. Or rather: how is it different, that my simple advice
>>> above does not work for you (as in the past you reply with some really
>>> unrelated sentence).
>>>
>> Ok, It's my poor English grammar, thanks for your review comments.
>>
>>> Best regards,
>>> Krzysztof
>>>
>
> Any reason this device tree binding got removed,I cannot find this file
> Can not find the commit which removed this file.
Use git log.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/4] ARM: dts: aspeed: greatlakes: correct Mellanox multi-host property
From: Krzysztof Kozlowski @ 2024-04-04 6:13 UTC (permalink / raw)
To: Andrew Jeffery, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <8610e0a8aa5c2916fa04292a10e8a843862ff0ee.camel@codeconstruct.com.au>
On 04/04/2024 03:41, Andrew Jeffery wrote:
> On Wed, 2024-04-03 at 12:04 +0200, Krzysztof Kozlowski wrote:
>> On Sat, 09 Dec 2023 11:44:09 +0100, Krzysztof Kozlowski wrote:
>>> "mlx,multi-host" is using incorrect vendor prefix and is not documented.
>>>
>>>
>>
>> These wait for ~4 months and they were not picked up. Let me know if anyone
>> else wants to take these.
>>
>> Applied, thanks!
>>
>> [1/4] ARM: dts: aspeed: greatlakes: correct Mellanox multi-host property
>> https://git.kernel.org/krzk/linux-dt/c/7da85354c4fa35b862294dbbb450baeb405b5a92
>> [2/4] ARM: dts: aspeed: minerva-cmc: correct Mellanox multi-host property
>> https://git.kernel.org/krzk/linux-dt/c/e515719c17beb9625a90039f6c45fa36d58bdda2
>> [3/4] ARM: dts: aspeed: yosemite4: correct Mellanox multi-host property
>> https://git.kernel.org/krzk/linux-dt/c/af3deaf9bcb4571feb89a4050c7ad75de9aa8e1e
>> [4/4] ARM: dts: aspeed: yosemitev2: correct Mellanox multi-host property
>> https://git.kernel.org/krzk/linux-dt/c/cac1c1dda6130771e06ace030b1b0ed62096a912
>>
>> Best regards,
>
> Ah, my apologies. Joel's on leave and I'm accumulating patches in a
> tree for him in the mean time. I've had some things going on
> professionally (changed jobs) and personally, and these fell into a bit
> of a hole.
>
> I'm okay for these patches to be integrated through your tree, given
> you've already applied them. Feel free to add acks if your branch
> allows:
>
> Acked-by: Andrew Jeffery <andrew@codeconstruct.com.au>
>
> I'm working to stay on top of things a bit more now than I have in the
> recent past, so hopefully I won't miss patches again in the future.
Stephen reported conflict, although trivial, but maybe better if you
take them? I can rebase and resend.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 0/6] Add Synopsys DesignWare HDMI RX Controller
From: Krzysztof Kozlowski @ 2024-04-04 6:15 UTC (permalink / raw)
To: Heiko Stübner, Shreeya Patel
Cc: mchehab, hverkuil, hverkuil-cisco, robh, krzysztof.kozlowski+dt,
conor+dt, mturquette, sboyd, p.zabel, shawn.wen, kernel,
linux-kernel, linux-media, devicetree, linux-arm-kernel,
linux-rockchip, linux-clk, linux-arm
In-Reply-To: <3049149.687JKscXgg@diego>
On 04/04/2024 00:48, Heiko Stübner wrote:
> Am Mittwoch, 3. April 2024, 13:24:05 CEST schrieb Krzysztof Kozlowski:
>> On 03/04/2024 13:20, Shreeya Patel wrote:
>>> On Wednesday, April 03, 2024 15:51 IST, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
>>>
>>>> On 03/04/2024 11:24, Shreeya Patel wrote:
>>>>> On Thursday, March 28, 2024 04:20 IST, Shreeya Patel <shreeya.patel@collabora.com> wrote:
>>>>>
>>>>>> This series implements support for the Synopsys DesignWare
>>>>>> HDMI RX Controller, being compliant with standard HDMI 1.4b
>>>>>> and HDMI 2.0.
>>>>>>
>>>>>
>>>>> Hi Mauro and Hans,
>>>>>
>>>>> I haven't received any reviews so far. Hence, this is just a gentle reminder to review this patch series.
>>>>
>>>> Why did you put clk changes here? These go via different subsystem. That
>>>> might be one of obstacles for your patchset.
>>>>
>>>
>>> I added clock changes in this patch series because HDMIRX driver depends on it.
>>> I thought it is wrong to send the driver patches which don't even compile?
>>
>> Hm, why HDMIRX driver depends on clock? How? This sounds really wrong.
>> Please get it reviewed internally first.
>
> For the change in question, the clock controller on the soc also handles
> the reset controls (hence its name CRU, clock-and-reset-unit) .
>
> There are at least 660 reset lines in the unit and it seems the hdmi-rx one
> was overlooked on the initial submission, hence patches 1+2 add the
> reset-line.
>
> Of course, here only the "arm64: dts:" patch depends on the clock
> change, is it references the new reset-id.
Wait, that's expected, but it is not what was written. Claim was HDMIRX
driver depends *build time* ("don't even compile").
>
>
> Am Mittwoch, 3. April 2024, 12:22:57 CEST schrieb Krzysztof Kozlowski:
>> Please do not engage multiple subsystems in one patchset, if not
>> necessary. Especially do not mix DTS into media or USB subsystems. And
>> do not put DTS in the middle!
>
> picking up your reply from patch 4/6, there seem to be different "schools
> of thought" for this. Some maintainers might want to really only see
> patches that are explicitly for their subsystem - I guess networking
> might be a prime example for that, who will essentially apply whole series'
> if nobody protests in time (including dts patches)
There is no school saying DTS is allowed to be in the middle.
Other schools are indeed saying that seeing DTS is good and
recommendation is to post it separate and provide a link. That's way you
avoid DTS being pulled by Greg, media or networking.
>
> On the other hand I also remember seeing requests for "the full picture"
> and individual maintainers then just picking and applying the patches
> meant for their subsystem.
>
> The series as it stands right now is nice in that it allows (random)
> developers to just pick it up, apply it to a tree and test the actual driver
> without needing to hunt for multiple dependant series.
>
>
> Of course you're right, the "arm64: dts:" patch should be the last in the
> series and not be in the middle of it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 0/6] Add Synopsys DesignWare HDMI RX Controller
From: Krzysztof Kozlowski @ 2024-04-04 6:17 UTC (permalink / raw)
To: Deborah Brouwer
Cc: Shreeya Patel, mchehab, hverkuil, hverkuil-cisco, heiko, robh,
krzysztof.kozlowski+dt, conor+dt, mturquette, sboyd, p.zabel,
shawn.wen, kernel, linux-kernel, linux-media, devicetree,
linux-arm-kernel, linux-rockchip, linux-clk, linux-arm
In-Reply-To: <Zg3Gh8P97GaBtgAB@mz550>
On 03/04/2024 23:13, Deborah Brouwer wrote:
> On Wed, Apr 03, 2024 at 01:24:05PM +0200, Krzysztof Kozlowski wrote:
>> On 03/04/2024 13:20, Shreeya Patel wrote:
>>> On Wednesday, April 03, 2024 15:51 IST, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
>>>
>>>> On 03/04/2024 11:24, Shreeya Patel wrote:
>>>>> On Thursday, March 28, 2024 04:20 IST, Shreeya Patel <shreeya.patel@collabora.com> wrote:
>>>>>
>>>>>> This series implements support for the Synopsys DesignWare
>>>>>> HDMI RX Controller, being compliant with standard HDMI 1.4b
>>>>>> and HDMI 2.0.
>>>>>>
>>>>>
>>>>> Hi Mauro and Hans,
>>>>>
>>>>> I haven't received any reviews so far. Hence, this is just a gentle reminder to review this patch series.
>>>>
>>>> Why did you put clk changes here? These go via different subsystem. That
>>>> might be one of obstacles for your patchset.
>>>>
>>>
>>> I added clock changes in this patch series because HDMIRX driver depends on it.
>>> I thought it is wrong to send the driver patches which don't even compile?
>>
>> Hm, why HDMIRX driver depends on clock? How? This sounds really wrong.
>> Please get it reviewed internally first.
>>
>>>
>>> Since you are a more experienced developer, can you help me understand what would
>>> be the right way to send patches in such scenarios?
>>
>> I am not the substitute for your Collabora engineers and peers. You do
>> not get free work from the community. First, do the work and review
>> internally, to solve all trivial things, like how to submit patches
>> upstream or how to make your driver buildable, and then ask community
>> for the review.
>
> I don't think Shreeya was asking for "free" work from the community.
> Her question wasn't trivial or obvious since reasonable people seem to sometimes
> disagree about where to send a patch especially if it's needed to make a series compile.
> I heard the issue was already resolved but had to say something since this accusation
> seemed so unfair.
If HDMI driver does not build because of clock driver, something is
really wrong at the basics level. Therefore I am sure my statement was
fair,. based on Shreeya statement of build failure.
I am sorry, but independence of drivers and independence of DTS is a
basic thing, so to solve such you can easily get help internally from
your experienced folks (which you have).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: PCI: qcom: Add IPQ9574 PCIe controller
From: Krzysztof Kozlowski @ 2024-04-04 6:18 UTC (permalink / raw)
To: mr.nuke.me, Bjorn Andersson, Konrad Dybcio, Bjorn Helgaas,
Lorenzo Pieralisi, Krzysztof Wilczyński, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam
Cc: ansuelsmth, robimarko, linux-arm-msm, linux-pci, devicetree,
linux-kernel
In-Reply-To: <d35c96ca-24af-fbad-74fe-ad85a433caa2@gmail.com>
On 03/04/2024 20:05, mr.nuke.me@gmail.com wrote:
>
>
> On 4/3/24 02:14, Krzysztof Kozlowski wrote:
>> On 02/04/2024 21:25, Alexandru Gagniuc wrote:
>>> IPQ9574 has PCIe controllers which are almost identical to IPQ6018.
>>> The only difference is that the "iface" clock is not required.
>>> Document this difference along with the compatible string.
>>>
>>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>>> ---
>>> .../devicetree/bindings/pci/qcom,pcie.yaml | 32 +++++++++++++++++++
>>> 1 file changed, 32 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
>>> index cf9a6910b542..6eb29547c18e 100644
>>> --- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
>>> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
>>> @@ -26,6 +26,7 @@ properties:
>>> - qcom,pcie-ipq8064-v2
>>> - qcom,pcie-ipq8074
>>> - qcom,pcie-ipq8074-gen3
>>> + - qcom,pcie-ipq9574
>>> - qcom,pcie-msm8996
>>> - qcom,pcie-qcs404
>>> - qcom,pcie-sdm845
>>> @@ -383,6 +384,35 @@ allOf:
>>> - const: axi_s # AXI Slave clock
>>> - const: axi_bridge # AXI bridge clock
>>> - const: rchng
>>> +
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + enum:
>>> + - qcom,pcie-ipq9574
>>> + then:
>>> + properties:
>>> + clocks:
>>> + minItems: 4
>>> + maxItems: 4
>>> + clock-names:
>>> + items:
>>> + - const: axi_m # AXI Master clock
>>> + - const: axi_s # AXI Slave clock
>>> + - const: axi_bridge # AXI bridge clock
>>> + - const: rchng
>>> +
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + enum:
>>> + - qcom,pcie-ipq6018
>>> + - qcom,pcie-ipq8074-gen3
>>> + - qcom,pcie-ipq9574
>>> + then:
>>
>> Do not introduce inconsistent style. All if:then: define both clocks and
>> resets, right? And after your patch not anymore?
>>
> I kept the resets in one place because they are the same cross the ipq*
> variants.
>
> Do I understand correctly that you wish me to split up the resets as well?
>
> if ipq8074 ipq6018
> clocks
> resets
>
> if ipq9754
> clocks
> resets
Yes, keep it consistent with all other cases.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 0/2] Add initial ARM MHUv3 mailbox support
From: Cristian Marussi @ 2024-04-04 6:23 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, devicetree
Cc: sudeep.holla, cristian.marussi, jassisinghbrar, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Hi,
This series adds support for the new ARM Message Handling Unit v3 mailbox
controller [1].
The ARM MHUv3 can optionally support various extensions, enabling the
usage of different transport protocols.
Patch [2/2] adds a platform driver which, as of now, provides support only
for the Doorbell extension using the combined interrupt.
On the other side, bindings in [1/2] are introduced for all the extensions
described by the specification, as long as they are of interest to an
entity running from Normal world, like Linux: as such, Doorbell, FIFO and
FastChannel extensions are documented.
In these regards, note that the ARM MHUv3 controller can optionally
implement a considerable number of interrupts to express a great deal of
events and many of such interrupts are defined as being per-channel: with
the total maximum amount of possibly implemented channels across all
extensions being 1216 (1024+128+64), it would mean *a lot* of
interrupt-names to enumerate in the bindings.
For the sake of simplicity the binding as of now only introduces interrupt
names for a mere 8-channels in the range (0,7) for each per-channel
interrupt type: the idea is to leave open the possibility to add more to
this list of numbered items only when (and if) new real HW appears that
effectively needs more than 8 channels. (like AMBA, where the maximum
number of IRQ was progressively increased when needed, AFAIU).
Based on v6.9-rc1, tested on ARM TCS23 [2]
(TCS23 reference SW stack is still to be made fully publicly available)
Thanks,
Cristian
[1]: https://developer.arm.com/documentation/aes0072/aa/?lang=en
[2]: https://community.arm.com/arm-community-blogs/b/tools-software-ides-blog/posts/total-compute-solutions-platform-software-stack-and-fvp
---
v2 -> v3
- fixed spurious tabs/spaces in DT binding
v1 -> v2
- clarified DT bindings extension descriptions around configurability
and discoverability
- removed unused labels from the DT example
- using pattern properties to define DT interrupt-names
- bumped DT interrupt maxItems to 74 (allowing uo to 8 channels per extension)
- fixed checkpatch warnings about side-effects on write/read bitfield macros
- fixed sparse errors as reported
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202403290015.tCLXudqC-lkp@intel.com/
Cristian Marussi (2):
dt-bindings: mailbox: arm,mhuv3: Add bindings
mailbox: arm_mhuv3: Add driver
.../bindings/mailbox/arm,mhuv3.yaml | 217 ++++
MAINTAINERS | 9 +
drivers/mailbox/Kconfig | 11 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm_mhuv3.c | 1063 +++++++++++++++++
5 files changed, 1302 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
create mode 100644 drivers/mailbox/arm_mhuv3.c
--
2.34.1
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: mailbox: arm,mhuv3: Add bindings
From: Cristian Marussi @ 2024-04-04 6:23 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, devicetree
Cc: sudeep.holla, cristian.marussi, jassisinghbrar, robh+dt,
krzysztof.kozlowski+dt, conor+dt
In-Reply-To: <20240404062347.3219795-1-cristian.marussi@arm.com>
Add bindings for the ARM MHUv3 Mailbox controller.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v2 -> v3
- fixed spurious tabs in dt_binding_check
v1 -> v2
- clarified extension descriptions around configurability and discoverability
- removed unused labels from the example
- using pattern properties to define interrupt-names
- bumped interrupt maxItems to 74 (allowing uo to 8 channels per extension)
---
.../bindings/mailbox/arm,mhuv3.yaml | 217 ++++++++++++++++++
1 file changed, 217 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
new file mode 100644
index 000000000000..32a8bb711464
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
@@ -0,0 +1,217 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm,mhuv3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM MHUv3 Mailbox Controller
+
+maintainers:
+ - Sudeep Holla <sudeep.holla@arm.com>
+ - Cristian Marussi <cristian.marussi@arm.com>
+
+description: |
+ The Arm Message Handling Unit (MHU) Version 3 is a mailbox controller that
+ enables unidirectional communications with remote processors through various
+ possible transport protocols.
+ The controller can optionally support a varying number of extensions that, in
+ turn, enable different kinds of transport to be used for communication.
+ Number, type and characteristics of each supported extension can be discovered
+ dynamically at runtime.
+
+ Given the unidirectional nature of the controller, an MHUv3 mailbox controller
+ is composed of a MHU Sender (MHUS) containing a PostBox (PBX) block and a MHU
+ Receiver (MHUR) containing a MailBox (MBX) block, where
+
+ PBX is used to
+ - Configure the MHU
+ - Send Transfers to the Receiver
+ - Optionally receive acknowledgment of a Transfer from the Receiver
+
+ MBX is used to
+ - Configure the MHU
+ - Receive Transfers from the Sender
+ - Optionally acknowledge Transfers sent by the Sender
+
+ Both PBX and MBX need to be present and defined in the DT description if you
+ need to establish a bidirectional communication, since you will have to
+ acquire two distinct unidirectional channels, one for each block.
+
+ As a consequence both blocks needs to be represented separately and specified
+ as distinct DT nodes in order to properly describe their resources.
+
+ Note that, though, thanks to the runtime discoverability, there is no need to
+ identify the type of blocks with distinct compatibles.
+
+ Following are the MHUv3 possible extensions.
+
+ - Doorbell Extension (DBE): DBE defines a type of channel called a Doorbell
+ Channel (DBCH). DBCH enables a single bit Transfer to be sent from the
+ Sender to Receiver. The Transfer indicates that an event has occurred.
+ When DBE is implemented, the number of DBCHs that an implementation of the
+ MHU can support is between 1 and 128, numbered starting from 0 in ascending
+ order and discoverable at run-time.
+ Each DBCH contains 32 individual fields, referred to as flags, each of which
+ can be used independently. It is possible for the Sender to send multiple
+ Transfers at once using a single DBCH, so long as each Transfer uses
+ a different flag in the DBCH.
+ Optionally, data may be transmitted through an out-of-band shared memory
+ region, wherein the MHU Doorbell is used strictly as an interrupt generation
+ mechanism, but this is out of the scope of these bindings.
+
+ - FastChannel Extension (FCE): FCE defines a type of channel called a Fast
+ Channel (FCH). FCH is intended for lower overhead communication between
+ Sender and Receiver at the expense of determinism. An FCH allows the Sender
+ to update the channel value at any time, regardless of whether the previous
+ value has been seen by the Receiver. When the Receiver reads the channel's
+ content it gets the last value written to the channel.
+ FCH is considered lossy in nature, and means that the Sender has no way of
+ knowing if, or when, the Receiver will act on the Transfer.
+ FCHs are expected to behave as RAM which generates interrupts when writes
+ occur to the locations within the RAM.
+ When FCE is implemented, the number of FCHs that an implementation of the
+ MHU can support is between 1-1024, if the FastChannel word-size is 32-bits,
+ or between 1-512, when the FastChannel word-size is 64-bits.
+ FCHs are numbered from 0 in ascending order.
+ Note that the number of FCHs and the word-size are implementation defined,
+ not configurable but discoverable at run-time.
+ Optionally, data may be transmitted through an out-of-band shared memory
+ region, wherein the MHU FastChannel is used as an interrupt generation
+ mechanism which carries also a pointer to such out-of-band data, but this
+ is out of the scope of these bindings.
+
+ - FIFO Extension (FE): FE defines a Channel type called a FIFO Channel (FFCH).
+ FFCH allows a Sender to send
+ - Multiple Transfers to the Receiver without having to wait for the
+ previous Transfer to be acknowledged by the Receiver, as long as the
+ FIFO has room for the Transfer.
+ - Transfers which require the Receiver to provide acknowledgment.
+ - Transfers which have in-band payload.
+ In all cases, the data is guaranteed to be observed by the Receiver in the
+ same order which the Sender sent it.
+ When FE is implemented, the number of FFCHs that an implementation of the
+ MHU can support is between 1 and 64, numbered starting from 0 in ascending
+ order. The number of FFCHs, their depth (same for all implemented FFCHs) and
+ the access-granularity are implementation defined, not configurable but
+ discoverable at run-time.
+ Optionally, additional data may be transmitted through an out-of-band shared
+ memory region, wherein the MHU FIFO is used to transmit, in order, a small
+ part of the payload (like a header) and a reference to the shared memory
+ area holding the remaining, bigger, chunk of the payload, but this is out of
+ the scope of these bindings.
+
+properties:
+ compatible:
+ const: arm,mhuv3
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 74
+
+ interrupt-names:
+ description: |
+ The MHUv3 controller generates a number of events some of which are used
+ to generate interrupts; as a consequence it can expose a varying number of
+ optional PBX/MBX interrupts, representing the events generated during the
+ operation of the various transport protocols associated with different
+ extensions. All interrupts of the MHU are level-sensitive.
+ Some of these optional interrupts are defined per-channel, where the
+ number of channels effectively available is implementation defined and
+ run-time discoverable.
+ In the following names are enumerated using patterns, with per-channel
+ interrupts implicitly capped at the maximum channels allowed by the
+ specification for each extension type.
+ For the sake of simplicity maxItems is anyway capped to a most plausible
+ number, assuming way less channels would be implemented than actually
+ possible.
+
+ The only mandatory interrupts on the MHU are:
+ - combined
+ - mbx-fch-xfer-<N> but only if mbx-fcgrp-xfer-<N> is not implemented.
+
+ minItems: 1
+ maxItems: 74
+ items:
+ oneOf:
+ - const: combined
+ description: PBX/MBX Combined interrupt
+ - const: combined-ffch
+ description: PBX/MBX FIFO Combined interrupt
+ - pattern: '^ffch-low-tide-[0-9]+$'
+ description: PBX/MBX FIFO Channel <N> Low Tide interrupt
+ - pattern: '^ffch-high-tide-[0-9]+$'
+ description: PBX/MBX FIFO Channel <N> High Tide interrupt
+ - pattern: '^ffch-flush-[0-9]+$'
+ description: PBX/MBX FIFO Channel <N> Flush interrupt
+ - pattern: '^mbx-dbch-xfer-[0-9]+$'
+ description: MBX Doorbell Channel <N> Transfer interrupt
+ - pattern: '^mbx-fch-xfer-[0-9]+$'
+ description: MBX FastChannel <N> Transfer interrupt
+ - pattern: '^mbx-fchgrp-xfer-[0-9]+$'
+ description: MBX FastChannel <N> Group Transfer interrupt
+ - pattern: '^mbx-ffch-xfer-[0-9]+$'
+ description: MBX FIFO Channel <N> Transfer interrupt
+ - pattern: '^pbx-dbch-xfer-ack-[0-9]+$'
+ description: PBX Doorbell Channel <N> Transfer Ack interrupt
+ - pattern: '^pbx-ffch-xfer-ack-[0-9]+$'
+ description: PBX FIFO Channel <N> Transfer Ack interrupt
+
+ '#mbox-cells':
+ description: |
+ The first argument in the consumers 'mboxes' property represents the
+ extension type, the second is for the channel number while the third
+ depends on extension type.
+
+ Extension type for DBE is 0 and the third parameter represents the
+ doorbell flag number to use.
+ Extension type for FCE is 1, third parameter unused.
+ Extension type for FE is 2, third parameter unused.
+
+ mboxes = <&mhu 0 0 5>; // DBE, Doorbell Channel Window 0, doorbell flag 5.
+ mboxes = <&mhu 0 1 7>; // DBE, Doorbell Channel Window 1, doorbell flag 7.
+ mboxes = <&mhu 1 0 0>; // FCE, FastChannel Window 0.
+ mboxes = <&mhu 1 3 0>; // FCE, FastChannel Window 3.
+ mboxes = <&mhu 2 1 0>; // FE, FIFO Channel Window 1.
+ mboxes = <&mhu 2 7 0>; // FE, FIFO Channel Window 7.
+ const: 3
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - '#mbox-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ mailbox@2aaa0000 {
+ compatible = "arm,mhuv3";
+ #mbox-cells = <3>;
+ reg = <0 0x2aaa0000 0 0x10000>;
+ clocks = <&clock 0>;
+ interrupt-names = "combined", "pbx-dbch-xfer-ack-1",
+ "ffch-high-tide-0";
+ interrupts = <0 36 4>, <0 37 4>;
+ };
+
+ mailbox@2ab00000 {
+ compatible = "arm,mhuv3";
+ #mbox-cells = <3>;
+ reg = <0 0x2aab0000 0 0x10000>;
+ clocks = <&clock 0>;
+ interrupt-names = "combined", "mbx-dbch-xfer-1", "ffch-low-tide-0";
+ interrupts = <0 35 4>, <0 38 4>, <0 39 4>;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/2] mailbox: arm_mhuv3: Add driver
From: Cristian Marussi @ 2024-04-04 6:23 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, devicetree
Cc: sudeep.holla, cristian.marussi, jassisinghbrar, robh+dt,
krzysztof.kozlowski+dt, conor+dt
In-Reply-To: <20240404062347.3219795-1-cristian.marussi@arm.com>
Add support for ARM MHUv3 mailbox controller.
Support is limited to the MHUv3 Doorbell extension using only the PBX/MBX
combined interrupts.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v1 -> v2
- fixed checkpatch warnings about side-effects
- fixed sparse errors as reported
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202403290015.tCLXudqC-lkp@intel.com/
---
MAINTAINERS | 9 +
drivers/mailbox/Kconfig | 11 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm_mhuv3.c | 1063 +++++++++++++++++++++++++++++++++++
4 files changed, 1085 insertions(+)
create mode 100644 drivers/mailbox/arm_mhuv3.c
diff --git a/MAINTAINERS b/MAINTAINERS
index aa3b947fb080..e957b9d9e32a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12998,6 +12998,15 @@ F: Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
F: drivers/mailbox/arm_mhuv2.c
F: include/linux/mailbox/arm_mhuv2_message.h
+MAILBOX ARM MHUv3
+M: Sudeep Holla <sudeep.holla@arm.com>
+M: Cristian Marussi <cristian.marussi@arm.com>
+L: linux-kernel@vger.kernel.org
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
+F: drivers/mailbox/arm_mhuv3.c
+
MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7
M: Alejandro Colomar <alx@kernel.org>
L: linux-man@vger.kernel.org
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 42940108a187..d20cdae65cfe 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -23,6 +23,17 @@ config ARM_MHU_V2
Say Y here if you want to build the ARM MHUv2 controller driver,
which provides unidirectional mailboxes between processing elements.
+config ARM_MHU_V3
+ tristate "ARM MHUv3 Mailbox"
+ depends on ARM64 || COMPILE_TEST
+ help
+ Say Y here if you want to build the ARM MHUv3 controller driver,
+ which provides unidirectional mailboxes between processing elements.
+
+ ARM MHUv3 controllers can implement a varying number of extensions
+ that provides different means of transports: supported extensions
+ will be discovered and possibly managed at probe-time.
+
config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 18793e6caa2f..5cf2f54debaf 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -9,6 +9,8 @@ obj-$(CONFIG_ARM_MHU) += arm_mhu.o arm_mhu_db.o
obj-$(CONFIG_ARM_MHU_V2) += arm_mhuv2.o
+obj-$(CONFIG_ARM_MHU_V3) += arm_mhuv3.o
+
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX) += armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm_mhuv3.c b/drivers/mailbox/arm_mhuv3.c
new file mode 100644
index 000000000000..e4125568bec0
--- /dev/null
+++ b/drivers/mailbox/arm_mhuv3.c
@@ -0,0 +1,1063 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ARM Message Handling Unit Version 3 (MHUv3) driver.
+ *
+ * Copyright (C) 2024 ARM Ltd.
+ *
+ * Based on ARM MHUv2 driver.
+ */
+
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+/* ====== MHUv3 Registers ====== */
+
+/* Maximum number of Doorbell channel windows */
+#define MHUV3_DBCW_MAX 128
+/* Number of DBCH combined interrupt status registers */
+#define MHUV3_DBCH_CMB_INT_ST_REG_CNT 4
+#define MHUV3_INVALID_DOORBELL 0xFFFFFFFFUL
+
+/* Number of FFCH combined interrupt status registers */
+#define MHUV3_FFCH_CMB_INT_ST_REG_CNT 2
+
+#define MHUV3_STAT_BYTES (sizeof(u32))
+#define MHUV3_STAT_BITS (MHUV3_STAT_BYTES * __CHAR_BIT__)
+
+/* Not a typo ... */
+#define MHUV3_MAJOR_VERSION 2
+
+enum {
+ MHUV3_MBOX_CELL_TYPE,
+ MHUV3_MBOX_CELL_CHWN,
+ MHUV3_MBOX_CELL_PARAM,
+ MHUV3_MBOX_CELLS
+};
+
+/* CTRL_Page */
+
+struct blk_id {
+ u32 blk_id : 4;
+ u32 pad : 28;
+} __packed;
+
+struct feat_spt0 {
+ u32 dbe_spt : 4;
+ u32 fe_spt : 4;
+ u32 fce_spt : 4;
+ u32 tze_spt : 4;
+ u32 rme_spt : 4;
+ u32 rase_spt : 4;
+ u32 pad: 8;
+} __packed;
+
+struct feat_spt1 {
+ u32 auto_op_spt : 4;
+ u32 pad: 28;
+} __packed;
+
+struct dbch_cfg0 {
+ u32 num_dbch : 8;
+ u32 pad: 24;
+} __packed;
+
+struct ffch_cfg0 {
+ u32 num_ffch : 8;
+ u32 x8ba_spt : 1;
+ u32 x16ba_spt : 1;
+ u32 x32ba_spt : 1;
+ u32 x64ba_spt : 1;
+ u32 pad : 4;
+ u32 ffch_depth : 10;
+ u32 pad2 : 6;
+} __packed;
+
+struct fch_cfg0 {
+ u32 num_fch : 10;
+ /* MBX only registers */
+ u32 fcgi_spt : 1;
+ /* ------------------ */
+ u32 num_fcg : 5;
+ u32 num_fch_per_grp : 5;
+ u32 fch_ws : 8;
+ u32 pad : 3;
+} __packed;
+
+struct ctrl {
+ u32 op_req : 1;
+ u32 ch_op_mask : 1;
+ u32 pad : 30;
+} __packed;
+
+struct fch_ctrl {
+ u32 pad : 2;
+ u32 int_en : 1;
+ u32 pad2 : 29;
+} __packed;
+
+struct iidr {
+ u32 implementer : 12;
+ u32 revision : 4;
+ u32 variant : 4;
+ u32 product_id : 12;
+} __packed;
+
+struct aidr {
+ u32 arch_minor_rev : 4;
+ u32 arch_major_rev : 4;
+ u32 pad : 24;
+} __packed;
+
+struct ctrl_page {
+ struct blk_id blk_id;
+ u8 pad[0x10 - 0x4];
+ struct feat_spt0 feat_spt0;
+ struct feat_spt1 feat_spt1;
+ u8 pad1[0x20 - 0x18];
+ struct dbch_cfg0 dbch_cfg0;
+ u8 pad2[0x30 - 0x24];
+ struct ffch_cfg0 ffch_cfg0;
+ u8 pad3[0x40 - 0x34];
+ struct fch_cfg0 fch_cfg0;
+ u8 pad4[0x100 - 0x44];
+ struct ctrl ctrl;
+ /* MBX only registers */
+ u8 pad5[0x140 - 0x104];
+ struct fch_ctrl fch_ctrl;
+ u32 fcg_int_en;
+ u8 pad6[0x400 - 0x148];
+ /* ------------------ */
+ u32 dbch_int_st[MHUV3_DBCH_CMB_INT_ST_REG_CNT];
+ u32 ffch_int_st[MHUV3_FFCH_CMB_INT_ST_REG_CNT];
+ /* MBX only registers */
+ u8 pad7[0x470 - 0x418];
+ u32 fcg_int_st;
+ u8 pad8[0x480 - 0x474];
+ u32 fcg_grp_int_st[32];
+ u8 pad9[0xFC8 - 0x500];
+ /* ------------------ */
+ struct iidr iidr;
+ struct aidr aidr;
+ u32 imp_def_id[12];
+} __packed;
+
+/* DBCW_Page */
+
+struct xbcw_ctrl {
+ u32 comb_en : 1;
+ u32 pad : 31;
+} __packed;
+
+struct pdbcw_int {
+ u32 tfr_ack : 1;
+ u32 pad : 31;
+} __packed;
+
+struct pdbcw_page {
+ u32 st;
+ u8 pad[0xC - 0x4];
+ u32 set;
+ struct pdbcw_int int_st;
+ struct pdbcw_int int_clr;
+ struct pdbcw_int int_en;
+ struct xbcw_ctrl ctrl;
+} __packed;
+
+struct mdbcw_page {
+ u32 st;
+ u32 st_msk;
+ u32 clr;
+ u8 pad[0x10 - 0xC];
+ u32 msk_st;
+ u32 msk_set;
+ u32 msk_clr;
+ struct xbcw_ctrl ctrl;
+} __packed;
+
+struct dummy_page {
+ u8 pad[0x1000];
+} __packed;
+
+struct mhu3_pbx_frame_reg {
+ struct ctrl_page ctrl;
+ struct pdbcw_page dbcw[MHUV3_DBCW_MAX];
+ struct dummy_page ffcw;
+ struct dummy_page fcw;
+ u8 pad[0xF000 - 0x4000];
+ struct dummy_page impdef;
+} __packed;
+
+struct mhu3_mbx_frame_reg {
+ struct ctrl_page ctrl;
+ struct mdbcw_page dbcw[MHUV3_DBCW_MAX];
+ struct dummy_page ffcw;
+ struct dummy_page fcw;
+ u8 pad[0xF000 - 0x4000];
+ struct dummy_page impdef;
+} __packed;
+
+/* Macro for reading a bitfield within a physically mapped packed struct */
+#define readl_relaxed_bitfield(_regptr, _field) \
+ ({ \
+ u32 _rval; \
+ typeof(_regptr) _rptr = _regptr; \
+ _rval = readl_relaxed(_rptr); \
+ ((typeof(*_rptr) __force *)(&_rval))->_field; \
+ })
+
+/* Macro for writing a bitfield within a physically mapped packed struct */
+#define writel_relaxed_bitfield(_value, _regptr, _field) \
+ ({ \
+ u32 _rval; \
+ typeof(_regptr) _rptr = _regptr; \
+ _rval = readl_relaxed(_rptr); \
+ ((typeof(*_rptr) __force *)(&_rval))->_field = _value; \
+ writel_relaxed(_rval, _rptr); \
+ })
+
+/* ====== MHUv3 data structures ====== */
+
+enum mhuv3_frame {
+ PBX_FRAME,
+ MBX_FRAME
+};
+
+static char *mhuv3_str[] = {
+ "PBX",
+ "MBX"
+};
+
+enum mhuv3_extension_type {
+ FIRST_EXT = 0,
+ DBE_EXT = FIRST_EXT,
+ FCE_EXT,
+ FE_EXT,
+ MAX_EXT
+};
+
+struct mhuv3;
+
+/**
+ * struct mhuv3_protocol_ops - MHUv3 operations
+ *
+ * @rx_startup: Receiver startup callback.
+ * @rx_shutdown: Receiver shutdown callback.
+ * @read_data: Read available Sender in-band LE data (if any).
+ * @rx_complete: Acknowledge data reception to the Sender. Any out-of-band data
+ * has to have been already retrieved before calling this.
+ * @tx_startup: Sender startup callback.
+ * @tx_shutdown: Sender shutdown callback.
+ * @last_tx_done: Report back to the Sender if the last transfer has completed.
+ * @send_data: Send data to the receiver.
+ *
+ * Each supported transport protocol provides its own implementation of
+ * these operations.
+ */
+struct mhuv3_protocol_ops {
+ int (*rx_startup)(struct mhuv3 *mhu, struct mbox_chan *chan);
+ void (*rx_shutdown)(struct mhuv3 *mhu, struct mbox_chan *chan);
+ void *(*read_data)(struct mhuv3 *mhu, struct mbox_chan *chan);
+ void (*rx_complete)(struct mhuv3 *mhu, struct mbox_chan *chan);
+ void (*tx_startup)(struct mhuv3 *mhu, struct mbox_chan *chan);
+ void (*tx_shutdown)(struct mhuv3 *mhu, struct mbox_chan *chan);
+ int (*last_tx_done)(struct mhuv3 *mhu, struct mbox_chan *chan);
+ int (*send_data)(struct mhuv3 *mhu, struct mbox_chan *chan, void *arg);
+};
+
+/**
+ * struct mhuv3_mbox_chan_priv - MHUv3 channel private information
+ *
+ * @ch_idx: Channel window index associated to this mailbox channel.
+ * @doorbell: Doorbell bit number within the @ch_idx window.
+ * Only relevant to Doorbell transport.
+ * @ops: Transport protocol specific operations for this channel.
+ *
+ * Transport specific data attached to mmailbox channel priv data.
+ */
+struct mhuv3_mbox_chan_priv {
+ u32 ch_idx;
+ u32 doorbell;
+ const struct mhuv3_protocol_ops *ops;
+};
+
+/**
+ * struct mhuv3_extension - MHUv3 extension descriptor
+ *
+ * @type: Type of extension
+ * @max_chans: Max number of channels found for this extension.
+ * @base_ch_idx: First channel number assigned to this extension, picked from
+ * the set of all mailbox channels descriptors created.
+ * @mbox_of_xlate: Extension specific helper to parse DT and lookup associated
+ * channel from the related 'mboxes' property.
+ * @combined_irq_setup: Extension specific helper to setup the combined irq.
+ * @channels_init: Extension specific helper to initialize channels.
+ * @chan_from_comb_irq_get: Extension specific helper to lookup which channel
+ * triggered the combined irq.
+ * @pending_db: Array of per-channel pending doorbells.
+ * @pending_lock: Protect access to pending_db.
+ */
+struct mhuv3_extension {
+ enum mhuv3_extension_type type;
+ unsigned int max_chans;
+ unsigned int base_ch_idx;
+ struct mbox_chan *(*mbox_of_xlate)(struct mhuv3 *mhu,
+ unsigned int channel,
+ unsigned int param);
+ void (*combined_irq_setup)(struct mhuv3 *mhu);
+ int (*channels_init)(struct mhuv3 *mhu);
+ struct mbox_chan *(*chan_from_comb_irq_get)(struct mhuv3 *mhu);
+ u32 pending_db[MHUV3_DBCW_MAX];
+ /* Protect access to pending_db */
+ spinlock_t pending_lock;
+};
+
+/**
+ * struct mhuv3 - MHUv3 mailbox controller data
+ *
+ * @frame: Frame type: MBX_FRAME or PBX_FRAME.
+ * @auto_op_full: Flag to indicate if the MHU supports AutoOp full mode.
+ * @major: MHUv3 controller architectural major version.
+ * @minor: MHUv3 controller architectural minor version.
+ * @tot_chans: The total number of channnels discovered across all extensions.
+ * @cmb_irq: Combined IRQ number if any found defined.
+ * @ctrl: A reference to the MHUv3 control page for this block.
+ * @pbx: Base address of the PBX register mapping region.
+ * @mbx: Base address of the MBX register mapping region.
+ * @ext: Array holding descriptors for any found implemented extension.
+ * @mbox: Mailbox controller belonging to the MHU frame.
+ */
+struct mhuv3 {
+ enum mhuv3_frame frame;
+ bool auto_op_full;
+ unsigned int major;
+ unsigned int minor;
+ unsigned int tot_chans;
+ int cmb_irq;
+ struct ctrl_page __iomem *ctrl;
+ union {
+ struct mhu3_pbx_frame_reg __iomem *pbx;
+ struct mhu3_mbx_frame_reg __iomem *mbx;
+ };
+ struct mhuv3_extension *ext[MAX_EXT];
+ struct mbox_controller mbox;
+};
+
+#define mhu_from_mbox(_mbox) container_of(_mbox, struct mhuv3, mbox)
+
+typedef int (*mhuv3_extension_initializer)(struct mhuv3 *mhu);
+
+/* =================== Doorbell transport protocol operations =============== */
+
+static void mhuv3_doorbell_tx_startup(struct mhuv3 *mhu, struct mbox_chan *chan)
+{
+ struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+ /* Enable Transfer Acknowledgment events */
+ writel_relaxed_bitfield(0x1, &mhu->pbx->dbcw[priv->ch_idx].int_en, tfr_ack);
+}
+
+static void mhuv3_doorbell_tx_shutdown(struct mhuv3 *mhu, struct mbox_chan *chan)
+{
+ unsigned long flags;
+ struct mhuv3_extension *e = mhu->ext[DBE_EXT];
+ struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+ /* Disable Channel Transfer Ack events */
+ writel_relaxed_bitfield(0x0, &mhu->pbx->dbcw[priv->ch_idx].int_en, tfr_ack);
+
+ /* Clear Channel Transfer Ack and pending doorbells */
+ writel_relaxed_bitfield(0x1, &mhu->pbx->dbcw[priv->ch_idx].int_clr, tfr_ack);
+ spin_lock_irqsave(&e->pending_lock, flags);
+ e->pending_db[priv->ch_idx] = 0;
+ spin_unlock_irqrestore(&e->pending_lock, flags);
+}
+
+static int mhuv3_doorbell_rx_startup(struct mhuv3 *mhu, struct mbox_chan *chan)
+{
+ struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+ /* Unmask Channel Transfer events */
+ writel_relaxed(BIT(priv->doorbell), &mhu->mbx->dbcw[priv->ch_idx].msk_clr);
+
+ return 0;
+}
+
+static void mhuv3_doorbell_rx_shutdown(struct mhuv3 *mhu,
+ struct mbox_chan *chan)
+{
+ struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+ /* Mask Channel Transfer events */
+ writel_relaxed(BIT(priv->doorbell), &mhu->mbx->dbcw[priv->ch_idx].msk_set);
+}
+
+static void mhuv3_doorbell_rx_complete(struct mhuv3 *mhu, struct mbox_chan *chan)
+{
+ struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+ /* Clearing the pending transfer generates the Channel Transfer Ack */
+ writel_relaxed(BIT(priv->doorbell), &mhu->mbx->dbcw[priv->ch_idx].clr);
+}
+
+static int mhuv3_doorbell_last_tx_done(struct mhuv3 *mhu,
+ struct mbox_chan *chan)
+{
+ int done;
+ struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+ done = !(readl_relaxed(&mhu->pbx->dbcw[priv->ch_idx].st) &
+ BIT(priv->doorbell));
+ if (done) {
+ unsigned long flags;
+ struct mhuv3_extension *e = mhu->ext[DBE_EXT];
+
+ /* Take care to clear the pending doorbell also when polling */
+ spin_lock_irqsave(&e->pending_lock, flags);
+ e->pending_db[priv->ch_idx] &= ~BIT(priv->doorbell);
+ spin_unlock_irqrestore(&e->pending_lock, flags);
+ }
+
+ return done;
+}
+
+static int mhuv3_doorbell_send_data(struct mhuv3 *mhu, struct mbox_chan *chan,
+ void *arg)
+{
+ int ret = 0;
+ struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+ struct mhuv3_extension *e = mhu->ext[DBE_EXT];
+ unsigned long flags;
+
+ spin_lock_irqsave(&e->pending_lock, flags);
+ /* Only one in-flight Transfer is allowed per-doorbell */
+ if (!(e->pending_db[priv->ch_idx] & BIT(priv->doorbell))) {
+ e->pending_db[priv->ch_idx] |= BIT(priv->doorbell);
+ writel_relaxed(BIT(priv->doorbell),
+ &mhu->pbx->dbcw[priv->ch_idx].set);
+ } else {
+ ret = -EBUSY;
+ }
+ spin_unlock_irqrestore(&e->pending_lock, flags);
+
+ return ret;
+}
+
+static const struct mhuv3_protocol_ops mhuv3_doorbell_ops = {
+ .tx_startup = mhuv3_doorbell_tx_startup,
+ .tx_shutdown = mhuv3_doorbell_tx_shutdown,
+ .rx_startup = mhuv3_doorbell_rx_startup,
+ .rx_shutdown = mhuv3_doorbell_rx_shutdown,
+ .rx_complete = mhuv3_doorbell_rx_complete,
+ .last_tx_done = mhuv3_doorbell_last_tx_done,
+ .send_data = mhuv3_doorbell_send_data,
+};
+
+/* Sender and receiver mailbox ops */
+static bool mhuv3_sender_last_tx_done(struct mbox_chan *chan)
+{
+ struct mhuv3 *mhu = mhu_from_mbox(chan->mbox);
+ struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+ return priv->ops->last_tx_done(mhu, chan);
+}
+
+static int mhuv3_sender_send_data(struct mbox_chan *chan, void *data)
+{
+ struct mhuv3 *mhu = mhu_from_mbox(chan->mbox);
+ struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+ if (!priv->ops->last_tx_done(mhu, chan))
+ return -EBUSY;
+
+ return priv->ops->send_data(mhu, chan, data);
+}
+
+static int mhuv3_sender_startup(struct mbox_chan *chan)
+{
+ struct mhuv3 *mhu = mhu_from_mbox(chan->mbox);
+ struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+ if (priv->ops->tx_startup)
+ priv->ops->tx_startup(mhu, chan);
+
+ return 0;
+}
+
+static void mhuv3_sender_shutdown(struct mbox_chan *chan)
+{
+ struct mhuv3 *mhu = mhu_from_mbox(chan->mbox);
+ struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+ if (priv->ops->tx_shutdown)
+ priv->ops->tx_shutdown(mhu, chan);
+}
+
+static const struct mbox_chan_ops mhuv3_sender_ops = {
+ .send_data = mhuv3_sender_send_data,
+ .startup = mhuv3_sender_startup,
+ .shutdown = mhuv3_sender_shutdown,
+ .last_tx_done = mhuv3_sender_last_tx_done,
+};
+
+static int mhuv3_receiver_startup(struct mbox_chan *chan)
+{
+ struct mhuv3 *mhu = mhu_from_mbox(chan->mbox);
+ struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+ return priv->ops->rx_startup(mhu, chan);
+}
+
+static void mhuv3_receiver_shutdown(struct mbox_chan *chan)
+{
+ struct mhuv3 *mhu = mhu_from_mbox(chan->mbox);
+ struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+ priv->ops->rx_shutdown(mhu, chan);
+}
+
+static int mhuv3_receiver_send_data(struct mbox_chan *chan, void *data)
+{
+ dev_err(chan->mbox->dev,
+ "Trying to transmit on a MBX MHUv3 frame\n");
+ return -EIO;
+}
+
+static bool mhuv3_receiver_last_tx_done(struct mbox_chan *chan)
+{
+ dev_err(chan->mbox->dev, "Trying to Tx poll on a MBX MHUv3 frame\n");
+ return true;
+}
+
+static const struct mbox_chan_ops mhuv3_receiver_ops = {
+ .send_data = mhuv3_receiver_send_data,
+ .startup = mhuv3_receiver_startup,
+ .shutdown = mhuv3_receiver_shutdown,
+ .last_tx_done = mhuv3_receiver_last_tx_done,
+};
+
+static struct mbox_chan *mhuv3_dbe_mbox_of_xlate(struct mhuv3 *mhu,
+ unsigned int channel,
+ unsigned int doorbell)
+{
+ struct mbox_controller *mbox = &mhu->mbox;
+ struct mbox_chan *chans = mbox->chans;
+ struct mhuv3_extension *e = mhu->ext[DBE_EXT];
+
+ if (channel >= e->max_chans || doorbell >= MHUV3_STAT_BITS) {
+ dev_err(mbox->dev, "Couldn't xlate to a valid channel (%d: %d)\n",
+ channel, doorbell);
+ return ERR_PTR(-ENODEV);
+ }
+
+ return &chans[e->base_ch_idx + channel * MHUV3_STAT_BITS + doorbell];
+}
+
+static void mhuv3_dbe_combined_irq_setup(struct mhuv3 *mhu)
+{
+ int i;
+ struct mhuv3_extension *e = mhu->ext[DBE_EXT];
+
+ if (mhu->frame == PBX_FRAME) {
+ struct pdbcw_page __iomem *dbcw = mhu->pbx->dbcw;
+
+ for (i = 0; i < e->max_chans; i++) {
+ writel_relaxed_bitfield(0x1, &dbcw[i].int_clr, tfr_ack);
+ writel_relaxed_bitfield(0x0, &dbcw[i].int_en, tfr_ack);
+ writel_relaxed_bitfield(0x1, &dbcw[i].ctrl, comb_en);
+ }
+ } else {
+ struct mdbcw_page __iomem *dbcw = mhu->mbx->dbcw;
+
+ for (i = 0; i < e->max_chans; i++) {
+ writel_relaxed(0xFFFFFFFF, &dbcw[i].clr);
+ writel_relaxed(0xFFFFFFFF, &dbcw[i].msk_set);
+ writel_relaxed_bitfield(0x1, &dbcw[i].ctrl, comb_en);
+ }
+ }
+}
+
+static int mhuv3_dbe_channels_init(struct mhuv3 *mhu)
+{
+ int i;
+ struct mhuv3_extension *e = mhu->ext[DBE_EXT];
+ struct mbox_controller *mbox = &mhu->mbox;
+ struct mbox_chan *chans;
+
+ chans = mbox->chans + mbox->num_chans;
+ e->base_ch_idx = mbox->num_chans;
+ for (i = 0; i < e->max_chans; i++) {
+ int k;
+ struct mhuv3_mbox_chan_priv *priv;
+
+ for (k = 0; k < MHUV3_STAT_BITS; k++) {
+ priv = devm_kmalloc(mbox->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->ch_idx = i;
+ priv->ops = &mhuv3_doorbell_ops;
+ priv->doorbell = k;
+ chans++->con_priv = priv;
+ mbox->num_chans++;
+ }
+ }
+
+ spin_lock_init(&e->pending_lock);
+
+ return 0;
+}
+
+static struct mbox_chan *mhuv3_dbe_chan_from_comb_irq_get(struct mhuv3 *mhu)
+{
+ int i;
+ struct mhuv3_extension *e = mhu->ext[DBE_EXT];
+ struct device *dev = mhu->mbox.dev;
+
+ for (i = 0; i < MHUV3_DBCH_CMB_INT_ST_REG_CNT; i++) {
+ unsigned int channel, db = MHUV3_INVALID_DOORBELL;
+ u32 cmb_st, st;
+
+ cmb_st = readl_relaxed(&mhu->ctrl->dbch_int_st[i]);
+ if (!cmb_st)
+ continue;
+
+ channel = i * MHUV3_STAT_BITS + __builtin_ctz(cmb_st);
+ if (channel >= e->max_chans) {
+ dev_err(dev, "Invalid %s channel:%d\n",
+ mhuv3_str[mhu->frame], channel);
+ break;
+ }
+
+ if (mhu->frame == PBX_FRAME) {
+ unsigned long flags;
+ u32 active_dbs, fired_dbs;
+
+ st = readl_relaxed_bitfield(&mhu->pbx->dbcw[channel].int_st,
+ tfr_ack);
+ if (!st) {
+ dev_warn(dev, "Spurios IRQ on %s channel:%d\n",
+ mhuv3_str[mhu->frame], channel);
+ continue;
+ }
+
+ active_dbs = readl_relaxed(&mhu->pbx->dbcw[channel].st);
+ spin_lock_irqsave(&e->pending_lock, flags);
+ fired_dbs = e->pending_db[channel] & ~active_dbs;
+ if (fired_dbs) {
+ db = __builtin_ctz(fired_dbs);
+ e->pending_db[channel] &= ~BIT(db);
+ fired_dbs &= ~BIT(db);
+ }
+ spin_unlock_irqrestore(&e->pending_lock, flags);
+
+ /* Clear TFR Ack if no more doorbells pending */
+ if (!fired_dbs)
+ writel_relaxed_bitfield(0x1,
+ &mhu->pbx->dbcw[channel].int_clr,
+ tfr_ack);
+ } else {
+ st = readl_relaxed(&mhu->mbx->dbcw[channel].st_msk);
+ if (!st) {
+ dev_warn(dev, "Spurios IRQ on %s channel:%d\n",
+ mhuv3_str[mhu->frame], channel);
+ continue;
+ }
+ db = __builtin_ctz(st);
+ }
+
+ if (db != MHUV3_INVALID_DOORBELL) {
+ dev_dbg(dev, "Found %s ch[%d]/db[%d]\n",
+ mhuv3_str[mhu->frame], channel, db);
+
+ return &mhu->mbox.chans[channel * MHUV3_STAT_BITS + db];
+ }
+ }
+
+ return ERR_PTR(-EIO);
+}
+
+static int mhuv3_dbe_init(struct mhuv3 *mhu)
+{
+ struct mhuv3_extension *e;
+ struct device *dev = mhu->mbox.dev;
+
+ if (!readl_relaxed_bitfield(&mhu->ctrl->feat_spt0, dbe_spt))
+ return 0;
+
+ dev_dbg(dev, "%s: Initializing DBE Extension.\n", mhuv3_str[mhu->frame]);
+
+ e = devm_kzalloc(dev, sizeof(*e), GFP_KERNEL);
+ if (!e)
+ return -ENOMEM;
+
+ e->type = DBE_EXT;
+ /* Note that, by the spec, the number of channels is (num_dbch + 1) */
+ e->max_chans =
+ readl_relaxed_bitfield(&mhu->ctrl->dbch_cfg0, num_dbch) + 1;
+ e->mbox_of_xlate = mhuv3_dbe_mbox_of_xlate;
+ e->combined_irq_setup = mhuv3_dbe_combined_irq_setup;
+ e->channels_init = mhuv3_dbe_channels_init;
+ e->chan_from_comb_irq_get = mhuv3_dbe_chan_from_comb_irq_get;
+
+ mhu->tot_chans += e->max_chans * MHUV3_STAT_BITS;
+ mhu->ext[DBE_EXT] = e;
+
+ dev_info(dev, "%s: found %d DBE channels.\n",
+ mhuv3_str[mhu->frame], e->max_chans);
+
+ return 0;
+}
+
+static int mhuv3_fce_init(struct mhuv3 *mhu)
+{
+ struct device *dev = mhu->mbox.dev;
+
+ if (!readl_relaxed_bitfield(&mhu->ctrl->feat_spt0, fce_spt))
+ return 0;
+
+ dev_dbg(dev, "%s: FCE Extension not supported by driver.\n",
+ mhuv3_str[mhu->frame]);
+
+ return 0;
+}
+
+static int mhuv3_fe_init(struct mhuv3 *mhu)
+{
+ struct device *dev = mhu->mbox.dev;
+
+ if (!readl_relaxed_bitfield(&mhu->ctrl->feat_spt0, fe_spt))
+ return 0;
+
+ dev_dbg(dev, "%s: FE Extension not supported by driver.\n",
+ mhuv3_str[mhu->frame]);
+
+ return 0;
+}
+
+static mhuv3_extension_initializer mhuv3_extension_init[MAX_EXT] = {
+ mhuv3_dbe_init,
+ mhuv3_fce_init,
+ mhuv3_fe_init,
+};
+
+static int mhuv3_initialize_channels(struct device *dev, struct mhuv3 *mhu)
+{
+ int i, ret = 0;
+ struct mbox_controller *mbox = &mhu->mbox;
+
+ mbox->chans = devm_kcalloc(dev, mhu->tot_chans,
+ sizeof(*mbox->chans), GFP_KERNEL);
+ if (!mbox->chans)
+ return -ENOMEM;
+
+ for (i = FIRST_EXT; i < MAX_EXT && !ret; i++)
+ if (mhu->ext[i])
+ ret = mhu->ext[i]->channels_init(mhu);
+
+ return ret;
+}
+
+static struct mbox_chan *mhuv3_mbox_of_xlate(struct mbox_controller *mbox,
+ const struct of_phandle_args *pa)
+{
+ unsigned int type, channel, param;
+ struct mhuv3 *mhu = mhu_from_mbox(mbox);
+
+ if (pa->args_count != MHUV3_MBOX_CELLS)
+ return ERR_PTR(-EINVAL);
+
+ type = pa->args[MHUV3_MBOX_CELL_TYPE];
+ if (type >= MAX_EXT)
+ return ERR_PTR(-EINVAL);
+
+ channel = pa->args[MHUV3_MBOX_CELL_CHWN];
+ param = pa->args[MHUV3_MBOX_CELL_PARAM];
+
+ return mhu->ext[type]->mbox_of_xlate(mhu, channel, param);
+}
+
+static int mhuv3_frame_init(struct mhuv3 *mhu, void __iomem *regs)
+{
+ int i, ret = 0;
+ struct device *dev = mhu->mbox.dev;
+
+ mhu->ctrl = regs;
+ mhu->frame = readl_relaxed_bitfield(&mhu->ctrl->blk_id, blk_id);
+ if (mhu->frame > MBX_FRAME) {
+ dev_err(dev, "Invalid Frame type- %d\n", mhu->frame);
+ return -EINVAL;
+ }
+
+ mhu->major = readl_relaxed_bitfield(&mhu->ctrl->aidr, arch_major_rev);
+ mhu->minor = readl_relaxed_bitfield(&mhu->ctrl->aidr, arch_minor_rev);
+ if (mhu->major != MHUV3_MAJOR_VERSION) {
+ dev_warn(dev, "Unsupported MHU %s block - major:%d minor:%d\n",
+ mhuv3_str[mhu->frame], mhu->major, mhu->minor);
+ return -EINVAL;
+ }
+ mhu->auto_op_full = !!readl_relaxed_bitfield(&mhu->ctrl->feat_spt1,
+ auto_op_spt);
+ /* Request the PBX/MBX to remain operational */
+ if (mhu->auto_op_full)
+ writel_relaxed_bitfield(0x1, &mhu->ctrl->ctrl, op_req);
+
+ dev_dbg(dev, "Found MHU %s block - major:%d minor:%d\n",
+ mhuv3_str[mhu->frame], mhu->major, mhu->minor);
+
+ if (mhu->frame == PBX_FRAME)
+ mhu->pbx = regs;
+ else
+ mhu->mbx = regs;
+
+ for (i = FIRST_EXT; i < MAX_EXT && !ret; i++)
+ ret = mhuv3_extension_init[i](mhu);
+
+ return ret;
+}
+
+static irqreturn_t mhuv3_pbx_comb_interrupt(int irq, void *arg)
+{
+ int ret = IRQ_NONE;
+ unsigned int i, found = 0;
+ struct mhuv3 *mhu = arg;
+ struct device *dev = mhu->mbox.dev;
+ struct mbox_chan *chan;
+
+ for (i = FIRST_EXT; i < MAX_EXT; i++) {
+ /* FCE does not participate to the PBX combined */
+ if (i == FCE_EXT || !mhu->ext[i])
+ continue;
+
+ chan = mhu->ext[i]->chan_from_comb_irq_get(mhu);
+ if (!IS_ERR(chan)) {
+ struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+ found++;
+ if (chan->cl) {
+ mbox_chan_txdone(chan, 0);
+ ret = IRQ_HANDLED;
+ } else {
+ dev_warn(dev,
+ "TX Ack on UNBOUND channel (%u)\n",
+ priv->ch_idx);
+ }
+ }
+ }
+
+ if (!found)
+ dev_warn_once(dev, "Failed to find channel for the TX interrupt\n");
+
+ return ret;
+}
+
+static irqreturn_t mhuv3_mbx_comb_interrupt(int irq, void *arg)
+{
+ int ret = IRQ_NONE;
+ unsigned int i, found = 0;
+ struct mhuv3 *mhu = arg;
+ struct device *dev = mhu->mbox.dev;
+ struct mbox_chan *chan;
+
+ for (i = FIRST_EXT; i < MAX_EXT; i++) {
+ if (!mhu->ext[i])
+ continue;
+
+ /* Process any extension which could be source of the IRQ */
+ chan = mhu->ext[i]->chan_from_comb_irq_get(mhu);
+ if (!IS_ERR(chan)) {
+ void *data = NULL;
+ struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+ found++;
+ /* Read and acknowledge optional in-band LE data first. */
+ if (priv->ops->read_data)
+ data = priv->ops->read_data(mhu, chan);
+
+ if (chan->cl && !IS_ERR(data)) {
+ mbox_chan_received_data(chan, data);
+ ret = IRQ_HANDLED;
+ } else if (!chan->cl) {
+ dev_warn(dev,
+ "RX Data on UNBOUND channel (%u)\n",
+ priv->ch_idx);
+ } else {
+ dev_err(dev, "Failed to read data: %lu\n",
+ PTR_ERR(data));
+ }
+
+ if (!IS_ERR(data))
+ kfree(data);
+
+ /*
+ * Acknowledge transfer after any possible optional
+ * out-of-band data has also been retrieved via
+ * mbox_chan_received_data().
+ */
+ if (priv->ops->rx_complete)
+ priv->ops->rx_complete(mhu, chan);
+ }
+ }
+
+ if (!found)
+ dev_warn_once(dev, "Failed to find channel for the RX interrupt\n");
+
+ return ret;
+}
+
+static int mhuv3_setup_pbx(struct mhuv3 *mhu)
+{
+ struct device *dev = mhu->mbox.dev;
+
+ mhu->mbox.ops = &mhuv3_sender_ops;
+
+ if (mhu->cmb_irq > 0) {
+ int ret;
+
+ ret = devm_request_threaded_irq(dev, mhu->cmb_irq, NULL,
+ mhuv3_pbx_comb_interrupt,
+ IRQF_ONESHOT, "mhuv3-pbx", mhu);
+ if (!ret) {
+ int i;
+
+ mhu->mbox.txdone_irq = true;
+ mhu->mbox.txdone_poll = false;
+
+ for (i = FIRST_EXT; i < MAX_EXT; i++)
+ if (mhu->ext[i])
+ mhu->ext[i]->combined_irq_setup(mhu);
+
+ dev_dbg(dev, "MHUv3 PBX IRQs initialized.\n");
+
+ return 0;
+ }
+
+ dev_err(dev, "Failed to request PBX IRQ - ret:%d", ret);
+ }
+
+ dev_info(dev, "Using PBX in Tx polling mode.\n");
+ mhu->mbox.txdone_irq = false;
+ mhu->mbox.txdone_poll = true;
+ mhu->mbox.txpoll_period = 1;
+
+ return 0;
+}
+
+static int mhuv3_setup_mbx(struct mhuv3 *mhu)
+{
+ int ret, i;
+ struct device *dev = mhu->mbox.dev;
+
+ mhu->mbox.ops = &mhuv3_receiver_ops;
+
+ if (mhu->cmb_irq <= 0) {
+ dev_err(dev, "Missing MBX combined IRQ !\n");
+ return -EINVAL;
+ }
+
+ ret = devm_request_threaded_irq(dev, mhu->cmb_irq, NULL,
+ mhuv3_mbx_comb_interrupt, IRQF_ONESHOT,
+ "mhuv3-mbx", mhu);
+ if (ret) {
+ dev_err(dev, "Failed to request MBX IRQ - ret:%d\n", ret);
+ return ret;
+ }
+
+ for (i = FIRST_EXT; i < MAX_EXT; i++)
+ if (mhu->ext[i])
+ mhu->ext[i]->combined_irq_setup(mhu);
+
+ dev_dbg(dev, "MHUv3 MBX IRQs initialized.\n");
+
+ return ret;
+}
+
+static int mhuv3_irqs_init(struct mhuv3 *mhu, struct platform_device *pdev)
+{
+ int ret;
+
+ dev_dbg(mhu->mbox.dev, "Initializing %s block.\n", mhuv3_str[mhu->frame]);
+
+ if (mhu->frame == PBX_FRAME) {
+ mhu->cmb_irq = platform_get_irq_byname_optional(pdev, "combined");
+ ret = mhuv3_setup_pbx(mhu);
+ } else {
+ mhu->cmb_irq = platform_get_irq_byname(pdev, "combined");
+ ret = mhuv3_setup_mbx(mhu);
+ }
+
+ return ret;
+}
+
+static int mhuv3_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct mhuv3 *mhu;
+ void __iomem *regs;
+ struct device *dev = &pdev->dev;
+
+ mhu = devm_kzalloc(dev, sizeof(*mhu), GFP_KERNEL);
+ if (!mhu)
+ return -ENOMEM;
+
+ regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
+
+ mhu->mbox.dev = dev;
+ ret = mhuv3_frame_init(mhu, regs);
+ if (ret)
+ return ret;
+
+ ret = mhuv3_irqs_init(mhu, pdev);
+ if (ret)
+ return ret;
+
+ mhu->mbox.of_xlate = mhuv3_mbox_of_xlate;
+ ret = mhuv3_initialize_channels(dev, mhu);
+ if (ret)
+ return ret;
+
+ ret = devm_mbox_controller_register(dev, &mhu->mbox);
+ if (ret)
+ dev_err(dev, "failed to register ARM MHUv3 driver %d\n", ret);
+
+ platform_set_drvdata(pdev, mhu);
+
+ return ret;
+}
+
+static int mhuv3_remove(struct platform_device *pdev)
+{
+ struct mhuv3 *mhu = platform_get_drvdata(pdev);
+
+ if (mhu->auto_op_full)
+ writel_relaxed_bitfield(0x0, &mhu->ctrl->ctrl, op_req);
+
+ return 0;
+}
+
+static const struct of_device_id mhuv3_of_match[] = {
+ { .compatible = "arm,mhuv3", .data = NULL },
+ {}
+};
+MODULE_DEVICE_TABLE(of, mhuv3_of_match);
+
+static struct platform_driver mhuv3_driver = {
+ .driver = {
+ .name = "arm-mhuv3-mailbox",
+ .of_match_table = mhuv3_of_match,
+ },
+ .probe = mhuv3_probe,
+ .remove = mhuv3_remove,
+};
+module_platform_driver(mhuv3_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("ARM MHUv3 Driver");
+MODULE_AUTHOR("Cristian Marussi <cristian.marussi@arm.com>");
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 1/1] dt-bindings: media: imx-jpeg: add clocks,clock-names,slot to fix warning
From: Krzysztof Kozlowski @ 2024-04-04 6:26 UTC (permalink / raw)
To: Frank Li, Mirela Rabulea, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER,
open list:NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <20240404035205.59492-1-Frank.Li@nxp.com>
On 04/04/2024 05:52, Frank Li wrote:
> Fix below DTB_CHECK warning.
>
> make CHECK_DTBS=y freescale/imx8qxp-mek.dtb
> DTC_CHK arch/arm64/boot/dts/freescale/imx8qxp-mek.dtb
> arch/arm64/boot/dts/freescale/imx8qxp-mek.dtb: jpegdec@58400000: 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks', 'slot' do not match any of the regexes: 'pinctrl-[0-9]+'
> from schema $id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
No, that's not the reason to add properties. Add them if they are valid.
>
> + slot:
> + description: Certain slot number is used.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 3
NAK. Every time.
Fix your DTS instead.
Please read the feedback instead of pushing this stuff for the third time!
https://lore.kernel.org/all/bbb1875b-7980-46aa-80b4-dbaf2a2d5755@linaro.org/
Can NXP take responsibility for this piece of code?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: interrupt-controller: renesas,rzg2l-irqc: Document RZ/Five SoC
From: Krzysztof Kozlowski @ 2024-04-04 6:28 UTC (permalink / raw)
To: Prabhakar, Geert Uytterhoeven, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Paul Walmsley,
Palmer Dabbelt, Albert Ou
Cc: linux-kernel, devicetree, linux-renesas-soc, linux-riscv,
Lad Prabhakar
In-Reply-To: <20240403203503.634465-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
On 03/04/2024 22:34, Prabhakar wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Document RZ/Five (R9A07G043F) IRQC bindings. The IRQC block on the RZ/Five
> SoC is almost identical to the one found on the RZ/G2L SoC, with the only
> difference being that it has additional mask control registers for
> NMI/IRQ/TINT.
>
> Hence new compatible string "renesas,r9a07g043f-irqc" is added for RZ/Five
> SoC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> v1->v2
> - Dropped the checks for interrupts as its already handled
> - Added SoC specific compat string
> ---
> .../renesas,rzg2l-irqc.yaml | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml
> index daef4ee06f4e..2a871cbf6f87 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml
> @@ -21,13 +21,16 @@ description: |
>
> properties:
> compatible:
> - items:
> - - enum:
> - - renesas,r9a07g043u-irqc # RZ/G2UL
> - - renesas,r9a07g044-irqc # RZ/G2{L,LC}
> - - renesas,r9a07g054-irqc # RZ/V2L
> - - renesas,r9a08g045-irqc # RZ/G3S
> - - const: renesas,rzg2l-irqc
> + oneOf:
> + - items:
> + - enum:
> + - renesas,r9a07g043u-irqc # RZ/G2UL
> + - renesas,r9a07g044-irqc # RZ/G2{L,LC}
> + - renesas,r9a07g054-irqc # RZ/V2L
> + - renesas,r9a08g045-irqc # RZ/G3S
> + - const: renesas,rzg2l-irqc
> + - items:
This is just const, no need for items.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: mailbox: arm,mhuv3: Add bindings
From: Krzysztof Kozlowski @ 2024-04-04 6:30 UTC (permalink / raw)
To: Cristian Marussi, linux-kernel, linux-arm-kernel, devicetree
Cc: sudeep.holla, jassisinghbrar, robh+dt, krzysztof.kozlowski+dt,
conor+dt
In-Reply-To: <20240404062347.3219795-2-cristian.marussi@arm.com>
On 04/04/2024 08:23, Cristian Marussi wrote:
> Add bindings for the ARM MHUv3 Mailbox controller.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> v2 -> v3
> - fixed spurious tabs in dt_binding_check
Did you test this patch before sending?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: usb: Add the binding example for the Genesys Logic GL3523 hub
From: Anand Moon @ 2024-04-04 6:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Greg Kroah-Hartman, Krzysztof Kozlowski,
Conor Dooley, Icenowy Zheng, Neil Armstrong, linux-amlogic,
Conor Dooley, linux-usb, devicetree, linux-kernel
In-Reply-To: <194aa24c-2763-47e2-8ccc-1637d299c1ba@linaro.org>
Hi,
On Thu, 4 Apr 2024 at 11:42, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 04/04/2024 06:27, Anand Moon wrote:
> > Hi Krzysztof,
> >
> > On Tue, 12 Dec 2023 at 18:47, Anand Moon <linux.amoon@gmail.com> wrote:
> >>
> >> Hi Krzysztof,
> >>
> >> On Tue, 12 Dec 2023 at 18:39, Krzysztof Kozlowski
> >> <krzysztof.kozlowski@linaro.org> wrote:
> >>>
> >>> On 12/12/2023 13:51, Anand Moon wrote:
> >>>> Hi Krzysztof,
> >>>>
> >>>> On Tue, 12 Dec 2023 at 17:22, Krzysztof Kozlowski
> >>>> <krzysztof.kozlowski@linaro.org> wrote:
> >>>>>
> >>>>> On 12/12/2023 12:37, Anand Moon wrote:
> >>>>>>
> >>>>>> Here is the list of warnings I observed with this patch
> >>>>>>
> >>>>>> DTC_CHK Documentation/devicetree/bindings/usb/nvidia,tegra186-xusb.example.dtb
> >>>>>> /home/amoon/mainline/linux-amlogic-6.y-devel/Documentation/devicetree/bindings/usb/usb-device.example.dtb:
> >>>>>> hub@1: 'vdd-supply' is a required property
> >>>>>
> >>>>> You always require the property, but it is not valid for some devices.
> >>>>> Just require it only where it is applicable (in if:then: clause).
> >>>>>
> >>>> I had already done this check many times before.
> >>>
> >>> I don't ask you to check. I ask you to change the code.
> >>>
> >> I have tried this and it's not working for me.
> >>
> >>>> my v6 original patch was doing the same and it passed all the tests
> >>>> but since I updated the required field it not parsing correctly.
> >>>
> >>> Your original v6 patch was different. I don't understand what you are
> >>> trying to achieve. Or rather: how is it different, that my simple advice
> >>> above does not work for you (as in the past you reply with some really
> >>> unrelated sentence).
> >>>
> >> Ok, It's my poor English grammar, thanks for your review comments.
> >>
> >>> Best regards,
> >>> Krzysztof
> >>>
> >
> > Any reason this device tree binding got removed,I cannot find this file
> > Can not find the commit which removed this file.
>
> Use git log.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 5/5] arm64: dts: qcom: x1e80100: Enable cpufreq
From: Sibi Sankar @ 2024-04-04 6:32 UTC (permalink / raw)
To: Ulf Hansson, Sudeep Holla
Cc: cristian.marussi, andersson, konrad.dybcio, jassisinghbrar,
robh+dt, krzysztof.kozlowski+dt, linux-kernel, linux-arm-msm,
devicetree, quic_rgottimu, quic_kshivnan, conor+dt, quic_gkohli,
quic_nkela, quic_psodagud
In-Reply-To: <CAPDyKFous+aoopf+=ZRugR78jyekobODqn7tqWRCyirPD+=eYw@mail.gmail.com>
On 4/3/24 16:50, Ulf Hansson wrote:
> On Tue, 2 Apr 2024 at 13:10, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>> On Thu, Mar 28, 2024 at 03:20:44PM +0530, Sibi Sankar wrote:
>>> Enable cpufreq on X1E80100 SoCs through the SCMI perf protocol node.
>>>
>>> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/x1e80100.dtsi | 27 ++++++++++++++++++++++++++
>>> 1 file changed, 27 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
>>> index 4e0ec859ed61..d1d232cd1f25 100644
>>> --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
>>> @@ -68,6 +68,7 @@ CPU0: cpu@0 {
>>> compatible = "qcom,oryon";
>>> reg = <0x0 0x0>;
>>> enable-method = "psci";
>>> + clocks = <&scmi_dvfs 0>;
>>> next-level-cache = <&L2_0>;
>>> power-domains = <&CPU_PD0>;
>>> power-domain-names = "psci";
>>
>>
>> Any reason why you wouldn't want to use the new genpd based perf controls.
>> IIRC it was added based on mainly Qcom platform requirements.
>>
>> - clocks = <&scmi_dvfs 0>;
>> next-level-cache = <&L2_0>;
>> - power-domains = <&CPU_PD0>;
>> - power-domain-names = "psci";
>> + power-domains = <&CPU_PD0>, <&scmi_dvfs 0>;
>> + power-domain-names = "psci", "perf";
>>
>>
>> And the associated changes in the scmi dvfs node for cells property.
>>
>> This change is OK but just wanted to check the reasoning for the choice.
>
> To me, it seems reasonable to move to the new binding with
> #power-domain-cells for protocol@13. This becomes more future proof,
> as it can then easily be extended to be used beyond CPUs.
>
> That said, I just submitted a patch [1] to update the examples in the
> scmi DT doc to use #power-domain-cells in favor of #clock-cells. I
> don't know if there is a better way to promote the new bindings?
> Perhaps moving Juno to use this too?
>
> Kind regards
> Uffe
Sudeep/Ulfe,
Thanks I'll move to the new recommendation.
-Sibi
>
> [1]
> https://lore.kernel.org/all/20240403111106.1110940-1-ulf.hansson@linaro.org/
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: clock: airoha: add EN7581 binding
From: Krzysztof Kozlowski @ 2024-04-04 6:34 UTC (permalink / raw)
To: Lorenzo Bianconi, linux-clk
Cc: mturquette, sboyd, linux-arm-kernel, robh+dt,
krzysztof.kozlowski+dt, conor+dt, nbd, john, devicetree, dd,
catalin.marinas, will, upstream, lorenzo.bianconi83,
angelogioacchino.delregno
In-Reply-To: <1988a4460ed327bea7841f6a0f3a756dd7cec4bb.1712160869.git.lorenzo@kernel.org>
On 03/04/2024 18:20, Lorenzo Bianconi wrote:
> Introduce Airoha EN7581 entry in Airoha EN7523 clock binding
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> .../bindings/clock/airoha,en7523-scu.yaml | 26 +++++++++++++++++--
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
> index 79b0752faa91..cf893d4c74cd 100644
> --- a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
> +++ b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
> @@ -29,10 +29,13 @@ description: |
> properties:
> compatible:
> items:
> - - const: airoha,en7523-scu
> + - enum:
> + - airoha,en7523-scu
> + - airoha,en7581-scu
>
> reg:
> - maxItems: 2
> + minItems: 2
> + maxItems: 3
>
> "#clock-cells":
> description:
> @@ -45,6 +48,25 @@ required:
> - reg
> - '#clock-cells'
>
> +allOf:
> + - if:
> + properties:
> + compatible:
> + const: airoha,en7523-scu
> + then:
> + properties:
> + reg:
> + maxItems: 2
> +
> + - if:
> + properties:
> + compatible:
> + const: airoha,en7581-scu
> + then:
> + properties:
> + reg:
> + maxItems: 3
Original code had here issue - lack of description of the items. You are
now growing it. Please instead list the items (items: - description: foo
bar .....).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: usb: Add the binding example for the Genesys Logic GL3523 hub
From: Anand Moon @ 2024-04-04 6:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Greg Kroah-Hartman, Krzysztof Kozlowski,
Conor Dooley, Icenowy Zheng, Neil Armstrong, linux-amlogic,
Conor Dooley, linux-usb, devicetree, linux-kernel
In-Reply-To: <CANAwSgR4zwoHUZRFmbjV9Z5kX9P_bU=HjkUokZm3eNStPXwwOw@mail.gmail.com>
Hi Krzysztof,
On Thu, 4 Apr 2024 at 12:02, Anand Moon <linux.amoon@gmail.com> wrote:
>
> Hi,
>
> On Thu, 4 Apr 2024 at 11:42, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
> >
> > On 04/04/2024 06:27, Anand Moon wrote:
> > > Hi Krzysztof,
> > >
> > > On Tue, 12 Dec 2023 at 18:47, Anand Moon <linux.amoon@gmail.com> wrote:
> > >>
> > >> Hi Krzysztof,
> > >>
> > >> On Tue, 12 Dec 2023 at 18:39, Krzysztof Kozlowski
> > >> <krzysztof.kozlowski@linaro.org> wrote:
> > >>>
> > >>> On 12/12/2023 13:51, Anand Moon wrote:
> > >>>> Hi Krzysztof,
> > >>>>
> > >>>> On Tue, 12 Dec 2023 at 17:22, Krzysztof Kozlowski
> > >>>> <krzysztof.kozlowski@linaro.org> wrote:
> > >>>>>
> > >>>>> On 12/12/2023 12:37, Anand Moon wrote:
> > >>>>>>
> > >>>>>> Here is the list of warnings I observed with this patch
> > >>>>>>
> > >>>>>> DTC_CHK Documentation/devicetree/bindings/usb/nvidia,tegra186-xusb.example.dtb
> > >>>>>> /home/amoon/mainline/linux-amlogic-6.y-devel/Documentation/devicetree/bindings/usb/usb-device.example.dtb:
> > >>>>>> hub@1: 'vdd-supply' is a required property
> > >>>>>
> > >>>>> You always require the property, but it is not valid for some devices.
> > >>>>> Just require it only where it is applicable (in if:then: clause).
> > >>>>>
> > >>>> I had already done this check many times before.
> > >>>
> > >>> I don't ask you to check. I ask you to change the code.
> > >>>
> > >> I have tried this and it's not working for me.
> > >>
> > >>>> my v6 original patch was doing the same and it passed all the tests
> > >>>> but since I updated the required field it not parsing correctly.
> > >>>
> > >>> Your original v6 patch was different. I don't understand what you are
> > >>> trying to achieve. Or rather: how is it different, that my simple advice
> > >>> above does not work for you (as in the past you reply with some really
> > >>> unrelated sentence).
> > >>>
> > >> Ok, It's my poor English grammar, thanks for your review comments.
> > >>
> > >>> Best regards,
> > >>> Krzysztof
> > >>>
> > >
> > > Any reason this device tree binding got removed,I cannot find this file
> > > Can not find the commit which removed this file.
> >
> > Use git log.
> >
I got confused with the file name and my local changes.
> > Best regards,
> > Krzysztof
> >
Thanks
-Anand
^ permalink raw reply
* Re: [PATCH 4/4] clk: en7523: add EN7581 support
From: Krzysztof Kozlowski @ 2024-04-04 6:36 UTC (permalink / raw)
To: Lorenzo Bianconi, linux-clk
Cc: mturquette, sboyd, linux-arm-kernel, robh+dt,
krzysztof.kozlowski+dt, conor+dt, nbd, john, devicetree, dd,
catalin.marinas, will, upstream, lorenzo.bianconi83,
angelogioacchino.delregno
In-Reply-To: <3aaf638b846ecfdbfc1c903206b7d519d56c9130.1712160869.git.lorenzo@kernel.org>
On 03/04/2024 18:20, Lorenzo Bianconi wrote:
> Introduce EN7581 clock support to clk-en7523 driver.
>
> Tested-by: Zhengping Zhang <zhengping.zhang@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> + return 0;
> +}
> +
> static int en7523_clk_probe(struct platform_device *pdev)
> {
> struct device_node *node = pdev->dev.of_node;
> @@ -306,6 +413,12 @@ static int en7523_clk_probe(struct platform_device *pdev)
> if (IS_ERR(np_base))
> return PTR_ERR(np_base);
>
> + if (of_device_is_compatible(node, "airoha,en7581-scu")) {
Having matching and compatible comparisons inside various code is
discouraged. Does not scale. Use driver/match data to store some sort of
flags and check for the flag or some other parameter. The best if
compatible appears once and only once: in of_device_id.
> + r = en7581_clk_hw_init(pdev, base, np_base);
> + if (r)
> + return r;
> + }
> +
> clk_data = devm_kzalloc(&pdev->dev,
> struct_size(clk_data, hws, EN7523_NUM_CLOCKS),
> GFP_KERNEL);
> @@ -329,8 +442,15 @@ static const struct clk_ops en7523_pcie_ops = {
> .unprepare = en7523_pci_unprepare,
> };
>
> +static const struct clk_ops en7581_pcie_ops = {
> + .is_enabled = en7581_pci_is_enabled,
> + .prepare = en7581_pci_prepare,
> + .unprepare = en7581_pci_unprepare,
> +};
> +
> static const struct of_device_id of_match_clk_en7523[] = {
> { .compatible = "airoha,en7523-scu", .data = &en7523_pcie_ops },
> + { .compatible = "airoha,en7581-scu", .data = &en7581_pcie_ops },
> { /* sentinel */ }
> };
>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8m/qxp: Pass the tcpci compatible
From: Krzysztof Kozlowski @ 2024-04-04 6:38 UTC (permalink / raw)
To: Fabio Estevam, shawnguo
Cc: robh, krzk+dt, conor+dt, devicetree, linux-arm-kernel,
Fabio Estevam
In-Reply-To: <20240403194019.453253-1-festevam@gmail.com>
On 03/04/2024 21:40, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
>
> Per nxp,ptn5110.yaml, also pass the fallback "tcpci" compatible
> to fix the following dt-schema warning:
>
> usb-typec@50: compatible: ['nxp,ptn5110'] is too short
> from schema $id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml#
>
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 0/8] cpufreq: sun50i: Add Allwinner H616 support
From: Viresh Kumar @ 2024-04-04 6:40 UTC (permalink / raw)
To: Andre Przywara
Cc: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki, linux-pm,
devicetree, linux-sunxi, linux-arm-kernel, Brandon Cheo Fusi,
Martin Botka, Martin Botka, Chris Morgan, Ryan Walklin,
Mark Rutland, Lorenzo Pieralisi, Sudeep Holla
In-Reply-To: <20240329141311.27158-1-andre.przywara@arm.com>
On 29-03-24, 14:13, Andre Przywara wrote:
> This series adds cpufreq support to the Allwinner H616 SoC.
> v4 allows compilation outside of arm/arm64, by making the SMCCC call
> optional, the rest of the changes are added tags and cosmetic fixes.
> This is based on Martin's original series from about half a year ago[1].
> Thanks for the comments on the list!
> See below for a changelog.
Is it okay to merge all the changes via the cpufreq tree ?
--
viresh
^ permalink raw reply
* Re: [PATCH v3 21/25] drivers: media: i2c: imx258: Use macros
From: Sakari Ailus @ 2024-04-04 6:46 UTC (permalink / raw)
To: Luigi311
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, devicetree, imx, linux-arm-kernel, linux-kernel, pavel,
phone-devel, Ondrej Jirman
In-Reply-To: <df8c245a-40e9-4bf5-b870-7efe321d820a@luigi311.com>
On Wed, Apr 03, 2024 at 01:17:26PM -0600, Luigi311 wrote:
> On 4/3/24 10:23, Sakari Ailus wrote:
> > Hi Luis,
> >
> > On Wed, Apr 03, 2024 at 09:03:50AM -0600, git@luigi311.com wrote:
> >> From: Luis Garcia <git@luigi311.com>
> >>
> >> Use understandable macros instead of raw values.
> >>
> >> Signed-off-by: Ondrej Jirman <megi@xff.cz>
> >> Signed-off-by: Luis Garcia <git@luigi311.com>
> >> ---
> >> drivers/media/i2c/imx258.c | 434 ++++++++++++++++++-------------------
> >> 1 file changed, 207 insertions(+), 227 deletions(-)
> >>
> >> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> >> index e2ecf6109516..30352c33f63c 100644
> >> --- a/drivers/media/i2c/imx258.c
> >> +++ b/drivers/media/i2c/imx258.c
> >> @@ -33,8 +33,6 @@
> >> #define IMX258_VTS_30FPS_VGA 0x034c
> >> #define IMX258_VTS_MAX 65525
> >>
> >> -#define IMX258_REG_VTS 0x0340
> >> -
> >> /* HBLANK control - read only */
> >> #define IMX258_PPL_DEFAULT 5352
> >>
> >> @@ -90,6 +88,53 @@
> >> #define IMX258_PIXEL_ARRAY_WIDTH 4208U
> >> #define IMX258_PIXEL_ARRAY_HEIGHT 3120U
> >>
> >> +/* regs */
> >> +#define IMX258_REG_PLL_MULT_DRIV 0x0310
> >> +#define IMX258_REG_IVTPXCK_DIV 0x0301
> >> +#define IMX258_REG_IVTSYCK_DIV 0x0303
> >> +#define IMX258_REG_PREPLLCK_VT_DIV 0x0305
> >> +#define IMX258_REG_IOPPXCK_DIV 0x0309
> >> +#define IMX258_REG_IOPSYCK_DIV 0x030b
> >> +#define IMX258_REG_PREPLLCK_OP_DIV 0x030d
> >> +#define IMX258_REG_PHASE_PIX_OUTEN 0x3030
> >> +#define IMX258_REG_PDPIX_DATA_RATE 0x3032
> >> +#define IMX258_REG_SCALE_MODE 0x0401
> >> +#define IMX258_REG_SCALE_MODE_EXT 0x3038
> >> +#define IMX258_REG_AF_WINDOW_MODE 0x7bcd
> >> +#define IMX258_REG_FRM_LENGTH_CTL 0x0350
> >> +#define IMX258_REG_CSI_LANE_MODE 0x0114
> >> +#define IMX258_REG_X_EVN_INC 0x0381
> >> +#define IMX258_REG_X_ODD_INC 0x0383
> >> +#define IMX258_REG_Y_EVN_INC 0x0385
> >> +#define IMX258_REG_Y_ODD_INC 0x0387
> >> +#define IMX258_REG_BINNING_MODE 0x0900
> >> +#define IMX258_REG_BINNING_TYPE_V 0x0901
> >> +#define IMX258_REG_FORCE_FD_SUM 0x300d
> >> +#define IMX258_REG_DIG_CROP_X_OFFSET 0x0408
> >> +#define IMX258_REG_DIG_CROP_Y_OFFSET 0x040a
> >> +#define IMX258_REG_DIG_CROP_IMAGE_WIDTH 0x040c
> >> +#define IMX258_REG_DIG_CROP_IMAGE_HEIGHT 0x040e
> >> +#define IMX258_REG_SCALE_M 0x0404
> >> +#define IMX258_REG_X_OUT_SIZE 0x034c
> >> +#define IMX258_REG_Y_OUT_SIZE 0x034e
> >> +#define IMX258_REG_X_ADD_STA 0x0344
> >> +#define IMX258_REG_Y_ADD_STA 0x0346
> >> +#define IMX258_REG_X_ADD_END 0x0348
> >> +#define IMX258_REG_Y_ADD_END 0x034a
> >> +#define IMX258_REG_EXCK_FREQ 0x0136
> >> +#define IMX258_REG_CSI_DT_FMT 0x0112
> >> +#define IMX258_REG_LINE_LENGTH_PCK 0x0342
> >> +#define IMX258_REG_SCALE_M_EXT 0x303a
> >> +#define IMX258_REG_FRM_LENGTH_LINES 0x0340
> >> +#define IMX258_REG_FINE_INTEG_TIME 0x0200
> >> +#define IMX258_REG_PLL_IVT_MPY 0x0306
> >> +#define IMX258_REG_PLL_IOP_MPY 0x030e
> >> +#define IMX258_REG_REQ_LINK_BIT_RATE_MBPS_H 0x0820
> >> +#define IMX258_REG_REQ_LINK_BIT_RATE_MBPS_L 0x0822
> >> +
> >> +#define REG8(a, v) { a, v }
> >> +#define REG16(a, v) { a, ((v) >> 8) & 0xff }, { (a) + 1, (v) & 0xff }
> >
> > The patch is nice but these macros are better replaced by the V4L2 CCI
> > helper that also offers register access functions. Could you add a patch to
> > convert the driver to use it (maybe after this one)?
> >
>
> Ohh perfect, using something else would be great. Ill go ahead and see
> if I can get that working.
Thanks. It may be easier to just do it in this one actually. Up to you.
--
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v3 22/25] dt-bindings: media: imx258: Add binding for powerdown-gpio
From: Sakari Ailus @ 2024-04-04 6:47 UTC (permalink / raw)
To: git
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, devicetree, imx, linux-arm-kernel, linux-kernel, pavel,
phone-devel, Ondrej Jirman
In-Reply-To: <20240403150355.189229-23-git@luigi311.com>
Hi Luigi,
On Wed, Apr 03, 2024 at 09:03:51AM -0600, git@luigi311.com wrote:
> From: Luis Garcia <git@luigi311.com>
>
> Add powerdown-gpio binding as it is required for some boards
>
> Signed-off-by: Ondrej Jirman <megi@xff.cz>
> Signed-off-by: Luis Garcia <git@luigi311.com>
> ---
> Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> index c978abc0cdb3..33338139e6e8 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> @@ -36,6 +36,10 @@ properties:
> reg:
> maxItems: 1
>
> + powerdown-gpios:
> + description:
> + Reference to the GPIO connected to the PWDN pin, if any.
The sensor datasheet does not mention this one so I presume this is
unrelated to the sensor. Could it be for GPIO regulator control instead?
> +
> reset-gpios:
> description: |-
> Reference to the GPIO connected to the XCLR pin, if any.
--
Regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH 1/1] dt-bindings: media: imx-jpeg: add clocks,clock-names,slot to fix warning
From: Krzysztof Kozlowski @ 2024-04-04 6:54 UTC (permalink / raw)
To: Frank Li, Mirela Rabulea, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER,
open list:NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <af602862-5120-4717-adb6-694ada09e8d8@linaro.org>
On 04/04/2024 08:26, Krzysztof Kozlowski wrote:
> On 04/04/2024 05:52, Frank Li wrote:
>> Fix below DTB_CHECK warning.
>>
>> make CHECK_DTBS=y freescale/imx8qxp-mek.dtb
>> DTC_CHK arch/arm64/boot/dts/freescale/imx8qxp-mek.dtb
>> arch/arm64/boot/dts/freescale/imx8qxp-mek.dtb: jpegdec@58400000: 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks', 'slot' do not match any of the regexes: 'pinctrl-[0-9]+'
>> from schema $id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
>
> No, that's not the reason to add properties. Add them if they are valid.
And for the clocks, instead pick up this patch:
https://lore.kernel.org/all/20230721111020.1234278-3-alexander.stein@ew.tq-group.com/
Please check for same work on lore before working on old issues. dfn in
lore is your friend.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: mailbox: arm,mhuv3: Add bindings
From: Cristian Marussi @ 2024-04-04 6:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-kernel, linux-arm-kernel, devicetree, sudeep.holla,
jassisinghbrar, robh+dt, krzysztof.kozlowski+dt, conor+dt
In-Reply-To: <da62846c-884f-4059-a4bd-2e5f5c879e8b@linaro.org>
On Thu, Apr 04, 2024 at 08:30:27AM +0200, Krzysztof Kozlowski wrote:
> On 04/04/2024 08:23, Cristian Marussi wrote:
> > Add bindings for the ARM MHUv3 Mailbox controller.
> >
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---
> > v2 -> v3
> > - fixed spurious tabs in dt_binding_check
>
> Did you test this patch before sending?
>
Tested with:
make -j8 DT_SCHEMA_FILES=arm,mhuv3.yaml DT_CHECKER_FLAGS=-m dt_binding_check
(with dtschema upgraded)
...and indeed even v2 was supposedly already tested (since included a
bunch of changes as advised), then I made a small last-minute nitpick and
my editor splipped in a couple of tabs...apologies for that.
Thanks,
Cristian
^ permalink raw reply
* Re: [RESEND v7 26/37] dt-bindings: vendor-prefixes: Add iodata
From: Krzysztof Kozlowski @ 2024-04-04 6:57 UTC (permalink / raw)
To: Yoshinori Sato, linux-sh
Cc: Damien Le Moal, Niklas Cassel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
David Airlie, Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Thomas Gleixner, Bjorn Helgaas,
Lorenzo Pieralisi, Krzysztof Wilczyński, Greg Kroah-Hartman,
Jiri Slaby, Magnus Damm, Daniel Lezcano, Rich Felker,
John Paul Adrian Glaubitz, Lee Jones, Helge Deller,
Heiko Stuebner, Shawn Guo, Sebastian Reichel, Chris Morgan,
Linus Walleij, Arnd Bergmann, David Rientjes, Hyeonggon Yoo,
Vlastimil Babka, Baoquan He, Andrew Morton, Guenter Roeck,
Kefeng Wang, Stephen Rothwell, Javier Martinez Canillas, Guo Ren,
Azeem Shaikh, Max Filippov, Jonathan Corbet, Jacky Huang,
Herve Codina, Manikanta Guntupalli, Anup Patel, Biju Das,
Uwe Kleine-König, Sam Ravnborg, Sergey Shtylyov,
Laurent Pinchart, linux-ide, devicetree, linux-kernel,
linux-renesas-soc, linux-clk, dri-devel, linux-pci, linux-serial,
linux-fbdev
In-Reply-To: <4649938dc48da6e449ef6f1987c7739ba3a80b42.1712207606.git.ysato@users.sourceforge.jp>
On 04/04/2024 07:14, Yoshinori Sato wrote:
> Add IO DATA DEVICE INC.
> https://www.iodata.com/
>
> Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.
https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state why and what changed.
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox