* RE: [PATCH 1/2] dt-bindings: imx-ocotp: Add i.MX8MN compatible
From: Anson Huang @ 2019-08-06 5:59 UTC (permalink / raw)
To: srinivas.kandagatla@linaro.org, robh+dt@kernel.org,
mark.rutland@arm.com, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <20190711023714.16000-1-Anson.Huang@nxp.com>
Gentle Ping...
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Add compatible for i.MX8MN and add i.MX8MM/i.MX8MN to the description.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> index 96ffd06..904dadf 100644
> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> @@ -2,7 +2,7 @@ Freescale i.MX6 On-Chip OTP Controller (OCOTP) device
> tree bindings
>
> This binding represents the on-chip eFuse OTP controller found on
> i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX, i.MX6UL, i.MX6ULL/ULZ, i.MX6SLL, -
> i.MX7D/S, i.MX7ULP and i.MX8MQ SoCs.
> +i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM and i.MX8MN SoCs.
>
> Required properties:
> - compatible: should be one of
> @@ -16,6 +16,7 @@ Required properties:
> "fsl,imx7ulp-ocotp" (i.MX7ULP),
> "fsl,imx8mq-ocotp" (i.MX8MQ),
> "fsl,imx8mm-ocotp" (i.MX8MM),
> + "fsl,imx8mn-ocotp" (i.MX8MN),
> followed by "syscon".
> - #address-cells : Should be 1
> - #size-cells : Should be 1
> --
> 2.7.4
_______________________________________________
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 4/7] ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_*
From: Takashi Iwai @ 2019-08-06 6:00 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, Takashi Iwai,
linuxppc-dev, x86, linux-m68k, linux-kernel, iommu, Robin Murphy,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190806052949.GC13409@lst.de>
On Tue, 06 Aug 2019 07:29:49 +0200,
Christoph Hellwig wrote:
>
> On Mon, Aug 05, 2019 at 11:22:03AM +0200, Takashi Iwai wrote:
> > This won't work as expected, unfortunately. It's a bit tricky check,
> > since the driver may have its own mmap implementation via
> > substream->ops->mmap, and the dma_buffer.dev.dev might point to
> > another object depending on the dma_buffer.dev.type.
> >
> > So please replace with something like below:
>
> >From my gut feeling I'd reorder it a bit to make it more clear like
> this:
>
> http://git.infradead.org/users/hch/misc.git/commitdiff/958fccf54d00c16740522f818d23f9350498e911
>
> if this is fine it'll be in the next version, waiting for a little more
> feedback on the other patches.
Yes, the new one looks good.
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Thanks!
Takashi
_______________________________________________
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 V3] soc: imx-scu: Add SoC UID(unique identifier) support
From: Anson Huang @ 2019-08-06 6:04 UTC (permalink / raw)
To: Shawn Guo, Marco Felsch
Cc: Aisheng Dong, Abel Vesa, s.hauer@pengutronix.de,
linux-kernel@vger.kernel.org, dl-linux-imx, kernel@pengutronix.de,
festevam@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190718082216.GO3738@dragon>
Hi, Marco
Are you OK with this patch?
Thanks,
Anson.
> On Tue, Jul 02, 2019 at 03:45:45PM +0800, Anson.Huang@nxp.com wrote:
> > From: Anson Huang <Anson.Huang@nxp.com>
> >
> > Add i.MX SCU SoC's UID(unique identifier) support, user can read it
> > from sysfs:
> >
> > root@imx8qxpmek:~# cat /sys/devices/soc0/soc_uid
> > 7B64280B57AC1898
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
>
> @Marco, are you happy with it?
>
> Shawn
>
> > ---
> > Change since V2:
> > - The SCU FW API for getting UID does NOT have response, so we
> should set
> > imx_scu_call_rpc()'s 3rd parameter as false and still can check the
> returned
> > value, and comment is no needed any more.
> > ---
> > drivers/soc/imx/soc-imx-scu.c | 39
> > +++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/drivers/soc/imx/soc-imx-scu.c
> > b/drivers/soc/imx/soc-imx-scu.c index 676f612..50831eb 100644
> > --- a/drivers/soc/imx/soc-imx-scu.c
> > +++ b/drivers/soc/imx/soc-imx-scu.c
> > @@ -27,6 +27,40 @@ struct imx_sc_msg_misc_get_soc_id {
> > } data;
> > } __packed;
> >
> > +struct imx_sc_msg_misc_get_soc_uid {
> > + struct imx_sc_rpc_msg hdr;
> > + u32 uid_low;
> > + u32 uid_high;
> > +} __packed;
> > +
> > +static ssize_t soc_uid_show(struct device *dev,
> > + struct device_attribute *attr, char *buf) {
> > + struct imx_sc_msg_misc_get_soc_uid msg;
> > + struct imx_sc_rpc_msg *hdr = &msg.hdr;
> > + u64 soc_uid;
> > + int ret;
> > +
> > + hdr->ver = IMX_SC_RPC_VERSION;
> > + hdr->svc = IMX_SC_RPC_SVC_MISC;
> > + hdr->func = IMX_SC_MISC_FUNC_UNIQUE_ID;
> > + hdr->size = 1;
> > +
> > + ret = imx_scu_call_rpc(soc_ipc_handle, &msg, false);
> > + if (ret) {
> > + pr_err("%s: get soc uid failed, ret %d\n", __func__, ret);
> > + return ret;
> > + }
> > +
> > + soc_uid = msg.uid_high;
> > + soc_uid <<= 32;
> > + soc_uid |= msg.uid_low;
> > +
> > + return sprintf(buf, "%016llX\n", soc_uid); }
> > +
> > +static DEVICE_ATTR_RO(soc_uid);
> > +
> > static int imx_scu_soc_id(void)
> > {
> > struct imx_sc_msg_misc_get_soc_id msg; @@ -102,6 +136,11 @@
> static
> > int imx_scu_soc_probe(struct platform_device *pdev)
> > goto free_revision;
> > }
> >
> > + ret = device_create_file(soc_device_to_device(soc_dev),
> > + &dev_attr_soc_uid);
> > + if (ret)
> > + goto free_revision;
> > +
> > return 0;
> >
> > free_revision:
> > --
> > 2.7.4
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH v4 6/9] ASoC: sun4i-i2s: Add multi-lane functionality
From: Chen-Yu Tsai @ 2019-08-06 6:22 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Linux-ALSA, Andrea Venturi (pers), Maxime Ripard,
Christopher Obbard, Liam Girdwood, linux-kernel, Code Kipper,
linux-sunxi, Mark Brown, linux-arm-kernel
In-Reply-To: <1589203.0AjJVEASy3@jernej-laptop>
On Thu, Aug 1, 2019 at 1:32 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> Dne sreda, 31. julij 2019 ob 14:29:53 CEST je Maxime Ripard napisal(a):
> > On Tue, Jul 30, 2019 at 07:57:10PM +0200, Jernej Škrabec wrote:
> > > Dne torek, 04. junij 2019 ob 11:38:44 CEST je Code Kipper napisal(a):
> > > > On Tue, 4 Jun 2019 at 11:02, Christopher Obbard <chris@64studio.com>
> wrote:
> > > > > On Tue, 4 Jun 2019 at 09:43, Code Kipper <codekipper@gmail.com> wrote:
> > > > > > On Tue, 4 Jun 2019 at 09:58, Maxime Ripard
> > > > > > <maxime.ripard@bootlin.com>
> > >
> > > wrote:
> > > > > > > On Mon, Jun 03, 2019 at 07:47:32PM +0200, codekipper@gmail.com
> wrote:
> > > > > > > > From: Marcus Cooper <codekipper@gmail.com>
> > > > > > > >
> > > > > > > > The i2s block supports multi-lane i2s output however this
> > > > > > > > functionality
> > > > > > > > is only possible in earlier SoCs where the pins are exposed and
> > > > > > > > for
> > > > > > > > the i2s block used for HDMI audio on the later SoCs.
> > > > > > > >
> > > > > > > > To enable this functionality, an optional property has been
> > > > > > > > added to
> > > > > > > > the bindings.
> > > > > > > >
> > > > > > > > Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> > > > > > >
> > > > > > > I'd like to have Mark's input on this, but I'm really worried
> > > > > > > about
> > > > > > > the interaction with the proper TDM support.
> > > > > > >
> > > > > > > Our fundamental issue is that the controller can have up to 8
> > > > > > > channels, but either on 4 lines (instead of 1), or 8 channels on 1
> > > > > > > (like proper TDM) (or any combination between the two, but that
> > > > > > > should
> > > > > > > be pretty rare).
> > > > > >
> > > > > > I understand...maybe the TDM needs to be extended to support this to
> > > > > > consider channel mapping and multiple transfer lines. I was thinking
> > > > > > about the later when someone was requesting support on IIRC a while
> > > > > > ago, I thought masking might of been a solution. These can wait as
> > > > > > the
> > > > > > only consumer at the moment is LibreELEC and we can patch it there.
> > > > >
> > > > > Hi Marcus,
> > > > >
> > > > > FWIW, the TI McASP driver has support for TDM & (i think?) multiple
> > > > > transfer lines which are called serializers.
> > > > > Maybe this can help with inspiration?
> > > > > see
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tre
> > > > > e/s
> > > > > ound/soc/ti/davinci-mcasp.c sample DTS:
> > > > >
> > > > > &mcasp0 {
> > > > >
> > > > > #sound-dai-cells = <0>;
> > > > > status = "okay";
> > > > > pinctrl-names = "default";
> > > > > pinctrl-0 = <&mcasp0_pins>;
> > > > >
> > > > > op-mode = <0>;
> > > > > tdm-slots = <8>;
> > > > > serial-dir = <
> > > > >
> > > > > 2 0 1 0
> > > > > 0 0 0 0
> > > > > 0 0 0 0
> > > > > 0 0 0 0
> > > > > >
> > > > > >;
> > > > >
> > > > > tx-num-evt = <1>;
> > > > > rx-num-evt = <1>;
> > > > >
> > > > > };
> > > > >
> > > > > Cheers!
> > > >
> > > > Thanks, this looks good.
> > >
> > > I would really like to see this issue resolved, because HDMI audio support
> > > in mainline Linux for those SoCs is long overdue.
> > >
> > > However, there is a possibility to still add HDMI audio suport (stereo
> > > only) even if this issue is not completely solved. If we agree that
> > > configuration of channels would be solved with additional property as
> > > Christopher suggested, support for >2 channels can be left for a later
> > > time when support for that property would be implemented. Currently,
> > > stereo HDMI audio support can be added with a few patches.
> > >
> > > I think all I2S cores are really the same, no matter if internally
> > > connected to HDMI controller or routed to pins, so it would make sense to
> > > use same compatible for all of them. It's just that those I2S cores which
> > > are routed to pins can use only one lane and >2 channels can be used only
> > > in TDM mode of operation, if I understand this correctly.
> > >
> > > New property would have to be optional, so it's omission would result in
> > > same channel configuration as it is already present, to preserve
> > > compatibility with old device trees. And this mode is already sufficient
> > > for stereo HDMI audio support.
> >
> > Yeah, it looks like a good plan.
> >
> > > Side note: HDMI audio with current sun4i-i2s driver has a delay (about a
> > > second), supposedly because DW HDMI controller automatically generates CTS
> > > value based on I2S clock (auto CTS value generation is enabled per
> > > DesignWare recomendation for DW HDMI I2S interface).
> >
> > Is that a constant delay during the audio playback, or only at startup?
>
> I think it's just at startup, e.g. if you're watching movie, audio is in sync,
> it's just that first second or so is silent.
>
> >
> > > I2S driver from BSP Linux solves that by having I2S clock output
> > > enabled all the time. Should this be flagged with some additional
> > > property in DT?
> >
> > I'd say that if the codec has that requirement, then it should be
> > between the codec and the DAI, the DT doesn't really have anything to
> > do with this.
>
> Ok, but how to communicate that fact to I2S driver then? BSP driver solves
> that by using different compatible, but as I said before, I2S cores are not
> really different, so this seems wrong.
Maybe we could make the DW-HDMI I2S driver require the I2S clock be on all
the time? You wouldn't need any changes to the DT.
ChenYu
_______________________________________________
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] arm64: dts: allwinner: a64: Enable eMMC on A64-OLinuXino
From: Chen-Yu Tsai @ 2019-08-06 6:25 UTC (permalink / raw)
To: Martin Ayotte; +Cc: Maxime Ripard, Sunil Mohan Adapa, linux-arm-kernel
In-Reply-To: <1955D9AD572C4F57A2D66B15EB8CF79C@GirolesWin7>
On Mon, Aug 5, 2019 at 8:58 PM Martin Ayotte <martinayotte@gmail.com> wrote:
>
> Fine for me too.
>
> Thanks .
>
> -----Message d'origine-----
> De : Sunil Mohan Adapa [mailto:sunil@medhas.org]
> Envoyé : Monday, August 05, 2019 1:25 AM
> À : Chen-Yu Tsai
> Cc : Maxime Ripard; Martin Ayotte; linux-arm-kernel
> Objet : Re: [PATCH v2] arm64: dts: allwinner: a64: Enable eMMC on
> A64-OLinuXino
>
> On 04/08/19 8:33 pm, Chen-Yu Tsai wrote:
> > On Fri, Aug 2, 2019 at 2:47 AM Sunil Mohan Adapa <sunil@medhas.org> wrote:
> >>
> >> On 01/08/19 6:49 am, Martin Ayotte wrote:
> >>> If my SOB could help here, I don't mind since I've done the commit
> >>> more than a year ago for Armbian ...
> >>>
> >>> Signed-off-by: Martin Ayotte <martinayotte@gmai.com>
> >>> Tested-by: Martin Ayotte <martinayotte@gmai.com>
> >> gmai.com is likely a typo.
> >>
> >>> On Wed, Jul 31, 2019 at 10:42 PM Chen-Yu Tsai <wens@csie.org
> >>>
> >>>> Thanks. The patch looks good overall. The authorship is a little
> >>>> confusing though. If it was initially done by Martin (CC-ed), then
> >>>> he should be the author, and we should get his Signed-off-by if
> >>>> possible.
> >>
> >> Martin is indeed the original author of the patch. Thank you for
> reviewing.
> >
> > I'd like to apply this patch with Martin as the author, if that's OK with
> you
> > both?
>
> That is completely okay with me.
Applied for 5.4.
I reordered the tags so they make more sense:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/dt-for-5.4&id=0834887732df5af41b59b2e4d530fc1f5478965f
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv3 1/3] dt-bindings: pci: layerscape-pci: add compatible strings "fsl, ls1028a-pcie"
From: Xiaowei Bao @ 2019-08-06 6:15 UTC (permalink / raw)
To: bhelgaas, robh+dt, mark.rutland, shawnguo, leoyang.li, kishon,
lorenzo.pieralisi, arnd, gregkh, minghuan.Lian, mingkai.hu,
zhiqiang.hou, roy.zang, kstewart, pombredanne, shawn.lin,
linux-pci, devicetree, linux-kernel, linux-arm-kernel,
linuxppc-dev
Cc: Hou Zhiqiang, Xiaowei Bao
Add the PCIe compatible string for LS1028A
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
---
v2:
- no change.
v3:
- no change.
Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index e20ceaa..99a386e 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -21,6 +21,7 @@ Required properties:
"fsl,ls1046a-pcie"
"fsl,ls1043a-pcie"
"fsl,ls1012a-pcie"
+ "fsl,ls1028a-pcie"
EP mode:
"fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep"
- reg: base addresses and lengths of the PCIe controller register blocks.
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv3 3/3] PCI: layerscape: Add LS1028a support
From: Xiaowei Bao @ 2019-08-06 6:15 UTC (permalink / raw)
To: bhelgaas, robh+dt, mark.rutland, shawnguo, leoyang.li, kishon,
lorenzo.pieralisi, arnd, gregkh, minghuan.Lian, mingkai.hu,
zhiqiang.hou, roy.zang, kstewart, pombredanne, shawn.lin,
linux-pci, devicetree, linux-kernel, linux-arm-kernel,
linuxppc-dev
Cc: Hou Zhiqiang, Xiaowei Bao
In-Reply-To: <20190806061553.19934-1-xiaowei.bao@nxp.com>
Add support for the LS1028a PCIe controller.
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
---
v2:
- no change.
v3:
- Reuse the ls2088 driver data structurt.
drivers/pci/controller/dwc/pci-layerscape.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index 3a5fa26..f24f79a 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -263,6 +263,7 @@ static const struct ls_pcie_drvdata ls2088_drvdata = {
static const struct of_device_id ls_pcie_of_match[] = {
{ .compatible = "fsl,ls1012a-pcie", .data = &ls1046_drvdata },
{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
+ { .compatible = "fsl,ls1028a-pcie", .data = &ls2088_drvdata },
{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
{ .compatible = "fsl,ls1046a-pcie", .data = &ls1046_drvdata },
{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv3 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
From: Xiaowei Bao @ 2019-08-06 6:15 UTC (permalink / raw)
To: bhelgaas, robh+dt, mark.rutland, shawnguo, leoyang.li, kishon,
lorenzo.pieralisi, arnd, gregkh, minghuan.Lian, mingkai.hu,
zhiqiang.hou, roy.zang, kstewart, pombredanne, shawn.lin,
linux-pci, devicetree, linux-kernel, linux-arm-kernel,
linuxppc-dev
Cc: Hou Zhiqiang, Xiaowei Bao
In-Reply-To: <20190806061553.19934-1-xiaowei.bao@nxp.com>
LS1028a implements 2 PCIe 3.0 controllers.
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
---
v2:
- Fix up the legacy INTx allocate failed issue.
v3:
- no change.
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 52 ++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index aef5b06..0b542ed 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -503,6 +503,58 @@
status = "disabled";
};
+ pcie@3400000 {
+ compatible = "fsl,ls1028a-pcie";
+ reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */
+ 0x80 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
+ <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>; /* aer interrupt */
+ interrupt-names = "pme", "aer";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ num-lanes = <4>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000 /* downstream I/O */
+ 0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ msi-parent = <&its>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ pcie@3500000 {
+ compatible = "fsl,ls1028a-pcie";
+ reg = <0x00 0x03500000 0x0 0x00100000 /* controller registers */
+ 0x88 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "pme", "aer";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ num-lanes = <4>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x81000000 0x0 0x00000000 0x88 0x00010000 0x0 0x00010000 /* downstream I/O */
+ 0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ msi-parent = <&its>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
pcie@1f0000000 { /* Integrated Endpoint Root Complex */
compatible = "pci-host-ecam-generic";
reg = <0x01 0xf0000000 0x0 0x100000>;
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/2] KVM: arm64: Don't write junk to sysregs on reset
From: Zenghui Yu @ 2019-08-06 6:29 UTC (permalink / raw)
To: Marc Zyngier, kvm, kvmarm, linux-arm-kernel
Cc: Andrew Jones, James Morse, Julien Thierry, Suzuki K Poulose
In-Reply-To: <20190805121555.130897-2-maz@kernel.org>
Hi Marc,
On 2019/8/5 20:15, Marc Zyngier wrote:
> At the moment, the way we reset system registers is mildly insane:
> We write junk to them, call the reset functions, and then check that
> we have something else in them.
>
> The "fun" thing is that this can happen while the guest is running
> (PSCI, for example). If anything in KVM has to evaluate the state
> of a system register while junk is in there, bad thing may happen.
>
> Let's stop doing that. Instead, we track that we have called a
> reset function for that register, and assume that the reset
> function has done something. This requires fixing a couple of
> sysreg refinition in the trap table.
>
> In the end, the very need of this reset check is pretty dubious,
> as it doesn't check everything (a lot of the sysregs leave outside of
> the sys_regs[] array). It may well be axed in the near future.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
(Regardless of whether this check is needed or not,) I tested this patch
with kvm-unit-tests:
for i in {1..100}; do QEMU=/path/to/qemu-system-aarch64 accel=kvm
arch=arm64 ./run_tests.sh; done
And all the tests passed!
Thanks,
zenghui
_______________________________________________
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 1/2] ARM: zynq: support smp in thumb mode
From: Michal Simek @ 2019-08-06 6:39 UTC (permalink / raw)
To: Luis Araneda, linux, michal.simek; +Cc: linux-arm-kernel, stable, linux-kernel
In-Reply-To: <20190806030718.29048-2-luaraneda@gmail.com>
On 06. 08. 19 5:07, Luis Araneda wrote:
> Add .arm directive to headsmp.S to ensure that the
> CPU starts in 32-bit ARM mode and the correct code
> size is copied on smp bring-up
>
> Additionally, start secondary CPUs on secondary_startup_arm
> to automatically switch from ARM to thumb on a thumb kernel
>
> Suggested-by: Michal Simek <michal.simek@xilinx.com>
> Signed-off-by: Luis Araneda <luaraneda@gmail.com>
> ---
> arch/arm/mach-zynq/headsmp.S | 2 ++
> arch/arm/mach-zynq/platsmp.c | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-zynq/headsmp.S b/arch/arm/mach-zynq/headsmp.S
> index ab85003cf9ad..3449e0d1f990 100644
> --- a/arch/arm/mach-zynq/headsmp.S
> +++ b/arch/arm/mach-zynq/headsmp.S
> @@ -7,6 +7,8 @@
> #include <linux/init.h>
> #include <asm/assembler.h>
>
> + .arm
> +
> ENTRY(zynq_secondary_trampoline)
> ARM_BE8(setend be) @ ensure we are in BE8 mode
> ldr r0, zynq_secondary_trampoline_jump
> diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
> index a7cfe07156f4..38728badabd4 100644
> --- a/arch/arm/mach-zynq/platsmp.c
> +++ b/arch/arm/mach-zynq/platsmp.c
> @@ -81,7 +81,7 @@ EXPORT_SYMBOL(zynq_cpun_start);
>
> static int zynq_boot_secondary(unsigned int cpu, struct task_struct *idle)
> {
> - return zynq_cpun_start(__pa_symbol(secondary_startup), cpu);
> + return zynq_cpun_start(__pa_symbol(secondary_startup_arm), cpu);
> }
>
> /*
>
It is really a question if this should go to stable tree. It is pretty
much new feature.
Will be good to also add link to similar patch for example this one
5616f36713ea77f57ae908bf2fef641364403c9f.
M
_______________________________________________
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 04/22] media: Move v4l2_fwnode_parse_link from v4l2 to driver base
From: Andy Shevchenko @ 2019-08-06 6:41 UTC (permalink / raw)
To: Steve Longerbeam
Cc: Heikki Krogerus, Rafael J. Wysocki, Laurent Pinchart, Shawn Guo,
Fabio Estevam, open list:STAGING SUBSYSTEM, Mauro Carvalho Chehab,
Michal Simek, open list:ACPI, NXP Linux Team, Philipp Zabel,
Len Brown, Sakari Ailus, Sascha Hauer, Thomas Gleixner,
Andy Shevchenko, moderated list:ARM/ZYNQ ARCHITECTURE, Hyun Kwon,
Greg Kroah-Hartman, open list, Jacopo Mondi,
Pengutronix Kernel Team, Hans Verkuil, Linux Media Mailing List,
Enrico Weigelt
In-Reply-To: <20190805233505.21167-5-slongerbeam@gmail.com>
On Tue, Aug 6, 2019 at 2:37 AM Steve Longerbeam <slongerbeam@gmail.com> wrote:
>
> There is nothing v4l2-specific about v4l2_fwnode_{parse|put}_link().
> Make these functions more generally available by moving them to driver
> base, with the appropriate name changes to the functions and struct.
>
> In the process embed a 'struct fwnode_endpoint' in 'struct fwnode_link'
> for both sides of the link, and make use of fwnode_graph_parse_endpoint()
> to fully parse both endpoints. Rename members local_node and
> remote_node to more descriptive local_port_parent and
> remote_port_parent.
>
May I ask if it's going to be used outside of v4l2?
Any user in mind?
--
With Best Regards,
Andy Shevchenko
_______________________________________________
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] ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up
From: Michal Simek @ 2019-08-06 6:41 UTC (permalink / raw)
To: Luis Araneda, linux, michal.simek; +Cc: linux-arm-kernel, stable, linux-kernel
In-Reply-To: <20190806030718.29048-3-luaraneda@gmail.com>
On 06. 08. 19 5:07, Luis Araneda wrote:
> This fixes a kernel panic (read overflow) on memcpy when
> FORTIFY_SOURCE is enabled.
>
> The computed size of memcpy args are:
> - p_size (dst): 4294967295 = (size_t) -1
> - q_size (src): 1
> - size (len): 8
>
> Additionally, the memory is marked as __iomem, so one of
> the memcpy_* functions should be used for read/write
>
> Signed-off-by: Luis Araneda <luaraneda@gmail.com>
> ---
> arch/arm/mach-zynq/platsmp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
> index 38728badabd4..a10085be9073 100644
> --- a/arch/arm/mach-zynq/platsmp.c
> +++ b/arch/arm/mach-zynq/platsmp.c
> @@ -57,7 +57,7 @@ int zynq_cpun_start(u32 address, int cpu)
> * 0x4: Jump by mov instruction
> * 0x8: Jumping address
> */
> - memcpy((__force void *)zero, &zynq_secondary_trampoline,
> + memcpy_toio(zero, &zynq_secondary_trampoline,
> trampoline_size);
> writel(address, zero + trampoline_size);
>
I would consider this one as stable material. Please also add there link
to the patch which this patch fixes.
M
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] clk: imx8mq: Unregister clks when of_clk_add_provider failed
From: Anson.Huang @ 2019-08-06 6:46 UTC (permalink / raw)
To: mturquette, sboyd, shawnguo, s.hauer, kernel, festevam, abel.vesa,
peng.fan, leonard.crestez, ping.bai, jun.li, chen.fang, agx,
linux-clk, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <20190806064614.20294-1-Anson.Huang@nxp.com>
From: Anson Huang <Anson.Huang@nxp.com>
When of_clk_add_provider failed, all clks should be unregistered.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/clk/imx/clk-imx8mq.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
index 04302f2..81a0249 100644
--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -562,10 +562,18 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
clk_data.clk_num = ARRAY_SIZE(clks);
err = of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
- WARN_ON(err);
+ if (err < 0) {
+ dev_err(dev, "failed to register clks for i.MX8MQ\n");
+ goto unregister_clks;
+ }
imx_register_uart_clocks(uart_clks);
+ return 0;
+
+unregister_clks:
+ imx_unregister_clocks(clks, ARRAY_SIZE(clks));
+
return err;
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] clk: imx8mm: Unregister clks when of_clk_add_provider failed
From: Anson.Huang @ 2019-08-06 6:46 UTC (permalink / raw)
To: mturquette, sboyd, shawnguo, s.hauer, kernel, festevam, abel.vesa,
peng.fan, leonard.crestez, ping.bai, jun.li, chen.fang, agx,
linux-clk, linux-arm-kernel, linux-kernel
Cc: Linux-imx
From: Anson Huang <Anson.Huang@nxp.com>
When of_clk_add_provider failed, all clks should be unregistered.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/clk/imx/clk-imx8mm.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index e494e99..49ad761 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -661,12 +661,17 @@ static int imx8mm_clocks_probe(struct platform_device *pdev)
ret = of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
if (ret < 0) {
pr_err("failed to register clks for i.MX8MM\n");
- return -EINVAL;
+ goto unregister_clks;
}
imx_register_uart_clocks(uart_clks);
return 0;
+
+unregister_clks:
+ imx_unregister_clocks(clks, ARRAY_SIZE(clks));
+
+ return ret;
}
static const struct of_device_id imx8mm_clk_of_match[] = {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 07/10] regulator: mt6358: Add support for MT6358 regulator
From: Hsin-hsiung Wang @ 2019-08-06 7:28 UTC (permalink / raw)
To: Mark Brown
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Kate Stewart, Sean Wang, Liam Girdwood, linux-kernel,
Richard Fontana, Rob Herring, linux-mediatek, linux-arm-kernel,
Matthias Brugger, Thomas Gleixner, Eddie Huang, Lee Jones,
Allison Randal, linux-rtc
In-Reply-To: <20190805131030.GE6432@sirena.org.uk>
Hi Mark,
On Mon, 2019-08-05 at 14:10 +0100, Mark Brown wrote:
> On Mon, Aug 05, 2019 at 01:21:55PM +0800, Hsin-Hsiung Wang wrote:
>
> > +static const u32 vmch_voltages[] = {
> > + 2900000, 3000000, 3300000,
> > +};
>
> > +static const u32 vemc_voltages[] = {
> > + 2900000, 3000000, 3300000,
> > +};
>
> Several of these tables appear to be identical.
>
I will use the same voltage table in the next patch.
> > +static inline unsigned int mt6358_map_mode(unsigned int mode)
> > +{
> > + return mode == MT6358_BUCK_MODE_AUTO ?
> > + REGULATOR_MODE_NORMAL : REGULATOR_MODE_FAST;
> > +}
>
> There is no need for this to be an inline and please write normal
> conditional statements to improve legibility. There's other examples in
> the driver.
>
will fix it in the next patch.
> > +static int mt6358_get_buck_voltage_sel(struct regulator_dev *rdev)
> > +{
> > + int ret, regval;
> > + struct mt6358_regulator_info *info = rdev_get_drvdata(rdev);
> > +
> > + ret = regmap_read(rdev->regmap, info->da_vsel_reg, ®val);
> > + if (ret != 0) {
> > + dev_info(&rdev->dev,
> > + "Failed to get mt6358 Buck %s vsel reg: %d\n",
> > + info->desc.name, ret);
>
> dev_err() for errors here and throughout the driver.
>
will fix it in the next patch.
> > + return ret;
> > + }
> > +
> > + ret = (regval >> info->da_vsel_shift) & info->da_vsel_mask;
> > +
> > + return ret;
> > +}
>
> This looks like a standard get_voltage_sel_regmap()?
>
MT6358 has buck voltage status registers to show the actual output
voltage and the registers are different from the voltage setting
registers.
We want to get the actual voltage output, so we use the da_vsel status
registers here.
> > +err_mode:
> > + if (ret != 0)
> > + return ret;
> > +
> > + return 0;
>
> Or just return ret unconditionally?
will modify it to return ret unconditionally in the next patch.
Thanks a lot.
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm:unwind: fix backtrace error with unwind_table
From: chenzefeng @ 2019-08-06 7:32 UTC (permalink / raw)
To: linux, kstewart, tglx, allison, jeyu, gregkh, matthias.schiffer
Cc: stable, chenzefeng2, nixiaoming, linux-kernel, linux-arm-kernel
For arm, when load_module success, the mod->init_layout.base would
be free in function do_free_init, but do not remove it's unwind table
from the unwind_tables' list. And later the above mod->init_layout.base
would alloc for another module's text section, and add to the
unwind_tables which cause one address can found more than two unwind table
in the unwind_tables' list, therefore may get to errror unwind table to
backtrace, and get an error backtrace.
Signed-off-by: chenzefeng <chenzefeng2@huawei.com>
---
arch/arm/kernel/module.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index deef17f..a4eb5f4 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -403,14 +403,24 @@ int module_finalize(const Elf32_Ehdr *hdr, const Elf_Shdr *sechdrs,
return 0;
}
-void
-module_arch_cleanup(struct module *mod)
-{
+
#ifdef CONFIG_ARM_UNWIND
+void module_arch_cleanup(struct module *mod)
+{
int i;
for (i = 0; i < ARM_SEC_MAX; i++)
- if (mod->arch.unwind[i])
+ if (mod->arch.unwind[i]) {
unwind_table_del(mod->arch.unwind[i]);
-#endif
+ mod->arch.unwind[i] = NULL;
+ }
}
+
+void module_arch_freeing_init(struct module *mod)
+{
+ if (mod->arch.unwind[ARM_SEC_INIT]) {
+ unwind_table_del(mod->arch.unwind[ARM_SEC_INIT]);
+ mod->arch.unwind[ARM_SEC_INIT] = NULL;
+ }
+}
+#endif
--
1.8.5.6
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net] net: ethernet: sun4i-emac: Support phy-handle property for finding PHYs
From: Chen-Yu Tsai @ 2019-08-06 7:35 UTC (permalink / raw)
To: David S. Miller, Maxime Ripard
Cc: netdev, Chen-Yu Tsai, linux-kernel, linux-arm-kernel
From: Chen-Yu Tsai <wens@csie.org>
The sun4i-emac uses the "phy" property to find the PHY it's supposed to
use. This property was deprecated in favor of "phy-handle" in commit
8c5b09447625 ("dt-bindings: net: sun4i-emac: Convert the binding to a
schemas").
Add support for this new property name, and fall back to the old one in
case the device tree hasn't been updated.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
The aforementioned commit is in v5.3-rc1. It would be nice to have the
driver fix in the same release. In addition, an update for the device
tree has been queued up for v5.4, which made us realize the driver needs
an update.
---
drivers/net/ethernet/allwinner/sun4i-emac.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c b/drivers/net/ethernet/allwinner/sun4i-emac.c
index 3434730a7699..0537df06a9b5 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -860,7 +860,9 @@ static int emac_probe(struct platform_device *pdev)
goto out_clk_disable_unprepare;
}
- db->phy_node = of_parse_phandle(np, "phy", 0);
+ db->phy_node = of_parse_phandle(np, "phy-handle", 0);
+ if (!db->phy_node)
+ db->phy_node = of_parse_phandle(np, "phy", 0);
if (!db->phy_node) {
dev_err(&pdev->dev, "no associated PHY\n");
ret = -ENODEV;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFCv2 4/9] dt-bindings: reset: amlogic,meson-reset: convert to yaml
From: Philipp Zabel @ 2019-08-06 7:41 UTC (permalink / raw)
To: Neil Armstrong, robh+dt; +Cc: linux-amlogic, linux-arm-kernel, devicetree
In-Reply-To: <20190805120320.32282-5-narmstrong@baylibre.com>
On Mon, 2019-08-05 at 14:03 +0200, Neil Armstrong wrote:
> Now that we have the DT validation in place, let's convert the device tree
> bindings for the Amlogic Reset controller over to a YAML schemas.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Let me know if you want me to pick up this patch, otherwise
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
to merge with the rest of the series.
regards
Philipp
> ---
> .../bindings/reset/amlogic,meson-reset.txt | 19 ----------
> .../bindings/reset/amlogic,meson-reset.yaml | 37 +++++++++++++++++++
> 2 files changed, 37 insertions(+), 19 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
> create mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
>
> diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
> deleted file mode 100644
> index 28ef6c295c76..000000000000
> --- a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
> +++ /dev/null
> @@ -1,19 +0,0 @@
> -Amlogic Meson SoC Reset Controller
> -=======================================
> -
> -Please also refer to reset.txt in this directory for common reset
> -controller binding usage.
> -
> -Required properties:
> -- compatible: Should be "amlogic,meson8b-reset", "amlogic,meson-gxbb-reset" or
> - "amlogic,meson-axg-reset".
> -- reg: should contain the register address base
> -- #reset-cells: 1, see below
> -
> -example:
> -
> -reset: reset-controller {
> - compatible = "amlogic,meson-gxbb-reset";
> - reg = <0x0 0x04404 0x0 0x20>;
> - #reset-cells = <1>;
> -};
> diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
> new file mode 100644
> index 000000000000..00917d868d58
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 BayLibre, SAS
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/reset/amlogic,meson-reset.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Amlogic Meson SoC Reset Controller
> +
> +maintainers:
> + - Neil Armstrong <narmstrong@baylibre.com>
> +
> +properties:
> + compatible:
> + enum:
> + - amlogic,meson8b-reset # Reset Controller on Meson8b and compatible SoCs
> + - amlogic,meson-gxbb-reset # Reset Controller on GXBB and compatible SoCs
> + - amlogic,meson-axg-reset # Reset Controller on AXG and compatible SoCs
> +
> + reg:
> + maxItems: 1
> +
> + "#reset-cells":
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - "#reset-cells"
> +
> +examples:
> + - |
> + reset-controller@c884404 {
> + compatible = "amlogic,meson-gxbb-reset";
> + reg = <0xc884404 0x20>;
> + #reset-cells = <1>;
> + };
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFCv2 0/9] dt-bindings: first tentative of conversion to yaml format
From: Neil Armstrong @ 2019-08-06 7:42 UTC (permalink / raw)
To: Rob Herring
Cc: Philipp Zabel, devicetree, LINUX-WATCHDOG, Jassi Brar, linux-spi,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
open list:SERIAL DRIVERS, linux-amlogic, Kishon Vijay Abraham I,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqJzwtSXX0nrS7RBP8u-e=16SiWOBjLrvy8Amc08PfpXag@mail.gmail.com>
Hi Rob,
On 05/08/2019 23:51, Rob Herring wrote:
> On Mon, Aug 5, 2019 at 6:03 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>> This is a first tentative to convert some of the simplest Amlogic
>> dt-bindings to the yaml format.
>>
>> All have been tested using :
>> $ make ARCH=arm64 dtbs_check
>>
>> Issues with the amlogic arm64 DTs has already been identified thanks
>> to the validation scripts. The DT fixes will be pushed once these yaml
>> bindings are acked.
>>
>> Changes since rfc v1:
>> - Fixed bindings according to Rob's comments
>> - Added commit log
>> - renamed yaml files using amlogic prefix
>>
>> Neil Armstrong (9):
>> dt-bindings: mailbox: meson-mhu: convert to yaml
>> dt-bindings: rng: amlogic,meson-rng: convert to yaml
>> dt-bindings: spi: meson: convert to yaml
>> dt-bindings: reset: amlogic,meson-reset: convert to yaml
>> dt-bindings: arm: amlogic: amlogic,meson-gx-ao-secure: convert to yaml
>> dt-bindings: phy: meson-g12a-usb2-phy: convert to yaml
>> dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to yaml
>> dt-bindings: serial: meson-uart: convert to yaml
>> dt-bindings: watchdog: meson-gxbb-wdt: convert to yaml
>
> For the series,
>
> Reviewed-by: Rob Herring <robh@kernel.org>
>
> What's your merge plan? Do you want me to take the whole series?
I planned to split them for each subsystem, but it may be much simpler
if you take the whole serie.
Neil
>
> Rob
>
_______________________________________________
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 0/6] hwspinlock: allow sharing of hwspinlocks
From: Fabien DESSENNE @ 2019-08-06 7:43 UTC (permalink / raw)
To: s-anna@ti.com
Cc: Ohad Ben-Cohen, Mark Rutland, Alexandre TORGUE, Jonathan Corbet,
linux-doc@vger.kernel.org, linux-remoteproc@vger.kernel.org,
linux-kernel@vger.kernel.org, Bjorn Andersson,
devicetree@vger.kernel.org, Rob Herring, Maxime Coquelin,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, Benjamin GAIGNARD
In-Reply-To: <20190805174659.GA23928@tuxbook-pro>
Hi Suman,
Could you please let us know your thoughts or comments?
BR
Fabien
> -----Original Message-----
> From: Bjorn Andersson <bjorn.andersson@linaro.org>
> Sent: lundi 5 août 2019 19:47
> To: Fabien DESSENNE <fabien.dessenne@st.com>
> Cc: Ohad Ben-Cohen <ohad@wizery.com>; Rob Herring <robh+dt@kernel.org>;
> Mark Rutland <mark.rutland@arm.com>; Maxime Coquelin
> <mcoquelin.stm32@gmail.com>; Alexandre TORGUE
> <alexandre.torgue@st.com>; Jonathan Corbet <corbet@lwn.net>; linux-
> remoteproc@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com; linux-arm-
> kernel@lists.infradead.org; linux-doc@vger.kernel.org; Benjamin GAIGNARD
> <benjamin.gaignard@st.com>
> Subject: Re: [PATCH 0/6] hwspinlock: allow sharing of hwspinlocks
>
> On Mon 05 Aug 01:48 PDT 2019, Fabien DESSENNE wrote:
>
> >
> > On 01/08/2019 9:14 PM, Bjorn Andersson wrote:
> > > On Wed 13 Mar 08:50 PDT 2019, Fabien Dessenne wrote:
> > >
> > >> The current implementation does not allow two different devices to
> > >> use a common hwspinlock. This patch set proposes to have, as an
> > >> option, some hwspinlocks shared between several users.
> > >>
> > >> Below is an example that explain the need for this:
> > >> exti: interrupt-controller@5000d000 {
> > >> compatible = "st,stm32mp1-exti", "syscon";
> > >> interrupt-controller;
> > >> #interrupt-cells = <2>;
> > >> reg = <0x5000d000 0x400>;
> > >> hwlocks = <&hsem 1>;
> > >> };
> > >> The two drivers (stm32mp1-exti and syscon) refer to the same hwlock.
> > >> With the current hwspinlock implementation, only the first driver
> > >> succeeds in requesting (hwspin_lock_request_specific) the hwlock.
> > >> The second request fails.
> > >>
> > >>
> > >> The proposed approach does not modify the API, but extends the DT
> 'hwlocks'
> > >> property with a second optional parameter (the first one identifies
> > >> an
> > >> hwlock) that specifies whether an hwlock is requested for exclusive
> > >> usage (current behavior) or can be shared between several users.
> > >> Examples:
> > >> hwlocks = <&hsem 8>; Ref to hwlock #8 for exclusive usage
> > >> hwlocks = <&hsem 8 0>; Ref to hwlock #8 for exclusive (0) usage
> > >> hwlocks = <&hsem 8 1>; Ref to hwlock #8 for shared (1) usage
> > >>
> > >> As a constraint, the #hwlock-cells value must be 1 or 2.
> > >> In the current implementation, this can have theorically any value but:
> > >> - all of the exisiting drivers use the same value : 1.
> > >> - the framework supports only one value : 1 (see implementation of
> > >> of_hwspin_lock_simple_xlate())
> > >> Hence, it shall not be a problem to restrict this value to 1 or 2
> > >> since it won't break any driver.
> > >>
> > > Hi Fabien,
> > >
> > > Your series looks good, but it makes me wonder why the hardware
> > > locks should be an exclusive resource.
> > >
> > > How about just making all (specific) locks shared?
> >
> > Hi Bjorn,
> >
> > Making all locks shared is a possible implementation (my first
> > implementation was going this way) but there are some drawbacks we
> > must be aware of:
> >
> > A/ This theoretically break the legacy behavior (the legacy works with
> > exclusive (UNUSED radix tag) usage). As a consequence, an existing
> > driver that is currently failing to request a lock (already claimed by
> > another
> > user) would now work fine. Not sure that there are such drivers, so
> > this point is probably not a real issue.
> >
>
> Right, it's possible that a previously misconfigured system now successfully
> probes more than one device that uses a particular spinlock. But such system
> would be suffering from issues related to e.g.
> probe ordering.
>
> So I think we should ignore this issue.
>
> > B/ This would introduce some inconsistency between the two 'request'
> > API which are hwspin_lock_request() and hwspin_lock_request_specific().
> > hwspin_lock_request() looks for an unused lock, so requests for an
> > exclusive usage. On the other side, request_specific() would request shared
> locks.
> > Worst the following sequence can transform an exclusive usage into a
> > shared
> >
>
> There is already an inconsistency in between these; as with above any system
> that uses both request() and request_specific() will be suffering from intermittent
> failures due to probe ordering.
>
> > one:
> > -hwspin_lock_request() -> returns Id#0 (exclusive)
> > -hwspin_lock_request() -> returns Id#1 (exclusive)
> > -hwspin_lock_request_specific(0) -> returns Id#0 and makes Id#0
> > shared Honestly I am not sure that this is a real issue, but it's
> > better to have it in mind before we take ay decision
>
> The case where I can see a
> problem with this would be if the two clients somehow would nest their locking
> regions.
>
> But generally I think this could consider this an improvement, because the
> request_specific() would now be able to acquire its hwlock, with some additional
> contention due to the multiple use.
>
> > I could not find any driver using the hwspin_lock_request() API, we
> > may decide to remove (or to make deprecated) this API, having
> > everything 'shared without any conditions'.
> >
>
> It would be nice to have an upstream user of this API.
>
> >
> > I can see three options:
> > 1- Keep my initial proposition
> > 2- Have hwspin_lock_request_specific() using shared locks and
> > hwspin_lock_request() using unused (so 'initially' exclusive) locks.
> > 3- Have hwspin_lock_request_specific() using shared locks and
> > remove/make deprecated hwspin_lock_request().
> >
> > Just let me know what is your preference.
> >
>
> I think we should start with #2 and would like input from e.g. Suman regarding #3.
>
> Regards,
> Bjorn
>
> > BR
> >
> > Fabien
> >
> > >
> > > Regards,
> > > Bjorn
> > >
> > >> Fabien Dessenne (6):
> > >> dt-bindings: hwlock: add support of shared locks
> > >> hwspinlock: allow sharing of hwspinlocks
> > >> dt-bindings: hwlock: update STM32 #hwlock-cells value
> > >> ARM: dts: stm32: Add hwspinlock node for stm32mp157 SoC
> > >> ARM: dts: stm32: Add hwlock for irqchip on stm32mp157
> > >> ARM: dts: stm32: hwlocks for GPIO for stm32mp157
> > >>
> > >> .../devicetree/bindings/hwlock/hwlock.txt | 27 +++++--
> > >> .../bindings/hwlock/st,stm32-hwspinlock.txt | 6 +-
> > >> Documentation/hwspinlock.txt | 10 ++-
> > >> arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 2 +
> > >> arch/arm/boot/dts/stm32mp157c.dtsi | 10 +++
> > >> drivers/hwspinlock/hwspinlock_core.c | 82 +++++++++++++++++-
> ----
> > >> drivers/hwspinlock/hwspinlock_internal.h | 2 +
> > >> 7 files changed, 108 insertions(+), 31 deletions(-)
> > >>
> > >> --
> > >> 2.7.4
> > >>
_______________________________________________
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 v3 4/4] serial: 8250: Don't check for mctrl_gpio_init() returning -ENOSYS
From: Uwe Kleine-König @ 2019-08-06 7:44 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-serial@vger.kernel.org, geert+renesas@glider.be,
shawnguo@kernel.org, s.hauer@pengutronix.de,
linux-kernel@vger.kernel.org, Schrempf Frieder, linux-imx@nxp.com,
kernel@pengutronix.de, Jiri Slaby, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190802122623.GA25281@kroah.com>
Hey Greg
On Fri, Aug 02, 2019 at 02:26:23PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Aug 02, 2019 at 02:15:55PM +0200, Uwe Kleine-König wrote:
> > On Fri, Aug 02, 2019 at 10:04:11AM +0000, Schrempf Frieder wrote:
> > > From: Frieder Schrempf <frieder.schrempf@kontron.de>
> > >
> > > Now that the mctrl_gpio code returns NULL instead of ERR_PTR(-ENOSYS)
> > > if CONFIG_GPIOLIB is disabled, we can safely remove this check.
> > >
> > > Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> >
> > Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> >
> > @greg: This patch doesn't depend on patch 2; ditto for patch 3. So only
> > taking patches 1, 3 and 4 should be fine. This way Frieder's v4 only
> > have to care for patch 2. (Assuming noone objects to 1, 3 and 4 of
> > course.)
>
> Sounds good, I'll do that, thanks.
again you somehow managed to mangle my name :-|
$ git log -3 8f0df898b27926e443d13770adfd828cc0f50148 | grep Uwe
Acked-by: Uwe Kleine-Knig <u.kleine-koenig@pengutronix.de>
Acked-by: Uwe Kleine-Knig <u.kleine-koenig@pengutronix.de>
Reviewed-by: Uwe Kleine-Knig <u.kleine-koenig@pengutronix.de>
in all three instances the ö is missing.
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
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 v3 2/4] serial: mctrl_gpio: Add a NULL check to mctrl_gpio_to_gpiod()
From: Uwe Kleine-König @ 2019-08-06 7:45 UTC (permalink / raw)
To: Schrempf Frieder
Cc: linux-serial@vger.kernel.org, geert+renesas@glider.be,
shawnguo@kernel.org, s.hauer@pengutronix.de, Jiri Slaby,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, Greg Kroah-Hartman, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <f866213b-fd3b-8602-6c11-56cb65a1ea05@kontron.de>
Hello Frieder,
On Mon, Aug 05, 2019 at 09:01:39AM +0000, Schrempf Frieder wrote:
> On 02.08.19 14:12, Uwe Kleine-König wrote:
> > On Fri, Aug 02, 2019 at 10:04:10AM +0000, Schrempf Frieder wrote:
> >> From: Frieder Schrempf <frieder.schrempf@kontron.de>
> >>
> >> As it is allowed to use the mctrl_gpio_* functions before
> >> initialization (as the 8250 driver does according to 434be0ae7aa7),
> >
> > Actually I was surprised some time ago that 8250 used serial_mctrl
> > without first initializing it and expecting it to work. I didn't look in
> > detail, but I wouldn't go so far to call this "allowed". The commit
> > itself calls it "workaround" which seems a better match.
>
> Ok, but if this is considered to be a workaround and as the 8250 driver
> does not use mctrl_gpio_to_gpiod(), we should maybe just drop this patch
> instead of encouraging others to use mctrl_gpio before initialization.
>
> I'm really not sure what's best, so depending on what you will propose,
> I'll send a new version of this patch with adjusted commit message or not.
I wouldn't encourage usage of mctrl-gpio before it's initialized. So I
suggest to drop this patch.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
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 v8 00/11] add USB GPIO based connection detection driver
From: Chunfeng Yun @ 2019-08-06 7:48 UTC (permalink / raw)
To: Linus Walleij
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Heikki Krogerus, Hans de Goede, Greg Kroah-Hartman, linux-usb,
linux-kernel@vger.kernel.org, Biju Das, Badhri Jagan Sridharan,
Andy Shevchenko, Rob Herring,
moderated list:ARM/Mediatek SoC support, Min Guo,
Matthias Brugger, Adam Thomson, Linux ARM, Li Jun
In-Reply-To: <CACRpkdaBT24JPH_VsKtgp6fjWtVuqM50rXkDVYKmLHgR5hdJzA@mail.gmail.com>
On Mon, 2019-08-05 at 12:06 +0200, Linus Walleij wrote:
> On Wed, Jul 24, 2019 at 10:51 AM Chunfeng Yun <chunfeng.yun@mediatek.com> wrote:
>
> > Because the USB Connector is introduced and the requirement of
> > usb-connector.txt binding, the old way using extcon to support
> > USB Dual-Role switch is now deprecated, meanwhile there is no
> > available common driver when use Type-B connector, typically
> > using an input GPIO to detect USB ID pin.
>
> However while this was going on,
> drivers/extcon/extcon-fsa9480.c was merged and that detects
> not only GPIO on the USB port but multiplexed usecases such
> as UART over the USB micro PHY (and no that UART is not
> a USB UART, but an actual RX/TX over D-/D+).
>
> That driver also measure a whole slew of funny resistance
> values on the ID pin, that is how it does its job.
I look into the spec of fsa9480, it indeed detect many USB accessories.
But this driver is used for simplest cases that only uses micro
receptacle with id-pin/vbus-pin
>
> But for just "hey I'm plugged in" we can surely keep this
> ID on GPIO detection in the USB subsystem.
Sorry, you mean provide a common API? could you please describe more
clearer about your suggestion?
Introducing a single driver using usb_role_switch will help to keep
transparent for USB controller driver, no matter it uses type-c or micro
Thanks a lot
>
> I just get a bit insecure about how we should ideally
> handle these "funny-PHY's".
>
> Yours,
> Linus Walleij
_______________________________________________
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 v3 2/4] serial: mctrl_gpio: Add a NULL check to mctrl_gpio_to_gpiod()
From: Schrempf Frieder @ 2019-08-06 8:02 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-serial@vger.kernel.org, geert+renesas@glider.be,
shawnguo@kernel.org, s.hauer@pengutronix.de, Jiri Slaby,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, Greg Kroah-Hartman, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190806074534.5w773nltywxyiljz@pengutronix.de>
On 06.08.19 09:45, Uwe Kleine-König wrote:
> Hello Frieder,
>
> On Mon, Aug 05, 2019 at 09:01:39AM +0000, Schrempf Frieder wrote:
>> On 02.08.19 14:12, Uwe Kleine-König wrote:
>>> On Fri, Aug 02, 2019 at 10:04:10AM +0000, Schrempf Frieder wrote:
>>>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>>>
>>>> As it is allowed to use the mctrl_gpio_* functions before
>>>> initialization (as the 8250 driver does according to 434be0ae7aa7),
>>>
>>> Actually I was surprised some time ago that 8250 used serial_mctrl
>>> without first initializing it and expecting it to work. I didn't look in
>>> detail, but I wouldn't go so far to call this "allowed". The commit
>>> itself calls it "workaround" which seems a better match.
>>
>> Ok, but if this is considered to be a workaround and as the 8250 driver
>> does not use mctrl_gpio_to_gpiod(), we should maybe just drop this patch
>> instead of encouraging others to use mctrl_gpio before initialization.
>>
>> I'm really not sure what's best, so depending on what you will propose,
>> I'll send a new version of this patch with adjusted commit message or not.
>
> I wouldn't encourage usage of mctrl-gpio before it's initialized. So I
> suggest to drop this patch.
Ok, thanks.
_______________________________________________
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 v3 1/4] serial: mctrl_gpio: Avoid probe failures in case of missing gpiolib
From: Geert Uytterhoeven @ 2019-08-06 8:09 UTC (permalink / raw)
To: Schrempf Frieder
Cc: linux-serial@vger.kernel.org, geert+renesas@glider.be,
Greg Kroah-Hartman, shawnguo@kernel.org, s.hauer@pengutronix.de,
Jiri Slaby, linux-kernel@vger.kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, u.kleine-koenig@pengutronix.de,
festevam@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190802100349.8659-1-frieder.schrempf@kontron.de>
On Fri, Aug 2, 2019 at 12:04 PM Schrempf Frieder
<frieder.schrempf@kontron.de> wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() and
> mctrl_gpio_init_noauto() will currently return an error pointer with
> -ENOSYS. As the mctrl GPIOs are usually optional, drivers need to
> check for this condition to allow continue probing.
>
> To avoid the need for this check in each driver, we return NULL
> instead, as all the mctrl_gpio_*() functions are skipped anyway.
> We also adapt mctrl_gpio_to_gpiod() to be in line with this change.
>
> Reviewed-by: Fabio Estevam <festevam@gmail.com>
> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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