* [PATCH] ARM: dts: berlin2q: move PMU node from soc to root
From: Jisheng Zhang @ 2018-05-15 10:19 UTC (permalink / raw)
To: Sebastian Hesselbarth, Rob Herring, Mark Rutland
Cc: linux-arm-kernel, devicetree, linux-kernel
Fix "make dtbs W=1" warns about missing reg or ranges property.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
arch/arm/boot/dts/berlin2q.dtsi | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 82e176011d36..c1bf23a4412b 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -62,6 +62,18 @@
};
};
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>,
+ <&cpu1>,
+ <&cpu2>,
+ <&cpu3>;
+ };
+
refclk: oscillator {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -76,18 +88,6 @@
ranges = <0 0xf7000000 0x1000000>;
interrupt-parent = <&gic>;
- pmu {
- compatible = "arm,cortex-a9-pmu";
- interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-affinity = <&cpu0>,
- <&cpu1>,
- <&cpu2>,
- <&cpu3>;
- };
-
sdhci0: sdhci@ab0000 {
compatible = "mrvl,pxav3-mmc";
reg = <0xab0000 0x200>;
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v2 11/11] docs: fix broken references with multiple hints
From: Bartlomiej Zolnierkiewicz @ 2018-05-15 10:28 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Mark Rutland, linux-fbdev, linux-usb, Linux Doc Mailing List,
David Airlie, dri-devel, Harry Wei, devel, Jonathan Corbet,
James Morris, Ingo Molnar, linux-input, Roy Pledge,
Serge E. Hallyn, devicetree, Jiri Kosina, Steven Rostedt,
Mauro Carvalho Chehab, linux-gpio, Rob Herring,
Greg Kroah-Hartman, Dmitry Torokhov, linux-kernel,
linux-security-module, Benjamin Tissoires <benjamin.tissoires@
In-Reply-To: <63a4f8a93f9115475bc184d0f37d076c9b9c75ff.1525870886.git.mchehab+samsung@kernel.org>
On Wednesday, May 09, 2018 10:18:54 AM Mauro Carvalho Chehab wrote:
> The script:
> ./scripts/documentation-file-ref-check --fix-rst
>
> Gives multiple hints for broken references on some files.
> Manually use the one that applies for some files.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> # for fbdev part
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/RFC v3 1/4] base: devcon: add a new API to find the graph
From: Yoshihiro Shimoda @ 2018-05-15 11:02 UTC (permalink / raw)
To: Heikki Krogerus
Cc: gregkh@linuxfoundation.org, robh+dt@kernel.org,
mark.rutland@arm.com, hdegoede@redhat.com,
andy.shevchenko@gmail.com, linux-usb@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20180515082911.GH21435@kuha.fi.intel.com>
Hi Heikki,
Thank you for the reply!
> From: Heikki Krogerus, Sent: Tuesday, May 15, 2018 5:29 PM
>
> On Tue, May 15, 2018 at 02:19:14AM +0000, Yoshihiro Shimoda wrote:
> > Hi Heikki,
> >
> > > From: Heikki Krogerus, Sent: Monday, May 14, 2018 10:28 PM
> > >
> > > On Mon, May 14, 2018 at 06:15:57PM +0900, Yoshihiro Shimoda wrote:
<snip>
> > > > +struct device *device_connection_find_by_graph(struct device *dev, u32 port,
> > > > + u32 endpoint)
> > > > +{
> > > > + struct bus_type *bus;
> > > > + struct fwnode_handle *remote;
> > > > + struct device *conn;
> > > > +
> > > > + remote = fwnode_graph_get_remote_node(dev_fwnode(dev), port, endpoint);
> > > > + if (!remote)
> > > > + return NULL;
> > > > +
> > > > + for (bus = generic_match_buses[0]; bus; bus++) {
> > > > + conn = bus_find_device(bus, NULL, remote, generic_graph_match);
> > > > + if (conn)
> > > > + return conn;
> > > > + }
> > > > +
> > > > + /*
> > > > + * We only get called if a connection was found, tell the caller to
> > > > + * wait for the other device to show up.
> > > > + */
> > > > + return ERR_PTR(-EPROBE_DEFER);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(device_connection_find_by_graph);
> > >
> > > Why do we need more API for walking through the graph?
> >
> > I thought there is difficult to find if a device has multiple ports or endpoints.
> > So, I'd like to use port and endpoint number for finding a device.
> >
> > > I'm not sure exactly sure what is going on here, I'll try to study
> > > your patches more when I have time, but the approach looks wrong. That
> > > function looks like a helper, but just not that useful one.
> > >
> > > We really should be able to use the existing functions. In practice
> > > device_connection_find_match() should eventually parse the graph, then
> > > fallback to build-in connections if no graph is found. Otherwise
> > > parsing graph here is not really useful at all.
> >
> > I think using device_connection_find_match() for finding the graph becomes complicated.
> > The current arguments of the function is the below:
> >
> > void *device_connection_find_match(struct device *dev, const char *con_id,
> > void *data,
> > void *(*match)(struct device_connection *con,
> > int ep, void *data))
> >
> > If finding the graph, the following arguments will be not used.
> > - con_id
> > - *con and ep of "match" arguments.
> >
> > This is because these arguments are for the build-in connections.
>
> No they're not. You do realize that we can build a temporary struct
> device_connection there and then (in stack) to be supplied for the
> ->match callback.
I understood it.
> > So, should I modify the arguments of the function for finding both
> > the graph and built-in connections somehow?
>
> I don't see any need for that. We may need to modify struct
> device_connection, but there should not be any need to touch the API.
>
> Your plan to use port and endpoint number is wrong, as they are just
> indexes, and therefore not reliable. Luckily it should be completely
> unnecessary to use them.
>
> The way I see this working is that we parse all the endpoints the
> caller device has. If we can't take advantage of the con_id for
> identification (though ideally we can), we just need to call ->match
> with every one of them. The implementation for the ->match callback is
> then responsible of figuring out if the endpoint is the one we are
> looking for or not in that case.
I understood it. But, I need to investigate how to find a device.
> The only problem I see with that is that we may not have a reliable
> way to convert the fwnode pointing to the remote-endpoint parent into
> struct device (if one has already been enumerated) in order to get the
> device name and use it as the second endpoint name in struct
> device_connection. To solve that, we could consider for example just
> adding a new member, fwnode pointer perhaps, to the structure. Or
> perhaps use the endpoint members for something else than device names
> when graph is used, and add a member defining the type of match:
> graph, build-in, etc. There are many things we can consider.
I don't understand why adding such new member(s) can solve that.
Anyway, I will investigate this more...
> I don't know if I'm able to explain what I'm after with this, so if
> you like, I can propose something for this myself. Though that will
> have to wait for few weeks. Right now I'm too busy with other stuff.
Thank you for your proposal! However, I'd like to try to investigate
once more while you are too busy.
Best regards,
Yoshihiro Shimoda
>
> Thanks,
>
> --
> heikki
^ permalink raw reply
* Re: [PATCH v2 4/4] ARM: PWM: add allwinner sun8i pwm support.
From: Maxime Ripard @ 2018-05-15 11:17 UTC (permalink / raw)
To: Hao Zhang
Cc: Thierry Reding, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Mark Rutland,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, Chen-Yu Tsai, Claudiu Beznea,
linux-gpio-u79uwXL29TY76Z2rM5mHXA, open list,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Allwinner sunXi SoC support,
linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <CAJeuY7-Dz1u9J8GMu=OdzJ2cJUnE3wEobJoQz6RV-ibjBjoW4A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2376 bytes --]
Hi,
On Mon, May 14, 2018 at 10:45:44PM +0800, Hao Zhang wrote:
> 2018-02-26 17:00 GMT+08:00 Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>:
> > Thanks for respinning this serie. It looks mostly good, but you still
> > have a quite significant number of checkpatch (--strict) warnings that
> > you should address.
>
> Thanks for reviews :) ,i'm sorry for that, it will be fixed next
> time. and, besides, in what situation were the checkpatch warning
> can be ignore？
The only one that can be reasonably be ignored is the long line
warning, and only if complying to the limit would make it less easy to
understand.
> >
> > On Sun, Feb 25, 2018 at 09:53:08PM +0800, hao_zhang wrote:
> >> +#define CAPTURE_IRQ_ENABLE_REG 0x0010
> >> +#define CFIE(ch) BIT(ch << 1 + 1)
> >> +#define CRIE(ch) BIT(ch << 1)
> >
> > You should also put your argument between parentheses here (and in all
> > your other macros).
>
> Do you mean like this ?
> #define CFIE(ch) BIT((ch) << 1 + 1)
> #define CRIE(ch) BIT((ch) << 1)
Yep, exactly. Otherwise, if you do something like CRIE(1 + 1), the
result will be BIT(1 + 1 << 1), which will expand to 3, instead of 4.
Also, CFIE looks a bit weird here, is it the offset that is
incremented, or the value? You should probably have parentheses to
make it explicit.
> >
> >> +static const u16 div_m_table[] = {
> >> + 1,
> >> + 2,
> >> + 4,
> >> + 8,
> >> + 16,
> >> + 32,
> >> + 64,
> >> + 128,
> >> + 256
> >> +};
> >
> > If this is just a power of two, you can use either the power of two /
> > ilog2 to switch back and forth, instead of using that table.
>
> I think using table is more explicit and extended...
If you didn't have a simple mapping between the register values and
the divider value, then yeah, sure. But it's not the case here.
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 09/21] arm64: dts: allwinner: a64: Add HDMI support
From: Maxime Ripard @ 2018-05-15 11:19 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, Icenowy Zheng, Jernej Skrabec, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, David Airlie,
dri-devel, Michael Turquette, Stephen Boyd, linux-clk,
Michael Trimarchi, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <CAMty3ZDCubM2sLBfNVar-kA9djZ8PJDQJOS0Jwi6wWNVeK9mCg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]
On Mon, May 14, 2018 at 04:01:15PM +0530, Jagan Teki wrote:
> On Mon, May 14, 2018 at 2:10 PM, Maxime Ripard
> <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > On Mon, May 14, 2018 at 02:03:36PM +0530, Jagan Teki wrote:
> >> On Wed, May 2, 2018 at 5:04 PM, Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> >> > Hi,
> >> >
> >> > On Mon, Apr 30, 2018 at 05:10:46PM +0530, Jagan Teki wrote:
> >> >> + hdmi_phy: hdmi-phy@1ef0000 {
> >> >> + compatible = "allwinner,sun50i-a64-hdmi-phy",
> >> >> + "allwinner,sun8i-h3-hdmi-phy";
> >> >> + reg = <0x01ef0000 0x10000>;
> >> >> + clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_DDC>,
> >> >> + <&ccu CLK_PLL_VIDEO1>;
> >> >
> >> > You were discussing that the PLL0 could also be used to clock the PHY,
> >> > has that been figured out?
> >>
> >> This is what I understand from Fig: 3-3. Module Clock Diagram, both
> >> tcon0 and tcon1 are using HDMI. I'm thinking based on the tcon
> >> configuration we need use proper PLL or some logic to get common PLL
> >> don't know yet. Since this series adding tcon1 I've attached PLL1.
> >
> > You're not describing the TCON node here though, but the HDMI one, and
> > the HDMI block is listed in both the PLL video 0 and 1.
>
> So how can we attach particular PLL with particular HDMI(PLL0 to HDMI0
> and so-on) or do we need to attached both the PLL's any suggestion?
I'm not sure what your question is here, just add the possibility to
have an extra PLL if that makes sense to the binding.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx7d: correct cpu supply name for voltage scaling
From: Fabio Estevam @ 2018-05-15 11:44 UTC (permalink / raw)
To: Anson Huang
Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, Rob Herring, Mark Rutland,
NXP Linux Team,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel
In-Reply-To: <1526375609-17676-1-git-send-email-Anson.Huang@nxp.com>
On Tue, May 15, 2018 at 6:13 AM, Anson Huang <Anson.Huang@nxp.com> wrote:
> diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
> index 7f64568..60deaf9 100644
> --- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
> +++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
> @@ -33,7 +33,7 @@
> };
>
> &cpu0 {
> - arm-supply = <&sw1a_reg>;
> + cpu-supply = <&sw1a_reg>;
> };
>
> &fec1 {
> @@ -284,4 +284,4 @@
> MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG PWREN */
> >;
> };
> -};
> \ No newline at end of file
> +};
This change seems unrelated.
Other than that:
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH v2 0/2] soc: renesas: r8a77990-sysc: Add support for R-Car E3
From: Yoshihiro Shimoda @ 2018-05-15 12:07 UTC (permalink / raw)
To: horms, magnus.damm, robh+dt, mark.rutland
Cc: devicetree, linux-renesas-soc, Yoshihiro Shimoda
This patch is based on the renesas-devel-20180515-v4.17-rc5 tag of
renesas.git.
Changes from v1:
- Rebase the latest kernel.
- Modify r8a77990_areas[] as the specification in patch 1.
- Use // instead of /* */ at the SPDX-License-Identifier line in patch 1.
- Add workaround patch for 3DG-{A,B} of R-Car E3 ES1.0 as patch 2.
Takeshi Kihara (1):
soc: renesas: rcar-sysc: Add support for R-Car E3 power areas
Yoshihiro Shimoda (1):
soc: renesas: r8a77990-sysc: Add workaround for 3DG-{A,B}
.../bindings/power/renesas,rcar-sysc.txt | 1 +
drivers/soc/renesas/Kconfig | 5 ++
drivers/soc/renesas/Makefile | 1 +
drivers/soc/renesas/r8a77990-sysc.c | 68 ++++++++++++++++++++++
drivers/soc/renesas/rcar-sysc.c | 3 +
drivers/soc/renesas/rcar-sysc.h | 1 +
6 files changed, 79 insertions(+)
create mode 100644 drivers/soc/renesas/r8a77990-sysc.c
--
1.9.1
^ permalink raw reply
* [PATCH v2 1/2] soc: renesas: rcar-sysc: Add support for R-Car E3 power areas
From: Yoshihiro Shimoda @ 2018-05-15 12:07 UTC (permalink / raw)
To: horms, magnus.damm, robh+dt, mark.rutland
Cc: devicetree, linux-renesas-soc, Takeshi Kihara, Yoshihiro Shimoda
In-Reply-To: <1526386059-6173-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>
From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
This patch adds Cortex-A53 CPU{0,1}, Cortex-A53 SCU, Cortex-R7, A3VC,
A2VC1 and 3DG-{A,B} power domain areas for the R8A77990 SoC.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[shimoda: fix 3DG-{A,B} and add SPDX-License-Identifier]
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
.../bindings/power/renesas,rcar-sysc.txt | 1 +
drivers/soc/renesas/Kconfig | 5 ++++
drivers/soc/renesas/Makefile | 1 +
drivers/soc/renesas/r8a77990-sysc.c | 33 ++++++++++++++++++++++
drivers/soc/renesas/rcar-sysc.c | 3 ++
drivers/soc/renesas/rcar-sysc.h | 1 +
6 files changed, 44 insertions(+)
create mode 100644 drivers/soc/renesas/r8a77990-sysc.c
diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
index 3e91d20..180ae65 100644
--- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
+++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
@@ -21,6 +21,7 @@ Required properties:
- "renesas,r8a77965-sysc" (R-Car M3-N)
- "renesas,r8a77970-sysc" (R-Car V3M)
- "renesas,r8a77980-sysc" (R-Car V3H)
+ - "renesas,r8a77990-sysc" (R-Car E3)
- "renesas,r8a77995-sysc" (R-Car D3)
- reg: Address start and address range for the device.
- #power-domain-cells: Must be 1.
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index c0e0286..1d824cb 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -19,6 +19,7 @@ config SOC_RENESAS
select SYSC_R8A77965 if ARCH_R8A77965
select SYSC_R8A77970 if ARCH_R8A77970
select SYSC_R8A77980 if ARCH_R8A77980
+ select SYSC_R8A77990 if ARCH_R8A77990
select SYSC_R8A77995 if ARCH_R8A77995
if SOC_RENESAS
@@ -76,6 +77,10 @@ config SYSC_R8A77980
bool "R-Car V3H System Controller support" if COMPILE_TEST
select SYSC_RCAR
+config SYSC_R8A77990
+ bool "R-Car E3 System Controller support" if COMPILE_TEST
+ select SYSC_RCAR
+
config SYSC_R8A77995
bool "R-Car D3 System Controller support" if COMPILE_TEST
select SYSC_RCAR
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index a86ece7..7dc0f20 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_SYSC_R8A7796) += r8a7796-sysc.o
obj-$(CONFIG_SYSC_R8A77965) += r8a77965-sysc.o
obj-$(CONFIG_SYSC_R8A77970) += r8a77970-sysc.o
obj-$(CONFIG_SYSC_R8A77980) += r8a77980-sysc.o
+obj-$(CONFIG_SYSC_R8A77990) += r8a77990-sysc.o
obj-$(CONFIG_SYSC_R8A77995) += r8a77995-sysc.o
# Family
diff --git a/drivers/soc/renesas/r8a77990-sysc.c b/drivers/soc/renesas/r8a77990-sysc.c
new file mode 100644
index 0000000..a8c6417
--- /dev/null
+++ b/drivers/soc/renesas/r8a77990-sysc.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Renesas R-Car E3 System Controller
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ */
+
+#include <linux/bug.h>
+#include <linux/kernel.h>
+
+#include <dt-bindings/power/r8a77990-sysc.h>
+
+#include "rcar-sysc.h"
+
+static const struct rcar_sysc_area r8a77990_areas[] __initconst = {
+ { "always-on", 0, 0, R8A77990_PD_ALWAYS_ON, -1, PD_ALWAYS_ON },
+ { "ca53-scu", 0x140, 0, R8A77990_PD_CA53_SCU, R8A77990_PD_ALWAYS_ON,
+ PD_SCU },
+ { "ca53-cpu0", 0x200, 0, R8A77990_PD_CA53_CPU0, R8A77990_PD_CA53_SCU,
+ PD_CPU_NOCR },
+ { "ca53-cpu1", 0x200, 1, R8A77990_PD_CA53_CPU1, R8A77990_PD_CA53_SCU,
+ PD_CPU_NOCR },
+ { "cr7", 0x240, 0, R8A77990_PD_CR7, R8A77990_PD_ALWAYS_ON },
+ { "a3vc", 0x380, 0, R8A77990_PD_A3VC, R8A77990_PD_ALWAYS_ON },
+ { "a2vc1", 0x3c0, 1, R8A77990_PD_A2VC1, R8A77990_PD_A3VC },
+ { "3dg-a", 0x100, 0, R8A77990_PD_3DG_A, R8A77990_PD_ALWAYS_ON },
+ { "3dg-b", 0x100, 1, R8A77990_PD_3DG_B, R8A77990_PD_3DG_A },
+};
+
+const struct rcar_sysc_info r8a77990_sysc_info __initconst = {
+ .areas = r8a77990_areas,
+ .num_areas = ARRAY_SIZE(r8a77990_areas),
+};
diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index 99203bd..95120ac 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -296,6 +296,9 @@ static void __init rcar_sysc_pd_setup(struct rcar_sysc_pd *pd)
#ifdef CONFIG_SYSC_R8A77980
{ .compatible = "renesas,r8a77980-sysc", .data = &r8a77980_sysc_info },
#endif
+#ifdef CONFIG_SYSC_R8A77990
+ { .compatible = "renesas,r8a77990-sysc", .data = &r8a77990_sysc_info },
+#endif
#ifdef CONFIG_SYSC_R8A77995
{ .compatible = "renesas,r8a77995-sysc", .data = &r8a77995_sysc_info },
#endif
diff --git a/drivers/soc/renesas/rcar-sysc.h b/drivers/soc/renesas/rcar-sysc.h
index 9b24e3a..a22e7cf 100644
--- a/drivers/soc/renesas/rcar-sysc.h
+++ b/drivers/soc/renesas/rcar-sysc.h
@@ -62,6 +62,7 @@ struct rcar_sysc_info {
extern const struct rcar_sysc_info r8a77965_sysc_info;
extern const struct rcar_sysc_info r8a77970_sysc_info;
extern const struct rcar_sysc_info r8a77980_sysc_info;
+extern const struct rcar_sysc_info r8a77990_sysc_info;
extern const struct rcar_sysc_info r8a77995_sysc_info;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2] soc: renesas: r8a77990-sysc: Add workaround for 3DG-{A,B}
From: Yoshihiro Shimoda @ 2018-05-15 12:07 UTC (permalink / raw)
To: horms, magnus.damm, robh+dt, mark.rutland
Cc: devicetree, linux-renesas-soc, Yoshihiro Shimoda
In-Reply-To: <1526386059-6173-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>
This patch adds workaround for 3DG-{A,B} of R-Car E3 ES1.0 because
the SoC has a restriction about the order.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/soc/renesas/r8a77990-sysc.c | 37 ++++++++++++++++++++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/renesas/r8a77990-sysc.c b/drivers/soc/renesas/r8a77990-sysc.c
index a8c6417..15579eb 100644
--- a/drivers/soc/renesas/r8a77990-sysc.c
+++ b/drivers/soc/renesas/r8a77990-sysc.c
@@ -7,12 +7,13 @@
#include <linux/bug.h>
#include <linux/kernel.h>
+#include <linux/sys_soc.h>
#include <dt-bindings/power/r8a77990-sysc.h>
#include "rcar-sysc.h"
-static const struct rcar_sysc_area r8a77990_areas[] __initconst = {
+static struct rcar_sysc_area r8a77990_areas[] __initdata = {
{ "always-on", 0, 0, R8A77990_PD_ALWAYS_ON, -1, PD_ALWAYS_ON },
{ "ca53-scu", 0x140, 0, R8A77990_PD_CA53_SCU, R8A77990_PD_ALWAYS_ON,
PD_SCU },
@@ -27,7 +28,41 @@
{ "3dg-b", 0x100, 1, R8A77990_PD_3DG_B, R8A77990_PD_3DG_A },
};
+static void __init rcar_sysc_fix_parent(struct rcar_sysc_area *areas,
+ unsigned int num_areas, u8 id,
+ int new_parent)
+{
+ unsigned int i;
+
+ for (i = 0; i < num_areas; i++)
+ if (areas[i].isr_bit == id) {
+ areas[i].parent = new_parent;
+ return;
+ }
+}
+
+/* Fixups for R-Car E3 ES1.0 revision */
+static const struct soc_device_attribute r8a77990[] __initconst = {
+ { .soc_id = "r8a77990", .revision = "ES1.0" },
+ { /* sentinel */ }
+};
+
+static int __init r8a77990_sysc_init(void)
+{
+ if (soc_device_match(r8a77990)) {
+ rcar_sysc_fix_parent(r8a77990_areas,
+ ARRAY_SIZE(r8a77990_areas),
+ R8A77990_PD_3DG_A, R8A77990_PD_3DG_B);
+ rcar_sysc_fix_parent(r8a77990_areas,
+ ARRAY_SIZE(r8a77990_areas),
+ R8A77990_PD_3DG_B, R8A77990_PD_ALWAYS_ON);
+ }
+
+ return 0;
+}
+
const struct rcar_sysc_info r8a77990_sysc_info __initconst = {
+ .init = r8a77990_sysc_init,
.areas = r8a77990_areas,
.num_areas = ARRAY_SIZE(r8a77990_areas),
};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 0/2] USB: dwc3: get extcon device by OF graph bindings
From: Andrzej Hajda @ 2018-05-15 12:12 UTC (permalink / raw)
To: open list:DESIGNWARE USB3 DRD IP DRIVER
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Felipe Balbi, Greg Kroah-Hartman, Inki Dae, Rob Herring,
Mark Rutland, Krzysztof Kozlowski, Chanwoo Choi, Laurent Pinchart,
linux-kernel, linux-samsung-soc
In-Reply-To: <CGME20180515121250eucas1p115e0ee3cefb47faacbd4e4583b11f6e8@eucas1p1.samsung.com>
Hi,
This small patchset tries to address issue with broken DT extcon property
in case of USB controller - DWC3. It exposes similar problem as in proposed
USB connector bindings[1] - extcon device is required by devices not always
connected directly to extcon device. Here we have:
DWC3 -> USB-PHY -> MUIC -> USB-connector
^
MHL-bridge---------------------^
More details and proposition of generic solution in first patch
v2:
- rebased on latest linux-next,
- since recently dwc3 fallbacks to ID detection using internal OTG block if
extcon property is not present, added code allowing to fallback to OTG
block also in case of graph is not present
[1]: https://marc.info/?i=20180131134435.12216-1-a.hajda%40samsung.com
Regards
Andrzej
Andrzej Hajda (2):
USB: dwc3: get extcon device by OF graph bindings
arm64: dts: exynos: add OF graph between USB-PHY and MUIC
.../dts/exynos/exynos5433-tm2-common.dtsi | 19 ++++++++++-
drivers/usb/dwc3/drd.c | 34 +++++++++++++++----
2 files changed, 46 insertions(+), 7 deletions(-)
--
2.17.0
^ permalink raw reply
* [PATCH v2 1/2] USB: dwc3: get extcon device by OF graph bindings
From: Andrzej Hajda @ 2018-05-15 12:12 UTC (permalink / raw)
To: open list:DESIGNWARE USB3 DRD IP DRIVER
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Felipe Balbi, Greg Kroah-Hartman, Inki Dae, Rob Herring,
Mark Rutland, Krzysztof Kozlowski, Chanwoo Choi, Laurent Pinchart,
linux-kernel, linux-samsung-soc
In-Reply-To: <20180515121239.18192-1-a.hajda@samsung.com>
extcon device is used to detect host/device connection. Since extcon
OF property is deprecated, alternative method should be added.
This method uses OF graph bindings to locate extcon.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
---
drivers/usb/dwc3/drd.c | 34 ++++++++++++++++++++++++++++------
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
index 1d8c557e97e0..270682486f82 100644
--- a/drivers/usb/dwc3/drd.c
+++ b/drivers/usb/dwc3/drd.c
@@ -8,6 +8,7 @@
*/
#include <linux/extcon.h>
+#include <linux/of_graph.h>
#include <linux/platform_device.h>
#include "debug.h"
@@ -439,17 +440,38 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
return NOTIFY_DONE;
}
+struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
+{
+ struct device *dev = dwc->dev;
+ struct device_node *np_phy, *np_conn;
+ struct extcon_dev *edev;
+
+ if (of_property_read_bool(dev->of_node, "extcon"))
+ return extcon_get_edev_by_phandle(dwc->dev, 0);
+
+ np_phy = of_parse_phandle(dev->of_node, "phys", 0);
+ np_conn = of_graph_get_remote_node(np_phy, -1, -1);
+
+ if (np_conn)
+ edev = extcon_find_edev_by_node(np_conn);
+ else
+ edev = NULL;
+
+ of_node_put(np_conn);
+ of_node_put(np_phy);
+
+ return edev;
+}
+
int dwc3_drd_init(struct dwc3 *dwc)
{
int ret, irq;
- if (dwc->dev->of_node &&
- of_property_read_bool(dwc->dev->of_node, "extcon")) {
- dwc->edev = extcon_get_edev_by_phandle(dwc->dev, 0);
-
- if (IS_ERR(dwc->edev))
- return PTR_ERR(dwc->edev);
+ dwc->edev = dwc3_get_extcon(dwc);
+ if (IS_ERR(dwc->edev))
+ return PTR_ERR(dwc->edev);
+ if (dwc->edev) {
dwc->edev_nb.notifier_call = dwc3_drd_notifier;
ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
&dwc->edev_nb);
--
2.17.0
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: exynos: add OF graph between USB-PHY and MUIC
From: Andrzej Hajda @ 2018-05-15 12:12 UTC (permalink / raw)
To: open list:DESIGNWARE USB3 DRD IP DRIVER
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Felipe Balbi, Greg Kroah-Hartman, Inki Dae, Rob Herring,
Mark Rutland, Krzysztof Kozlowski, Chanwoo Choi, Laurent Pinchart,
linux-kernel, linux-samsung-soc
In-Reply-To: <20180515121239.18192-1-a.hajda@samsung.com>
OF graph describes USB data lanes between USB-PHY and respective MUIC.
Since graph is present and DWC driver can use it to get extcon, obsolete
extcon property can be removed.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
---
.../dts/exynos/exynos5433-tm2-common.dtsi | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 03453b822093..042e5894a138 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -868,6 +868,18 @@
};
};
};
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ muic_to_usb: endpoint {
+ remote-endpoint = <&usb_to_muic>;
+ };
+ };
+ };
};
regulators {
@@ -1287,12 +1299,17 @@
&usbdrd_dwc3 {
dr_mode = "otg";
- extcon = <&muic>;
};
&usbdrd30_phy {
vbus-supply = <&safeout1_reg>;
status = "okay";
+
+ port {
+ usb_to_muic: endpoint {
+ remote-endpoint = <&muic_to_usb>;
+ };
+ };
};
&xxti {
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] arm64: dts: exynos: add OF graph between USB-PHY and MUIC
From: Krzysztof Kozlowski @ 2018-05-15 12:19 UTC (permalink / raw)
To: Andrzej Hajda
Cc: open list:DESIGNWARE USB3 DRD IP DRIVER,
Bartlomiej Zolnierkiewicz, Marek Szyprowski,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Felipe Balbi, Greg Kroah-Hartman, Inki Dae, Rob Herring,
Mark Rutland, Chanwoo Choi, Laurent Pinchart, linux-kernel,
linux-samsung-soc@vger.kernel.org
In-Reply-To: <20180515121239.18192-3-a.hajda@samsung.com>
On Tue, May 15, 2018 at 2:12 PM, Andrzej Hajda <a.hajda@samsung.com> wrote:
> OF graph describes USB data lanes between USB-PHY and respective MUIC.
> Since graph is present and DWC driver can use it to get extcon, obsolete
> extcon property can be removed.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> ---
> .../dts/exynos/exynos5433-tm2-common.dtsi | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
As we discussed for v1 - since this was not split into two, I'll apply
it once first patch hits mainline.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/2] m_can support to stm32mp157c
From: Erwan Le Ray @ 2018-05-15 12:23 UTC (permalink / raw)
To: Maxime Coquelin, arnd, robh+dt, mark.rutland, linux
Cc: devicetree, bich.hemon, Alexandre Torgue, linux-arm-kernel,
erwan.leray
Add support for the Controller Area Network m_can to STM32MP157C SoC and
activation on stm32mp157c-ev1 board
Bich Hemon (2):
ARM: dts: stm32: m_can support to stm32mp157c
ARM: dts: stm32: m_can activation on stm32mp157c-ev1
arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 13 +++++++++++++
arch/arm/boot/dts/stm32mp157c-ev1.dts | 6 ++++++
arch/arm/boot/dts/stm32mp157c.dtsi | 26 ++++++++++++++++++++++++++
3 files changed, 45 insertions(+)
--
1.9.1
^ permalink raw reply
* [PATCH 1/2] ARM: dts: stm32: m_can support to stm32mp157c
From: Erwan Le Ray @ 2018-05-15 12:23 UTC (permalink / raw)
To: Maxime Coquelin, arnd, robh+dt, mark.rutland, linux
Cc: devicetree, bich.hemon, Alexandre Torgue, linux-arm-kernel,
erwan.leray
In-Reply-To: <1526387039-14813-1-git-send-email-erwan.leray@st.com>
Add support for the Controller Area Network m_can to STM32MP157C SoC.
Signed-off-by: Bich Hemon <bich.hemon@st.com>
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
index b66f673..12ac73f 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -556,6 +556,32 @@
};
};
+ m_can1: can@4400e000 {
+ compatible = "bosch,m_can";
+ reg = <0x4400e000 0x400>, <0x44011000 0x2800>;
+ reg-names = "m_can", "message_ram";
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "int0", "int1";
+ clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+ clock-names = "hclk", "cclk";
+ bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
+ status = "disabled";
+ };
+
+ m_can2: can@4400f000 {
+ compatible = "bosch,m_can";
+ reg = <0x4400f000 0x400>, <0x44011000 0x2800>;
+ reg-names = "m_can", "message_ram";
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "int0", "int1";
+ clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+ clock-names = "hclk", "cclk";
+ bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
+ status = "disabled";
+ };
+
dma1: dma@48000000 {
compatible = "st,stm32-dma";
reg = <0x48000000 0x400>;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: stm32: m_can activation on stm32mp157c-ev1
From: Erwan Le Ray @ 2018-05-15 12:23 UTC (permalink / raw)
To: Maxime Coquelin, arnd, robh+dt, mark.rutland, linux
Cc: devicetree, bich.hemon, Alexandre Torgue, linux-arm-kernel,
erwan.leray
In-Reply-To: <1526387039-14813-1-git-send-email-erwan.leray@st.com>
Add activation of the Controller Area Network m_can on stm32mp157c-ev1
board.
Signed-off-by: Bich Hemon <bich.hemon@st.com>
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
index 88e9133..2e4c5e3 100644
--- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
@@ -185,6 +185,19 @@
};
};
+ m_can1_pins_a: m_can1-0 {
+ pins1 {
+ pinmux = <STM32_PINMUX('H', 13, AF9)>; /* CAN1_TX */
+ slew-rate = <1>;
+ drive-push-pull;
+ bias-disable;
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('I', 9, AF9)>; /* CAN1_RX */
+ bias-disable;
+ };
+ };
+
pwm2_pins_a: pwm2-0 {
pins {
pinmux = <STM32_PINMUX('A', 3, AF1)>; /* TIM2_CH4 */
diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
index 9382d80..3be73d2 100644
--- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
@@ -42,6 +42,12 @@
status = "okay";
};
+&m_can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&m_can1_pins_a>;
+ status = "okay";
+};
+
&qspi {
pinctrl-names = "default";
pinctrl-0 = <&qspi_clk_pins_a &qspi_bk1_pins_a &qspi_bk2_pins_a>;
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3] enable ccree on Renesas R-Car platform
From: Gilad Ben-Yossef @ 2018-05-15 12:29 UTC (permalink / raw)
To: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Michael Turquette, Stephen Boyd, Herbert Xu, David S. Miller
Cc: Ofir Drang, linux-renesas-soc, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-crypto
The following patch set enables CryptoCell present in the Renesas
R-Car SoC.
Gilad Ben-Yossef (3):
crypto: ccree: drop signature register check
clk: renesas: r8a7795: Add ccree clock
arm64: dts: renesas: r8a7795: add ccree binding
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 8 ++++++++
drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
drivers/crypto/ccree/cc_driver.c | 18 +++---------------
3 files changed, 12 insertions(+), 15 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] crypto: ccree: drop signature register check
From: Gilad Ben-Yossef @ 2018-05-15 12:29 UTC (permalink / raw)
To: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Michael Turquette, Stephen Boyd, Herbert Xu, David S. Miller
Cc: Ofir Drang, linux-renesas-soc, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-crypto
In-Reply-To: <1526387370-17142-1-git-send-email-gilad@benyossef.com>
We were using the content of the signature register as a sanity
check for the hardware functioning but it turns out not all
implementers use the same values so the check is giving false
negative on certain SoCs and so we drop it.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
---
drivers/crypto/ccree/cc_driver.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/crypto/ccree/cc_driver.c b/drivers/crypto/ccree/cc_driver.c
index 89ce013..f8ff358 100644
--- a/drivers/crypto/ccree/cc_driver.c
+++ b/drivers/crypto/ccree/cc_driver.c
@@ -38,21 +38,20 @@ MODULE_PARM_DESC(cc_dump_bytes, "Dump buffers to kernel log as debugging aid");
struct cc_hw_data {
char *name;
enum cc_hw_rev rev;
- u32 sig;
};
/* Hardware revisions defs. */
static const struct cc_hw_data cc712_hw = {
- .name = "712", .rev = CC_HW_REV_712, .sig = 0xDCC71200U
+ .name = "712", .rev = CC_HW_REV_712
};
static const struct cc_hw_data cc710_hw = {
- .name = "710", .rev = CC_HW_REV_710, .sig = 0xDCC63200U
+ .name = "710", .rev = CC_HW_REV_710
};
static const struct cc_hw_data cc630p_hw = {
- .name = "630P", .rev = CC_HW_REV_630, .sig = 0xDCC63000U
+ .name = "630P", .rev = CC_HW_REV_630
};
static const struct of_device_id arm_ccree_dev_of_match[] = {
@@ -186,7 +185,6 @@ static int init_cc_resources(struct platform_device *plat_dev)
struct cc_drvdata *new_drvdata;
struct device *dev = &plat_dev->dev;
struct device_node *np = dev->of_node;
- u32 signature_val;
u64 dma_mask;
const struct cc_hw_data *hw_rev;
const struct of_device_id *dev_id;
@@ -275,16 +273,6 @@ static int init_cc_resources(struct platform_device *plat_dev)
return rc;
}
- /* Verify correct mapping */
- signature_val = cc_ioread(new_drvdata, CC_REG(HOST_SIGNATURE));
- if (signature_val != hw_rev->sig) {
- dev_err(dev, "Invalid CC signature: SIGNATURE=0x%08X != expected=0x%08X\n",
- signature_val, hw_rev->sig);
- rc = -EINVAL;
- goto post_clk_err;
- }
- dev_dbg(dev, "CC SIGNATURE=0x%08X\n", signature_val);
-
/* Display HW versions */
dev_info(dev, "ARM CryptoCell %s Driver: HW version 0x%08X, Driver version %s\n",
hw_rev->name, cc_ioread(new_drvdata, CC_REG(HOST_VERSION)),
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] clk: renesas: r8a7795: Add ccree clock
From: Gilad Ben-Yossef @ 2018-05-15 12:29 UTC (permalink / raw)
To: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Michael Turquette, Stephen Boyd, Herbert Xu, David S. Miller
Cc: Ofir Drang, linux-renesas-soc, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-crypto
In-Reply-To: <1526387370-17142-1-git-send-email-gilad@benyossef.com>
This patch adds the clock used by the CryptoCell 630p instance in the SoC.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
---
drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index 775b0ce..642706a 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -132,6 +132,7 @@ static struct mssr_mod_clk r8a7795_mod_clks[] __initdata = {
DEF_MOD("sys-dmac2", 217, R8A7795_CLK_S0D3),
DEF_MOD("sys-dmac1", 218, R8A7795_CLK_S0D3),
DEF_MOD("sys-dmac0", 219, R8A7795_CLK_S0D3),
+ DEF_MOD("ccree", 229, R8A7795_CLK_S3D2),
DEF_MOD("cmt3", 300, R8A7795_CLK_R),
DEF_MOD("cmt2", 301, R8A7795_CLK_R),
DEF_MOD("cmt1", 302, R8A7795_CLK_R),
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Gilad Ben-Yossef @ 2018-05-15 12:29 UTC (permalink / raw)
To: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Michael Turquette, Stephen Boyd, Herbert Xu, David S. Miller
Cc: Ofir Drang, linux-renesas-soc, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-crypto
In-Reply-To: <1526387370-17142-1-git-send-email-gilad@benyossef.com>
Add bindings for CryptoCell instance in the SoC.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 91486b4..6c76841 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -528,6 +528,14 @@
status = "disabled";
};
+ arm_cc630p: crypto@e6601000 {
+ compatible = "arm,cryptocell-630p-ree";
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <2>;
+ reg = <0x0 0xe6601000 0 0x1000>;
+ clocks = <&cpg CPG_MOD 229>;
+ };
+
i2c3: i2c@e66d0000 {
#address-cells = <1>;
#size-cells = <0>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd
From: Radu Pirea @ 2018-05-15 12:47 UTC (permalink / raw)
To: Richard Genoud, devicetree, linux-serial, linux-kernel,
linux-arm-kernel, linux-spi
Cc: mark.rutland, robh+dt, lee.jones, gregkh, jslaby,
alexandre.belloni, nicolas.ferre, broonie
In-Reply-To: <4a75568e-a52e-3872-f465-d707372a5c12@sorico.fr>
[-- Attachment #1: Type: text/plain, Size: 6813 bytes --]
On Mon, 2018-05-14 at 12:57 +0200, Richard Genoud wrote:
> Hi,
>
> On 11/05/2018 12:38, Radu Pirea wrote:
> > This patch modifies the place where resources and device tree
> > properties
> > are searched.
> >
> > Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
> > ---
> > drivers/tty/serial/Kconfig | 1 +
> > drivers/tty/serial/atmel_serial.c | 29 +++++++++++++++----------
> > ----
> > 2 files changed, 16 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/tty/serial/Kconfig
> > b/drivers/tty/serial/Kconfig
> > index 3682fd3e960c..25e55332f8b1 100644
> > --- a/drivers/tty/serial/Kconfig
> > +++ b/drivers/tty/serial/Kconfig
> > @@ -119,6 +119,7 @@ config SERIAL_ATMEL
> > depends on ARCH_AT91 || COMPILE_TEST
> > select SERIAL_CORE
> > select SERIAL_MCTRL_GPIO if GPIOLIB
> > + select MFD_AT91_USART
> > help
> > This enables the driver for the on-chip UARTs of the
> > Atmel
> > AT91 processors.
> > diff --git a/drivers/tty/serial/atmel_serial.c
> > b/drivers/tty/serial/atmel_serial.c
> > index df46a9e88c34..6b4494352853 100644
> > --- a/drivers/tty/serial/atmel_serial.c
> > +++ b/drivers/tty/serial/atmel_serial.c
> > @@ -193,8 +193,8 @@ static struct console atmel_console;
> >
> > #if defined(CONFIG_OF)
> > static const struct of_device_id atmel_serial_dt_ids[] = {
> > - { .compatible = "atmel,at91rm9200-usart" },
> > - { .compatible = "atmel,at91sam9260-usart" },
> > + { .compatible = "atmel,at91rm9200-usart-serial" },
> > + { .compatible = "atmel,at91sam9260-usart-serial" },
> > { /* sentinel */ }
> > };
> > #endif
> > @@ -1631,7 +1631,7 @@ static void atmel_tasklet_tx_func(unsigned
> > long data)
> > static void atmel_init_property(struct atmel_uart_port
> > *atmel_port,
> > struct platform_device *pdev)
> > {
> > - struct device_node *np = pdev->dev.of_node;
> > + struct device_node *np = pdev->dev.parent->of_node;
> >
> > /* DMA/PDC usage specification */
> > if (of_property_read_bool(np, "atmel,use-dma-rx")) {
> > @@ -2223,7 +2223,8 @@ static const char *atmel_type(struct
> > uart_port *port)
> > static void atmel_release_port(struct uart_port *port)
> > {
> > struct platform_device *pdev = to_platform_device(port-
> > >dev);
> > - int size = pdev->resource[0].end - pdev->resource[0].start
> > + 1;
> > + int size = to_platform_device(pdev->dev.parent)-
> > >resource[0].end -
> > + to_platform_device(pdev->dev.parent)-
> > >resource[0].start + 1;
>
> I think it may be simpler with something like:
> + struct platform_device *mfd_pdev = to_platform_device(port-
> >dev->parent);
> + int size = mfd_pdev->resource[0].end - mfd_pdev-
> >resource[0].start + 1;
>
> >
> > release_mem_region(port->mapbase, size);
> >
> > @@ -2239,7 +2240,8 @@ static void atmel_release_port(struct
> > uart_port *port)
> > static int atmel_request_port(struct uart_port *port)
> > {
> > struct platform_device *pdev = to_platform_device(port-
> > >dev);
> > - int size = pdev->resource[0].end - pdev->resource[0].start
> > + 1;
> > + int size = to_platform_device(pdev->dev.parent)-
> > >resource[0].end -
> > + to_platform_device(pdev->dev.parent)-
> > >resource[0].start + 1;
> >
>
> ditto
>
> > if (!request_mem_region(port->mapbase, size,
> > "atmel_serial"))
> > return -EBUSY;
> > @@ -2345,23 +2347,23 @@ static int atmel_init_port(struct
> > atmel_uart_port *atmel_port,
>
> Here, we could also add:
> + struct device *mfd_dev = pdev->dev.parent;
> + struct platform_device *mfd_pdev =
> to_platform_device(mfd_dev);
>
> > atmel_init_property(atmel_port, pdev);
> > atmel_set_ops(port);
> >
> > - uart_get_rs485_mode(&pdev->dev, &port->rs485);
> > + uart_get_rs485_mode(pdev->dev.parent, &port->rs485);
>
> ...and use them here
>
> >
> > port->iotype = UPIO_MEM;
> > port->flags = UPF_BOOT_AUTOCONF |
> > UPF_IOREMAP;
> > port->ops = &atmel_pops;
> > port->fifosize = 1;
> > port->dev = &pdev->dev;
> > - port->mapbase = pdev->resource[0].start;
> > - port->irq = pdev->resource[1].start;
> > + port->mapbase = to_platform_device(pdev-
> > >dev.parent)->resource[0].start;
> > + port->irq = to_platform_device(pdev-
> > >dev.parent)->resource[1].start;
>
> and here
> I think it would be easier to read.
>
> > port->rs485_config = atmel_config_rs485;
> > - port->membase = NULL;
> > + port->membase = NULL;
> >
> > memset(&atmel_port->rx_ring, 0, sizeof(atmel_port-
> > >rx_ring));
> >
> > /* for console, the clock could already be configured */
> > if (!atmel_port->clk) {
> > - atmel_port->clk = clk_get(&pdev->dev, "usart");
> > + atmel_port->clk = clk_get(pdev->dev.parent,
> > "usart");
>
> and here
>
> > if (IS_ERR(atmel_port->clk)) {
> > ret = PTR_ERR(atmel_port->clk);
> > atmel_port->clk = NULL;
> > @@ -2656,7 +2658,7 @@ static void atmel_serial_probe_fifos(struct
> > atmel_uart_port *atmel_port,
> > atmel_port->rts_low = 0;
> > atmel_port->rts_high = 0;
> >
> > - if (of_property_read_u32(pdev->dev.of_node,
> > + if (of_property_read_u32(pdev->dev.parent->of_node,
> > "atmel,fifo-size",
> > &atmel_port->fifo_size))
> > return;
> > @@ -2694,11 +2696,10 @@ static void atmel_serial_probe_fifos(struct
> > atmel_uart_port *atmel_port,
> > static int atmel_serial_probe(struct platform_device *pdev)
> > {
> > struct atmel_uart_port *atmel_port;
> > - struct device_node *np = pdev->dev.of_node;
> > + struct device_node *np = pdev->dev.parent->of_node;
> > void *data;
> > int ret = -ENODEV;
> > bool rs485_enabled;
> > -
>
> I think this line feed wasn't so bad.
>
> > BUILD_BUG_ON(ATMEL_SERIAL_RINGSIZE &
> > (ATMEL_SERIAL_RINGSIZE - 1));
> >
> > ret = of_alias_get_id(np, "serial");
> > @@ -2845,7 +2846,7 @@ static struct platform_driver
> > atmel_serial_driver = {
> > .suspend = atmel_serial_suspend,
> > .resume = atmel_serial_resume,
> > .driver = {
> > - .name = "atmel_usart",
> > + .name =
> > "atmel_usart_serial",
> > .of_match_table =
> > of_match_ptr(atmel_serial_dt_ids),
> > },
> > };
> >
>
> After your patch, the DMA is not selected anymore:
> atmel_usart_serial atmel_usart_serial.0.auto: TX channel not
> available, switch to pio
> instead of:
> atmel_usart fffff200.serial: using dma1chan2 for tx DMA transfers
>
Fixed.
> And the kernel doesn't log anymore on the serial console, despite the
> loglevel=8
> (after reverting this series, the kernel logs reappears on the serial
> console)
>
Which serial are you using as console?
> (tests done on sam9g35)
>
I will consider the rest of suggestions.
> regards,
> Richard
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH trivial] dt-bindings: iio: afe: Spelling s/mesaurement/measurement/
From: Geert Uytterhoeven @ 2018-05-15 13:06 UTC (permalink / raw)
To: Peter Rosin, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Rob Herring, Mark Rutland, Jiri Kosina
Cc: linux-iio, devicetree, Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.txt | 2 +-
Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.txt b/Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.txt
index 0ddbaebba8ceca13..821b61b8c542ff92 100644
--- a/Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.txt
+++ b/Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.txt
@@ -2,7 +2,7 @@ Current Sense Amplifier
=======================
When an io-channel measures the output voltage from a current sense
-amplifier, the interesting mesaurement is almost always the current
+amplifier, the interesting measurement is almost always the current
through the sense resistor, not the voltage output. This binding
describes such a current sense circuit.
diff --git a/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt b/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
index 8e7b3e408a5253c5..0f67108a07b6327b 100644
--- a/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
+++ b/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
@@ -2,7 +2,7 @@ Current Sense Shunt
===================
When an io-channel measures the voltage over a current sense shunt,
-the interesting mesaurement is almost always the current through the
+the interesting measurement is almost always the current through the
shunt, not the voltage over it. This binding describes such a current
sense circuit.
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd
From: Richard Genoud @ 2018-05-15 13:14 UTC (permalink / raw)
To: Radu Pirea, devicetree, linux-serial, linux-kernel,
linux-arm-kernel, linux-spi
Cc: mark.rutland, robh+dt, lee.jones, gregkh, jslaby,
alexandre.belloni, nicolas.ferre, broonie
In-Reply-To: <95a51c6c69bf1a2422f545ac1f06846ebcdb186a.camel@microchip.com>
On 15/05/2018 14:47, Radu Pirea wrote:
> On Mon, 2018-05-14 at 12:57 +0200, Richard Genoud wrote:
>> After your patch, the DMA is not selected anymore:
>> atmel_usart_serial atmel_usart_serial.0.auto: TX channel not
>> available, switch to pio
>> instead of:
>> atmel_usart fffff200.serial: using dma1chan2 for tx DMA transfers
>>
> Fixed.
>> And the kernel doesn't log anymore on the serial console, despite the
>> loglevel=8
>> (after reverting this series, the kernel logs reappears on the serial
>> console)
>>
> Which serial are you using as console?
fffff200.serial (sam9g35-cm)
( stdout-path = "serial0:115200n8"; in the DTS )
With this series applied, all the kernel log goes on the screen.
Without, it goes on the serial debug.
>> (tests done on sam9g35)
>>
> I will consider the rest of suggestions.
>> regards,
>> Richard
^ permalink raw reply
* Re: [PATCH v10 02/27] clk: davinci: da850-pll: change PLL0 to CLK_OF_DECLARE
From: Sekhar Nori @ 2018-05-15 13:31 UTC (permalink / raw)
To: David Lechner, linux-clk, devicetree, linux-arm-kernel
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Kevin Hilman, Bartosz Golaszewski, Adam Ford, linux-kernel
In-Reply-To: <20180509172606.29387-3-david@lechnology.com>
On Wednesday 09 May 2018 10:55 PM, David Lechner wrote:
> +void of_da850_pll0_init(struct device_node *node)
> {
> - return of_davinci_pll_init(dev, dev->of_node, &da850_pll0_info,
> - &da850_pll0_obsclk_info,
> - da850_pll0_sysclk_info, 7, base, cfgchip);
> + void __iomem *base;
> + struct regmap *cfgchip;
> +
> + base = of_iomap(node, 0);
> + if (!base) {
> + pr_err("%s: ioremap failed\n", __func__);
> + return;
> + }
> +
> + cfgchip = syscon_regmap_lookup_by_compatible("ti,da830-cfgchip");
It will be nice to handle the error case here.
> +
> + of_davinci_pll_init(NULL, node, &da850_pll0_info,
> + &da850_pll0_obsclk_info,
> + da850_pll0_sysclk_info, 7, base, cfgchip);
Apart from that, it looks good to me.
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v4 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN90
From: Maxime Ripard @ 2018-05-15 13:35 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Rob Herring, Mark Rutland,
Chen-Yu Tsai, Thierry Reding, David Airlie
In-Reply-To: <abeac1ee792b8f063001c4c280ca7f0167ac59be.camel-W9ppeneeCTY@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 5695 bytes --]
On Mon, May 14, 2018 at 10:40:15PM +0200, Paul Kocialkowski wrote:
> Le vendredi 11 mai 2018 à 10:59 +0200, Maxime Ripard a écrit :
> > On Wed, May 09, 2018 at 01:31:23PM +0200, Paul Kocialkowski wrote:
> > > On Wed, 2018-05-09 at 09:12 +0200, Maxime Ripard wrote:
> > > > On Tue, May 08, 2018 at 12:04:11AM +0200, Paul Kocialkowski wrote:
> > > > > This adds timings for the RGB666 variant of the Innolux AT070TN90 panel,
> > > > > as found on the Ainol AW1 tablet.
> > > > >
> > > > > The panel also supports RGB888 output. When RGB666 mode is used instead,
> > > > > the two extra lanes per component are grounded.
> > > > >
> > > > > In the future, it might become necessary to introduce a dedicated
> > > > > device-tree property to specify the bus format to use instead of the
> > > > > default one for the panel. This will allow supporting different bus
> > > > > formats for the same panel modes.
> > > > >
> > > > > Signed-off-by: Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org>
> > > > > ---
> > > > > drivers/gpu/drm/panel/panel-simple.c | 26 ++++++++++++++++++++++++++
> > > > > 1 file changed, 26 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > > > > index cbf1ab404ee7..32e30d5a8f08 100644
> > > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > > @@ -1063,6 +1063,29 @@ static const struct panel_desc innolux_at043tn24 = {
> > > > > .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
> > > > > };
> > > > >
> > > > > +static const struct drm_display_mode innolux_at070tn90_mode = {
> > > > > + .clock = 40000,
> > > > > + .hdisplay = 800,
> > > > > + .hsync_start = 800 + 112,
> > > > > + .hsync_end = 800 + 112 + 1,
> > > > > + .htotal = 800 + 112 + 1 + 87,
> > > > > + .vdisplay = 480,
> > > > > + .vsync_start = 480 + 141,
> > > > > + .vsync_end = 480 + 141 + 1,
> > > > > + .vtotal = 480 + 141 + 1 + 38,
> > > > > + .vrefresh = 60,
> > > > > +};
> > > > > +
> > > > > +static const struct panel_desc innolux_at070tn90 = {
> > > > > + .modes = &innolux_at070tn90_mode,
> > > > > + .num_modes = 1,
> > > > > + .size = {
> > > > > + .width = 154,
> > > > > + .height = 86,
> > > > > + },
> > > > > + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> > > > > +};
> > > > > +
> > > >
> > > > I'm not really convinced this is the right approach. You said it
> > > > yourself, the panel is using a 24-bits interface, and you just happen
> > > > to have a tablet that routed it using a 18-bits interface instead.
> > > >
> > > > That doesn't belong in the driver, especially associated to the
> > > > compatible, but where the routing is described: in the device
> > > > tree. And given that the panel interface is a 24 bits panel, if we
> > > > were to have a default, we should have this one, and not the one
> > > > fitting your use case.
> > >
> > > I fully agree, this is why I suggested introducing a dedicated dt
> > > property for selecting the bus format (in the commit message). I still
> > > proposed this patch as a temporary solution, but I'm definitely willing
> > > to craft a proper solution as well.
> > >
> > > Here is an initial proposition:
> > > 1. Making bus_format an array in struct panel_desc and listing all the
> > > relevant bus formats that the panel can support there;
> >
> > I'm not sure this is needed, the input format is always the same in
> > your case, the panel will always take a 24 bits RGB value. What you
> > want to change is the encoder output format (and I guess you want that
> > to be meaningful to enable or not the dithering).
>
> Isn't the panel format supposed to match what the encoder's output
> should be aiming for? In my case, that would be RGB666, so the idea
> would be specifying both MEDIA_BUS_FMT_RGB666_1X18 and
> MEDIA_BUS_FMT_RGB888_1X24 in a list of supported bus formats for the
> panel.
The width your panel has in input is in 24 bits. The width the encoder
outputs in is 16 bits. This is the panel driver, you should expose the
panel capabilities.
> This way, both my setup and RGB888 setups can be supported.
I don't see what prevents you to do that with my suggestion either.
> > > 2. Introducing an optional "bus-format" dt property that indicates which
> > > bus format to use, and using the first index of the bus formats array if
> > > the property is not present;
> >
> > I guess the width would be enough, and that way we can take the
> > bus-width format that is already defined (but used in the v4l2
> > framework, not in DRM yet).
>
> Well, we already have bus-format defines on the DRM side and it feels
> like mapping these directly in device-tree would be more useful as a
> description of the hardware than just having the bus width.
Having the format in the DT doesn't make much sense. A given panel can
support multiple formats, just like a given encoder can.
If you're in that situation, the DT would describe a policy over what
happens in the OS, which isn't what should be stored in the DT. The
bus width, on the other end, is a property of the hardware.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ 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