* [PATCH] i2c: i2c-cadence: Don't register the adapter until it's ready
From: Vladimir Zapolskiy @ 2017-01-06 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483613240-32501-1-git-send-email-mike.looijmans@topic.nl>
Hello Mike,
On 01/05/2017 12:47 PM, Mike Looijmans wrote:
> The driver calls i2c_add_adapter before writing to config registers,
> resulting in dmesg output like this, where devices fail to initialize:
>
> cdns-i2c ff030000.i2c: timeout waiting on completion
> pca953x 1-0041: failed reading register
> pca953x: probe of 1-0041 failed with error -110
> at24 1-0050: 512 byte 24c04 EEPROM, writable, 1 bytes/write
> cdns-i2c ff030000.i2c: 100 kHz mmio ff030000 irq 197
>
> The adapter is being used before it completed the "probe". To fix
> this, make "i2c_add_adapter" the last thing it calls in probe.
> It also makes sense to show the adapter initialization before
> the devices on the bus.
commonly "it also" in a commit message means a change, which should be done
separately, and this is the case here as well.
Because the adapter registration i2c_add_adapter() can fail, information
about the adapter initialization would be expected only in case of
successful registration.
The information sent to the kernel log buffer here is quite trivial,
probably dev_info() can be just removed, but in any case it should be
a separate change.
> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node
From: Chanwoo Choi @ 2017-01-06 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106134350.32428-6-andi.shyti@samsung.com>
Hi,
2017-01-06 22:43 GMT+09:00 Andi Shyti <andi.shyti@samsung.com>:
> From: Jaechul Lee <jcsing.lee@samsung.com>
>
> Add DT node support for TM2 touchkey device.
>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index 2449266b268f..92fcc4ec8319 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -18,6 +18,19 @@
> compatible = "samsung,tm2", "samsung,exynos5433";
> };
>
> +&hsi2c_9 {
> + status = "okay";
> +
> + touchkey at 20 {
> + compatible = "samsung,tm2-touchkey";
> + reg = <0x20>;
> + interrupt-parent = <&gpa3>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> + vcc-supply = <&ldo32_reg>;
> + vdd-supply = <&ldo33_reg>;
> + };
> +};
> +
> &ldo31_reg {
> regulator-name = "TSP_VDD_1.85V_AP";
> regulator-min-microvolt = <1850000>;
Looks good to me.
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* [PATCH v5 2/5] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Chanwoo Choi @ 2017-01-06 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106134350.32428-3-andi.shyti@samsung.com>
Hi Andi,
2017-01-06 22:43 GMT+09:00 Andi Shyti <andi.shyti@samsung.com>:
> Currently tm2e dts includes tm2 but there are some differences
> between the two boards and tm2 has some properties that tm2e
> doesn't have.
>
> That's why it's important to keep the two dts files independent
> and put all the commonalities in a tm2-common.dtsi file.
>
> At the current status the only two differences between the two
> dts files (besides the board name) are ldo31 and ldo38.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
> ...ynos5433-tm2.dts => exynos5433-tm2-common.dtsi} | 21 +-
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1150 +-------------------
> arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 2 +-
> 3 files changed, 42 insertions(+), 1131 deletions(-)
> copy arch/arm64/boot/dts/exynos/{exynos5433-tm2.dts => exynos5433-tm2-common.dtsi} (98%)
> rewrite arch/arm64/boot/dts/exynos/exynos5433-tm2.dts (98%)
Looks good to me.
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
[snip]
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* imx: RS-485 problems during TX, maybe DMA related
From: Fabio Estevam @ 2017-01-06 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104160024.GA13442@archie.localdomain>
Hi Clemens,
On Wed, Jan 4, 2017 at 2:00 PM, Clemens Gruber
<clemens.gruber@pqgruber.com> wrote:
> Hi,
>
> I observed odd behavior of the current tty/serial/imx.c driver in RS-485
> mode.
>
> RX works fine, but TX does not: When sending data, it arrives multiple
I am also trying to get rs485 in half-duplex mode to work on mx6dl
with kernel 4.9.
RX also works for me, but TX does not.
On my board it is the MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B pin that
controls the rs485 transceiver flow, but I do not
see RTS to toggle to 1 during transmit. It stays always at 0.
I see you use CTS pin instead, but I thought RTS pin should be used.
On my userspace application I have:
/* enable RS485 mode: */
rs485conf.flags |= SER_RS485_ENABLED;
/* set logical level for RTS pin equal to 1 when sending: */
rs485conf.flags |= SER_RS485_RTS_ON_SEND;
/* set logical level for RTS pin equal to 0 after sending: */
rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);
Any ideas as to how to make RTS go to one so that the data can go
through the rs485 transceiver?
Thanks
^ permalink raw reply
* [PATCH] net: phy: dp83867: fix irq generation
From: David Miller @ 2017-01-06 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105204807.25990-1-grygorii.strashko@ti.com>
From: Grygorii Strashko <grygorii.strashko@ti.com>
Date: Thu, 5 Jan 2017 14:48:07 -0600
> For proper IRQ generation by DP83867 phy the INT/PWDN pin has to be
> programmed as an interrupt output instead of a Powerdown input in
> Configuration Register 3 (CFG3), Address 0x001E, bit 7 INT_OE = 1. The
> current driver doesn't do this and as result IRQs will not be generated by
> DP83867 phy even if they are properly configured in DT.
>
> Hence, fix IRQ generation by properly configuring CFG3.INT_OE bit and
> ensure that Link Status Change (LINK_STATUS_CHNG_INT) and Auto-Negotiation
> Complete (AUTONEG_COMP_INT) interrupt are enabled. After this the DP83867
> driver will work properly in interrupt enabled mode.
>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Applied.
^ permalink raw reply
* [PATCH v2 4/7] x86: put msr-index.h in uapi
From: Andy Shevchenko @ 2017-01-06 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483695839-18660-5-git-send-email-nicolas.dichtel@6wind.com>
On Fri, Jan 6, 2017 at 11:43 AM, Nicolas Dichtel
<nicolas.dichtel@6wind.com> wrote:
> This header file is exported, thus move it to uapi.
Just hint for the future:
-M (move)
-C (copy)
-D (delete) [though this is NOT for applying]
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] ARM: socfpga_defconfig: update defconfig for SoCFPGA
From: Dinh Nguyen @ 2017-01-06 20:50 UTC (permalink / raw)
To: linux-arm-kernel
MARVELL_PHY - support for the Marvell PHY that is on most of the devkits
EEPROM_AT24 - support for I2C EEPROMs on the devkits
GPIO_ALTERA - support for Altera's GPIO driver
NAND - support for the Denali NAND controller along with MTD subsystem
SPI_DESIGNWARE - support for SPI that is on SoCFPGA
SPI_DW_MMIO - support for the memory-mapped io interface for the DW SPI core
OF_CONFIGFS - SoCFPGA makes use of DT overlays using configfs, enable it
GPIO_ALTERA_A10SR - support for the newly added Altera HWMON driver
LEDS - support for the GPIO LEDs on the SoCFPGA devkits
RTC - support for the DS1307 RTC
JFFS2_FS - support for the JFFS2 filesystem
NFS_V4 - supports for v4 NFS
FUNCTION_TRACER - supports debug function tracing
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
arch/arm/configs/socfpga_defconfig | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig
index 2e1d254..030264c 100644
--- a/arch/arm/configs/socfpga_defconfig
+++ b/arch/arm/configs/socfpga_defconfig
@@ -52,14 +52,20 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_M25P80=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_DENALI_DT=y
CONFIG_MTD_SPI_NOR=y
CONFIG_SPI_CADENCE_QUADSPI=y
CONFIG_OF_OVERLAY=y
+CONFIG_OF_CONFIGFS=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=2
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_NVME=m
CONFIG_SRAM=y
+CONFIG_EEPROM_AT24=y
CONFIG_SCSI=y
# CONFIG_SCSI_PROC_FS is not set
CONFIG_BLK_DEV_SD=y
@@ -69,6 +75,7 @@ CONFIG_E1000E=m
CONFIG_IGB=m
CONFIG_IXGBE=m
CONFIG_STMMAC_ETH=y
+CONFIG_MARVELL_PHY=y
CONFIG_MICREL_PHY=y
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_TOUCHSCREEN=y
@@ -84,14 +91,22 @@ CONFIG_SERIAL_8250_DW=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
+CONFIG_SPI=y
+CONFIG_SPI_DESIGNWARE=y
+CONFIG_SPI_DW_MMIO=y
+CONFIG_SPI_SPIDEV=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
+CONFIG_GPIO_ALTERA=y
CONFIG_GPIO_DWAPB=y
+CONFIG_GPIO_ALTERA_A10SR=y
+CONFIG_SENSORS_MAX1619=y
CONFIG_PMBUS=y
CONFIG_SENSORS_LTC2978=y
CONFIG_SENSORS_LTC2978_REGULATOR=y
CONFIG_WATCHDOG=y
CONFIG_DW_WATCHDOG=y
+CONFIG_MFD_ALTERA_A10SR=y
CONFIG_MFD_STMPE=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
@@ -102,6 +117,14 @@ CONFIG_NOP_USB_XCEIV=y
CONFIG_USB_GADGET=y
CONFIG_MMC=y
CONFIG_MMC_DW=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_CPU=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_DS1307=y
CONFIG_DMADEVICES=y
CONFIG_PL330_DMA=y
CONFIG_DMATEST=m
@@ -121,9 +144,10 @@ CONFIG_VFAT_FS=y
CONFIG_NTFS_FS=y
CONFIG_NTFS_RW=y
CONFIG_TMPFS=y
-CONFIG_CONFIGFS_FS=y
+CONFIG_JFFS2_FS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
CONFIG_ROOT_NFS=y
CONFIG_NFSD=y
CONFIG_NFSD_V3_ACL=y
@@ -135,5 +159,5 @@ CONFIG_DEBUG_INFO=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DETECT_HUNG_TASK=y
# CONFIG_SCHED_DEBUG is not set
-CONFIG_ENABLE_DEFAULT_TRACERS=y
+CONFIG_FUNCTION_TRACER=y
CONFIG_DEBUG_USER=y
--
2.7.4
^ permalink raw reply related
* [PATCH] clk: rockchip: Remove useless init of "grf" to -EPROBE_DEFER
From: Heiko Stuebner @ 2017-01-06 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106163101.32048-1-dianders@chromium.org>
Am Freitag, 6. Januar 2017, 08:31:01 CET schrieb Douglas Anderson:
> When we used to defer setting the "grf" member to
> rockchip_clk_get_grf() it was important to init the "grf" member to an
> error value in rockchip_clk_init(). With recent changes, we now set
> "grf" right in rockchip_clk_init() (two lines below the place where we
> initted it). That makes the old init useless. Get rid of it.
>
> Fixes: 6f339dc2719e ("clk: rockchip: lookup General Register Files in
> rockchip_clk_init") Signed-off-by: Douglas Anderson <dianders@chromium.org>
thanks for the catch, applied for 4.11
Thanks
Heiko
^ permalink raw reply
* [PATCH 0/5] Use mmio-sram driver for Keystone MSMC RAM
From: Santosh Shilimkar @ 2017-01-06 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b49bfb08-292f-ee26-b385-fdba304571b0@ti.com>
On 1/6/2017 11:10 AM, Suman Anna wrote:
> Hi Santosh,
>
>>> OK. Its good to add the code at least with one active user of it.
>>> Since this has to anyway wait for another merge window, please post the
>>> users of it so that I can pull the combined patchset.
>>>
>> Are you going to post new patchset or you dropped this series ?
>>
>> If you want me to include it for next merge window, please post
>> refreshed patchset.
>
> No, haven't dropped the series, will post it today. You prefer the
> series on -rc1 or -rc2, not that it makes a difference.
>
Right. rc1 is just fine.
Regards,
Sasntosh
^ permalink raw reply
* [PATCH 0/5] Use mmio-sram driver for Keystone MSMC RAM
From: Suman Anna @ 2017-01-06 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3abc3c7d-2f45-f5dd-e6f5-c03008d22d56@oracle.com>
Hi Santosh,
>
> On 9/7/16 9:25 AM, Santosh Shilimkar wrote:
>> On 9/7/2016 9:22 AM, Suman Anna wrote:
>>> Hi Santosh,
>>>
>>> On 09/07/2016 11:11 AM, Santosh Shilimkar wrote:
>>>> Hi Suman,
>>>>
>>>> On 9/1/2016 3:58 PM, Suman Anna wrote:
>>>>> Hi,
>>>>>
>>>>> The Keystone 2 family of SoCs have an on-chip RAM called the
>>>>> Multicore Shared Memory (MSM) RAM. This RAM is accessible through
>>>>> the Multicore Shared Memory Controller (MSMC). This series represents
>>>>> these on-chip RAMs as sram nodes so that the memory allocations
>>>>> can be managed by the in-kernel mmio-sram driver.
>>>>>
>>>>> The first 4 patches adds the basic SRAM nodes on each of the SoCs,
>>>>> and the last patch enables the generic on-chip SRAM driver for
>>>>> keystone defconfig.
>>>>>
>>>> The series looks good in general but I would like to understand
>>>> the users of this memory in kernel. Is that going to be posted
>>>> as a follow up patch ? Is the Power controller going to make
>>>> use of this SRAM for PM code ?
>>>
>>> Yes, the users will eventually follow. Power Controller code is not
>>> gonna be using this SRAM, it has its own RAM. This memory is gonna be
>>> split between various functional features like IPC, OPTEE integration,
>>> we already have the Boot Monitor code using this. We will have the
>>> memory split by either having static child nodes or drivers requesting
>>> the memory using gen_pool API.
>>>
>> OK. Its good to add the code at least with one active user of it.
>> Since this has to anyway wait for another merge window, please post the
>> users of it so that I can pull the combined patchset.
>>
> Are you going to post new patchset or you dropped this series ?
>
> If you want me to include it for next merge window, please post
> refreshed patchset.
No, haven't dropped the series, will post it today. You prefer the
series on -rc1 or -rc2, not that it makes a difference.
regards
Suman
^ permalink raw reply
* [PATCH v2 15/19] media: imx: Add MIPI CSI-2 Receiver subdev driver
From: Steve Longerbeam @ 2017-01-06 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ecfcd8e5-01bd-b9a4-8653-7bbbdece4231@mentor.com>
On 01/04/2017 07:05 AM, Vladimir Zapolskiy wrote:
> On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
>> Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
>> for sensors with a MIPI CSI2 interface.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>> ---
>> drivers/staging/media/imx/Makefile | 1 +
>> drivers/staging/media/imx/imx-mipi-csi2.c | 509 ++++++++++++++++++++++++++++++
>> 2 files changed, 510 insertions(+)
>> create mode 100644 drivers/staging/media/imx/imx-mipi-csi2.c
>>
>> diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile
>> index fe9e992..0decef7 100644
>> --- a/drivers/staging/media/imx/Makefile
>> +++ b/drivers/staging/media/imx/Makefile
>> @@ -9,3 +9,4 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-ic.o
>> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o
>> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-smfc.o
>> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-camif.o
>> +obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-mipi-csi2.o
>> diff --git a/drivers/staging/media/imx/imx-mipi-csi2.c b/drivers/staging/media/imx/imx-mipi-csi2.c
>> new file mode 100644
>> index 0000000..84df16e
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-mipi-csi2.c
>> @@ -0,0 +1,509 @@
>> +/*
>> + * MIPI CSI-2 Receiver Subdev for Freescale i.MX5/6 SOC.
>> + *
>> + * Copyright (c) 2012-2014 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/export.h>
>> +#include <linux/types.h>
>> +#include <linux/init.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/err.h>
>> +#include <linux/delay.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/clk.h>
>> +#include <linux/list.h>
>> +#include <linux/irq.h>
>> +#include <linux/of_device.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-async.h>
> Please sort the list of headers alphabetically.
done.
>
>> +#include <asm/mach/irq.h>
> Why do you need to include this header?
good question. In fact this include list was in need of a lot of pruning,
so I paired it down to the essentials.
>> +static int imxcsi2_s_stream(struct v4l2_subdev *sd, int enable)
>> +{
>> + struct imxcsi2_dev *csi2 = sd_to_dev(sd);
>> + int i, ret = 0;
>> +
>> + if (!csi2->src_sd)
>> + return -EPIPE;
>> + for (i = 0; i < CSI2_NUM_SRC_PADS; i++) {
>> + if (csi2->sink_sd[i])
>> + break;
>> + }
>> + if (i >= CSI2_NUM_SRC_PADS)
>> + return -EPIPE;
>> +
>> + v4l2_info(sd, "stream %s\n", enable ? "ON" : "OFF");
>> +
>> + if (enable && !csi2->stream_on) {
>> + clk_prepare_enable(csi2->pix_clk);
> It can complicate the design for you, but in general clk_prepare_enable()
> can return an error.
I added an error check and reorganized a little.
>> +
>> +static int imxcsi2_parse_endpoints(struct imxcsi2_dev *csi2)
>> +{
>> + struct device_node *node = csi2->dev->of_node;
>> + struct device_node *epnode;
>> + struct v4l2_of_endpoint ep;
>> + int ret = 0;
>> +
>> + epnode = of_graph_get_next_endpoint(node, NULL);
>> + if (!epnode) {
>> + v4l2_err(&csi2->sd, "failed to get endpoint node\n");
>> + return -EINVAL;
>> + }
>> +
>> + v4l2_of_parse_endpoint(epnode, &ep);
> Do of_node_put(epnode) here and remove 'out' goto label.
done.
>> +static const struct of_device_id imxcsi2_dt_ids[] = {
>> + { .compatible = "fsl,imx-mipi-csi2", },
>> + { /* sentinel */ }
>> +};
>> +MODULE_DEVICE_TABLE(of, imxcsi2_dt_ids);
>> +
>> +static struct platform_driver imxcsi2_driver = {
>> + .driver = {
>> + .name = DEVICE_NAME,
>> + .owner = THIS_MODULE,
> Please drop .owner assignment.
done.
Steve
^ permalink raw reply
* [PATCH 0/5] Use mmio-sram driver for Keystone MSMC RAM
From: santosh.shilimkar at oracle.com @ 2017-01-06 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <287b7e1d-1453-2832-515d-e7e51373a3bc@oracle.com>
Hi Suman,
On 9/7/16 9:25 AM, Santosh Shilimkar wrote:
> On 9/7/2016 9:22 AM, Suman Anna wrote:
>> Hi Santosh,
>>
>> On 09/07/2016 11:11 AM, Santosh Shilimkar wrote:
>>> Hi Suman,
>>>
>>> On 9/1/2016 3:58 PM, Suman Anna wrote:
>>>> Hi,
>>>>
>>>> The Keystone 2 family of SoCs have an on-chip RAM called the
>>>> Multicore Shared Memory (MSM) RAM. This RAM is accessible through
>>>> the Multicore Shared Memory Controller (MSMC). This series represents
>>>> these on-chip RAMs as sram nodes so that the memory allocations
>>>> can be managed by the in-kernel mmio-sram driver.
>>>>
>>>> The first 4 patches adds the basic SRAM nodes on each of the SoCs,
>>>> and the last patch enables the generic on-chip SRAM driver for
>>>> keystone defconfig.
>>>>
>>> The series looks good in general but I would like to understand
>>> the users of this memory in kernel. Is that going to be posted
>>> as a follow up patch ? Is the Power controller going to make
>>> use of this SRAM for PM code ?
>>
>> Yes, the users will eventually follow. Power Controller code is not
>> gonna be using this SRAM, it has its own RAM. This memory is gonna be
>> split between various functional features like IPC, OPTEE integration,
>> we already have the Boot Monitor code using this. We will have the
>> memory split by either having static child nodes or drivers requesting
>> the memory using gen_pool API.
>>
> OK. Its good to add the code at least with one active user of it.
> Since this has to anyway wait for another merge window, please post the
> users of it so that I can pull the combined patchset.
>
Are you going to post new patchset or you dropped this series ?
If you want me to include it for next merge window, please post
refreshed patchset.
Regards,
Santosh
^ permalink raw reply
* [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Tony Lindgren @ 2017-01-06 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106182052.GA127120@google.com>
* Brian Norris <briannorris@chromium.org> [170106 10:21]:
> On Fri, Jan 06, 2017 at 08:14:22AM -0800, Tony Lindgren wrote:
> > * Adam Ford <aford173@gmail.com> [170106 08:06]:
> > > On Fri, Jan 6, 2017 at 10:02 AM, Tony Lindgren <tony@atomide.com> wrote:
> > > > * Teresa Remmet <t.remmet@phytec.de> [170106 01:28]:
> > > >> Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:
> > > >> > On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
> > > >> > > I'm suggesting we leave the kernel nodes empty and let u-boot
> > > >> > > populate them, so maybe you guys can discuss this on the related
> > > >> > > lists.
> > > >> > That's an option. I've worked with platforms that did something like
> > > >> > this, and that's really one of the only ways you can handle putting
> > > >> > partition information in the device tree. You're really hamstringing
> > > >> > yourself when you put all the partition information in the device
> > > >> > tree.
> > > >> > And it's just dumb once that gets codified in the kernel source tree.
> > > >> >
> > > >>
> > > >> In our case the bootloader does pass the partition table to the kernel.
> > > >> So it gets overwritten anyway. This was just more for backup,
> > > >> if someone uses a different bootloader. But I'm fine with removing the
> > > >> nand partition table completely from the kernel device tree.
> > > >> Same with the SPI nor partition table.
>
> Ah, well if these are essentially just a backup, then why do they need
> changed at all? To be more precise about my "dumb" statement: it seems
> unwise to assume that all systems using a particular board will have the
> same partition layout. So *relying* on the in-kernel DTS(I) files to
> have a universal partition layout would likely cause problems.
>
> I don't have much problem with keeping a sample layout there as a
> backup, if you find it useful. But it seems like it will be hard to
> argue that you can ever change it in the future.
>
> Anyway, the ofpart mechanism is there, and it's fine to use it, but it's
> up to you to understand the implications and manage the backwards
> compatibility problems :)
>
> > > >> I will send patches for this.
> > > >
> > > > OK thanks! Also thank you Brian for your comments.
> > > >
> > >
> > > Tony - I tested leaving the partition info as-is with the updates from
> > > the bootloader and it works. Would you prefer that I match Brian and
> > > remove the partition table completely, or should I just leave my board
> > > alone?
> > >
> > > I am good either way.
> >
> > OK. How about let's remove the partitions from kernel for v4.11 as
> > clean-up then for cases where the bootloader might change them?
>
> I don't have much stake in this but...if there were any systems using
> the backup layout (i.e., the in-kernel partition layout), wouldn't that
> break them? Is there a problem with just leaving them alone?
Yeah I guess it depends on the device and it's bootloader versions.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 14/19] media: imx: Add Camera Interface subdev driver
From: Steve Longerbeam @ 2017-01-06 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4a893d70-f34a-9fb1-401f-bcb954e3a2cb@mentor.com>
On 01/04/2017 06:55 AM, Vladimir Zapolskiy wrote:
> On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
>>
>> diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile
>> index d2a962c..fe9e992 100644
>> --- a/drivers/staging/media/imx/Makefile
>> +++ b/drivers/staging/media/imx/Makefile
>> @@ -8,4 +8,4 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-ic.o
>>
>> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o
>> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-smfc.o
>> -
>> +obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-camif.o
> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-camif.o imx-csi.o imx-smfc.o
>
> as an option.
I prefer to keep on separate lines as explained earlier.
>
>> diff --git a/drivers/staging/media/imx/imx-camif.c b/drivers/staging/media/imx/imx-camif.c
>> new file mode 100644
>> index 0000000..3cf167e
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-camif.c
>> @@ -0,0 +1,1010 @@
>> +/*
>> + * Video Camera Capture Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * Copyright (c) 2012-2016 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/timer.h>
>> +#include <linux/sched.h>
>> +#include <linux/slab.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pinctrl/consumer.h>
>> +#include <linux/of_platform.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-ioctl.h>
>> +#include <media/videobuf2-dma-contig.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
>> +#include <media/v4l2-event.h>
> Please sort the list of headers alphabetically.
done.
>> +#include <video/imx-ipu-v3.h>
>> +#include <media/imx.h>
>> +#include "imx-media.h"
>> +
>> +#define DEVICE_NAME "imx-media-camif"
> I would propose to drop this macro.
done.
>> +
>> +#define CAMIF_DQ_TIMEOUT 5000
> Add a comment about time unit?
actually that was ancient and no longer used, removed.
>
>> +
>> +struct camif_priv;
>> +
> This is a leftover apparently.
ditto, removed.
>> +
>> + ret = v4l2_async_register_subdev(&priv->sd);
>> + if (ret)
>> + goto free_ctrls;
>> +
>> + return 0;
>> +free_ctrls:
>> + v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
>> + return ret;
> A shorter version:
>
> if (ret)
> v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
>
> return ret;
done.
>> +
>> +static struct platform_driver imx_camif_driver = {
>> + .probe = camif_probe,
>> + .remove = camif_remove,
>> + .driver = {
>> + .name = DEVICE_NAME,
>> + .owner = THIS_MODULE,
> Please drop the owner assignment.
done.
Steve
^ permalink raw reply
* [PATCH v2 13/19] media: imx: Add IC subdev drivers
From: Steve Longerbeam @ 2017-01-06 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <96684048-c5ad-3e64-0fbc-61dcaf184519@mentor.com>
On 01/04/2017 06:48 AM, Vladimir Zapolskiy wrote:
> On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
>
>> +
>> + ret = ic_ops[priv->task_id]->init(priv);
>> + if (ret)
>> + return ret;
>> +
>> + ret = v4l2_async_register_subdev(&priv->sd);
>> + if (ret)
>> + goto remove;
>> +
>> + return 0;
>> +remove:
>> + ic_ops[priv->task_id]->remove(priv);
>> + return ret;
> if (ret)
> ic_ops[priv->task_id]->remove(priv);
>
> return ret;
>
> as an alternative.
done.
>
>
> +
> +static struct platform_driver imx_ic_driver = {
> + .probe = imx_ic_probe,
> + .remove = imx_ic_remove,
> + .id_table = imx_ic_ids,
> + .driver = {
> + .name = "imx-ipuv3-ic",
> + .owner = THIS_MODULE,
> Please drop .owner assignment.
done.
>> diff --git a/drivers/staging/media/imx/imx-ic-pp.c b/drivers/staging/media/imx/imx-ic-pp.c
>> new file mode 100644
>> index 0000000..5ef0581
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-ic-pp.c
>> @@ -0,0 +1,636 @@
>> +/*
>> + * V4L2 IC Post-Processor Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * Copyright (c) 2014-2016 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/timer.h>
>> +#include <linux/sched.h>
>> +#include <linux/slab.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pinctrl/consumer.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-ioctl.h>
>> +#include <media/videobuf2-dma-contig.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
> Please sort the list of headers alphabetically.
done.
>
>>
>> +
>> + priv->out_run = kzalloc(IMX_MEDIA_MAX_RING_BUFS *
>> + sizeof(*priv->out_run), GFP_KERNEL);
>> + if (!priv->out_run) {
>> + v4l2_err(&ic_priv->sd, "failed to alloc src ring runs\n");
> In OOM situation the core will report it, probably you can drop the message.
with a backtrace? I can't remember, if not I'd like to keep this.
>> diff --git a/drivers/staging/media/imx/imx-ic-prpenc.c b/drivers/staging/media/imx/imx-ic-prpenc.c
>> new file mode 100644
>> index 0000000..e17216b
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-ic-prpenc.c
>> @@ -0,0 +1,1037 @@
>> +/*
>> + * V4L2 Capture IC Encoder Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * This subdevice handles capture of video frames from the CSI, which
>> + * are routed directly to the Image Converter preprocess encode task,
>> + * for resizing, colorspace conversion, and rotation.
>> + *
>> + * Copyright (c) 2012-2016 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/timer.h>
>> +#include <linux/sched.h>
>> +#include <linux/slab.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pinctrl/consumer.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-ioctl.h>
>> +#include <media/videobuf2-dma-contig.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
> Please sort the list of headers alphabetically.
done.
>
>> +static irqreturn_t prpenc_eof_interrupt(int irq, void *dev_id)
>> +{
>> + struct prpenc_priv *priv = dev_id;
>> + struct imx_media_dma_buf *done, *next;
>> + struct ipuv3_channel *channel;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&priv->irqlock, flags);
> Here spin_lock(&priv->irqlock) should be sufficient.
done.
>> +
>> + ret = media_entity_pads_init(&sd->entity, PRPENC_NUM_PADS, priv->pad);
>> + if (ret)
>> + goto free_ctrls;
>> +
>> + return 0;
>> +free_ctrls:
>> + v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
>> + return ret;
> if (ret)
> v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
>
> return ret;
>
> version is shorter.
done.
>
> diff --git a/drivers/staging/media/imx/imx-ic-prpvf.c
> b/drivers/staging/media/imx/imx-ic-prpvf.c
>> new file mode 100644
>> index 0000000..53ce006
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-ic-prpvf.c
>> @@ -0,0 +1,1180 @@
>> +/*
>> + * V4L2 IC Deinterlacer Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * Copyright (c) 2014-2016 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/timer.h>
>> +#include <linux/sched.h>
>> +#include <linux/slab.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pinctrl/consumer.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-ioctl.h>
>> +#include <media/videobuf2-dma-contig.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
> Please sort the list of headers alphabetically.
done.
>
>> +/* prpvf_out_ch EOF interrupt (progressive frame ready) */
>> +static irqreturn_t prpvf_out_eof_interrupt(int irq, void *dev_id)
>> +{
>> + struct prpvf_priv *priv = dev_id;
>> + struct imx_media_dma_buf *done;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&priv->irqlock, flags);
>
> Here spin_lock(&priv->irqlock) should be sufficient.
done.
>
>> diff --git a/drivers/staging/media/imx/imx-ic.h b/drivers/staging/media/imx/imx-ic.h
>> new file mode 100644
>> index 0000000..9aed5f5
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-ic.h
>> @@ -0,0 +1,36 @@
>> +/*
>> + * V4L2 Image Converter Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * Copyright (c) 2016 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#ifndef _IMX_IC_H
>> +#define _IMX_IC_H
>> +
> Please add header files or declarations of all used structs.
done (it only needs v4l2-subdev.h).
Steve
^ permalink raw reply
* [RFC PATCH] vring: Force use of DMA API for ARM-based systems
From: Robin Murphy @ 2017-01-06 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0b9a1f70-58fe-69c2-87db-d7773cb6a68c@arm.com>
On 06/01/17 17:48, Jean-Philippe Brucker wrote:
> Hi Will,
>
> On 20/12/16 15:14, Will Deacon wrote:
>> Booting Linux on an ARM fastmodel containing an SMMU emulation results
>> in an unexpected I/O page fault from the legacy virtio-blk PCI device:
>>
>> [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
>> [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
>> [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
>> [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
>> [ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
>> [ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
>> [ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
>> [ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
>> [ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
>> [ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
>>
>> <system hangs failing to read partition table>
>>
>> This is because the virtio-blk is behind an SMMU, so we have consequently
>> swizzled its DMA ops and configured the SMMU to translate accesses. This
>> then requires the vring code to use the DMA API to establish translations,
>> otherwise all transactions will result in fatal faults and termination.
>>
>> Given that ARM-based systems only see an SMMU if one is really present
>> (the topology is all described by firmware tables such as device-tree or
>> IORT), then we can safely use the DMA API for all virtio devices.
>
> There is a problem with the platform block device on that same model.
> Since it's not behind the SMMU, the DMA ops fall back to swiotlb, which
> limits the number of mappings.
>
> It used to work with 4.9, but since 9491ae4 ("mm: don't cap request size
> based on read-ahead setting") unlocked read-ahead, we quickly run into
> the limit of swiotlb and panic:
>
> [ 5.382359] virtio-mmio 1c130000.virtio_block: swiotlb buffer is full
> (sz: 491520 bytes)
> [ 5.382452] virtio-mmio 1c130000.virtio_block: DMA: Out of SW-IOMMU
> space for 491520 bytes
> [ 5.382531] Kernel panic - not syncing: DMA: Random memory could be
> DMA written
> ...
> [ 5.383148] [<ffff0000083ad754>] swiotlb_map_page+0x194/0x1a0
> [ 5.383226] [<ffff000008096bb8>] __swiotlb_map_page+0x20/0x88
> [ 5.383320] [<ffff0000084bf738>] vring_map_one_sg.isra.1+0x70/0x88
> [ 5.383417] [<ffff0000084c04fc>] virtqueue_add_sgs+0x2ec/0x4e8
> [ 5.383505] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8
> ...
> [ 5.384449] [<ffff0000081829c4>] ondemand_readahead+0xfc/0x2b8
>
> Commit 9491ae4 caps the read-ahead request to a limit set by the backing
> device. For virtio-blk, it is infinite (as set by the call to
> blk_queue_max_hw_sectors in virtblk_probe).
>
> I'm not sure how to fix this. Setting an arbitrary sector limit in the
> virtio-blk driver seems unfair to other users. Maybe we should check if
> the device is behind a hardware IOMMU before using the DMA API?
Hmm, this looks more like the virtio_block device simply has the wrong
DMA mask to begin with. For virtio-pci we set the streaming DMA mask to
64 bits - should a platform device not be similarly capable?
Robin.
>
> Thanks,
> Jean-Philippe
>
>> Cc: Andy Lutomirski <luto@kernel.org>
>> Cc: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>> ---
>> drivers/virtio/virtio_ring.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
>> index ed9c9eeedfe5..06b91e29d1b7 100644
>> --- a/drivers/virtio/virtio_ring.c
>> +++ b/drivers/virtio/virtio_ring.c
>> @@ -159,6 +159,10 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
>> if (xen_domain())
>> return true;
>>
>> + /* On ARM-based machines, the DMA ops will do the right thing */
>> + if (IS_ENABLED(CONFIG_ARM) || IS_ENABLED(CONFIG_ARM64))
>> + return true;
>> +
>> return false;
>> }
>>
>>
>
>
> _______________________________________________
> 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 v4 2/2] cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs
From: Markus Mayer @ 2017-01-06 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106041442.GD21926@vireshk-i7>
On 5 January 2017 at 20:14, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 20-12-16, 14:55, Markus Mayer wrote:
>> From: Markus Mayer <mmayer@broadcom.com>
>>
>> This CPUfreq driver provides basic frequency scaling for older Broadcom
>> STB SoCs that do not use AVS firmware with DVFS support. There is no
>> support for voltage scaling.
>>
>> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
>> ---
>> drivers/cpufreq/Kconfig.arm | 12 ++
>> drivers/cpufreq/Makefile | 1 +
>> drivers/cpufreq/brcmstb-cpufreq.c | 377 ++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 390 insertions(+)
>> create mode 100644 drivers/cpufreq/brcmstb-cpufreq.c
>
> I am fine with this patch as I have already Acked V3 of it. But please fix the
> bindings improvement suggested by Stephen first.
Yes, that is on my list of things to do. I will send an update
hopefully next week.
Thanks,
-Markus
^ permalink raw reply
* [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Brian Norris @ 2017-01-06 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106161421.GD2630@atomide.com>
On Fri, Jan 06, 2017 at 08:14:22AM -0800, Tony Lindgren wrote:
> * Adam Ford <aford173@gmail.com> [170106 08:06]:
> > On Fri, Jan 6, 2017 at 10:02 AM, Tony Lindgren <tony@atomide.com> wrote:
> > > * Teresa Remmet <t.remmet@phytec.de> [170106 01:28]:
> > >> Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:
> > >> > On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
> > >> > > I'm suggesting we leave the kernel nodes empty and let u-boot
> > >> > > populate them, so maybe you guys can discuss this on the related
> > >> > > lists.
> > >> > That's an option. I've worked with platforms that did something like
> > >> > this, and that's really one of the only ways you can handle putting
> > >> > partition information in the device tree. You're really hamstringing
> > >> > yourself when you put all the partition information in the device
> > >> > tree.
> > >> > And it's just dumb once that gets codified in the kernel source tree.
> > >> >
> > >>
> > >> In our case the bootloader does pass the partition table to the kernel.
> > >> So it gets overwritten anyway. This was just more for backup,
> > >> if someone uses a different bootloader. But I'm fine with removing the
> > >> nand partition table completely from the kernel device tree.
> > >> Same with the SPI nor partition table.
Ah, well if these are essentially just a backup, then why do they need
changed at all? To be more precise about my "dumb" statement: it seems
unwise to assume that all systems using a particular board will have the
same partition layout. So *relying* on the in-kernel DTS(I) files to
have a universal partition layout would likely cause problems.
I don't have much problem with keeping a sample layout there as a
backup, if you find it useful. But it seems like it will be hard to
argue that you can ever change it in the future.
Anyway, the ofpart mechanism is there, and it's fine to use it, but it's
up to you to understand the implications and manage the backwards
compatibility problems :)
> > >> I will send patches for this.
> > >
> > > OK thanks! Also thank you Brian for your comments.
> > >
> >
> > Tony - I tested leaving the partition info as-is with the updates from
> > the bootloader and it works. Would you prefer that I match Brian and
> > remove the partition table completely, or should I just leave my board
> > alone?
> >
> > I am good either way.
>
> OK. How about let's remove the partitions from kernel for v4.11 as
> clean-up then for cases where the bootloader might change them?
I don't have much stake in this but...if there were any systems using
the backup layout (i.e., the in-kernel partition layout), wouldn't that
break them? Is there a problem with just leaving them alone?
Brian
^ permalink raw reply
* [PATCH v2 2/4] watchdog: bcm2835_wdt: Use watchdog core to install restart handler
From: Eric Anholt @ 2017-01-06 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483674720-4870-2-git-send-email-linux@roeck-us.net>
Guenter Roeck <linux@roeck-us.net> writes:
> Use the infrastructure provided by the watchdog core to install
> the restart handler.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> v2: Need to call watchdog_set_restart_priority()
Seems fine.
Acked-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170106/394426ae/attachment.sig>
^ permalink raw reply
* [PATCH v2 12/19] media: imx: Add SMFC subdev driver
From: Steve Longerbeam @ 2017-01-06 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13ff9579-ce8e-9272-ee44-9b597631f6b5@mentor.com>
On 01/04/2017 06:23 AM, Vladimir Zapolskiy wrote:
> On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
>> This is a media entity subdevice driver for the i.MX Sensor Multi-FIFO
>> Controller module. Video frames are received from the CSI and can
>> be routed to various sinks including the i.MX Image Converter for
>> scaling, color-space conversion, motion compensated deinterlacing,
>> and image rotation.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>> ---
>> drivers/staging/media/imx/Makefile | 1 +
>> drivers/staging/media/imx/imx-smfc.c | 739 +++++++++++++++++++++++++++++++++++
>> 2 files changed, 740 insertions(+)
>> create mode 100644 drivers/staging/media/imx/imx-smfc.c
>>
>> diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile
>> index 133672a..3559d7b 100644
>> --- a/drivers/staging/media/imx/Makefile
>> +++ b/drivers/staging/media/imx/Makefile
>> @@ -5,4 +5,5 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
>> obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
>>
>> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o
>> +obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-smfc.o
> May be
>
> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o imx-smfc.o
I'd prefer to keep them on separate lines, to indicate they
are all built as separate modules.
>
>>
>> diff --git a/drivers/staging/media/imx/imx-smfc.c b/drivers/staging/media/imx/imx-smfc.c
>> new file mode 100644
>> index 0000000..565048c
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-smfc.c
>> @@ -0,0 +1,739 @@
>> +/*
>> + * V4L2 Capture SMFC Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * This subdevice handles capture of raw/unconverted video frames
>> + * from the CSI, directly to memory via the Sensor Multi-FIFO Controller.
>> + *
>> + * Copyright (c) 2012-2016 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/timer.h>
>> +#include <linux/sched.h>
>> +#include <linux/slab.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pinctrl/consumer.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-ioctl.h>
>> +#include <media/videobuf2-dma-contig.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
> Please sort the list of headers alphabetically.
done.
>
>> +static irqreturn_t imx_smfc_eof_interrupt(int irq, void *dev_id)
>> +{
>> + struct imx_smfc_priv *priv = dev_id;
>> + struct imx_media_dma_buf *done, *next;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&priv->irqlock, flags);
> spin_lock(&priv->irqlock) should be sufficient.
yes thanks.
>
>> +
>> +static const struct platform_device_id imx_smfc_ids[] = {
>> + { .name = "imx-ipuv3-smfc" },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(platform, imx_smfc_ids);
>> +
>> +static struct platform_driver imx_smfc_driver = {
>> + .probe = imx_smfc_probe,
>> + .remove = imx_smfc_remove,
>> + .id_table = imx_smfc_ids,
>> + .driver = {
>> + .name = "imx-ipuv3-smfc",
>> + .owner = THIS_MODULE,
> You can drop owner assignment.
done.
Steve
^ permalink raw reply
* [RFC PATCH] vring: Force use of DMA API for ARM-based systems
From: Will Deacon @ 2017-01-06 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0b9a1f70-58fe-69c2-87db-d7773cb6a68c@arm.com>
Hi Jean-Philippe,
On Fri, Jan 06, 2017 at 05:48:33PM +0000, Jean-Philippe Brucker wrote:
> On 20/12/16 15:14, Will Deacon wrote:
> > Booting Linux on an ARM fastmodel containing an SMMU emulation results
> > in an unexpected I/O page fault from the legacy virtio-blk PCI device:
> >
> > [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> > [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> > [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> > [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
> > [ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> > [ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> > [ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> > [ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> > [ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
> > [ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> >
> > <system hangs failing to read partition table>
> >
> > This is because the virtio-blk is behind an SMMU, so we have consequently
> > swizzled its DMA ops and configured the SMMU to translate accesses. This
> > then requires the vring code to use the DMA API to establish translations,
> > otherwise all transactions will result in fatal faults and termination.
> >
> > Given that ARM-based systems only see an SMMU if one is really present
> > (the topology is all described by firmware tables such as device-tree or
> > IORT), then we can safely use the DMA API for all virtio devices.
>
> There is a problem with the platform block device on that same model.
> Since it's not behind the SMMU, the DMA ops fall back to swiotlb, which
> limits the number of mappings.
>
> It used to work with 4.9, but since 9491ae4 ("mm: don't cap request size
> based on read-ahead setting") unlocked read-ahead, we quickly run into
> the limit of swiotlb and panic:
>
> [ 5.382359] virtio-mmio 1c130000.virtio_block: swiotlb buffer is full
> (sz: 491520 bytes)
> [ 5.382452] virtio-mmio 1c130000.virtio_block: DMA: Out of SW-IOMMU
> space for 491520 bytes
> [ 5.382531] Kernel panic - not syncing: DMA: Random memory could be
> DMA written
> ...
> [ 5.383148] [<ffff0000083ad754>] swiotlb_map_page+0x194/0x1a0
> [ 5.383226] [<ffff000008096bb8>] __swiotlb_map_page+0x20/0x88
> [ 5.383320] [<ffff0000084bf738>] vring_map_one_sg.isra.1+0x70/0x88
> [ 5.383417] [<ffff0000084c04fc>] virtqueue_add_sgs+0x2ec/0x4e8
> [ 5.383505] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8
> ...
> [ 5.384449] [<ffff0000081829c4>] ondemand_readahead+0xfc/0x2b8
Oh, lovely!
> Commit 9491ae4 caps the read-ahead request to a limit set by the backing
> device. For virtio-blk, it is infinite (as set by the call to
> blk_queue_max_hw_sectors in virtblk_probe).
>
> I'm not sure how to fix this. Setting an arbitrary sector limit in the
> virtio-blk driver seems unfair to other users. Maybe we should check if
> the device is behind a hardware IOMMU before using the DMA API?
Couldn't the same issue potentially occur with a hardware IOMMU, where
we run out of IOVA space due to unlimited readahead? I think it might be
best to enforce a finite limit for virtio devices when the DMA API is in
use.
Do any drivers for physical (i.e. non-virtual) hardware make use of
unlimited readahead?
Will
^ permalink raw reply
* [PATCH v2 11/19] media: imx: Add CSI subdev driver
From: Steve Longerbeam @ 2017-01-06 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21b54a7b-1254-a14f-767c-c92feed7433d@mentor.com>
On 01/04/2017 05:44 AM, Vladimir Zapolskiy wrote:
>
>> diff --git a/drivers/staging/media/imx/imx-csi.c b/drivers/staging/media/imx/imx-csi.c
>> new file mode 100644
>> index 0000000..975eafb
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-csi.c
>> @@ -0,0 +1,638 @@
>> +/*
>> + * V4L2 Capture CSI Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * Copyright (c) 2014-2016 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/videobuf2-dma-contig.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
> Please add the headers alphabetically ordered.
done.
>> +
>> +static int csi_start(struct csi_priv *priv)
>> +{
>> + int ret;
>> +
>> + if (!priv->sensor) {
>> + v4l2_err(&priv->sd, "no sensor attached\n");
>> + return -EINVAL;
>> + }
>> +
>> + ret = csi_setup(priv);
>> + if (ret)
>> + return ret;
>> +
>> + /* start the frame interval monitor */
>> + ret = imx_media_fim_set_stream(priv->fim, priv->sensor, true);
>> + if (ret)
>> + return ret;
>> +
>> + ret = ipu_csi_enable(priv->csi);
>> + if (ret) {
>> + v4l2_err(&priv->sd, "CSI enable error: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + return 0;
> if (ret)
> v4l2_err(&priv->sd, "CSI enable error: %d\n", ret);
>
> return ret;
I failed to cleanup in this path, so it is now:
ret = ipu_csi_enable(priv->csi);
if (ret) {
v4l2_err(&priv->sd, "CSI enable error: %d\n", ret);
goto fim_off;
}
return 0;
fim_off:
if (priv->fim)
imx_media_fim_set_stream(priv->fim, priv->sensor, false);
return ret;
>> +
>> +static int csi_link_setup(struct media_entity *entity,
>> + const struct media_pad *local,
>> + const struct media_pad *remote, u32 flags)
>> +{
>> + struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
>> + struct csi_priv *priv = v4l2_get_subdevdata(sd);
>> + struct v4l2_subdev *remote_sd;
>> +
>> + dev_dbg(priv->dev, "link setup %s -> %s", remote->entity->name,
>> + local->entity->name);
>> +
>> + remote_sd = media_entity_to_v4l2_subdev(remote->entity);
>> +
>> + if (local->flags & MEDIA_PAD_FL_SINK) {
>> + if (flags & MEDIA_LNK_FL_ENABLED) {
>> + if (priv->src_sd)
>> + return -EBUSY;
>> + priv->src_sd = remote_sd;
>> + } else {
>> + priv->src_sd = NULL;
>> + return 0;
> You can remove the return above.
right, fixed.
>
>> +
>> + ret = v4l2_async_register_subdev(&priv->sd);
>> + if (ret)
>> + goto free_ctrls;
>> +
>> + return 0;
>> +free_ctrls:
>> + v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
>> + return ret;
> This is a functionally equal and simplified version:
>
> if (ret)
> v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
>
> return ret;
thanks, done.
>> +
>> +static struct platform_driver imx_csi_driver = {
>> + .probe = imx_csi_probe,
>> + .remove = imx_csi_remove,
>> + .id_table = imx_csi_ids,
>> + .driver = {
>> + .name = "imx-ipuv3-csi",
>> + .owner = THIS_MODULE,
> Please drop .owner.
ok, I tested this and there are no regressions, done
for all modules.
Steve
^ permalink raw reply
* [GIT PULL] arm64 fixes for 4.10-rc3
From: Catalin Marinas @ 2017-01-06 18:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull the arm64 fixes below. Thanks.
The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for you to fetch changes up to 9d84fb27fa135c99c9fe3de33628774a336a70a8:
arm64: restore get_current() optimisation (2017-01-04 16:26:18 +0000)
----------------------------------------------------------------
- Re-introduce the arm64 get_current() optimisation
- KERN_CONT fallout fix in show_pte()
----------------------------------------------------------------
Mark Rutland (2):
arm64: mm: fix show_pte KERN_CONT fallout
arm64: restore get_current() optimisation
arch/arm64/include/asm/current.h | 10 +++++++++-
arch/arm64/mm/fault.c | 8 ++++----
2 files changed, 13 insertions(+), 5 deletions(-)
--
Catalin
^ permalink raw reply
* [PATCH v2 5/5] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: kbuild test robot @ 2017-01-06 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483677228-2325-6-git-send-email-david@lechnology.com>
Hi David,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/David-Lechner/Support-for-LEGO-MINDSTORMS-EV3/20170107-002649
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/da850-lego-ev3.dts:378.1-6 Label or path usb1 not found
FATAL ERROR: Syntax error parsing input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 22125 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170107/22479587/attachment-0001.gz>
^ permalink raw reply
* [RFC PATCH] vring: Force use of DMA API for ARM-based systems
From: Jean-Philippe Brucker @ 2017-01-06 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482246864-16399-1-git-send-email-will.deacon@arm.com>
Hi Will,
On 20/12/16 15:14, Will Deacon wrote:
> Booting Linux on an ARM fastmodel containing an SMMU emulation results
> in an unexpected I/O page fault from the legacy virtio-blk PCI device:
>
> [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
> [ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> [ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> [ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> [ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> [ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
> [ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
>
> <system hangs failing to read partition table>
>
> This is because the virtio-blk is behind an SMMU, so we have consequently
> swizzled its DMA ops and configured the SMMU to translate accesses. This
> then requires the vring code to use the DMA API to establish translations,
> otherwise all transactions will result in fatal faults and termination.
>
> Given that ARM-based systems only see an SMMU if one is really present
> (the topology is all described by firmware tables such as device-tree or
> IORT), then we can safely use the DMA API for all virtio devices.
There is a problem with the platform block device on that same model.
Since it's not behind the SMMU, the DMA ops fall back to swiotlb, which
limits the number of mappings.
It used to work with 4.9, but since 9491ae4 ("mm: don't cap request size
based on read-ahead setting") unlocked read-ahead, we quickly run into
the limit of swiotlb and panic:
[ 5.382359] virtio-mmio 1c130000.virtio_block: swiotlb buffer is full
(sz: 491520 bytes)
[ 5.382452] virtio-mmio 1c130000.virtio_block: DMA: Out of SW-IOMMU
space for 491520 bytes
[ 5.382531] Kernel panic - not syncing: DMA: Random memory could be
DMA written
...
[ 5.383148] [<ffff0000083ad754>] swiotlb_map_page+0x194/0x1a0
[ 5.383226] [<ffff000008096bb8>] __swiotlb_map_page+0x20/0x88
[ 5.383320] [<ffff0000084bf738>] vring_map_one_sg.isra.1+0x70/0x88
[ 5.383417] [<ffff0000084c04fc>] virtqueue_add_sgs+0x2ec/0x4e8
[ 5.383505] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8
...
[ 5.384449] [<ffff0000081829c4>] ondemand_readahead+0xfc/0x2b8
Commit 9491ae4 caps the read-ahead request to a limit set by the backing
device. For virtio-blk, it is infinite (as set by the call to
blk_queue_max_hw_sectors in virtblk_probe).
I'm not sure how to fix this. Setting an arbitrary sector limit in the
virtio-blk driver seems unfair to other users. Maybe we should check if
the device is behind a hardware IOMMU before using the DMA API?
Thanks,
Jean-Philippe
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> drivers/virtio/virtio_ring.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index ed9c9eeedfe5..06b91e29d1b7 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -159,6 +159,10 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
> if (xen_domain())
> return true;
>
> + /* On ARM-based machines, the DMA ops will do the right thing */
> + if (IS_ENABLED(CONFIG_ARM) || IS_ENABLED(CONFIG_ARM64))
> + return true;
> +
> return false;
> }
>
>
^ 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