Re: [PATCH] arm64: dts: renesas: r8a7795: add missing dma-names on hscif2
On Fri, Sep 28, 2018 at 4:38 AM Kuninori Morimoto
wrote:
> From: Kuninori Morimoto
>
> hscif2 has 4 dmas, but has only 2 dma-names.
> This patch add missing dma-names.
Nice catch!
> Signed-off-by: Kuninori Morimoto
Fixes: e0f0bda79337701a ("arm64: dts: renesas: r8a7795: sort subnodes
of the soc node")
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
[PATCH] arm64: dts: renesas: r8a7795: remove unneeded sound #address/size-cells
From: Kuninori Morimoto
commit 2d87dc0e5be2 ("arm64: dts: renesas: r8a7795: Add address
properties to rcar_sound port nodes") added missing #address-cells
and #size-cells for sound ports.
But, these are based on platform, not on SoC. This patch cleanups it.
Signed-off-by: Kuninori Morimoto
---
arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts | 2 ++
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 2 ++
arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts| 2 ++
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 14 --
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 3 +++
5 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
index 0895503..c1a56ea 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
@@ -112,6 +112,7 @@
ports {
/* rsnd_port0 is on salvator-common */
rsnd_port1: port@1 {
+ reg = <1>;
rsnd_endpoint1: endpoint {
remote-endpoint = <&dw_hdmi0_snd_in>;
@@ -123,6 +124,7 @@
};
};
rsnd_port2: port@2 {
+ reg = <2>;
rsnd_endpoint2: endpoint {
remote-endpoint = <&dw_hdmi1_snd_in>;
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 1620e8d..d2d48b3 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -112,6 +112,7 @@
ports {
/* rsnd_port0 is on salvator-common */
rsnd_port1: port@1 {
+ reg = <1>;
rsnd_endpoint1: endpoint {
remote-endpoint = <&dw_hdmi0_snd_in>;
@@ -123,6 +124,7 @@
};
};
rsnd_port2: port@2 {
+ reg = <2>;
rsnd_endpoint2: endpoint {
remote-endpoint = <&dw_hdmi1_snd_in>;
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
index cf08a11..42101fc 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
@@ -127,6 +127,7 @@
ports {
/* rsnd_port0 is on salvator-common */
rsnd_port1: port@1 {
+ reg = <1>;
rsnd_endpoint1: endpoint {
remote-endpoint = <&dw_hdmi0_snd_in>;
@@ -138,6 +139,7 @@
};
};
rsnd_port2: port@2 {
+ reg = <2>;
rsnd_endpoint2: endpoint {
remote-endpoint = <&dw_hdmi1_snd_in>;
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index a79c8d3..5f6020e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1972,20 +1972,6 @@
dma-names = "rx", "tx", "rxu", "txu";
};
};
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
- port@0 {
- reg = <0>;
- };
- port@1 {
- reg = <1>;
- };
- port@2 {
- reg = <2>;
- };
- };
};
audma0: dma-controller@ec70 {
diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 7f91ff5..054a7ee 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -707,7 +707,10 @@
<&cpg CPG_CORE CPG_AUDIO_CLK_I>;
ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
rsnd_port0: port@0 {
+ reg = <0>;
rsnd_endpoint0: endpoint {
remote-endpoint = <&ak4613_endpoint>;
--
2.7.4
[PATCH] arm64: dts: renesas: r8a7795: add missing dma-names on hscif2
From: Kuninori Morimoto hscif2 has 4 dmas, but has only 2 dma-names. This patch add missing dma-names. Signed-off-by: Kuninori Morimoto --- Hi Simon, Geert I think this is bugfix, but I'm not sure detail of scif... arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index b5f2273..a79c8d3 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi @@ -652,7 +652,7 @@ clock-names = "fck", "brg_int", "scif_clk"; dmas = <&dmac1 0x35>, <&dmac1 0x34>, <&dmac2 0x35>, <&dmac2 0x34>; - dma-names = "tx", "rx"; + dma-names = "tx", "rx", "tx", "rx"; power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; resets = <&cpg 518>; status = "disabled"; -- 2.7.4
Re: [PATCH resend] can: rcar_can: convert to SPDX identifiers
Hi Marc > > From: Kuninori Morimoto > > > > This patch updates license to use SPDX-License-Identifier > > instead of verbose license text. > > > > Signed-off-by: Kuninori Morimoto > > Reviewed-by: Simon Horman > > Wolfram Sang has already supplied a similar patch, but not for Makefile > and Kconfig. I've applied your patch for Makefile and Kconfig and > adjusted the commit message accordingly. Thank you very much
Re: [PATCH linux-next 01/10] ASoC: rsnd: ssi: Request dedicated dma channels for busif1 to 7
Hi Jiada
Cc: linux-renesas-soc ML
Thank you for your patch
> From: Jiada Wang
>
> Currently ssi driver only request dma channel for SSI_0,
> which is used to transfer data to/from busif0.
>
> But since busif1 to busif7 also maybe used, dedicated dma channels
> are request for data transfer between these busif.
>
> Signed-off-by: Jiada Wang
> ---
(snip)
> @@ -938,12 +940,20 @@ static struct dma_chan *rsnd_ssi_dma_req(struct
> rsnd_dai_stream *io,
> {
> struct rsnd_priv *priv = rsnd_mod_to_priv(mod);
> int is_play = rsnd_io_is_play(io);
> - char *name;
> + int busif = rsnd_ssi_get_busif(io);
> + char name[SSI_DMA_NAME_SIZE];
>
> - if (rsnd_ssi_use_busif(io))
> - name = is_play ? "rxu" : "txu";
> - else
> - name = is_play ? "rx" : "tx";
> + if (rsnd_ssi_use_busif(io)) {
> + if (is_play)
> + snprintf(name, SSI_DMA_NAME_SIZE, "rxu%d", busif);
> + else
> + snprintf(name, SSI_DMA_NAME_SIZE, "txu%d", busif);
> + } else {
> + if (is_play)
> + snprintf(name, SSI_DMA_NAME_SIZE, "rx");
> + else
> + snprintf(name, SSI_DMA_NAME_SIZE, "tx");
> + }
Unfortunately, this patch breaks "git bisect", and Gen2 platforms.
We need to keep existing "rxu/txu" more. Please consider compatibility.
# we can remove it 2 or 3 version later ?
If the commit which has this patch, but doesn't have [02/xx] or later,
it can't use BUSIF.
And your patch doesn't care Gen2 series.
DT compatibility is very sensitive...
Applied "spi: spi-mem: Fix inverted logic in op sanity check" to the spi tree
The patch
spi: spi-mem: Fix inverted logic in op sanity check
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From aea3877e24f3acc6145094848dbb85f9ce85674a Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven
Date: Tue, 25 Sep 2018 11:46:55 +0200
Subject: [PATCH] spi: spi-mem: Fix inverted logic in op sanity check
On r8a7791/koelsch:
m25p80 spi0.0: error -22 reading 9f
m25p80: probe of spi0.0 failed with error -22
Apparently the logic in spi_mem_check_op() is wrong, rejecting the
spi-mem operation if any buswidth is valid, instead of invalid.
Fixes: 380583227c0c7f52 ("spi: spi-mem: Add extra sanity checks on the op
param")
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Boris Brezillon
Signed-off-by: Mark Brown
---
drivers/spi/spi-mem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index cc3d425aae56..62a7b80801d2 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -169,10 +169,10 @@ static int spi_mem_check_op(const struct spi_mem_op *op)
(op->data.nbytes && !op->data.buswidth))
return -EINVAL;
- if (spi_mem_buswidth_is_valid(op->cmd.buswidth) ||
- spi_mem_buswidth_is_valid(op->addr.buswidth) ||
- spi_mem_buswidth_is_valid(op->dummy.buswidth) ||
- spi_mem_buswidth_is_valid(op->data.buswidth))
+ if (!spi_mem_buswidth_is_valid(op->cmd.buswidth) ||
+ !spi_mem_buswidth_is_valid(op->addr.buswidth) ||
+ !spi_mem_buswidth_is_valid(op->dummy.buswidth) ||
+ !spi_mem_buswidth_is_valid(op->data.buswidth))
return -EINVAL;
return 0;
--
2.19.0
Applied "dt-bindings: spi: rspi: Add R7S9210 support" to the spi tree
The patch dt-bindings: spi: rspi: Add R7S9210 support has been applied to the spi tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 73569a50959e4ec63bcf05839a030e799a350de1 Mon Sep 17 00:00:00 2001 From: Chris Brandt Date: Thu, 27 Sep 2018 09:35:19 -0500 Subject: [PATCH] dt-bindings: spi: rspi: Add R7S9210 support Add support for RZ/A2 Signed-off-by: Chris Brandt Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-rspi.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/spi/spi-rspi.txt b/Documentation/devicetree/bindings/spi/spi-rspi.txt index 96fd58548f69..dd5c36a0b9ac 100644 --- a/Documentation/devicetree/bindings/spi/spi-rspi.txt +++ b/Documentation/devicetree/bindings/spi/spi-rspi.txt @@ -3,7 +3,7 @@ Device tree configuration for Renesas RSPI/QSPI driver Required properties: - compatible : For Renesas Serial Peripheral Interface on legacy SH: "renesas,rspi-", "renesas,rspi" as fallback. -For Renesas Serial Peripheral Interface on RZ/A1H: +For Renesas Serial Peripheral Interface on RZ/A: "renesas,rspi-", "renesas,rspi-rz" as fallback. For Quad Serial Peripheral Interface on R-Car Gen2 and RZ/G1 devices: @@ -11,6 +11,7 @@ Required properties: Examples with soctypes are: - "renesas,rspi-sh7757" (SH) - "renesas,rspi-r7s72100" (RZ/A1H) + - "renesas,rspi-r7s9210" (RZ/A2) - "renesas,qspi-r8a7743" (RZ/G1M) - "renesas,qspi-r8a7745" (RZ/G1E) - "renesas,qspi-r8a7790" (R-Car H2) -- 2.19.0
Applied "ASoC: rsnd: Add r8a7744 support" to the asoc tree
The patch ASoC: rsnd: Add r8a7744 support has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 765f50d464457c6a397506b3f3dc58dacc227c6d Mon Sep 17 00:00:00 2001 From: Biju Das Date: Thu, 27 Sep 2018 14:51:25 +0100 Subject: [PATCH] ASoC: rsnd: Add r8a7744 support Document RZ/G1N (R8A7744) SoC bindings. Signed-off-by: Biju Das Reviewed-by: Chris Paterson Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index f4688c508be6..d92b705e7917 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -343,6 +343,7 @@ Required properties: "renesas,rcar_sound-gen3" if generation3 (or RZ/G2) Examples with soctypes are: - "renesas,rcar_sound-r8a7743" (RZ/G1M) + - "renesas,rcar_sound-r8a7744" (RZ/G1N) - "renesas,rcar_sound-r8a7745" (RZ/G1E) - "renesas,rcar_sound-r8a774a1" (RZ/G2M) - "renesas,rcar_sound-r8a7778" (R-Car M1A) -- 2.19.0
[PATCH v2] reset: Exclusive resets must be dedicated to a single hardware block
In some SoCs multiple hardware blocks may share a reset control.
The reset control API for shared resets will only assert such a reset
when the drivers for all hardware blocks agree.
The exclusive reset control API still allows to assert such a reset, but
that impacts all other hardware blocks sharing the reset.
While the kernel doc comments clearly state that the API for shared
resets applies to reset controls which are shared between hardware
blocks, the exact meaning of exclusive resets is not documented.
Fix the semantic ambiguity with respect to exclusive access vs.
exclusive reset lines by:
1. Clarifying that exclusive resets really are intended for use with
reset controls which are dedicated to a single hardware block,
2. Ensuring that obtaining an exclusive reset control will fail if the
reset is shared by multiple hardware blocks, for both DT-based and
lookup-based reset controls.
Signed-off-by: Geert Uytterhoeven
---
This is v2 of "[RFC] reset: Add support for dedicated reset controls":
- Fix wrong variable in __reset_is_dedicated() loop,
- Add missing of_node_put() in __of_reset_is_dedicated(),
- Document that exclusive reset controls imply they are dedicated to a
single hardware block,
- Drop new dedicated flag and new API reset_control_get_dedicated(),
as exclusive already implies dedicated,
- Rename {__of_,}reset_is_dedicated() to {__of_,}reset_is_exclusive(),
- Reword description.
Note: Exclusive lookup-based reset controls were not tested.
---
drivers/reset/core.c | 58 +++
include/linux/reset.h | 5 +++-
2 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 225e34c56b94a2e3..2f5b61226c7964eb 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -459,6 +459,38 @@ static void __reset_control_put_internal(struct
reset_control *rstc)
kref_put(&rstc->refcnt, __reset_control_release);
}
+static bool __of_reset_is_exclusive(const struct device_node *node,
+ const struct of_phandle_args args)
+{
+ struct of_phandle_args args2;
+ struct device_node *node2;
+ int index, ret;
+ bool eq;
+
+ for_each_node_with_property(node2, "resets") {
+ if (node == node2)
+ continue;
+
+ for (index = 0; ; index++) {
+ ret = of_parse_phandle_with_args(node2, "resets",
+"#reset-cells", index,
+&args2);
+ if (ret)
+ break;
+
+ eq = (args2.np == args.np &&
+ args2.args_count == args.args_count &&
+ !memcmp(args2.args, args.args,
+ args.args_count * sizeof(args.args[0])));
+ of_node_put(args2.np);
+ if (eq)
+ return false;
+ }
+ }
+
+ return true;
+}
+
struct reset_control *__of_reset_control_get(struct device_node *node,
const char *id, int index, bool shared,
bool optional)
@@ -514,6 +546,11 @@ struct reset_control *__of_reset_control_get(struct
device_node *node,
return ERR_PTR(rstc_id);
}
+ if (!shared && !__of_reset_is_exclusive(node, args)) {
+ mutex_unlock(&reset_list_mutex);
+ return ERR_PTR(-EINVAL);
+ }
+
/* reset_list_mutex also protects the rcdev's reset_control list */
rstc = __reset_control_get_internal(rcdev, rstc_id, shared);
@@ -541,6 +578,22 @@ __reset_controller_by_name(const char *name)
return NULL;
}
+static bool __reset_is_exclusive(const struct reset_control_lookup *lookup)
+{
+ const struct reset_control_lookup *lookup2;
+
+ list_for_each_entry(lookup2, &reset_lookup_list, list) {
+ if (lookup2 == lookup)
+ continue;
+
+ if (lookup2->provider == lookup->provider &&
+ lookup2->index == lookup->index)
+ return false;
+ }
+
+ return true;
+}
+
static struct reset_control *
__reset_control_get_from_lookup(struct device *dev, const char *con_id,
bool shared, bool optional)
@@ -562,6 +615,11 @@ __reset_control_get_from_lookup(struct device *dev, const
char *con_id,
if ((!con_id && !lookup->con_id) ||
((con_id && lookup->con_id) &&
!strcmp(con_id, lookup->con_id))) {
+ if (!shared && !__reset_is_exclusive(lookup)) {
+ mutex_unlock(&reset_lookup_mutex);
+ return ERR_PTR(-EINVAL);
+
Re: [PATCH v6 1/3] dt-bindings: pinctrl: renesas,rzn1-pinctrl: documentation
On Thu, Sep 27, 2018 at 05:15:54PM +0200, Geert Uytterhoeven wrote:
> On Thu, Sep 27, 2018 at 3:59 PM Phil Edworthy
> wrote:
> > The Renesas RZ/N1 device family PINCTRL node description.
> >
> > Based on a patch originally written by Michel Pollet at Renesas.
> >
> > Signed-off-by: Phil Edworthy
> > Reviewed-by: Jacopo Mondi
> > ---
> > v6:
> > - Instead of combining the pin nr and func into a single element, use
> >a pair of 8-bit elements.
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.txt
>
> > +- Pin multiplexing sub-nodes:
> > + A pin multiplexing sub-node describes how to configure a set of
> > + (or a single) pin in some desired alternate function mode.
> > + A single sub-node may define several pin configurations.
> > + Please refer to pinctrl-bindings.txt to get to know more on generic
> > + pin properties usage.
> > +
> > + The allowed generic formats for a pin multiplexing sub-node are the
> > + following ones:
> > +
> > + node-1 {
> > + pinmux = /bits/ 8 , , ... ;
> > + GENERIC_PINCONFIG;
> > + };
>
> and
>
> > + Example:
> > + A serial communication interface with a TX output pin and an RX input
> > pin.
> > +
> > + &pinctrl {
> > + pins_uart0: pins_uart0 {
> > + pinmux = /bits/ 8 <
> > + 103 RZN1_FUNC_UART0_I /* UART0_TXD */
> > + 104 RZN1_FUNC_UART0_I /* UART0_RXD */
> > + >;
> > + };
> > + };
>
> So the above is in response to Rob's comment on v4:
>
> | > +#define RZN1_MUX(_gpio, _func) \
> | > + (((RZN1_FUNC_##_func) << 8) | (_gpio))
> |
> | I'm not a fan of token pasting and it also goes against kernel style.
> | If every other Renesas platform is doing this, then fine. Otherwise,
> | you can express it in pretty much the same (source) space:
> |
> | pinmux = ;
> |
> | Yes, this is 2 cells instead of 1, but if you care about space, you
> | can use 8 or 16 bit size.
>
> I'm not so much impressed by the "/bits/ 8" part.
> No other pinctrl bindings uses this.
> We do have RZA1_PINMUX() and STM32_PINMUX() macros.
Yes, but those aren't doing token pasting which was my complaint here.
> Rob: Is this really what you intended?
Do whatever is most consistant. If you want a macro to shift fields,
then fine.
Rob
Re: [PATCH v6 1/3] dt-bindings: pinctrl: renesas,rzn1-pinctrl: documentation
On Thu, Sep 27, 2018 at 3:59 PM Phil Edworthy wrote:
> The Renesas RZ/N1 device family PINCTRL node description.
>
> Based on a patch originally written by Michel Pollet at Renesas.
>
> Signed-off-by: Phil Edworthy
> Reviewed-by: Jacopo Mondi
> ---
> v6:
> - Instead of combining the pin nr and func into a single element, use
>a pair of 8-bit elements.
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.txt
> +- Pin multiplexing sub-nodes:
> + A pin multiplexing sub-node describes how to configure a set of
> + (or a single) pin in some desired alternate function mode.
> + A single sub-node may define several pin configurations.
> + Please refer to pinctrl-bindings.txt to get to know more on generic
> + pin properties usage.
> +
> + The allowed generic formats for a pin multiplexing sub-node are the
> + following ones:
> +
> + node-1 {
> + pinmux = /bits/ 8 , , ... ;
> + GENERIC_PINCONFIG;
> + };
and
> + Example:
> + A serial communication interface with a TX output pin and an RX input pin.
> +
> + &pinctrl {
> + pins_uart0: pins_uart0 {
> + pinmux = /bits/ 8 <
> + 103 RZN1_FUNC_UART0_I /* UART0_TXD */
> + 104 RZN1_FUNC_UART0_I /* UART0_RXD */
> + >;
> + };
> + };
So the above is in response to Rob's comment on v4:
| > +#define RZN1_MUX(_gpio, _func) \
| > + (((RZN1_FUNC_##_func) << 8) | (_gpio))
|
| I'm not a fan of token pasting and it also goes against kernel style.
| If every other Renesas platform is doing this, then fine. Otherwise,
| you can express it in pretty much the same (source) space:
|
| pinmux = ;
|
| Yes, this is 2 cells instead of 1, but if you care about space, you
| can use 8 or 16 bit size.
I'm not so much impressed by the "/bits/ 8" part.
No other pinctrl bindings uses this.
We do have RZA1_PINMUX() and STM32_PINMUX() macros.
Rob: Is this really what you intended?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
RE: [PATCH] dt-bindings: spi: rspi: Add R7S9210 support
Hi Geert, On Thursday, September 27, 2018 1, Geert Uytterhoeven wrote: > Looks good, but you forgot to update the paragraph above (outside the > quoted context). OK, thanks. Funny...even a 1-line patch requires 2 versions from me! (I wish I got paid per revision) Chris
[PATCH v2] dt-bindings: spi: rspi: Add R7S9210 support
Add support for RZ/A2 Signed-off-by: Chris Brandt --- v2: * Made instructions more generic for RZ/A devices FYI: No driver changes were needed --- Documentation/devicetree/bindings/spi/spi-rspi.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/spi/spi-rspi.txt b/Documentation/devicetree/bindings/spi/spi-rspi.txt index 96fd58548f69..dd5c36a0b9ac 100644 --- a/Documentation/devicetree/bindings/spi/spi-rspi.txt +++ b/Documentation/devicetree/bindings/spi/spi-rspi.txt @@ -3,7 +3,7 @@ Device tree configuration for Renesas RSPI/QSPI driver Required properties: - compatible : For Renesas Serial Peripheral Interface on legacy SH: "renesas,rspi-", "renesas,rspi" as fallback. -For Renesas Serial Peripheral Interface on RZ/A1H: +For Renesas Serial Peripheral Interface on RZ/A: "renesas,rspi-", "renesas,rspi-rz" as fallback. For Quad Serial Peripheral Interface on R-Car Gen2 and RZ/G1 devices: @@ -11,6 +11,7 @@ Required properties: Examples with soctypes are: - "renesas,rspi-sh7757" (SH) - "renesas,rspi-r7s72100" (RZ/A1H) + - "renesas,rspi-r7s9210" (RZ/A2) - "renesas,qspi-r8a7743" (RZ/G1M) - "renesas,qspi-r8a7745" (RZ/G1E) - "renesas,qspi-r8a7790" (R-Car H2) -- 2.16.1
Re: [PATCH] dt-bindings: spi: rspi: Add R7S9210 support
Hi Chris,
On Thu, Sep 27, 2018 at 4:15 PM Chris Brandt wrote:
> Add support for RZ/A2
>
> Signed-off-by: Chris Brandt
Thanks for your patch!
> --- a/Documentation/devicetree/bindings/spi/spi-rspi.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-rspi.txt
> @@ -11,6 +11,7 @@ Required properties:
> Examples with soctypes are:
> - "renesas,rspi-sh7757" (SH)
> - "renesas,rspi-r7s72100" (RZ/A1H)
> + - "renesas,rspi-r7s9210" (RZ/A2)
Looks good, but you forgot to update the paragraph above (outside the
quoted context).
> - "renesas,qspi-r8a7743" (RZ/G1M)
> - "renesas,qspi-r8a7745" (RZ/G1E)
> - "renesas,qspi-r8a7790" (R-Car H2)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
[PATCH] dt-bindings: timer: ostm: Add R7S9210 support
The R7S9210 belongs to the RZ/A2 SoC series Signed-off-by: Chris Brandt --- FYI: No driver changes were needed --- Documentation/devicetree/bindings/timer/renesas,ostm.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.txt b/Documentation/devicetree/bindings/timer/renesas,ostm.txt index be3ae0fdf775..81a78f8bcf17 100644 --- a/Documentation/devicetree/bindings/timer/renesas,ostm.txt +++ b/Documentation/devicetree/bindings/timer/renesas,ostm.txt @@ -9,7 +9,8 @@ Channels are independent from each other. Required Properties: - compatible: must be one or more of the following: -- "renesas,r7s72100-ostm" for the r7s72100 OSTM +- "renesas,r7s72100-ostm" for the R7S72100 (RZ/A1) OSTM +- "renesas,r7s9210-ostm" for the R7S9210 (RZ/A2) OSTM - "renesas,ostm" for any OSTM This is a fallback for the above renesas,*-ostm entries -- 2.16.1
[PATCH] dt-bindings: spi: rspi: Add R7S9210 support
Add support for RZ/A2 Signed-off-by: Chris Brandt --- FYI: No driver changes were needed --- Documentation/devicetree/bindings/spi/spi-rspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/spi-rspi.txt b/Documentation/devicetree/bindings/spi/spi-rspi.txt index 96fd58548f69..35d74de9e6fd 100644 --- a/Documentation/devicetree/bindings/spi/spi-rspi.txt +++ b/Documentation/devicetree/bindings/spi/spi-rspi.txt @@ -11,6 +11,7 @@ Required properties: Examples with soctypes are: - "renesas,rspi-sh7757" (SH) - "renesas,rspi-r7s72100" (RZ/A1H) + - "renesas,rspi-r7s9210" (RZ/A2) - "renesas,qspi-r8a7743" (RZ/G1M) - "renesas,qspi-r8a7745" (RZ/G1E) - "renesas,qspi-r8a7790" (R-Car H2) -- 2.16.1
[PATCH v6 3/3] ARM: dts: r9a06g032: Add pinctrl node
This provides a pinctrl driver for the Renesas R9A06G032 SoC
Based on a patch originally written by Michel Pollet at Renesas.
Signed-off-by: Phil Edworthy
---
v6:
- No changes.
v5:
- No changes.
v4:
- No changes.
v3:
- No changes.
v2:
- Add "renesas,rzn1-pinctrl" compatible fallback string
- Register size corrected.
---
arch/arm/boot/dts/r9a06g032.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
index eaf94976ed6d..2322268bc862 100644
--- a/arch/arm/boot/dts/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -165,6 +165,14 @@
status = "disabled";
};
+ pinctrl: pin-controller@40067000 {
+ compatible = "renesas,r9a06g032-pinctrl",
"renesas,rzn1-pinctrl";
+ reg = <0x40067000 0x1000>, <0x5100 0x480>;
+ clocks = <&sysctrl R9A06G032_HCLK_PINCONFIG>;
+ clock-names = "bus";
+ status = "okay";
+ };
+
gic: gic@44101000 {
compatible = "arm,cortex-a7-gic", "arm,gic-400";
interrupt-controller;
--
2.17.1
[PATCH v6 2/3] pinctrl: renesas: Renesas RZ/N1 pinctrl driver
This provides a pinctrl driver for the Renesas RZ/N1 device family. Based on a patch originally written by Michel Pollet at Renesas. Signed-off-by: Phil Edworthy Reviewed-by: Jacopo Mondi --- v6: - Instead of combining the pin nr and func into a single element, use a pair of 8-bit elements. - Simplified how the MDIO function is calculated v5: - Address Jacopo's comments - Address Geert's comments v4: - Address Jacopo's comments - Implement pin_config_group_get() - Fix function to get pin configs, i.e. return -EINVAL when disabled. v3: - Use standard DT props instead of proprietary ones. - Replace virtual pins used for MDIO muxing with extra funcs. - Use pinctrl_utils funcs to handle the maps. - Remove the dbg functions to keep things simple. v2: - Change filename to generic rzn1, instead of device specific. - Changed Kconfig symbol and file name to generic rzn1 family. - Added "renesas,rzn1-pinctrl" compatible fallback string - Changes suggested by Jacopo Mondi. Mainly formatting, plus: - Removed global ptr - Removed unused code accessing parent of node. - Removed check for null OF np that can't happen. - Replaced overlapping enums with #defines - Renamed some variables and symbols to clarify their use - Fix error handling during probe - Move probe from postcore_initcall to subsys_initcall to ensure drivers that require clocks get them instead of having to defer probing. --- drivers/pinctrl/Kconfig| 10 + drivers/pinctrl/Makefile | 1 + drivers/pinctrl/pinctrl-rzn1.c | 941 + 3 files changed, 952 insertions(+) create mode 100644 drivers/pinctrl/pinctrl-rzn1.c diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index 978b2ed4d014..4d8c00eac742 100644 --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -195,6 +195,16 @@ config PINCTRL_RZA1 help This selects pinctrl driver for Renesas RZ/A1 platforms. +config PINCTRL_RZN1 + bool "Renesas RZ/N1 pinctrl driver" + depends on OF + depends on ARCH_RZN1 || COMPILE_TEST + select GENERIC_PINCTRL_GROUPS + select GENERIC_PINMUX_FUNCTIONS + select GENERIC_PINCONF + help + This selects pinctrl driver for Renesas RZ/N1 devices. + config PINCTRL_SINGLE tristate "One-register-per-pin type device tree based pinctrl driver" depends on OF diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile index 8e127bd8610f..18a13c1e2c21 100644 --- a/drivers/pinctrl/Makefile +++ b/drivers/pinctrl/Makefile @@ -27,6 +27,7 @@ obj-$(CONFIG_PINCTRL_PIC32) += pinctrl-pic32.o obj-$(CONFIG_PINCTRL_PISTACHIO)+= pinctrl-pistachio.o obj-$(CONFIG_PINCTRL_ROCKCHIP) += pinctrl-rockchip.o obj-$(CONFIG_PINCTRL_RZA1) += pinctrl-rza1.o +obj-$(CONFIG_PINCTRL_RZN1) += pinctrl-rzn1.o obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o obj-$(CONFIG_PINCTRL_SIRF) += sirf/ obj-$(CONFIG_PINCTRL_SX150X) += pinctrl-sx150x.o diff --git a/drivers/pinctrl/pinctrl-rzn1.c b/drivers/pinctrl/pinctrl-rzn1.c new file mode 100644 index ..c1c9ee4c502f --- /dev/null +++ b/drivers/pinctrl/pinctrl-rzn1.c @@ -0,0 +1,941 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2014-2018 Renesas Electronics Europe Limited + * + * Phil Edworthy + * Based on a driver originally written by Michel Pollet at Renesas. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "core.h" +#include "pinconf.h" +#include "pinctrl-utils.h" + +#define RZN1_FUNC_L2_MAX RZN1_FUNC_MAC_MTIP_SWITCH +#define RZN1_FUNC_MDIO_MAX RZN1_FUNC_MDIO1_E1_SWITCH + +/* Field positions and masks in the pinmux registers */ +#define RZN1_L1_PIN_DRIVE_STRENGTH 10 +#define RZN1_L1_PIN_DRIVE_STRENGTH_4MA 0 +#define RZN1_L1_PIN_DRIVE_STRENGTH_6MA 1 +#define RZN1_L1_PIN_DRIVE_STRENGTH_8MA 2 +#define RZN1_L1_PIN_DRIVE_STRENGTH_12MA3 +#define RZN1_L1_PIN_PULL 8 +#define RZN1_L1_PIN_PULL_NONE 0 +#define RZN1_L1_PIN_PULL_UP1 +#define RZN1_L1_PIN_PULL_DOWN 3 +#define RZN1_L1_FUNCTION 0 +#define RZN1_L1_FUNC_MASK 0xf +#define RZN1_L1_FUNCTION_L20xf + +/* + * The hardware manual describes two levels of multiplexing, but it's more + * logical to think of the hardware as three levels, with level 3 consisting of + * the multiplexing for Ethernet MDIO signals. + * + * Level 1 functions go from 0 to 9, with level 1 function '15' (0xf) specifying + * that level 2 functions are used instead. Level 2 has a lot more options, + * going from 0 to 61. Level 3 allows selection of MDIO functions which can be + * floating, or one of seven internal peripherals. Unfortunately, there are two + * level 2 functions that can select MDIO, and two MDIO channels so we have four + * sets of level 3 functions. + * + * For this driver, we've com
[PATCH v6 1/3] dt-bindings: pinctrl: renesas,rzn1-pinctrl: documentation
The Renesas RZ/N1 device family PINCTRL node description.
Based on a patch originally written by Michel Pollet at Renesas.
Signed-off-by: Phil Edworthy
Reviewed-by: Jacopo Mondi
---
v6:
- Instead of combining the pin nr and func into a single element, use
a pair of 8-bit elements.
v5:
- 'Optional generic properties' => 'Optional generic pinconf properties'
v4:
- Add alternative way to use the pinmux prop.
- Remove mention of gpios.
v3:
- Use standard bindings
- Change the way the functions are defined so it is easy to check
against the hardware numbering.
- Add functions for the MDIO source peripheral instead of using
virtual pins.
v2:
- Change filename to generic rzn1, instead of device specific.
- Add "renesas,rzn1-pinctrl" compatible fallback string.
- Example register size corrected.
- Typos fixed.
- Changes suggested by Jacopo Mondi.
- rzn1-pinctrl.h squashed into this as requested by Rob Herring.
---
.../bindings/pinctrl/renesas,rzn1-pinctrl.txt | 155 ++
include/dt-bindings/pinctrl/rzn1-pinctrl.h| 135 +++
2 files changed, 290 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.txt
create mode 100644 include/dt-bindings/pinctrl/rzn1-pinctrl.h
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.txt
new file mode 100644
index ..ca747b3b7455
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.txt
@@ -0,0 +1,155 @@
+Renesas RZ/N1 SoC Pinctrl node description.
+
+Pin controller node
+---
+Required properties:
+- compatible: SoC-specific compatible string "renesas,-pinctrl"
+ followed by "renesas,rzn1-pinctrl" as fallback. The SoC-specific compatible
+ strings must be one of:
+ "renesas,r9a06g032-pinctrl" for RZ/N1D
+ "renesas,r9a06g033-pinctrl" for RZ/N1S
+- reg: Address base and length of the memory area where the pin controller
+ hardware is mapped to.
+- clocks: phandle for the clock, see the description of clock-names below.
+- clock-names: Contains the name of the clock:
+"bus", the bus clock, sometimes described as pclk, for register accesses.
+
+Example:
+ pinctrl: pin-controller@40067000 {
+ compatible = "renesas,r9a06g032-pinctrl", "renesas,rzn1-pinctrl";
+ reg = <0x40067000 0x1000>, <0x5100 0x480>;
+ clocks = <&sysctrl R9A06G032_HCLK_PINCONFIG>;
+ clock-names = "bus";
+ };
+
+Sub-nodes
+-
+
+The child nodes of the pin controller node describe a pin multiplexing
+function.
+
+- Pin multiplexing sub-nodes:
+ A pin multiplexing sub-node describes how to configure a set of
+ (or a single) pin in some desired alternate function mode.
+ A single sub-node may define several pin configurations.
+ Please refer to pinctrl-bindings.txt to get to know more on generic
+ pin properties usage.
+
+ The allowed generic formats for a pin multiplexing sub-node are the
+ following ones:
+
+ node-1 {
+ pinmux = /bits/ 8 , , ... ;
+ GENERIC_PINCONFIG;
+ };
+
+ node-2 {
+ sub-node-1 {
+ pinmux = /bits/ 8 , , ... ;
+ GENERIC_PINCONFIG;
+ };
+
+ sub-node-2 {
+ pinmux = /bits/ 8 , , ... ;
+ GENERIC_PINCONFIG;
+ };
+
+ ...
+
+ sub-node-n {
+ pinmux = /bits/ 8 , , ... ;
+ GENERIC_PINCONFIG;
+ };
+ };
+
+ node-3 {
+ pinmux = /bits/ 8 , , ... ;
+ GENERIC_PINCONFIG;
+
+ sub-node-1 {
+ pinmux = /bits/ 8 , , ... ;
+ GENERIC_PINCONFIG;
+ };
+
+ ...
+
+ sub-node-n {
+ pinmux = /bits/ 8 , , ... ;
+ GENERIC_PINCONFIG;
+ };
+ };
+
+ Use the latter two formats when pins part of the same logical group need to
+ have different generic pin configuration flags applied. Note that the generic
+ pinconfig in node-3 does not apply to the sub-nodes.
+
+ Client sub-nodes shall refer to pin multiplexing sub-nodes using the phandle
+ of the most external one.
+
+ Eg.
+
+ client-1 {
+ ...
+ pinctrl-0 = <&node-1>;
+ ...
+ };
+
+ client-2 {
+ ...
+ pinctrl-0 = <&node-2>;
+ ...
+ };
+
+ Required properties:
+- pinmux:
+ 8-bit integer array consisting of PIN_NR pin number and MUX_FUNC pairs.
+ When a pin has to be configured in alternate function mode, use this
+ property to identify the pin by its global index, and provide its
+ alternate function configuration number.
+ When multiple pins are required to be configured as part of the same
+ alternate function they shall be specified as members of the same
+ argument list of a single "pinmux" property.
+ PIN_NR directly corresponds to the pl_gpio pin number and MUX_FUNC is
+ one of the alternate function identifiers defined in:
+
+ These identifiers collapse the IO Multiplex Confi
[PATCH v6 0/3] Renesas R9A06G032 PINCTRL Driver
This implements the pinctrl driver for the RZ/N1 family of devices, including the R9A06G032 (RZ/N1D) device. This series was originally written by Michel Pollet whilst at Renesas, and I have taken over this work. Main changes: v6: - Instead of combining the pin nr and func into a single element, use a pair of 8-bit elements. - Simplified how the MDIO function is calculated v5: - Address Jacopo's further comments - Address Geert's comments v4: - Address Jacopo's comments - Add alternative way to use the pinmux prop. - Remove mention of gpios. - Implement pin_config_group_get() - Fix function to get pin configs, i.e. return -EINVAL when disabled. v3: - Use standard DT props instead of proprietary ones. - Replace virtual pins used for MDIO muxing with extra funcs. - Use pinctrl_utils funcs to handle the maps. - Remove the dbg functions to keep things simple. - Change the way the functions are defined so it is easy to check against the hardware numbering. v2: - Change to generic rzn1 family driver, instead of device specific. - Review comments fixed. - Fix error handling during probe Phil Edworthy (3): dt-bindings: pinctrl: renesas,rzn1-pinctrl: documentation pinctrl: renesas: Renesas RZ/N1 pinctrl driver ARM: dts: r9a06g032: Add pinctrl node .../bindings/pinctrl/renesas,rzn1-pinctrl.txt | 155 +++ arch/arm/boot/dts/r9a06g032.dtsi | 8 + drivers/pinctrl/Kconfig | 10 + drivers/pinctrl/Makefile | 1 + drivers/pinctrl/pinctrl-rzn1.c| 941 ++ include/dt-bindings/pinctrl/rzn1-pinctrl.h| 135 +++ 6 files changed, 1250 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.txt create mode 100644 drivers/pinctrl/pinctrl-rzn1.c create mode 100644 include/dt-bindings/pinctrl/rzn1-pinctrl.h -- 2.17.1
[PATCH] ASoC: rsnd: Add r8a7744 support
Document RZ/G1N (R8A7744) SoC bindings. Signed-off-by: Biju Das Reviewed-by: Chris Paterson --- This patch is tested against linux-next next-20180927. --- Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index f4688c5..d92b705 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -343,6 +343,7 @@ Required properties: "renesas,rcar_sound-gen3" if generation3 (or RZ/G2) Examples with soctypes are: - "renesas,rcar_sound-r8a7743" (RZ/G1M) + - "renesas,rcar_sound-r8a7744" (RZ/G1N) - "renesas,rcar_sound-r8a7745" (RZ/G1E) - "renesas,rcar_sound-r8a774a1" (RZ/G2M) - "renesas,rcar_sound-r8a7778" (R-Car M1A) -- 2.7.4
[PATCH] dt-bindings: usb-xhci: Document r8a7744 support
Document r8a7744 xhci support. The driver will use the fallback compatible string "renesas,rcar-gen2-xhci", therefore no driver change is needed. Signed-off-by: Biju Das Reviewed-by: Chris Paterson --- This patch is tested against linux-next next-20180927 and usb-next --- Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index fb564e7..fea8b15 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -8,6 +8,7 @@ Required properties: - "marvell,armada-375-xhci" for Armada 375 SoCs - "marvell,armada-380-xhci" for Armada 38x SoCs - "renesas,xhci-r8a7743" for r8a7743 SoC +- "renesas,xhci-r8a7744" for r8a7744 SoC - "renesas,xhci-r8a774a1" for r8a774a1 SoC - "renesas,xhci-r8a7790" for r8a7790 SoC - "renesas,xhci-r8a7791" for r8a7791 SoC -- 2.7.4
[PATCH] dt-bindings: usb: renesas_usbhs: Add support for r8a7744
Document support for RZ/G1N (R8A7744) SoC. Signed-off-by: Biju Das Reviewed-by: Chris Paterson --- This patch is tested against linux-next next-20180927 and usb-next --- Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt index 15fb3b3..a5dbdb5 100644 --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt @@ -4,6 +4,7 @@ Required properties: - compatible: Must contain one or more of the following: - "renesas,usbhs-r8a7743" for r8a7743 (RZ/G1M) compatible device + - "renesas,usbhs-r8a7744" for r8a7744 (RZ/G1N) compatible device - "renesas,usbhs-r8a7745" for r8a7745 (RZ/G1E) compatible device - "renesas,usbhs-r8a774a1" for r8a774a1 (RZ/G2M) compatible device - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device -- 2.7.4
Re: [PATCH 07/30] media: entity: Add has_route entity operation
Hello,
thank you all for the patches!
On Thu, Aug 23, 2018 at 03:25:21PM +0200, Niklas Söderlund wrote:
> From: Laurent Pinchart
>
> The optional operation can be used by entities to report whether two
> pads are internally connected.
>
> Signed-off-by: Laurent Pinchart
> Signed-off-by: Michal Simek
> Signed-off-by: Sakari Ailus
> ---
> include/media/media-entity.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> index 532c438b9eb862c5..07df1b8d85a3c1ba 100644
> --- a/include/media/media-entity.h
> +++ b/include/media/media-entity.h
> @@ -193,6 +193,9 @@ struct media_pad {
> * @link_validate: Return whether a link is valid from the entity point of
> * view. The media_pipeline_start() function
> * validates all links by calling this operation. Optional.
> + * @has_route: Return whether a route exists inside the entity
> between
> + * two given pads. Optional. If the operation isn't
> + * implemented all pads will be considered as connected.
> *
> * .. note::
> *
> @@ -205,6 +208,8 @@ struct media_entity_operations {
> const struct media_pad *local,
> const struct media_pad *remote, u32 flags);
> int (*link_validate)(struct media_link *link);
> + bool (*has_route)(struct media_entity *entity, unsigned int pad0,
> + unsigned int pad1);
In one next patch in the series:
[PATCH 09/30] media: entity: Swap pads if route is checked from source to sink
the media_entity_has_route() operations ensures the sink pad is always
the first one. Could we make it explicit in the paramters name and
documentation to ease understanding when driver will have to implement this?
Thanks
j
> };
>
> /**
> --
> 2.18.0
>
signature.asc
Description: PGP signature
[PATCH] dt-bindings: dmaengine: usb-dmac: Add binding for r8a7744
This patch adds binding for r8a7744 (RZ/G1N). Signed-off-by: Biju Das Reviewed-by: Chris Paterson --- This patch is tested against linux-next next-20180927 --- Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt index 482e543..1743017 100644 --- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt +++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt @@ -4,6 +4,7 @@ Required Properties: -compatible: "renesas,-usb-dmac", "renesas,usb-dmac" as fallback. Examples with soctypes are: - "renesas,r8a7743-usb-dmac" (RZ/G1M) + - "renesas,r8a7744-usb-dmac" (RZ/G1N) - "renesas,r8a7745-usb-dmac" (RZ/G1E) - "renesas,r8a7790-usb-dmac" (R-Car H2) - "renesas,r8a7791-usb-dmac" (R-Car M2-W) -- 2.7.4
[PATCH] dt-bindings: phy: rcar-gen2: Add r8a7744 support
Add USB PHY support for r8a7744 SoC. Renesas RZ/G1N (R8A7744) USB PHY is identical to the R-Car Gen2 family. Signed-off-by: Biju Das Reviewed-by: Chris Paterson --- This patch is tested against linux-next next-20180927 --- Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt index eeb9e18..4f0879a 100644 --- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt +++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt @@ -5,6 +5,7 @@ This file provides information on what the device node for the R-Car generation Required properties: - compatible: "renesas,usb-phy-r8a7743" if the device is a part of R8A7743 SoC. + "renesas,usb-phy-r8a7744" if the device is a part of R8A7744 SoC. "renesas,usb-phy-r8a7745" if the device is a part of R8A7745 SoC. "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 SoC. "renesas,usb-phy-r8a7791" if the device is a part of R8A7791 SoC. -- 2.7.4
[PATCH] dt-bindings: can: rcar_can: Add r8a7744 support
Document RZ/G1N (r8a7744) SoC specific bindings. Signed-off-by: Biju Das Reviewed-by: Chris Paterson --- This patch is tested against linux-next next-20180927 --- Documentation/devicetree/bindings/net/can/rcar_can.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt index 94a7f33..cc43728 100644 --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt @@ -3,6 +3,7 @@ Renesas R-Car CAN controller Device Tree Bindings Required properties: - compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC. + "renesas,can-r8a7744" if CAN controller is a part of R8A7744 SoC. "renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC. "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC. "renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC. -- 2.7.4
[PATCH qemu v5 3/3] hw/arm/virt: Allow dynamic vfio-platform devices again
Allow the instantation of generic dynamic vfio-platform devices again,
without the need to create a new device-specific vfio type.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Eric Auger
Tested-by: Eric Auger
---
v5:
- Drop reference to commit 6f2062b9758ebc64 ("hw/arm/virt: Allow only
supported dynamic sysbus devices"),
- Add Reviewed-by, Tested-by,
v4:
- s/sysbus/vfio-platform/ in patch description,
v3:
- Drop RFC state,
v2:
- Restrict from TYPE_SYS_BUS_DEVICE to TYPE_VFIO_PLATFORM, as
suggested by Eric Auger.
---
hw/arm/virt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 0b57f87abcbfd54b..e33f7776c72fa9d0 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1758,6 +1758,7 @@ static void virt_machine_class_init(ObjectClass *oc, void
*data)
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_CALXEDA_XGMAC);
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_AMD_XGBE);
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_RAMFB_DEVICE);
+machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_PLATFORM);
mc->block_default_type = IF_VIRTIO;
mc->no_cdrom = 1;
mc->pci_allow_0_address = true;
--
2.17.1
[PATCH qemu v5 2/3] hw/arm/sysbus-fdt: Allow device matching with DT compatible value
From: Auger Eric
Up to now we have relied on the device type to identify a device tree
node creation function. Since we would like the vfio-platform device to
be instantiable with different compatible strings we introduce the
capability to specialize the node creation depending on actual
compatible value.
NodeCreationPair is renamed into BindingEntry. The struct is enhanced
with compat and match_fn() fields. We introduce a new matching function
adapted to the vfio-platform generic device.
Soon, the AMD XGBE can be instantiated with either manner, i.e.:
-device vfio-amd-xgbe,host=e090.xgmac
or using the new option line:
-device vfio-platform,host=e090.xgmac
Signed-off-by: Eric Auger
[geert: Match using compatible values in sysfs instead of user-supplied
manufacturer/model options, reword]
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Eric Auger
Tested-by: Eric Auger
---
v5:
- s/instantiatable/instantiable/,
- Add Reviewed-by,
v4:
- Add Tested-by (with amd-xgbe),
- s/From now on/Soon/ in patch description,
v3:
- Match using the compatible values from sysfs instead of using
user-supplied manufacturer and model options,
- Reword patch description,
- Drop RFC state,
v2:
- No changes,
v1:
- No changes,
v0:
- Original version from Eric.
---
hw/arm/sysbus-fdt.c | 61 ++---
1 file changed, 47 insertions(+), 14 deletions(-)
diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
index 43d6a7bb48ddc351..0e24c803a1c2c734 100644
--- a/hw/arm/sysbus-fdt.c
+++ b/hw/arm/sysbus-fdt.c
@@ -50,11 +50,13 @@ typedef struct PlatformBusFDTData {
PlatformBusDevice *pbus;
} PlatformBusFDTData;
-/* struct that associates a device type name and a node creation function */
-typedef struct NodeCreationPair {
+/* struct that allows to match a device and create its FDT node */
+typedef struct BindingEntry {
const char *typename;
-int (*add_fdt_node_fn)(SysBusDevice *sbdev, void *opaque);
-} NodeCreationPair;
+const char *compat;
+int (*add_fn)(SysBusDevice *sbdev, void *opaque);
+bool (*match_fn)(SysBusDevice *sbdev, const struct BindingEntry *combo);
+} BindingEntry;
/* helpers */
@@ -413,6 +415,27 @@ static int add_amd_xgbe_fdt_node(SysBusDevice *sbdev, void
*opaque)
return 0;
}
+/* DT compatible matching */
+static bool vfio_platform_match(SysBusDevice *sbdev,
+const BindingEntry *entry)
+{
+VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
+const char *compat;
+unsigned int n;
+
+for (n = vdev->num_compat, compat = vdev->compat; n > 0;
+ n--, compat += strlen(compat) + 1) {
+if (!strcmp(entry->compat, compat)) {
+return true;
+}
+}
+
+return false;
+}
+
+#define VFIO_PLATFORM_BINDING(compat, add_fn) \
+{TYPE_VFIO_PLATFORM, (compat), (add_fn), vfio_platform_match}
+
#endif /* CONFIG_LINUX */
static int no_fdt_node(SysBusDevice *sbdev, void *opaque)
@@ -420,14 +443,23 @@ static int no_fdt_node(SysBusDevice *sbdev, void *opaque)
return 0;
}
-/* list of supported dynamic sysbus devices */
-static const NodeCreationPair add_fdt_node_functions[] = {
+/* Device type based matching */
+static bool type_match(SysBusDevice *sbdev, const BindingEntry *entry)
+{
+return !strcmp(object_get_typename(OBJECT(sbdev)), entry->typename);
+}
+
+#define TYPE_BINDING(type, add_fn) {(type), NULL, (add_fn), type_match}
+
+/* list of supported dynamic sysbus bindings */
+static const BindingEntry bindings[] = {
#ifdef CONFIG_LINUX
-{TYPE_VFIO_CALXEDA_XGMAC, add_calxeda_midway_xgmac_fdt_node},
-{TYPE_VFIO_AMD_XGBE, add_amd_xgbe_fdt_node},
+TYPE_BINDING(TYPE_VFIO_CALXEDA_XGMAC, add_calxeda_midway_xgmac_fdt_node),
+TYPE_BINDING(TYPE_VFIO_AMD_XGBE, add_amd_xgbe_fdt_node),
+VFIO_PLATFORM_BINDING("amd,xgbe-seattle-v1a", add_amd_xgbe_fdt_node),
#endif
-{TYPE_RAMFB_DEVICE, no_fdt_node},
-{"", NULL}, /* last element */
+TYPE_BINDING(TYPE_RAMFB_DEVICE, no_fdt_node),
+TYPE_BINDING("", NULL), /* last element */
};
/* Generic Code */
@@ -446,10 +478,11 @@ static void add_fdt_node(SysBusDevice *sbdev, void
*opaque)
{
int i, ret;
-for (i = 0; i < ARRAY_SIZE(add_fdt_node_functions); i++) {
-if (!strcmp(object_get_typename(OBJECT(sbdev)),
-add_fdt_node_functions[i].typename)) {
-ret = add_fdt_node_functions[i].add_fdt_node_fn(sbdev, opaque);
+for (i = 0; i < ARRAY_SIZE(bindings); i++) {
+const BindingEntry *iter = &bindings[i];
+
+if (iter->match_fn(sbdev, iter)) {
+ret = iter->add_fn(sbdev, opaque);
assert(!ret);
return;
}
--
2.17.1
[PATCH qemu v5 0/3] vfio/sysbus-fdt: Prepare for Generic DT Pass-Through
Hi all,
This patch series prepares for exporting generic devices in DT using
vfio-platform, providing direct access from a QEMU+KVM guest to the
exported devices.
- Patches 1-2 (submitted before by Eric Auger) make the vfio-platform
device non-abstract, incl. matching using a compatible string.
- Patch 3 allows dynamic vfio-platform devices again, without needing to
create device-specific vfio types for each and every new device.
This will avoid having to write device-specific instantation methods for
each and every "simple" device using only a set of generic properties.
Devices that need more specialized handling will still be able provide
their own instantation methods.
Note that this series no longer contains "[PATCH 4/4] hw/arm/sysbus-fdt:
Add support for instantiating generic devices", following advice from Eric
Auger, as that patch needs more safeguards. Hence this series now contains
only preparative work.
Changes compared to v4 ("vfio/sysbus-fdt: Prepare for Generic DT Pass-Through",
http://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg01672.html):
- Add Reviewed-by, Tested-by,
- Fix path leak on error,
- s/instantiatable/instantiable/,
- Drop reference to commit 6f2062b9758ebc64 ("hw/arm/virt: Allow only
supported dynamic sysbus devices").
Changes compared to v3 ("hw/arm/sysbus-fdt: Generic DT Pass-Through"),
http://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg05006.html):
- Propagate g_file_get_contents() errors through errp,
- Add Tested-by (with amd-xgbe),
- s/From now on/Soon/ in patch description,
- s/sysbus/vfio-platform/ in patch description,
- Postpone "[PATCH 4/4] hw/arm/sysbus-fdt: Add support for instantiating
generic devices".
Changes compared to v2 (not submitted to the mailing list):
- Use the compatible values from sysfs instead of user-supplied
manufacturer and model options,
- Replace "hw/arm/sysbus-fdt: Enable rcar-gen3-gpio dynamic
instatiation" by generic "hw/arm/sysbus-fdt: Add support for
instantiating generic devices",
- Reword patch descriptions,
- Drop RFC state,
- Drop "vfio: No-IOMMU mode support".
Changes compared to v1 ("R-Car Gen3 GPIO Pass-Through Prototype (QEMU)",
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02716.html):
- Restrict dynamic sysbus devices to TYPE_VFIO_PLATFORM, as suggested
by Eric Auger.
This (plus the postponed "hw/arm/sysbus-fdt: Add support for instantiating
generic devices") has been tested on a Renesas Salvator-XS board with R-Car
H3 ES2.0 with SATA:
-device vfio-platform,host=ee30.sata
and GPIO (needs VFIO No-IOMMU support):
-device vfio-platform,host=e6055400.gpio
Thanks for applying!
Auger Eric (2):
vfio/platform: Make the vfio-platform device non-abstract
hw/arm/sysbus-fdt: Allow device matching with DT compatible value
Geert Uytterhoeven (1):
hw/arm/virt: Allow dynamic vfio-platform devices again
hw/arm/sysbus-fdt.c | 61 +
hw/arm/virt.c | 1 +
hw/vfio/amd-xgbe.c | 1 +
hw/vfio/calxeda-xgmac.c | 1 +
hw/vfio/platform.c | 25 +-
include/hw/vfio/vfio-platform.h | 3 +-
6 files changed, 76 insertions(+), 16 deletions(-)
--
2.17.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
[PATCH qemu v5 1/3] vfio/platform: Make the vfio-platform device non-abstract
From: Auger Eric
Up to now the vfio-platform device has been abstract and could not be
instantiated. The integration of a new vfio platform device required
creating a dummy derived device which only set the compatible string.
Following the few vfio-platform device integrations we have seen the
actual requested adaptation happens on device tree node creation
(sysbus-fdt).
Hence remove the abstract setting, and read the list of compatible
values from sysfs if not set by a derived device.
Update the amd-xgbe and calxeda-xgmac drivers to fill in the number of
compatible values, as there can now be more than one.
Note that sysbus-fdt does not support the instantiation of the
vfio-platform device yet.
Signed-off-by: Eric Auger
[geert: Rebase, set user_creatable=true, use compatible values in sysfs
instead of user-supplied manufacturer/model options, reword]
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Eric Auger
Tested-by: Eric Auger
---
v5:
- Fix path leak on error,
- Add Reviewed-by, Tested-by,
v4:
- Propagate g_file_get_contents() errors through errp,
v3:
- Read all compatible values from sysfs instead of using user-supplied
manufacturer and model options,
- Reword patch description,
- Drop RFC state,
v2:
- No changes,
v1:
- Rebase, Set user_creatable=true,
v0:
- Original version from Eric.
---
hw/vfio/amd-xgbe.c | 1 +
hw/vfio/calxeda-xgmac.c | 1 +
hw/vfio/platform.c | 25 -
include/hw/vfio/vfio-platform.h | 3 ++-
4 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/hw/vfio/amd-xgbe.c b/hw/vfio/amd-xgbe.c
index 0c4ec4ba25170366..ee64a3b4a2e45bf5 100644
--- a/hw/vfio/amd-xgbe.c
+++ b/hw/vfio/amd-xgbe.c
@@ -20,6 +20,7 @@ static void amd_xgbe_realize(DeviceState *dev, Error **errp)
VFIOAmdXgbeDeviceClass *k = VFIO_AMD_XGBE_DEVICE_GET_CLASS(dev);
vdev->compat = g_strdup("amd,xgbe-seattle-v1a");
+vdev->num_compat = 1;
k->parent_realize(dev, errp);
}
diff --git a/hw/vfio/calxeda-xgmac.c b/hw/vfio/calxeda-xgmac.c
index 24cee6d06512c1b6..e7767c4b021be566 100644
--- a/hw/vfio/calxeda-xgmac.c
+++ b/hw/vfio/calxeda-xgmac.c
@@ -20,6 +20,7 @@ static void calxeda_xgmac_realize(DeviceState *dev, Error
**errp)
VFIOCalxedaXgmacDeviceClass *k = VFIO_CALXEDA_XGMAC_DEVICE_GET_CLASS(dev);
vdev->compat = g_strdup("calxeda,hb-xgmac");
+vdev->num_compat = 1;
k->parent_realize(dev, errp);
}
diff --git a/hw/vfio/platform.c b/hw/vfio/platform.c
index 57c4a0ee2b58da70..64c1af653d145cc0 100644
--- a/hw/vfio/platform.c
+++ b/hw/vfio/platform.c
@@ -655,6 +655,28 @@ static void vfio_platform_realize(DeviceState *dev, Error
**errp)
goto out;
}
+if (!vdev->compat) {
+GError *gerr = NULL;
+gchar *contents;
+gsize length;
+char *path;
+
+path = g_strdup_printf("%s/of_node/compatible", vbasedev->sysfsdev);
+if (!g_file_get_contents(path, &contents, &length, &gerr)) {
+error_setg(errp, "%s", gerr->message);
+g_error_free(gerr);
+g_free(path);
+return;
+}
+g_free(path);
+vdev->compat = contents;
+for (vdev->num_compat = 0; length; vdev->num_compat++) {
+size_t skip = strlen(contents) + 1;
+contents += skip;
+length -= skip;
+}
+}
+
for (i = 0; i < vbasedev->num_regions; i++) {
if (vfio_region_mmap(vdev->regions[i])) {
error_report("%s mmap unsupported. Performance may be slow",
@@ -700,6 +722,8 @@ static void vfio_platform_class_init(ObjectClass *klass,
void *data)
dc->desc = "VFIO-based platform device assignment";
sbc->connect_irq_notifier = vfio_start_irqfd_injection;
set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+/* Supported by TYPE_VIRT_MACHINE */
+dc->user_creatable = true;
}
static const TypeInfo vfio_platform_dev_info = {
@@ -708,7 +732,6 @@ static const TypeInfo vfio_platform_dev_info = {
.instance_size = sizeof(VFIOPlatformDevice),
.class_init = vfio_platform_class_init,
.class_size = sizeof(VFIOPlatformDeviceClass),
-.abstract = true,
};
static void register_vfio_platform_dev_type(void)
diff --git a/include/hw/vfio/vfio-platform.h b/include/hw/vfio/vfio-platform.h
index 9baaa2db09b84f3e..0ee10b1d71ed2503 100644
--- a/include/hw/vfio/vfio-platform.h
+++ b/include/hw/vfio/vfio-platform.h
@@ -54,7 +54,8 @@ typedef struct VFIOPlatformDevice {
QLIST_HEAD(, VFIOINTp) intp_list; /* list of IRQs */
/* queue of pending IRQs */
QSIMPLEQ_HEAD(pending_intp_queue, VFIOINTp) pending_intp_queue;
-char *compat; /* compatibility string */
+char *compat; /* DT compatible values, separated by NUL */
+unsigned int num_compat; /* number of compatible values */
uint32_t mmap_timeout; /* delay to re-enable mmaps after interrupt */
QEMUTimer *mmap_timer; /* allows fast-path resum
[PATCH 3/3] thermal: da9062/61: Prevent hardware access during system suspend
The workqueue used for monitoring the hardware may run while the device
is already suspended. Fix this by using the freezable system workqueue
instead, cfr. commit 51e20d0e3a60cf46 ("thermal: Prevent polling from
happening during system suspend").
Fixes: 608567aac3206ae8 ("thermal: da9062/61: Thermal junction temperature
monitoring driver")
Signed-off-by: Geert Uytterhoeven
---
Untested due to lack of hardware.
---
drivers/thermal/da9062-thermal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/da9062-thermal.c b/drivers/thermal/da9062-thermal.c
index dd8dd947b7f0737c..01b0cb9944577851 100644
--- a/drivers/thermal/da9062-thermal.c
+++ b/drivers/thermal/da9062-thermal.c
@@ -106,7 +106,7 @@ static void da9062_thermal_poll_on(struct work_struct *work)
THERMAL_EVENT_UNSPECIFIED);
delay = msecs_to_jiffies(thermal->zone->passive_delay);
- schedule_delayed_work(&thermal->work, delay);
+ queue_delayed_work(system_freezable_wq, &thermal->work, delay);
return;
}
@@ -125,7 +125,7 @@ static irqreturn_t da9062_thermal_irq_handler(int irq, void
*data)
struct da9062_thermal *thermal = data;
disable_irq_nosync(thermal->irq);
- schedule_delayed_work(&thermal->work, 0);
+ queue_delayed_work(system_freezable_wq, &thermal->work, 0);
return IRQ_HANDLED;
}
--
2.17.1
[PATCH 0/3] thermal: Fix workqueue-related issues in drivers
Hi,
This patch series fixes workqueue-related issues in the Renesas R-Car
Thermal and Dialog DA9062/9061 PMIC drivers, where the workqueue may run
while the device is suspended, or unbound.
The R-Car Thermal driver fixes have been tested on R-Car M2-W and R-Mobile
APE6.
The DA9062/9061 fixes have been compile-tested only.
Note: The Intel PowerClamp driver also uses schedule_delayed_work(), but I
believe that is OK, as the thermal registers are part of the CPU.
Thanks!
Geert Uytterhoeven (3):
thermal: rcar_thermal: Prevent hardware access during system suspend
thermal: rcar_thermal: Prevent doing work after unbind
thermal: da9062/61: Prevent hardware access during system suspend
drivers/thermal/da9062-thermal.c | 4 ++--
drivers/thermal/rcar_thermal.c | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
--
2.17.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
[PATCH 1/3] thermal: rcar_thermal: Prevent hardware access during system suspend
On r8a7791/koelsch, sometimes the following message is printed during
system suspend:
rcar_thermal e61f.thermal: thermal sensor was broken
This happens if the workqueue runs while the device is already
suspended. Fix this by using the freezable system workqueue instead,
cfr. commit 51e20d0e3a60cf46 ("thermal: Prevent polling from happening
during system suspend").
Fixes: e0a5172e9eec7f0d ("thermal: rcar: add interrupt support")
Signed-off-by: Geert Uytterhoeven
---
drivers/thermal/rcar_thermal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 78f932822d381c9d..ea132e122b174757 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -434,8 +434,8 @@ static irqreturn_t rcar_thermal_irq(int irq, void *data)
rcar_thermal_for_each_priv(priv, common) {
if (rcar_thermal_had_changed(priv, status)) {
rcar_thermal_irq_disable(priv);
- schedule_delayed_work(&priv->work,
- msecs_to_jiffies(300));
+ queue_delayed_work(system_freezable_wq, &priv->work,
+ msecs_to_jiffies(300));
}
}
--
2.17.1
[PATCH 2/3] thermal: rcar_thermal: Prevent doing work after unbind
When testing bind/unbind on r8a7791/koelsch:
WARNING: CPU: 1 PID: 697 at lib/debugobjects.c:329
debug_print_object+0x8c/0xb4
ODEBUG: free active (active state 0) object type: timer_list hint:
delayed_work_timer_fn+0x0/0x10
This happens if the workqueue runs after the device has been unbound.
Fix this by cancelling any queued work during remove.
Fixes: e0a5172e9eec7f0d ("thermal: rcar: add interrupt support")
Signed-off-by: Geert Uytterhoeven
---
drivers/thermal/rcar_thermal.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index ea132e122b174757..616ba2fccf410d3b 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -453,6 +453,7 @@ static int rcar_thermal_remove(struct platform_device *pdev)
rcar_thermal_for_each_priv(priv, common) {
rcar_thermal_irq_disable(priv);
+ cancel_delayed_work_sync(&priv->work);
if (priv->chip->use_of_thermal)
thermal_remove_hwmon_sysfs(priv->zone);
else
--
2.17.1
RE: [PATCH v2 3/3] arm64: dts: renesas: r8a774a1: Add CAN nodes
Hello Simon,
> Subject: Re: [PATCH v2 3/3] arm64: dts: renesas: r8a774a1: Add CAN nodes
>
> On Mon, Sep 10, 2018 at 11:43:15AM +0100, Fabrizio Castro wrote:
> > From: Chris Paterson
> >
> > Add the device nodes for both RZ/G2M CAN channels.
> >
> > Signed-off-by: Chris Paterson
> > Reviewed-by: Biju Das
> > ---
> >
> > v1->v2:
> > * replaced "renesas,rzg-gen2-can" with "renesas,rcar-gen3-can" as per
> > Geert's comment.
> >
> > This patch applies on top of renesas-devel-20180906-v4.19-rc2.
>
> Thanks Fabrizio,
>
> I would like to waif for the bindings to be accepted before accepting this
> patch.
Marc has taken the bindings, I guess we can unblock this patch now?
Thanks,
Fab
>
> >
> > arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 24
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > index 046fc93..867e875 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > @@ -874,6 +874,30 @@
> > status = "disabled";
> > };
> >
> > +can0: can@e6c3 {
> > +compatible = "renesas,can-r8a774a1",
> > + "renesas,rcar-gen3-can";
> > +reg = <0 0xe6c3 0 0x1000>;
> > +interrupts = ;
> > +clocks = <&cpg CPG_MOD 916>, <&can_clk>;
> > +clock-names = "clkp1", "can_clk";
> > +power-domains = <&sysc 32>;
> > +resets = <&cpg 916>;
> > +status = "disabled";
> > +};
> > +
> > +can1: can@e6c38000 {
> > +compatible = "renesas,can-r8a774a1",
> > + "renesas,rcar-gen3-can";
> > +reg = <0 0xe6c38000 0 0x1000>;
> > +interrupts = ;
> > +clocks = <&cpg CPG_MOD 915>, <&can_clk>;
> > +clock-names = "clkp1", "can_clk";
> > +power-domains = <&sysc 32>;
> > +resets = <&cpg 915>;
> > +status = "disabled";
> > +};
> > +
> > pwm0: pwm@e6e3 {
> > compatible = "renesas,pwm-r8a774a1", "renesas,pwm-rcar";
> > reg = <0 0xe6e3 0 0x8>;
> > --
> > 2.7.4
> >
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
Re: [PATCH v3 net-next] dt-bindings: can: rcar_can: document r8a77965 support
On 09/21/2018 09:48 PM, Eugeniu Rosca wrote: > Hi Marc, > > On Mon, Aug 27, 2018 at 12:08:48PM +0200, Marc Kleine-Budde wrote: >> On 08/20/2018 04:49 PM, Eugeniu Rosca wrote: >>> From: Eugeniu Rosca >>> >>> Document the support for rcar_can on R8A77965 SoC devices. >>> Add R8A77965 to the list of SoCs which require the "assigned-clocks" and >>> "assigned-clock-rates" properties (thanks, Sergei). >>> >>> Signed-off-by: Eugeniu Rosca >>> Reviewed-by: Simon Horman >>> Reviewed-by: Kieran Bingham >> >> Added to linux-can. > > I can't find the patch in below repositories: > - https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git > - https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git > > Could you please let me know what "linux-can" means? I haven't pushed it yet, it will be in the testing branch of linux-can.git Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 0/3] Add can support to RZ/G2M
On 09/10/2018 12:43 PM, Fabrizio Castro wrote: > Dear All, > > this series contains all that's necessary to add CAN support > for RZ/G2M (a.k.a. r8a774a1). > > v1-v2: > * applied Geert's comments Added 1/3 and 2/3 to linux-can. Tnx. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH resend] can: rcar_can: convert to SPDX identifiers
On 09/26/2018 03:41 AM, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch updates license to use SPDX-License-Identifier > instead of verbose license text. > > Signed-off-by: Kuninori Morimoto > Reviewed-by: Simon Horman Wolfram Sang has already supplied a similar patch, but not for Makefile and Kconfig. I've applied your patch for Makefile and Kconfig and adjusted the commit message accordingly. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/2] serial: sh-sci: Fix earlycon on Renesas ARM platforms
Hi Greg,
On Thu, Aug 30, 2018 at 2:54 PM Geert Uytterhoeven
wrote:
> Due to an unfortunate oversight, commit 2d4dd0da45401c7a ("serial: sh-sci:
> Allow for compressed SCIF address") broke earlycon on all Renesas ARM
> platforms using a SCIF port for the serial console (R-Car, RZ/A1, RZ/G1,
> RZ/G2 SoCs), due to an incorrect value of port->regshift.
>
> This patch series fixes that by reverting that commit, and a (reverse)
> dependency.
>
> Earlycon for RZ/A2 (which is a new platform) will be fixed later in a
> separate patch.
>
> Thanks for applying!
>
> Geert Uytterhoeven (2):
> Revert "serial: sh-sci: Remove SCIx_RZ_SCIFA_REGTYPE"
> Revert "serial: sh-sci: Allow for compressed SCIF address"
>
> drivers/tty/serial/sh-sci.c | 56 +++--
> include/linux/serial_sci.h | 1 +
> 2 files changed, 42 insertions(+), 15 deletions(-)
These are now in tty-next:
10c63443b74d1ef5 Revert "serial: sh-sci: Remove SCIx_RZ_SCIFA_REGTYPE"
a1c2fd7e1098ea49 Revert "serial: sh-sci: Allow for compressed SCIF address"
Can you please include them in v4.19-rc6, as they fix a regression introduced
in v4.19-rc1?
In addition:
3d8b43ad9c0cf023 serial: sh-sci: Add earlycon for R7S9210
(also in tty-next) enables earlycon on RZ/A2 again, as it was disabled
by the two
reverts above.
Thanks a lot!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: [PATCH] rcar-vin: fix redeclaration of symbol
Hi Niklas,
On Wed, Sep 26, 2018 at 11:40:06PM +0200, Niklas Söderlund wrote:
> When adding support for parallel subdev for Gen3 it was missed that the
> symbol 'i' in rvin_group_link_notify() was already declare, remove the
> dupe as it's only used as a loop variable this have no functional
> change. This fixes warning:
>
> rcar-core.c:117:52: originally declared here
> rcar-core.c:173:30: warning: symbol 'i' shadows an earlier one
>
> Fixes: 1284605dc821cebd ("media: rcar-vin: Handle parallel subdev in
> link_notify")
> Signed-off-by: Niklas Söderlund
Acked-by: Jacopo Mondi
Thanks
j
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 5dd16af3625c333b..01e418c2d4c6792e 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -170,7 +170,6 @@ static int rvin_group_link_notify(struct media_link
> *link, u32 flags,
>
> if (csi_id == -ENODEV) {
> struct v4l2_subdev *sd;
> - unsigned int i;
>
> /*
>* Make sure the source entity subdevice is registered as
> --
> 2.19.0
>
signature.asc
Description: PGP signature
