* Re: [PATCH v5 1/7] iio: accel: adxl345: Make data_range obsolete
From: Lothar Rubusch @ 2024-03-29 0:03 UTC (permalink / raw)
To: Jonathan Cameron
Cc: lars, Michael.Hennerich, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-iio, devicetree, linux-kernel, eraretuya
In-Reply-To: <20240328133720.7dfd46b0@jic23-huawei>
On Thu, Mar 28, 2024 at 2:37 PM Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Wed, 27 Mar 2024 22:03:14 +0000
> Lothar Rubusch <l.rubusch@gmail.com> wrote:
>
> > Replace write() data_format by regmap_update_bits(), because bus specific
> > pre-configuration may have happened before on the same register. For
> > further updates to the data_format register then bus pre-configuration
> > needs to be masked out.
> >
> > Remove the data_range field from the struct adxl345_data, because it is
> > not used anymore.
> >
> > Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> > ---
> > drivers/iio/accel/adxl345_core.c | 18 ++++++++++++------
> > 1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/iio/accel/adxl345_core.c b/drivers/iio/accel/adxl345_core.c
> > index 8bd30a23e..35df5e372 100644
> > --- a/drivers/iio/accel/adxl345_core.c
> > +++ b/drivers/iio/accel/adxl345_core.c
> > @@ -37,7 +37,15 @@
> > #define ADXL345_POWER_CTL_MEASURE BIT(3)
> > #define ADXL345_POWER_CTL_STANDBY 0x00
> >
> > +#define ADXL345_DATA_FORMAT_RANGE GENMASK(1, 0) /* Set the g range */
> > +#define ADXL345_DATA_FORMAT_JUSTIFY BIT(2) /* Left-justified (MSB) mode */
> > #define ADXL345_DATA_FORMAT_FULL_RES BIT(3) /* Up to 13-bits resolution */
> > +#define ADXL345_DATA_FORMAT_SELF_TEST BIT(7) /* Enable a self test */
> > +#define ADXL345_DATA_FORMAT_MSK (ADXL345_DATA_FORMAT_RANGE | \
> > + ADXL345_DATA_FORMAT_JUSTIFY | \
> > + ADXL345_DATA_FORMAT_FULL_RES | \
> > + ADXL345_DATA_FORMAT_SELF_TEST)
> This needs renaming. It's not a mask of everything in the register, or
> even just of everything related to format.
>
> Actually I'd just not have this definition. Use the build up value
> from all the submasks at the call site. Then we are just making it clear
> only a subset of fields are being cleared.
>
I understand this solution was not very useful. I'm not sure, I
understood you correctly. Please have a look into v6 if this matches
your comment.
Now, I remove the mask, instead I use a local variable in core's
probe() for the update mask. I added a comment. Nevertheless, I keep
the used flags for FORMAT_DATA. Does this go into the direction of
using the build up value from the submasks at the call site?
> Jonathan
>
> > +
> > #define ADXL345_DATA_FORMAT_2G 0
> > #define ADXL345_DATA_FORMAT_4G 1
> > #define ADXL345_DATA_FORMAT_8G 2
> > @@ -48,7 +56,6 @@
> > struct adxl345_data {
> > const struct adxl345_chip_info *info;
> > struct regmap *regmap;
> > - u8 data_range;
> > };
> >
> > #define ADXL345_CHANNEL(index, axis) { \
> > @@ -218,15 +225,14 @@ int adxl345_core_probe(struct device *dev, struct regmap *regmap)
> >
> > data = iio_priv(indio_dev);
> > data->regmap = regmap;
> > - /* Enable full-resolution mode */
> > - data->data_range = ADXL345_DATA_FORMAT_FULL_RES;
> > data->info = device_get_match_data(dev);
> > if (!data->info)
> > return -ENODEV;
> >
> > - ret = regmap_write(data->regmap, ADXL345_REG_DATA_FORMAT,
> > - data->data_range);
> > - if (ret < 0)
> > + /* Enable full-resolution mode */
> > + ret = regmap_update_bits(regmap, ADXL345_REG_DATA_FORMAT,
> > + ADXL345_DATA_FORMAT_MSK, ADXL345_DATA_FORMAT_FULL_RES);
> > + if (ret)
> > return dev_err_probe(dev, ret, "Failed to set data range\n");
> >
> > indio_dev->name = data->info->name;
>
^ permalink raw reply
* Re: [PATCH v5 7/7] iio: accel: adxl345: Add spi-3wire option
From: Lothar Rubusch @ 2024-03-29 0:33 UTC (permalink / raw)
To: Jonathan Cameron
Cc: lars, Michael.Hennerich, robh+dt, krzysztof.kozlowski+dt,
conor+dt, linux-iio, devicetree, linux-kernel, eraretuya
In-Reply-To: <20240328133927.7e49f3bf@jic23-huawei>
On Thu, Mar 28, 2024 at 2:39 PM Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Wed, 27 Mar 2024 22:03:20 +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 | 2 ++
> > drivers/iio/accel/adxl345_spi.c | 12 +++++++++++-
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/accel/adxl345.h b/drivers/iio/accel/adxl345.h
> > index 4ea9341d4..e6bc3591c 100644
> > --- a/drivers/iio/accel/adxl345.h
> > +++ b/drivers/iio/accel/adxl345.h
> > @@ -30,6 +30,8 @@
> > #define ADXL345_POWER_CTL_MEASURE BIT(3)
> > #define ADXL345_POWER_CTL_STANDBY 0x00
> >
> > +#define ADXL345_DATA_FORMAT_SPI_3WIRE BIT(6) /* 3-wire SPI mode */
> > +
> > #define ADXL345_DATA_FORMAT_RANGE GENMASK(1, 0) /* Set the g range */
> > #define ADXL345_DATA_FORMAT_JUSTIFY BIT(2) /* Left-justified (MSB) mode */
> > #define ADXL345_DATA_FORMAT_FULL_RES BIT(3) /* Up to 13-bits resolution */
> > diff --git a/drivers/iio/accel/adxl345_spi.c b/drivers/iio/accel/adxl345_spi.c
> > index 1c0513bd3..f145d5c1d 100644
> > --- a/drivers/iio/accel/adxl345_spi.c
> > +++ b/drivers/iio/accel/adxl345_spi.c
> > @@ -20,6 +20,16 @@ static const struct regmap_config adxl345_spi_regmap_config = {
> > .read_flag_mask = BIT(7) | BIT(6),
> > };
> >
> > +static int adxl345_spi_setup(struct device *dev, struct regmap *regmap)
> > +{
> > + struct spi_device *spi = container_of(dev, struct spi_device, dev);
> > +
> > + if (spi->mode & SPI_3WIRE)
> > + return regmap_write(regmap, ADXL345_REG_DATA_FORMAT,
> > + ADXL345_DATA_FORMAT_SPI_3WIRE);
> Your earlier patch carefully (I think) left one or two fields alone, then
> this write just comes in and changes them. In particular INT_INVERT.
>
Why do you refer here to INT_INVERT? In this code above I try to set
SPI to 3 lines. Since this is a SPI configuration, i.e. bus specific,
it happens in adxl345_spi.c. Passing this function to the bus
independent adxl345_core.c file allows to configure the bus first.
Therefore, I'm using the update function in core masking out the SPI
filag.
My reason why I try to keep INT_INVERT out is different. There is
another driver for the same part in the kernel:
./drivers/input/misc/adxl34x.c - This is a input driver, using the
interrupts of the adxl345 for the input device implementation. I
assumed, that in the iio implementation there won't be interrupt
handling for the adx345, since it is not an input device. Does this
make sense?
> If it doesn't makes sense to write it there, either write that bit
> every time here, or leave it alone every time. Not decide on whether
> to write the bit based on SPI_3WIRE or not. As far as I know they
> are unconnected features.
>
I think I did not understand. Could you please specify a bit more?
When spi-3wire is configured in the DT it has to be parsed and handled
in the bus specific part, i.e. the adxl345_spi.c Therefore I configure
SPI_3WIRE there. I don't want to place SPI specific code in the core
file.
> > + return 0;
> > +}
> > +
> > static int adxl345_spi_probe(struct spi_device *spi)
> > {
> > struct regmap *regmap;
> > @@ -33,7 +43,7 @@ static int adxl345_spi_probe(struct spi_device *spi)
> > if (IS_ERR(regmap))
> > return dev_err_probe(&spi->dev, PTR_ERR(regmap), "Error initializing regmap\n");
> >
> > - return adxl345_core_probe(&spi->dev, regmap, NULL);
> > + return adxl345_core_probe(&spi->dev, regmap, adxl345_spi_setup);
> > }
> >
> > static const struct adxl345_chip_info adxl345_spi_info = {
>
^ permalink raw reply
* RE: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings
From: Klymenko, Anatoliy @ 2024-03-29 0:38 UTC (permalink / raw)
To: Krzysztof Kozlowski, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Simek, Michal, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab
Cc: Tomi Valkeinen, dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-media@vger.kernel.org
In-Reply-To: <c0d70ba9-34ef-4121-834d-4d107f03d7f0@linaro.org>
Hi Krzysztof,
Thank you for the feedback.
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Saturday, March 23, 2024 3:21 AM
> To: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; Maxime Ripard
> <mripard@kernel.org>; Thomas Zimmermann <tzimmermann@suse.de>;
> David Airlie <airlied@gmail.com>; Daniel Vetter <daniel@ffwll.ch>; Simek,
> Michal <michal.simek@amd.com>; Andrzej Hajda
> <andrzej.hajda@intel.com>; Neil Armstrong <neil.armstrong@linaro.org>;
> Robert Foss <rfoss@kernel.org>; Jonas Karlman <jonas@kwiboo.se>; Jernej
> Skrabec <jernej.skrabec@gmail.com>; Rob Herring <robh+dt@kernel.org>;
> Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley
> <conor+dt@kernel.org>; Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>; dri-
> devel@lists.freedesktop.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-
> media@vger.kernel.org
> Subject: Re: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> On 22/03/2024 20:12, Klymenko, Anatoliy wrote:
> > Hi Krzysztof,
> >
> > Thanks a lot for the review.
> >
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> >> Sent: Thursday, March 21, 2024 10:59 PM
> >> To: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>; Laurent Pinchart
> >> <laurent.pinchart@ideasonboard.com>; Maarten Lankhorst
> >> <maarten.lankhorst@linux.intel.com>; Maxime Ripard
> >> <mripard@kernel.org>; Thomas Zimmermann <tzimmermann@suse.de>;
> David
> >> Airlie <airlied@gmail.com>; Daniel Vetter <daniel@ffwll.ch>; Simek,
> >> Michal <michal.simek@amd.com>; Andrzej Hajda
> >> <andrzej.hajda@intel.com>; Neil Armstrong
> >> <neil.armstrong@linaro.org>; Robert Foss <rfoss@kernel.org>; Jonas
> >> Karlman <jonas@kwiboo.se>; Jernej Skrabec
> <jernej.skrabec@gmail.com>;
> >> Rob Herring <robh+dt@kernel.org>; Krzysztof Kozlowski
> >> <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley
> >> <conor+dt@kernel.org>; Mauro Carvalho Chehab <mchehab@kernel.org>
> >> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>; dri-
> >> devel@lists.freedesktop.org; linux-arm-kernel@lists.infradead.org;
> >> linux- kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-
> >> media@vger.kernel.org
> >> Subject: Re: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG
> >> bindings
> >>
> >> Caution: This message originated from an External Source. Use proper
> >> caution when opening attachments, clicking links, or responding.
> >>
> >>
> >> On 21/03/2024 21:43, Anatoliy Klymenko wrote:
> >>> diff --git a/include/dt-bindings/media/media-bus-format.h
> >>> b/include/dt-
> >> bindings/media/media-bus-format.h
> >>> new file mode 100644
> >>> index 000000000000..60fc6e11dabc
> >>> --- /dev/null
> >>> +++ b/include/dt-bindings/media/media-bus-format.h
> >>> @@ -0,0 +1,177 @@
> >>> +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */
> >>> +/*
> >>> + * Media Bus API header
> >>> + *
> >>> + * Copyright (C) 2009, Guennadi Liakhovetski
> >>> +<g.liakhovetski@gmx.de>
> >>> + *
> >>> + * This program is free software; you can redistribute it and/or
> >>> +modify
> >>> + * it under the terms of the GNU General Public License version 2
> >>> +as
> >>> + * published by the Free Software Foundation.
> >>
> >> That's not true. Your SPDX tells something entirely different.
> >>
> >
> > Thank you - I'll see how to fix it.
> >
> >> Anyway, you did not explain why you need to copy anything anywhere.
> >>
> >> Specifically, random hex values *are not bindings*.
> >>
> >
> > The same media bus format values are being used by the reference
> > driver in patch #9. And, as far as I know, we cannot use headers from
> > Linux API headers directly (at least I
>
> I don't understand what does it mean. You can use in your driver whatever
> headers you wish, I don't care about them.
>
>
> noticed the same pattern in ../dt-bindings/sdtv-standarts.h for instance).
> What would be the best approach to reusing the same defines on DT and
> driver sides from your point of view? Symlink maybe?
> >
>
> Wrap your messages to match mailing list discussion style. There are no
> defines used in DT. If there are, show me them in *THIS* or other
> *upstreamed* (being upstreamed) patchset.
>
Sorry, I didn't explain properly what I'm trying to achieve. I need to
create a DT node property that represents video signal format, one of
MEDIA_BUS_FMT_* from include/uapi/linux/media-bus-format.h. It would be
nice to reuse the same symbolic values in the device tree. What is the
best approach here? Should I create a separate header in
include/dt-bindings with the same or similar (to avoid multiple
definition errors) defines, or is it better to create a symlink to
media-bus-format.h like include/dt-bindings/linux-event-codes.h?
> Whatever you have out of tree or "DO NOT MERGE" does not matter and
> does not justify anything.
>
>
> Best regards,
> Krzysztof
Thank you,
Anatoliy
^ permalink raw reply
* [PATCH v6 0/7] iio: accel: adxl345: Add spi-3wire feature
From: Lothar Rubusch @ 2024-03-29 0:40 UTC (permalink / raw)
To: lars, Michael.Hennerich, jic23, robh+dt, krzysztof.kozlowski+dt,
conor+dt
Cc: linux-iio, devicetree, linux-kernel, eraretuya, l.rubusch
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.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
V1 -> V2: Split into spi-3wire and refactoring
V2 -> V3: Split further, focus on needed changesets
V3 -> V4: Drop "Remove single info instances";
split "Group bus configuration" into separat
comment patch; reorder patch set
V4 -> V5: Refrase comments; Align comments to 75; rebuild FORMAT_MASK by
available flags; fix indention
V5 -> V6: Remove FORMAT_MASK by a local variable on call site;
Refrase comments;
Remove unneeded include
Lothar Rubusch (7):
iio: accel: adxl345: Make data_range obsolete
iio: accel: adxl345: Group bus configuration
iio: accel: adxl345: Move defines to header
dt-bindings: iio: accel: adxl345: Add spi-3wire
iio: accel: adxl345: Pass function pointer to core
iio: accel: adxl345: Add comment to probe
iio: accel: adxl345: Add spi-3wire option
.../bindings/iio/accel/adi,adxl345.yaml | 2 +
drivers/iio/accel/adxl345.h | 36 +++++++++-
drivers/iio/accel/adxl345_core.c | 72 +++++++++----------
drivers/iio/accel/adxl345_i2c.c | 2 +-
drivers/iio/accel/adxl345_spi.c | 12 +++-
5 files changed, 84 insertions(+), 40 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH v6 1/7] iio: accel: adxl345: Make data_range obsolete
From: Lothar Rubusch @ 2024-03-29 0:40 UTC (permalink / raw)
To: lars, Michael.Hennerich, jic23, robh+dt, krzysztof.kozlowski+dt,
conor+dt
Cc: linux-iio, devicetree, linux-kernel, eraretuya, l.rubusch
In-Reply-To: <20240329004030.16153-1-l.rubusch@gmail.com>
Replace write() data_format by regmap_update_bits() to keep bus specific
pre-configuration which might have happened before on the same register.
The bus specific bits in data_format register then need to be masked out,
Remove the data_range field from the struct adxl345_data, because it is
not used anymore.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/iio/accel/adxl345_core.c | 26 +++++++++++++++++++-------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/iio/accel/adxl345_core.c b/drivers/iio/accel/adxl345_core.c
index 8bd30a23e..f4dec5ff1 100644
--- a/drivers/iio/accel/adxl345_core.c
+++ b/drivers/iio/accel/adxl345_core.c
@@ -37,7 +37,11 @@
#define ADXL345_POWER_CTL_MEASURE BIT(3)
#define ADXL345_POWER_CTL_STANDBY 0x00
-#define ADXL345_DATA_FORMAT_FULL_RES BIT(3) /* Up to 13-bits resolution */
+#define ADXL345_DATA_FORMAT_RANGE GENMASK(1, 0) /* Set the g range */
+#define ADXL345_DATA_FORMAT_JUSTIFY BIT(2) /* Left-justified (MSB) mode */
+#define ADXL345_DATA_FORMAT_FULL_RES BIT(3) /* Up to 13-bits resolution */
+#define ADXL345_DATA_FORMAT_SELF_TEST BIT(7) /* Enable a self test */
+
#define ADXL345_DATA_FORMAT_2G 0
#define ADXL345_DATA_FORMAT_4G 1
#define ADXL345_DATA_FORMAT_8G 2
@@ -48,7 +52,6 @@
struct adxl345_data {
const struct adxl345_chip_info *info;
struct regmap *regmap;
- u8 data_range;
};
#define ADXL345_CHANNEL(index, axis) { \
@@ -202,6 +205,7 @@ int adxl345_core_probe(struct device *dev, struct regmap *regmap)
struct adxl345_data *data;
struct iio_dev *indio_dev;
u32 regval;
+ unsigned int data_format_mask;
int ret;
ret = regmap_read(regmap, ADXL345_REG_DEVID, ®val);
@@ -218,15 +222,23 @@ int adxl345_core_probe(struct device *dev, struct regmap *regmap)
data = iio_priv(indio_dev);
data->regmap = regmap;
- /* Enable full-resolution mode */
- data->data_range = ADXL345_DATA_FORMAT_FULL_RES;
data->info = device_get_match_data(dev);
if (!data->info)
return -ENODEV;
- ret = regmap_write(data->regmap, ADXL345_REG_DATA_FORMAT,
- data->data_range);
- if (ret < 0)
+ /*
+ * Only allow updates of bus independent bits to the data_format
+ * register. Keep the bus specific pre-configuration.
+ */
+ data_format_mask = (ADXL345_DATA_FORMAT_RANGE |
+ ADXL345_DATA_FORMAT_JUSTIFY |
+ ADXL345_DATA_FORMAT_FULL_RES |
+ ADXL345_DATA_FORMAT_SELF_TEST);
+
+ /* Enable full-resolution mode */
+ ret = regmap_update_bits(regmap, ADXL345_REG_DATA_FORMAT,
+ data_format_mask, ADXL345_DATA_FORMAT_FULL_RES);
+ if (ret)
return dev_err_probe(dev, ret, "Failed to set data range\n");
indio_dev->name = data->info->name;
--
2.25.1
^ permalink raw reply related
* [PATCH v6 2/7] iio: accel: adxl345: Group bus configuration
From: Lothar Rubusch @ 2024-03-29 0:40 UTC (permalink / raw)
To: lars, Michael.Hennerich, jic23, robh+dt, krzysztof.kozlowski+dt,
conor+dt
Cc: linux-iio, devicetree, linux-kernel, eraretuya, l.rubusch
In-Reply-To: <20240329004030.16153-1-l.rubusch@gmail.com>
Group the indio_dev initialization and bus configuration for improved
readability.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/iio/accel/adxl345_core.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/accel/adxl345_core.c b/drivers/iio/accel/adxl345_core.c
index f4dec5ff1..78ac6ea54 100644
--- a/drivers/iio/accel/adxl345_core.c
+++ b/drivers/iio/accel/adxl345_core.c
@@ -226,6 +226,12 @@ int adxl345_core_probe(struct device *dev, struct regmap *regmap)
if (!data->info)
return -ENODEV;
+ indio_dev->name = data->info->name;
+ indio_dev->info = &adxl345_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->channels = adxl345_channels;
+ indio_dev->num_channels = ARRAY_SIZE(adxl345_channels);
+
/*
* Only allow updates of bus independent bits to the data_format
* register. Keep the bus specific pre-configuration.
@@ -241,12 +247,6 @@ int adxl345_core_probe(struct device *dev, struct regmap *regmap)
if (ret)
return dev_err_probe(dev, ret, "Failed to set data range\n");
- indio_dev->name = data->info->name;
- indio_dev->info = &adxl345_info;
- indio_dev->modes = INDIO_DIRECT_MODE;
- indio_dev->channels = adxl345_channels;
- indio_dev->num_channels = ARRAY_SIZE(adxl345_channels);
-
/* Enable measurement mode */
ret = adxl345_powerup(data->regmap);
if (ret < 0)
--
2.25.1
^ permalink raw reply related
* [PATCH v6 3/7] iio: accel: adxl345: Move defines to header
From: Lothar Rubusch @ 2024-03-29 0:40 UTC (permalink / raw)
To: lars, Michael.Hennerich, jic23, robh+dt, krzysztof.kozlowski+dt,
conor+dt
Cc: linux-iio, devicetree, linux-kernel, eraretuya, l.rubusch
In-Reply-To: <20240329004030.16153-1-l.rubusch@gmail.com>
Move defines from core to the header file. Keep the defines block together
in one location.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/iio/accel/adxl345.h | 32 ++++++++++++++++++++++++++++++++
drivers/iio/accel/adxl345_core.c | 32 --------------------------------
2 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/iio/accel/adxl345.h b/drivers/iio/accel/adxl345.h
index 284bd387c..732820d34 100644
--- a/drivers/iio/accel/adxl345.h
+++ b/drivers/iio/accel/adxl345.h
@@ -8,6 +8,38 @@
#ifndef _ADXL345_H_
#define _ADXL345_H_
+#define ADXL345_REG_DEVID 0x00
+#define ADXL345_REG_OFSX 0x1E
+#define ADXL345_REG_OFSY 0x1F
+#define ADXL345_REG_OFSZ 0x20
+#define ADXL345_REG_OFS_AXIS(index) (ADXL345_REG_OFSX + (index))
+#define ADXL345_REG_BW_RATE 0x2C
+#define ADXL345_REG_POWER_CTL 0x2D
+#define ADXL345_REG_DATA_FORMAT 0x31
+#define ADXL345_REG_DATAX0 0x32
+#define ADXL345_REG_DATAY0 0x34
+#define ADXL345_REG_DATAZ0 0x36
+#define ADXL345_REG_DATA_AXIS(index) \
+ (ADXL345_REG_DATAX0 + (index) * sizeof(__le16))
+
+#define ADXL345_BW_RATE GENMASK(3, 0)
+#define ADXL345_BASE_RATE_NANO_HZ 97656250LL
+
+#define ADXL345_POWER_CTL_MEASURE BIT(3)
+#define ADXL345_POWER_CTL_STANDBY 0x00
+
+#define ADXL345_DATA_FORMAT_RANGE GENMASK(1, 0) /* Set the g range */
+#define ADXL345_DATA_FORMAT_JUSTIFY BIT(2) /* Left-justified (MSB) mode */
+#define ADXL345_DATA_FORMAT_FULL_RES BIT(3) /* Up to 13-bits resolution */
+#define ADXL345_DATA_FORMAT_SELF_TEST BIT(7) /* Enable a self test */
+
+#define ADXL345_DATA_FORMAT_2G 0
+#define ADXL345_DATA_FORMAT_4G 1
+#define ADXL345_DATA_FORMAT_8G 2
+#define ADXL345_DATA_FORMAT_16G 3
+
+#define ADXL345_DEVID 0xE5
+
/*
* In full-resolution mode, scale factor is maintained at ~4 mg/LSB
* in all g ranges.
diff --git a/drivers/iio/accel/adxl345_core.c b/drivers/iio/accel/adxl345_core.c
index 78ac6ea54..2d229fa80 100644
--- a/drivers/iio/accel/adxl345_core.c
+++ b/drivers/iio/accel/adxl345_core.c
@@ -17,38 +17,6 @@
#include "adxl345.h"
-#define ADXL345_REG_DEVID 0x00
-#define ADXL345_REG_OFSX 0x1e
-#define ADXL345_REG_OFSY 0x1f
-#define ADXL345_REG_OFSZ 0x20
-#define ADXL345_REG_OFS_AXIS(index) (ADXL345_REG_OFSX + (index))
-#define ADXL345_REG_BW_RATE 0x2C
-#define ADXL345_REG_POWER_CTL 0x2D
-#define ADXL345_REG_DATA_FORMAT 0x31
-#define ADXL345_REG_DATAX0 0x32
-#define ADXL345_REG_DATAY0 0x34
-#define ADXL345_REG_DATAZ0 0x36
-#define ADXL345_REG_DATA_AXIS(index) \
- (ADXL345_REG_DATAX0 + (index) * sizeof(__le16))
-
-#define ADXL345_BW_RATE GENMASK(3, 0)
-#define ADXL345_BASE_RATE_NANO_HZ 97656250LL
-
-#define ADXL345_POWER_CTL_MEASURE BIT(3)
-#define ADXL345_POWER_CTL_STANDBY 0x00
-
-#define ADXL345_DATA_FORMAT_RANGE GENMASK(1, 0) /* Set the g range */
-#define ADXL345_DATA_FORMAT_JUSTIFY BIT(2) /* Left-justified (MSB) mode */
-#define ADXL345_DATA_FORMAT_FULL_RES BIT(3) /* Up to 13-bits resolution */
-#define ADXL345_DATA_FORMAT_SELF_TEST BIT(7) /* Enable a self test */
-
-#define ADXL345_DATA_FORMAT_2G 0
-#define ADXL345_DATA_FORMAT_4G 1
-#define ADXL345_DATA_FORMAT_8G 2
-#define ADXL345_DATA_FORMAT_16G 3
-
-#define ADXL345_DEVID 0xE5
-
struct adxl345_data {
const struct adxl345_chip_info *info;
struct regmap *regmap;
--
2.25.1
^ permalink raw reply related
* [PATCH v6 4/7] dt-bindings: iio: accel: adxl345: Add spi-3wire
From: Lothar Rubusch @ 2024-03-29 0:40 UTC (permalink / raw)
To: lars, Michael.Hennerich, jic23, robh+dt, krzysztof.kozlowski+dt,
conor+dt
Cc: linux-iio, devicetree, linux-kernel, eraretuya, l.rubusch,
Krzysztof Kozlowski
In-Reply-To: <20240329004030.16153-1-l.rubusch@gmail.com>
Add spi-3wire because the device allows to be configured for spi 3-wire
communication.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
index 07cacc3f6..280ed479e 100644
--- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
@@ -32,6 +32,8 @@ properties:
spi-cpol: true
+ spi-3wire: true
+
interrupts:
maxItems: 1
--
2.25.1
^ permalink raw reply related
* [PATCH v6 5/7] iio: accel: adxl345: Pass function pointer to core
From: Lothar Rubusch @ 2024-03-29 0:40 UTC (permalink / raw)
To: lars, Michael.Hennerich, jic23, robh+dt, krzysztof.kozlowski+dt,
conor+dt
Cc: linux-iio, devicetree, linux-kernel, eraretuya, l.rubusch
In-Reply-To: <20240329004030.16153-1-l.rubusch@gmail.com>
Provide a way for bus specific pre-configuration by adding a function
pointer argument to the driver core's probe() function, and keep
the driver core implementation bus independent.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/iio/accel/adxl345.h | 3 ++-
drivers/iio/accel/adxl345_core.c | 10 +++++++++-
drivers/iio/accel/adxl345_i2c.c | 2 +-
drivers/iio/accel/adxl345_spi.c | 2 +-
4 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/accel/adxl345.h b/drivers/iio/accel/adxl345.h
index 732820d34..e859c01d4 100644
--- a/drivers/iio/accel/adxl345.h
+++ b/drivers/iio/accel/adxl345.h
@@ -60,6 +60,7 @@ struct adxl345_chip_info {
int uscale;
};
-int adxl345_core_probe(struct device *dev, struct regmap *regmap);
+int adxl345_core_probe(struct device *dev, struct regmap *regmap,
+ int (*setup)(struct device*, struct regmap*));
#endif /* _ADXL345_H_ */
diff --git a/drivers/iio/accel/adxl345_core.c b/drivers/iio/accel/adxl345_core.c
index 2d229fa80..83d7e7d4e 100644
--- a/drivers/iio/accel/adxl345_core.c
+++ b/drivers/iio/accel/adxl345_core.c
@@ -168,7 +168,8 @@ static void adxl345_powerdown(void *regmap)
regmap_write(regmap, ADXL345_REG_POWER_CTL, ADXL345_POWER_CTL_STANDBY);
}
-int adxl345_core_probe(struct device *dev, struct regmap *regmap)
+int adxl345_core_probe(struct device *dev, struct regmap *regmap,
+ int (*setup)(struct device*, struct regmap*))
{
struct adxl345_data *data;
struct iio_dev *indio_dev;
@@ -176,6 +177,13 @@ int adxl345_core_probe(struct device *dev, struct regmap *regmap)
unsigned int data_format_mask;
int ret;
+ /* Perform optional initial bus specific configuration */
+ if (setup) {
+ ret = setup(dev, regmap);
+ if (ret)
+ return ret;
+ }
+
ret = regmap_read(regmap, ADXL345_REG_DEVID, ®val);
if (ret < 0)
return dev_err_probe(dev, ret, "Error reading device ID\n");
diff --git a/drivers/iio/accel/adxl345_i2c.c b/drivers/iio/accel/adxl345_i2c.c
index a3084b0a8..4065b8f7c 100644
--- a/drivers/iio/accel/adxl345_i2c.c
+++ b/drivers/iio/accel/adxl345_i2c.c
@@ -27,7 +27,7 @@ static int adxl345_i2c_probe(struct i2c_client *client)
if (IS_ERR(regmap))
return dev_err_probe(&client->dev, PTR_ERR(regmap), "Error initializing regmap\n");
- return adxl345_core_probe(&client->dev, regmap);
+ return adxl345_core_probe(&client->dev, regmap, NULL);
}
static const struct adxl345_chip_info adxl345_i2c_info = {
diff --git a/drivers/iio/accel/adxl345_spi.c b/drivers/iio/accel/adxl345_spi.c
index 93ca349f1..1c0513bd3 100644
--- a/drivers/iio/accel/adxl345_spi.c
+++ b/drivers/iio/accel/adxl345_spi.c
@@ -33,7 +33,7 @@ static int adxl345_spi_probe(struct spi_device *spi)
if (IS_ERR(regmap))
return dev_err_probe(&spi->dev, PTR_ERR(regmap), "Error initializing regmap\n");
- return adxl345_core_probe(&spi->dev, regmap);
+ return adxl345_core_probe(&spi->dev, regmap, NULL);
}
static const struct adxl345_chip_info adxl345_spi_info = {
--
2.25.1
^ permalink raw reply related
* [PATCH v6 6/7] iio: accel: adxl345: Add comment to probe
From: Lothar Rubusch @ 2024-03-29 0:40 UTC (permalink / raw)
To: lars, Michael.Hennerich, jic23, robh+dt, krzysztof.kozlowski+dt,
conor+dt
Cc: linux-iio, devicetree, linux-kernel, eraretuya, l.rubusch
In-Reply-To: <20240329004030.16153-1-l.rubusch@gmail.com>
Add a comment to the probe() function to describe the passed function
pointer argument in particular.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/iio/accel/adxl345_core.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/iio/accel/adxl345_core.c b/drivers/iio/accel/adxl345_core.c
index 83d7e7d4e..511c27eb3 100644
--- a/drivers/iio/accel/adxl345_core.c
+++ b/drivers/iio/accel/adxl345_core.c
@@ -168,6 +168,16 @@ static void adxl345_powerdown(void *regmap)
regmap_write(regmap, ADXL345_REG_POWER_CTL, ADXL345_POWER_CTL_STANDBY);
}
+/**
+ * adxl345_core_probe() - probe and setup for the adxl345 accelerometer,
+ * also covers the adlx375 accelerometer
+ * @dev: Driver model representation of the device
+ * @regmap: Regmap instance for the device
+ * @setup: Setup routine to be executed right before the standard device
+ * setup
+ *
+ * Return: 0 on success, negative errno on error
+ */
int adxl345_core_probe(struct device *dev, struct regmap *regmap,
int (*setup)(struct device*, struct regmap*))
{
--
2.25.1
^ permalink raw reply related
* [PATCH v6 7/7] iio: accel: adxl345: Add spi-3wire option
From: Lothar Rubusch @ 2024-03-29 0:40 UTC (permalink / raw)
To: lars, Michael.Hennerich, jic23, robh+dt, krzysztof.kozlowski+dt,
conor+dt
Cc: linux-iio, devicetree, linux-kernel, eraretuya, l.rubusch
In-Reply-To: <20240329004030.16153-1-l.rubusch@gmail.com>
Add a setup function implementation to the spi module to enable spi-3wire
when specified in the device-tree.
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
drivers/iio/accel/adxl345.h | 1 +
drivers/iio/accel/adxl345_spi.c | 12 +++++++++++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/accel/adxl345.h b/drivers/iio/accel/adxl345.h
index e859c01d4..3d5c8719d 100644
--- a/drivers/iio/accel/adxl345.h
+++ b/drivers/iio/accel/adxl345.h
@@ -31,6 +31,7 @@
#define ADXL345_DATA_FORMAT_RANGE GENMASK(1, 0) /* Set the g range */
#define ADXL345_DATA_FORMAT_JUSTIFY BIT(2) /* Left-justified (MSB) mode */
#define ADXL345_DATA_FORMAT_FULL_RES BIT(3) /* Up to 13-bits resolution */
+#define ADXL345_DATA_FORMAT_SPI_3WIRE BIT(6) /* 3-wire SPI mode */
#define ADXL345_DATA_FORMAT_SELF_TEST BIT(7) /* Enable a self test */
#define ADXL345_DATA_FORMAT_2G 0
diff --git a/drivers/iio/accel/adxl345_spi.c b/drivers/iio/accel/adxl345_spi.c
index 1c0513bd3..f145d5c1d 100644
--- a/drivers/iio/accel/adxl345_spi.c
+++ b/drivers/iio/accel/adxl345_spi.c
@@ -20,6 +20,16 @@ static const struct regmap_config adxl345_spi_regmap_config = {
.read_flag_mask = BIT(7) | BIT(6),
};
+static int adxl345_spi_setup(struct device *dev, struct regmap *regmap)
+{
+ struct spi_device *spi = container_of(dev, struct spi_device, dev);
+
+ if (spi->mode & SPI_3WIRE)
+ return regmap_write(regmap, ADXL345_REG_DATA_FORMAT,
+ ADXL345_DATA_FORMAT_SPI_3WIRE);
+ return 0;
+}
+
static int adxl345_spi_probe(struct spi_device *spi)
{
struct regmap *regmap;
@@ -33,7 +43,7 @@ static int adxl345_spi_probe(struct spi_device *spi)
if (IS_ERR(regmap))
return dev_err_probe(&spi->dev, PTR_ERR(regmap), "Error initializing regmap\n");
- return adxl345_core_probe(&spi->dev, regmap, NULL);
+ return adxl345_core_probe(&spi->dev, regmap, adxl345_spi_setup);
}
static const struct adxl345_chip_info adxl345_spi_info = {
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 1/2] V2 arm64: dts: qcom: Add support for Samsung Galaxy Z Fold5
From: Konrad Dybcio @ 2024-03-29 0:52 UTC (permalink / raw)
To: serdeliuk, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240329-v2-dts-add-support-for-samsung-galaxy-zfold5-v1-1-9a91e635cacc@yahoo.com>
On 29.03.2024 12:08 AM, Alexandru Marc Serdeliuc via B4 Relay wrote:
> From: Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
>
> Add support for Samsung Galaxy Z Fold5 (q5q) foldable phone
>
> Currently working features:
> - Framebuffer
> - UFS
> - i2c
> - Buttons
>
> Signed-off-by: Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
> ---
Your commit title now includes "V2". Move it inside the square braces the
next time around, so it's like [PATCH v3 1/2]. With b4, this should be done
automagically, though..
[...]
> +/ {
> + model = "Samsung Galaxy Z Fold5";
> + compatible = "samsung,q5q", "qcom,sm8550";
> + #address-cells = <0x02>;
> + #size-cells = <0x02>;
These two can go
[...]
> + reserved-memory {
> + /*
> + * The bootloader will only keep display hardware enabled
> + * if this memory region is named exactly 'splash_region'
> + */
Ouch.
[...]
> + vreg_l15b_1p8: ldo15 {
> + regulator-name = "vreg_l15b_1p8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + regulator-allow-set-load;
> + regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
> + RPMH_REGULATOR_MODE_HPM>;
> + regulator-always-on;
Any particular reason as to why?
[...]
> +&remoteproc_adsp {
> + firmware-name = "qcom/sm8550/adsp.mbn",
> + "qcom/sm8550/adsp_dtb.mbn";
> + status = "okay";
> +};
> +
> +&remoteproc_cdsp {
> + firmware-name = "qcom/sm8550/cdsp.mbn",
> + "qcom/sm8550/cdsp_dtb.mbn";
> + status = "okay";
> +};
> +
> +&remoteproc_mpss {
> + firmware-name = "qcom/sm8550/modem.mbn",
> + "qcom/sm8550/modem_dtb.mbn";
> + status = "okay";
Unless you stole one from the factory, these firmwares will not
load on your phone..
> +};
> +
> +&sleep_clk {
> + clock-frequency = <32000>;
> +};
> +
> +&tlmm {
> + gpio-reserved-ranges = <36 4>, <50 2>;
Would you have an idea what these GPIOs are used for?
Konrad
^ permalink raw reply
* Re: [PATCH 2/2] v2 arm64: dts: qcom: Add support for Samsung Galaxy Z Fold5
From: Konrad Dybcio @ 2024-03-29 0:54 UTC (permalink / raw)
To: serdeliuk, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240329-v2-dts-add-support-for-samsung-galaxy-zfold5-v1-2-9a91e635cacc@yahoo.com>
On 29.03.2024 12:08 AM, Alexandru Marc Serdeliuc via B4 Relay wrote:
> From: Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
>
> Add support for Samsung Galaxy Z Fold5 (q5q) foldable phone
>
> Currently working features:
> - Framebuffer
> - UFS
> - i2c
> - Buttons
>
> Signed-off-by: Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
> ---
Looks like the commit message and contents got mixed up!
Konrad
^ permalink raw reply
* Re: [net-next,v4 0/2] ravb: Support describing the MDIO bus
From: patchwork-bot+netdevbpf @ 2024-03-29 1:30 UTC (permalink / raw)
To: =?utf-8?q?Niklas_S=C3=B6derlund_=3Cniklas=2Esoderlund+renesas=40ragnatech=2E?=,
=?utf-8?q?se=3E?=
Cc: s.shtylyov, davem, edumazet, kuba, pabeni, robh+dt,
krzysztof.kozlowski+dt, conor+dt, geert+renesas,
claudiu.beznea.uj, yoshihiro.shimoda.uh, biju.das.jz, netdev,
devicetree, linux-renesas-soc
In-Reply-To: <20240325153451.2366083-1-niklas.soderlund+renesas@ragnatech.se>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 25 Mar 2024 16:34:49 +0100 you wrote:
> Hello,
>
> This series adds support to the binding and driver of the Renesas
> Ethernet AVB to described the MDIO bus. Currently the driver uses the OF
> node of the device itself when registering the MDIO bus. This forces any
> MDIO bus properties the MDIO core should react on to be set on the
> device OF node. This is confusing and non of the MDIO bus properties are
> described in the Ethernet AVB bindings.
>
> [...]
Here is the summary with links:
- [net-next,v4,1/2] dt-bindings: net: renesas,etheravb: Add optional MDIO bus node
https://git.kernel.org/netdev/net-next/c/a87590c45c87
- [net-next,v4,2/2] ravb: Add support for an optional MDIO mode
https://git.kernel.org/netdev/net-next/c/2c60c4c008d4
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 2/6] arm64: dts: qcom: qcs6490-rb3gen2: Add DP output
From: Bjorn Andersson @ 2024-03-29 1:37 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, cros-qcom-dts-watchers, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <CAA8EJppCuoOnaB03GsjXGYSs5Q9iQ2uXHWQqfkPA5jKzdHc8NQ@mail.gmail.com>
On Thu, Mar 28, 2024 at 09:17:45AM +0200, Dmitry Baryshkov wrote:
> On Thu, 28 Mar 2024 at 05:07, Bjorn Andersson <andersson@kernel.org> wrote:
> >
> > On Thu, Mar 28, 2024 at 03:51:54AM +0200, Dmitry Baryshkov wrote:
> > > On Wed, 27 Mar 2024 at 04:04, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
> > > >
> > > > The RB3Gen2 board comes with a mini DP connector, describe this, enable
> > > > MDSS, DP controller and the PHY that drives this.
> > > >
> > > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> > > > ---
> > > > arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 40 ++++++++++++++++++++++++++++
> > > > 1 file changed, 40 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > index 63ebe0774f1d..f90bf3518e98 100644
> > > > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > @@ -39,6 +39,20 @@ chosen {
> > > > stdout-path = "serial0:115200n8";
> > > > };
> > > >
> > > > + dp-connector {
> > > > + compatible = "dp-connector";
> > > > + label = "DP";
> > > > + type = "mini";
> > > > +
> > > > + hpd-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
> > >
> > > Is it the standard hpd gpio? If so, is there any reason for using it
> > > through dp-connector rather than as a native HPD signal?
> > >
> >
> > I added it because you asked for it. That said, I do like having it
> > clearly defined in the devicetree.
>
> I asked for the dp-connector device, not for the HPD function change.
>
I didn't realize that you could have a dp-connector device without
defining the hpd-gpios, but it looks like you're right.
Do we have any reason for using the internal HPD, when we're already
spending the memory to allocate the dp-connector device?
PS. It's recommended that you dynamically switch to GPIO-based HPD in
lower-power scenarios, as this allow you to turn off the DP controller
and still detect plug events...
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v2 2/6] arm64: dts: qcom: qcs6490-rb3gen2: Add DP output
From: Dmitry Baryshkov @ 2024-03-29 1:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Bjorn Andersson, cros-qcom-dts-watchers, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20240329013743.GA3476498@hu-bjorande-lv.qualcomm.com>
On Fri, 29 Mar 2024 at 03:37, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
>
> On Thu, Mar 28, 2024 at 09:17:45AM +0200, Dmitry Baryshkov wrote:
> > On Thu, 28 Mar 2024 at 05:07, Bjorn Andersson <andersson@kernel.org> wrote:
> > >
> > > On Thu, Mar 28, 2024 at 03:51:54AM +0200, Dmitry Baryshkov wrote:
> > > > On Wed, 27 Mar 2024 at 04:04, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
> > > > >
> > > > > The RB3Gen2 board comes with a mini DP connector, describe this, enable
> > > > > MDSS, DP controller and the PHY that drives this.
> > > > >
> > > > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> > > > > ---
> > > > > arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 40 ++++++++++++++++++++++++++++
> > > > > 1 file changed, 40 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > > index 63ebe0774f1d..f90bf3518e98 100644
> > > > > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > > @@ -39,6 +39,20 @@ chosen {
> > > > > stdout-path = "serial0:115200n8";
> > > > > };
> > > > >
> > > > > + dp-connector {
> > > > > + compatible = "dp-connector";
> > > > > + label = "DP";
> > > > > + type = "mini";
> > > > > +
> > > > > + hpd-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
> > > >
> > > > Is it the standard hpd gpio? If so, is there any reason for using it
> > > > through dp-connector rather than as a native HPD signal?
> > > >
> > >
> > > I added it because you asked for it. That said, I do like having it
> > > clearly defined in the devicetree.
> >
> > I asked for the dp-connector device, not for the HPD function change.
> >
>
> I didn't realize that you could have a dp-connector device without
> defining the hpd-gpios, but it looks like you're right.
>
> Do we have any reason for using the internal HPD, when we're already
> spending the memory to allocate the dp-connector device?
No, no particular reason. I was trying to understand if there was any
reason for that from your side.
Then:
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> PS. It's recommended that you dynamically switch to GPIO-based HPD in
> lower-power scenarios, as this allow you to turn off the DP controller
> and still detect plug events...
I don't think rb3g2 is a low-power device, but I think this is still a
valid argument.
--
With best wishes
Dmitry
^ permalink raw reply
* [RFC PATCH 1/2] spi: dt-bindings: add Siflower Quad SPI controller
From: Qingfang Deng @ 2024-03-29 1:51 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Qingfang Deng, linux-spi, devicetree, linux-kernel
From: Qingfang Deng <qingfang.deng@siflower.com.cn>
Add YAML devicetree bindings for Siflower Quad SPI controller.
Signed-off-by: Qingfang Deng <qingfang.deng@siflower.com.cn>
---
.../bindings/spi/siflower,qspi.yaml | 54 +++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/siflower,qspi.yaml
diff --git a/Documentation/devicetree/bindings/spi/siflower,qspi.yaml b/Documentation/devicetree/bindings/spi/siflower,qspi.yaml
new file mode 100644
index 000000000000..c2dbe82affc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/siflower,qspi.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/siflower,qspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Siflower Quad Serial Peripheral Interface (QSPI)
+
+maintainers:
+ - Qingfang Deng <qingfang.deng@siflower.com.cn>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: siflower,qspi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#address-cells'
+ - '#size-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi@c200000 {
+ compatible = "siflower,qspi";
+ reg = <0 0xc200000 0 0x1000>;
+ clocks = <&apb_clk>;
+ interrupts = <39>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
--
2.34.1
^ permalink raw reply related
* [RFC PATCH 2/2] spi: add Siflower Quad SPI controller
From: Qingfang Deng @ 2024-03-29 1:51 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-spi, devicetree, linux-kernel
Cc: Qingfang Deng
In-Reply-To: <20240329015147.1481349-1-dqfext@gmail.com>
From: Qingfang Deng <qingfang.deng@siflower.com.cn>
Add Quad SPI controller driver for Siflower SoCs. It is based on ARM
PL022, with custom modifications to support Dual/Quad SPI modes.
Signed-off-by: Qingfang Deng <qingfang.deng@siflower.com.cn>
---
drivers/spi/Kconfig | 6 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-siflower-qspi.c | 414 ++++++++++++++++++++++++++++++++
3 files changed, 421 insertions(+)
create mode 100644 drivers/spi/spi-siflower-qspi.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index bc7021da2fe9..5e3a6b431a12 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -952,6 +952,12 @@ config SPI_SIFIVE
help
This exposes the SPI controller IP from SiFive.
+config SPI_SIFLOWER_QSPI
+ tristate "Siflower Quad SPI Controller"
+ depends on OF && SPI_MEM
+ help
+ Quad SPI driver for Siflower SoCs.
+
config SPI_SLAVE_MT27XX
tristate "MediaTek SPI slave device"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 4ff8d725ba5e..226aebe80a3d 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -126,6 +126,7 @@ obj-$(CONFIG_SPI_SH_HSPI) += spi-sh-hspi.o
obj-$(CONFIG_SPI_SH_MSIOF) += spi-sh-msiof.o
obj-$(CONFIG_SPI_SH_SCI) += spi-sh-sci.o
obj-$(CONFIG_SPI_SIFIVE) += spi-sifive.o
+obj-$(CONFIG_SPI_SIFLOWER_QSPI) += spi-siflower-qspi.o
obj-$(CONFIG_SPI_SLAVE_MT27XX) += spi-slave-mt27xx.o
obj-$(CONFIG_SPI_SN_F_OSPI) += spi-sn-f-ospi.o
obj-$(CONFIG_SPI_SPRD) += spi-sprd.o
diff --git a/drivers/spi/spi-siflower-qspi.c b/drivers/spi/spi-siflower-qspi.c
new file mode 100644
index 000000000000..fd814de4bc4e
--- /dev/null
+++ b/drivers/spi/spi-siflower-qspi.c
@@ -0,0 +1,414 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/sh_clk.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/jiffies.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/sizes.h>
+
+#include <linux/spi/spi-mem.h>
+#include <linux/spi/spi.h>
+
+/*
+ * siflower SSP fifo level
+ * */
+#define SF_SSP_FIFO_LEVEL 0x100
+/*
+ * siflower SSP register
+ * */
+#define SSP_CR0 0x000
+#define SSP_CR1 0x004
+#define SSP_DR 0x008
+#define SSP_SR 0x00C
+#define SSP_CPSR 0x010
+#define SSP_IMSC 0x014
+#define SSP_RIS 0x018
+#define SSP_MIS 0x01C
+#define SSP_ICR 0x020
+#define SSP_DMACR 0x024
+#define SSP_FIFO_LEVEL 0x028
+#define SSP_EXSPI_CMD0 0x02C
+#define SSP_EXSPI_CMD1 0x030
+#define SSP_EXSPI_CMD2 0x034
+/* SSP Control Register 0 - SSP_CR0 */
+#define SSP_CR0_EXSPI_FRAME (0x3 << 4)
+#define SSP_CR0_SPO (0x1 << 6)
+#define SSP_CR0_SPH (0x1 << 7)
+#define SSP_CR0_BIT_MODE(x) ((x)-1)
+#define SSP_SCR_MIN (0x00)
+#define SSP_SCR_MAX (0xFF)
+#define SSP_SCR_SHFT 8
+#define DFLT_CLKRATE 2
+/* SSP Control Register 1 - SSP_CR1 */
+#define SSP_CR1_MASK_SSE (0x1 << 1)
+#define SSP_CPSR_MIN (0x02)
+#define SSP_CPSR_MAX (0xFE)
+#define DFLT_PRESCALE (0x40)
+/* SSP Status Register - SSP_SR */
+#define SSP_SR_MASK_TFE (0x1 << 0) /* Transmit FIFO empty */
+#define SSP_SR_MASK_TNF (0x1 << 1) /* Transmit FIFO not full */
+#define SSP_SR_MASK_RNE (0x1 << 2) /* Receive FIFO not empty */
+#define SSP_SR_MASK_RFF (0x1 << 3) /* Receive FIFO full */
+#define SSP_SR_MASK_BSY (0x1 << 4) /* Busy Flag */
+
+/* SSP FIFO Threshold Register - SSP_FIFO_LEVEL */
+#define SSP_FIFO_LEVEL_RX GENMASK(14, 8) /* Receive FIFO watermark */
+#define SSP_FIFO_LEVEL_TX GENMASK(6, 0) /* Transmit FIFO watermark */
+#define DFLT_THRESH_RX 32
+#define DFLT_THRESH_TX 32
+
+/* SSP Raw Interrupt Status Register - SSP_RIS */
+#define SSP_RIS_MASK_RORRIS (0x1 << 0) /* Receive Overrun */
+#define SSP_RIS_MASK_RTRIS (0x1 << 1) /* Receive Timeout */
+#define SSP_RIS_MASK_RXRIS (0x1 << 2) /* Receive FIFO Raw Interrupt status */
+#define SSP_RIS_MASK_TXRIS (0x1 << 3) /* Transmit FIFO Raw Interrupt status */
+
+/* EXSPI command register 0 SSP_EXSPI_CMD0 */
+#define EXSPI_CMD0_CMD_COUNT BIT(0) /* cmd byte, must be set at last */
+#define EXSPI_CMD0_ADDR_COUNT GENMASK(2, 1) /* addr bytes */
+#define EXSPI_CMD0_EHC_COUNT BIT(3) /* Set 1 for 4-byte address mode */
+#define EXSPI_CMD0_TX_COUNT GENMASK(14, 4) /* TX data bytes */
+#define EXSPI_CMD0_VALID BIT(15) /* Set 1 to make the cmd to be run */
+
+/* EXSPI command register 1 SSP_EXSPI_CMD1 */
+#define EXSPI_CMD1_DUMMY_COUNT GENMASK(3, 0) /* dummy bytes */
+#define EXSPI_CMD1_RX_COUNT GENMASK(14, 4) /* RX data bytes */
+
+/* EXSPI command register 2 SSP_EXSPI_CMD2 */
+/* Set 1 for 1-wire, 2 for 2-wire, 3 for 4-wire */
+#define EXSPI_CMD2_CMD_IO_MODE GENMASK(1, 0) /* cmd IO mode */
+#define EXSPI_CMD2_ADDR_IO_MODE GENMASK(3, 2) /* addr IO mode */
+#define EXSPI_CMD2_DATA_IO_MODE GENMASK(5, 4) /* data IO mode */
+
+#define SF_READ_TIMEOUT (10 * HZ)
+#define MAX_S_BUF 100
+
+struct sf_qspi {
+ void __iomem *base;
+ struct clk *clk;
+ struct device *dev;
+ u32 freq;
+ int mode_bit;
+};
+
+static void sf_qspi_flush_rxfifo(struct sf_qspi *s) {
+ while (readw(s->base + SSP_SR) & SSP_SR_MASK_RNE)
+ readw(s->base + SSP_DR);
+}
+
+static int sf_qspi_wait_not_busy(struct sf_qspi *s) {
+ unsigned long timeout = jiffies + SF_READ_TIMEOUT;
+
+ do {
+ if (!(readw(s->base + SSP_SR) & SSP_SR_MASK_BSY))
+ return 0;
+
+ cond_resched();
+ } while (time_after(timeout, jiffies));
+
+ dev_err(s->dev, "I/O timed out\n");
+ return -ETIMEDOUT;
+}
+
+static int sf_qspi_wait_rx_not_empty(struct sf_qspi *s) {
+ unsigned long timeout = jiffies + SF_READ_TIMEOUT;
+
+ do {
+ if (readw(s->base + SSP_SR) & SSP_SR_MASK_RNE)
+ return 0;
+
+ cond_resched();
+ } while (time_after(timeout, jiffies));
+
+ dev_err(s->dev, "read timed out\n");
+ return -ETIMEDOUT;
+}
+
+static int sf_qspi_wait_rxfifo(struct sf_qspi *s) {
+ unsigned long timeout = jiffies + SF_READ_TIMEOUT;
+
+ do {
+ if (readw(s->base + SSP_RIS) & SSP_RIS_MASK_RXRIS)
+ return 0;
+
+ cond_resched();
+ } while (time_after(timeout, jiffies));
+
+ dev_err(s->dev, "read timed out\n");
+ return -ETIMEDOUT;
+}
+
+static void sf_qspi_enable(struct sf_qspi *s) {
+ /* Enable the SPI hardware */
+ writew(SSP_CR1_MASK_SSE, s->base + SSP_CR1);
+}
+
+static void sf_qspi_disable(struct sf_qspi *s) {
+ /* Disable the SPI hardware */
+ writew(0, s->base + SSP_CR1);
+}
+
+static void sf_qspi_xmit(struct sf_qspi *s, unsigned int nbytes, const u8 *out)
+{
+ while (nbytes--)
+ writew(*out++, s->base + SSP_DR);
+}
+
+static int sf_qspi_rcv(struct sf_qspi *s, unsigned int nbytes, u8 *in)
+{
+ int ret, i;
+
+ while (nbytes >= DFLT_THRESH_RX) {
+ /* wait for RX FIFO to reach the threshold */
+ ret = sf_qspi_wait_rxfifo(s);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < DFLT_THRESH_RX; i++)
+ *in++ = readw(s->base + SSP_DR);
+
+ nbytes -= DFLT_THRESH_RX;
+ }
+
+ /* read the remaining data */
+ while (nbytes) {
+ ret = sf_qspi_wait_rx_not_empty(s);
+ if (ret)
+ return ret;
+
+ *in++ = readw(s->base + SSP_DR);
+ nbytes--;
+ }
+
+ return 0;
+}
+
+static inline u32 spi_rate(u32 rate, u16 csdvsr, u16 scr) {
+ return rate / (csdvsr * (1 + scr));
+}
+
+static void sf_qspi_set_param(struct sf_qspi *s, const struct spi_mem_op *op) {
+ unsigned int tx_count = 0, rx_count = 0;
+ u8 cmd_io, addr_io, data_io;
+ u8 cmd_count, addr_count, ehc_count;
+
+ cmd_io = op->cmd.buswidth == 4 ? 3 : op->cmd.buswidth;
+ addr_io = op->addr.buswidth == 4 ? 3 : op->addr.buswidth;
+ data_io = op->data.buswidth == 4 ? 3 : op->data.buswidth;
+
+ if (op->data.nbytes) {
+ if (op->data.dir == SPI_MEM_DATA_IN) {
+ rx_count = op->data.nbytes;
+ } else {
+ tx_count = op->data.nbytes;
+ }
+ }
+ if (op->addr.nbytes > 3) {
+ addr_count = 3;
+ ehc_count = 1;
+ } else {
+ addr_count = op->addr.nbytes;
+ ehc_count = 0;
+ }
+ cmd_count = op->cmd.nbytes;
+
+ writew(FIELD_PREP(EXSPI_CMD2_CMD_IO_MODE, cmd_io) |
+ FIELD_PREP(EXSPI_CMD2_ADDR_IO_MODE, addr_io) |
+ FIELD_PREP(EXSPI_CMD2_DATA_IO_MODE, data_io),
+ s->base + SSP_EXSPI_CMD2);
+ writew(FIELD_PREP(EXSPI_CMD1_DUMMY_COUNT, op->dummy.nbytes) |
+ FIELD_PREP(EXSPI_CMD1_RX_COUNT, rx_count),
+ s->base + SSP_EXSPI_CMD1);
+ writew(EXSPI_CMD0_VALID |
+ FIELD_PREP(EXSPI_CMD0_CMD_COUNT, op->cmd.nbytes) |
+ FIELD_PREP(EXSPI_CMD0_ADDR_COUNT, addr_count) |
+ FIELD_PREP(EXSPI_CMD0_EHC_COUNT, ehc_count) |
+ FIELD_PREP(EXSPI_CMD0_TX_COUNT, tx_count),
+ s->base + SSP_EXSPI_CMD0);
+}
+
+static int sf_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+ struct sf_qspi *s = spi_controller_get_devdata(mem->spi->master);
+ unsigned int pops = 0;
+ int ret, i, op_len;
+ const u8 *tx_buf = NULL;
+ u8 *rx_buf = NULL, op_buf[MAX_S_BUF];
+
+ if (op->data.nbytes) {
+ if (op->data.dir == SPI_MEM_DATA_IN) {
+ rx_buf = op->data.buf.in;
+ } else {
+ tx_buf = op->data.buf.out;
+ }
+ }
+ op_len = op->cmd.nbytes + op->addr.nbytes + op->dummy.nbytes;
+ sf_qspi_set_param(s, op);
+ /*
+ * Avoid using malloc() here so that we can use this code in SPL where
+ * simple malloc may be used. That implementation does not allow free()
+ * so repeated calls to this code can exhaust the space.
+ *
+ * The value of op_len is small, since it does not include the actual
+ * data being sent, only the op-code and address. In fact, it should be
+ * popssible to just use a small fixed value here instead of op_len.
+ */
+ op_buf[pops++] = op->cmd.opcode;
+ if (op->addr.nbytes) {
+ for (i = 0; i < op->addr.nbytes; i++)
+ op_buf[pops + i] = op->addr.val >>
+ (8 * (op->addr.nbytes - i - 1));
+ pops += op->addr.nbytes;
+ }
+
+ sf_qspi_flush_rxfifo(s);
+ memset(op_buf + pops, 0xff, op->dummy.nbytes);
+ sf_qspi_xmit(s, op_len, op_buf);
+ if (tx_buf) {
+ sf_qspi_xmit(s, op->data.nbytes, tx_buf);
+ }
+ sf_qspi_enable(s);
+ if (rx_buf) {
+ ret = sf_qspi_rcv(s, op->data.nbytes, rx_buf);
+ } else {
+ ret = sf_qspi_wait_not_busy(s);
+ }
+ sf_qspi_disable(s);
+ return ret;
+}
+
+static int sf_qspi_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
+{
+ u32 nbytes;
+
+ nbytes = op->cmd.nbytes + op->addr.nbytes + op->dummy.nbytes;
+ if (nbytes >= SF_SSP_FIFO_LEVEL)
+ return -ENOTSUPP;
+
+ if (op->data.dir == SPI_MEM_DATA_IN)
+ op->data.nbytes = min_t(unsigned int, op->data.nbytes,
+ SF_SSP_FIFO_LEVEL);
+ else
+ op->data.nbytes = min_t(unsigned int, op->data.nbytes,
+ SF_SSP_FIFO_LEVEL - nbytes);
+
+ return 0;
+}
+
+static int sf_qspi_default_setup(struct sf_qspi *s) {
+ u16 scr = SSP_SCR_MIN, cr0 = 0, cpsr = SSP_CPSR_MIN, best_scr = scr, best_cpsr = cpsr;
+ u32 min, max, best_freq = 0, tmp;
+ u32 rate = clk_get_rate(s->clk), speed = s->freq;
+ bool found = false;
+
+ writew(DFLT_PRESCALE, s->base + SSP_CPSR);
+
+ max = spi_rate(rate, SSP_CPSR_MIN, SSP_SCR_MIN);
+ min = spi_rate(rate, SSP_CPSR_MAX, SSP_SCR_MAX);
+
+ if (speed > max || speed < min) {
+ dev_err(s->dev, "Tried to set speed to %dHz but min=%d and max=%d\n", speed, min, max);
+ return -EINVAL;
+ }
+ while (cpsr <= SSP_CPSR_MAX && !found) {
+ while (scr <= SSP_SCR_MAX) {
+ tmp = spi_rate(rate, cpsr, scr);
+ if (abs(speed - tmp) < abs(speed - best_freq)) {
+ best_freq = tmp;
+ best_cpsr = cpsr;
+ best_scr = scr;
+ if (tmp == speed) {
+ found = true;
+ break;
+ }
+ }
+ scr++;
+ }
+ cpsr += 2;
+ scr = SSP_SCR_MIN;
+ }
+ writew(best_cpsr, s->base + SSP_CPSR);
+ cr0 = SSP_CR0_BIT_MODE(8);
+ cr0 |= best_scr << 8;
+ /*set module*/
+ cr0 &= ~(SSP_CR0_SPH | SSP_CR0_SPO);
+ if(s->mode_bit & SPI_CPHA)
+ cr0 |= SSP_CR0_SPH;
+ if(s->mode_bit & SPI_CPOL)
+ cr0 |= SSP_CR0_SPO;
+ cr0 |= SSP_CR0_EXSPI_FRAME;
+ writew(cr0, s->base + SSP_CR0);
+ /*clear and enable interrupt*/
+ writew(FIELD_PREP(SSP_FIFO_LEVEL_RX, DFLT_THRESH_RX) |
+ FIELD_PREP(SSP_FIFO_LEVEL_TX, DFLT_THRESH_TX),
+ s->base + SSP_FIFO_LEVEL);
+
+ return 0;
+}
+
+static const struct spi_controller_mem_ops sf_qspi_mem_ops = {
+ .adjust_op_size = sf_qspi_adjust_op_size,
+ .exec_op = sf_qspi_exec_op,
+};
+
+static int sf_qspi_probe(struct platform_device *pdev) {
+ struct spi_controller *master;
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node, *nc;
+ struct sf_qspi *s;
+
+ master = devm_spi_alloc_host(&pdev->dev, sizeof(*s));
+ if (!master)
+ return -ENOMEM;
+ master->mode_bits = SPI_RX_DUAL | SPI_RX_QUAD | SPI_TX_DUAL |
+ SPI_TX_QUAD;
+ s = spi_controller_get_devdata(master);
+ s->dev = dev;
+ s->mode_bit = 0;
+ platform_set_drvdata(pdev, s);
+ s->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(s->base))
+ return PTR_ERR(s->base);
+
+ s->clk = devm_clk_get_enabled(dev, NULL);
+ if (IS_ERR(s->clk))
+ return PTR_ERR(s->clk);
+
+ for_each_available_child_of_node(dev->of_node, nc) {
+ of_property_read_u32(nc, "spi-max-frequency", &s->freq);
+ }
+
+ master->bus_num = pdev->id;
+ master->num_chipselect = 1;
+
+ master->mem_ops = &sf_qspi_mem_ops;
+ sf_qspi_default_setup(s);
+ master->dev.of_node = np;
+ return devm_spi_register_controller(dev, master);
+}
+
+static const struct of_device_id sf_qspi_ids[] = {
+ { .compatible = "siflower,qspi" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sf_qspi_ids);
+
+static struct platform_driver sf_qspi_driver = {
+ .driver = {
+ .name = "siflower_qspi",
+ .of_match_table = sf_qspi_ids,
+ },
+ .probe = sf_qspi_probe,
+};
+module_platform_driver(sf_qspi_driver);
+
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v6 0/3] riscv: sophgo: add dmamux support for Sophgo CV1800/SG2000 SoCs
From: Inochi Amaoto @ 2024-03-29 2:03 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen Wang, Inochi Amaoto, Paul Walmsley, Palmer Dabbelt,
Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv
Add dma multiplexer support for the Sophgo CV1800/SG2000 SoCs.
As the syscon device of CV1800 have a usb phy subdevices. The
binding of the syscon can not be complete without the usb phy
is finished. As a result, the binding of syscon is removed
and will be evolved in its original series after the usb phy
binding is fully explored.
Changed from v5:
1. remove dead binding header.
2. make "reg" required so the syscon binding can have the same
example node of the dmamux binding.
Changed from v4:
1. remove the syscon binding since it can not be complete (still
lack some subdevices)
2. add reg description for the binding,
3. remove the fixed channel assign for dmamux binding
3. driver adopt to the binding change. Now the driver allocates all the
channel when initing and maps the request chan to the channel dynamicly.
Changed from v3:
1. fix dt-binding address issue.
Changed from v2:
1. add reg property of dmamux node in the binding of patch 2
Changed from v1:
1. fix wrong title of patch 2.
Inochi Amaoto (3):
dt-bindings: dmaengine: Add dma multiplexer for CV18XX/SG200X series
SoC
soc/sophgo: add top sysctrl layout file for CV18XX/SG200X
dmaengine: add driver for Sophgo CV18XX/SG200X dmamux
.../bindings/dma/sophgo,cv1800-dmamux.yaml | 51 ++++
drivers/dma/Kconfig | 9 +
drivers/dma/Makefile | 1 +
drivers/dma/cv1800-dmamux.c | 267 ++++++++++++++++++
include/soc/sophgo/cv1800-sysctl.h | 30 ++
5 files changed, 358 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml
create mode 100644 drivers/dma/cv1800-dmamux.c
create mode 100644 include/soc/sophgo/cv1800-sysctl.h
--
2.44.0
^ permalink raw reply
* [PATCH v6 1/3] dt-bindings: dmaengine: Add dma multiplexer for CV18XX/SG200X series SoC
From: Inochi Amaoto @ 2024-03-29 2:04 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen Wang, Inochi Amaoto, Paul Walmsley, Palmer Dabbelt,
Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv
In-Reply-To: <IA1PR20MB4953F0FAED4373660C7873A2BB3A2@IA1PR20MB4953.namprd20.prod.outlook.com>
The DMA IP of Sophgo CV18XX/SG200X is based on a DW AXI CORE, with
an additional channel remap register located in the top system control
area. The DMA channel is exclusive to each core.
In addition, the DMA multiplexer is a subdevice of system controller,
so this binding only contains necessary properties for the multiplexer
itself.
Add the dmamux binding for CV18XX/SG200X series SoC.
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
---
.../bindings/dma/sophgo,cv1800-dmamux.yaml | 51 +++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml
diff --git a/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml b/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml
new file mode 100644
index 000000000000..480cb117db9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/sophgo,cv1800-dmamux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo CV1800/SG200 Series DMA multiplexer
+
+maintainers:
+ - Inochi Amaoto <inochiama@outlook.com>
+
+description: |
+ The DMA multiplexer of CV1800 is a subdevice of the system
+ controller. It support mapping 8 channels, but each channel
+ can be mapped only once.
+
+allOf:
+ - $ref: dma-router.yaml#
+
+properties:
+ compatible:
+ const: sophgo,cv1800-dmamux
+
+ reg:
+ items:
+ - description: DMA channal remapping register
+ - description: DMA channel interrupt mapping register
+
+ '#dma-cells':
+ const: 2
+ description:
+ The first cells is device id. The second one is the cpu id.
+
+ dma-masters:
+ maxItems: 1
+
+required:
+ - reg
+ - '#dma-cells'
+ - dma-masters
+
+additionalProperties: false
+
+examples:
+ - |
+ dma-router@154 {
+ compatible = "sophgo,cv1800-dmamux";
+ reg = <0x154 0x8>, <0x298 0x4>;
+ #dma-cells = <2>;
+ dma-masters = <&dmac>;
+ };
--
2.44.0
^ permalink raw reply related
* [PATCH v6 2/3] soc/sophgo: add top sysctrl layout file for CV18XX/SG200X
From: Inochi Amaoto @ 2024-03-29 2:04 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen Wang, Inochi Amaoto, Paul Walmsley, Palmer Dabbelt,
Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv
In-Reply-To: <IA1PR20MB4953F0FAED4373660C7873A2BB3A2@IA1PR20MB4953.namprd20.prod.outlook.com>
The "top" system controller of CV18XX/SG200X exposes control
register access for various devices. Add soc header file to
describe it.
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
---
include/soc/sophgo/cv1800-sysctl.h | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 include/soc/sophgo/cv1800-sysctl.h
diff --git a/include/soc/sophgo/cv1800-sysctl.h b/include/soc/sophgo/cv1800-sysctl.h
new file mode 100644
index 000000000000..b9396d33e240
--- /dev/null
+++ b/include/soc/sophgo/cv1800-sysctl.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2023 Inochi Amaoto <inochiama@outlook.com>
+ */
+
+#ifndef CV1800_SYSCTL_H
+#define CV1800_SYSCTL_H
+
+/*
+ * SOPHGO CV1800/SG2000 SoC top system controller registers offsets.
+ */
+
+#define CV1800_CONF_INFO 0x004
+#define CV1800_SYS_CTRL_REG 0x008
+#define CV1800_USB_PHY_CTRL_REG 0x048
+#define CV1800_SDMA_DMA_CHANNEL_REMAP0 0x154
+#define CV1800_SDMA_DMA_CHANNEL_REMAP1 0x158
+#define CV1800_TOP_TIMER_CLK_SEL 0x1a0
+#define CV1800_TOP_WDT_CTRL 0x1a8
+#define CV1800_DDR_AXI_URGENT_OW 0x1b8
+#define CV1800_DDR_AXI_URGENT 0x1bc
+#define CV1800_DDR_AXI_QOS_0 0x1d8
+#define CV1800_DDR_AXI_QOS_1 0x1dc
+#define CV1800_SD_PWRSW_CTRL 0x1f4
+#define CV1800_SD_PWRSW_TIME 0x1f8
+#define CV1800_DDR_AXI_QOS_OW 0x23c
+#define CV1800_SD_CTRL_OPT 0x294
+#define CV1800_SDMA_DMA_INT_MUX 0x298
+
+#endif // CV1800_SYSCTL_H
--
2.44.0
^ permalink raw reply related
* [PATCH v6 3/3] dmaengine: add driver for Sophgo CV18XX/SG200X dmamux
From: Inochi Amaoto @ 2024-03-29 2:04 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen Wang, Inochi Amaoto, Paul Walmsley, Palmer Dabbelt,
Albert Ou
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, dmaengine, devicetree,
linux-kernel, linux-riscv
In-Reply-To: <IA1PR20MB4953F0FAED4373660C7873A2BB3A2@IA1PR20MB4953.namprd20.prod.outlook.com>
Sophgo CV18XX/SG200X use DW AXI CORE with a multiplexer for remapping
its request lines. The multiplexer supports at most 8 request lines.
Add driver for Sophgo CV18XX/SG200X DMA multiplexer.
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
---
drivers/dma/Kconfig | 9 ++
drivers/dma/Makefile | 1 +
drivers/dma/cv1800-dmamux.c | 267 ++++++++++++++++++++++++++++++++++++
3 files changed, 277 insertions(+)
create mode 100644 drivers/dma/cv1800-dmamux.c
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 002a5ec80620..cb31520b9f86 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -546,6 +546,15 @@ config PLX_DMA
These are exposed via extra functions on the switch's
upstream port. Each function exposes one DMA channel.
+config SOPHGO_CV1800_DMAMUX
+ tristate "Sophgo CV1800/SG2000 series SoC DMA multiplexer support"
+ depends on MFD_SYSCON
+ depends on ARCH_SOPHGO
+ help
+ Support for the DMA multiplexer on Sophgo CV1800/SG2000
+ series SoCs.
+ Say Y here if your board have this soc.
+
config STE_DMA40
bool "ST-Ericsson DMA40 support"
depends on ARCH_U8500
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index dfd40d14e408..7465f249ee47 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
obj-$(CONFIG_PXA_DMA) += pxa_dma.o
obj-$(CONFIG_RENESAS_DMA) += sh/
obj-$(CONFIG_SF_PDMA) += sf-pdma/
+obj-$(CONFIG_SOPHGO_CV1800_DMAMUX) += cv1800-dmamux.o
obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
obj-$(CONFIG_STM32_DMA) += stm32-dma.o
obj-$(CONFIG_STM32_DMAMUX) += stm32-dmamux.o
diff --git a/drivers/dma/cv1800-dmamux.c b/drivers/dma/cv1800-dmamux.c
new file mode 100644
index 000000000000..709414898b67
--- /dev/null
+++ b/drivers/dma/cv1800-dmamux.c
@@ -0,0 +1,267 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 Inochi Amaoto <inochiama@outlook.com>
+ */
+
+#include <linux/bitops.h>
+#include <linux/module.h>
+#include <linux/of_dma.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/llist.h>
+#include <linux/regmap.h>
+#include <linux/spinlock.h>
+#include <linux/mfd/syscon.h>
+
+#include <soc/sophgo/cv1800-sysctl.h>
+
+#define DMAMUX_NCELLS 2
+#define MAX_DMA_MAPPING_ID 42
+#define MAX_DMA_CPU_ID 2
+#define MAX_DMA_CH_ID 7
+
+#define DMAMUX_INTMUX_REGISTER_LEN 4
+#define DMAMUX_NR_CH_PER_REGISTER 4
+#define DMAMUX_BIT_PER_CH 8
+#define DMAMUX_CH_MASk GENMASK(5, 0)
+#define DMAMUX_INT_BIT_PER_CPU 10
+#define DMAMUX_CH_UPDATE_BIT BIT(31)
+
+#define DMAMUX_CH_REGPOS(chid) \
+ ((chid) / DMAMUX_NR_CH_PER_REGISTER)
+#define DMAMUX_CH_REGOFF(chid) \
+ ((chid) % DMAMUX_NR_CH_PER_REGISTER)
+#define DMAMUX_CH_REG(chid) \
+ ((DMAMUX_CH_REGPOS(chid) * sizeof(u32)) + \
+ CV1800_SDMA_DMA_CHANNEL_REMAP0)
+#define DMAMUX_CH_SET(chid, val) \
+ (((val) << (DMAMUX_CH_REGOFF(chid) * DMAMUX_BIT_PER_CH)) | \
+ DMAMUX_CH_UPDATE_BIT)
+#define DMAMUX_CH_MASK(chid) \
+ DMAMUX_CH_SET(chid, DMAMUX_CH_MASk)
+
+#define DMAMUX_INT_BIT(chid, cpuid) \
+ BIT((cpuid) * DMAMUX_INT_BIT_PER_CPU + (chid))
+#define DMAMUX_INTEN_BIT(cpuid) \
+ DMAMUX_INT_BIT(8, cpuid)
+#define DMAMUX_INT_CH_BIT(chid, cpuid) \
+ (DMAMUX_INT_BIT(chid, cpuid) | DMAMUX_INTEN_BIT(cpuid))
+#define DMAMUX_INT_MASK(chid) \
+ (DMAMUX_INT_BIT(chid, 0) | \
+ DMAMUX_INT_BIT(chid, 1) | \
+ DMAMUX_INT_BIT(chid, 2))
+#define DMAMUX_INT_CH_MASK(chid, cpuid) \
+ (DMAMUX_INT_MASK(chid) | DMAMUX_INTEN_BIT(cpuid))
+
+struct cv1800_dmamux_data {
+ struct dma_router dmarouter;
+ struct regmap *regmap;
+ spinlock_t lock;
+ struct llist_head free_maps;
+ struct llist_head reserve_maps;
+ DECLARE_BITMAP(mapped_peripherals, MAX_DMA_MAPPING_ID);
+};
+
+struct cv1800_dmamux_map {
+ struct llist_node node;
+ unsigned int channel;
+ unsigned int peripheral;
+ unsigned int cpu;
+};
+
+static void cv1800_dmamux_free(struct device *dev, void *route_data)
+{
+ struct cv1800_dmamux_data *dmamux = dev_get_drvdata(dev);
+ struct cv1800_dmamux_map *map = route_data;
+ unsigned long flags;
+
+ spin_lock_irqsave(&dmamux->lock, flags);
+
+ regmap_update_bits(dmamux->regmap,
+ DMAMUX_CH_REG(map->channel),
+ DMAMUX_CH_MASK(map->channel),
+ DMAMUX_CH_UPDATE_BIT);
+
+ regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX,
+ DMAMUX_INT_CH_MASK(map->channel, map->cpu),
+ DMAMUX_INTEN_BIT(map->cpu));
+
+ spin_unlock_irqrestore(&dmamux->lock, flags);
+
+ dev_info(dev, "free channel %u for req %u (cpu %u)\n",
+ map->channel, map->peripheral, map->cpu);
+}
+
+static void *cv1800_dmamux_route_allocate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct platform_device *pdev = of_find_device_by_node(ofdma->of_node);
+ struct cv1800_dmamux_data *dmamux = platform_get_drvdata(pdev);
+ struct cv1800_dmamux_map *map;
+ struct llist_node *node;
+ unsigned long flags;
+ unsigned int chid, devid, cpuid;
+ int ret;
+
+ if (dma_spec->args_count != DMAMUX_NCELLS) {
+ dev_err(&pdev->dev, "invalid number of dma mux args\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ devid = dma_spec->args[0];
+ cpuid = dma_spec->args[1];
+ dma_spec->args_count = 1;
+
+ if (devid > MAX_DMA_MAPPING_ID) {
+ dev_err(&pdev->dev, "invalid device id: %u\n", devid);
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (cpuid > MAX_DMA_CPU_ID) {
+ dev_err(&pdev->dev, "invalid cpu id: %u\n", cpuid);
+ return ERR_PTR(-EINVAL);
+ }
+
+ dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", 0);
+ if (!dma_spec->np) {
+ dev_err(&pdev->dev, "can't get dma master\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ spin_lock_irqsave(&dmamux->lock, flags);
+
+ if (test_bit(devid, dmamux->mapped_peripherals)) {
+ llist_for_each_entry(map, dmamux->reserve_maps.first, node) {
+ if (map->peripheral == devid && map->cpu == cpuid)
+ goto found;
+ }
+
+ ret = -EINVAL;
+ goto failed;
+ } else {
+ node = llist_del_first(&dmamux->free_maps);
+ if (!node) {
+ ret = -ENODEV;
+ goto failed;
+ }
+
+ map = llist_entry(node, struct cv1800_dmamux_map, node);
+ llist_add(&map->node, &dmamux->reserve_maps);
+ set_bit(devid, dmamux->mapped_peripherals);
+ }
+
+found:
+ chid = map->channel;
+ map->peripheral = devid;
+ map->cpu = cpuid;
+
+ regmap_set_bits(dmamux->regmap,
+ DMAMUX_CH_REG(chid),
+ DMAMUX_CH_SET(chid, devid));
+
+ regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX,
+ DMAMUX_INT_CH_MASK(chid, cpuid),
+ DMAMUX_INT_CH_BIT(chid, cpuid));
+
+ spin_unlock_irqrestore(&dmamux->lock, flags);
+
+ dma_spec->args[0] = chid;
+
+ dev_info(&pdev->dev, "register channel %u for req %u (cpu %u)\n",
+ chid, devid, cpuid);
+
+ return map;
+
+failed:
+ spin_unlock_irqrestore(&dmamux->lock, flags);
+ of_node_put(dma_spec->np);
+ dev_err(&pdev->dev, "errno %d\n", ret);
+ return ERR_PTR(ret);
+
+}
+
+static int cv1800_dmamux_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *mux_node = dev->of_node;
+ struct cv1800_dmamux_data *data;
+ struct cv1800_dmamux_map *tmp;
+ struct device *parent = dev->parent;
+ struct device_node *dma_master;
+ struct regmap *regmap = NULL;
+ unsigned int i;
+
+ if (!parent)
+ return -ENODEV;
+
+ regmap = device_node_to_regmap(parent->of_node);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ dma_master = of_parse_phandle(mux_node, "dma-masters", 0);
+ if (!dma_master) {
+ dev_err(dev, "invalid dma-requests property\n");
+ return -ENODEV;
+ }
+ of_node_put(dma_master);
+
+ data = devm_kmalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ spin_lock_init(&data->lock);
+ init_llist_head(&data->free_maps);
+
+ for (i = 0; i <= MAX_DMA_CH_ID; i++) {
+ tmp = devm_kmalloc(dev, sizeof(*tmp), GFP_KERNEL);
+ if (!tmp) {
+ /* It is OK for not allocating all channel */
+ dev_warn(dev, "can not allocate channel %u\n", i);
+ continue;
+ }
+
+ init_llist_node(&tmp->node);
+ tmp->channel = i;
+ llist_add(&tmp->node, &data->free_maps);
+ }
+
+ /* if no channel is allocated, the probe must fail */
+ if (llist_empty(&data->free_maps))
+ return -ENOMEM;
+
+ data->regmap = regmap;
+ data->dmarouter.dev = dev;
+ data->dmarouter.route_free = cv1800_dmamux_free;
+
+ platform_set_drvdata(pdev, data);
+
+ return of_dma_router_register(mux_node,
+ cv1800_dmamux_route_allocate,
+ &data->dmarouter);
+}
+
+static void cv1800_dmamux_remove(struct platform_device *pdev)
+{
+ of_dma_controller_free(pdev->dev.of_node);
+}
+
+static const struct of_device_id cv1800_dmamux_ids[] = {
+ { .compatible = "sophgo,cv1800-dmamux", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, cv1800_dmamux_ids);
+
+static struct platform_driver cv1800_dmamux_driver = {
+ .driver = {
+ .name = "cv1800-dmamux",
+ .of_match_table = cv1800_dmamux_ids,
+ },
+ .probe = cv1800_dmamux_probe,
+ .remove_new = cv1800_dmamux_remove,
+};
+module_platform_driver(cv1800_dmamux_driver);
+
+MODULE_AUTHOR("Inochi Amaoto <inochiama@outlook.com>");
+MODULE_DESCRIPTION("Sophgo CV1800/SG2000 Series Soc DMAMUX driver");
+MODULE_LICENSE("GPL");
--
2.44.0
^ permalink raw reply related
* RE: [PATCH v2 5/6] PCI: dwc: rcar-gen4: Add support for other R-Car Gen4 PCIe controller
From: Yoshihiro Shimoda @ 2024-03-29 2:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: lpieralisi@kernel.org, kw@linux.com, robh@kernel.org,
bhelgaas@google.com, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, jingoohan1@gmail.com,
gustavo.pimentel@synopsys.com, mani@kernel.org,
marek.vasut+renesas@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <20240327181451.GA1531625@bhelgaas>
Hi Bjorn,
> From: Bjorn Helgaas, Sent: Thursday, March 28, 2024 3:15 AM
>
> On Wed, Mar 27, 2024 at 05:32:57AM +0000, Yoshihiro Shimoda wrote:
> > > From: Bjorn Helgaas, Sent: Wednesday, March 27, 2024 5:49 AM
>
> > > > static int rcar_gen4_pcie_get_resources(struct rcar_gen4_pcie *rcar)
> > > > {
> > > > + rcar->phy_base = devm_platform_ioremap_resource_byname(rcar->pdev, "phy");
> > > > + if (IS_ERR(rcar->phy_base))
> > > > + return PTR_ERR(rcar->base);
> > >
> > > I don't get it. This imposes a new requirement (presence of "phy"
> > > resource) on the existing SoCs. That doesn't sound right.
> >
> > According to the dt-binding doc, the existing SoCs are also required
> > for the "phy". That's why I didn't add any condition to simplify
> > the code.
>
> Is there anything that enforces that? Is it possible that DTs exist
> in the field without it? We don't want to break any existing setup.
Using make dtbs_check can detect an error if the "phy" doesn't exist like below:
/home/shimoda/development/linux/linux/arch/arm64/boot/dts/renesas/r8a779f0-spider.dtb: pcie@e65d0000: reg-names:5: 'phy' was expected
from schema $id: http://devicetree.org/schemas/pci/rcar-gen4-pci-host.yaml#
So, I believe that this can enforce that in review process at least.
Now arch/arm64/boot/dts/renesas/r8a779f0.dtsi has the pcie compatible,
and all pcie nodes in the dtsi have "phy". So, this patch will not break any existing setup.
Best regards,
Yoshihiro Shimoda
^ permalink raw reply
* Re: [PATCH v5 2/2] ASoC: nau8325: new driver
From: WTLI @ 2024-03-29 2:33 UTC (permalink / raw)
To: Mark Brown
Cc: lgirdwood, alsa-devel, devicetree, linux-sound,
krzysztof.kozlowski+dt, linux-kernel, robh+dt, conor+dt, perex,
tiwai, YHCHuang, KCHSU0, CTLIN0, SJLIN0, scott6986,
supercraig0719, dardar923
In-Reply-To: <8278611a-a46f-4d5e-9861-67ff1084db50@sirena.org.uk>
Mark Brown 於 3/28/2024 11:22 PM 寫道:
> On Wed, Mar 27, 2024 at 03:57:55PM +0800, Seven Lee wrote:
>
>> +static const char * const nau8325_dac_oversampl[] = {
>> + "64", "256", "128", "", "32" };
>> +
>> +static const struct soc_enum nau8325_dac_oversampl_enum =
>> + SOC_ENUM_SINGLE(NAU8325_R29_DAC_CTRL1, NAU8325_DAC_OVERSAMPLE_SFT,
>> + ARRAY_SIZE(nau8325_dac_oversampl),
>> + nau8325_dac_oversampl);
> This should really be a SOC_VALUE_ENUM so you can just hide the fourth
> value rather than having the empty (presumably invalid) option. Please
> send an incremental patch doing this.
okay, thanks for reminding.
________________________________
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
^ permalink raw reply
* Re: [PATCH v3 6/6] riscv: dts: starfive: add Milkv Mars board device tree
From: Jisheng Zhang @ 2024-03-29 2:31 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Rob Herring, Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Emil Renner Berthing, linux-riscv, devicetree,
linux-kernel, Conor Dooley, Aurelien Jarno
In-Reply-To: <43918921-0d05-41d3-a19b-f137314e868d@canonical.com>
On Thu, Mar 28, 2024 at 10:28:28PM +0100, Heinrich Schuchardt wrote:
> On 2/6/24 20:13, Conor Dooley wrote:
> > On Wed, Jan 31, 2024 at 09:26:00PM +0800, Jisheng Zhang wrote:
> > > The Milkv Mars is a development board based on the Starfive JH7110 SoC.
> > > The board features:
> > >
> > > - JH7110 SoC
> > > - 1/2/4/8 GiB LPDDR4 DRAM
> > > - AXP15060 PMIC
> > > - 40 pin GPIO header
> > > - 3x USB 3.0 host port
> > > - 1x USB 2.0 host port
> > > - 1x M.2 E-Key
> > > - 1x eMMC slot
> > > - 1x MicroSD slot
> > > - 1x QSPI Flash
> > > - 1x 1Gbps Ethernet port
> > > - 1x HDMI port
> > > - 1x 2-lane DSI and 1x 4-lane DSI
> > > - 1x 2-lane CSI
> > >
> > > Add the devicetree file describing the currently supported features,
> > > namely PMIC, UART, I2C, GPIO, SD card, QSPI Flash, eMMC and Ethernet.
> > >
> > > Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
> >
> > Got a dtbs_check issue in the patchwork CI:
> >
> > +arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dtb: gmac1-rgmii-rxin-clock: 'clock-frequency' is a required property
> > + from schema $id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
> > +arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dtb: gmac1-rmii-refin-clock: 'clock-frequency' is a required property
> > + from schema $id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
> >
> > Can you fix that please? Also, I applied some patches the other day that
> > seem to conflict quite a bit with the common board dts patch. Would you
> > please do a rebase on top of that please?
> >
> > Cheers,
> > Conor.
> >
> > > ---
> > > arch/riscv/boot/dts/starfive/Makefile | 1 +
> > > .../boot/dts/starfive/jh7110-milkv-mars.dts | 35 +++++++++++++++++++
> > > 2 files changed, 36 insertions(+)
> > > create mode 100644 arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts
> > >
> > > diff --git a/arch/riscv/boot/dts/starfive/Makefile b/arch/riscv/boot/dts/starfive/Makefile
> > > index 0141504c0f5c..2fa0cd7f31c3 100644
> > > --- a/arch/riscv/boot/dts/starfive/Makefile
> > > +++ b/arch/riscv/boot/dts/starfive/Makefile
> > > @@ -8,5 +8,6 @@ DTC_FLAGS_jh7110-starfive-visionfive-2-v1.3b := -@
> > > dtb-$(CONFIG_ARCH_STARFIVE) += jh7100-beaglev-starlight.dtb
> > > dtb-$(CONFIG_ARCH_STARFIVE) += jh7100-starfive-visionfive-v1.dtb
> > > +dtb-$(CONFIG_ARCH_STARFIVE) += jh7110-milkv-mars.dtb
> > > dtb-$(CONFIG_ARCH_STARFIVE) += jh7110-starfive-visionfive-2-v1.2a.dtb
> > > dtb-$(CONFIG_ARCH_STARFIVE) += jh7110-starfive-visionfive-2-v1.3b.dtb
> > > diff --git a/arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts b/arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts
> > > new file mode 100644
> > > index 000000000000..de600e799e7d
> > > --- /dev/null
> > > +++ b/arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dts
> > > @@ -0,0 +1,35 @@
> > > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > > +/*
> > > + * Copyright (C) 2023 Jisheng Zhang <jszhang@kernel.org>
> > > + */
> > > +
> > > +/dts-v1/;
> > > +#include "jh7110-visionfive2-mars-common.dtsi"
> > > +
> > > +/ {
> > > + model = "Milk-V Mars";
> > > + compatible = "milkv,mars", "starfive,jh7110";
> > > +};
> > > +
> > > +&gmac0 {
> > > + starfive,tx-use-rgmii-clk;
> > > + assigned-clocks = <&aoncrg JH7110_AONCLK_GMAC0_TX>;
> > > + assigned-clock-parents = <&aoncrg JH7110_AONCLK_GMAC0_RMII_RTX>;
> > > +};
> > > +
> > > +
> > > +&phy0 {
> > > + motorcomm,tx-clk-adj-enabled;
> > > + motorcomm,tx-clk-10-inverted;
> > > + motorcomm,tx-clk-100-inverted;
> > > + motorcomm,tx-clk-1000-inverted;
> > > + motorcomm,rx-clk-drv-microamp = <3970>;
> > > + motorcomm,rx-data-drv-microamp = <2910>;
> > > + rx-internal-delay-ps = <1500>;
> > > + tx-internal-delay-ps = <1500>;
> > > +};
> > > +
> > > +&mmc1 {
> > > + disable-wp;
>
> Due to which difference is 'disable-wp' necessary for the Mars board and not
> necessary for the VisionFive 2 board?
Mars doesn't have wp pin, but dunno vf2 case since I don't have a VF2
board ;)
>
> > > + cd-gpios = <&sysgpio 41 GPIO_ACTIVE_LOW>;
>
> On my VisionFive 2 1.2B, and 1.3A boards GPIO 41 reflects if an SD-card is
> inserted (as shown in U-Boot by gpio status -a). So shouldn't this value be
> moved to the common include "jh7110-visionfive2-mars-common.dtsi" and
> broken-cd removed from the VisionFive2 board?
I tested the CD pin and can confirm it works on Mars, but I dunno whether
this works on VF2 since I have no VF2 board.
Could you please check whether it works or not on VF2?
>
> https://doc-en.rvspace.org/VisionFive2/PDF/SCH_RV002_V1.2A_20221216.pdf
> has a line
>
> GPIO41 | SD_SDIO0_CD_GPIO41 | Micro SD：J10
>
> Best regards
>
> Heinrich
>
> > > +};
> > > --
> > > 2.43.0
>
^ 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