* Re: [PATCH v4 02/11] mfd: Add support for Kontron sl28cpld management controller
From: Lee Jones @ 2020-06-05 6:57 UTC (permalink / raw)
To: Michael Walle, broonie
Cc: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
linux-watchdog, linux-arm-kernel, Linus Walleij,
Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Mark Brown, Greg Kroah-Hartman, Andy Shevchenko
In-Reply-To: <20200604211039.12689-3-michael@walle.cc>
Mark, what do you think?
On Thu, 04 Jun 2020, Michael Walle wrote:
> Add the core support for the board management controller found on the
> SMARC-sAL28 board. It consists of the following functions:
> - watchdog
> - GPIO controller
> - PWM controller
> - fan sensor
> - interrupt controller
>
> At the moment, this controller is used on the Kontron SMARC-sAL28 board.
>
> Please note that the MFD driver is defined as bool in the Kconfig
> because the next patch will add interrupt support.
>
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
> drivers/mfd/Kconfig | 19 ++++++++++
> drivers/mfd/Makefile | 2 ++
> drivers/mfd/sl28cpld.c | 79 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 100 insertions(+)
> create mode 100644 drivers/mfd/sl28cpld.c
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 4f8b73d92df3..5c0cd514d197 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -2109,5 +2109,24 @@ config SGI_MFD_IOC3
> If you have an SGI Origin, Octane, or a PCI IOC3 card,
> then say Y. Otherwise say N.
>
> +config MFD_SL28CPLD
> + bool "Kontron sl28 core driver"
"Kontron SL28 Core Driver"
> + depends on I2C=y
> + depends on OF
> + select REGMAP_I2C
> + select MFD_CORE
> + help
> + This option enables support for the board management controller
> + found on the Kontron sl28 CPLD. You have to select individual
I can't find any reference to the "Kontron sl28 CPLD" online.
Is there a datasheet?
> + functions, such as watchdog, GPIO, etc, under the corresponding menus
> + in order to enable them.
> +
> + Currently supported boards are:
> +
> + Kontron SMARC-sAL28
> +
> + To compile this driver as a module, choose M here: the module will be
> + called sl28cpld.
> +
> endmenu
> endif
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 9367a92f795a..be59fb40aa28 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -264,3 +264,5 @@ obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
> obj-$(CONFIG_MFD_STMFX) += stmfx.o
>
> obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
> +
> +obj-$(CONFIG_MFD_SL28CPLD) += sl28cpld.o
> diff --git a/drivers/mfd/sl28cpld.c b/drivers/mfd/sl28cpld.c
> new file mode 100644
> index 000000000000..a23194bb6efa
> --- /dev/null
> +++ b/drivers/mfd/sl28cpld.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * MFD core for the sl28cpld.
Ideally this would match the Kconfig subject line.
> + * Copyright 2019 Kontron Europe GmbH
This is out of date.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/core.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/regmap.h>
> +
> +#define SL28CPLD_VERSION 0x03
> +#define SL28CPLD_MIN_REQ_VERSION 14
> +
> +struct sl28cpld {
> + struct device *dev;
> + struct regmap *regmap;
> +};
Why do you need this structure?
> +static const struct regmap_config sl28cpld_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .reg_stride = 1,
> +};
> +
> +static int sl28cpld_probe(struct i2c_client *i2c)
> +{
> + struct sl28cpld *sl28cpld;
> + struct device *dev = &i2c->dev;
> + unsigned int cpld_version;
> + int ret;
> +
> + sl28cpld = devm_kzalloc(dev, sizeof(*sl28cpld), GFP_KERNEL);
> + if (!sl28cpld)
> + return -ENOMEM;
> +
> + sl28cpld->regmap = devm_regmap_init_i2c(i2c, &sl28cpld_regmap_config);
> + if (IS_ERR(sl28cpld->regmap))
> + return PTR_ERR(sl28cpld->regmap);
This is now a shared memory allocator and not an MFD at all.
I'm clamping down on these type of drivers!
Please find a better way to accomplish this.
Potentially using "simple-mfd" and "simple-regmap".
The former already exists and does what you want. The latter doesn't
yet exist, but could solve your and lots of other contributor's
issues.
Heck maybe I'll implement it myself if this keeps happening.
> + ret = regmap_read(sl28cpld->regmap, SL28CPLD_VERSION, &cpld_version);
> + if (ret)
> + return ret;
> +
> + if (cpld_version < SL28CPLD_MIN_REQ_VERSION) {
> + dev_err(dev, "unsupported CPLD version %d\n", cpld_version);
> + return -ENODEV;
> + }
> +
> + sl28cpld->dev = dev;
> + i2c_set_clientdata(i2c, sl28cpld);
If the struct definition is in here, how do you use it elsewhere?
> + dev_info(dev, "successfully probed. CPLD version %d\n", cpld_version);
> +
> + return devm_of_platform_populate(&i2c->dev);
> +}
> +
> +static const struct of_device_id sl28cpld_of_match[] = {
> + { .compatible = "kontron,sl28cpld-r1", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, sl28cpld_of_match);
> +
> +static struct i2c_driver sl28cpld_driver = {
> + .probe_new = sl28cpld_probe,
> + .driver = {
> + .name = "sl28cpld",
> + .of_match_table = of_match_ptr(sl28cpld_of_match),
> + },
> +};
> +module_i2c_driver(sl28cpld_driver);
> +
> +MODULE_DESCRIPTION("sl28cpld MFD Core Driver");
> +MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
> +MODULE_LICENSE("GPL");
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] dt-bindings: clock: Add a missing include to MMP Audio Clock binding
From: Lubomir Rintel @ 2020-06-05 6:52 UTC (permalink / raw)
To: Stephen Boyd
Cc: Michael Turquette, Rob Herring, linux-clk, devicetree,
linux-kernel, Lubomir Rintel
The include file for input clock in the example was missing, breaking the
validation.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reported-by: Rob Herring <robh+dt@kernel.org>
---
.../devicetree/bindings/clock/marvell,mmp2-audio-clock.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/clock/marvell,mmp2-audio-clock.yaml b/Documentation/devicetree/bindings/clock/marvell,mmp2-audio-clock.yaml
index ab6e82d1d3a9e..dffa73402da93 100644
--- a/Documentation/devicetree/bindings/clock/marvell,mmp2-audio-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/marvell,mmp2-audio-clock.yaml
@@ -59,6 +59,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/clock/marvell,mmp2-audio.h>
+ #include <dt-bindings/clock/marvell,mmp2.h>
#include <dt-bindings/power/marvell,mmp2.h>
clock-controller@d42a0c30 {
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v8 10/14] media: platform: Delete redundant code for improving code quality
From: Xia Jiang @ 2020-06-05 6:41 UTC (permalink / raw)
To: Tomasz Figa
Cc: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Rick Chang, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Marek Szyprowski,
srv_heupstream, senozhatsky, mojahsu, drinkcat, maoguang.meng,
sj.huang
In-Reply-To: <20200521154958.GI209565@chromium.org>
On Thu, 2020-05-21 at 15:49 +0000, Tomasz Figa wrote:
> Hi Xia,
>
> On Fri, Apr 03, 2020 at 05:40:29PM +0800, Xia Jiang wrote:
> > Delete unused member variables annotation.
> > Delete unused variable definition.
> > Delete redundant log print, because V4L2 debug logs already print it.
> >
> > Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
> > ---
> > v8: no changes
> > ---
> > drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 16 ++--------------
> > drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 5 +++--
> > 2 files changed, 5 insertions(+), 16 deletions(-)
> >
>
> Thank you for the patch. Please see my comments inline.
>
> > diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > index 4e64046a6854..9e59b9a51ef0 100644
> > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > @@ -182,7 +182,6 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
> > struct mtk_jpeg_ctx *ctx, int q_type)
> > {
> > struct v4l2_pix_format_mplane *pix_mp = &f->fmt.pix_mp;
> > - struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> > int i;
> >
> > memset(pix_mp->reserved, 0, sizeof(pix_mp->reserved));
> > @@ -190,7 +189,7 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
> >
> > if (ctx->state != MTK_JPEG_INIT) {
> > mtk_jpeg_adjust_fmt_mplane(ctx, f);
> > - goto end;
> > + return 0;
> > }
> >
> > pix_mp->num_planes = fmt->colplanes;
> > @@ -210,7 +209,7 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
> > pfmt->sizeimage = round_up(pfmt->sizeimage, 128);
> > if (pfmt->sizeimage == 0)
> > pfmt->sizeimage = MTK_JPEG_DEFAULT_SIZEIMAGE;
> > - goto end;
> > + return 0;
> > }
> >
> > /* type is MTK_JPEG_FMT_TYPE_CAPTURE */
> > @@ -224,20 +223,9 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
> > u32 stride = pix_mp->width * fmt->h_sample[i] / 4;
> > u32 h = pix_mp->height * fmt->v_sample[i] / 4;
> >
> > - memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
>
> This change is not mentioned in the description. I'd suggest moving it
> to a separate patch, because it's a functional change.
>
> > pfmt->bytesperline = stride;
> > pfmt->sizeimage = stride * h;
> > }
> > -end:
> > - v4l2_dbg(2, debug, &jpeg->v4l2_dev, "wxh:%ux%u\n",
> > - pix_mp->width, pix_mp->height);
> > - for (i = 0; i < pix_mp->num_planes; i++) {
> > - v4l2_dbg(2, debug, &jpeg->v4l2_dev,
> > - "plane[%d] bpl=%u, size=%u\n",
> > - i,
> > - pix_mp->plane_fmt[i].bytesperline,
> > - pix_mp->plane_fmt[i].sizeimage);
> > - }
> > return 0;
> > }
> >
> > diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> > index 64a731261214..9bbd615b1067 100644
> > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> > @@ -30,6 +30,9 @@
> >
> > #define MTK_JPEG_DEFAULT_SIZEIMAGE (1 * 1024 * 1024)
> >
> > +/**
> > + * enum mtk_jpeg_ctx_state - contex state of jpeg
>
> typo: s/contex/context/
>
> But I'd rephrase it to "states of the context state machine".
>
> > + */
>
> Not mentioned in the description. Also, the documentation of an enum
> should have descriptions for the values.
Done.
>
> Best regards,
> Tomasz
^ permalink raw reply
* Re: [PATCH v8 07/14] media: platform: Use kernel native functions for improving code quality
From: Xia Jiang @ 2020-06-05 6:41 UTC (permalink / raw)
To: Tomasz Figa
Cc: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Rick Chang, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Marek Szyprowski,
srv_heupstream, senozhatsky, mojahsu, drinkcat, maoguang.meng,
sj.huang
In-Reply-To: <20200521154137.GG209565@chromium.org>
On Thu, 2020-05-21 at 15:41 +0000, Tomasz Figa wrote:
> Hi Xia,
>
> On Fri, Apr 03, 2020 at 05:40:26PM +0800, Xia Jiang wrote:
>
> Thank you for the patch. Please see my comments inline.
>
> nit: I'd remove "for improving code quality" from the subject, as it's
> obvious that we don't intend to make the code quality worse. ;)
> On the contrary, I'd make it more specific, e.g.
>
> media: mtk-jpeg: Use generic rounding helpers
>
> WDYT?
Done
>
> > Use clamp() to replace mtk_jpeg_bound_align_image() and round() to
> > replace mtk_jpeg_align().
> >
> > Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
> > ---
> > v8: no changes
> > ---
> > .../media/platform/mtk-jpeg/mtk_jpeg_core.c | 41 +++++--------------
> > .../media/platform/mtk-jpeg/mtk_jpeg_core.h | 8 ++--
> > drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c | 8 ++--
> > drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h | 5 ---
> > 4 files changed, 19 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > index 2fa3711fdc9b..4e64046a6854 100644
> > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > @@ -157,25 +157,6 @@ static struct mtk_jpeg_fmt *mtk_jpeg_find_format(struct mtk_jpeg_ctx *ctx,
> > return NULL;
> > }
> >
> > -static void mtk_jpeg_bound_align_image(u32 *w, unsigned int wmin,
> > - unsigned int wmax, unsigned int walign,
> > - u32 *h, unsigned int hmin,
> > - unsigned int hmax, unsigned int halign)
> > -{
> > - int width, height, w_step, h_step;
> > -
> > - width = *w;
> > - height = *h;
> > - w_step = 1 << walign;
> > - h_step = 1 << halign;
> > -
> > - v4l_bound_align_image(w, wmin, wmax, walign, h, hmin, hmax, halign, 0);
> > - if (*w < width && (*w + w_step) <= wmax)
> > - *w += w_step;
> > - if (*h < height && (*h + h_step) <= hmax)
> > - *h += h_step;
> > -}
> > -
> > static void mtk_jpeg_adjust_fmt_mplane(struct mtk_jpeg_ctx *ctx,
> > struct v4l2_format *f)
> > {
> > @@ -218,25 +199,25 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
> > if (q_type == MTK_JPEG_FMT_TYPE_OUTPUT) {
> > struct v4l2_plane_pix_format *pfmt = &pix_mp->plane_fmt[0];
> >
> > - mtk_jpeg_bound_align_image(&pix_mp->width, MTK_JPEG_MIN_WIDTH,
> > - MTK_JPEG_MAX_WIDTH, 0,
> > - &pix_mp->height, MTK_JPEG_MIN_HEIGHT,
> > - MTK_JPEG_MAX_HEIGHT, 0);
> > + pix_mp->height = clamp(pix_mp->height, MTK_JPEG_MIN_HEIGHT,
> > + MTK_JPEG_MAX_HEIGHT);
> > + pix_mp->width = clamp(pix_mp->width, MTK_JPEG_MIN_WIDTH,
> > + MTK_JPEG_MAX_WIDTH);
> >
> > memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
> > pfmt->bytesperline = 0;
> > /* Source size must be aligned to 128 */
> > - pfmt->sizeimage = mtk_jpeg_align(pfmt->sizeimage, 128);
> > + pfmt->sizeimage = round_up(pfmt->sizeimage, 128);
> > if (pfmt->sizeimage == 0)
> > pfmt->sizeimage = MTK_JPEG_DEFAULT_SIZEIMAGE;
> > goto end;
> > }
> >
> > /* type is MTK_JPEG_FMT_TYPE_CAPTURE */
> > - mtk_jpeg_bound_align_image(&pix_mp->width, MTK_JPEG_MIN_WIDTH,
> > - MTK_JPEG_MAX_WIDTH, fmt->h_align,
> > - &pix_mp->height, MTK_JPEG_MIN_HEIGHT,
> > - MTK_JPEG_MAX_HEIGHT, fmt->v_align);
> > + pix_mp->height = clamp(round_up(pix_mp->height, fmt->v_align),
> > + MTK_JPEG_MIN_HEIGHT, MTK_JPEG_MAX_HEIGHT);
> > + pix_mp->width = clamp(round_up(pix_mp->width, fmt->h_align),
> > + MTK_JPEG_MIN_WIDTH, MTK_JPEG_MAX_WIDTH);
> >
> > for (i = 0; i < fmt->colplanes; i++) {
> > struct v4l2_plane_pix_format *pfmt = &pix_mp->plane_fmt[i];
> > @@ -751,8 +732,8 @@ static void mtk_jpeg_set_dec_src(struct mtk_jpeg_ctx *ctx,
> > {
> > bs->str_addr = vb2_dma_contig_plane_dma_addr(src_buf, 0);
> > bs->end_addr = bs->str_addr +
> > - mtk_jpeg_align(vb2_get_plane_payload(src_buf, 0), 16);
> > - bs->size = mtk_jpeg_align(vb2_plane_size(src_buf, 0), 128);
> > + round_up(vb2_get_plane_payload(src_buf, 0), 16);
> > + bs->size = round_up(vb2_plane_size(src_buf, 0), 128);
> > }
> >
> > static int mtk_jpeg_set_dec_dst(struct mtk_jpeg_ctx *ctx,
> > diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> > index 999bd1427809..28e9b30ad5c3 100644
> > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> > @@ -21,10 +21,10 @@
> > #define MTK_JPEG_FMT_TYPE_OUTPUT 1
> > #define MTK_JPEG_FMT_TYPE_CAPTURE 2
> >
> > -#define MTK_JPEG_MIN_WIDTH 32
> > -#define MTK_JPEG_MIN_HEIGHT 32
> > -#define MTK_JPEG_MAX_WIDTH 8192
> > -#define MTK_JPEG_MAX_HEIGHT 8192
> > +#define MTK_JPEG_MIN_WIDTH 32U
> > +#define MTK_JPEG_MIN_HEIGHT 32U
> > +#define MTK_JPEG_MAX_WIDTH 8192U
> > +#define MTK_JPEG_MAX_HEIGHT 8192U
>
> This change is not mentioned in the commit message. It should go to a
> separate patch, possibly merged with other really minor stylistic changes
> like this, e.g. patch 08/14.
Done
>
> Otherwise the patch looks good, so after addressing the above minor changes
> please feel free to add
>
> Reviewed-by: Tomasz Figa <tfiga@chromium.org>
>
> Best regards,
> Tomasz
>
^ permalink raw reply
* RE: [PATCH v3 10/10] net: eth: altera: update devicetree bindings documentation
From: Ooi, Joyce @ 2020-06-05 6:36 UTC (permalink / raw)
To: Rob Herring
Cc: David S . Miller, Jakub Kicinski, Thor Thayer,
netdev@vger.kernel.org, Rob Herring, See, Chin Liang,
linux-kernel@vger.kernel.org, Nguyen, Dinh, Westergreen, Dalon,
devicetree@vger.kernel.org, Dalon Westergreen, Tan, Ley Foon
In-Reply-To: <20200604222311.GA4151468@bogus>
> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Friday, June 5, 2020 6:23 AM
> To: Ooi, Joyce <joyce.ooi@intel.com>
> Cc: David S . Miller <davem@davemloft.net>; Jakub Kicinski
> <kuba@kernel.org>; Thor Thayer <thor.thayer@linux.intel.com>;
> netdev@vger.kernel.org; Rob Herring <robh+dt@kernel.org>; See, Chin
> Liang <chin.liang.see@intel.com>; linux-kernel@vger.kernel.org; Nguyen,
> Dinh <dinh.nguyen@intel.com>; Westergreen, Dalon
> <dalon.westergreen@intel.com>; devicetree@vger.kernel.org; Dalon
> Westergreen <dalon.westergreen@linux.intel.com>; Tan, Ley Foon
> <ley.foon.tan@intel.com>
> Subject: Re: [PATCH v3 10/10] net: eth: altera: update devicetree bindings
> documentation
>
> On Thu, 04 Jun 2020 15:32:56 +0800, Ooi, Joyce wrote:
> > From: Dalon Westergreen <dalon.westergreen@intel.com>
> >
> > Update devicetree bindings documentation to include msgdma prefetcher
> > and ptp bindings.
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Dalon Westergreen <dalon.westergreen@intel.com>
> > Signed-off-by: Joyce Ooi <joyce.ooi@intel.com>
> > ---
> > v2: no change
> > v3: no change
> > ---
> > .../devicetree/bindings/net/altera_tse.txt | 103
> +++++++++++++++++----
> > 1 file changed, 84 insertions(+), 19 deletions(-)
> >
>
>
> Please add Acked-by/Reviewed-by tags when posting new versions.
> However, there's no need to repost patches *only* to add the tags. The
> upstream maintainer will do that for acks received on the version they apply.
>
> If a tag was not added on purpose, please state why and what changed.
Noted, will do that next time.
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Jassi Brar @ 2020-06-05 6:30 UTC (permalink / raw)
To: Sudeep Holla
Cc: Viresh Kumar, Rob Herring, Arnd Bergmann, Frank Rowand,
Bjorn Andersson, Vincent Guittot, linux-arm-kernel,
Devicetree List, Linux Kernel Mailing List
In-Reply-To: <20200605045645.GD12397@bogus>
On Thu, Jun 4, 2020 at 11:56 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> > >> bash-1526 [000] 1149.472553: scmi_xfer_begin: transfer_id=1538 msg_id=6 protocol_id=21 seq=0 poll=0
> > >> <idle>-0 [001] 1149.472733: scmi_xfer_begin: transfer_id=1539 msg_id=7 protocol_id=19 seq=1 poll=1
> > >
> > Here another request is started before the first is finished.
>
> Ah, the prints are when the client requested. It is not when the mailbox
> started it. So this just indicates the beginning of the transfer from the
> client.
>
There maybe condition on a sensor read to finish within 1ms, but there
is no condition for the read to _start_ at this very moment (usually
there are sleeps in the path to sensor requests).
> > If you want this to work you have to serialise access to the single
> > physical channel and/or run the remote firmware in asynchronous mode -
> > that is, the firmware ack the bit as soon as it sees and starts
> > working in the background, so that we return in ~3usec always, while
> > the data returns whenever it is ready.
>
> Yes it does that for few requests like DVFS while it uses synchronous
> mode for few others. While ideally I agree everything in asynchronous
> most is better, I don't know there may be reasons for such design.
>
The reason is that, if the firmware works asynchronously, every call
would return in ~3usec and you won't think you need virtual channels.
You have shared only 'bad' log without serialising access. Please
share log after serialising access to the channel and the 'good' log
with virtual channels. That should put the topic to rest.
thanks.
^ permalink raw reply
* Re: [PATCH v4 00/11] Add support for Kontron sl28cpld
From: Lee Jones @ 2020-06-05 6:13 UTC (permalink / raw)
To: Michael Walle
Cc: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
linux-watchdog, linux-arm-kernel, Linus Walleij,
Bartosz Golaszewski, Rob Herring, Jean Delvare, Guenter Roeck,
Thierry Reding, Uwe Kleine-König, Wim Van Sebroeck,
Shawn Guo, Li Yang, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Mark Brown, Greg Kroah-Hartman, Andy Shevchenko
In-Reply-To: <20200604211039.12689-1-michael@walle.cc>
On Thu, 04 Jun 2020, Michael Walle wrote:
> The Kontron sl28cpld is a board management chip providing gpio, pwm, fan
> monitoring and an interrupt controller. For now this controller is used on
> the Kontron SMARC-sAL28 board. But because of its flexible nature, it
> might also be used on other boards in the future. The individual blocks
> (like gpio, pwm, etc) are kept intentionally small. The MFD core driver
> then instantiates different (or multiple of the same) blocks. It also
> provides the register layout so it might be updated in the future without a
> device tree change; and support other boards with a different layout or
> functionalities.
>
> See also [1] for more information.
>
> This is my first take of a MFD driver. I don't know whether the subsystem
> maintainers should only be CCed on the patches which affect the subsystem
> or on all patches for this series. I've chosen the latter so you can get a
> more complete picture.
You chose wisely. :)
> [1] https://lore.kernel.org/linux-devicetree/0e3e8204ab992d75aa07fc36af7e4ab2@walle.cc/
>
> Changes since v3:
> - use of_platform_populate() to populate internal devices using the
> internal register offsets as unit-addresses
> - because we don't use mfd_cells anymore, we cannot use IORESOURCE_REG,
> but instead parse the reg property in each individual driver
> - dropped the following patches because they were already merged:
> gpiolib: Introduce gpiochip_irqchip_add_domain()
> gpio: add a reusable generic gpio_chip using regmap
> - dropped the following patches because they are no longer needed:
> include/linux/ioport.h: add helper to define REG resource constructs
> mfd: mfd-core: Don't overwrite the dma_mask of the child device
> mfd: mfd-core: match device tree node against reg property
> - rephrase commit messages, as suggested by Thomas Gleixner
It's great to have this changelog overview.
However it's equally, if not arguably more important to have a more
fine grained changelog in each of the patches, usually placed between
the '---' and the diff stat.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v8 05/14] media: platform: Improve power on and power off flow
From: Xia Jiang @ 2020-06-05 6:03 UTC (permalink / raw)
To: Tomasz Figa
Cc: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Rick Chang, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Marek Szyprowski,
srv_heupstream, senozhatsky, mojahsu, drinkcat, maoguang.meng,
sj.huang
In-Reply-To: <20200521152253.GE209565@chromium.org>
On Thu, 2020-05-21 at 15:22 +0000, Tomasz Figa wrote:
> Hi Xia,
>
> On Fri, Apr 03, 2020 at 05:40:24PM +0800, Xia Jiang wrote:
> > Call pm_runtime_get_sync() before starting a frame and then
> > pm_runtime_put() after completing it. This can save power for the time
> > between processing two frames.
> >
> > Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
> > ---
> > .../media/platform/mtk-jpeg/mtk_jpeg_core.c | 27 +++++--------------
> > 1 file changed, 6 insertions(+), 21 deletions(-)
> >
>
> Thank you for the patch. Please see my comments inline.
>
> > diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > index a536fa95b3d6..dd5cadd101ef 100644
> > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > @@ -710,23 +710,6 @@ static struct vb2_v4l2_buffer *mtk_jpeg_buf_remove(struct mtk_jpeg_ctx *ctx,
> > return v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > }
> >
> > -static int mtk_jpeg_start_streaming(struct vb2_queue *q, unsigned int count)
> > -{
> > - struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
> > - struct vb2_v4l2_buffer *vb;
> > - int ret = 0;
> > -
> > - ret = pm_runtime_get_sync(ctx->jpeg->dev);
> > - if (ret < 0)
> > - goto err;
> > -
> > - return 0;
> > -err:
> > - while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
> > - v4l2_m2m_buf_done(vb, VB2_BUF_STATE_QUEUED);
> > - return ret;
> > -}
> > -
> > static void mtk_jpeg_stop_streaming(struct vb2_queue *q)
> > {
> > struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
> > @@ -751,8 +734,6 @@ static void mtk_jpeg_stop_streaming(struct vb2_queue *q)
> >
> > while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
> > v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
> > -
> > - pm_runtime_put_sync(ctx->jpeg->dev);
> > }
> >
> > static const struct vb2_ops mtk_jpeg_qops = {
> > @@ -761,7 +742,6 @@ static const struct vb2_ops mtk_jpeg_qops = {
> > .buf_queue = mtk_jpeg_buf_queue,
> > .wait_prepare = vb2_ops_wait_prepare,
> > .wait_finish = vb2_ops_wait_finish,
> > - .start_streaming = mtk_jpeg_start_streaming,
> > .stop_streaming = mtk_jpeg_stop_streaming,
> > };
> >
> > @@ -812,7 +792,7 @@ static void mtk_jpeg_device_run(void *priv)
> > struct mtk_jpeg_src_buf *jpeg_src_buf;
> > struct mtk_jpeg_bs bs;
> > struct mtk_jpeg_fb fb;
> > - int i;
> > + int i, ret;
> >
> > src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > @@ -832,6 +812,10 @@ static void mtk_jpeg_device_run(void *priv)
> > return;
> > }
> >
> > + ret = pm_runtime_get_sync(jpeg->dev);
> > + if (ret < 0)
> > + goto dec_end;
> > +
> > mtk_jpeg_set_dec_src(ctx, &src_buf->vb2_buf, &bs);
> > if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, &dst_buf->vb2_buf, &fb))
> > goto dec_end;
> > @@ -957,6 +941,7 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
> > v4l2_m2m_buf_done(src_buf, buf_state);
> > v4l2_m2m_buf_done(dst_buf, buf_state);
> > v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> > + pm_runtime_put_sync(ctx->jpeg->dev);
>
> The _sync variant explicitly waits until the asynchronous PM operation
> completes. This is usually undesired, because the CPU stays blocked for
> no good reason. In this context it is actually a bug, because this is an
> interrupt handler and it's not allowed to sleep. I wonder why this
> actually didn't crash in your testing. Please change to the regular
> pm_runtime_put().
Done.
>
> Best regards,
> Tomasz
^ permalink raw reply
* Re: [PATCH v8 04/14] media: platform: Change the fixed device node number to unfixed value
From: Xia Jiang @ 2020-06-05 6:02 UTC (permalink / raw)
To: Tomasz Figa
Cc: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Rick Chang, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Marek Szyprowski,
srv_heupstream, senozhatsky, mojahsu, drinkcat, maoguang.meng,
sj.huang
In-Reply-To: <20200521135937.GD209565@chromium.org>
On Thu, 2020-05-21 at 13:59 +0000, Tomasz Figa wrote:
> Hi Xia,
>
> On Fri, Apr 03, 2020 at 05:40:23PM +0800, Xia Jiang wrote:
> > Change device node number from 3 to -1 because that the driver will
> > also support jpeg encoder.
> >
>
> Thanks for the patch. The change is correct, but I think the commit
> message doesn't really explain the real reason for it. Perhaps something
> like
>
> "The driver can be instantiated multiple times, e.g. for a decoder and
> an encoder. Moreover, other drivers could coexist on the same system.
> This makes the static video node number assignment pointless, so switch
> to automatic assignment instead."
>
> WDYT?
Dear Tomasz,
Thanks for your advice.I have changed it in new v9 .
Best Regards,
Xia Jiang
>
> Best regards,
> Tomasz
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Sudeep Holla @ 2020-06-05 4:56 UTC (permalink / raw)
To: Jassi Brar
Cc: Viresh Kumar, Rob Herring, Arnd Bergmann, Frank Rowand,
Bjorn Andersson, Vincent Guittot, Sudeep Holla, linux-arm-kernel,
Devicetree List, Linux Kernel Mailing List
In-Reply-To: <CABb+yY27Ngb0C-onkU2qyt=uKgG4iVrcv8hGkC+anypQbTRA1w@mail.gmail.com>
On Thu, Jun 04, 2020 at 10:15:55AM -0500, Jassi Brar wrote:
> On Thu, Jun 4, 2020 at 4:20 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> > On Wed, Jun 03, 2020 at 01:32:42PM -0500, Jassi Brar wrote:
> > > On Wed, Jun 3, 2020 at 1:04 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > > >
> > > > On Fri, May 29, 2020 at 09:37:58AM +0530, Viresh Kumar wrote:
> > > > > On 28-05-20, 13:20, Rob Herring wrote:
> > > > > > Whether Linux
> > > > > > requires serializing mailbox accesses is a separate issue. On that side,
> > > > > > it seems silly to not allow driving the h/w in the most efficient way
> > > > > > possible.
> > > > >
> > > > > That's exactly what we are trying to say. The hardware allows us to
> > > > > write all 32 bits in parallel, without any hardware issues, why
> > > > > shouldn't we do that ? The delay (which Sudeep will find out, he is
> > > > > facing issues with hardware access because of lockdown right now)
> > > >
> > > > OK, I was able to access the setup today. I couldn't reach a point
> > > > where I can do measurements as the system just became unusable with
> > > > one physical channel instead of 2 virtual channels as in my patches.
> > > >
> > > > My test was simple. Switch to schedutil and read sensors periodically
> > > > via sysfs.
> > > >
> > > > arm-scmi firmware:scmi: message for 1 is not expected!
> > > >
> > > This sounds like you are not serialising requests on a shared channel.
> > > Can you please also share the patch?
> >
> > OK, I did try with a small patch initially and then realised we must hit
> > issue with mainline as is. Tried and the behaviour is exact same. All
> > I did is removed my patches and use bit[0] as the signal. It doesn't
> > matter as writes to the register are now serialised. Oh, the above
> > message comes when OS times out in advance while firmware continues to
> > process the old request and respond.
> >
> > The trace I sent gives much better view of what's going on.
> >
> BTW, you didn't even share 'good' vs 'bad' log for me to actually see
> if the api lacks.
>
> Let us look closely ...
>
> >> bash-1019 [005] 1149.452340: scmi_xfer_begin:
> transfer_id=1537 msg_id=7 protocol_id=19 seq=0 poll=1
> >> bash-1019 [005] 1149.452407: scmi_xfer_end:
> transfer_id=1537 msg_id=7 protocol_id=19 seq=0 status=0
> >
> This round trip took 67usecs. (log shows some at even 3usecs)
> That includes mailbox api overhead, memcpy and the time taken by
> remote to respond.
This is DVFS request which firmware acknowledges quickly and expected
to at most 100us.
> So the api is definitely capable of much faster transfers than you require.
>
I am not complaining about that. The delay is mostly due to the load on
the mailbox and parallelising helps is the focus here.
> >> bash-1526 [000] 1149.472553: scmi_xfer_begin: transfer_id=1538 msg_id=6 protocol_id=21 seq=0 poll=0
> >> <idle>-0 [001] 1149.472733: scmi_xfer_begin: transfer_id=1539 msg_id=7 protocol_id=19 seq=1 poll=1
> >
> Here another request is started before the first is finished.
Ah, the prints are when the client requested. It is not when the mailbox
started it. So this just indicates the beginning of the transfer from the
client. I must have mentioned that earlier. Some request timeout before
being picked up by mailbox if the previous request is not acknowledge
quickly. E.g. Say a sensor command started which may take upto 1ms,
almost 5-6 DVFS request after that will timeout.
> If you want this to work you have to serialise access to the single
> physical channel and/or run the remote firmware in asynchronous mode -
> that is, the firmware ack the bit as soon as it sees and starts
> working in the background, so that we return in ~3usec always, while
> the data returns whenever it is ready.
Yes it does that for few requests like DVFS while it uses synchronous
mode for few others. While ideally I agree everything in asynchronous
most is better, I don't know there may be reasons for such design. Also
the solution given is to use different bits as independent channels
which hardware allows. Anyways it's open source SCP project[1].
--
Regards,
Sudeep
[1] https://github.com/ARM-software/SCP-firmware
^ permalink raw reply
* Re: [PATCH 5/7] arm64: dts: qcom: pm8150x: add thermal alarms and thermal zones
From: Vinod Koul @ 2020-06-05 4:39 UTC (permalink / raw)
To: Dmitry Baryshkov, Amit Kucheria
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm,
devicetree, patches, linaro-kernel
In-Reply-To: <8df3fe11-867f-b6a3-fe29-5a8ab988e006@linaro.org>
Sorry missed ccing Amit, done now.
On 04-06-20, 18:03, Dmitry Baryshkov wrote:
> On 04/06/2020 13:47, Vinod Koul wrote:
> > On 04-06-20, 03:43, Dmitry Baryshkov wrote:
> > > pm8150_adc: adc@3100 {
> > > compatible = "qcom,spmi-adc5";
> > > reg = <0x3100>;
> > > @@ -38,8 +47,6 @@ pm8150_adc: adc@3100 {
> > > #io-channel-cells = <1>;
> > > interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
> > > - status = "disabled";
> > > -
> >
> > This should not be removed, rather than this please add enabled in you
> > board dts file
...
> > > +&thermal_zones {
> > > + pm8150_temp {
> > > + polling-delay-passive = <0>;
> > > + polling-delay = <0>;
> > > +
> > > + thermal-sensors = <&pm8150_temp>;
> > > +
> > > + trips {
> > > + trip0 {
> > > + temperature = <95000>;
> > > + hysteresis = <0>;
> > > + type = "passive";
> > > + };
> > > +
> > > + trip1 {
> > > + temperature = <115000>;
> > > + hysteresis = <0>;
> > > + type = "passive";
> > > + };
> > > +
> > > + trip2 {
> > > + temperature = <145000>;
> > > + hysteresis = <0>;
> > > + type = "passive";
> > > + };
> > > + };
> > > +
> > > + };
> >
> > Not sure about this, Amit..? Should this also not be in board dts?
> >
> > Similar comments on similar ones for rest of the patch as well..
>
> I'm not so sure. This part of the configuration seems generic to me. Unlike
> adc-tm config, which definitely goes to the board file.
I think the temperature values may be board specific, Amit can confirm
that. If that is the case then this belongs to board dts, otherwise here :)
> I can split this into a separate pm8150-temp.dtsi file. Does that sound
> better?
That might make it worse, we don't do splitting.
--
~Vinod
^ permalink raw reply
* [PATCH 2/2] ASoC: dt-bindings: add compatible string for MAX98360A
From: Tzung-Bi Shih @ 2020-06-05 3:49 UTC (permalink / raw)
To: broonie, robh+dt; +Cc: alsa-devel, devicetree, tzungbi
In-Reply-To: <20200605034931.107713-1-tzungbi@google.com>
Maxim MAX98360A audio amplifier is functionally identical to MAX98357A.
Adds compatible string "maxim,max98360a" for driver reuse.
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
---
.../devicetree/bindings/sound/max98357a.txt | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/max98357a.txt b/Documentation/devicetree/bindings/sound/max98357a.txt
index 4bce14ce806f..75db84d06240 100644
--- a/Documentation/devicetree/bindings/sound/max98357a.txt
+++ b/Documentation/devicetree/bindings/sound/max98357a.txt
@@ -1,9 +1,10 @@
-Maxim MAX98357A audio DAC
+Maxim MAX98357A/MAX98360A audio DAC
-This node models the Maxim MAX98357A DAC.
+This node models the Maxim MAX98357A/MAX98360A DAC.
Required properties:
-- compatible : "maxim,max98357a"
+- compatible : "maxim,max98357a" for MAX98357A.
+ "maxim,max98360a" for MAX98360A.
Optional properties:
- sdmode-gpios : GPIO specifier for the chip's SD_MODE pin.
@@ -20,3 +21,8 @@ max98357a {
compatible = "maxim,max98357a";
sdmode-gpios = <&qcom_pinmux 25 0>;
};
+
+max98360a {
+ compatible = "maxim,max98360a";
+ sdmode-gpios = <&qcom_pinmux 25 0>;
+};
--
2.27.0.278.ge193c7cf3a9-goog
^ permalink raw reply related
* [PATCH 1/2] ASoC: max98357a: add compatible string for MAX98360A
From: Tzung-Bi Shih @ 2020-06-05 3:49 UTC (permalink / raw)
To: broonie, robh+dt; +Cc: alsa-devel, devicetree, tzungbi
In-Reply-To: <20200605034931.107713-1-tzungbi@google.com>
Maxim MAX98360A audio amplifier is functionally identical to MAX98357A.
Adds compatible string "maxim,max98360a" for driver reuse.
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
---
sound/soc/codecs/max98357a.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/max98357a.c b/sound/soc/codecs/max98357a.c
index a8bd793a7867..4f431133d0bb 100644
--- a/sound/soc/codecs/max98357a.c
+++ b/sound/soc/codecs/max98357a.c
@@ -125,6 +125,7 @@ static int max98357a_platform_probe(struct platform_device *pdev)
#ifdef CONFIG_OF
static const struct of_device_id max98357a_device_id[] = {
{ .compatible = "maxim,max98357a" },
+ { .compatible = "maxim,max98360a" },
{}
};
MODULE_DEVICE_TABLE(of, max98357a_device_id);
--
2.27.0.278.ge193c7cf3a9-goog
^ permalink raw reply related
* [PATCH 0/2] ASoC: max98357a: support MAX98360A in OF
From: Tzung-Bi Shih @ 2020-06-05 3:49 UTC (permalink / raw)
To: broonie, robh+dt; +Cc: alsa-devel, devicetree, tzungbi
Commit 1a0f2433d738 ("ASoC: max98357a: Add ACPI HID MAX98360A") supports
MAX98360A in ACPI world. This series supports MAX98360A in OF world.
Tzung-Bi Shih (2):
ASoC: max98357a: add compatible string for MAX98360A
ASoC: dt-bindings: add compatible string for MAX98360A
.../devicetree/bindings/sound/max98357a.txt | 12 +++++++++---
sound/soc/codecs/max98357a.c | 1 +
2 files changed, 10 insertions(+), 3 deletions(-)
--
2.27.0.278.ge193c7cf3a9-goog
^ permalink raw reply
* Re: [V6, 2/2] media: i2c: dw9768: Add DW9768 VCM driver
From: Dongchun Zhu @ 2020-06-05 3:28 UTC (permalink / raw)
To: Sakari Ailus
Cc: Tomasz Figa, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Rob Herring, Mark Rutland,
Nicolas Boichat, Matthias Brugger, Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>,,
Sj Huang, Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男), dongchun.zhu
In-Reply-To: <20200604081032.GG16711@paasikivi.fi.intel.com>
Hi Sakari,
On Thu, 2020-06-04 at 11:10 +0300, Sakari Ailus wrote:
> On Thu, Jun 04, 2020 at 10:33:38AM +0800, Dongchun Zhu wrote:
> > Hi Tomasz,
> >
> > On Mon, 2020-06-01 at 20:47 +0200, Tomasz Figa wrote:
> > > On Wed, May 27, 2020 at 11:03 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > >
> > > > Hi Tomasz,
> > > >
> > > > On Mon, 2020-05-25 at 13:45 +0200, Tomasz Figa wrote:
> > > > > On Fri, May 22, 2020 at 11:27 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > >
> > > > > > Hi Tomasz,
> > > > > >
> > > > > > Thanks for the review. My replies are as below.
> > > > > >
> > > > > > On Thu, 2020-05-21 at 19:51 +0000, Tomasz Figa wrote:
> > > > > > > Hi Dongchun, Sakari,
> > > > > > >
> > > > > > > On Mon, May 18, 2020 at 09:27:31PM +0800, Dongchun Zhu wrote:
> > > > > [snip]
> > > > > > > > + pm_runtime_enable(dev);
> > > > > > > > + if (!pm_runtime_enabled(dev)) {
> > > > > > > > + ret = dw9768_runtime_resume(dev);
> > > > > > > > + if (ret < 0) {
> > > > > > > > + dev_err(dev, "failed to power on: %d\n", ret);
> > > > > > > > + goto entity_cleanup;
> > > > > > > > + }
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + ret = v4l2_async_register_subdev(&dw9768->sd);
> > > > > > > > + if (ret < 0)
> > > > > > > > + goto entity_cleanup;
> > > > > > > > +
> > > > > > > > + return 0;
> > > > > > > > +
> > > > > > > > +entity_cleanup:
> > > > > > >
> > > > > > > Need to power off if the code above powered on.
> > > > > > >
> > > > > >
> > > > > > Thanks for the reminder.
> > > > > > If there is something wrong with runtime PM, actuator is to be powered
> > > > > > on via dw9768_runtime_resume() API.
> > > > > > When actuator sub-device is powered on completely and async registered
> > > > > > successfully, we shall power off it afterwards.
> > > > > >
> > > > >
> > > > > The code above calls dw9768_runtime_resume() if
> > > > > !pm_runtime_enabled(dev), but the clean-up code below the
> > > > > entity_cleanup label doesn't have the corresponding
> > > > > dw9768_runtime_suspend() call.
> > > > >
> > > >
> > > > Did you mean the 'entity_cleanup' after v4l2_async_register_subdev()?
> > >
> > > Yes.
> > >
> > > > Actually I made some changes for OV02A V9, according to this comment.
> > > > Could you help review that change? Thanks.
> > >
> > > Sure, I will take a look.
> > >
> >
> > Thanks.
> > Sorry, I just wanna make sure the change is okay for next release.
> > May we use the check like OV02A V9 did?
> > ret = v4l2_async_register_subdev(&dw9768->sd);
> > if (ret < 0) {
> > if (!pm_runtime_enabled(dev))
> > dw9768_runtime_suspend(dev);
>
> Please do this part where you're jumping to, if possible.
>
Fine.
Fixed in next release.
> > goto entity_cleanup;
> > }
> >
>
^ permalink raw reply
* Re: [GIT PULL] Devicetree updates for v5.8
From: pr-tracker-bot @ 2020-06-05 3:30 UTC (permalink / raw)
To: Rob Herring; +Cc: Linus Torvalds, linux-kernel, devicetree, Frank Rowand
In-Reply-To: <20200604220459.GA4123489@bogus>
The pull request you sent on Thu, 4 Jun 2020 16:04:59 -0600:
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git tags/devicetree-for-5.8
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/571d54ed91c0fae174d933683c0c2e11c84843d9
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [V9, 2/2] media: i2c: ov02a10: Add OV02A10 image sensor driver
From: Dongchun Zhu @ 2020-06-05 3:19 UTC (permalink / raw)
To: Sakari Ailus
Cc: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, drinkcat, tfiga, matthias.bgg, bingbu.cao,
srv_heupstream, linux-mediatek, linux-arm-kernel, sj.huang,
linux-media, devicetree, louis.kuo, shengnan.wang
In-Reply-To: <20200604092616.GJ16711@paasikivi.fi.intel.com>
Hi Sakari,
On Thu, 2020-06-04 at 12:26 +0300, Sakari Ailus wrote:
> Hi Dongchun,
>
> On Thu, Jun 04, 2020 at 10:14:05AM +0800, Dongchun Zhu wrote:
> > Hi Tomasz, Sakari, and sirs,
> >
> > Could anyone help to review this patch?
> >
> > On Sat, 2020-05-23 at 16:41 +0800, Dongchun Zhu wrote:
> > > Add a V4L2 sub-device driver for OV02A10 image sensor.
> > >
> > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > ---
> > > MAINTAINERS | 1 +
> > > drivers/media/i2c/Kconfig | 13 +
> > > drivers/media/i2c/Makefile | 1 +
> > > drivers/media/i2c/ov02a10.c | 1025 +++++++++++++++++++++++++++++++++++++++++++
> > > 4 files changed, 1040 insertions(+)
> > > create mode 100644 drivers/media/i2c/ov02a10.c
> > >
> >
> > [snip]
> >
> > > +static int ov02a10_probe(struct i2c_client *client)
> > > +{
> > > + struct device *dev = &client->dev;
> > > + struct ov02a10 *ov02a10;
> > > + unsigned int rotation;
> > > + unsigned int clock_lane_tx_speed;
> > > + unsigned int i;
> > > + int ret;
> > > +
> > > + ov02a10 = devm_kzalloc(dev, sizeof(*ov02a10), GFP_KERNEL);
> > > + if (!ov02a10)
> > > + return -ENOMEM;
> > > +
> > > + ret = ov02a10_check_hwcfg(dev, ov02a10);
> > > + if (ret) {
> > > + dev_err(dev, "failed to check HW configuration: %d", ret);
> > > + return ret;
> > > + }
> > > +
> > > + v4l2_i2c_subdev_init(&ov02a10->subdev, client, &ov02a10_subdev_ops);
> > > + ov02a10->mipi_clock_tx_speed = OV02A10_MIPI_TX_SPEED_DEFAULT;
> > > + ov02a10->fmt.code = MEDIA_BUS_FMT_SBGGR10_1X10;
> > > +
> > > + /* Optional indication of physical rotation of sensor */
> > > + ret = fwnode_property_read_u32(dev_fwnode(dev), "rotation", &rotation);
> > > + if (!ret && rotation == 180) {
> > > + ov02a10->upside_down = true;
> > > + ov02a10->fmt.code = MEDIA_BUS_FMT_SRGGB10_1X10;
> > > + }
> > > +
> > > + /* Optional indication of mipi TX speed */
> > > + ret = fwnode_property_read_u32(dev_fwnode(dev), "ovti,mipi-tx-speed",
> > > + &clock_lane_tx_speed);
> > > +
> > > + if (!ret)
> > > + ov02a10->mipi_clock_tx_speed = clock_lane_tx_speed;
> > > +
> > > + /* Get system clock (eclk) */
> > > + ov02a10->eclk = devm_clk_get(dev, "eclk");
> > > + if (IS_ERR(ov02a10->eclk)) {
> > > + ret = PTR_ERR(ov02a10->eclk);
> > > + dev_err(dev, "failed to get eclk %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency",
> > > + &ov02a10->eclk_freq);
> > > + if (ret) {
> > > + dev_err(dev, "failed to get eclk frequency\n");
> > > + return ret;
> > > + }
> > > +
> > > + ret = clk_set_rate(ov02a10->eclk, ov02a10->eclk_freq);
> > > + if (ret) {
> > > + dev_err(dev, "failed to set eclk frequency (24MHz)\n");
> > > + return ret;
> > > + }
> > > +
> > > + if (clk_get_rate(ov02a10->eclk) != OV02A10_ECLK_FREQ) {
> > > + dev_warn(dev, "wrong eclk frequency %d Hz, expected: %d Hz\n",
> > > + ov02a10->eclk_freq, OV02A10_ECLK_FREQ);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + ov02a10->pd_gpio = devm_gpiod_get(dev, "powerdown", GPIOD_OUT_HIGH);
> > > + if (IS_ERR(ov02a10->pd_gpio)) {
> > > + ret = PTR_ERR(ov02a10->pd_gpio);
> > > + dev_err(dev, "failed to get powerdown-gpios %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + ov02a10->n_rst_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> > > + if (IS_ERR(ov02a10->n_rst_gpio)) {
> > > + ret = PTR_ERR(ov02a10->n_rst_gpio);
> > > + dev_err(dev, "failed to get reset-gpios %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(ov02a10_supply_names); i++)
> > > + ov02a10->supplies[i].supply = ov02a10_supply_names[i];
> > > +
> > > + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ov02a10_supply_names),
> > > + ov02a10->supplies);
> > > + if (ret) {
> > > + dev_err(dev, "failed to get regulators\n");
> > > + return ret;
> > > + }
> > > +
> > > + mutex_init(&ov02a10->mutex);
> > > + ov02a10->cur_mode = &supported_modes[0];
> > > + ret = ov02a10_initialize_controls(ov02a10);
> > > + if (ret) {
> > > + dev_err(dev, "failed to initialize controls\n");
> > > + goto err_destroy_mutex;
> > > + }
> > > +
> > > + ov02a10->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> > > + ov02a10->subdev.entity.ops = &ov02a10_subdev_entity_ops;
> > > + ov02a10->subdev.entity.function = MEDIA_ENT_F_CAM_SENSOR;
> > > + ov02a10->pad.flags = MEDIA_PAD_FL_SOURCE;
> > > + ret = media_entity_pads_init(&ov02a10->subdev.entity, 1, &ov02a10->pad);
> > > + if (ret < 0) {
> > > + dev_err(dev, "failed to init entity pads: %d", ret);
> > > + goto err_free_handler;
> > > + }
> > > +
> > > + pm_runtime_enable(dev);
> > > + if (!pm_runtime_enabled(dev)) {
> > > + ret = ov02a10_power_on(dev);
> > > + if (ret < 0) {
> > > + dev_err(dev, "failed to power on: %d\n", ret);
> > > + goto err_free_handler;
This is actually wrong, which should be replaced of "err_clean_entity".
> > > + }
> > > + }
> > > +
> > > + ret = v4l2_async_register_subdev(&ov02a10->subdev);
> > > + if (ret) {
> > > + dev_err(dev, "failed to register V4L2 subdev: %d", ret);
> > > + if (!pm_runtime_enabled(dev))
> > > + ov02a10_power_off(dev);
>
> This should be moved to error handling section below.
>
Fine.
It would be abstracted as "err_async_register" in next release.
Something like:
err_async_register:
if (!pm_runtime_enabled(dev))
ov02a10_power_off(dev);
err_clean_entity:
media_entity_cleanup(&ov02a10->subdev.entity);
...
> > > + goto err_clean_entity;
> > > + }
> >
> > Tomasz, Sakari, is this ok?
> > or coding like this:
> >
> > ret = v4l2_async_register_subdev(&ov02a10->subdev);
> > if (!pm_runtime_enabled(dev))
> > ov02a10_power_off(dev);
> > if (ret) {
> > dev_err(dev, "failed to register V4L2 subdev: %d", ret);
> > goto err_clean_entity;
> > }
> >
> > What's your opinions about the change?
>
> This turns power off if runtime PM is disabled. I'd keep it as-is, as it'd
> require re-implementing what runtime PM is used for now --- and that's not
> a sensor driver's job.
>
> >
> > > +
> > > + return 0;
> > > +
> > > +err_clean_entity:
> > > + media_entity_cleanup(&ov02a10->subdev.entity);
> > > +err_free_handler:
> > > + v4l2_ctrl_handler_free(ov02a10->subdev.ctrl_handler);
> > > +err_destroy_mutex:
> > > + mutex_destroy(&ov02a10->mutex);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static int ov02a10_remove(struct i2c_client *client)
> > > +{
> > > + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> > > + struct ov02a10 *ov02a10 = to_ov02a10(sd);
> > > +
> > > + v4l2_async_unregister_subdev(sd);
> > > + media_entity_cleanup(&sd->entity);
> > > + v4l2_ctrl_handler_free(sd->ctrl_handler);
> > > + pm_runtime_disable(&client->dev);
> > > + if (!pm_runtime_status_suspended(&client->dev))
> > > + ov02a10_power_off(&client->dev);
> > > + pm_runtime_set_suspended(&client->dev);
> > > + mutex_destroy(&ov02a10->mutex);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static const struct of_device_id ov02a10_of_match[] = {
> > > + { .compatible = "ovti,ov02a10" },
> > > + {}
> > > +};
> > > +MODULE_DEVICE_TABLE(of, ov02a10_of_match);
> > > +
> > > +static struct i2c_driver ov02a10_i2c_driver = {
> > > + .driver = {
> > > + .name = "ov02a10",
> > > + .pm = &ov02a10_pm_ops,
> > > + .of_match_table = ov02a10_of_match,
> > > + },
> > > + .probe_new = &ov02a10_probe,
> > > + .remove = &ov02a10_remove,
> > > +};
> > > +
> > > +module_i2c_driver(ov02a10_i2c_driver);
> > > +
> > > +MODULE_AUTHOR("Dongchun Zhu <dongchun.zhu@mediatek.com>");
> > > +MODULE_DESCRIPTION("OmniVision OV02A10 sensor driver");
> > > +MODULE_LICENSE("GPL v2");
> > > +
> >
>
^ permalink raw reply
* RE: [PATCH v8 00/13] add ecspi ERR009165 for i.mx6/7 soc family
From: Robin Gong @ 2020-06-05 2:45 UTC (permalink / raw)
To: Matthias Schiffer
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org, dl-linux-imx, kernel@pengutronix.de,
linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
broonie@kernel.org, robh+dt@kernel.org, catalin.marinas@arm.com,
vkoul@kernel.org, will.deacon@arm.com, shawnguo@kernel.org,
festevam@gmail.com, s.hauer@pengutronix.de,
martin.fuzzey@flowbird.group, u.kleine-koenig@pengutronix.de,
dan.j.williams@intel.com, Markus Niebel
In-Reply-To: <7cb6cf02fc7cf860d1da7ba889887e79623e71a9.camel@ew.tq-group.com>
[-- Attachment #1: Type: text/plain, Size: 4271 bytes --]
On 2020/06/03 Matthias Schiffer <matthias.schiffer@ew.tq-group.com> wrote:
> On Wed, 2020-06-03 at 09:50 +0000, Robin Gong wrote:
> > On 2020/06/03 Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> > wrote:
> > > On Thu, 2020-05-21 at 04:34 +0800, Robin Gong wrote:
> > > > There is ecspi ERR009165 on i.mx6/7 soc family, which cause FIFO
> > > > transfer to be send twice in DMA mode. Please get more information
> > > > from:
> > > >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> > > > .
> > > >
> > >
> > >
> nxp.com%2Fdocs%2Fen%2Ferrata%2FIMX6DQCE.pdf&data=02%7C01%7C
> > > yibin.g
> > > >
> > >
> > >
> ong%40nxp.com%7C4621358b9be04a79d2d508d80798835b%7C686ea1d3bc2b
> > > 4c6fa92
> > > >
> > >
> > >
> cd99c5c301635%7C0%7C1%7C637267698912634476&sdata=hR66H1hP%
> > > 2Fqb6OXe
> > > > w9wpXizY8DiNfZZ1KLwu3Kty87jc%3D&reserved=0. The workaround
> is
> > > > adding new sdma ram script which works in XCH mode as PIO inside
> > > > sdma instead of SMC mode, meanwhile, 'TX_THRESHOLD' should be 0.
> > > > The issue
> > >
> > > should be exist on all legacy i.mx6/7 soc family before i.mx6ul.
> > > > NXP fix this design issue from i.mx6ul, so newer chips including
> > > > i.mx6ul/ 6ull/6sll do not need this workaroud anymore. All other
> > > > i.mx6/7/8 chips still need this workaroud. This patch set add new
> > > > 'fsl,imx6ul-ecspi'
> > > > for ecspi driver and 'ecspi_fixed' in sdma driver to choose if
> > > > need errata or not.
> > > > The first two reverted patches should be the same issue, though,
> > > > it seems 'fixed' by changing to other shp script. Hope Sean or
> > > > Sascha could have the chance to test this patch set if could fix
> > > > their issues.
> > > > Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1 not
> > > > work on i.mx8mm because the event id is zero.
> > > >
> > > > PS:
> > > > Please get sdma firmware from below linux-firmware and copy it
> > > > to your local rootfs /lib/firmware/imx/sdma.
> > >
> > >
> > > Hello Robin,
> > >
> > > we have tried out this series, and there seems to be an issue with
> > > the
> > > PIO fallback. We are testing on an i.MX6Q board, and our kernel is
> > > a
> > > mostly-unmodified 5.4, on which we backported all SDMA patches from
> > > next-20200602 (imx-sdma.c is identical to next-20200602 version),
> > > and
> > > then applied this whole series.
> > >
> > > We build the SDMA driver as a kernel module, which is loaded by
> > > udev,
> > > so the root filesystem is ready and the SDMA firmware can be
> > > loaded.
> > > The behaviour we're seeing is the following:
> > >
> > > 1. As long as the SDMA driver is not loaded, initializing spi_imx
> > > will
> > > be deferred
> > > 2. imx_sdma is loaded. The SDMA firmware is not yet loaded at this
> > > point
> > > 3. spi_imx is initialized and an SPI-NOR flash is probed. To load
> > > the
> > > BFPT, the driver will attempt to use DMA; this will fail with
> > > EINVAL as
> > > long as the SDMA firmware is not ready, so the fallback to PIO
> > > happens
> > > (4. SDMA firmware is ready, subsequent SPI transfers use DMA)
> > >
> > > The problem happens in step 3: Whenever the driver falls back to
> > > PIO,
> > > the received data is corrupt. The behaviour is specific to the
> > > fallback: When I disable DMA completely via spi_imx.use_dma, or
> > > when
> > > the timing is lucky and the SDMA firmware gets loaded before the
> > > flash
> > > is probed, no corruption can be observed.
> >
> > Thanks Matthias, would you like post log?
> >
>
> I have attached the following log files:
> - pio.log: DMA disabled via module parameter
> - dma.log: "lucky" timing, SDMA firmware loaded before SPI-NOR probe
> - fallback.log: DMA->PIO fallback
>
> The logs include some additional log messages:
> - Return value of spi_imx_dma_transfer() before PIO fallback
> - SPI-NOR SFPT dump
>
> It can be seen that the BFPT data is identical in pio.log and dma.log,
> and differs almost completely in fallback.log. The corrupted data seems
> to be random, or uninitialized memory; it differs with every boot.
Would you please have a try with the attached patch? Thanks.
[-- Attachment #2: 0006-spi-imx-add-dma_sync_sg_for_device-after-fallback-fr.patch --]
[-- Type: application/octet-stream, Size: 1526 bytes --]
From 08becec165b15663fafea52e3dc6ed5482ad3652 Mon Sep 17 00:00:00 2001
From: Robin Gong <yibin.gong@nxp.com>
Date: Fri, 5 Jun 2020 08:57:19 +0800
Subject: [PATCH v9 06/14] spi: imx: add dma_sync_sg_for_device after fallback
from dma
In case dma transfer failed and fallback to pio, tx_buf/rx_buf need to be
taken care cache since they have already been mapped by dma_map_sg() in
spi.c.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/spi/spi-imx.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index b7a85e3..c51cd3a 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -1456,6 +1456,13 @@ static int spi_imx_pio_transfer(struct spi_device *spi,
return -ETIMEDOUT;
}
+ if (transfer->rx_sg.sgl) {
+ struct device *rx_dev = spi->controller->dma_rx->device->dev;
+
+ dma_sync_sg_for_device(rx_dev, transfer->rx_sg.sgl,
+ transfer->rx_sg.nents, DMA_TO_DEVICE);
+ }
+
return transfer->len;
}
@@ -1521,10 +1528,15 @@ static int spi_imx_transfer(struct spi_device *spi,
* firmware may not be updated as ERR009165 required.
*/
if (spi_imx->usedma) {
+ struct device *tx_dev = spi->controller->dma_tx->device->dev;
+
ret = spi_imx_dma_transfer(spi_imx, transfer);
if (ret != -EINVAL)
return ret;
+ dma_sync_sg_for_device(tx_dev, transfer->tx_sg.sgl,
+ transfer->tx_sg.nents, DMA_FROM_DEVICE);
+
spi_imx->devtype_data->disable_dma(spi_imx);
spi_imx->usedma = false;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 2/6] PCI: uniphier: Add misc interrupt handler to invoke PME and AER
From: Kunihiko Hayashi @ 2020-06-05 2:36 UTC (permalink / raw)
To: Marc Zyngier
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada, linux-pci, devicetree,
linux-arm-kernel, linux-kernel, Masami Hiramatsu, Jassi Brar
In-Reply-To: <9cbfdacba32c5e351fd9e14444768666@kernel.org>
Hi Marc,
On 2020/06/04 19:11, Marc Zyngier wrote:
> On 2020-06-04 10:43, Kunihiko Hayashi wrote:
>
> [...]
>
>>>> -static void uniphier_pcie_irq_handler(struct irq_desc *desc)
>>>> +static void uniphier_pcie_misc_isr(struct pcie_port *pp)
>>>> {
>>>> - struct pcie_port *pp = irq_desc_get_handler_data(desc);
>>>> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>>>> struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
>>>> - struct irq_chip *chip = irq_desc_get_chip(desc);
>>>> - unsigned long reg;
>>>> - u32 val, bit, virq;
>>>> + u32 val, virq;
>>>>
>>>> - /* INT for debug */
>>>> val = readl(priv->base + PCL_RCV_INT);
>>>>
>>>> if (val & PCL_CFG_BW_MGT_STATUS)
>>>> dev_dbg(pci->dev, "Link Bandwidth Management Event\n");
>>>> +
>>>> if (val & PCL_CFG_LINK_AUTO_BW_STATUS)
>>>> dev_dbg(pci->dev, "Link Autonomous Bandwidth Event\n");
>>>> - if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS)
>>>> - dev_dbg(pci->dev, "Root Error\n");
>>>> - if (val & PCL_CFG_PME_MSI_STATUS)
>>>> - dev_dbg(pci->dev, "PME Interrupt\n");
>>>> +
>>>> + if (pci_msi_enabled()) {
>>>
>>> This checks whether the kernel supports MSIs. Not that they are
>>> enabled in your controller. Is that really what you want to do?
>>
>> The below two status bits are valid when the interrupt for MSI is asserted.
>> That is, pci_msi_enabled() is wrong.
>>
>> I'll modify the function to check the two bits only if this function is
>> called from MSI handler.
>>
>>>
>>>> + if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS) {
>>>> + dev_dbg(pci->dev, "Root Error Status\n");
>>>> + virq = irq_linear_revmap(pp->irq_domain, 0);
>>>> + generic_handle_irq(virq);
>>>> + }
>>>> +
>>>> + if (val & PCL_CFG_PME_MSI_STATUS) {
>>>> + dev_dbg(pci->dev, "PME Interrupt\n");
>>>> + virq = irq_linear_revmap(pp->irq_domain, 0);
>>>> + generic_handle_irq(virq);
>>>> + }
>>>
>>> These two cases do the exact same thing, calling the same interrupt.
>>> What is the point of dealing with them independently?
>>
>> Both PME and AER are asserted from MSI-0, and each handler checks its own
>> status bit in the PCIe register (aer_irq() in pcie/aer.c and pcie_pme_irq()
>> in pcie/pme.c).
>> So I think this handler calls generic_handle_irq() for the same MSI-0.
>
> So what is wrong with
>
> if (val & (PCL_CFG_AER_RC_ERR_MSI_STATUS |
> PCL_CFG_PME_MSI_STATUS)) {
> // handle interrupt
> }
>
> ?
No problem.
I'll rewrite it in the same way as yours in handling interrupts.
> If you have two handlers for the same interrupt, this is a shared
> interrupt and each handler will be called in turn.
Yes, MSI-0 is shared with PME and AER, and it will be like that.
Thank you,
---
Best Regards
Kunihiko Hayashi
^ permalink raw reply
* Re: [PATCH v12 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema
From: Xin Ji @ 2020-06-05 2:36 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Neil Armstrong, Jonas Karlman, Jernej Skrabec,
Hsin-Yi Wang, David Airlie, Daniel Vetter, Dan Carpenter,
Nicolas Boichat, linux-kernel, dri-devel, Pi-Hsun Shih, Sheng Pan
In-Reply-To: <20200604222402.GA4153046@bogus>
On Thu, Jun 04, 2020 at 04:24:02PM -0600, Rob Herring wrote:
> On Thu, 04 Jun 2020 15:56:36 +0800, Xin Ji wrote:
> > anx7625: MIPI to DP transmitter DT schema
> >
> > Signed-off-by: Xin Ji <xji@analogixsemi.com>
> > ---
> > .../bindings/display/bridge/analogix,anx7625.yaml | 95 ++++++++++++++++++++++
> > 1 file changed, 95 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> >
>
>
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
>
> If a tag was not added on purpose, please state why and what changed.
Hi Rob Herring, thanks for your comment. I'll add tags in the next
versions.
Thanks,
Xin
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: John Donnelly @ 2020-06-05 2:26 UTC (permalink / raw)
To: Nicolas Saenz Julienne, Bhupesh Sharma
Cc: chenzhou, Simon Horman, Devicetree List, Arnd Bergmann,
Baoquan He, Linux Doc Mailing List, Catalin Marinas, guohanjun,
kexec mailing list, Linux Kernel Mailing List, Will Deacon,
Rob Herring, James Morse, Prabhakar Kushwaha, Thomas Gleixner,
Prabhakar Kushwaha, RuiRui Yang, Ingo Molnar, linux-arm-kernel
In-Reply-To: <751bbe2512628ff38002db33ce02af051d080cd2.camel@suse.de>
On 6/4/20 12:01 PM, Nicolas Saenz Julienne wrote:
> On Thu, 2020-06-04 at 01:17 +0530, Bhupesh Sharma wrote:
>> Hi All,
>>
>> On Wed, Jun 3, 2020 at 9:03 PM John Donnelly <john.p.donnelly@oracle.com>
>> wrote:
>>>
>>>> On Jun 3, 2020, at 8:20 AM, chenzhou <chenzhou10@huawei.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>> On 2020/6/3 19:47, Prabhakar Kushwaha wrote:
>>>>> Hi Chen,
>>>>>
>>>>> On Tue, Jun 2, 2020 at 8:12 PM John Donnelly <john.p.donnelly@oracle.com
>>>>>> wrote:
>>>>>>
>>>>>>> On Jun 2, 2020, at 12:38 AM, Prabhakar Kushwaha <
>>>>>>> prabhakar.pkin@gmail.com> wrote:
>>>>>>>
>>>>>>> On Tue, Jun 2, 2020 at 3:29 AM John Donnelly <
>>>>>>> john.p.donnelly@oracle.com> wrote:
>>>>>>>> Hi . See below !
>>>>>>>>
>>>>>>>>> On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma <bhsharma@redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi John,
>>>>>>>>>
>>>>>>>>> On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <
>>>>>>>>> John.P.donnelly@oracle.com> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
>>>>>>>>>>> Hi Chen,
>>>>>>>>>>>
>>>>>>>>>>> On Thu, May 21, 2020 at 3:05 PM Chen Zhou <
>>>>>>>>>>> chenzhou10@huawei.com> wrote:
>>>>>>>>>>>> This patch series enable reserving crashkernel above 4G in
>>>>>>>>>>>> arm64.
>>>>>>>>>>>>
>>>>>>>>>>>> There are following issues in arm64 kdump:
>>>>>>>>>>>> 1. We use crashkernel=X to reserve crashkernel below 4G,
>>>>>>>>>>>> which will fail
>>>>>>>>>>>> when there is no enough low memory.
>>>>>>>>>>>> 2. Currently, crashkernel=Y@X can be used to reserve
>>>>>>>>>>>> crashkernel above 4G,
>>>>>>>>>>>> in this case, if swiotlb or DMA buffers are required,
>>>>>>>>>>>> crash dump kernel
>>>>>>>>>>>> will boot failure because there is no low memory available
>>>>>>>>>>>> for allocation.
>>>>>>>>>>>>
>>>>>>>>>>> We are getting "warn_alloc" [1] warning during boot of kdump
>>>>>>>>>>> kernel
>>>>>>>>>>> with bootargs as [2] of primary kernel.
>>>>>>>>>>> This error observed on ThunderX2 ARM64 platform.
>>>>>>>>>>>
>>>>>>>>>>> It is observed with latest upstream tag (v5.7-rc3) with this
>>>>>>>>>>> patch set
>>>>>>>>>>> and
>>>>>>>>>>>
> https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
>>>>>>>>>>> Also **without** this patch-set
>>>>>>>>>>> "
>>>>>>>>>>>
> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$
>>>>>>>>>>> "
>>>>>>>>>>>
>>>>>>>>>>> This issue comes whenever crashkernel memory is reserved
>>>>>>>>>>> after 0xc000_0000.
>>>>>>>>>>> More details discussed earlier in
>>>>>>>>>>>
> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$
> without
>>>>>>>>>>> any
>>>>>>>>>>> solution
>>>>>>>>>>>
>>>>>>>>>>> This patch-set is expected to solve similar kind of issue.
>>>>>>>>>>> i.e. low memory is only targeted for DMA, swiotlb; So above
>>>>>>>>>>> mentioned
>>>>>>>>>>> observation should be considered/fixed. .
>>>>>>>>>>>
>>>>>>>>>>> --pk
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>> [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
>>>>>>>>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>>>>>>>>>> [ 30.367696] NET: Registered protocol family 16
>>>>>>>>>>> [ 30.369973] swapper/0: page allocation failure: order:6,
>>>>>>>>>>> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
>>>>>>>>>>> [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
>>>>>>>>>>> 5.7.0-rc3+ #121
>>>>>>>>>>> [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
>>>>>>>>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>>>>>>>>>> [ 30.369984] Call trace:
>>>>>>>>>>> [ 30.369989] dump_backtrace+0x0/0x1f8
>>>>>>>>>>> [ 30.369991] show_stack+0x20/0x30
>>>>>>>>>>> [ 30.369997] dump_stack+0xc0/0x10c
>>>>>>>>>>> [ 30.370001] warn_alloc+0x10c/0x178
>>>>>>>>>>> [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0
>>>>>>>>>>> xb50
>>>>>>>>>>> [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
>>>>>>>>>>> [ 30.370008] alloc_page_interleave+0x24/0x98
>>>>>>>>>>> [ 30.370011] alloc_pages_current+0xe4/0x108
>>>>>>>>>>> [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
>>>>>>>>>>> [ 30.370020] do_one_initcall+0x54/0x228
>>>>>>>>>>> [ 30.370027] kernel_init_freeable+0x228/0x2cc
>>>>>>>>>>> [ 30.370031] kernel_init+0x1c/0x110
>>>>>>>>>>> [ 30.370034] ret_from_fork+0x10/0x18
>>>>>>>>>>> [ 30.370036] Mem-Info:
>>>>>>>>>>> [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
>>>>>>>>>>> [ 30.370064] active_file:0 inactive_file:0
>>>>>>>>>>> isolated_file:0
>>>>>>>>>>> [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
>>>>>>>>>>> [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
>>>>>>>>>>> [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
>>>>>>>>>>> [ 30.370064] free:1537719 free_pcp:219 free_cma:0
>>>>>>>>>>> [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
>>>>>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB
>>>>>>>>>>> isolated(anon):0kB
>>>>>>>>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB
>>>>>>>>>>> shmem:0kB
>>>>>>>>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB
>>>>>>>>>>> writeback_tmp:0kB
>>>>>>>>>>> unstable:0kB all_unreclaimable? no
>>>>>>>>>>> [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
>>>>>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB
>>>>>>>>>>> isolated(anon):0kB
>>>>>>>>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB
>>>>>>>>>>> shmem:0kB
>>>>>>>>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB
>>>>>>>>>>> writeback_tmp:0kB
>>>>>>>>>>> unstable:0kB all_unreclaimable? no
>>>>>>>>>>> [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
>>>>>>>>>>> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>>>>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB
>>>>>>>>>>> writepending:0kB
>>>>>>>>>>> present:128kB managed:0kB mlocked:0kB kernel_stack:0kB
>>>>>>>>>>> pagetables:0kB
>>>>>>>>>>> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>>>>>>>>>>> [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
>>>>>>>>>>> [ 30.370090] Node 0 DMA32 free:256000kB min:408kB
>>>>>>>>>>> low:664kB
>>>>>>>>>>> high:920kB reserved_highatomic:0KB active_anon:0kB
>>>>>>>>>>> inactive_anon:0kB
>>>>>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB
>>>>>>>>>>> writepending:0kB
>>>>>>>>>>> present:269700kB managed:256000kB mlocked:0kB
>>>>>>>>>>> kernel_stack:0kB
>>>>>>>>>>> pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
>>>>>>>>>>> free_cma:0kB
>>>>>>>>>>> [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
>>>>>>>>>>> [ 30.370100] Node 0 Normal free:5894876kB min:9552kB
>>>>>>>>>>> low:15504kB
>>>>>>>>>>> high:21456kB reserved_highatomic:0KB active_anon:0kB
>>>>>>>>>>> inactive_anon:0kB
>>>>>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB
>>>>>>>>>>> writepending:0kB
>>>>>>>>>>> present:8388608kB managed:5953112kB mlocked:0kB
>>>>>>>>>>> kernel_stack:21672kB
>>>>>>>>>>> pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB
>>>>>>>>>>> free_cma:0kB
>>>>>>>>>>> [ 30.370104] lowmem_reserve[]: 0 0 0 0
>>>>>>>>>>> [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB
>>>>>>>>>>> 0*128kB
>>>>>>>>>>> 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
>>>>>>>>>>> [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB
>>>>>>>>>>> 0*64kB 0*128kB
>>>>>>>>>>> 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) =
>>>>>>>>>>> 256000kB
>>>>>>>>>>> [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB
>>>>>>>>>>> (UE) 3*32kB
>>>>>>>>>>> (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME)
>>>>>>>>>>> 3*1024kB (ME)
>>>>>>>>>>> 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
>>>>>>>>>>> [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
>>>>>>>>>>> hugepages_surp=0 hugepages_size=1048576kB
>>>>>>>>>>> [ 30.370130] 0 total pagecache pages
>>>>>>>>>>> [ 30.370132] 0 pages in swap cache
>>>>>>>>>>> [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
>>>>>>>>>>> [ 30.370135] Free swap = 0kB
>>>>>>>>>>> [ 30.370136] Total swap = 0kB
>>>>>>>>>>> [ 30.370137] 2164609 pages RAM
>>>>>>>>>>> [ 30.370139] 0 pages HighMem/MovableOnly
>>>>>>>>>>> [ 30.370140] 612331 pages reserved
>>>>>>>>>>> [ 30.370141] 0 pages hwpoisoned
>>>>>>>>>>> [ 30.370143] DMA: failed to allocate 256 KiB pool for
>>>>>>>>>>> atomic
>>>>>>>>>>> coherent allocation
>>>>>>>>>> During my testing I saw the same error and Chen's solution
>>>>>>>>>> corrected it .
>>>>>>>>> Which combination you are using on your side? I am using
>>>>>>>>> Prabhakar's
>>>>>>>>> suggested environment and can reproduce the issue
>>>>>>>>> with or without Chen's crashkernel support above 4G patchset.
>>>>>>>>>
>>>>>>>>> I am also using a ThunderX2 platform with latest makedumpfile
>>>>>>>>> code and
>>>>>>>>> kexec-tools (with the suggested patch
>>>>>>>>> <
>>>>>>>>>
> https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!J6lUig58-Gw6TKZnEEYzEeSU36T-1SqlB1kImU00xtX_lss5Tx-JbUmLE9TJC3foXBLg$
>>>>>>>>>> ).
>>>>>>>>> Thanks,
>>>>>>>>> Bhupesh
>>>>>>>> I did this activity 5 months ago and I have moved on to other
>>>>>>>> activities. My DMA failures were related to PCI devices that could
>>>>>>>> not be enumerated because low-DMA space was not available when
>>>>>>>> crashkernel was moved above 4G; I don’t recall the exact platform.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> For this failure ,
>>>>>>>>
>>>>>>>>>>> DMA: failed to allocate 256 KiB pool for atomic
>>>>>>>>>>> coherent allocation
>>>>>>>> Is due to :
>>>>>>>>
>>>>>>>>
>>>>>>>> 3618082c
>>>>>>>> ("arm64 use both ZONE_DMA and ZONE_DMA32")
>>>>>>>>
>>>>>>>> With the introduction of ZONE_DMA to support the Raspberry DMA
>>>>>>>> region below 1G, the crashkernel is placed in the upper 4G
>>>>>>>> ZONE_DMA_32 region. Since the crashkernel does not have access
>>>>>>>> to the ZONE_DMA region, it prints out call trace during bootup.
>>>>>>>>
>>>>>>>> It is due to having this CONFIG item ON :
>>>>>>>>
>>>>>>>>
>>>>>>>> CONFIG_ZONE_DMA=y
>>>>>>>>
>>>>>>>> Turning off ZONE_DMA fixes a issue and Raspberry PI 4 will
>>>>>>>> use the device tree to specify memory below 1G.
>>>>>>>>
>>>>>>>>
>>>>>>> Disabling ZONE_DMA is temporary solution. We may need proper
>>>>>>> solution
>>>>>> Perhaps the Raspberry platform configuration dependencies need
>>>>>> separated from “server class” Arm equipment ? Or auto-configured on
>>>>>> boot ? Consult an expert ;-)
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> I would like to see Chen’s feature added , perhaps as
>>>>>>>> EXPERIMENTAL, so we can get some configuration testing done on
>>>>>>>> it. It corrects having a DMA zone in low memory while crash-
>>>>>>>> kernel is above 4GB. This has been going on for a year now.
>>>>>>> I will also like this patch to be added in Linux as early as
>>>>>>> possible.
>>>>>>>
>>>>>>> Issue mentioned by me happens with or without this patch.
>>>>>>>
>>>>>>> This patch-set can consider fixing because it uses low memory for
>>>>>>> DMA
>>>>>>> & swiotlb only.
>>>>>>> We can consider restricting crashkernel within the required range
>>>>>>> like below
>>>>>>>
>>>>>>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
>>>>>>> index 7f9e5a6dc48c..bd67b90d35bd 100644
>>>>>>> --- a/kernel/crash_core.c
>>>>>>> +++ b/kernel/crash_core.c
>>>>>>> @@ -354,7 +354,7 @@ int __init reserve_crashkernel_low(void)
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> - low_base = memblock_find_in_range(0, 1ULL << 32, low_size,
>>>>>>> CRASH_ALIGN);
>>>>>>> + low_base = memblock_find_in_range(0,0xc0000000, low_size,
>>>>>>> CRASH_ALIGN);
>>>>>>> if (!low_base) {
>>>>>>> pr_err("Cannot reserve %ldMB crashkernel low memory,
>>>>>>> please try smaller size.\n",
>>>>>>> (unsigned long)(low_size >> 20));
>>>>>>>
>>>>>>>
>>>>>> I suspect 0xc0000000 would need to be a CONFIG item and not
>>>>>> hard-coded.
>>>>>>
>>>>> if you consider this as valid change, can you please incorporate as
>>>>> part of your patch-set.
>>>> After commit 1a8e1cef7 ("arm64: use both ZONE_DMA and ZONE_DMA32")，the 0-
>>>> 4G memory is splited
>>>> to DMA [mem 0x0000000000000000-0x000000003fffffff] and DMA32 [mem
>>>> 0x0000000040000000-0x00000000ffffffff] on arm64.
>>>>
>>>> From the above discussion, on your platform, the low crashkernel fall in
>>>> DMA32 region, but your environment needs to access DMA
>>>> region, so there is the call trace.
>>>>
>>>> I have a question, why do you choose 0xc0000000 here?
>>>>
>>>> Besides, this is common code, we also need to consider about x86.
>>>>
>>> + nsaenzjulienne@suse.de
> Thanks for adding me to the conversation, and sorry for the headaches.
>
>>> Exactly . This is why it needs to be a CONFIG option for Raspberry
>>> .., or device tree option.
>>>
>>>
>>> We could revert 1a8e1cef7 since it broke Arm kdump too.
>> Well, unfortunately the patch for commit 1a8e1cef7603 ("arm64: use
>> both ZONE_DMA and ZONE_DMA32") was not Cc'ed to the kexec mailing
>> list, thus we couldn't get many eyes on it for a thorough review from
>> kexec/kdump p-o-v.
>>
>> Also we historically never had distinction in common arch code on the
>> basis of the intended end use-case: embedded, server or automotive, so
>> I am not sure introducing a Raspberry specific CONFIG option would be
>> a good idea.
> +1
>
> From the distros perspective it's very important to keep a single kernel image.
>
>> So, rather than reverting the patch, we can look at addressing the
>> same properly this time - especially from a kdump p-o-v.
>> This issue has been reported by some Red Hat arm64 partners with
>> upstream kernel also and as we have noticed in the past as well,
>> hardcoding the placement of the crashkernel base address (unless the
>> base address is specified by a crashkernel=X@Y like bootargs) is also
>> not a portable suggestion.
>>
>> I am working on a possible fix and will have more updates on the same
>> in a day-or-two.
> Please keep me in the loop, we've also had issues pointing to this reported by
> SUSE partners. I can do some testing both on the RPi4 and on big servers that
> need huge crashkernel sizes.
>
> Regards,
> Nicolas
>
Hi Nicolas,
You want want to review this topic with the various email threads . It
has been a long journey.
[1]:https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJwQs3C4x$
[v1]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ6e-mIEp$
[v2]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJyUVjUta$
[v3]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ3CXBRdT$
[v4]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ7SxW1Vj$
[v5]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ2wyJ9tj$
[v6]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJzvGhWBh$
[v7]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ6pAg6tX$
Chen Zhou (5):
x86: kdump: move reserve_crashkernel_low() into crash_core.c
arm64: kdump: reserve crashkenel above 4G for crash dump kernel
arm64: kdump: add memory for devices by DT property, low-memory-range
kdump: update Documentation about crashkernel on arm64
dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
Documentation/admin-guide/kdump/kdump.rst | 13 ++-
.../admin-guide/kernel-parameters.txt | 12 ++-
Documentation/devicetree/bindings/chosen.txt | 25 ++++++
arch/arm64/kernel/setup.c | 8 +-
arch/arm64/mm/init.c | 61 ++++++++++++-
arch/x86/kernel/setup.c | 66 ++------------
include/linux/crash_core.h | 3 +
include/linux/kexec.h | 2 -
kernel/crash_core.c | 85 +++++++++++++++++++
kernel/kexec_core.c | 17 ----
10 files changed, 208 insertions(+), 84 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: rectify entry in ARM SMC WATCHDOG DRIVER
From: Evan Benn @ 2020-06-05 1:42 UTC (permalink / raw)
To: Julius Werner
Cc: Guenter Roeck, Lukas Bulwahn, Wim Van Sebroeck, LINUX-WATCHDOG,
Rob Herring, devicetree, Joe Perches, kernel-janitors, LKML
In-Reply-To: <CAKz_xw0Tqr-idoZbNzg_didSCr5L+L1=76xjF=Sqj4DgpL9g7Q@mail.gmail.com>
AFAICT this has now been merged upstream, I'm not sure what action to take:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c24a28b4eb842ad1256496be6ae01bab15f1dcb
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72a9e7fea5866fc471fda78f05f166595c8c6ba6
On Wed, Jun 3, 2020 at 9:22 AM Evan Benn <evanbenn@chromium.org> wrote:
>
> Apologies for that slip up.
>
> Reviewed-by: Evan Benn <evanbenn@chromium.org>
>
> On Wed, Jun 3, 2020 at 6:16 AM Julius Werner <jwerner@chromium.org> wrote:
> >
> > Reviewed-by: Julius Werner <jwerner@chromium.org>
^ permalink raw reply
* Re: [PATCH v4 03/11] irqchip: add sl28cpld interrupt controller support
From: kernel test robot @ 2020-06-05 1:26 UTC (permalink / raw)
To: Michael Walle, linux-gpio, devicetree, linux-kernel, linux-hwmon,
linux-pwm, linux-watchdog, linux-arm-kernel
Cc: kbuild-all, Linus Walleij, Bartosz Golaszewski, Rob Herring
In-Reply-To: <20200604211039.12689-4-michael@walle.cc>
[-- Attachment #1: Type: text/plain, Size: 2927 bytes --]
Hi Michael,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20200604]
[cannot apply to gpio/for-next hwmon/hwmon-next ljones-mfd/for-mfd-next shawnguo/for-next v5.7 v5.7-rc7 v5.7-rc6 v5.7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Michael-Walle/Add-support-for-Kontron-sl28cpld/20200605-051333
base: d4899e5542c15062cc55cac0ca99025bb64edc61
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
drivers/irqchip/irq-sl28cpld.c: In function 'sl28cpld_intc_probe':
>> drivers/irqchip/irq-sl28cpld.c:56:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
56 | if (irq < 0)
| ^
vim +56 drivers/irqchip/irq-sl28cpld.c
35
36 static int sl28cpld_intc_probe(struct platform_device *pdev)
37 {
38 struct device *dev = &pdev->dev;
39 struct sl28cpld_intc *irqchip;
40 unsigned int irq;
41 u32 base;
42 int ret;
43
44 if (!dev->parent)
45 return -ENODEV;
46
47 irqchip = devm_kzalloc(dev, sizeof(*irqchip), GFP_KERNEL);
48 if (!irqchip)
49 return -ENOMEM;
50
51 irqchip->regmap = dev_get_regmap(dev->parent, NULL);
52 if (!irqchip->regmap)
53 return -ENODEV;
54
55 irq = platform_get_irq(pdev, 0);
> 56 if (irq < 0)
57 return irq;
58
59 ret = device_property_read_u32(&pdev->dev, "reg", &base);
60 if (ret)
61 return -EINVAL;
62
63 irqchip->chip.name = "sl28cpld-intc";
64 irqchip->chip.irqs = sl28cpld_irqs;
65 irqchip->chip.num_irqs = ARRAY_SIZE(sl28cpld_irqs);
66 irqchip->chip.num_regs = 1;
67 irqchip->chip.status_base = base + INTC_IP;
68 irqchip->chip.mask_base = base + INTC_IE;
69 irqchip->chip.mask_invert = true,
70 irqchip->chip.ack_base = base + INTC_IP;
71
72 return devm_regmap_add_irq_chip_np(&pdev->dev, dev->of_node,
73 irqchip->regmap, irq,
74 IRQF_SHARED | IRQF_ONESHOT, 0,
75 &irqchip->chip, &irqchip->irq_data);
76 }
77
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 66540 bytes --]
^ permalink raw reply
* Re: [PATCH v26 06/15] dt-bindings: leds: Convert leds-lp55xx to yaml
From: Dan Murphy @ 2020-06-05 0:08 UTC (permalink / raw)
To: Rob Herring; +Cc: jacek.anaszewski, pavel, devicetree, linux-leds, linux-kernel
In-Reply-To: <20200604230456.GA6520@bogus>
Rob
On 6/4/20 6:04 PM, Rob Herring wrote:
> On Thu, Jun 04, 2020 at 07:04:55AM -0500, Dan Murphy wrote:
>> Convert the leds-lp55xx.txt to yaml binding.
I will fix all your comments.
But why does your BOT have checkpatch warnings?
https://gitlab.com/robherring/linux-dt-review/-/jobs/581282098/artifacts/file/checkpatch-1303471.log
Is this because checkpatch thinks the .txt file is invalid?
Dan
^ permalink raw reply
* Re: [PATCH v26 06/15] dt-bindings: leds: Convert leds-lp55xx to yaml
From: Rob Herring @ 2020-06-04 23:04 UTC (permalink / raw)
To: Dan Murphy; +Cc: jacek.anaszewski, pavel, devicetree, linux-leds, linux-kernel
In-Reply-To: <20200604120504.32425-7-dmurphy@ti.com>
On Thu, Jun 04, 2020 at 07:04:55AM -0500, Dan Murphy wrote:
> Convert the leds-lp55xx.txt to yaml binding.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> .../devicetree/bindings/leds/leds-lp55xx.txt | 228 ------------------
> .../devicetree/bindings/leds/leds-lp55xx.yaml | 220 +++++++++++++++++
> 2 files changed, 220 insertions(+), 228 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/leds/leds-lp55xx.txt
> create mode 100644 Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
> deleted file mode 100644
> index 1b66a413fb9d..000000000000
> --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
> +++ /dev/null
> @@ -1,228 +0,0 @@
> -Binding for TI/National Semiconductor LP55xx Led Drivers
> -
> -Required properties:
> -- compatible: one of
> - national,lp5521
> - national,lp5523
> - ti,lp55231
> - ti,lp5562
> - ti,lp8501
> -
> -- reg: I2C slave address
> -- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external)
> -
> -Each child has own specific current settings
> -- led-cur: Current setting at each led channel (mA x10, 0 if led is not connected)
> -- max-cur: Maximun current at each led channel.
> -
> -Optional properties:
> -- enable-gpio: GPIO attached to the chip's enable pin
> -- label: Used for naming LEDs
> -- pwr-sel: LP8501 specific property. Power selection for output channels.
> - 0: D1~9 are connected to VDD
> - 1: D1~6 with VDD, D7~9 with VOUT
> - 2: D1~6 with VOUT, D7~9 with VDD
> - 3: D1~9 are connected to VOUT
> -
> -Alternatively, each child can have a specific channel name and trigger:
> -- chan-name (optional): name of channel
> -- linux,default-trigger (optional): see
> - Documentation/devicetree/bindings/leds/common.txt
> -
> -example 1) LP5521
> -3 LED channels, external clock used. Channel names are 'lp5521_pri:channel0',
> -'lp5521_pri:channel1' and 'lp5521_pri:channel2', with a heartbeat trigger
> -on channel 0.
> -
> -lp5521@32 {
> - compatible = "national,lp5521";
> - reg = <0x32>;
> - label = "lp5521_pri";
> - clock-mode = /bits/ 8 <2>;
> -
> - chan0 {
> - led-cur = /bits/ 8 <0x2f>;
> - max-cur = /bits/ 8 <0x5f>;
> - linux,default-trigger = "heartbeat";
> - };
> -
> - chan1 {
> - led-cur = /bits/ 8 <0x2f>;
> - max-cur = /bits/ 8 <0x5f>;
> - };
> -
> - chan2 {
> - led-cur = /bits/ 8 <0x2f>;
> - max-cur = /bits/ 8 <0x5f>;
> - };
> -};
> -
> -example 2) LP5523
> -9 LED channels with specific name. Internal clock used.
> -The I2C slave address is configurable with ASEL1 and ASEL0 pins.
> -Available addresses are 32/33/34/35h.
> -
> -ASEL1 ASEL0 Address
> --------------------------
> - GND GND 32h
> - GND VEN 33h
> - VEN GND 34h
> - VEN VEN 35h
> -
> -lp5523@32 {
> - compatible = "national,lp5523";
> - reg = <0x32>;
> - clock-mode = /bits/ 8 <1>;
> -
> - chan0 {
> - chan-name = "d1";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan1 {
> - chan-name = "d2";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan2 {
> - chan-name = "d3";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan3 {
> - chan-name = "d4";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan4 {
> - chan-name = "d5";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan5 {
> - chan-name = "d6";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan6 {
> - chan-name = "d7";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan7 {
> - chan-name = "d8";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan8 {
> - chan-name = "d9";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -};
> -
> -example 3) LP5562
> -4 channels are defined.
> -
> -lp5562@30 {
> - compatible = "ti,lp5562";
> - reg = <0x30>;
> - clock-mode = /bits/8 <2>;
> -
> - chan0 {
> - chan-name = "R";
> - led-cur = /bits/ 8 <0x20>;
> - max-cur = /bits/ 8 <0x60>;
> - };
> -
> - chan1 {
> - chan-name = "G";
> - led-cur = /bits/ 8 <0x20>;
> - max-cur = /bits/ 8 <0x60>;
> - };
> -
> - chan2 {
> - chan-name = "B";
> - led-cur = /bits/ 8 <0x20>;
> - max-cur = /bits/ 8 <0x60>;
> - };
> -
> - chan3 {
> - chan-name = "W";
> - led-cur = /bits/ 8 <0x20>;
> - max-cur = /bits/ 8 <0x60>;
> - };
> -};
> -
> -example 4) LP8501
> -9 channels are defined. The 'pwr-sel' is LP8501 specific property.
> -Others are same as LP5523.
> -
> -lp8501@32 {
> - compatible = "ti,lp8501";
> - reg = <0x32>;
> - clock-mode = /bits/ 8 <2>;
> - pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */
> -
> - chan0 {
> - chan-name = "d1";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan1 {
> - chan-name = "d2";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan2 {
> - chan-name = "d3";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan3 {
> - chan-name = "d4";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan4 {
> - chan-name = "d5";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan5 {
> - chan-name = "d6";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan6 {
> - chan-name = "d7";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan7 {
> - chan-name = "d8";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan8 {
> - chan-name = "d9";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
> new file mode 100644
> index 000000000000..9d6ded5fbc14
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
> @@ -0,0 +1,220 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/leds-lp55xx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI/National Semiconductor LP55xx and LP8501 LED Drivers
> +
> +maintainers:
> + - Jacek Anaszewski <jacek.anaszewski@gmail.com>
> + - Pavel Machek <pavel@ucw.cz>
> +
> +description: |
> + Bindings for the TI/National Semiconductor LP55xx and LP8501 multi channel
> + LED Drivers.
> +
> + For more product information please see the link below:
> + https://www.ti.com/lit/gpn/lp5521
> + https://www.ti.com/lit/gpn/lp5523
> + https://www.ti.com/lit/gpn/lp55231
> + https://www.ti.com/lit/gpn/lp5562
> + https://www.ti.com/lit/gpn/lp8501
> +
> +properties:
> + #allOf:
> + #- $ref: "common.yaml#"
> + #- $ref: "leds-class-multicolor.yaml#"
> +
> + compatible:
> + enum:
> + - national,lp5521
> + - national,lp5523
> + - ti,lp55231
> + - ti,lp5562
> + - ti,lp8501
> +
> + reg:
> + maxItems: 1
> + description: I2C slave address
> +
> + clock-mode:
> + $ref: /schemas/types.yaml#definitions/uint8
> + maxItems: 1
'maxItems' is for an array. This is a scalar, so drop.
> + description: |
> + Input clock mode
> + 0 - automode
> + 1 - internal
> + 2 - external
enum:
- 0 # automode
- 1
- 2
> +
> + enable-gpio:
> + maxItems: 1
> + description: |
> + GPIO attached to the chip's enable pin
> +
> + pwr-sel:
> + $ref: /schemas/types.yaml#definitions/uint8
> + maxItems: 1
> + description: |
> + LP8501 specific property. Power selection for output channels.
> + 0 - D1~9 are connected to VDD
> + 1 - D1~6 with VDD, D7~9 with VOUT
> + 2 - D1~6 with VOUT, D7~9 with VDD
> + 3 - D1~9 are connected to VOUT
Similarly here, make this a schema.
> +
> + child-node:
This needs to be a pattern matching the child nodes' names.
> + type: object
> + properties:
> + led-cur:
> + $ref: /schemas/types.yaml#definitions/uint8
> + maxItems: 1
Not an array.
> + description: |
> + Current setting at each LED channel (mA x10, 0 if LED is not connected)
0-255 are valid values?
> +
> + max-cur:
> + $ref: /schemas/types.yaml#definitions/uint8
> + maxItems: 1
> + description: Maximun current at each LED channel.
> +
> + reg:
> + maxItems: 1
> + description: |
> + Output channel for the LED. This is zero based channel identifier and
> + the data sheet is a one based channel identifier.
> + reg value to output to LED output number
> + D1 = reg value is 0
> + D2 = reg value is 1
> + D3 = reg value is 2
> + D4 = reg value is 3
> + D5 = reg value is 4
> + D6 = reg value is 5
> + D7 = reg value is 6
> + D8 = reg value is 7
> + D9 = reg value is 8
> +
> + chan-name:
> + $ref: /schemas/types.yaml#definitions/string
> + description: name of channel
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> + #include <dt-bindings/leds/common.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led-controller@32 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "ti,lp8501";
> + reg = <0x32>;
> + clock-mode = /bits/ 8 <2>;
> + pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */
> +
> + led@0 {
> + reg = <0>;
> + chan-name = "d1";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@1 {
> + reg = <1>;
> + chan-name = "d2";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@2 {
> + reg = <2>;
> + chan-name = "d3";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@3 {
> + reg = <3>;
> + chan-name = "d4";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@4 {
> + reg = <4>;
> + chan-name = "d5";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@5 {
> + reg = <5>;
> + chan-name = "d6";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@6 {
> + reg = <6>;
> + chan-name = "d7";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@7 {
> + reg = <7>;
> + chan-name = "d8";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@8 {
> + reg = <8>;
> + chan-name = "d9";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> + };
> +
> + led-controller@33 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "national,lp5523";
> + reg = <0x33>;
> + clock-mode = /bits/ 8 <0>;
> +
> + multi-led@2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x2>;
> + color = <LED_COLOR_ID_MULTI>;
> + function = LED_FUNCTION_STANDBY;
> + linux,default-trigger = "heartbeat";
> +
> + led@0 {
> + led-cur = /bits/ 8 <50>;
> + max-cur = /bits/ 8 <100>;
> + reg = <0x0>;
> + color = <LED_COLOR_ID_GREEN>;
> + };
> +
> + led@1 {
> + led-cur = /bits/ 8 <50>;
> + max-cur = /bits/ 8 <100>;
> + reg = <0x1>;
> + color = <LED_COLOR_ID_BLUE>;
> + };
> +
> + led@6 {
> + led-cur = /bits/ 8 <50>;
> + max-cur = /bits/ 8 <100>;
> + reg = <0x6>;
> + color = <LED_COLOR_ID_RED>;
> + };
> + };
> + };
> + };
> --
> 2.26.2
>
^ 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