* [PATCH V7 4/4] dmaengine: qcom_hidma: add MSI support for interrupts
From: Andy Shevchenko @ 2016-10-21 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477067879-23750-5-git-send-email-okaya@codeaurora.org>
On Fri, Oct 21, 2016 at 7:37 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
> The interrupts can now be delivered as platform MSI interrupts on newer
> platforms. The code looks for a new OF and ACPI strings in order to enable
> the functionality.
> +#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
> +static void hidma_write_msi_msg(struct msi_desc *desc, struct msi_msg *msg)
> +{
> + struct device *dev = msi_desc_to_dev(desc);
> + struct hidma_dev *dmadev = dev_get_drvdata(dev);
> +
> + if (!desc->platform.msi_index) {
> + writel(msg->address_lo, dmadev->dev_evca + 0x118);
> + writel(msg->address_hi, dmadev->dev_evca + 0x11C);
> + writel(msg->data, dmadev->dev_evca + 0x120);
> + }
> +}
> +#endif
> +
> +static void hidma_free_msis(struct hidma_dev *dmadev)
> +{
> +#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
Perhaps one #ifdef and two definitions of functions?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 1/3] mtd: s3c2410: make ecc mode configurable via platform data
From: Sergio Prado @ 2016-10-21 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021182710.GA17279@kozik-lap>
On Fri, Oct 21, 2016 at 09:27:10PM +0300, Krzysztof Kozlowski wrote:
>
> I acked this twice (v1 and v2)... and still you are ignoring them. I am
> sorry, I am not gonna to ack this third time!
>
> For v2 I acked also other patches but it it is not there as well...
>
> BR,
> Krzysztof
I'm really sorry Krzysztof. This is my first patch series and I didn't
know I should add the acked-by tag to the patches (I thought it would be
done by the maintainer when the patches are accepted/applied).
I'll make sure to do it right next time.
Thanks for taking your time to reviewing and acking my patches.
Best regards,
Sergio Prado
--
Sergio Prado
Embedded Labworks
Office: +55 11 2628-3461
Mobile: +55 11 97123-3420
^ permalink raw reply
* [PATCH v2 3/4] soc: ti: Add ti_sci_pm_domains driver
From: Santosh Shilimkar @ 2016-10-21 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7h4m45plxr.fsf@baylibre.com>
On 10/21/2016 12:00 PM, Kevin Hilman wrote:
> Dave Gerlach <d-gerlach@ti.com> writes:
>
[...]
>
> BTW, what is the the status of the TI-SCI protocol drivers themselves?
> This can't be merged until that is or this won't even compile.
>
I was just about to ask the same question.
Regards,
Santosh
^ permalink raw reply
* [PATCH v2 3/4] soc: ti: Add ti_sci_pm_domains driver
From: Kevin Hilman @ 2016-10-21 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019203347.17893-4-d-gerlach@ti.com>
Dave Gerlach <d-gerlach@ti.com> writes:
> Introduce a ti_sci_pm_domains driver to act as a generic pm domain provider
> to allow each device to attach and associate it's ti-sci-id so that it can
> be controlled through the TI SCI protocol.
>
> This driver implements a simple genpd where each device node has
> a phandle to the power domain node and also must provide an index which
> represents the ID to be passed with TI SCI representing the device using a
> ti,sci-id property. Through this interface the genpd dev_ops start and
> stop hooks will use TI SCI to turn on and off each device as determined
> by pm_runtime usage.
>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> MAINTAINERS | 1 +
> arch/arm/mach-keystone/Kconfig | 1 +
> drivers/soc/ti/Kconfig | 12 +++
> drivers/soc/ti/Makefile | 1 +
> drivers/soc/ti/ti_sci_pm_domains.c | 198 +++++++++++++++++++++++++++++++++++++
> 5 files changed, 213 insertions(+)
> create mode 100644 drivers/soc/ti/ti_sci_pm_domains.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d894873c2bff..3eaac5ede847 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11894,6 +11894,7 @@ F: drivers/firmware/ti_sci*
> F: include/linux/soc/ti/ti_sci_protocol.h
> F: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> F: include/dt-bindings/genpd/k2g.h
> +F: drivers/soc/ti/ti_sci_pm_domains.c
>
> THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
> M: Hans Verkuil <hverkuil@xs4all.nl>
> diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
> index 24bd64dabdfc..18d49465cafb 100644
> --- a/arch/arm/mach-keystone/Kconfig
> +++ b/arch/arm/mach-keystone/Kconfig
> @@ -9,6 +9,7 @@ config ARCH_KEYSTONE
> select ARCH_SUPPORTS_BIG_ENDIAN
> select ZONE_DMA if ARM_LPAE
> select PINCTRL
> + select PM_GENERIC_DOMAINS if PM
> help
> Support for boards based on the Texas Instruments Keystone family of
> SoCs.
> diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
> index 3557c5e32a93..39e152abe6b9 100644
> --- a/drivers/soc/ti/Kconfig
> +++ b/drivers/soc/ti/Kconfig
> @@ -38,4 +38,16 @@ config WKUP_M3_IPC
> to communicate and use the Wakeup M3 for PM features like suspend
> resume and boots it using wkup_m3_rproc driver.
>
> +config TI_SCI_PM_DOMAINS
> + tristate "TI SCI PM Domains Driver"
> + depends on TI_SCI_PROTOCOL
> + depends on PM_GENERIC_DOMAINS
> + help
> + Generic power domain implementation for TI device implementing
> + the TI SCI protocol.
> +
> + To compile this as a module, choose M here. The module will be
> + called ti_sci_pm_domains. Note this is needed early in boot before
> + rootfs may be available.
> +
> endif # SOC_TI
> diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
> index 48ff3a79634f..7d572736c86e 100644
> --- a/drivers/soc/ti/Makefile
> +++ b/drivers/soc/ti/Makefile
> @@ -5,3 +5,4 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS) += knav_qmss.o
> knav_qmss-y := knav_qmss_queue.o knav_qmss_acc.o
> obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
> obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
> +obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
> diff --git a/drivers/soc/ti/ti_sci_pm_domains.c b/drivers/soc/ti/ti_sci_pm_domains.c
> new file mode 100644
> index 000000000000..ec76215d64c7
> --- /dev/null
> +++ b/drivers/soc/ti/ti_sci_pm_domains.c
> @@ -0,0 +1,198 @@
> +/*
> + * TI SCI Generic Power Domain Driver
> + *
> + * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
> + * J Keerthy <j-keerthy@ti.com>
> + * Dave Gerlach <d-gerlach@ti.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +#include <linux/slab.h>
> +#include <linux/soc/ti/ti_sci_protocol.h>
> +
> +/**
> + * struct ti_sci_genpd_dev_data: holds data needed for every device attached
> + * to this genpd
> + * @idx: index of the device that identifies it with the system
> + * control processor.
> + */
> +struct ti_sci_genpd_dev_data {
> + int idx;
> +};
If you use #power-domain-cells = <1>, you can drop this...
> +/**
> + * struct ti_sci_pm_domain: TI specific data needed for power domain
> + * @ti_sci: handle to TI SCI protocol driver that provides ops to
> + * communicate with system control processor.
> + * @dev: pointer to dev for the driver for devm allocs
> + * @pd: generic_pm_domain for use with the genpd framework
> + */
> +struct ti_sci_pm_domain {
> + const struct ti_sci_handle *ti_sci;
> + struct device *dev;
> + struct generic_pm_domain pd;
> +};
and add and 'idx' field to this which is populated on attach.
Thank you shouldn't need PATCH 1/4 which adds the new 'void * data'.
Otherwise, the driver looks pretty straight forward.
BTW, what is the the status of the TI-SCI protocol drivers themselves?
This can't be merged until that is or this won't even compile.
Kevin
^ permalink raw reply
* [PATCH v3 1/3] mtd: s3c2410: make ecc mode configurable via platform data
From: Marek Vasut @ 2016-10-21 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021182710.GA17279@kozik-lap>
On 10/21/2016 08:27 PM, Krzysztof Kozlowski wrote:
> On Thu, Oct 20, 2016 at 07:42:44PM -0200, Sergio Prado wrote:
>> Removing CONFIG_MTD_NAND_S3C2410_HWECC option and adding a ecc_mode
>> field in the drivers's platform data structure so it can be selectable
>> via platform data.
>>
>> Also setting this field to NAND_ECC_SOFT in all boards using this
>> driver since none of them had CONFIG_MTD_NAND_S3C2410_HWECC enabled.
>>
>> Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
>> ---
>> arch/arm/mach-s3c24xx/common-smdk.c | 1 +
>> arch/arm/mach-s3c24xx/mach-anubis.c | 1 +
>> arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 +
>> arch/arm/mach-s3c24xx/mach-bast.c | 1 +
>> arch/arm/mach-s3c24xx/mach-gta02.c | 1 +
>> arch/arm/mach-s3c24xx/mach-jive.c | 1 +
>> arch/arm/mach-s3c24xx/mach-mini2440.c | 1 +
>> arch/arm/mach-s3c24xx/mach-osiris.c | 1 +
>> arch/arm/mach-s3c24xx/mach-qt2410.c | 1 +
>> arch/arm/mach-s3c24xx/mach-rx1950.c | 1 +
>> arch/arm/mach-s3c24xx/mach-rx3715.c | 1 +
>> arch/arm/mach-s3c24xx/mach-vstms.c | 1 +
>> arch/arm/mach-s3c64xx/mach-hmt.c | 1 +
>> arch/arm/mach-s3c64xx/mach-mini6410.c | 1 +
>> arch/arm/mach-s3c64xx/mach-real6410.c | 1 +
>> drivers/mtd/nand/Kconfig | 9 --
>> drivers/mtd/nand/s3c2410.c | 119 +++++++++++++------------
>> include/linux/platform_data/mtd-nand-s3c2410.h | 6 +-
>> 18 files changed, 79 insertions(+), 70 deletions(-)
>>
>
> I acked this twice (v1 and v2)... and still you are ignoring them. I am
> sorry, I am not gonna to ack this third time!
Hi, um, I am kinda new to this mess, what's going on ? You ACKed
previous patches, next revision was submitted, so you need to ACK
the next revision too (due to the changes).
> For v2 I acked also other patches but it it is not there as well...
>
> BR,
> Krzysztof
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Kevin Hilman @ 2016-10-21 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019203347.17893-3-d-gerlach@ti.com>
Dave Gerlach <d-gerlach@ti.com> writes:
> Add a generic power domain implementation, TI SCI PM Domains, that
> will hook into the genpd framework and allow the TI SCI protocol to
> control device power states.
>
> Also, provide macros representing each device index as understood
> by TI SCI to be used in the device node power-domain references.
> These are identifiers for the K2G devices managed by the PMMC.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54 +++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
> 3 files changed, 146 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> create mode 100644 include/dt-bindings/genpd/k2g.h
>
> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> new file mode 100644
> index 000000000000..32f38a349656
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> @@ -0,0 +1,54 @@
> +Texas Instruments TI-SCI Generic Power Domain
> +---------------------------------------------
> +
> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
> +responsible for controlling the state of the IPs that are present.
> +Communication between the host processor running an OS and the system
> +controller happens through a protocol known as TI-SCI [1]. This pm domain
> +implementation plugs into the generic pm domain framework and makes use of
> +the TI SCI protocol power on and off each device when needed.
> +
> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +PM Domain Node
> +==============
> +The PM domain node represents the global PM domain managed by the PMMC,
> +which in this case is the single implementation as documented by the generic
> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
> +
> +Required Properties:
> +--------------------
> +- compatible: should be "ti,sci-pm-domain"
> +- #power-domain-cells: Must be 0.
> +- ti,sci: Phandle to the TI SCI device to use for managing the devices.
>
> +Example:
> +--------------------
> +k2g_pds: k2g_pds {
should use generic name like "power-contoller", e.g. k2g_pds: power-controller
> + compatible = "ti,sci-pm-domain";
> + #power-domain-cells = <0>;
> + ti,sci = <&pmmc>;
> +};
> +
> +PM Domain Consumers
> +===================
> +Hardware blocks that require SCI control over their state must provide
> +a reference to the sci-pm-domain they are part of and a unique device
> +specific ID that identifies the device.
> +
> +Required Properties:
> +--------------------
> +- power-domains: phandle pointing to the corresponding PM domain node.
> +- ti,sci-id: index representing the device id to be passed oevr SCI to
> + be used for device control.
This ID doesn't look right.
Why not use #power-domain-cells = <1> and pass the index in the DT? ...
> +See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g.
> +
> +Example:
> +--------------------
> +uart0: serial at 02530c00 {
> + compatible = "ns16550a";
> + ...
> + power-domains = <&k2g_pds>;
> + ti,sci-id = <K2G_DEV_UART0>;
... like this:
power-domains = <&k2g_pds K2G_DEV_UART0>;
Kevin
^ permalink raw reply
* [PATCH 0/5] Support for LEGO MINDSTORTMS EV3
From: Lennart Sorensen @ 2016-10-21 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-1-git-send-email-david@lechnology.com>
On Fri, Oct 21, 2016 at 01:36:52PM -0500, David Lechner wrote:
> This patch series adds support for LEGO MINDSTORTMS EV3[1]. This is a TI AM1808
> based board.
>
> This patch series has been tested working (along with some hacks to fix the
> GPIOs) on an EV3.
>
> There are still quite a few additional new drivers that need to be submitted
> to get everything working. This patch series just adds support for the parts
> that already have mainline kernel drivers.
>
> I have a plan/driver in progress for many of the components[2], but I could use
> some advice on a few particulars.
>
> Bluetooth: This needs a driver to sequence a GPIO to take the Bluetooth chip
> out of shutdown *after* the Bluetooth clock has been configured and started.
> Is there a generic driver that can do this sort of thing? Or, if not, which
> subsystem should the new driver go in?
>
> Input and output ports: These ports are capable of hotplugging various devices,
> such as sensors and motors. I have written a driver for these that can detect
> most devices. I created a new subsystem for this called `lego-port`. However,
> I am wondering if the existing phy or extcon subsystems might be a good fit for
> this sort of thing.
Both this cover and patch 5/5 has MINDSTORTMS instead of MINDSTORMS in
a few places (including the subject line).
--
Len Sorensen
^ permalink raw reply
* Disabling an interrupt in the handler locks the system up
From: Mason @ 2016-10-21 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a79e2d2c-8ec8-744f-50fb-8c39216aa23e@arm.com>
On 21/10/2016 19:46, Marc Zyngier wrote:
> On 21/10/16 17:37, Mason wrote:
>
>> On my platform, one HW block pulls the interrupt line high
>> as long as it remains idle, and low when it is busy.
>>
>> The device tree node is:
>>
>> test at 22222 {
>> compatible = "vendor,testme";
>> interrupts = <23 IRQ_TYPE_LEVEL_HIGH>;
>> };
>
> I assume that this is for the sake of the discussion, and that you do
> not actually intend to put together such a monstrosity.
It's just missing a reg properties to be a valid node, right?
>> I wrote a minimal driver which registers the irq.
>> And in the interrupt handler, I disable said irq.
>>
>> Since the irq is IRQ_TYPE_LEVEL_HIGH, it will fire as soon as
>> it is registered (because the block is idle).
>>
>> Here is the code I've been running, request_irq doesn't return.
>
> [...]
>
>> And here's what I get when I try to load the module:
>> (I'm using the default CONFIG_RCU_CPU_STALL_TIMEOUT=21)
>
> [...]
>
>> Are we not supposed to disable the irq in the handler?
>
> You can. It then depends on what your interrupt controller does to
> actually ensure that the interrupt is disabled. Only you can trace it on
> your HW to find out.
I'm using an upstream driver on v4.9-rc1
http://lxr.free-electrons.com/source/drivers/irqchip/irq-tango.c
Given that the system locks up, is it possible there is a bug
in the driver?
Which call-back handles enabling/disabling interrupts?
Regards.
^ permalink raw reply
* [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts
From: David Lechner @ 2016-10-21 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-1-git-send-email-david@lechnology.com>
This adds a device tree definition file for LEGO MINDSTORMS EV3.
What is working:
* Pin muxing
* MicroSD card reader
* UART on input port 1
What is partially working:
* Buttons - working after GPIO fix
* LEDs - working after GPIO fix
* Poweroff/reset - working after GPIO fix
* Flash memory - driver loads but can't read the block devices - this is
probably due to the fact that we are not able to configure the SPI to
use DMA via device tree
* EEPROM - there seems to be a hardware bug that causes the first byte
read to be corrupted - this can be worked around by adding an I2C stop
between writing the register and reading the data, but the at24 driver
does not have an option to do this
What is not working/to be added later:
* Display - waiting for "tiny DRM" to be mainlined
* Speaker - needs new PWM sound driver
* USB - waiting for OHCI and MUSB device tree support to be mainlined
* ADC - needs new iio driver
* GPIOs - broken because of recent changes to core gpio driver
* Bluetooth - needs new driver for sequencing power/enable/clock
* Input and output ports - need some sort of new phy or extcon driver
* Battery - needs new power supply driver (depends on ADC iio driver)
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/lego-ev3.dts | 454 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 456 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/lego-ev3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f80f5b7..5f91c1a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -116,7 +116,8 @@ dtb-$(CONFIG_ARCH_CLPS711X) += \
dtb-$(CONFIG_ARCH_DAVINCI) += \
da850-lcdk.dtb \
da850-enbw-cmc.dtb \
- da850-evm.dtb
+ da850-evm.dtb \
+ lego-ev3.dtb
dtb-$(CONFIG_ARCH_DIGICOLOR) += \
cx92755_equinox.dtb
dtb-$(CONFIG_ARCH_EFM32) += \
diff --git a/arch/arm/boot/dts/lego-ev3.dts b/arch/arm/boot/dts/lego-ev3.dts
new file mode 100644
index 0000000..a6b4c7d
--- /dev/null
+++ b/arch/arm/boot/dts/lego-ev3.dts
@@ -0,0 +1,454 @@
+/*
+ * Device tree for LEGO MINDSTORMS EV3
+ *
+ * Copyright (C) 2016 David Lechner <david@lechnology.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation, version 2.
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+
+#include "da850.dtsi"
+
+/ {
+ compatible = "lego,ev3", "ti,da850";
+ model = "LEGO MINDSTORMS EV3";
+
+ soc at 1c00000 {
+ /*
+ * (ab)using pinctrl-single to disable all internal pullups/
+ * pulldowns on I/O.
+ */
+ pinmux at 22c00c {
+ compatible = "pinctrl-single";
+ reg = <0x22c00c 0x4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0xf>;
+ /*
+ * There is a bug in pinctrl-single that prevents us
+ * from setting function-mask to 1, so doing things
+ * in groups of 4. Doesn't really matter since we are
+ * disabling all at once anyway.
+ */
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pupu_disable>;
+
+ pupu_disable: pinmux_all_pins {
+ pinctrl-single,bits = <
+ 0x0 0x00000000 0xffffffff
+ >;
+ };
+ };
+ };
+
+ /*
+ * The buttons on the EV3 are mapped to keyboard keys.
+ */
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ label = "EV3 buttons";
+ pinctrl-names = "default";
+ pinctrl-0 = <&button_pins>;
+
+ enter {
+ label = "EV3 Button ENTER";
+ linux,code = <KEY_ENTER>;
+ gpios = <&gpio 29 GPIO_ACTIVE_HIGH>;
+ };
+ left {
+ label = "EV3 Button LEFT";
+ linux,code = <KEY_LEFT>;
+ gpios = <&gpio 102 GPIO_ACTIVE_HIGH>;
+ };
+ back {
+ label = "EV3 Button BACK";
+ linux,code = <KEY_BACKSPACE>;
+ gpios = <&gpio 106 GPIO_ACTIVE_HIGH>;
+ };
+ right {
+ label = "EV3 Button RIGHT";
+ linux,code = <KEY_RIGHT>;
+ gpios = <&gpio 124 GPIO_ACTIVE_HIGH>;
+ };
+ down {
+ label = "EV3 Button DOWN";
+ linux,code = <KEY_DOWN>;
+ gpios = <&gpio 126 GPIO_ACTIVE_HIGH>;
+ };
+ up {
+ label = "EV3 Button UP";
+ linux,code = <KEY_UP>;
+ gpios = <&gpio 127 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ /*
+ * The EV3 has two built-in bi-color LEDs behind the buttons.
+ */
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins>;
+
+ left_red {
+ label = "led1:red:brick-status";
+ /* GP6[13] */
+ gpios = <&gpio 103 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+ left_green {
+ label = "led1:green:brick-status";
+ /* GP6[7] */
+ gpios = <&gpio 108 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+ right_red {
+ label = "led2:red:brick-status";
+ /* GP6[12] */
+ gpios = <&gpio 109 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+ right_green {
+ label = "led2:green:brick-status";
+ /* GP6[14] */
+ gpios = <&gpio 110 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+ };
+
+ /*
+ * The EV3 is powered down by turning off the main 5V supply.
+ */
+ gpio-poweroff {
+ compatible = "gpio-poweroff";
+ /* low signal powers off the board */
+ gpios = <&gpio 107 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&system_power_pin>;
+ };
+
+ /*
+ * The Bluetooth chip requires a clock at 32768Hz. One of the PWMs
+ * is used to generate this signal.
+ */
+ bt-slow-clock {
+ status = "disabled";
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "slow_clk";
+ pwms = <&ecap2 0 30517>;
+ };
+};
+
+&pmx_core {
+ status = "okay";
+
+ spi0_cs3_pin: pinmux_spi0_cs3_pin {
+ pinctrl-single,bits = <
+ /* CS3 */
+ 0xc 0x01000000 0x0f000000
+ >;
+ };
+ mmc0_cd_pin: pinmux_mmc0_cd {
+ pinctrl-single,bits = <
+ /* GP5[14] */
+ 0x2C 0x00000080 0x000000f0
+ >;
+ };
+ button_pins: pinmux_button_pins {
+ pinctrl-single,bits = <
+ /* GP1[13] */
+ 0x8 0x00000800 0x00000f00
+ /* GP6[10] */
+ 0x34 0x00800000 0x00f00000
+ /* GP6[6] */
+ 0x38 0x00000080 0x000000f0
+ /* GP7[12], GP7[14], GP7[15] */
+ 0x40 0x00808800 0x00f0ff00
+ >;
+ };
+ led_pins: pinmux_led_pins {
+ pinctrl-single,bits = <
+ /* GP6[12], GP6[13], GP6[14] */
+ 0x34 0x00008880 0x0000fff0
+ /* GP6[7] */
+ 0x38 0x00000008 0x0000000f
+ >;
+ };
+ system_power_pin: pinmux_system_power {
+ pinctrl-single,bits = <
+ /* GP6[11] */
+ 0x34 0x00080000 0x000f0000
+ >;
+ };
+ in1_pins: pinmux_in1_pins {
+ pinctrl-single,bits = <
+ /* GP0[15] */
+ 0x0 0x00000008 0x0000000f
+ /* GP0[2] */
+ 0x4 0x00800000 0x00f00000
+ /* GP2[2] */
+ 0x18 0x00800000 0x00f00000
+ /* GP8[10], GP8[11] */
+ 0x48 0x88000000 0xff000000
+ >;
+ };
+ in2_pins: pinmux_in2_pins {
+ pinctrl-single,bits = <
+ /* GP0[13], GP0[14] */
+ 0x0 0x00000880 0x00000ff0
+ /* GP8[12], GP8[14], GP8[15] */
+ 0x48 0x00808800 0x00f0ff00
+ >;
+ };
+ in3_pins: pinmux_in3_pins {
+ pinctrl-single,bits = <
+ /* GP0[12] */
+ 0x0 0x00008000 0x0000f000
+ /* GP1[14] */
+ 0x8 0x00000080 0x000000f0
+ /* GP7[11] */
+ 0x40 0x08000000 0x0f000000
+ /* GP7[9] */
+ 0x44 0x00000008 0x0000000f
+ /* GP8[9] */
+ 0x4c 0x00000008 0x0000000f
+ >;
+ };
+ in4_pins: pinmux_in4_pins {
+ pinctrl-single,bits = <
+ /* GP0[1] */
+ 0x4 0x08000000 0x0f000000
+ /* GP1[15] */
+ 0x8 0x00000008 0x0000000f
+ /* GP7[10] */
+ 0x40 0x80000000 0xf0000000
+ /* GP7[8] */
+ 0x44 0x00000080 0x000000f0
+ /* GP6[4] */
+ 0x4c 0x00000800 0x00000f00
+ >;
+ };
+ outa_pins: pinmux_outa_pins {
+ pinctrl-single,bits = <
+ /* GP0[4] */
+ 0x4 0x00008000 0x0000f000
+ /* GP3[15] */
+ 0x1c 0x00000008 0x0000000f
+ /* GP3[6] */
+ 0x20 0x00000080 0x000000f0
+ /* GP5[11] */
+ 0x2c 0x00080000 0x000f0000
+ /* GP5[4] */
+ 0x30 0x00008000 0x0000f000
+ >;
+ };
+ outb_pins: pinmux_outb_pins {
+ pinctrl-single,bits = <
+ /* GP0[3] */
+ 0x4 0x00080000 0x000f0000
+ /* GP2[9] */
+ 0x14 0x08000000 0x0f000000
+ /* GP2[1], GP2[5] */
+ 0x18 0x08000800 0x0f000f00
+ /* GP5[11] */
+ 0x2c 0x80000000 0xf0000000
+ >;
+ };
+ outc_pins: pinmux_outc_pins {
+ pinctrl-single,bits = <
+ /* GP3[8], GP3[14] */
+ 0x1c 0x80000080 0xf00000f0
+ /* GP5[9], GP5[13] */
+ 0x2c 0x08000800 0x0f000f00
+ /* GP6[8] */
+ 0x34 0x80000000 0xf0000000
+ >;
+ };
+ outd_pins: pinmux_outd_pins {
+ pinctrl-single,bits = <
+ /* GP2[8] */
+ 0x14 0x80000000 0xf0000000
+ /* GP5[10], GP5[15] */
+ 0x2c 0x00800008 0x00f0000f
+ /* GP5[3] */
+ 0x30 0x00080000 0x000f0000
+ /* GP6[9] */
+ 0x34 0x08000000 0x0f000000
+ >;
+ };
+ sound_pins: pinmux_sound_pins {
+ pinctrl-single,bits = <
+ /* GP6[15] */
+ 0x34 0x00000008 0x0000000f
+ >;
+ };
+ usb11_pins: pinmux_usb11_pins {
+ pinctrl-single,bits = <
+ /* GP6[5] */
+ 0x40 0x00000080 0x000000f0
+ /* GP6[3] */
+ 0x4c 0x00008000 0x0000f000
+ >;
+ };
+};
+
+/* Input port 2 */
+&serial0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&serial0_rxtx_pins>;
+};
+
+/* Input port 1 */
+&serial1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&serial1_rxtx_pins>;
+};
+
+/* Bluetooth */
+&serial2 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&serial2_rxtx_pins>, <&serial2_rtscts_pins>;
+};
+
+&rtc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+
+ /*
+ * EEPROM contains the first stage bootloader, HW ID and Bluetooth MAC.
+ */
+ eeprom at 50 {
+ compatible = "at24,24c128";
+ pagesize = <64>;
+ read-only;
+ reg = <0x50>;
+ };
+};
+
+&wdt {
+ status = "okay";
+};
+
+&mmc0 {
+ status = "okay";
+ max-frequency = <50000000>;
+ bus-width = <4>;
+ cd-gpios = <&gpio 94 GPIO_ACTIVE_LOW>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>, <&mmc0_cd_pin>;
+};
+
+&ehrpwm0 {
+ status = "okay";
+ pinctrl-names = "default";
+ /* SOUND_ARMA */
+ pinctrl-0 = <&ehrpwm0b_pins>;
+};
+
+&ehrpwm1 {
+ status = "disabled";
+ pinctrl-names = "default";
+ /* MBPWM, MAPWM */
+ pinctrl-0 = <&ehrpwm1a_pins>, <&ehrpwm1b_pins>;
+};
+
+&ecap0 {
+ status = "okay";
+ pinctrl-names = "default";
+ /* MCPWM */
+ pinctrl-0 = <&ecap0_pins>;
+};
+
+&ecap1 {
+ status = "disabled";
+ pinctrl-names = "default";
+ /* MDPWM */
+ pinctrl-0 = <&ecap1_pins>;
+};
+
+&ecap2 {
+ status = "disabled";
+ pinctrl-names = "default";
+ /* BTSLOWCLK */
+ pinctrl-0 = <&ecap2_pins>;
+};
+
+&spi0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
+ dmas = <&edma0 14 0>, <&edma0 15 0>;
+ dma-names = "rx", "tx";
+
+ spi-flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q128a13", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ ti,spi-wdelay = <8>;
+
+ partition at 0 {
+ label = "U-Boot";
+ reg = <0 0x40000>;
+ };
+
+ partition at 40000 {
+ label = "U-Boot Env";
+ reg = <0x40000 0x10000>;
+ };
+
+ partition at 50000 {
+ label = "Kernel";
+ reg = <0x50000 0x200000>;
+ };
+
+ partition at 250000 {
+ label = "Filesystem";
+ reg = <0x250000 0xa50000>;
+ };
+
+ partition at cb0000 {
+ label = "Storage";
+ reg = <0xcb0000 0x2f0000>;
+ };
+ };
+
+ /* TODO: ADC goes here */
+};
+
+&spi1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins>, <&spi1_cs0_pin>;
+
+ /* TODO: LCD Display goes here */
+};
+
+&gpio {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] ARM: davinci: enable LEDs default-on trigger in default config
From: David Lechner @ 2016-10-21 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-1-git-send-email-david@lechnology.com>
The LEDs default-on trigger is nice to have. For example, it can be used
to configure a LED as a power indicator.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/configs/davinci_all_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 9d7f0bc..e380743 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -181,6 +181,7 @@ CONFIG_LEDS_GPIO=m
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_HEARTBEAT=m
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_OMAP=m
CONFIG_DMADEVICES=y
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] ARM: davinci: enable gpio poweroff in default config
From: David Lechner @ 2016-10-21 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-1-git-send-email-david@lechnology.com>
The gpio-poweroff driver is needed by LEGO MINDSTORMS EV3 (AM1808 based
board).
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/configs/davinci_all_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 9254609..9d7f0bc 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -117,6 +117,8 @@ CONFIG_SPI_DAVINCI=m
CONFIG_PINCTRL_SINGLE=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_PCA953X=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_GPIO=y
CONFIG_WATCHDOG=y
CONFIG_DAVINCI_WATCHDOG=m
CONFIG_MFD_DM355EVM_MSP=y
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] ARM: davinci: Don't append git rev to local version
From: David Lechner @ 2016-10-21 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-1-git-send-email-david@lechnology.com>
In the davinci default configuration, don't append the git revision to
the local kernel version by. This seems like the more desirable default
value.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/configs/davinci_all_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index a2f89a3..9254609 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -1,3 +1,4 @@
+# CONFIG_LOCALVERSION_AUTO is not set
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
--
2.7.4
^ permalink raw reply related
* [PATCH 1/5] ARM: davinci: Compile MMC in kernel
From: David Lechner @ 2016-10-21 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-1-git-send-email-david@lechnology.com>
This changes the davinci default configuration to compile the davinci
MMC driver into the kernel. This allows booting from an SD card without
requiring an initrd containing the kernel module.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/configs/davinci_all_defconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 58d04f1..a2f89a3 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -169,9 +169,9 @@ CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_G_PRINTER=m
CONFIG_USB_CDC_COMPOSITE=m
-CONFIG_MMC=m
+CONFIG_MMC=y
# CONFIG_MMC_BLOCK_BOUNCE is not set
-CONFIG_MMC_DAVINCI=m
+CONFIG_MMC_DAVINCI=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=m
CONFIG_LEDS_GPIO=m
--
2.7.4
^ permalink raw reply related
* [PATCH 0/5] Support for LEGO MINDSTORTMS EV3
From: David Lechner @ 2016-10-21 18:36 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds support for LEGO MINDSTORTMS EV3[1]. This is a TI AM1808
based board.
This patch series has been tested working (along with some hacks to fix the
GPIOs) on an EV3.
There are still quite a few additional new drivers that need to be submitted
to get everything working. This patch series just adds support for the parts
that already have mainline kernel drivers.
I have a plan/driver in progress for many of the components[2], but I could use
some advice on a few particulars.
Bluetooth: This needs a driver to sequence a GPIO to take the Bluetooth chip
out of shutdown *after* the Bluetooth clock has been configured and started.
Is there a generic driver that can do this sort of thing? Or, if not, which
subsystem should the new driver go in?
Input and output ports: These ports are capable of hotplugging various devices,
such as sensors and motors. I have written a driver for these that can detect
most devices. I created a new subsystem for this called `lego-port`. However,
I am wondering if the existing phy or extcon subsystems might be a good fit for
this sort of thing.
[1]: http://mindstorms.lego.com
[2]: https://github.com/ev3dev/lego-linux-drivers/tree/master/evb
David Lechner (5):
ARM: davinci: Compile MMC in kernel
ARM: davinci: Don't append git rev to local version
ARM: davinci: enable gpio poweroff in default config
ARM: davinci: enable LEDs default-on trigger in default config
ARM: dts: Add LEGO MINDSTORTMS EV3 dts
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/lego-ev3.dts | 454 +++++++++++++++++++++++++++++++++
arch/arm/configs/davinci_all_defconfig | 8 +-
3 files changed, 462 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/boot/dts/lego-ev3.dts
--
2.7.4
^ permalink raw reply
* [PATCH v3 0/8] PM / Domains: DT support for domain idle states & atomic PM domains
From: Kevin Hilman @ 2016-10-21 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFpQwOkXUk8wT6sZ-Ad4XpTnyodK5m24fYJ3P+1QtS0XOA@mail.gmail.com>
Ulf Hansson <ulf.hansson@linaro.org> writes:
> On 14 October 2016 at 19:47, Lina Iyer <lina.iyer@linaro.org> wrote:
>> Hi all,
>>
>> Changes since v2 [3] -
>> - Addressed review comments from v2.
>> - domain-idle-states documentation updated
>> - fixed compiler issues with imx driver
>> - minor code change in pm_domains.c
>> - The series is available at [4].
>>
>> Changes since v1 [2] -
>> - Addressed review comments from v1.
>> - Fixes around dynamic allocation of genpd states
>> - Used OF method for iterating phandles
>> - Updated documentation, examples
>> - Rename state variable (provider -> fwnode)
>> - The series is available at [3].
>>
>> The changes from [1] are -
>> - Allocating memory for domain idle states dynamically
>> - Conform to naming conventions for internal and exported genpd functions
>> - DT binding example for domain-idle-state
>> - Use fwnode instead of of_node
>> - Handle atomic case for removal of PM Domain
>> - Rebase on top of Rafael's pm/genpd tree
>>
>> Thanks,
>> Lina
>>
>> Lina Iyer (8):
>> PM / Domains: Make genpd state allocation dynamic
>> PM / Domain: Add residency property to genpd states
>> PM / Domains: Allow domain power states to be read from DT
>> PM / Domains: Save the fwnode in genpd_power_state
>> dt/bindings: Update binding for PM domain idle states
>> PM / Domains: Abstract genpd locking
>> PM / Domains: Support IRQ safe PM domains
>> PM / doc: Update device documentation for devices in IRQ safe PM
>> domains
>>
>> .../devicetree/bindings/power/power_domain.txt | 43 +++
>> Documentation/power/devices.txt | 9 +-
>> arch/arm/mach-imx/gpc.c | 17 +-
>> drivers/base/power/domain.c | 358 +++++++++++++++++----
>> include/linux/pm_domain.h | 28 +-
>> 5 files changed, 383 insertions(+), 72 deletions(-)
>>
>
> Rafael, Lina,
>
> This looks good to me! Unless any other objections, I suggest to apply
> this to get it tested in linux-next.
Looks like it might be a little late now, but anyways
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [PATCH v3 1/3] mtd: s3c2410: make ecc mode configurable via platform data
From: Krzysztof Kozlowski @ 2016-10-21 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476999766-32526-2-git-send-email-sergio.prado@e-labworks.com>
On Thu, Oct 20, 2016 at 07:42:44PM -0200, Sergio Prado wrote:
> Removing CONFIG_MTD_NAND_S3C2410_HWECC option and adding a ecc_mode
> field in the drivers's platform data structure so it can be selectable
> via platform data.
>
> Also setting this field to NAND_ECC_SOFT in all boards using this
> driver since none of them had CONFIG_MTD_NAND_S3C2410_HWECC enabled.
>
> Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> ---
> arch/arm/mach-s3c24xx/common-smdk.c | 1 +
> arch/arm/mach-s3c24xx/mach-anubis.c | 1 +
> arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 +
> arch/arm/mach-s3c24xx/mach-bast.c | 1 +
> arch/arm/mach-s3c24xx/mach-gta02.c | 1 +
> arch/arm/mach-s3c24xx/mach-jive.c | 1 +
> arch/arm/mach-s3c24xx/mach-mini2440.c | 1 +
> arch/arm/mach-s3c24xx/mach-osiris.c | 1 +
> arch/arm/mach-s3c24xx/mach-qt2410.c | 1 +
> arch/arm/mach-s3c24xx/mach-rx1950.c | 1 +
> arch/arm/mach-s3c24xx/mach-rx3715.c | 1 +
> arch/arm/mach-s3c24xx/mach-vstms.c | 1 +
> arch/arm/mach-s3c64xx/mach-hmt.c | 1 +
> arch/arm/mach-s3c64xx/mach-mini6410.c | 1 +
> arch/arm/mach-s3c64xx/mach-real6410.c | 1 +
> drivers/mtd/nand/Kconfig | 9 --
> drivers/mtd/nand/s3c2410.c | 119 +++++++++++++------------
> include/linux/platform_data/mtd-nand-s3c2410.h | 6 +-
> 18 files changed, 79 insertions(+), 70 deletions(-)
>
I acked this twice (v1 and v2)... and still you are ignoring them. I am
sorry, I am not gonna to ack this third time!
For v2 I acked also other patches but it it is not there as well...
BR,
Krzysztof
^ permalink raw reply
* [PATCH/RFC 4/4] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-10-21 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7196231.EBkNfFgrcH@wuerfel>
Hi Arnd,
On Wed, Oct 19, 2016 at 12:59 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, October 19, 2016 10:02:57 AM CEST Geert Uytterhoeven wrote:
>> On Mon, Oct 10, 2016 at 4:23 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Tuesday, October 4, 2016 11:09:27 AM CEST Geert Uytterhoeven wrote:
>> >> +static const struct renesas_family fam_rza __initconst = {
>> >> + .name = "RZ/A",
>> >> +};
>> >
>> > I'm not sure about the relationship between this one and the others,
>> > maybe it should be treated in the same way as emev2 and left out from
>> > this driver?
>>
>> While RZ/A doesn't have a version registers (AFAIK), it shares several
>> drivers with the other SoCs (SH/R-Mobile, R-Car).
>> Hence I'd like to keep it, so we can match for it in these drivers when
>> needed. It has e.g. a different variant of the serial port (SCIF), more
>> closely to the one on SH2 rather than SH4.
>
> I'd prefer seeing a separate soc driver for that one.
OK, that can be done.
>> >> +static const struct renesas_family fam_rmobile __initconst = {
>> >> + .name = "R-Mobile",
>> >> + .reg = 0xe600101c, /* CCCR (Common Chip Code Register) */
>> >> +};
>> >> +
>> >> +static const struct renesas_family fam_rcar_gen1 __initconst = {
>> >> + .name = "R-Car Gen1",
>> >> + .reg = 0xff000044, /* PRR (Product Register) */
>> >> +};
>> >> +
>> >> +static const struct renesas_family fam_rcar_gen2 __initconst = {
>> >> + .name = "R-Car Gen2",
>> >> + .reg = 0xff000044, /* PRR (Product Register) */
>> >> +};
>> >> +
>> >> +static const struct renesas_family fam_rcar_gen3 __initconst = {
>> >> + .name = "R-Car Gen3",
>> >> + .reg = 0xfff00044, /* PRR (Product Register) */
>> >> +};
>> >> +
>> >> +static const struct renesas_family fam_rzg __initconst = {
>> >> + .name = "RZ/G",
>> >> + .reg = 0xff000044, /* PRR (Product Register) */
>> >> +};
>> >> +
>> >> +static const struct renesas_family fam_shmobile __initconst = {
>> >> + .name = "SH-Mobile",
>> >> + .reg = 0xe600101c, /* CCCR (Common Chip Code Register) */
>> >> +};
>> >
>> > These seem to fall into two distinct categories, maybe there is a
>> > better way to group them. What device contain the two kinds of
>> > registers (PRR, CCCR)?
>>
>> Actually there are three (notice the extra "f" on R-Car Gen3 ;-)
>
> I see. Hopefully this is just the same register block at a different
> location though.
More or less.
>> Some SoCs have only CCCR, others have only PRR, some have both.
>> On some SoCs one of them can be accessed from the RealTime CPU
>> core (SH) only.
>> On some SoCs the register is not documented, but present.
>> If the PRR exists, it's a better choice, as it contains additional information
>> in the high order bits (representing the presence of each big (CA15/CA57),
>> little (CA7/CA53), and RT (CR7) CPU core). Currently we don't use that
>> information, though.
>>
>> Grouping them in some other way means we would loose the family name,
>> which is exposed through soc_dev_attr->family.
>> The usefulness of family names is debatable though, as this is more an
>> issue of marketing business.
>
> How about having a table to look up the family name by the value
> of the PRR or CCCR then?
Unfortunately there exist SoCs from different families using the same
product ID.
And different SoCs from the same family may have a revision register
or not (e.g. R-Car H1 has, M1A hasn't).
>> > Hardcoding the register address seems rather ugly here, so maybe
>> > there is a way to have two separate probe methods based on the
>> > surrounding register range, and then bind to that?
>>
>> There's no simple relation between CCCR/PRR and other register blocks.
>> I prefer not to add these to DT, as that would add one more worm to the
>> backwards compatibility can.
>
> Hmm, I understand the concern about compatibility with existing DT files,
> but I also really hate to see hardcoded register addresses.
>
> Any reason against requiring the DT node for future chips though?
For future SoCs, we can easily make it mandatory.
> How about this:
>
> The driver could report the hardcoded strings for the SoCs it already
> knows about (you have the table anyway) and not report the revision
> unless there is a regmap containing the CCCR or the PRR, in which
> case you use that. Future SoCs will provide the PRR (I assume
> CCCR is only used on the older ones) through a syscon regmap
> that we can use to find out the exact revision as well.
>
> The existing DT files can gain the syscon device so you can report
> the revision on those machines as well, unless you use an old DTB.
Hmm... That means that if we have to add a driver quirk to distinguish
between different revisions of the same SoC, we have to update the
DTB anyway, to add the CCCR/PRR device node.
We might as well just change the compatible value in that DTB for the
device that needs the quirk. Which is what we'd like to avoid in the
first place.
>> >> +static const struct of_device_id renesas_socs[] __initconst = {
>> >> +#ifdef CONFIG_ARCH_EMEV2
>> >> + { .compatible = "renesas,emev2", .data = &soc_emev2 },
>> >> +#endif
>> >> +#ifdef CONFIG_ARCH_R7S72100
>> >> + { .compatible = "renesas,r7s72100", .data = &soc_rz_a1h },
>> >> +#endif
>> >> +#ifdef CONFIG_ARCH_R8A73A4
>> >
>> > I think the #ifdefs here will result in warnings for unused symbols
>> > when the Kconfig symbols are disabled.
>>
>> Originally I had __maybe_unused, but it didn't seem to be needed.
>> Do you know which compiler needs it, so I can check?
>
> Ah, I remember now: gcc doesn't warn for 'static const' variables
> unless we pass -Wunused-const, which should be enabled with "make W=1",
> and we might make that the default in the future (after fixing the
> handful of drivers currently relying on this).
OK.
> Why not just drop all the #ifdef here? There should be very little
> overhead in size, especially if all the data is __initconst.
It still saves ca. 3 KiB for a kernel for a single SoC.
It's been a while I've tried multi_v7_defconfig, but I'm afraid there's no
Renesas SoC left that can boot it, due to sheer size.
We're facing the same issue with arm64_defconfig soon (it already
fails now if you add a small (1.5 MiB) initrd).
Not to mention RZ/A1H, which is used on some boards running with
its 10 MiB of internal SRAM only.
Kernel size does matter, despite no progress on linux-tiny.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v5 11/23] usb: chipidea: Emulate OTGSC interrupt enable path
From: Stephen Boyd @ 2016-10-21 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021021450.GA16461@b29397-desktop>
Quoting Peter Chen (2016-10-20 19:14:50)
>
> I tested my patch, it works well at my side, if it is ok for you, please
> ack it, I will apply it as well as your chipidea series after your
> gpu fix patch at greg's usb-next tree.
Feel free to add my:
Tested-by: Stephen Boyd <stephen.boyd@linaro.org>
Reported-by: Stephen Boyd <stephen.boyd@linaro.org>
tags to the patch.
>
> Is it ok for you?
>
Ok sounds good. The GPU patch has been picked up into drm-misc now, but
I'm not sure if it's going to be merged into -rc2 or not but it sounds
like you'll figure that part out.
I'll resend the phy drivers to Kishon now. Thanks.
^ permalink raw reply
* [PATCH] arm64: qcom: enable GPIOLIB in Kconfig
From: Michael Scott @ 2016-10-21 17:56 UTC (permalink / raw)
To: linux-arm-kernel
While debugging a kernel image size issue, I discovered that if all
non ARCH_QCOM configs in the ARM64 defconfig are disabled, the QCOM
pinctrl drivers will not be built.
The QCOM pinctrl drivers have a dependency on GPIOLIB which was being
selected when other ARCH configs were enabled, but ARCH_QCOM doesn't
select GPIOLIB directly. Let's select GPIOLIB here to ensure the pinctrl
drivers are built for QCOM platforms.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index cfbdf02..e9fc226 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -113,6 +113,7 @@ config ARCH_MVEBU
config ARCH_QCOM
bool "Qualcomm Platforms"
+ select GPIOLIB
select PINCTRL
help
This enables support for the ARMv8 based Qualcomm chipsets.
--
2.9.3
^ permalink raw reply related
* [PATCH 2/8] mtd: nand: add support for the TC58NVG2S0H chip
From: Boris Brezillon @ 2016-10-21 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <62d5d978da8c6bc6b47c340c86e9a5fe5f6971ef.1476951078.git-series.maxime.ripard@free-electrons.com>
On Thu, 20 Oct 2016 10:12:43 +0200
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> From: Boris Brezillon <boris.brezillon@free-electrons.com>
>
> Add the description of the Toshiba TC58NVG2S0H SLC nand to the nand_ids
> table so we can use the NAND ECC infos and the ONFI timings.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Applied.
> ---
> drivers/mtd/nand/nand_ids.c | 3 +++
> 1 file changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
> index 2af9869a115e..b3a332f37e14 100644
> --- a/drivers/mtd/nand/nand_ids.c
> +++ b/drivers/mtd/nand/nand_ids.c
> @@ -36,6 +36,9 @@ struct nand_flash_dev nand_flash_ids[] = {
> {"TC58NVG2S0F 4G 3.3V 8-bit",
> { .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08} },
> SZ_4K, SZ_512, SZ_256K, 0, 8, 224, NAND_ECC_INFO(4, SZ_512) },
> + {"TC58NVG2S0H 4G 3.3V 8-bit",
> + { .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x16, 0x08, 0x00} },
> + SZ_4K, SZ_512, SZ_256K, 0, 8, 256, NAND_ECC_INFO(8, SZ_512) },
> {"TC58NVG3S0F 8G 3.3V 8-bit",
> { .id = {0x98, 0xd3, 0x90, 0x26, 0x76, 0x15, 0x02, 0x08} },
> SZ_4K, SZ_1K, SZ_256K, 0, 8, 232, NAND_ECC_INFO(4, SZ_512) },
^ permalink raw reply
* [PATCH 1/8] mtd: nand: sunxi: fix support for 512bytes ECC chunks
From: Boris Brezillon @ 2016-10-21 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f1cb6efb6817c11b235f073639a137bec6ac17e5.1476951078.git-series.maxime.ripard@free-electrons.com>
On Thu, 20 Oct 2016 10:12:42 +0200
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> From: Boris Brezillon <boris.brezillon@free-electrons.com>
>
> The driver is incorrectly assuming that the ECC block size is always 1k
> which is not always true.
>
> Also take the other cases into account.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Applied.
> ---
> drivers/mtd/nand/sunxi_nand.c | 4 ++++
> 1 file changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> index 8b8470c4e6d0..e40482a65de6 100644
> --- a/drivers/mtd/nand/sunxi_nand.c
> +++ b/drivers/mtd/nand/sunxi_nand.c
> @@ -145,6 +145,7 @@
> #define NFC_ECC_PIPELINE BIT(3)
> #define NFC_ECC_EXCEPTION BIT(4)
> #define NFC_ECC_BLOCK_SIZE_MSK BIT(5)
> +#define NFC_ECC_BLOCK_512 BIT(5)
> #define NFC_RANDOM_EN BIT(9)
> #define NFC_RANDOM_DIRECTION BIT(10)
> #define NFC_ECC_MODE_MSK GENMASK(15, 12)
> @@ -817,6 +818,9 @@ static void sunxi_nfc_hw_ecc_enable(struct mtd_info *mtd)
> ecc_ctl |= NFC_ECC_EN | NFC_ECC_MODE(data->mode) | NFC_ECC_EXCEPTION |
> NFC_ECC_PIPELINE;
>
> + if (nand->ecc.size == 512)
> + ecc_ctl |= NFC_ECC_BLOCK_512;
> +
> writel(ecc_ctl, nfc->regs + NFC_REG_ECC_CTL);
> }
>
^ permalink raw reply
* Disabling an interrupt in the handler locks the system up
From: Marc Zyngier @ 2016-10-21 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <580A4460.2090306@free.fr>
On 21/10/16 17:37, Mason wrote:
> Hello,
>
> On my platform, one HW block pulls the interrupt line high
> as long as it remains idle, and low when it is busy.
>
> The device tree node is:
>
> test at 22222 {
> compatible = "vendor,testme";
> interrupts = <23 IRQ_TYPE_LEVEL_HIGH>;
> };
I assume that this is for the sake of the discussion, and that you do
not actually intend to put together such a monstrosity.
>
> I wrote a minimal driver which registers the irq.
> And in the interrupt handler, I disable said irq.
>
> Since the irq is IRQ_TYPE_LEVEL_HIGH, it will fire as soon as
> it is registered (because the block is idle).
>
> Here is the code I've been running, request_irq doesn't return.
[...]
> And here's what I get when I try to load the module:
> (I'm using the default CONFIG_RCU_CPU_STALL_TIMEOUT=21)
[...]
> Are we not supposed to disable the irq in the handler?
You can. It then depends on what your interrupt controller does to
actually ensure that the interrupt is disabled. Only you can trace it on
your HW to find out.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 2/2] gpio: mxs: fix duplicate level interrupts
From: Marek Vasut @ 2016-10-21 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021131138.10467-3-s.hauer@pengutronix.de>
On 10/21/2016 03:11 PM, Sascha Hauer wrote:
> According to the reference manual level interrupts can't be acked
> using the IRQSTAT registers. The effect is that when a level interrupt
> triggers the following ack is a no-op and the same interrupt triggers
> again right after it has been unmasked after running the interrupt
> handler.
>
> The reference manual says:
>
> Status bits for pins configured as level sensitive interrupts cannot be
> cleared unless either the actual pin is in the non-interrupting state, or
> the pin has been disabled as an interrupt source by clearing its bit in
> HW_PINCTRL_PIN2IRQ.
>
> To work around the duplicated interrupts we can use the PIN2IRQ
> rather than the IRQEN registers to mask the interrupts. This
> probably does not work for the edge interrupts, so we have to split up
> the irq chip into two chip types, one for the level interrupts and
> one for the edge interrupts. We now make use of two different enable
> registers, so we have to take care to always enable the right one,
> especially during switching of the interrupt type. An easy way
> to accomplish this is to use the IRQCHIP_SET_TYPE_MASKED which
> makes sure that set_irq_type is called with masked interrupts. With this
> the flow to change the irq type is like:
>
> - core masks interrupt (using the current chip type)
> - mxs_gpio_set_irq_type() changes chip type if necessary
> - mxs_gpio_set_irq_type() unconditionally sets the enable bit in the
> now unused enable register
> - core eventually unmasks the interrupt (using the new chip type)
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Thanks for the detailed explanation, that was really needed.
> ---
> drivers/gpio/gpio-mxs.c | 38 +++++++++++++++++++++++++++++---------
> 1 file changed, 29 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mxs.c b/drivers/gpio/gpio-mxs.c
> index 1cf579f..62061f7 100644
> --- a/drivers/gpio/gpio-mxs.c
> +++ b/drivers/gpio/gpio-mxs.c
> @@ -87,10 +87,15 @@ static int mxs_gpio_set_irq_type(struct irq_data *d, unsigned int type)
> u32 val;
> u32 pin_mask = 1 << d->hwirq;
> struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> + struct irq_chip_type *ct = irq_data_get_chip_type(d);
> struct mxs_gpio_port *port = gc->private;
> void __iomem *pin_addr;
> int edge;
>
> + if (!(ct->type & type))
> + if (irq_setup_alt_chip(d, type))
> + return -EINVAL;
> +
> port->both_edges &= ~pin_mask;
> switch (type) {
> case IRQ_TYPE_EDGE_BOTH:
> @@ -119,10 +124,13 @@ static int mxs_gpio_set_irq_type(struct irq_data *d, unsigned int type)
>
> /* set level or edge */
> pin_addr = port->base + PINCTRL_IRQLEV(port);
> - if (edge & GPIO_INT_LEV_MASK)
> + if (edge & GPIO_INT_LEV_MASK) {
> writel(pin_mask, pin_addr + MXS_SET);
> - else
> + writel(pin_mask, port->base + PINCTRL_IRQEN(port) + MXS_SET);
> + } else {
> writel(pin_mask, pin_addr + MXS_CLR);
> + writel(pin_mask, port->base + PINCTRL_PIN2IRQ(port) + MXS_SET);
> + }
>
> /* set polarity */
> pin_addr = port->base + PINCTRL_IRQPOL(port);
> @@ -202,22 +210,37 @@ static int __init mxs_gpio_init_gc(struct mxs_gpio_port *port, int irq_base)
> struct irq_chip_generic *gc;
> struct irq_chip_type *ct;
>
> - gc = irq_alloc_generic_chip("gpio-mxs", 1, irq_base,
> + gc = irq_alloc_generic_chip("gpio-mxs", 2, irq_base,
> port->base, handle_level_irq);
> if (!gc)
> return -ENOMEM;
>
> gc->private = port;
>
> - ct = gc->chip_types;
> + ct = &gc->chip_types[0];
> + ct->type = IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW;
> + ct->chip.irq_ack = irq_gc_ack_set_bit;
> + ct->chip.irq_mask = irq_gc_mask_disable_reg;
> + ct->chip.irq_unmask = irq_gc_unmask_enable_reg;
> + ct->chip.irq_set_type = mxs_gpio_set_irq_type;
> + ct->chip.irq_set_wake = mxs_gpio_set_wake_irq;
> + ct->chip.flags = IRQCHIP_SET_TYPE_MASKED;
> + ct->regs.ack = PINCTRL_IRQSTAT(port) + MXS_CLR;
> + ct->regs.enable = PINCTRL_PIN2IRQ(port) + MXS_SET;
> + ct->regs.disable = PINCTRL_PIN2IRQ(port) + MXS_CLR;
> +
> + ct = &gc->chip_types[1];
> + ct->type = IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING;
> ct->chip.irq_ack = irq_gc_ack_set_bit;
> ct->chip.irq_mask = irq_gc_mask_disable_reg;
> ct->chip.irq_unmask = irq_gc_unmask_enable_reg;
> ct->chip.irq_set_type = mxs_gpio_set_irq_type;
> ct->chip.irq_set_wake = mxs_gpio_set_wake_irq;
> + ct->chip.flags = IRQCHIP_SET_TYPE_MASKED;
> ct->regs.ack = PINCTRL_IRQSTAT(port) + MXS_CLR;
> ct->regs.enable = PINCTRL_IRQEN(port) + MXS_SET;
> ct->regs.disable = PINCTRL_IRQEN(port) + MXS_CLR;
> + ct->handler = handle_level_irq;
>
> irq_setup_generic_chip(gc, IRQ_MSK(32), IRQ_GC_INIT_NESTED_LOCK,
> IRQ_NOREQUEST, 0);
> @@ -298,11 +321,8 @@ static int mxs_gpio_probe(struct platform_device *pdev)
> }
> port->base = base;
>
> - /*
> - * select the pin interrupt functionality but initially
> - * disable the interrupts
> - */
> - writel(~0U, port->base + PINCTRL_PIN2IRQ(port));
> + /* initially disable the interrupts */
> + writel(0, port->base + PINCTRL_PIN2IRQ(port));
> writel(0, port->base + PINCTRL_IRQEN(port));
>
> /* clear address has to be used to clear IRQSTAT bits */
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 1/2] gpio: mxs: use enable/disable regs to (un)mask irqs
From: Marek Vasut @ 2016-10-21 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021131138.10467-2-s.hauer@pengutronix.de>
On 10/21/2016 03:11 PM, Sascha Hauer wrote:
> The mxs gpio controller does not only have a mask register to mask
> interrupts, but also enable/disable registers. Use the enable/disable
> registers rather than the mask register. This does not have any
> advantage for now, but makes the next patch simpler.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Thanks
> ---
> drivers/gpio/gpio-mxs.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mxs.c b/drivers/gpio/gpio-mxs.c
> index b9daa0b..1cf579f 100644
> --- a/drivers/gpio/gpio-mxs.c
> +++ b/drivers/gpio/gpio-mxs.c
> @@ -211,12 +211,13 @@ static int __init mxs_gpio_init_gc(struct mxs_gpio_port *port, int irq_base)
>
> ct = gc->chip_types;
> ct->chip.irq_ack = irq_gc_ack_set_bit;
> - ct->chip.irq_mask = irq_gc_mask_clr_bit;
> - ct->chip.irq_unmask = irq_gc_mask_set_bit;
> + ct->chip.irq_mask = irq_gc_mask_disable_reg;
> + ct->chip.irq_unmask = irq_gc_unmask_enable_reg;
> ct->chip.irq_set_type = mxs_gpio_set_irq_type;
> ct->chip.irq_set_wake = mxs_gpio_set_wake_irq;
> ct->regs.ack = PINCTRL_IRQSTAT(port) + MXS_CLR;
> - ct->regs.mask = PINCTRL_IRQEN(port);
> + ct->regs.enable = PINCTRL_IRQEN(port) + MXS_SET;
> + ct->regs.disable = PINCTRL_IRQEN(port) + MXS_CLR;
>
> irq_setup_generic_chip(gc, IRQ_MSK(32), IRQ_GC_INIT_NESTED_LOCK,
> IRQ_NOREQUEST, 0);
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH V4 10/10] arm64: KVM: add guest SEA support
From: Tyler Baicar @ 2016-10-21 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477071013-29563-1-git-send-email-tbaicar@codeaurora.org>
Currently external aborts are unsupported by the guest abort
handling. Add handling for SEAs so that the host kernel reports
SEAs which occur in the guest kernel.
Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
---
arch/arm/include/asm/kvm_arm.h | 1 +
arch/arm/include/asm/system_misc.h | 5 +++++
arch/arm/kvm/mmu.c | 18 ++++++++++++++++--
arch/arm64/include/asm/kvm_arm.h | 1 +
arch/arm64/include/asm/system_misc.h | 2 ++
arch/arm64/mm/fault.c | 13 +++++++++++++
6 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h
index e22089f..33a77509 100644
--- a/arch/arm/include/asm/kvm_arm.h
+++ b/arch/arm/include/asm/kvm_arm.h
@@ -187,6 +187,7 @@
#define FSC_FAULT (0x04)
#define FSC_ACCESS (0x08)
#define FSC_PERM (0x0c)
+#define FSC_EXTABT (0x10)
/* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
#define HPFAR_MASK (~0xf)
diff --git a/arch/arm/include/asm/system_misc.h b/arch/arm/include/asm/system_misc.h
index a3d61ad..86e1faa 100644
--- a/arch/arm/include/asm/system_misc.h
+++ b/arch/arm/include/asm/system_misc.h
@@ -24,4 +24,9 @@ extern unsigned int user_debug;
#endif /* !__ASSEMBLY__ */
+inline int handle_guest_sea(unsigned long addr, unsigned int esr)
+{
+ return -1;
+}
+
#endif /* __ASM_ARM_SYSTEM_MISC_H */
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index e9a5c0e..1152966 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -29,6 +29,7 @@
#include <asm/kvm_asm.h>
#include <asm/kvm_emulate.h>
#include <asm/virt.h>
+#include <asm/system_misc.h>
#include "trace.h"
@@ -1441,8 +1442,21 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
/* Check the stage-2 fault is trans. fault or write fault */
fault_status = kvm_vcpu_trap_get_fault_type(vcpu);
- if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
- fault_status != FSC_ACCESS) {
+
+ /* The host kernel will handle the synchronous external abort. There
+ * is no need to pass the error into the guest.
+ */
+ if (fault_status == FSC_EXTABT) {
+ if(handle_guest_sea((unsigned long)fault_ipa,
+ kvm_vcpu_get_hsr(vcpu))) {
+ kvm_err("Failed to handle guest SEA, FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
+ kvm_vcpu_trap_get_class(vcpu),
+ (unsigned long)kvm_vcpu_trap_get_fault(vcpu),
+ (unsigned long)kvm_vcpu_get_hsr(vcpu));
+ return -EFAULT;
+ }
+ } else if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
+ fault_status != FSC_ACCESS) {
kvm_err("Unsupported FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
kvm_vcpu_trap_get_class(vcpu),
(unsigned long)kvm_vcpu_trap_get_fault(vcpu),
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 4b5c977..be0efb6 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -201,6 +201,7 @@
#define FSC_FAULT ESR_ELx_FSC_FAULT
#define FSC_ACCESS ESR_ELx_FSC_ACCESS
#define FSC_PERM ESR_ELx_FSC_PERM
+#define FSC_EXTABT ESR_ELx_FSC_EXTABT
/* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
#define HPFAR_MASK (~UL(0xf))
diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
index 9040e1d..3a142a5 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -77,4 +77,6 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
int register_synchronous_ext_abort_notifier(struct notifier_block *nb);
void unregister_synchronous_ext_abort_notifier(struct notifier_block *nb);
+int handle_guest_sea(unsigned long addr, unsigned int esr);
+
#endif /* __ASM_SYSTEM_MISC_H */
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index fcc49f1..691399e 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -597,6 +597,19 @@ static const char *fault_name(unsigned int esr)
}
/*
+ * Handle Synchronous External Aborts that occur in a guest kernel.
+ */
+int handle_guest_sea(unsigned long addr, unsigned int esr)
+{
+ atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
+
+ pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
+ fault_name(esr), esr, addr);
+
+ return 0;
+}
+
+/*
* Dispatch a data abort to the relevant handler.
*/
asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ 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