* Re: [PATCH 3/5] arm64: dts: qcom: sdm845: remove unit name for thermal trip points
From: Stephen Boyd @ 2019-07-23 14:47 UTC (permalink / raw)
To: Andy Gross
Cc: linux-arm-msm, Bjorn Andersson, Vinod Koul, Rob Herring,
Mark Rutland, devicetree, linux-kernel
In-Reply-To: <20190722123422.4571-4-vkoul@kernel.org>
Quoting Vinod Koul (2019-07-22 05:34:20)
> The thermal trip points have unit name but no reg property, so we can
> remove them
>
> arch/arm64/boot/dts/qcom/sdm845.dtsi:2824.31-2828.7: Warning (unit_address_vs_reg): /thermal-zones/cpu0-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:2830.31-2834.7: Warning (unit_address_vs_reg): /thermal-zones/cpu0-thermal/trips/trip-point@1: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:2868.31-2872.7: Warning (unit_address_vs_reg): /thermal-zones/cpu1-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:2874.31-2878.7: Warning (unit_address_vs_reg): /thermal-zones/cpu1-thermal/trips/trip-point@1: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:2912.31-2916.7: Warning (unit_address_vs_reg): /thermal-zones/cpu2-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:2918.31-2922.7: Warning (unit_address_vs_reg): /thermal-zones/cpu2-thermal/trips/trip-point@1: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:2956.31-2960.7: Warning (unit_address_vs_reg): /thermal-zones/cpu3-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:2962.31-2966.7: Warning (unit_address_vs_reg): /thermal-zones/cpu3-thermal/trips/trip-point@1: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3000.31-3004.7: Warning (unit_address_vs_reg): /thermal-zones/cpu4-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3006.31-3010.7: Warning (unit_address_vs_reg): /thermal-zones/cpu4-thermal/trips/trip-point@1: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3044.31-3048.7: Warning (unit_address_vs_reg): /thermal-zones/cpu5-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3050.31-3054.7: Warning (unit_address_vs_reg): /thermal-zones/cpu5-thermal/trips/trip-point@1: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3088.31-3092.7: Warning (unit_address_vs_reg): /thermal-zones/cpu6-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3094.31-3098.7: Warning (unit_address_vs_reg): /thermal-zones/cpu6-thermal/trips/trip-point@1: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3132.31-3136.7: Warning (unit_address_vs_reg): /thermal-zones/cpu7-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3138.31-3142.7: Warning (unit_address_vs_reg): /thermal-zones/cpu7-thermal/trips/trip-point@1: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3176.32-3180.7: Warning (unit_address_vs_reg): /thermal-zones/aoss0-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3191.35-3195.7: Warning (unit_address_vs_reg): /thermal-zones/cluster0-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3211.35-3215.7: Warning (unit_address_vs_reg): /thermal-zones/cluster1-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3231.31-3235.7: Warning (unit_address_vs_reg): /thermal-zones/gpu-thermal-top/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3246.31-3250.7: Warning (unit_address_vs_reg): /thermal-zones/gpu-thermal-bottom/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3261.32-3265.7: Warning (unit_address_vs_reg): /thermal-zones/aoss1-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3276.35-3280.7: Warning (unit_address_vs_reg): /thermal-zones/q6-modem-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3291.30-3295.7: Warning (unit_address_vs_reg): /thermal-zones/mem-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3306.31-3310.7: Warning (unit_address_vs_reg): /thermal-zones/wlan-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3321.33-3325.7: Warning (unit_address_vs_reg): /thermal-zones/q6-hvx-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3336.33-3340.7: Warning (unit_address_vs_reg): /thermal-zones/camera-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3351.32-3355.7: Warning (unit_address_vs_reg): /thermal-zones/video-thermal/trips/trip-point@0: node has a unit name, but no reg property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:3366.32-3370.7: Warning (unit_address_vs_reg): /thermal-zones/modem-thermal/trips/trip-point@0: node has a unit name, but no reg property
>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
> ---
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
^ permalink raw reply
* Re: [PATCH 1/5] arm64: dts: qcom: sdm845: Add unit name to soc node
From: Stephen Boyd @ 2019-07-23 14:50 UTC (permalink / raw)
To: Andy Gross
Cc: linux-arm-msm, Bjorn Andersson, Vinod Koul, Rob Herring,
Mark Rutland, devicetree, linux-kernel
In-Reply-To: <20190722123422.4571-2-vkoul@kernel.org>
Quoting Vinod Koul (2019-07-22 05:34:18)
> We get a warning about missing unit name for soc node, so add it.
>
> arch/arm64/boot/dts/qcom/sdm845.dtsi:623.11-2814.4: Warning (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit name
>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
> ---
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 601cfb078bd5..e81f4a6d08ce 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -620,7 +620,7 @@
> method = "smc";
> };
>
> - soc: soc {
> + soc: soc@0 {
This is kinda sad, but ok. Maybe you can apply this fix to at least all
the qcom boards then.
> #address-cells = <2>;
> #size-cells = <2>;
> ranges = <0 0 0 0 0x10 0>;
^ permalink raw reply
* Re: [PATCH] dt-bindings: Add pxe1610 as a trivial device
From: Rob Herring @ 2019-07-23 14:50 UTC (permalink / raw)
To: Vijay Khemka
Cc: Mark Rutland, Jiri Kosina, Guenter Roeck, Herbert Xu,
Patrick Venture, Ard Biesheuvel, Anson Huang, Jeremy Gebben,
devicetree, linux-kernel@vger.kernel.org,
openbmc @ lists . ozlabs . org, Joel Stanley, linux-aspeed,
sdasari
In-Reply-To: <20190723002052.2878847-1-vijaykhemka@fb.com>
On Mon, Jul 22, 2019 at 6:46 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
> The pxe1610 is a voltage regulator from Infineon. It also supports
> other VRs pxe1110 and pxm1310 from Infineon.
>
> Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> ---
> Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
> index 2e742d399e87..1be648828a31 100644
> --- a/Documentation/devicetree/bindings/trivial-devices.yaml
> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
> @@ -99,6 +99,8 @@ properties:
> # Infineon IR38064 Voltage Regulator
> - infineon,ir38064
> # Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz)
> + - infineon,pxe1610
> + # Infineon PXE1610, PXE1110 and PXM1310 Voltage Regulators
The comment goes above the entry.
> - infineon,slb9635tt
> # Infineon SLB9645 I2C TPM (new protocol, max 400khz)
> - infineon,slb9645tt
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 3/4] ARM: dts: am33xx: Add nodes for eQEP
From: Tony Lindgren @ 2019-07-23 14:51 UTC (permalink / raw)
To: David Lechner
Cc: linux-iio, linux-omap, devicetree, Rob Herring, Mark Rutland,
Benoît Cousson, William Breathitt Gray, Thierry Reding,
linux-kernel, linux-pwm
In-Reply-To: <af21fd76-7123-b317-896b-bfe18d293325@lechnology.com>
* David Lechner <david@lechnology.com> [190723 14:46]:
> On 7/23/19 3:42 AM, Tony Lindgren wrote:
> > * David Lechner <david@lechnology.com> [190722 15:46]:
> > > This adds new nodes for the Texas Instruments Enhanced Quadrature
> > > Encoder Pulse (eQEP) module in the PWM subsystem on AM33XX.
> > >
> > > Signed-off-by: David Lechner <david@lechnology.com>
> > > ---
> > > arch/arm/boot/dts/am33xx-l4.dtsi | 27 +++++++++++++++++++++++++++
> > > 1 file changed, 27 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi
> > > index 3b1fb2ba4dff..7fdc2f61c553 100644
> > > --- a/arch/arm/boot/dts/am33xx-l4.dtsi
> > > +++ b/arch/arm/boot/dts/am33xx-l4.dtsi
> > > @@ -1908,6 +1908,15 @@
> > > status = "disabled";
> > > };
> > > + eqep0: eqep@180 {
> > > + compatible = "ti,am3352-eqep";
> > > + reg = <0x180 0x80>;
> > > + clocks = <&l4ls_gclk>;
> > > + clock-names = "fck";
> > > + interrupts = <79>;
> > > + status = "disabled";
> > > + };
> > > +
> >
> > You probably no longer need to map any clocks here as this> is now a child of the interconnect target module managed
> > by ti-sysc driver. I have not checked but probably l4ls_gclk
> > is same as clocks = <&l4ls_clkctrl AM3_L4LS_EPWMSS0_CLKCTRL 0>
> > already managed by ti-sysc. If so, then just using runtime PM
> > calls in any of the child device drivers will keep it enabled.
> >
> > If l4ls_gclk is a separate functional clock, then it still
> > needs to be managed by the child device driver directly.
>
> The clock is included so that we can get the clock rate for
> the timing aspects of the eQEP, not for power management.
>
> I chose to use the "fck" name to be consistent with the
> sibling EHRPWM and ECAP nodes that already have the same
> bindings for the same clock.
OK makes sense to me thanks.
Tony
^ permalink raw reply
* Re: [PATCH 5/5] arm64: dts: qcom: sdm845-cheza: remove macro from unit name
From: Stephen Boyd @ 2019-07-23 14:51 UTC (permalink / raw)
To: Andy Gross
Cc: linux-arm-msm, Bjorn Andersson, Vinod Koul, Rob Herring,
Mark Rutland, devicetree, linux-kernel
In-Reply-To: <20190722123422.4571-6-vkoul@kernel.org>
Quoting Vinod Koul (2019-07-22 05:34:22)
> Unit name is supposed to be a number, using a macro with hex value is
> not recommended, so add the value in unit name.
>
> arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:966.16-969.4: Warning (unit_address_format): /soc@0/spmi@c440000/pmic@0/adc@3100/adc-chan@0x4d: unit name should not have leading "0x"
> arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:971.16-974.4: Warning (unit_address_format): /soc@0/spmi@c440000/pmic@0/adc@3100/adc-chan@0x4e: unit name should not have leading "0x"
> arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:976.16-979.4: Warning (unit_address_format): /soc@0/spmi@c440000/pmic@0/adc@3100/adc-chan@0x4f: unit name should not have leading "0x"
> arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:981.16-984.4: Warning (unit_address_format): /soc@0/spmi@c440000/pmic@0/adc@3100/adc-chan@0x50: unit name should not have leading "0x"
> arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:986.16-989.4: Warning (unit_address_format): /soc@0/spmi@c440000/pmic@0/adc@3100/adc-chan@0x51: unit name should not have leading "0x"
>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
> ---
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: Add pxe1610 as a trivial device
From: Rob Herring @ 2019-07-23 14:52 UTC (permalink / raw)
To: Vijay Khemka
Cc: Mark Rutland, Jiri Kosina, Guenter Roeck, Herbert Xu,
Patrick Venture, Ard Biesheuvel, Anson Huang, Jeremy Gebben,
devicetree, linux-kernel@vger.kernel.org,
openbmc @ lists . ozlabs . org, Joel Stanley, linux-aspeed,
sdasari
In-Reply-To: <CAL_Jsq+uAjK6+xzkyOhcH96tZuqv7i6Nz5_nhUQkZ2adt2gutA@mail.gmail.com>
On Tue, Jul 23, 2019 at 8:50 AM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Mon, Jul 22, 2019 at 6:46 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
> >
> > The pxe1610 is a voltage regulator from Infineon. It also supports
> > other VRs pxe1110 and pxm1310 from Infineon.
What happened to the other compatibles? S/w doesn't need to know the
differences?
> >
> > Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> > ---
> > Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
> > index 2e742d399e87..1be648828a31 100644
> > --- a/Documentation/devicetree/bindings/trivial-devices.yaml
> > +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
> > @@ -99,6 +99,8 @@ properties:
> > # Infineon IR38064 Voltage Regulator
> > - infineon,ir38064
> > # Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz)
> > + - infineon,pxe1610
> > + # Infineon PXE1610, PXE1110 and PXM1310 Voltage Regulators
>
> The comment goes above the entry.
>
> > - infineon,slb9635tt
> > # Infineon SLB9645 I2C TPM (new protocol, max 400khz)
> > - infineon,slb9645tt
> > --
> > 2.17.1
> >
^ permalink raw reply
* Re: [Sound-open-firmware] [PATCH v2 1/5] ASoC: SOF: imx: Add i.MX8 HW support
From: Pierre-Louis Bossart @ 2019-07-23 15:01 UTC (permalink / raw)
To: Daniel Baluta, m.felsch, shawnguo
Cc: mark.rutland, aisheng.dong, peng.fan, anson.huang, devicetree,
shengjiu.wang, linux-kernel, paul.olaru, robh+dt, linux-imx,
kernel, leonard.crestez, festevam, linux-arm-kernel,
sound-open-firmware
In-Reply-To: <20190723084104.12639-2-daniel.baluta@nxp.com>
> diff --git a/sound/soc/sof/imx/Makefile b/sound/soc/sof/imx/Makefile
> new file mode 100644
> index 000000000000..c69237971da5
> --- /dev/null
> +++ b/sound/soc/sof/imx/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +
> +ccflags-y += -DDEBUG
this should be removed or in a separate patch.
> +struct imx8_priv {
> + struct device *dev;
> + struct snd_sof_dev *sdev;
> + struct imx_dsp_ipc *dsp_ipc;
> + struct imx_sc_ipc *sc_ipc;
maybe a comment to explain what 'sc' stands for?
> +};
> +
> +static void imx8_get_windows(struct snd_sof_dev *sdev)
> +{
> + struct sof_ipc_window_elem *elem;
> + u32 outbox_offset = 0;
> + u32 stream_offset = 0;
> + u32 inbox_offset = 0;
> + u32 outbox_size = 0;
> + u32 stream_size = 0;
> + u32 inbox_size = 0;
> + int i;
> +
> + if (!sdev->info_window) {
> + dev_err(sdev->dev, "error: have no window info\n");
> + return;
> + }
> +
> + for (i = 0; i < sdev->info_window->num_windows; i++) {
> + elem = &sdev->info_window->window[i];
> +
> + switch (elem->type) {
> + case SOF_IPC_REGION_UPBOX:
> + inbox_offset = elem->offset + MBOX_OFFSET;
> + inbox_size = elem->size;
> + snd_sof_debugfs_io_item(sdev,
> + sdev->bar[SOF_FW_BLK_TYPE_SRAM]
> + + inbox_offset,
> + elem->size, "inbox",
> + SOF_DEBUGFS_ACCESS_D0_ONLY);
> + break;
> + case SOF_IPC_REGION_DOWNBOX:
> + outbox_offset = elem->offset + MBOX_OFFSET;
> + outbox_size = elem->size;
> + snd_sof_debugfs_io_item(sdev,
> + sdev->bar[SOF_FW_BLK_TYPE_SRAM]
> + + outbox_offset,
> + elem->size, "outbox",
> + SOF_DEBUGFS_ACCESS_D0_ONLY);
> + break;
> + case SOF_IPC_REGION_TRACE:
> + snd_sof_debugfs_io_item(sdev,
> + sdev->bar[SOF_FW_BLK_TYPE_SRAM]
> + + elem->offset + MBOX_OFFSET,
> + elem->size, "etrace",
> + SOF_DEBUGFS_ACCESS_D0_ONLY);
> + break;
> + case SOF_IPC_REGION_DEBUG:
> + snd_sof_debugfs_io_item(sdev,
> + sdev->bar[SOF_FW_BLK_TYPE_SRAM]
> + + elem->offset + MBOX_OFFSET,
> + elem->size, "debug",
> + SOF_DEBUGFS_ACCESS_D0_ONLY);
> + break;
> + case SOF_IPC_REGION_STREAM:
> + stream_offset = elem->offset + MBOX_OFFSET;
> + stream_size = elem->size;
> + snd_sof_debugfs_io_item(sdev,
> + sdev->bar[SOF_FW_BLK_TYPE_SRAM]
> + + stream_offset,
> + elem->size, "stream",
> + SOF_DEBUGFS_ACCESS_D0_ONLY);
> + break;
> + case SOF_IPC_REGION_REGS:
> + snd_sof_debugfs_io_item(sdev,
> + sdev->bar[SOF_FW_BLK_TYPE_SRAM]
> + + elem->offset + MBOX_OFFSET,
> + elem->size, "regs",
> + SOF_DEBUGFS_ACCESS_D0_ONLY);
> + break;
> + case SOF_IPC_REGION_EXCEPTION:
> + sdev->dsp_oops_offset = elem->offset + MBOX_OFFSET;
> + snd_sof_debugfs_io_item(sdev,
> + sdev->bar[SOF_FW_BLK_TYPE_SRAM]
> + + elem->offset + MBOX_OFFSET,
> + elem->size, "exception",
> + SOF_DEBUGFS_ACCESS_D0_ONLY);
> + break;
> + default:
> + dev_err(sdev->dev, "error: get illegal window info\n");
> + return;
> + }
> + }
> +
> + if (outbox_size == 0 || inbox_size == 0) {
> + dev_err(sdev->dev, "error: get illegal mailbox window\n");
> + return;
> + }
> +
> + snd_sof_dsp_mailbox_init(sdev, inbox_offset, inbox_size,
> + outbox_offset, outbox_size);
> + sdev->stream_box.offset = stream_offset;
> + sdev->stream_box.size = stream_size;
> +
> + dev_dbg(sdev->dev, " mailbox upstream 0x%x - size 0x%x\n",
> + inbox_offset, inbox_size);
> + dev_dbg(sdev->dev, " mailbox downstream 0x%x - size 0x%x\n",
> + outbox_offset, outbox_size);
> + dev_dbg(sdev->dev, " stream region 0x%x - size 0x%x\n",
> + stream_offset, stream_size);
> +}
This looks 100% similar to Baytrail?
> +
> +/*
> + * IPC Firmware ready.
> + */
> +static int imx8_fw_ready(struct snd_sof_dev *sdev, u32 msg_id)
> +{
> + struct sof_ipc_fw_ready *fw_ready = &sdev->fw_ready;
> + u32 offset;
> + int ret;
> +
> + /* mailbox must be on 4k boundary */
> + offset = MBOX_OFFSET;
> +
> + dev_dbg(sdev->dev, "ipc: DSP is ready 0x%8.8x offset 0x%x\n",
> + msg_id, offset);
> +
> + /* no need to re-check version/ABI for subsequent boots */
> + if (!sdev->first_boot)
> + return 0;
> +
> + /* copy data from the DSP FW ready offset */
> + sof_block_read(sdev, sdev->mailbox_bar, offset, fw_ready,
> + sizeof(*fw_ready));
> + snd_sof_dsp_mailbox_init(sdev, fw_ready->dspbox_offset,
> + fw_ready->dspbox_size,
> + fw_ready->hostbox_offset,
> + fw_ready->hostbox_size);
> +
> + /* make sure ABI version is compatible */
> + ret = snd_sof_ipc_valid(sdev);
> + if (ret < 0)
> + return ret;
> +
> + /* now check for extended data */
> + snd_sof_fw_parse_ext_data(sdev, SOF_FW_BLK_TYPE_SRAM, MBOX_OFFSET +
> + sizeof(struct sof_ipc_fw_ready));
> +
> + imx8_get_windows(sdev);
> +
> + return 0;
> +}
That code looks nearly similar to the baytrail one except for the last
line, we should look into factoring this.
> +
> +static void imx8_get_reply(struct snd_sof_dev *sdev)
> +{
> + struct snd_sof_ipc_msg *msg = sdev->msg;
> + struct sof_ipc_reply reply;
> + unsigned long flags;
> + int ret = 0;
> +
> + if (!msg) {
> + dev_warn(sdev->dev, "unexpected ipc interrupt\n");
> + return;
> + }
> +
> + /* get reply */
> + sof_mailbox_read(sdev, sdev->host_box.offset, &reply, sizeof(reply));
> +
> + spin_lock_irqsave(&sdev->ipc_lock, flags);
> +
> + if (reply.error < 0) {
> + memcpy(msg->reply_data, &reply, sizeof(reply));
> + ret = reply.error;
> + } else {
> + /* reply has correct size? */
> + if (reply.hdr.size != msg->reply_size) {
> + dev_err(sdev->dev, "error: reply expected %zu got %u bytes\n",
> + msg->reply_size, reply.hdr.size);
> + ret = -EINVAL;
> + }
> +
> + /* read the message */
> + if (msg->reply_size > 0)
> + sof_mailbox_read(sdev, sdev->host_box.offset,
> + msg->reply_data, msg->reply_size);
> + }
> +
> + msg->reply_error = ret;
> +
> + spin_unlock_irqrestore(&sdev->ipc_lock, flags);
I don't see a spin_lock/unlock for the get_reply in the Intel code, is
this necessary?
> +}
> +
> +void imx_dsp_handle_reply(struct imx_dsp_ipc *ipc)
> +{
> + struct imx8_priv *priv = imx_dsp_get_data(ipc);
> +
> + imx8_get_reply(priv->sdev);
> + snd_sof_ipc_reply(priv->sdev, 0);
> +}
> +
> +void imx_dsp_handle_request(struct imx_dsp_ipc *ipc)
> +{
> + struct imx8_priv *priv = imx_dsp_get_data(ipc);
> +
> + snd_sof_ipc_msgs_rx(priv->sdev);
> +}
> +
> +struct imx_dsp_ops dsp_ops = {
> + .handle_reply = imx_dsp_handle_reply,
> + .handle_request = imx_dsp_handle_request,
> +};
> +
> +static int imx8_send_msg(struct snd_sof_dev *sdev, struct snd_sof_ipc_msg *msg)
> +{
> + struct imx8_priv *priv = (struct imx8_priv *)sdev->private;
> +
> + sof_mailbox_write(sdev, sdev->host_box.offset, msg->msg_data,
> + msg->msg_size);
> + imx_dsp_ring_doorbell(priv->dsp_ipc, 0);
> +
> + return 0;
> +}
> +
> +/*
> + * DSP control.
> + */
> +static int imx8_run(struct snd_sof_dev *sdev)
> +{
> + int ret;
> + struct imx8_priv *dsp_priv = (struct imx8_priv *)sdev->private;
> +
> + ret = imx_sc_misc_set_control(dsp_priv->sc_ipc, IMX_SC_R_DSP,
> + IMX_SC_C_OFS_SEL, 1);
> + if (ret < 0) {
> + dev_err(sdev->dev, "Error system address offset source select\n");
> + return ret;
> + }
> +
> + ret = imx_sc_misc_set_control(dsp_priv->sc_ipc, IMX_SC_R_DSP,
> + IMX_SC_C_OFS_AUDIO, 0x80);
> + if (ret < 0) {
> + dev_err(sdev->dev, "Error system address offset of AUDIO\n");
> + return ret;
> + }
> +
> + ret = imx_sc_misc_set_control(dsp_priv->sc_ipc, IMX_SC_R_DSP,
> + IMX_SC_C_OFS_PERIPH, 0x5A);
> + if (ret < 0) {
> + dev_err(sdev->dev, "Error system address offset of PERIPH %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = imx_sc_misc_set_control(dsp_priv->sc_ipc, IMX_SC_R_DSP,
> + IMX_SC_C_OFS_IRQ, 0x51);
> + if (ret < 0) {
> + dev_err(sdev->dev, "Error system address offset of IRQ\n");
> + return ret;
> + }
> +
> + imx_sc_pm_cpu_start(dsp_priv->sc_ipc, IMX_SC_R_DSP, true,
> + RESET_VECTOR_VADDR);
> +
> + return 0;
> +}
> +
> +static int imx8_probe(struct snd_sof_dev *sdev)
> +{
> + struct imx8_priv *priv;
> + int i;
> + struct platform_device *pdev =
> + container_of(sdev->dev, struct platform_device, dev);
> + struct platform_device *ipc_dev;
> + struct resource *mmio;
> + int num_domains = 0;
> + u32 base, size;
> + int ret = 0;
> + struct device_node *np = pdev->dev.of_node;
> + struct device_node *res_node;
> + struct resource res;
nit-pick: can we reorder so that we have all counters last and a nice
xmas-tree shape.
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + sdev->private = priv;
> + priv->dev = sdev->dev;
> + priv->sdev = sdev;
> +
> + ret = imx_scu_get_handle(&priv->sc_ipc);
> + if (ret) {
> + dev_err(sdev->dev, "Cannot obtain SCU handle (err = %d)\n",
> + ret);
> + return ret;
> + }
> +
> + ipc_dev = platform_device_register_data(sdev->dev, "imx-dsp",
> + PLATFORM_DEVID_NONE,
> + pdev, sizeof(*pdev));
> + if (IS_ERR(ipc_dev)) {
> + dev_err(sdev->dev, "Failed to register platform device\n");
> + return PTR_ERR(ipc_dev);
> + }
> +
> + priv->dsp_ipc = dev_get_drvdata(&ipc_dev->dev);
> + if (!priv->dsp_ipc)
> + return -EPROBE_DEFER;
> +
> + imx_dsp_set_data(priv->dsp_ipc, priv);
> + priv->dsp_ipc->ops = &dsp_ops;
> +
> + num_domains = of_count_phandle_with_args(np, "power-domains",
> + "#power-domain-cells");
> + for (i = 0; i < num_domains; i++) {
> + struct device *pd_dev;
> + struct device_link *link;
> +
> + pd_dev = dev_pm_domain_attach_by_id(&pdev->dev, i);
> + if (IS_ERR(pd_dev))
> + return PTR_ERR(pd_dev);
> +
> + link = device_link_add(&pdev->dev, pd_dev,
> + DL_FLAG_STATELESS |
> + DL_FLAG_PM_RUNTIME |
> + DL_FLAG_RPM_ACTIVE);
> + if (IS_ERR(link))
> + return PTR_ERR(link);
Question: is the error flow final? Wondering if we release all the
resources/memory/devices on errors?
Also are all the resources device-managed, I don't see a remove()?
> + }
> +
> + /* DSP base */
> + mmio = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (mmio) {
> + base = mmio->start;
> + size = resource_size(mmio);
> + } else {
> + dev_err(sdev->dev, "error: failed to get DSP base at idx 0\n");
> + return -EINVAL;
> + }
> +
> + sdev->bar[SOF_FW_BLK_TYPE_IRAM] = devm_ioremap(sdev->dev, base, size);
> + if (!sdev->bar[SOF_FW_BLK_TYPE_IRAM]) {
> + dev_err(sdev->dev, "failed to ioremap base 0x%x size 0x%x\n",
> + base, size);
> + return -ENODEV;
> + }
> + sdev->mmio_bar = SOF_FW_BLK_TYPE_IRAM;
> +
> + res_node = of_parse_phandle(np, "memory-region", 0);
> + if (!res_node) {
> + dev_err(&pdev->dev, "failed to get memory region node\n");
> + return -ENODEV;
> + }
> + if (of_address_to_resource(res_node, 0, &res)) {
> + dev_err(&pdev->dev, "failed to get reserved region address\n");
> + return -EINVAL;
> + }
> +
> + sdev->bar[SOF_FW_BLK_TYPE_SRAM] = devm_ioremap_wc(sdev->dev, res.start,
> + res.end - res.start +
> + 1);
> + if (!sdev->bar[SOF_FW_BLK_TYPE_SRAM]) {
> + dev_err(sdev->dev, "failed to ioremap mem 0x%x size 0x%x\n",
> + base, size);
> + return -ENODEV;
> + }
> + sdev->mailbox_bar = SOF_FW_BLK_TYPE_SRAM;
> +
> + return ret;
> +}
> +
> +/* on i.MX8 there is 1 to 1 match between type and BAR idx */
> +int imx8_get_bar_index(struct snd_sof_dev *sdev, u32 type)
> +{
> + return type;
> +}
> +
> +void imx8_ipc_msg_data(struct snd_sof_dev *sdev,
> + struct snd_pcm_substream *substream,
> + void *p, size_t sz)
> +{
> + sof_mailbox_read(sdev, sdev->dsp_box.offset, p, sz);
> +}
> +
> +int imx8_ipc_pcm_params(struct snd_sof_dev *sdev,
> + struct snd_pcm_substream *substream,
> + const struct sof_ipc_pcm_params_reply *reply)
> +{
> + return 0;
> +}
> +
> +static struct snd_soc_dai_driver imx8_dai[] = {
> +{
> + .name = "esai-port",
> +},
> +};
> +
> +/* i.MX8 ops */
> +struct snd_sof_dsp_ops sof_imx8_ops = {
> + /* device init */
> + .probe = imx8_probe,
> +
> + /* DSP core boot */
> + .run = imx8_run,
> +
> + /* Block IO */
> + .block_read = sof_block_read,
> + .block_write = sof_block_write,
> +
> + /* ipc */
> + .send_msg = imx8_send_msg,
> + .fw_ready = imx8_fw_ready,
> +
> + .ipc_msg_data = imx8_ipc_msg_data,
> + .ipc_pcm_params = imx8_ipc_pcm_params,
> +
> + /* module loading */
> + .load_module = snd_sof_parse_module_memcpy,
> + .get_bar_index = imx8_get_bar_index,
> + /* firmware loading */
> + .load_firmware = snd_sof_load_firmware_memcpy,
> +
> + /* DAI drivers */
> + .drv = imx8_dai,
> + .num_drv = 1, /* we have only 1 ESAI interface on i.MX8 */
> +};
> +EXPORT_SYMBOL(sof_imx8_ops);
> +
> +MODULE_LICENSE("Dual BSD/GPL");
>
^ permalink raw reply
* Re: [Sound-open-firmware] [PATCH v2 3/5] ASoC: SOF: Add DT DSP device support
From: Pierre-Louis Bossart @ 2019-07-23 15:11 UTC (permalink / raw)
To: Daniel Baluta, m.felsch, shawnguo
Cc: mark.rutland, aisheng.dong, peng.fan, anson.huang, devicetree,
shengjiu.wang, linux-kernel, paul.olaru, robh+dt, linux-imx,
kernel, leonard.crestez, festevam, linux-arm-kernel,
sound-open-firmware
In-Reply-To: <20190723084104.12639-4-daniel.baluta@nxp.com>
> diff --git a/sound/soc/sof/Kconfig b/sound/soc/sof/Kconfig
> index 61b97fc55bb2..2aa3a1cdf60c 100644
> --- a/sound/soc/sof/Kconfig
> +++ b/sound/soc/sof/Kconfig
> @@ -36,6 +36,15 @@ config SND_SOC_SOF_ACPI
> Say Y if you need this option
> If unsure select "N".
>
> +config SND_SOC_SOF_DT
> + tristate "SOF DT enumeration support"
> + select SND_SOC_SOF
> + select SND_SOC_SOF_OPTIONS
> + help
> + This adds support for Device Tree enumeration. This option is
> + required to enable i.MX8 devices.
> + Say Y if you need this option. If unsure select "N".
> +
[snip]
> diff --git a/sound/soc/sof/imx/Kconfig b/sound/soc/sof/imx/Kconfig
> index fff64a9970f0..fa35994a79c4 100644
> --- a/sound/soc/sof/imx/Kconfig
> +++ b/sound/soc/sof/imx/Kconfig
> @@ -12,6 +12,7 @@ if SND_SOC_SOF_IMX_TOPLEVEL
>
> config SND_SOC_SOF_IMX8
> tristate "SOF support for i.MX8"
> + select SND_SOC_SOF_DT
This looks upside down. You should select SOF_DT first then include the
NXP stuff.
> help
> This adds support for Sound Open Firmware for NXP i.MX8 platforms
> Say Y if you have such a device.
> diff --git a/sound/soc/sof/sof-dt-dev.c b/sound/soc/sof/sof-dt-dev.c
> new file mode 100644
> index 000000000000..31429bbb5c7e
> --- /dev/null
> +++ b/sound/soc/sof/sof-dt-dev.c
> @@ -0,0 +1,159 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +//
> +// Copyright 2019 NXP
> +//
> +// Author: Daniel Baluta <daniel.baluta@nxp.com>
> +//
> +
> +#include <linux/firmware.h>
> +#include <linux/module.h>
> +#include <linux/pm_runtime.h>
> +#include <sound/sof.h>
> +
> +#include "ops.h"
> +
> +extern struct snd_sof_dsp_ops sof_imx8_ops;
> +
> +static char *fw_path;
> +module_param(fw_path, charp, 0444);
> +MODULE_PARM_DESC(fw_path, "alternate path for SOF firmware.");
> +
> +static char *tplg_path;
> +module_param(tplg_path, charp, 0444);
> +MODULE_PARM_DESC(tplg_path, "alternate path for SOF topology.");
> +
> +/* platform specific devices */
> +#if IS_ENABLED(CONFIG_SND_SOC_SOF_IMX8)
> +static struct sof_dev_desc sof_dt_imx8qxp_desc = {
> + .default_fw_path = "imx/sof",
> + .default_tplg_path = "imx/sof-tplg",
> + .nocodec_fw_filename = "sof-imx8.ri",
> + .nocodec_tplg_filename = "sof-imx8-nocodec.tplg",
> + .ops = &sof_imx8_ops,
> +};
> +#endif
> +
> +static const struct dev_pm_ops sof_dt_pm = {
> + SET_SYSTEM_SLEEP_PM_OPS(snd_sof_suspend, snd_sof_resume)
> + SET_RUNTIME_PM_OPS(snd_sof_runtime_suspend, snd_sof_runtime_resume,
> + NULL)
> +};
> +
> +static void sof_dt_probe_complete(struct device *dev)
> +{
> + /* allow runtime_pm */
> + pm_runtime_set_autosuspend_delay(dev, SND_SOF_SUSPEND_DELAY_MS);
> + pm_runtime_use_autosuspend(dev);
> + pm_runtime_enable(dev);
> +}
> +
> +static int sof_dt_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + const struct sof_dev_desc *desc;
> + /*TODO: create a generic snd_soc_xxx_mach */
> + struct snd_soc_acpi_mach *mach;
I wonder if you really need to use the same structures. For Intel we get
absolutely zero info from the firmware so rely on an ACPI codec ID as a
key to find information on which firmware and topology to use, and which
machine driver to load. You could have all this information in a DT blob?
> + struct snd_sof_pdata *sof_pdata;
> + const struct snd_sof_dsp_ops *ops;
> + int ret;
> +
> + dev_info(&pdev->dev, "DT DSP detected");
> +
> + sof_pdata = devm_kzalloc(dev, sizeof(*sof_pdata), GFP_KERNEL);
> + if (!sof_pdata)
> + return -ENOMEM;
> +
> + desc = device_get_match_data(dev);
> + if (!desc)
> + return -ENODEV;
> +
> + /* get ops for platform */
> + ops = desc->ops;
> + if (!ops) {
> + dev_err(dev, "error: no matching DT descriptor ops\n");
> + return -ENODEV;
> + }
> +
> +#if IS_ENABLED(CONFIG_SND_SOC_SOF_FORCE_NOCODEC_MODE)
> + /* force nocodec mode */
> + dev_warn(dev, "Force to use nocodec mode\n");
> + mach = devm_kzalloc(dev, sizeof(*mach), GFP_KERNEL);
> + if (!mach)
> + return -ENOMEM;
> + ret = sof_nocodec_setup(dev, sof_pdata, mach, desc, ops);
> + if (ret < 0)
> + return ret;
> +#else
> + /* TODO: implement case where we actually have a codec */
> + return -ENODEV;
> +#endif
> +
> + if (mach)
> + mach->mach_params.platform = dev_name(dev);
> +
> + sof_pdata->machine = mach;
> + sof_pdata->desc = desc;
> + sof_pdata->dev = &pdev->dev;
> + sof_pdata->platform = dev_name(dev);
> +
> + /* alternate fw and tplg filenames */
> + if (fw_path)
> + sof_pdata->fw_filename_prefix = fw_path;
> + else
> + sof_pdata->fw_filename_prefix =
> + sof_pdata->desc->default_fw_path;
> + if (tplg_path)
> + sof_pdata->tplg_filename_prefix = tplg_path;
> + else
> + sof_pdata->tplg_filename_prefix =
> + sof_pdata->desc->default_tplg_path;
> +
> +#if IS_ENABLED(CONFIG_SND_SOC_SOF_PROBE_WORK_QUEUE)
> + /* set callback to enable runtime_pm */
> + sof_pdata->sof_probe_complete = sof_dt_probe_complete;
> +#endif
> + /* call sof helper for DSP hardware probe */
> + ret = snd_sof_device_probe(dev, sof_pdata);
> + if (ret) {
> + dev_err(dev, "error: failed to probe DSP hardware\n");
> + return ret;
> + }
> +
> +#if !IS_ENABLED(CONFIG_SND_SOC_SOF_PROBE_WORK_QUEUE)
> + sof_dt_probe_complete(dev);
> +#endif
> +
> + return ret;
> +}
> +
> +static int sof_dt_remove(struct platform_device *pdev)
> +{
> + pm_runtime_disable(&pdev->dev);
> +
> + /* call sof helper for DSP hardware remove */
> + snd_sof_device_remove(&pdev->dev);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id sof_dt_ids[] = {
> +#if IS_ENABLED(CONFIG_SND_SOC_SOF_IMX8)
> + { .compatible = "fsl,imx8qxp-dsp", .data = &sof_dt_imx8qxp_desc},
> +#endif
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, sof_dt_ids);
> +
> +/* DT driver definition */
> +static struct platform_driver snd_sof_dt_driver = {
> + .probe = sof_dt_probe,
> + .remove = sof_dt_remove,
> + .driver = {
> + .name = "sof-audio-dt",
> + .pm = &sof_dt_pm,
> + .of_match_table = sof_dt_ids
> + },
> +};
> +module_platform_driver(snd_sof_dt_driver);
> +
> +MODULE_LICENSE("Dual BSD/GPL");
>
^ permalink raw reply
* [PATCH net-next 0/3] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Claudiu Manoil @ 2019-07-23 15:15 UTC (permalink / raw)
To: David S . Miller
Cc: Rob Herring, Li Yang, alexandru.marginean, netdev, devicetree,
linux-arm-kernel, linux-kernel
First patch just registers the PCIe endpoint device containing
the MDIO registers as a standalone MDIO bus driver, to allow
an alternative way to control the MDIO bus. The same code used
by the ENETC ports (eth controllers) to manage MDIO via local
registers applies and is reused.
Bindings are provided for the new MDIO node, similarly to ENETC
port nodes bindings.
Last patch enables the ENETC port 1 and its RGMII PHY on the
LS1028A QDS board, where the MDIO muxing configuration relies
on the MDIO support provided in the first patch.
Claudiu Manoil (3):
enetc: Add mdio bus driver for the PCIe MDIO endpoint
dt-bindings: net: fsl: enetc: Add bindings for the central MDIO PCIe
endpoint
arm64: dts: ls1028a: Enable eth port1 on the ls1028a QDS board
.../devicetree/bindings/net/fsl-enetc.txt | 42 ++++++++-
.../boot/dts/freescale/fsl-ls1028a-qds.dts | 40 +++++++++
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 ++
.../net/ethernet/freescale/enetc/enetc_mdio.c | 90 +++++++++++++++++++
.../net/ethernet/freescale/enetc/enetc_pf.c | 5 +-
5 files changed, 179 insertions(+), 4 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net-next 1/3] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Claudiu Manoil @ 2019-07-23 15:15 UTC (permalink / raw)
To: David S . Miller
Cc: Rob Herring, Li Yang, alexandru.marginean, netdev, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1563894955-545-1-git-send-email-claudiu.manoil@nxp.com>
ENETC ports can manage the MDIO bus via local register
interface. However there's also a centralized way
to manage the MDIO bus, via the MDIO PCIe endpoint
device integrated by the same root complex that also
integrates the ENETC ports (eth controllers).
Depending on board design and use case, centralized
access to MDIO may be better than using local ENETC
port registers. For instance, on the LS1028A QDS board
where MDIO muxing is requiered. Also, the LS1028A on-chip
switch doesn't have a local MDIO register interface.
The current patch registers the above PCIe enpoint as a
separate MDIO bus and provides a driver for it by re-using
the code used for local MDIO access. It also allows the
ENETC port PHYs to be managed by this driver if the local
"mdio" node is missing from the ENETC port node.
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
.../net/ethernet/freescale/enetc/enetc_mdio.c | 90 +++++++++++++++++++
.../net/ethernet/freescale/enetc/enetc_pf.c | 5 +-
2 files changed, 94 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
index 77b9cd10ba2b..efa8a29f463d 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
@@ -197,3 +197,93 @@ void enetc_mdio_remove(struct enetc_pf *pf)
mdiobus_free(pf->mdio);
}
}
+
+#define ENETC_MDIO_DEV_ID 0xee01
+#define ENETC_MDIO_DEV_NAME "FSL PCIe IE Central MDIO"
+#define ENETC_MDIO_BUS_NAME ENETC_MDIO_DEV_NAME " Bus"
+#define ENETC_MDIO_DRV_NAME ENETC_MDIO_DEV_NAME " driver"
+#define ENETC_MDIO_DRV_ID "fsl_enetc_mdio"
+
+static int enetc_pci_mdio_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+{
+ struct device *dev = &pdev->dev;
+ struct mii_bus *bus;
+ int err;
+
+ bus = mdiobus_alloc_size(sizeof(u32 *));
+ if (!bus)
+ return -ENOMEM;
+
+ bus->name = ENETC_MDIO_BUS_NAME;
+ bus->read = enetc_mdio_read;
+ bus->write = enetc_mdio_write;
+ bus->parent = dev;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
+
+ pcie_flr(pdev);
+ err = pci_enable_device_mem(pdev);
+ if (err) {
+ dev_err(dev, "device enable failed\n");
+ return err;
+ }
+
+ err = pci_request_mem_regions(pdev, ENETC_MDIO_DRV_ID);
+ if (err) {
+ dev_err(dev, "pci_request_regions failed\n");
+ goto err_pci_mem_reg;
+ }
+
+ bus->priv = pci_iomap_range(pdev, 0, ENETC_MDIO_REG_OFFSET, 0);
+ if (!bus->priv) {
+ err = -ENXIO;
+ dev_err(dev, "ioremap failed\n");
+ goto err_ioremap;
+ }
+
+ err = of_mdiobus_register(bus, dev->of_node);
+ if (err)
+ goto err_mdiobus_reg;
+
+ pci_set_drvdata(pdev, bus);
+
+ return 0;
+
+err_mdiobus_reg:
+ iounmap(bus->priv);
+err_ioremap:
+ pci_release_mem_regions(pdev);
+err_pci_mem_reg:
+ pci_disable_device(pdev);
+
+ return err;
+}
+
+static void enetc_pci_mdio_remove(struct pci_dev *pdev)
+{
+ struct mii_bus *bus = pci_get_drvdata(pdev);
+
+ mdiobus_unregister(bus);
+ iounmap(bus->priv);
+ mdiobus_free(bus);
+
+ pci_release_mem_regions(pdev);
+ pci_disable_device(pdev);
+}
+
+static const struct pci_device_id enetc_pci_mdio_id_table[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, ENETC_MDIO_DEV_ID) },
+ { 0, } /* End of table. */
+};
+MODULE_DEVICE_TABLE(pci, enetc_mdio_id_table);
+
+static struct pci_driver enetc_pci_mdio_driver = {
+ .name = ENETC_MDIO_DRV_ID,
+ .id_table = enetc_pci_mdio_id_table,
+ .probe = enetc_pci_mdio_probe,
+ .remove = enetc_pci_mdio_remove,
+};
+module_pci_driver(enetc_pci_mdio_driver);
+
+MODULE_DESCRIPTION(ENETC_MDIO_DRV_NAME);
+MODULE_LICENSE("Dual BSD/GPL");
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index 258b3cb38a6f..7d6513ff8507 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -750,6 +750,7 @@ static int enetc_of_get_phy(struct enetc_ndev_priv *priv)
{
struct enetc_pf *pf = enetc_si_priv(priv->si);
struct device_node *np = priv->dev->of_node;
+ struct device_node *mdio_np;
int err;
if (!np) {
@@ -773,7 +774,9 @@ static int enetc_of_get_phy(struct enetc_ndev_priv *priv)
priv->phy_node = of_node_get(np);
}
- if (!of_phy_is_fixed_link(np)) {
+ mdio_np = of_get_child_by_name(np, "mdio");
+ if (mdio_np) {
+ of_node_put(mdio_np);
err = enetc_mdio_probe(pf);
if (err) {
of_node_put(priv->phy_node);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 2/3] dt-bindings: net: fsl: enetc: Add bindings for the central MDIO PCIe endpoint
From: Claudiu Manoil @ 2019-07-23 15:15 UTC (permalink / raw)
To: David S . Miller
Cc: Rob Herring, Li Yang, alexandru.marginean, netdev, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1563894955-545-1-git-send-email-claudiu.manoil@nxp.com>
The on-chip PCIe root complex that integrates the ENETC ethernet
controllers also integrates a PCIe enpoint for the MDIO controller
provinding for cetralized control of the ENETC mdio bus.
Add bindings for this "central" MDIO Integrated PCIe Endpoit.
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
.../devicetree/bindings/net/fsl-enetc.txt | 42 +++++++++++++++++--
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/fsl-enetc.txt b/Documentation/devicetree/bindings/net/fsl-enetc.txt
index 25fc687419db..c090f6df7a39 100644
--- a/Documentation/devicetree/bindings/net/fsl-enetc.txt
+++ b/Documentation/devicetree/bindings/net/fsl-enetc.txt
@@ -11,7 +11,9 @@ Required properties:
to parent node bindings.
- compatible : Should be "fsl,enetc".
-1) The ENETC external port is connected to a MDIO configurable phy:
+1. The ENETC external port is connected to a MDIO configurable phy
+
+1.1. Using the local ENETC Port MDIO interface
In this case, the ENETC node should include a "mdio" sub-node
that in turn should contain the "ethernet-phy" node describing the
@@ -47,8 +49,42 @@ Example:
};
};
-2) The ENETC port is an internal port or has a fixed-link external
-connection:
+1.2. Using the central MDIO PCIe enpoint device
+
+In this case, the mdio node should be defined as another PCIe
+endpoint node, at the same level with the ENETC port nodes.
+
+Required properties:
+
+- reg : Specifies PCIe Device Number and Function
+ Number of the ENETC endpoint device, according
+ to parent node bindings.
+- compatible : Should be "fsl,enetc-mdio".
+
+The remaining required mdio bus properties are standard, their bindings
+already defined in Documentation/devicetree/bindings/net/mdio.txt.
+
+Example:
+
+ ethernet@0,0 {
+ compatible = "fsl,enetc";
+ reg = <0x000000 0 0 0 0>;
+ phy-handle = <&sgmii_phy0>;
+ phy-connection-type = "sgmii";
+ };
+
+ mdio@0,3 {
+ compatible = "fsl,enetc-mdio";
+ reg = <0x000300 0 0 0 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ sgmii_phy0: ethernet-phy@2 {
+ reg = <0x2>;
+ };
+ };
+
+2. The ENETC port is an internal port or has a fixed-link external
+connection
In this case, the ENETC port node defines a fixed link connection,
as specified by Documentation/devicetree/bindings/net/fixed-link.txt.
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 3/3] arm64: dts: ls1028a: Enable eth port1 on the ls1028a QDS board
From: Claudiu Manoil @ 2019-07-23 15:15 UTC (permalink / raw)
To: David S . Miller
Cc: Rob Herring, Li Yang, alexandru.marginean, netdev, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1563894955-545-1-git-send-email-claudiu.manoil@nxp.com>
LS1028a has one Ethernet management interface. On the QDS board, the
MDIO signals are multiplexed to either on-board AR8035 PHY device or
to 4 PCIe slots allowing for SGMII cards.
To enable the Ethernet ENETC Port 1, which can only be connected to a
RGMII PHY, the multiplexer needs to be configured to route the MDIO to
the AR8035 PHY. The MDIO/MDC routing is controlled by bits 7:4 of FPGA
board config register 0x54, and value 0 selects the on-board RGMII PHY.
The FPGA board config registers are accessible on the i2c bus, at address
0x66.
The PF3 MDIO PCIe integrated endpoint device allows for centralized access
to the MDIO bus. Add the corresponding devicetree node and set it to be
the MDIO bus parent.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
.../boot/dts/freescale/fsl-ls1028a-qds.dts | 40 +++++++++++++++++++
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 +++
2 files changed, 46 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
index de6ef39f3118..663c4b728c07 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
@@ -85,6 +85,26 @@
system-clock-frequency = <25000000>;
};
};
+
+ mdio-mux {
+ compatible = "mdio-mux-multiplexer";
+ mux-controls = <&mux 0>;
+ mdio-parent-bus = <&enetc_mdio_pf3>;
+ #address-cells=<1>;
+ #size-cells = <0>;
+
+ /* on-board RGMII PHY */
+ mdio@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ qds_phy1: ethernet-phy@5 {
+ /* Atheros 8035 */
+ reg = <5>;
+ };
+ };
+ };
};
&duart0 {
@@ -164,6 +184,26 @@
};
};
};
+
+ fpga@66 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,ls1028aqds-fpga", "fsl,fpga-qixis-i2c",
+ "simple-mfd";
+ reg = <0x66>;
+
+ mux: mux-controller {
+ compatible = "reg-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x54 0xf0>; /* 0: reg 0x54, bits 7:4 */
+ };
+ };
+
+};
+
+&enetc_port1 {
+ phy-handle = <&qds_phy1>;
+ phy-connection-type = "rgmii-id";
};
&sai1 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 7975519b4f56..de71153fda00 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -536,6 +536,12 @@
compatible = "fsl,enetc";
reg = <0x000100 0 0 0 0>;
};
+ enetc_mdio_pf3: mdio@0,3 {
+ compatible = "fsl,enetc-mdio";
+ reg = <0x000300 0 0 0 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
ethernet@0,4 {
compatible = "fsl,enetc-ptp";
reg = <0x000400 0 0 0 0>;
--
2.17.1
^ permalink raw reply related
* [RESEND V2 0/2] Add DesignWare IP support to simple reset
From: Luis Oliveira @ 2019-07-23 15:17 UTC (permalink / raw)
To: p.zabel, robh+dt, mark.rutland, linux-kernel, devicetree
Cc: Joao.Pinto, Luis Oliveira
This patch series adds a reset-simple compatible string for DesignWare
IPs allowing active high and low resets inputs.
Also adds the corresponding documentation.
Gustavo Pimentel (1):
reset: Add DesignWare IP support to simple reset
Luis Oliveira (1):
dt-bindings: Document the DesignWare IP reset bindings
.../devicetree/bindings/reset/snps,dw-reset.txt | 30 ++++++++++++++++++++++
drivers/reset/Kconfig | 2 +-
drivers/reset/reset-simple.c | 3 +++
3 files changed, 34 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/reset/snps,dw-reset.txt
--
2.7.4
^ permalink raw reply
* [RESEND V2 1/2] dt-bindings: Document the DesignWare IP reset bindings
From: Luis Oliveira @ 2019-07-23 15:17 UTC (permalink / raw)
To: p.zabel, robh+dt, mark.rutland, linux-kernel, devicetree
Cc: Joao.Pinto, Luis Oliveira, Gustavo Pimentel
In-Reply-To: <1563895048-30038-1-git-send-email-luis.oliveira@synopsys.com>
This adds documentation of device tree bindings for the
DesignWare IP reset controller.
Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Signed-off-by: Luis Oliveira <luis.oliveira@synopsys.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changelog
-no changes
.../devicetree/bindings/reset/snps,dw-reset.txt | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/snps,dw-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/snps,dw-reset.txt b/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
new file mode 100644
index 0000000..f94f911
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
@@ -0,0 +1,30 @@
+Synopsys DesignWare Reset controller
+=======================================
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+
+- compatible: should be one of the following.
+ "snps,dw-high-reset" - for active high configuration
+ "snps,dw-low-reset" - for active low configuration
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #reset-cells: must be 1.
+
+example:
+
+ dw_rst_1: reset-controller@0000 {
+ compatible = "snps,dw-high-reset";
+ reg = <0x0000 0x4>;
+ #reset-cells = <1>;
+ };
+
+ dw_rst_2: reset-controller@1000 {i
+ compatible = "snps,dw-low-reset";
+ reg = <0x1000 0x8>;
+ #reset-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related
* [RESEND V2 2/2] reset: Add DesignWare IP support to simple reset
From: Luis Oliveira @ 2019-07-23 15:17 UTC (permalink / raw)
To: p.zabel, robh+dt, mark.rutland, linux-kernel, devicetree
Cc: Joao.Pinto, Gustavo Pimentel, Luis Oliveira
In-Reply-To: <1563895048-30038-1-git-send-email-luis.oliveira@synopsys.com>
From: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
The reset-simple driver can be now used on DesignWare IPs by
default by selecting the following compatible strings:
- snps,dw-high-reset for active high resets inputs
- snps,dw-low-reset for active low resets inputs
Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Signed-off-by: Luis Oliveira <luis.oliveira@synopsys.com>
---
Changelog
-no changes
drivers/reset/Kconfig | 2 +-
drivers/reset/reset-simple.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 2c8c23d..2ee69f2 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -117,7 +117,7 @@ config RESET_QCOM_PDC
config RESET_SIMPLE
bool "Simple Reset Controller Driver" if COMPILE_TEST
- default ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || ARCH_ZX || ARCH_ASPEED
+ default ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || ARCH_ZX || ARCH_ASPEED || ARC
help
This enables a simple reset controller driver for reset lines that
that can be asserted and deasserted by toggling bits in a contiguous,
diff --git a/drivers/reset/reset-simple.c b/drivers/reset/reset-simple.c
index 77fbba3..79e73be 100644
--- a/drivers/reset/reset-simple.c
+++ b/drivers/reset/reset-simple.c
@@ -129,6 +129,9 @@ static const struct of_device_id reset_simple_dt_ids[] = {
.data = &reset_simple_active_low },
{ .compatible = "aspeed,ast2400-lpc-reset" },
{ .compatible = "aspeed,ast2500-lpc-reset" },
+ { .compatible = "snps,dw-high-reset" },
+ { .compatible = "snps,dw-low-reset",
+ .data = &reset_simple_active_low },
{ /* sentinel */ },
};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 0/6] video: ssd1307fb: Support more displays
From: Bartlomiej Zolnierkiewicz @ 2019-07-23 15:38 UTC (permalink / raw)
To: Marko Kohtala
Cc: Mark Rutland, devicetree, linux-fbdev, Michal Vokáč,
David Airlie, dri-devel, Rob Herring
In-Reply-To: <20190618074111.9309-1-marko.kohtala@okoko.fi>
On 6/18/19 9:41 AM, Marko Kohtala wrote:
> The kernel driver for ssd1307fb did not allow for all proper
> initialization for a Densitron 128x36 display. The trend in the driver
> has been to add devicetree properties for the controller initialization
> and these patches continue on that trend.
>
> There also were some sparse and Coccinelle errors.
>
> A small bug causing scrolling on display updates with nonzero page_offset
> was a bit surprising. It would seem the driver has only been used with
> page_offset set to zero. Bug has been there since commit
> 301bc0675b677a98475187050d56cd2b39ff0acf ("video: ssd1307fb: Make use of
> horizontal addressing mode").
>
> Marko Kohtala (6):
> video: ssd1307fb: Use screen_buffer instead of screen_base
> video: ssd1307fb: Remove unneeded semicolons
> video: ssd1307fb: Start page range at page_offset
> video: ssd1307fb: Handle width and height that are not multiple of 8
> dt-bindings: display: ssd1307fb: Add initialization properties
> video: ssd1307fb: Add devicetree configuration of display setup
>
> .../devicetree/bindings/display/ssd1307fb.txt | 10 ++
> drivers/video/fbdev/ssd1307fb.c | 130 ++++++++++++------
> 2 files changed, 101 insertions(+), 39 deletions(-)
Patch series queued for v5.4, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 02/10] iio: document bindings for mounting matrices
From: Andy Shevchenko @ 2019-07-23 15:39 UTC (permalink / raw)
To: Linus Walleij
Cc: H. Nikolaus Schaller, Jonathan Cameron, Rob Herring, Mark Rutland,
Charles Keepax, Song Qiang, Jean-Baptiste Maneyrol, Martin Kelly,
Jonathan Marek, Brian Masney, Stephan Gerhold,
Discussions about the Letux Kernel, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, linux-iio,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kerne
In-Reply-To: <CACRpkdZ5Z9VY457Fywt6X=K5XONgiPVcwbwSkwL_U+GCqZ+u5g@mail.gmail.com>
On Tue, Jul 23, 2019 at 09:42:59AM +0200, Linus Walleij wrote:
> On Thu, Feb 21, 2019 at 6:03 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:
> > From: Linus Walleij <linus.walleij@linaro.org>
>
> It is fair for you to change authorship to yourself at this point.
> Just keeping my Signed-off-by is sufficient.
...or Co-developed-by: can be used.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: irq: Convert Allwinner IRQ Controller to a schema
From: Rob Herring @ 2019-07-23 16:14 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Jason Cooper, maz, Chen-Yu Tsai,
Thomas Gleixner, Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190723132658.5068-1-maxime.ripard@bootlin.com>
On Tue, Jul 23, 2019 at 7:27 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> The Allwinner SoCs have an interrupt controller supported in Linux, with a
> matching Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a YAML schemas.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../allwinner,sun4i-a10-ic.yaml | 49 +++++++++++++++++++
> .../allwinner,sun4i-ic.txt | 20 --------
> 2 files changed, 49 insertions(+), 20 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml
> delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml
> new file mode 100644
> index 000000000000..806cf4770f75
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml
> @@ -0,0 +1,49 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/interrupt-controller/allwinner,sun4i-a10-ic.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Allwinner A10 Interrupt Controller Device Tree Bindings
> +
> +maintainers:
> + - Chen-Yu Tsai <wens@csie.org>
> + - Maxime Ripard <maxime.ripard@bootlin.com>
> +
> +allOf:
> + - $ref: /schemas/interrupt-controller.yaml#
> +
> +properties:
> + "#interrupt-cells":
> + const: 1
> +
> + compatible:
> + enum:
> + - allwinner,sun4i-a10-ic
> + - allwinner,suniv-f1c100s-ic
> +
> + reg:
> + maxItems: 1
> +
> + interrupt-controller: true
> +
> +required:
> + - "#interrupt-cells"
> + - compatible
> + - reg
> + - interrupt-controller
> +
> +# FIXME: We should set it, but it would report all the generic
> +# properties as additional properties.
> +# additionalProperties: false
Looks to me like you could enable this.
BTW, I think the fix is going to be just the new
'unevaluatedProperties: false'. We could start putting that in as
unknown keys are ignored (though the meta-schema will need an update
to allow it).
> +
> +examples:
> + - |
> + intc: interrupt-controller {
unit-address needed.
I need to figure out how to enable dtc warnings by default on the examples...
> + compatible = "allwinner,sun4i-a10-ic";
> + reg = <0x01c20400 0x400>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> +
> +...
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: irq: Convert Allwinner NMI Controller to a schema
From: Rob Herring @ 2019-07-23 16:32 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Jason Cooper, maz, Chen-Yu Tsai,
Thomas Gleixner, Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190723132658.5068-2-maxime.ripard@bootlin.com>
On Tue, Jul 23, 2019 at 7:27 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> The Allwinner SoCs have an interrupt controller called NMI supported in
> Linux, with a matching Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a YAML schemas.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../allwinner,sun7i-a20-sc-nmi.yaml | 83 +++++++++++++++++++
> .../allwinner,sunxi-nmi.txt | 29 -------
> 2 files changed, 83 insertions(+), 29 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
> delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
> new file mode 100644
> index 000000000000..cb8077b0c8dd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
> @@ -0,0 +1,83 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Allwinner A20 Non-Maskable Interrupt Controller Device Tree Bindings
> +
> +maintainers:
> + - Chen-Yu Tsai <wens@csie.org>
> + - Maxime Ripard <maxime.ripard@bootlin.com>
> +
> +allOf:
> + - $ref: /schemas/interrupt-controller.yaml#
> +
> +select:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - allwinner,sun6i-a31-r-intc
> + - allwinner,sun7i-a20-sc-nmi
> + - allwinner,sun9i-a80-sc-nmi
This should have all the possible compatibles in case all are not listed.
> +
> + # Deprecated
> + - allwinner,sun6i-a31-sc-nmi
I know we already did things this way before, but perhaps this should
be listed below with the 'deprecated' property. The tools can include
it in select, but then remove it from compatible property.
> +
> + required:
> + - compatible
> +
> +properties:
> + "#interrupt-cells":
> + const: 2
> + description:
> + The first cell is the IRQ number, the second cell the trigger
> + type as defined in interrupt.txt in this directory.
> +
> + compatible:
> + oneOf:
> + - const: allwinner,sun6i-a31-r-intc
> + - const: allwinner,sun7i-a20-sc-nmi
> + - items:
> + - const: allwinner,sun8i-a83t-r-intc
> + - const: allwinner,sun6i-a31-r-intc
> + - const: allwinner,sun9i-a80-sc-nmi
> + - items:
> + - const: allwinner,sun50i-a64-r-intc
> + - const: allwinner,sun6i-a31-r-intc
> + - items:
> + - const: allwinner,sun50i-h6-r-intc
> + - const: allwinner,sun6i-a31-r-intc
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + interrupt-controller: true
> +
> +required:
> + - "#interrupt-cells"
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-controller
> +
> +# FIXME: We should set it, but it would report all the generic
> +# properties as additional properties.
> +# additionalProperties: false
> +
> +examples:
> + - |
> + interrupt-controller@1c00030 {
> + compatible = "allwinner,sun7i-a20-sc-nmi";
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + reg = <0x01c00030 0x0c>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 0 4>;
> + };
> +
> +...
^ permalink raw reply
* Re: [PATCH] dt-bindings: Add pxe1610 as a trivial device
From: Vijay Khemka @ 2019-07-23 17:13 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, Jiri Kosina, Guenter Roeck, Herbert Xu,
Patrick Venture, Ard Biesheuvel, Anson Huang, Jeremy Gebben,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
openbmc @ lists . ozlabs . org, Joel Stanley,
linux-aspeed@lists.ozlabs.org, Sai Dasari
In-Reply-To: <CAL_Jsq+Kw0TFW_v54Y2QHcChqpNDYhFyCSO5Cj-be9yLSCq-Pw@mail.gmail.com>
On 7/23/19, 7:53 AM, "Rob Herring" <robh+dt@kernel.org> wrote:
On Tue, Jul 23, 2019 at 8:50 AM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Mon, Jul 22, 2019 at 6:46 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
> >
> > The pxe1610 is a voltage regulator from Infineon. It also supports
> > other VRs pxe1110 and pxm1310 from Infineon.
What happened to the other compatibles? S/w doesn't need to know the
differences?
As far as driver is concerned, it doesn't need to know differences.
> >
> > Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> > ---
> > Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
> > index 2e742d399e87..1be648828a31 100644
> > --- a/Documentation/devicetree/bindings/trivial-devices.yaml
> > +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
> > @@ -99,6 +99,8 @@ properties:
> > # Infineon IR38064 Voltage Regulator
> > - infineon,ir38064
> > # Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz)
> > + - infineon,pxe1610
> > + # Infineon PXE1610, PXE1110 and PXM1310 Voltage Regulators
>
> The comment goes above the entry.
>
> > - infineon,slb9635tt
> > # Infineon SLB9645 I2C TPM (new protocol, max 400khz)
> > - infineon,slb9645tt
> > --
> > 2.17.1
> >
^ permalink raw reply
* [PATCH v2] dt-bindings: Add pxe1610 as a trivial device
From: Vijay Khemka @ 2019-07-23 17:19 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Jiri Kosina, Guenter Roeck, Herbert Xu,
Patrick Venture, Ard Biesheuvel, Vijay Khemka, Anson Huang,
Jeremy Gebben, devicetree, linux-kernel
Cc: openbmc @ lists . ozlabs . org, joel, linux-aspeed, sdasari
The pxe1610 is a voltage regulator from Infineon. It also supports
other VRs pxe1110 and pxm1310 from Infineon.
Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
---
In V2: comment was put wrongly after device so corrected.
Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index 2e742d399e87..a3dd83d4f429 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -98,6 +98,8 @@ properties:
- gmt,g751
# Infineon IR38064 Voltage Regulator
- infineon,ir38064
+ # Infineon PXE1610, PXE1110 and PXM1310 Voltage Regulators
+ - infineon,pxe1610
# Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz)
- infineon,slb9635tt
# Infineon SLB9645 I2C TPM (new protocol, max 400khz)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 2/2] ARM: dts: aspeed: tiogapass: Add Riser card
From: Vijay Khemka @ 2019-07-23 17:22 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck, Rob Herring, Mark Rutland,
Joel Stanley, Andrew Jeffery, linux-hwmon@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org
Cc: openbmc @ lists . ozlabs . org, Sai Dasari
In-Reply-To: <20190722192451.1947348-3-vijaykhemka@fb.com>
Team,
This patch also needs review. I separated first patch with v2 and that was acked. Please review this as well.
Regards
-Vijay
On 7/22/19, 12:41 PM, "Vijay Khemka" <vijaykhemka@fb.com> wrote:
Added i2c mux for riser card and multiple ava card and its sensor
components for Facebook Tiogapass platform
Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
---
.../dts/aspeed-bmc-facebook-tiogapass.dts | 230 ++++++++++++++++++
1 file changed, 230 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
index b7783833a58c..8d0bcb3cd419 100644
--- a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
@@ -12,6 +12,27 @@
aliases {
serial0 = &uart1;
serial4 = &uart5;
+
+ /*
+ * Hardcode the bus number of i2c switches' channels to
+ * avoid breaking the legacy applications.
+ */
+ i2c16 = &imux16;
+ i2c17 = &imux17;
+ i2c18 = &imux18;
+ i2c19 = &imux19;
+ i2c20 = &imux20;
+ i2c21 = &imux21;
+ i2c22 = &imux22;
+ i2c23 = &imux23;
+ i2c24 = &imux24;
+ i2c25 = &imux25;
+ i2c26 = &imux26;
+ i2c27 = &imux27;
+ i2c28 = &imux28;
+ i2c29 = &imux29;
+ i2c30 = &imux30;
+ i2c31 = &imux31;
};
chosen {
stdout-path = &uart5;
@@ -124,6 +145,215 @@
&i2c1 {
status = "okay";
//X24 Riser
+ i2c-switch@71 {
+ compatible = "nxp,pca9544";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x71>;
+
+ imux16: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ ina219@45 {
+ compatible = "ti,ina219";
+ reg = <0x45>;
+ };
+
+ tmp75@48 {
+ compatible = "ti,tmp75";
+ reg = <0x48>;
+ };
+
+ tmp421@49 {
+ compatible = "ti,tmp75";
+ reg = <0x49>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ pagesize = <32>;
+ };
+
+ i2c-switch@73 {
+ compatible = "nxp,pca9546";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x73>;
+
+ imux20: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux21: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux22: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux23: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ };
+
+ };
+
+ imux17: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ ina219@45 {
+ compatible = "ti,ina219";
+ reg = <0x45>;
+ };
+
+ tmp421@48 {
+ compatible = "ti,tmp75";
+ reg = <0x48>;
+ };
+
+ tmp421@49 {
+ compatible = "ti,tmp75";
+ reg = <0x49>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ pagesize = <32>;
+ };
+
+ i2c-switch@73 {
+ compatible = "nxp,pca9546";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x73>;
+
+ imux24: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux25: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux26: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux27: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ };
+
+ };
+
+ imux18: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+
+ ina219@45 {
+ compatible = "ti,ina219";
+ reg = <0x45>;
+ };
+
+ tmp421@48 {
+ compatible = "ti,tmp75";
+ reg = <0x48>;
+ };
+
+ tmp421@49 {
+ compatible = "ti,tmp75";
+ reg = <0x49>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ pagesize = <32>;
+ };
+
+ i2c-switch@73 {
+ compatible = "nxp,pca9546";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x73>;
+
+ imux28: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux29: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux30: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux31: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ };
+
+ };
+
+ imux19: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ i2c-switch@40 {
+ compatible = "ti,ina219";
+ reg = <0x40>;
+ };
+
+ i2c-switch@41 {
+ compatible = "ti,ina219";
+ reg = <0x41>;
+ };
+
+ i2c-switch@45 {
+ compatible = "ti,ina219";
+ reg = <0x45>;
+ };
+
+ };
+
+ };
};
&i2c2 {
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] extcon: fsa9480: Support the FSA880 variant
From: Linus Walleij @ 2019-07-23 17:43 UTC (permalink / raw)
To: MyungJoo Ham, Chanwoo Choi
Cc: linux-kernel, linux-gpio, Mike Lockwood, Linus Walleij,
devicetree
The older compatible variant of this chip is called FSA880
and works the same way, if we need some quirks in the future,
it is good to let it have its own compatible string.
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt | 4 +++-
drivers/extcon/extcon-fsa9480.c | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt b/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
index d592c21245f2..624bd76f468e 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
+++ b/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
@@ -5,7 +5,9 @@ controlled using I2C and enables USB data, stereo and mono audio, video,
microphone, and UART data to use a common connector port.
Required properties:
- - compatible : Must be "fcs,fsa9480"
+ - compatible : Must be one of
+ "fcs,fsa9480"
+ "fcs,fsa880"
- reg : Specifies i2c slave address. Must be 0x25.
- interrupts : Should contain one entry specifying interrupt signal of
interrupt parent to which interrupt pin of the chip is connected.
diff --git a/drivers/extcon/extcon-fsa9480.c b/drivers/extcon/extcon-fsa9480.c
index 350fb34abfa0..8405512f5199 100644
--- a/drivers/extcon/extcon-fsa9480.c
+++ b/drivers/extcon/extcon-fsa9480.c
@@ -363,6 +363,7 @@ MODULE_DEVICE_TABLE(i2c, fsa9480_id);
static const struct of_device_id fsa9480_of_match[] = {
{ .compatible = "fcs,fsa9480", },
+ { .compatible = "fcs,fsa880", },
{ },
};
MODULE_DEVICE_TABLE(of, fsa9480_of_match);
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 0/5] Add support for WD MyCloud EX2 Ultra (+ versatile UART-based restart/poweroff drivers)
From: Evgeny Kolesnikov @ 2019-07-23 17:48 UTC (permalink / raw)
To: Andrew Lunn
Cc: Mark Rutland, Jason Cooper, linux-pm, Gregory Clement,
Sebastian Reichel, linux-kernel, devicetree, Rob Herring,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20190723015631.GI8972@lunn.ch>
On 23/07/2019 03:56, Andrew Lunn wrote:
> On Mon, Jul 22, 2019 at 09:53:00PM +0200, Evgeny Kolesnikov wrote:
>>
>> The difference between uart-poweroff and qnap-poweroff is small, but important:
>> uart-poweroff is able to send to an MCU a command of arbitrary length, and the command
>> itself is defined in a DTS file for a specific device/board, thus making this driver
>> applicable to wider range of devices.
>
> There is a lot of replicated code here, and in the original
> qnap-poweroff.c driver. Please consolidate it by extending the current
> driver. It should be easy to add a new compatible string, and turn
> power_off_cfg.cmd into an array.
Hi, Andrew.
I've considered extending qnap driver, but I have some doubts about this
approach.
First of all there is only a poweroff counterpart. As there is no
qnap-restart driver, what should I do with uart-restart? Is it OK to
have xxx-restart-poweroff driver (never saw anything like that)?
While I can add cmd as a parameter to qnap driver (having it converted
into an array) it should be optional as original qnap relies on two
hardcoded values for its devices. And having a non-qnap device with this
driver in DT without defined cmd would not make any sense. It feels
kinda ugly.
Wouldn't it be more fitting to have these two generic drivers and then
retire old qnap driver while moving everything that uses it to the new one?
Thanks for the review.
EK.
^ permalink raw reply
* Re: [PATCH 1/4] arm64: dts: ti: k3-am65-main: Add mailbox cluster nodes
From: Suman Anna @ 2019-07-23 17:50 UTC (permalink / raw)
To: Nishanth Menon; +Cc: Tero Kristo, devicetree, linux-arm-kernel
In-Reply-To: <20190723113540.xvhsrlbf66lr5aaq@kahuna>
Hi Nishanth,
On 7/23/19 6:35 AM, Nishanth Menon wrote:
> On 15:20-20190722, Suman Anna wrote:
>> The AM65x Main NavSS block contains a Mailbox IP instance with
>> multiple clusters. Each cluster is equivalent to an Mailbox IP
>> instance on OMAP platforms.
>>
>> Add all the Mailbox clusters as their own nodes under the MAIN
>> NavSS cbass_main_navss interconnect node instead of creating an
>> almost empty parent node for the new K3 mailbox IP and the clusters
>> as its child nodes. All these nodes are marked as disabled, and
>> they need to be enabled along with the appropriate child nodes
>> on a need basis.
>>
>> NOTE:
>> The NavSS only has a limited number of interrupts, so all the
>> interrupts generated by a Mailbox IP are not added by default.
>> Only the needed interrupts that are targeted towards the A53
>> GIC will need to be be added later on when some sub-mailbox
>> child nodes are added.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> ---
>> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 108 +++++++++++++++++++++++
>> 1 file changed, 108 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> index 8413e80f9d3a..0b3ea2a871ee 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> @@ -419,6 +419,114 @@
>> reg = <0x00 0x30e00000 0x00 0x1000>;
>> #hwlock-cells = <1>;
>> };
>> +
>> + mailbox0_cluster0: mailbox@31f80000 {
>> + compatible = "ti,am654-mailbox";
>> + reg = <0x00 0x31f80000 0x00 0x200>;
>> + #mbox-cells = <1>;
>> + ti,mbox-num-users = <4>;
>> + ti,mbox-num-fifos = <16>;
>> + status = "disabled";
>
> We don't use status="disabled" as default so far.
>
For the OMAP mailboxes, we do not want to enable just the cluster. A
cluster without any enabled sub-mailboxes or interrupts will fail the probe.
There are 12 clusters but we won't be enabling all clusters for the MPU
core running Linux. There are some clusters that are dedicated to
RTOS-to-RTOS IPC which we don't want to even probe on Linux. This patch
adds all the clusters, and the next patch enables only the clusters used
by Linux that have the proper sub-mailboxes and interrupts. Please see
the NOTE above for the reason why not all the 4 interrupts from each
cluster are added here.
regards
Suman
^ 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