* Re: [PATCH 0/3] ARM: dts: NSP: Add support for Cisco Meraki NSP devices
From: Florian Fainelli @ 2020-06-02 21:55 UTC (permalink / raw)
To: Matthew Hagan
Cc: Rob Herring, Ray Jui, Scott Branden, bcm-kernel-feedback-list,
devicetree, linux-arm-kernel
In-Reply-To: <cover.1591114003.git.mnhagan88@gmail.com>
Hi Matthew,
On 6/2/2020 9:11 AM, Matthew Hagan wrote:
> This patch set adds support for the Meraki MX64(W) and MX65(W) security
> devices. There are four devices in total, all using the same basic hardware.
>
> The MX64 series has five ethernet ports connected to the BCM SRAB. The MX65
> series has two ports conected to the SRAB, and two QCA8337 switches connected
> by SGMII to SRAB ports 4 and 5, each providing five additional ports.
>
> The W variants of these devices have two BCM43520s on the PCIe bus. On the
> non-wireless variants PCIe is inactive, hence separate dts files.
>
> 1/3 contains common bindings for both Meraki devices.
> 2/3 contains MX64 specific bindings.
> 3/3 contains MX65 specific bindings.
Glad to see those patches being submitted upstream to support those
devices, don't we need a change to arch/arm/boot/dts/Makefile to add
those DTS files to be built when ARCH_BCM_NSP is enabled?
>
> Note that Chris Packham's "[PATCH 2/2] ARM: dts: NSP: avoid unnecessary probe
> deferrals" is also necessary.
Humm, I am not sure this patch is really the way to go, but I have to
look at it again.
>
> Thanks,
> Matthew
>
> Matthew Hagan (3):
> ARM: dts: NSP: Add common bindings for Meraki MX64/65
> ARM: dts: NSP: Add support for Cisco Meraki MX64(W)
> ARM: dts: NSP: Add support for Cisco Meraki MX65(W)
>
> arch/arm/boot/dts/bcm958625-mx64.dts | 15 +
> arch/arm/boot/dts/bcm958625-mx64w.dts | 23 ++
> arch/arm/boot/dts/bcm958625-mx64x.dtsi | 136 ++++++++
> arch/arm/boot/dts/bcm958625-mx65.dts | 15 +
> arch/arm/boot/dts/bcm958625-mx65w.dts | 23 ++
> arch/arm/boot/dts/bcm958625-mx65x.dtsi | 321 +++++++++++++++++++
> arch/arm/boot/dts/bcm958625-mx6x-common.dtsi | 172 ++++++++++
> 7 files changed, 705 insertions(+)
> create mode 100644 arch/arm/boot/dts/bcm958625-mx64.dts
> create mode 100644 arch/arm/boot/dts/bcm958625-mx64w.dts
> create mode 100644 arch/arm/boot/dts/bcm958625-mx64x.dtsi
> create mode 100644 arch/arm/boot/dts/bcm958625-mx65.dts
> create mode 100644 arch/arm/boot/dts/bcm958625-mx65w.dts
> create mode 100644 arch/arm/boot/dts/bcm958625-mx65x.dtsi
> create mode 100644 arch/arm/boot/dts/bcm958625-mx6x-common.dtsi
>
--
Florian
^ permalink raw reply
* Re: [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings documention
From: Rob Herring @ 2020-06-02 21:44 UTC (permalink / raw)
To: Pavel Machek
Cc: Dan Murphy, Jacek Anaszewski, devicetree, Linux LED Subsystem,
linux-kernel@vger.kernel.org
In-Reply-To: <20200602200436.GA6535@amd>
On Tue, Jun 2, 2020 at 2:04 PM Pavel Machek <pavel@ucw.cz> wrote:
>
> 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.
There's no risk because you are supposed to apply both patches. I
don't apply binding patches that are a part of a series like this.
Rob
^ permalink raw reply
* Re: [PATCH v2 4/4] remoteproc/k3-dsp: Add support for L2RAM loading on C66x DSPs
From: Mathieu Poirier @ 2020-06-02 21:42 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-5-s-anna@ti.com>
On Wed, May 20, 2020 at 07:10:06PM -0500, Suman Anna wrote:
> The resets for the DSP processors on K3 SoCs are managed through the
> Power and Sleep Controller (PSC) module. Each DSP typically has two
> resets - a global module reset for powering on the device, and a local
> reset that affects only the CPU while allowing access to the other
> sub-modules within the DSP processor sub-systems.
>
> The C66x DSPs have two levels of internal RAMs that can be used to
> boot from, and the firmware loading into these RAMs require the
> local reset to be asserted with the device powered on/enabled using
> the module reset. Enhance the K3 DSP remoteproc driver to add support
> for loading into the internal RAMs. The local reset is deasserted on
> SoC power-on-reset, so logic has to be added in probe in remoteproc
> mode to balance the remoteproc state-machine.
>
> Note that the local resets are a no-op on C71x cores, and the hardware
> does not supporting loading into its internal RAMs.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> v2:
> - Dropped the local-reset no-op checks from k3_dsp_rproc_prepare/unprepare()
> callbacks. The logic will be adjusted back in the C71 patch series.
> - The C71 local reset references are also removed from the comments for the
> k3_dsp_rproc_prepare() function.
> v1: https://patchwork.kernel.org/patch/11458579/
>
> drivers/remoteproc/ti_k3_dsp_remoteproc.c | 72 +++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> index e4036f5992fe..610fbbf85ee6 100644
> --- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> @@ -174,6 +174,9 @@ static int k3_dsp_rproc_reset(struct k3_dsp_rproc *kproc)
> return ret;
> }
>
> + if (kproc->data->uses_lreset)
> + return ret;
> +
> ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
> kproc->ti_sci_id);
> if (ret) {
> @@ -191,6 +194,9 @@ static int k3_dsp_rproc_release(struct k3_dsp_rproc *kproc)
> struct device *dev = kproc->dev;
> int ret;
>
> + if (kproc->data->uses_lreset)
> + goto lreset;
> +
> ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci,
> kproc->ti_sci_id);
> if (ret) {
> @@ -198,6 +204,7 @@ static int k3_dsp_rproc_release(struct k3_dsp_rproc *kproc)
> return ret;
> }
>
> +lreset:
> ret = reset_control_deassert(kproc->reset);
> if (ret) {
> dev_err(dev, "local-reset deassert failed, ret = %d\n", ret);
> @@ -209,6 +216,53 @@ static int k3_dsp_rproc_release(struct k3_dsp_rproc *kproc)
> return ret;
> }
>
> +/*
> + * The C66x DSP cores have a local reset that affects only the CPU, and a
> + * generic module reset that powers on the device and allows the DSP internal
> + * memories to be accessed while the local reset is asserted. This function is
> + * used to release the global reset on C66x DSPs to allow loading into the DSP
> + * internal RAMs. The .prepare() ops is invoked by remoteproc core before any
> + * firmware loading, and is followed by the .start() ops after loading to
> + * actually let the C66x DSP cores run.
> + */
> +static int k3_dsp_rproc_prepare(struct rproc *rproc)
> +{
> + struct k3_dsp_rproc *kproc = rproc->priv;
> + struct device *dev = kproc->dev;
> + int ret;
> +
> + ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci,
> + kproc->ti_sci_id);
> + if (ret)
> + dev_err(dev, "module-reset deassert failed, cannot enable internal RAM loading, ret = %d\n",
> + ret);
> +
> + return ret;
> +}
> +
> +/*
> + * This function implements the .unprepare() ops and performs the complimentary
> + * operations to that of the .prepare() ops. The function is used to assert the
> + * global reset on applicable C66x cores. This completes the second portion of
> + * powering down the C66x DSP cores. The cores themselves are only halted in the
> + * .stop() callback through the local reset, and the .unprepare() ops is invoked
> + * by the remoteproc core after the remoteproc is stopped to balance the global
> + * reset.
> + */
> +static int k3_dsp_rproc_unprepare(struct rproc *rproc)
> +{
> + struct k3_dsp_rproc *kproc = rproc->priv;
> + struct device *dev = kproc->dev;
> + int ret;
> +
> + ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
> + kproc->ti_sci_id);
> + if (ret)
> + dev_err(dev, "module-reset assert failed, ret = %d\n", ret);
> +
> + return ret;
> +}
> +
> /*
> * Power up the DSP remote processor.
> *
> @@ -352,6 +406,8 @@ static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> }
>
> static const struct rproc_ops k3_dsp_rproc_ops = {
> + .prepare = k3_dsp_rproc_prepare,
> + .unprepare = k3_dsp_rproc_unprepare,
> .start = k3_dsp_rproc_start,
> .stop = k3_dsp_rproc_stop,
> .kick = k3_dsp_rproc_kick,
> @@ -614,6 +670,22 @@ static int k3_dsp_rproc_probe(struct platform_device *pdev)
> goto release_tsp;
> }
>
> + /*
> + * ensure the DSP local reset is asserted to ensure the DSP doesn't
> + * execute bogus code in .prepare() when the module reset is released.
> + */
> + if (data->uses_lreset) {
> + ret = reset_control_status(kproc->reset);
> + if (ret < 0) {
> + dev_err(dev, "failed to get reset status, status = %d\n",
> + ret);
> + goto release_mem;
> + } else if (ret == 0) {
> + dev_warn(dev, "local reset is deasserted for device\n");
> + k3_dsp_rproc_reset(kproc);
> + }
> + }
> +
> ret = rproc_add(rproc);
> if (ret) {
> dev_err(dev, "failed to add register device with remoteproc core, status = %d\n",
> --
> 2.26.0
>
^ permalink raw reply
* Re: [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips
From: Rob Herring @ 2020-06-02 21:41 UTC (permalink / raw)
To: Jim Quinlan
Cc: open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, Nicolas Saenz Julienne,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Florian Fainelli,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <CA+-6iNwWBFYHVKiwwJ95DYQ5zmc5uBo1cgZzd6rpD++aQWgGpw@mail.gmail.com>
On Tue, Jun 2, 2020 at 2:53 PM Jim Quinlan <james.quinlan@broadcom.com> wrote:
>
> On Fri, May 29, 2020 at 1:46 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Tue, May 26, 2020 at 03:12:42PM -0400, Jim Quinlan wrote:
> > > From: Jim Quinlan <jquinlan@broadcom.com>
> > >
> > > - Add compatible strings for three more Broadcom STB chips: 7278, 7216,
> > > 7211 (STB version of RPi4).
> > > - add new property 'brcm,scb-sizes'
> > > - add new property 'resets'
> > > - add new property 'reset-names'
> > > - allow 'ranges' and 'dma-ranges' to have more than one item and update
> > > the example to show this.
> > >
> > > Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> > > ---
> > > .../bindings/pci/brcm,stb-pcie.yaml | 40 +++++++++++++++++--
> > > 1 file changed, 36 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > index 8680a0f86c5a..66a7df45983d 100644
> > > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > @@ -14,7 +14,13 @@ allOf:
> > >
> > > properties:
> > > compatible:
> > > - const: brcm,bcm2711-pcie # The Raspberry Pi 4
> > > + items:
> > > + - enum:
> >
> > Don't need items here. Just change the const to enum.
> >
> > > + - brcm,bcm2711-pcie # The Raspberry Pi 4
> > > + - brcm,bcm7211-pcie # Broadcom STB version of RPi4
> > > + - brcm,bcm7278-pcie # Broadcom 7278 Arm
> > > + - brcm,bcm7216-pcie # Broadcom 7216 Arm
> > > + - brcm,bcm7445-pcie # Broadcom 7445 Arm
> > >
> > > reg:
> > > maxItems: 1
> > > @@ -34,10 +40,12 @@ properties:
> > > - const: msi
> > >
> > > ranges:
> > > - maxItems: 1
> > > + minItems: 1
> > > + maxItems: 4
> > >
> > > dma-ranges:
> > > - maxItems: 1
> > > + minItems: 1
> > > + maxItems: 6
> > >
> > > clocks:
> > > maxItems: 1
> > > @@ -58,8 +66,30 @@ properties:
> > >
> > > aspm-no-l0s: true
> > >
> > > + resets:
> > > + description: for "brcm,bcm7216-pcie", must be a valid reset
> > > + phandle pointing to the RESCAL reset controller provider node.
> > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > +
> > > + reset-names:
> > > + items:
> > > + - const: rescal
> >
> > These are going to need to be an if/then schema if they only apply to
> > certain compatible(s).
>
> Why is that -- the code is general enough to handle its presence or
> not (it is an optional compatibility)>
Because an if/then schema expresses in a parse-able form what your
'description' does in free form text.
Presumably a 'resets' property for !brcm,bcm7216-pcie is invalid, so
we should check that. The schema shouldn't be just what some driver
happens to currently allow. Also, it's not a driver's job to validate
DT, so it shouldn't check any of this.
> > > + brcm,scb-sizes:
> > > + description: (u32, u32) tuple giving the 64bit PCIe memory
> > > + viewport size of a memory controller. There may be up to
> > > + three controllers, and each size must be a power of two
> > > + with a size greater or equal to the amount of memory the
> > > + controller supports.
> >
> > This sounds like what dma-ranges should express?
>
> There is some overlap but this contains information that is not in the
> dma-ranges. Believe me I tried.
I don't understand. If you had 3 dma-ranges entries, you'd have 3
sizes. Can you expand or show me what you tried?
> > If not, we do have 64-bit size if that what you need.
>
> IIRC I tried the 64-bit size but the YAML validator did not like it;
> it wanted numbers like <0x1122334455667788> while dtc wanted <
> 0x11223344 0x55667788>. I gave up trying and switched to u32.
You used the /bits/ annotation for dtc?:
/bits/ 64 <0x1122334455667788>
I also made a recent fix to dt-schema around handling of 64-bit sizes,
so update if you have problems still.
Rob
^ permalink raw reply
* Re: [PATCH 05/10] spi: spi-dw-mmio: Spin off MSCC platforms into spi-dw-mchp
From: Serge Semin @ 2020-06-02 21:12 UTC (permalink / raw)
To: Lars Povlsen
Cc: Serge Semin, Mark Brown, devicetree, Alexandre Belloni,
linux-kernel, linux-spi, SoC Team, Microchip Linux Driver Support,
linux-arm-kernel
In-Reply-To: <20200519120519.GE24801@soft-dev15.microsemi.net>
On Tue, May 19, 2020 at 02:05:19PM +0200, Lars Povlsen wrote:
> On 13/05/20 16:18, Mark Brown wrote:
> > Date: Wed, 13 May 2020 16:18:11 +0100
> > From: Mark Brown <broonie@kernel.org>
> > To: Lars Povlsen <lars.povlsen@microchip.com>
> > Cc: SoC Team <soc@kernel.org>, Microchip Linux Driver Support
> > <UNGLinuxDriver@microchip.com>, linux-spi@vger.kernel.org,
> > devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
> > linux-arm-kernel@lists.infradead.org, Alexandre Belloni
> > <alexandre.belloni@bootlin.com>
> > Subject: Re: [PATCH 05/10] spi: spi-dw-mmio: Spin off MSCC platforms into
> > spi-dw-mchp
> > User-Agent: Mutt/1.10.1 (2018-07-13)
> >
> > On Wed, May 13, 2020 at 04:00:26PM +0200, Lars Povlsen wrote:
> >
> > > +config SPI_DW_MCHP
> > > + tristate "Memory-mapped io interface driver using DW SPI core of MSCC SoCs"
> > > + default y if ARCH_SPARX5
> > > + default y if SOC_VCOREIII
> >
> > Why the default ys?
>
> The SoC will typically boot from SPI... But its not a requirement per
> se. I will remove it.
>
> >
> > > +++ b/drivers/spi/Makefile
> > > @@ -37,6 +37,7 @@ obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o
> > > obj-$(CONFIG_SPI_DLN2) += spi-dln2.o
> > > obj-$(CONFIG_SPI_DESIGNWARE) += spi-dw.o
> > > obj-$(CONFIG_SPI_DW_MMIO) += spi-dw-mmio.o
> > > +obj-$(CONFIG_SPI_DW_MCHP) += spi-dw-mchp.o
> > > obj-$(CONFIG_SPI_DW_PCI) += spi-dw-midpci.o
> > > spi-dw-midpci-objs := spi-dw-pci.o spi-dw-mid.o
> > > obj-$(CONFIG_SPI_EFM32) += spi-efm32.o
> >
> > Please keep the file alphabetically sorted.
> >
>
> Noted.
>
> > > +++ b/drivers/spi/spi-dw-mchp.c
> > > @@ -0,0 +1,232 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Memory-mapped interface driver for MSCC SoCs
> > > + *
> >
> > Please make the entire comment a C++ one so things look more
> > intentional.
>
> Sure, I can do that. The presented form matches that of the other
> spi-dw-* drivers, but I can see other using // blocks. Ack.
>
> >
> > > +#define MAX_CS 4
> >
> > This should be namespaced.
>
> Ack.
>
> >
> > > + rx_sample_dly = 0;
> > > + device_property_read_u32(&pdev->dev, "spi-rx-delay-us", &rx_sample_dly);
> > > + dws->rx_sample_dly = DIV_ROUND_UP(rx_sample_dly,
> > > + (dws->max_freq / 1000000));
Perhaps 100000 is better to be replace with macro USEC_PER_SEC...
Moreover are you sure the formulae is correct?
dws->rx_sample_dly - a number of ssi_clk periods/cycles to delay the Rx-data sample,
dws->max_freq - ssi_clk frequency (not period).
In real math the formulae would look like:
S = d * P [s], where d - number of delay cycles, P - ssi_clk period in seconds,
S - requested delay in seconds.
In the driver notation: d = dws->rx_sample_dly, P = 1 / dws->max_freq,
S = rx_sample_dly ("spi-rx-delay-us" property value).
dws->rx_sample_dly * (1 / dws->max_freq) = rx_sample_dly <=>
dws->rx_sample_dly = rx_sample_dly * dws->max_freq.
Though that's represented in seconds, so if rx_sample_dly is specified in usec,
then you'd need to scale it down dividing by USEC_PER_SEC.
For example, imagine we need a delay of 1 usec with ssi_clk of 50MHz.
By your formulae we'd have: 1 / (50000000 / 1000000) = 0 cycles (actually 1 due
to DIV_ROUND_UP, but incorrect anyway),
By mine: 1 * (500000000 / 1000000) = 50 cycles. Seems closer to reality.
Am I missing something?
> >
> > If this is a standard feature of the DesignWare IP why parse it here and
> > not in the generic code?
>
> This is a standard feature of the DesignWare IP, so good suggestion. I
> will arrange with Serge.
Regarding "spi-rx-delay-us" and the sampling delay the IP supports. Here is what
documentation says regarding the register, which is then initialized with this
parameter "This register controls the number of ssi_clk cycles that are
delayed from the default sample time before the actual sample of the rxd input
signal occurs." While the "spi-rx-delay-us" property is described as: "Delay, in
microseconds, after a read transfer." I may misunderstand something, but IMO
these descriptions don't refer to the same values. The only real use of the
"spi-rx-delay-us" property I've found in "./drivers/input/rmi4/rmi_spi.c".
That driver gets the value of the property and just sets the delay_usecs
of some transfers, which isn't even close to the functionality the RX_SAMPLE_DLY
register provides.
To be clear the RX_SAMPLE_DLY register can be used to delay the RX-bits sample
with respect to the normal Rx sampling timing. The delay is measured in the
numbers of the ssi_clk periods. (Note also that the maximum delay is limited
with a constant parameter pre-initialized at the IP-core synthesis stage. It can
be defined within a range [4, 255]. In our IP it's limited with just 4 periods.)
As I see it, a better way would be to either define a new vendor-specific
property like "snps,rx-sample-delay-ns" (note NS here, since normally the
ssi_clk is much higher than 1MHz), or define a new generic SPI property.
Mark, Andy?
-Sergey
>
> Thank you for your comments!
>
> ---Lars
>
>
> _______________________________________________
> 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 2/2] drm/panel: simple: Add support for KOE TX26D202VM0BWA panel
From: Sam Ravnborg @ 2020-06-02 20:56 UTC (permalink / raw)
To: Emil Velikov
Cc: Liu Ying, ML dri-devel, devicetree, Thierry Reding,
NXP Linux Team
In-Reply-To: <CACvgo50UOby-xV_OYmM55VUXUbwLxK-q6bs2FoS_FuwB9ChYJg@mail.gmail.com>
Hi Emil.
On Tue, Jun 02, 2020 at 01:46:19PM +0100, Emil Velikov wrote:
> On Tue, 2 Jun 2020 at 08:17, Liu Ying <victor.liu@nxp.com> wrote:
> >
> > This patch adds support for Kaohsiung Opto-Electronics Inc.
> > 10.1" TX26D202VM0BWA WUXGA(1920x1200) TFT LCD panel with LVDS interface.
> > The panel has dual LVDS channels.
> >
> > My panel is manufactured by US Micro Products(USMP). There is a tag at
> > the back of the panel, which indicates the panel type is 'TX26D202VM0BWA'
> > and it's made by KOE in Taiwan.
> >
> > The panel spec from USMP can be found at:
> > https://www.usmicroproducts.com/sites/default/files/datasheets/USMP-T101-192120NDU-A0.pdf
> >
> > The below panel spec from KOE is basically the same to the one from USMP.
> > However, the panel type 'TX26D202VM0BAA' is a little bit different.
> > It looks that the two types of panel are compatible with each other.
> > http://www.koe.j-display.com/upload/product/TX26D202VM0BAA.pdf
> >
> > Cc: Thierry Reding <thierry.reding@gmail.com>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Signed-off-by: Liu Ying <victor.liu@nxp.com>
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 34 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > index b6ecd15..7c222ec 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -2200,6 +2200,37 @@ static const struct panel_desc koe_tx14d24vm1bpa = {
> > },
> > };
> >
> > +static const struct display_timing koe_tx26d202vm0bwa_timing = {
> > + .pixelclock = { 151820000, 156720000, 159780000 },
> > + .hactive = { 1920, 1920, 1920 },
> > + .hfront_porch = { 105, 130, 142 },
> > + .hback_porch = { 45, 70, 82 },
> > + .hsync_len = { 30, 30, 30 },
> > + .vactive = { 1200, 1200, 1200},
> > + .vfront_porch = { 3, 5, 10 },
> > + .vback_porch = { 2, 5, 10 },
> > + .vsync_len = { 5, 5, 5 },
> > +};
> > +
> > +static const struct panel_desc koe_tx26d202vm0bwa = {
> > + .timings = &koe_tx26d202vm0bwa_timing,
> > + .num_timings = 1,
> > + .bpc = 8,
> > + .size = {
> > + .width = 217,
> > + .height = 136,
> > + },
> > + .delay = {
> > + .prepare = 1000,
> > + .enable = 1000,
> > + .unprepare = 1000,
> > + .disable = 1000,
> Ouch 1s for each delay is huge. Nevertheless it matches the specs so,
> the series is:
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>
> Sam, Thierry I assume you'll merge the series. Let me know if I should
> pick it up.
I am quite busy with non-linux stuff these days so fine if you can pick
them up. I like that simple panel patches are processed fast.
I expect to have some hours for linux work friday or saturday, but no
promises...
Sam
>
> -Emil
^ permalink raw reply
* Re: [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips
From: Jim Quinlan @ 2020-06-02 20:53 UTC (permalink / raw)
To: Rob Herring
Cc: open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, Nicolas Saenz Julienne,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Florian Fainelli,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20200529174634.GA2630216@bogus>
On Fri, May 29, 2020 at 1:46 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, May 26, 2020 at 03:12:42PM -0400, Jim Quinlan wrote:
> > From: Jim Quinlan <jquinlan@broadcom.com>
> >
> > - Add compatible strings for three more Broadcom STB chips: 7278, 7216,
> > 7211 (STB version of RPi4).
> > - add new property 'brcm,scb-sizes'
> > - add new property 'resets'
> > - add new property 'reset-names'
> > - allow 'ranges' and 'dma-ranges' to have more than one item and update
> > the example to show this.
> >
> > Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> > ---
> > .../bindings/pci/brcm,stb-pcie.yaml | 40 +++++++++++++++++--
> > 1 file changed, 36 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > index 8680a0f86c5a..66a7df45983d 100644
> > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > @@ -14,7 +14,13 @@ allOf:
> >
> > properties:
> > compatible:
> > - const: brcm,bcm2711-pcie # The Raspberry Pi 4
> > + items:
> > + - enum:
>
> Don't need items here. Just change the const to enum.
>
> > + - brcm,bcm2711-pcie # The Raspberry Pi 4
> > + - brcm,bcm7211-pcie # Broadcom STB version of RPi4
> > + - brcm,bcm7278-pcie # Broadcom 7278 Arm
> > + - brcm,bcm7216-pcie # Broadcom 7216 Arm
> > + - brcm,bcm7445-pcie # Broadcom 7445 Arm
> >
> > reg:
> > maxItems: 1
> > @@ -34,10 +40,12 @@ properties:
> > - const: msi
> >
> > ranges:
> > - maxItems: 1
> > + minItems: 1
> > + maxItems: 4
> >
> > dma-ranges:
> > - maxItems: 1
> > + minItems: 1
> > + maxItems: 6
> >
> > clocks:
> > maxItems: 1
> > @@ -58,8 +66,30 @@ properties:
> >
> > aspm-no-l0s: true
> >
> > + resets:
> > + description: for "brcm,bcm7216-pcie", must be a valid reset
> > + phandle pointing to the RESCAL reset controller provider node.
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + reset-names:
> > + items:
> > + - const: rescal
>
> These are going to need to be an if/then schema if they only apply to
> certain compatible(s).
Why is that -- the code is general enough to handle its presence or
not (it is an optional compatibility)>
>
>
> > +
> > + brcm,scb-sizes:
> > + description: (u32, u32) tuple giving the 64bit PCIe memory
> > + viewport size of a memory controller. There may be up to
> > + three controllers, and each size must be a power of two
> > + with a size greater or equal to the amount of memory the
> > + controller supports.
>
> This sounds like what dma-ranges should express?
There is some overlap but this contains information that is not in the
dma-ranges. Believe me I tried.
>
> If not, we do have 64-bit size if that what you need.
IIRC I tried the 64-bit size but the YAML validator did not like it;
it wanted numbers like <0x1122334455667788> while dtc wanted <
0x11223344 0x55667788>. I gave up trying and switched to u32.
Thanks,
Jim
>
>
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32-array
> > + - items:
> > + minItems: 2
> > + maxItems: 6
> > +
> > required:
> > - reg
> > + - ranges
> > - dma-ranges
> > - "#interrupt-cells"
> > - interrupts
> > @@ -93,7 +123,9 @@ examples:
> > msi-parent = <&pcie0>;
> > msi-controller;
> > ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>;
> > - dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>;
> > + dma-ranges = <0x42000000 0x1 0x00000000 0x0 0x40000000 0x0 0x80000000>,
> > + <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>;
> > brcm,enable-ssc;
> > + brcm,scb-sizes = <0x0 0x80000000 0x0 0x80000000>;
> > };
> > };
> > --
> > 2.17.1
> >
^ permalink raw reply
* Re: [PATCH v2 3/4] remoteproc/k3-dsp: Add a remoteproc driver of K3 C66x DSPs
From: Mathieu Poirier @ 2020-06-02 20:53 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-4-s-anna@ti.com>
On Wed, May 20, 2020 at 07:10:05PM -0500, Suman Anna wrote:
> The Texas Instrument's K3 J721E SoCs have two C66x DSP Subsystems in MAIN
> voltage domain that are based on the TI's standard TMS320C66x DSP CorePac
> module. Each subsystem has a Fixed/Floating-Point DSP CPU, with 32 KB each
> of L1P & L1D SRAMs that can be configured and partitioned as either RAM
> and/or Cache, and 288 KB of L2 SRAM with 256 KB of memory configurable as
> either RAM and/or Cache. The CorePac also includes an Internal DMA (IDMA),
> External Memory Controller (EMC), Extended Memory Controller (XMC) with a
> Region Address Translator (RAT) unit for 32-bit to 48-bit address
> extension/translations, an Interrupt Controller (INTC) and a Powerdown
> Controller (PDC).
>
> A new remoteproc module is added to perform the device management of
> these DSP devices. The support is limited to images using only external
> DDR memory at the moment, the loading support to internal memories and
> any on-chip RAM memories will be added in a subsequent patch. RAT support
> is also left for a future patch, and as such the reserved memory carveout
> regions are all expected to be using memory regions within the first 2 GB.
> Error Recovery and Power Management features are not currently supported.
>
> The C66x remote processors do not have an MMU, and so require fixed memory
> carveout regions matching the firmware image addresses. Support for this
> is provided by mandating multiple memory regions to be attached to the
> remoteproc device. The first memory region will be used to serve as the
> DMA pool for all dynamic allocations like the vrings and vring buffers.
> The remaining memory regions are mapped into the kernel at device probe
> time, and are used to provide address translations for firmware image
> segments without the need for any RSC_CARVEOUT entries. Any firmware
> image using memory outside of the supplied reserved memory carveout
> regions will be errored out.
>
> The driver uses various TI-SCI interfaces to talk to the System Controller
> (DMSC) for managing configuration, power and reset management of these
> cores. IPC between the A72 cores and the DSP cores is supported through
> the virtio rpmsg stack using shared memory and OMAP Mailboxes.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> v2:
> - Dropped the pm_runtime usage
> - Replaced the private k3_dsp_rproc_get_firmware() with the newly introduced
> rproc_of_parse_firmware()
> - Addressed other minor comments from Mathieu - Revised help on Kconfig, reordered
> header files, whitespace indentation fixes, remove the stale memset comment on
> internal memories, renamed struct k3_dsp_rproc_mem to struct k3_dsp_mem.
> v1: https://patchwork.kernel.org/patch/11458577/
>
> drivers/remoteproc/Kconfig | 13 +
> drivers/remoteproc/Makefile | 1 +
> drivers/remoteproc/ti_k3_dsp_remoteproc.c | 701 ++++++++++++++++++++++
> 3 files changed, 715 insertions(+)
> create mode 100644 drivers/remoteproc/ti_k3_dsp_remoteproc.c
>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 2c9fb870a276..ef787774b52b 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -265,6 +265,19 @@ config TI_K3_R5_REMOTEPROC
> It's safe to say N here if you're not interested in utilizing
> a slave processor
>
> +config TI_K3_DSP_REMOTEPROC
> + tristate "TI K3 DSP remoteproc support"
> + depends on ARCH_K3
> + select MAILBOX
> + select OMAP2PLUS_MBOX
> + help
> + Say m here to support TI's C66x and C71x DSP remote processor
> + subsystems on various TI K3 family of SoCs through the remote
> + processor framework.
> +
> + It's safe to say N here if you're not interested in utilizing
> + the DSP slave processors.
> +
> endif # REMOTEPROC
>
> endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index ea0c6812e4fc..9f87d222744c 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -31,3 +31,4 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
> obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
> obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
> obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
> +obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> new file mode 100644
> index 000000000000..e4036f5992fe
> --- /dev/null
> +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> @@ -0,0 +1,701 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * TI K3 DSP Remote Processor(s) driver
> + *
> + * Copyright (C) 2018-2020 Texas Instruments Incorporated - http://www.ti.com/
> + * Suman Anna <s-anna@ti.com>
> + */
> +
> +#include <linux/io.h>
> +#include <linux/mailbox_client.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/omap-mailbox.h>
> +#include <linux/platform_device.h>
> +#include <linux/remoteproc.h>
> +#include <linux/reset.h>
> +#include <linux/soc/ti/ti_sci_protocol.h>
> +
> +#include "omap_remoteproc.h"
> +#include "remoteproc_internal.h"
> +#include "ti_sci_proc.h"
> +
> +#define KEYSTONE_RPROC_LOCAL_ADDRESS_MASK (SZ_16M - 1)
> +
> +/**
> + * struct k3_dsp_mem - internal memory structure
> + * @cpu_addr: MPU virtual address of the memory region
> + * @bus_addr: Bus address used to access the memory region
> + * @dev_addr: Device address of the memory region from DSP view
> + * @size: Size of the memory region
> + */
> +struct k3_dsp_mem {
> + void __iomem *cpu_addr;
> + phys_addr_t bus_addr;
> + u32 dev_addr;
> + size_t size;
> +};
> +
> +/**
> + * struct k3_dsp_mem_data - memory definitions for a DSP
> + * @name: name for this memory entry
> + * @dev_addr: device address for the memory entry
> + */
> +struct k3_dsp_mem_data {
> + const char *name;
> + const u32 dev_addr;
> +};
> +
> +/**
> + * struct k3_dsp_dev_data - device data structure for a DSP
> + * @mems: pointer to memory definitions for a DSP
> + * @num_mems: number of memory regions in @mems
> + * @boot_align_addr: boot vector address alignment granularity
> + * @uses_lreset: flag to denote the need for local reset management
> + */
> +struct k3_dsp_dev_data {
> + const struct k3_dsp_mem_data *mems;
> + u32 num_mems;
> + u32 boot_align_addr;
> + bool uses_lreset;
> +};
> +
> +/**
> + * struct k3_dsp_rproc - k3 DSP remote processor driver structure
> + * @dev: cached device pointer
> + * @rproc: remoteproc device handle
> + * @mem: internal memory regions data
> + * @num_mems: number of internal memory regions
> + * @rmem: reserved memory regions data
> + * @num_rmems: number of reserved memory regions
> + * @reset: reset control handle
> + * @data: pointer to DSP-specific device data
> + * @tsp: TI-SCI processor control handle
> + * @ti_sci: TI-SCI handle
> + * @ti_sci_id: TI-SCI device identifier
> + * @mbox: mailbox channel handle
> + * @client: mailbox client to request the mailbox channel
> + */
> +struct k3_dsp_rproc {
> + struct device *dev;
> + struct rproc *rproc;
> + struct k3_dsp_mem *mem;
> + int num_mems;
> + struct k3_dsp_mem *rmem;
> + int num_rmems;
> + struct reset_control *reset;
> + const struct k3_dsp_dev_data *data;
> + struct ti_sci_proc *tsp;
> + const struct ti_sci_handle *ti_sci;
> + u32 ti_sci_id;
> + struct mbox_chan *mbox;
> + struct mbox_client client;
> +};
> +
> +/**
> + * k3_dsp_rproc_mbox_callback() - inbound mailbox message handler
> + * @client: mailbox client pointer used for requesting the mailbox channel
> + * @data: mailbox payload
> + *
> + * This handler is invoked by the OMAP mailbox driver whenever a mailbox
> + * message is received. Usually, the mailbox payload simply contains
> + * the index of the virtqueue that is kicked by the remote processor,
> + * and we let remoteproc core handle it.
> + *
> + * In addition to virtqueue indices, we also have some out-of-band values
> + * that indicate different events. Those values are deliberately very
> + * large so they don't coincide with virtqueue indices.
> + */
> +static void k3_dsp_rproc_mbox_callback(struct mbox_client *client, void *data)
> +{
> + struct k3_dsp_rproc *kproc = container_of(client, struct k3_dsp_rproc,
> + client);
> + struct device *dev = kproc->rproc->dev.parent;
> + const char *name = kproc->rproc->name;
> + u32 msg = omap_mbox_message(data);
> +
> + dev_dbg(dev, "mbox msg: 0x%x\n", msg);
> +
> + switch (msg) {
> + case RP_MBOX_CRASH:
> + /*
> + * remoteproc detected an exception, but error recovery is not
> + * supported. So, just log this for now
> + */
> + dev_err(dev, "K3 DSP rproc %s crashed\n", name);
> + break;
> + case RP_MBOX_ECHO_REPLY:
> + dev_info(dev, "received echo reply from %s\n", name);
> + break;
> + default:
> + /* silently handle all other valid messages */
> + if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
> + return;
> + if (msg > kproc->rproc->max_notifyid) {
> + dev_dbg(dev, "dropping unknown message 0x%x", msg);
> + return;
> + }
> + /* msg contains the index of the triggered vring */
> + if (rproc_vq_interrupt(kproc->rproc, msg) == IRQ_NONE)
> + dev_dbg(dev, "no message was found in vqid %d\n", msg);
> + }
> +}
> +
> +/*
> + * Kick the remote processor to notify about pending unprocessed messages.
> + * The vqid usage is not used and is inconsequential, as the kick is performed
> + * through a simulated GPIO (a bit in an IPC interrupt-triggering register),
> + * the remote processor is expected to process both its Tx and Rx virtqueues.
> + */
> +static void k3_dsp_rproc_kick(struct rproc *rproc, int vqid)
> +{
> + struct k3_dsp_rproc *kproc = rproc->priv;
> + struct device *dev = rproc->dev.parent;
> + mbox_msg_t msg = (mbox_msg_t)vqid;
> + int ret;
> +
> + /* send the index of the triggered virtqueue in the mailbox payload */
> + ret = mbox_send_message(kproc->mbox, (void *)msg);
> + if (ret < 0)
> + dev_err(dev, "failed to send mailbox message, status = %d\n",
> + ret);
> +}
> +
> +/* Put the DSP processor into reset */
> +static int k3_dsp_rproc_reset(struct k3_dsp_rproc *kproc)
> +{
> + struct device *dev = kproc->dev;
> + int ret;
> +
> + ret = reset_control_assert(kproc->reset);
> + if (ret) {
> + dev_err(dev, "local-reset assert failed, ret = %d\n", ret);
> + return ret;
> + }
> +
> + ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
> + kproc->ti_sci_id);
> + if (ret) {
> + dev_err(dev, "module-reset assert failed, ret = %d\n", ret);
> + if (reset_control_deassert(kproc->reset))
> + dev_warn(dev, "local-reset deassert back failed\n");
> + }
> +
> + return ret;
> +}
> +
> +/* Release the DSP processor from reset */
> +static int k3_dsp_rproc_release(struct k3_dsp_rproc *kproc)
> +{
> + struct device *dev = kproc->dev;
> + int ret;
> +
> + ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci,
> + kproc->ti_sci_id);
> + if (ret) {
> + dev_err(dev, "module-reset deassert failed, ret = %d\n", ret);
> + return ret;
> + }
> +
> + ret = reset_control_deassert(kproc->reset);
> + if (ret) {
> + dev_err(dev, "local-reset deassert failed, ret = %d\n", ret);
> + if (kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
> + kproc->ti_sci_id))
> + dev_warn(dev, "module-reset assert back failed\n");
> + }
> +
> + return ret;
> +}
> +
> +/*
> + * Power up the DSP remote processor.
> + *
> + * This function will be invoked only after the firmware for this rproc
> + * was loaded, parsed successfully, and all of its resource requirements
> + * were met.
> + */
> +static int k3_dsp_rproc_start(struct rproc *rproc)
> +{
> + struct k3_dsp_rproc *kproc = rproc->priv;
> + struct mbox_client *client = &kproc->client;
> + struct device *dev = kproc->dev;
> + u32 boot_addr;
> + int ret;
> +
> + client->dev = dev;
> + client->tx_done = NULL;
> + client->rx_callback = k3_dsp_rproc_mbox_callback;
> + client->tx_block = false;
> + client->knows_txdone = false;
> +
> + kproc->mbox = mbox_request_channel(client, 0);
> + if (IS_ERR(kproc->mbox)) {
> + ret = -EBUSY;
> + dev_err(dev, "mbox_request_channel failed: %ld\n",
> + PTR_ERR(kproc->mbox));
> + return ret;
> + }
> +
> + /*
> + * Ping the remote processor, this is only for sanity-sake for now;
> + * there is no functional effect whatsoever.
> + *
> + * Note that the reply will _not_ arrive immediately: this message
> + * will wait in the mailbox fifo until the remote processor is booted.
> + */
> + ret = mbox_send_message(kproc->mbox, (void *)RP_MBOX_ECHO_REQUEST);
> + if (ret < 0) {
> + dev_err(dev, "mbox_send_message failed: %d\n", ret);
> + goto put_mbox;
> + }
> +
> + boot_addr = rproc->bootaddr;
> + if (boot_addr & (kproc->data->boot_align_addr - 1)) {
> + dev_err(dev, "invalid boot address 0x%x, must be aligned on a 0x%x boundary\n",
> + boot_addr, kproc->data->boot_align_addr);
> + ret = -EINVAL;
> + goto put_mbox;
> + }
> +
> + dev_err(dev, "booting DSP core using boot addr = 0x%x\n", boot_addr);
> + ret = ti_sci_proc_set_config(kproc->tsp, boot_addr, 0, 0);
> + if (ret)
> + goto put_mbox;
> +
> + ret = k3_dsp_rproc_release(kproc);
> + if (ret)
> + goto put_mbox;
> +
> + return 0;
> +
> +put_mbox:
> + mbox_free_channel(kproc->mbox);
> + return ret;
> +}
> +
> +/*
> + * Stop the DSP remote processor.
> + *
> + * This function puts the DSP processor into reset, and finishes processing
> + * of any pending messages.
> + */
> +static int k3_dsp_rproc_stop(struct rproc *rproc)
> +{
> + struct k3_dsp_rproc *kproc = rproc->priv;
> +
> + mbox_free_channel(kproc->mbox);
> +
> + k3_dsp_rproc_reset(kproc);
> +
> + return 0;
> +}
> +
> +/*
> + * Custom function to translate a DSP device address (internal RAMs only) to a
> + * kernel virtual address. The DSPs can access their RAMs at either an internal
> + * address visible only from a DSP, or at the SoC-level bus address. Both these
> + * addresses need to be looked through for translation. The translated addresses
> + * can be used either by the remoteproc core for loading (when using kernel
> + * remoteproc loader), or by any rpmsg bus drivers.
> + */
> +static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +{
> + struct k3_dsp_rproc *kproc = rproc->priv;
> + void __iomem *va = NULL;
> + phys_addr_t bus_addr;
> + u32 dev_addr, offset;
> + size_t size;
> + int i;
> +
> + if (len == 0)
> + return NULL;
> +
> + for (i = 0; i < kproc->num_mems; i++) {
> + bus_addr = kproc->mem[i].bus_addr;
> + dev_addr = kproc->mem[i].dev_addr;
> + size = kproc->mem[i].size;
> +
> + if (da < KEYSTONE_RPROC_LOCAL_ADDRESS_MASK) {
> + /* handle DSP-view addresses */
> + if (da >= dev_addr &&
> + ((da + len) <= (dev_addr + size))) {
> + offset = da - dev_addr;
> + va = kproc->mem[i].cpu_addr + offset;
> + return (__force void *)va;
> + }
> + } else {
> + /* handle SoC-view addresses */
> + if (da >= bus_addr &&
> + (da + len) <= (bus_addr + size)) {
> + offset = da - bus_addr;
> + va = kproc->mem[i].cpu_addr + offset;
> + return (__force void *)va;
> + }
> + }
> + }
> +
> + /* handle static DDR reserved memory regions */
> + for (i = 0; i < kproc->num_rmems; i++) {
> + dev_addr = kproc->rmem[i].dev_addr;
> + size = kproc->rmem[i].size;
> +
> + if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
> + offset = da - dev_addr;
> + va = kproc->rmem[i].cpu_addr + offset;
> + return (__force void *)va;
> + }
> + }
> +
> + return NULL;
> +}
> +
> +static const struct rproc_ops k3_dsp_rproc_ops = {
> + .start = k3_dsp_rproc_start,
> + .stop = k3_dsp_rproc_stop,
> + .kick = k3_dsp_rproc_kick,
> + .da_to_va = k3_dsp_rproc_da_to_va,
> +};
> +
> +static int k3_dsp_rproc_of_get_memories(struct platform_device *pdev,
> + struct k3_dsp_rproc *kproc)
> +{
> + const struct k3_dsp_dev_data *data = kproc->data;
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + int num_mems = 0;
> + int i;
> +
> + num_mems = kproc->data->num_mems;
> + kproc->mem = devm_kcalloc(kproc->dev, num_mems,
> + sizeof(*kproc->mem), GFP_KERNEL);
> + if (!kproc->mem)
> + return -ENOMEM;
> +
> + for (i = 0; i < num_mems; i++) {
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> + data->mems[i].name);
> + if (!res) {
> + dev_err(dev, "found no memory resource for %s\n",
> + data->mems[i].name);
> + return -EINVAL;
> + }
> + if (!devm_request_mem_region(dev, res->start,
> + resource_size(res),
> + dev_name(dev))) {
> + dev_err(dev, "could not request %s region for resource\n",
> + data->mems[i].name);
> + return -EBUSY;
> + }
> +
> + kproc->mem[i].cpu_addr = devm_ioremap_wc(dev, res->start,
> + resource_size(res));
> + if (IS_ERR(kproc->mem[i].cpu_addr)) {
> + dev_err(dev, "failed to map %s memory\n",
> + data->mems[i].name);
> + return PTR_ERR(kproc->mem[i].cpu_addr);
> + }
> + kproc->mem[i].bus_addr = res->start;
> + kproc->mem[i].dev_addr = data->mems[i].dev_addr;
> + kproc->mem[i].size = resource_size(res);
> +
> + dev_dbg(dev, "memory %8s: bus addr %pa size 0x%zx va %pK da 0x%x\n",
> + data->mems[i].name, &kproc->mem[i].bus_addr,
> + kproc->mem[i].size, kproc->mem[i].cpu_addr,
> + kproc->mem[i].dev_addr);
> + }
> + kproc->num_mems = num_mems;
> +
> + return 0;
> +}
> +
> +static int k3_dsp_reserved_mem_init(struct k3_dsp_rproc *kproc)
> +{
> + struct device *dev = kproc->dev;
> + struct device_node *np = dev->of_node;
> + struct device_node *rmem_np;
> + struct reserved_mem *rmem;
> + int num_rmems;
> + int ret, i;
> +
> + num_rmems = of_property_count_elems_of_size(np, "memory-region",
> + sizeof(phandle));
> + if (num_rmems <= 0) {
> + dev_err(dev, "device does not reserved memory regions, ret = %d\n",
> + num_rmems);
> + return -EINVAL;
> + }
> + if (num_rmems < 2) {
> + dev_err(dev, "device needs atleast two memory regions to be defined, num = %d\n",
> + num_rmems);
> + return -EINVAL;
> + }
> +
> + /* use reserved memory region 0 for vring DMA allocations */
> + ret = of_reserved_mem_device_init_by_idx(dev, np, 0);
> + if (ret) {
> + dev_err(dev, "device cannot initialize DMA pool, ret = %d\n",
> + ret);
> + return ret;
> + }
> +
> + num_rmems--;
> + kproc->rmem = kcalloc(num_rmems, sizeof(*kproc->rmem), GFP_KERNEL);
> + if (!kproc->rmem) {
> + ret = -ENOMEM;
> + goto release_rmem;
> + }
> +
> + /* use remaining reserved memory regions for static carveouts */
> + for (i = 0; i < num_rmems; i++) {
> + rmem_np = of_parse_phandle(np, "memory-region", i + 1);
> + if (!rmem_np) {
> + ret = -EINVAL;
> + goto unmap_rmem;
> + }
> +
> + rmem = of_reserved_mem_lookup(rmem_np);
> + if (!rmem) {
> + of_node_put(rmem_np);
> + ret = -EINVAL;
> + goto unmap_rmem;
> + }
> + of_node_put(rmem_np);
> +
> + kproc->rmem[i].bus_addr = rmem->base;
> + /* 64-bit address regions currently not supported */
> + kproc->rmem[i].dev_addr = (u32)rmem->base;
> + kproc->rmem[i].size = rmem->size;
> + kproc->rmem[i].cpu_addr = ioremap_wc(rmem->base, rmem->size);
> + if (!kproc->rmem[i].cpu_addr) {
> + dev_err(dev, "failed to map reserved memory#%d at %pa of size %pa\n",
> + i + 1, &rmem->base, &rmem->size);
> + ret = -ENOMEM;
> + goto unmap_rmem;
> + }
> +
> + dev_dbg(dev, "reserved memory%d: bus addr %pa size 0x%zx va %pK da 0x%x\n",
> + i + 1, &kproc->rmem[i].bus_addr,
> + kproc->rmem[i].size, kproc->rmem[i].cpu_addr,
> + kproc->rmem[i].dev_addr);
> + }
> + kproc->num_rmems = num_rmems;
> +
> + return 0;
> +
> +unmap_rmem:
> + for (i--; i >= 0; i--) {
> + if (kproc->rmem[i].cpu_addr)
> + iounmap(kproc->rmem[i].cpu_addr);
> + }
> + kfree(kproc->rmem);
> +release_rmem:
> + of_reserved_mem_device_release(kproc->dev);
> + return ret;
> +}
> +
> +static void k3_dsp_reserved_mem_exit(struct k3_dsp_rproc *kproc)
> +{
> + int i;
> +
> + for (i = 0; i < kproc->num_rmems; i++)
> + iounmap(kproc->rmem[i].cpu_addr);
> + kfree(kproc->rmem);
> +
> + of_reserved_mem_device_release(kproc->dev);
> +}
> +
> +static
> +struct ti_sci_proc *k3_dsp_rproc_of_get_tsp(struct device *dev,
> + const struct ti_sci_handle *sci)
> +{
> + struct ti_sci_proc *tsp;
> + u32 temp[2];
> + int ret;
> +
> + ret = of_property_read_u32_array(dev->of_node, "ti,sci-proc-ids",
> + temp, 2);
> + if (ret < 0)
> + return ERR_PTR(ret);
> +
> + tsp = kzalloc(sizeof(*tsp), GFP_KERNEL);
> + if (!tsp)
> + return ERR_PTR(-ENOMEM);
> +
> + tsp->dev = dev;
> + tsp->sci = sci;
> + tsp->ops = &sci->ops.proc_ops;
> + tsp->proc_id = temp[0];
> + tsp->host_id = temp[1];
> +
> + return tsp;
> +}
> +
> +static int k3_dsp_rproc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + const struct k3_dsp_dev_data *data;
> + struct k3_dsp_rproc *kproc;
> + struct rproc *rproc;
> + const char *fw_name;
> + int ret = 0;
> + int ret1;
> +
> + data = of_device_get_match_data(dev);
> + if (!data)
> + return -ENODEV;
> +
> + ret = rproc_of_parse_firmware(dev, 0, &fw_name);
> + if (ret) {
> + dev_err(dev, "failed to parse firmware-name property, ret = %d\n",
> + ret);
> + return ret;
> + }
> +
> + rproc = rproc_alloc(dev, dev_name(dev), &k3_dsp_rproc_ops, fw_name,
> + sizeof(*kproc));
> + if (!rproc)
> + return -ENOMEM;
> +
> + rproc->has_iommu = false;
> + rproc->recovery_disabled = true;
> + kproc = rproc->priv;
> + kproc->rproc = rproc;
> + kproc->dev = dev;
> + kproc->data = data;
> +
> + kproc->ti_sci = ti_sci_get_by_phandle(np, "ti,sci");
> + if (IS_ERR(kproc->ti_sci)) {
> + ret = PTR_ERR(kproc->ti_sci);
> + if (ret != -EPROBE_DEFER) {
> + dev_err(dev, "failed to get ti-sci handle, ret = %d\n",
> + ret);
> + }
> + kproc->ti_sci = NULL;
> + goto free_rproc;
> + }
> +
> + ret = of_property_read_u32(np, "ti,sci-dev-id", &kproc->ti_sci_id);
> + if (ret) {
> + dev_err(dev, "missing 'ti,sci-dev-id' property\n");
> + goto put_sci;
> + }
> +
> + kproc->reset = devm_reset_control_get_exclusive(dev, NULL);
> + if (IS_ERR(kproc->reset)) {
> + ret = PTR_ERR(kproc->reset);
> + dev_err(dev, "failed to get reset, status = %d\n", ret);
> + goto put_sci;
> + }
> +
> + kproc->tsp = k3_dsp_rproc_of_get_tsp(dev, kproc->ti_sci);
> + if (IS_ERR(kproc->tsp)) {
> + dev_err(dev, "failed to construct ti-sci proc control, ret = %d\n",
> + ret);
> + ret = PTR_ERR(kproc->tsp);
> + goto put_sci;
> + }
> +
> + ret = ti_sci_proc_request(kproc->tsp);
> + if (ret < 0) {
> + dev_err(dev, "ti_sci_proc_request failed, ret = %d\n", ret);
> + goto free_tsp;
> + }
> +
> + ret = k3_dsp_rproc_of_get_memories(pdev, kproc);
> + if (ret)
> + goto release_tsp;
> +
> + ret = k3_dsp_reserved_mem_init(kproc);
> + if (ret) {
> + dev_err(dev, "reserved memory init failed, ret = %d\n", ret);
> + goto release_tsp;
> + }
> +
> + ret = rproc_add(rproc);
> + if (ret) {
> + dev_err(dev, "failed to add register device with remoteproc core, status = %d\n",
> + ret);
> + goto release_mem;
> + }
> +
> + platform_set_drvdata(pdev, kproc);
> +
> + return 0;
> +
> +release_mem:
> + k3_dsp_reserved_mem_exit(kproc);
> +release_tsp:
> + ret1 = ti_sci_proc_release(kproc->tsp);
> + if (ret1)
> + dev_err(dev, "failed to release proc, ret = %d\n", ret1);
> +free_tsp:
> + kfree(kproc->tsp);
> +put_sci:
> + ret1 = ti_sci_put_handle(kproc->ti_sci);
> + if (ret1)
> + dev_err(dev, "failed to put ti_sci handle, ret = %d\n", ret1);
> +free_rproc:
> + rproc_free(rproc);
> + return ret;
> +}
> +
> +static int k3_dsp_rproc_remove(struct platform_device *pdev)
> +{
> + struct k3_dsp_rproc *kproc = platform_get_drvdata(pdev);
> + struct device *dev = &pdev->dev;
> + int ret;
> +
> + rproc_del(kproc->rproc);
> +
> + ret = ti_sci_proc_release(kproc->tsp);
> + if (ret)
> + dev_err(dev, "failed to release proc, ret = %d\n", ret);
> +
> + kfree(kproc->tsp);
> +
> + ret = ti_sci_put_handle(kproc->ti_sci);
> + if (ret)
> + dev_err(dev, "failed to put ti_sci handle, ret = %d\n", ret);
> +
> + k3_dsp_reserved_mem_exit(kproc);
> + rproc_free(kproc->rproc);
> +
> + return 0;
> +}
> +
> +static const struct k3_dsp_mem_data c66_mems[] = {
> + { .name = "l2sram", .dev_addr = 0x800000 },
> + { .name = "l1pram", .dev_addr = 0xe00000 },
> + { .name = "l1dram", .dev_addr = 0xf00000 },
> +};
> +
> +static const struct k3_dsp_dev_data c66_data = {
> + .mems = c66_mems,
> + .num_mems = ARRAY_SIZE(c66_mems),
> + .boot_align_addr = SZ_1K,
> + .uses_lreset = true,
> +};
> +
> +static const struct of_device_id k3_dsp_of_match[] = {
> + { .compatible = "ti,j721e-c66-dsp", .data = &c66_data, },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, k3_dsp_of_match);
> +
> +static struct platform_driver k3_dsp_rproc_driver = {
> + .probe = k3_dsp_rproc_probe,
> + .remove = k3_dsp_rproc_remove,
> + .driver = {
> + .name = "k3-dsp-rproc",
> + .of_match_table = k3_dsp_of_match,
> + },
> +};
> +
> +module_platform_driver(k3_dsp_rproc_driver);
> +
> +MODULE_AUTHOR("Suman Anna <s-anna@ti.com>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("TI K3 DSP Remoteproc driver");
> --
> 2.26.0
>
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: rectify entry in ARM SMC WATCHDOG DRIVER
From: Julius Werner @ 2020-06-02 20:16 UTC (permalink / raw)
To: Guenter Roeck
Cc: Lukas Bulwahn, Julius Werner, Evan Benn, Wim Van Sebroeck,
LINUX-WATCHDOG, Rob Herring, devicetree, Joe Perches,
kernel-janitors, LKML
In-Reply-To: <828311d2-61ea-42cb-1449-a53f3772543d@roeck-us.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
^ permalink raw reply
* 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
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