* Re: [PATCH 12/17] ARM: dts: r8a7742: Add Ethernet AVB support
From: Geert Uytterhoeven @ 2020-05-18 11:53 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Jens Axboe, Rob Herring, Wolfram Sang, Ulf Hansson,
Sergei Shtylyov, David S. Miller, Wim Van Sebroeck, Guenter Roeck,
linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux I2C, Linux MMC List, netdev,
Linux-Renesas, Linux Watchdog Mailing List, Prabhakar
In-Reply-To: <1589555337-5498-13-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, May 15, 2020 at 5:10 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Add Ethernet AVB support for R8A7742 SoC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 09/17] ARM: dts: r8a7742: Add sata nodes
From: Geert Uytterhoeven @ 2020-05-18 11:52 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Jens Axboe, Rob Herring, Wolfram Sang, Ulf Hansson,
Sergei Shtylyov, David S. Miller, Wim Van Sebroeck, Guenter Roeck,
linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux I2C, Linux MMC List, netdev,
Linux-Renesas, Linux Watchdog Mailing List, Prabhakar
In-Reply-To: <1589555337-5498-10-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, May 15, 2020 at 5:10 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Add the sata devices nodes to the R8A7742 device tree.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 07/17] ARM: dts: r8a7742: Add MMC0 node
From: Geert Uytterhoeven @ 2020-05-18 11:52 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Jens Axboe, Rob Herring, Wolfram Sang, Ulf Hansson,
Sergei Shtylyov, David S. Miller, Wim Van Sebroeck, Guenter Roeck,
linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux I2C, Linux MMC List, netdev,
Linux-Renesas, Linux Watchdog Mailing List, Prabhakar
In-Reply-To: <1589555337-5498-8-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, May 15, 2020 at 5:10 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Describe MMC0 device node in the R8A7742 device tree.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 06/17] ARM: dts: r8a7742: Add SDHI nodes
From: Geert Uytterhoeven @ 2020-05-18 11:51 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Jens Axboe, Rob Herring, Wolfram Sang, Ulf Hansson,
Sergei Shtylyov, David S. Miller, Wim Van Sebroeck, Guenter Roeck,
linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux I2C, Linux MMC List, netdev,
Linux-Renesas, Linux Watchdog Mailing List, Prabhakar
In-Reply-To: <1589555337-5498-7-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, May 15, 2020 at 5:09 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Add the SDHI devices nodes to the R8A7742 device tree.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] ARM: dts: at91: sama5d2_xplained: Add aliases for the dedicated I2C IPs
From: Tudor.Ambarus @ 2020-05-18 11:49 UTC (permalink / raw)
To: alexandre.belloni, Nicolas.Ferre, Ludovic.Desroches
Cc: robh+dt, devicetree, linux-arm-kernel, linux-kernel,
Tudor.Ambarus
From: Tudor Ambarus <tudor.ambarus@microchip.com>
The sama5d2 SoC has two dedicated I2C IPs that are enabled on
sama5d2_xplained. Add alias for the i2c devices to not rely on
probe order for the i2c device numbering.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 851b8587068b..a927165ea7c2 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -18,6 +18,8 @@
aliases {
serial0 = &uart1; /* DBGU */
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
i2c2 = &i2c2; /* XPRO EXT2 */
};
--
2.23.0
^ permalink raw reply related
* Re: [PATCH 17/17] ARM: dts: r8a7742: Add RWDT node
From: Geert Uytterhoeven @ 2020-05-18 11:47 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Jens Axboe, Rob Herring, Wolfram Sang, Ulf Hansson,
Sergei Shtylyov, David S. Miller, Wim Van Sebroeck, Guenter Roeck,
linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux I2C, Linux MMC List, netdev,
Linux-Renesas, Linux Watchdog Mailing List, Prabhakar
In-Reply-To: <1589555337-5498-18-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
On Fri, May 15, 2020 at 5:10 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Add a device node for the Watchdog Timer (RWDT) controller on the Renesas
> RZ/G1H (r8a7742) SoC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Thanks for your patch!
> --- a/arch/arm/boot/dts/r8a7742.dtsi
> +++ b/arch/arm/boot/dts/r8a7742.dtsi
> @@ -201,6 +201,16 @@
> #size-cells = <2>;
> ranges;
>
> + rwdt: watchdog@e6020000 {
> + compatible = "renesas,r8a7742-wdt",
> + "renesas,rcar-gen2-wdt";
> + reg = <0 0xe6020000 0 0x0c>;
> + clocks = <&cpg CPG_MOD 402>;
> + power-domains = <&sysc R8A7742_PD_ALWAYS_ON>;
> + resets = <&cpg 402>;
> + status = "disabled";
Missing "interrupts" property.
> + };
> +
> gpio0: gpio@e6050000 {
> compatible = "renesas,gpio-r8a7742",
> "renesas,rcar-gen2-gpio";
The rest looks fine, so with the above fixed:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v9 2/4] media: i2c: Add MAX9286 driver
From: Kieran Bingham @ 2020-05-18 11:45 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-renesas-soc, linux-media, devicetree, linux-kernel,
Mauro Carvalho Chehab, Kieran Bingham, Laurent Pinchart,
Jacopo Mondi, Niklas Söderlund, Hans Verkuil, Hyun Kwon,
Manivannan Sadhasivam, Rob Herring, Jacopo Mondi,
Laurent Pinchart, Niklas Söderlund
In-Reply-To: <20200516215103.GA857@valkosipuli.retiisi.org.uk>
Hi Sakari,
There are only fairly minor comments here, fix ups will be included in a
v10.
Is there anything major blocking integration?
Regards
Kieran
On 16/05/2020 22:51, Sakari Ailus wrote:
> Hi Kieran,
>
> Thanks for the update.
>
> On Tue, May 12, 2020 at 04:51:03PM +0100, Kieran Bingham wrote:
>
> ...
>
>> +static int max9286_enum_mbus_code(struct v4l2_subdev *sd,
>> + struct v4l2_subdev_pad_config *cfg,
>> + struct v4l2_subdev_mbus_code_enum *code)
>> +{
>> + if (code->pad || code->index > 0)
>> + return -EINVAL;
>> +
>> + code->code = MEDIA_BUS_FMT_UYVY8_2X8;
>
> Why UYVY8_2X8 and not UYVY8_1X16? In general, the single sample / pixel
> variant of the format is generally used on the serial busses. This choice
> was made when serial busses were introduced.
Ok - I presume this doesn't really have much effect anyway, they just
have to match for the transmitter/receiver?
But it makes sense to me, so I'll update to the 1x16 variant.
>> +
>> + return 0;
>> +}
>> +
>> +static struct v4l2_mbus_framefmt *
>> +max9286_get_pad_format(struct max9286_priv *priv,
>> + struct v4l2_subdev_pad_config *cfg,
>> + unsigned int pad, u32 which)
>> +{
>> + switch (which) {
>> + case V4L2_SUBDEV_FORMAT_TRY:
>> + return v4l2_subdev_get_try_format(&priv->sd, cfg, pad);
>> + case V4L2_SUBDEV_FORMAT_ACTIVE:
>> + return &priv->fmt[pad];
>> + default:
>> + return NULL;
>> + }
>> +}
>> +
>> +static int max9286_set_fmt(struct v4l2_subdev *sd,
>> + struct v4l2_subdev_pad_config *cfg,
>> + struct v4l2_subdev_format *format)
>> +{
>> + struct max9286_priv *priv = sd_to_max9286(sd);
>> + struct v4l2_mbus_framefmt *cfg_fmt;
>> +
>> + if (format->pad >= MAX9286_SRC_PAD)
>> + return -EINVAL;
>
> You can remove these checks; it's been already done by the caller.
>
Ok.
> ...
>
>> +static int max9286_parse_dt(struct max9286_priv *priv)
>> +{
>> + struct device *dev = &priv->client->dev;
>> + struct device_node *i2c_mux;
>> + struct device_node *node = NULL;
>> + unsigned int i2c_mux_mask = 0;
>> +
>> + of_node_get(dev->of_node);
>> + i2c_mux = of_find_node_by_name(dev->of_node, "i2c-mux");
>> + if (!i2c_mux) {
>> + dev_err(dev, "Failed to find i2c-mux node\n");
>> + of_node_put(dev->of_node);
>> + return -EINVAL;
>> + }
>> +
>> + /* Identify which i2c-mux channels are enabled */
>> + for_each_child_of_node(i2c_mux, node) {
>> + u32 id = 0;
>> +
>> + of_property_read_u32(node, "reg", &id);
>> + if (id >= MAX9286_NUM_GMSL)
>> + continue;
>> +
>> + if (!of_device_is_available(node)) {
>> + dev_dbg(dev, "Skipping disabled I2C bus port %u\n", id);
>> + continue;
>> + }
>> +
>> + i2c_mux_mask |= BIT(id);
>> + }
>> + of_node_put(node);
>> + of_node_put(i2c_mux);
>> +
>> + /* Parse the endpoints */
>> + for_each_endpoint_of_node(dev->of_node, node) {
>> + struct max9286_source *source;
>> + struct of_endpoint ep;
>> +
>> + of_graph_parse_endpoint(node, &ep);
>> + dev_dbg(dev, "Endpoint %pOF on port %d",
>> + ep.local_node, ep.port);
>> +
>> + if (ep.port > MAX9286_NUM_GMSL) {
>> + dev_err(dev, "Invalid endpoint %s on port %d",
>> + of_node_full_name(ep.local_node), ep.port);
>> + continue;
>> + }
>> +
>> + /* For the source endpoint just parse the bus configuration. */
>> + if (ep.port == MAX9286_SRC_PAD) {
>> + struct v4l2_fwnode_endpoint vep = {
>> + .bus_type = V4L2_MBUS_CSI2_DPHY
>> + };
>> + int ret;
>> +
>> + ret = v4l2_fwnode_endpoint_parse(
>> + of_fwnode_handle(node), &vep);
>> + if (ret) {
>> + of_node_put(node);
>> + of_node_put(dev->of_node);
>> + return ret;
>> + }
>> +
>> + if (vep.bus_type != V4L2_MBUS_CSI2_DPHY) {
>
> This won't happen, the bus type will stay if you set it to a non-zero
> value.
Ok - I'll remove this check.
>
>> + dev_err(dev,
>> + "Media bus %u type not supported\n",
>> + vep.bus_type);
>> + v4l2_fwnode_endpoint_free(&vep);
>> + of_node_put(node);
>> + of_node_put(dev->of_node);
>> + return -EINVAL;
>> + }
>> +
>> + priv->csi2_data_lanes =
>> + vep.bus.mipi_csi2.num_data_lanes;
>> + v4l2_fwnode_endpoint_free(&vep);
>
> No need to call this unless you use v4l2_fwnode_endpoint_alloc_parse().
>
> And as you don't, you also won't know which frequencies are known to be
> safe to use. That said, perhaps where this device is used having a random
> frequency on that bus could not be an issue. Perhaps.
Does this generate a range? or a list of static supported frequencies?
We configure the pixel clock based upon the number of cameras connected,
and their pixel rates etc ...
Are you saying that the frequency of this clock should be validated to
be a specific range? or are you talking about a different frequency?
For now I'll remove the v4l2_fwnode_endpoint_alloc_parse().
>> +
>> + continue;
>> + }
>> +
>> + /* Skip if the corresponding GMSL link is unavailable. */
>> + if (!(i2c_mux_mask & BIT(ep.port)))
>> + continue;
>> +
>> + if (priv->sources[ep.port].fwnode) {
>> + dev_err(dev,
>> + "Multiple port endpoints are not supported: %d",
>> + ep.port);
>> +
>> + continue;
>> + }
>> +
>> + source = &priv->sources[ep.port];
>> + source->fwnode = fwnode_graph_get_remote_endpoint(
>> + of_fwnode_handle(node));
>> + if (!source->fwnode) {
>> + dev_err(dev,
>> + "Endpoint %pOF has no remote endpoint connection\n",
>> + ep.local_node);
>> +
>> + continue;
>> + }
>> +
>> + priv->source_mask |= BIT(ep.port);
>> + priv->nsources++;
>> + }
>> + of_node_put(node);
>> + of_node_put(dev->of_node);
>> +
>> + priv->route_mask = priv->source_mask;
>> +
>> + return 0;
>> +}
>
^ permalink raw reply
* Re: [PATCH v7 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Andy Shevchenko @ 2020-05-18 11:43 UTC (permalink / raw)
To: Ramuthevar, Vadivel MuruganX
Cc: Arnd Bergmann, kbuild test robot, Linux Kernel Mailing List,
open list:MEMORY TECHNOLOGY..., devicetree, kbuild-all,
Miquel Raynal, Richard Weinberger, Vignesh R, Brendan Higgins,
Thomas Gleixner, Boris Brezillon, Anders Roxell, masonccyang
In-Reply-To: <5180e734-ff56-db5a-ab49-8a55cfa2f2c0@linux.intel.com>
On Mon, May 18, 2020 at 2:39 PM Ramuthevar, Vadivel MuruganX
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
> On 15/5/2020 10:30 pm, Arnd Bergmann wrote:
> > On Fri, May 15, 2020 at 4:25 PM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> >> On Fri, May 15, 2020 at 4:48 PM kbuild test robot <lkp@intel.com> wrote:
> > iowrite_be32() is the correct way to store word into a big-endian mmio register,
> > if that is the intention here.
> Thank you for suggestions to use iowrite32be(), it suits exactly.
Can you before doing this comment what is the real intention here?
And note, if you are going to use iowrite*() / ioread*() in one place,
you will probably need to replace all of the read*() / write*() to
respective io* API.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 15/17] ARM: dts: r8a7742: Add APMU nodes
From: Geert Uytterhoeven @ 2020-05-18 11:41 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Rob Herring, Wolfram Sang,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux-Renesas, Prabhakar,
Rafael J. Wysocki, Daniel Lezcano, Linux PM list
In-Reply-To: <1589555337-5498-16-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
reduced CC list
added CPUidle people
On Fri, May 15, 2020 at 5:10 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Add DT nodes for the Advanced Power Management Units (APMU), and use the
> enable-method to point out that the APMU should be used for SMP support.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Thanks for your patch!
> --- a/arch/arm/boot/dts/r8a7742.dtsi
> +++ b/arch/arm/boot/dts/r8a7742.dtsi
> @@ -18,6 +18,7 @@
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> + enable-method = "renesas,apmu";
According to Documentation/devicetree/bindings/arm/cpus.yaml,
"enable-method" should be a property of the individual CPU nodes,
and not of the parent "cpus" container node.
However, so far we always put it in the parents "cpus" node, which works from
secondary CPU bringup, but may cause issues with CPUidle?
See also "[PATCH/RFC v2] ARM: dts: r8a7791: Move enable-method to CPU nodes"
https://lore.kernel.org/linux-arm-kernel/20190514085837.18325-1-geert+renesas@glider.be/
which so far has received no feedback from the DT or CPUidle people.
Thanks!
> cpu0: cpu@0 {
> device_type = "cpu";
> @@ -305,6 +306,18 @@
> #reset-cells = <1>;
> };
>
> + apmu@e6151000 {
> + compatible = "renesas,r8a7742-apmu", "renesas,apmu";
> + reg = <0 0xe6151000 0 0x188>;
> + cpus = <&cpu4 &cpu5 &cpu6 &cpu7>;
> + };
> +
> + apmu@e6152000 {
> + compatible = "renesas,r8a7742-apmu", "renesas,apmu";
> + reg = <0 0xe6152000 0 0x188>;
> + cpus = <&cpu0 &cpu1 &cpu2 &cpu3>;
> + };
> +
> rst: reset-controller@e6160000 {
> compatible = "renesas,r8a7742-rst";
> reg = <0 0xe6160000 0 0x0100>;
Regardless:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
and I'll see what I will queue in renesas-devel for v5.9 ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v7 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Ramuthevar, Vadivel MuruganX @ 2020-05-18 11:39 UTC (permalink / raw)
To: Arnd Bergmann, Andy Shevchenko
Cc: kbuild test robot, Linux Kernel Mailing List,
open list:MEMORY TECHNOLOGY..., devicetree, kbuild-all,
Miquel Raynal, Richard Weinberger, Vignesh R, Brendan Higgins,
Thomas Gleixner, Boris Brezillon, Anders Roxell, masonccyang
In-Reply-To: <CAK8P3a3RKJo-C5=19oAppx212s7T8NdnKJVmkj+h=34a8aKMNA@mail.gmail.com>
Hi Arnd, Andy,
On 15/5/2020 10:30 pm, Arnd Bergmann wrote:
> On Fri, May 15, 2020 at 4:25 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>>
>> On Fri, May 15, 2020 at 4:48 PM kbuild test robot <lkp@intel.com> wrote:
>>
>>> sparse warnings: (new ones prefixed by >>)
>>>
>>>>> drivers/mtd/nand/raw/intel-nand-controller.c:441:24: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int val @@ got restricted __be32 [assignedunsigned int val @@
>>>>> drivers/mtd/nand/raw/intel-nand-controller.c:441:24: sparse: expected unsigned int val
>>>>> drivers/mtd/nand/raw/intel-nand-controller.c:441:24: sparse: got restricted __be32 [assigned] [usertype] reg
>>> drivers/mtd/nand/raw/intel-nand-controller.c:444:24: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int val @@ got restricted __be32 [assignedunsigned int val @@
>>> drivers/mtd/nand/raw/intel-nand-controller.c:444:24: sparse: expected unsigned int val
>>> drivers/mtd/nand/raw/intel-nand-controller.c:444:24: sparse: got restricted __be32 [assigned] [usertype] reg
>>>
>>> 440 reg = cpu_to_be32(*pdata++);
>>> > 441 writel(reg, ebu_host->hsnand + HSNAND_CMSG_0);
>>> 442
>>> 443 reg = cpu_to_be32(*pdata);
>>> 444 writel(reg, ebu_host->hsnand + HSNAND_CMSG_1);
>>
>> On BE:
>> cpu_to_be32 -> no-op
>> writel() -> converts reg to LE
>>
>> On LE:
>> cpu_to_be32 -> converts to BE
>> writel() -> no-op (in terms of conversion)
>>
>> Seems to me that the proper API (if above is intended) should be swab32().
>> But something tells me that above is broken (or my understanding is wrong).
>
> iowrite_be32() is the correct way to store word into a big-endian mmio register,
> if that is the intention here.
Thank you for suggestions to use iowrite32be(), it suits exactly.
Regards
Vadivel
>
> Arnd
>
^ permalink raw reply
* Re: [PATCH v2 06/19] spi: dw: Discard static DW DMA slave structures
From: Andy Shevchenko @ 2020-05-18 11:38 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Serge Semin, Mark Brown, Georgy Vlasov,
Ramil Zaripov, Alexey Malahov, Thomas Bogendoerfer, Paul Burton,
Ralf Baechle, Allison Randal, Gareth Williams, Arnd Bergmann,
Rob Herring, linux-mips, devicetree, Wan Ahmad Zainie,
Jarkko Nikula, Thomas Gleixner, wuxu.wu, Clement Leger, linux-spi,
Linux Kernel Mailing List
In-Reply-To: <20200518110004.GW1634618@smile.fi.intel.com>
On Mon, May 18, 2020 at 2:01 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Sat, May 16, 2020 at 05:20:30PM +0300, Serge Semin wrote:
> > On Fri, May 15, 2020 at 03:34:22PM +0300, Andy Shevchenko wrote:
> > > On Fri, May 15, 2020 at 01:47:45PM +0300, Serge Semin wrote:
> > > > Having them declared is redundant since each struct dw_dma_chan has
> > > > the same structure embedded and the structure from the passed dma_chan
> > > > private pointer will be copied there as a result of the next calls
> > > > chain:
> > > > dma_request_channel() -> find_candidate() -> dma_chan_get() ->
> > > > device_alloc_chan_resources() = dwc_alloc_chan_resources() ->
> > > > dw_dma_filter().
> > > > So just remove the static dw_dma_chan structures and use a locally
> > > > declared data instance with dst_id/src_id set to the same values as
> > > > the static copies used to have.
> > >
> > > ...
> > >
> > > > -static struct dw_dma_slave mid_dma_tx = { .dst_id = 1 };
> > > > -static struct dw_dma_slave mid_dma_rx = { .src_id = 0 };
> > >
> > > > + struct dw_dma_slave slave = {0};
> > >
> > > I really would like to leave them separated and as in the original form, i.e.
> > >
> > > struct dw_dma_slave tx = { .dst_id = 1 };
> > > struct dw_dma_slave rx = { .src_id = 0 };
> > >
> > > those src and dst IDs are put in that form on purpose...
> >
> > As long as you don't tell us what purpose it is, my position won't change.
>
> It's not the way when your changes makes this the older (upstreamed) stuff's
> issue, it's an opposite. But I will help you here...
>
> > These structures declared here just hold the static memory and nothing
> > else. Allocating them on stack is better.
>
> I'm not talking about stack, it's fine for me, what I'm talking about is *how*
> they are being initialized. Read my message again carefully, please.
And to avoid additional churn around this, the purpose is to show what
Dreq number is in use actually for these transfers (that's why 0
assignment is explicitly there and no counterpart Dreq filled).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] of: drop a reference on error in __of_attach_node_sysfs()
From: Dan Carpenter @ 2020-05-18 11:30 UTC (permalink / raw)
To: Rob Herring, Frank Rowand
Cc: Michael Ellerman, devicetree, linux-kernel, kernel-janitors
We add a new of_node_get() to this function, but we should drop the
reference if kobject_add().
Fixes: 5b2c2f5a0ea3 ("of: overlay: add missing of_node_get() in __of_attach_node_sysfs")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
From static analysis. Maybe we should just call of_node_get() right
before we return 0?
drivers/of/kobj.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/of/kobj.c b/drivers/of/kobj.c
index c72eef988041..a90dc4b3b060 100644
--- a/drivers/of/kobj.c
+++ b/drivers/of/kobj.c
@@ -138,8 +138,10 @@ int __of_attach_node_sysfs(struct device_node *np)
rc = kobject_add(&np->kobj, parent, "%s", name);
kfree(name);
- if (rc)
+ if (rc) {
+ of_node_put(np);
return rc;
+ }
for_each_property_of_node(np, pp)
__of_add_property_sysfs(np, pp);
--
2.26.2
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: mt6797: Fix mmsys node name
From: matthias.bgg @ 2020-05-18 11:31 UTC (permalink / raw)
To: Rob Herring, Matthias Brugger, Michael Turquette, Stephen Boyd
Cc: mtk01761, devicetree, Allison Randal, linux-kernel,
Thomas Gleixner, linux-mediatek, Kate Stewart, Greg Kroah-Hartman,
linux-clk, linux-arm-kernel
In-Reply-To: <20200518113156.25009-1-matthias.bgg@kernel.org>
From: Matthias Brugger <matthias.bgg@gmail.com>
Node names are supposed to match the class of the device. The
mmsys node is a syscon as it provides more then just a clock controller.
Update the name.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
---
arch/arm64/boot/dts/mediatek/mt6797.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
index 136ef9527a0d..3efd032481ce 100644
--- a/arch/arm64/boot/dts/mediatek/mt6797.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
@@ -233,7 +233,7 @@ uart3: serial@11005000 {
status = "disabled";
};
- mmsys: mmsys_config@14000000 {
+ mmsys: syscon@14000000 {
compatible = "mediatek,mt6797-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
#clock-cells = <1>;
--
2.26.2
^ permalink raw reply related
* [PATCH 3/4] clk/soc: mediatek: mt6779: Bind clock driver from platform device
From: matthias.bgg @ 2020-05-18 11:31 UTC (permalink / raw)
To: Rob Herring, Matthias Brugger, Michael Turquette, Stephen Boyd
Cc: mtk01761, devicetree, Allison Randal, linux-kernel,
Thomas Gleixner, linux-mediatek, Kate Stewart, Greg Kroah-Hartman,
linux-clk, linux-arm-kernel
In-Reply-To: <20200518113156.25009-1-matthias.bgg@kernel.org>
From: Matthias Brugger <matthias.bgg@gmail.com>
The mmsys driver is now the top level entry point for the multimedia
system (mmsys), we bind the clock driver by creating a platform device.
We also bind the MediaTek DRM driver which is not yet implement and
therefor will errror out for now.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/clk/mediatek/clk-mt6779-mm.c | 9 ++-------
drivers/soc/mediatek/mtk-mmsys.c | 8 ++++++++
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt6779-mm.c b/drivers/clk/mediatek/clk-mt6779-mm.c
index fb5fbb8e3e41..059c1a41ac7a 100644
--- a/drivers/clk/mediatek/clk-mt6779-mm.c
+++ b/drivers/clk/mediatek/clk-mt6779-mm.c
@@ -84,15 +84,11 @@ static const struct mtk_gate mm_clks[] = {
GATE_MM1(CLK_MM_DISP_OVL_FBDC, "mm_disp_ovl_fbdc", "mm_sel", 16),
};
-static const struct of_device_id of_match_clk_mt6779_mm[] = {
- { .compatible = "mediatek,mt6779-mmsys", },
- {}
-};
-
static int clk_mt6779_mm_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
+ struct device_node *node = dev->parent->of_node;
struct clk_onecell_data *clk_data;
- struct device_node *node = pdev->dev.of_node;
clk_data = mtk_alloc_clk_data(CLK_MM_NR_CLK);
@@ -106,7 +102,6 @@ static struct platform_driver clk_mt6779_mm_drv = {
.probe = clk_mt6779_mm_probe,
.driver = {
.name = "clk-mt6779-mm",
- .of_match_table = of_match_clk_mt6779_mm,
},
};
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index fee64c8d3020..dc15808cf3a3 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -88,6 +88,10 @@ static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
.clk_driver = "clk-mt2712-mm",
};
+static const struct mtk_mmsys_driver_data mt6779_mmsys_driver_data = {
+ .clk_driver = "clk-mt6779-mm",
+};
+
static const struct mtk_mmsys_driver_data mt6797_mmsys_driver_data = {
.clk_driver = "clk-mt6797-mm",
};
@@ -343,6 +347,10 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
.compatible = "mediatek,mt2712-mmsys",
.data = &mt2712_mmsys_driver_data,
},
+ {
+ .compatible = "mediatek,mt6779-mmsys",
+ .data = &mt6779_mmsys_driver_data,
+ },
{
.compatible = "mediatek,mt6797-mmsys",
.data = &mt6797_mmsys_driver_data,
--
2.26.2
^ permalink raw reply related
* [PATCH 2/4] clk/soc: mediatek: mt6797: Bind clock driver from platform device
From: matthias.bgg @ 2020-05-18 11:31 UTC (permalink / raw)
To: Rob Herring, Matthias Brugger, Michael Turquette, Stephen Boyd
Cc: mtk01761, devicetree, Allison Randal, linux-kernel,
Thomas Gleixner, linux-mediatek, Kate Stewart, Greg Kroah-Hartman,
linux-clk, linux-arm-kernel, Richard Fontana
In-Reply-To: <20200518113156.25009-1-matthias.bgg@kernel.org>
From: Matthias Brugger <matthias.bgg@gmail.com>
The mmsys driver is now the top level entry point for the multimedia
system (mmsys), we bind the clock driver by creating a platform device.
We also bind the MediaTek DRM driver which is not yet implement and
therefor will errror out for now.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/clk/mediatek/clk-mt6797-mm.c | 9 ++-------
drivers/soc/mediatek/mtk-mmsys.c | 8 ++++++++
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt6797-mm.c b/drivers/clk/mediatek/clk-mt6797-mm.c
index 8f05653b387d..01fdce287247 100644
--- a/drivers/clk/mediatek/clk-mt6797-mm.c
+++ b/drivers/clk/mediatek/clk-mt6797-mm.c
@@ -92,16 +92,12 @@ static const struct mtk_gate mm_clks[] = {
"clk26m", 3),
};
-static const struct of_device_id of_match_clk_mt6797_mm[] = {
- { .compatible = "mediatek,mt6797-mmsys", },
- {}
-};
-
static int clk_mt6797_mm_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
+ struct device_node *node = dev->parent->of_node;
struct clk_onecell_data *clk_data;
int r;
- struct device_node *node = pdev->dev.of_node;
clk_data = mtk_alloc_clk_data(CLK_MM_NR);
@@ -121,7 +117,6 @@ static struct platform_driver clk_mt6797_mm_drv = {
.probe = clk_mt6797_mm_probe,
.driver = {
.name = "clk-mt6797-mm",
- .of_match_table = of_match_clk_mt6797_mm,
},
};
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 783c3dd008b2..fee64c8d3020 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -88,6 +88,10 @@ static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
.clk_driver = "clk-mt2712-mm",
};
+static const struct mtk_mmsys_driver_data mt6797_mmsys_driver_data = {
+ .clk_driver = "clk-mt6797-mm",
+};
+
static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
.clk_driver = "clk-mt8173-mm",
};
@@ -339,6 +343,10 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
.compatible = "mediatek,mt2712-mmsys",
.data = &mt2712_mmsys_driver_data,
},
+ {
+ .compatible = "mediatek,mt6797-mmsys",
+ .data = &mt6797_mmsys_driver_data,
+ },
{
.compatible = "mediatek,mt8173-mmsys",
.data = &mt8173_mmsys_driver_data,
--
2.26.2
^ permalink raw reply related
* [PATCH 1/4] clk/soc: mediatek: mt8183: Bind clock driver from platform device
From: matthias.bgg @ 2020-05-18 11:31 UTC (permalink / raw)
To: Rob Herring, Matthias Brugger, Michael Turquette, Stephen Boyd
Cc: mtk01761, devicetree, Allison Randal, linux-kernel,
Thomas Gleixner, linux-mediatek, Kate Stewart, Greg Kroah-Hartman,
linux-clk, linux-arm-kernel
From: Matthias Brugger <matthias.bgg@gmail.com>
The mmsys driver is now the top level entry point for the multimedia
system (mmsys), we bind the clock driver by creating a platform device.
We also bind the MediaTek DRM driver which is not yet implement and
therefor will errror out for now.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/clk/mediatek/clk-mt8183-mm.c | 9 ++-------
drivers/soc/mediatek/mtk-mmsys.c | 8 ++++++++
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt8183-mm.c b/drivers/clk/mediatek/clk-mt8183-mm.c
index 720c696b506d..9d60e09619c1 100644
--- a/drivers/clk/mediatek/clk-mt8183-mm.c
+++ b/drivers/clk/mediatek/clk-mt8183-mm.c
@@ -84,8 +84,9 @@ static const struct mtk_gate mm_clks[] = {
static int clk_mt8183_mm_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
+ struct device_node *node = dev->parent->of_node;
struct clk_onecell_data *clk_data;
- struct device_node *node = pdev->dev.of_node;
clk_data = mtk_alloc_clk_data(CLK_MM_NR_CLK);
@@ -95,16 +96,10 @@ static int clk_mt8183_mm_probe(struct platform_device *pdev)
return of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
}
-static const struct of_device_id of_match_clk_mt8183_mm[] = {
- { .compatible = "mediatek,mt8183-mmsys", },
- {}
-};
-
static struct platform_driver clk_mt8183_mm_drv = {
.probe = clk_mt8183_mm_probe,
.driver = {
.name = "clk-mt8183-mm",
- .of_match_table = of_match_clk_mt8183_mm,
},
};
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index cacafe23c823..783c3dd008b2 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -92,6 +92,10 @@ static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
.clk_driver = "clk-mt8173-mm",
};
+static const struct mtk_mmsys_driver_data mt8183_mmsys_driver_data = {
+ .clk_driver = "clk-mt8183-mm",
+};
+
static unsigned int mtk_mmsys_ddp_mout_en(enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next,
unsigned int *addr)
@@ -339,6 +343,10 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
.compatible = "mediatek,mt8173-mmsys",
.data = &mt8173_mmsys_driver_data,
},
+ {
+ .compatible = "mediatek,mt8183-mmsys",
+ .data = &mt8183_mmsys_driver_data,
+ },
{ }
};
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v3 00/20] dts/dt-bindings: Fix Arm Ltd. ARMv8 "boards"
From: Sudeep Holla @ 2020-05-18 11:31 UTC (permalink / raw)
To: Andre Przywara
Cc: Sudeep Holla, Liviu Dudau, Lorenzo Pieralisi, Rob Herring,
Marc Zyngier, linux-arm-kernel, devicetree, Mark Rutland
In-Reply-To: <20200513103016.130417-1-andre.przywara@arm.com>
On Wed, 13 May 2020 11:29:56 +0100, Andre Przywara wrote:
> A few updates compared to v2. The most important is to fix the
> interrupt-maps, triggered by changing the number of address-cells in
> the GIC node. For this I split the former patch 07/17 into two (09/20
> and 10/20), one for the foundation model, the other for Juno.
> Also I fixed a dtc complaint about device nodes without reg properties
> being inside simple-bus nodes, those are the new patches 04-06/20.
> Will took patch 01/17 from v2 already, so I removed this from this
> series.
> The rest of the patches stayed the same.
> -----------------------------------
>
> [...]
Hi Andre,
Patch 12/20 was missing your Signed-off tags, re-applied adding the same.
Applied to scmi-vexpress-juno (for-next/juno), thanks!
[02/20] arm64: dts: fvp/juno: Fix node address fields
https://git.kernel.org/sudeep.holla/c/bb5cce12ac
[03/20] arm64: dts: fvp: Move fixed devices out of bus node
https://git.kernel.org/sudeep.holla/c/849bfc3dfc
[04/20] arm64: dts: vexpress: Move fixed devices out of bus node
https://git.kernel.org/sudeep.holla/c/d9258898ad
[05/20] arm64: dts: fvp: Move fixed clocks out of bus node
https://git.kernel.org/sudeep.holla/c/feebdc3f79
[06/20] arm64: dts: juno: Move fixed devices out of bus node
https://git.kernel.org/sudeep.holla/c/948204a1bf
[07/20] arm64: dts: juno: Fix mem-timer
https://git.kernel.org/sudeep.holla/c/0e529dae51
[08/20] arm64: dts: fvp: Fix GIC compatible names
https://git.kernel.org/sudeep.holla/c/336edacfb9
[09/20] arm64: dts: juno: Fix GIC child nodes
https://git.kernel.org/sudeep.holla/c/a78aee9e43
[10/20] arm64: dts: fvp: Fix GIC child nodes
https://git.kernel.org/sudeep.holla/c/78631aecc5
[11/20] arm64: dts: fvp: Fix ITS node names and #msi-cells
https://git.kernel.org/sudeep.holla/c/fac959c93f
[12/20] arm64: dts: juno: Use proper DT node name for USB
https://git.kernel.org/sudeep.holla/c/a66ab61b2c
[13/20] arm64: dts: fvp/juno: Fix serial node names
https://git.kernel.org/sudeep.holla/c/1d33445a19
[14/20] arm64: dts: fvp: Fix SMMU DT node
https://git.kernel.org/sudeep.holla/c/386270bad0
[15/20] arm64: dts: fvp/juno: Fix bus node names
https://git.kernel.org/sudeep.holla/c/48db29f2c9
[16/20] arm64: dts: juno: Fix GPU interrupt order
https://git.kernel.org/sudeep.holla/c/90280c4dc0
[17/20] arm64: dts: vexpress: Fix VExpress LED names
https://git.kernel.org/sudeep.holla/c/dc6e874179
[18/20] arm64: dts: juno: Fix SCPI shared mem node name
https://git.kernel.org/sudeep.holla/c/267c673233
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 11/12] gpu/drm: Ingenic: Add support for the IPU
From: Paul Cercueil @ 2020-05-18 11:26 UTC (permalink / raw)
To: Emil Velikov
Cc: David Airlie, Daniel Vetter, Rob Herring, Greg Kroah-Hartman,
Rafael J . Wysocki, devicetree, od, linux-kernel, ML dri-devel
In-Reply-To: <CACvgo50q=qJXk3nFSCm+S6JHBMxpY0C_HwH8KGB2EAcKwgL0oQ@mail.gmail.com>
Hi Emil,
Le lun. 18 mai 2020 à 11:48, Emil Velikov <emil.l.velikov@gmail.com> a
écrit :
> Hi Paul,
>
> Disclaimer: I don't know much about the hardware :-P
>
> On Sun, 17 May 2020 at 00:31, Paul Cercueil <paul@crapouillou.net>
> wrote:
>>
>> Add support for the Image Processing Unit (IPU) found in all Ingenic
>> SoCs.
>>
> Since the IPU is present on all devices supported, does it make sense
> to have it as separate module?
> Didn't check closely although I suspect doing that will remove the
> need for the component patch.
It makes sense to me; you may not want to enable the IPU on platforms
where it doesn't add much, e.g. on the JZ4725B where it only handles
YUV and not RGB.
Besides, while the older JZ4740 SoC has a IPU, it's mem-to-mem and
cannot output directly to the CRTC, so it cannot be represented as a
plane. On this SoC the current IPU code cannot be used. So the Ingenic
DRM driver must still be able to probe with zero components.
>> --- a/drivers/gpu/drm/ingenic/ingenic-drm.c
>> +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
>> @@ -50,7 +50,7 @@ struct jz_soc_info {
>>
>> struct ingenic_drm {
>> struct drm_device drm;
>> - struct drm_plane f0, f1;
>> + struct drm_plane f0, f1, *ipu_plane;
>> struct drm_crtc crtc;
>> struct drm_encoder encoder;
>>
>> @@ -186,13 +186,16 @@ static void
>> ingenic_drm_crtc_update_timings(struct ingenic_drm *priv,
>> regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
>> JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16,
>> JZ_LCD_CTRL_OFUP | JZ_LCD_CTRL_BURST_16);
>> +
>> + regmap_write(priv->map, JZ_REG_LCD_IPUR, JZ_LCD_IPUR_IPUREN
>> |
>> + (ht * vpe / 3) << JZ_LCD_IPUR_IPUR_LSB);
>
> This hunk also indicates that it may be better to merge the IPU within
> the existing driver.
This writes the IPUR register of the CRTC, nothing wrong here.
-Paul
^ permalink raw reply
* Re: [PATCH 05/17] mmc: renesas_sdhi_sys_dmac: Add support for r8a7742 SoC
From: Geert Uytterhoeven @ 2020-05-18 11:24 UTC (permalink / raw)
To: Wolfram Sang
Cc: Lad Prabhakar, Jens Axboe, Rob Herring, Ulf Hansson,
Sergei Shtylyov, David S. Miller, Wim Van Sebroeck, Guenter Roeck,
linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux I2C, Linux MMC List, netdev,
Linux-Renesas, Linux Watchdog Mailing List, Prabhakar
In-Reply-To: <20200515171754.GF19423@ninjato>
Hi Wolfram, Prabhakar,
On Fri, May 15, 2020 at 7:17 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> On Fri, May 15, 2020 at 04:08:45PM +0100, Lad Prabhakar wrote:
> > Add support for r8a7742 SoC. Renesas RZ/G1H (R8A7742) SDHI is identical to
> > the R-Car Gen2 family.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
>
> I think we can skip this because of the generic fallback? The other
Agreed.
> entries come from a time when we had a different policy IIRC.
Indeed. Commit c16a854e4463078a ("mmc: renesas_sdhi: Add r8a7743/5
support") predated commit d6dc425ae595e140 ("mmc: renesas_sdhi:
implement R-Car Gen[123] fallback compatibility strings").
> > --- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> > +++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> > @@ -75,6 +75,7 @@ static const struct of_device_id renesas_sdhi_sys_dmac_of_match[] = {
> > { .compatible = "renesas,sdhi-r7s72100", .data = &of_rz_compatible, },
> > { .compatible = "renesas,sdhi-r8a7778", .data = &of_rcar_gen1_compatible, },
> > { .compatible = "renesas,sdhi-r8a7779", .data = &of_rcar_gen1_compatible, },
> > + { .compatible = "renesas,sdhi-r8a7742", .data = &of_rcar_gen2_compatible, },
> > { .compatible = "renesas,sdhi-r8a7743", .data = &of_rcar_gen2_compatible, },
> > { .compatible = "renesas,sdhi-r8a7745", .data = &of_rcar_gen2_compatible, },
> > { .compatible = "renesas,sdhi-r8a7790", .data = &of_rcar_gen2_compatible, },
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 18/19] spi: dw: Use regset32 DebugFS method to create regdump file
From: Andy Shevchenko @ 2020-05-18 11:18 UTC (permalink / raw)
To: Serge Semin
Cc: Serge Semin, Mark Brown, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Thomas Bogendoerfer, Paul Burton, Ralf Baechle,
Arnd Bergmann, Allison Randal, Gareth Williams, Rob Herring,
linux-mips, devicetree, Wan Ahmad Zainie, Charles Keepax,
Clement Leger, wuxu.wu, Phil Edworthy, Thomas Gleixner,
Jarkko Nikula, linux-spi, linux-kernel
In-Reply-To: <20200516204634.td52orxfnh7iewg6@mobilestation>
On Sat, May 16, 2020 at 11:46:34PM +0300, Serge Semin wrote:
> On Fri, May 15, 2020 at 06:10:56PM +0300, Andy Shevchenko wrote:
> > On Fri, May 15, 2020 at 01:47:57PM +0300, Serge Semin wrote:
> > > DebugFS kernel interface provides a dedicated method to create the
> > > registers dump file. Use it instead of creating a generic DebugFS
> > > file with manually written read callback function.
> > With below nit addressed,
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > +#define DW_SPI_DBGFS_REG(_name, _off) \
> > > +{ \
> > > + .name = _name, \
> >
> > > + .offset = _off \
> >
> > As previously discussed (did I miss your answer?) the comma at the end leaves
> > better pattern for maintenance prospective.
>
> Ah, sorry. Missed that. This comma is hardly needed seeing the structure
> consists of just two elements. So I'd rather leave it as is.
While it's a really small thing, I consider that it's not good to make
someone's else problem what can be done here. So, please, consider to add a
comma. Look at the other drivers and code in the kernel. This is at least
defacto preferred style.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 16/17] dt-bindings: watchdog: renesas,wdt: Document r8a7742 support
From: Geert Uytterhoeven @ 2020-05-18 11:17 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Jens Axboe, Rob Herring, Wolfram Sang, Ulf Hansson,
Sergei Shtylyov, David S. Miller, Wim Van Sebroeck, Guenter Roeck,
linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux I2C, Linux MMC List, netdev,
Linux-Renesas, Linux Watchdog Mailing List, Prabhakar
In-Reply-To: <1589555337-5498-17-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, May 15, 2020 at 5:10 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> RZ/G1H (R8A7742) watchdog implementation is compatible with R-Car Gen2,
> therefore add relevant documentation.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 14/17] dt-bindings: power: renesas,apmu: Document r8a7742 support
From: Geert Uytterhoeven @ 2020-05-18 11:16 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Jens Axboe, Rob Herring, Wolfram Sang, Ulf Hansson,
Sergei Shtylyov, David S. Miller, Wim Van Sebroeck, Guenter Roeck,
linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux I2C, Linux MMC List, netdev,
Linux-Renesas, Linux Watchdog Mailing List, Prabhakar
In-Reply-To: <1589555337-5498-15-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, May 15, 2020 at 5:10 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Document APMU and SMP enable method for RZ/G1H (also known as r8a7742)
> SoC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 11/17] dt-bindings: net: renesas,ether: Document R8A7742 SoC
From: Geert Uytterhoeven @ 2020-05-18 11:15 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Jens Axboe, Rob Herring, Wolfram Sang, Ulf Hansson,
Sergei Shtylyov, David S. Miller, Wim Van Sebroeck, Guenter Roeck,
linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux I2C, Linux MMC List, netdev,
Linux-Renesas, Linux Watchdog Mailing List, Prabhakar
In-Reply-To: <1589555337-5498-12-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, May 15, 2020 at 5:10 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Document RZ/G1H (R8A7742) SoC bindings.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 4/4] sc16is7xx: Use threaded IRQ
From: Maarten Brock @ 2020-05-18 11:14 UTC (permalink / raw)
To: Daniel Mack
Cc: devicetree, linux-serial, gregkh, robh+dt, jslaby, pascal.huerst,
linux-serial-owner
In-Reply-To: <584de876-e675-0172-97ed-0c9534eb9526@zonque.org>
On 2020-05-17 22:44, Daniel Mack wrote:
> Hi Maarten,
>
> Thanks for your review!
>
> On 5/9/20 2:55 PM, Maarten Brock wrote:
>> On 2020-05-08 16:37, Daniel Mack wrote:
>>> Use a threaded IRQ handler to get rid of the irq_work kthread.
>>> This also allows for the driver to use interrupts generated by
>>> a threaded controller.
>>>
>>> Signed-off-by: Daniel Mack <daniel@zonque.org>
>>> ---
>>> drivers/tty/serial/sc16is7xx.c | 18 +++++-------------
>>> 1 file changed, 5 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/tty/serial/sc16is7xx.c
>>> b/drivers/tty/serial/sc16is7xx.c
>
>>> @@ -1317,8 +1308,9 @@ static int sc16is7xx_probe(struct device *dev,
>>> }
>>>
>>> /* Setup interrupt */
>>> - ret = devm_request_irq(dev, irq, sc16is7xx_irq,
>>> - IRQF_TRIGGER_FALLING, dev_name(dev), s);
>>> + ret = devm_request_threaded_irq(dev, irq, NULL, sc16is7xx_irq,
>>> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>>> + dev_name(dev), s);
>>> if (!ret)
>>> return 0;
>>
>> Since UART0 is first handled completely in the for loop before UART1
>> is
>> handled, a new interrupt may arise on UART0 while UART1 is being
>> handled.
>
> The code in the interrupt handling function loops forever until there
> is
> no more interrupt bits pending. So if there is a new IRQ happening for
> UART0 while UART1 is being served, it will be handled in the same loop.
I'm sorry. I remembered this problem and didn't look well enough. It has
been fixed already for 20 months by the keep_polling flag.
> And just to be sure I understand correctly: this is unrelated to the
> switch to threaded IRQs, right? Falling edge triggers were always used
> for pdata probed devices.
The switch to threaded makes it possible to use IRQF_TRIGGER_LOW instead
of IRQF_TRIGGER_FALLING. The current implementation would keep on
triggering
with IRQF_TRIGGER_LOW and the worker thread might not even get executed.
I don't have a clue what a pdata probed device is.
>> The result is a missed interrupt since the IRQ line might not *FALL*
>> again.
>
> It doesn't have to. We only exit the interrupt handler when there is
> nothing left to do, at which point the IRQ line ist back high. So it
> will fall again in case of new events.
Right, already fixed for a single device.
Different problem then: what if the interrupt is shared with another
device, say another sc16is7xx?
>> Therefor I suggest to change IRQF_TRIGGER_FALLING to IRQF_TRIGGER_LOW.
>> This
>> way the thread will be retriggered after IRQ_HANDLED is returned.
>
> This doesn't work in my setup unfortunately, as the interrupt
> controller
> is incapable of handling level IRQs.
That sounds like a lousy interrupt controller to me. But still, I would
expect the interrupt controller driver to handle that problem, not the
device driver for the device hanging off the interrupt controller. Or
at least the interrupt controller driver should throw an error.
> Thanks,
> Daniel
Summerizing:
- After switching to a threaded IRQ, the trigger could be switched to
IRQF_TRIGGER_LOW and with that interrupt sharing can be enabled for
this device with IRQF_SHARED.
- Some (your) interrupt controllers do not support IRQF_TRIGGER_LOW.
For those only IRQF_TRIGGER_FALLING can be used for this device and
thus IRQF_SHARED cannot be used.
- The driver for your interrupt controller should be improved to support
level IRQs.
This makes me wonder if it would be better to let the device tree
specify
the interrupt configuration. Which leads back to my earlier question:
How
does one specify in the device tree that an interrupt is shared?
Kind regards,
Maarten
^ permalink raw reply
* Re: [PATCH 10/17] dt-bindings: net: renesas,ravb: Add support for r8a7742 SoC
From: Geert Uytterhoeven @ 2020-05-18 11:14 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Jens Axboe, Rob Herring, Wolfram Sang, Ulf Hansson,
Sergei Shtylyov, David S. Miller, Wim Van Sebroeck, Guenter Roeck,
linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux I2C, Linux MMC List, netdev,
Linux-Renesas, Linux Watchdog Mailing List, Prabhakar
In-Reply-To: <1589555337-5498-11-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, May 15, 2020 at 5:10 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Document RZ/G1H (R8A7742) SoC bindings.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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