* [PATCH v4 01/11] acpi: thermal: Fix error handling in the register function
From: Andrzej Pietrasiewicz @ 2020-05-28 19:20 UTC (permalink / raw)
To: linux-pm, linux-acpi, netdev, linux-wireless, platform-driver-x86,
linux-arm-kernel, linux-renesas-soc, linux-rockchip
Cc: Emmanuel Grumbach, Heiko Stuebner, Rafael J . Wysocki,
Vishal Kulkarni, Luca Coelho, Miquel Raynal, kernel,
Fabio Estevam, Amit Kucheria, Chunyan Zhang, Daniel Lezcano,
Allison Randal, NXP Linux Team, Darren Hart, Zhang Rui,
Gayatri Kammela, Len Brown, Johannes Berg, Intel Linux Wireless,
Sascha Hauer, Ido Schimmel, Baolin Wang, Jiri Pirko, Orson Zhai,
Thomas Gleixner, Kalle Valo, Support Opensource, Enrico Weigelt,
Peter Kaestle, Sebastian Reichel, Andrzej Pietrasiewicz,
Bartlomiej Zolnierkiewicz, Pengutronix Kernel Team,
Niklas Söderlund, Shawn Guo, David S . Miller,
Andy Shevchenko
In-Reply-To: <20200528192051.28034-1-andrzej.p@collabora.com>
The acpi_thermal_register_thermal_zone() is missing any error handling.
This needs to be fixed.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
---
drivers/acpi/thermal.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 19067a5e5293..6de8066ca1e7 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -901,23 +901,35 @@ static int acpi_thermal_register_thermal_zone(struct acpi_thermal *tz)
result = sysfs_create_link(&tz->device->dev.kobj,
&tz->thermal_zone->device.kobj, "thermal_zone");
if (result)
- return result;
+ goto unregister_tzd;
result = sysfs_create_link(&tz->thermal_zone->device.kobj,
&tz->device->dev.kobj, "device");
if (result)
- return result;
+ goto remove_tz_link;
status = acpi_bus_attach_private_data(tz->device->handle,
tz->thermal_zone);
- if (ACPI_FAILURE(status))
- return -ENODEV;
+ if (ACPI_FAILURE(status)) {
+ result = -ENODEV;
+ goto remove_dev_link;
+ }
tz->tz_enabled = 1;
dev_info(&tz->device->dev, "registered as thermal_zone%d\n",
tz->thermal_zone->id);
+
return 0;
+
+remove_dev_link:
+ sysfs_remove_link(&tz->thermal_zone->device.kobj, "device");
+remove_tz_link:
+ sysfs_remove_link(&tz->device->dev.kobj, "thermal_zone");
+unregister_tzd:
+ thermal_zone_device_unregister(tz->thermal_zone);
+
+ return result;
}
static void acpi_thermal_unregister_thermal_zone(struct acpi_thermal *tz)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Rob Herring @ 2020-05-28 19:20 UTC (permalink / raw)
To: Viresh Kumar
Cc: devicetree, Arnd Bergmann, Jassi Brar, linux-kernel,
Bjorn Andersson, Sudeep Holla, Frank Rowand, linux-arm-kernel
In-Reply-To: <0a50f0cf5593baeb628dc8606c523665e5e2ae6c.1589519600.git.viresh.kumar@linaro.org>
On Fri, May 15, 2020 at 10:47:38AM +0530, Viresh Kumar wrote:
> From: Sudeep Holla <sudeep.holla@arm.com>
>
> Hi Rob, Arnd and Jassi,
>
> This stuff has been doing rounds on the mailing list since several years
> now with no agreed conclusion by all the parties. And here is another
> attempt to get some feedback from everyone involved to close this once
> and for ever. Your comments will very much be appreciated.
>
> The ARM MHU is defined here in the TRM [1] for your reference, which
> states following:
>
> "The MHU drives the signal using a 32-bit register, with all 32
> bits logically ORed together. The MHU provides a set of
> registers to enable software to set, clear, and check the status
> of each of the bits of this register independently. The use of
> 32 bits for each interrupt line enables software to provide more
> information about the source of the interrupt. For example, each
> bit of the register can be associated with a type of event that
> can contribute to raising the interrupt."
>
> On few other platforms, like qcom, similar doorbell mechanism is present
> with separate interrupt for each of the bits (that's how I understood
> it), while in case of ARM MHU, there is a single interrupt line for all
> the 32 bits. Also in case of ARM MHU, these registers and interrupts
> have 3 copies for different priority levels, i.e. low priority
> non-secure, high priority non-secure and secure channels.
>
> For ARM MHU, both the dt bindings and the Linux driver support 3
> channels for the different priorities right now and support sending a 32
> bit data on every transfer in a locked fashion, i.e. only one transfer
> can be done at once and the other have to wait for it to finish first.
>
> Here are the point of view of the parties involved on this subject:
>
> Jassi's viewpoint:
>
> - Virtualization of channels should be discouraged in software based on
> specific usecases of the application. This may invite other mailbox
> driver authors to ask for doing virtualization in their drivers.
>
> - In mailbox's terminology, every channel is equivalent to a signal,
> since there is only one signal generated here by the MHU, there should
> be only one channel per priority level.
>
> - The clients should send data (of just setting 1 bit or many in the 32
> bit word) using the existing mechanism as the delays due to
> serialization shouldn't be significant anyway.
>
> - The driver supports 90% of the users with the current implementation
> and it shouldn't be extended to support doorbell and implement two
> different modes by changing value of #mbox-cells field in bindings.
>
> Sudeep (ARM) and myself as well to some extent:
>
> - The hardware gives us the capability to write the register in
> parallel, i.e. we can write 0x800 and 0x400 together without any
> software locks, and so these 32 bits should be considered as separate
> channel even if only one interrupt is issued by the hardware finally.
> This shouldn't be called as virtualization of the channels, as the
> hardware supports this (as clearly mentioned in the TRM) and it takes
> care of handling the signal properly.
>
> - With serialization, if we use only one channel as today at every
> priority, if there are 5 requests to send signal to the receiver and
> the dvfs request is the last one in queue (which may be called from
> scheduler's hot path with fast switching), it unnecessarily needs to
> wait for the first four transfers to finish due to the software
> locking imposed by the mailbox framework. This adds additional delay,
> maybe of few ms only, which isn't required by the hardware but just by
> the software and few ms can be important in scheduler's hotpath.
>
> - With the current approach it isn't possible to assign different bits
> (or doorbell numbers) to clients from DT and the only way of doing
> that without adding new bindings is by extending #mbox-cells to accept
> a value of 2 as done in this patch.
>
> Jassi and Sudeep, I hope I was able to represent both the view points
> properly here. Please correct me if I have made a mistake here.
>
> This is it. It would be nice to get the views of everyone now on this
> and how should this be handled.
I am perfectly fine with adding another cell which seems appropriate
here. You can have 5 cells for all I care if that makes sense for
the h/w. That has nothing to do with the Linux design. Whether Linux
requires serializing mailbox accesses is a separate issue. On that side,
it seems silly to not allow driving the h/w in the most efficient way
possible.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: vdso32: force vdso32 to be compiled as -marm
From: Nick Desaulniers @ 2020-05-28 19:06 UTC (permalink / raw)
To: Catalin Marinas, Peter Smith, Will Deacon
Cc: Naohiro Aota, Stephen Boyd, Arnd Bergmann, Masahiro Yamada, LKML,
david.spickett@linaro.org, Manoj Gupta, Kristof Beyls,
Luis Lozano, Nathan Chancellor, Vincenzo Frascino, Robin Murphy,
Victor Campos, Linux ARM
In-Reply-To: <20200528094154.GB2961@gaia>
On Thu, May 28, 2020 at 12:20 AM Will Deacon <will@kernel.org> wrote:
> > Yes, I know that :)
Right, I forgot; you wrote the 64b one. :)
On Thu, May 28, 2020 at 2:41 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Thu, May 28, 2020 at 09:05:08AM +0100, Peter Smith wrote:
> > I suggest using Arm if you need a frame pointer, and disable the
> > frame pointer if you want/need to use Thumb. My understanding is that
> > runtime unwinding using the frame pointer in Thumb is already difficult
> > due to Arm and Thumb functions using different registers for the frame
> > pointer.
>
> IIRC from the Thumb-2 kernel porting days, even in the absence of
> ARM/Thumb interworking, the Thumb-2 frame pointer was pretty useless for
> unwinding since it points to the bottom of the current stack frame (the
> reason I think is that some LDR/STR instructions with negative indexing
> are not available). So finding the previous frame pointer was not
> possible and had to rely on the exception unwinding information.
Eureka! That's it! Implicit state of -fomit-frame-pointer.
Ok, forgetting ARCH=arm64 for a second, for ARCH=arm we have the
choice CONFIG_THUMB2_KERNEL. Regardless of which is chosen, we
*always* explicitly set -mthumb or -marm, but we never rely on
implicit defaults. Again for ARCH=arm, we have a choice of unwinders,
or at least we do when *not* targeting thumb. If we select
CONFIG_THUMB2_KERNEL, then CONFIG_UNWINDER_FRAME_POINTER cannot be
selected.
arch/arm/Kconfig.debug:
57 config UNWINDER_FRAME_POINTER
58 bool "Frame pointer unwinder"
59 depends on !THUMB2_KERNEL
...
CONFIG_UNWINDER_FRAME_POINTER selects CONFIG_FRAME_POINTER which sets
-fno-omit-frame-pointer. Otherwise, it looks like the choice of
-f{no-}omit-frame-pointer is left unspecified, relying on compiler
defaults.
And that's just for ARCH=arm. Returning to ARCH=arm64, and the compat
vdso in particular, it doesn't look like we ever set
-f{no-}omit-frame-pointer either, so again we're looking at the
compiler defaults.
And when we look at the default behavior for the implicit state of
-f{no-}omit-frame-pointer, we find differences.
Here's a test case you can play around with:
https://godbolt.org/z/0oY39t
For Clang, can you tell what the default state is if left off?
For GCC, can you tell what the default state is if left off?
Do they match?
Is this specific to -mthumb?
(Bonus: what happens when you remove `-O2`?)
Answers:
-fno-omit-frame-pointer
-fomit-frame-pointer
No.
No.
-fno-omit-frame-pointer in GCC (-fomit-frame-pointer is an optimization)
Deja vu, I fixed a very similar discrepancy reported by Linus not too long ago.
https://reviews.llvm.org/D74698
Looking at the relevant logic in Clang:
https://github.com/llvm/llvm-project/blob/58beb76b7bd2f7caa1df461b9db6629521c3b60b/clang/lib/Driver/ToolChains/Clang.cpp#L527-L591
Noticely absent are arm, thumb, aarch64, and big endian variants,
specifically here:
https://github.com/llvm/llvm-project/blob/58beb76b7bd2f7caa1df461b9db6629521c3b60b/clang/lib/Driver/ToolChains/Clang.cpp#L556-L571
I should fix that in Clang.
That should also speed up our 32b ARM kernels that select
CONFIG_THUMB2_KERNEL (ie. CrOS veyron-minnie platform, rk3288).
Shouldn't make a difference for 64b ARM kernels since those select
frame pointers. Though I am curious about the userspaces now for CrOS
and Android...
On Thu, May 28, 2020 at 1:05 AM Peter Smith <Peter.Smith@arm.com> wrote:
> > Hope this helps
Always, m8, you're the expert.
So r11 will be the frame pointer for arm and thumb according to latest
aapcs, but the compilers haven't yet made any changes related to this,
and can still use r7 in a bunch of cases (-mthumb
--target=arm-linux-gnueabi being the most relevant one for our
discussion).
> On Thu, May 28, 2020 at 12:20 AM Will Deacon <will@kernel.org> wrote:
> your
> patch is papering over a deeper issue.
Ah, your right. Sorry, I was wrong. I owe you (another) beer? I'm
going into debt over these and will have to take out a loan, soon!
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] spi: bcm2835: Implement shutdown callback
From: Florian Fainelli @ 2020-05-28 19:06 UTC (permalink / raw)
To: linux-kernel
Cc: moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Florian Fainelli, Scott Branden, Ray Jui, open list:SPI SUBSYSTEM,
Mark Brown,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Nicolas Saenz Julienne
Make sure we clear the FIFOs, stop the block, disable the clock and
release the DMA channel.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/spi/spi-bcm2835.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
index 20d8581fdf88..237bd306c268 100644
--- a/drivers/spi/spi-bcm2835.c
+++ b/drivers/spi/spi-bcm2835.c
@@ -1391,6 +1391,15 @@ static int bcm2835_spi_remove(struct platform_device *pdev)
return 0;
}
+static void bcm2835_spi_shutdown(struct platform_device *pdev)
+{
+ int ret;
+
+ ret = bcm2835_spi_remove(pdev);
+ if (ret)
+ dev_err(&pdev->dev, "failed to shutdown\n");
+}
+
static const struct of_device_id bcm2835_spi_match[] = {
{ .compatible = "brcm,bcm2835-spi", },
{}
@@ -1404,6 +1413,7 @@ static struct platform_driver bcm2835_spi_driver = {
},
.probe = bcm2835_spi_probe,
.remove = bcm2835_spi_remove,
+ .shutdown = bcm2835_spi_shutdown,
};
module_platform_driver(bcm2835_spi_driver);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] spi: bcm2835: Enable shared interrupt support
From: Florian Fainelli @ 2020-05-28 19:00 UTC (permalink / raw)
To: Nicolas Saenz Julienne, Mark Brown, Ray Jui, Scott Branden,
bcm-kernel-feedback-list
Cc: Martin Sperl, linux-kernel, linux-rpi-kernel, linux-arm-kernel,
linux-spi
In-Reply-To: <20200528185805.28991-1-nsaenzjulienne@suse.de>
On 5/28/20 11:58 AM, Nicolas Saenz Julienne wrote:
> From: Martin Sperl <kernel@martin.sperl.org>
>
> bcm2711, Rasberry Pi 4's SoC, shares one interrupt for multiple
> instances of the bcm2835 SPI controller. So this enables shared
> interrupt support for them.
>
> The early bail out in the interrupt routine avoids messing with buffers
> of transfers being done by other means. Otherwise, the driver can handle
> receiving interrupts asserted by other controllers during an IRQ based
> transfer.
>
> Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Thanks Nicolas, we have been using this patch on 7211 (which is very
similar to 2711):
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] spi: bcm2835: Enable shared interrupt support
From: Nicolas Saenz Julienne @ 2020-05-28 18:58 UTC (permalink / raw)
To: Mark Brown, Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list, Nicolas Saenz Julienne
Cc: Martin Sperl, linux-kernel, linux-rpi-kernel, linux-arm-kernel,
linux-spi
From: Martin Sperl <kernel@martin.sperl.org>
bcm2711, Rasberry Pi 4's SoC, shares one interrupt for multiple
instances of the bcm2835 SPI controller. So this enables shared
interrupt support for them.
The early bail out in the interrupt routine avoids messing with buffers
of transfers being done by other means. Otherwise, the driver can handle
receiving interrupts asserted by other controllers during an IRQ based
transfer.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/spi/spi-bcm2835.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
index 11c235879bb7..ca1085c812f2 100644
--- a/drivers/spi/spi-bcm2835.c
+++ b/drivers/spi/spi-bcm2835.c
@@ -379,6 +379,10 @@ static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
if (bs->tx_len && cs & BCM2835_SPI_CS_DONE)
bcm2835_wr_fifo_blind(bs, BCM2835_SPI_FIFO_SIZE);
+ /* check if we got interrupt enabled */
+ if (!(bcm2835_rd(bs, BCM2835_SPI_CS) & BCM2835_SPI_CS_INTR))
+ return IRQ_NONE;
+
/* Read as many bytes as possible from FIFO */
bcm2835_rd_fifo(bs);
/* Write as many bytes as possible to FIFO */
@@ -1340,8 +1344,8 @@ static int bcm2835_spi_probe(struct platform_device *pdev)
bcm2835_wr(bs, BCM2835_SPI_CS,
BCM2835_SPI_CS_CLEAR_RX | BCM2835_SPI_CS_CLEAR_TX);
- err = devm_request_irq(&pdev->dev, bs->irq, bcm2835_spi_interrupt, 0,
- dev_name(&pdev->dev), ctlr);
+ err = devm_request_irq(&pdev->dev, bs->irq, bcm2835_spi_interrupt,
+ IRQF_SHARED, dev_name(&pdev->dev), ctlr);
if (err) {
dev_err(&pdev->dev, "could not request IRQ: %d\n", err);
goto out_dma_release;
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6 15/18] mtd: nand: Introduce the ECC engine abstraction
From: Boris Brezillon @ 2020-05-28 18:52 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Rob Herring, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200528113113.9166-16-miquel.raynal@bootlin.com>
On Thu, 28 May 2020 13:31:10 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Create a generic ECC engine object.
>
> Later the ecc.c file will receive more generic code coming from
> the raw NAND specific part. This is a base to instantiate ECC engine
> objects.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> drivers/mtd/nand/Kconfig | 7 ++
> drivers/mtd/nand/Makefile | 2 +
> drivers/mtd/nand/ecc.c | 138 ++++++++++++++++++++++++++++++++++++++
> include/linux/mtd/nand.h | 67 ++++++++++++++++++
> 4 files changed, 214 insertions(+)
> create mode 100644 drivers/mtd/nand/ecc.c
>
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index c1a45b071165..a4478ffa279d 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -9,4 +9,11 @@ source "drivers/mtd/nand/onenand/Kconfig"
> source "drivers/mtd/nand/raw/Kconfig"
> source "drivers/mtd/nand/spi/Kconfig"
>
> +menu "ECC engine support"
> +
> +config MTD_NAND_ECC
> + bool
> +
> +endmenu
> +
> endmenu
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index 7ecd80c0a66e..981372953b56 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -6,3 +6,5 @@ obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
> obj-y += onenand/
> obj-y += raw/
> obj-y += spi/
> +
> +nandcore-$(CONFIG_MTD_NAND_ECC) += ecc.o
> diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
> new file mode 100644
> index 000000000000..e4f2b6fcbb12
> --- /dev/null
> +++ b/drivers/mtd/nand/ecc.c
> @@ -0,0 +1,138 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Generic Error-Correcting Code (ECC) engine
> + *
> + * Copyright (C) 2019 Macronix
> + * Author:
> + * Miquèl RAYNAL <miquel.raynal@bootlin.com>
> + *
> + *
> + * This file describes the abstraction of any NAND ECC engine. It has been
> + * designed to fit most cases, including parallel NANDs and SPI-NANDs.
> + *
> + * There are three main situations where instantiating this ECC engine makes
> + * sense:
> + * - "external": The ECC engine is outside the NAND pipeline, typically this
I'm not sure why you put quotes around those names.
> + * is a software ECC engine. One can also imagine a generic
^ or an hardware
engine that's outside the NAND controller pipeline.
You can the drop the "One can also imagine ..." since it's more than a
theoretical use case, we already have a few engines that fall in this
category.
> + * hardware ECC engine which would be an IP itself. Interacting
> + * with a SPI-NAND device without on-die ECC could be achieved
^can
> + * thanks to the use of such external engine.
But I think I would simply drop this last sentence.
> + * - "pipelined": The ECC engine is inside the NAND pipeline, ie. on the
> + * controller's side. This is the case of most of the raw NAND
> + * controllers. These controllers usually embed an hardware ECC
> + * engine which is managed thanks to the same register set as
> + * the controller's.
Again, I would drop the last sentence here. I think saying the ECC
bytes are generated/data corrected on the fly when a page is
written/read would be more useful.
> + * - "ondie": The ECC engine is inside the NAND pipeline, on the chip's side.
> + * Some NAND chips can correct themselves the data. The on-die
> + * correction can be enabled, disabled and the status of the
> + * correction after a read may be retrieved with a NAND command
> + * (may be vendor specific).
"The on-die correction can be enabled, disabled" -> this is true for
any kind of ECC engine :P.
> + *
> + * Besides the initial setup and final cleanups, the interfaces are rather
> + * simple:
> + * - "prepare": Prepare an I/O request, check the ECC engine is enabled or
^if/whether
> + * disabled as requested before the I/O. In case of software
How about "Enable/disable the ECC engine based on the I/O request type."
> + * correction, this step may involve to derive the ECC bytes and
> + * place them in the OOB area before a write.
This is also true for external hardware ECC engines.
> + * - "finish": Finish an I/O request, check the status of the operation ie.
> + * the data validity in case of a read (report to the upper layer
> + * any bitflip/errors).
It's all about correcting/reporting errors, right. Let's try to put
that into simple words: "Correct the data in case of a read request and
report the number of corrected bits/uncorrectable errors. Most likely
empty for write operations, unless you have hardware specific stuff to
do, like shutting down the engine to save some power"
> + *
> + * Both prepare/finish callbacks are supposed to enclose I/O request and will
"The I/O request should be enclosed in a prepare()/finish() pair of
calls" or "The prepare/finish call should surround the I/O request".
> + * behave differently depending on the desired correction:
^requested I/O type
> + * - "raw": Correction disabled
> + * - "ecc": Correction enabled
> + *
> + * The request direction is impacting the logic as well:
> + * - "read": Load data from the NAND chip
> + * - "write": Store data in the NAND chip
> + *
> + * Mixing all this combinations together gives the following behavior.
Mention that those are just examples, and drivers are free to add
custom steps in their prepare/finish hooks.
> + *
> + * ["external" ECC engine]
> + * - external + prepare + raw + read: do nothing
> + * - external + finish + raw + read: do nothing
> + * - external + prepare + raw + write: do nothing
> + * - external + finish + raw + write: do nothing
> + * - external + prepare + ecc + read: do nothing
> + * - external + finish + ecc + read: calculate expected ECC bytes, extract
> + * ECC bytes from OOB buffer, correct
> + * and report any bitflip/error
> + * - external + prepare + ecc + write: calculate ECC bytes and store them at
> + * the right place in the OOB buffer based
> + * on the OOB layout
> + * - external + finish + ecc + write: do nothing
> + *
> + * ["pipelined" ECC engine]
> + * - pipelined + prepare + raw + read: disable the controller's ECC engine if
> + * activated
> + * - pipelined + finish + raw + read: do nothing
> + * - pipelined + prepare + raw + write: disable the controller's ECC engine if
> + * activated
> + * - pipelined + finish + raw + write: do nothing
> + * - pipelined + prepare + ecc + read: enable the controller's ECC engine if
> + * deactivated
> + * - pipelined + finish + ecc + read: check the status, report any
> + * error/bitflip
> + * - pipelined + prepare + ecc + write: enable the controller's ECC engine if
> + * deactivated
> + * - pipelined + finish + ecc + write: do nothing
> + *
> + * ["ondie" ECC engine]
> + * - ondie + prepare + raw + read: send commands to disable the on-chip ECC
> + * engine if activated
> + * - ondie + finish + raw + read: do nothing
> + * - ondie + prepare + raw + write: send commands to disable the on-chip ECC
> + * engine if activated
> + * - ondie + finish + raw + write: do nothing
> + * - ondie + prepare + ecc + read: send commands to enable the on-chip ECC
> + * engine if deactivated
> + * - ondie + finish + ecc + read: send commands to check the status, report
> + * any error/bitflip
> + * - ondie + prepare + ecc + write: send commands to enable the on-chip ECC
> + * engine if deactivated
> + * - ondie + finish + ecc + write: do nothing
> + */
> +
> +#include <linux/module.h>
> +#include <linux/mtd/nand.h>
> +
Shouldn't we have kernel-docs for those functions?
> +int nand_ecc_init_ctx(struct nand_device *nand)
> +{
> + if (!nand->ecc.engine->ops->init_ctx)
> + return 0;
> +
> + return nand->ecc.engine->ops->init_ctx(nand);
> +}
> +EXPORT_SYMBOL(nand_ecc_init_ctx);
> +
> +void nand_ecc_cleanup_ctx(struct nand_device *nand)
> +{
> + if (nand->ecc.engine->ops->cleanup_ctx)
> + nand->ecc.engine->ops->cleanup_ctx(nand);
> +}
> +EXPORT_SYMBOL(nand_ecc_cleanup_ctx);
> +
> +int nand_ecc_prepare_io_req(struct nand_device *nand,
> + struct nand_page_io_req *req)
> +{
> + if (!nand->ecc.engine->ops->prepare_io_req)
> + return 0;
> +
> + return nand->ecc.engine->ops->prepare_io_req(nand, req);
> +}
> +EXPORT_SYMBOL(nand_ecc_prepare_io_req);
> +
> +int nand_ecc_finish_io_req(struct nand_device *nand,
> + struct nand_page_io_req *req)
> +{
> + if (!nand->ecc.engine->ops->finish_io_req)
> + return 0;
> +
> + return nand->ecc.engine->ops->finish_io_req(nand, req);
> +}
> +EXPORT_SYMBOL(nand_ecc_finish_io_req);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
> +MODULE_DESCRIPTION("Generic ECC engine");
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 2e9af24936cd..0be260fd2f86 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -221,6 +221,73 @@ struct nand_ops {
> bool (*isbad)(struct nand_device *nand, const struct nand_pos *pos);
> };
>
> +/**
> + * struct nand_ecc_context - Context for the ECC engine
> + * @conf: basic ECC engine parameters
> + * @total: Total number of bytes used for storing ECC codes, this is used by
Sometimes you start your description with an uppercase, sometimes not.
> + * generic OOB layouts
> + * @priv: ECC engine driver private data
> + */
> +struct nand_ecc_context {
> + struct nand_ecc_props conf;
> + unsigned int total;
> + void *priv;
> +};
> +
> +/**
> + * struct nand_ecc_engine_ops - Generic ECC engine operations
^s/Generic//
> + * @init_ctx: given a desired user configuration for the pointed NAND device,
> + * requests the ECC engine driver to setup a configuration with
> + * values it supports.
> + * @cleanup_ctx: clean the context initialized by @init_ctx.
> + * @prepare_io_req: is called before reading/writing a page to prepare the I/O
> + * request to be performed with ECC correction.
> + * @finish_io_req: is called after reading/writing a page to terminate the I/O
> + * request and ensure proper ECC correction.
> + */
> +struct nand_ecc_engine_ops {
> + int (*init_ctx)(struct nand_device *nand);
> + void (*cleanup_ctx)(struct nand_device *nand);
> + int (*prepare_io_req)(struct nand_device *nand,
> + struct nand_page_io_req *req);
> + int (*finish_io_req)(struct nand_device *nand,
> + struct nand_page_io_req *req);
> +};
> +
> +/**
> + * struct nand_ecc_engine - Generic ECC engine abstraction for NAND devices
^s/Generic//
> + * @ops: ECC engine operations
> + */
> +struct nand_ecc_engine {
> + struct nand_ecc_engine_ops *ops;
> +};
> +
> +int nand_ecc_init_ctx(struct nand_device *nand);
> +void nand_ecc_cleanup_ctx(struct nand_device *nand);
> +int nand_ecc_prepare_io_req(struct nand_device *nand,
> + struct nand_page_io_req *req);
> +int nand_ecc_finish_io_req(struct nand_device *nand,
> + struct nand_page_io_req *req);
> +
> +/**
> + * struct nand_ecc - High-level ECC object
I think you can drop the "High-level" and just say "Information
relative to the ECC"
> + * @defaults: Default values, depend on the underlying subsystem
> + * @requirements: ECC requirements from the NAND chip perspective
> + * @user_conf: User desires in terms of ECC parameters
> + * @ctx: ECC context for the ECC engine, derived from the device @requirements
> + * the @user_conf and the @defaults
> + * @ondie_engine: On-die ECC engine reference, if any
> + * @engine: ECC engine actually bound
> + */
> +struct nand_ecc {
> + struct nand_ecc_props defaults;
> + struct nand_ecc_props requirements;
> + struct nand_ecc_props user_conf;
> + struct nand_ecc_context ctx;
> + struct nand_ecc_engine *ondie_engine;
> + struct nand_ecc_engine *engine;
> +};
> +
> /**
> * struct nand_device - NAND device
> * @mtd: MTD instance attached to the NAND device
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] usb: gadget: udc: atmel: implement .pullup callback
From: Michał Mirosław @ 2020-05-28 18:35 UTC (permalink / raw)
To: Cristian Birsan, Felipe Balbi, Greg Kroah-Hartman, Nicolas Ferre,
Alexandre Belloni, Ludovic Desroches, Songjun Wu
Cc: linux-usb, linux-kernel, linux-arm-kernel
In-Reply-To: <cover.1590690650.git.mirq-linux@rere.qmqm.pl>
Implement udc->pullup callback, so that udc_connect/disconnect work.
This is needed for composite gadget, as it assumes udc_disconnect()
actually works and calls gadget's ->disconnect callback.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 9342a3d24963..c5128c229c52 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1028,6 +1028,7 @@ usba_udc_set_selfpowered(struct usb_gadget *gadget, int is_selfpowered)
return 0;
}
+static int atmel_usba_pullup(struct usb_gadget *gadget, int is_on);
static int atmel_usba_start(struct usb_gadget *gadget,
struct usb_gadget_driver *driver);
static int atmel_usba_stop(struct usb_gadget *gadget);
@@ -1101,6 +1102,7 @@ static const struct usb_gadget_ops usba_udc_ops = {
.get_frame = usba_udc_get_frame,
.wakeup = usba_udc_wakeup,
.set_selfpowered = usba_udc_set_selfpowered,
+ .pullup = atmel_usba_pullup,
.udc_start = atmel_usba_start,
.udc_stop = atmel_usba_stop,
.match_ep = atmel_usba_match_ep,
@@ -1957,6 +1959,24 @@ static irqreturn_t usba_vbus_irq_thread(int irq, void *devid)
return IRQ_HANDLED;
}
+static int atmel_usba_pullup(struct usb_gadget *gadget, int is_on)
+{
+ struct usba_udc *udc = container_of(gadget, struct usba_udc, gadget);
+ unsigned long flags;
+ u32 ctrl;
+
+ spin_lock_irqsave(&udc->lock, flags);
+ ctrl = usba_readl(udc, CTRL);
+ if (is_on)
+ ctrl &= ~USBA_DETACH;
+ else
+ ctrl |= USBA_DETACH;
+ usba_writel(udc, CTRL, ctrl);
+ spin_unlock_irqrestore(&udc->lock, flags);
+
+ return 0;
+}
+
static int atmel_usba_start(struct usb_gadget *gadget,
struct usb_gadget_driver *driver)
{
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] usb: gadget: udc: atmel: fix uninitialized read in debug printk
From: Michał Mirosław @ 2020-05-28 18:35 UTC (permalink / raw)
To: Cristian Birsan, Felipe Balbi, Greg Kroah-Hartman, Nicolas Ferre,
Alexandre Belloni, Ludovic Desroches, Songjun Wu
Cc: linux-usb, linux-kernel, linux-arm-kernel
In-Reply-To: <cover.1590690650.git.mirq-linux@rere.qmqm.pl>
Fixed commit moved the assignment of 'req', but did not update a
reference in the DBG() call. Use the argument as it was renamed.
Fixes: 5fb694f96e7c ("usb: gadget: udc: atmel: fix possible oops when unloading module")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 9153e220848d..9342a3d24963 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -865,7 +865,7 @@ static int usba_ep_dequeue(struct usb_ep *_ep, struct usb_request *_req)
u32 status;
DBG(DBG_GADGET | DBG_QUEUE, "ep_dequeue: %s, req %p\n",
- ep->ep.name, req);
+ ep->ep.name, _req);
spin_lock_irqsave(&udc->lock, flags);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] usb: gadget: udc: atmel: remove outdated comment in usba_ep_disable()
From: Michał Mirosław @ 2020-05-28 18:35 UTC (permalink / raw)
To: Cristian Birsan, Felipe Balbi, Greg Kroah-Hartman, Nicolas Ferre,
Alexandre Belloni, Ludovic Desroches, Songjun Wu
Cc: linux-usb, linux-kernel, linux-arm-kernel
In-Reply-To: <cover.1590690650.git.mirq-linux@rere.qmqm.pl>
Fixed commit removed the offending behaviour from the driver, but missed
the comment and associated test. Remove them now.
Fixes: 38e58986e6fc ("usb: gadget: udc: atmel: don't disable enpdoints we don't own")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index d69f61ff0181..9153e220848d 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -676,13 +676,7 @@ static int usba_ep_disable(struct usb_ep *_ep)
if (!ep->ep.desc) {
spin_unlock_irqrestore(&udc->lock, flags);
- /* REVISIT because this driver disables endpoints in
- * reset_all_endpoints() before calling disconnect(),
- * most gadget drivers would trigger this non-error ...
- */
- if (udc->gadget.speed != USB_SPEED_UNKNOWN)
- DBG(DBG_ERR, "ep_disable: %s not enabled\n",
- ep->ep.name);
+ DBG(DBG_ERR, "ep_disable: %s not enabled\n", ep->ep.name);
return -EINVAL;
}
ep->ep.desc = NULL;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] usb: gadget: udc: atmel: assorted fixes
From: Michał Mirosław @ 2020-05-28 18:35 UTC (permalink / raw)
To: Alexandre Belloni, Cristian Birsan, Felipe Balbi,
Greg Kroah-Hartman, Ludovic Desroches, Nicolas Ferre, Songjun Wu
Cc: linux-usb, linux-kernel, linux-arm-kernel
Two trivial fixes and .pullup implementation for Atmel UDC driver to
make composite gadget happy when handling reconfiguration.
Michał Mirosław (3):
usb: gadget: udc: atmel: remove outdated comment in usba_ep_disable()
usb: gadget: udc: atmel: fix uninitialized read in debug printk
usb: gadget: udc: atmel: implement .pullup callback
drivers/usb/gadget/udc/atmel_usba_udc.c | 30 ++++++++++++++++++-------
1 file changed, 22 insertions(+), 8 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] cpufreq: brcmstb-avs-cpufreq: send S2_ENTER / S2_EXIT commands to AVS
From: Markus Mayer @ 2020-05-28 18:20 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Florian Fainelli
Cc: Linux Kernel Mailing List, Broadcom Kernel List, ARM Kernel List,
Markus Mayer, Linux Power Management List
In-Reply-To: <20200528182014.20021-1-mmayer@broadcom.com>
On suspend we send AVS_CMD_S2_ENTER and on resume AVS_CMD_S2_EXIT.
These are best effort calls, so we don't check the return code or take
any action if either of the calls fails.
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
---
drivers/cpufreq/brcmstb-avs-cpufreq.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c b/drivers/cpufreq/brcmstb-avs-cpufreq.c
index 79a0538a531a..3e31e5d28b79 100644
--- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -506,7 +506,14 @@ static int brcm_avs_suspend(struct cpufreq_policy *policy)
* AVS co-processor, not necessarily the P-state we are running at now.
* So, we get the current P-state explicitly.
*/
- return brcm_avs_get_pstate(priv, &priv->pmap.state);
+ ret = brcm_avs_get_pstate(priv, &priv->pmap.state);
+ if (ret)
+ return ret;
+
+ /* This is best effort. Nothing to do if it fails. */
+ (void)__issue_avs_command(priv, AVS_CMD_S2_ENTER, 0, 0, NULL);
+
+ return 0;
}
static int brcm_avs_resume(struct cpufreq_policy *policy)
@@ -514,6 +521,9 @@ static int brcm_avs_resume(struct cpufreq_policy *policy)
struct private_data *priv = policy->driver_data;
int ret;
+ /* This is best effort. Nothing to do if it fails. */
+ (void)__issue_avs_command(priv, AVS_CMD_S2_EXIT, 0, 0, NULL);
+
ret = brcm_avs_set_pmap(priv, &priv->pmap);
if (ret == -EEXIST) {
struct platform_device *pdev = cpufreq_get_driver_data();
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] cpufreq: brcmstb-avs-cpufreq: Support polling AVS firmware
From: Markus Mayer @ 2020-05-28 18:20 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Florian Fainelli
Cc: Markus Mayer, Broadcom Kernel List, Linux Kernel Mailing List,
ARM Kernel List, Linux Power Management List
In-Reply-To: <20200528182014.20021-1-mmayer@broadcom.com>
From: Florian Fainelli <f.fainelli@gmail.com>
In case the interrupt towards the host is never raised, yet the AVS
firmware responds correctly within the alloted time, allow supporting a
polling mode.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
---
drivers/cpufreq/brcmstb-avs-cpufreq.c | 47 +++++++++++++++++++--------
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c b/drivers/cpufreq/brcmstb-avs-cpufreq.c
index c8b754694a5e..79a0538a531a 100644
--- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -42,6 +42,7 @@
*/
#include <linux/cpufreq.h>
+#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/module.h>
@@ -178,6 +179,7 @@ struct private_data {
struct completion done;
struct semaphore sem;
struct pmap pmap;
+ int host_irq;
};
static void __iomem *__map_region(const char *name)
@@ -195,12 +197,36 @@ static void __iomem *__map_region(const char *name)
return ptr;
}
+static unsigned long wait_for_avs_command(struct private_data *priv,
+ unsigned long timeout)
+{
+ unsigned long time_left = 0;
+ u32 val;
+
+ /* Event driven, wait for the command interrupt */
+ if (priv->host_irq >= 0)
+ return wait_for_completion_timeout(&priv->done,
+ msecs_to_jiffies(timeout));
+
+ /* Polling for command completion */
+ do {
+ time_left = timeout;
+ val = readl(priv->base + AVS_MBOX_STATUS);
+ if (val)
+ break;
+
+ usleep_range(1000, 2000);
+ } while (--timeout);
+
+ return time_left;
+}
+
static int __issue_avs_command(struct private_data *priv, unsigned int cmd,
unsigned int num_in, unsigned int num_out,
u32 args[])
{
- unsigned long time_left = msecs_to_jiffies(AVS_TIMEOUT);
void __iomem *base = priv->base;
+ unsigned long time_left;
unsigned int i;
int ret;
u32 val;
@@ -238,7 +264,7 @@ static int __issue_avs_command(struct private_data *priv, unsigned int cmd,
writel(AVS_CPU_L2_INT_MASK, priv->avs_intr_base + AVS_CPU_L2_SET0);
/* Wait for AVS co-processor to finish processing the command. */
- time_left = wait_for_completion_timeout(&priv->done, time_left);
+ time_left = wait_for_avs_command(priv, AVS_TIMEOUT);
/*
* If the AVS status is not in the expected range, it means AVS didn't
@@ -509,7 +535,7 @@ static int brcm_avs_prepare_init(struct platform_device *pdev)
{
struct private_data *priv;
struct device *dev;
- int host_irq, ret;
+ int ret;
dev = &pdev->dev;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -536,19 +562,14 @@ static int brcm_avs_prepare_init(struct platform_device *pdev)
goto unmap_base;
}
- host_irq = platform_get_irq_byname(pdev, BRCM_AVS_HOST_INTR);
- if (host_irq < 0) {
- dev_err(dev, "Couldn't find interrupt %s -- %d\n",
- BRCM_AVS_HOST_INTR, host_irq);
- ret = host_irq;
- goto unmap_intr_base;
- }
+ priv->host_irq = platform_get_irq_byname(pdev, BRCM_AVS_HOST_INTR);
- ret = devm_request_irq(dev, host_irq, irq_handler, IRQF_TRIGGER_RISING,
+ ret = devm_request_irq(dev, priv->host_irq, irq_handler,
+ IRQF_TRIGGER_RISING,
BRCM_AVS_HOST_INTR, priv);
- if (ret) {
+ if (ret && priv->host_irq >= 0) {
dev_err(dev, "IRQ request failed: %s (%d) -- %d\n",
- BRCM_AVS_HOST_INTR, host_irq, ret);
+ BRCM_AVS_HOST_INTR, priv->host_irq, ret);
goto unmap_intr_base;
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] cpufreq: brcmstb-avs-cpufreq: more flexible interface for __issue_avs_command()
From: Markus Mayer @ 2020-05-28 18:20 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Florian Fainelli
Cc: Linux Kernel Mailing List, Broadcom Kernel List, ARM Kernel List,
Markus Mayer, Linux Power Management List
We are changing how parameters are passed to __issue_avs_command(), so we
can pass input *and* output arguments with the same command, rather than
just one or the other.
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
---
drivers/cpufreq/brcmstb-avs-cpufreq.c | 30 +++++++++++++--------------
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c b/drivers/cpufreq/brcmstb-avs-cpufreq.c
index 4f86ce2db34f..c8b754694a5e 100644
--- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -195,7 +195,8 @@ static void __iomem *__map_region(const char *name)
return ptr;
}
-static int __issue_avs_command(struct private_data *priv, int cmd, bool is_send,
+static int __issue_avs_command(struct private_data *priv, unsigned int cmd,
+ unsigned int num_in, unsigned int num_out,
u32 args[])
{
unsigned long time_left = msecs_to_jiffies(AVS_TIMEOUT);
@@ -225,11 +226,9 @@ static int __issue_avs_command(struct private_data *priv, int cmd, bool is_send,
/* Clear status before we begin. */
writel(AVS_STATUS_CLEAR, base + AVS_MBOX_STATUS);
- /* We need to send arguments for this command. */
- if (args && is_send) {
- for (i = 0; i < AVS_MAX_CMD_ARGS; i++)
- writel(args[i], base + AVS_MBOX_PARAM(i));
- }
+ /* Provide input parameters */
+ for (i = 0; i < num_in; i++)
+ writel(args[i], base + AVS_MBOX_PARAM(i));
/* Protect from spurious interrupts. */
reinit_completion(&priv->done);
@@ -256,11 +255,9 @@ static int __issue_avs_command(struct private_data *priv, int cmd, bool is_send,
goto out;
}
- /* This command returned arguments, so we read them back. */
- if (args && !is_send) {
- for (i = 0; i < AVS_MAX_CMD_ARGS; i++)
- args[i] = readl(base + AVS_MBOX_PARAM(i));
- }
+ /* Process returned values */
+ for (i = 0; i < num_out; i++)
+ args[i] = readl(base + AVS_MBOX_PARAM(i));
/* Clear status to tell AVS co-processor we are done. */
writel(AVS_STATUS_CLEAR, base + AVS_MBOX_STATUS);
@@ -338,7 +335,7 @@ static int brcm_avs_get_pmap(struct private_data *priv, struct pmap *pmap)
u32 args[AVS_MAX_CMD_ARGS];
int ret;
- ret = __issue_avs_command(priv, AVS_CMD_GET_PMAP, false, args);
+ ret = __issue_avs_command(priv, AVS_CMD_GET_PMAP, 0, 4, args);
if (ret || !pmap)
return ret;
@@ -359,7 +356,7 @@ static int brcm_avs_set_pmap(struct private_data *priv, struct pmap *pmap)
args[2] = pmap->p2;
args[3] = pmap->state;
- return __issue_avs_command(priv, AVS_CMD_SET_PMAP, true, args);
+ return __issue_avs_command(priv, AVS_CMD_SET_PMAP, 4, 0, args);
}
static int brcm_avs_get_pstate(struct private_data *priv, unsigned int *pstate)
@@ -367,7 +364,7 @@ static int brcm_avs_get_pstate(struct private_data *priv, unsigned int *pstate)
u32 args[AVS_MAX_CMD_ARGS];
int ret;
- ret = __issue_avs_command(priv, AVS_CMD_GET_PSTATE, false, args);
+ ret = __issue_avs_command(priv, AVS_CMD_GET_PSTATE, 0, 1, args);
if (ret)
return ret;
*pstate = args[0];
@@ -381,7 +378,8 @@ static int brcm_avs_set_pstate(struct private_data *priv, unsigned int pstate)
args[0] = pstate;
- return __issue_avs_command(priv, AVS_CMD_SET_PSTATE, true, args);
+ return __issue_avs_command(priv, AVS_CMD_SET_PSTATE, 1, 0, args);
+
}
static u32 brcm_avs_get_voltage(void __iomem *base)
@@ -593,7 +591,7 @@ static int brcm_avs_cpufreq_init(struct cpufreq_policy *policy)
/* All cores share the same clock and thus the same policy. */
cpumask_setall(policy->cpus);
- ret = __issue_avs_command(priv, AVS_CMD_ENABLE, false, NULL);
+ ret = __issue_avs_command(priv, AVS_CMD_ENABLE, 0, 0, NULL);
if (!ret) {
unsigned int pstate;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] brcmstb-avs-cpufreq updates
From: Markus Mayer @ 2020-05-28 18:19 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Florian Fainelli
Cc: Linux Kernel Mailing List, Broadcom Kernel List, ARM Kernel List,
Markus Mayer, Linux Power Management List
Hi all,
Here is a collection of little, independent improvements to the
brcmstb-avs-cpufreq driver.
- more flexible interface for __issue_avs_command()
This change makes the function more versatile as it can handle input
and output parameters at the same time.
- Support polling AVS firmware
This change allows the driver to use polling if interrupt driven mode
doesn't work for some reason.
- send S2_ENTER / S2_EXIT commands to AVS
Let the AVS firmware know when we are about to enter, or have just
exited, S2 mode.
Regards,
-Markus
Florian Fainelli (1):
cpufreq: brcmstb-avs-cpufreq: Support polling AVS firmware
Markus Mayer (2):
cpufreq: brcmstb-avs-cpufreq: more flexible interface for
__issue_avs_command()
cpufreq: brcmstb-avs-cpufreq: send S2_ENTER / S2_EXIT commands to AVS
drivers/cpufreq/brcmstb-avs-cpufreq.c | 89 ++++++++++++++++++---------
1 file changed, 59 insertions(+), 30 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 11/15] PCI: iproc: Use pci_host_probe() to register host
From: Scott Branden @ 2020-05-28 17:53 UTC (permalink / raw)
To: Rob Herring, Lorenzo Pieralisi
Cc: Scott Branden, linux-pci, bcm-kernel-feedback-list, Ray Jui,
Bjorn Helgaas, linux-arm-kernel
In-Reply-To: <20200522234832.954484-12-robh@kernel.org>
On 2020-05-22 4:48 p.m., Rob Herring wrote:
> The iproc host driver does the same host registration and bus scanning
> calls as pci_host_probe, so let's use it instead.
>
> The only difference is pci_assign_unassigned_bus_resources() was called
> instead of pci_bus_size_bridges() and pci_bus_assign_resources(). This
> should be the same.
>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Ray Jui <rjui@broadcom.com>
> Cc: Scott Branden <sbranden@broadcom.com>
> Cc: bcm-kernel-feedback-list@broadcom.com
> Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Scott Branden <scott.branden@broadcom.com>
> ---
> drivers/pci/controller/pcie-iproc.c | 18 +++++-------------
> drivers/pci/controller/pcie-iproc.h | 2 --
> 2 files changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> index 8c7f875acf7f..232fca0754e1 100644
> --- a/drivers/pci/controller/pcie-iproc.c
> +++ b/drivers/pci/controller/pcie-iproc.c
> @@ -1470,7 +1470,6 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)
> {
> struct device *dev;
> int ret;
> - struct pci_bus *child;
> struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
>
> dev = pcie->dev;
> @@ -1531,21 +1530,12 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)
> host->map_irq = pcie->map_irq;
> host->swizzle_irq = pci_common_swizzle;
>
> - ret = pci_scan_root_bus_bridge(host);
> + ret = pci_host_probe(host);
> if (ret < 0) {
> dev_err(dev, "failed to scan host: %d\n", ret);
> goto err_power_off_phy;
> }
>
> - pci_assign_unassigned_bus_resources(host->bus);
> -
> - pcie->root_bus = host->bus;
> -
> - list_for_each_entry(child, &host->bus->children, node)
> - pcie_bus_configure_settings(child);
> -
> - pci_bus_add_devices(host->bus);
> -
> return 0;
>
> err_power_off_phy:
> @@ -1558,8 +1548,10 @@ EXPORT_SYMBOL(iproc_pcie_setup);
>
> int iproc_pcie_remove(struct iproc_pcie *pcie)
> {
> - pci_stop_root_bus(pcie->root_bus);
> - pci_remove_root_bus(pcie->root_bus);
> + struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
> +
> + pci_stop_root_bus(host->bus);
> + pci_remove_root_bus(host->bus);
>
> iproc_pcie_msi_disable(pcie);
>
> diff --git a/drivers/pci/controller/pcie-iproc.h b/drivers/pci/controller/pcie-iproc.h
> index 4f03ea539805..c2676e442f55 100644
> --- a/drivers/pci/controller/pcie-iproc.h
> +++ b/drivers/pci/controller/pcie-iproc.h
> @@ -54,7 +54,6 @@ struct iproc_msi;
> * @reg_offsets: register offsets
> * @base: PCIe host controller I/O register base
> * @base_addr: PCIe host controller register base physical address
> - * @root_bus: pointer to root bus
> * @phy: optional PHY device that controls the Serdes
> * @map_irq: function callback to map interrupts
> * @ep_is_internal: indicates an internal emulated endpoint device is connected
> @@ -85,7 +84,6 @@ struct iproc_pcie {
> void __iomem *base;
> phys_addr_t base_addr;
> struct resource mem;
> - struct pci_bus *root_bus;
> struct phy *phy;
> int (*map_irq)(const struct pci_dev *, u8, u8);
> bool ep_is_internal;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction clock check from custom type flags
From: Jolly Shah @ 2020-05-28 17:44 UTC (permalink / raw)
To: Stephen Boyd, Jolly Shah, arm, linux-clk, michal.simek,
mturquette, olof
Cc: Tejas Patel, Rajan Vaja, rajanv, linux-kernel, linux-arm-kernel
In-Reply-To: <159054169658.88029.371843532116000844@swboyd.mtv.corp.google.com>
Hi Stephan,
Thanks for the review.
> ------Original Message------
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: Tuesday, May 26, 2020 6:08PM
> To: Jolly Shah <jolly.shah@xilinx.com>, Arm <arm@kernel.org>,
Linux-clk <linux-clk@vger.kernel.org>, Michal Simek
<michal.simek@xilinx.com>, Mturquette <mturquette@baylibre.com>, Olof
<olof@lixom.net>
> Cc: Rajan Vaja <rajanv@xilinx.com>,
Linux-arm-kernel@lists.infradead.org
<linux-arm-kernel@lists.infradead.org>, Linux-kernel@vger.kernel.org
<linux-kernel@vger.kernel.org>, Tejas Patel <tejas.patel@xilinx.com>,
Rajan Vaja <rajan.vaja@xilinx.com>, Jolly Shah <jolly.shah@xilinx.com>
> Subject: Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction
clock check from custom type flags
>
> Quoting Jolly Shah (2020-03-12 14:31:39)
>> From: Tejas Patel <tejas.patel@xilinx.com>
>>
>> Older firmware version sets BIT(13) in clkflag to mark a
>> divider as fractional divider. Updated firmware version sets BIT(4)
>> in type flags to mark a divider as fractional divider since
>> BIT(13) is defined as CLK_DUTY_CYCLE_PARENT in the common clk
>> framework flags.
>>
>> To support both old and new firmware version, consider BIT(13) from
>> clkflag and BIT(4) from type_flag to check if divider is fractional
>> or not.
>>
>> To maintain compatibility BIT(13) of clkflag in firmware will not be
>> used in future for any purpose and will be marked as unused.
>
> Why are we mixing the firmware flags with the ccf flags? They shouldn't
> be the same. The firmware should have its own 'flag numberspace' that is
> distinct from the common clk framework's 'flag numberspace'. Please fix
> the code.
>
Yes firmware flags are using separate numberspace now. Firmware
maintains CCF and firmware specific flags separately but earlier
CLK_FRAC was mistakenly defined in ccf flagspace and hence handled here
for backward compatibility. Driver takes care of not registering same
with CCF. Let me know if I misunderstood.
Thanks,
Jolly Shah
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv3 0/2] Add support for replicators which loses context on clock removal
From: Mathieu Poirier @ 2020-05-28 17:40 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Sai Prakash Ranjan, Suzuki K Poulose, linux-arm-msm,
linux-kernel, Stephen Boyd, linux-arm-kernel, Mike Leach
In-Reply-To: <20200528144803.GA36440@bogus>
On Thu, May 28, 2020 at 08:48:03AM -0600, Rob Herring wrote:
> On Mon, May 25, 2020 at 10:15:53AM -0600, Mathieu Poirier wrote:
> > Hi Sai,
> >
> > On Sat, May 23, 2020 at 12:06:50AM +0530, Sai Prakash Ranjan wrote:
> > > This series is mainly to add support for replicators
> > > which lose context on removing AMBA clock like on SC7180
> > > SoC where replicator in AOSS domain loses context.
> > >
> >
> > I am good with this set but need a reviewed-by on the DT binding before I can
> > add it to my tree. The same goes for your other set[1].
>
> Then why is it already in linux-next?
I wanted the patches to get exposure to linux-next before sending them on to
Greg for inclusion in the next merge window. Rest assured that I would not have
moved forward without your consent.
>
> In any case,
>
> Acked-by: Rob Herring <robh@kernel.org>
Thank you for that.
Mathieu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/4] ARM: dts: dove: Make the DT compliant with the ti,tfp410 binding
From: Rob Herring @ 2020-05-28 17:37 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: devicetree, jason, airlied, dri-devel, tomi.valkeinen,
Laurent.pinchart, kernel, shawnguo, linux-arm-kernel
In-Reply-To: <20200514143612.2094-2-ricardo.canuelo@collabora.com>
On Thu, May 14, 2020 at 04:36:09PM +0200, Ricardo Cañuelo wrote:
> Define a 'ports' node for 'dvi: video@39' and use the proper naming for
> the powerdown-gpios property to make it compliant with the ti,tfp410
> binding.
>
> This fills the minimum requirements to meet the binding requirements,
> port endpoints are not defined.
Just make 'ports' optional. This isn't really any better unless you add
endpoints too.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
> arch/arm/boot/dts/dove-sbc-a510.dts | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/dove-sbc-a510.dts b/arch/arm/boot/dts/dove-sbc-a510.dts
> index 2bb85a9b7614..32804c981625 100644
> --- a/arch/arm/boot/dts/dove-sbc-a510.dts
> +++ b/arch/arm/boot/dts/dove-sbc-a510.dts
> @@ -132,7 +132,18 @@
> dvi: video@39 {
> compatible = "ti,tfp410";
> reg = <0x39>;
> - powerdown-gpio = <&gpio_ext 3 GPIO_ACTIVE_LOW>;
> + powerdown-gpios = <&gpio_ext 3 GPIO_ACTIVE_LOW>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + };
> + port@1 {
> + reg = <1>;
> + };
> + };
> };
> };
>
> --
> 2.18.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 13/16] soc: mediatek: cmdq: export finalize function
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: devicetree, wsd_upstream, linux-kernel, dri-devel, HS Liao,
Dennis YC Hsieh, linux-mediatek, Houlong Wei, Bibby Hsieh, CK Hu,
linux-arm-kernel
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
Export finalize function to client which helps append eoc and jump
command to pkt. Let client decide call finalize or not.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 +
drivers/soc/mediatek/mtk-cmdq-helper.c | 7 ++-----
include/linux/soc/mediatek/mtk-cmdq.h | 8 ++++++++
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 0dfcd1787e65..7daaabc26eb1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -490,6 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
mtk_crtc_ddp_config(crtc, cmdq_handle);
+ cmdq_pkt_finalize(cmdq_handle);
cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
}
#endif
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 4b07da56c7bb..ebcdd30cd783 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -391,7 +391,7 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
}
EXPORT_SYMBOL(cmdq_pkt_assign);
-static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
+int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
{
struct cmdq_instruction inst = { {0} };
int err;
@@ -411,6 +411,7 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
return err;
}
+EXPORT_SYMBOL(cmdq_pkt_finalize);
static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
{
@@ -445,10 +446,6 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb,
unsigned long flags = 0;
struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
- err = cmdq_pkt_finalize(pkt);
- if (err < 0)
- return err;
-
pkt->cb.cb = cb;
pkt->cb.data = data;
pkt->async_cb.cb = cmdq_pkt_flush_async_cb;
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 28a50c3cf6a1..703cffcd55bd 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -244,6 +244,14 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
*/
int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
+/**
+ * cmdq_pkt_finalize() - Append EOC and jump command to pkt.
+ * @pkt: the CMDQ packet
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
+
/**
* cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
* packet and call back at the end of done packet
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 14/16] soc: mediatek: cmdq: add jump function
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: devicetree, wsd_upstream, linux-kernel, dri-devel, HS Liao,
Dennis YC Hsieh, linux-mediatek, Houlong Wei, Bibby Hsieh, CK Hu,
linux-arm-kernel
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
Add jump function so that client can jump to any address which
contains instruction.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 13 +++++++++++++
include/linux/soc/mediatek/mtk-cmdq.h | 11 +++++++++++
2 files changed, 24 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index ebcdd30cd783..5cf9e71b7900 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -13,6 +13,7 @@
#define CMDQ_POLL_ENABLE_MASK BIT(0)
#define CMDQ_EOC_IRQ_EN BIT(0)
#define CMDQ_REG_TYPE 1
+#define CMDQ_JUMP_RELATIVE 1
struct cmdq_instruction {
union {
@@ -391,6 +392,18 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
}
EXPORT_SYMBOL(cmdq_pkt_assign);
+int cmdq_pkt_jump(struct cmdq_pkt *pkt, dma_addr_t addr)
+{
+ struct cmdq_instruction inst = { {0} };
+
+ inst.op = CMDQ_CODE_JUMP;
+ inst.offset = CMDQ_JUMP_RELATIVE;
+ inst.value = addr >>
+ cmdq_mbox_shift(((struct cmdq_client *)pkt->cl)->chan);
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_jump);
+
int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 703cffcd55bd..9494b293bad9 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -244,6 +244,17 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
*/
int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
+/**
+ * cmdq_pkt_jump() - Append jump command to the CMDQ packet, ask GCE
+ * to execute an instruction that change current thread PC to
+ * a physical address which should contains more instruction.
+ * @pkt: the CMDQ packet
+ * @addr: physical address of target instruction buffer
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_jump(struct cmdq_pkt *pkt, dma_addr_t addr);
+
/**
* cmdq_pkt_finalize() - Append EOC and jump command to pkt.
* @pkt: the CMDQ packet
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 16/16] soc: mediatek: cmdq: add set event function
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: devicetree, wsd_upstream, linux-kernel, dri-devel, HS Liao,
Dennis YC Hsieh, linux-mediatek, Houlong Wei, Bibby Hsieh, CK Hu,
linux-arm-kernel
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
Add set event function in cmdq helper functions to set specific event.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 15 +++++++++++++++
include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
include/linux/soc/mediatek/mtk-cmdq.h | 9 +++++++++
3 files changed, 25 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 9e9a4c81553a..e9b1dd31f63b 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -346,6 +346,21 @@ int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
}
EXPORT_SYMBOL(cmdq_pkt_clear_event);
+int cmdq_pkt_set_event(struct cmdq_pkt *pkt, u16 event)
+{
+ struct cmdq_instruction inst = { {0} };
+
+ if (event >= CMDQ_MAX_EVENT)
+ return -EINVAL;
+
+ inst.op = CMDQ_CODE_WFE;
+ inst.value = CMDQ_WFE_UPDATE | CMDQ_WFE_UPDATE_VALUE;
+ inst.event = event;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_set_event);
+
int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value)
{
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 42d2a30e6a70..ba2d811183a9 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -17,6 +17,7 @@
#define CMDQ_JUMP_PASS CMDQ_INST_SIZE
#define CMDQ_WFE_UPDATE BIT(31)
+#define CMDQ_WFE_UPDATE_VALUE BIT(16)
#define CMDQ_WFE_WAIT BIT(15)
#define CMDQ_WFE_WAIT_VALUE 0x1
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 3216ccfff4a9..ea26020e63bf 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -199,6 +199,15 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear);
*/
int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
+/**
+ * cmdq_pkt_set_event() - append set event command to the CMDQ packet
+ * @pkt: the CMDQ packet
+ * @event: the desired event to be set
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_set_event(struct cmdq_pkt *pkt, u16 event);
+
/**
* cmdq_pkt_poll() - Append polling command to the CMDQ packet, ask GCE to
* execute an instruction that wait for a specified
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 12/16] soc: mediatek: cmdq: add write_s_mask value function
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: devicetree, wsd_upstream, linux-kernel, dri-devel, HS Liao,
Dennis YC Hsieh, linux-mediatek, Houlong Wei, Bibby Hsieh, CK Hu,
linux-arm-kernel
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
add write_s_mask_value function in cmdq helper functions which
writes a constant value to address with mask and large dma
access support.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 21 +++++++++++++++++++++
include/linux/soc/mediatek/mtk-cmdq.h | 15 +++++++++++++++
2 files changed, 36 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 12095a1b701b..4b07da56c7bb 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -293,6 +293,27 @@ int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s_value);
+int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value, u32 mask)
+{
+ struct cmdq_instruction inst = { {0} };
+ int err;
+
+ inst.op = CMDQ_CODE_MASK;
+ inst.mask = ~mask;
+ err = cmdq_pkt_append_command(pkt, inst);
+ if (err < 0)
+ return err;
+
+ inst.op = CMDQ_CODE_WRITE_S_MASK;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.value = value;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index bb36750be58c..28a50c3cf6a1 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -165,6 +165,21 @@ int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
u16 addr_low, u32 value);
+/**
+ * cmdq_pkt_write_s_mask_value() - append write_s command with mask to the CMDQ
+ * packet which write value to a physical
+ * address
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @value: the specified target value
+ * @mask: the specified target mask
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value, u32 mask);
+
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 15/16] soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: devicetree, wsd_upstream, linux-kernel, dri-devel, HS Liao,
Dennis YC Hsieh, linux-mediatek, Houlong Wei, Bibby Hsieh, CK Hu,
linux-arm-kernel
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
Add clear parameter to let client decide if
event should be clear to 0 after GCE receive it.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
drivers/soc/mediatek/mtk-cmdq-helper.c | 5 +++--
include/linux/mailbox/mtk-cmdq-mailbox.h | 3 +--
include/linux/soc/mediatek/mtk-cmdq.h | 5 +++--
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 7daaabc26eb1..a065b3a412cf 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -488,7 +488,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
if (mtk_crtc->cmdq_client) {
cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
- cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
+ cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
mtk_crtc_ddp_config(crtc, cmdq_handle);
cmdq_pkt_finalize(cmdq_handle);
cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 5cf9e71b7900..9e9a4c81553a 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -315,15 +315,16 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear)
{
struct cmdq_instruction inst = { {0} };
+ u32 clear_option = clear ? CMDQ_WFE_UPDATE : 0;
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
inst.op = CMDQ_CODE_WFE;
- inst.value = CMDQ_WFE_OPTION;
+ inst.value = CMDQ_WFE_OPTION | clear_option;
inst.event = event;
return cmdq_pkt_append_command(pkt, inst);
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 3f6bc0dfd5da..42d2a30e6a70 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -27,8 +27,7 @@
* bit 16-27: update value
* bit 31: 1 - update, 0 - no update
*/
-#define CMDQ_WFE_OPTION (CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | \
- CMDQ_WFE_WAIT_VALUE)
+#define CMDQ_WFE_OPTION (CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE)
/** cmdq event maximum */
#define CMDQ_MAX_EVENT 0x3ff
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 9494b293bad9..3216ccfff4a9 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -183,11 +183,12 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
- * @event: the desired event type to "wait and CLEAR"
+ * @event: the desired event type to wait
+ * @clear: clear event or not after event arrive
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear);
/**
* cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 08/16] soc: mediatek: cmdq: add write_s function
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: devicetree, wsd_upstream, linux-kernel, dri-devel, HS Liao,
Dennis YC Hsieh, linux-mediatek, Houlong Wei, Bibby Hsieh, CK Hu,
linux-arm-kernel
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
add write_s function in cmdq helper functions which
writes value contains in internal register to address
with large dma access support.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 21 ++++++++++++++++++++-
include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
include/linux/soc/mediatek/mtk-cmdq.h | 20 ++++++++++++++++++++
3 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 33153d17c9d9..ee24c0ec0a24 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -18,6 +18,10 @@ struct cmdq_instruction {
union {
u32 value;
u32 mask;
+ struct {
+ u16 arg_c;
+ u16 src_reg;
+ };
};
union {
u16 offset;
@@ -29,7 +33,7 @@ struct cmdq_instruction {
struct {
u8 sop:5;
u8 arg_c_t:1;
- u8 arg_b_t:1;
+ u8 src_t:1;
u8 dst_t:1;
};
};
@@ -222,6 +226,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
}
EXPORT_SYMBOL(cmdq_pkt_write_mask);
+int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+ u16 addr_low, u16 src_reg_idx)
+{
+ struct cmdq_instruction inst = { {0} };
+
+ inst.op = CMDQ_CODE_WRITE_S;
+ inst.src_t = CMDQ_REG_TYPE;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.src_reg = src_reg_idx;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 121c3bb6d3de..ee67dd3b86f5 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -59,6 +59,7 @@ enum cmdq_code {
CMDQ_CODE_JUMP = 0x10,
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
+ CMDQ_CODE_WRITE_S = 0x90,
CMDQ_CODE_LOGIC = 0xa0,
};
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 83340211e1d3..d623f1aa7814 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -12,6 +12,8 @@
#include <linux/timer.h>
#define CMDQ_NO_TIMEOUT 0xffffffffu
+#define CMDQ_ADDR_HIGH(addr) ((u32)(((addr) >> 16) & GENMASK(31, 0)))
+#define CMDQ_ADDR_LOW(addr) ((u16)(addr) | BIT(1))
struct cmdq_pkt;
@@ -102,6 +104,24 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value);
int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask);
+/**
+ * cmdq_pkt_write_s() - append write_s command to the CMDQ packet
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @src_reg_idx: the CMDQ internal register ID which cache source value
+ * @mask: the specified target address mask, use U32_MAX if no need
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ * Support write value to physical address without subsys. Use CMDQ_ADDR_HIGH()
+ * to get high address and call cmdq_pkt_assign() to assign value into internal
+ * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low parameter when
+ * call to this function.
+ */
+int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+ u16 addr_low, u16 src_reg_idx);
+
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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