* Re: [PATCH v3 000/105] drm/vc4: Support BCM2711 Display Pipeline
From: Stefan Wahren @ 2020-06-02 20:12 UTC (permalink / raw)
To: Maxime Ripard, Nicolas Saenz Julienne, Eric Anholt
Cc: devicetree, Tim Gover, Dave Stevenson, Stephen Boyd,
Michael Turquette, Kamal Dasu, linux-kernel, dri-devel, linux-clk,
Rob Herring, bcm-kernel-feedback-list, linux-rpi-kernel,
Philipp Zabel, Phil Elwell, linux-arm-kernel
In-Reply-To: <cover.aaf2100bd7da4609f8bcb8216247d4b4e4379639.1590594512.git-series.maxime@cerno.tech>
Hi Maxime,
Am 27.05.20 um 17:47 schrieb Maxime Ripard:
> Hi everyone,
>
> Here's a (pretty long) series to introduce support in the VC4 DRM driver
> for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
>
> The main differences are that there's two HDMI controllers and that there's
> more pixelvalve now. Those pixelvalve come with a mux in the HVS that still
> have only 3 FIFOs. Both of those differences are breaking a bunch of
> expectations in the driver, so we first need a good bunch of cleanup and
> reworks to introduce support for the new controllers.
>
> Similarly, the HDMI controller has all its registers shuffled and split in
> multiple controllers now, so we need a bunch of changes to support this as
> well.
>
> Only the HDMI support is enabled for now (even though the DPI output has
> been tested too).
>
> This is based on the firmware clocks series sent separately:
> https://lore.kernel.org/lkml/cover.662a8d401787ef33780d91252a352de91dc4be10.1590594293.git-series.maxime@cerno.tech/
>
> Let me know if you have any comments
> Maxime
>
> Cc: bcm-kernel-feedback-list@broadcom.com
> Cc: devicetree@vger.kernel.org
> Cc: Kamal Dasu <kdasu.kdev@gmail.com>
> Cc: linux-clk@vger.kernel.org
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
>
> Changes from v2:
> - Rebased on top of next-20200526
i assume this is the reason why this series doesn't completely apply
against drm-misc-next.
^ permalink raw reply
* [PATCH 1/1] Documentation: Document an existing qcom,rpm-msm8996 compatible
From: Konrad Dybcio @ 2020-06-02 20:08 UTC (permalink / raw)
Cc: Konrad Dybcio, Andy Gross, Bjorn Andersson, Rob Herring,
linux-arm-msm, devicetree, linux-kernel
This compatible has been included in the driver for
some time, but it has been overlooked in documentation.
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
---
Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
index 25541a475ead..4b916d67064a 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
@@ -24,6 +24,7 @@ resources.
"qcom,rpm-msm8974"
"qcom,rpm-msm8976"
"qcom,rpm-msm8994"
+ "qcom,rpm-msm8996"
"qcom,rpm-msm8998"
"qcom,rpm-sdm660"
"qcom,rpm-qcs404"
--
2.26.2
^ permalink raw reply related
* Re: [PATCH 1/1] soc: qcom: smd-rpm: Add msm8994 compatible
From: Konrad Dybcio @ 2020-06-02 20:05 UTC (permalink / raw)
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm, DTML,
Linux Kernel Mailing List
In-Reply-To: <20200602200407.320908-1-konradybcio@gmail.com>
Interestingly enough, this compatible has been used in lg-bullhead DTS
for a long long time, even though it has never existed upstream.
^ permalink raw reply
* Re: [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings documention
From: Pavel Machek @ 2020-06-02 20:04 UTC (permalink / raw)
To: Rob Herring
Cc: Dan Murphy, Jacek Anaszewski, devicetree, Linux LED Subsystem,
linux-kernel@vger.kernel.org
In-Reply-To: <CAL_Jsq+rS=awLC_maPGjeWhh1Sb9U31xfvLecVe9sPTh83eDBw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]
On Wed 2020-05-27 08:35:06, Rob Herring wrote:
> On Wed, May 27, 2020 at 7:39 AM Pavel Machek <pavel@ucw.cz> wrote:
> >
> > Hi!
> >
> > Thanks for reviews!
> >
> > > > +additionalProperties: false
> > > > +...
> > > > diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
> > >
> > > This isn't a binding file. Belongs in another patch.
> >
> > These constants are directly related to the binding. It makes sense to
> > go in one patch...
>
> Yes, the header does go in this patch, but kernel subsystem files do not.
>
> Part of the reason for separating is we generate a DT only repository
> which filters out all the kernel code. Ideally this is just filtering
> out commits and the commit messages still make sens
Well, but the patch can't be split like that. Otherwise we risk null
pointer dereferences when one part is applied but not the second one.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH 1/1] soc: qcom: smd-rpm: Add msm8994 compatible
From: Konrad Dybcio @ 2020-06-02 20:04 UTC (permalink / raw)
Cc: Konrad Dybcio, Andy Gross, Bjorn Andersson, Rob Herring,
linux-arm-msm, devicetree, linux-kernel
Add the compatible for the RPM in msm8994.
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
---
Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt | 1 +
drivers/soc/qcom/smd-rpm.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
index 616fddcd09fd..25541a475ead 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
@@ -23,6 +23,7 @@ resources.
"qcom,rpm-msm8916"
"qcom,rpm-msm8974"
"qcom,rpm-msm8976"
+ "qcom,rpm-msm8994"
"qcom,rpm-msm8998"
"qcom,rpm-sdm660"
"qcom,rpm-qcs404"
diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
index 005dd30c58fa..54eb5cbc05fd 100644
--- a/drivers/soc/qcom/smd-rpm.c
+++ b/drivers/soc/qcom/smd-rpm.c
@@ -233,6 +233,7 @@ static const struct of_device_id qcom_smd_rpm_of_match[] = {
{ .compatible = "qcom,rpm-msm8916" },
{ .compatible = "qcom,rpm-msm8974" },
{ .compatible = "qcom,rpm-msm8976" },
+ { .compatible = "qcom,rpm-msm8994" },
{ .compatible = "qcom,rpm-msm8996" },
{ .compatible = "qcom,rpm-msm8998" },
{ .compatible = "qcom,rpm-sdm660" },
--
2.26.2
^ permalink raw reply related
* Re: [PATCH 04/10] dt-bindings: spi: Add bindings for spi-dw-mchp
From: Serge Semin @ 2020-06-02 19:49 UTC (permalink / raw)
To: Lars Povlsen
Cc: Serge Semin, Mark Brown, SoC Team, Rob Herring, devicetree,
Alexandre Belloni, linux-kernel, linux-spi,
Microchip Linux Driver Support, linux-arm-kernel
In-Reply-To: <20200513140031.25633-5-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 04:00:25PM +0200, Lars Povlsen wrote:
> This add DT bindings for the Microsemi/Microchip SPI controller used
> in various SoC's. It describes the "mscc,ocelot-spi" and
> "mscc,jaguar2-spi" bindings.
As I see it, there is no need in this patch at all. Current DT binding file
describes the MSCC version of the DW APB SSI IP pretty well. You can add an
example to the DT schema though with "mscc,ocelot-spi" or "mscc,jaguar2-spi"
compatible string and additional registers range.
-Sergey
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
> .../bindings/spi/mscc,ocelot-spi.yaml | 60 +++++++++++++++++++
> .../bindings/spi/snps,dw-apb-ssi.txt | 7 +--
> MAINTAINERS | 1 +
> 3 files changed, 63 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
>
> diff --git a/Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml b/Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> new file mode 100644
> index 0000000000000..a3ac0fa576553
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> @@ -0,0 +1,60 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/spi/mscc,ocelot-spi.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Microsemi Vcore-III SPI Communication Controller
> +
> +maintainers:
> + - Alexandre Belloni <alexandre.belloni@bootlin.com>
> + - Lars Povlsen <lars.povlsen@microchip.com>
> +
> +allOf:
> + - $ref: "spi-controller.yaml#"
> +
> +description: |
> + The Microsemi Vcore-III SPI controller is a general purpose SPI
> + controller based upon the Designware SPI controller. It uses an 8
> + byte rx/tx fifo.
> +
> +properties:
> + compatible:
> + enum:
> + - mscc,ocelot-spi
> + - mscc,jaguar2-spi
> +
> + interrupts:
> + maxItems: 1
> +
> + reg:
> + minItems: 2
> + items:
> + - description: Designware SPI registers
> + - description: CS override registers
> +
> + clocks:
> + maxItems: 1
> +
> + reg-io-width:
> + description: |
> + The I/O register width (in bytes) implemented by this device.
> + items:
> + enum: [ 2, 4 ]
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> +
> +examples:
> + - |
> + spi0: spi@101000 {
> + compatible = "mscc,ocelot-spi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x101000 0x100>, <0x3c 0x18>;
> + interrupts = <9>;
> + clocks = <&ahb_clk>;
> + };
> diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
> index 3ed08ee9feba4..5e1849be7bae5 100644
> --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
> +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
> @@ -1,10 +1,8 @@
> Synopsys DesignWare AMBA 2.0 Synchronous Serial Interface.
>
> Required properties:
> -- compatible : "snps,dw-apb-ssi" or "mscc,<soc>-spi", where soc is "ocelot" or
> - "jaguar2", or "amazon,alpine-dw-apb-ssi"
> -- reg : The register base for the controller. For "mscc,<soc>-spi", a second
> - register set is required (named ICPU_CFG:SPI_MST)
> +- compatible : "snps,dw-apb-ssi" or "amazon,alpine-dw-apb-ssi"
> +- reg : The register base for the controller.
> - interrupts : One interrupt, used by the controller.
> - #address-cells : <1>, as required by generic SPI binding.
> - #size-cells : <0>, also as required by generic SPI binding.
> @@ -38,4 +36,3 @@ Example:
> cs-gpios = <&gpio0 13 0>,
> <&gpio0 14 0>;
> };
> -
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1db598723a1d8..6472240b8391b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11231,6 +11231,7 @@ L: linux-mips@vger.kernel.org
> S: Supported
> F: Documentation/devicetree/bindings/mips/mscc.txt
> F: Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> +F: Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> F: arch/mips/boot/dts/mscc/
> F: arch/mips/configs/generic/board-ocelot.config
> F: arch/mips/generic/board-ocelot.c
> --
> 2.26.2
>
> _______________________________________________
> 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 02/10] spi: dw: Add support for RX sample delay register
From: Serge Semin @ 2020-06-02 19:39 UTC (permalink / raw)
To: Lars Povlsen
Cc: Serge Semin, Mark Brown, SoC Team, devicetree, Alexandre Belloni,
linux-kernel, linux-spi, Microchip Linux Driver Support,
linux-arm-kernel
In-Reply-To: <20200513140031.25633-3-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 04:00:23PM +0200, Lars Povlsen wrote:
> This add support for the RX_SAMPLE_DLY register. If enabled in the
> Designware IP, it allows tuning of the rx data signal by means of an
> internal rx sample fifo.
>
> The register is located at offset 0xf0, and if the option is not
> enabled in the IP, changing the register will have no effect.
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
> drivers/spi/spi-dw.c | 7 +++++++
> drivers/spi/spi-dw.h | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
> index e572eb34a3c1a..32997f28fa5bb 100644
> --- a/drivers/spi/spi-dw.c
> +++ b/drivers/spi/spi-dw.c
> @@ -81,6 +81,9 @@ static ssize_t dw_spi_show_regs(struct file *file, char __user *user_buf,
> "DMATDLR: \t0x%08x\n", dw_readl(dws, DW_SPI_DMATDLR));
> len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
> "DMARDLR: \t0x%08x\n", dw_readl(dws, DW_SPI_DMARDLR));
> + len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
> + "RX_SAMPLE_DLY: \t0x%08x\n",
> + dw_readl(dws, DW_SPI_RX_SAMPLE_DLY));
debugfs_reg32 interface is now utilized in the driver to dump the registers
state. So this will have to be converted to just a new entry in the
dw_spi_dbgfs_regs array.
> len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
> "=================================\n");
>
> @@ -315,6 +318,10 @@ static int dw_spi_transfer_one(struct spi_controller *master,
> spi_set_clk(dws, chip->clk_div);
> }
>
> + /* Apply RX sample delay, iff requested (nonzero) */
s/iff/if
> + if (dws->rx_sample_dly)
> + dw_writel(dws, DW_SPI_RX_SAMPLE_DLY, dws->rx_sample_dly);
> +
> dws->n_bytes = DIV_ROUND_UP(transfer->bits_per_word, BITS_PER_BYTE);
> dws->dma_width = DIV_ROUND_UP(transfer->bits_per_word, BITS_PER_BYTE);
>
> diff --git a/drivers/spi/spi-dw.h b/drivers/spi/spi-dw.h
> index 1bf5713e047d3..ed6e47b3f50da 100644
> --- a/drivers/spi/spi-dw.h
> +++ b/drivers/spi/spi-dw.h
> @@ -31,6 +31,7 @@
> #define DW_SPI_IDR 0x58
> #define DW_SPI_VERSION 0x5c
> #define DW_SPI_DR 0x60
> +#define DW_SPI_RX_SAMPLE_DLY 0xf0
> #define DW_SPI_CS_OVERRIDE 0xf4
>
> /* Bit fields in CTRLR0 */
> @@ -111,6 +112,7 @@ struct dw_spi {
>
> int cs_override;
> u32 reg_io_width; /* DR I/O width in bytes */
> + u8 rx_sample_dly; /* RX fifo tuning (option) */
This doesn't seem like a good place for this parameter. The sample delay is
SPI-slave specific. So as I see it, the parameter should be moved to the
chip_data.
-Sergey
> u16 bus_num;
> u16 num_cs; /* supported slave numbers */
> void (*set_cs)(struct spi_device *spi, bool enable);
> --
> 2.26.2
>
> _______________________________________________
> 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 v2 1/4] remoteproc: Introduce rproc_of_parse_firmware() helper
From: Mathieu Poirier @ 2020-06-02 19:37 UTC (permalink / raw)
To: Suman Anna
Cc: Bjorn Andersson, Rob Herring, Lokesh Vutla, linux-remoteproc,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20200521001006.2725-2-s-anna@ti.com>
On Wed, May 20, 2020 at 07:10:03PM -0500, Suman Anna wrote:
> Add a new helper function rproc_of_parse_firmware() to the remoteproc
> core that can be used by various remoteproc drivers to look up the
> the "firmware-name" property from a rproc device node. This property
> is already being used by multiple drivers, so this helper can avoid
> repeating equivalent code in remoteproc drivers.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> v2: New patch
>
> drivers/remoteproc/remoteproc_core.c | 23 +++++++++++++++++++++++
> drivers/remoteproc/remoteproc_internal.h | 2 ++
> 2 files changed, 25 insertions(+)
>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 9f04c30c4aaf..c458b218d524 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1034,6 +1034,29 @@ rproc_of_resm_mem_entry_init(struct device *dev, u32 of_resm_idx, size_t len,
> }
> EXPORT_SYMBOL(rproc_of_resm_mem_entry_init);
>
> +/**
> + * rproc_of_parse_firmware() - parse and return the firmware-name
> + * @dev: pointer on device struct representing a rproc
> + * @index: index to use for the firmware-name retrieval
> + * @fw_name: pointer to a character string, in which the firmware
> + * name is returned on success and unmodified otherwise.
> + *
> + * This is an OF helper function that parses a device's DT node for
> + * the "firmware-name" property and returns the firmware name pointer
> + * in @fw_name on success.
> + *
> + * Return: 0 on success, or an appropriate failure.
> + */
> +int rproc_of_parse_firmware(struct device *dev, int index, const char **fw_name)
> +{
> + int ret;
> +
> + ret = of_property_read_string_index(dev->of_node, "firmware-name",
> + index, fw_name);
> + return ret ? ret : 0;
> +}
> +EXPORT_SYMBOL(rproc_of_parse_firmware);
> +
> /*
> * A lookup table for resource handlers. The indices are defined in
> * enum fw_resource_type.
> diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
> index 4ba7cb59d3e8..e5341e91d2fc 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -28,6 +28,8 @@ struct rproc_debug_trace {
> void rproc_release(struct kref *kref);
> irqreturn_t rproc_vq_interrupt(struct rproc *rproc, int vq_id);
> void rproc_vdev_release(struct kref *ref);
> +int rproc_of_parse_firmware(struct device *dev, int index,
> + const char **fw_name);
>
> /* from remoteproc_virtio.c */
> int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id);
> --
> 2.26.0
>
^ permalink raw reply
* [PATCH 2/2] dt-bindings: tas2562: Convert the tas2562 binding to yaml
From: Dan Murphy @ 2020-06-02 19:35 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai
Cc: alsa-devel, linux-kernel, robh, devicetree, Dan Murphy
In-Reply-To: <20200602193524.30309-1-dmurphy@ti.com>
Convert the TAS2562 text file to yaml format.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../devicetree/bindings/sound/tas2562.txt | 34 ----------
.../devicetree/bindings/sound/tas2562.yaml | 65 +++++++++++++++++++
2 files changed, 65 insertions(+), 34 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/tas2562.txt
create mode 100644 Documentation/devicetree/bindings/sound/tas2562.yaml
diff --git a/Documentation/devicetree/bindings/sound/tas2562.txt b/Documentation/devicetree/bindings/sound/tas2562.txt
deleted file mode 100644
index 94796b547184..000000000000
--- a/Documentation/devicetree/bindings/sound/tas2562.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Texas Instruments TAS2562 Smart PA
-
-The TAS2562 is a mono, digital input Class-D audio amplifier optimized for
-efficiently driving high peak power into small loudspeakers.
-Integrated speaker voltage and current sense provides for
-real time monitoring of loudspeaker behavior.
-
-Required properties:
- - #address-cells - Should be <1>.
- - #size-cells - Should be <0>.
- - compatible: - Should contain "ti,tas2562", "ti,tas2563".
- - reg: - The i2c address. Should be 0x4c, 0x4d, 0x4e or 0x4f.
- - ti,imon-slot-no:- TDM TX current sense time slot.
-
-Optional properties:
-- interrupt-parent: phandle to the interrupt controller which provides
- the interrupt.
-- interrupts: (GPIO) interrupt to which the chip is connected.
-- shut-down: GPIO used to control the state of the device.
-
-Examples:
-tas2562@4c {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "ti,tas2562";
- reg = <0x4c>;
-
- interrupt-parent = <&gpio1>;
- interrupts = <14>;
-
- shut-down = <&gpio1 15 0>;
- ti,imon-slot-no = <0>;
-};
-
diff --git a/Documentation/devicetree/bindings/sound/tas2562.yaml b/Documentation/devicetree/bindings/sound/tas2562.yaml
new file mode 100644
index 000000000000..11e0269d03b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tas2562.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause)
+# Copyright (C) 2019 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/sound/tas2562.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Texas Instruments TAS2562 Smart PA
+
+maintainers:
+ - Dan Murphy <dmurphy@ti.com>
+
+description: |
+ The TAS2562 is a mono, digital input Class-D audio amplifier optimized for
+ efficiently driving high peak power into small loudspeakers.
+ Integrated speaker voltage and current sense provides for
+ real time monitoring of loudspeaker behavior.
+
+properties:
+ compatible:
+ enum:
+ - ti,tas2562
+ - ti,tas2563
+
+ reg:
+ maxItems: 1
+ description: |
+ I2C addresss of the device can be one of these 0x4c, 0x4d, 0x4e or 0x4f
+
+ shut-down:
+ description: GPIO used to control the state of the device.
+
+ interrupts:
+ maxItems: 1
+
+ ti,imon-slot-no:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: TDM TX current sense time slot.
+
+ '#sound-dai-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec: codec@4c {
+ compatible = "ti,tas2562";
+ reg = <0x4c>;
+ #sound-dai-cells = <1>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <14>;
+
+ shut-down = <&gpio1 15 0>;
+ ti,imon-slot-no = <0>;
+ };
+ };
+
--
2.26.2
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: ASoc: Fix tdm-slot documentation spelling error
From: Dan Murphy @ 2020-06-02 19:35 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai
Cc: alsa-devel, linux-kernel, robh, devicetree, Dan Murphy
Fix the spelling of 'specified'. Also fix grammarical issue with the
use of 'a' over 'an'
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
Documentation/devicetree/bindings/sound/tdm-slot.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/tdm-slot.txt b/Documentation/devicetree/bindings/sound/tdm-slot.txt
index 34cf70e2cbc4..4bb513ae62fc 100644
--- a/Documentation/devicetree/bindings/sound/tdm-slot.txt
+++ b/Documentation/devicetree/bindings/sound/tdm-slot.txt
@@ -14,8 +14,8 @@ For instance:
dai-tdm-slot-tx-mask = <0 1>;
dai-tdm-slot-rx-mask = <1 0>;
-And for each spcified driver, there could be one .of_xlate_tdm_slot_mask()
-to specify a explicit mapping of the channels and the slots. If it's absent
+And for each specified driver, there could be one .of_xlate_tdm_slot_mask()
+to specify an explicit mapping of the channels and the slots. If it's absent
the default snd_soc_of_xlate_tdm_slot_mask() will be used to generating the
tx and rx masks.
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v3 3/4] iio: chemical: scd30: add serial interface driver
From: Tomasz Duszynski @ 2020-06-02 19:15 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Tomasz Duszynski, linux-iio, Linux Kernel Mailing List,
devicetree, Rob Herring, Jonathan Cameron, Peter Meerwald
In-Reply-To: <20200602175723.GC2668@arch>
On Tue, Jun 02, 2020 at 07:57:23PM +0200, Tomasz Duszynski wrote:
> On Tue, Jun 02, 2020 at 08:04:16PM +0300, Andy Shevchenko wrote:
> > On Tue, Jun 2, 2020 at 7:49 PM Tomasz Duszynski
> > <tomasz.duszynski@octakon.com> wrote:
> > >
> > > Add serial interface driver for the SCD30 sensor.
> >
> > ...
> >
> > > +static u16 scd30_serdev_cmd_lookup_tbl[] = {
> > > + [CMD_START_MEAS] = 0x0036,
> > > + [CMD_STOP_MEAS] = 0x0037,
> > > + [CMD_MEAS_INTERVAL] = 0x0025,
> > > + [CMD_MEAS_READY] = 0x0027,
> > > + [CMD_READ_MEAS] = 0x0028,
> > > + [CMD_ASC] = 0x003a,
> > > + [CMD_FRC] = 0x0039,
> > > + [CMD_TEMP_OFFSET] = 0x003b,
> > > + [CMD_FW_VERSION] = 0x0020,
> > > + [CMD_RESET] = 0x0034,
> >
> > Hmm... Can't we keep them ordered by value?
> >
> > > +};
> >
> > ...
> >
> > > + ret = wait_for_completion_interruptible_timeout(&priv->meas_ready,
> > > + SCD30_SERDEV_TIMEOUT);
> > > + if (ret > 0)
> > > + ret = 0;
> > > + else if (!ret)
> > > + ret = -ETIMEDOUT;
> > > +
> > > + return ret;
> >
> > Perhaps
> >
> > if (ret < 0)
> > return ret;
> > if (ret == 0)
> > return -ETIMEDOUT;
> > return 0;
> >
> > ?
>
> Matter of style but since I will be doing other changes I can touch that
> too.
>
> >
> > ...
> >
> > > + char txbuf[SCD30_SERDEV_MAX_BUF_SIZE] = { SCD30_SERDEV_ADDR },
> > > + rxbuf[SCD30_SERDEV_MAX_BUF_SIZE], *rsp = response;
> >
> > Please, apply type to each variable separately.
> >
>
> Fine.
>
> > ...
> >
> > > + switch (txbuf[1]) {
> > > + case SCD30_SERDEV_WRITE:
> >
> > > + if (memcmp(txbuf, txbuf, txsize)) {
> >
> > I'm not sure I understand this.
> >
>
> Ah, thanks for catching this. tx should be compared to rx.
>
> > > + dev_err(state->dev, "wrong message received\n");
> > > + return -EIO;
> > > + }
> > > + break;
> > > + case SCD30_SERDEV_READ:
> >
> > > + if (rxbuf[2] != (rxsize -
> > > + SCD30_SERDEV_RX_HEADER_SIZE -
> > > + SCD30_SERDEV_CRC_SIZE)) {
> >
> > Perhaps you can come up with better indentation/ line split?
> >
>
> I'd rather leave it as is.
>
On the second thought, that would fit 100 column line.
> > > + dev_err(state->dev,
> > > + "received data size does not match header\n");
> > > + return -EIO;
> > > + }
> > > +
> > > + rxsize -= SCD30_SERDEV_CRC_SIZE;
> > > + crc = get_unaligned_le16(rxbuf + rxsize);
> > > + if (crc != scd30_serdev_calc_crc(rxbuf, rxsize)) {
> > > + dev_err(state->dev, "data integrity check failed\n");
> > > + return -EIO;
> > > + }
> > > +
> > > + rxsize -= SCD30_SERDEV_RX_HEADER_SIZE;
> > > + memcpy(rsp, rxbuf + SCD30_SERDEV_RX_HEADER_SIZE, rxsize);
> > > + break;
> > > + default:
> > > + dev_err(state->dev, "received unknown op code\n");
> > > + return -EIO;
> > > + }
> > > +
> > > + return 0;
> > > +}
> >
> > ...
> >
> > > +static struct serdev_device_driver scd30_serdev_driver = {
> > > + .driver = {
> >
> > > + .name = KBUILD_MODNAME,
> >
> > This is not the best what we can do. The name is an ABI and better if
> > it will be constant (independent on file name).
> >
> > > + .of_match_table = scd30_serdev_of_match,
> > > + .pm = &scd30_pm_ops,
> > > + },
> > > + .probe = scd30_serdev_probe,
> > > +};
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 01/10] spi: dw: Add support for polled operation via no IRQ specified in DT
From: Serge Semin @ 2020-06-02 19:10 UTC (permalink / raw)
To: Lars Povlsen
Cc: Serge Semin, Mark Brown, SoC Team, devicetree, Alexandre Belloni,
linux-kernel, linux-spi, Microchip Linux Driver Support,
linux-arm-kernel
In-Reply-To: <20200513140031.25633-2-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 04:00:22PM +0200, Lars Povlsen wrote:
> With this change a SPI controller can be added without having a IRQ
> associated, and causing all transfers to be polled. For SPI controllers
> without DMA, this can significantly improve performance by less
> interrupt handling overhead.
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
> drivers/spi/spi-dw.c | 21 +++++++++++++--------
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
> index 31e3f866d11a7..e572eb34a3c1a 100644
> --- a/drivers/spi/spi-dw.c
> +++ b/drivers/spi/spi-dw.c
> @@ -19,6 +19,8 @@
> #include <linux/debugfs.h>
> #endif
>
> +#define VALID_IRQ(i) (i >= 0)
Mark and Andy are right. It is a good candidate to be in a generic IRQ-related
code as Anyd suggested:
> > drivers/rtc/rtc-cmos.c:95:#define is_valid_irq(n) ((n) > 0)
> > Candidate to be in include/linux/irq.h ?
So if you feel like to author additional useful patch integrated into the
kernel, this one is a good chance for it.
> +
> /* Slave spi_dev related */
> struct chip_data {
> u8 tmode; /* TR/TO/RO/EEPROM */
> @@ -359,7 +361,7 @@ static int dw_spi_transfer_one(struct spi_controller *master,
> spi_enable_chip(dws, 1);
> return ret;
> }
> - } else if (!chip->poll_mode) {
> + } else if (!chip->poll_mode && VALID_IRQ(dws->irq)) {
> txlevel = min_t(u16, dws->fifo_len / 2, dws->len / dws->n_bytes);
> dw_writel(dws, DW_SPI_TXFLTR, txlevel);
>
> @@ -379,7 +381,7 @@ static int dw_spi_transfer_one(struct spi_controller *master,
> return ret;
> }
>
> - if (chip->poll_mode)
> + if (chip->poll_mode || !VALID_IRQ(dws->irq))
> return poll_transfer(dws);
Please note. The chip->poll and the poll_transfer() methods've been discarded
from the driver, since commit 1ceb09717e98 ("spi: dw: remove cs_control and
poll_mode members from chip_data"). So you gonna have to get the
poll_transfer-like method back.
-Sergey
>
> return 1;
> @@ -487,11 +489,13 @@ int dw_spi_add_host(struct device *dev, struct dw_spi *dws)
>
> spi_controller_set_devdata(master, dws);
>
> - ret = request_irq(dws->irq, dw_spi_irq, IRQF_SHARED, dev_name(dev),
> - master);
> - if (ret < 0) {
> - dev_err(dev, "can not get IRQ\n");
> - goto err_free_master;
> + if (VALID_IRQ(dws->irq)) {
> + ret = request_irq(dws->irq, dw_spi_irq, IRQF_SHARED,
> + dev_name(dev), master);
> + if (ret < 0) {
> + dev_err(dev, "can not get IRQ\n");
> + goto err_free_master;
> + }
> }
>
> master->use_gpio_descriptors = true;
> @@ -539,7 +543,8 @@ int dw_spi_add_host(struct device *dev, struct dw_spi *dws)
> if (dws->dma_ops && dws->dma_ops->dma_exit)
> dws->dma_ops->dma_exit(dws);
> spi_enable_chip(dws, 0);
> - free_irq(dws->irq, master);
> + if (VALID_IRQ(dws->irq))
> + free_irq(dws->irq, master);
> err_free_master:
> spi_controller_put(master);
> return ret;
> --
> 2.26.2
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 2/2] media: cec: i2c: ch7322: Add ch7322 CEC controller driver
From: Jeff Chase @ 2020-06-02 19:09 UTC (permalink / raw)
To: linux-media; +Cc: mchehab, hverkuil-cisco, robh+dt, devicetree, Jeff Chase
In-Reply-To: <20200602190914.218541-1-jnchase@google.com>
Add a CEC device driver for the Chrontel ch7322 CEC conroller.
This is an I2C device capable of sending and receiving CEC messages.
Signed-off-by: Jeff Chase <jnchase@google.com>
---
MAINTAINERS | 1 +
drivers/media/cec/Kconfig | 1 +
drivers/media/cec/Makefile | 2 +-
drivers/media/cec/i2c/Kconfig | 14 +
drivers/media/cec/i2c/Makefile | 5 +
drivers/media/cec/i2c/ch7322.c | 503 +++++++++++++++++++++++++++++++++
6 files changed, 525 insertions(+), 1 deletion(-)
create mode 100644 drivers/media/cec/i2c/Kconfig
create mode 100644 drivers/media/cec/i2c/Makefile
create mode 100644 drivers/media/cec/i2c/ch7322.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 34c6d30e61e5..43e876395686 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4053,6 +4053,7 @@ L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/chontel,ch7322.yaml
+F: drivers/media/cec/i2c/ch7322.c
CIRRUS LOGIC AUDIO CODEC DRIVERS
M: James Schulman <james.schulman@cirrus.com>
diff --git a/drivers/media/cec/Kconfig b/drivers/media/cec/Kconfig
index eea74b7cfa8c..3e934aa239ab 100644
--- a/drivers/media/cec/Kconfig
+++ b/drivers/media/cec/Kconfig
@@ -33,6 +33,7 @@ menuconfig MEDIA_CEC_SUPPORT
adapter that supports HDMI CEC.
if MEDIA_CEC_SUPPORT
+source "drivers/media/cec/i2c/Kconfig"
source "drivers/media/cec/platform/Kconfig"
source "drivers/media/cec/usb/Kconfig"
endif
diff --git a/drivers/media/cec/Makefile b/drivers/media/cec/Makefile
index 74e80e1b3571..23539339bc81 100644
--- a/drivers/media/cec/Makefile
+++ b/drivers/media/cec/Makefile
@@ -1,2 +1,2 @@
# SPDX-License-Identifier: GPL-2.0
-obj-y += core/ platform/ usb/
+obj-y += core/ i2c/ platform/ usb/
diff --git a/drivers/media/cec/i2c/Kconfig b/drivers/media/cec/i2c/Kconfig
new file mode 100644
index 000000000000..e445ca2110b3
--- /dev/null
+++ b/drivers/media/cec/i2c/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# I2C drivers
+
+config CEC_CH7322
+ tristate "Chrontel CH7322 CEC controller"
+ select I2C
+ select REGMAP_I2C
+ select CEC_CORE
+ help
+ This is a driver for the Chrontel CH7322 CEC controller. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
diff --git a/drivers/media/cec/i2c/Makefile b/drivers/media/cec/i2c/Makefile
new file mode 100644
index 000000000000..d7496dfd0fa4
--- /dev/null
+++ b/drivers/media/cec/i2c/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for the CEC I2C device drivers.
+#
+obj-$(CONFIG_CEC_CH7322) += ch7322.o
diff --git a/drivers/media/cec/i2c/ch7322.c b/drivers/media/cec/i2c/ch7322.c
new file mode 100644
index 000000000000..4e6976a51774
--- /dev/null
+++ b/drivers/media/cec/i2c/ch7322.c
@@ -0,0 +1,503 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for the Chrontel CH7322 CEC Controller
+ *
+ * Copyright 2020 Google LLC.
+ */
+
+/*
+ * Notes
+ *
+ * - This device powers on in Auto Mode which has limited functionality. This
+ * driver disables Auto Mode when it attaches.
+ *
+ */
+
+#include <linux/cec.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/regmap.h>
+#include <media/cec.h>
+
+#define CH7322_WRITE 0x00
+#define CH7322_WRITE_MSENT 0x80
+#define CH7322_WRITE_BOK 0x40
+#define CH7322_WRITE_NMASK 0x0f
+
+/* Write buffer is 0x01-0x10 */
+#define CH7322_WRBUF 0x01
+#define CH7322_WRBUF_LEN 0x10
+
+#define CH7322_READ 0x40
+#define CH7322_READ_NRDT 0x80
+#define CH7322_READ_MSENT 0x20
+#define CH7322_READ_NMASK 0x0f
+
+/* Read buffer is 0x41-0x50 */
+#define CH7322_RDBUF 0x41
+#define CH7322_RDBUF_LEN 0x10
+
+#define CH7322_MODE 0x11
+#define CH7322_MODE_AUTO 0x78
+#define CH7322_MODE_SW 0xb5
+
+#define CH7322_RESET 0x12
+#define CH7322_RESET_RST 0x00
+
+#define CH7322_POWER 0x13
+#define CH7322_POWER_FPD 0x04
+
+#define CH7322_CFG0 0x17
+#define CH7322_CFG0_EOBEN 0x40
+#define CH7322_CFG0_PEOB 0x20
+#define CH7322_CFG0_CLRSPP 0x10
+#define CH7322_CFG0_FLOW 0x08
+
+#define CH7322_CFG1 0x1a
+#define CH7322_CFG1_STDBYO 0x04
+#define CH7322_CFG1_HPBP 0x02
+#define CH7322_CFG1_PIO 0x01
+
+#define CH7322_INTCTL 0x1b
+#define CH7322_INTCTL_INTPB 0x80
+#define CH7322_INTCTL_STDBY 0x40
+#define CH7322_INTCTL_HPDFALL 0x20
+#define CH7322_INTCTL_HPDRISE 0x10
+#define CH7322_INTCTL_RXMSG 0x08
+#define CH7322_INTCTL_TXMSG 0x04
+#define CH7322_INTCTL_NEWPHA 0x02
+#define CH7322_INTCTL_ERROR 0x01
+
+#define CH7322_DVCLKFNH 0x1d
+#define CH7322_DVCLKFNL 0x1e
+
+#define CH7322_CTL 0x31
+#define CH7322_CTL_FSTDBY 0x80
+#define CH7322_CTL_PLSEN 0x40
+#define CH7322_CTL_PLSPB 0x20
+#define CH7322_CTL_SPADL 0x10
+#define CH7322_CTL_HINIT 0x08
+#define CH7322_CTL_WPHYA 0x04
+#define CH7322_CTL_H1T 0x02
+#define CH7322_CTL_S1T 0x01
+
+#define CH7322_PAWH 0x32
+#define CH7322_PAWL 0x33
+
+#define CH7322_ADDLW 0x34
+#define CH7322_ADDLW_MASK 0xf0
+
+#define CH7322_ADDLR 0x3d
+#define CH7322_ADDLR_HPD 0x80
+#define CH7322_ADDLR_MASK 0x0f
+
+#define CH7322_INTDATA 0x3e
+#define CH7322_INTDATA_MODE 0x80
+#define CH7322_INTDATA_STDBY 0x40
+#define CH7322_INTDATA_HPDFALL 0x20
+#define CH7322_INTDATA_HPDRISE 0x10
+#define CH7322_INTDATA_RXMSG 0x08
+#define CH7322_INTDATA_TXMSG 0x04
+#define CH7322_INTDATA_NEWPHA 0x02
+#define CH7322_INTDATA_ERROR 0x01
+
+#define CH7322_EVENT 0x3F
+#define CH7322_EVENT_TXERR 0x80
+#define CH7322_EVENT_HRST 0x40
+#define CH7322_EVENT_HFST 0x20
+#define CH7322_EVENT_PHACHG 0x10
+#define CH7322_EVENT_ACTST 0x08
+#define CH7322_EVENT_PHARDY 0x04
+#define CH7322_EVENT_BSOK 0x02
+#define CH7322_EVENT_ERRADCF 0x01
+
+#define CH7322_DID 0x51
+#define CH7322_DID_CH7322 0x5b
+#define CH7322_DID_CH7323 0x5f
+
+#define CH7322_REVISIONID 0x52
+
+#define CH7322_PARH 0x53
+#define CH7322_PARL 0x54
+
+#define CH7322_IOCFG2 0x75
+#define CH7322_IOCFG_CIO 0x80
+#define CH7322_IOCFG_IOCFGMASK 0x78
+#define CH7322_IOCFG_AUDIO 0x04
+#define CH7322_IOCFG_SPAMST 0x02
+#define CH7322_IOCFG_SPAMSP 0x01
+
+#define CH7322_CTL3 0x7b
+#define CH7322_CTL3_SWENA 0x80
+#define CH7322_CTL3_FC_INIT 0x40
+#define CH7322_CTL3_SML_FL 0x20
+#define CH7322_CTL3_SM_RDST 0x10
+#define CH7322_CTL3_SPP_CIAH 0x08
+#define CH7322_CTL3_SPP_CIAL 0x04
+#define CH7322_CTL3_SPP_ACTH 0x02
+#define CH7322_CTL3_SPP_ACTL 0x01
+
+/* BOK status means NACK */
+#define CH7322_TX_FLAG_NACK BIT(0)
+/* Device will retry automatically */
+#define CH7322_TX_FLAG_RETRY BIT(1)
+
+struct ch7322 {
+ struct i2c_client *i2c;
+ struct regmap *regmap;
+ struct cec_adapter *cec;
+ struct mutex mutex; /* device access mutex */
+ u8 tx_flags;
+};
+
+static const struct regmap_config ch7322_regmap = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0x7f,
+ .disable_locking = true,
+
+};
+
+static int ch7322_send_message(struct ch7322 *ch7322, const struct cec_msg *msg)
+{
+ unsigned int val;
+ unsigned int len = msg->len;
+ int ret;
+ int i;
+
+ WARN_ON(!mutex_is_locked(&ch7322->mutex));
+
+ if (len > CH7322_WRBUF_LEN || len < 1)
+ return -EINVAL;
+
+ ret = regmap_read(ch7322->regmap, CH7322_WRITE, &val);
+ if (ret)
+ return ret;
+
+ /* Buffer not ready */
+ if (!(val & CH7322_WRITE_MSENT))
+ return -EBUSY;
+
+ if (cec_msg_opcode(msg) == -1 &&
+ cec_msg_initiator(msg) == cec_msg_destination(msg)) {
+ ch7322->tx_flags = CH7322_TX_FLAG_NACK | CH7322_TX_FLAG_RETRY;
+ } else if (cec_msg_is_broadcast(msg)) {
+ ch7322->tx_flags = CH7322_TX_FLAG_NACK;
+ } else {
+ ch7322->tx_flags = CH7322_TX_FLAG_RETRY;
+ }
+
+ ret = regmap_write(ch7322->regmap, CH7322_WRITE, len - 1);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < len; i++) {
+ ret = regmap_write(ch7322->regmap,
+ CH7322_WRBUF + i, msg->msg[i]);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ch7322_receive_message(struct ch7322 *ch7322, struct cec_msg *msg)
+{
+ unsigned int val;
+ int ret = 0;
+ int i;
+
+ WARN_ON(!mutex_is_locked(&ch7322->mutex));
+
+ ret = regmap_read(ch7322->regmap, CH7322_READ, &val);
+ if (ret)
+ return ret;
+
+ /* Message not ready */
+ if (!(val & CH7322_READ_NRDT))
+ return -EIO;
+
+ msg->len = (val & CH7322_READ_NMASK) + 1;
+
+ /* Read entire RDBUF to clear state */
+ for (i = 0; i < CH7322_RDBUF_LEN; i++) {
+ ret = regmap_read(ch7322->regmap, CH7322_RDBUF + i, &val);
+ if (ret)
+ return ret;
+ msg->msg[i] = (u8)val;
+ }
+
+ return 0;
+}
+
+static void ch7322_tx_done(struct ch7322 *ch7322)
+{
+ int ret;
+ unsigned int val;
+ u8 status, flags;
+
+ mutex_lock(&ch7322->mutex);
+ ret = regmap_read(ch7322->regmap, CH7322_WRITE, &val);
+ flags = ch7322->tx_flags;
+ mutex_unlock(&ch7322->mutex);
+
+ /*
+ * The device returns a one-bit OK status which usually means ACK but
+ * actually means NACK when sending a logical address query or a
+ * broadcast.
+ */
+ if (ret)
+ status = CEC_TX_STATUS_ERROR;
+ else if ((val & CH7322_WRITE_BOK) && (flags & CH7322_TX_FLAG_NACK))
+ status = CEC_TX_STATUS_NACK;
+ else if (val & CH7322_WRITE_BOK)
+ status = CEC_TX_STATUS_OK;
+ else if (flags & CH7322_TX_FLAG_NACK)
+ status = CEC_TX_STATUS_OK;
+ else
+ status = CEC_TX_STATUS_NACK;
+
+ if (status == CEC_TX_STATUS_NACK && (flags & CH7322_TX_FLAG_RETRY))
+ status |= CEC_TX_STATUS_MAX_RETRIES;
+
+ cec_transmit_attempt_done(ch7322->cec, status);
+}
+
+static void ch7322_rx_done(struct ch7322 *ch7322)
+{
+ struct cec_msg msg;
+ int ret;
+
+ mutex_lock(&ch7322->mutex);
+ ret = ch7322_receive_message(ch7322, &msg);
+ mutex_unlock(&ch7322->mutex);
+
+ if (ret)
+ dev_err(&ch7322->i2c->dev, "cec receive error: %d\n", ret);
+ else
+ cec_received_msg(ch7322->cec, &msg);
+}
+
+/*
+ * This device can either monitor the DDC lines to obtain the physical address
+ * or it can allow the host to program it. This driver lets the device obtain
+ * it.
+ */
+static void ch7322_phys_addr(struct ch7322 *ch7322)
+{
+ unsigned int pah, pal;
+ int ret = 0;
+
+ mutex_lock(&ch7322->mutex);
+ ret |= regmap_read(ch7322->regmap, CH7322_PARH, &pah);
+ ret |= regmap_read(ch7322->regmap, CH7322_PARL, &pal);
+ mutex_unlock(&ch7322->mutex);
+
+ if (ret)
+ dev_err(&ch7322->i2c->dev, "phys addr error\n");
+ else
+ cec_s_phys_addr(ch7322->cec, pal | (pah << 8), false);
+}
+
+static void ch7322_handle_events(struct ch7322 *ch7322)
+{
+ unsigned int data = 0;
+
+ mutex_lock(&ch7322->mutex);
+ regmap_read(ch7322->regmap, CH7322_INTDATA, &data);
+ regmap_write(ch7322->regmap, CH7322_INTDATA, data);
+ mutex_unlock(&ch7322->mutex);
+
+ if (data & CH7322_INTDATA_HPDFALL)
+ cec_phys_addr_invalidate(ch7322->cec);
+
+ if (data & CH7322_INTDATA_TXMSG)
+ ch7322_tx_done(ch7322);
+
+ if (data & CH7322_INTDATA_RXMSG)
+ ch7322_rx_done(ch7322);
+
+ if (data & CH7322_INTDATA_NEWPHA)
+ ch7322_phys_addr(ch7322);
+
+ if (data & CH7322_INTDATA_ERROR)
+ dev_dbg(&ch7322->i2c->dev, "unknown error\n");
+}
+
+static irqreturn_t ch7322_irq(int irq, void *dev)
+{
+ struct ch7322 *ch7322 = dev;
+
+ ch7322_handle_events(ch7322);
+
+ return IRQ_HANDLED;
+}
+
+/* This device is always enabled */
+static int ch7322_cec_adap_enable(struct cec_adapter *adap, bool enable)
+{
+ return 0;
+}
+
+static int ch7322_cec_adap_log_addr(struct cec_adapter *adap, u8 log_addr)
+{
+ struct ch7322 *ch7322 = cec_get_drvdata(adap);
+ int ret;
+
+ mutex_lock(&ch7322->mutex);
+ ret = regmap_update_bits(ch7322->regmap, CH7322_ADDLW,
+ CH7322_ADDLW_MASK, log_addr << 4);
+ mutex_unlock(&ch7322->mutex);
+
+ return ret;
+}
+
+static int ch7322_cec_adap_transmit(struct cec_adapter *adap, u8 attempts,
+ u32 signal_free_time, struct cec_msg *msg)
+{
+ struct ch7322 *ch7322 = cec_get_drvdata(adap);
+ int ret;
+
+ mutex_lock(&ch7322->mutex);
+ ret = ch7322_send_message(ch7322, msg);
+ mutex_unlock(&ch7322->mutex);
+
+ return ret;
+}
+
+static const struct cec_adap_ops ch7322_cec_adap_ops = {
+ .adap_enable = ch7322_cec_adap_enable,
+ .adap_log_addr = ch7322_cec_adap_log_addr,
+ .adap_transmit = ch7322_cec_adap_transmit,
+};
+
+static int ch7322_probe(struct i2c_client *client)
+{
+ struct ch7322 *ch7322;
+ int ret;
+ unsigned int val;
+
+ ch7322 = devm_kzalloc(&client->dev, sizeof(*ch7322), GFP_KERNEL);
+ if (!ch7322)
+ return -ENOMEM;
+
+ ch7322->regmap = devm_regmap_init_i2c(client, &ch7322_regmap);
+ if (IS_ERR(ch7322->regmap))
+ return PTR_ERR(ch7322->regmap);
+
+ ret = regmap_read(ch7322->regmap, CH7322_DID, &val);
+ if (ret)
+ return ret;
+
+ if (val != CH7322_DID_CH7322)
+ return -ENOTSUPP;
+
+ mutex_init(&ch7322->mutex);
+ ch7322->i2c = client;
+ ch7322->tx_flags = 0;
+
+ i2c_set_clientdata(client, ch7322);
+
+ /* Disable auto mode */
+ ret = regmap_write(ch7322->regmap, CH7322_MODE, CH7322_MODE_SW);
+ if (ret)
+ goto err_mutex;
+
+ /* Enable logical address register */
+ ret = regmap_update_bits(ch7322->regmap, CH7322_CTL,
+ CH7322_CTL_SPADL, CH7322_CTL_SPADL);
+ if (ret)
+ goto err_mutex;
+
+ ch7322->cec = cec_allocate_adapter(&ch7322_cec_adap_ops, ch7322,
+ dev_name(&client->dev),
+ CEC_CAP_DEFAULTS, 1);
+
+ if (IS_ERR(ch7322->cec)) {
+ ret = PTR_ERR(ch7322->cec);
+ goto err_mutex;
+ }
+
+ ret = cec_register_adapter(ch7322->cec, &client->dev);
+ if (ret) {
+ cec_delete_adapter(ch7322->cec);
+ goto err_mutex;
+ }
+
+ /* Configure and mask interrupt */
+ ret = regmap_write(ch7322->regmap, CH7322_CFG1, 0);
+ if (ret)
+ goto err_cec;
+
+ ret = regmap_write(ch7322->regmap, CH7322_INTCTL, CH7322_INTCTL_INTPB);
+ if (ret)
+ goto err_cec;
+
+ ret = devm_request_threaded_irq(&client->dev, client->irq, NULL,
+ ch7322_irq,
+ IRQF_ONESHOT | IRQF_TRIGGER_RISING,
+ client->name, ch7322);
+ if (ret)
+ goto err_cec;
+
+ ch7322_handle_events(ch7322);
+
+ /* Unmask interrupt */
+ mutex_lock(&ch7322->mutex);
+ ret = regmap_write(ch7322->regmap, CH7322_INTCTL, 0xff);
+ mutex_unlock(&ch7322->mutex);
+
+ if (ret)
+ goto err_cec;
+
+ dev_info(&client->dev, "device registered\n");
+
+ return 0;
+
+err_cec:
+ cec_unregister_adapter(ch7322->cec);
+
+err_mutex:
+ mutex_destroy(&ch7322->mutex);
+ return ret;
+}
+
+static int ch7322_remove(struct i2c_client *client)
+{
+ struct ch7322 *ch7322 = i2c_get_clientdata(client);
+
+ /* Mask interrupt */
+ mutex_lock(&ch7322->mutex);
+ regmap_write(ch7322->regmap, CH7322_INTCTL, CH7322_INTCTL_INTPB);
+ mutex_unlock(&ch7322->mutex);
+
+ cec_unregister_adapter(ch7322->cec);
+ mutex_destroy(&ch7322->mutex);
+
+ dev_info(&client->dev, "device unregistered\n");
+
+ return 0;
+}
+
+static const struct of_device_id ch7322_of_match[] = {
+ { .compatible = "chrontel,ch7322", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ch7322_of_match);
+
+static struct i2c_driver ch7322_i2c_driver = {
+ .driver = {
+ .name = "ch7322",
+ .of_match_table = of_match_ptr(ch7322_of_match),
+ },
+ .probe_new = ch7322_probe,
+ .remove = ch7322_remove,
+};
+
+module_i2c_driver(ch7322_i2c_driver);
+
+MODULE_DESCRIPTION("Chrontel CH7322 CEC Controller Driver");
+MODULE_AUTHOR("Jeff Chase <jnchase@google.com>");
+MODULE_LICENSE("GPL");
--
2.27.0.rc2.251.g90737beb825-goog
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: Add ch7322 media i2c device
From: Jeff Chase @ 2020-06-02 19:09 UTC (permalink / raw)
To: linux-media; +Cc: mchehab, hverkuil-cisco, robh+dt, devicetree, Jeff Chase
In-Reply-To: <20200602190914.218541-1-jnchase@google.com>
The ch7322 is a Chrontel CEC controller.
Signed-off-by: Jeff Chase <jnchase@google.com>
---
.../bindings/media/i2c/chrontel,ch7322.yaml | 67 +++++++++++++++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 7 ++
3 files changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml
diff --git a/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml
new file mode 100644
index 000000000000..daa2869377c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/media/i2c/chrontel,ch7322.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Chrontel HDMI-CEC Controller
+
+maintainers:
+ - Jeff Chase <jnchase@google.com>
+
+description:
+ The Chrontel CH7322 is a discrete HDMI-CEC controller. It is
+ programmable through I2C and drives a single CEC line.
+
+properties:
+ compatible:
+ const: chrontel,ch7322
+
+ reg:
+ description: I2C device address
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ Reference to the GPIO connected to the RESET pin, if any. This
+ pin is active-low.
+ maxItems: 1
+
+ standby-gpios:
+ description:
+ Reference to the GPIO connected to the OE pin, if any. When low
+ the device will respond to power status requests with "standby"
+ if in auto mode.
+ maxItems: 1
+
+ # see ../cec.txt
+ hdmi-phandle:
+ description: phandle to the HDMI controller
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ch7322@75 {
+ compatible = "chrontel,ch7322";
+ reg = <0x75>;
+ interrupts = <47 IRQ_TYPE_EDGE_RISING>;
+ standby-gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
+ hdmi-phandle = <&hdmi>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index d3891386d671..7794ffccd325 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -187,6 +187,8 @@ patternProperties:
description: ChipOne
"^chipspark,.*":
description: ChipSPARK
+ "^chrontel,.*":
+ description: Chrontel, Inc.
"^chrp,.*":
description: Common Hardware Reference Platform
"^chunghwa,.*":
diff --git a/MAINTAINERS b/MAINTAINERS
index d633a131dcd7..34c6d30e61e5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4047,6 +4047,13 @@ F: drivers/power/supply/cros_usbpd-charger.c
N: cros_ec
N: cros-ec
+CHRONTEL CH7322 CEC DRIVER
+M: Jeff Chase <jnchase@google.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: Documentation/devicetree/bindings/media/i2c/chontel,ch7322.yaml
+
CIRRUS LOGIC AUDIO CODEC DRIVERS
M: James Schulman <james.schulman@cirrus.com>
M: David Rhodes <david.rhodes@cirrus.com>
--
2.27.0.rc2.251.g90737beb825-goog
^ permalink raw reply related
* [PATCH v4 0/2] CH7322 CEC controller driver
From: Jeff Chase @ 2020-06-02 19:09 UTC (permalink / raw)
To: linux-media; +Cc: mchehab, hverkuil-cisco, robh+dt, devicetree, Jeff Chase
Add device driver and device tree bindings for a Chrontel CEC
conroller. This is an I2C device that can send and receive CEC
messages.
Changes from v3:
- address devicetree comments
- revert interrupt mask/unmask in cec adapter enable
(the driver relies on the interrupt to get the physical address)
Changes from v2:
- fix formatting errors
- mask and unmask interrupt in cec adapter enable
Changes from v1:
- fix formatpatch.pl --strict errors
- additional comments
- enable and program logical address register
- add flags to aid interpreting transmit done status
- move ch7322 out of devicetree trivial devices
Jeff Chase (2):
dt-bindings: Add ch7322 media i2c device
media: cec: i2c: ch7322: Add ch7322 CEC controller driver
.../bindings/media/i2c/chrontel,ch7322.yaml | 67 +++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 8 +
drivers/media/cec/Kconfig | 1 +
drivers/media/cec/Makefile | 2 +-
drivers/media/cec/i2c/Kconfig | 14 +
drivers/media/cec/i2c/Makefile | 5 +
drivers/media/cec/i2c/ch7322.c | 503 ++++++++++++++++++
8 files changed, 601 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml
create mode 100644 drivers/media/cec/i2c/Kconfig
create mode 100644 drivers/media/cec/i2c/Makefile
create mode 100644 drivers/media/cec/i2c/ch7322.c
--
2.27.0.rc2.251.g90737beb825-goog
^ permalink raw reply
* [PATCH v2 0/1] Document Ingenic SoCs binding.
From: 周琰杰 (Zhou Yanjie) @ 2020-06-02 18:33 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, devicetree, tsbogend, robh+dt, paul, dongsheng.qiu,
aric.pzqi, rick.tyliu, yanfei.li, sernia.zhou, zhenwenjin
Document the available properties for the SoC root node and the
CPU nodes of the devicetree for the Ingenic XBurst SoCs.
v1->v2:
1.Remove unnecessary "items".
2.Add "clocks" as suggested by Paul Cercueil.
周琰杰 (Zhou Yanjie) (1):
dt-bindings: MIPS: Document Ingenic SoCs binding.
.../bindings/mips/ingenic/ingenic,cpu.yaml | 67 ++++++++++++++++++++++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
--
2.11.0
^ permalink raw reply
* [PATCH v2 1/1] dt-bindings: MIPS: Document Ingenic SoCs binding.
From: 周琰杰 (Zhou Yanjie) @ 2020-06-02 18:33 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, devicetree, tsbogend, robh+dt, paul, dongsheng.qiu,
aric.pzqi, rick.tyliu, yanfei.li, sernia.zhou, zhenwenjin
In-Reply-To: <20200602183354.39707-1-zhouyanjie@wanyeetech.com>
Document the available properties for the SoC root node and the
CPU nodes of the devicetree for the Ingenic XBurst SoCs.
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Tested-by: Paul Boddie <paul@boddie.org.uk>
Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
---
Notes:
v1->v2:
1.Remove unnecessary "items".
2.Add "clocks" as suggested by Paul Cercueil.
.../bindings/mips/ingenic/ingenic,cpu.yaml | 67 ++++++++++++++++++++++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
diff --git a/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
new file mode 100644
index 000000000000..171503e08505
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mips/ingenic/ingenic,cpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for Ingenic XBurst family CPUs
+
+maintainers:
+ - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
+
+description:
+ Ingenic XBurst family CPUs shall have the following properties.
+
+properties:
+ compatible:
+ oneOf:
+
+ - description: Ingenic XBurst®1 CPU Cores
+ enum:
+ - ingenic,xburst-mxu1.0
+ - ingenic,xburst-fpu1.0-mxu1.1
+ - ingenic,xburst-fpu2.0-mxu2.0
+
+ - description: Ingenic XBurst®2 CPU Cores
+ enum:
+ - ingenic,xburst2-fpu2.1-mxu2.1-smt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - device_type
+ - compatible
+ - reg
+ - clocks
+
+examples:
+ - |
+ #include <dt-bindings/clock/jz4780-cgu.h>
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "ingenic,xburst-fpu1.0-mxu1.1";
+ reg = <0>;
+
+ clocks = <&cgu JZ4780_CLK_CPU>;
+ clock-names = "cpu";
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "ingenic,xburst-fpu1.0-mxu1.1";
+ reg = <1>;
+
+ clocks = <&cgu JZ4780_CLK_CORE1>;
+ clock-names = "cpu";
+ };
+ };
+...
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] ARM: dts: AM33xx-l4: add gpio-ranges
From: Drew Fustini @ 2020-06-02 18:24 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Tony Lindgren, linux-omap, linux-kernel, Benoît Cousson,
Rob Herring, devicetree, Santosh Shilimkar, Suman Anna,
Haojian Zhuang, Linus Walleij, linux-gpio, jkridner,
robertcnelson
In-Reply-To: <803e2d78-28ba-0816-dbb5-d441d7659a91@ti.com>
On Tue, Jun 02, 2020 at 04:44:03PM +0300, Grygorii Strashko wrote:
>
>
> On 02/06/2020 16:14, Drew Fustini wrote:
> > Add gpio-ranges properties to the gpio controller nodes.
> >
> > These gpio-ranges were created based on "Table 9-10. CONTROL_MODULE
> > REGISTERS" in the "AM335x Technical Reference Manual" [0] and "Table
> > 4-2. Pin Attributes" in the "AM335x Sitara Processor datasheet" [1].
> > A csv file with this data is available for reference [2].
>
> It will be good if you can explain not only "what" is changed, but
> also "why" it's needed in commit message.
That is a good point.
One reason for this patch is I think it makes sense to add gpio-ranges
properties as they describe the relationship between a gpio line and
pin control register that exists in the hardware. For example, GPMC_A0
pin has mode 7 which is labeled gpio1_16. The conf_gpmc_a0 register is
at offset 840h which makes it pin 16.
The other reason is that I would like to patch omap_gpio_set_config()
to call gpiochip_generic_config() for PIN_CONFIG_PULL_{UP,DOWN}. It
currently fails at pinctrl_get_device_gpio_range():
omap_gpio_set_config()
|- gpiochip_generic_config()
|- pinctrl_gpio_set_config()
|- gpio_to_pin()
|- pinctrl_get_device_gpio_range() [no gpio-ranges so fails]
Thank you,
Drew
^ permalink raw reply
* Re: Fwd: [PATCH v3 2/2] media: cec: i2c: ch7322: Add ch7322 CEC controller driver
From: Jeff Chase @ 2020-06-02 18:17 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-media, mchehab, robh+dt, devicetree
In-Reply-To: <d7e759d1-9bdf-0ab3-143a-f0e374667f04@xs4all.nl>
> > I haven't looked into the cec notifier mechanism yet but would it be
> > better to try to use that instead if possible and just ignore this
> > device's physical address detection? Then I could do more of a proper
> > reset in this enable op. But I'm not sure if I can properly associate
> > the device with an HDMI port on my platform unless I make some changes
> > to coreboot.
>
> I don't think this is useful: it's nice to have the CEC adapter do the
> physical address detection.
>
> One question about that though: if there is no physical address, can this
> driver still transmit CEC messages? Specifically Image View On. This is
> important to wake up displays that pull down the HPD when in standby.
Yes it can. I just verified this with the kwikwai analyzer.
Thanks,
Jeff
^ permalink raw reply
* Re: [PATCH v3 0/4] Add support for SCD30 sensor
From: Tomasz Duszynski @ 2020-06-02 18:08 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Tomasz Duszynski, linux-iio, Linux Kernel Mailing List,
devicetree, Rob Herring, Jonathan Cameron, Peter Meerwald
In-Reply-To: <CAHp75VdPF=LzDn0f_Ljb=S+8L58DS4ofC6fD=Nzu1afR_nD8vQ@mail.gmail.com>
On Tue, Jun 02, 2020 at 07:55:55PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 2, 2020 at 7:49 PM Tomasz Duszynski
> <tomasz.duszynski@octakon.com> wrote:
> >
> > Following series adds support for Sensirion SCD30 sensor module capable of
> > measuring carbon dioxide, temperature and relative humidity. CO2 measurements
> > base on NDIR principle while temperature and relative humidity are measured by
> > the on board SHT31. As for sensor communication, both I2C and serial interfaces
> > are supported.
>
> Btw, since we have relaxed 80 limit to 100, I recommend to reconsider
> some lines to be joined.
>
Heh, that particular change is becoming more viral that corona itself these days.
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply
* Re: [PATCHv1 00/19] Improve SBS battery support
From: Sebastian Reichel @ 2020-06-02 18:01 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Rob Herring, Greg Kroah-Hartman, Rafael J . Wysocki, linux-pm,
devicetree, linux-kernel, kernel, 'Linux Samsung SOC'
In-Reply-To: <b3fd35de-1dd6-1ddc-7e57-2d9ab2860e81@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 5570 bytes --]
Hi,
On Tue, Jun 02, 2020 at 09:17:09AM +0200, Marek Szyprowski wrote:
> Hi Sebastian,
>
> On 01.06.2020 19:05, Sebastian Reichel wrote:
> > On Mon, Jun 01, 2020 at 12:40:27PM +0200, Marek Szyprowski wrote:
> >> On 13.05.2020 20:55, Sebastian Reichel wrote:
> >>> This patchset improves support for SBS compliant batteries. Due to
> >>> the changes, the battery now exposes 32 power supply properties and
> >>> (un)plugging it generates a backtrace containing the following message
> >>> without the first patch in this series:
> >>>
> >>> ---------------------------
> >>> WARNING: CPU: 0 PID: 20 at lib/kobject_uevent.c:659 add_uevent_var+0xd4/0x104
> >>> add_uevent_var: too many keys
> >>> ---------------------------
> >>>
> >>> For references this is what an SBS battery status looks like after
> >>> the patch series has been applied:
> >>>
> >>> cat /sys/class/power_supply/sbs-0-000b/uevent
> >>> POWER_SUPPLY_NAME=sbs-0-000b
> >>> POWER_SUPPLY_TYPE=Battery
> >>> POWER_SUPPLY_STATUS=Discharging
> >>> POWER_SUPPLY_CAPACITY_LEVEL=Normal
> >>> POWER_SUPPLY_HEALTH=Good
> >>> POWER_SUPPLY_PRESENT=1
> >>> POWER_SUPPLY_TECHNOLOGY=Li-ion
> >>> POWER_SUPPLY_CYCLE_COUNT=12
> >>> POWER_SUPPLY_VOLTAGE_NOW=11441000
> >>> POWER_SUPPLY_CURRENT_NOW=-26000
> >>> POWER_SUPPLY_CURRENT_AVG=-24000
> >>> POWER_SUPPLY_CAPACITY=76
> >>> POWER_SUPPLY_CAPACITY_ERROR_MARGIN=1
> >>> POWER_SUPPLY_TEMP=198
> >>> POWER_SUPPLY_TIME_TO_EMPTY_AVG=438600
> >>> POWER_SUPPLY_TIME_TO_FULL_AVG=3932100
> >>> POWER_SUPPLY_SERIAL_NUMBER=0000
> >>> POWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000
> >>> POWER_SUPPLY_VOLTAGE_MAX_DESIGN=10800000
> >>> POWER_SUPPLY_ENERGY_NOW=31090000
> >>> POWER_SUPPLY_ENERGY_FULL=42450000
> >>> POWER_SUPPLY_ENERGY_FULL_DESIGN=41040000
> >>> POWER_SUPPLY_CHARGE_NOW=2924000
> >>> POWER_SUPPLY_CHARGE_FULL=3898000
> >>> POWER_SUPPLY_CHARGE_FULL_DESIGN=3800000
> >>> POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=3000000
> >>> POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=12300000
> >>> POWER_SUPPLY_MANUFACTURE_YEAR=2017
> >>> POWER_SUPPLY_MANUFACTURE_MONTH=7
> >>> POWER_SUPPLY_MANUFACTURE_DAY=3
> >>> POWER_SUPPLY_MANUFACTURER=UR18650A
> >>> POWER_SUPPLY_MODEL_NAME=GEHC
> >> This patch landed in linux-next dated 20200529. Sadly it causes a
> >> regression on Samsung Exynos-based Chromebooks (Exynos5250 Snow,
> >> Exynos5420 Peach-Pi and Exynos5800 Peach-Pit). System boots to
> >> userspace, but then, when udev populates /dev, booting hangs:
> >>
> >> [ 4.435167] VFS: Mounted root (ext4 filesystem) readonly on device
> >> 179:51.
> >> [ 4.457477] devtmpfs: mounted
> >> [ 4.460235] Freeing unused kernel memory: 1024K
> >> [ 4.464022] Run /sbin/init as init process
> >> INIT: version 2.88 booting
> >> [info] Using makefile-style concurrent boot in runlevel S.
> >> [ 5.102096] random: crng init done
> >> [....] Starting the hotplug events dispatcher: systemd-udevdstarting
> >> version 236
> >> [ ok .
> >> [....] Synthesizing the initial hotplug events...[ ok done.
> >> [....] Waiting for /dev to be fully populated...[ 34.409914]
> >> TPS65090_RAILSDCDC1: disabling
> >> [ 34.412977] TPS65090_RAILSDCDC2: disabling
> >> [ 34.417021] TPS65090_RAILSDCDC3: disabling
> >> [ 34.423848] TPS65090_RAILSLDO1: disabling
> >> [ 34.429068] TPS65090_RAILSLDO2: disabling
> > :(
> >
> > log does not look useful either.
> >
> >> Bisect between v5.7-rc1 and next-20200529 pointed me to the first bad
> >> commit: [c4b12a2f3f3de670f6be5e96092a2cab0b877f1a] power: supply:
> >> sbs-battery: simplify read_read_string_data.
> > ok. I tested this on an to-be-upstreamed i.MX6 based system
> > and arch/arm/boot/dts/imx53-ppd.dts. I think the difference
> > is, that i2c-exynos5 does not expose I2C_FUNC_SMBUS_READ_BLOCK_DATA.
> > I hoped all systems using SBS battery support this, but now
> > I see I2C_FUNC_SMBUS_EMUL only supports writing block data.
> > Looks like I need to add another patch implementing that
> > using the old code with added PEC support.
> >
> > In any case that should only return -ENODEV for the property
> > (and uevent), but not break boot. So something fishy is going
> > on.
> >
> >> However reverting it in linux-next doesn't fix the issue, so the
> >> next commits are also relevant to this issue.
> > The next patch, which adds PEC support depends on the simplification
> > of sbs_read_string_data. The old, open coded variant will result in
> > PEC failure for string properties (which should not stop boot either
> > of course). Can you try reverting both?
> Indeed, reverting both (and fixing the conflict) restores proper boot.
Ok, I pushed out a revert of those two patches. They should land in
tomorrows linux-next release. Please test it.
> > If that helps I will revert those two instead of dropping the whole
> > series for this merge window.
> >
> >> Let me know how can I help debugging it.
> > I suspect, that this is userspace endlessly retrying reading the
> > battery uevent when an error is returned. Could you check this?
> > Should be easy to see by adding some printfs.
> I've added some debug messages in sbs_get_property() and it read the
> same properties many times. However I've noticed that if I wait long
> enough booting finally continues.
So basically userspace slows down itself massively by trying to
re-read uevent over and over when an error occurs. Does not seem
like a sensible thing to do. I will have a look at this when I find
some time.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/4] iio: chemical: scd30: add serial interface driver
From: Tomasz Duszynski @ 2020-06-02 17:57 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Tomasz Duszynski, linux-iio, Linux Kernel Mailing List,
devicetree, Rob Herring, Jonathan Cameron, Peter Meerwald
In-Reply-To: <CAHp75VfjWG_3XC5FJoaU7XXJc+04JTbEKdjZK=g6ffBPvJNhxA@mail.gmail.com>
On Tue, Jun 02, 2020 at 08:04:16PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 2, 2020 at 7:49 PM Tomasz Duszynski
> <tomasz.duszynski@octakon.com> wrote:
> >
> > Add serial interface driver for the SCD30 sensor.
>
> ...
>
> > +static u16 scd30_serdev_cmd_lookup_tbl[] = {
> > + [CMD_START_MEAS] = 0x0036,
> > + [CMD_STOP_MEAS] = 0x0037,
> > + [CMD_MEAS_INTERVAL] = 0x0025,
> > + [CMD_MEAS_READY] = 0x0027,
> > + [CMD_READ_MEAS] = 0x0028,
> > + [CMD_ASC] = 0x003a,
> > + [CMD_FRC] = 0x0039,
> > + [CMD_TEMP_OFFSET] = 0x003b,
> > + [CMD_FW_VERSION] = 0x0020,
> > + [CMD_RESET] = 0x0034,
>
> Hmm... Can't we keep them ordered by value?
>
> > +};
>
> ...
>
> > + ret = wait_for_completion_interruptible_timeout(&priv->meas_ready,
> > + SCD30_SERDEV_TIMEOUT);
> > + if (ret > 0)
> > + ret = 0;
> > + else if (!ret)
> > + ret = -ETIMEDOUT;
> > +
> > + return ret;
>
> Perhaps
>
> if (ret < 0)
> return ret;
> if (ret == 0)
> return -ETIMEDOUT;
> return 0;
>
> ?
Matter of style but since I will be doing other changes I can touch that
too.
>
> ...
>
> > + char txbuf[SCD30_SERDEV_MAX_BUF_SIZE] = { SCD30_SERDEV_ADDR },
> > + rxbuf[SCD30_SERDEV_MAX_BUF_SIZE], *rsp = response;
>
> Please, apply type to each variable separately.
>
Fine.
> ...
>
> > + switch (txbuf[1]) {
> > + case SCD30_SERDEV_WRITE:
>
> > + if (memcmp(txbuf, txbuf, txsize)) {
>
> I'm not sure I understand this.
>
Ah, thanks for catching this. tx should be compared to rx.
> > + dev_err(state->dev, "wrong message received\n");
> > + return -EIO;
> > + }
> > + break;
> > + case SCD30_SERDEV_READ:
>
> > + if (rxbuf[2] != (rxsize -
> > + SCD30_SERDEV_RX_HEADER_SIZE -
> > + SCD30_SERDEV_CRC_SIZE)) {
>
> Perhaps you can come up with better indentation/ line split?
>
I'd rather leave it as is.
> > + dev_err(state->dev,
> > + "received data size does not match header\n");
> > + return -EIO;
> > + }
> > +
> > + rxsize -= SCD30_SERDEV_CRC_SIZE;
> > + crc = get_unaligned_le16(rxbuf + rxsize);
> > + if (crc != scd30_serdev_calc_crc(rxbuf, rxsize)) {
> > + dev_err(state->dev, "data integrity check failed\n");
> > + return -EIO;
> > + }
> > +
> > + rxsize -= SCD30_SERDEV_RX_HEADER_SIZE;
> > + memcpy(rsp, rxbuf + SCD30_SERDEV_RX_HEADER_SIZE, rxsize);
> > + break;
> > + default:
> > + dev_err(state->dev, "received unknown op code\n");
> > + return -EIO;
> > + }
> > +
> > + return 0;
> > +}
>
> ...
>
> > +static struct serdev_device_driver scd30_serdev_driver = {
> > + .driver = {
>
> > + .name = KBUILD_MODNAME,
>
> This is not the best what we can do. The name is an ABI and better if
> it will be constant (independent on file name).
>
> > + .of_match_table = scd30_serdev_of_match,
> > + .pm = &scd30_pm_ops,
> > + },
> > + .probe = scd30_serdev_probe,
> > +};
>
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 2/4] iio: chemical: scd30: add I2C interface driver
From: Tomasz Duszynski @ 2020-06-02 17:48 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Tomasz Duszynski, linux-iio, Linux Kernel Mailing List,
devicetree, Rob Herring, Jonathan Cameron, Peter Meerwald
In-Reply-To: <CAHp75Vc60q1PC9j6KR1-OJHxw=nBAHt9zJK=h9f27yJxMHpb8A@mail.gmail.com>
Hello Andy,
On Tue, Jun 02, 2020 at 08:14:13PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 2, 2020 at 7:49 PM Tomasz Duszynski
> <tomasz.duszynski@octakon.com> wrote:
> >
> > Add I2C interface driver for the SCD30 sensor.
>
> ...
>
> > +static u16 scd30_i2c_cmd_lookup_tbl[] = {
> > + [CMD_START_MEAS] = 0x0010,
> > + [CMD_STOP_MEAS] = 0x0104,
> > + [CMD_MEAS_INTERVAL] = 0x4600,
> > + [CMD_MEAS_READY] = 0x0202,
> > + [CMD_READ_MEAS] = 0x0300,
> > + [CMD_ASC] = 0x5306,
> > + [CMD_FRC] = 0x5204,
> > + [CMD_TEMP_OFFSET] = 0x5403,
> > + [CMD_FW_VERSION] = 0xd100,
> > + [CMD_RESET] = 0xd304,
>
> Keep sorted by value?
>
I'd rather leave it as is simply because order here matches order in
sensor datasheet.
> > +};
>
> ...
>
> > + ret = i2c_master_send(client, txbuf, txsize);
>
> > + if (ret != txsize)
> > + return ret < 0 ? ret : -EIO;
>
> Wouldn't be better
>
> if (ret < 0)
> return ret;
> if (ret != txsize)
> return -EIO;
>
> ?
>
Hmm, okay. Perhaps slightly easier to read.
> > + if (!rxbuf)
> > + return 0;
> > +
> > + ret = i2c_master_recv(client, rxbuf, rxsize);
>
> > + if (ret != rxsize)
> > + return ret < 0 ? ret : -EIO;
>
> Ditto.
>
> ...
>
> > +static int scd30_i2c_command(struct scd30_state *state, enum scd30_cmd cmd,
> > + u16 arg, void *response, int size)
> > +{
> > + char crc, buf[SCD30_I2C_MAX_BUF_SIZE], *rsp = response;
> > + int i, ret;
>
> i -> offset ?
>
'i' is shorter and I am lazy :).
> > + put_unaligned_be16(scd30_i2c_cmd_lookup_tbl[cmd], buf);
> > + i = 2;
> > +
> > + if (rsp) {
> > + /* each two bytes are followed by a crc8 */
> > + size += size / 2;
> > + } else {
> > + put_unaligned_be16(arg, buf + i);
> > + crc = crc8(scd30_i2c_crc8_tbl, buf + i, 2, CRC8_INIT_VALUE);
> > + i += 2;
>
> > + buf[i] = crc;
> > + i += 1;
>
> buf[offset++] = crc; ?
>
I'd rather stick to what I have now. It looks more consistent.
> > + /* commands below don't take an argument */
> > + if ((cmd == CMD_STOP_MEAS) || (cmd == CMD_RESET))
> > + i -= 3;
> > + }
> > +
> > + ret = scd30_i2c_xfer(state, buf, i, buf, size);
> > + if (ret)
> > + return ret;
> > +
> > + /* validate received data and strip off crc bytes */
> > + for (i = 0; i < size; i += 3) {
> > + crc = crc8(scd30_i2c_crc8_tbl, buf + i, 2, CRC8_INIT_VALUE);
> > + if (crc != buf[i + 2]) {
> > + dev_err(state->dev, "data integrity check failed\n");
> > + return -EIO;
> > + }
> > +
>
> > + *rsp++ = buf[i];
>
> + 0 (for the sake of consistency?
>
Adding 0 is a little bit odd.
> > + *rsp++ = buf[i + 1];
> > + }
> > +
> > + return 0;
> > +}
>
> ...
>
> > +static struct i2c_driver scd30_i2c_driver = {
> > + .driver = {
>
> > + .name = KBUILD_MODNAME,
>
> Better to hard code.
>
I seriously doubt anyone will ever want to change module name. What for?
> > + .of_match_table = scd30_i2c_of_match,
> > + .pm = &scd30_pm_ops,
> > + },
> > + .probe_new = scd30_i2c_probe,
> > +};
>
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply
* [PATCH v3 10/10] arm64: dts: actions: Add uSD support for Cubieboard7
From: Amit Singh Tomar @ 2020-06-02 17:33 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: cristian.ciocaltea, linux-kernel, linux-arm-kernel, linux-actions,
devicetree
In-Reply-To: <1591119192-18538-1-git-send-email-amittomer25@gmail.com>
This commit adds uSD support for Cubieboard7 board based on Actions Semi
S700 SoC. SD0 is connected to uSD slot. Since there is no PMIC support
added yet, fixed regulator has been used as a regulator node.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since v2:
* No change.
Changes since v1:
* No change.
Changes since RFC:
* No change.
---
arch/arm64/boot/dts/actions/s700-cubieboard7.dts | 41 ++++++++++++++++++++++++
arch/arm64/boot/dts/actions/s700.dtsi | 1 +
2 files changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
index 63e375cd9eb4..ec117eb12f3a 100644
--- a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
+++ b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
@@ -13,6 +13,7 @@
aliases {
serial3 = &uart3;
+ mmc0 = &mmc0;
};
chosen {
@@ -28,6 +29,23 @@
device_type = "memory";
reg = <0x1 0xe0000000 0x0 0x0>;
};
+
+ /* Fixed regulator used in the absence of PMIC */
+ vcc_3v1: vcc-3v1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.1V";
+ regulator-min-microvolt = <3100000>;
+ regulator-max-microvolt = <3100000>;
+ };
+
+ /* Fixed regulator used in the absence of PMIC */
+ sd_vcc: sd-vcc {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.1V";
+ regulator-min-microvolt = <3100000>;
+ regulator-max-microvolt = <3100000>;
+ regulator-always-on;
+ };
};
&i2c0 {
@@ -81,6 +99,14 @@
bias-pull-up;
};
};
+
+ mmc0_default: mmc0_default {
+ pinmux {
+ groups = "sd0_d0_mfp", "sd0_d1_mfp", "sd0_d2_d3_mfp",
+ "sd0_cmd_mfp", "sd0_clk_mfp";
+ function = "sd0";
+ };
+ };
};
&timer {
@@ -90,3 +116,18 @@
&uart3 {
status = "okay";
};
+
+/* uSD */
+&mmc0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_default>;
+ cd-gpios = <&pinctrl 120 GPIO_ACTIVE_LOW>;
+ no-sdio;
+ no-mmc;
+ no-1-8-v;
+ bus-width = <4>;
+ vmmc-supply = <&sd_vcc>;
+ vqmmc-supply = <&sd_vcc>;
+};
+
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index b1a34f95d44c..2bb29bc683ef 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -4,6 +4,7 @@
*/
#include <dt-bindings/clock/actions,s700-cmu.h>
+#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/actions,s700-reset.h>
#include <dt-bindings/power/owl-s700-powergate.h>
--
2.7.4
^ permalink raw reply related
* [PATCH v3 09/10] arm64: dts: actions: Add MMC controller support for S700
From: Amit Singh Tomar @ 2020-06-02 17:33 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: cristian.ciocaltea, linux-kernel, linux-arm-kernel, linux-actions,
devicetree
In-Reply-To: <1591119192-18538-1-git-send-email-amittomer25@gmail.com>
This commits adds support for MMC controllers present on Actions S700 SoC,
there are 3 MMC controllers in this SoC which can be used for accessing
SD/EMMC/SDIO cards.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since v2:
* No change.
Changes since v1:
* Added SoC specific compatibe string.
Changes since RFC:
* No change
---
arch/arm64/boot/dts/actions/s700.dtsi | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index 605594dd7a0e..b1a34f95d44c 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -259,5 +259,38 @@
clocks = <&cmu CLK_DMAC>;
power-domains = <&sps S700_PD_DMA>;
};
+
+ mmc0: mmc@e0210000 {
+ compatible = "actions,s700-mmc", "actions,owl-mmc";
+ reg = <0x0 0xe0210000 0x0 0x4000>;
+ interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_SD0>;
+ resets = <&cmu RESET_SD0>;
+ dmas = <&dma 2>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
+
+ mmc1: mmc@e0214000 {
+ compatible = "actions,s700-mmc", "actions,owl-mmc";
+ reg = <0x0 0xe0214000 0x0 0x4000>;
+ interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_SD1>;
+ resets = <&cmu RESET_SD1>;
+ dmas = <&dma 3>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
+
+ mmc2: mmc@e0218000 {
+ compatible = "actions,s700-mmc", "actions,owl-mmc";
+ reg = <0x0 0xe0218000 0x0 0x4000>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_SD2>;
+ resets = <&cmu RESET_SD2>;
+ dmas = <&dma 4>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
};
};
--
2.7.4
^ 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