* Re: [PATCH V6 1/7] soc: qcom: geni: Support for ICC voting
From: Matthias Kaehlcke @ 2020-05-21 15:50 UTC (permalink / raw)
To: Akash Asthana
Cc: gregkh, agross, bjorn.andersson, wsa, broonie, mark.rutland,
robh+dt, linux-i2c, linux-spi, devicetree, swboyd, mgautam,
linux-arm-msm, linux-serial, dianders, msavaliy, evgreen
In-Reply-To: <1590049764-20912-2-git-send-email-akashast@codeaurora.org>
Hi Akash,
On Thu, May 21, 2020 at 01:59:18PM +0530, Akash Asthana wrote:
> Add necessary macros and structure variables to support ICC BW
> voting from individual SE drivers.
>
> Signed-off-by: Akash Asthana <akashast@codeaurora.org>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> Changes in V2:
> - As per Bjorn's comment dropped enums for ICC paths, given the three
> paths individual members
>
> Changes in V3:
> - Add geni_icc_get, geni_icc_vote_on and geni_icc_vote_off as helper API.
> - Add geni_icc_path structure in common header
>
> Changes in V4:
> - As per Bjorn's comment print error message in geni_icc_get if return
> value is not -EPROBE_DEFER.
> - As per Bjorn's comment remove NULL on path before calling icc_set_bw
> API.
> - As per Bjorn's comment drop __func__ print.
> - As per Matthias's comment, make ICC path a array instead of individual
> member entry in geni_se struct.
>
> Changes in V5:
> - As per Matthias's comment defined enums for ICC paths.
> - Integrate icc_enable/disable with power on/off call for driver.
> - As per Matthias's comment added icc_path_names array to print icc path name
> in failure case.
> - As per Georgi's suggestion assume peak_bw = avg_bw if not mentioned.
>
> Changes in V6:
> - Addressed nitpicks from Matthias.
>
> Note: I have ignored below check patch suggestion because it was throwing
> compilation error as 'icc_ddr' is not compile time comstant.
>
> WARNING: char * array declaration might be better as static const
> - FILE: drivers/soc/qcom/qcom-geni-se.c:726:
> - const char *icc_names[] = {"qup-core", "qup-config", icc_ddr};
>
> drivers/soc/qcom/qcom-geni-se.c | 92 +++++++++++++++++++++++++++++++++++++++++
> include/linux/qcom-geni-se.h | 42 +++++++++++++++++++
> 2 files changed, 134 insertions(+)
>
> diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
> index 7d622ea..0b2526d 100644
> --- a/drivers/soc/qcom/qcom-geni-se.c
> +++ b/drivers/soc/qcom/qcom-geni-se.c
> @@ -92,6 +92,9 @@ struct geni_wrapper {
> struct clk_bulk_data ahb_clks[NUM_AHB_CLKS];
> };
>
> +static const char * const icc_path_names[] = {"qup-core", "qup-config",
> + "qup-memory"};
> +
> #define QUP_HW_VER_REG 0x4
>
> /* Common SE registers */
> @@ -720,6 +723,95 @@ void geni_se_rx_dma_unprep(struct geni_se *se, dma_addr_t iova, size_t len)
> }
> EXPORT_SYMBOL(geni_se_rx_dma_unprep);
>
> +int geni_icc_get(struct geni_se *se, const char *icc_ddr)
> +{
> + int i, err;
> + const char *icc_names[] = {"qup-core", "qup-config", icc_ddr};
> +
> + for (i = 0; i < ARRAY_SIZE(se->icc_paths); i++) {
> + if (!icc_names[i])
> + continue;
> +
> + se->icc_paths[i].path = devm_of_icc_get(se->dev, icc_names[i]);
> + if (IS_ERR(se->icc_paths[i].path))
> + goto err;
> + }
> +
> + return 0;
> +
> +err:
> + err = PTR_ERR(se->icc_paths[i].path);
> + if (err != -EPROBE_DEFER)
> + dev_err_ratelimited(se->dev, "Failed to get ICC path:%s :%d\n",
That's still an odd format, especially the colon before the error code. My
suggestion was "... path 'qup-core': 42" i.e. "... path '%s': %d".
I don't want to stall the series on nits though, if there is no need for
a respin for other reasons this can be also fixed with a patch after this
has landed.
I'm still not overly convinced about having two bandwidth values for what
might happen in the future (or not). Typically unused functions or struct
members that are added just in case tend to be rejected, since they can be
added when the need actually arises. Anyway, as long as maintainers are
happy with it I won't object.
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
^ permalink raw reply
* Re: [PATCH v8 10/14] media: platform: Delete redundant code for improving code quality
From: Tomasz Figa @ 2020-05-21 15:49 UTC (permalink / raw)
To: Xia Jiang
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: <20200403094033.8288-11-xia.jiang@mediatek.com>
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.
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH v3 11/14] bus: cdmm: Add MIPS R5 arch support
From: Sergei Shtylyov @ 2020-05-21 15:44 UTC (permalink / raw)
To: Serge Semin
Cc: Serge Semin, Thomas Bogendoerfer, Alexey Malahov, Paul Burton,
Ralf Baechle, Greg Kroah-Hartman, Arnd Bergmann, Olof Johansson,
Rob Herring, linux-mips, devicetree, Jonathan Cameron,
David Lechner, John Garry, Manivannan Sadhasivam, Jon Hunter,
Marek Behún, Sameer Pujar, linux-kernel
In-Reply-To: <20200521125851.5upamjd7ldirj57a@mobilestation>
On 21.05.2020 15:58, Serge Semin wrote:
>>> CDMM may be available not only MIPS R2 architectures, but also in
>> ^ on -re, it's singular
>
> Thanks, Sergey. Got it. I'll fix it in the next revision.
>
>>> newer MIPS R5 chips. For instance our P5600 chip has one. Lets mark
> Probably also: ^ Let's
> Right?
Yes.
Thanks for replying. :-)
>
> -Sergey
>
>>> the CDMM bus being supported for that MIPS arch too.
>
>>>
>>> Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
>>> Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
>>> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>>> Reviewed-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
>>> Cc: Paul Burton <paulburton@kernel.org>
>>> Cc: Ralf Baechle <ralf@linux-mips.org>
>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>> Cc: Olof Johansson <olof@lixom.net>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>> Cc: linux-mips@vger.kernel.org
>>> Cc: devicetree@vger.kernel.org
>> [...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v8 09/14] media: platform: Change MTK_JPEG_COMP_MAX macro definition location
From: Tomasz Figa @ 2020-05-21 15:44 UTC (permalink / raw)
To: Xia Jiang
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: <20200403094033.8288-10-xia.jiang@mediatek.com>
On Fri, Apr 03, 2020 at 05:40:28PM +0800, Xia Jiang wrote:
> Move MTK_JPEG_COMP_MAX definition to mtk_jpeg_core.h file, because it
> is used by mtk_jpeg_core.c file.
>
> Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
> ---
> v8: no changes
> ---
> drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 2 ++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h | 1 -
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH v8 07/14] media: platform: Use kernel native functions for improving code quality
From: Tomasz Figa @ 2020-05-21 15:41 UTC (permalink / raw)
To: Xia Jiang
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: <20200403094033.8288-8-xia.jiang@mediatek.com>
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?
> 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.
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
* [PATCH v7 0/2] Add USB DWC3 support for SC7180
From: Sandeep Maheswaram @ 2020-05-21 15:38 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Greg Kroah-Hartman, Rob Herring,
Mark Rutland, Felipe Balbi, Stephen Boyd, Doug Anderson,
Matthias Kaehlcke
Cc: linux-arm-msm, linux-usb, devicetree, linux-kernel, Manu Gautam,
Sandeep Maheswaram
Converting dt binding to yaml.
Adding compatible for SC7180 in dt bindings.
Changes in v7:
Solved the dt binding check error by adding soc field in example.
Changes in v6:
Addressed the comments from Stephen on interrupts.
Added ranges property and dropped maxItems field for assigned-clock-rates.
Changes in v5:
Addressed the comments from Stephen in yaml file.
Changes in v4:
Addressed the comments from Doug in yaml file.
Changes in v3:
Dropped the patch for adding the compatible in dwc3 driver from the series.
Addressed the comments from Doug in yaml file.
Changes in v2:
Sorted the compatible in dwc3 driver.
Converted dt binding to yaml.
Added compatible in yaml.
Sandeep Maheswaram (2):
dt-bindings: usb: qcom,dwc3: Convert USB DWC3 bindings
dt-bindings: usb: qcom,dwc3: Add compatible for SC7180
.../devicetree/bindings/usb/qcom,dwc3.txt | 104 -------------
.../devicetree/bindings/usb/qcom,dwc3.yaml | 168 +++++++++++++++++++++
2 files changed, 168 insertions(+), 104 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/qcom,dwc3.txt
create mode 100644 Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v7 1/2] dt-bindings: usb: qcom,dwc3: Convert USB DWC3 bindings
From: Sandeep Maheswaram @ 2020-05-21 15:38 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Greg Kroah-Hartman, Rob Herring,
Mark Rutland, Felipe Balbi, Stephen Boyd, Doug Anderson,
Matthias Kaehlcke
Cc: linux-arm-msm, linux-usb, devicetree, linux-kernel, Manu Gautam,
Sandeep Maheswaram
In-Reply-To: <1590075499-21350-1-git-send-email-sanm@codeaurora.org>
Convert USB DWC3 bindings to DT schema format using json-schema.
Signed-off-by: Sandeep Maheswaram <sanm@codeaurora.org>
---
.../devicetree/bindings/usb/qcom,dwc3.txt | 104 -------------
.../devicetree/bindings/usb/qcom,dwc3.yaml | 167 +++++++++++++++++++++
2 files changed, 167 insertions(+), 104 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/qcom,dwc3.txt
create mode 100644 Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
deleted file mode 100644
index fbdd017..0000000
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
+++ /dev/null
@@ -1,104 +0,0 @@
-Qualcomm SuperSpeed DWC3 USB SoC controller
-
-Required properties:
-- compatible: Compatible list, contains
- "qcom,dwc3"
- "qcom,msm8996-dwc3" for msm8996 SOC.
- "qcom,msm8998-dwc3" for msm8998 SOC.
- "qcom,sdm845-dwc3" for sdm845 SOC.
-- reg: Offset and length of register set for QSCRATCH wrapper
-- power-domains: specifies a phandle to PM domain provider node
-- clocks: A list of phandle + clock-specifier pairs for the
- clocks listed in clock-names
-- clock-names: Should contain the following:
- "core" Master/Core clock, have to be >= 125 MHz for SS
- operation and >= 60MHz for HS operation
- "mock_utmi" Mock utmi clock needed for ITP/SOF generation in
- host mode. Its frequency should be 19.2MHz.
- "sleep" Sleep clock, used for wakeup when USB3 core goes
- into low power mode (U3).
-
-Optional clocks:
- "iface" System bus AXI clock.
- Not present on "qcom,msm8996-dwc3" compatible.
- "cfg_noc" System Config NOC clock.
- Not present on "qcom,msm8996-dwc3" compatible.
-- assigned-clocks: Should be:
- MOCK_UTMI_CLK
- MASTER_CLK
-- assigned-clock-rates: Should be:
- 19.2Mhz (192000000) for MOCK_UTMI_CLK
- >=125Mhz (125000000) for MASTER_CLK in SS mode
- >=60Mhz (60000000) for MASTER_CLK in HS mode
-
-Optional properties:
-- resets: Phandle to reset control that resets core and wrapper.
-- interrupts: specifies interrupts from controller wrapper used
- to wakeup from low power/susepnd state. Must contain
- one or more entry for interrupt-names property
-- interrupt-names: Must include the following entries:
- - "hs_phy_irq": The interrupt that is asserted when a
- wakeup event is received on USB2 bus
- - "ss_phy_irq": The interrupt that is asserted when a
- wakeup event is received on USB3 bus
- - "dm_hs_phy_irq" and "dp_hs_phy_irq": Separate
- interrupts for any wakeup event on DM and DP lines
-- qcom,select-utmi-as-pipe-clk: if present, disable USB3 pipe_clk requirement.
- Used when dwc3 operates without SSPHY and only
- HS/FS/LS modes are supported.
-
-Required child node:
-A child node must exist to represent the core DWC3 IP block. The name of
-the node is not important. The content of the node is defined in dwc3.txt.
-
-Phy documentation is provided in the following places:
-Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt - USB3 QMP PHY
-Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml - USB2 QUSB2 PHY
-
-Example device nodes:
-
- hs_phy: phy@100f8800 {
- compatible = "qcom,qusb2-v2-phy";
- ...
- };
-
- ss_phy: phy@100f8830 {
- compatible = "qcom,qmp-v3-usb3-phy";
- ...
- };
-
- usb3_0: usb30@a6f8800 {
- compatible = "qcom,dwc3";
- reg = <0xa6f8800 0x400>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- interrupts = <0 131 0>, <0 486 0>, <0 488 0>, <0 489 0>;
- interrupt-names = "hs_phy_irq", "ss_phy_irq",
- "dm_hs_phy_irq", "dp_hs_phy_irq";
-
- clocks = <&gcc GCC_USB30_PRIM_MASTER_CLK>,
- <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
- <&gcc GCC_USB30_PRIM_SLEEP_CLK>;
- clock-names = "core", "mock_utmi", "sleep";
-
- assigned-clocks = <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
- <&gcc GCC_USB30_PRIM_MASTER_CLK>;
- assigned-clock-rates = <19200000>, <133000000>;
-
- resets = <&gcc GCC_USB30_PRIM_BCR>;
- reset-names = "core_reset";
- power-domains = <&gcc USB30_PRIM_GDSC>;
- qcom,select-utmi-as-pipe-clk;
-
- dwc3@10000000 {
- compatible = "snps,dwc3";
- reg = <0x10000000 0xcd00>;
- interrupts = <0 205 0x4>;
- phys = <&hs_phy>, <&ss_phy>;
- phy-names = "usb2-phy", "usb3-phy";
- dr_mode = "host";
- };
- };
-
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
new file mode 100644
index 0000000..6be384c
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -0,0 +1,167 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SuperSpeed DWC3 USB SoC controller
+
+maintainers:
+ - Manu Gautam <mgautam@codeaurora.org>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,msm8996-dwc3
+ - qcom,msm8998-dwc3
+ - qcom,sdm845-dwc3
+ - const: qcom,dwc3
+
+ reg:
+ description: Offset and length of register set for QSCRATCH wrapper
+ maxItems: 1
+
+ "#address-cells":
+ enum: [ 1, 2 ]
+
+ "#size-cells":
+ enum: [ 1, 2 ]
+
+ ranges: true
+
+ power-domains:
+ description: specifies a phandle to PM domain provider node
+ maxItems: 1
+
+ clocks:
+ description:
+ A list of phandle and clock-specifier pairs for the clocks
+ listed in clock-names.
+ items:
+ - description: System Config NOC clock.
+ - description: Master/Core clock, has to be >= 125 MHz
+ for SS operation and >= 60MHz for HS operation.
+ - description: System bus AXI clock.
+ - description: Mock utmi clock needed for ITP/SOF generation
+ in host mode. Its frequency should be 19.2MHz.
+ - description: Sleep clock, used for wakeup when
+ USB3 core goes into low power mode (U3).
+
+ clock-names:
+ items:
+ - const: cfg_noc
+ - const: core
+ - const: iface
+ - const: mock_utmi
+ - const: sleep
+
+ assigned-clocks:
+ items:
+ - description: Phandle and clock specifier of MOCK_UTMI_CLK.
+ - description: Phandle and clock specifoer of MASTER_CLK.
+
+ assigned-clock-rates:
+ items:
+ - description: Must be 19.2MHz (19200000).
+ - description: Must be >= 60 MHz in HS mode, >= 125 MHz in SS mode.
+ resets:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: The interrupt that is asserted
+ when a wakeup event is received on USB2 bus.
+ - description: The interrupt that is asserted
+ when a wakeup event is received on USB3 bus.
+ - description: Wakeup event on DM line.
+ - description: Wakeup event on DP line.
+
+ interrupt-names:
+ items:
+ - const: hs_phy_irq
+ - const: ss_phy_irq
+ - const: dm_hs_phy_irq
+ - const: dp_hs_phy_irq
+
+ qcom,select-utmi-as-pipe-clk:
+ description:
+ If present, disable USB3 pipe_clk requirement.
+ Used when dwc3 operates without SSPHY and only
+ HS/FS/LS modes are supported.
+ type: boolean
+
+# Required child node:
+
+patternProperties:
+ "^dwc3@[0-9a-f]+$":
+ type: object
+ description:
+ A child node must exist to represent the core DWC3 IP block
+ The content of the node is defined in dwc3.txt.
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+ - power-domains
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sdm845.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ soc: soc@0 {
+ reg = <0 0x10000000 0 0x0fffffff>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ usb@a6f8800 {
+ compatible = "qcom,sdm845-dwc3", "qcom,dwc3";
+ reg = <0 0x0a6f8800 0 0x400>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ clocks = <&gcc GCC_CFG_NOC_USB3_PRIM_AXI_CLK>,
+ <&gcc GCC_USB30_PRIM_MASTER_CLK>,
+ <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>,
+ <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
+ <&gcc GCC_USB30_PRIM_SLEEP_CLK>;
+ clock-names = "cfg_noc", "core", "iface", "mock_utmi",
+ "sleep";
+
+ assigned-clocks = <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
+ <&gcc GCC_USB30_PRIM_MASTER_CLK>;
+ assigned-clock-rates = <19200000>, <150000000>;
+
+ interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 486 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 488 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 489 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hs_phy_irq", "ss_phy_irq",
+ "dm_hs_phy_irq", "dp_hs_phy_irq";
+
+ power-domains = <&gcc USB30_PRIM_GDSC>;
+
+ resets = <&gcc GCC_USB30_PRIM_BCR>;
+
+ dwc3@a600000 {
+ compatible = "snps,dwc3";
+ reg = <0 0x0a600000 0 0xcd00>;
+ interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
+ iommus = <&apps_smmu 0x740 0>;
+ snps,dis_u2_susphy_quirk;
+ snps,dis_enblslpm_quirk;
+ phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
+ phy-names = "usb2-phy", "usb3-phy";
+ };
+ };
+ };
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v7 2/2] dt-bindings: usb: qcom,dwc3: Add compatible for SC7180
From: Sandeep Maheswaram @ 2020-05-21 15:38 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Greg Kroah-Hartman, Rob Herring,
Mark Rutland, Felipe Balbi, Stephen Boyd, Doug Anderson,
Matthias Kaehlcke
Cc: linux-arm-msm, linux-usb, devicetree, linux-kernel, Manu Gautam,
Sandeep Maheswaram
In-Reply-To: <1590075499-21350-1-git-send-email-sanm@codeaurora.org>
Add compatible for SC7180 in usb dwc3 bindings.
Signed-off-by: Sandeep Maheswaram <sanm@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
---
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index 6be384c..052d85e 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -16,6 +16,7 @@ properties:
- enum:
- qcom,msm8996-dwc3
- qcom,msm8998-dwc3
+ - qcom,sc7180-dwc3
- qcom,sdm845-dwc3
- const: qcom,dwc3
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile
From: Florian Fainelli @ 2020-05-21 15:37 UTC (permalink / raw)
To: Greg Kroah-Hartman, Alan Cooper
Cc: Alan Stern, : Linux Kernel Mailing List, Andy Shevchenko, DTML,
Krzysztof Kozlowski, USB list, Mathias Nyman, Rob Herring,
Yoshihiro Shimoda, Andy Shevchenko
In-Reply-To: <20200521060902.GA2352222@kroah.com>
On 5/20/2020 11:09 PM, Greg Kroah-Hartman wrote:
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
> A: No.
> Q: Should I include quotations after my reply?
>
> http://daringfireball.net/2007/07/on_top
>
> On Wed, May 20, 2020 at 01:29:45PM -0400, Alan Cooper wrote:
>> Greg, Alan,
>>
>> The other 4 related patches were accepted into usb-next and I just
>> realized that this one didn't make it. This patch will not fix the
>> "insmod out of order" issue, but will help our controllers work with
>> some poorly behaved USB devices when the drivers are builtin.
>
> As it doesn't solve the real issue, I did not accept this so that you
> all can continue to work on creating a real solution that works for both
> situations (built in and as modules.)
>
> I thought I said that already...
Your message was not clear to me at least, I understood your message as:
I acknowledge the problem you are trying to solve and accept Al's
solution for the case where modules are built-in, and another solution
should be found for when the modules are built as loadable modules.
But okay, your message is clear now :).
--
Florian
^ permalink raw reply
* Re: [PATCH 2/4] arm: dts: mt2712: add uart APDMA to device tree
From: Matthias Brugger @ 2020-05-21 15:35 UTC (permalink / raw)
To: Long Cheng, Vinod Koul, Randy Dunlap, Rob Herring, Mark Rutland,
Ryder Lee, Sean Wang, Nicolas Boichat
Cc: Dan Williams, Greg Kroah-Hartman, Jiri Slaby, Sean Wang,
dmaengine, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-serial, srv_heupstream, Yingjoe Chen, YT Shen,
Zhenbao Liu
In-Reply-To: <1556336193-15198-3-git-send-email-long.cheng@mediatek.com>
On 27/04/2019 05:36, Long Cheng wrote:
> 1. add uart APDMA controller device node
> 2. add uart 0/1/2/3/4/5 DMA function
>
> Signed-off-by: Long Cheng <long.cheng@mediatek.com>
Queued now for v5.7-next/dts64
Thanks!
> ---
> arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 51 +++++++++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> index 976d92a..f1e419e 100644
> --- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> @@ -300,6 +300,9 @@
> interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
> clocks = <&baud_clk>, <&sys_clk>;
> clock-names = "baud", "bus";
> + dmas = <&apdma 10
> + &apdma 11>;
> + dma-names = "tx", "rx";
> status = "disabled";
> };
>
> @@ -369,6 +372,39 @@
> (GIC_CPU_MASK_RAW(0x13) | IRQ_TYPE_LEVEL_HIGH)>;
> };
>
> + apdma: dma-controller@11000400 {
> + compatible = "mediatek,mt2712-uart-dma",
> + "mediatek,mt6577-uart-dma";
> + reg = <0 0x11000400 0 0x80>,
> + <0 0x11000480 0 0x80>,
> + <0 0x11000500 0 0x80>,
> + <0 0x11000580 0 0x80>,
> + <0 0x11000600 0 0x80>,
> + <0 0x11000680 0 0x80>,
> + <0 0x11000700 0 0x80>,
> + <0 0x11000780 0 0x80>,
> + <0 0x11000800 0 0x80>,
> + <0 0x11000880 0 0x80>,
> + <0 0x11000900 0 0x80>,
> + <0 0x11000980 0 0x80>;
> + interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 105 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 106 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 107 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 108 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 109 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 110 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 111 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 112 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 113 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 114 IRQ_TYPE_LEVEL_LOW>;
> + dma-requests = <12>;
> + clocks = <&pericfg CLK_PERI_AP_DMA>;
> + clock-names = "apdma";
> + #dma-cells = <1>;
> + };
> +
> auxadc: adc@11001000 {
> compatible = "mediatek,mt2712-auxadc";
> reg = <0 0x11001000 0 0x1000>;
> @@ -385,6 +421,9 @@
> interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_LOW>;
> clocks = <&baud_clk>, <&sys_clk>;
> clock-names = "baud", "bus";
> + dmas = <&apdma 0
> + &apdma 1>;
> + dma-names = "tx", "rx";
> status = "disabled";
> };
>
> @@ -395,6 +434,9 @@
> interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_LOW>;
> clocks = <&baud_clk>, <&sys_clk>;
> clock-names = "baud", "bus";
> + dmas = <&apdma 2
> + &apdma 3>;
> + dma-names = "tx", "rx";
> status = "disabled";
> };
>
> @@ -405,6 +447,9 @@
> interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_LOW>;
> clocks = <&baud_clk>, <&sys_clk>;
> clock-names = "baud", "bus";
> + dmas = <&apdma 4
> + &apdma 5>;
> + dma-names = "tx", "rx";
> status = "disabled";
> };
>
> @@ -415,6 +460,9 @@
> interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_LOW>;
> clocks = <&baud_clk>, <&sys_clk>;
> clock-names = "baud", "bus";
> + dmas = <&apdma 6
> + &apdma 7>;
> + dma-names = "tx", "rx";
> status = "disabled";
> };
>
> @@ -629,6 +677,9 @@
> interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_LOW>;
> clocks = <&baud_clk>, <&sys_clk>;
> clock-names = "baud", "bus";
> + dmas = <&apdma 8
> + &apdma 9>;
> + dma-names = "tx", "rx";
> status = "disabled";
> };
>
>
^ permalink raw reply
* Re: [PATCH v3 01/16] spi: dw: Add Tx/Rx finish wait methods to the MID DMA
From: Serge Semin @ 2020-05-21 15:33 UTC (permalink / raw)
To: Feng Tang
Cc: Serge Semin, Mark Brown, Grant Likely, Vinod Koul, Alan Cox,
Linus Walleij, Georgy Vlasov, Ramil Zaripov, Alexey Malahov,
Thomas Bogendoerfer, Paul Burton, Ralf Baechle, Arnd Bergmann,
Andy Shevchenko, Rob Herring, linux-mips, devicetree,
Jarkko Nikula, Thomas Gleixner, Wan Ahmad Zainie, Linus Walleij,
Clement Leger, linux-spi, linux-kernel
In-Reply-To: <20200521145520.GB12568@shbuild999.sh.intel.com>
On Thu, May 21, 2020 at 10:55:20PM +0800, Feng Tang wrote:
> Hi Serge,
>
> On Thu, May 21, 2020 at 02:47:36PM +0300, Serge Semin wrote:
> > Hello Feng,
> >
> > On Thu, May 21, 2020 at 11:09:24AM +0800, Feng Tang wrote:
> > > Hi Serge,
> > >
> > > On Thu, May 21, 2020 at 04:21:51AM +0300, Serge Semin wrote:
> >
> > [nip]
> >
> > > > /*
> > > > * dws->dma_chan_busy is set before the dma transfer starts, callback for rx
> > > > * channel will clear a corresponding bit.
> > > > @@ -200,6 +267,8 @@ static void dw_spi_dma_rx_done(void *arg)
> > > > {
> > > > struct dw_spi *dws = arg;
> > > >
> > > > + dw_spi_dma_wait_rx_done(dws);
> > >
> > > I can understand the problem about TX, but I don't see how RX
> > > will get hurt, can you elaborate more? thanks
> > >
> > > - Feng
> >
> > Your question is correct. You are right with your hypothesis. Ideally upon the
> > dw_spi_dma_rx_done() execution Rx FIFO must be already empty. That's why the
> > commit log signifies the error being mostly related with Tx FIFO. But
> > practically there are many reasons why Rx FIFO might be left with data:
> > DMA engine failures, incorrect DMA configuration (if DW SPI or DW DMA driver
> > messed something up), controller hanging up, and so on. It's better to catch
> > an error at this stage while propagating it up to the SPI device drivers.
> > Especially seeing the wait-check implementation doesn't gives us much of the
> > execution overhead in normal conditions. So by calling dw_spi_dma_wait_rx_done()
> > we make sure that all the data has been fetched and we may freely get the
> > buffers back to the client driver.
>
> I see your point about checking RX. But I still don't think checking
> RX FIFO level is the right way to detect error. Some data left in
> RX FIFO doesn't always mean a error, say for some case if there is
> 20 words in RX FIFO, and the driver starts a DMA request for 16
> words, then after a sucessful DMA transaction, there are 4 words
> left without any error.
Neither Tx nor Rx FIFO should be left with any data after transaction is
finished. If they are then something has been wrong.
See, every SPI transfer starts with FIFO clearance since we disable/enable the
SPI controller by means of the SSIENR (spi_enable_chip(dws, 0) and
spi_enable_chip(dws, 1) called in the dw_spi_transfer_one() callback). Here is the
SSIENR register description: "It enables and disables all SPI Controller operations.
When disabled, all serial transfers are halted immediately. Transmit and receive
FIFO buffers are cleared when the device is disabled. It is impossible to program
some of the SPI Controller control registers when enabled"
No mater whether we start DMA request or perform the normal IRQ-based PIO, we
request as much data as we need and neither Tx nor Rx FIFO are supposed to
be left with any data after the request is finished. If data is left, then
either we didn't push all of the necessary data to the SPI bus, or we didn't
pull all the data from the FIFO, and this could have happened only due to some
component mulfunction (drivers, DMA engine, SPI device). In any case the SPI
device driver should be notified about the problem.
-Sergey
>
> Thanks,
> Feng
>
> >
> > -Sergey
^ permalink raw reply
* Re: [PATCH v8 06/14] media: platform: Improve the implementation of the system PM ops
From: Tomasz Figa @ 2020-05-21 15:32 UTC (permalink / raw)
To: Xia Jiang
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: <20200403094033.8288-7-xia.jiang@mediatek.com>
Hi Xia,
On Fri, Apr 03, 2020 at 05:40:25PM +0800, Xia Jiang wrote:
> Cancel reset hw operation in suspend and resume function because this
> will be done in device_run().
This and...
> Add spin_lock and unlock operation in irq and resume function to make
> sure that the current frame is processed completely before suspend.
...this are two separate changes. Please split.
>
> Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
> ---
> drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> index dd5cadd101ef..2fa3711fdc9b 100644
> --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> @@ -911,6 +911,8 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
> u32 dec_ret;
> int i;
>
> + spin_lock(&jpeg->hw_lock);
> +
nit: For consistency, it is recommended to always use the same, i.e. the
strongest, spin_(un)lock_ primitives when operating on the same spinlock.
In this case it would be the irqsave(restore) variants.
> dec_ret = mtk_jpeg_dec_get_int_status(jpeg->dec_reg_base);
> dec_irq_ret = mtk_jpeg_dec_enum_result(dec_ret);
> ctx = v4l2_m2m_get_curr_priv(jpeg->m2m_dev);
> @@ -941,6 +943,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);
> + spin_unlock(&jpeg->hw_lock);
> pm_runtime_put_sync(ctx->jpeg->dev);
> return IRQ_HANDLED;
> }
> @@ -1191,7 +1194,6 @@ static __maybe_unused int mtk_jpeg_pm_suspend(struct device *dev)
> {
> struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
>
> - mtk_jpeg_dec_reset(jpeg->dec_reg_base);
> mtk_jpeg_clk_off(jpeg);
>
> return 0;
> @@ -1202,19 +1204,24 @@ static __maybe_unused int mtk_jpeg_pm_resume(struct device *dev)
> struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
>
> mtk_jpeg_clk_on(jpeg);
> - mtk_jpeg_dec_reset(jpeg->dec_reg_base);
>
> return 0;
> }
>
> static __maybe_unused int mtk_jpeg_suspend(struct device *dev)
> {
> + struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
> + unsigned long flags;
> int ret;
>
> if (pm_runtime_suspended(dev))
> return 0;
>
> + spin_lock_irqsave(&jpeg->hw_lock, flags);
What does this spinlock protect us from? I can see that it would prevent
the interrupt handler from being called, but is it okay to suspend the
system without handling the interrupt?
> +
> ret = mtk_jpeg_pm_suspend(dev);
> +
Looking at the implementation of mtk_jpeg_pm_suspend(), all it does is
disabling the clock. How do we make sure that there is no frame currently
being processed by the hardware?
Best regards,
Tomasz
^ permalink raw reply
* [PATCH V2 1/3] dt-bindings: mmc: Supply max load for mmc supplies
From: Veerabhadrarao Badiganti @ 2020-05-21 15:23 UTC (permalink / raw)
To: adrian.hunter, ulf.hansson, bjorn.andersson, robh+dt
Cc: linux-mmc, linux-kernel, linux-arm-msm, devicetree,
Veerabhadrarao Badiganti
In-Reply-To: <1590074615-10787-1-git-send-email-vbadigan@codeaurora.org>
Supply the max load needed for driving the mmc supplies.
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
---
.../devicetree/bindings/mmc/mmc-controller.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
index acc9f10..9058b82 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
@@ -290,6 +290,22 @@ properties:
description:
Supply for the bus IO line power
+ vmmc-max-load-microamp:
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - minimum: 0
+ - maximum: 1000000
+ description:
+ Maximum load for the card power.
+
+ vqmmc-max-load-microamp:
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - minimum: 0
+ - maximum: 1000000
+ description:
+ Maximum load for the bus IO line power.
+
mmc-pwrseq:
$ref: /schemas/types.yaml#/definitions/phandle
description:
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH V2 0/3] Internal voltage control for qcom SDHC
From: Veerabhadrarao Badiganti @ 2020-05-21 15:23 UTC (permalink / raw)
To: adrian.hunter, ulf.hansson, bjorn.andersson, robh+dt
Cc: linux-mmc, linux-kernel, linux-arm-msm, devicetree,
Veerabhadrarao Badiganti
In-Reply-To: <1589541535-8523-1-git-send-email-vbadigan@codeaurora.org>
On qcom SD host controllers voltage switching be done after the HW
is ready for it. The HW informs its readiness through power irq.
The voltage switching should happen only then.
So added support to register voltage regulators from the msm driver
and use them.
This patchset was posted long back but not actively pursued
https://lore.kernel.org/linux-arm-msm/1539004739-32060-1-git-send-email-vbadigan@codeaurora.org/
So posting it as fresh patchset.
Changes since V1:
- Removed setting load for Vmmc regulator while turning it on/off.
Instead setting the active load once during probe.
- Simplified handlng of supplies for BUS_ON/OFF cases in shci_msm_handle_pwr_irq().
- Moved common code out of switch case in sdhci_msm_start_signal_voltage_switch().
- Updated variable name to sdhci_core_to_disable_vqmmc.
- Updated pr_err logs to dev_err logs.
Veerabhadrarao Badiganti (1):
dt-bindings: mmc: Supply max load for mmc supplies
mmc: sdhci-msm: Use internal voltage control
Vijay Viswanath (1):
mmc: sdhci: Allow platform controlled voltage switching
.../devicetree/bindings/mmc/mmc-controller.yaml | 16 ++
drivers/mmc/host/sdhci-msm.c | 207 ++++++++++++++++++++-
drivers/mmc/host/sdhci.c | 32 ++--
drivers/mmc/host/sdhci.h | 1 +
4 files changed, 234 insertions(+), 22 deletions(-)
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V2 2/3] mmc: sdhci-msm: Use internal voltage control
From: Veerabhadrarao Badiganti @ 2020-05-21 15:23 UTC (permalink / raw)
To: adrian.hunter, ulf.hansson, bjorn.andersson, robh+dt
Cc: linux-mmc, linux-kernel, linux-arm-msm, devicetree,
Veerabhadrarao Badiganti, Asutosh Das, Vijay Viswanath,
Andy Gross
In-Reply-To: <1590074615-10787-1-git-send-email-vbadigan@codeaurora.org>
On qcom SD host controllers voltage switching be done after the HW
is ready for it. The HW informs its readiness through power irq.
The voltage switching should happen only then.
Use the internal voltage switching and then control the voltage
switching using power irq.
Set the regulator load as well so that regulator can be configured
in LPM mode when in is not being used.
Co-developed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Co-developed-by: Vijay Viswanath <vviswana@codeaurora.org>
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Co-developed-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
---
drivers/mmc/host/sdhci-msm.c | 207 +++++++++++++++++++++++++++++++++++++++++--
1 file changed, 198 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 97758fa..6211ab4 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -36,7 +36,9 @@
#define CORE_PWRCTL_IO_LOW BIT(2)
#define CORE_PWRCTL_IO_HIGH BIT(3)
#define CORE_PWRCTL_BUS_SUCCESS BIT(0)
+#define CORE_PWRCTL_BUS_FAIL BIT(1)
#define CORE_PWRCTL_IO_SUCCESS BIT(2)
+#define CORE_PWRCTL_IO_FAIL BIT(3)
#define REQ_BUS_OFF BIT(0)
#define REQ_BUS_ON BIT(1)
#define REQ_IO_LOW BIT(2)
@@ -263,6 +265,8 @@ struct sdhci_msm_host {
bool use_cdr;
u32 transfer_mode;
bool updated_ddr_cfg;
+ u32 vqmmc_load;
+ bool vqmmc_enabled;
};
static const struct sdhci_msm_offset *sdhci_priv_msm_offset(struct sdhci_host *host)
@@ -1298,6 +1302,71 @@ static void sdhci_msm_set_uhs_signaling(struct sdhci_host *host,
sdhci_msm_hs400(host, &mmc->ios);
}
+static int sdhci_msm_set_vmmc(struct mmc_host *mmc)
+{
+ int ret;
+
+ if (IS_ERR(mmc->supply.vmmc))
+ return 0;
+
+ ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, mmc->ios.vdd);
+ if (ret)
+ dev_err(mmc_dev(mmc), "%s: vmmc set ocr with vdd=%d failed: %d\n",
+ mmc_hostname(mmc), mmc->ios.vdd, ret);
+
+ return ret;
+}
+
+static int sdhci_msm_set_vqmmc(struct sdhci_msm_host *msm_host,
+ struct mmc_host *mmc, bool level)
+{
+ int load, ret;
+ struct mmc_ios ios;
+
+ if (IS_ERR(mmc->supply.vqmmc) ||
+ (mmc->ios.power_mode == MMC_POWER_UNDEFINED) ||
+ (msm_host->vqmmc_enabled == level))
+ return 0;
+
+ if (msm_host->vqmmc_load) {
+ load = level ? msm_host->vqmmc_load : 0;
+ ret = regulator_set_load(mmc->supply.vqmmc, load);
+ if (ret) {
+ dev_err(mmc_dev(mmc), "%s: vqmmc set load failed: %d\n",
+ mmc_hostname(mmc), ret);
+ goto out;
+ }
+ }
+
+ if (level) {
+ /* Set the IO voltage regulator to default voltage level */
+ if (msm_host->caps_0 & CORE_3_0V_SUPPORT)
+ ios.signal_voltage = MMC_SIGNAL_VOLTAGE_330;
+ else if (msm_host->caps_0 & CORE_1_8V_SUPPORT)
+ ios.signal_voltage = MMC_SIGNAL_VOLTAGE_180;
+
+ if (msm_host->caps_0 & CORE_VOLT_SUPPORT) {
+ ret = mmc_regulator_set_vqmmc(mmc, &ios);
+ if (ret < 0) {
+ dev_err(mmc_dev(mmc), "%s: vqmmc set volgate failed: %d\n",
+ mmc_hostname(mmc), ret);
+ goto out;
+ }
+ }
+ ret = regulator_enable(mmc->supply.vqmmc);
+ } else {
+ ret = regulator_disable(mmc->supply.vqmmc);
+ }
+
+ if (ret)
+ dev_err(mmc_dev(mmc), "%s: vqmm %sable failed: %d\n",
+ mmc_hostname(mmc), level ? "en":"dis", ret);
+ else
+ msm_host->vqmmc_enabled = level;
+out:
+ return ret;
+}
+
static inline void sdhci_msm_init_pwr_irq_wait(struct sdhci_msm_host *msm_host)
{
init_waitqueue_head(&msm_host->pwr_irq_wait);
@@ -1401,8 +1470,9 @@ static void sdhci_msm_handle_pwr_irq(struct sdhci_host *host, int irq)
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
+ struct mmc_host *mmc = host->mmc;
u32 irq_status, irq_ack = 0;
- int retry = 10;
+ int retry = 10, ret;
u32 pwr_state = 0, io_level = 0;
u32 config;
const struct sdhci_msm_offset *msm_offset = msm_host->offset;
@@ -1440,21 +1510,42 @@ static void sdhci_msm_handle_pwr_irq(struct sdhci_host *host, int irq)
if (irq_status & CORE_PWRCTL_BUS_ON) {
pwr_state = REQ_BUS_ON;
io_level = REQ_IO_HIGH;
- irq_ack |= CORE_PWRCTL_BUS_SUCCESS;
}
if (irq_status & CORE_PWRCTL_BUS_OFF) {
pwr_state = REQ_BUS_OFF;
io_level = REQ_IO_LOW;
- irq_ack |= CORE_PWRCTL_BUS_SUCCESS;
}
+
+ if (pwr_state) {
+ ret = sdhci_msm_set_vmmc(mmc);
+ if (!ret)
+ ret = sdhci_msm_set_vqmmc(msm_host, mmc,
+ pwr_state & REQ_BUS_ON);
+ if (!ret)
+ irq_ack |= CORE_PWRCTL_BUS_SUCCESS;
+ else
+ irq_ack |= CORE_PWRCTL_BUS_FAIL;
+ }
+
/* Handle IO LOW/HIGH */
- if (irq_status & CORE_PWRCTL_IO_LOW) {
+ if (irq_status & CORE_PWRCTL_IO_LOW)
io_level = REQ_IO_LOW;
- irq_ack |= CORE_PWRCTL_IO_SUCCESS;
- }
- if (irq_status & CORE_PWRCTL_IO_HIGH) {
+
+ if (irq_status & CORE_PWRCTL_IO_HIGH)
io_level = REQ_IO_HIGH;
+
+ if (io_level)
irq_ack |= CORE_PWRCTL_IO_SUCCESS;
+
+ if (io_level && !IS_ERR(mmc->supply.vqmmc) && !pwr_state) {
+ ret = mmc_regulator_set_vqmmc(mmc, &mmc->ios);
+ if (ret < 0) {
+ dev_err(mmc_dev(mmc), "%s: IO_level setting failed(%d). signal_voltage: %d, vdd: %d irq_status: 0x%08x\n",
+ mmc_hostname(mmc), ret,
+ mmc->ios.signal_voltage, mmc->ios.vdd,
+ irq_status);
+ irq_ack |= CORE_PWRCTL_IO_FAIL;
+ }
}
/*
@@ -1503,7 +1594,7 @@ static void sdhci_msm_handle_pwr_irq(struct sdhci_host *host, int irq)
if (io_level)
msm_host->curr_io_level = io_level;
- pr_debug("%s: %s: Handled IRQ(%d), irq_status=0x%x, ack=0x%x\n",
+ dev_dbg(mmc_dev(mmc), "%s: %s: Handled IRQ(%d), irq_status=0x%x, ack=0x%x\n",
mmc_hostname(msm_host->mmc), __func__, irq, irq_status,
irq_ack);
}
@@ -1833,6 +1924,98 @@ static void sdhci_msm_reset(struct sdhci_host *host, u8 mask)
sdhci_reset(host, mask);
}
+static int sdhci_msm_register_vreg(struct sdhci_msm_host *msm_host)
+{
+ int ret;
+ u32 vmmc_load;
+ struct mmc_host *mmc = msm_host->mmc;
+
+ ret = mmc_regulator_get_supply(msm_host->mmc);
+ if (ret)
+ return ret;
+ device_property_read_u32(&msm_host->pdev->dev,
+ "vmmc-max-load-microamp",
+ &vmmc_load);
+ device_property_read_u32(&msm_host->pdev->dev,
+ "vqmmc-max-load-microamp",
+ &msm_host->vqmmc_load);
+
+ /* Vmmc regulator can be turned off. So just set active load once */
+ if (!IS_ERR(mmc->supply.vmmc) && vmmc_load) {
+ ret = regulator_set_load(mmc->supply.vmmc, vmmc_load);
+ if (ret) {
+ dev_err(mmc_dev(mmc), "%s: vmmc set active load failed: %d\n",
+ mmc_hostname(mmc), ret);
+ return ret;
+ }
+ }
+
+ sdhci_msm_set_regulator_caps(msm_host);
+ mmc->ios.power_mode = MMC_POWER_UNDEFINED;
+
+ return 0;
+
+}
+
+static int sdhci_msm_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios)
+{
+ struct sdhci_host *host = mmc_priv(mmc);
+ u16 ctrl, status;
+
+ /*
+ * Signal Voltage Switching is only applicable for Host Controllers
+ * v3.00 and above.
+ */
+ if (host->version < SDHCI_SPEC_300)
+ return 0;
+
+ ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+
+ switch (ios->signal_voltage) {
+ case MMC_SIGNAL_VOLTAGE_330:
+ if (!(host->flags & SDHCI_SIGNALING_330))
+ return -EINVAL;
+
+ /* Set 1.8V Signal Enable in the Host Control2 register to 0 */
+ ctrl &= ~SDHCI_CTRL_VDD_180;
+ break;
+ case MMC_SIGNAL_VOLTAGE_180:
+ if (!(host->flags & SDHCI_SIGNALING_180))
+ return -EINVAL;
+
+ /*
+ * Enable 1.8V Signal Enable in the Host Control2
+ * register
+ */
+ ctrl |= SDHCI_CTRL_VDD_180;
+ break;
+ case MMC_SIGNAL_VOLTAGE_120:
+ if (!(host->flags & SDHCI_SIGNALING_120))
+ return -EINVAL;
+ return 0;
+ default:
+ /* No signal voltage switch required */
+ return 0;
+ }
+
+ sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
+
+ /* Wait for 5ms */
+ usleep_range(5000, 5500);
+
+ /* regulator output should be stable within 5 ms */
+ status = !!(ctrl & SDHCI_CTRL_VDD_180);
+ ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+ if (!!(ctrl & SDHCI_CTRL_VDD_180) == status)
+ return 0;
+
+ dev_warn(mmc_dev(mmc), "%s: Regulator output did not became stable\n",
+ mmc_hostname(mmc));
+
+ return -EAGAIN;
+}
+
static const struct sdhci_msm_variant_ops mci_var_ops = {
.msm_readl_relaxed = sdhci_msm_mci_variant_readl_relaxed,
.msm_writel_relaxed = sdhci_msm_mci_variant_writel_relaxed,
@@ -1880,6 +2063,7 @@ static void sdhci_msm_reset(struct sdhci_host *host, u8 mask)
.write_w = sdhci_msm_writew,
.write_b = sdhci_msm_writeb,
.irq = sdhci_msm_cqe_irq,
+ .set_power = sdhci_set_power_noreg,
};
static const struct sdhci_pltfm_data sdhci_msm_pdata = {
@@ -2072,6 +2256,10 @@ static int sdhci_msm_probe(struct platform_device *pdev)
if (core_major == 1 && core_minor >= 0x49)
msm_host->updated_ddr_cfg = true;
+ ret = sdhci_msm_register_vreg(msm_host);
+ if (ret)
+ goto clk_disable;
+
/*
* Power on reset state may trigger power irq if previous status of
* PWRCTL was either BUS_ON or IO_HIGH_V. So before enabling pwr irq
@@ -2116,6 +2304,8 @@ static int sdhci_msm_probe(struct platform_device *pdev)
MSM_MMC_AUTOSUSPEND_DELAY_MS);
pm_runtime_use_autosuspend(&pdev->dev);
+ host->mmc_host_ops.start_signal_voltage_switch =
+ sdhci_msm_start_signal_voltage_switch;
host->mmc_host_ops.execute_tuning = sdhci_msm_execute_tuning;
if (of_property_read_bool(node, "supports-cqe"))
ret = sdhci_msm_cqe_add_host(host, pdev);
@@ -2123,7 +2313,6 @@ static int sdhci_msm_probe(struct platform_device *pdev)
ret = sdhci_add_host(host);
if (ret)
goto pm_runtime_disable;
- sdhci_msm_set_regulator_caps(msm_host);
pm_runtime_mark_last_busy(&pdev->dev);
pm_runtime_put_autosuspend(&pdev->dev);
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH V2 3/3] mmc: sdhci: Allow platform controlled voltage switching
From: Veerabhadrarao Badiganti @ 2020-05-21 15:23 UTC (permalink / raw)
To: adrian.hunter, ulf.hansson, bjorn.andersson, robh+dt
Cc: linux-mmc, linux-kernel, linux-arm-msm, devicetree,
Vijay Viswanath, Veerabhadrarao Badiganti
In-Reply-To: <1590074615-10787-1-git-send-email-vbadigan@codeaurora.org>
From: Vijay Viswanath <vviswana@codeaurora.org>
If vendor platform drivers are controlling whole logic of voltage
switching, then sdhci driver no need control vqmmc regulator.
So skip enabling/disable vqmmc from SDHC driver.
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
---
drivers/mmc/host/sdhci.c | 32 +++++++++++++++++++-------------
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1bb6b67..88e5312 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -4098,6 +4098,7 @@ int sdhci_setup_host(struct sdhci_host *host)
unsigned int override_timeout_clk;
u32 max_clk;
int ret;
+ bool enable_vqmmc = false;
WARN_ON(host == NULL);
if (host == NULL)
@@ -4111,9 +4112,12 @@ int sdhci_setup_host(struct sdhci_host *host)
* the host can take the appropriate action if regulators are not
* available.
*/
- ret = mmc_regulator_get_supply(mmc);
- if (ret)
- return ret;
+ if (!mmc->supply.vqmmc) {
+ ret = mmc_regulator_get_supply(mmc);
+ if (ret)
+ return ret;
+ enable_vqmmc = true;
+ }
DBG("Version: 0x%08x | Present: 0x%08x\n",
sdhci_readw(host, SDHCI_HOST_VERSION),
@@ -4373,7 +4377,15 @@ int sdhci_setup_host(struct sdhci_host *host)
mmc->caps |= MMC_CAP_NEEDS_POLL;
if (!IS_ERR(mmc->supply.vqmmc)) {
- ret = regulator_enable(mmc->supply.vqmmc);
+ if (enable_vqmmc) {
+ ret = regulator_enable(mmc->supply.vqmmc);
+ if (ret) {
+ pr_warn("%s: Failed to enable vqmmc regulator: %d\n",
+ mmc_hostname(mmc), ret);
+ mmc->supply.vqmmc = ERR_PTR(-EINVAL);
+ }
+ host->sdhci_core_to_disable_vqmmc = !ret;
+ }
/* If vqmmc provides no 1.8V signalling, then there's no UHS */
if (!regulator_is_supported_voltage(mmc->supply.vqmmc, 1700000,
@@ -4386,12 +4398,6 @@ int sdhci_setup_host(struct sdhci_host *host)
if (!regulator_is_supported_voltage(mmc->supply.vqmmc, 2700000,
3600000))
host->flags &= ~SDHCI_SIGNALING_330;
-
- if (ret) {
- pr_warn("%s: Failed to enable vqmmc regulator: %d\n",
- mmc_hostname(mmc), ret);
- mmc->supply.vqmmc = ERR_PTR(-EINVAL);
- }
}
if (host->quirks2 & SDHCI_QUIRK2_NO_1_8_V) {
@@ -4625,7 +4631,7 @@ int sdhci_setup_host(struct sdhci_host *host)
return 0;
unreg:
- if (!IS_ERR(mmc->supply.vqmmc))
+ if (host->sdhci_core_to_disable_vqmmc)
regulator_disable(mmc->supply.vqmmc);
undma:
if (host->align_buffer)
@@ -4643,7 +4649,7 @@ void sdhci_cleanup_host(struct sdhci_host *host)
{
struct mmc_host *mmc = host->mmc;
- if (!IS_ERR(mmc->supply.vqmmc))
+ if (host->sdhci_core_to_disable_vqmmc)
regulator_disable(mmc->supply.vqmmc);
if (host->align_buffer)
@@ -4780,7 +4786,7 @@ void sdhci_remove_host(struct sdhci_host *host, int dead)
destroy_workqueue(host->complete_wq);
- if (!IS_ERR(mmc->supply.vqmmc))
+ if (host->sdhci_core_to_disable_vqmmc)
regulator_disable(mmc->supply.vqmmc);
if (host->align_buffer)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 8d2a096..c7dbc68 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -570,6 +570,7 @@ struct sdhci_host {
u32 caps1; /* CAPABILITY_1 */
bool read_caps; /* Capability flags have been read */
+ bool sdhci_core_to_disable_vqmmc; /* sdhci core can disable vqmmc */
unsigned int ocr_avail_sdio; /* OCR bit masks */
unsigned int ocr_avail_sd;
unsigned int ocr_avail_mmc;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: [PATCH v8 05/14] media: platform: Improve power on and power off flow
From: Tomasz Figa @ 2020-05-21 15:22 UTC (permalink / raw)
To: Xia Jiang
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: <20200403094033.8288-6-xia.jiang@mediatek.com>
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().
Best regards,
Tomasz
^ permalink raw reply
* [PATCH v2 0/2] Update K3 DSP remoteproc driver for C71x DSPs
From: Suman Anna @ 2020-05-21 15:16 UTC (permalink / raw)
To: Bjorn Andersson, Rob Herring, Mathieu Poirier
Cc: Lokesh Vutla, linux-remoteproc, devicetree, linux-arm-kernel,
linux-kernel, Suman Anna
Hi All,
This series is an updated version of the enhancements to the K3 DSP
remoteproc driver to support the 64-bit TI DSP called C71x. The series
is on top of the K3 DSP remoteproc driver v2 [1], and includes only
the platform driver portions. Please see the v1 cover-letter [2] for
a summary of supported features.
The 64-bit resource type enhancements (patches 2 and 3 from v1 [3][4])
can be reviewed and discussed separately. I can post the next versions
just for those based on any review comments on those.
Please see the individual patches for differences in v2.
regards
Suman
[1] https://patchwork.kernel.org/cover/11561787/
[2] https://patchwork.kernel.org/cover/11458599/
[3] https://patchwork.kernel.org/patch/11458593/
[4] https://patchwork.kernel.org/patch/11458589/
Suman Anna (2):
dt-bindings: remoteproc: k3-dsp: Update bindings for C71x DSPs
remoteproc/k3-dsp: Add support for C71x DSPs
.../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 76 +++++++++++++++++--
drivers/remoteproc/ti_k3_dsp_remoteproc.c | 20 ++++-
2 files changed, 86 insertions(+), 10 deletions(-)
--
2.26.0
^ permalink raw reply
* [PATCH v2 2/2] remoteproc/k3-dsp: Add support for C71x DSPs
From: Suman Anna @ 2020-05-21 15:16 UTC (permalink / raw)
To: Bjorn Andersson, Rob Herring, Mathieu Poirier
Cc: Lokesh Vutla, linux-remoteproc, devicetree, linux-arm-kernel,
linux-kernel, Suman Anna
In-Reply-To: <20200521151636.28260-1-s-anna@ti.com>
The Texas Instrument's K3 J721E SoCs have a newer next-generation
C71x DSP Subsystem in the MAIN voltage domain in addition to the
previous generation C66x DSP subsystems. The C71x DSP subsystem is
based on the TMS320C71x DSP CorePac module. The C71x CPU is a true
64-bit machine including 64-bit memory addressing and single-cycle
64-bit base arithmetic operations and supports vector signal processing
providing a significant lift in DSP processing power over C66x DSPs.
J721E SoCs use a C711 (a one-core 512-bit vector width CPU core) DSP
that is cache coherent with the A72 Arm cores.
Each subsystem has one or more Fixed/Floating-Point DSP CPUs, with 32 KB
of L1P Cache, 48 KB of L1D SRAM that can be configured and partitioned as
either RAM and/or Cache, and 512 KB of L2 SRAM configurable as either RAM
and/or Cache. The CorePac also includes a Matrix Multiplication Accelerator
(MMA), a Stream Engine (SE) and a C71x Memory Management Unit (CMMU), an
Interrupt Controller (INTC) and a Powerdown Management Unit (PMU) modules.
Update the existing K3 DSP remoteproc driver to add support for this C71x
DSP subsystem. The firmware loading support is provided by using the newly
added 64-bit ELF loader support, and is limited to images using only
external DDR memory at the moment. The L1D and L2 SRAMs are used as scratch
memory when using as RAMs, and cannot be used for loadable segments. The
CMMU is also not supported to begin with, and the driver is designed to
treat the MMU as if it is in bypass mode.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2:
- k3_dsp_rproc_prepare/unprepare plugged in dynamically based on local reset,
C71x doesn't use local resets
- Dropped the sanity_check ops override, not needed on latest codebase
v1: https://patchwork.kernel.org/patch/11458595/
drivers/remoteproc/ti_k3_dsp_remoteproc.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
index 610fbbf85ee6..2dbed316b6ac 100644
--- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
@@ -406,8 +406,6 @@ static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
}
static const struct rproc_ops k3_dsp_rproc_ops = {
- .prepare = k3_dsp_rproc_prepare,
- .unprepare = k3_dsp_rproc_unprepare,
.start = k3_dsp_rproc_start,
.stop = k3_dsp_rproc_stop,
.kick = k3_dsp_rproc_kick,
@@ -617,6 +615,10 @@ static int k3_dsp_rproc_probe(struct platform_device *pdev)
rproc->has_iommu = false;
rproc->recovery_disabled = true;
+ if (data->uses_lreset) {
+ rproc->ops->prepare = k3_dsp_rproc_prepare;
+ rproc->ops->unprepare = k3_dsp_rproc_unprepare;
+ }
kproc = rproc->priv;
kproc->rproc = rproc;
kproc->dev = dev;
@@ -744,6 +746,12 @@ static const struct k3_dsp_mem_data c66_mems[] = {
{ .name = "l1dram", .dev_addr = 0xf00000 },
};
+/* C71x cores only have a L1P Cache, there are no L1P SRAMs */
+static const struct k3_dsp_mem_data c71_mems[] = {
+ { .name = "l2sram", .dev_addr = 0x800000 },
+ { .name = "l1dram", .dev_addr = 0xe00000 },
+};
+
static const struct k3_dsp_dev_data c66_data = {
.mems = c66_mems,
.num_mems = ARRAY_SIZE(c66_mems),
@@ -751,8 +759,16 @@ static const struct k3_dsp_dev_data c66_data = {
.uses_lreset = true,
};
+static const struct k3_dsp_dev_data c71_data = {
+ .mems = c71_mems,
+ .num_mems = ARRAY_SIZE(c71_mems),
+ .boot_align_addr = SZ_2M,
+ .uses_lreset = false,
+};
+
static const struct of_device_id k3_dsp_of_match[] = {
{ .compatible = "ti,j721e-c66-dsp", .data = &c66_data, },
+ { .compatible = "ti,j721e-c71-dsp", .data = &c71_data, },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, k3_dsp_of_match);
--
2.26.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: remoteproc: k3-dsp: Update bindings for C71x DSPs
From: Suman Anna @ 2020-05-21 15:16 UTC (permalink / raw)
To: Bjorn Andersson, Rob Herring, Mathieu Poirier
Cc: Lokesh Vutla, linux-remoteproc, devicetree, linux-arm-kernel,
linux-kernel, Suman Anna, Rob Herring
In-Reply-To: <20200521151636.28260-1-s-anna@ti.com>
Some Texas Instruments K3 family of SoCs have one of more newer
generation TMS320C71x CorePac processor subsystem in addition to
the existing TMS320C66x CorePac processor subsystems. Update the
device tree bindings document for the C71x DSP devices.
The example is also updated to show the single C71 DSP present
on J721E SoCs.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
v2:
- Rebased patch, no changes to binding properties
- Example additions indented one level to right as part of rebase and
changes done in updated C66x bindings patch
- Added Rob's Reviewed-by
v1: https://patchwork.kernel.org/patch/11458601/
.../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 76 +++++++++++++++++--
1 file changed, 68 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
index cdf649655838..47642015c884 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
@@ -27,9 +27,12 @@ description: |
properties:
compatible:
- const: ti,j721e-c66-dsp
+ enum:
+ - ti,j721e-c66-dsp
+ - ti,j721e-c71-dsp
description:
Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
+ Use "ti,j721e-c71-dsp" for C71x DSPs on K3 J721E SoCs
reg:
description: |
@@ -37,18 +40,11 @@ properties:
Each entry should have the memory region's start address
and the size of the region, the representation matching
the parent node's '#address-cells' and '#size-cells' values.
- minItems: 3
- maxItems: 3
reg-names:
description: |
Should contain strings with the names of the specific internal
memory regions, and should be defined in this order
- maxItems: 3
- items:
- - const: l2sram
- - const: l1pram
- - const: l1dram
ti,sci:
$ref: /schemas/types.yaml#/definitions/phandle
@@ -121,6 +117,41 @@ properties:
should be defined as per the generic bindings in,
Documentation/devicetree/bindings/sram/sram.yaml
+if:
+ properties:
+ compatible:
+ enum:
+ - ti,j721e-c66-dsp
+then:
+ properties:
+ reg:
+ minItems: 3
+ maxItems: 3
+ reg-names:
+ minItems: 3
+ maxItems: 3
+ items:
+ - const: l2sram
+ - const: l1pram
+ - const: l1dram
+else:
+ if:
+ properties:
+ compatible:
+ enum:
+ - ti,j721e-c71-dsp
+ then:
+ properties:
+ reg:
+ minItems: 2
+ maxItems: 2
+ reg-names:
+ minItems: 2
+ maxItems: 2
+ items:
+ - const: l2sram
+ - const: l1dram
+
required:
- compatible
- reg
@@ -160,6 +191,18 @@ examples:
reg = <0x00 0xa6100000 0x00 0xf00000>;
no-map;
};
+
+ c71_0_dma_memory_region: c71-dma-memory@a8000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa8000000 0x00 0x100000>;
+ no-map;
+ };
+
+ c71_0_memory_region: c71-memory@a8100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa8100000 0x00 0xf00000>;
+ no-map;
+ };
};
cbass_main: bus@100000 {
@@ -167,6 +210,7 @@ examples:
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x00 0x00100000 0x00 0x00100000 0x00 0x00020000>, /* ctrl mmr */
+ <0x00 0x64800000 0x00 0x64800000 0x00 0x00800000>, /* C71_0 */
<0x4d 0x80800000 0x4d 0x80800000 0x00 0x00800000>, /* C66_0 */
<0x4d 0x81800000 0x4d 0x81800000 0x00 0x00800000>; /* C66_1 */
@@ -186,5 +230,21 @@ examples:
<&c66_0_memory_region>;
mboxes = <&mailbox0_cluster3 &mbox_c66_0>;
};
+
+ /* J721E C71_0 DSP node */
+ c71_0: dsp@64800000 {
+ compatible = "ti,j721e-c71-dsp";
+ reg = <0x00 0x64800000 0x00 0x00080000>,
+ <0x00 0x64e00000 0x00 0x0000c000>;
+ reg-names = "l2sram", "l1dram";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <15>;
+ ti,sci-proc-ids = <0x30 0xFF>;
+ resets = <&k3_reset 15 1>;
+ firmware-name = "j7-c71_0-fw";
+ memory-region = <&c71_0_dma_memory_region>,
+ <&c71_0_memory_region>;
+ mboxes = <&mailbox0_cluster4 &mbox_c71_0>;
+ };
};
};
--
2.26.0
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: spi: Add Baikal-T1 System Boot SPI Controller binding
From: Serge Semin @ 2020-05-21 15:11 UTC (permalink / raw)
To: Rob Herring
Cc: Serge Semin, Mark Brown, Ramil Zaripov, Alexey Malahov,
Thomas Bogendoerfer, Paul Burton, Ralf Baechle, John Garry,
Chuanhong Guo, Tomer Maimon, Lee Jones, Miquel Raynal,
Arnd Bergmann, open list:MIPS, linux-spi, devicetree,
linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqLLMh1LAvVXccyjLc4SqTAaPQ5LC7Nb6Q5ib8_3a0q6Ow@mail.gmail.com>
On Thu, May 21, 2020 at 08:57:10AM -0600, Rob Herring wrote:
> On Mon, May 18, 2020 at 3:27 PM Serge Semin
> <Sergey.Semin@baikalelectronics.ru> wrote:
> >
> > On Mon, May 18, 2020 at 09:26:59AM -0600, Rob Herring wrote:
> > > On Fri, May 08, 2020 at 12:36:20PM +0300, Serge Semin wrote:
> > > > Baikal-T1 Boot SPI is a part of the SoC System Controller and is
> > > > responsible for the system bootup from an external SPI flash. It's a DW
> > > > APB SSI-based SPI-controller with no interrupts, no DMA, with just one
> > > > native chip-select available and a single reference clock. Since Baikal-T1
> > > > SoC is normally booted up from an external SPI flash this SPI controller
> > > > in most of the cases is supposed to be connected to a single SPI-nor
> > > > flash. Additionally in order to provide a transparent from CPU point of
> > > > view initial code execution procedure the system designers created an IP
> > > > block which physically maps the SPI flash found at CS0 to a memory region.
> > > >
> > > > Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
> > > > Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
> > > > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > > > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > > > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > > > Cc: Paul Burton <paulburton@kernel.org>
> > > > Cc: Ralf Baechle <ralf@linux-mips.org>
> > > > Cc: John Garry <john.garry@huawei.com>
> > > > Cc: Chuanhong Guo <gch981213@gmail.com>
> > > > Cc: Tomer Maimon <tmaimon77@gmail.com>
> > > > Cc: Lee Jones <lee.jones@linaro.org>
> > > > Cc: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > Cc: Arnd Bergmann <arnd@arndb.de>
> > > > Cc: linux-mips@vger.kernel.org
> > > > Cc: linux-spi@vger.kernel.org
> > > > ---
> > > > .../bindings/spi/baikal,bt1-sys-ssi.yaml | 100 ++++++++++++++++++
> > > > 1 file changed, 100 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/spi/baikal,bt1-sys-ssi.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/spi/baikal,bt1-sys-ssi.yaml b/Documentation/devicetree/bindings/spi/baikal,bt1-sys-ssi.yaml
> > > > new file mode 100644
> > > > index 000000000000..d9d3257d78f4
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/spi/baikal,bt1-sys-ssi.yaml
> > > > @@ -0,0 +1,100 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/spi/baikal,bt1-sys-ssi.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Baikal-T1 System Boot SSI Controller
> > > > +
> > > > +description: |
> > > > + Baikal-T1 System Controller includes a Boot SPI Controller, which is
> > > > + responsible for loading chip bootup code from an external SPI flash. In order
> > > > + to do this transparently from CPU point of view there is a dedicated IP block
> > > > + mapping the 16MB flash to a dedicated MMIO range. The controller is based on
> > > > + the DW APB SSI IP-core but equipped with very limited resources: no IRQ,
> > > > + no DMA, a single native CS being necessarily connected to a 16MB SPI flash
> > > > + (otherwise the system won't bootup from the flash), internal Tx/Rx FIFO of
> > > > + just 8 bytes depth. Access to DW APB SSI controller registers is mutually
> > > > + exclusive from normal MMIO interface and from physically mapped SPI Flash
> > > > + memory. So either one or another way of using the controller functionality
> > > > + can be enabled at a time.
> > > > +
> > > > +maintainers:
> > > > + - Serge Semin <fancer.lancer@gmail.com>
> > > > +
> > > > +allOf:
> > > > + - $ref: spi-controller.yaml#
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + const: baikal,bt1-sys-ssi
> > > > +
> > > > + reg:
> > > > + items:
> > > > + - description: Baikal-T1 Boot Controller configuration registers
> > > > + - description: Physically mapped SPI flash ROM found at CS0
> > > > +
> > > > + reg-names:
> > > > + items:
> > > > + - const: config
> > > > + - const: map
> > > > +
> > > > + clocks:
> > > > + description: SPI Controller reference clock source
> > >
> > > Can drop this.
> >
> > Ok.
> >
> > >
> > > > + maxItems: 1
> > > > +
> > > > + clock-names:
> > > > + items:
> > > > + - const: ssi_clk
> > > > +
> > > > + num-cs:
> > > > + const: 1
> > > > +
> > > > +patternProperties:
> > > > + "^.*@[0-9a-f]+":
> > > > + type: object
> > > > + properties:
> > > > + reg:
> > > > + minimum: 0
> > > > + maximum: 0
> > > > +
> > > > + spi-rx-bus-width:
> > > > + const: 1
> > > > +
> > > > + spi-tx-bus-width:
> > > > + const: 1
> > >
> > > What's the point of these 2 properties if they aren't required?
> >
> > Yes, they are optional, but this is a constraint on the bus-width parameters.
> > DW APB SSI provides a single laned Tx and Rx.
>
> Are you just trying to keep someone from saying 'spi-tx-bus-width: 2'
> for example?
Right.
>
> You could also say 'spi-tx-bus-width: false' here to disallow the
> property. I guess the above is fine.
Ok. If it's fine I'll leave them as is then. Right?
What about the next question you've asked:
> >
> > > +
> > > +unevaluatedProperties: false
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - reg-names
> >
> > > + - "#address-cells"
> > > + - "#size-cells"
> >
> > These 2 are required by spi-controller.yaml, so you can drop here.
>
> Yes, "#address-cells" is required, but "#size-cells" isn't. Is this supposed to
> be like that?
As far as I can see in spi-controller.yaml, "#address-cells" is required, but
"#size-cells" isn't. Is this intentional?
-Sergey
>
> Rob
^ permalink raw reply
* Re: [RFC v1 2/3] drivers: nvmem: Add driver for QTI qfprom-efuse support
From: Doug Anderson @ 2020-05-21 15:10 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Ravi Kumar Bokka (Temp), Rob Herring, LKML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rajendra Nayak, Sai Prakash Ranjan, dhavalp, mturney, sparate,
c_rbokka, mkurumel
In-Reply-To: <99f07eaa-d072-f391-098e-e6f7a50a1960@linaro.org>
Hi,
On Thu, May 21, 2020 at 8:01 AM Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
>
> On 20/05/2020 23:48, Doug Anderson wrote:
> >> Is this only applicable for corrected address space?
> > I guess I was proposing a two dts-node / two drive approach here.
> >
> > dts node #1:just covers the memory range for accessing the FEC-corrected data
> > driver #1: read-only and reads the FEC-corrected data
> >
> > dts node #2: covers the memory range that's_not_ the FEC-corrected
> > memory range.
> > driver #2: read-write. reading reads uncorrected data
> >
> > Does that seem sane?
>
> I see your point but it does not make sense to have two node for same thing.
OK, so that sounds as if we want to go with the proposal where we
"deprecate the old driver and/or bindings and say that there really
should just be one node and one driver".
Would this be acceptable to you?
1. Officially mark the old bindings as deprecated.
2. Leave the old driver there to support the old deprecated bindings,
at least until everyone can be transferred over. There seem to be
quite a few existing users of "qcom,qfprom" and we're supposed to make
an attempt at keeping the old device trees working, at least for a
little while. Once everyone is transferred over we could decide to
delete the old driver.
3. We will have a totally new driver here.
4. A given device tree will _not_ be allowed to have both
"qcom,qfprom" specified and "qcom,SOC-qfprom" specified. ...and by
"qcom,SOC-qfprom" I mean that SOC should be replaced by the SoC name,
so "qcom,sc7180-qfprom" or "qcom,sdm845-qfprom". So once you switch
to the new node it replaces the old node.
> Isn't the raw address space reads used to for blowing and checking the
> fuses if they are blown correctly or not and software usage of these
> fuses should only be done from correct address space?
>
> the read interface to user should be always from corrected address space
> and write interface should be to raw address space.
Great. That sounds right to me. Presumably the driver could add some
sort of "debugfs" access to read the raw address space if needed.
-Doug
^ permalink raw reply
* Re: [PATCH v3 5/7] arm64: dts: mt8183: add usb and phy nodes
From: Matthias Brugger @ 2020-05-21 15:06 UTC (permalink / raw)
To: Chunfeng Yun, Greg Kroah-Hartman, Rob Herring
Cc: Mark Rutland, Mathias Nyman, linux-usb, devicetree,
linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <1567150854-30033-6-git-send-email-chunfeng.yun@mediatek.com>
On 30/08/2019 09:40, Chunfeng Yun wrote:
> Add USB related nodes for MT8183, set it as host mode by default.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> v2~v3: no changes
> ---
> arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 22 +++++++++
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 55 +++++++++++++++++++++
> 2 files changed, 77 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> index d8e555cbb5d3..142ff52f0f42 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> @@ -6,7 +6,9 @@
> */
>
> /dts-v1/;
> +#include <dt-bindings/gpio/gpio.h>
> #include "mt8183.dtsi"
> +#include "mt6358.dtsi"
mt6358.dtsi is accepted upstream now.
While the rest of the series implements wake up function, I understand that this
patch is independent and enables USB without wake up.
If so, let me know and I can take it now.
Regards,
Matthias
>
> / {
> model = "MediaTek MT8183 evaluation board";
> @@ -24,6 +26,16 @@
> chosen {
> stdout-path = "serial0:921600n8";
> };
> +
> + usb_vbus: regulator@0 {
> + compatible = "regulator-fixed";
> + regulator-name = "p0_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&pio 42 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + regulator-always-on;
> + };
> };
>
> &auxadc {
> @@ -135,6 +147,16 @@
>
> };
>
> +&ssusb {
> + vusb33-supply = <&mt6358_vusb_reg>;
> + dr_mode = "host";
> + status = "okay";
> +};
> +
> +&usb_host {
> + status = "okay";
> +};
> +
> &uart0 {
> status = "okay";
> };
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index c2749c4631bc..28da334237c6 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -8,6 +8,7 @@
> #include <dt-bindings/clock/mt8183-clk.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/phy/phy.h>
> #include "mt8183-pinfunc.h"
>
> / {
> @@ -372,6 +373,35 @@
> status = "disabled";
> };
>
> + ssusb: usb@11201000 {
> + compatible = "mediatek,mt8183-mtu3", "mediatek,mtu3";
> + reg = <0 0x11201000 0 0x2e00>,
> + <0 0x11203e00 0 0x0100>;
> + reg-names = "mac", "ippc";
> + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_LOW>;
> + phys = <&u2port0 PHY_TYPE_USB2>,
> + <&u3port0 PHY_TYPE_USB3>;
> + clocks = <&infracfg CLK_INFRA_UNIPRO_SCK>,
> + <&infracfg CLK_INFRA_USB>;
> + clock-names = "sys_ck", "ref_ck";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + status = "disabled";
> +
> + usb_host: xhci@11200000 {
> + compatible = "mediatek,mt8183-xhci",
> + "mediatek,mtk-xhci";
> + reg = <0 0x11200000 0 0x1000>;
> + reg-names = "mac";
> + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_UNIPRO_SCK>,
> + <&infracfg CLK_INFRA_USB>;
> + clock-names = "sys_ck", "ref_ck";
> + status = "disabled";
> + };
> + };
> +
> audiosys: syscon@11220000 {
> compatible = "mediatek,mt8183-audiosys", "syscon";
> reg = <0 0x11220000 0 0x1000>;
> @@ -384,6 +414,31 @@
> reg = <0 0x11f10000 0 0x1000>;
> };
>
> + u3phy: usb-phy@11f40000 {
> + compatible = "mediatek,mt8183-tphy",
> + "mediatek,generic-tphy-v2";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0 0x11f40000 0x1000>;
> + status = "okay";
> +
> + u2port0: usb-phy@0 {
> + reg = <0x0 0x700>;
> + clocks = <&clk26m>;
> + clock-names = "ref";
> + #phy-cells = <1>;
> + status = "okay";
> + };
> +
> + u3port0: usb-phy@0700 {
> + reg = <0x0700 0x900>;
> + clocks = <&clk26m>;
> + clock-names = "ref";
> + #phy-cells = <1>;
> + status = "okay";
> + };
> + };
> +
> mfgcfg: syscon@13000000 {
> compatible = "mediatek,mt8183-mfgcfg", "syscon";
> reg = <0 0x13000000 0 0x1000>;
>
^ permalink raw reply
* Re: [PATCH v4 4/7] clocksource: dw_apb_timer: Set clockevent any-possible-CPU mask
From: Serge Semin @ 2020-05-21 15:04 UTC (permalink / raw)
To: Thomas Gleixner, Thomas Bogendoerfer, Daniel Lezcano
Cc: Serge Semin, Alexey Malahov, Paul Burton, Ralf Baechle,
Alessandro Zummo, Alexandre Belloni, Arnd Bergmann, Rob Herring,
linux-mips, linux-rtc, devicetree, Allison Randal, afzal mohammed,
Kate Stewart, Greg Kroah-Hartman, Enrico Weigelt, Alexios Zavras,
linux-kernel
In-Reply-To: <20200521005321.12129-5-Sergey.Semin@baikalelectronics.ru>
Daniel,
On Thu, May 21, 2020 at 03:53:17AM +0300, Serge Semin wrote:
> Currently the DW APB Timer driver binds all clockevent timers to
> CPU #0. This isn't good for multiple reasons. First of all seeing
> the device is placed on APB bus (which makes it accessible from any
> CPU core), accessible over MMIO and having the DYNIRQ flag set we
> can be sure that manually binding the timer to any CPU just isn't
> correct. By doing so we just set an extra limitation on device usage.
> This also doesn't reflect the device actual capability, since by
> setting the IRQ affinity we can make it virtually local to any CPU.
> Secondly imagine if you had a real CPU-local timer with the same
> rating and the same CPU-affinity. In this case if DW APB timer was
> registered first, then due to the clockevent framework tick-timer
> selection procedure we'll end up with the real CPU-local timer being
> left unselected for clock-events tracking. But on most of the platforms
> (MIPS/ARM/etc) such timers are normally embedded into the CPU core and
> are accessible with much better performance then devices placed on APB.
> For instance in MIPS architectures there is r4k-timer, which is
> CPU-local, assigned with the same rating, and normally its
> clockevent device is registered after the platform-specific one.
>
> So in order to fix all of these issues lets set the DW APB clockevent
> timer cpumask to be 'cpu_possible_mask'. By doing so the clockevent
> framework would prefer to select the real CPU-local timer instead
> of DW APB one. Otherwise if there is no other than DW APB device for
> clockevents tracking then it will be selected.
Hm, seems to me it has been a mistake to remove the CPU affiliation for the
timers since x86 has got a specific use-case with assigning the timers to all
detected CPUs. Though for our needs we don't need this feature. I'll make the
affiliation optional then. Like this:
> dw_apb_clockevent_init(int cpu, const char *name, unsigned rating,
> void __iomem *base, int irq, unsigned long freq)
> {
> ...
> dw_ced->ced.cpumask = cpu < 0 ? cpu_possible_mask : cpumask_of(cpu);
> ...
> }
DW APB Timer OF-based devices won't make the timer affiliated to the CPU #0, but
to any possible CPU by passing -1 to the dw_apb_clockevent_init():
--- drivers/clocksource/dw_apb_timer_of.c
+++ drivers/clocksource/dw_apb_timer_of.c
- ced = dw_apb_clockevent_init(0, event_timer->name, 300, iobase, irq,
rate);
+ ced = dw_apb_clockevent_init(-1, event_timer->name, 300, iobase, irq,
rate);
What do you think?
-Sergey
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Paul Burton <paulburton@kernel.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Alessandro Zummo <a.zummo@towertech.it>
> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-mips@vger.kernel.org
> Cc: linux-rtc@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> ---
> drivers/clocksource/dw_apb_timer.c | 18 +++++++-----------
> drivers/clocksource/dw_apb_timer_of.c | 3 +--
> include/linux/dw_apb_timer.h | 2 +-
> 3 files changed, 9 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
> index b207a77b0831..8ebb43916423 100644
> --- a/drivers/clocksource/dw_apb_timer.c
> +++ b/drivers/clocksource/dw_apb_timer.c
> @@ -106,6 +106,7 @@ static irqreturn_t dw_apb_clockevent_irq(int irq, void *data)
> dw_ced->eoi(&dw_ced->timer);
>
> evt->event_handler(evt);
> +
> return IRQ_HANDLED;
> }
>
> @@ -123,8 +124,7 @@ static int apbt_shutdown(struct clock_event_device *evt)
> struct dw_apb_clock_event_device *dw_ced = ced_to_dw_apb_ced(evt);
> u32 ctrl;
>
> - pr_debug("%s CPU %d state=shutdown\n", __func__,
> - cpumask_first(evt->cpumask));
> + pr_debug("%s state=shutdown\n", __func__);
>
> ctrl = apbt_readl(&dw_ced->timer, APBTMR_N_CONTROL);
> ctrl &= ~APBTMR_CONTROL_ENABLE;
> @@ -137,8 +137,7 @@ static int apbt_set_oneshot(struct clock_event_device *evt)
> struct dw_apb_clock_event_device *dw_ced = ced_to_dw_apb_ced(evt);
> u32 ctrl;
>
> - pr_debug("%s CPU %d state=oneshot\n", __func__,
> - cpumask_first(evt->cpumask));
> + pr_debug("%s state=oneshot\n", __func__);
>
> ctrl = apbt_readl(&dw_ced->timer, APBTMR_N_CONTROL);
> /*
> @@ -170,8 +169,7 @@ static int apbt_set_periodic(struct clock_event_device *evt)
> unsigned long period = DIV_ROUND_UP(dw_ced->timer.freq, HZ);
> u32 ctrl;
>
> - pr_debug("%s CPU %d state=periodic\n", __func__,
> - cpumask_first(evt->cpumask));
> + pr_debug("%s state=periodic\n", __func__);
>
> ctrl = apbt_readl(&dw_ced->timer, APBTMR_N_CONTROL);
> ctrl |= APBTMR_CONTROL_MODE_PERIODIC;
> @@ -194,8 +192,7 @@ static int apbt_resume(struct clock_event_device *evt)
> {
> struct dw_apb_clock_event_device *dw_ced = ced_to_dw_apb_ced(evt);
>
> - pr_debug("%s CPU %d state=resume\n", __func__,
> - cpumask_first(evt->cpumask));
> + pr_debug("%s state=resume\n", __func__);
>
> apbt_enable_int(&dw_ced->timer);
> return 0;
> @@ -222,7 +219,6 @@ static int apbt_next_event(unsigned long delta,
> /**
> * dw_apb_clockevent_init() - use an APB timer as a clock_event_device
> *
> - * @cpu: The CPU the events will be targeted at.
> * @name: The name used for the timer and the IRQ for it.
> * @rating: The rating to give the timer.
> * @base: I/O base for the timer registers.
> @@ -237,7 +233,7 @@ static int apbt_next_event(unsigned long delta,
> * releasing the IRQ.
> */
> struct dw_apb_clock_event_device *
> -dw_apb_clockevent_init(int cpu, const char *name, unsigned rating,
> +dw_apb_clockevent_init(const char *name, unsigned int rating,
> void __iomem *base, int irq, unsigned long freq)
> {
> struct dw_apb_clock_event_device *dw_ced =
> @@ -257,7 +253,7 @@ dw_apb_clockevent_init(int cpu, const char *name, unsigned rating,
> dw_ced->ced.max_delta_ticks = 0x7fffffff;
> dw_ced->ced.min_delta_ns = clockevent_delta2ns(5000, &dw_ced->ced);
> dw_ced->ced.min_delta_ticks = 5000;
> - dw_ced->ced.cpumask = cpumask_of(cpu);
> + dw_ced->ced.cpumask = cpu_possible_mask;
> dw_ced->ced.features = CLOCK_EVT_FEAT_PERIODIC |
> CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_DYNIRQ;
> dw_ced->ced.set_state_shutdown = apbt_shutdown;
> diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
> index 8c28b127759f..0a2505b323d7 100644
> --- a/drivers/clocksource/dw_apb_timer_of.c
> +++ b/drivers/clocksource/dw_apb_timer_of.c
> @@ -73,8 +73,7 @@ static void __init add_clockevent(struct device_node *event_timer)
>
> timer_get_base_and_rate(event_timer, &iobase, &rate);
>
> - ced = dw_apb_clockevent_init(0, event_timer->name, 300, iobase, irq,
> - rate);
> + ced = dw_apb_clockevent_init(event_timer->name, 300, iobase, irq, rate);
> if (!ced)
> panic("Unable to initialise clockevent device");
>
> diff --git a/include/linux/dw_apb_timer.h b/include/linux/dw_apb_timer.h
> index 82ebf9223948..689022bc8d17 100644
> --- a/include/linux/dw_apb_timer.h
> +++ b/include/linux/dw_apb_timer.h
> @@ -39,7 +39,7 @@ void dw_apb_clockevent_resume(struct dw_apb_clock_event_device *dw_ced);
> void dw_apb_clockevent_stop(struct dw_apb_clock_event_device *dw_ced);
>
> struct dw_apb_clock_event_device *
> -dw_apb_clockevent_init(int cpu, const char *name, unsigned rating,
> +dw_apb_clockevent_init(const char *name, unsigned int rating,
> void __iomem *base, int irq, unsigned long freq);
> struct dw_apb_clocksource *
> dw_apb_clocksource_init(unsigned rating, const char *name, void __iomem *base,
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH 12/12] bus: fsl-mc: Add ACPI support for fsl-mc
From: Laurentiu Tudor @ 2020-05-21 15:03 UTC (permalink / raw)
To: Lorenzo Pieralisi, linux-arm-kernel
Cc: Diana Craciun, Makarand Pawagi, iommu, linux-acpi, devicetree,
linux-pci, Rob Herring, Rafael J. Wysocki, Joerg Roedel,
Hanjun Guo, Bjorn Helgaas, Sudeep Holla, Robin Murphy,
Catalin Marinas, Will Deacon, Marc Zyngier
In-Reply-To: <20200521130008.8266-13-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
On 5/21/2020 4:00 PM, Lorenzo Pieralisi wrote:
> From: Diana Craciun <diana.craciun@oss.nxp.com>
>
> Add ACPI support in the fsl-mc driver. Driver parses MC DSDT table to
> extract memory and other resources.
>
> Interrupt (GIC ITS) information is extracted from the MADT table
> by drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
>
> IORT table is parsed to configure DMA.
>
> Signed-off-by: Makarand Pawagi <makarand.pawagi@nxp.com>
> Signed-off-by: Diana Craciun <diana.craciun@oss.nxp.com>
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> ---
The author of this patch should be Makarand. I think I accidentaly broke
it when we exchanged the patches. Very sorry about it.
---
Best Regards, Laurentiu
> drivers/bus/fsl-mc/fsl-mc-bus.c | 73 +++++++++++++++-----
> drivers/bus/fsl-mc/fsl-mc-msi.c | 37 +++++-----
> drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 75 ++++++++++++++++++++-
> 3 files changed, 150 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index 824ff77bbe86..324d49d6df89 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -18,6 +18,8 @@
> #include <linux/bitops.h>
> #include <linux/msi.h>
> #include <linux/dma-mapping.h>
> +#include <linux/acpi.h>
> +#include <linux/iommu.h>
>
> #include "fsl-mc-private.h"
>
> @@ -38,6 +40,7 @@ struct fsl_mc {
> struct fsl_mc_device *root_mc_bus_dev;
> u8 num_translation_ranges;
> struct fsl_mc_addr_translation_range *translation_ranges;
> + void *fsl_mc_regs;
> };
>
> /**
> @@ -56,6 +59,10 @@ struct fsl_mc_addr_translation_range {
> phys_addr_t start_phys_addr;
> };
>
> +#define FSL_MC_FAPR 0x28
> +#define MC_FAPR_PL BIT(18)
> +#define MC_FAPR_BMT BIT(17)
> +
> /**
> * fsl_mc_bus_match - device to driver matching callback
> * @dev: the fsl-mc device to match against
> @@ -124,7 +131,10 @@ static int fsl_mc_dma_configure(struct device *dev)
> while (dev_is_fsl_mc(dma_dev))
> dma_dev = dma_dev->parent;
>
> - return of_dma_configure_id(dev, dma_dev->of_node, 0, &input_id);
> + if (dev_of_node(dma_dev))
> + return of_dma_configure_id(dev, dma_dev->of_node, 0, &input_id);
> +
> + return acpi_dma_configure_id(dev, DEV_DMA_COHERENT, &input_id);
> }
>
> static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
> @@ -865,8 +875,11 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
> struct fsl_mc_io *mc_io = NULL;
> int container_id;
> phys_addr_t mc_portal_phys_addr;
> - u32 mc_portal_size;
> - struct resource res;
> + u32 mc_portal_size, mc_stream_id;
> + struct resource *plat_res;
> +
> + if (!iommu_present(&fsl_mc_bus_type))
> + return -EPROBE_DEFER;
>
> mc = devm_kzalloc(&pdev->dev, sizeof(*mc), GFP_KERNEL);
> if (!mc)
> @@ -874,19 +887,33 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, mc);
>
> + plat_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + mc->fsl_mc_regs = devm_ioremap_resource(&pdev->dev, plat_res);
> + if (IS_ERR(mc->fsl_mc_regs))
> + return PTR_ERR(mc->fsl_mc_regs);
> +
> + if (IS_ENABLED(CONFIG_ACPI) && !dev_of_node(&pdev->dev)) {
> + mc_stream_id = readl(mc->fsl_mc_regs + FSL_MC_FAPR);
> + /*
> + * HW ORs the PL and BMT bit, places the result in bit 15 of
> + * the StreamID and ORs in the ICID. Calculate it accordingly.
> + */
> + mc_stream_id = (mc_stream_id & 0xffff) |
> + ((mc_stream_id & (MC_FAPR_PL | MC_FAPR_BMT)) ?
> + 0x4000 : 0);
> + error = acpi_dma_configure_id(&pdev->dev, DEV_DMA_COHERENT,
> + &mc_stream_id);
> + if (error)
> + dev_warn(&pdev->dev, "failed to configure dma: %d.\n",
> + error);
> + }
> +
> /*
> * Get physical address of MC portal for the root DPRC:
> */
> - error = of_address_to_resource(pdev->dev.of_node, 0, &res);
> - if (error < 0) {
> - dev_err(&pdev->dev,
> - "of_address_to_resource() failed for %pOF\n",
> - pdev->dev.of_node);
> - return error;
> - }
> -
> - mc_portal_phys_addr = res.start;
> - mc_portal_size = resource_size(&res);
> + plat_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + mc_portal_phys_addr = plat_res->start;
> + mc_portal_size = resource_size(plat_res);
> error = fsl_create_mc_io(&pdev->dev, mc_portal_phys_addr,
> mc_portal_size, NULL,
> FSL_MC_IO_ATOMIC_CONTEXT_PORTAL, &mc_io);
> @@ -903,11 +930,13 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
> dev_info(&pdev->dev, "MC firmware version: %u.%u.%u\n",
> mc_version.major, mc_version.minor, mc_version.revision);
>
> - error = get_mc_addr_translation_ranges(&pdev->dev,
> - &mc->translation_ranges,
> - &mc->num_translation_ranges);
> - if (error < 0)
> - goto error_cleanup_mc_io;
> + if (dev_of_node(&pdev->dev)) {
> + error = get_mc_addr_translation_ranges(&pdev->dev,
> + &mc->translation_ranges,
> + &mc->num_translation_ranges);
> + if (error < 0)
> + goto error_cleanup_mc_io;
> + }
>
> error = dprc_get_container_id(mc_io, 0, &container_id);
> if (error < 0) {
> @@ -934,6 +963,7 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
> goto error_cleanup_mc_io;
>
> mc->root_mc_bus_dev = mc_bus_dev;
> + mc_bus_dev->dev.fwnode = pdev->dev.fwnode;
> return 0;
>
> error_cleanup_mc_io:
> @@ -967,11 +997,18 @@ static const struct of_device_id fsl_mc_bus_match_table[] = {
>
> MODULE_DEVICE_TABLE(of, fsl_mc_bus_match_table);
>
> +static const struct acpi_device_id fsl_mc_bus_acpi_match_table[] = {
> + {"NXP0008", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, fsl_mc_bus_acpi_match_table);
> +
> static struct platform_driver fsl_mc_bus_driver = {
> .driver = {
> .name = "fsl_mc_bus",
> .pm = NULL,
> .of_match_table = fsl_mc_bus_match_table,
> + .acpi_match_table = fsl_mc_bus_acpi_match_table,
> },
> .probe = fsl_mc_bus_probe,
> .remove = fsl_mc_bus_remove,
> diff --git a/drivers/bus/fsl-mc/fsl-mc-msi.c b/drivers/bus/fsl-mc/fsl-mc-msi.c
> index e7bbff445a83..8edadf05cbb7 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-msi.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-msi.c
> @@ -13,6 +13,7 @@
> #include <linux/irq.h>
> #include <linux/irqdomain.h>
> #include <linux/msi.h>
> +#include <linux/acpi_iort.h>
>
> #include "fsl-mc-private.h"
>
> @@ -179,25 +180,31 @@ struct irq_domain *fsl_mc_msi_create_irq_domain(struct fwnode_handle *fwnode,
>
> struct irq_domain *fsl_mc_find_msi_domain(struct device *dev)
> {
> - struct irq_domain *msi_domain = NULL;
> + struct device *root_dprc_dev;
> + struct device *bus_dev;
> + struct irq_domain *msi_domain;
> struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
>
> - msi_domain = of_msi_map_get_device_domain(dev, mc_dev->icid,
> + fsl_mc_get_root_dprc(dev, &root_dprc_dev);
> + bus_dev = root_dprc_dev->parent;
> +
> + if (bus_dev->of_node) {
> + msi_domain = of_msi_map_get_device_domain(dev,
> + mc_dev->icid,
> DOMAIN_BUS_FSL_MC_MSI);
>
> - /*
> - * if the msi-map property is missing assume that all the
> - * child containers inherit the domain from the parent
> - */
> - if (!msi_domain) {
> - struct device *root_dprc_dev;
> - struct device *bus_dev;
> -
> - fsl_mc_get_root_dprc(dev, &root_dprc_dev);
> - bus_dev = root_dprc_dev->parent;
> - msi_domain = of_msi_get_domain(bus_dev,
> - bus_dev->of_node,
> - DOMAIN_BUS_FSL_MC_MSI);
> + /*
> + * if the msi-map property is missing assume that all the
> + * child containers inherit the domain from the parent
> + */
> + if (!msi_domain)
> +
> + msi_domain = of_msi_get_domain(bus_dev,
> + bus_dev->of_node,
> + DOMAIN_BUS_FSL_MC_MSI);
> + } else {
> + msi_domain = iort_get_device_domain(dev, mc_dev->icid,
> + DOMAIN_BUS_FSL_MC_MSI);
> }
>
> return msi_domain;
> diff --git a/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c b/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
> index a5c8d577e424..b8b948fb6b2d 100644
> --- a/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
> @@ -7,6 +7,8 @@
> *
> */
>
> +#include <linux/acpi.h>
> +#include <linux/acpi_iort.h>
> #include <linux/of_device.h>
> #include <linux/of_address.h>
> #include <linux/irq.h>
> @@ -30,7 +32,8 @@ static u32 fsl_mc_msi_domain_get_msi_id(struct irq_domain *domain,
> u32 out_id;
>
> of_node = irq_domain_get_of_node(domain);
> - out_id = of_msi_map_id(&mc_dev->dev, of_node, mc_dev->icid);
> + out_id = of_node ? of_msi_map_id(&mc_dev->dev, of_node, mc_dev->icid) :
> + iort_msi_map_id(&mc_dev->dev, mc_dev->icid);
>
> return out_id;
> }
> @@ -79,7 +82,67 @@ static const struct of_device_id its_device_id[] = {
> {},
> };
>
> -static int __init its_fsl_mc_msi_init(void)
> +static int __init its_fsl_mc_msi_init_one(struct fwnode_handle *handle,
> + const char *name)
> +{
> + struct irq_domain *parent;
> + struct irq_domain *mc_msi_domain;
> +
> + parent = irq_find_matching_fwnode(handle, DOMAIN_BUS_NEXUS);
> + if (!parent || !msi_get_domain_info(parent)) {
> + pr_err("%s: Unable to locate ITS domain\n", name);
> + return -ENXIO;
> + }
> +
> + mc_msi_domain = fsl_mc_msi_create_irq_domain(handle,
> + &its_fsl_mc_msi_domain_info,
> + parent);
> + if (!mc_msi_domain)
> + pr_err("ACPIF: unable to create fsl-mc domain\n");
> +
> + pr_info("fsl-mc MSI: domain created\n");
> +
> + return 0;
> +}
> +
> +static int __init
> +its_fsl_mc_msi_parse_madt(union acpi_subtable_headers *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_translator *its_entry;
> + struct fwnode_handle *dom_handle;
> + const char *node_name;
> + int err = -ENXIO;
> +
> + its_entry = (struct acpi_madt_generic_translator *)header;
> + node_name = kasprintf(GFP_KERNEL, "ITS@0x%lx",
> + (long)its_entry->base_address);
> +
> + dom_handle = iort_find_domain_token(its_entry->translation_id);
> + if (!dom_handle) {
> + pr_err("%s: Unable to locate ITS domain handle\n", node_name);
> + goto out;
> + }
> +
> + err = its_fsl_mc_msi_init_one(dom_handle, node_name);
> + if (!err)
> + pr_info("fsl-mc MSI: %s domain created\n", node_name);
> +
> +out:
> + kfree(node_name);
> + return err;
> +}
> +
> +
> +static int __init its_fsl_mc_acpi_msi_init(void)
> +{
> + acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
> + its_fsl_mc_msi_parse_madt, 0);
> +
> + return 0;
> +}
> +
> +static int __init its_fsl_mc_of_msi_init(void)
> {
> struct device_node *np;
> struct irq_domain *parent;
> @@ -113,4 +176,12 @@ static int __init its_fsl_mc_msi_init(void)
> return 0;
> }
>
> +static int __init its_fsl_mc_msi_init(void)
> +{
> + its_fsl_mc_of_msi_init();
> + its_fsl_mc_acpi_msi_init();
> +
> + return 0;
> +}
> +
> early_initcall(its_fsl_mc_msi_init);
>
^ 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