* [PATCH 5/6] ARM: add low level debug uart for rk1108
From: Andy Yan @ 2016-11-03 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478175975-11779-1-git-send-email-andy.yan@rock-chips.com>
RK1108 UARTs are Synopsis DesignWare 8250 compatible.
Only with different register addresses.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
---
arch/arm/Kconfig.debug | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index d83f7c3..408540f 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -776,6 +776,30 @@ choice
their output to the standard serial port on the RealView
PB1176 platform.
+ config DEBUG_RK1108_UART0
+ bool "Kernel low-level debugging messages via Rockchip RK1108 UART0"
+ depends on ARCH_ROCKCHIP
+ select DEBUG_UART_8250
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Rockchip RK1108 based platforms.
+
+ config DEBUG_RK1108_UART1
+ bool "Kernel low-level debugging messages via Rockchip RK1108 UART1"
+ depends on ARCH_ROCKCHIP
+ select DEBUG_UART_8250
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Rockchip RK1108 based platforms.
+
+ config DEBUG_RK1108_UART2
+ bool "Kernel low-level debugging messages via Rockchip RK1108 UART2"
+ depends on ARCH_ROCKCHIP
+ select DEBUG_UART_8250
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Rockchip RK1108 based platforms.
+
config DEBUG_RK29_UART0
bool "Kernel low-level debugging messages via Rockchip RK29 UART0"
depends on ARCH_ROCKCHIP
@@ -1465,6 +1489,9 @@ config DEBUG_UART_PHYS
default 0x10126000 if DEBUG_RK3X_UART1
default 0x101f1000 if DEBUG_VERSATILE
default 0x101fb000 if DEBUG_NOMADIK_UART
+ default 0x10210000 if DEBUG_RK1108_UART2
+ default 0x10220000 if DEBUG_RK1108_UART1
+ default 0x10230000 if DEBUG_RK1108_UART0
default 0x11002000 if DEBUG_MT8127_UART0
default 0x11006000 if DEBUG_MT6589_UART0
default 0x11009000 if DEBUG_MT8135_UART3
@@ -1563,6 +1590,9 @@ config DEBUG_UART_PHYS
config DEBUG_UART_VIRT
hex "Virtual base address of debug UART"
+ default 0xc881f000 if DEBUG_RK1108_UART2
+ default 0xc8821000 if DEBUG_RK1108_UART1
+ default 0xc8912000 if DEBUG_RK1108_UART0
default 0xe0000a00 if DEBUG_NETX_UART
default 0xe0010fe0 if ARCH_RPC
default 0xf0000be0 if ARCH_EBSA110
--
2.7.4
^ permalink raw reply related
* [PATCH 6/6] ARM: dts: rockchip: add rockchip RK1108 Evaluation board
From: Andy Yan @ 2016-11-03 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478175975-11779-1-git-send-email-andy.yan@rock-chips.com>
RK1108EVB is designed by Rockchip for CVR field.
This patch add basic support for it, which can boot with
initramfs into shell.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
---
Documentation/devicetree/bindings/arm/rockchip.txt | 3 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk1108-evb.dts | 69 ++++++++++++++++++++++
3 files changed, 73 insertions(+)
create mode 100644 arch/arm/boot/dts/rk1108-evb.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
index 10b92b5..8670181 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -1,5 +1,8 @@
Rockchip platforms device tree bindings
---------------------------------------
+- Rockchip RK1108 Evaluation board
+ Required root node properties:
+ - compatible = "rockchip,rk1108-evb", "rockchip,rk1108";
- Kylin RK3036 board:
Required root node properties:
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e49476a..249dca9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -635,6 +635,7 @@ dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pba8.dtb \
arm-realview-pbx-a9.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
+ rk1108-evb.dtb \
rk3036-evb.dtb \
rk3036-kylin.dtb \
rk3066a-bqcurie2.dtb \
diff --git a/arch/arm/boot/dts/rk1108-evb.dts b/arch/arm/boot/dts/rk1108-evb.dts
new file mode 100644
index 0000000..3956cff
--- /dev/null
+++ b/arch/arm/boot/dts/rk1108-evb.dts
@@ -0,0 +1,69 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk1108.dtsi"
+
+/ {
+ model = "Rockchip RK1108 Evaluation board";
+ compatible = "rockchip,rk1108-evb", "rockchip,rk1108";
+
+ memory at 60000000 {
+ device_type = "memory";
+ reg = <0x60000000 0x08000000>;
+ };
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH next 1/2] media: mtk-mdp: fix video_device_release argument
From: Hans Verkuil @ 2016-11-03 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028075253.gdy2bbugih6oqncw@romuald.bergerie>
Hi Vincent,
On 28/10/16 09:52, Vincent Stehl? wrote:
> On Thu, Oct 27, 2016 at 10:23:24PM +0200, Vincent Stehl? wrote:
>> video_device_release() takes a pointer to struct video_device as argument.
>> Fix two call sites where the address of the pointer is passed instead.
>
> Sorry, I messed up: please ignore that "fix". The 0day robot made me
> realize this is indeed not a proper fix.
>
> The issue remains, though: we cannot call video_device_release() on the
> vdev structure member, as this will in turn call kfree(). Most probably,
> vdev needs to be dynamically allocated, or the call to
> video_device_release() dropped completely.
I prefer that vdev is dynamically allocated. There are known problems with
embedded video_device structs, so allocating it is preferred.
Minghsiu, can you do that?
Regards,
Hans
>
> Sorry for the bad patch.
>
> Best regards,
>
> Vincent.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH V3 6/6] bus: Add support for Tegra Generic Memory Interface
From: Mirza Krak @ 2016-11-03 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3cdf7281-840f-1aa0-5a57-fe58501165f4@nvidia.com>
2016-11-03 11:51 GMT+01:00 Jon Hunter <jonathanh@nvidia.com>:
>
> On 27/10/16 15:01, Mirza Krak wrote:
>>
>> From: Mirza Krak <mirza.krak@gmail.com>
>>
>> The Generic Memory Interface bus can be used to connect high-speed
>> devices such as NOR flash, FPGAs, DSPs...
>>
>> Signed-off-by: Mirza Krak <mirza.krak@gmail.com>
>> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>> Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
>> ---
>>
>> Changes in v2:
>> - Fixed some checkpatch errors
>> - Re-ordered probe to get rid of local variables
>> - Moved of_platform_default_populate call to the end of probe
>> - Use the timing and configuration properties from the child device
>> - Added warning if more then 1 child device exist
>>
>> Changes in v3:
>> - added helper function to disable the controller which is used in remove
>> and
>> on error.
>> - Added logic to parse CS# from "ranges" property with fallback to "reg"
>> property
>>
>> drivers/bus/Kconfig | 8 ++
>> drivers/bus/Makefile | 1 +
>> drivers/bus/tegra-gmi.c | 267
>> ++++++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 276 insertions(+)
>> create mode 100644 drivers/bus/tegra-gmi.c
>>
>> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
>> index 4ed7d26..2e75a7f 100644
>> --- a/drivers/bus/Kconfig
>> +++ b/drivers/bus/Kconfig
>> @@ -141,6 +141,14 @@ config TEGRA_ACONNECT
>> Driver for the Tegra ACONNECT bus which is used to interface
>> with
>> the devices inside the Audio Processing Engine (APE) for
>> Tegra210.
>>
>> +config TEGRA_GMI
>> + tristate "Tegra Generic Memory Interface bus driver"
>> + depends on ARCH_TEGRA
>> + help
>> + Driver for the Tegra Generic Memory Interface bus which can be
>> used
>> + to attach devices such as NOR, UART, FPGA and more.
>> +
>> +
>
>
> Nit-pick ... only one additional line above is needed to be consistent with
> the rest of the file.
Will fix that.
>
>
>> config UNIPHIER_SYSTEM_BUS
>> tristate "UniPhier System Bus driver"
>> depends on ARCH_UNIPHIER && OF
>> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
>> index ac84cc4..34e2bab 100644
>> --- a/drivers/bus/Makefile
>> +++ b/drivers/bus/Makefile
>> @@ -18,5 +18,6 @@ obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
>> obj-$(CONFIG_SUNXI_RSB) += sunxi-rsb.o
>> obj-$(CONFIG_SIMPLE_PM_BUS) += simple-pm-bus.o
>> obj-$(CONFIG_TEGRA_ACONNECT) += tegra-aconnect.o
>> +obj-$(CONFIG_TEGRA_GMI) += tegra-gmi.o
>> obj-$(CONFIG_UNIPHIER_SYSTEM_BUS) += uniphier-system-bus.o
>> obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o
>> diff --git a/drivers/bus/tegra-gmi.c b/drivers/bus/tegra-gmi.c
>> new file mode 100644
>> index 0000000..dd9623e
>> --- /dev/null
>> +++ b/drivers/bus/tegra-gmi.c
>> @@ -0,0 +1,267 @@
>> +/*
>> + * Driver for NVIDIA Generic Memory Interface
>> + *
>> + * Copyright (C) 2016 Host Mobility AB. All rights reserved.
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/of_device.h>
>> +#include <linux/reset.h>
>> +
>> +#define TEGRA_GMI_CONFIG 0x00
>> +#define TEGRA_GMI_CONFIG_GO BIT(31)
>> +#define TEGRA_GMI_BUS_WIDTH_32BIT BIT(30)
>> +#define TEGRA_GMI_MUX_MODE BIT(28)
>> +#define TEGRA_GMI_RDY_BEFORE_DATA BIT(24)
>> +#define TEGRA_GMI_RDY_ACTIVE_HIGH BIT(23)
>> +#define TEGRA_GMI_ADV_ACTIVE_HIGH BIT(22)
>> +#define TEGRA_GMI_OE_ACTIVE_HIGH BIT(21)
>> +#define TEGRA_GMI_CS_ACTIVE_HIGH BIT(20)
>> +#define TEGRA_GMI_CS_SELECT(x) ((x & 0x7) << 4)
>> +
>> +#define TEGRA_GMI_TIMING0 0x10
>> +#define TEGRA_GMI_MUXED_WIDTH(x) ((x & 0xf) << 12)
>> +#define TEGRA_GMI_HOLD_WIDTH(x) ((x & 0xf) << 8)
>> +#define TEGRA_GMI_ADV_WIDTH(x) ((x & 0xf) << 4)
>> +#define TEGRA_GMI_CE_WIDTH(x) (x & 0xf)
>> +
>> +#define TEGRA_GMI_TIMING1 0x14
>> +#define TEGRA_GMI_WE_WIDTH(x) ((x & 0xff) << 16)
>> +#define TEGRA_GMI_OE_WIDTH(x) ((x & 0xff) << 8)
>> +#define TEGRA_GMI_WAIT_WIDTH(x) (x & 0xff)
>> +
>> +struct tegra_gmi_priv {
>> + void __iomem *base;
>> + struct reset_control *rst;
>> + struct clk *clk;
>> +
>> + u32 snor_config;
>> + u32 snor_timing0;
>> + u32 snor_timing1;
>> +};
>> +
>> +static void tegra_gmi_disable(struct tegra_gmi_priv *priv)
>> +{
>> + u32 config;
>> +
>> + /* stop GMI operation */
>> + config = readl(priv->base + TEGRA_GMI_CONFIG);
>> + config &= ~TEGRA_GMI_CONFIG_GO;
>> + writel(config, priv->base + TEGRA_GMI_CONFIG);
>> +
>> + reset_control_assert(priv->rst);
>> + clk_disable_unprepare(priv->clk);
>> +}
>> +
>> +static void tegra_gmi_init(struct device *dev, struct tegra_gmi_priv
>> *priv)
>> +{
>> + writel(priv->snor_timing0, priv->base + TEGRA_GMI_TIMING0);
>> + writel(priv->snor_timing1, priv->base + TEGRA_GMI_TIMING1);
>> +
>> + priv->snor_config |= TEGRA_GMI_CONFIG_GO;
>> + writel(priv->snor_config, priv->base + TEGRA_GMI_CONFIG);
>> +}
>> +
>> +static int tegra_gmi_parse_dt(struct device *dev, struct tegra_gmi_priv
>> *priv)
>> +{
>> + struct device_node *child =
>> of_get_next_available_child(dev->of_node,
>> + NULL);
>> + u32 property, ranges[4];
>> + int ret;
>> +
>> + if (!child) {
>> + dev_warn(dev, "no child nodes found\n");
>> + return 0;
>
>
> Don't we want to return an error here? Otherwise, we will call
> tegra_gmi_init() with an invalid configuration.
True, we probably want that. My thought was that we might accept a
tegra-gmi node without any child nodes and just print a warning. But
since it is the child node that holds the bus configuration it makes
sense to fail probe due to no child nodes.
>
>
>> + }
>> +
>> + /*
>> + * We currently only support one child device due to lack of
>> + * chip-select address decoding. Which means that we only have one
>> + * chip-select line from the GMI controller.
>> + */
>> + if (of_get_child_count(dev->of_node) > 1)
>> + dev_warn(dev, "only one child device is supported.");
>> +
>> + if (of_property_read_bool(child, "nvidia,snor-data-width-32bit"))
>> + priv->snor_config |= TEGRA_GMI_BUS_WIDTH_32BIT;
>> +
>> + if (of_property_read_bool(child, "nvidia,snor-mux-mode"))
>> + priv->snor_config |= TEGRA_GMI_MUX_MODE;
>> +
>> + if (of_property_read_bool(child,
>> "nvidia,snor-rdy-active-before-data"))
>> + priv->snor_config |= TEGRA_GMI_RDY_BEFORE_DATA;
>> +
>> + if (of_property_read_bool(child, "nvidia,snor-rdy-inv"))
>> + priv->snor_config |= TEGRA_GMI_RDY_ACTIVE_HIGH;
>> +
>> + if (of_property_read_bool(child, "nvidia,snor-adv-inv"))
>> + priv->snor_config |= TEGRA_GMI_ADV_ACTIVE_HIGH;
>> +
>> + if (of_property_read_bool(child, "nvidia,snor-oe-inv"))
>> + priv->snor_config |= TEGRA_GMI_OE_ACTIVE_HIGH;
>> +
>> + if (of_property_read_bool(child, "nvidia,snor-cs-inv"))
>> + priv->snor_config |= TEGRA_GMI_CS_ACTIVE_HIGH;
>> +
>> + /* Decode the CS# */
>> + ret = of_property_read_u32_array(child, "ranges", ranges, 4);
>> + if (ret < 0) {
>> + /* Invalid binding */
>> + if (ret == -EOVERFLOW) {
>> + dev_err(dev, "invalid ranges length\n");
>> + goto error_cs_decode;
>> + }
>> +
>> + /*
>> + * If we reach here it means that the child node has an
>> empty
>> + * ranges or it does not exist at all. Attempt to decode
>> the
>> + * CS# from the reg property instead.
>> + */
>> + ret = of_property_read_u32(child, "reg", &property);
>> + if (ret < 0) {
>> + dev_err(dev, "no reg property found\n");
>> + goto error_cs_decode;
>> + }
>> + } else {
>> + property = ranges[1];
>> + }
>> +
>> + priv->snor_config |= TEGRA_GMI_CS_SELECT(property);
>
>
> Should we make sure the CS is a valid value before setting?
The TEGRA_GMI_CS_SELECT(x) macro will truncate any erroneous CS value.
But yeah we could do a sanity check instead and return an error if it
is invalid.
>
>
>> +
>> + /* The default values that are provided below are reset values */
>> + if (!of_property_read_u32(child, "nvidia,snor-muxed-width",
>> &property))
>> + priv->snor_timing0 |= TEGRA_GMI_MUXED_WIDTH(property);
>> + else
>> + priv->snor_timing0 |= TEGRA_GMI_MUXED_WIDTH(1);
>> +
>> + if (!of_property_read_u32(child, "nvidia,snor-hold-width",
>> &property))
>> + priv->snor_timing0 |= TEGRA_GMI_HOLD_WIDTH(property);
>> + else
>> + priv->snor_timing0 |= TEGRA_GMI_HOLD_WIDTH(1);
>> +
>> + if (!of_property_read_u32(child, "nvidia,snor-adv-width",
>> &property))
>> + priv->snor_timing0 |= TEGRA_GMI_ADV_WIDTH(property);
>> + else
>> + priv->snor_timing0 |= TEGRA_GMI_ADV_WIDTH(1);
>> +
>> + if (!of_property_read_u32(child, "nvidia,snor-ce-width",
>> &property))
>> + priv->snor_timing0 |= TEGRA_GMI_CE_WIDTH(property);
>> + else
>> + priv->snor_timing0 |= TEGRA_GMI_CE_WIDTH(4);
>> +
>> + if (!of_property_read_u32(child, "nvidia,snor-we-width",
>> &property))
>> + priv->snor_timing1 |= TEGRA_GMI_WE_WIDTH(property);
>> + else
>> + priv->snor_timing1 |= TEGRA_GMI_WE_WIDTH(1);
>> +
>> + if (!of_property_read_u32(child, "nvidia,snor-oe-width",
>> &property))
>> + priv->snor_timing1 |= TEGRA_GMI_OE_WIDTH(property);
>> + else
>> + priv->snor_timing1 |= TEGRA_GMI_OE_WIDTH(1);
>> +
>> + if (!of_property_read_u32(child, "nvidia,snor-wait-width",
>> &property))
>> + priv->snor_timing1 |= TEGRA_GMI_WAIT_WIDTH(property);
>> + else
>> + priv->snor_timing1 |= TEGRA_GMI_WAIT_WIDTH(3);
>> +
>> +error_cs_decode:
>> + if (ret < 0)
>> + dev_err(dev, "failed to decode chip-select number\n");
>
>
> Nit do we need another error message here? Can we add the "failed to decode
> CS" part the earlier message?
Does it make sense to drop the two earlier messages instead and keep this one?
Best Regards
Mirza
^ permalink raw reply
* [PATCH] dmaengine: st_fdma: Update st_fdma to 'depends on REMOTEPROC'.
From: Koul, Vinod @ 2016-11-03 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477039465-31121-1-git-send-email-peter.griffin@linaro.org>
On Fri, 2016-10-21 at 09:44 +0100, Peter Griffin wrote:
> During randconfig builds you can get the following warning
> "warning: (ST_FDMA) selects ST_SLIM_REMOTEPROC which has unmet direct
> ?dependencies (REMOTEPROC)"
>
> randconfig builds should always build without any warnings so
> update fdma to depend on REMOTEPROC so this can not happen.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH V7 0/4] dmaengine: qcom_hidma: add MSI interrupt support
From: Koul, Vinod @ 2016-11-03 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477067879-23750-1-git-send-email-okaya@codeaurora.org>
On Fri, 2016-10-21 at 12:37 -0400, Sinan Kaya wrote:
> The new version of the HW supports MSI interrupts instead of wired
> interrupts. The MSI interrupts are especially useful for the guest
> machine
> execution. The wired interrupts usually trap to the hypervisor and
> then are
> relayed to the actual interrupt.
>
> The MSI interrupts can be directly fed into the interrupt controller.
>
> Adding a new OF compat string (qcom,hidma-1.1) and ACPI string
> (QCOM8062)
> to distinguish newer HW from the older ones.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH] ARM: DTS: r8a7794: alt: Fix PCF names for DU
From: Jacopo Mondi @ 2016-11-03 13:42 UTC (permalink / raw)
To: linux-arm-kernel
Update the PCF pin groups and function names of DU interface for
r8a7794 ALT board.
The currently specified pin groups and function names prevented PCF and
DU interfaces from being correctly configured:
sh-pfc e6060000.pin-controller: function 'du' not supported
sh-pfc e6060000.pin-controller: invalid function du in map table
sh-pfc e6060000.pin-controller: function 'du' not supported
sh-pfc e6060000.pin-controller: invalid function du in map table
sh-pfc e6060000.pin-controller: function 'du' not supported
sh-pfc e6060000.pin-controller: invalid function du in map table
sh-pfc e6060000.pin-controller: function 'du' not supported
sh-pfc e6060000.pin-controller: invalid function du in map table
rcar-du: probe of feb00000.display failed with error -22
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
---
Patch applied against Simon Horman's renesas/master branch.
The PCF pin groups and function renaming was introduced by commit 56ed4bb9 and
DTS for ALT board has never been update accordingly.
Tested displaying frames on VGA interface: the rcar-du driver loads correctly.
arch/arm/boot/dts/r8a7794-alt.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
index 8d1b35a..9d65fb3 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -165,8 +165,8 @@
pinctrl-names = "default";
du_pins: du {
- groups = "du1_rgb666", "du1_sync", "du1_disp", "du1_dotclkout0";
- function = "du";
+ groups = "du1_rgb666", "du1_sync", "du1_disp", "du1_clk0_out";
+ function = "du1";
};
scif2_pins: scif2 {
--
2.7.4
^ permalink raw reply related
* [PATCH V3 1/6] clk: tegra: add TEGRA20_CLK_NOR to init table
From: Jon Hunter @ 2016-11-03 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALw8SCWC7RmNLVv4vxO9xw3jHVkgCaevbL61sJcpcva9CiaAVQ@mail.gmail.com>
On 03/11/16 12:30, Mirza Krak wrote:
> 2016-11-03 13:26 GMT+01:00 Mirza Krak <mirza.krak@gmail.com>:
>> 2016-11-03 11:06 GMT+01:00 Jon Hunter <jonathanh@nvidia.com>:
>>> Hi Mirza,
>>>
>>> On 27/10/16 15:01, Mirza Krak wrote:
>>>>
>>>> From: Mirza Krak <mirza.krak@gmail.com>
>>>>
>>>> Add TEGRA20_CLK_NOR to init table and set default rate to 92 MHz which
>>>> is max rate.
>>>>
>>>> The maximum rate value of 92 MHz is pulled from the downstream L4T
>>>> kernel.
>>>
>>>
>>> Thanks for adding this. I assume that this is from an L4T r16 release with a
>>> v3.1 kernel. I had a quick poke through the kernel sources for v3.1 but was
>>> unable to see where this is set. Obviously v3.1 did not have CCF and so
>>> everything seems to be in the arch/arm/mach-tegra directory for setting up
>>> clocks. Can you point me to the appropriate sources so I can ACK this?
>>
>> I use the kernel sources provided by Toradex, and these sources are
>> based on L4T r16 release.
>>
>> http://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/mach-tegra/tegra2_clocks.c?h=tegra#n2463
>
> Ops, pre-mature send.
>
> I also added Marcel from Toradex on CC.
>
> The link to the source are [1] for Tegra2 and [2] for Tegra3.
>
> [1]. http://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/mach-tegra/tegra2_clocks.c?h=tegra#n2463
> [2]. http://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/mach-tegra/tegra3_clocks.c?h=tegra#n4353
Great. Yes I see the same. Thanks!
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v14 14/16] vfio/type1: Check doorbell safety
From: Diana Madalina Craciun @ 2016-11-03 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476278544-3397-15-git-send-email-eric.auger@redhat.com>
Hi Eric,
On 10/12/2016 04:23 PM, Eric Auger wrote:
> On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted
> by the msi controller.
>
> Since we currently have no way to detect whether the MSI controller is
> upstream or downstream to the IOMMU we rely on the MSI doorbell information
> registered by the interrupt controllers. In case at least one doorbell
> does not implement proper isolation, we state the assignment is unsafe
> with regard to interrupts. This is a coarse assessment but should allow to
> wait for a better system description.
>
> At this point ARM sMMU still advertises IOMMU_CAP_INTR_REMAP. This is
> removed in next patch.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
> v13 -> v15:
> - check vfio_msi_resv before checking whether msi doorbell is safe
>
> v9 -> v10:
> - coarse safety assessment based on MSI doorbell info
>
> v3 -> v4:
> - rename vfio_msi_parent_irq_remapping_capable into vfio_safe_irq_domain
> and irq_remapping into safe_irq_domains
>
> v2 -> v3:
> - protect vfio_msi_parent_irq_remapping_capable with
> CONFIG_GENERIC_MSI_IRQ_DOMAIN
> ---
> drivers/vfio/vfio_iommu_type1.c | 30 +++++++++++++++++++++++++++++-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index e0c97ef..c18ba9d 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -442,6 +442,29 @@ static void vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma *dma)
> }
>
> /**
> + * vfio_msi_resv - Return whether any VFIO iommu domain requires
> + * MSI mapping
> + *
> + * @iommu: vfio iommu handle
> + *
> + * Return: true of MSI mapping is needed, false otherwise
> + */
> +static bool vfio_msi_resv(struct vfio_iommu *iommu)
> +{
> + struct iommu_domain_msi_resv msi_resv;
> + struct vfio_domain *d;
> + int ret;
> +
> + list_for_each_entry(d, &iommu->domain_list, next) {
> + ret = iommu_domain_get_attr(d->domain, DOMAIN_ATTR_MSI_RESV,
> + &msi_resv);
> + if (!ret)
> + return true;
> + }
> + return false;
> +}
> +
> +/**
> * vfio_set_msi_aperture - Sets the msi aperture on all domains
> * requesting MSI mapping
> *
> @@ -945,8 +968,13 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
> INIT_LIST_HEAD(&domain->group_list);
> list_add(&group->next, &domain->group_list);
>
> + /*
> + * to advertise safe interrupts either the IOMMU or the MSI controllers
> + * must support IRQ remapping (aka. interrupt translation)
> + */
> if (!allow_unsafe_interrupts &&
> - !iommu_capable(bus, IOMMU_CAP_INTR_REMAP)) {
> + (!iommu_capable(bus, IOMMU_CAP_INTR_REMAP) &&
> + !(vfio_msi_resv(iommu) && iommu_msi_doorbell_safe()))) {
> pr_warn("%s: No interrupt remapping support. Use the module param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this platform\n",
> __func__);
> ret = -EPERM;
I understand from the other discussions that you will respin these
series, but anyway I have tested this version with GICV3 + ITS and it
stops here. As I have a GICv3 I am not supposed to enable allow unsafe
interrupts. What I see is that vfio_msi_resv returns false just because
the iommu->domain_list list is empty. The newly created domain is
actually added to the domain_list at the end of this function, so it
seems normal for the list to be empty at this point.
Thanks,
Diana
^ permalink raw reply
* [PATCH V3 1/6] clk: tegra: add TEGRA20_CLK_NOR to init table
From: Jon Hunter @ 2016-11-03 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477576872-2665-2-git-send-email-mirza.krak@gmail.com>
On 27/10/16 15:01, Mirza Krak wrote:
> From: Mirza Krak <mirza.krak@gmail.com>
>
> Add TEGRA20_CLK_NOR to init table and set default rate to 92 MHz which
> is max rate.
>
> The maximum rate value of 92 MHz is pulled from the downstream L4T
> kernel.
>
> Signed-off-by: Mirza Krak <mirza.krak@gmail.com>
> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH V3 2/6] clk: tegra: add TEGRA30_CLK_NOR to init table
From: Jon Hunter @ 2016-11-03 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477576872-2665-3-git-send-email-mirza.krak@gmail.com>
On 27/10/16 15:01, Mirza Krak wrote:
> From: Mirza Krak <mirza.krak@gmail.com>
>
> Add TEGRA30_CLK_NOR to init table and set default rate to 127 MHz which
> is max rate.
>
> The maximum rate value of 127 MHz is pulled from the downstream L4T
> kernel.
>
> Signed-off-by: Mirza Krak <mirza.krak@gmail.com>
> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH V3 6/6] bus: Add support for Tegra Generic Memory Interface
From: Jon Hunter @ 2016-11-03 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALw8SCVu+-h_yhOa7uDuyFBPVvhwjD64S+-MDeYN8EZsGHpXyw@mail.gmail.com>
On 03/11/16 13:08, Mirza Krak wrote:
> 2016-11-03 11:51 GMT+01:00 Jon Hunter <jonathanh@nvidia.com>:
>>
>> On 27/10/16 15:01, Mirza Krak wrote:
>>>
>>> From: Mirza Krak <mirza.krak@gmail.com>
>>>
>>> The Generic Memory Interface bus can be used to connect high-speed
>>> devices such as NOR flash, FPGAs, DSPs...
>>>
>>> Signed-off-by: Mirza Krak <mirza.krak@gmail.com>
>>> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>>> Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
>>> ---
>>>
>>> Changes in v2:
>>> - Fixed some checkpatch errors
>>> - Re-ordered probe to get rid of local variables
>>> - Moved of_platform_default_populate call to the end of probe
>>> - Use the timing and configuration properties from the child device
>>> - Added warning if more then 1 child device exist
>>>
>>> Changes in v3:
>>> - added helper function to disable the controller which is used in remove
>>> and
>>> on error.
>>> - Added logic to parse CS# from "ranges" property with fallback to "reg"
>>> property
>>>
>>> drivers/bus/Kconfig | 8 ++
>>> drivers/bus/Makefile | 1 +
>>> drivers/bus/tegra-gmi.c | 267
>>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 276 insertions(+)
>>> create mode 100644 drivers/bus/tegra-gmi.c
>>>
>>> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
>>> index 4ed7d26..2e75a7f 100644
>>> --- a/drivers/bus/Kconfig
>>> +++ b/drivers/bus/Kconfig
>>> @@ -141,6 +141,14 @@ config TEGRA_ACONNECT
>>> Driver for the Tegra ACONNECT bus which is used to interface
>>> with
>>> the devices inside the Audio Processing Engine (APE) for
>>> Tegra210.
>>>
>>> +config TEGRA_GMI
>>> + tristate "Tegra Generic Memory Interface bus driver"
>>> + depends on ARCH_TEGRA
>>> + help
>>> + Driver for the Tegra Generic Memory Interface bus which can be
>>> used
>>> + to attach devices such as NOR, UART, FPGA and more.
>>> +
>>> +
>>
>>
>> Nit-pick ... only one additional line above is needed to be consistent with
>> the rest of the file.
>
> Will fix that.
>
>>
>>
>>> config UNIPHIER_SYSTEM_BUS
>>> tristate "UniPhier System Bus driver"
>>> depends on ARCH_UNIPHIER && OF
>>> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
>>> index ac84cc4..34e2bab 100644
>>> --- a/drivers/bus/Makefile
>>> +++ b/drivers/bus/Makefile
>>> @@ -18,5 +18,6 @@ obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
>>> obj-$(CONFIG_SUNXI_RSB) += sunxi-rsb.o
>>> obj-$(CONFIG_SIMPLE_PM_BUS) += simple-pm-bus.o
>>> obj-$(CONFIG_TEGRA_ACONNECT) += tegra-aconnect.o
>>> +obj-$(CONFIG_TEGRA_GMI) += tegra-gmi.o
>>> obj-$(CONFIG_UNIPHIER_SYSTEM_BUS) += uniphier-system-bus.o
>>> obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o
>>> diff --git a/drivers/bus/tegra-gmi.c b/drivers/bus/tegra-gmi.c
>>> new file mode 100644
>>> index 0000000..dd9623e
>>> --- /dev/null
>>> +++ b/drivers/bus/tegra-gmi.c
>>> @@ -0,0 +1,267 @@
>>> +/*
>>> + * Driver for NVIDIA Generic Memory Interface
>>> + *
>>> + * Copyright (C) 2016 Host Mobility AB. All rights reserved.
>>> + *
>>> + * This file is licensed under the terms of the GNU General Public
>>> + * License version 2. This program is licensed "as is" without any
>>> + * warranty of any kind, whether express or implied.
>>> + */
>>> +#include <linux/clk.h>
>>> +#include <linux/delay.h>
>>> +#include <linux/io.h>
>>> +#include <linux/module.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/reset.h>
>>> +
>>> +#define TEGRA_GMI_CONFIG 0x00
>>> +#define TEGRA_GMI_CONFIG_GO BIT(31)
>>> +#define TEGRA_GMI_BUS_WIDTH_32BIT BIT(30)
>>> +#define TEGRA_GMI_MUX_MODE BIT(28)
>>> +#define TEGRA_GMI_RDY_BEFORE_DATA BIT(24)
>>> +#define TEGRA_GMI_RDY_ACTIVE_HIGH BIT(23)
>>> +#define TEGRA_GMI_ADV_ACTIVE_HIGH BIT(22)
>>> +#define TEGRA_GMI_OE_ACTIVE_HIGH BIT(21)
>>> +#define TEGRA_GMI_CS_ACTIVE_HIGH BIT(20)
>>> +#define TEGRA_GMI_CS_SELECT(x) ((x & 0x7) << 4)
>>> +
>>> +#define TEGRA_GMI_TIMING0 0x10
>>> +#define TEGRA_GMI_MUXED_WIDTH(x) ((x & 0xf) << 12)
>>> +#define TEGRA_GMI_HOLD_WIDTH(x) ((x & 0xf) << 8)
>>> +#define TEGRA_GMI_ADV_WIDTH(x) ((x & 0xf) << 4)
>>> +#define TEGRA_GMI_CE_WIDTH(x) (x & 0xf)
>>> +
>>> +#define TEGRA_GMI_TIMING1 0x14
>>> +#define TEGRA_GMI_WE_WIDTH(x) ((x & 0xff) << 16)
>>> +#define TEGRA_GMI_OE_WIDTH(x) ((x & 0xff) << 8)
>>> +#define TEGRA_GMI_WAIT_WIDTH(x) (x & 0xff)
>>> +
>>> +struct tegra_gmi_priv {
>>> + void __iomem *base;
>>> + struct reset_control *rst;
>>> + struct clk *clk;
>>> +
>>> + u32 snor_config;
>>> + u32 snor_timing0;
>>> + u32 snor_timing1;
>>> +};
>>> +
>>> +static void tegra_gmi_disable(struct tegra_gmi_priv *priv)
>>> +{
>>> + u32 config;
>>> +
>>> + /* stop GMI operation */
>>> + config = readl(priv->base + TEGRA_GMI_CONFIG);
>>> + config &= ~TEGRA_GMI_CONFIG_GO;
>>> + writel(config, priv->base + TEGRA_GMI_CONFIG);
>>> +
>>> + reset_control_assert(priv->rst);
>>> + clk_disable_unprepare(priv->clk);
>>> +}
>>> +
>>> +static void tegra_gmi_init(struct device *dev, struct tegra_gmi_priv
>>> *priv)
>>> +{
>>> + writel(priv->snor_timing0, priv->base + TEGRA_GMI_TIMING0);
>>> + writel(priv->snor_timing1, priv->base + TEGRA_GMI_TIMING1);
>>> +
>>> + priv->snor_config |= TEGRA_GMI_CONFIG_GO;
>>> + writel(priv->snor_config, priv->base + TEGRA_GMI_CONFIG);
>>> +}
>>> +
>>> +static int tegra_gmi_parse_dt(struct device *dev, struct tegra_gmi_priv
>>> *priv)
>>> +{
>>> + struct device_node *child =
>>> of_get_next_available_child(dev->of_node,
>>> + NULL);
>>> + u32 property, ranges[4];
>>> + int ret;
>>> +
>>> + if (!child) {
>>> + dev_warn(dev, "no child nodes found\n");
>>> + return 0;
>>
>>
>> Don't we want to return an error here? Otherwise, we will call
>> tegra_gmi_init() with an invalid configuration.
>
> True, we probably want that. My thought was that we might accept a
> tegra-gmi node without any child nodes and just print a warning. But
> since it is the child node that holds the bus configuration it makes
> sense to fail probe due to no child nodes.
I was wondering that too, but given that we then program and enable the
GMI I think it is best to just fail for now.
>>
>>
>>> + }
>>> +
>>> + /*
>>> + * We currently only support one child device due to lack of
>>> + * chip-select address decoding. Which means that we only have one
>>> + * chip-select line from the GMI controller.
>>> + */
>>> + if (of_get_child_count(dev->of_node) > 1)
>>> + dev_warn(dev, "only one child device is supported.");
>>> +
>>> + if (of_property_read_bool(child, "nvidia,snor-data-width-32bit"))
>>> + priv->snor_config |= TEGRA_GMI_BUS_WIDTH_32BIT;
>>> +
>>> + if (of_property_read_bool(child, "nvidia,snor-mux-mode"))
>>> + priv->snor_config |= TEGRA_GMI_MUX_MODE;
>>> +
>>> + if (of_property_read_bool(child,
>>> "nvidia,snor-rdy-active-before-data"))
>>> + priv->snor_config |= TEGRA_GMI_RDY_BEFORE_DATA;
>>> +
>>> + if (of_property_read_bool(child, "nvidia,snor-rdy-inv"))
>>> + priv->snor_config |= TEGRA_GMI_RDY_ACTIVE_HIGH;
>>> +
>>> + if (of_property_read_bool(child, "nvidia,snor-adv-inv"))
>>> + priv->snor_config |= TEGRA_GMI_ADV_ACTIVE_HIGH;
>>> +
>>> + if (of_property_read_bool(child, "nvidia,snor-oe-inv"))
>>> + priv->snor_config |= TEGRA_GMI_OE_ACTIVE_HIGH;
>>> +
>>> + if (of_property_read_bool(child, "nvidia,snor-cs-inv"))
>>> + priv->snor_config |= TEGRA_GMI_CS_ACTIVE_HIGH;
>>> +
>>> + /* Decode the CS# */
>>> + ret = of_property_read_u32_array(child, "ranges", ranges, 4);
>>> + if (ret < 0) {
>>> + /* Invalid binding */
>>> + if (ret == -EOVERFLOW) {
>>> + dev_err(dev, "invalid ranges length\n");
>>> + goto error_cs_decode;
>>> + }
>>> +
>>> + /*
>>> + * If we reach here it means that the child node has an
>>> empty
>>> + * ranges or it does not exist at all. Attempt to decode
>>> the
>>> + * CS# from the reg property instead.
>>> + */
>>> + ret = of_property_read_u32(child, "reg", &property);
>>> + if (ret < 0) {
>>> + dev_err(dev, "no reg property found\n");
>>> + goto error_cs_decode;
>>> + }
>>> + } else {
>>> + property = ranges[1];
>>> + }
>>> +
>>> + priv->snor_config |= TEGRA_GMI_CS_SELECT(property);
>>
>>
>> Should we make sure the CS is a valid value before setting?
>
> The TEGRA_GMI_CS_SELECT(x) macro will truncate any erroneous CS value.
> But yeah we could do a sanity check instead and return an error if it
> is invalid.
>
>>
>>
>>> +
>>> + /* The default values that are provided below are reset values */
>>> + if (!of_property_read_u32(child, "nvidia,snor-muxed-width",
>>> &property))
>>> + priv->snor_timing0 |= TEGRA_GMI_MUXED_WIDTH(property);
>>> + else
>>> + priv->snor_timing0 |= TEGRA_GMI_MUXED_WIDTH(1);
>>> +
>>> + if (!of_property_read_u32(child, "nvidia,snor-hold-width",
>>> &property))
>>> + priv->snor_timing0 |= TEGRA_GMI_HOLD_WIDTH(property);
>>> + else
>>> + priv->snor_timing0 |= TEGRA_GMI_HOLD_WIDTH(1);
>>> +
>>> + if (!of_property_read_u32(child, "nvidia,snor-adv-width",
>>> &property))
>>> + priv->snor_timing0 |= TEGRA_GMI_ADV_WIDTH(property);
>>> + else
>>> + priv->snor_timing0 |= TEGRA_GMI_ADV_WIDTH(1);
>>> +
>>> + if (!of_property_read_u32(child, "nvidia,snor-ce-width",
>>> &property))
>>> + priv->snor_timing0 |= TEGRA_GMI_CE_WIDTH(property);
>>> + else
>>> + priv->snor_timing0 |= TEGRA_GMI_CE_WIDTH(4);
>>> +
>>> + if (!of_property_read_u32(child, "nvidia,snor-we-width",
>>> &property))
>>> + priv->snor_timing1 |= TEGRA_GMI_WE_WIDTH(property);
>>> + else
>>> + priv->snor_timing1 |= TEGRA_GMI_WE_WIDTH(1);
>>> +
>>> + if (!of_property_read_u32(child, "nvidia,snor-oe-width",
>>> &property))
>>> + priv->snor_timing1 |= TEGRA_GMI_OE_WIDTH(property);
>>> + else
>>> + priv->snor_timing1 |= TEGRA_GMI_OE_WIDTH(1);
>>> +
>>> + if (!of_property_read_u32(child, "nvidia,snor-wait-width",
>>> &property))
>>> + priv->snor_timing1 |= TEGRA_GMI_WAIT_WIDTH(property);
>>> + else
>>> + priv->snor_timing1 |= TEGRA_GMI_WAIT_WIDTH(3);
>>> +
>>> +error_cs_decode:
>>> + if (ret < 0)
>>> + dev_err(dev, "failed to decode chip-select number\n");
>>
>>
>> Nit do we need another error message here? Can we add the "failed to decode
>> CS" part the earlier message?
>
> Does it make sense to drop the two earlier messages instead and keep this one?
I think it is nice to have specific errors so we know where it failed.
You could just drop the above and when you add the test for making sure
the CS is valid add another error message for that. Not a big deal
either way. So I will leave to you to decide.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [crypto] [marvell-cesa] Possible regression after Linux 4.7
From: Romain Perier @ 2016-11-03 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58174e5d.233ac20a.a4335.5656@mx.google.com>
Hello,
Le 31/10/2016 ? 14:59, radioconfusion at gmail.com a ?crit :
> Do you have any improvement for the issue?
> Please let me know if you need any help to resolve it.
>
> Best Regards,
> Jussi
>
Sorry for the delay.
Could you try to revert locally commit
2786cee8e50bb4b4303dc22665f391b72318fa84 (crypto: marvell - Move SRAM
I/O operations to step functions) ?
It seems to fix most of the issues I had with curl.
I will continue to investigate, that's just to confirm if it fixes the
issues for you.
Thanks,
Romain
--
Romain Perier, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 0/3] fix ohci phy name
From: Axel Haslam @ 2016-11-03 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d72af1ff-52f1-09ea-ee22-110c163d52f8@ti.com>
On Thu, Nov 3, 2016 at 1:00 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> On Thursday 03 November 2016 01:54 PM, Axel Haslam wrote:
>> Hi Sekhar, David,
>>
>> It might make sense to have this patch series,
>> squashed into a single patch, would you agree,
>> or do you prefer it as is: one-per-subsystem?
>
> Patches in the current form are okay. Some coordination is required in
> getting them merged though. I am happy to take the driver patches
> through ARM-SoC with ack from respective maintainers.
>
> I will need to carry the platform patch through my tree because it
> conflicts with other changes I have already queued.
>
> That said, I am unable to review 3/3 since I am unable to find its baseline.
>
ok, ill send v2 fixing Davids comments on the commit messages
and referencing the missing patch that is queued on usb-next.
-Axel
> Thanks,
> Sekhar
^ permalink raw reply
* [PATCHv2] PCI: QDF2432 32 bit config space accessors
From: Bjorn Helgaas @ 2016-11-03 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3fd26a0d-a5c2-c385-866e-b957dffb7dda@codeaurora.org>
On Wed, Nov 02, 2016 at 12:36:16PM -0400, Sinan Kaya wrote:
> Hi Bjorn,
>
> On 11/2/2016 12:08 PM, Bjorn Helgaas wrote:
> > On Tue, Nov 01, 2016 at 07:06:31AM -0600, cov at codeaurora.org wrote:
> >> Hi Bjorn,
> >>
> >> On 2016-10-31 15:48, Bjorn Helgaas wrote:
> >>> On Wed, Sep 21, 2016 at 06:38:05PM -0400, Christopher Covington wrote:
> >>>> The Qualcomm Technologies QDF2432 SoC does not support accesses
> >>>> smaller
> >>>> than 32 bits to the PCI configuration space. Register the appropriate
> >>>> quirk.
> >>>>
> >>>> Signed-off-by: Christopher Covington <cov@codeaurora.org>
> >>>
> >>> Hi Christopher,
> >>>
> >>> Can you rebase this against v4.9-rc1? It no longer applies to my tree.
> >>
> >> I apologize for not being clearer. This patch depends on:
> >>
> >> PCI/ACPI: Extend pci_mcfg_lookup() responsibilities
> >> PCI/ACPI: Check platform-specific ECAM quirks
> >>
> >> These patches from Tomasz Nowicki were previously in your pci/ecam-v6
> >> branch, but that seems to have come and gone. How would you like to
> >> proceed?
> >
> > Oh yes, that's right, I forgot that connection. I'm afraid I kind of
> > dropped the ball on that thread, so I went back and read through it
> > again.
> >
> > I *think* the current state is:
> >
> > - I'm OK with the first two patches that add the quirk
> > infrastructure.
> >
> > - My issue with the last three patches that add ThunderX quirks is
> > that there's no generic description of the ECAM address space.
> >
> > So if I understand correctly, your Qualcomm patch depends only on the
> > first two patches.
> >
> > Then the question is how the Qualcomm ECAM address space is described.
> > Your quirk overrides the default pci_generic_ecam_ops with the
> > &pci_32b_ops, but it doesn't touch the address space part, so I assume
> > the bus ranges and corresponding address space in your MCFG is
> > correct. So far, so good.
>
> Qualcomm ECAM space includes both the root port and the endpoint address
> space with a single contiguous 256 MB address space described in MCFG table.
> There is no need to describe additional resources like PNP0C02.
This is the crucial point I have failed to communicate clearly: the
PNP0C02 resource is *always* required, even if the MCFG is correct.
The reason is that MCFG is a PCI-specific table, and it should be
possible to boot a kernel with no PCI support. That kernel will not
look at the MCFG. The PCI hardware will still be present and will
still consume the ECAM space, so the OS must be able to discover that
the ECAM space is not available for other devices.
The usual way to for the OS to discover that would be via the _CRS of
a PNP0A03 or PNP0A08 host bridge device. _CRS is what I mean by a
"generic" way to describe this address space, because the ACPI core
can interpret _CRS for all ACPI devices, even if the kernel doesn't
contain drivers for all of those devices.
It turns out that we can't use the _CRS of host bridges because of the
Producer/Consumer bit screwup [1]. So the fallback is to include the
ECAM space in the _CRS of a PNP0C02 device. This is what the PCI
Firmware spec r3.0, Table 4-2, footnote 2 is talking about.
Bjorn
[1] The original ACPI spec intent was that Consumer resources would be
space like ECAM that is consumed directly by the bridge, and Producer
resources would be the windows forwarded down to PCI. But BIOSes
didn't use the Producer/Consumer bit consistently, so we have to
assume that all resources in host bridge _CRS are windows, which
leaves us no way to describe the Consumer resources.
^ permalink raw reply
* [PATCH v14 14/16] vfio/type1: Check doorbell safety
From: Auger Eric @ 2016-11-03 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR04MB1321EAD1CE91D2B6FC04BB55FFA30@HE1PR04MB1321.eurprd04.prod.outlook.com>
Hi Diana,
On 03/11/2016 14:45, Diana Madalina Craciun wrote:
> Hi Eric,
>
> On 10/12/2016 04:23 PM, Eric Auger wrote:
>> On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted
>> by the msi controller.
>>
>> Since we currently have no way to detect whether the MSI controller is
>> upstream or downstream to the IOMMU we rely on the MSI doorbell information
>> registered by the interrupt controllers. In case at least one doorbell
>> does not implement proper isolation, we state the assignment is unsafe
>> with regard to interrupts. This is a coarse assessment but should allow to
>> wait for a better system description.
>>
>> At this point ARM sMMU still advertises IOMMU_CAP_INTR_REMAP. This is
>> removed in next patch.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>> v13 -> v15:
>> - check vfio_msi_resv before checking whether msi doorbell is safe
>>
>> v9 -> v10:
>> - coarse safety assessment based on MSI doorbell info
>>
>> v3 -> v4:
>> - rename vfio_msi_parent_irq_remapping_capable into vfio_safe_irq_domain
>> and irq_remapping into safe_irq_domains
>>
>> v2 -> v3:
>> - protect vfio_msi_parent_irq_remapping_capable with
>> CONFIG_GENERIC_MSI_IRQ_DOMAIN
>> ---
>> drivers/vfio/vfio_iommu_type1.c | 30 +++++++++++++++++++++++++++++-
>> 1 file changed, 29 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
>> index e0c97ef..c18ba9d 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -442,6 +442,29 @@ static void vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma *dma)
>> }
>>
>> /**
>> + * vfio_msi_resv - Return whether any VFIO iommu domain requires
>> + * MSI mapping
>> + *
>> + * @iommu: vfio iommu handle
>> + *
>> + * Return: true of MSI mapping is needed, false otherwise
>> + */
>> +static bool vfio_msi_resv(struct vfio_iommu *iommu)
>> +{
>> + struct iommu_domain_msi_resv msi_resv;
>> + struct vfio_domain *d;
>> + int ret;
>> +
>> + list_for_each_entry(d, &iommu->domain_list, next) {
>> + ret = iommu_domain_get_attr(d->domain, DOMAIN_ATTR_MSI_RESV,
>> + &msi_resv);
>> + if (!ret)
>> + return true;
>> + }
>> + return false;
>> +}
>> +
>> +/**
>> * vfio_set_msi_aperture - Sets the msi aperture on all domains
>> * requesting MSI mapping
>> *
>> @@ -945,8 +968,13 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
>> INIT_LIST_HEAD(&domain->group_list);
>> list_add(&group->next, &domain->group_list);
>>
>> + /*
>> + * to advertise safe interrupts either the IOMMU or the MSI controllers
>> + * must support IRQ remapping (aka. interrupt translation)
>> + */
>> if (!allow_unsafe_interrupts &&
>> - !iommu_capable(bus, IOMMU_CAP_INTR_REMAP)) {
>> + (!iommu_capable(bus, IOMMU_CAP_INTR_REMAP) &&
>> + !(vfio_msi_resv(iommu) && iommu_msi_doorbell_safe()))) {
>> pr_warn("%s: No interrupt remapping support. Use the module param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this platform\n",
>> __func__);
>> ret = -EPERM;
>
> I understand from the other discussions that you will respin these
> series, but anyway I have tested this version with GICV3 + ITS and it
> stops here. As I have a GICv3 I am not supposed to enable allow unsafe
> interrupts. What I see is that vfio_msi_resv returns false just because
> the iommu->domain_list list is empty. The newly created domain is
> actually added to the domain_list at the end of this function, so it
> seems normal for the list to be empty at this point.
Thanks for reporting the issue. You are fully right. I must have missed
that test. I should just check the current iommu_domain attribute I think.
waiting for a fix, please probe the vfio_iommu_type1 module with
allow_unsafe_interrupts=1
Thanks
Eric
>
> Thanks,
>
> Diana
>
>
^ permalink raw reply
* [PATCH] arm64: errata: Check for --fix-cortex-a53-843419 and --fix-cortex-a53
From: Will Deacon @ 2016-11-03 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2d72cbbb-df03-267c-53b0-e3083a746175@gmail.com>
On Wed, Nov 02, 2016 at 02:57:26PM -0700, Florian Fainelli wrote:
> On 11/02/2016 02:41 PM, Markus Mayer wrote:
> > On 2 November 2016 at 14:27, Will Deacon <will.deacon@arm.com> wrote:
> >> On Wed, Nov 02, 2016 at 02:07:17PM -0700, Markus Mayer wrote:
> >>> The question I am asking is: What do we have to lose by supporting both options?
> >>
> >> We end up passing "--fix-cortex-a53" to the linker, without knowing what it
> >> might do in the future.
> >
> > It seems highly unlikely that such a generic option would be added in
> > the future, both, because the precedent has been set for topic
> > specific options, and because they know it has been used in the past,
> > so they wouldn't add a previously used option to do something
> > completely different. (And if they really did, then that would be a
> > huge binutils bug.)
> >
> > So, we have a trade-off between a real world problem that does
> > currently exist and avoiding a theoretical issue that may never
> > materialize.
>
> Agreed, also the way Markus' patch is designed makes it such that we
> first try the full and current option name, and if not supported, try
> the second (and earlier, now obsolete) option name, so I really don't
> see a lot of room for things to go wrong here...
It's not beyond the realms of possibility that ld will grow a
"fix-cortex-a53" option in the future, that enables all of the a53
workarounds. Since ld is the linker supported by the kernel and gold isn't,
I don't want to pass this option down.
If you can't change toolchain and you want this worked around, why can't you
either build gold with it enabled by default, or pass the extra flag on the
command line to the kernel build system?
Will
^ permalink raw reply
* [PATCH v2] iio: adc: at91: add suspend and resume callback
From: Ludovic Desroches @ 2016-11-03 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478078508-24541-1-git-send-email-wenyou.yang@atmel.com>
On Wed, Nov 02, 2016 at 05:21:48PM +0800, Wenyou Yang wrote:
> Add suspend/resume callback, support the pinctrl sleep state when
> the system suspend as well.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Thanks
> ---
>
> Changes in v2:
> - Use CONFIG_PM_SLEEP.
> - Use SIMPLE_DEV_PM_OPS macro.
>
> drivers/iio/adc/at91_adc.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index bbdac07..34b928c 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -30,6 +30,7 @@
> #include <linux/iio/trigger.h>
> #include <linux/iio/trigger_consumer.h>
> #include <linux/iio/triggered_buffer.h>
> +#include <linux/pinctrl/consumer.h>
>
> /* Registers */
> #define AT91_ADC_CR 0x00 /* Control Register */
> @@ -1347,6 +1348,32 @@ static int at91_adc_remove(struct platform_device *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int at91_adc_suspend(struct device *dev)
> +{
> + struct iio_dev *idev = platform_get_drvdata(to_platform_device(dev));
> + struct at91_adc_state *st = iio_priv(idev);
> +
> + pinctrl_pm_select_sleep_state(dev);
> + clk_disable_unprepare(st->clk);
> +
> + return 0;
> +}
> +
> +static int at91_adc_resume(struct device *dev)
> +{
> + struct iio_dev *idev = platform_get_drvdata(to_platform_device(dev));
> + struct at91_adc_state *st = iio_priv(idev);
> +
> + clk_prepare_enable(st->clk);
> + pinctrl_pm_select_default_state(dev);
> +
> + return 0;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(at91_adc_pm_ops, at91_adc_suspend, at91_adc_resume);
> +
> static struct at91_adc_caps at91sam9260_caps = {
> .calc_startup_ticks = calc_startup_ticks_9260,
> .num_channels = 4,
> @@ -1441,6 +1468,7 @@ static struct platform_driver at91_adc_driver = {
> .driver = {
> .name = DRIVER_NAME,
> .of_match_table = of_match_ptr(at91_adc_dt_ids),
> + .pm = &at91_adc_pm_ops,
> },
> };
>
> --
> 2.7.4
>
^ permalink raw reply
* Use of GICv3/ITS with PCIe host-generic driver - resizing ITS MAPD?
From: Alan Douglas @ 2016-11-03 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8637j9iomo.fsf@arm.com>
Hi Marc,
> >> > When setting up bus 0, the ITS device is created, and
> >> > its_build_map_cmd() sets the size of the ITS MAPD based on the
> >> > number of interrupts claimed by bus 0. When subsequent buses are
> >> > enumerated, the ITS device will be reused, however we do not
> >> > increase the number of supported interrupts to allow for the
> >> > additional interrupts claimed by the additional devices being
> >> > enumerated. (This can be seen in its_msi_prepare(), which is
> >> > called for each device which has MSI/MSI-X enabled, and will reuse
> >> > an existing ITS. )
> >>
> >> Am I right in understanding that all the PCIe devices in your system
> >> end-up aliasing to the same RequesterID? If so, that's a major issue.
> >> The ITS is designed so that each device exposes its *own* RID, and
> >> have its own Interrupt Translation Table (ITT).
> >>
> >> In your case, you seem to first discover the root port, which is not
> >> upstream of anything, so it doesn't alias with anything at that
> >> point. We allocate the corresponding ITT, and it's all fine. Until we
> >> start probing the rest, and ugly things happen.
> >>
> > Yes, your understanding is correct. I will dig into this a bit
> > further to see what is wrong then send an update. I suspect my DTS
> > msi mapping.
>
> Right. That would explain a lot of what you're seeing. In general, and unless
> you have some funky remapping going on, you're better off having a very
> straightforward msi-map property in your RC node (such as example
> #1 in Documentation/devicetree/bindings/pci/pci-msi.txt).
The problem was that I had an msi-map-mask specified such that all
requester IDs were seen as zero. Now fixed that and checked that the
requester ID for each device is being correctly provided by HW to the GIC,
and all is now working correctly with without any patches required.
Thanks for your help.
Alan
^ permalink raw reply
* [RFC PATCH 0/3] ARM64: meson-gxbb: Add support for system suspend
From: Neil Armstrong @ 2016-11-03 14:29 UTC (permalink / raw)
To: linux-arm-kernel
Thie patchset is a very experiment patchset to support the System Suspend
feature of the Amlogic Meson GX SoCs.
These SoCs implements system suspend using a non-standard PSCI CPU_SUSPEND
parameter to enter system suspend.
A small driver is added to properly fill the platform_suspend_ops and make
to correct SMC call.
In order to wake up from an alarm, these SoCs have a special memory mapped
register where an alarm time delay in seconds is stored.
In order to reuse the RTC wakealarm feature, implement a fake RTC device
that uses the system time to calculate a delay to write to the register.
Note that this RFC is here to seek a better way to handle these platform
specific features.
Neil Armstrong (3):
ARM64: meson: Add Amlogic Meson GX PM Suspend
rtc: Add Amlogic Virtual Wake RTC
ARM64: dts: meson-gxbb: Add support for PM and Virtual RTC
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 9 ++
drivers/firmware/meson/Kconfig | 6 +
drivers/firmware/meson/Makefile | 1 +
drivers/firmware/meson/meson_gx_pm.c | 86 +++++++++++++++
drivers/rtc/Kconfig | 10 ++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-meson-vrtc.c | 164 ++++++++++++++++++++++++++++
7 files changed, 277 insertions(+)
create mode 100644 drivers/firmware/meson/meson_gx_pm.c
create mode 100644 drivers/rtc/rtc-meson-vrtc.c
--
1.9.1
^ permalink raw reply
* [RFC PATCH 1/3] ARM64: meson: Add Amlogic Meson GX PM Suspend
From: Neil Armstrong @ 2016-11-03 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478183365-23708-1-git-send-email-narmstrong@baylibre.com>
The Amlogic Meson GX SoCs uses a non-standard argument to the
PSCI CPU_SUSPEND call to enter system suspend.
Implement such call within platform_suspend_ops.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/firmware/meson/Kconfig | 6 +++
drivers/firmware/meson/Makefile | 1 +
drivers/firmware/meson/meson_gx_pm.c | 86 ++++++++++++++++++++++++++++++++++++
3 files changed, 93 insertions(+)
create mode 100644 drivers/firmware/meson/meson_gx_pm.c
diff --git a/drivers/firmware/meson/Kconfig b/drivers/firmware/meson/Kconfig
index 170d7e8..5b3fea3 100644
--- a/drivers/firmware/meson/Kconfig
+++ b/drivers/firmware/meson/Kconfig
@@ -7,3 +7,9 @@ config MESON_SM
depends on ARM64_4K_PAGES
help
Say y here to enable the Amlogic secure monitor driver
+
+config MESON_GX_PM
+ bool
+ default ARCH_MESON if ARM64
+ help
+ Say y here to enable the Amlogic GX SoC Power Management
diff --git a/drivers/firmware/meson/Makefile b/drivers/firmware/meson/Makefile
index 9ab3884..b6e285d 100644
--- a/drivers/firmware/meson/Makefile
+++ b/drivers/firmware/meson/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_MESON_SM) += meson_sm.o
+obj-$(CONFIG_MESON_GX_PM) += meson_gx_pm.o
diff --git a/drivers/firmware/meson/meson_gx_pm.c b/drivers/firmware/meson/meson_gx_pm.c
new file mode 100644
index 0000000..c104c2e
--- /dev/null
+++ b/drivers/firmware/meson/meson_gx_pm.c
@@ -0,0 +1,86 @@
+/*
+ * Amlogic Meson GX Power Management
+ *
+ * Copyright (c) 2016 Baylibre, SAS.
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License 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/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/suspend.h>
+#include <linux/arm-smccc.h>
+
+#include <uapi/linux/psci.h>
+
+#include <asm/suspend.h>
+
+/*
+ * The Amlogic GX SoCs uses a special argument value to the
+ * PSCI CPU_SUSPEND method to enter SUSPEND_MEM.
+ */
+
+#define MESON_SUSPEND_PARAM 0x0010000
+#define PSCI_FN_NATIVE(version, name) PSCI_##version##_FN64_##name
+
+static int meson_gx_suspend_finish(unsigned long arg)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(PSCI_FN_NATIVE(0_2, CPU_SUSPEND), arg,
+ virt_to_phys(cpu_resume), 0, 0, 0, 0, 0, &res);
+
+ return res.a0;
+}
+
+static int meson_gx_suspend_enter(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_MEM:
+ return cpu_suspend(MESON_SUSPEND_PARAM,
+ meson_gx_suspend_finish);
+ }
+
+ return -EINVAL;
+}
+
+static const struct platform_suspend_ops meson_gx_pm_ops = {
+ .enter = meson_gx_suspend_enter,
+ .valid = suspend_valid_only_mem,
+};
+
+static const struct of_device_id meson_gx_pm_match[] = {
+ { .compatible = "amlogic,meson-gx-pm", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, meson_gx_pm_match);
+
+static int meson_gx_pm_probe(struct platform_device *pdev)
+{
+ suspend_set_ops(&meson_gx_pm_ops);
+
+ return 0;
+}
+
+static struct platform_driver meson_gx_pm_driver = {
+ .probe = meson_gx_pm_probe,
+ .driver = {
+ .name = "meson-gx-pm",
+ .of_match_table = meson_gx_pm_match,
+ },
+};
+
+module_platform_driver(meson_gx_pm_driver);
+
+MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
+MODULE_DESCRIPTION("Amlogic Meson GX PM driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [RFC PATCH 2/3] rtc: Add Amlogic Virtual Wake RTC
From: Neil Armstrong @ 2016-11-03 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478183365-23708-1-git-send-email-narmstrong@baylibre.com>
The Amlogic Meson GX SoCs uses a special register to store the
time in seconds to wakeup after a system suspend.
In order to be able to reuse the RTC wakealarm feature, this
driver implements a fake RTC device which uses the system time
to deduce a suspend delay.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/rtc/Kconfig | 10 +++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-meson-vrtc.c | 164 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 175 insertions(+)
create mode 100644 drivers/rtc/rtc-meson-vrtc.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index e859d14..d0f65fb 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -351,6 +351,16 @@ config RTC_DRV_MAX77686
This driver can also be built as a module. If so, the module
will be called rtc-max77686.
+config RTC_DRV_MESON_VRTC
+ tristate "Amlogic Meson Virtual RTC"
+ depends on ARCH_MESON
+ help
+ If you say yes here you will get support for the
+ Virtual RTC of Amlogic SoCs.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-meson-vrtc.
+
config RTC_DRV_RK808
tristate "Rockchip RK808/RK818 RTC"
depends on MFD_RK808
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 1ac694a..feb83ad 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -92,6 +92,7 @@ obj-$(CONFIG_RTC_DRV_MAX8907) += rtc-max8907.o
obj-$(CONFIG_RTC_DRV_MAX8925) += rtc-max8925.o
obj-$(CONFIG_RTC_DRV_MAX8997) += rtc-max8997.o
obj-$(CONFIG_RTC_DRV_MAX8998) += rtc-max8998.o
+obj-$(CONFIG_RTC_DRV_MESON_VRTC)+= rtc-meson-vrtc.o
obj-$(CONFIG_RTC_DRV_MC13XXX) += rtc-mc13xxx.o
obj-$(CONFIG_RTC_DRV_MCP795) += rtc-mcp795.o
obj-$(CONFIG_RTC_DRV_MOXART) += rtc-moxart.o
diff --git a/drivers/rtc/rtc-meson-vrtc.c b/drivers/rtc/rtc-meson-vrtc.c
new file mode 100644
index 0000000..34c45bd
--- /dev/null
+++ b/drivers/rtc/rtc-meson-vrtc.c
@@ -0,0 +1,164 @@
+/*
+ * drivers/rtc/rtc-meson-vrtc.c
+ *
+ * Copyright (C) 2016 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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/module.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+#include <linux/slab.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/pm_wakeup.h>
+#include <linux/time64.h>
+
+struct meson_vrtc_data {
+ struct platform_device *pdev;
+ void __iomem *io_alarm;
+ struct rtc_device *rtc;
+ unsigned long alarm_time;
+};
+
+static int meson_vrtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ unsigned long local_time;
+ struct timeval time;
+
+ do_gettimeofday(&time);
+ local_time = time.tv_sec - (sys_tz.tz_minuteswest * 60);
+ rtc_time_to_tm(local_time, tm);
+
+ return 0;
+}
+
+static void meson_vrtc_set_wakeup_time(struct meson_vrtc_data *vrtc,
+ unsigned long time)
+{
+ writel_relaxed(time, vrtc->io_alarm);
+
+ dev_dbg(&vrtc->pdev->dev, "set_wakeup_time: %lu\n", time);
+}
+
+static int meson_vrtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
+{
+ struct meson_vrtc_data *vrtc = dev_get_drvdata(dev);
+ struct timeval time;
+ unsigned long local_time;
+ unsigned long alarm_secs;
+ int ret;
+
+ if (alarm->enabled) {
+ ret = rtc_tm_to_time(&alarm->time, &alarm_secs);
+ if (ret)
+ return ret;
+
+ do_gettimeofday(&time);
+ local_time = time.tv_sec - (sys_tz.tz_minuteswest * 60);
+
+ vrtc->alarm_time = alarm_secs;
+
+ if (alarm_secs >= local_time) {
+ alarm_secs = alarm_secs - local_time;
+
+ meson_vrtc_set_wakeup_time(vrtc, alarm_secs);
+
+ pr_debug("system will wakeup %lus later\n", alarm_secs);
+ }
+ } else {
+ vrtc->alarm_time = 0;
+ meson_vrtc_set_wakeup_time(vrtc, 0);
+ }
+
+ return 0;
+}
+
+static int meson_vrtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
+{
+ struct meson_vrtc_data *vrtc = dev_get_drvdata(dev);
+
+ if (!vrtc->alarm_time) {
+ alm->enabled = true;
+
+ rtc_time_to_tm(vrtc->alarm_time, &alm->time);
+ }
+
+ return 0;
+}
+
+static const struct rtc_class_ops meson_vrtc_ops = {
+ .read_time = meson_vrtc_read_time,
+ .set_alarm = meson_vrtc_set_alarm,
+ .read_alarm = meson_vrtc_read_alarm,
+};
+
+static int meson_vrtc_probe(struct platform_device *pdev)
+{
+ struct meson_vrtc_data *vrtc;
+ struct resource *res;
+
+ vrtc = devm_kzalloc(&pdev->dev, sizeof(*vrtc), GFP_KERNEL);
+ if (!vrtc)
+ return -ENOMEM;
+
+ vrtc->pdev = pdev;
+
+ /* Alarm registers */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ vrtc->io_alarm = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(vrtc->io_alarm))
+ return PTR_ERR(vrtc->io_alarm);
+
+ device_init_wakeup(&pdev->dev, 1);
+
+ platform_set_drvdata(pdev, vrtc);
+
+ vrtc->rtc = devm_rtc_device_register(&pdev->dev, "meson-vrtc",
+ &meson_vrtc_ops, THIS_MODULE);
+ if (IS_ERR(vrtc->rtc))
+ return PTR_ERR(vrtc->rtc);
+
+ return 0;
+}
+
+int meson_vrtc_resume(struct platform_device *pdev)
+{
+ struct meson_vrtc_data *vrtc = platform_get_drvdata(pdev);
+
+ meson_vrtc_set_wakeup_time(vrtc, 0);
+
+ return 0;
+}
+
+static const struct of_device_id meson_vrtc_dt_match[] = {
+ { .compatible = "amlogic,meson-vrtc"},
+ {},
+};
+MODULE_DEVICE_TABLE(of, meson_vrtc_dt_match);
+
+struct platform_driver meson_vrtc_driver = {
+ .driver = {
+ .name = "meson-vrtc",
+ .of_match_table = meson_vrtc_dt_match,
+ },
+ .probe = meson_vrtc_probe,
+ .resume = meson_vrtc_resume,
+};
+
+module_platform_driver(meson_vrtc_driver);
+
+MODULE_DESCRIPTION("Amlogic Virtual Wakeup RTC Timer driver");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [RFC PATCH 3/3] ARM64: dts: meson-gxbb: Add support for PM and Virtual RTC
From: Neil Armstrong @ 2016-11-03 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478183365-23708-1-git-send-email-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 2d69a3b..6c08d21 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -56,6 +56,10 @@
};
};
+ system-suspend {
+ compatible = "amlogic,meson-gx-pm";
+ };
+
efuse: efuse {
compatible = "amlogic,meson-gxbb-efuse";
#address-cells = <1>;
@@ -355,6 +359,11 @@
#reset-cells = <1>;
};
+ vrtc: rtc at 0a8 {
+ compatible = "amlogic,meson-vrtc";
+ reg = <0x0 0x000a8 0x0 0x4>;
+ };
+
ir: ir at 580 {
compatible = "amlogic,meson-gxbb-ir";
reg = <0x0 0x00580 0x0 0x40>;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/1] KVM: ARM64: Fix the issues when PMCCFILTR is configured
From: Wei Huang @ 2016-11-03 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <db2cdc7caf7dc40b0895e1b6f91c7758@codeaurora.org>
On 11/02/2016 11:11 PM, cov at codeaurora.org wrote:
> Hi Wei,
>
> On 2016-11-02 14:55, Wei Huang wrote:
>> KVM calls kvm_pmu_set_counter_event_type() when PMCCFILTR is configured.
>> But this function can't deals with PMCCFILTR correctly because the
>> evtCount
>> bit of PMCCFILTR, which is reserved 0, conflits with the SW_INCR event
>> type of other PMXEVTYPER<n> registers. To fix it, when eventsel == 0, KVM
>> shouldn't return immediately, but instead it needs to check further if
>> select_idx is ARMV8_PMU_CYCLE_IDX.
>>
>> Another issue is that KVM shouldn't copy the eventsel bits of PMCCFILTER
>> directly to attr.config. Istead it shoudl convert the request to
>> perf_event of type 0x11 (i.e. the "cpu cycle" event type).
>>
>> Signed-off-by: Wei Huang <wei@redhat.com>
>> ---
>> virt/kvm/arm/pmu.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
>> index 6e9c40e..13cc812 100644
>> --- a/virt/kvm/arm/pmu.c
>> +++ b/virt/kvm/arm/pmu.c
>> @@ -379,7 +379,8 @@ void kvm_pmu_set_counter_event_type(struct
>> kvm_vcpu *vcpu, u64 data,
>> eventsel = data & ARMV8_PMU_EVTYPE_EVENT;
>>
>> /* Software increment event does't need to be backed by a perf
>> event */
>> - if (eventsel == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
>> + if (eventsel == ARMV8_PMU_EVTYPE_EVENT_SW_INCR &&
>> + select_idx != ARMV8_PMU_CYCLE_IDX)
>> return;
>>
>> memset(&attr, 0, sizeof(struct perf_event_attr));
>> @@ -391,7 +392,7 @@ void kvm_pmu_set_counter_event_type(struct
>> kvm_vcpu *vcpu, u64 data,
>> attr.exclude_kernel = data & ARMV8_PMU_EXCLUDE_EL1 ? 1 : 0;
>> attr.exclude_hv = 1; /* Don't count EL2 events */
>> attr.exclude_host = 1; /* Don't count host events */
>> - attr.config = eventsel;
>> + attr.config = (select_idx == ARMV8_PMU_CYCLE_IDX) ? 0x011 :
>> eventsel;
>
> Nit: Is there some way you could use ARMV8_PMUV3_PERFCTR_CPU_CYCLES
> currently
> defined in arch/arm64/kernel/perf_event.c?
The event definitions in perf_event.c are local to this file. To use
them, I have to re-factor them out to a header file, which is bigger
than this patch intended. How about adding the following line to
arch/arm64/include/asm/perf_event.h (i.e. the same file of
ARMV8_PMU_EVTYPE_EVENT_SW_INCR)?
#define ARMV8_PMU_EVTYPE_EVENT_CPU_CYCLES 0x11
>
> Thanks,
> Cov
^ permalink raw reply
* [PATCH] clk: rockchip: fix some clocks' name to be more standard style
From: Heiko Stübner @ 2016-11-03 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <763cad68-a068-9a4b-e26d-2c459c2d4808@rock-chips.com>
Am Donnerstag, 3. November 2016, 16:52:48 schrieb Shawn Lin:
> On 2016/11/2 15:04, Jianqun Xu wrote:
> > Fix aclk_emmcgrf to aclk_emmc_grf, and fix aclk_emmccore to be
> > aclk_emmc_core.
>
> What is the standard style should be?
>
> TRM uses aclk_emmccore but not aclk_emmc_core, so should it be more
> standrad to keep it as-is?
I tend to agree with Shawn. While it looks like the missing "_" is some sort
of mistake, we should strive to follow TRM naming, so grepping so it becomes
easier to look for informations in these things in the TRM.
Same reason for naming our regulators and pinctrl after the names used in
device schematics, if available.
Heiko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox