* [RFC v3 PATCH 00/25] Allow NOMMU for MULTIPLATFORM
From: Peter Korsgaard @ 2016-12-11 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211070104.GB3035@afzalpc>
>>>>> "Afzal" == Afzal Mohammed <afzal.mohd.ma@gmail.com> writes:
Hi,
>> You can build a toolchain and initramfs with Buildroot. Have a look at
>> the stm32f429 nommu config:
>>
>> https://git.buildroot.net/buildroot/tree/configs/stm32f429_disco_defconfig
> iiuc, it builds one for Cortex-M. i already had a file system w/
> busybox compiled using a Cortex-M toolchain (stolen from
> Pengutronix's OSELAS.Toolchain), which works on Cortex M4 (Vybrid
> VF610 M4 core). But it does not work here, i.e. on Cortex A, seems the
> above mentioned also would have the same effect.
Hmm, I'm not sure why a cortex-M toolchain wouldn't work on cortex-A, I
thought the 'M' instruction set was a pure subset of the 'A'.
> And in buildroot, couldn't see Cortex R option in menuconfig, and
> selecting Cortex-A's excludes flat binary target & presents only with
> ELF.
We indeed don't have cortex-R support. I'm not aware of any cortex-R
Linux support.
When you select a cortex-A variant, then we enable MMU support by
default, but you can disable it under toolchain options (Enable MMU) and
then the flat binary option is available.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH v3] SCPI (pre-v1.0): fix reading sensor value
From: Martin Blumenstingl @ 2016-12-11 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125005432.1205-1-martin.blumenstingl@googlemail.com>
I observed the following "strange" value when trying to read the SCPI
temperature sensor on my Amlogic GXM S912 device:
$ cat /sys/class/hwmon/hwmon0/temp1_input
6875990994467160116
The value reported by the original kernel (Amlogic vendor kernel, after
a reboot obviously) was 53C.
The Amlogic SCPI driver only uses a single 32bit value to read the
sensor value, instead of two. After stripping the upper 32bits from
above value gives "52" as result, which is basically identical to
what the vendor kernel reports.
I also compared this with the value shown by u-boot (since there's
less delay between "reboot to u-boot" compared to "reboot from mainline
kernel to vendor kernel") and the temperature reported by u-boot always
matches the lower 32bits of the value from scpi-hwmon temp1_input.
Changes since v2:
- use simplified approach from Sudeep Holla which is similar to v1
but avoids duplicate code by adding a simple
"if (scpi_info->is_legacy)" to scpi_sensor_get_value() instead of
duplicating the logic
Changes since v1:
- zero out the rx_buf before reading the mbox buffer (see long
description above) instead of introducing a separate legacy command
for reading the sensor value
- added patch 2/2 which validates the payload lengths (so nobody can
read or write data beyond rx_buf or tx_buf). This optional and patch
1/2 can be applied without it
Martin Blumenstingl (1):
firmware: arm_scpi: fix reading sensor values on pre-1.0 SCPI
firmwares
drivers/firmware/arm_scpi.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH v3] firmware: arm_scpi: fix reading sensor values on pre-1.0 SCPI firmwares
From: Martin Blumenstingl @ 2016-12-11 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211211432.13252-1-martin.blumenstingl@googlemail.com>
The pre-1.0 SCPI firmwares are using one __le32 as sensor value, while
the 1.0 SCPI protocol uses two __le32 as sensor values (a total of
64bit, split into 32bit upper and 32bit lower value).
Using an "struct sensor_value" to read the sensor value on a pre-1.0
SCPI firmware gives garbage in the "hi_val" field. Introducing a
separate function which handles scpi_ops.sensor_get_value for pre-1.0
SCPI firmware implementations ensures that we do not read memory which
was not written by the SCPI firmware (which fixes for example the
temperature reported by scpi-hwmon).
Suggested-by: Sudeep Holla <Sudeep.Holla@arm.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/firmware/arm_scpi.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 70e1323..9ad0b19 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -721,11 +721,17 @@ static int scpi_sensor_get_value(u16 sensor, u64 *val)
ret = scpi_send_message(CMD_SENSOR_VALUE, &id, sizeof(id),
&buf, sizeof(buf));
- if (!ret)
+ if (ret)
+ return ret;
+
+ if (scpi_info->is_legacy)
+ /* only 32-bits supported, hi_val can be junk */
+ *val = le32_to_cpu(buf.lo_val);
+ else
*val = (u64)le32_to_cpu(buf.hi_val) << 32 |
le32_to_cpu(buf.lo_val);
- return ret;
+ return 0;
}
static int scpi_device_get_power_state(u16 dev_id)
--
2.10.2
^ permalink raw reply related
* [PATCH] firmware: arm_scpi: fix reading sensor values on pre-1.0 SCPI firmwares
From: Martin Blumenstingl @ 2016-12-11 21:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <663deed4-fbbb-20ad-1943-dbd4e66e797f@arm.com>
On Wed, Dec 7, 2016 at 7:44 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 24/11/16 00:18, Martin Blumenstingl wrote:
>> The pre-1.0 SCPI firmwares are using one __le32 as sensor value, while
>> the 1.0 SCPI protocol uses two __le32 as sensor values (a total of
>> 64bit, split into 32bit upper and 32bit lower value).
>> Using an "struct sensor_value" to read the sensor value on a pre-1.0
>> SCPI firmware gives garbage in the "hi_val" field. Introducing a
>> separate function which handles scpi_ops.sensor_get_value for pre-1.0
>> SCPI firmware implementations ensures that we do not read memory which
>> was not written by the SCPI firmware (which fixes for example the
>> temperature reported by scpi-hwmon).
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> ---
>> drivers/firmware/arm_scpi.c | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
>> index 70e1323..19f750d 100644
>> --- a/drivers/firmware/arm_scpi.c
>> +++ b/drivers/firmware/arm_scpi.c
>> @@ -728,6 +728,20 @@ static int scpi_sensor_get_value(u16 sensor, u64 *val)
>> return ret;
>> }
>>
>> +static int legacy_scpi_sensor_get_value(u16 sensor, u64 *val)
>> +{
>> + __le16 id = cpu_to_le16(sensor);
>> + __le32 value;
>> + int ret;
>> +
>> + ret = scpi_send_message(CMD_SENSOR_VALUE, &id, sizeof(id),
>> + &value, sizeof(value));
>> + if (!ret)
>> + *val = le32_to_cpu(value);
>> +
>> + return ret;
>> +}
>
> Instead of duplicating the code so much, can we just manage something
> like this. If more commands need Rx len, then we can think of adding
> that. Even then reseting shared buffers is not good, we can clear the
> buffers on the stack.
I tested this approach and it's working fine! I just went ahead and
took your patch, moved the comment to a separate line, added a
description and send the patch as v3 (feel free to add yourself as
author and simply replace my Signed-off-by with a Tested-by).
> diff --git i/drivers/firmware/arm_scpi.c w/drivers/firmware/arm_scpi.c
> index 70e13230d8db..04aa873205e9 100644
> --- i/drivers/firmware/arm_scpi.c
> +++ w/drivers/firmware/arm_scpi.c
> @@ -721,11 +721,15 @@ static int scpi_sensor_get_value(u16 sensor, u64 *val)
>
> ret = scpi_send_message(CMD_SENSOR_VALUE, &id, sizeof(id),
> &buf, sizeof(buf));
> - if (!ret)
> + if (ret)
> + return ret;
> +
> + if (scpi_info->is_legacy) /* 32-bits supported, hi_val can be
> junk */
> + *val = le32_to_cpu(buf.lo_val);
> + else
> *val = (u64)le32_to_cpu(buf.hi_val) << 32 |
> le32_to_cpu(buf.lo_val);
> -
> - return ret;
> + return 0;
> }
>
> static int scpi_device_get_power_state(u16 dev_id)
>
>
> --
> Regards,
> Sudeep
^ permalink raw reply
* [PATCH 2/2] kcov: make kcov work properly with KASLR enabled
From: Alexander Popov @ 2016-12-11 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACT4Y+bOd-Lzs45jyEr73GkRc7zZDxL8Z3fSc+TeZVRNVC6M-A@mail.gmail.com>
On 11.12.2016 12:32, Dmitry Vyukov wrote:
> On Sun, Dec 11, 2016 at 1:50 AM, Alexander Popov <alex.popov@linux.com> wrote:
>> Subtract KASLR offset from the kernel addresses reported by kcov.
>> Tested on x86_64 and AArch64 (Hikey LeMaker).
>>
>> Signed-off-by: Alexander Popov <alex.popov@linux.com>
>> ---
>> kernel/kcov.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> I think generally this is the right thing to do.
>
> There are 2 pending patches for kcov by +Quentin (hopefully in mm):
> "kcov: add AFL-style tracing"
> "kcov: size of arena is now given in bytes"
> https://groups.google.com/forum/#!topic/syzkaller/gcqbIhKjGcY
> https://groups.google.com/d/msg/syzkaller/gcqbIhKjGcY/KQFryjBKCAAJ
>
> Your patch probably conflicts with them.
> Should you base them on top of these patches, so that Andrew can merge
> it without conflicts?
Excuse me, I can't find these patches in:
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
git://git.cmpxchg.org/linux-mmots.git
Could you point at the tree which I can rebase onto?
Should I cherry-pick Quentin's patches manually?
Best regards,
Alexander
^ permalink raw reply
* [PATCH v5 2/5] i2c: Add STM32F4 I2C driver
From: Wolfram Sang @ 2016-12-11 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481185563-8735-3-git-send-email-cedric.madianga@gmail.com>
Hi,
> +config I2C_STM32F4
> + tristate "STMicroelectronics STM32F4 I2C support"
> + depends on ARCH_STM32 || COMPILE_TEST
Double space.
> +#define STM32F4_I2C_MIN_FREQ 2
> +#define STM32F4_I2C_MAX_FREQ 42
Those two must be unsigned to fix the build error (e.g. 2U) reported by
build-bot.
Also, I get the following build warnings:
CC drivers/i2c/busses/i2c-stm32f4.o
drivers/i2c/busses/i2c-stm32f4.c: In function ?stm32f4_i2c_handle_rx_addr?:
drivers/i2c/busses/i2c-stm32f4.c:445:6: warning: variable ?sr2? set but not used [-Wunused-but-set-variable]
u32 sr2;
^~~
drivers/i2c/busses/i2c-stm32f4.c: In function ?stm32f4_i2c_isr_event?:
drivers/i2c/busses/i2c-stm32f4.c:496:41: warning: variable ?sr2? set but not used [-Wunused-but-set-variable]
u32 real_status, possible_status, ien, sr2;
I assume those are reads to clear the register, so we really don't need
to save the value in a variable.
Rest is looking good.
Thanks,
Wolfram
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161211/0379cc61/attachment.sig>
^ permalink raw reply
* [PATCH] pinctrl: meson: fix gpio request disabling other modes
From: Beniamino Galvani @ 2016-12-11 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206140817.11708-1-narmstrong@baylibre.com>
On Tue, Dec 06, 2016 at 03:08:16PM +0100, Neil Armstrong wrote:
> The pinctrl_gpio_request is called with the "full" gpio number, already
> containing the base, then meson_pmx_request_gpio is then called with the
> final pin number.
> Remove the base addition when calling meson_pmx_disable_other_groups.
>
> Fixes: 6ac730951104 ("pinctrl: add driver for Amlogic Meson SoCs")
> CC: Beniamino Galvani <b.galvani@gmail.com>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Beniamino Galvani <b.galvani@gmail.com>
^ permalink raw reply
* [PATCH 0/2] FPGA: TS-7300 FPGA manager
From: Florian Fainelli @ 2016-12-11 22:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This patch series adds support for loading bitstreams into the Altera Cyclone II
connected to an EP9302 on a TS-7300 board.
Florian Fainelli (1):
ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300
FPGA: Add TS-7300 FPGA manager
drivers/fpga/Kconfig | 7 ++
drivers/fpga/Makefile | 1 +
drivers/fpga/ts73xx-fpga.c | 165 +++++++++++++++++++++++++++++++++++++++++++++
drivers/mfd/Kconfig | 7 ++
4 files changed, 180 insertions(+)
create mode 100644 drivers/fpga/ts73xx-fpga.c
--
2.9.3
^ permalink raw reply
* [PATCH 1/2] ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300
From: Florian Fainelli @ 2016-12-11 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211221750.27743-1-f.fainelli@gmail.com>
Register the TS-7300 FPGA manager device drivers which allows us to load
bitstreams into the on-board Altera Cyclone II FPGA.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/mach-ep93xx/ts72xx.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 3b39ea353d30..acf72ea670ef 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -230,6 +230,28 @@ static struct ep93xx_eth_data __initdata ts72xx_eth_data = {
.phy_id = 1,
};
+#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
+
+/* Relative to EP93XX_CS1_PHYS_BASE */
+#define TS73XX_FPGA_LOADER_BASE 0x03c00000
+
+static struct resource ts73xx_fpga_resources[] = {
+ {
+ .start = EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE,
+ .end = EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE + 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device ts73xx_fpga_device = {
+ .name = "ts73xx-fpga-mgr",
+ .id = -1,
+ .resource = ts73xx_fpga_resources,
+ .num_resources = ARRAY_SIZE(ts73xx_fpga_resources),
+};
+
+#endif
+
static void __init ts72xx_init_machine(void)
{
ep93xx_init_devices();
@@ -238,6 +260,10 @@ static void __init ts72xx_init_machine(void)
platform_device_register(&ts72xx_wdt_device);
ep93xx_register_eth(&ts72xx_eth_data, 1);
+#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
+ if (board_is_ts7300())
+ platform_device_register(&ts73xx_fpga_device);
+#endif
}
MACHINE_START(TS72XX, "Technologic Systems TS-72xx SBC")
--
2.9.3
^ permalink raw reply related
* [PATCH 2/2] FPGA: Add TS-7300 FPGA manager
From: Florian Fainelli @ 2016-12-11 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211221750.27743-1-f.fainelli@gmail.com>
Add support for loading bitstreams on the Altera Cyclone II FPGA
populated on the TS-7300 board. This is done through the configuration
and data registers offered through a memory interface between the EP93xx
SoC and the FPGA.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/fpga/Kconfig | 7 ++
drivers/fpga/Makefile | 1 +
drivers/fpga/ts73xx-fpga.c | 165 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 173 insertions(+)
create mode 100644 drivers/fpga/ts73xx-fpga.c
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index cd84934774cc..109625707ef0 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -26,6 +26,13 @@ config FPGA_MGR_ZYNQ_FPGA
help
FPGA manager driver support for Xilinx Zynq FPGAs.
+config FPGA_MGR_TS73XX
+ tristate "Technologic Systems TS-73xx SBC FPGA Manager"
+ depends on ARCH_EP93XX && MACH_TS72XX
+ help
+ FPGA manager driver support for the Altera Cyclone II FPGA
+ present on the TS-73xx SBC boards.
+
endif # FPGA
endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8d83fc6b1613..5d51265cc1b4 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_FPGA) += fpga-mgr.o
# FPGA Manager Drivers
obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
+obj-$(CONFIG_FPGA_MGR_TS73XX) += ts73xx-fpga.o
diff --git a/drivers/fpga/ts73xx-fpga.c b/drivers/fpga/ts73xx-fpga.c
new file mode 100644
index 000000000000..2b3d5d668dfc
--- /dev/null
+++ b/drivers/fpga/ts73xx-fpga.c
@@ -0,0 +1,165 @@
+/*
+ * Technologic Systems TS-73xx SBC FPGA loader
+ *
+ * Copyright (C) 2016 Florian Fainelli <f.fainelli@gmail.com>
+ *
+ * FPGA Manager Driver for the on-board Altera Cyclone II FPGA found on
+ * TS-7300, heavily based on load_fpga.c in their vendor tree.
+ *
+ * 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 of the License.
+ *
+ * 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/delay.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/string.h>
+#include <linux/bitrev.h>
+#include <linux/fpga/fpga-mgr.h>
+
+#define TS73XX_FPGA_DATA_REG 0
+#define TS73XX_FPGA_CONFIG_REG 1
+
+struct ts73xx_fpga_priv {
+ void __iomem *io_base;
+ struct device *dev;
+};
+
+static enum fpga_mgr_states ts73xx_fpga_state(struct fpga_manager *mgr)
+{
+ return FPGA_MGR_STATE_UNKNOWN;
+}
+
+static int ts73xx_fpga_write_init(struct fpga_manager *mgr, u32 flags,
+ const char *buf, size_t count)
+{
+ struct ts73xx_fpga_priv *priv = mgr->priv;
+
+ /* Reset the FPGA */
+ writeb(0, priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ udelay(30);
+ writeb(0x2, priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ udelay(80);
+
+ return 0;
+}
+
+static inline int ts73xx_fpga_can_write(struct ts73xx_fpga_priv *priv)
+{
+ unsigned int timeout = 1000;
+ u8 reg;
+
+ while (timeout--) {
+ reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ if (!(reg & 0x1))
+ return 0;
+ cpu_relax();
+ }
+
+ return -ETIMEDOUT;
+}
+
+static int ts73xx_fpga_write(struct fpga_manager *mgr, const char *buf,
+ size_t count)
+{
+ struct ts73xx_fpga_priv *priv = mgr->priv;
+ size_t i = 0;
+ int ret;
+ u8 reg;
+
+ while (count--) {
+ ret = ts73xx_fpga_can_write(priv);
+ if (ret < 0)
+ return ret;
+
+ writeb(buf[i], priv->io_base + TS73XX_FPGA_DATA_REG);
+ i++;
+ }
+
+ usleep_range(1000, 2000);
+ reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ reg |= 0x8;
+ writeb(reg, priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ usleep_range(1000, 2000);
+
+ reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ reg &= ~0x8;
+ writeb(reg, priv->io_base + TS73XX_FPGA_CONFIG_REG);
+
+ return 0;
+}
+
+static int ts73xx_fpga_write_complete(struct fpga_manager *mgr, u32 flags)
+{
+ struct ts73xx_fpga_priv *priv = mgr->priv;
+ u8 reg;
+
+ reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ if ((reg & 0x4) != 0x4)
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
+static const struct fpga_manager_ops ts73xx_fpga_ops = {
+ .state = ts73xx_fpga_state,
+ .write_init = ts73xx_fpga_write_init,
+ .write = ts73xx_fpga_write,
+ .write_complete = ts73xx_fpga_write_complete,
+};
+
+static int ts73xx_fpga_probe(struct platform_device *pdev)
+{
+ struct device *kdev = &pdev->dev;
+ struct ts73xx_fpga_priv *priv;
+ struct fpga_manager *mgr;
+ struct resource *res;
+ int err;
+
+ priv = devm_kzalloc(kdev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = kdev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->io_base = devm_ioremap_resource(kdev, res);
+ if (IS_ERR(priv->io_base))
+ return PTR_ERR(priv->io_base);
+
+ err = fpga_mgr_register(kdev, "TS-73xx FPGA Manager",
+ &ts73xx_fpga_ops, priv);
+ if (err) {
+ dev_err(kdev, "failed to register FPGA manager\n");
+ return err;
+ }
+
+ return err;
+}
+
+static int ts73xx_fpga_remove(struct platform_device *pdev)
+{
+ fpga_mgr_unregister(&pdev->dev);
+
+ return 0;
+}
+
+static struct platform_driver ts73xx_fpga_driver = {
+ .driver = {
+ .name = "ts73xx-fpga-mgr",
+ },
+ .probe = ts73xx_fpga_probe,
+ .remove = ts73xx_fpga_remove,
+};
+module_platform_driver(ts73xx_fpga_driver);
+
+MODULE_AUTHOR("Florian Fainelli <f.fainelli@gmail.com>");
+MODULE_DESCRIPTION("TS-73xx FPGA Manager driver");
+MODULE_LICENSE("GPL v2");
--
2.9.3
^ permalink raw reply related
* [PATCH 2/2] FPGA: Add TS-7300 FPGA manager
From: Moritz Fischer @ 2016-12-11 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211221750.27743-3-f.fainelli@gmail.com>
Hi Florian,
can you Cc: linxu-fpga at vger.kernel.org for your next round?
On Sun, Dec 11, 2016 at 2:17 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Add support for loading bitstreams on the Altera Cyclone II FPGA
> populated on the TS-7300 board. This is done through the configuration
> and data registers offered through a memory interface between the EP93xx
> SoC and the FPGA.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/fpga/Kconfig | 7 ++
> drivers/fpga/Makefile | 1 +
> drivers/fpga/ts73xx-fpga.c | 165 +++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 173 insertions(+)
> create mode 100644 drivers/fpga/ts73xx-fpga.c
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index cd84934774cc..109625707ef0 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -26,6 +26,13 @@ config FPGA_MGR_ZYNQ_FPGA
> help
> FPGA manager driver support for Xilinx Zynq FPGAs.
>
> +config FPGA_MGR_TS73XX
> + tristate "Technologic Systems TS-73xx SBC FPGA Manager"
> + depends on ARCH_EP93XX && MACH_TS72XX
> + help
> + FPGA manager driver support for the Altera Cyclone II FPGA
> + present on the TS-73xx SBC boards.
> +
> endif # FPGA
>
> endmenu
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 8d83fc6b1613..5d51265cc1b4 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_FPGA) += fpga-mgr.o
> # FPGA Manager Drivers
> obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> +obj-$(CONFIG_FPGA_MGR_TS73XX) += ts73xx-fpga.o
> diff --git a/drivers/fpga/ts73xx-fpga.c b/drivers/fpga/ts73xx-fpga.c
> new file mode 100644
> index 000000000000..2b3d5d668dfc
> --- /dev/null
> +++ b/drivers/fpga/ts73xx-fpga.c
> @@ -0,0 +1,165 @@
> +/*
> + * Technologic Systems TS-73xx SBC FPGA loader
> + *
> + * Copyright (C) 2016 Florian Fainelli <f.fainelli@gmail.com>
> + *
> + * FPGA Manager Driver for the on-board Altera Cyclone II FPGA found on
> + * TS-7300, heavily based on load_fpga.c in their vendor tree.
> + *
> + * 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 of the License.
> + *
> + * 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/delay.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/string.h>
> +#include <linux/bitrev.h>
> +#include <linux/fpga/fpga-mgr.h>
> +
> +#define TS73XX_FPGA_DATA_REG 0
> +#define TS73XX_FPGA_CONFIG_REG 1
> +
> +struct ts73xx_fpga_priv {
> + void __iomem *io_base;
> + struct device *dev;
> +};
> +
> +static enum fpga_mgr_states ts73xx_fpga_state(struct fpga_manager *mgr)
> +{
> + return FPGA_MGR_STATE_UNKNOWN;
> +}
> +
> +static int ts73xx_fpga_write_init(struct fpga_manager *mgr, u32 flags,
> + const char *buf, size_t count)
> +{
> + struct ts73xx_fpga_priv *priv = mgr->priv;
> +
> + /* Reset the FPGA */
> + writeb(0, priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + udelay(30);
> + writeb(0x2, priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + udelay(80);
> +
> + return 0;
> +}
> +
> +static inline int ts73xx_fpga_can_write(struct ts73xx_fpga_priv *priv)
> +{
> + unsigned int timeout = 1000;
> + u8 reg;
> +
> + while (timeout--) {
> + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + if (!(reg & 0x1))
> + return 0;
> + cpu_relax();
> + }
You can use readb_poll_timeout() for this I think.
> +
> + return -ETIMEDOUT;
> +}
> +
> +static int ts73xx_fpga_write(struct fpga_manager *mgr, const char *buf,
> + size_t count)
> +{
> + struct ts73xx_fpga_priv *priv = mgr->priv;
> + size_t i = 0;
> + int ret;
> + u8 reg;
> +
> + while (count--) {
> + ret = ts73xx_fpga_can_write(priv);
> + if (ret < 0)
> + return ret;
> +
> + writeb(buf[i], priv->io_base + TS73XX_FPGA_DATA_REG);
> + i++;
> + }
> +
> + usleep_range(1000, 2000);
> + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + reg |= 0x8;
What's happening here?
> + writeb(reg, priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + usleep_range(1000, 2000);
> +
> + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + reg &= ~0x8;
and here? Can we have a named constant for these, or a comment to
explain what happens?
> + writeb(reg, priv->io_base + TS73XX_FPGA_CONFIG_REG);
> +
> + return 0;
> +}
> +
> +static int ts73xx_fpga_write_complete(struct fpga_manager *mgr, u32 flags)
> +{
> + struct ts73xx_fpga_priv *priv = mgr->priv;
> + u8 reg;
> +
> + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
> + if ((reg & 0x4) != 0x4)
Named constants, please
> + return -ETIMEDOUT;
> +
> + return 0;
> +}
> +
> +static const struct fpga_manager_ops ts73xx_fpga_ops = {
> + .state = ts73xx_fpga_state,
> + .write_init = ts73xx_fpga_write_init,
> + .write = ts73xx_fpga_write,
> + .write_complete = ts73xx_fpga_write_complete,
> +};
> +
> +static int ts73xx_fpga_probe(struct platform_device *pdev)
> +{
> + struct device *kdev = &pdev->dev;
> + struct ts73xx_fpga_priv *priv;
> + struct fpga_manager *mgr;
> + struct resource *res;
> + int err;
> +
> + priv = devm_kzalloc(kdev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = kdev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + priv->io_base = devm_ioremap_resource(kdev, res);
> + if (IS_ERR(priv->io_base))
> + return PTR_ERR(priv->io_base);
Maybe an error message here?
> +
> + err = fpga_mgr_register(kdev, "TS-73xx FPGA Manager",
> + &ts73xx_fpga_ops, priv);
> + if (err) {
> + dev_err(kdev, "failed to register FPGA manager\n");
> + return err;
> + }
> +
> + return err;
> +}
> +
> +static int ts73xx_fpga_remove(struct platform_device *pdev)
> +{
> + fpga_mgr_unregister(&pdev->dev);
> +
> + return 0;
> +}
> +
> +static struct platform_driver ts73xx_fpga_driver = {
> + .driver = {
> + .name = "ts73xx-fpga-mgr",
> + },
> + .probe = ts73xx_fpga_probe,
> + .remove = ts73xx_fpga_remove,
> +};
> +module_platform_driver(ts73xx_fpga_driver);
> +
> +MODULE_AUTHOR("Florian Fainelli <f.fainelli@gmail.com>");
> +MODULE_DESCRIPTION("TS-73xx FPGA Manager driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.9.3
>
Thanks,
Moritz
^ permalink raw reply
* sunxi-ng clocks: leaving certain clocks alone?
From: André Przywara @ 2016-12-11 23:54 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I was observing that the new sunxi-ng clock code apparently explicitly
turns off _all_ clocks that are not used or needed. I find this rather
unfortunate, as I wanted to use the THS temperature sensor from ARM
Trusted Firmware to implement emergency shutdown or DVFS throttling.
That works until the clock framework finds the clock (as enumerated in
ccu-sun50i-a64.c) and obviously explicitly clears bit 31 in the THS mod
clock register and bit 8 in the respective clock gate register.
Turning them manually back on via /dev/mem or removing the THS clock
from the sunxi-ng driver fixes this for me.
This was not happening with the old Allwinner clocks, since the kernel
wouldn't even know about it if there was no driver and the clock wasn't
mentioned in the DT.
Now with sunxi-ng even though the THS clock is not actually referenced
or used in the DT, the kernel turns it off. I would expect that upon
entering the kernel all unneeded clocks are turned off anyway, so there
is no need to mess with clocks that have no user, but are enumerated in
the ccu driver.
I wonder if this kills simplefb as well, for instance, since I believe
that U-Boot needs to turn on certain clocks and relies on them staying up.
So my questions:
1) Is this expected behaviour?
2) If yes, should it really be?
3) If yes, shouldn't there be way to explicitly tell Linux to leave that
clock alone, preferably via DT? Although the sunxi-ng clocks take
control over the whole CCU unit, I wonder if it should really mess with
clocks there are not referenced in the DT.
Maybe there is some way to reference those clocks via some dummy driver
or DT node to avoid this behaviour? Is there any prior art in this respect?
I think this issue will affect more future users (thinking of EFI RTC,
EFI graphics, etc.), so I wanted to start a discussion on this.
Any input welcome.
Cheers,
Andre.
P.S. For reference my use case: ARM Trusted Firmware (ATF) enables the
temperature sensor (THS) and programs a shutdown value. It programs the
respective interrupt as secure and registers an IRQ handler in ATF to
shutdown the system or take other appropriate matters to avoid
overheating. Additionally the sensor is exported via the generic SCPI
interface, so the existing scpi-hwmon driver picks it up and reports it
to whoever is interested in Linux land via the normal interfaces.
^ permalink raw reply
* [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
From: Jacky Bai @ 2016-12-12 2:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161208225424.GQ5423@codeaurora.org>
> Subject: Re: [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
>
> On 12/02, Bai Ping wrote:
> > Add necessary document update for i.MX6SLL support.
> >
> > Signed-off-by: Bai Ping <ping.bai@nxp.com>
> > ---
> > .../devicetree/bindings/clock/imx6sll-clock.txt | 13 ++++++++
> > .../bindings/pinctrl/fsl,imx6sll-pinctrl.txt | 37 ++++++++++++++++++++++
>
> Please split the bindings into different patches and put them closer to the
> drivers that use them in the series.
Ok, I will fix it in V2.
>
> > 2 files changed, 50 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > create mode 100644
> > Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> >
> > diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > new file mode 100644
> > index 0000000..4f52efa
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > @@ -0,0 +1,13 @@
> > +* Clock bindings for Freescale i.MX6 UltraLite
> > +
> > +Required properties:
> > +- compatible: Should be "fsl,imx6sll-ccm"
> > +- reg: Address and length of the register set
> > +- #clock-cells: Should be <1>
> > +- clocks: list of clock specifiers, must contain an entry for each
> > +required
> > + entry in clock-names
> > +- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
> > +
> > +The clock consumer should specify the desired clock by having the
> > +clock ID in its "clocks" phandle cell. See
> > +include/dt-bindings/clock/imx6sll-clock.h
> > +for the full list of i.MX6 SLL clock IDs.
>
> Can you add an example node here?
>
Thanks for review, I will add it in V2.
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
^ permalink raw reply
* [PATCH 03/11] driver: clk: imx: Add clock driver for imx6sll
From: Jacky Bai @ 2016-12-12 2:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161208225257.GP5423@codeaurora.org>
> Subject: Re: [PATCH 03/11] driver: clk: imx: Add clock driver for imx6sll
>
> On 12/02, Bai Ping wrote:
> > diff --git a/drivers/clk/imx/clk-imx6sll.c
> > b/drivers/clk/imx/clk-imx6sll.c new file mode 100644 index
> > 0000000..c5219e1
> > --- /dev/null
> > +++ b/drivers/clk/imx/clk-imx6sll.c
> > @@ -0,0 +1,366 @@
> > +/*
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + *
> > + * The code contained herein is licensed under the GNU General Public
> > + * License. You may obtain a copy of the GNU General Public License
> > + * Version 2 or later at the following locations:
> > + *
> > + * http://www.opensource.org/licenses/gpl-license.html
> > + * http://www.gnu.org/copyleft/gpl.html
> > + */
> > +
> > +#include <dt-bindings/clock/imx6sll-clock.h>
> > +#include <linux/clk.h>
> > +#include <linux/clkdev.h>
>
> Is this include used?
>
It seems no use, I will remove it in V2.
> > +#include <linux/err.h>
> > +#include <linux/init.h>
> > +#include <linux/io.h>
> > +#include <linux/of.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/types.h>
>
> Is there an include of clk_provider.h missing?
>
clk_provider.h is included in below "clk.h".
> > +
> > +#include "clk.h"
> > +
> > +#define BM_CCM_CCDR_MMDC_CH0_MASK (0x2 << 16)
> > +#define CCDR 0x4
> > +
> > +static const char *pll_bypass_src_sels[] = { "osc", "dummy", };
>
> const char * const? For all of these names.
>
ok, I will fix in V2.
> > +static const char *pll1_bypass_sels[] = { "pll1", "pll1_bypass_src",
> > +}; static const char *pll2_bypass_sels[] = { "pll2",
> > +"pll2_bypass_src", }; static const char *pll3_bypass_sels[] = {
> > +"pll3", "pll3_bypass_src", }; static const char *pll4_bypass_sels[] =
> > +{ "pll4", "pll4_bypass_src", }; static const char *pll5_bypass_sels[]
> > += { "pll5", "pll5_bypass_src", }; static const char
> > +*pll6_bypass_sels[] = { "pll6", "pll6_bypass_src", }; static const
> > +char *pll7_bypass_sels[] = { "pll7", "pll7_bypass_src", }; static
> > +const char *step_sels[] = { "osc", "pll2_pfd2_396m", }; static const
> > +char *pll1_sw_sels[] = { "pll1_sys", "step", }; static const char
> > +*axi_alt_sels[] = { "pll2_pfd2_396m", "pll3_pfd1_540m", }; static
> > +const char *axi_sels[] = {"periph", "axi_alt_sel", }; static const
> > +char *periph_pre_sels[] = { "pll2_bus", "pll2_pfd2_396m",
> > +"pll2_pfd0_352m", "pll2_198m", }; static const char
> > +*periph2_pre_sels[] = { "pll2_bus", "pll2_pfd2_396m",
> > +"pll2_pfd0_352m", "pll4_audio_div", }; static const char
> > +*periph_clk2_sels[] = { "pll3_usb_otg", "osc", "osc", }; static const
> > +char *periph2_clk2_sels[] = { "pll3_usb_otg", "osc", }; static const
> > +char *periph_sels[] = { "periph_pre", "periph_clk2", }; static const
> > +char *periph2_sels[] = { "periph2_pre", "periph2_clk2", }; static
> > +const char *usdhc_sels[] = { "pll2_pfd2_396m", "pll2_pfd0_352m", };
> > +static const char *ssi_sels[] = {"pll3_pfd2_508m", "pll3_pfd3_454m",
> > +"pll4_audio_div", "dummy",}; static const char *spdif_sels[] = {
> > +"pll4_audio_div", "pll3_pfd2_508m", "pll5_video_div", "pll3_usb_otg",
> > +}; static const char *ldb_di0_div_sels[] = { "ldb_di0_div_3_5",
> > +"ldb_di0_div_7", }; static const char *ldb_di1_div_sels[] = {
> > +"ldb_di1_div_3_5", "ldb_di1_div_7", }; static const char
> > +*ldb_di0_sels[] = { "pll5_video_div", "pll2_pfd0_352m",
> > +"pll2_pfd2_396m", "pll2_pfd3_594m", "pll2_pfd1_594m",
> > +"pll3_pfd3_454m", }; static const char *ldb_di1_sels[] = {
> > +"pll3_usb_otg", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll2_bus",
> > +"pll3_pfd3_454m", "pll3_pfd2_508m", }; static const char
> > +*lcdif_pre_sels[] = { "pll2_bus", "pll3_pfd3_454m", "pll5_video_div",
> > +"pll2_pfd0_352m", "pll2_pfd1_594m", "pll3_pfd1_540m", }; static const
> > +char *ecspi_sels[] = { "pll3_60m", "osc", }; static const char
> > +*uart_sels[] = { "pll3_80m", "osc", }; static const char
> > +*perclk_sels[] = { "ipg", "osc", }; static const char *lcdif_sels[] =
> > +{ "lcdif_podf", "ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
> > +
> > +static const char *epdc_pre_sels[] = { "pll2_bus", "pll3_usb_otg",
> > +"pll5_video_div", "pll2_pfd0_352m", "pll2_pfd2_396m",
> > +"pll3_pfd2_508m", }; static const char *epdc_sels[] = { "epdc_podf",
> > +"ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
> > +
> > +static struct clk *clks[IMX6SLL_CLK_END]; static struct
> > +clk_onecell_data clk_data;
> > +
> > +static int const clks_init_on[] __initconst = {
>
> static const int is more preferred style.
>
ok, will fix in V2.
> > + IMX6SLL_CLK_AIPSTZ1, IMX6SLL_CLK_AIPSTZ2,
> > + IMX6SLL_CLK_OCRAM, IMX6SLL_CLK_ARM, IMX6SLL_CLK_ROM,
> > + IMX6SLL_CLK_MMDC_P0_FAST, IMX6SLL_CLK_MMDC_P0_IPG, };
> > +
> > +static struct clk_div_table post_div_table[] = {
>
> const?
>
ok, will fix in V2.
> > + { .val = 2, .div = 1, },
> > + { .val = 1, .div = 2, },
> > + { .val = 0, .div = 4, },
> > + { }
> > +};
> > +
> > +static struct clk_div_table video_div_table[] = {
>
> const?
>
ok. will fix in V2.
> > + { .val = 0, .div = 1, },
> > + { .val = 1, .div = 2, },
> > + { .val = 2, .div = 1, },
> > + { .val = 3, .div = 4, },
> > + { }
> > +};
> > +
> > +static u32 share_count_audio;
> > +static u32 share_count_ssi1;
> > +static u32 share_count_ssi2;
> > +static u32 share_count_ssi3;
> > +
> > +static void __init imx6sll_clocks_init(struct device_node *ccm_node)
> > +{
> > + struct device_node *np;
> > + void __iomem *base;
> > + int i;
> > +
> > + clks[IMX6SLL_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
> > +
> > + clks[IMX6SLL_CLK_CKIL] = of_clk_get_by_name(ccm_node, "ckil");
> > + clks[IMX6SLL_CLK_OSC] = of_clk_get_by_name(ccm_node, "osc");
> > +
> > + /* ipp_di clock is external input */
> > + clks[IMX6SLL_CLK_IPP_DI0] = of_clk_get_by_name(ccm_node,
> "ipp_di0");
> > + clks[IMX6SLL_CLK_IPP_DI1] = of_clk_get_by_name(ccm_node,
> "ipp_di1");
> > +
> > + np = of_find_compatible_node(NULL, NULL, "fsl,imx6sll-anatop");
> > + base = of_iomap(np, 0);
> > + WARN_ON(!base);
> > +
> > + clks[IMX6SLL_PLL1_BYPASS_SRC] = imx_clk_mux("pll1_bypass_src",
> base + 0x00, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL2_BYPASS_SRC] = imx_clk_mux("pll2_bypass_src",
> base + 0x30, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL3_BYPASS_SRC] = imx_clk_mux("pll3_bypass_src",
> base + 0x10, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL4_BYPASS_SRC] = imx_clk_mux("pll4_bypass_src",
> base + 0x70, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL5_BYPASS_SRC] = imx_clk_mux("pll5_bypass_src",
> base + 0xa0, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL6_BYPASS_SRC] = imx_clk_mux("pll6_bypass_src",
> base + 0xe0, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > + clks[IMX6SLL_PLL7_BYPASS_SRC] = imx_clk_mux("pll7_bypass_src",
> base
> > ++ 0x20, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
> > +
> > + clks[IMX6SLL_CLK_PLL1] = imx_clk_pllv3(IMX_PLLV3_SYS, "pll1",
> "pll1_bypass_src", base + 0x00, 0x7f);
> > + clks[IMX6SLL_CLK_PLL2] = imx_clk_pllv3(IMX_PLLV3_GENERIC, "pll2",
> "pll2_bypass_src", base + 0x30, 0x1);
> > + clks[IMX6SLL_CLK_PLL3] = imx_clk_pllv3(IMX_PLLV3_USB, "pll3",
> "pll3_bypass_src", base + 0x10, 0x3);
> > + clks[IMX6SLL_CLK_PLL4] = imx_clk_pllv3(IMX_PLLV3_AV, "pll4",
> "pll4_bypass_src", base + 0x70, 0x7f);
> > + clks[IMX6SLL_CLK_PLL5] = imx_clk_pllv3(IMX_PLLV3_AV, "pll5",
> "pll5_bypass_src", base + 0xa0, 0x7f);
> > + clks[IMX6SLL_CLK_PLL6] = imx_clk_pllv3(IMX_PLLV3_ENET, "pll6",
> "pll6_bypass_src", base + 0xe0, 0x3);
> > + clks[IMX6SLL_CLK_PLL7] = imx_clk_pllv3(IMX_PLLV3_USB, "pll7",
> "pll7_bypass_src", base + 0x20, 0x3);
> > +
> > + clks[IMX6SLL_PLL1_BYPASS] = imx_clk_mux_flags("pll1_bypass", base
> + 0x00, 16, 1, pll1_bypass_sels, ARRAY_SIZE(pll1_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL2_BYPASS] = imx_clk_mux_flags("pll2_bypass", base
> + 0x30, 16, 1, pll2_bypass_sels, ARRAY_SIZE(pll2_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL3_BYPASS] = imx_clk_mux_flags("pll3_bypass", base
> + 0x10, 16, 1, pll3_bypass_sels, ARRAY_SIZE(pll3_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL4_BYPASS] = imx_clk_mux_flags("pll4_bypass", base
> + 0x70, 16, 1, pll4_bypass_sels, ARRAY_SIZE(pll4_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL5_BYPASS] = imx_clk_mux_flags("pll5_bypass", base
> + 0xa0, 16, 1, pll5_bypass_sels, ARRAY_SIZE(pll5_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL6_BYPASS] = imx_clk_mux_flags("pll6_bypass", base
> + 0xe0, 16, 1, pll6_bypass_sels, ARRAY_SIZE(pll6_bypass_sels),
> CLK_SET_RATE_PARENT);
> > + clks[IMX6SLL_PLL7_BYPASS] = imx_clk_mux_flags("pll7_bypass", base
> +
> > +0x20, 16, 1, pll7_bypass_sels, ARRAY_SIZE(pll7_bypass_sels),
> > +CLK_SET_RATE_PARENT);
> > +
> > + /* Do not bypass PLLs initially */
> > + clk_set_parent(clks[IMX6SLL_PLL1_BYPASS], clks[IMX6SLL_CLK_PLL1]);
> > + clk_set_parent(clks[IMX6SLL_PLL2_BYPASS], clks[IMX6SLL_CLK_PLL2]);
> > + clk_set_parent(clks[IMX6SLL_PLL3_BYPASS], clks[IMX6SLL_CLK_PLL3]);
> > + clk_set_parent(clks[IMX6SLL_PLL4_BYPASS], clks[IMX6SLL_CLK_PLL4]);
> > + clk_set_parent(clks[IMX6SLL_PLL5_BYPASS], clks[IMX6SLL_CLK_PLL5]);
> > + clk_set_parent(clks[IMX6SLL_PLL6_BYPASS], clks[IMX6SLL_CLK_PLL6]);
> > + clk_set_parent(clks[IMX6SLL_PLL7_BYPASS], clks[IMX6SLL_CLK_PLL7]);
>
> Can we just put raw register writes here instead? I'd prefer we didn't use clk
> consumer APIs to do things to the clk tree from the providers. The problem
> there being that:
>
> 1) We're trying to move away from using consumer APIs in provider drivers.
> It's ok if they're used during probe, but inside clk_ops is not preferred.
>
> 2) Even if you have a clk pointer, it may be "orphaned" at the time of
> registration and so calling the APIs here works now but eventually we may
> want to return an EPROBE_DEFER error in that case and this may block that
> effort.
>
> I suppose if this is the only clk driver on this machine then this last point isn't a
> concern and things are probably ok here.
>
Using raw register writing has an issue. The register is modified, but it seems the clock 'parent-child' relationship can
not match the register setting. The register setting is not bypass the pll, but in debug 'clk_summary', the
pll is bypassed.
BR
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
^ permalink raw reply
* [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
From: Jacky Bai @ 2016-12-12 2:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209181201.ewcqeqslyf3je7kq@rob-hp-laptop>
> Subject: Re: [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
>
> On Fri, Dec 02, 2016 at 02:39:33PM +0800, Bai Ping wrote:
> > Add necessary document update for i.MX6SLL support.
> >
> > Signed-off-by: Bai Ping <ping.bai@nxp.com>
> > ---
> > .../devicetree/bindings/clock/imx6sll-clock.txt | 13 ++++++++
> > .../bindings/pinctrl/fsl,imx6sll-pinctrl.txt | 37 ++++++++++++++++++++++
> > 2 files changed, 50 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > create mode 100644
> > Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> >
> > diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > new file mode 100644
> > index 0000000..4f52efa
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> > @@ -0,0 +1,13 @@
> > +* Clock bindings for Freescale i.MX6 UltraLite
>
> I thought UltraLite was MX6UL?
>
Sorry, it is a typo, will fix in V2.
> > +
> > +Required properties:
> > +- compatible: Should be "fsl,imx6sll-ccm"
> > +- reg: Address and length of the register set
> > +- #clock-cells: Should be <1>
> > +- clocks: list of clock specifiers, must contain an entry for each
> > +required
> > + entry in clock-names
> > +- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
> > +
> > +The clock consumer should specify the desired clock by having the
> > +clock ID in its "clocks" phandle cell. See
> > +include/dt-bindings/clock/imx6sll-clock.h
> > +for the full list of i.MX6 SLL clock IDs.
> > diff --git
> > a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> > b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
> > new file mode 100644
> > index 0000000..096e471
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.tx
> > +++ t
> > @@ -0,0 +1,37 @@
> > +* Freescale i.MX6 UltraLite IOMUX Controller
>
> ditto
>
Will fix in V2. Thanks for review.
> > +
> > +Please refer to fsl,imx-pinctrl.txt in this directory for common
> > +binding part and usage.
> > +
> > +Required properties:
> > +- compatible: "fsl,imx6sll-iomuxc"
> > +- fsl,pins: each entry consists of 6 integers and represents the mux
> > +and config
> > + setting for one pin. The first 5 integers <mux_reg conf_reg
> > +input_reg mux_val
> > + input_val> are specified using a PIN_FUNC_ID macro, which can be
> > +found in
> > + imx6ul-pinfunc.h under device tree source folder. The last integer
> > +CONFIG is
> > + the pad setting value like pull-up on this pin. Please refer to
> > +i.MX6SLL
> > + Reference Manual for detailed CONFIG settings.
> > +
> > +CONFIG bits definition:
> > +PAD_CTL_LVE (1 << 22)
> > +PAD_CTL_HYS (1 << 16)
> > +PAD_CTL_PUS_100K_DOWN (0 << 14)
> > +PAD_CTL_PUS_47K_UP (1 << 14)
> > +PAD_CTL_PUS_100K_UP (2 << 14)
> > +PAD_CTL_PUS_22K_UP (3 << 14)
> > +PAD_CTL_PUE (1 << 13)
> > +PAD_CTL_PKE (1 << 12)
> > +PAD_CTL_ODE (1 << 11)
> > +PAD_CTL_SPEED_LOW (0 << 6)
> > +PAD_CTL_SPEED_MED (1 << 6)
> > +PAD_CTL_SPEED_HIGH (3 << 6)
> > +PAD_CTL_DSE_DISABLE (0 << 3)
> > +PAD_CTL_DSE_260ohm (1 << 3)
> > +PAD_CTL_DSE_130ohm (2 << 3)
> > +PAD_CTL_DSE_87ohm (3 << 3)
> > +PAD_CTL_DSE_65ohm (4 << 3)
> > +PAD_CTL_DSE_52ohm (5 << 3)
> > +PAD_CTL_DSE_43ohm (6 << 3)
> > +PAD_CTL_DSE_37ohm (7 << 3)
> > +PAD_CTL_SRE_FAST (1 << 0)
> > +PAD_CTL_SRE_SLOW (0 << 0)
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: mm: Fix NOMAP page initialization
From: Yisheng Xie @ 2016-12-12 3:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481307042-29773-1-git-send-email-rrichter@cavium.com>
hi Robert,
On 2016/12/10 2:10, Robert Richter wrote:
> On ThunderX systems with certain memory configurations we see the
> following BUG_ON():
>
> kernel BUG at mm/page_alloc.c:1848!
>
> This happens for some configs with 64k page size enabled. The BUG_ON()
> checks if start and end page of a memmap range belongs to the same
> zone.
>
> The BUG_ON() check fails if a memory zone contains NOMAP regions. In
> this case the node information of those pages is not initialized. This
> causes an inconsistency of the page links with wrong zone and node
> information for that pages. NOMAP pages from node 1 still point to the
> mem zone from node 0 and have the wrong nid assigned.
>
The patch can work for zone contains NOMAP regions.
However, if BIOS do not add WB/WT/WC attribute to a physical address range, the
is_memory(md) will return false and this range will not be added to memblock.
efi_init
-> reserve_regions
if (is_memory(md)) {
early_init_dt_add_memory_arch(paddr, size);
if (!is_usable_memory(md))
memblock_mark_nomap(paddr, size);
}
Then BUG_ON() check will also fails. Any idea about it?
Here is the crash log I got from D05:
crash log---------------
[ 0.000000] Booting Linux on physical CPU 0x10000
[ 0.000000] Linux version 4.9.0-rc8+ (xys at linux-ibm) (gcc version 6.1.1 20160711 (Linaro GCC 6.1-2016.08) ) #61 SMP Fri Dec 9 19:46:24 CST 2016
[ 0.000000] Boot CPU: AArch64 Processor [410fd082]
[ 0.000000] earlycon: pl11 at MMIO32 0x00000000602b0000 (options '')
[ 0.000000] bootconsole [pl11] enabled
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: System Table: 0x000000003f150018
[ 0.000000] efi: MemMap Address: 0x0000000031b33018
[ 0.000000] efi: MemMap Size: 0x000009f0
[ 0.000000] efi: MemMap Desc. Size: 0x00000030
[ 0.000000] efi: MemMap Desc. Version: 0x00000001
[ 0.000000] efi: EFI v2.60 by EDK II
[ 0.000000] efi: SMBIOS=0x3f130000 SMBIOS 3.0=0x39ca0000 ACPI=0x39d70000 ACPI 2.0=0x39d70014 MEMATTR=0x3ce14018
[ 0.000000] efi: Processing EFI memory map:
[ 0.000000] MEMBLOCK configuration:
[ 0.000000] memory size = 0x0 reserved size = 0x1000
[ 0.000000] memory.cnt = 0x1
[ 0.000000] memory[0x0] [0x00000000000000-0xffffffffffffffff], 0x0 bytes on node 0 flags: 0x0
[ 0.000000] reserved.cnt = 0x1
[ 0.000000] reserved[0x0] [0x0000001e400000-0x0000001e400fff], 0x1000 bytes flags: 0x0
[ 0.000000] efi: 0x000000000000-0x00000007ffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000000000000-0x0000000007ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000000080000-0x0000016cffff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000000080000-0x000000016cffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x0000016d0000-0x00001e3fffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x000000016d0000-0x0000001e3fffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00001e400000-0x00001e40ffff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000001e400000-0x0000001e40ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00001e410000-0x00001e47ffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000001e410000-0x0000001e47ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00001e480000-0x00001fffffff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000001e480000-0x0000001fffffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000020000000-0x00002fbfffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000020000000-0x0000002fbfffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00002fc00000-0x00002fc1ffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000002fc00000-0x0000002fc1ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00002fc20000-0x00003049cfff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000002fc20000-0x0000003049ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003049d000-0x000031b0ffff [Loader Code | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000030490000-0x00000031b0ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000031b10000-0x000031b2ffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000031b10000-0x00000031b2ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000031b30000-0x000031b32fff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000031b30000-0x00000031b3ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000031b33000-0x000031b33fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000031b30000-0x00000031b3ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000031b34000-0x000031b37fff [Reserved | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000031b30000-0x00000031b3ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000031b38000-0x000031baefff [Boot Code | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000031b30000-0x00000031baffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000031baf000-0x000039baffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000031ba0000-0x00000039baffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039bb0000-0x000039beffff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039bb0000-0x00000039beffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039bf0000-0x000039c3ffff [ACPI Reclaim Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039bf0000-0x00000039c3ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039c40000-0x000039c4ffff [ACPI Memory NVS | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039c40000-0x00000039c4ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039c50000-0x000039c8ffff [ACPI Reclaim Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039c50000-0x00000039c8ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039c90000-0x000039d0ffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039c90000-0x00000039d0ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039d10000-0x000039d5ffff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039d10000-0x00000039d5ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039d60000-0x000039d7ffff [ACPI Reclaim Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039d60000-0x00000039d7ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039d80000-0x000039dcffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039d80000-0x00000039dcffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039dd0000-0x000039e1ffff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039dd0000-0x00000039e1ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039e20000-0x000039e6ffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039e20000-0x00000039e6ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039e70000-0x000039f3ffff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039e70000-0x00000039f3ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039f40000-0x000039faffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039f40000-0x00000039faffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x000039fb0000-0x000039ffffff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00000039fb0000-0x00000039ffffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003a000000-0x00003a04ffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003a000000-0x0000003a04ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003a050000-0x00003a09ffff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003a050000-0x0000003a09ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003a0a0000-0x00003a0effff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003a0a0000-0x0000003a0effff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003a0f0000-0x00003a13ffff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003a0f0000-0x0000003a13ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003a140000-0x00003a140fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003a140000-0x0000003a14ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003a141000-0x00003a14bfff [Boot Code | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003a140000-0x0000003a14ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003a14c000-0x00003c31dfff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003a140000-0x0000003c31ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003c31e000-0x00003cdcdfff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003c310000-0x0000003cdcffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003cdce000-0x00003cdfdfff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003cdc0000-0x0000003cdfffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003cdfe000-0x00003ef7ffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003cdf0000-0x0000003ef7ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003ef80000-0x00003ef81fff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003ef80000-0x0000003ef8ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003ef82000-0x00003f10ffff [Boot Code | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003ef80000-0x0000003f10ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003f110000-0x00003f12ffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003f110000-0x0000003f12ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003f130000-0x00003f15ffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003f130000-0x0000003f15ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003f160000-0x00003f16ffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003f160000-0x0000003f16ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003f170000-0x00003fbfffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x0000003f170000-0x0000003fbfffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x00003fc00000-0x00003fffffff [Reserved | | | | | | | | | | | | ]
[ 0.000000] efi: 0x000078000000-0x00007800ffff [Memory Mapped I/O |RUN| | | | | | | | | | |UC]
[ 0.000000] efi: 0x0000a4000000-0x0000a4ffffff [Memory Mapped I/O |RUN| | | | | | | | | | |UC]
[ 0.000000] efi: 0x0000a6000000-0x0000a600ffff [Memory Mapped I/O |RUN| | | | | | | | | | |UC]
[ 0.000000] efi: 0x0000d00e0000-0x0000d00effff [Memory Mapped I/O |RUN| | | | | | | | | | |UC]
[ 0.000000] efi: 0x001040000000-0x0013fbffffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00001040000000-0x000013fbffffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x041000000000-0x0413fbfeffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x00041000000000-0x000413fbfeffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] efi: 0x0413fbff0000-0x0413fbffffff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] memblock_add: [0x000413fbff0000-0x000413fbffffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c
[ 0.000000] memblock_reserve: [0x0000003ce14018-0x0000003ce14657] flags 0x0 efi_memattr_init+0x8c/0xa8
[ 0.000000] memblock_reserve: [0x00000031b30000-0x00000031b3ffff] flags 0x0 efi_init+0xa8/0x148
[ 0.000000] memblock_add: [0x0000001e480000-0x0000001fffffff] flags 0x0 arm64_memblock_init+0x16c/0x248
[ 0.000000] memblock_reserve: [0x0000001e480000-0x0000001fffffff] flags 0x0 arm64_memblock_init+0x178/0x248
[ 0.000000] memblock_reserve: [0x00000000080000-0x000000016cffff] flags 0x0 arm64_memblock_init+0x1b0/0x248
[ 0.000000] memblock_reserve: [0x0000001e480000-0x0000001fffdc62] flags 0x0 arm64_memblock_init+0x1cc/0x248
[ 0.000000] cma: Failed to reserve 512 MiB
[ 0.000000] memblock_reserve: [0x000013fbff0000-0x000013fbffffff] flags 0x0 memblock_alloc_range_nid+0x30/0x48
[ 0.000000] memblock_reserve: [0x000013fbfe0000-0x000013fbfeffff] flags 0x0 memblock_alloc_range_nid+0x30/0x48
[ 0.000000] memblock_reserve: [0x000013fbfd0000-0x000013fbfdffff] flags 0x0 memblock_alloc_range_nid+0x30/0x48
[ 0.000000] memblock_reserve: [0x000013fbfc0000-0x000013fbfcffff] flags 0x0 memblock_alloc_range_nid+0x30/0x48
[ 0.000000] memblock_reserve: [0x000013fbfb0000-0x000013fbfbffff] flags 0x0 memblock_alloc_range_nid+0x30/0x48
[ 0.000000] memblock_free: [0x000013fbff0000-0x000013fbffffff] paging_init+0x65c/0x6ac
[ 0.000000] memblock_free: [0x000000016c0000-0x000000016cffff] paging_init+0x690/0x6ac
[...]
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000000000-0x00000000ffffffff]
[ 0.000000] Normal [mem 0x0000000100000000-0x00000013fbffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 1: [mem 0x0000000000000000-0x000000000001ffff]
[ 0.000000] node 1: [mem 0x0000000000030000-0x0000000031b0ffff]
[ 0.000000] node 1: [mem 0x0000000031b10000-0x0000000031b3ffff]
[ 0.000000] node 1: [mem 0x0000000031b40000-0x0000000039baffff]
[ 0.000000] node 1: [mem 0x0000000039bb0000-0x000000003a13ffff]
[ 0.000000] node 1: [mem 0x000000003a140000-0x000000003f12ffff]
[ 0.000000] node 1: [mem 0x000000003f130000-0x000000003f15ffff]
[ 0.000000] node 1: [mem 0x000000003f160000-0x000000003fbfffff]
[ 0.000000] node 1: [mem 0x0000001040000000-0x00000013fbffffff]
[ 0.000000] Could not find start_pfn for node 0
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000000000000]
[ 0.000000] Initmem setup node 1 [mem 0x0000000000000000-0x00000013fbffffff]
[ 0.000000] Could not find start_pfn for node 2
[ 0.000000] Initmem setup node 2 [mem 0x0000000000000000-0x0000000000000000]
[ 0.000000] Could not find start_pfn for node 3
[ 0.000000] Initmem setup node 3 [mem 0x0000000000000000-0x0000000000000000]
[ 0.000000] MEMBLOCK configuration:
[ 0.000000] memory size = 0x3fbc00000 reserved size = 0x42a7cc0
[ 0.000000] memory.cnt = 0x9
[ 0.000000] memory[0x0] [0x00000000000000-0x000000000257ff], 0x25800 bytes on node 1 flags: 0x4
[ 0.000000] memory[0x1] [0x00000000025800-0x00000031b0ffff], 0x31aea800 bytes on node 1 flags: 0x0
[ 0.000000] memory[0x2] [0x00000031b10000-0x00000031b3ffff], 0x30000 bytes on node 1 flags: 0x4
[ 0.000000] memory[0x3] [0x00000031b40000-0x00000039baffff], 0x8070000 bytes on node 1 flags: 0x0
[ 0.000000] memory[0x4] [0x00000039bb0000-0x0000003a13ffff], 0x590000 bytes on node 1 flags: 0x4
[ 0.000000] memory[0x5] [0x0000003a140000-0x0000003f12ffff], 0x4ff0000 bytes on node 1 flags: 0x0
[ 0.000000] memory[0x6] [0x0000003f130000-0x0000003f15ffff], 0x30000 bytes on node 1 flags: 0x4
[ 0.000000] memory[0x7] [0x0000003f160000-0x0000003fbfffff], 0xaa0000 bytes on node 1 flags: 0x0
[ 0.000000] memory[0x8] [0x00001040000000-0x000013fbffffff], 0x3bc000000 bytes on node 1 flags: 0x0
[ 0.000000] reserved.cnt = 0x8
[ 0.000000] reserved[0x0] [0x00000000080000-0x000000016bffff], 0x1640000 bytes flags: 0x0
[ 0.000000] reserved[0x1] [0x0000001e400000-0x0000001e400fff], 0x1000 bytes flags: 0x0
[ 0.000000] reserved[0x2] [0x0000001e480000-0x0000001fffffff], 0x1b80000 bytes flags: 0x0
[ 0.000000] reserved[0x3] [0x00000031b30000-0x00000031b3ffff], 0x10000 bytes flags: 0x0
[ 0.000000] reserved[0x4] [0x0000003ce14018-0x0000003ce14657], 0x640 bytes flags: 0x0
[ 0.000000] reserved[0x5] [0x000013fad20000-0x000013fbd2ffff], 0x1010000 bytes flags: 0x0
[ 0.000000] reserved[0x6] [0x000013fbf37380-0x000013fbfeffff], 0xb8c80 bytes flags: 0x0
[ 0.000000] reserved[0x7] [0x000013fbff2600-0x000013fbffffff], 0xda00 bytes flags: 0x0
[ 0.000000] memblock_reserve: [0x0000003fbfff80-0x0000003fbfffbf] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbfff00-0x0000003fbfff3f] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbffe80-0x0000003fbffebf] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbffe00-0x0000003fbffe3f] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbffd80-0x0000003fbffdbf] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbffd00-0x0000003fbffd3f] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbffc80-0x0000003fbffcbf] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbffc00-0x0000003fbffc3f] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[ 0.000000] memblock_reserve: [0x0000003fbffb80-0x0000003fbffbbf] flags 0x0 __alloc_memory_core_early+0x9c/0xe4
[...]
[ 5.081443] move_freepages: start_page info: zonenum = 0, nid = 1, pfn = 8192, valid = 1, phys = 0x20000000
[ 5.081443] move_freepages: end_page info: zonenum = 0, nid = 0, pfn = 16383, valid = 0, phys = 0x3fff0000
[ 5.091280] ------------[ cut here ]------------
[ 5.095971] kernel BUG at mm/page_alloc.c:1871! ----> is mm/page_alloc.c:1863! without add debug log.
[ 5.100576] Internal error: Oops - BUG: 0 [#1] SMP
[ 5.105446] Modules linked in:
[ 5.108552] CPU: 61 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc8+ #61
[ 5.115101] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 UEFI 16.08 RC1 12/08/2016
[ 5.124126] task: fffffe13f23d1700 task.stack: fffffe13f66a0000
[ 5.130157] PC is at move_freepages+0x280/0x288
[ 5.134764] LR is at move_freepages+0x23c/0x288
[ 5.139365] pc : [<fffffc00081e9698>] lr : [<fffffc00081e9654>] pstate: 200000c5
[ 5.146889] sp : fffffe13f66a38d0
[ 5.150253] x29: fffffe13f66a38f0 x28: fffffdff80000000
[ 5.155652] x27: 0000000000003fff x26: 0000000000002000
[ 5.161051] x25: 0000000000000000 x24: 0000000000000000
[ 5.166453] x23: 0000000000000001 x22: fffffc0008e12328
[ 5.171851] x21: fffffdff800fffc0 x20: fffffe13fbf62680
[ 5.177251] x19: fffffdff80080000 x18: 0000000000000010
[ 5.182652] x17: 0000000000000000 x16: 0000000000000000
[ 5.188053] x15: 0000000000000006 x14: 702c29302c312864
[ 5.193455] x13: 696c61762c293338 x12: 3336312c32393138
[ 5.198854] x11: 286e66702c29302c x10: 0000000000000559
[ 5.204258] x9 : 000000000000006e x8 : 302c303030303030
[ 5.209663] x7 : 3032783028737968 x6 : fffffe13fbff2680
[ 5.215068] x5 : 0000000000000001 x4 : fffffe13fbf62680
[ 5.220468] x3 : 0000000000000000 x2 : 0000000000000000
[ 5.225870] x1 : fffffe13fbff2680 x0 : fffffe13fbf62680
[...]
[ 5.793294] [<fffffc00081e9698>] move_freepages+0x280/0x288
[ 5.798964] [<fffffc00081e9748>] move_freepages_block+0xa8/0xb8
[ 5.804994] [<fffffc00081e9cc4>] __rmqueue+0x494/0x5f0
[ 5.810225] [<fffffc00081eb214>] get_page_from_freelist+0x5ec/0xb58
[ 5.816603] [<fffffc00081ebd54>] __alloc_pages_nodemask+0x144/0xd08
[ 5.822979] [<fffffc000824061c>] alloc_page_interleave+0x64/0xc0
[ 5.829092] [<fffffc0008240c28>] alloc_pages_current+0x108/0x168
[ 5.835207] [<fffffc0008c75410>] atomic_pool_init+0x78/0x1cc
[ 5.840970] [<fffffc0008c755a0>] arm64_dma_init+0x3c/0x44
[ 5.846471] [<fffffc0008082d94>] do_one_initcall+0x44/0x138
[ 5.852143] [<fffffc0008c70d54>] kernel_init_freeable+0x1ec/0x28c
[ 5.858351] [<fffffc00088a7af0>] kernel_init+0x18/0x110
[ 5.863665] [<fffffc0008082b30>] ret_from_fork+0x10/0x20
[ 5.869078] Code: 8b001c80 8b011cc1 eb00003f 54fff080 (d4210000)
[ 5.875318] ---[ end trace b723f6d3d3b4c326 ]---
[ 5.880038] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 5.880038]
[ 5.889340] SMP: stopping secondary CPUs
[ 5.893339] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
^ permalink raw reply
* [PATCH v8 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver
From: Ricky Liang @ 2016-12-12 4:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480475340-21893-3-git-send-email-rick.chang@mediatek.com>
Hi Rick,
On Wed, Nov 30, 2016 at 11:08 AM, Rick Chang <rick.chang@mediatek.com> wrote:
> Add v4l2 driver for Mediatek JPEG Decoder
>
> Signed-off-by: Rick Chang <rick.chang@mediatek.com>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
<snip...>
> +static bool mtk_jpeg_check_resolution_change(struct mtk_jpeg_ctx *ctx,
> + struct mtk_jpeg_dec_param *param)
> +{
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + struct mtk_jpeg_q_data *q_data;
> +
> + q_data = &ctx->out_q;
> + if (q_data->w != param->pic_w || q_data->h != param->pic_h) {
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "Picture size change\n");
> + return true;
> + }
> +
> + q_data = &ctx->cap_q;
> + if (q_data->fmt != mtk_jpeg_find_format(ctx, param->dst_fourcc,
> + MTK_JPEG_FMT_TYPE_CAPTURE)) {
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "format change\n");
> + return true;
> + }
> + return false;
<snip...>
> +static void mtk_jpeg_device_run(void *priv)
> +{
> + struct mtk_jpeg_ctx *ctx = priv;
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + struct vb2_buffer *src_buf, *dst_buf;
> + enum vb2_buffer_state buf_state = VB2_BUF_STATE_ERROR;
> + unsigned long flags;
> + struct mtk_jpeg_src_buf *jpeg_src_buf;
> + struct mtk_jpeg_bs bs;
> + struct mtk_jpeg_fb fb;
> + int i;
> +
> + src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> + dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> + jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(src_buf);
> +
> + if (jpeg_src_buf->flags & MTK_JPEG_BUF_FLAGS_LAST_FRAME) {
> + for (i = 0; i < dst_buf->num_planes; i++)
> + vb2_set_plane_payload(dst_buf, i, 0);
> + buf_state = VB2_BUF_STATE_DONE;
> + goto dec_end;
> + }
> +
> + if (mtk_jpeg_check_resolution_change(ctx, &jpeg_src_buf->dec_param)) {
> + mtk_jpeg_queue_src_chg_event(ctx);
> + ctx->state = MTK_JPEG_SOURCE_CHANGE;
> + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> + return;
> + }
This only detects source change if multiple OUPUT buffers are queued.
It does not catch the source change in the following scenario:
- OUPUT buffers for jpeg1 enqueued
- OUTPUT queue STREAMON
- userspace creates CAPTURE buffers
- CAPTURE buffers enqueued
- CAPTURE queue STREAMON
- decode
- OUTPUT queue STREAMOFF
- userspace recreates OUTPUT buffers for jpeg2
- OUTPUT buffers for jpeg2 enqueued
- OUTPUT queue STREAMON
In the above sequence if jpeg2's decoded size is larger than jpeg1 the
function fails to detect that the existing CAPTURE buffers are not big
enough to hold the decoded data.
A possible fix is to pass *dst_buf to
mtk_jpeg_check_resolution_change(), and check in the function that all
the dst_buf planes are large enough to hold the decoded data.
> +
> + mtk_jpeg_set_dec_src(ctx, src_buf, &bs);
> + if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, dst_buf, &fb))
> + goto dec_end;
> +
> + spin_lock_irqsave(&jpeg->hw_lock, flags);
> + mtk_jpeg_dec_reset(jpeg->dec_reg_base);
> + mtk_jpeg_dec_set_config(jpeg->dec_reg_base,
> + &jpeg_src_buf->dec_param, &bs, &fb);
> +
> + mtk_jpeg_dec_start(jpeg->dec_reg_base);
> + spin_unlock_irqrestore(&jpeg->hw_lock, flags);
> + return;
> +
> +dec_end:
> + v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf), buf_state);
> + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(dst_buf), buf_state);
> + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> +}
<snip...>
^ permalink raw reply
* [linux-sunxi] sunxi-ng clocks: leaving certain clocks alone?
From: Chen-Yu Tsai @ 2016-12-12 4:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d70f2809-102c-a3de-c77c-43af27bbcbbc@arm.com>
On Mon, Dec 12, 2016 at 7:54 AM, Andr? Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> I was observing that the new sunxi-ng clock code apparently explicitly
> turns off _all_ clocks that are not used or needed. I find this rather
> unfortunate, as I wanted to use the THS temperature sensor from ARM
> Trusted Firmware to implement emergency shutdown or DVFS throttling.
> That works until the clock framework finds the clock (as enumerated in
> ccu-sun50i-a64.c) and obviously explicitly clears bit 31 in the THS mod
> clock register and bit 8 in the respective clock gate register.
> Turning them manually back on via /dev/mem or removing the THS clock
> from the sunxi-ng driver fixes this for me.
>
> This was not happening with the old Allwinner clocks, since the kernel
> wouldn't even know about it if there was no driver and the clock wasn't
> mentioned in the DT.
>
> Now with sunxi-ng even though the THS clock is not actually referenced
> or used in the DT, the kernel turns it off. I would expect that upon
> entering the kernel all unneeded clocks are turned off anyway, so there
> is no need to mess with clocks that have no user, but are enumerated in
> the ccu driver.
I can't say that's absolutely true (wink).
>
> I wonder if this kills simplefb as well, for instance, since I believe
> that U-Boot needs to turn on certain clocks and relies on them staying up.
The simplefb bindings takes clocks and regulators expressly for the
purpose of keeping them enabled.
>
> So my questions:
> 1) Is this expected behaviour?
Yes.
> 2) If yes, should it really be?
> 3) If yes, shouldn't there be way to explicitly tell Linux to leave that
> clock alone, preferably via DT? Although the sunxi-ng clocks take
> control over the whole CCU unit, I wonder if it should really mess with
> clocks there are not referenced in the DT.
As it owns the whole CCU unit, why not? And how would it know if some
clock is referenced or not, unless going through the whole device tree?
Furthermore, nothing prevents another device driver from referencing
said clock and turning it off when it's not in use. Think THS driver
with runtime PM.
Are you also mapping the THS to secure only? Otherwise nothing would
prevent Linux from also claiming it.
>
> Maybe there is some way to reference those clocks via some dummy driver
> or DT node to avoid this behaviour? Is there any prior art in this respect?
If you want a clock to not be disabled by anyone, adding CLK_IS_CRITICAL
to its flags is the proper option. This is done in the clk driver though.
If you just don't want the clk subsystem to disable unused clks at boot
time, you can add "clk_ignore_unused" to the kernel boot parameters.
I think this is more of a hack and debugging tool though.
About dummy drivers, simplefb comes to mind again. But simplefb disables
them when it gets kicked out by the drm driver. Maybe there are other
examples.
Regards
ChenYu
> I think this issue will affect more future users (thinking of EFI RTC,
> EFI graphics, etc.), so I wanted to start a discussion on this.
>
> Any input welcome.
>
> Cheers,
> Andre.
>
> P.S. For reference my use case: ARM Trusted Firmware (ATF) enables the
> temperature sensor (THS) and programs a shutdown value. It programs the
> respective interrupt as secure and registers an IRQ handler in ATF to
> shutdown the system or take other appropriate matters to avoid
> overheating. Additionally the sensor is exported via the generic SCPI
> interface, so the existing scpi-hwmon driver picks it up and reports it
> to whoever is interested in Linux land via the normal interfaces.
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Vinod Koul @ 2016-12-12 5:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7900ae24-6803-a271-944c-8830f718fef0@free.fr>
On Fri, Dec 09, 2016 at 07:23:17PM +0100, Mason wrote:
> [ Dropping Mans to preserve his peace-of-mind ]
>
> On 09/12/2016 18:56, Vinod Koul wrote:
> > On Fri, Dec 09, 2016 at 06:34:15PM +0100, Mason wrote:
> >> On 09/12/2016 18:17, Vinod Koul wrote:
> >>
> >>> On Fri, Dec 09, 2016 at 11:25:57AM +0100, Sebastian Frias wrote:
> >>>>
> >>>> What concrete solution do you propose?
> >>>
> >>> I have already proposed two solutions.
> >>>
> >>> A) Request a channel only when you need it. Obviously we can't do virtual
> >>> channels with this (though we should still use virt-channels framework).
> >>> The sbox setup and teardown can be done as part of channel request and
> >>> freeup. PL08x already does this.
> >>>
> >>> Downside is that we can only have as many consumers at a time as channels.
> >>>
> >>> I have not heard any technical reason for not doing this apart from drivers
> >>> grab the channel at probe, which is incorrect and needs to be fixed
> >>> irrespective of the problem at hand.
> >>>
> >>> This is my preferred option.
> >>
> >> There is one important drawback with this solution. If a driver calls
> >> dma_request_chan() when no channels are currently available, it will
> >> get -EBUSY. If there were a flag in dma_request_chan to be put to
> >> sleep (with timeout) until a channel is available, then it would
> >> work. But busy waiting in the client driver is a waste of power.
> >
> > Right, but in that case the fallback would be PIO mode, and if that is
> > not availble (IIRC some f your devices don't) then reject the usage with
> > EAGAIN.
>
> Maybe I'm missing something, but I don't see how that would help.
> Take the NAND Flash controller driver, for instance. PIO is not
> an option, because the ECC engine is tied to DMA.
>
> And failing with -EAGAIN doesn't help the busy looping situation.
> The caller should be put on some kind of queue to wait for a
> "channel ready" event.
So if you go down this route then we have do a bit of engineering for this
solutions to solve the hardware issue.
Can you tell me the clients for this controller and channels available?
In this case possibly we can dedicate one for NAND and keep the ones with
PIO mode dynamic in nature.. But yes it is not an elegant one.
--
~Vinod
^ permalink raw reply
* [PATCH] trace: extend trace_clock to support arch_arm clock counter
From: Srinivas Ramana @ 2016-12-12 5:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206121346.GF2498@arm.com>
On 12/06/2016 05:43 PM, Will Deacon wrote:
> On Sun, Dec 04, 2016 at 02:06:23PM +0530, Srinivas Ramana wrote:
>> On 12/02/2016 04:38 PM, Will Deacon wrote:
>>> On Fri, Dec 02, 2016 at 01:44:55PM +0530, Srinivas Ramana wrote:
>>>> Extend the trace_clock to support the arch timer cycle
>>>> counter so that we can get the monotonic cycle count
>>>> in the traces. This will help in correlating the traces with the
>>>> timestamps/events in other subsystems in the soc which share
>>>> this common counter for driving their timers.
>>>
>>> I'm not sure I follow this reasoning. What's wrong with nanoseconds? In
>>> particular, the "perf" trace_clock hangs off sched_clock, which should
>>> be backed by the architected counter anyway. What does the cycle counter in
>>> isolation tell you, given that the frequency isn't architected?
>>>
>>> I think I'm missing something here.
>>>
>>
>> Having cycle counter would help in the cases where we want to correlate the
>> time with other subsystems which are outside cpu subsystem.
>
> Do you have an example of these subsystems? Can they be used to generate
> trace data with mainline?
Some of the subsystems i can list are Modem(on a mobilephone), GPU or
video subsystem, or a DSP among others.
>
>> local_clock or even the perf track_clock uses sched_clock which gets
>> suspended during system suspend. Yes, they are backed up by the
>> architected counter but they ignore the cycles spent in suspend.i
>
> Does mono_raw solve this (also hangs off the architected counter and is
> supported in the vdso)?
Doesn't seem like. Any of the existing clock sources are designed not
show the jump, when there is a suspend and resume. Even though they run
out of architected counter they just cane give exact correlation with
the counter. Furthermore, during the initial kernel boot, these just run
out of jiffies clock source. They also not account for the time spent in
boot loaders.
>
>> so, when comparing with monotonically increasing cycle counter, other
>> clocks doesn't help. It seems X86 uses the TSC counter to help such cases.
>
> Does this mean we need a way to expose the frequency to userspace, too?
Not really. The CNTFRQ_EL0 of timer subsystem holds the clock frequency
of system timer and is available to EL0.
>
> Will
>
Thanks,
-- Srinivas R
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative
Project.
^ permalink raw reply
* [PATCH 4/4] ARM: versatile: support configuring versatile machine for no-MMU
From: Greg Ungerer @ 2016-12-12 5:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209202901.GQ14217@n2100.armlinux.org.uk>
On 10/12/16 06:29, Russell King - ARM Linux wrote:
> On Wed, Dec 07, 2016 at 02:33:53PM +0000, Vladimir Murzin wrote:
>> Hi Linus,
>>
>> On 07/12/16 14:11, Linus Walleij wrote:
>>> Another target I had in mind was the Integrator which
>>> incidentally supports a bunch of the old noMMU core
>>> tiles where we can swap in an ARM946, which I guess
>>> could work with this?
>>
>> Do you mind trying my "Allow NOMMU for MULTIPLATFORM" series [1]? Greg just
>> reported it did a trick for Versatile, there is a good chance it would work
>> for Integrator too ;)
>
> My views on gluing multiplatform and nommu together have already been
> stated several times, and remain unchanged.
>
> Greg's patch looks almost sane, but what I'd like to see is instead of
> directly doing this:
>
> config ARCH_VERSATILE
> bool "ARM Ltd. Versatile family"
> - depends on ARCH_MULTI_V5
> + depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
>
> we could do:
>
> config ARCH_VERSATILE
> bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5
> - depends on ARCH_MULTI_V5
> + depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
> default y if ARM_SINGLE_ARCH_VERSATILE
>
> adding the versatile entry in the upper level choice (where it always used
> to be) but with "ARM_SINGLE_ARCH_VERSATILE" instead.
>
> This would have the effect of allowing the multiplatform-converted stuff
> to start being used on nommu (again) but without running into the problems
> I've highlighted.
Thanks for the feedback Russell. Let me re-spin this patch with
this in mind.
Regards
Greg
^ permalink raw reply
* [PATCHv2 4/4] ARM: versatile: support configuring versatile machine for, no-MMU
From: Greg Ungerer @ 2016-12-12 5:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209202901.GQ14217@n2100.armlinux.org.uk>
Allow the arm versatile machine to be configured for no-MMU operation.
Older kernels had the ability to build the versatile machine with the MMU
disabled (!CONFIG_MMU). Recent changes to convert the versatile machine
to device tree lost this ability. (Although older kernels could be built
they did not run due to a bug in the IO_ADDRESS() mapping on this machine).
The motivation for this is that the versatile machine is well supported
in qemu. And this provides an excellent platform for development and
testing no-MMU support on ARM in general.
This patch adds a versatile platform selection in the upper level arm
system type menu - where it appeared in older kernel versions - when
configuring for the no-MMU case. There is no visible change to the way
versatile is selected for the MMU enabled case.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/Kconfig | 11 +++++++++++
arch/arm/Kconfig.debug | 3 ++-
arch/arm/mach-versatile/Kconfig | 5 +++--
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529f..8960e7a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -353,6 +353,17 @@ config ARM_SINGLE_ARMV7M
select SPARSE_IRQ
select USE_OF
+config ARM_SINGLE_ARCH_VERSATILE
+ bool "ARM Ltd. Versatile family"
+ depends on !MMU
+ select AUTO_ZRELADDR
+ select CLKSRC_OF
+ select COMMON_CLK
+ select GENERIC_CLOCKEVENTS
+ select GPIOLIB
+ select SPARSE_IRQ
+ select USE_OF
+
config ARCH_GEMINI
bool "Cortina Systems Gemini"
select CLKSRC_MMIO
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index d83f7c3..3f393e4 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1712,7 +1712,8 @@ config DEBUG_UNCOMPRESS
config UNCOMPRESS_INCLUDE
string
default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
- PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
+ PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
+ ARM_SINGLE_ARCH_VERSATILE
default "mach/uncompress.h"
config EARLY_PRINTK
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
index c257d40..c03a8c8 100644
--- a/arch/arm/mach-versatile/Kconfig
+++ b/arch/arm/mach-versatile/Kconfig
@@ -1,6 +1,7 @@
config ARCH_VERSATILE
- bool "ARM Ltd. Versatile family"
- depends on ARCH_MULTI_V5
+ bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5
+ depends on ARCH_MULTI_V5 || ARM_SINGLE_ARCH_VERSATILE
+ default y if ARM_SINGLE_ARCH_VERSATILE
select ARM_AMBA
select ARM_TIMER_SP804
select ARM_VIC
--
1.9.1
^ permalink raw reply related
* [PATCH] mmc: sdhci-xenon: fix device_node_continue.cocci warnings
From: Ziji Hu @ 2016-12-12 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1612092006080.1960@hadrien>
Hi Julia,
On 2016/12/10 3:08, Julia Lawall wrote:
> Device node iterators put the previous value of the index variable, so an
> explicit put causes a double put.
>
> Generated by: scripts/coccinelle/iterators/device_node_continue.cocci
>
> CC: Hu Ziji <huziji@marvell.com>
> Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> ---
>
> Please check on this. I have only seen the code shown below, but the rule
> normally has a lot false positive rate.
>
Thank you.
It seems that the check is right. I will correct it.
Thank you.
Best regards,
Hu Ziji
> url:
> https://github.com/0day-ci/linux/commits/Gregory-CLEMENT/mmc-Add-support-to-Marvell-Xenon-SD-Host-Controller/20161210-002602
> base:
> :::::: branch date: 2 hours ago
> :::::: commit date: 2 hours ago
>
>
> Please take the patch only if it's a positive warning. Thanks!
>
> sdhci-xenon.c | 1 -
> 1 file changed, 1 deletion(-)
>
> --- a/drivers/mmc/host/sdhci-xenon.c
> +++ b/drivers/mmc/host/sdhci-xenon.c
> @@ -423,7 +423,6 @@ static int xenon_child_node_of_parse(str
> MMC_CAP2_NO_SD |
> MMC_CAP2_NO_SDIO;
> }
> - of_node_put(child);
> }
>
> return 0;
>
^ permalink raw reply
* [PATCH 2/2] kcov: make kcov work properly with KASLR enabled
From: Dmitry Vyukov @ 2016-12-12 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f3f9c3a3-349d-65ff-6c84-51878cfd8072@linux.com>
On Sun, Dec 11, 2016 at 10:37 PM, Alexander Popov <alex.popov@linux.com> wrote:
> On 11.12.2016 12:32, Dmitry Vyukov wrote:
>> On Sun, Dec 11, 2016 at 1:50 AM, Alexander Popov <alex.popov@linux.com> wrote:
>>> Subtract KASLR offset from the kernel addresses reported by kcov.
>>> Tested on x86_64 and AArch64 (Hikey LeMaker).
>>>
>>> Signed-off-by: Alexander Popov <alex.popov@linux.com>
>>> ---
>>> kernel/kcov.c | 8 +++++++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> I think generally this is the right thing to do.
>>
>> There are 2 pending patches for kcov by +Quentin (hopefully in mm):
>> "kcov: add AFL-style tracing"
>> "kcov: size of arena is now given in bytes"
>> https://groups.google.com/forum/#!topic/syzkaller/gcqbIhKjGcY
>> https://groups.google.com/d/msg/syzkaller/gcqbIhKjGcY/KQFryjBKCAAJ
>>
>> Your patch probably conflicts with them.
>> Should you base them on top of these patches, so that Andrew can merge
>> it without conflicts?
>
> Excuse me, I can't find these patches in:
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> git://git.cmpxchg.org/linux-mmots.git
>
> Could you point at the tree which I can rebase onto?
> Should I cherry-pick Quentin's patches manually?
Quentin, do you know destiny of your patches? They does not seem to be
in mm tree.
^ permalink raw reply
* [RFC v3 PATCH 00/25] Allow NOMMU for MULTIPLATFORM
From: mickael guene @ 2016-12-12 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fulus094.fsf@dell.be.48ers.dk>
Hi all,
You can find an R toolchain here:
https://github.com/mickael-guene/fdpic_manifest/releases/download/v7-r-1.0.1/toolset-v7-r-1.0.1-0-gbdcc6a7c-armv7-r.tgz
It's an fdpic toolset for cortex-r cpu class. gcc version is
quite old (4.7).
Note also that generated code may crash on class A cpu due to
generation of udiv/sdiv which is optional for class A.
(cortex a15 is ok but not a9).
Hope it helps
Regards
Mickael
On 12/11/2016 09:01 PM, Peter Korsgaard wrote:
>>>>>> "Afzal" == Afzal Mohammed <afzal.mohd.ma@gmail.com> writes:
>
> Hi,
>
> >> You can build a toolchain and initramfs with Buildroot. Have a look at
> >> the stm32f429 nommu config:
> >>
> >> https://git.buildroot.net/buildroot/tree/configs/stm32f429_disco_defconfig
>
> > iiuc, it builds one for Cortex-M. i already had a file system w/
> > busybox compiled using a Cortex-M toolchain (stolen from
> > Pengutronix's OSELAS.Toolchain), which works on Cortex M4 (Vybrid
> > VF610 M4 core). But it does not work here, i.e. on Cortex A, seems the
> > above mentioned also would have the same effect.
>
> Hmm, I'm not sure why a cortex-M toolchain wouldn't work on cortex-A, I
> thought the 'M' instruction set was a pure subset of the 'A'.
>
> > And in buildroot, couldn't see Cortex R option in menuconfig, and
> > selecting Cortex-A's excludes flat binary target & presents only with
> > ELF.
>
> We indeed don't have cortex-R support. I'm not aware of any cortex-R
> Linux support.
>
> When you select a cortex-A variant, then we enable MMU support by
> default, but you can disable it under toolchain options (Enable MMU) and
> then the flat binary option is available.
>
^ 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