* Re: [PATCH v2 2/2] mfd: rohm-bd71828: Add power off functionality
From: Andreas Kemnade @ 2024-03-27 13:04 UTC (permalink / raw)
To: Matti Vaittinen
Cc: lee, robh+dt, krzysztof.kozlowski+dt, conor+dt, devicetree,
linux-kernel
In-Reply-To: <815e1cdc-145e-4880-96a0-d9c21308b9b3@gmail.com>
Hi,
On Wed, 27 Mar 2024 09:32:29 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> It's worth noting that there is another PMIC, BD71879, which, from the
> driver software point of view, should be (almost?) identical to the
> BD71828. I believe the BD71828 drivers should work with it as well - if
> not out of the box, at least with very minor modifications.
> Unfortunately I don't know products where the BD71879 is used or if it
> is sold via distributors - so I don't know if adding a DT
> compatible/chip type define for it would be beneficial.
yes, you already told we thet the BD71828 drivers are compatible with
the BD71879 and I am using the latter.
But that at least should be commented somewhere, so that
people do not raise questions, like: Do I have some strange board revision,
etc?
The most terse form to comment it is a separate dt compatible so we are
prepare any "almost identical" surprises.
Regards,
Andreas
^ permalink raw reply
* Re: [PATCH 4/4] drm/bridge: hotplug-bridge: add driver to support hot-pluggable DSI bridges
From: Maxime Ripard @ 2024-03-27 12:42 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, David Airlie, Daniel Vetter,
Maarten Lankhorst, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Paul Kocialkowski,
Hervé Codina, Thomas Petazzoni, dri-devel, devicetree,
linux-kernel, Paul Kocialkowski
In-Reply-To: <20240326-hotplug-drm-bridge-v1-4-4b51b5eb75d5@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 5228 bytes --]
On Tue, Mar 26, 2024 at 05:28:14PM +0100, Luca Ceresoli wrote:
> This driver implements the point of a DRM pipeline where a connector allows
> removal of all the following bridges up to the panel.
>
> The DRM subsystem currently allows hotplug of the monitor but not preceding
> components. However there are embedded devices where the "tail" of the DRM
> pipeline, including one or more bridges, can be physically removed:
>
> .------------------------.
> | DISPLAY CONTROLLER |
> | .---------. .------. |
> | | ENCODER |<--| CRTC | |
> | '---------' '------' |
> '------|-----------------'
> |
> | HOTPLUG
> V CONNECTOR
> .---------. .--. .-. .---------. .-------.
> | 0 to N | | _| _| | | 1 to N | | |
> | BRIDGES |--DSI-->||_ |_ |--DSI-->| BRIDGES |--LVDS-->| PANEL |
> | | | | | | | | | |
> '---------' '--' '-' '---------' '-------'
>
> [--- fixed components --] [----------- removable add-on -----------]
>
> This driver supports such devices, where the final segment of a MIPI DSI
> bus, including one or more bridges, can be physically disconnected and
> reconnected at runtime, possibly with a different model.
>
> This implementation supports a MIPI DSI bus only, but it is designed to be
> as far as possible generic and extendable to other busses that have no
> native hotplug and model ID discovery.
>
> This driver does not provide facilities to add and remove the hot-pluggable
> components from the kernel: this needs to be done by other means
> (e.g. device tree overlay runtime insertion and removal). The
> hotplug-bridge gets notified of hot-plugging by the DRM bridge notifier
> callbacks after they get added or before they get removed.
>
> The hotplug-bridge role is to implement the "hot-pluggable connector" in
> the bridge chain. In this position, what the hotplug-bridge should ideally
> do is:
>
> * communicate with the previous component (bridge or encoder) so that it
> believes it always has a connected bridge following it and the DRM card
> is always present
> * be notified of the addition and removal of the following bridge and
> attach/detach to/from it
> * communicate with the following bridge so that it will attach and detach
> using the normal procedure (as if the entire pipeline were being created
> or destroyed, not only the tail)
> * expose the "add-on connected/disconnected" status via the DRM connector
> connected/disconnected status, so that users of the DRM pipeline know
> when they can render output on the display
>
> However some aspects make it a bit more complex than that. Most notably:
>
> * the next bridge can be probed and removed at any moment and all probing
> sequences need to be handled
> * the DSI host/device registration process, which adds to the DRM bridge
> attach process, makes the initial card registration tricky
> * the need to register and deregister the following bridges at runtime
> without tearing down the whole DRM card prevents using the functions
> that are normally recommended
> * the automatic mechanism to call the appropriate .get_modes operation
> (typically provided by the panel bridge) cannot work as the panel can
> disappear and reappear as a different model, so an ad-hoc lookup is
> needed
There's several additional hurdles there:
- You mentioned the connector in your ideal scenario. But as soon as
you remove the last bridge, the connector will probably go away too.
There's two scenarii here then:
- The driver is ok, and it will stay there until the last user its to
the main DRM device. Which means that if you create a new one,
you'll have the old one and the new one together, but you can't
tell which one you're supposed to use.
- If the driver isn't ok, the connector will be freed immediately.
There's plenty of lingering pointers in the framework, and
especially the states though, leading to use-after-free errors.
- So far, we told everyone that the graphics pipeline wasn't going to
change. How do you expect applications to deal with a connector going
away without any regression? I guess the natural thing here would be
to emit a uevent just like we do when the connection status change,
but the thing is: we're doing that for the connector, and the
connector is gone.
Between the userspace expectations and the memory-safety issue plaguing
way too many drivers, I'm not sure this approach can work.
I guess one way to somewhat achieve what you're trying to do would be to
introduce the connection status at the bridge level, reflect the
aggregate connection status of all bridges on the connector, and make
each bridge driver probe its device in the connect hook through DCS or
I2C.
We wouldn't be able to change the bridge halfway through the system's
life, but like I said, KMS cannot hotplug connectors at the moment and
doing so requires far more work.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: rockchip: Add VEPU121 to rk3588
From: Link Mauve @ 2024-03-27 12:40 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Emmanuel Gil Peyrot, linux-kernel, Ezequiel Garcia, Philipp Zabel,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Joerg Roedel, Will Deacon,
Robin Murphy, Sebastian Reichel, Cristian Ciocaltea, Dragan Simic,
Shreeya Patel, Chris Morgan, Andy Yan, Nicolas Frattaroli,
linux-media, linux-rockchip, devicetree, linux-arm-kernel, iommu
In-Reply-To: <a60f6017-bd19-431e-8cff-7d73f6f114fe@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]
On Thu, Mar 21, 2024 at 09:15:38AM +0100, Krzysztof Kozlowski wrote:
> On 20/03/2024 18:37, Emmanuel Gil Peyrot wrote:
> > The TRM (version 1.0 page 385) lists five VEPU121 cores, but only four
> > interrupts are listed (on page 24), so I’ve only enabled four of them
> > for now.
> >
> > Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
> > ---
> > arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 80 +++++++++++++++++++++++
> > 1 file changed, 80 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> > index 2a23b4dc36e4..fe77b56ac9a0 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> > @@ -2488,6 +2488,86 @@ gpio4: gpio@fec50000 {
> > };
> > };
> >
> > + jpeg_enc0: video-codec@fdba0000 {
> > + compatible = "rockchip,rk3588-vepu121";
> > + reg = <0x0 0xfdba0000 0x0 0x800>;
> > + interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH 0>;
> > + clocks = <&cru ACLK_JPEG_ENCODER0>, <&cru HCLK_JPEG_ENCODER0>;
> > + clock-names = "aclk", "hclk";
> > + iommus = <&jpeg_enc0_mmu>;
> > + power-domains = <&power RK3588_PD_VDPU>;
> > + };
> > +
> > + jpeg_enc0_mmu: iommu@fdba0800 {
> > + compatible = "rockchip,rk3588-iommu";
>
> It does not look like you tested the DTS against bindings. Please run
> `make dtbs_check W=1` (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
Even on master I get an exception about this unresolvable file:
referencing.exceptions.Unresolvable: cache-controller.yaml#
Yet it seems to be present in only three files, all of them unrelated to
the rockchip board I’m interested in (it seems), so I’m not sure what to
do about that.
The full stack trace is attached.
>
> Best regards,
> Krzysztof
>
--
Link Mauve
[-- Attachment #2: CHECK_DTBS=y W=1 --]
[-- Type: text/plain, Size: 4155 bytes --]
% make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y W=1 rockchip/rk3588-rock-5b.dtb
make[1]: Entering directory '/home/linkmauve/dev/linux'
DTC_CHK arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dtb
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/referencing/_core.py", line 417, in get_or_retrieve
resource = registry._retrieve(uri)
^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/jsonschema/validators.py", line 111, in _warn_for_remote_retrieve
request = Request(uri, headers=headers) # noqa: S310
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/urllib/request.py", line 322, in __init__
self.full_url = url
^^^^^^^^^^^^^
File "/usr/lib/python3.11/urllib/request.py", line 348, in full_url
self._parse()
File "/usr/lib/python3.11/urllib/request.py", line 377, in _parse
raise ValueError("unknown url type: %r" % self.full_url)
ValueError: unknown url type: 'cache-controller.yaml'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/referencing/_core.py", line 667, in lookup
retrieved = self._registry.get_or_retrieve(uri)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/referencing/_core.py", line 424, in get_or_retrieve
raise exceptions.Unretrievable(ref=uri) from error
referencing.exceptions.Unretrievable: 'cache-controller.yaml'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/bin/dt-validate", line 8, in <module>
sys.exit(main())
^^^^^^
File "/usr/lib/python3.11/site-packages/dtschema/dtb_validate.py", line 144, in main
sg.check_dtb(filename)
File "/usr/lib/python3.11/site-packages/dtschema/dtb_validate.py", line 89, in check_dtb
self.check_subtree(dt, subtree, False, "/", "/", filename)
File "/usr/lib/python3.11/site-packages/dtschema/dtb_validate.py", line 82, in check_subtree
self.check_subtree(tree, value, disabled, name, fullname + name, filename)
File "/usr/lib/python3.11/site-packages/dtschema/dtb_validate.py", line 82, in check_subtree
self.check_subtree(tree, value, disabled, name, fullname + name, filename)
File "/usr/lib/python3.11/site-packages/dtschema/dtb_validate.py", line 77, in check_subtree
self.check_node(tree, subtree, disabled, nodename, fullname, filename)
File "/usr/lib/python3.11/site-packages/dtschema/dtb_validate.py", line 33, in check_node
for error in self.validator.iter_errors(node, filter=match_schema_file):
File "/usr/lib/python3.11/site-packages/dtschema/validator.py", line 413, in iter_errors
for error in self.DtValidator(sch,
File "/usr/lib/python3.11/site-packages/jsonschema/validators.py", line 371, in iter_errors
for error in errors:
File "/usr/lib/python3.11/site-packages/jsonschema/_keywords.py", line 386, in if_
yield from validator.descend(instance, then, schema_path="then")
File "/usr/lib/python3.11/site-packages/jsonschema/validators.py", line 419, in descend
for error in errors:
File "/usr/lib/python3.11/site-packages/jsonschema/_legacy_keywords.py", line 423, in unevaluatedProperties_draft2019
evaluated_keys = find_evaluated_property_keys_by_schema(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/jsonschema/_legacy_keywords.py", line 399, in find_evaluated_property_keys_by_schema
evaluated_keys += find_evaluated_property_keys_by_schema(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/jsonschema/_legacy_keywords.py", line 342, in find_evaluated_property_keys_by_schema
resolved = validator._resolver.lookup(ref)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/referencing/_core.py", line 671, in lookup
raise exceptions.Unresolvable(ref=ref) from error
referencing.exceptions.Unresolvable: cache-controller.yaml#
make[1]: Leaving directory '/home/linkmauve/dev/linux'
^ permalink raw reply
* Re: [PATCH 0/8] block: implement NVMEM provider
From: Rob Herring @ 2024-03-27 12:33 UTC (permalink / raw)
To: Daniel Golle, Architecture Mailman List
Cc: Diping Zhang, Jianhui Zhao, Jieying Zeng, Chad Monroe, Adam Fox,
John Crispin, Felix Fietkau, Krzysztof Kozlowski, Conor Dooley,
Ulf Hansson, Jens Axboe, Dave Chinner, Jan Kara,
Thomas Weißschuh, Damien Le Moal, Li Lingfeng,
Christian Brauner, Christian Heusel, Min Li, Adrian Hunter,
Avri Altman, Hannes Reinecke, Christian Loehle, Bean Huo, Yeqi Fu,
Victor Shih, Christophe JAILLET, Dominique Martinet,
Ricardo B. Marliere, devicetree, linux-kernel, linux-mmc,
linux-block
In-Reply-To: <ZgM-AR1BFU_FPaXh@makrotopia.org>
On Tue, Mar 26, 2024 at 4:29 PM Daniel Golle <daniel@makrotopia.org> wrote:
>
> Hi Rob,
>
> On Tue, Mar 26, 2024 at 03:24:49PM -0500, Rob Herring wrote:
> > +boot-architecture list
>
> Good idea, thank you :)
Now really adding it. :(
Will reply to rest later.
> >
> > On Mon, Mar 25, 2024 at 03:38:19PM +0000, Daniel Golle wrote:
> > > On Mon, Mar 25, 2024 at 10:10:46AM -0500, Rob Herring wrote:
> > > > On Thu, Mar 21, 2024 at 07:31:48PM +0000, Daniel Golle wrote:
> > > > > On embedded devices using an eMMC it is common that one or more (hw/sw)
> > > > > partitions on the eMMC are used to store MAC addresses and Wi-Fi
> > > > > calibration EEPROM data.
> > > > >
> > > > > Implement an NVMEM provider backed by a block device as typically the
> > > > > NVMEM framework is used to have kernel drivers read and use binary data
> > > > > from EEPROMs, efuses, flash memory (MTD), ...
> > > > >
> > > > > In order to be able to reference hardware partitions on an eMMC, add code
> > > > > to bind each hardware partition to a specific firmware subnode.
> > > > >
> > > > > Overall, this enables uniform handling across practially all flash
> > > > > storage types used for this purpose (MTD, UBI, and now also MMC).
> > > > >
> > > > > As part of this series it was necessary to define a device tree schema
> > > > > for block devices and partitions on them, which (similar to how it now
> > > > > works also for UBI volumes) can be matched by one or more properties.
> > > > >
> > > > > ---
> > > > > This series has previously been submitted as RFC on July 19th 2023[1]
> > > > > and most of the basic idea did not change since. Another round of RFC
> > > > > was submitted on March 5th 2024[2] which has received overall positive
> > > > > feedback and only minor corrections have been done since (see
> > > > > changelog below).
> > > >
> > > > I don't recall giving positive feedback.
> > > >
> > > > I still think this should use offsets rather than partition specific
> > > > information. Not wanting to have to update the offsets if they change is
> > > > not reason enough to not use them.
> > >
> > > Using raw offsets on the block device (rather than the partition)
> > > won't work for most existing devices and boot firmware out there. They
> > > always reference the partition, usually by the name of a GPT
> > > partition (but sometimes also PARTUUID or even PARTNO) which is then
> > > used in the exact same way as an MTD partition or UBI volume would be
> > > on devices with NOR or NAND flash.
> >
> > MTD normally uses offsets hence why I'd like some alignment. UBI is
> > special because raw NAND is, well, special.
>
> I get the point and in a way this is also already intended and
> supported by this series. You can already just add an 'nvmem-layout'
> node directly to a disk device rather than to a partition and define a
> layout in this way.
>
> Making this useful in practice will require some improvements to the
> nvmem system in Linux though, because that currently uses signed 32-bit
> integers as addresses which is not sufficient for the size of the
> user-part of an eMMC. However, that needs to be done then and should
> of course not be read as an excuse.
>
> >
> > > Just on eMMC we usually use a GPT
> > > or MBR partition table rather than defining partitions in DT or cmdline,
> > > which is rather rare (for historic reasons, I suppose, but it is what it
> > > is now).
> >
> > Yes, I understand how eMMC works. I don't understand why if you have
> > part #, uuid, or name you can't get to the offset or vice-versa. You
> > need only 1 piece of identification to map partition table entries to DT
> > nodes.
>
> Yes, either of them (or a combination) is fine. In practise I've mostly
> seen PARTNAME as identifier used in userland scripts, and only adding
> this for now will probably cover most devices (and existing boot firmware)
> out there. Notable exceptions are devices which are using MBR partitions
> because the BootROM expects the bootloader to be at the same block as
> we would usually have the primary GPT. In this case we can only use the
> PARTNO, of course, and it stinks.
> MediaTek's MT7623A/N is such an example, but it's a slingly outdated
> and pretty weird niche SoC I admit.
>
> > Sure, offsets can change, but surely the firmware can handle
> > adjusting the DT?
>
> Future firmware may be able to do this, of course. Current existing
> firmware already out there on devices such as the quite popular
> GL.iNet MT-6000, Netgear's Orbi and Orbi Pro series as well as all
> Adtran SmartRG devices does not. Updating or changing the boot
> firmware of devices already out there is not intended and quite
> challenging, and will make the device incompatible with its vendor
> firmware. Hence it would be better to support replacing only the
> Linux-based firmware (eg. with OpenWrt or even Debian or any
> general-purpose Linux, the eMMC is large enough...) while not having
> to touch the boot firmware (and risking to brick the device if that
> goes wrong).
>
> Personally, I'm rather burdened and unhappy with vendor attempts to
> have the boot firmware mess around too much in (highly customized,
> downstream) DT, it may look like a good solution at the moment, but
> can totally become an obstacle in an unpredictable future (no offense
> ASUS...)
>
> >
> > An offset would also work for the case of random firmware data on the
> > disk that may or may not have a partition associated with it. There are
> > certainly cases of that. I don't think we have much of a solution for
> > that other than trying to educate vendors to not do that or OS
> > installers only supporting installing to something other than eMMC. This
> > is something EBBR[1] is trying to address.
>
> Absolutely. Actually *early* GL-iNet devices did exactly that: Use the
> eMMC boot hw-partitions to store boot firmware as well as MAC
> addresses and potentially also Wi-Fi calibration data.
>
> The MT-2500 is the example I'm aware of and got sitting on my desk for
> testing with this very series (which allows to also reference eMMC
> hardware partitions, see "[7/8] mmc: block: set fwnode of disk
> devices").
> Unfortunately later devices such the the flag-ship MT-6000 moved MAC
> addresses and WiFi-EEPROMs into a GPT partition on the user-part of
> the eMMC.
>
> >
> > > Depending on the eMMC chip used, that partition may not even be at the
> > > same offset for different batches of the same device and hence I'd
> > > like to just do it in the same way vendor firmware does it as well.
> >
> > Often vendor firmware is not a model to follow...
>
> I totally agree. However, I don't see a good reason for not supporting
> those network-appliance-type embedded devices which even ship with
> (outdated, downstream) Linux by default while going through great
> lengths for things like broken ACPI tables in many laptops which
> require lots of work-arounds to have features like suspend-to-disk
> working, or even be able to run Linux at all.
>
> >
> > > Chad of Adtran has previously confirmed that [1], which was the
> > > positive feedback I was refering to. Other vendors like GL-iNet or
> > > Netgear are doing the exact same thing.
> > >
> > > As of now, we support this in OpenWrt by adding a lot of
> > > board-specific knowledge to userland, which is ugly and also prevents
> > > using things like PXE-initiated nfsroot on those devices.
> > >
> > > The purpose of this series is to be able to properly support such devices
> > > (ie. practially all consumer-grade routers out there using an eMMC for
> > > storing firmware).
> > >
> > > Also, those devices have enough resources to run a general purpose
> > > distribution like Debian instead of OpenWrt, and all the userland
> > > hacks to set MAC addresses and extract WiFi-EEPROM-data in a
> > > board-specific ways will most certainly never find their way into
> > > Debian. It's just not how embedded Linux works, unless you are looking
> > > only at the RaspberryPi which got that data stored in a textfile
> > > which is shipped by the distribution -- something very weird and very
> > > different from literally all of-the-shelf routers, access-points or
> > > switches I have ever seen (and I've seen many). Maybe Felix who has
> > > seen even more of them can tell us more about that.
> >
> > General purpose distros want to partition the disk themselves. Adding
> > anything to the DT for disk partitions would require the installer to be
> > aware of it. There's various distro folks on the boot-arch list, so
> > maybe one of them can comment.
>
> Usually the installers are already aware to not touch partitions when
> unaware of their purpose. Repartitioning the disk from scratch is not
> what (modern) distributions are doing, at least the EFI System
> partition is kept, as well as typical rescue/recovery partitions many
> vendors put on their (Windows, Mac) laptops to allow to "factory
> reset" them.
>
> Installers usually offer to replace (or resize) the "large" partition
> used by the currently installed OS instead.
>
> And well, the DT reference to a partition holding e.g. MAC addresses
> does make the installer aware of it, obviously.
>
>
> Thank you for the constructive debate!
>
>
> Cheers
>
>
> Daniel
>
>
> >
> > Rob
> >
> > [1] https://arm-software.github.io/ebbr/index.html#document-chapter4-firmware-media
^ permalink raw reply
* [PATCH v1 5/5] riscv: dts: microchip: add an initial devicetree for the BeagleV Fire
From: Conor Dooley @ 2024-03-27 12:24 UTC (permalink / raw)
To: linux-riscv
Cc: conor, Conor Dooley, Daire McNamara, Jamie Gibbons,
Valentina Fernandez, Linus Walleij, Bartosz Golaszewski,
Rob Herring, Krzysztof Kozlowski, Lorenzo Pieralisi,
Krzysztof Wilczyński, Bjorn Helgaas, linux-gpio, devicetree,
linux-kernel, linux-pci
In-Reply-To: <20240327-parkway-dodgy-f0fe1fa20892@spud>
From: Conor Dooley <conor.dooley@microchip.com>
Add an initial devicetree for the BeagleV Fire. This devicetree differs
from that in the BeagleBoard BSP as it has a different memory
configuration, however it will boot on the same FPGA images. PCI is
disabled for now, as the Linux PCI driver (and the binding) assume
which root port instance is in use. This will need to be fixed before
PCI can be enabled.
Link: https://www.beagleboard.org/boards/beaglev-fire
Co-developed-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
arch/riscv/boot/dts/microchip/Makefile | 1 +
.../microchip/mpfs-beaglev-fire-fabric.dtsi | 124 ++++++++++
.../boot/dts/microchip/mpfs-beaglev-fire.dts | 223 ++++++++++++++++++
3 files changed, 348 insertions(+)
create mode 100644 arch/riscv/boot/dts/microchip/mpfs-beaglev-fire-fabric.dtsi
create mode 100644 arch/riscv/boot/dts/microchip/mpfs-beaglev-fire.dts
diff --git a/arch/riscv/boot/dts/microchip/Makefile b/arch/riscv/boot/dts/microchip/Makefile
index e177815bf1a2..f51aeeb9fd3b 100644
--- a/arch/riscv/boot/dts/microchip/Makefile
+++ b/arch/riscv/boot/dts/microchip/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_ARCH_MICROCHIP_POLARFIRE) += mpfs-beaglev-fire.dtb
dtb-$(CONFIG_ARCH_MICROCHIP_POLARFIRE) += mpfs-icicle-kit.dtb
dtb-$(CONFIG_ARCH_MICROCHIP_POLARFIRE) += mpfs-m100pfsevp.dtb
dtb-$(CONFIG_ARCH_MICROCHIP_POLARFIRE) += mpfs-polarberry.dtb
diff --git a/arch/riscv/boot/dts/microchip/mpfs-beaglev-fire-fabric.dtsi b/arch/riscv/boot/dts/microchip/mpfs-beaglev-fire-fabric.dtsi
new file mode 100644
index 000000000000..0abd0dc540be
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/mpfs-beaglev-fire-fabric.dtsi
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+
+/ {
+ fabric_clk3: fabric-clk3 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <50000000>;
+ };
+
+ fabric_clk1: fabric-clk1 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ };
+
+ fabric-bus@40000000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x0 0x40000000 0x0 0x40000000 0x0 0x20000000>, /* FIC3-FAB */
+ <0x0 0x60000000 0x0 0x60000000 0x0 0x20000000>, /* FIC0, LO */
+ <0x0 0xe0000000 0x0 0xe0000000 0x0 0x20000000>, /* FIC1, LO */
+ <0x20 0x0 0x20 0x0 0x10 0x0>, /* FIC0,HI */
+ <0x30 0x0 0x30 0x0 0x10 0x0>; /* FIC1,HI */
+
+ cape_gpios_p8: gpio@41100000 {
+ compatible = "microchip,coregpio-rtl-v3";
+ reg = <0x0 0x41100000 0x0 0x1000>;
+ clocks = <&fabric_clk3>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <16>;
+ gpio-line-names = "P8_PIN31", "P8_PIN32", "P8_PIN33", "P8_PIN34",
+ "P8_PIN35", "P8_PIN36", "P8_PIN37", "P8_PIN38",
+ "P8_PIN39", "P8_PIN40", "P8_PIN41", "P8_PIN42",
+ "P8_PIN43", "P8_PIN44", "P8_PIN45", "P8_PIN46";
+ };
+
+ cape_gpios_p9: gpio@41200000 {
+ compatible = "microchip,coregpio-rtl-v3";
+ reg = <0x0 0x41200000 0x0 0x1000>;
+ clocks = <&fabric_clk3>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <20>;
+ gpio-line-names = "P9_PIN11", "P9_PIN12", "P9_PIN13", "P9_PIN14",
+ "P9_PIN15", "P9_PIN16", "P9_PIN17", "P9_PIN18",
+ "P9_PIN21", "P9_PIN22", "P9_PIN23", "P9_PIN24",
+ "P9_PIN25", "P9_PIN26", "P9_PIN27", "P9_PIN28",
+ "P9_PIN29", "P9_PIN31", "P9_PIN41", "P9_PIN42";
+ };
+
+ hsi_gpios: gpio@44000000 {
+ compatible = "microchip,coregpio-rtl-v3";
+ reg = <0x0 0x44000000 0x0 0x1000>;
+ clocks = <&fabric_clk3>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <20>;
+ gpio-line-names = "B0_HSIO70N", "B0_HSIO71N", "B0_HSIO83N",
+ "B0_HSIO73N_C2P_CLKN", "B0_HSIO70P", "B0_HSIO71P",
+ "B0_HSIO83P", "B0_HSIO73N_C2P_CLKP", "XCVR1_RX_VALID",
+ "XCVR1_LOCK", "XCVR1_ERROR", "XCVR2_RX_VALID",
+ "XCVR2_LOCK", "XCVR2_ERROR", "XCVR3_RX_VALID",
+ "XCVR3_LOCK", "XCVR3_ERROR", "XCVR_0B_REF_CLK_PLL_LOCK",
+ "XCVR_0C_REF_CLK_PLL_LOCK", "B0_HSIO81N";
+ };
+ };
+
+ fabric-pcie-bus@3000000000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x0 0x40000000 0x0 0x40000000 0x0 0x20000000>,
+ <0x30 0x0 0x30 0x0 0x10 0x0>;
+
+ pcie: pcie@3000000000 {
+ compatible = "microchip,pcie-host-1.0";
+ #address-cells = <0x3>;
+ #interrupt-cells = <0x1>;
+ #size-cells = <0x2>;
+ device_type = "pci";
+ reg = <0x30 0x0 0x0 0x8000000>,
+ <0x0 0x43000000 0x0 0x10000>;
+ reg-names = "cfg", "apb";
+ bus-range = <0x0 0x7f>;
+ interrupt-parent = <&plic>;
+ interrupts = <119>;
+ interrupt-map = <0 0 0 1 &pcie_intc 0>,
+ <0 0 0 2 &pcie_intc 1>,
+ <0 0 0 3 &pcie_intc 2>,
+ <0 0 0 4 &pcie_intc 3>;
+ interrupt-map-mask = <0 0 0 7>;
+ clocks = <&ccc_nw CLK_CCC_PLL0_OUT1>,
+ <&ccc_nw CLK_CCC_PLL0_OUT3>;
+ clock-names = "fic1", "fic3";
+ ranges = <0x43000000 0x0 0x9000000 0x30 0x9000000 0x0 0xf000000>,
+ <0x1000000 0x0 0x8000000 0x30 0x8000000 0x0 0x1000000>,
+ <0x3000000 0x0 0x18000000 0x30 0x18000000 0x0 0x70000000>;
+ msi-parent = <&pcie>;
+ msi-controller;
+ status = "disabled";
+
+ pcie_intc: interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
+ };
+
+ refclk_ccc: cccrefclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ };
+};
+
+&ccc_nw {
+ clocks = <&refclk_ccc>, <&refclk_ccc>, <&refclk_ccc>, <&refclk_ccc>,
+ <&refclk_ccc>, <&refclk_ccc>;
+ clock-names = "pll0_ref0", "pll0_ref1", "pll1_ref0", "pll1_ref1",
+ "dll0_ref", "dll1_ref";
+ status = "okay";
+};
diff --git a/arch/riscv/boot/dts/microchip/mpfs-beaglev-fire.dts b/arch/riscv/boot/dts/microchip/mpfs-beaglev-fire.dts
new file mode 100644
index 000000000000..47cf693beb68
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/mpfs-beaglev-fire.dts
@@ -0,0 +1,223 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2020-2021 Microchip Technology Inc */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "mpfs.dtsi"
+#include "mpfs-beaglev-fire-fabric.dtsi"
+
+/* Clock frequency (in Hz) of MTIMER */
+#define MTIMER_FREQ 1000000
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ model = "BeagleBoard BeagleV-Fire";
+ compatible = "beagle,beaglev-fire", "microchip,mpfs";
+
+ aliases {
+ serial0 = &mmuart0;
+ serial1 = &mmuart1;
+ serial2 = &mmuart2;
+ serial3 = &mmuart3;
+ serial4 = &mmuart4;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ cpus {
+ timebase-frequency = <MTIMER_FREQ>;
+ };
+
+ ddrc_cache_lo: memory@80000000 {
+ device_type = "memory";
+ reg = <0x0 0x80000000 0x0 0x40000000>;
+ status = "okay";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ hss: hss-buffer@103fc00000 {
+ compatible = "shared-dma-pool";
+ reg = <0x10 0x3fc00000 0x0 0x400000>;
+ no-map;
+ };
+ };
+
+ imx219_clk: camera-clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24000000>;
+ };
+
+ imx219_vana: fixedregulator-0 {
+ compatible = "regulator-fixed";
+ regulator-name = "imx219_vana";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ imx219_vdig: fixedregulator-1 {
+ compatible = "regulator-fixed";
+ regulator-name = "imx219_vdig";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ imx219_vddl: fixedregulator-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "imx219_vddl";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+};
+
+&gpio2 {
+ interrupts = <53>, <53>, <53>, <53>,
+ <53>, <53>, <53>, <53>,
+ <53>, <53>, <53>, <53>,
+ <53>, <53>, <53>, <53>,
+ <53>, <53>, <53>, <53>,
+ <53>, <53>, <53>, <53>,
+ <53>, <53>, <53>, <53>,
+ <53>, <53>, <53>, <53>;
+ ngpios=<32>;
+ gpio-line-names = "P8_PIN3_USER_LED_0", "P8_PIN4_USER_LED_1", "P8_PIN5_USER_LED_2",
+ "P8_PIN6_USER_LED_3", "P8_PIN7_USER_LED_4", "P8_PIN8_USER_LED_5",
+ "P8_PIN9_USER_LED_6", "P8_PIN10_USER_LED_7", "P8_PIN11_USER_LED_8",
+ "P8_PIN12_USER_LED_9", "P8_PIN13_USER_LED_10", "P8_PIN14_USER_LED_11",
+ "P8_PIN15", "P8_PIN16", "P8_PIN17", "P8_PIN18", "P8_PIN19", "P8_PIN20",
+ "P8_PIN21", "P8_PIN22", "P8_PIN23", "P8_PIN24", "P8_PIN25", "P8_PIN26",
+ "P8_PIN27", "P8_PIN28", "P8_PIN29", "P8_PIN30", "M2_W_DISABLE1",
+ "M2_W_DISABLE2", "VIO_ENABLE", "SD_DET";
+ status = "okay";
+
+ vio-enable-hog {
+ gpio-hog;
+ gpios = <30 30>;
+ output-high;
+ line-name = "VIO_ENABLE";
+ };
+
+ sd-det-hog {
+ gpio-hog;
+ gpios = <31 31>;
+ input;
+ line-name = "SD_DET";
+ };
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+
+ eeprom: eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
+
+ imx219: sensor@10 {
+ compatible = "sony,imx219";
+ reg = <0x10>;
+ clocks = <&imx219_clk>;
+ VANA-supply = <&imx219_vana>; /* 2.8v */
+ VDIG-supply = <&imx219_vdig>; /* 1.8v */
+ VDDL-supply = <&imx219_vddl>; /* 1.2v */
+
+ port {
+ imx219_0: endpoint {
+ data-lanes = <1 2>;
+ clock-noncontinuous;
+ link-frequencies = /bits/ 64 <456000000>;
+ };
+ };
+ };
+};
+
+&mac0 {
+ status = "okay";
+ phy-mode = "sgmii";
+ phy-handle = <&phy0>;
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+&mbox {
+ status = "okay";
+};
+
+&mmc {
+ bus-width = <4>;
+ disable-wp;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
+
+&mmuart0 {
+ status = "okay";
+};
+
+&mmuart1 {
+ status = "okay";
+};
+
+&refclk {
+ clock-frequency = <125000000>;
+};
+
+&refclk_ccc {
+ clock-frequency = <50000000>;
+};
+
+&rtc {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+};
+
+&spi1 {
+ status = "okay";
+};
+
+&syscontroller {
+ microchip,bitstream-flash = <&sys_ctrl_flash>;
+ status = "okay";
+};
+
+&syscontroller_qspi {
+ status = "okay";
+
+ sys_ctrl_flash: flash@0 { // MT25QL01GBBB8ESF-0SIT
+ compatible = "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <1>;
+ reg = <0>;
+ };
+};
+
+&usb {
+ status = "okay";
+ dr_mode = "otg";
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v1 4/5] dt-bindings: PCI: microchip: increase number of items in ranges property
From: Conor Dooley @ 2024-03-27 12:24 UTC (permalink / raw)
To: linux-riscv
Cc: conor, Conor Dooley, Daire McNamara, Jamie Gibbons,
Valentina Fernandez, Linus Walleij, Bartosz Golaszewski,
Rob Herring, Krzysztof Kozlowski, Lorenzo Pieralisi,
Krzysztof Wilczyński, Bjorn Helgaas, linux-gpio, devicetree,
linux-kernel, linux-pci
In-Reply-To: <20240327-parkway-dodgy-f0fe1fa20892@spud>
From: Valentina Fernandez <valentina.fernandezalanis@microchip.com>
Increase the number of items in the ranges property to allow up to 3
ranges. For example a prefetchable range, a non-prefetchable range
and an IO range, depending on configuration.
Signed-off-by: Valentina Fernandez <valentina.fernandezalanis@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml
index f7a3c2636355..e8212a05b7b1 100644
--- a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml
+++ b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml
@@ -65,7 +65,8 @@ properties:
- const: msi
ranges:
- maxItems: 1
+ minItems: 1
+ maxItems: 3
dma-ranges:
minItems: 1
--
2.43.0
^ permalink raw reply related
* [PATCH v1 3/5] dt-bindings: gpio: mpfs: allow gpio-line-names
From: Conor Dooley @ 2024-03-27 12:24 UTC (permalink / raw)
To: linux-riscv
Cc: conor, Conor Dooley, Daire McNamara, Jamie Gibbons,
Valentina Fernandez, Linus Walleij, Bartosz Golaszewski,
Rob Herring, Krzysztof Kozlowski, Lorenzo Pieralisi,
Krzysztof Wilczyński, Bjorn Helgaas, linux-gpio, devicetree,
linux-kernel, linux-pci
In-Reply-To: <20240327-parkway-dodgy-f0fe1fa20892@spud>
From: Jamie Gibbons <jamie.gibbons@microchip.com>
The BeagleV Fire devicetree will make use of gpio-line-names, allow it
in the binding.
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
index 6884dacb2865..d61569b3f15b 100644
--- a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
@@ -44,6 +44,7 @@ properties:
default: 32
gpio-controller: true
+ gpio-line-names: true
patternProperties:
"^.+-hog(-[0-9]+)?$":
--
2.43.0
^ permalink raw reply related
* [PATCH v1 2/5] dt-bindings: gpio: mpfs: add coreGPIO support
From: Conor Dooley @ 2024-03-27 12:24 UTC (permalink / raw)
To: linux-riscv
Cc: conor, Conor Dooley, Daire McNamara, Jamie Gibbons,
Valentina Fernandez, Linus Walleij, Bartosz Golaszewski,
Rob Herring, Krzysztof Kozlowski, Lorenzo Pieralisi,
Krzysztof Wilczyński, Bjorn Helgaas, linux-gpio, devicetree,
linux-kernel, linux-pci
In-Reply-To: <20240327-parkway-dodgy-f0fe1fa20892@spud>
From: Jamie Gibbons <jamie.gibbons@microchip.com>
The GPIO controllers on PolarFire SoC were based on the "soft" IP
CoreGPIO, but the inp/outp registers are at different offsets. Add
compatible to allow for support of both sets of offsets. The soft
core will not always have interrupts wired up, so only enforce them for
the "hard" core on PolarFire SoC.
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
.../bindings/gpio/microchip,mpfs-gpio.yaml | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
index d481e78958a7..6884dacb2865 100644
--- a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
@@ -14,6 +14,7 @@ properties:
items:
- enum:
- microchip,mpfs-gpio
+ - microchip,coregpio-rtl-v3
reg:
maxItems: 1
@@ -62,12 +63,21 @@ patternProperties:
- gpio-hog
- gpios
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: microchip,mpfs-gpio
+ then:
+ required:
+ - interrupts
+ - "#interrupt-cells"
+ - interrupt-controller
+
required:
- compatible
- reg
- - interrupts
- - "#interrupt-cells"
- - interrupt-controller
- "#gpio-cells"
- gpio-controller
- clocks
--
2.43.0
^ permalink raw reply related
* [PATCH v1 1/5] dt-bindings: riscv: microchip: document beaglev-fire
From: Conor Dooley @ 2024-03-27 12:24 UTC (permalink / raw)
To: linux-riscv
Cc: conor, Conor Dooley, Daire McNamara, Jamie Gibbons,
Valentina Fernandez, Linus Walleij, Bartosz Golaszewski,
Rob Herring, Krzysztof Kozlowski, Lorenzo Pieralisi,
Krzysztof Wilczyński, Bjorn Helgaas, linux-gpio, devicetree,
linux-kernel, linux-pci
In-Reply-To: <20240327-parkway-dodgy-f0fe1fa20892@spud>
From: Conor Dooley <conor.dooley@microchip.com>
The BeagleV Fire is a BeagleBone Black form-factor board with a
PolarFire SoC.
Link: https://www.beagleboard.org/boards/beaglev-fire
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
Documentation/devicetree/bindings/riscv/microchip.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/riscv/microchip.yaml b/Documentation/devicetree/bindings/riscv/microchip.yaml
index 4a29c890619a..78ce76ae1b6d 100644
--- a/Documentation/devicetree/bindings/riscv/microchip.yaml
+++ b/Documentation/devicetree/bindings/riscv/microchip.yaml
@@ -29,6 +29,7 @@ properties:
- enum:
- aldec,tysom-m-mpfs250t-rev2
- aries,m100pfsevp
+ - beagle,beaglev-fire
- microchip,mpfs-sev-kit
- sundance,polarberry
- const: microchip,mpfs
--
2.43.0
^ permalink raw reply related
* [PATCH v1 0/5] BeagleV Fire support
From: Conor Dooley @ 2024-03-27 12:24 UTC (permalink / raw)
To: linux-riscv
Cc: conor, Conor Dooley, Daire McNamara, Jamie Gibbons,
Valentina Fernandez, Linus Walleij, Bartosz Golaszewski,
Rob Herring, Krzysztof Kozlowski, Lorenzo Pieralisi,
Krzysztof Wilczyński, Bjorn Helgaas, linux-gpio, devicetree,
linux-kernel, linux-pci
From: Conor Dooley <conor.dooley@microchip.com>
Yo,
Wee series adding support for the BeagleV Fire. I've had a dts sitting
locally for this for over a year for testing Auto Update and I meant to
submit something to mainline once the board got announced publicly, but
only got around to that now.
The PCI controller has to stay disabled for now, the driver (and
binding) made an assumption about which of the two root port "instances"
would be used by Linux and the BeagleV Fire uses the other one. I've got
a WIP patch for that in the works and a patchset for the GPIO controller
that I have been trying to find some time to clean up and submit.
Thanks,
Conor.
CC: Conor Dooley <conor.dooley@microchip.com>
CC: Daire McNamara <daire.mcnamara@microchip.com>
CC: Jamie Gibbons <jamie.gibbons@microchip.com>
CC: Valentina Fernandez <valentina.fernandezalanis@microchip.com>
CC: Linus Walleij <linus.walleij@linaro.org>
CC: Bartosz Golaszewski <brgl@bgdev.pl>
CC: Rob Herring <robh@kernel.org>
CC: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
CC: Lorenzo Pieralisi <lpieralisi@kernel.org>
CC: "Krzysztof Wilczyński" <kw@linux.com>
CC: Bjorn Helgaas <bhelgaas@google.com>
CC: linux-riscv@lists.infradead.org
CC: linux-gpio@vger.kernel.org
CC: devicetree@vger.kernel.org
CC: linux-kernel@vger.kernel.org
CC: linux-pci@vger.kernel.org
Conor Dooley (2):
dt-bindings: riscv: microchip: document beaglev-fire
riscv: dts: microchip: add an initial devicetree for the BeagleV Fire
Jamie Gibbons (2):
dt-bindings: gpio: mpfs: add coreGPIO support
dt-bindings: gpio: mpfs: allow gpio-line-names
Valentina Fernandez (1):
dt-bindings: PCI: microchip: increase number of items in ranges
property
.../bindings/gpio/microchip,mpfs-gpio.yaml | 17 +-
.../bindings/pci/microchip,pcie-host.yaml | 3 +-
.../devicetree/bindings/riscv/microchip.yaml | 1 +
arch/riscv/boot/dts/microchip/Makefile | 1 +
.../microchip/mpfs-beaglev-fire-fabric.dtsi | 124 ++++++++++
.../boot/dts/microchip/mpfs-beaglev-fire.dts | 223 ++++++++++++++++++
6 files changed, 365 insertions(+), 4 deletions(-)
create mode 100644 arch/riscv/boot/dts/microchip/mpfs-beaglev-fire-fabric.dtsi
create mode 100644 arch/riscv/boot/dts/microchip/mpfs-beaglev-fire.dts
--
2.43.0
^ permalink raw reply
* Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support
From: Cristian Marussi @ 2024-03-27 12:20 UTC (permalink / raw)
To: Dan Carpenter
Cc: Peng Fan (OSS), Sudeep Holla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Linus Walleij, linux-arm-kernel, linux-kernel,
devicetree, linux-gpio, Peng Fan, Oleksii Moisieiev
In-Reply-To: <4879ad5d-165c-4118-81f7-8f6348a5a5d4@moroto.mountain>
On Wed, Mar 27, 2024 at 01:46:11PM +0300, Dan Carpenter wrote:
> Looks really nice. Just a few small comments below.
>
Hi,
I aa having a look at this today (and try to retest it), just a quick remark
down below...
> On Sat, Mar 23, 2024 at 08:15:16PM +0800, Peng Fan (OSS) wrote:
> > +
> > +struct scmi_msg_func_set {
> > + __le32 identifier;
> > + __le32 function_id;
> > + __le32 flags;
> > +};
>
> This scmi_msg_func_set struct is unused. Delete.
>
> > +static void
> > +iter_pinctrl_settings_get_prepare_message(void *message, u32 desc_index,
> > + const void *priv)
> > +{
> > + struct scmi_msg_settings_get *msg = message;
> > + const struct scmi_settings_get_ipriv *p = priv;
> > + u32 attributes;
> > +
> > + attributes = FIELD_PREP(CONFIG_FLAG_MASK, p->flag) |
> > + FIELD_PREP(SELECTOR_MASK, p->type);
> > +
> > + if (p->flag == 1)
> > + attributes |= FIELD_PREP(SKIP_CONFIGS_MASK, desc_index);
> > + else if (!p->flag)
>
> This is a nit-pick but could you change these !p->flag conditions to
> p->flag == 0? It's a number zero, not a bool.
>
> > + attributes |= FIELD_PREP(CONFIG_TYPE_MASK, p->config_types[0]);
> > +
> > + msg->attributes = cpu_to_le32(attributes);
> > + msg->identifier = cpu_to_le32(p->selector);
> > +}
> > +
> > +static int
> > +iter_pinctrl_settings_get_update_state(struct scmi_iterator_state *st,
> > + const void *response, void *priv)
> > +{
> > + const struct scmi_resp_settings_get *r = response;
> > + struct scmi_settings_get_ipriv *p = priv;
> > +
> > + if (p->flag == 1) {
> > + st->num_returned = le32_get_bits(r->num_configs, GENMASK(7, 0));
> > + st->num_remaining = le32_get_bits(r->num_configs,
> > + GENMASK(31, 24));
> > + } else {
> > + st->num_returned = 1;
> > + st->num_remaining = 0;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int
> > +iter_pinctrl_settings_get_process_response(const struct scmi_protocol_handle *ph,
> > + const void *response,
> > + struct scmi_iterator_state *st,
> > + void *priv)
> > +{
> > + const struct scmi_resp_settings_get *r = response;
> > + struct scmi_settings_get_ipriv *p = priv;
> > +
> > + if (!p->flag) {
>
>
> if (p->flag == 0) {
>
> > + if (p->config_types[0] !=
> > + le32_get_bits(r->configs[st->loop_idx * 2], GENMASK(7, 0)))
> > + return -EINVAL;
> > + } else if (p->flag == 1) {
> > + p->config_types[st->desc_index + st->loop_idx] =
> > + le32_get_bits(r->configs[st->loop_idx * 2],
> > + GENMASK(7, 0));
> > + } else if (p->flag == 2) {
> > + return 0;
> > + }
> > +
> > + p->config_values[st->desc_index + st->loop_idx] =
> > + le32_to_cpu(r->configs[st->loop_idx * 2 + 1]);
> > +
> > + return 0;
> > +}
> > +
> > +static int
> > +scmi_pinctrl_settings_get(const struct scmi_protocol_handle *ph, u32 selector,
> > + enum scmi_pinctrl_selector_type type,
> > + enum scmi_pinctrl_conf_type config_type,
> > + u32 *config_value)
> > +{
> > + int ret;
> > + void *iter;
> > + struct scmi_iterator_ops ops = {
> > + .prepare_message = iter_pinctrl_settings_get_prepare_message,
> > + .update_state = iter_pinctrl_settings_get_update_state,
> > + .process_response = iter_pinctrl_settings_get_process_response,
> > + };
> > + struct scmi_settings_get_ipriv ipriv = {
> > + .selector = selector,
> > + .type = type,
> > + .flag = 0,
>
> ->flag should be 0-2.
>
The .flag in this priv structure is for 'configuring' the iterators in
the SCMI core to parse a multi-part response, so (looking at how the
iterators functs are implemented above) setting it here to zero
means issuing a SETTINGS_GET with attributes.config_flag[19:18] == 0,
that in turn means requesting just a single config_value to be read...
...if you want to support the other 'flavours' of SETTINGS_GET
(multiple configs & selected_func) you will have to extend the signature
of this function to optionally select to readback multiple configs (and to
allow the return of such multiple config_values) and/or optionally request
to return the selected function....
...or maybe add distinct wrapper protocol_ops just for these flavours...
Anyway, till now in this series it was avoided to add such 'flavours'
support (e.g. for multiple configs) since there are no users for the
multi-config and function selected in the pinctrl driver...so no way to test..
Will the Linux GPIO driver need these ? Should we delay anyway the
addition of the support of such variants of SETTING_GET for when a real
user like GPIO driveer appears ?
...anyway @Peng please add a comment somewhere explaining how p->flag is
used to configure the type of SETTINGS_GET
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v3 6/8] cpufreq: sun50i: Add H616 support
From: Andre Przywara @ 2024-03-27 12:16 UTC (permalink / raw)
To: Sudeep Holla
Cc: Samuel Holland, linux-pm, devicetree, linux-sunxi,
linux-arm-kernel, Brandon Cheo Fusi, Martin Botka, Martin Botka,
Chris Morgan, Ryan Walklin, Mark Rutland, Lorenzo Pieralisi,
Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Rafael J . Wysocki
In-Reply-To: <ZgQJ1N3-JeSFwZJb@bogus>
On Wed, 27 Mar 2024 11:58:12 +0000
Sudeep Holla <sudeep.holla@arm.com> wrote:
Hi Sudeep,
> On Wed, Mar 27, 2024 at 11:46:08AM +0000, Andre Przywara wrote:
> > On Tue, 26 Mar 2024 22:46:27 -0500
> > Samuel Holland <samuel@sholland.org> wrote:
> >
> > Hi Samuel,
> >
> > > On 3/26/24 06:47, Andre Przywara wrote:
> > > > From: Martin Botka <martin.botka@somainline.org>
> > > >
> > > > The Allwinner H616/H618 SoCs have different OPP tables per SoC version
> > > > and die revision. The SoC version is stored in NVMEM, as before, though
> > > > encoded differently. The die revision is in a different register, in the
> > > > SRAM controller. Firmware already exports that value in a standardised
> > > > way, through the SMCCC SoCID mechanism. We need both values, as some chips
> > > > have the same SoC version, but they don't support the same frequencies and
> > > > they get differentiated by the die revision.
> > > >
> > > > Add the new compatible string and tie the new translation function to
> > > > it. This mechanism not only covers the original H616 SoC, but also its
> > > > very close sibling SoCs H618 and H700, so add them to the list as well.
> > > >
> > > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
> > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > > ---
> > > > drivers/cpufreq/sun50i-cpufreq-nvmem.c | 61 ++++++++++++++++++++++++++
> > > > 1 file changed, 61 insertions(+)
> > > >
> > > > diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > > index bd170611c7906..f9e9fc340f848 100644
> > > > --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > > +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > > @@ -10,6 +10,7 @@
> > > >
> > > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > >
> > > > +#include <linux/arm-smccc.h>
> > > > #include <linux/cpu.h>
> > > > #include <linux/module.h>
> > > > #include <linux/nvmem-consumer.h>
> > > > @@ -46,14 +47,71 @@ static u32 sun50i_h6_efuse_xlate(u32 speedbin)
> > > > return 0;
> > > > }
> > > >
> > > > +/*
> > > > + * Judging by the OPP tables in the vendor BSP, the quality order of the
> > > > + * returned speedbin index is 4 -> 0/2 -> 3 -> 1, from worst to best.
> > > > + * 0 and 2 seem identical from the OPP tables' point of view.
> > > > + */
> > > > +static u32 sun50i_h616_efuse_xlate(u32 speedbin)
> > > > +{
> > > > + int ver_bits = arm_smccc_get_soc_id_revision();
> > >
> > > This needs a Kconfig dependency on ARM_SMCCC_SOC_ID.
> >
> > That was my first impulse as well, but it's actually not true:
> > ARM_SMCCC_SOC_ID just protects the sysfs export code, not this function
> > here. That does just depend on HAVE_ARM_SMCCC_DISCOVERY, which gets
> > selected by ARM_GIC_V3, which gets selected by CONFIG_ARM64. So the
> > arm64 kernel is safe.
>
> It is safe to add the dependency explicitly so that if GICV3 decides to drop
> it, this won't be affected. Thoughts ?
That would be one possibility, but since there are patches on the
list[1] that use this driver for the Allwinner D1 with RISC-V cores,
this would need to be revisited then anyway.
> > Now apart from ARM(32) (where the situation seems a bit more complex) I
> > just realise that this would torpedo Brandon's D1 efforts, so I need to
> > add this change I played with to provide an alternative:
> >
> > static int get_soc_id_revision(void)
> > {
> > #ifdef CONFIG_HAVE_ARM_SMCCC_DISCOVERY
> > return arm_smccc_get_soc_id_revision();
> > #else
> > /* Return the value for the worse die revision, to be safe. */
> > return 2;
> > #endif
> > }
> >
> > Does that look acceptable, despite the #ifdef?
> >
>
> if(IS_ENABLED(CONFIG_HAVE_ARM_SMCCC_DISCOVERY)) instead ?
Well, but this would rely on at least the prototype to be visible,
right? And then on the toolchain to optimise away the call, so that the
symbol doesn't even appear in the object file?
So would this work for the RISC-V case?
Cheers,
Andre
[1]
https://lore.kernel.org/linux-sunxi/20231218110543.64044-1-fusibrandon13@gmail.com/T/#t
^ permalink raw reply
* Re: [PATCH v4 3/4] dt-bindings: interconnect: add clock property to enable QOS on SC7280
From: Krzysztof Kozlowski @ 2024-03-27 12:14 UTC (permalink / raw)
To: Odelu Kukatla, Bjorn Andersson, Konrad Dybcio, Georgi Djakov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Kees Cook, cros-qcom-dts-watchers, Gustavo A . R . Silva,
linux-arm-msm, linux-pm, devicetree, linux-kernel,
linux-hardening, quic_rlaggysh, quic_mdtipton
In-Reply-To: <e95634ba-b186-4fee-b93b-1ac4662fd2c4@quicinc.com>
On 27/03/2024 12:35, Odelu Kukatla wrote:
>>> maxItems: 1
>>>
>>> + clocks:
>>> + minItems: 1
>>> + maxItems: 2
>>
>> Why is this flexible? Nothing in commit msg explains that. I gave the
>> same talk twice, gave there examples, yet it is not enough...
>>
>
> Clocks property is optional, and can be either 1 or 2 or none.
> I think "minItems: 1" should be removed. If no clock property is mentioned in node that means no clock is required to be enabled for QoS configuration.
>
> I will add back specific number of clocks based on interconnect compatible similar to what i did in v3.
Just be sure you read the example I gave you.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 6/8] cpufreq: sun50i: Add H616 support
From: Sudeep Holla @ 2024-03-27 12:01 UTC (permalink / raw)
To: Andre Przywara
Cc: Samuel Holland, linux-pm, devicetree, linux-sunxi,
linux-arm-kernel, Sudeep Holla, Brandon Cheo Fusi, Martin Botka,
Martin Botka, Chris Morgan, Ryan Walklin, Mark Rutland,
Lorenzo Pieralisi, Yangtao Li, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Rafael J . Wysocki
In-Reply-To: <ZgQJ1N3-JeSFwZJb@bogus>
On Wed, Mar 27, 2024 at 11:58:12AM +0000, Sudeep Holla wrote:
> On Wed, Mar 27, 2024 at 11:46:08AM +0000, Andre Przywara wrote:
> > On Tue, 26 Mar 2024 22:46:27 -0500
> > Samuel Holland <samuel@sholland.org> wrote:
> >
> > Hi Samuel,
> >
> > > On 3/26/24 06:47, Andre Przywara wrote:
> > > > From: Martin Botka <martin.botka@somainline.org>
> > > >
> > > > The Allwinner H616/H618 SoCs have different OPP tables per SoC version
> > > > and die revision. The SoC version is stored in NVMEM, as before, though
> > > > encoded differently. The die revision is in a different register, in the
> > > > SRAM controller. Firmware already exports that value in a standardised
> > > > way, through the SMCCC SoCID mechanism. We need both values, as some chips
> > > > have the same SoC version, but they don't support the same frequencies and
> > > > they get differentiated by the die revision.
> > > >
> > > > Add the new compatible string and tie the new translation function to
> > > > it. This mechanism not only covers the original H616 SoC, but also its
> > > > very close sibling SoCs H618 and H700, so add them to the list as well.
> > > >
> > > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
> > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > > ---
> > > > drivers/cpufreq/sun50i-cpufreq-nvmem.c | 61 ++++++++++++++++++++++++++
> > > > 1 file changed, 61 insertions(+)
> > > >
> > > > diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > > index bd170611c7906..f9e9fc340f848 100644
> > > > --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > > +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > > @@ -10,6 +10,7 @@
> > > >
> > > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > >
> > > > +#include <linux/arm-smccc.h>
> > > > #include <linux/cpu.h>
> > > > #include <linux/module.h>
> > > > #include <linux/nvmem-consumer.h>
> > > > @@ -46,14 +47,71 @@ static u32 sun50i_h6_efuse_xlate(u32 speedbin)
> > > > return 0;
> > > > }
> > > >
> > > > +/*
> > > > + * Judging by the OPP tables in the vendor BSP, the quality order of the
> > > > + * returned speedbin index is 4 -> 0/2 -> 3 -> 1, from worst to best.
> > > > + * 0 and 2 seem identical from the OPP tables' point of view.
> > > > + */
> > > > +static u32 sun50i_h616_efuse_xlate(u32 speedbin)
> > > > +{
> > > > + int ver_bits = arm_smccc_get_soc_id_revision();
> > >
> > > This needs a Kconfig dependency on ARM_SMCCC_SOC_ID.
> >
> > That was my first impulse as well, but it's actually not true:
> > ARM_SMCCC_SOC_ID just protects the sysfs export code, not this function
> > here. That does just depend on HAVE_ARM_SMCCC_DISCOVERY, which gets
> > selected by ARM_GIC_V3, which gets selected by CONFIG_ARM64. So the
> > arm64 kernel is safe.
>
> It is safe to add the dependency explicitly so that if GICV3 decides to drop
> it, this won't be affected. Thoughts ?
Ignore this as this will block the ARM(32) build of the driver which I suppose
is needed as well.
--
Regards,
Sudeep
^ permalink raw reply
* RE: [RFC PATCH 1/6] dt-bindings: pinctrl: starfive: add JH8100 pinctrl bindings
From: Yuklin Soo @ 2024-03-27 11:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, Linus Walleij, Bartosz Golaszewski, Hal Feng,
Leyfoon Tan, Jianlong Huang, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Drew Fustini
Cc: linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
Paul Walmsley, Palmer Dabbelt, Albert Ou
In-Reply-To: <58a62c7b-3348-4252-91be-ec30d5b723b6@linaro.org>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Tuesday, March 5, 2024 10:07 PM
> To: Yuklin Soo <yuklin.soo@starfivetech.com>; Linus Walleij
> <linus.walleij@linaro.org>; Bartosz Golaszewski
> <bartosz.golaszewski@linaro.org>; Hal Feng <hal.feng@starfivetech.com>;
> Leyfoon Tan <leyfoon.tan@starfivetech.com>; Jianlong Huang
> <jianlong.huang@starfivetech.com>; Emil Renner Berthing <kernel@esmil.dk>;
> Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley <conor+dt@kernel.org>;
> Drew Fustini <drew@beagleboard.org>
> Cc: linux-gpio@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicetree@vger.kernel.org; linux-riscv@lists.infradead.org; Paul Walmsley
> <paul.walmsley@sifive.com>; Palmer Dabbelt <palmer@dabbelt.com>; Albert
> Ou <aou@eecs.berkeley.edu>
> Subject: Re: [RFC PATCH 1/6] dt-bindings: pinctrl: starfive: add JH8100 pinctrl
> bindings
>
> On 05/03/2024 13:00, Yuklin Soo wrote:
> >
> >
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> >> Sent: Tuesday, February 20, 2024 4:10 PM
> >> To: Yuklin Soo <yuklin.soo@starfivetech.com>; Linus Walleij
> >> <linus.walleij@linaro.org>; Bartosz Golaszewski
> >> <bartosz.golaszewski@linaro.org>; Hal Feng
> >> <hal.feng@starfivetech.com>; Leyfoon Tan
> >> <leyfoon.tan@starfivetech.com>; Jianlong Huang
> >> <jianlong.huang@starfivetech.com>; Emil Renner Berthing
> >> <kernel@esmil.dk>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> >> <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley
> >> <conor+dt@kernel.org>; Drew Fustini <drew@beagleboard.org>
> >> Cc: linux-gpio@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> devicetree@vger.kernel.org; linux-riscv@lists.infradead.org; Paul
> >> Walmsley <paul.walmsley@sifive.com>; Palmer Dabbelt
> >> <palmer@dabbelt.com>; Albert Ou <aou@eecs.berkeley.edu>
> >> Subject: Re: [RFC PATCH 1/6] dt-bindings: pinctrl: starfive: add
> >> JH8100 pinctrl bindings
> >>
> >> On 07/02/2024 03:42, Yuklin Soo wrote:
> >>>>
> >>>>> + type: object
> >>>>> + additionalProperties: false
> >>>>> + patternProperties:
> >>>>> + '-pins$':
> >>>>> + type: object
> >>>>> + description: |
> >>>>> + A pinctrl node should contain at least one subnode
> >>>>> + representing
> >> the
> >>>>> + pinctrl groups available in the domain. Each subnode will list the
> >>>>> + pins it needs, and how they should be configured, with regard to
> >>>>> + muxer configuration, bias, input enable/disable, input schmitt
> >>>>> + trigger enable/disable, slew-rate and drive strength.
> >>>>> + allOf:
> >>>>> + - $ref: /schemas/pinctrl/pincfg-node.yaml
> >>>>> + - $ref: /schemas/pinctrl/pinmux-node.yaml
> >>>>> + additionalProperties: false
> >>>>
> >>>> Why the rest of the properties is not applicable?
> >>>
> >>> The regex “-pins$” make sure all client subnode names end with
> >>> suffix “-pins” (e.g, i2c0-scl-pins, i2c-sda-pins)
> >>
> >> I did not talk about subnodes.
> >>
> >> I asked why the rest of pincfg and pinmux schema properties are not
> allowed.
> >
> > Initially, I wanted to allow all properties in the pincfg and pinmux schema. I
> misunderstood the meaning of “additionalProperties: false”
> > and I thought it means all additional properties outside the pincfg
> > and pinmux schema are excluded. The “additionalProperties” will be set
> > to “true” to include the rest of the properties in pincfg and pinmux
> > schema and not to be restricted to only the properties defined in
>
> In that case drop all the properties and use unevaluatedProperties: false.
Isn’t that sufficient just to use “unevaluatedProperties: false” ?
To drop all the properties, we will be losing information below:
drive-strength-microamp:
enum: [ 2000, 4000, 8000, 12000 ]
slew-rate:
enum: [ 0, 1 ]
default: 0
description: |
0: slow (half frequency)
1: fast
>
> Fix your email setup, to wrap emails properly. This is unreadable.
>
> >
> >>
> >> Best regards,
> >> Krzysztof
> >
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v3 6/8] cpufreq: sun50i: Add H616 support
From: Sudeep Holla @ 2024-03-27 11:58 UTC (permalink / raw)
To: Andre Przywara
Cc: Samuel Holland, linux-pm, devicetree, linux-sunxi,
linux-arm-kernel, Sudeep Holla, Brandon Cheo Fusi, Martin Botka,
Martin Botka, Chris Morgan, Ryan Walklin, Mark Rutland,
Lorenzo Pieralisi, Yangtao Li, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Rafael J . Wysocki
In-Reply-To: <20240327114608.2ffca28e@minigeek.lan>
On Wed, Mar 27, 2024 at 11:46:08AM +0000, Andre Przywara wrote:
> On Tue, 26 Mar 2024 22:46:27 -0500
> Samuel Holland <samuel@sholland.org> wrote:
>
> Hi Samuel,
>
> > On 3/26/24 06:47, Andre Przywara wrote:
> > > From: Martin Botka <martin.botka@somainline.org>
> > >
> > > The Allwinner H616/H618 SoCs have different OPP tables per SoC version
> > > and die revision. The SoC version is stored in NVMEM, as before, though
> > > encoded differently. The die revision is in a different register, in the
> > > SRAM controller. Firmware already exports that value in a standardised
> > > way, through the SMCCC SoCID mechanism. We need both values, as some chips
> > > have the same SoC version, but they don't support the same frequencies and
> > > they get differentiated by the die revision.
> > >
> > > Add the new compatible string and tie the new translation function to
> > > it. This mechanism not only covers the original H616 SoC, but also its
> > > very close sibling SoCs H618 and H700, so add them to the list as well.
> > >
> > > Signed-off-by: Martin Botka <martin.botka@somainline.org>
> > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > ---
> > > drivers/cpufreq/sun50i-cpufreq-nvmem.c | 61 ++++++++++++++++++++++++++
> > > 1 file changed, 61 insertions(+)
> > >
> > > diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > index bd170611c7906..f9e9fc340f848 100644
> > > --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > @@ -10,6 +10,7 @@
> > >
> > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > >
> > > +#include <linux/arm-smccc.h>
> > > #include <linux/cpu.h>
> > > #include <linux/module.h>
> > > #include <linux/nvmem-consumer.h>
> > > @@ -46,14 +47,71 @@ static u32 sun50i_h6_efuse_xlate(u32 speedbin)
> > > return 0;
> > > }
> > >
> > > +/*
> > > + * Judging by the OPP tables in the vendor BSP, the quality order of the
> > > + * returned speedbin index is 4 -> 0/2 -> 3 -> 1, from worst to best.
> > > + * 0 and 2 seem identical from the OPP tables' point of view.
> > > + */
> > > +static u32 sun50i_h616_efuse_xlate(u32 speedbin)
> > > +{
> > > + int ver_bits = arm_smccc_get_soc_id_revision();
> >
> > This needs a Kconfig dependency on ARM_SMCCC_SOC_ID.
>
> That was my first impulse as well, but it's actually not true:
> ARM_SMCCC_SOC_ID just protects the sysfs export code, not this function
> here. That does just depend on HAVE_ARM_SMCCC_DISCOVERY, which gets
> selected by ARM_GIC_V3, which gets selected by CONFIG_ARM64. So the
> arm64 kernel is safe.
It is safe to add the dependency explicitly so that if GICV3 decides to drop
it, this won't be affected. Thoughts ?
> Now apart from ARM(32) (where the situation seems a bit more complex) I
> just realise that this would torpedo Brandon's D1 efforts, so I need to
> add this change I played with to provide an alternative:
>
> static int get_soc_id_revision(void)
> {
> #ifdef CONFIG_HAVE_ARM_SMCCC_DISCOVERY
> return arm_smccc_get_soc_id_revision();
> #else
> /* Return the value for the worse die revision, to be safe. */
> return 2;
> #endif
> }
>
> Does that look acceptable, despite the #ifdef?
>
if(IS_ENABLED(CONFIG_HAVE_ARM_SMCCC_DISCOVERY)) instead ?
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Alexandre Mergnat @ 2024-03-27 11:55 UTC (permalink / raw)
To: Krzysztof Kozlowski, Yu-chang Lee (李禹璋)
Cc: MandyJH Liu (劉人僖), conor+dt@kernel.org,
robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
matthias.bgg@gmail.com, ulf.hansson@linaro.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group,
Xiufeng Li (李秀峰),
linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡),
angelogioacchino.delregno@collabora.com
In-Reply-To: <c59f2f33-ad6b-469d-96be-9345920370b4@linaro.org>
Hello Yu-chang Lee,
SMI LARB must have a power domain, according to "mediatek,smi-larb.yaml"
Now you try to create a link from power domain to larb.
Here is my understanding: when you enable/disable power domain, the
larb linked to this power domain may have an issue. Then you want to
retrieve de LARB linked to the power domain though the dts to manage
the LARB. IMHO, using the dts to have this information into the power
driver isn't necessary and may introduce some bugs if the LARB node
and power node in the DTS aren't aligned.
It seems not implemented today but during the LARB probe, it should
"subscribe" to the linked power domain. Then, when the power domain
status is changing, it is able to "notify" (callback) the LARB, then
implement the good stuff to handle this power domain status change
into LARB driver.
Regards,
Alexandre
On Wed, Mar 27, 2024 at 12:04 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 27/03/2024 11:56, Yu-chang Lee (李禹璋) wrote:
> > On Wed, 2024-03-27 at 11:43 +0100, Krzysztof Kozlowski wrote:
> >>
> >> External email : Please do not click links or open attachments until
> >> you have verified the sender or the content.
> >> On 27/03/2024 11:39, Yu-chang Lee (李禹璋) wrote:
> >>>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I will double check the format of yaml for the next version,
> >> sorry
> >>>> for
> >>>>> inconvenience. But I did test it on mt8188 chromebook, the reason
> >>>> why
> >>>>
> >>>> How do you test a binding on chromebook?
> >>>>
> >>>>> power domain need larb node is that when mtcmos power on, signal
> >>>> glitch
> >>>>> may produce. Power domain driver must reset larb when this happen
> >>>> to
> >>>>> prevent dummy transaction on bus. That why I need larb node in
> >> dts.
> >>>>
> >>>> No one talks here about larb node...
> >>>
> >>> Sorry, May you elaborate on what information I need to provide to
> >> you
> >>> or it is just a syntax problem I need to fix?
> >>
> >> Please explain the purpose of this property (how is it going to be
> >> used by drivers)and what does it represent.
> >>
> >
> > It represent SMI LARB(Local ARBitration). In power domain driver when
> > power on power domain, It need to reset LARB to prevent potential power
> > glitch which may cause dummy transaction on bus. Without taking care of
> > this issue it often leads to camera hang in stress test.
>
> That sounds rather like missing resets... or something else connecting
> these devices. Maybe the explanation is just imprecise...
>
> Best regards,
> Krzysztof
>
>
^ permalink raw reply
* Re: [PATCH v3 6/8] cpufreq: sun50i: Add H616 support
From: Andre Przywara @ 2024-03-27 11:46 UTC (permalink / raw)
To: Samuel Holland
Cc: 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,
Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Rafael J . Wysocki
In-Reply-To: <65e86555-761e-4e26-8778-e2452876b5e4@sholland.org>
On Tue, 26 Mar 2024 22:46:27 -0500
Samuel Holland <samuel@sholland.org> wrote:
Hi Samuel,
> On 3/26/24 06:47, Andre Przywara wrote:
> > From: Martin Botka <martin.botka@somainline.org>
> >
> > The Allwinner H616/H618 SoCs have different OPP tables per SoC version
> > and die revision. The SoC version is stored in NVMEM, as before, though
> > encoded differently. The die revision is in a different register, in the
> > SRAM controller. Firmware already exports that value in a standardised
> > way, through the SMCCC SoCID mechanism. We need both values, as some chips
> > have the same SoC version, but they don't support the same frequencies and
> > they get differentiated by the die revision.
> >
> > Add the new compatible string and tie the new translation function to
> > it. This mechanism not only covers the original H616 SoC, but also its
> > very close sibling SoCs H618 and H700, so add them to the list as well.
> >
> > Signed-off-by: Martin Botka <martin.botka@somainline.org>
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > drivers/cpufreq/sun50i-cpufreq-nvmem.c | 61 ++++++++++++++++++++++++++
> > 1 file changed, 61 insertions(+)
> >
> > diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > index bd170611c7906..f9e9fc340f848 100644
> > --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > @@ -10,6 +10,7 @@
> >
> > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >
> > +#include <linux/arm-smccc.h>
> > #include <linux/cpu.h>
> > #include <linux/module.h>
> > #include <linux/nvmem-consumer.h>
> > @@ -46,14 +47,71 @@ static u32 sun50i_h6_efuse_xlate(u32 speedbin)
> > return 0;
> > }
> >
> > +/*
> > + * Judging by the OPP tables in the vendor BSP, the quality order of the
> > + * returned speedbin index is 4 -> 0/2 -> 3 -> 1, from worst to best.
> > + * 0 and 2 seem identical from the OPP tables' point of view.
> > + */
> > +static u32 sun50i_h616_efuse_xlate(u32 speedbin)
> > +{
> > + int ver_bits = arm_smccc_get_soc_id_revision();
>
> This needs a Kconfig dependency on ARM_SMCCC_SOC_ID.
That was my first impulse as well, but it's actually not true:
ARM_SMCCC_SOC_ID just protects the sysfs export code, not this function
here. That does just depend on HAVE_ARM_SMCCC_DISCOVERY, which gets
selected by ARM_GIC_V3, which gets selected by CONFIG_ARM64. So the
arm64 kernel is safe.
Now apart from ARM(32) (where the situation seems a bit more complex) I
just realise that this would torpedo Brandon's D1 efforts, so I need to
add this change I played with to provide an alternative:
static int get_soc_id_revision(void)
{
#ifdef CONFIG_HAVE_ARM_SMCCC_DISCOVERY
return arm_smccc_get_soc_id_revision();
#else
/* Return the value for the worse die revision, to be safe. */
return 2;
#endif
}
Does that look acceptable, despite the #ifdef?
Cheers,
Andre
>
> Regards,
> Samuel
>
> > + u32 value = 0;
> > +
> > + switch (speedbin & 0xffff) {
> > + case 0x2000:
> > + value = 0;
> > + break;
> > + case 0x2400:
> > + case 0x7400:
> > + case 0x2c00:
> > + case 0x7c00:
> > + if (ver_bits != SMCCC_RET_NOT_SUPPORTED &&
> > ver_bits <= 1) {
> > + /* ic version A/B */
> > + value = 1;
> > + } else {
> > + /* ic version C and later version */
> > + value = 2;
> > + }
> > + break;
> > + case 0x5000:
> > + case 0x5400:
> > + case 0x6000:
> > + value = 3;
> > + break;
> > + case 0x5c00:
> > + value = 4;
> > + break;
> > + case 0x5d00:
> > + value = 0;
> > + break;
> > + case 0x6c00:
> > + value = 5;
> > + break;
> > + default:
> > + pr_warn("sun50i-cpufreq-nvmem: unknown speed bin
> > 0x%x, using default bin 0\n",
> > + speedbin & 0xffff);
> > + value = 0;
> > + break;
> > + }
> > +
> > + return value;
> > +}
> > +
> > static struct sunxi_cpufreq_data sun50i_h6_cpufreq_data = {
> > .efuse_xlate = sun50i_h6_efuse_xlate,
> > };
> >
> > +static struct sunxi_cpufreq_data sun50i_h616_cpufreq_data = {
> > + .efuse_xlate = sun50i_h616_efuse_xlate,
> > +};
> > +
> > static const struct of_device_id cpu_opp_match_list[] = {
> > { .compatible = "allwinner,sun50i-h6-operating-points",
> > .data = &sun50i_h6_cpufreq_data,
> > },
> > + { .compatible = "allwinner,sun50i-h616-operating-points",
> > + .data = &sun50i_h616_cpufreq_data,
> > + },
> > {}
> > };
> >
> > @@ -230,6 +288,9 @@ static struct platform_driver
> > sun50i_cpufreq_driver = {
> > static const struct of_device_id sun50i_cpufreq_match_list[] = {
> > { .compatible = "allwinner,sun50i-h6" },
> > + { .compatible = "allwinner,sun50i-h616" },
> > + { .compatible = "allwinner,sun50i-h618" },
> > + { .compatible = "allwinner,sun50i-h700" },
> > {}
> > };
> > MODULE_DEVICE_TABLE(of, sun50i_cpufreq_match_list);
>
>
^ permalink raw reply
* Re: [PATCH v4 1/4] interconnect: qcom: icc-rpmh: Add QoS configuration support
From: Odelu Kukatla @ 2024-03-27 11:42 UTC (permalink / raw)
To: Krzysztof Kozlowski, Konrad Dybcio, Bjorn Andersson,
Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Kees Cook, cros-qcom-dts-watchers, Gustavo A . R . Silva,
linux-arm-msm, linux-pm, devicetree, linux-kernel,
linux-hardening, quic_rlaggysh, quic_mdtipton
In-Reply-To: <73e5a697-2eb4-45d3-84eb-60401ea10cc1@linaro.org>
On 3/27/2024 2:14 PM, Krzysztof Kozlowski wrote:
> On 26/03/2024 21:56, Konrad Dybcio wrote:
>> On 25.03.2024 7:16 PM, Odelu Kukatla wrote:
>>> It adds QoS support for QNOC device and includes support for
>>> configuring priority, priority forward disable, urgency forwarding.
>>> This helps in priortizing the traffic originating from different
>>> interconnect masters at NoC(Network On Chip).
>>>
>>> Signed-off-by: Odelu Kukatla <quic_okukatla@quicinc.com>
>>> ---
>>
>> [...]
>>
>>>
>>> + if (desc->config) {
>>> + struct resource *res;
>>> + void __iomem *base;
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + if (!res)
>>> + goto skip_qos_config;
>>> +
>>> + base = devm_ioremap_resource(dev, res);
>>
>> You were asked to substitute this call like 3 times already..
>>
>> devm_platform_get_and_ioremap_resource
>>
>> or even better, devm_platform_ioremap_resource
>
> Yeah, I wonder what else from my feedback got ignored :(
>
There was a misinterpretation of your comment from my side. Got it now, I will address this.
>
> Best regards,
> Krzysztof
>
Thanks,
Odelu
^ permalink raw reply
* Re: [PATCH v4 3/4] dt-bindings: interconnect: add clock property to enable QOS on SC7280
From: Odelu Kukatla @ 2024-03-27 11:35 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio,
Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Kees Cook, cros-qcom-dts-watchers, Gustavo A . R . Silva,
linux-arm-msm, linux-pm, devicetree, linux-kernel,
linux-hardening, quic_rlaggysh, quic_mdtipton
In-Reply-To: <a259fa95-bfc3-4959-a159-8683df473e66@linaro.org>
On 3/26/2024 1:00 PM, Krzysztof Kozlowski wrote:
> On 25/03/2024 19:16, Odelu Kukatla wrote:
>> Added clock property to enable clocks required for accessing
>> qos registers.
>>
>> Signed-off-by: Odelu Kukatla <quic_okukatla@quicinc.com>
>> ---
>> .../bindings/interconnect/qcom,sc7280-rpmh.yaml | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
>> index b135597d9489..950ecdd5252e 100644
>> --- a/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
>> @@ -35,6 +35,10 @@ properties:
>> reg:
>> maxItems: 1
>>
>> + clocks:
>> + minItems: 1
>> + maxItems: 2
>
> Why is this flexible? Nothing in commit msg explains that. I gave the
> same talk twice, gave there examples, yet it is not enough...
>
Clocks property is optional, and can be either 1 or 2 or none.
I think "minItems: 1" should be removed. If no clock property is mentioned in node that means no clock is required to be enabled for QoS configuration.
I will add back specific number of clocks based on interconnect compatible similar to what i did in v3.
> https://elixir.bootlin.com/linux/v6.8/source/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml#L132
>
>> +
>> required:
>> - compatible
>>
>> @@ -57,6 +61,7 @@ unevaluatedProperties: false
>>
>> examples:
>> - |
>> + #include <dt-bindings/clock/qcom,gcc-sc7280.h>
>> interconnect {
>> compatible = "qcom,sc7280-clk-virt";
>> #interconnect-cells = <2>;
>> @@ -69,3 +74,12 @@ examples:
>> #interconnect-cells = <2>;
>> qcom,bcm-voters = <&apps_bcm_voter>;
>
> If all devices have clocks, then you could add them here. It seems not
> all of them have clocks...
>
> Best regards,
> Krzysztof
>
Thanks,
Odelu
^ permalink raw reply
* Re: [PATCH v12 2/5] dt-bindings: clock: sophgo: add RP gate clocks for SG2042
From: Chen Wang @ 2024-03-27 11:32 UTC (permalink / raw)
To: Chen Wang, aou, chao.wei, conor, krzysztof.kozlowski+dt,
mturquette, palmer, paul.walmsley, richardcochran, robh+dt, sboyd,
devicetree, linux-clk, linux-kernel, linux-riscv, haijiao.liu,
xiaoguang.xing, guoren, jszhang, inochiama, samuel.holland
Cc: Rob Herring
In-Reply-To: <78ddd5b127860e110f4c782de90025153cdba083.1711527932.git.unicorn_wang@outlook.com>
hi, Stephen,
I updated the address in the example of this bindings as per your input
from
https://lore.kernel.org/linux-riscv/066c6fa4b537561ae6b20388a5497d9e.sboyd@kernel.org/.
I checked the
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/log/?h=clk-next
and seems you have not picked the 3 bindings patches, so please use v12
when you pick them.
Thanks, Chen
On 2024/3/27 16:30, Chen Wang wrote:
> From: Chen Wang <unicorn_wang@outlook.com>
>
> Add bindings for the gate clocks of RP subsystem for Sophgo SG2042.
>
> Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/clock/sophgo,sg2042-rpgate.yaml | 43 ++++++++++++++
> .../dt-bindings/clock/sophgo,sg2042-rpgate.h | 58 +++++++++++++++++++
> 2 files changed, 101 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/sophgo,sg2042-rpgate.yaml
> create mode 100644 include/dt-bindings/clock/sophgo,sg2042-rpgate.h
>
> diff --git a/Documentation/devicetree/bindings/clock/sophgo,sg2042-rpgate.yaml b/Documentation/devicetree/bindings/clock/sophgo,sg2042-rpgate.yaml
> new file mode 100644
> index 000000000000..9a58038b3182
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/sophgo,sg2042-rpgate.yaml
> @@ -0,0 +1,43 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/sophgo,sg2042-rpgate.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Sophgo SG2042 Gate Clock Generator for RP(riscv processors) subsystem
> +
> +maintainers:
> + - Chen Wang <unicorn_wang@outlook.com>
> +
> +properties:
> + compatible:
> + const: sophgo,sg2042-rpgate
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: Gate clock for RP subsystem
> +
> + '#clock-cells':
> + const: 1
> + description:
> + See <dt-bindings/clock/sophgo,sg2042-rpgate.h> for valid indices.
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - '#clock-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + clock-controller@20000000 {
> + compatible = "sophgo,sg2042-rpgate";
> + reg = <0x20000000 0x10000>;
> + clocks = <&clkgen 85>;
> + #clock-cells = <1>;
> + };
> diff --git a/include/dt-bindings/clock/sophgo,sg2042-rpgate.h b/include/dt-bindings/clock/sophgo,sg2042-rpgate.h
> new file mode 100644
> index 000000000000..8b4522d5f559
> --- /dev/null
> +++ b/include/dt-bindings/clock/sophgo,sg2042-rpgate.h
> @@ -0,0 +1,58 @@
> +/* SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */
> +/*
> + * Copyright (C) 2023 Sophgo Technology Inc. All rights reserved.
> + */
> +
> +#ifndef __DT_BINDINGS_SOPHGO_SG2042_RPGATE_H__
> +#define __DT_BINDINGS_SOPHGO_SG2042_RPGATE_H__
> +
> +#define GATE_CLK_RXU0 0
> +#define GATE_CLK_RXU1 1
> +#define GATE_CLK_RXU2 2
> +#define GATE_CLK_RXU3 3
> +#define GATE_CLK_RXU4 4
> +#define GATE_CLK_RXU5 5
> +#define GATE_CLK_RXU6 6
> +#define GATE_CLK_RXU7 7
> +#define GATE_CLK_RXU8 8
> +#define GATE_CLK_RXU9 9
> +#define GATE_CLK_RXU10 10
> +#define GATE_CLK_RXU11 11
> +#define GATE_CLK_RXU12 12
> +#define GATE_CLK_RXU13 13
> +#define GATE_CLK_RXU14 14
> +#define GATE_CLK_RXU15 15
> +#define GATE_CLK_RXU16 16
> +#define GATE_CLK_RXU17 17
> +#define GATE_CLK_RXU18 18
> +#define GATE_CLK_RXU19 19
> +#define GATE_CLK_RXU20 20
> +#define GATE_CLK_RXU21 21
> +#define GATE_CLK_RXU22 22
> +#define GATE_CLK_RXU23 23
> +#define GATE_CLK_RXU24 24
> +#define GATE_CLK_RXU25 25
> +#define GATE_CLK_RXU26 26
> +#define GATE_CLK_RXU27 27
> +#define GATE_CLK_RXU28 28
> +#define GATE_CLK_RXU29 29
> +#define GATE_CLK_RXU30 30
> +#define GATE_CLK_RXU31 31
> +#define GATE_CLK_MP0 32
> +#define GATE_CLK_MP1 33
> +#define GATE_CLK_MP2 34
> +#define GATE_CLK_MP3 35
> +#define GATE_CLK_MP4 36
> +#define GATE_CLK_MP5 37
> +#define GATE_CLK_MP6 38
> +#define GATE_CLK_MP7 39
> +#define GATE_CLK_MP8 40
> +#define GATE_CLK_MP9 41
> +#define GATE_CLK_MP10 42
> +#define GATE_CLK_MP11 43
> +#define GATE_CLK_MP12 44
> +#define GATE_CLK_MP13 45
> +#define GATE_CLK_MP14 46
> +#define GATE_CLK_MP15 47
> +
> +#endif /* __DT_BINDINGS_SOPHGO_SG2042_RPGATE_H__ */
^ permalink raw reply
* Re: [PATCH v7 09/15] media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface
From: Tomi Valkeinen @ 2024-03-27 11:21 UTC (permalink / raw)
To: Laurent Pinchart, linux-media
Cc: Dave Stevenson, David Plowman, Jean-Michel Hautbois, Hans Verkuil,
Naushir Patuck, Sakari Ailus, kernel-list, linux-rpi-kernel,
Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list, Conor Dooley, Krzysztof Kozlowski,
Rob Herring, devicetree
In-Reply-To: <20240324220854.15010-10-laurent.pinchart@ideasonboard.com>
On 25/03/2024 00:08, Laurent Pinchart wrote:
> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>
> Add a driver for the Unicam camera receiver block on BCM283x processors.
> It is represented as two video device nodes: unicam-image and
> unicam-embedded which are connected to an internal subdev (named
> unicam-subdev) in order to manage streams routing.
Shouldn't this driver call get_frame_desc somewhere to get the VC and DT
for the streams?
Tomi
^ permalink raw reply
* Re: [PATCH v6 4/4] pinctrl: Implementation of the generic scmi-pinctrl driver
From: Dan Carpenter @ 2024-03-27 11:20 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Linus Walleij, linux-arm-kernel, linux-kernel,
devicetree, linux-gpio, Peng Fan, Oleksii Moisieiev
In-Reply-To: <20240323-pinctrl-scmi-v6-4-a895243257c0@nxp.com>
On Sat, Mar 23, 2024 at 08:15:17PM +0800, Peng Fan (OSS) wrote:
> diff --git a/drivers/firmware/arm_scmi/pinctrl.c b/drivers/firmware/arm_scmi/pinctrl.c
> index 87d9b89cab13..0ecefe855432 100644
> --- a/drivers/firmware/arm_scmi/pinctrl.c
> +++ b/drivers/firmware/arm_scmi/pinctrl.c
> @@ -465,6 +465,7 @@ scmi_pinctrl_settings_conf(const struct scmi_protocol_handle *ph,
>
> tx = t->tx.buf;
> tx->identifier = cpu_to_le32(selector);
> + tx->function_id = cpu_to_le32(0xFFFFFFFF);
> attributes = FIELD_PREP(GENMASK(1, 0), type) |
> FIELD_PREP(GENMASK(9, 2), chunk);
> tx->attributes = cpu_to_le32(attributes);
This should have been done in patch 3.
regards,
dan carpenter
> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> index d45657aa986a..4e6f65cf0e76 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -450,6 +450,17 @@ config PINCTRL_ROCKCHIP
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Krzysztof Kozlowski @ 2024-03-27 11:04 UTC (permalink / raw)
To: Yu-chang Lee (李禹璋),
MandyJH Liu (劉人僖), conor+dt@kernel.org,
robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
matthias.bgg@gmail.com, ulf.hansson@linaro.org,
angelogioacchino.delregno@collabora.com
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group,
Xiufeng Li (李秀峰),
linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <7f24ca2806a7199e4de6fad17b8dc1f127c82180.camel@mediatek.com>
On 27/03/2024 11:56, Yu-chang Lee (李禹璋) wrote:
> On Wed, 2024-03-27 at 11:43 +0100, Krzysztof Kozlowski wrote:
>>
>> External email : Please do not click links or open attachments until
>> you have verified the sender or the content.
>> On 27/03/2024 11:39, Yu-chang Lee (李禹璋) wrote:
>>>>>>
>>>>> Hi,
>>>>>
>>>>> I will double check the format of yaml for the next version,
>> sorry
>>>> for
>>>>> inconvenience. But I did test it on mt8188 chromebook, the reason
>>>> why
>>>>
>>>> How do you test a binding on chromebook?
>>>>
>>>>> power domain need larb node is that when mtcmos power on, signal
>>>> glitch
>>>>> may produce. Power domain driver must reset larb when this happen
>>>> to
>>>>> prevent dummy transaction on bus. That why I need larb node in
>> dts.
>>>>
>>>> No one talks here about larb node...
>>>
>>> Sorry, May you elaborate on what information I need to provide to
>> you
>>> or it is just a syntax problem I need to fix?
>>
>> Please explain the purpose of this property (how is it going to be
>> used by drivers)and what does it represent.
>>
>
> It represent SMI LARB(Local ARBitration). In power domain driver when
> power on power domain, It need to reset LARB to prevent potential power
> glitch which may cause dummy transaction on bus. Without taking care of
> this issue it often leads to camera hang in stress test.
That sounds rather like missing resets... or something else connecting
these devices. Maybe the explanation is just imprecise...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v9 00/38] ep93xx device tree conversion
From: Andy Shevchenko @ 2024-03-27 10:59 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andy Shevchenko, nikita.shubin, Hartley Sweeten,
Alexander Sverdlin, Russell King, Lukasz Majewski, Linus Walleij,
Bartosz Golaszewski, Michael Turquette, Stephen Boyd,
Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Wim Van Sebroeck, Guenter Roeck, Thierry Reding,
Uwe Kleine-König, Mark Brown, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Damien Le Moal, Sergey Shtylyov,
Dmitry Torokhov, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Ralf Baechle, Wu, Aaron, Lee Jones, Olof Johansson, Niklas Cassel,
linux-arm-kernel, linux-kernel, linux-gpio, linux-clk, linux-pm,
devicetree, dmaengine, linux-watchdog, linux-pwm, linux-spi,
netdev, linux-mtd, linux-ide, linux-input, linux-sound,
Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn
In-Reply-To: <a16f45c9-747c-4a19-98a3-aa5f47ee5c4d@linaro.org>
On Wed, Mar 27, 2024 at 7:07 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
> On 26/03/2024 15:49, Andy Shevchenko wrote:
> > On Tue, Mar 26, 2024 at 11:19:54AM +0100, Krzysztof Kozlowski wrote:
> >> On 26/03/2024 10:18, Nikita Shubin via B4 Relay wrote:
...
> >> A lot of this could have been already merged if you split it... Just
> >> saying...
> >
> > But you able to apply DT schema patches if you wish.
> > Just doing? :-)
>
> Me? Why? DT bindings are supposed to go via subsystem maintainers, not
> DT tree.
Okay, I never remembered this rule, thank you for clarifying.
> Plus, I do not apply any bindings patches, except for managed
> subsystems and none of them are touched here.
Good to know!
--
With Best Regards,
Andy Shevchenko
^ 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