* Re: [PATCH v3 03/16] spi: dw: Discard static DW DMA slave structures
From: Serge Semin @ 2020-05-21 15:58 UTC (permalink / raw)
To: Mark Brown
Cc: Serge Semin, Andy Shevchenko, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Thomas Bogendoerfer, Paul Burton, Ralf Baechle,
Andy Shevchenko, Arnd Bergmann, Rob Herring, linux-mips,
devicetree, Thomas Gleixner, Wan Ahmad Zainie, Jarkko Nikula,
Clement Leger, linux-spi, Linux Kernel Mailing List
In-Reply-To: <20200521155143.GE4770@sirena.org.uk>
On Thu, May 21, 2020 at 04:51:43PM +0100, Mark Brown wrote:
> On Thu, May 21, 2020 at 03:12:28PM +0300, Serge Semin wrote:
>
> > Well, for me both solutions are equal except mine consumes less stack memory.
> > The only reason why your solution might be better is that if DW DMA driver or
> > the DMA engine subsystem changed the dw_dma_slave structure instance passed to
> > the dma_request_channel() method, which non of them do. So I'll leave this for
> > Mark to decide. Mark, could you give us your final word about this?
>
> Honestly I'm struggling to care either way. I guess saving a bit of
> stack is potentially useful.
Settled then. Let's leave the patch as is. I suppose we've finally finished a
review except a question Feng asked to the patch:
[PATCH v3 01/16] spi: dw: Add Tx/Rx finish wait methods to the MID DMA
If you are ok with my responses, then the patchset is ready for you further
actions.
-Sergey
^ permalink raw reply
* Re: [PATCH 0/4] Update K3 DSP remoteproc driver for C71x DSPs
From: Suman Anna @ 2020-05-21 15:57 UTC (permalink / raw)
To: Bjorn Andersson, Rob Herring, Mathieu Poirier
Cc: Clement Leger, Loic Pallardy, Arnaud Pouliquen, Lokesh Vutla,
linux-remoteproc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20200325204701.16862-1-s-anna@ti.com>
On 3/25/20 3:46 PM, Suman Anna wrote:
> Hi All,
>
> This series adds support for a new next generation 64-bit TI DSP based on
> the TMS320C71x CorePac processor subsystem called the C71x. The support is
> enabled through couple of enhancements to the remoteproc core (primarily to
> support a 64-bit trace resource entry), and does depend on the K3 DSP
> remoteproc driver posted earlier today [1].
>
> The loading support leveraged the 64-bit ELF loader support code added by
> Clement and already staged on the rproc-next branch. I am posting this
> series separate from the C66x series because of the new 64-bit resource
> type enhancement needs (patches 2 and 3). I have leveraged the existing
> resource types as is by introducing a new version element, and am open to
> ideas if it is desired to just define it as a separate resource type.
>
> The C71x DSP boots using firmware segments loaded into the DDR with a 2 MB
> aligned address requirement on the boot vectors. There is no support for
> internal memory loading, and all internal memories shall be used as fast
> RAMs/scatchpads by the firmware executing on the DSPs. IPC is through the
> virtio-rpmsg transport. There is no support for Error Recovery, Power
> Management or loading into on-chip SRAMs at present.
>
> Following is the patch summary:
> - Patch 1 updates the K3 DSP bindings for C71x cores
> - Patch 2 introduces a concept of version element into existing resource types
> - Patch 3 adds support for a new 64-bit trace resource entry
> - Patch 4 enhances the K3 DSP remoteproc driver for C71x
I have separated out the C71 platform driver pieces (patches 1 & 4) and
posted a v2 for those.
Appreciate any feedback on the core patches (patches 2 & 3) that add the
minimal 64-bit trace support, as this also sets the direction for
resource extensions. I can post the next version for those based on
feedback.
regards
Suman
>
> regards
> Suman
>
> [1] https://patchwork.kernel.org/cover/11458573/
>
> Suman Anna (4):
> dt-bindings: remoteproc: k3-dsp: Update bindings for C71x DSPs
> remoteproc: introduce version element into resource type field
> remoteproc: add support for a new 64-bit trace version
> remoteproc/k3-dsp: Add support for C71x DSPs
>
> .../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 78 ++++++++++++++++---
> drivers/remoteproc/remoteproc_core.c | 65 +++++++++++-----
> drivers/remoteproc/remoteproc_debugfs.c | 50 ++++++++----
> drivers/remoteproc/ti_k3_dsp_remoteproc.c | 17 ++++
> include/linux/remoteproc.h | 34 +++++++-
> 5 files changed, 203 insertions(+), 41 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v3 03/16] spi: dw: Discard static DW DMA slave structures
From: Andy Shevchenko @ 2020-05-21 15:56 UTC (permalink / raw)
To: Mark Brown
Cc: Serge Semin, Serge Semin, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Thomas Bogendoerfer, Paul Burton, Ralf Baechle,
Andy Shevchenko, Arnd Bergmann, Rob Herring, linux-mips,
devicetree, Thomas Gleixner, Wan Ahmad Zainie, Jarkko Nikula,
Clement Leger, linux-spi, Linux Kernel Mailing List
In-Reply-To: <20200521155143.GE4770@sirena.org.uk>
On Thu, May 21, 2020 at 6:51 PM Mark Brown <broonie@kernel.org> wrote:
> On Thu, May 21, 2020 at 03:12:28PM +0300, Serge Semin wrote:
>
> > Well, for me both solutions are equal except mine consumes less stack memory.
> > The only reason why your solution might be better is that if DW DMA driver or
> > the DMA engine subsystem changed the dw_dma_slave structure instance passed to
> > the dma_request_channel() method, which non of them do. So I'll leave this for
> > Mark to decide. Mark, could you give us your final word about this?
>
> Honestly I'm struggling to care either way. I guess saving a bit of
> stack is potentially useful.
Yes, but OTOH dropping maintainability by this is worse in my opinion.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [RFC v1 2/3] drivers: nvmem: Add driver for QTI qfprom-efuse support
From: Srinivas Kandagatla @ 2020-05-21 15:55 UTC (permalink / raw)
To: Doug Anderson
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: <CAD=FV=W+UES1f3reMhvPPUho5FbaZXdU-2jkRaPcbBEzDWT+WQ@mail.gmail.com>
On 21/05/2020 16:10, Doug Anderson 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.
Possibly Yes for some reasons below!
>
> 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.
we could consider "qcom,qfrom" to be only passing corrected address
space. Till we transition users to new bindings!
>
Yes.
> 3. We will have a totally new driver here.
No, we should still be using the same driver. But the exiting driver
seems to incorrect and is need of fixing.
Having a look at the memory map for old SoCs like msm8996 and msm8916
shows that memory map that was passed to qfprom driver is corrected
address space. Writes will not obviously work!
This should also be true with sdm845 or sc7180
That needs to be fixed first!
>
> 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.
Secondly, this IP is clearly an integral part of Secure Control Block,
which clearly has versioning information.
Versioning information should be part of compatible string in msm8996 it
should be "qcom,qfprom-5.1.0"
for msm8916 it should be "qcom,qfprom-4.0.0" this translates to
"qcom,qfprom-<MAJOR-NUMBER>-<MINOR-NUMBER>-<STEP>"
Thirdly we should be able to have common read for all these as they tend
to just read from corrected address space.
Offsets to corrected address space seems to always constant across SoCs too.
platform specific device tree nodes should also be able to specify
"read-only" property to not allow writes on to this raw area.
Does this make sense ?
Thanks,
srini
>
>
>> 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.
^ permalink raw reply
* Re: [PATCHv3 2/2] dt-bindings: arm: coresight: Add support to skip trace unit power up
From: Mathieu Poirier @ 2020-05-21 15:53 UTC (permalink / raw)
To: Sai Prakash Ranjan
Cc: Suzuki K Poulose, Mike Leach, devicetree, Rob Herring,
Stephen Boyd, Leo Yan, linux-arm-kernel,
Linux Kernel Mailing List, linux-arm-msm, Tingwei Zhang,
Coresight ML
In-Reply-To: <7b69c9752713ce22f04688e83ec78f8aa67c63dc.1589558615.git.saiprakash.ranjan@codeaurora.org>
On Fri, 15 May 2020 at 10:23, Sai Prakash Ranjan
<saiprakash.ranjan@codeaurora.org> wrote:
>
> From: Tingwei Zhang <tingwei@codeaurora.org>
>
> Add "qcom,skip-power-up" property to identify systems which can
> skip powering up of trace unit since they share the same power
> domain as their CPU core. This is required to identify such
> systems with hardware errata which stops the CPU watchdog counter
> when the power up bit is set (TRCPDCR.PU).
>
> Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
> Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> ---
> Documentation/devicetree/bindings/arm/coresight.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
> index 846f6daae71b..e4b2eda0b53b 100644
> --- a/Documentation/devicetree/bindings/arm/coresight.txt
> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> @@ -108,6 +108,13 @@ its hardware characteristcs.
> * arm,cp14: must be present if the system accesses ETM/PTM management
> registers via co-processor 14.
>
> + * qcom,skip-power-up: boolean. Indicates that an implementation can
> + skip powering up the trace unit. TRCPDCR.PU does not have to be set
> + on Qualcomm Technologies Inc. systems since ETMs are in the same power
> + domain as their CPU cores. This property is required to identify such
> + systems with hardware errata where the CPU watchdog counter is stopped
> + when TRCPDCR.PU is set.
> +
> * Optional property for TMC:
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> * arm,buffer-size: size of contiguous buffer space for TMC ETR
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH v3 03/16] spi: dw: Discard static DW DMA slave structures
From: Mark Brown @ 2020-05-21 15:51 UTC (permalink / raw)
To: Serge Semin
Cc: Andy Shevchenko, Serge Semin, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Thomas Bogendoerfer, Paul Burton, Ralf Baechle,
Andy Shevchenko, Arnd Bergmann, Rob Herring, linux-mips,
devicetree, Thomas Gleixner, Wan Ahmad Zainie, Jarkko Nikula,
Clement Leger, linux-spi, Linux Kernel Mailing List
In-Reply-To: <20200521121228.aqplh6eftylnys3p@mobilestation>
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
On Thu, May 21, 2020 at 03:12:28PM +0300, Serge Semin wrote:
> Well, for me both solutions are equal except mine consumes less stack memory.
> The only reason why your solution might be better is that if DW DMA driver or
> the DMA engine subsystem changed the dw_dma_slave structure instance passed to
> the dma_request_channel() method, which non of them do. So I'll leave this for
> Mark to decide. Mark, could you give us your final word about this?
Honestly I'm struggling to care either way. I guess saving a bit of
stack is potentially useful.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* 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
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