* Re: [PATCH 0/8] block: implement NVMEM provider
From: Rob Herring @ 2024-03-25 15:12 UTC (permalink / raw)
To: Daniel Golle
Cc: 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: <cover.1711048433.git.daniel@makrotopia.org>
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).
Also, please version your patches. 'RFC' is a tag, not a version. v1 was
July. v2 was March 5th. This is v3.
Rob
^ permalink raw reply
* Re: [PATCH 0/8] block: implement NVMEM provider
From: Rob Herring @ 2024-03-25 15:10 UTC (permalink / raw)
To: Daniel Golle
Cc: 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: <cover.1711048433.git.daniel@makrotopia.org>
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.
Rob
^ permalink raw reply
* [PATCH 2/2] Input: edt-ft5x06 - add ft5426
From: Andreas Kemnade @ 2024-03-24 18:44 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt,
andreas, o.rempel, dario.binacchi, u.kleine-koenig, hdegoede,
p.puschmann, linux-input, devicetree, linux-kernel,
caleb.connolly
In-Reply-To: <20240324184415.206587-1-andreas@kemnade.info>
As ft5426 seems to be compatible with this driver, add it.
Debug output during identification: Model "generic ft5x06 (79)", Rev. "
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
drivers/input/touchscreen/edt-ft5x06.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index 2a1db11344766..4e7621a801756 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1484,6 +1484,7 @@ static const struct of_device_id edt_ft5x06_of_match[] = {
{ .compatible = "edt,edt-ft5206", .data = &edt_ft5x06_data },
{ .compatible = "edt,edt-ft5306", .data = &edt_ft5x06_data },
{ .compatible = "edt,edt-ft5406", .data = &edt_ft5x06_data },
+ { .compatible = "focaltech,ft5426", .data = &edt_ft5506_data },
{ .compatible = "edt,edt-ft5506", .data = &edt_ft5506_data },
{ .compatible = "evervision,ev-ft5726", .data = &edt_ft5506_data },
/* Note focaltech vendor prefix for compatibility with ft6236.c */
--
2.39.2
^ permalink raw reply related
* [RFC PATCH 0/2] mfd: rohm-bd71828: Add power off
From: Andreas Kemnade @ 2024-03-24 20:12 UTC (permalink / raw)
To: lee, robh+dt, krzysztof.kozlowski+dt, conor+dt, mazziesaccount,
devicetree, linux-kernel, imx
Cc: Andreas Kemnade
Add power off functionality. Marked as RFC because of magic numbers
without a good source and strange delays. The only information source is
only a vendor kernel.
Andreas Kemnade (2):
dt-bindings: mfd: Add ROHM BD71828 system-power-controller property
mfd: rohm-bd71828: Add power off functionality
.../bindings/mfd/rohm,bd71828-pmic.yaml | 2 ++
drivers/mfd/rohm-bd71828.c | 31 ++++++++++++++++++-
2 files changed, 32 insertions(+), 1 deletion(-)
--
2.39.2
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: rng: Add vmgenid support
From: Rob Herring @ 2024-03-25 15:06 UTC (permalink / raw)
To: Sudan Landge
Cc: tytso, Jason, krzysztof.kozlowski+dt, conor+dt,
sathyanarayanan.kuppuswamy, thomas.lendacky, dan.j.williams,
devicetree, linux-kernel, graf, dwmw, bchalios, xmarcalx
In-Reply-To: <20240321025105.53210-4-sudanl@amazon.com>
On Thu, Mar 21, 2024 at 02:51:04AM +0000, Sudan Landge wrote:
> Virtual Machine Generation ID driver was introduced in commit af6b54e2b5ba
> ("virt: vmgenid: notify RNG of VM fork and supply generation ID"), as an
> ACPI only device.
>
> VMGenID specification http://go.microsoft.com/fwlink/?LinkId=260709 defines
> a mechanism for the BIOS/hypervisors to communicate to the virtual machine
> that it is executed with a different configuration (e.g. snapshot execution
> or creation from a template).
> The guest operating system can use the notification for various purposes
> such as re-initializing its random number generator etc.
>
> As per the specs, hypervisor should provide a globally unique identified,
> or GUID via ACPI.
>
> This patch tries to mimic the mechanism to provide the same functionality
> which is for a hypervisor/BIOS to notify the virtual machine when it is
> executed with a different configuration.
>
> As part of this support the devicetree bindings requires the hypervisors or
> BIOS to provide a memory address which holds the GUID and an IRQ which is
> used to notify when there is a change in the GUID.
> The memory exposed in the DT should follow the rules defined in the
> vmgenid spec mentioned above.
>
> *Reason for this change*:
> Chosing ACPI or devicetree is an intrinsic part of an hypervisor design.
> Without going into details of why a hypervisor would chose DT over ACPI,
> we would like to highlight that the hypervisors that have chose devicetree
> and now want to make use of the vmgenid functionality cannot do so today
> because vmgenid is an ACPI only device.
> This forces these hypervisors to change their design which could have
> undesirable impacts on their use-cases, test-scenarios etc.
>
> The point of vmgenid is to provide a mechanism to discover a GUID when
> the execution state of a virtual machine changes and the simplest
> way to do it is pass a memory location and an interrupt via devicetree.
> It would complicate things unnecessarily if instead of using devicetree,
> we try to implement a new protocol or modify other protocols to somehow
> provide the same functionility.
>
> We believe that adding a devicetree binding for vmgenid is a simpler,
> better alternative to provide the same functionality and will allow
> such hypervisors as mentioned above to continue using devicetree.
>
> More references to vmgenid specs:
> - https://www.qemu.org/docs/master/specs/vmgenid.html
> - https://learn.microsoft.com/en-us/windows/win32/hyperv_v2/virtual-machine-generation-identifier
>
> Signed-off-by: Sudan Landge <sudanl@amazon.com>
> ---
> .../devicetree/bindings/rng/vmgenid.yaml | 57 +++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 58 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rng/vmgenid.yaml
>
> diff --git a/Documentation/devicetree/bindings/rng/vmgenid.yaml b/Documentation/devicetree/bindings/rng/vmgenid.yaml
> new file mode 100644
> index 000000000000..4b6ab62cc2ae
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rng/vmgenid.yaml
> @@ -0,0 +1,57 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rng/vmgenid.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Virtual Machine Generation Counter ID device
> +
> +maintainers:
> + - Jason A. Donenfeld <Jason@zx2c4.com>
> +
> +description:
> + Firmwares or hypervisors can use this devicetree to describe
> + interrupts and the shared resources to inject a Virtual Machine Generation
> + counter.
> +
> +properties:
> + compatible:
> + const: linux,vmgenctr
Why 'linux'? It should be named for a particular host implementation
(and that implementation's bugs/quirks). However, this thing is simple
enough we can perhaps avoid that here. As the interface is defined by
Microsoft, then perhaps they should be the vendor here.
> +
> + "#interrupt-cells":
> + const: 3
> + description: |
> + The 1st cell is the interrupt type.
> + The 2nd cell contains the interrupt number for the interrupt type.
> + The 3rd cell is for trigger type and level flags.
> +
> + interrupt-controller: true
Why is this device an interrupt controller?
> +
> + reg:
> + description: |
> + specifies the base physical address and
> + size of the regions in memory which holds the VMGenID counter.
Odd wrapping, but drop unless you have something specific to say about
region like perhaps the layout of the registers. Or maybe thats defined
somewhere else?
Does the spec say anything about endianness or access size? DT assumes
native endianness by default. We have properties to deal these, but
would be better to be explicit if that's defined already.
> + maxItems: 1
> +
> + interrupts:
> + description: |
Don't need '|' if no formatting.
> + interrupt used to notify that a new VMGenID counter is available.
> + The interrupt should be Edge triggered.
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + rng@80000000 {
> + compatible = "linux,vmgenctr";
> + reg = <0x80000000 0x1000>;
> + interrupts = <0x00 0x23 0x01>;
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 43b39956694a..cf4b2e10fb49 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -18431,6 +18431,7 @@ M: "Theodore Ts'o" <tytso@mit.edu>
> M: Jason A. Donenfeld <Jason@zx2c4.com>
> S: Maintained
> T: git https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git
> +F: Documentation/devicetree/bindings/rng/vmgenid.yaml
> F: drivers/char/random.c
> F: drivers/virt/vmgenid.c
>
> --
> 2.40.1
>
>
^ permalink raw reply
* Re: [PATCH v5 7/7] iio: adc: ad7380: add support for ad738x-4 4 channels variants
From: David Lechner @ 2024-03-25 15:01 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Julien Stephan, Lars-Peter Clausen, Michael Hennerich,
Nuno Sá, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, linux-iio, devicetree, linux-kernel,
kernel test robot
In-Reply-To: <20240324131059.77fa8e68@jic23-huawei>
On Sun, Mar 24, 2024 at 8:11 AM Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Tue, 19 Mar 2024 11:11:28 +0100
> Julien Stephan <jstephan@baylibre.com> wrote:
>
> > Add support for ad7380/1/2/3-4 parts which are 4 channels
> > variants from ad7380/1/2/3
> >
> > Signed-off-by: Julien Stephan <jstephan@baylibre.com>
> This and other patches I didn't comment on all look good to me.
> So just those minor few bits and bobs for v6 and I'll pick this up
> if nothing else comes in.
>
Hi Jonathan, as a reminder, this is the driver we dropped from the 6.9
cycle. We still don't have a patch prepared for the resolution boost
feature that may require us to reconsider some of our userspace
interface choices here. Hopefully we can get that sorted out in the
next 6 weeks, but I just wanted to make you aware ahead of time so
that we don't end up in the same situation in case things don't go as
planned again. Do you have "usual" way you prefer to handle a
situation like this?
^ permalink raw reply
* Re: [PATCH v3 0/6] iio: accel: adxl345: Add spi-3wire feature
From: Jonathan Cameron @ 2024-03-25 14:51 UTC (permalink / raw)
To: Lothar Rubusch
Cc: Jonathan Cameron, lars, Michael.Hennerich, robh+dt,
krzysztof.kozlowski+dt, conor+dt, linux-iio, devicetree,
linux-kernel, eraretuya
In-Reply-To: <CAFXKEHbvdQoqyirUC8ueihfTcCs7m5CViP27S1sNDA0VerUVYQ@mail.gmail.com>
On Sun, 24 Mar 2024 20:20:21 +0100
Lothar Rubusch <l.rubusch@gmail.com> wrote:
> On Sun, Mar 24, 2024 at 2:39 PM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Sat, 23 Mar 2024 12:20:24 +0000
> > Lothar Rubusch <l.rubusch@gmail.com> wrote:
> >
> > > Pass a function setup() as pointer from SPI/I2C specific modules
> > > to the core module. Implement setup() to pass the spi-3wire bus
> > > option, if declared in the device-tree.
> > >
> > > In the core module, then update data_format register
> > > configuration bits instead of overwriting it. The changes allow
> > > to remove a data_range field, remove I2C and SPI redundant info
> > > instances and replace them by a common info array instance.
> > >
> > > Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> > That patch break up seems reasonable (one minor request for a split
> > in the relevant patch), but normal convention would be do do
> > refactoring first, then functionality at the end. Also removal stuff
> > and group, before adding things.
> >
> > So roughly speaking reorder as
> >
> > > iio: accel: adxl345: Make data_format obsolete
> > > iio: accel: adxl345: Remove single info instances
> > > iio: accel: adxl345: Group bus configuration
> > > dt-bindings: iio: accel: adxl345: Add spi-3wire
> > > iio: accel: adxl345: Pass function pointer to core
> > > iio: accel: adxl345: Add the spi-3wire
> >
>
> Ok. If I split "Group bus configuration" into the grouping of the
> indio_dev in the probe() and adding a comment to the core's probe(), I
> will end up with something like this:
>
> $ git log --oneline --reverse
> iio: accel: adxl345: Make data_range obsolete
> iio: accel: adxl345: Group bus configuration
> iio: accel: adxl345: Move defines to header <--- new
> dt-bindings: iio: accel: adxl345: Add spi-3wire
> iio: accel: adxl345: Pass function pointer to core
> iio: accel: adxl345: Add comment to probe <--- new after split
> iio: accel: adxl345: Add spi-3wire option
>
> I feel I have to add the comment after adding the passed function
> pointer. Bascially I liked to add a comment mentioning especially the
> new function pointer there. So, although being a comment, the commit
> will be in this "high" position. Is this ok, or am I doing something
> wrong? Should I split into setting the comment first, then inside
> "Pass function pointer.." also update the comment?
This is fine. Either of the options you suggest would be fine, but
given you've done the above already let's go with that.
Jonathan
>
^ permalink raw reply
* Re: [PATCH v5 0/4] platform: arm64: Acer Aspire 1 embedded controller
From: Hans de Goede @ 2024-03-25 14:50 UTC (permalink / raw)
To: Nikita Travkin, Ilpo Järvinen, Sebastian Reichel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
cros-qcom-dts-watchers, Andy Gross, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Bryan O'Donoghue
Cc: devicetree, linux-kernel, linux-arm-msm, platform-driver-x86
In-Reply-To: <20240315-aspire1-ec-v5-0-f93381deff39@trvn.ru>
Hi,
On 3/15/24 2:51 PM, Nikita Travkin wrote:
> The laptop contains an embedded controller that provides a set of
> features:
>
> - Battery and charger monitoring
> - USB Type-C DP alt mode HPD monitoring
> - Lid status detection
> - Small amount of keyboard configuration*
>
> [*] The keyboard is handled by the same EC but it has a dedicated i2c
> bus and is already enabled. This port only provides fn key behavior
> configuration.
>
> Unfortunately, while all this functionality is implemented in ACPI, it's
> currently not possible to use ACPI to boot Linux on such Qualcomm
> devices. Thus this series implements and enables a new driver that
> provides support for the EC features.
>
> The EC would be one of the last pieces to get almost full support for the
> Acer Aspire 1 laptop in the upstream Linux kernel.
>
> This series is similar to the EC driver for Lenovo Yoga C630, proposed
> in [1] but seemingly never followed up...
>
> [1] https://lore.kernel.org/all/20230205152809.2233436-1-dmitry.baryshkov@linaro.org/
>
> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Thank you for your patch-series, I've applied the series to my
review-hans branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans
I've fixed the Kconfig typo Randy spotted while applying this.
Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.
Regards,
Hans
> ---
> Changes in v5:
> - Various cleanups (Bryan, Ilpo)
> - Add Bryan as Reviewer for platform/arm64 (Bryan, Ilpo)
> - Link to v4: https://lore.kernel.org/r/20240312-aspire1-ec-v4-0-bd8e3eea212f@trvn.ru
>
> Changes in v4:
> - Move to platform/arm64 (Sebastian, Hans)
> - Drop fn mode dt property (Rob)
> - Add fn_lock attribute in sysfs (Rob)
> - Report psy present correctly (Sebastian)
> - Link to v3: https://lore.kernel.org/r/20240220-aspire1-ec-v3-0-02cb139a4931@trvn.ru
>
> Changes in v3:
> - Supress warning on few no-op events.
> - Invert the fn key behavior (Rob, Conor)
> - Link to v2: https://lore.kernel.org/r/20231212-aspire1-ec-v2-0-ca495ea0a7ac@trvn.ru
>
> Changes in v2:
> - Drop incorrectly allowed reg in the ec connector binding (Krzysztof)
> - Minor style changes (Konrad)
> - Link to v1: https://lore.kernel.org/r/20231207-aspire1-ec-v1-0-ba9e1c227007@trvn.ru
>
> ---
> Nikita Travkin (4):
> dt-bindings: platform: Add Acer Aspire 1 EC
> platform: Add ARM64 platform directory
> platform: arm64: Add Acer Aspire 1 embedded controller driver
> arm64: dts: qcom: acer-aspire1: Add embedded controller
>
> .../bindings/platform/acer,aspire1-ec.yaml | 60 +++
> MAINTAINERS | 16 +
> arch/arm64/boot/dts/qcom/sc7180-acer-aspire1.dts | 40 +-
> drivers/platform/Kconfig | 2 +
> drivers/platform/Makefile | 1 +
> drivers/platform/arm64/Kconfig | 35 ++
> drivers/platform/arm64/Makefile | 8 +
> drivers/platform/arm64/acer-aspire1-ec.c | 562 +++++++++++++++++++++
> 8 files changed, 723 insertions(+), 1 deletion(-)
> ---
> base-commit: a1e7655b77e3391b58ac28256789ea45b1685abb
> change-id: 20231206-aspire1-ec-6b3d2cac1a72
>
> Best regards,
^ permalink raw reply
* Re: [PATCH v3 4/6] iio: accel: adxl345: Remove single info instances
From: Jonathan Cameron @ 2024-03-25 14:48 UTC (permalink / raw)
To: Lothar Rubusch
Cc: Jonathan Cameron, lars, Michael.Hennerich, robh+dt,
krzysztof.kozlowski+dt, conor+dt, linux-iio, devicetree,
linux-kernel, eraretuya
In-Reply-To: <CAFXKEHZWArvErzeoaO+jMrrA7AuQ4izJioNW_wWTza-bLXV22A@mail.gmail.com>
On Sun, 24 Mar 2024 20:06:51 +0100
Lothar Rubusch <l.rubusch@gmail.com> wrote:
> On Sun, Mar 24, 2024 at 2:35 PM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Sat, 23 Mar 2024 12:20:28 +0000
> > Lothar Rubusch <l.rubusch@gmail.com> wrote:
> >
> > > Add a common array adxl3x5_chip_info and an enum for
> > > indexing. This allows to remove local redundantly
> > > initialized code in the bus specific modules.
> > >
> > > Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> > > ---
> > > drivers/iio/accel/adxl345.h | 7 +++++++
> > > drivers/iio/accel/adxl345_core.c | 12 ++++++++++++
> > > drivers/iio/accel/adxl345_i2c.c | 20 +++++---------------
> > > drivers/iio/accel/adxl345_spi.c | 20 +++++---------------
> > > 4 files changed, 29 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/drivers/iio/accel/adxl345.h b/drivers/iio/accel/adxl345.h
> > > index 6b84a2cee..de6b1767d 100644
> > > --- a/drivers/iio/accel/adxl345.h
> > > +++ b/drivers/iio/accel/adxl345.h
> > > @@ -26,11 +26,18 @@
> > > */
> > > #define ADXL375_USCALE 480000
> > >
> > > +enum adxl345_device_type {
> > > + ADXL345,
> > > + ADXL375,
> > > +};
> > > +
> > > struct adxl345_chip_info {
> > > const char *name;
> > > int uscale;
> > > };
> > >
> > > +extern const struct adxl345_chip_info adxl3x5_chip_info[];
> > > +
> > > int adxl345_core_probe(struct device *dev, struct regmap *regmap,
> > > int (*setup)(struct device*, struct regmap*));
> > >
> > > diff --git a/drivers/iio/accel/adxl345_core.c b/drivers/iio/accel/adxl345_core.c
> > > index 33424edca..e3718d0dd 100644
> > > --- a/drivers/iio/accel/adxl345_core.c
> > > +++ b/drivers/iio/accel/adxl345_core.c
> > > @@ -62,6 +62,18 @@ struct adxl345_data {
> > > BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> > > }
> > >
> > > +const struct adxl345_chip_info adxl3x5_chip_info[] = {
> > > + [ADXL345] = {
> > > + .name = "adxl345",
> > > + .uscale = ADXL345_USCALE,
> > > + },
> > > + [ADXL375] = {
> > > + .name = "adxl375",
> > > + .uscale = ADXL375_USCALE,
> > > + },
> > > +};
> > > +EXPORT_SYMBOL_NS_GPL(adxl3x5_chip_info, IIO_ADXL345);
> >
> > There is little advantage here form using an array. I'd just have
> > two exported structures. Then the name alone is enough in the
> > id tables. And probably no need for the enum definition.
> >
> > This use of arrays is an old pattern that makes little sense if the
> > IDs have no actual meaning and you aren't supporting lots of different
> > parts. For 2 parts I'd argue definitely not worth it.
> >
>
> Agree. I see your point. I drop the info array enum patch.
>
> (...)
>
> Btw. may I ask another question: The adxl345/75 driver is doing the
> configuration
> inside the probe(). Other Analog drivers moved that out into a
> xxx_setup() and call
> this function in the probe(). In general, is it better to keep all
> inside the probe() or
> separate? I mean, the probe is still quite short, and reading through
> severl call
> hierarchies feels a bit "sparghetti". On the other side I can see a
> certain idea of
> separation of functionality: dedicated chip configuration. Would you
> mind to give
> me a small statement/opinion on this please?
I'd based it on code complexity.
If it's one call (and error handling) to do it then inline makes sense.
If it's lots of lines, a separate function make sense.
Where the boundary between the two lies is subjective so I tend to
just go with whatever an author prefers. Note that I'm not keen
to see the noise of refactors if the code lies in this gray area?
Jonathan
>
^ permalink raw reply
* Re: [PATCH v3 3/6] iio: accel: adxl345: Add spi-3wire option
From: Jonathan Cameron @ 2024-03-25 14:46 UTC (permalink / raw)
To: Lothar Rubusch
Cc: Jonathan Cameron, lars, Michael.Hennerich, robh+dt,
krzysztof.kozlowski+dt, conor+dt, linux-iio, devicetree,
linux-kernel, eraretuya
In-Reply-To: <CAFXKEHaeWbLV6g9eEdp9de5sZO0TJPRrJvsVxnGCf9jzdxwgHA@mail.gmail.com>
On Sun, 24 Mar 2024 19:59:39 +0100
Lothar Rubusch <l.rubusch@gmail.com> wrote:
> On Sun, Mar 24, 2024 at 2:32 PM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Sat, 23 Mar 2024 12:20:27 +0000
> > Lothar Rubusch <l.rubusch@gmail.com> wrote:
> >
> > > Add a setup function implementation to the spi module to enable
> > > spi-3wire as option when specified in the device-tree.
> > >
> > > Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> > > ---
> > > drivers/iio/accel/adxl345.h | 3 +++
> > > drivers/iio/accel/adxl345_spi.c | 12 +++++++++++-
> > > 2 files changed, 14 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/iio/accel/adxl345.h b/drivers/iio/accel/adxl345.h
> > > index 3c1ded0c2..6b84a2cee 100644
> > > --- a/drivers/iio/accel/adxl345.h
> > > +++ b/drivers/iio/accel/adxl345.h
> > > @@ -8,6 +8,9 @@
> > > #ifndef _ADXL345_H_
> > > #define _ADXL345_H_
> > >
> > > +#define ADXL345_REG_DATA_FORMAT 0x31
> > > +#define ADXL345_DATA_FORMAT_SPI BIT(6) /* spi-3wire */
> > Name it that, rather than using a comment. No need to precisely
> > match datasheet naming - you are naming the value not the field here.
> >
> > ADXL345_DATA_FORMAT_SPI_3_WRITE perhaps?
> >
>
> Would you accept the following instead?
> ADXL345_DATA_FORMAT_SPI_3WIRE
>
> In the OF binding it is SPI_3WIRE. So, from this perspective I think it would
> be consistent naming.
That's fine. Precise naming up to you.
Jonathan
>
> (...)
>
^ permalink raw reply
* Re: [Upstream] [PATCH 0/2] i.MX93 ADC calibration settings
From: Jonathan Cameron @ 2024-03-25 14:45 UTC (permalink / raw)
To: Primoz Fiser
Cc: Andrej Picej, Jonathan Cameron, devicetree, conor+dt, lars,
krzysztof.kozlowski+dt, imx, linux-iio, festevam, s.hauer,
upstream, linux-kernel, haibo.chen, kernel, shawnguo, robh,
linux-arm-kernel
In-Reply-To: <44ac8977-cf98-46a5-be15-1bec330c6a2e@norik.com>
On Mon, 25 Mar 2024 09:55:23 +0100
Primoz Fiser <primoz.fiser@norik.com> wrote:
> Hi Jonathan,
>
> On 25. 03. 24 09:32, Andrej Picej wrote:
> > Hi Jonathan,
> >
> > On 24. 03. 24 14:55, Jonathan Cameron wrote:
> >> On Wed, 20 Mar 2024 11:04:04 +0100
> >> Andrej Picej <andrej.picej@norik.com> wrote:
> >>
> >>> Hi all,
> >>>
> >>> we had some problems with failing ADC calibration on the i.MX93 boards.
> >>> Changing default calibration settings fixed this. The board where this
> >>> patches are useful is not yet upstream but will be soon (hopefully).
> >>
> >> Tell us more. My initial instinct is that this shouldn't be board
> >> specific.
> >> What's the trade off we are making here? Time vs precision of
> >> calibration or
> >> something else? If these are set to a level by default that doesn't work
> >> for our board, maybe we should just change them for all devices?
> >>
>
> The imx93_adc driver is quite new.
>
> If you look at line #162, you will find a comment by the original author:
>
> > /*
> > * TODO: we use the default TSAMP/NRSMPL/AVGEN in MCR,
> > * can add the setting of these bit if need in future.
> > */
>
> URL:
> https://github.com/torvalds/linux/blob/master/drivers/iio/adc/imx93_adc.c#L162
>
> So, for most use-cases the default setting should work, but why not make
> them configurable?
>
> So this patch-series just implement what was missing from the beginning
> / was planned for later.
Hi Primoz,
I doubt anyone reviewed the comment closely enough to say if what it was
suggesting was sensible or not, so the fact it was listed as a todo
doesn't directly impact this discussion.
>
> BR,
> Primoz
>
>
> >
> > So we have two different boards with the same SoC. On one, the
> > calibration works with the default values, on the second one the
> > calibration fails, which makes the ADC unusable. What the ADC lines
> > measure differ between the boards though. But the implementation is
> > nothing out of the ordinary.
> >
> > We tried different things but the only thing that helped is to use
> > different calibration properties. We tried deferring the probe and
> > calibration until later boot and after boot, but it did not help.
> >
> > In the Reference Manual [1] (chapter 72.5.1) it is written:
> >
> >> 4. Configure desired calibration settings (default values kept for
> >> highest accuracy maximum time).
> >
> > So your assumption is correct, longer calibration time (more averaging
> > samples) -> higher precision. The default values go for a high accuracy.
> > And since we use a NRSMPL (Number of Averaging Samples) of 32 instead of
> > default 512, we reduce the accuracy so the calibration values pass the
> > internal defined limits.
Ouch. Let me try to dig into this. Is this effectively relaxing the
constraints? I guess because a value that is perhaps always biased one way
is considered within bounds if those acceptable bounds are wider because
of lower precision?
I was assuming it was the other way around and the device had fixed constraint
limits and you needed to take more samples due to higher noise. Seems the
opposite is true here and that worries me.
I'll definitely need input from NXP on this as a workaround and their
strong support to consider it.
> >
> > I'm not sure that changing default values is the right solution here. We
> > saw default values work with one of the boards. And since the NXP kept
> > these values adjustable I think there is a reason behind it.
I'd assume trade off between time and calibration precision, not the
sort of use I think you are describing.
> >
> > Note: When I say one of the boards I mean one board form. So same board
> > version, but different HW.
Superficially I'm struggling to not see this as broken hardware that it
is out of expected tolerances in some fashion. Maybe I misunderstood
the issue.
Jonathan
> >
> > Best regards,
> > Andrej
> >
> > [1] i.MX 93 Applications Processor Reference Manual, Rev. 4, 12/2023
> > _______________________________________________
> > upstream mailing list
> > upstream@lists.phytec.de
> > http://lists.phytec.de/cgi-bin/mailman/listinfo/upstream
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4] dt-bindings: display: atmel,lcdc: convert to dtschema
From: Rob Herring @ 2024-03-25 14:39 UTC (permalink / raw)
To: Dharma Balasubiramani
Cc: Rob Herring, Maxime Ripard, linux-kernel, David Airlie,
Maarten Lankhorst, Nicolas Ferre, Claudiu Beznea,
linux-arm-kernel, Krzysztof Kozlowski, devicetree, Daniel Vetter,
Alexandre Belloni, dri-devel, Conor Dooley, Thomas Zimmermann
In-Reply-To: <20240318-lcdc-fb-v4-1-c533c7c2c706@microchip.com>
On Mon, 18 Mar 2024 11:10:13 +0530, Dharma Balasubiramani wrote:
> Convert the atmel,lcdc bindings to DT schema.
> Changes during conversion: add missing clocks and clock-names properties.
>
> Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
> ---
> This patch converts the existing lcdc display text binding to JSON schema.
> The binding is split into two namely
> lcdc.yaml
> - Holds the frame buffer properties
> lcdc-display.yaml
> - Holds the display panel properties which is a phandle to the display
> property in lcdc fb node.
>
> These bindings are tested using the following command.
> 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> ---
> Changes in v4:
> - Add maximum for atmel,guard-time property.
> - Add constraints for bits-per-pixel property.
> - Update the atmel,lcd-wiring-mode property's ref to point single string
> rather than an array.
> - Add constraints for atmel,lcd-wiring-mode property.
> - Add maxItems to the atmel,power-control-gpio property.
> - Link to v3: https://lore.kernel.org/r/20240304-lcdc-fb-v3-1-8b616fbb0199@microchip.com
>
> Changes in v3:
> - Remove the generic property "bits-per-pixel"
> - Link to v2: https://lore.kernel.org/r/20240304-lcdc-fb-v2-1-a14b463c157a@microchip.com
>
> Changes in v2:
> - Run checkpatch and remove whitespace errors.
> - Add the standard interrupt flags.
> - Split the binding into two, namely lcdc.yaml and lcdc-display.yaml.
> - Link to v1: https://lore.kernel.org/r/20240223-lcdc-fb-v1-1-4c64cb6277df@microchip.com
> ---
> .../bindings/display/atmel,lcdc-display.yaml | 103 +++++++++++++++++++++
> .../devicetree/bindings/display/atmel,lcdc.txt | 87 -----------------
> .../devicetree/bindings/display/atmel,lcdc.yaml | 70 ++++++++++++++
> 3 files changed, 173 insertions(+), 87 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: iio: adc: nxp,imx93-adc.yaml: Add calibration properties
From: Jonathan Cameron @ 2024-03-25 14:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrej Picej, haibo.chen, linux-iio, devicetree, jic23, lars,
shawnguo, s.hauer, kernel, festevam, imx, linux-arm-kernel,
linux-kernel, robh, krzysztof.kozlowski+dt, conor+dt, upstream
In-Reply-To: <178594a2-cd5f-4608-aae6-7d68fd0817e0@linaro.org>
On Mon, 25 Mar 2024 10:58:51 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> On 22/03/2024 10:58, Andrej Picej wrote:
> > On 22. 03. 24 09:14, Krzysztof Kozlowski wrote:
> >> On 22/03/2024 08:39, Andrej Picej wrote:
> >>> On 20. 03. 24 13:15, Krzysztof Kozlowski wrote:
> >>>> On 20/03/2024 13:05, Andrej Picej wrote:
> >>>>> Hi Krzysztof,
> >>>>>
> >>>>> On 20. 03. 24 11:26, Krzysztof Kozlowski wrote:
> >>>>>> On 20/03/2024 11:04, Andrej Picej wrote:
> >>>>>>> Document calibration properties and how to set them.
> >>>>>>
> >>>>>> Bindings are before users.
> >>>>>
> >>>>> will change patch order when I send a v2.
> >>>>>
> >>>>>>
> >>>>>> Please use subject prefixes matching the subsystem. You can get them for
> >>>>>> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
> >>>>>> your patch is touching.
> >>>>>> There is no file extension in prefixes.
> >>>>>
> >>>>> So: dt-bindings: iio/adc: nxp,imx93-adc: Add calibration properties?
> >>>>
> >>>> Did you run the command I proposed? I don't see much of "/", but except
> >>>> that looks good.
> >>>
> >>> Ok noted.
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Signed-off-by: Andrej Picej <andrej.picej@norik.com>
> >>>>>>> ---
> >>>>>>> .../bindings/iio/adc/nxp,imx93-adc.yaml | 15 +++++++++++++++
> >>>>>>> 1 file changed, 15 insertions(+)
> >>>>>>>
> >>>>>>> diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
> >>>>>>> index dacc526dc695..64958be62a6a 100644
> >>>>>>> --- a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
> >>>>>>> +++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
> >>>>>>> @@ -46,6 +46,21 @@ properties:
> >>>>>>> "#io-channel-cells":
> >>>>>>> const: 1
> >>>>>>>
> >>>>>>> + nxp,calib-avg-en:
> >>>>>>> + description:
> >>>>>>> + Enable or disable averaging of calibration time.
> >>>>>>> + enum: [ 0, 1 ]
> >>>>>>> +
> >>>>>>> + nxp,calib-nr-samples:
> >>>>>>> + description:
> >>>>>>> + Selects the number of averaging samples to be used during calibration.
> >>>>>>> + enum: [ 16, 32, 128, 512 ]
> >>>>>>> +
> >>>>>>> + nxp,calib-t-samples:
> >>>>>>> + description:
> >>>>>>> + Specifies the sample time of calibration conversions.
> >>>>>>> + enum: [ 8, 16, 22, 32 ]
> >>>>>>
> >>>>>> No, use existing, generic properties. Open other bindings for this.
> >>>>>
> >>>>> You mean I should use generic properties for the ADC calibration
> >>>>> settings? Is there already something in place? Because as I understand
> >>>>> it, these calib-* values only effect the calibration process of the ADC.
> >>>>
> >>>> Please take a look at other devices and dtschema. We already have some
> >>>> properties for this... but maybe they cannot be used?
> >>>>
> >>>
> >>> I did look into other ADC devices, grep across iio/adc, adc bindings
> >>> folders and couldn't find anything closely related to what we are
> >>> looking for. Could you please point me to the properties that you think
> >>> should be used for this?
> >>
> >> Indeed, there are few device specific like qcom,avg-samples. We have
> >> though oversampling-ratio, settling-time-us and min-sample-time (which
> >> is not that good because does not use unit suffix).
> >
> > Ok, these are examples but I think I should not use them, since these
> > are i.MX93 ADC specific settings, which are used for configuration of
>
>
> No vendor prefix, so they rather should be generic, not imx93
> specific... But this the binding for imx93, so I don't understand your
> statement.
Based on my current understanding what we have here is not remotely
generic, so standard properties don't make sense (though naming the
nxp ones in a consistent fashion with other bindings is useful)
I'm not entirely convinced there is a strong argument to support them at all
though. Still thinking / gathering info on that.
>
> > calibration process, and are not related to the standard conversion
> > process during runtime. Calibration process is the first step that
> > should be done after every power-on reset.
> >
> >>
> >> Then follow up questions:
> >> - nxp,calib-avg-en: Why is it a board-level decision? I would assume
> >> this depends on user choice and what kind of input you have (which could
> >> be board dependent or could be runtime decision).
> >
> > Not really sure I get your question, so please elaborate if I missed the
> > point.
> > This is a user choice, to enable or disable the averaging function in
> > calibration, but this is a board-level decision, probably relates on
> > external ADC regulators and input connections. The same options are used
> > for every ADC channel and this can not be a runtime decision, since
> > calibration is done before the ADC is even registered.
>
> You now mix how Linux driver behaves with hardware. Why you cannot
> recalibrate later, e.g. when something else is being connected to the
> exposed pins?
Generally we don't make strong efforts to support dev board use cases where
the components wired tend to change. So normally this isn't too much of
a concern. Previously, we've tried to support this stuff and it always
ends up as a mess because of the crazy range of things that can be wired.
Jonathan
>
> Best regards,
> Krzysztof
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 04/16] dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on QCA6390
From: Kalle Valo @ 2024-03-25 14:37 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Liam Girdwood, Mark Brown, Catalin Marinas, Will Deacon,
Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven, Arnd Bergmann,
Neil Armstrong, Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov, linux-bluetooth, netdev,
devicetree, linux-kernel, linux-wireless, linux-arm-msm,
linux-arm-kernel, linux-pci, linux-pm, Bartosz Golaszewski,
ath11k, Johan Hovold
In-Reply-To: <CAMRc=Mc2Tc8oHr5NVo=aHAADkJtGCDAVvJs+7V-19m2zGi-vbw@mail.gmail.com>
Bartosz Golaszewski <brgl@bgdev.pl> writes:
> On Mon, Mar 25, 2024 at 2:57 PM Kalle Valo <kvalo@kernel.org> wrote:
>
>>
>> Bartosz Golaszewski <brgl@bgdev.pl> writes:
>>
>> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>> >
>> > Add a PCI compatible for the ATH11K module on QCA6390 and describe the
>> > power inputs from the PMU that it consumes.
>> >
>> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>
>> [...]
>>
>> > +allOf:
>> > + - if:
>> > + properties:
>> > + compatible:
>> > + contains:
>> > + const: pci17cb,1101
>> > + then:
>> > + required:
>> > + - vddrfacmn-supply
>> > + - vddaon-supply
>> > + - vddwlcx-supply
>> > + - vddwlmx-supply
>> > + - vddrfa0p8-supply
>> > + - vddrfa1p2-supply
>> > + - vddrfa1p7-supply
>> > + - vddpcie0p9-supply
>> > + - vddpcie1p8-supply
>>
>> I don't know DT well enough to know what the "required:" above means,
>> but does this take into account that there are normal "plug&play" type
>> of QCA6390 boards as well which don't need any DT settings?
>
> Do they require a DT node though for some reason?
You can attach the device to any PCI slot, connect the WLAN antenna and
it just works without DT nodes. I'm trying to make sure here that basic
setup still works.
Adding also Johan and ath11k list. For example, I don't know what's the
plan with Lenovo X13s, will it use this framework? I guess in theory we
could have devices which use qcom,ath11k-calibration-variant from DT but
not any of these supply properties?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH 4/4] arm64: dts: rockchip: Correct model name for Anbernic RGxx3 Devices
From: Chris Morgan @ 2024-03-25 14:37 UTC (permalink / raw)
To: linux-rockchip
Cc: devicetree, heiko, conor+dt, krzysztof.kozlowski+dt, robh,
Chris Morgan
In-Reply-To: <20240325143729.83852-1-macroalpha82@gmail.com>
From: Chris Morgan <macromorgan@hotmail.com>
Some Anbernic model names begin with the company "Anbernic" and others
simply list the model number. Make this consistent across the device
lineup by including the manufacturer in the model name.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353p.dts | 2 +-
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353ps.dts | 2 +-
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353v.dts | 2 +-
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353vs.dts | 2 +-
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353p.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353p.dts
index 94c678c44d3a..0df1254f89af 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353p.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353p.dts
@@ -8,7 +8,7 @@
#include "rk3566-anbernic-rg353x.dtsi"
/ {
- model = "RG353P";
+ model = "Anbernic RG353P";
compatible = "anbernic,rg353p", "rockchip,rk3566";
battery: battery {
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353ps.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353ps.dts
index 25edd81ce26b..b1fd2b0f6719 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353ps.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353ps.dts
@@ -8,7 +8,7 @@
#include "rk3566-anbernic-rg353x.dtsi"
/ {
- model = "RG353PS";
+ model = "Anbernic RG353PS";
compatible = "anbernic,rg353ps", "rockchip,rk3566";
battery: battery {
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353v.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353v.dts
index 5354c5958df2..9fa68cc53015 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353v.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353v.dts
@@ -8,7 +8,7 @@
#include "rk3566-anbernic-rg353x.dtsi"
/ {
- model = "RG353V";
+ model = "Anbernic RG353V";
compatible = "anbernic,rg353v", "rockchip,rk3566";
battery: battery {
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353vs.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353vs.dts
index 02653b59f6c2..78adac9fff58 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353vs.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353vs.dts
@@ -8,7 +8,7 @@
#include "rk3566-anbernic-rg353x.dtsi"
/ {
- model = "RG353VS";
+ model = "Anbernic RG353VS";
compatible = "anbernic,rg353vs", "rockchip,rk3566";
battery: battery {
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts
index e7161a86a9f1..b7e029a7039a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts
@@ -8,7 +8,7 @@
#include "rk3566-anbernic-rgxx3.dtsi"
/ {
- model = "RG503";
+ model = "Anbernic RG503";
compatible = "anbernic,rg503", "rockchip,rk3566";
adc-joystick {
--
2.34.1
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: rockchip: Correct RGxx3 SDMMC ordering
From: Chris Morgan @ 2024-03-25 14:37 UTC (permalink / raw)
To: linux-rockchip
Cc: devicetree, heiko, conor+dt, krzysztof.kozlowski+dt, robh,
Chris Morgan
In-Reply-To: <20240325143729.83852-1-macroalpha82@gmail.com>
From: Chris Morgan <macromorgan@hotmail.com>
Make the order of SDMMC predictable across the entire device lineup.
This allows userspace to always know that sdmmc0 is the eMMC (when
present), sdmmc1 is always the first sd card slot, sdmmc2 is always
the 2nd sd card slot (when present), and sdmmc3 is always the wifi
(when present).
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-d.dts | 7 -------
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-s.dts | 6 ------
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353p.dts | 7 -------
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353ps.dts | 6 ------
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353v.dts | 7 -------
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353vs.dts | 6 ------
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts | 6 ------
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi | 7 +++++++
8 files changed, 7 insertions(+), 45 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-d.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-d.dts
index ab83e8a61615..d239a8452957 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-d.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-d.dts
@@ -10,13 +10,6 @@
/ {
model = "Anbernic RG ARC-D";
compatible = "anbernic,rg-arc-d", "rockchip,rk3566";
-
- aliases {
- mmc0 = &sdhci;
- mmc1 = &sdmmc0;
- mmc2 = &sdmmc1;
- mmc3 = &sdmmc2;
- };
};
&i2c2 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-s.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-s.dts
index 6264a8c78d0b..4bb13d94a759 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-s.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg-arc-s.dts
@@ -10,10 +10,4 @@
/ {
model = "Anbernic RG ARC-S";
compatible = "anbernic,rg-arc-s", "rockchip,rk3566";
-
- aliases {
- mmc1 = &sdmmc0;
- mmc2 = &sdmmc1;
- mmc3 = &sdmmc2;
- };
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353p.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353p.dts
index 8aa93c646bec..94c678c44d3a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353p.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353p.dts
@@ -11,13 +11,6 @@ / {
model = "RG353P";
compatible = "anbernic,rg353p", "rockchip,rk3566";
- aliases {
- mmc0 = &sdhci;
- mmc1 = &sdmmc0;
- mmc2 = &sdmmc1;
- mmc3 = &sdmmc2;
- };
-
battery: battery {
compatible = "simple-battery";
charge-full-design-microamp-hours = <3472000>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353ps.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353ps.dts
index b211973e36c2..25edd81ce26b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353ps.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353ps.dts
@@ -11,12 +11,6 @@ / {
model = "RG353PS";
compatible = "anbernic,rg353ps", "rockchip,rk3566";
- aliases {
- mmc0 = &sdmmc0;
- mmc1 = &sdmmc1;
- mmc2 = &sdmmc2;
- };
-
battery: battery {
compatible = "simple-battery";
charge-full-design-microamp-hours = <3472000>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353v.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353v.dts
index f49ce29ba597..5354c5958df2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353v.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353v.dts
@@ -11,13 +11,6 @@ / {
model = "RG353V";
compatible = "anbernic,rg353v", "rockchip,rk3566";
- aliases {
- mmc0 = &sdhci;
- mmc1 = &sdmmc0;
- mmc2 = &sdmmc1;
- mmc3 = &sdmmc2;
- };
-
battery: battery {
compatible = "simple-battery";
charge-full-design-microamp-hours = <3151000>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353vs.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353vs.dts
index a7dc462fe21f..02653b59f6c2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353vs.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg353vs.dts
@@ -11,12 +11,6 @@ / {
model = "RG353VS";
compatible = "anbernic,rg353vs", "rockchip,rk3566";
- aliases {
- mmc0 = &sdmmc0;
- mmc1 = &sdmmc1;
- mmc2 = &sdmmc2;
- };
-
battery: battery {
compatible = "simple-battery";
charge-full-design-microamp-hours = <3151000>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts
index 94e6dd61a2db..e7161a86a9f1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dts
@@ -11,12 +11,6 @@ / {
model = "RG503";
compatible = "anbernic,rg503", "rockchip,rk3566";
- aliases {
- mmc0 = &sdmmc0;
- mmc1 = &sdmmc1;
- mmc2 = &sdmmc2;
- };
-
adc-joystick {
compatible = "adc-joystick";
io-channels = <&adc_mux 0>,
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi
index 233eade30f21..47c8fdc7c843 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi
@@ -12,6 +12,13 @@
/ {
chassis-type = "handset";
+ aliases {
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc0;
+ mmc2 = &sdmmc1;
+ mmc3 = &sdmmc2;
+ };
+
chosen: chosen {
stdout-path = "serial2:1500000n8";
};
--
2.34.1
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: rockchip: rgxx3: Add optional node for chasis-type
From: Chris Morgan @ 2024-03-25 14:37 UTC (permalink / raw)
To: linux-rockchip
Cc: devicetree, heiko, conor+dt, krzysztof.kozlowski+dt, robh,
Chris Morgan
In-Reply-To: <20240325143729.83852-1-macroalpha82@gmail.com>
From: Chris Morgan <macromorgan@hotmail.com>
Add optional node for chasis-type defining this device as a handset.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi
index c8fdb1b817f5..233eade30f21 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi
@@ -10,6 +10,8 @@
#include "rk3566.dtsi"
/ {
+ chassis-type = "handset";
+
chosen: chosen {
stdout-path = "serial2:1500000n8";
};
--
2.34.1
^ permalink raw reply related
* [PATCH 1/4] arm64: dts: rockchip: rgxx3: Add additional properties for WiFi
From: Chris Morgan @ 2024-03-25 14:37 UTC (permalink / raw)
To: linux-rockchip
Cc: devicetree, heiko, conor+dt, krzysztof.kozlowski+dt, robh,
Chris Morgan
In-Reply-To: <20240325143729.83852-1-macroalpha82@gmail.com>
From: Chris Morgan <macromorgan@hotmail.com>
Add additional properties for the SDMMC2 node. Based on user feedback
these help correct some issues with probing the WiFi hardware.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi
index 18b8c2e7befa..c8fdb1b817f5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi
@@ -623,9 +623,12 @@ &sdmmc2 {
cap-sdio-irq;
keep-power-in-suspend;
mmc-pwrseq = <&sdio_pwrseq>;
+ no-mmc;
+ no-sd;
non-removable;
pinctrl-0 = <&sdmmc2m0_bus4 &sdmmc2m0_cmd &sdmmc2m0_clk>;
pinctrl-names = "default";
+ sd-uhs-sdr50;
vmmc-supply = <&vcc_wifi>;
vqmmc-supply = <&vcca1v8_pmu>;
status = "okay";
--
2.34.1
^ permalink raw reply related
* [PATCH 0/4] User Requested Fixes for Anbernic RGxx3
From: Chris Morgan @ 2024-03-25 14:37 UTC (permalink / raw)
To: linux-rockchip
Cc: devicetree, heiko, conor+dt, krzysztof.kozlowski+dt, robh,
Chris Morgan
From: Chris Morgan <macromorgan@hotmail.com>
Users have requested fixes for Anbernic devices to help with some
intermittent WiFi issues by adding additional properties to the
SDMMC2 node and by making the sdmmc aliases consistent across the
device lineup. They have also requested that the model name be
represented consistently with both the manufacturer name and model
name.
I have added the new/additional property of "chasis-type" as well.
Chris Morgan (4):
arm64: dts: rockchip: rgxx3: Add additional properties for WiFi
arm64: dts: rockchip: rgxx3: Add optional node for chasis-type
arm64: dts: rockchip: Correct RGxx3 SDMMC ordering
arm64: dts: rockchip: Correct model name for Anbernic RGxx3 Devices
.../boot/dts/rockchip/rk3566-anbernic-rg-arc-d.dts | 7 -------
.../boot/dts/rockchip/rk3566-anbernic-rg-arc-s.dts | 6 ------
.../boot/dts/rockchip/rk3566-anbernic-rg353p.dts | 9 +--------
.../boot/dts/rockchip/rk3566-anbernic-rg353ps.dts | 8 +-------
.../boot/dts/rockchip/rk3566-anbernic-rg353v.dts | 9 +--------
.../boot/dts/rockchip/rk3566-anbernic-rg353vs.dts | 8 +-------
.../boot/dts/rockchip/rk3566-anbernic-rg503.dts | 8 +-------
.../boot/dts/rockchip/rk3566-anbernic-rgxx3.dtsi | 12 ++++++++++++
8 files changed, 17 insertions(+), 50 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: display: samsung,exynos5-dp: convert to DT Schema
From: Rob Herring @ 2024-03-25 14:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Inki Dae, devicetree, Seung-Woo Kim, linux-samsung-soc,
Conor Dooley, Alim Akhtar, Maxime Ripard, Maarten Lankhorst,
David Airlie, Daniel Vetter, Krzysztof Kozlowski, dri-devel,
linux-arm-kernel, Thomas Zimmermann, Kyungmin Park, linux-kernel
In-Reply-To: <20240313182855.14140-1-krzysztof.kozlowski@linaro.org>
On Wed, 13 Mar 2024 19:28:55 +0100, Krzysztof Kozlowski wrote:
> Convert Samsung Exynos5250/5420 SoC Display Port Controller bindings to
> DT schema with a change: add power-domains, already used in DTS.
>
> This Display Port controller is actually variant of Analogix Display
> Port bridge, however new DT Schema does not reference analogix,dp.yaml,
> because of incompatibilities in the driver. The analogix,dp.yaml
> expects two ports, input and output, but Linux Exynos DP DRM driver and
> DTS use only one port: output.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> ---
>
> Changes in v2:
> 1. Document deprecated samsung,hpd-gpios
> ---
> .../bindings/display/exynos/exynos_dp.txt | 112 ------------
> .../display/samsung/samsung,exynos5-dp.yaml | 163 ++++++++++++++++++
> 2 files changed, 163 insertions(+), 112 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> create mode 100644 Documentation/devicetree/bindings/display/samsung/samsung,exynos5-dp.yaml
>
Applied, thanks!
^ permalink raw reply
* [PATCH V2] arm64: dts: ti: k3-am625-beagleplay: Use mmc-pwrseq for wl18xx enable
From: Nishanth Menon @ 2024-03-25 14:35 UTC (permalink / raw)
To: Tero Kristo, Vignesh Raghavendra, Nishanth Menon
Cc: Robert Nelson, Conor Dooley, Krzysztof Kozlowski, Rob Herring,
linux-kernel, devicetree, linux-arm-kernel, Shengyu Qu,
Sukrut Bellary, Javier Martinez Canillas, Bill Mills
From: Sukrut Bellary <sukrut.bellary@linux.com>
BeaglePlay SBC[1] has Texas Instrument's WL18xx WiFi chipset[2].
Currently, WLAN_EN is configured as regulator and regulator-always-on.
However, the timing and wlan_en sequencing is not correctly modelled.
This causes the sdio access to fail during runtime-pm power operations
saving or during system suspend/resume/hibernation/freeze operations.
This is because the WLAN_EN line is not deasserted to low '0' to power
down the WiFi. So during restore, the WiFi driver tries to load the FW
without following correct power sequence. WLAN_EN => '1'/assert (high)
to power-up the chipset.
Use mmc-pwrseq-simple to drive TI's WiFi (WL18xx) chipset enable
'WLAN_EN'. mmc-pwrseq-simple provides power sequence flexibility with
support for post power-on and power-off delays.
Typical log signature that indicates this bug is:
wl1271_sdio mmc2:0001:2: sdio write failed (-110)
Followed by possibly a kernel warning (depending on firmware present):
WARNING: CPU: 1 PID: 45 at drivers/net/wireless/ti/wlcore/sdio.c:123 wl12xx_sdio_raw_write+0xe4/0x168 [wlcore_sdio]
[1] https://www.beagleboard.org/boards/beagleplay
[2] https://www.ti.com/lit/ds/symlink/wl1807mod.pdf
Fixes: f5a731f0787f ("arm64: dts: ti: Add k3-am625-beagleplay")
Suggested-by: Shengyu Qu <wiagn233@outlook.com>
Signed-off-by: Sukrut Bellary <sukrut.bellary@linux.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Picking this patch up since Sukrut was not able to refresh the patch in
the list and it does'nt make much sense to hold off this critical fixup.
Boot log:
https://gist.github.com/nmenon/a34abd03a6aaf84a39ffa569df248285
(includes defconfig change to make iwd work)
Changes Since v1:
* Update the power-on-time to 10ms (same as used in:
arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
)
* Add in-code documentation pointing at timing diagram for the values
used.
* Fixup fail log and commit message and make it generic to indicate
various other usecases of failure.
* Re-test on v6.9-rc1
V1: https://lore.kernel.org/all/20231213213219.566369-1-sukrut.bellary@linux.com/
.../arm64/boot/dts/ti/k3-am625-beagleplay.dts | 27 +++++++++----------
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts b/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
index a34e0df2ab86..ffc613543968 100644
--- a/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
+++ b/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
@@ -82,6 +82,17 @@ wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9db00000 {
};
};
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_en_pins_default>;
+ /* Interal power on time(Figure 8-3) * 2 */
+ post-power-on-delay-ms = <10>;
+ /* Re-enable time(Figure 8-2) + 20uS */
+ power-off-delay-us = <80>;
+ reset-gpios = <&main_gpio0 38 GPIO_ACTIVE_LOW>;
+ };
+
vsys_5v0: regulator-1 {
bootph-all;
compatible = "regulator-fixed";
@@ -104,20 +115,6 @@ vdd_3v3: regulator-2 {
regulator-boot-on;
};
- wlan_en: regulator-3 {
- /* OUTPUT of SN74AVC2T244DQMR */
- compatible = "regulator-fixed";
- regulator-name = "wlan_en";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- enable-active-high;
- regulator-always-on;
- vin-supply = <&vdd_3v3>;
- gpio = <&main_gpio0 38 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&wifi_en_pins_default>;
- };
-
vdd_3v3_sd: regulator-4 {
/* output of TPS22918DBVR-U21 */
bootph-all;
@@ -839,13 +836,13 @@ &sdhci1 {
};
&sdhci2 {
- vmmc-supply = <&wlan_en>;
pinctrl-names = "default";
pinctrl-0 = <&wifi_pins_default>, <&wifi_32k_clk>;
non-removable;
ti,fails-without-test-cd;
cap-power-off-card;
keep-power-in-suspend;
+ mmc-pwrseq = <&sdio_pwrseq>;
assigned-clocks = <&k3_clks 157 158>;
assigned-clock-parents = <&k3_clks 157 160>;
#address-cells = <1>;
base-commit: 4cece764965020c22cff7665b18a012006359095
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 02/16] regulator: dt-bindings: describe the PMU module of the WCN7850 package
From: Mark Brown @ 2024-03-25 14:34 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kalle Valo, Bjorn Andersson,
Konrad Dybcio, Liam Girdwood, Catalin Marinas, Will Deacon,
Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven, Arnd Bergmann,
Neil Armstrong, Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov, linux-bluetooth, netdev,
devicetree, linux-kernel, linux-wireless, linux-arm-msm,
linux-arm-kernel, linux-pci, linux-pm, Bartosz Golaszewski
In-Reply-To: <20240325131624.26023-3-brgl@bgdev.pl>
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
On Mon, Mar 25, 2024 at 02:16:10PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> The WCN7850 package contains discreet modules for WLAN and Bluetooth. They
> are powered by the Power Management Unit (PMU) that takes inputs from the
> host and provides LDO outputs. Extend the bindings for QCA6390 to also
> document this model.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v6 01/16] regulator: dt-bindings: describe the PMU module of the QCA6390 package
From: Mark Brown @ 2024-03-25 14:33 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kalle Valo, Bjorn Andersson,
Konrad Dybcio, Liam Girdwood, Catalin Marinas, Will Deacon,
Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven, Arnd Bergmann,
Neil Armstrong, Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov, linux-bluetooth, netdev,
devicetree, linux-kernel, linux-wireless, linux-arm-msm,
linux-arm-kernel, linux-pci, linux-pm, Bartosz Golaszewski
In-Reply-To: <20240325131624.26023-2-brgl@bgdev.pl>
[-- Attachment #1: Type: text/plain, Size: 407 bytes --]
On Mon, Mar 25, 2024 at 02:16:09PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> The QCA6390 package contains discreet modules for WLAN and Bluetooth. They
> are powered by the Power Management Unit (PMU) that takes inputs from the
> host and provides LDO outputs. This document describes this module.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RESEND PATCH] dt-bindings: display: sony,td4353-jdi: allow width-mm and height-mm
From: Rob Herring @ 2024-03-25 14:33 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Konrad Dybcio, Krzysztof Kozlowski, Neil Armstrong, dri-devel,
linux-kernel, Daniel Vetter, Maarten Lankhorst, devicetree,
Thomas Zimmermann, Jessica Zhang, Sam Ravnborg, David Airlie,
Maxime Ripard, Conor Dooley, Conor Dooley
In-Reply-To: <20240325103227.27474-1-krzysztof.kozlowski@linaro.org>
On Mon, 25 Mar 2024 11:32:27 +0100, Krzysztof Kozlowski wrote:
> Allow width and height properties from panel-common.yaml, already used
> on some boards:
>
> sdm845-sony-xperia-tama-apollo.dtb: panel@0: 'height-mm', 'width-mm' do not match any of the regexes: 'pinctrl-[0-9]+'
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
>
> Rob, could you pick up this one? Was on the list for almost a year.
>
>
> .../devicetree/bindings/display/panel/sony,td4353-jdi.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Applied, thanks!
^ permalink raw reply
* [PATCH 2/4] dt-bindings: arm: rockchip: add wolfvision pf5 mainboard
From: Michael Riesch @ 2024-03-25 14:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
Michael Riesch
In-Reply-To: <20240325-feature-wolfvision-pf5-v1-0-5725445f792a@wolfvision.net>
Add the WolfVision PF5 mainboard, which serves as base for recent
WolfVision products. It features the Rockchip RK3568 SoC and can
be extended with several different extension boards.
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index fcf7316ecd74..99bd5e2c76a0 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -927,6 +927,11 @@ properties:
- const: turing,rk1
- const: rockchip,rk3588
+ - description: WolfVision PF5 mainboard
+ items:
+ - const: wolfvision,rk3568-pf5
+ - const: rockchip,rk3568
+
- description: Xunlong Orange Pi 5 Plus
items:
- const: xunlong,orangepi-5-plus
--
2.34.1
^ permalink raw reply related
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