* [PATCH v6 05/14] ACPI: platform-msi: retrieve dev id from IORT
From: Tomasz Nowicki @ 2017-01-03 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-6-git-send-email-hanjun.guo@linaro.org>
On 02.01.2017 14:31, Hanjun Guo wrote:
> For devices connecting to ITS, it needs dev id to identify
> itself, and this dev id is represented in the IORT table in
> named componant node [1] for platform devices, so in this
> patch we will scan the IORT to retrieve device's dev id.
>
> Introduce iort_pmsi_get_dev_id() with pointer dev passed
> in for that purpose.
>
> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Sinan Kaya <okaya@codeaurora.org>
> Tested-by: Majun <majun258@huawei.com>
> Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/acpi/arm64/iort.c | 26 ++++++++++++++++++++++++++
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 4 +++-
> include/linux/acpi_iort.h | 8 ++++++++
> 3 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 174e983..ab7bae7 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -444,6 +444,32 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> }
>
> /**
> + * iort_pmsi_get_dev_id() - Get the device id for a device
> + * @dev: The device for which the mapping is to be done.
> + * @dev_id: The device ID found.
> + *
> + * Returns: 0 for successful find a dev id, errors otherwise
> + */
> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> +{
> + struct acpi_iort_node *node;
> +
> + if (!iort_table)
> + return -ENODEV;
> +
> + node = iort_find_dev_node(dev);
> + if (!node) {
> + dev_err(dev, "can't find related IORT node\n");
> + return -ENODEV;
> + }
> +
> + if(!iort_node_get_id(node, dev_id, IORT_MSI_TYPE, 0))
> + return -ENODEV;
> +
> + return 0;
> +}
> +
> +/**
Giving that you are extending this to NC->
SMMU->ITS case in later patch, we can use existing helpers from iort.c,
like that:
+/**
+ * iort_pmsi_get_dev_id() - Get the device id for a device
+ * @dev: The device for which the mapping is to be done.
+ * @dev_id: The device ID found.
+ *
+ * Returns: 0 for successful find a dev id, errors otherwise
+ */
+int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
+{
+ struct acpi_iort_node *node;
+
+ node = iort_find_dev_node(dev);
+ if (!node)
+ return -ENODEV;
+
+ if (!iort_node_map_rid(node, 0, dev_id, IORT_MSI_TYPE))
+ return -ENODEV;
+
+ return 0;
+}
Correct me if I am wrong.
Tomasz
^ permalink raw reply
* [PATCH v1] mtd: nand: tango: Update DT binding description
From: Boris Brezillon @ 2017-01-03 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <24522cc9-9d9a-980d-8cd2-18fb0de19a5f@sigmadesigns.com>
On Tue, 3 Jan 2017 09:34:59 +0100
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> wrote:
> On 29/12/2016 19:23, Boris Brezillon wrote:
> > On Mon, 19 Dec 2016 15:30:12 +0100
> > Marc Gonzalez <marc_gonzalez@sigmadesigns.com> wrote:
> >
> >> Visually separate register ranges (address/size pairs) in reg prop.
> >> Change DMA channel name, for consistency with other drivers.
> >>
> >> Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
> >> ---
> >> Documentation/devicetree/bindings/mtd/tango-nand.txt | 6 +++---
> >> drivers/mtd/nand/tango_nand.c | 2 +-
> >> 2 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mtd/tango-nand.txt b/Documentation/devicetree/bindings/mtd/tango-nand.txt
> >> index ad5a02f2ac8c..cd1bf2ac9055 100644
> >> --- a/Documentation/devicetree/bindings/mtd/tango-nand.txt
> >> +++ b/Documentation/devicetree/bindings/mtd/tango-nand.txt
> >> @@ -5,7 +5,7 @@ Required properties:
> >> - compatible: "sigma,smp8758-nand"
> >> - reg: address/size of nfc_reg, nfc_mem, and pbus_reg
> >> - dmas: reference to the DMA channel used by the controller
> >> -- dma-names: "nfc_sbox"
> >> +- dma-names: "rxtx"
> >
> > You probably want to fix the driver accordingly ;-).
>
> I'm confused...
>
> Did you miss the change (below) to drivers/mtd/nand/tango_nand.c
> fixing the driver as well as the documentation?
Indeed, I missed it. The patch is fine, I'll queue it for 4.10-rcX.
Sorry for the noise.
BTW, I heard you had some fixes for 4.10. Feel free to send them.
Regards,
Boris
^ permalink raw reply
* [PATCH v2] Fix CMD6 timeout issue
From: Yong Mao @ 2017-01-03 8:49 UTC (permalink / raw)
To: linux-arm-kernel
yong mao (2):
mmc: core: Fix CMD6 timeout issue
mmc: mediatek: correct the implementation of msdc_card_busy
drivers/mmc/core/core.c | 19 +++++++++++++++++++
drivers/mmc/host/mtk-sd.c | 7 ++-----
2 files changed, 21 insertions(+), 5 deletions(-)
--
1.8.1.1.dirty
^ permalink raw reply
* [PATCH v2 1/2] mmc: core: Fix CMD6 timeout issue
From: Yong Mao @ 2017-01-03 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483433397-11756-1-git-send-email-yong.mao@mediatek.com>
From: yong mao <yong.mao@mediatek.com>
When initializing EMMC, after switch to HS400,
it will issue CMD6 to change ext_csd,
if first CMD6 got CRC error,
the repeat CMD6 may get timeout,
that's because card is not back to transfer state immediately.
For resolving this issue, it need check if card is busy
before sending repeat CMD6.
Not only CMD6 here has this issue, but also other R1B CMD has
the same issue.
Signed-off-by: Yong Mao <yong.mao@mediatek.com>
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
---
drivers/mmc/core/core.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 1076b9d..8674dbb 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -566,6 +566,25 @@ void mmc_wait_for_req_done(struct mmc_host *host, struct mmc_request *mrq)
mmc_retune_recheck(host);
+ /*
+ * If a R1B CMD such as CMD6 occur CRC error,
+ * it will retry 3 times here.
+ * But before retrying, it must ensure card is in
+ * transfer state.
+ * Otherwise, the next retried CMD will got TMO error.
+ */
+ if (mmc_resp_type(cmd) == MMC_RSP_R1B && host->ops->card_busy) {
+ int tries = 500; /* Wait aprox 500ms at maximum */
+
+ while (host->ops->card_busy(host) && --tries)
+ mmc_delay(1);
+
+ if (tries == 0) {
+ cmd->error = -EBUSY;
+ break;
+ }
+ }
+
pr_debug("%s: req failed (CMD%u): %d, retrying...\n",
mmc_hostname(host), cmd->opcode, cmd->error);
cmd->retries--;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/2] mmc: mediatek: correct the implementation of msdc_card_busy
From: Yong Mao @ 2017-01-03 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483433397-11756-1-git-send-email-yong.mao@mediatek.com>
From: yong mao <yong.mao@mediatek.com>
msdc_card_busy only need check if the data0 is low.
In sdio data1 irq mode, data1 may be low because of interruption.
Signed-off-by: Yong Mao <yong.mao@mediatek.com>
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
---
drivers/mmc/host/mtk-sd.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 10ef2ae..80ba034 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1074,11 +1074,8 @@ static int msdc_card_busy(struct mmc_host *mmc)
struct msdc_host *host = mmc_priv(mmc);
u32 status = readl(host->base + MSDC_PS);
- /* check if any pin between dat[0:3] is low */
- if (((status >> 16) & 0xf) != 0xf)
- return 1;
-
- return 0;
+ /* only check if data0 is low */
+ return !(status & BIT(16));
}
static void msdc_request_timeout(struct work_struct *work)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3/4] ARM: davinci: da8xx: add pdata-quirks, use for VPIF capture
From: Sekhar Nori @ 2017-01-03 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207193137.27947-4-khilman@baylibre.com>
Hi Kevin,
On Thursday 08 December 2016 01:01 AM, Kevin Hilman wrote:
> Add pdata-quirks for da8xx DT platforms, which adds the legacy platform
> data for vpif_capture driver.
>
> Passing legacy platform_data is required until the V4L2 framework, and
> subdevice drivers (such as the tvp514x) grow a way of selecting input
> and output routing (c.f. V4L2 s_routing API)
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> arch/arm/mach-davinci/Makefile | 2 +-
> arch/arm/mach-davinci/da8xx-dt.c | 2 +
> arch/arm/mach-davinci/include/mach/common.h | 4 +
> arch/arm/mach-davinci/pdata-quirks.c | 155 ++++++++++++++++++++++++++++
> 4 files changed, 162 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/mach-davinci/pdata-quirks.c
Can you please split this to separate addition of pdata quirks from
adding vpif capture support. I think it is fine to have a pre-patch
adding support for pdata quirks with just the sentinel included.
>
> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
> index da4c336b4637..90d2e6e4d913 100644
> --- a/arch/arm/mach-davinci/Makefile
> +++ b/arch/arm/mach-davinci/Makefile
> @@ -21,7 +21,7 @@ obj-$(CONFIG_AINTC) += irq.o
> obj-$(CONFIG_CP_INTC) += cp_intc.o
>
> # Board specific
> -obj-$(CONFIG_MACH_DA8XX_DT) += da8xx-dt.o
> +obj-$(CONFIG_MACH_DA8XX_DT) += da8xx-dt.o pdata-quirks.o
> obj-$(CONFIG_MACH_DAVINCI_EVM) += board-dm644x-evm.o
> obj-$(CONFIG_MACH_SFFSDR) += board-sffsdr.o
> obj-$(CONFIG_MACH_NEUROS_OSD2) += board-neuros-osd2.o
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index c9f7e9274aa8..69c8099de9f5 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -38,6 +38,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
> NULL),
> OF_DEV_AUXDATA("ti,da830-mcasp-audio", 0x01d00000, "davinci-mcasp.0", NULL),
> OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", NULL),
> + OF_DEV_AUXDATA("ti,da850-vpif", 0x01e17000, "vpif", NULL),
> {}
> };
>
> @@ -46,6 +47,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
> static void __init da850_init_machine(void)
> {
> of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
> + pdata_quirks_init();
> }
>
> static const char *const da850_boards_compat[] __initconst = {
> diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
> index 0b3c169758ed..1fd4cd2d1c23 100644
> --- a/arch/arm/mach-davinci/include/mach/common.h
> +++ b/arch/arm/mach-davinci/include/mach/common.h
> @@ -102,6 +102,10 @@ int davinci_pm_init(void);
> static inline int davinci_pm_init(void) { return 0; }
> #endif
>
> +#ifdef CONFIG_MACH_DA8XX_DT
> +extern void __init pdata_quirks_init(void);
I noticed that checkpatch complains about the extern (with strict
warnings turned on). I think its better to drop it. I know you probably
added it to be consistent with other declarations in the file.
> +#endif
> +
> #define SRAM_SIZE SZ_128K
>
> #endif /* __ARCH_ARM_MACH_DAVINCI_COMMON_H */
> diff --git a/arch/arm/mach-davinci/pdata-quirks.c b/arch/arm/mach-davinci/pdata-quirks.c
> new file mode 100644
> index 000000000000..a186513edf7e
> --- /dev/null
> +++ b/arch/arm/mach-davinci/pdata-quirks.c
> @@ -0,0 +1,155 @@
> +/*
> + * Legacy platform_data quirks
> + *
> + * Copyright (C) 2016 BayLibre, Inc
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include <linux/kernel.h>
> +#include <linux/of_platform.h>
> +
> +#include <media/i2c/tvp514x.h>
> +
> +#include <mach/common.h>
> +#include <mach/da8xx.h>
> +#include <mach/mux.h>
The mux.h include can be dropped after you dropped the muxing from this
patch.
> +
> +struct pdata_init {
> + const char *compatible;
> + void (*fn)(void);
> +};
> +
> +#if IS_ENABLED(CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE)
> +
> +#define TVP5147_CH0 "tvp514x-0"
> +#define TVP5147_CH1 "tvp514x-1"
> +
> +/* VPIF capture configuration */
> +static struct tvp514x_platform_data tvp5146_pdata = {
> + .clk_polarity = 0,
> + .hs_polarity = 1,
> + .vs_polarity = 1,
> +};
> +
> +#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
> +
> +static const struct vpif_input da850_ch0_inputs[] = {
> + {
> + .input = {
> + .index = 0,
> + .name = "Composite",
> + .type = V4L2_INPUT_TYPE_CAMERA,
> + .capabilities = V4L2_IN_CAP_STD,
> + .std = TVP514X_STD_ALL,
> + },
> + .input_route = INPUT_CVBS_VI2B,
> + .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
> + .subdev_name = TVP5147_CH0,
> + },
> +};
> +
> +static const struct vpif_input da850_ch1_inputs[] = {
> + {
> + .input = {
> + .index = 0,
> + .name = "S-Video",
> + .type = V4L2_INPUT_TYPE_CAMERA,
> + .capabilities = V4L2_IN_CAP_STD,
> + .std = TVP514X_STD_ALL,
> + },
> + .input_route = INPUT_SVIDEO_VI2C_VI1C,
> + .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
> + .subdev_name = TVP5147_CH1,
> + },
> +};
> +
> +static struct vpif_subdev_info da850_vpif_capture_sdev_info[] = {
> + {
> + .name = TVP5147_CH0,
> + .board_info = {
> + I2C_BOARD_INFO("tvp5146", 0x5d),
> + .platform_data = &tvp5146_pdata,
> + },
> + },
> + {
> + .name = TVP5147_CH1,
> + .board_info = {
> + I2C_BOARD_INFO("tvp5146", 0x5c),
> + .platform_data = &tvp5146_pdata,
> + },
> + },
> +};
> +
> +static struct vpif_capture_config da850_vpif_capture_config = {
> + .subdev_info = da850_vpif_capture_sdev_info,
> + .subdev_count = ARRAY_SIZE(da850_vpif_capture_sdev_info),
> + .chan_config[0] = {
> + .inputs = da850_ch0_inputs,
> + .input_count = ARRAY_SIZE(da850_ch0_inputs),
> + .vpif_if = {
> + .if_type = VPIF_IF_BT656,
> + .hd_pol = 1,
> + .vd_pol = 1,
> + .fid_pol = 0,
> + },
> + },
> + .chan_config[1] = {
> + .inputs = da850_ch1_inputs,
> + .input_count = ARRAY_SIZE(da850_ch1_inputs),
> + .vpif_if = {
> + .if_type = VPIF_IF_BT656,
> + .hd_pol = 1,
> + .vd_pol = 1,
> + .fid_pol = 0,
> + },
> + },
> + .card_name = "DA850/OMAP-L138 Video Capture",
> +};
> +
> +static void __init da850_vpif_legacy_init(void)
> +{
> + int ret;
> +
> + /* LCDK doesn't have the 2nd TVP514x on CH1 */
> + if (of_machine_is_compatible("ti,da850-lcdk"))
> + da850_vpif_capture_config.subdev_count = 1;
> +
> + /* EVM (UI card) uses i2c adapter 1 (not default: zero) */
> + if (of_machine_is_compatible("ti,da850-evm"))
> + da850_vpif_capture_config.i2c_adapter_id = 1;
> +
> + ret = da850_register_vpif_capture(&da850_vpif_capture_config);
> + if (ret)
> + pr_warn("%s: VPIF capture setup failed: %d\n",
> + __func__, ret);
> +}
> +#endif
> +
> +static void pdata_quirks_check(struct pdata_init *quirks)
This function can be marked __init too.
Thanks,
Sekhar
^ permalink raw reply
* [v2, 1/4] ARM: davinci: da8xx-dt: Add ti-aemif lookup for clock matching
From: Sekhar Nori @ 2017-01-03 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <72eb6441-6463-abd8-65e6-06772b925999@ti.com>
On Monday 02 January 2017 01:34 PM, Sekhar Nori wrote:
> On Saturday 31 December 2016 06:22 AM, David Lechner wrote:
>> On 08/10/2016 06:00 AM, Karl Beldan wrote:
>>> Many davinci boards (da830 and da850 families) don't have their clocks
>>> in DT yet and won't be successful in getting an unnamed aemif clock
>>> without explicitly registering them via clk_lookups, failing the
>>> ti-aemif memory driver probe.
>>>
>>> The current aemif lookup entry resolving to the same clock:
>>> 'CLK(NULL, "aemif", &aemif_clk)'
>>> remains, as it is currently used (davinci_nand is getting a named clock
>>> "aemif").
>>>
>>> This change will allow to switch from the mach-davinci aemif code to
>>> the ti-aemif memory driver.
>>>
>>> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
>>> ---
>>
>> FYI, I can't boot LEGO MINDSTORMS EV3 (AM1908) with a v4.9 mainline
>> kernel. I did a git bisect and traced it down to this patch. I'm
>> guessing that simply reverting it will break other things.
>>
>> The problem is that &aemif_clk is a node in a linked list and points to
>> itself, which creates an infinite loop when looking up the usb clocks
>> that are later in the list.
>>
>> I thought there was a patch to fix this properly from one of the Bay
>> Libre guys to fix this already, but I can't seem to find it at the
>> moment. When it is found, it would be good to have it applied to the 4.9
>> stable and 4.10 mainline trees.
>
> Yes, a patch was submitted. It is pending in my queue since I need to do
> a few experiments myself to determine if its the best solution possible.
> Thanks for the heads-up on need to mark it for v4.9 stable. Will do.
The master branch of my tree should have the patch included. If you can
test and confirm it works fine on the lego platform, it will be great.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v6 0/5] davinci: VPIF: add DT support
From: Sekhar Nori @ 2017-01-03 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d4b0501a-f83a-c8b1-e460-1ba50f68cca7@xs4all.nl>
Hi Hans,
On Friday 16 December 2016 03:17 PM, Hans Verkuil wrote:
> On 07/12/16 19:30, Kevin Hilman wrote:
>> Prepare the groundwork for adding DT support for davinci VPIF drivers.
>> This series does some fixups/cleanups and then adds the DT binding and
>> DT compatible string matching for DT probing.
>>
>> The controversial part from previous versions around async subdev
>> parsing, and specifically hard-coding the input/output routing of
>> subdevs, has been left out of this series. That part can be done as a
>> follow-on step after agreement has been reached on the path forward.
>> With this version, platforms can still use the VPIF capture/display
>> drivers, but must provide platform_data for the subdevs and subdev
>> routing.
>>
>> Tested video capture to memory on da850-lcdk board using composite
>> input.
>
> Other than the comment for the first patch this series looks good.
>
> So once that's addressed I'll queue it up for 4.11.
Can you provide an immutable commit (as it will reach v4.11) with with
this series applied? I have some platform changes to queue for v4.11
that depend on the driver updates.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] ARM: davinci_all_defconfig: enable dumb vga-dac drm bridge
From: Bartosz Golaszewski @ 2017-01-03 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480065182-7095-1-git-send-email-bgolaszewski@baylibre.com>
2016-11-25 10:13 GMT+01:00 Bartosz Golaszewski <bgolaszewski@baylibre.com>:
> This enables the dumb-vga-dac driver by default for davinci boards.
>
> The driver is needed for tilcdc support on da850-lcdk board.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/configs/davinci_all_defconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
> index b5e978f..ab1bf18 100644
> --- a/arch/arm/configs/davinci_all_defconfig
> +++ b/arch/arm/configs/davinci_all_defconfig
> @@ -127,6 +127,8 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y
> CONFIG_REGULATOR_TPS6507X=y
> CONFIG_DRM=m
> CONFIG_DRM_TILCDC=m
> +CONFIG_DRM_BRIDGE=y
> +CONFIG_DRM_DUMB_VGA_DAC=m
> CONFIG_FB=y
> CONFIG_FIRMWARE_EDID=y
> CONFIG_FB_DA8XX=y
> --
> 2.9.3
>
Hi Sekhar,
ping for this patch - it's been stuck on the list since November. I
suppose it got lost in your queue.
Thanks,
Bartosz
^ permalink raw reply
* [PATCH v2 1/2] mtd: ifc: Update dependency of IFC for LS1021A
From: Boris Brezillon @ 2017-01-03 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483411266-45875-1-git-send-email-b18965@freescale.com>
Hi Alison,
The subject prefix should be "memory: " and not "mtd: ifc: ".
Looks good otherwise.
No need to resend, I can fix that when applying.
Regards,
Boris
On Tue, 3 Jan 2017 10:41:05 +0800
Alison Wang <b18965@freescale.com> wrote:
> As Freescale/NXP IFC controller is available on LS1021A, the dependency
> for LS1021A is added.
>
> Signed-off-by: Alison Wang <alison.wang@nxp.com>
> ---
> Changes in v2:
> - New patch
>
> drivers/memory/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index ec80e35..fff8345 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -115,7 +115,7 @@ config FSL_CORENET_CF
>
> config FSL_IFC
> bool
> - depends on FSL_SOC || ARCH_LAYERSCAPE
> + depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
>
> config JZ4780_NEMC
> bool "Ingenic JZ4780 SoC NEMC driver"
^ permalink raw reply
* [PATCH v6 0/5] davinci: VPIF: add DT support
From: Laurent Pinchart @ 2017-01-03 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4a03b56e-1e01-8b2c-c2a1-1b72d30f103a@ti.com>
Hi Sekhar,
On Tuesday 03 Jan 2017 14:33:00 Sekhar Nori wrote:
> On Friday 16 December 2016 03:17 PM, Hans Verkuil wrote:
> > On 07/12/16 19:30, Kevin Hilman wrote:
> >> Prepare the groundwork for adding DT support for davinci VPIF drivers.
> >> This series does some fixups/cleanups and then adds the DT binding and
> >> DT compatible string matching for DT probing.
> >>
> >> The controversial part from previous versions around async subdev
> >> parsing, and specifically hard-coding the input/output routing of
> >> subdevs, has been left out of this series. That part can be done as a
> >> follow-on step after agreement has been reached on the path forward.
> >> With this version, platforms can still use the VPIF capture/display
> >> drivers, but must provide platform_data for the subdevs and subdev
> >> routing.
> >>
> >> Tested video capture to memory on da850-lcdk board using composite
> >> input.
> >
> > Other than the comment for the first patch this series looks good.
> >
> > So once that's addressed I'll queue it up for 4.11.
>
> Can you provide an immutable commit (as it will reach v4.11) with with
> this series applied? I have some platform changes to queue for v4.11
> that depend on the driver updates.
I don't think that's possible, given that Mauro rewrites all patches when
handling pull requests to prepend [media] to the subject line and to add his
SoB. Only Mauro can thus provide a stable branch, Hans can't.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] mtd: nand: lpc32xx: fix invalid error handling of a requested irq
From: Boris Brezillon @ 2017-01-03 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205014710.2015-1-vz@mleia.com>
Hi Vladimir
On Mon, 5 Dec 2016 03:47:10 +0200
Vladimir Zapolskiy <vz@mleia.com> wrote:
> Semantics of NR_IRQS is different on machines with SPARSE_IRQ option
> disabled or enabled, in the latter case IRQs are allocated starting
> at least from the value specified by NR_IRQS and going upwards, so
> the check of (irq >= NR_IRQ) to decide about an error code returned by
> platform_get_irq() is completely invalid, don't attempt to overrule
> irq subsystem in the driver.
>
> The change fixes LPC32xx NAND MLC driver initialization on boot.
Do you need to backport this fix to stable releases? If that's the
case, I'll add the Cc: stable tag when applying.
Thanks,
Boris
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> ---
> drivers/mtd/nand/lpc32xx_mlc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/lpc32xx_mlc.c b/drivers/mtd/nand/lpc32xx_mlc.c
> index 8523881..bc6e49a 100644
> --- a/drivers/mtd/nand/lpc32xx_mlc.c
> +++ b/drivers/mtd/nand/lpc32xx_mlc.c
> @@ -776,7 +776,7 @@ static int lpc32xx_nand_probe(struct platform_device *pdev)
> init_completion(&host->comp_controller);
>
> host->irq = platform_get_irq(pdev, 0);
> - if ((host->irq < 0) || (host->irq >= NR_IRQS)) {
> + if (host->irq < 0) {
> dev_err(&pdev->dev, "failed to get platform irq\n");
> res = -EINVAL;
> goto err_exit3;
^ permalink raw reply
* [PATCH 1/4] mmc: mediatek: Fix CMD6 timeout issue
From: Yong Mao @ 2017-01-03 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFosQkxaFAKo0dm0TajgXqKG7XqRM1tTqR2vTsHzVrocfQ@mail.gmail.com>
On Thu, 2016-12-01 at 10:51 +0100, Ulf Hansson wrote:
> On 8 November 2016 at 07:08, Yong Mao <yong.mao@mediatek.com> wrote:
> > From: yong mao <yong.mao@mediatek.com>
> >
> > When initializing EMMC, after switch to HS400,
> > it will issue CMD6 to change ext_csd, if first CMD6 got CRC
> > error, the repeat CMD6 may get timeout, that's
> > because SDCBSY was cleared by msdc_reset_hw()
>
> Sorry for the delay!
>
> We have recently been re-working the sequence for how to deal more
> properly with CMD6 in the mmc core.
>
> The changes done so far should mostly concern switches to HS and HS
> DDR, but I think you should run a re-test to make sure you still hit
> the same problems.
>
Happy New Year!
The issue we met is not only just for CMD6, but also for other R1B CMD.
Your new changes does not cover all of these cases.
We would like to make error handle in the core layer to deal with these
issues.
I had submitted a new path ([PATCH v2] Fix CMD6 timeout issue) to you,
please help to review it.
Thanks.
> >
> > Signed-off-by: Yong Mao <yong.mao@mediatek.com>
> > Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
> > ---
> > drivers/mmc/host/mtk-sd.c | 77 ++++++++++++++++++++++++++++++---------------
> > 1 file changed, 51 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> > index 84e9afc..b29683b 100644
> > --- a/drivers/mmc/host/mtk-sd.c
> > +++ b/drivers/mmc/host/mtk-sd.c
> > @@ -826,6 +826,15 @@ static bool msdc_cmd_done(struct msdc_host *host, int events,
> > return true;
> > }
> >
> > +static int msdc_card_busy(struct mmc_host *mmc)
> > +{
> > + struct msdc_host *host = mmc_priv(mmc);
> > + u32 status = readl(host->base + MSDC_PS);
> > +
> > + /* check if data0 is low */
> > + return !(status & BIT(16));
> > +}
> > +
> > /* It is the core layer's responsibility to ensure card status
> > * is correct before issue a request. but host design do below
> > * checks recommended.
>
> Hmm. Why?
>
> I think you should rely on the mmc core to invoke the ->card_busy()
> ops instead. The core knows better when it's needed.
>
> Perhaps that may also resolve some of these issues for you!?
In my latest patch, msdc_card_busy will not be used in mtk-sd.c
directly. It only can be invoked by ->card_busy() in the mmc core.
>
> > @@ -835,10 +844,20 @@ static inline bool msdc_cmd_is_ready(struct msdc_host *host,
> > {
> > /* The max busy time we can endure is 20ms */
> > unsigned long tmo = jiffies + msecs_to_jiffies(20);
> > + u32 count = 0;
> > +
> > + if (in_interrupt()) {
> > + while ((readl(host->base + SDC_STS) & SDC_STS_CMDBUSY) &&
> > + (count < 1000)) {
> > + udelay(1);
> > + count++;
>
> This seems like a bad idea, "busy-wait" in irq context is never a good idea.
Thanks. The modification here is not for the current issue.
I will submit a new patch to discuss with you.
> > + }
> > + } else {
> > + while ((readl(host->base + SDC_STS) & SDC_STS_CMDBUSY) &&
> > + time_before(jiffies, tmo))
> > + cpu_relax();
> > + }
> >
> > - while ((readl(host->base + SDC_STS) & SDC_STS_CMDBUSY) &&
> > - time_before(jiffies, tmo))
> > - cpu_relax();
> > if (readl(host->base + SDC_STS) & SDC_STS_CMDBUSY) {
> > dev_err(host->dev, "CMD bus busy detected\n");
> > host->error |= REQ_CMD_BUSY;
> > @@ -846,17 +865,35 @@ static inline bool msdc_cmd_is_ready(struct msdc_host *host,
> > return false;
> > }
> >
> > - if (mmc_resp_type(cmd) == MMC_RSP_R1B || cmd->data) {
> > - tmo = jiffies + msecs_to_jiffies(20);
> > - /* R1B or with data, should check SDCBUSY */
> > - while ((readl(host->base + SDC_STS) & SDC_STS_SDCBUSY) &&
> > - time_before(jiffies, tmo))
> > - cpu_relax();
> > - if (readl(host->base + SDC_STS) & SDC_STS_SDCBUSY) {
> > - dev_err(host->dev, "Controller busy detected\n");
> > - host->error |= REQ_CMD_BUSY;
> > - msdc_cmd_done(host, MSDC_INT_CMDTMO, mrq, cmd);
> > - return false;
> > + if (cmd->opcode != MMC_SEND_STATUS) {
> > + count = 0;
> > + /* Consider that CMD6 crc error before card was init done,
> > + * mmc_retune() will return directly as host->card is null.
> > + * and CMD6 will retry 3 times, must ensure card is in transfer
> > + * state when retry.
> > + */
> > + tmo = jiffies + msecs_to_jiffies(60 * 1000);
> > + while (1) {
> > + if (msdc_card_busy(host->mmc)) {
> > + if (in_interrupt()) {
> > + udelay(1);
> > + count++;
> > + } else {
> > + msleep_interruptible(10);
> > + }
> > + } else {
> > + break;
> > + }
> > + /* Timeout if the device never
> > + * leaves the program state.
> > + */
> > + if (count > 1000 || time_after(jiffies, tmo)) {
> > + pr_err("%s: Card stuck in programming state! %s\n",
> > + mmc_hostname(host->mmc), __func__);
> > + host->error |= REQ_CMD_BUSY;
> > + msdc_cmd_done(host, MSDC_INT_CMDTMO, mrq, cmd);
> > + return false;
> > + }
>
> This hole new code is a hack, that shouldn't be needed in the host driver.
>
> I think we need to investigate and fix the issue in the mmc core
> layer, to make this work for your host driver. That instead of doing a
> work around in the host.
>
I had already make some modification on the mmc core to resolve these
issues in the latest patch.
> > }
> > }
> > return true;
> > @@ -1070,18 +1107,6 @@ static int msdc_ops_switch_volt(struct mmc_host *mmc, struct mmc_ios *ios)
> > return ret;
> > }
> >
> > -static int msdc_card_busy(struct mmc_host *mmc)
> > -{
> > - struct msdc_host *host = mmc_priv(mmc);
> > - u32 status = readl(host->base + MSDC_PS);
> > -
> > - /* check if any pin between dat[0:3] is low */
> > - if (((status >> 16) & 0xf) != 0xf)
> > - return 1;
> > -
> > - return 0;
> > -}
> > -
> > static void msdc_request_timeout(struct work_struct *work)
> > {
> > struct msdc_host *host = container_of(work, struct msdc_host,
> > --
> > 1.7.9.5
> >
>
> Kind regards
> Uffe
^ permalink raw reply
* [PATCH v2 1/2] mtd: ifc: Update dependency of IFC for LS1021A
From: Alison Wang @ 2017-01-03 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103100439.6e7360c6@bbrezillon>
Ok, I see. Thanks.
Best Regards,
Alison Wang
> -----Original Message-----
> From: Boris Brezillon [mailto:boris.brezillon at free-electrons.com]
> Sent: Tuesday, January 03, 2017 5:05 PM
> To: Alison Wang <b18965@freescale.com>
> Cc: marek.vasut at gmail.com; cyrille.pitchen at atmel.com; linux-
> kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> mtd at lists.infradead.org; dwmw2 at infradead.org;
> computersforpeace at gmail.com; Alison Wang <alison.wang@nxp.com>
> Subject: Re: [PATCH v2 1/2] mtd: ifc: Update dependency of IFC for
> LS1021A
>
> Hi Alison,
>
> The subject prefix should be "memory: " and not "mtd: ifc: ".
>
> Looks good otherwise.
>
> No need to resend, I can fix that when applying.
>
> Regards,
>
> Boris
>
> On Tue, 3 Jan 2017 10:41:05 +0800
> Alison Wang <b18965@freescale.com> wrote:
>
> > As Freescale/NXP IFC controller is available on LS1021A, the
> > dependency for LS1021A is added.
> >
> > Signed-off-by: Alison Wang <alison.wang@nxp.com>
> > ---
> > Changes in v2:
> > - New patch
> >
> > drivers/memory/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index
> > ec80e35..fff8345 100644
> > --- a/drivers/memory/Kconfig
> > +++ b/drivers/memory/Kconfig
> > @@ -115,7 +115,7 @@ config FSL_CORENET_CF
> >
> > config FSL_IFC
> > bool
> > - depends on FSL_SOC || ARCH_LAYERSCAPE
> > + depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
> >
> > config JZ4780_NEMC
> > bool "Ingenic JZ4780 SoC NEMC driver"
^ permalink raw reply
* [PATCH] ARM: davinci_all_defconfig: enable dumb vga-dac drm bridge
From: Sekhar Nori @ 2017-01-03 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480065182-7095-1-git-send-email-bgolaszewski@baylibre.com>
On Friday 25 November 2016 02:43 PM, Bartosz Golaszewski wrote:
> This enables the dumb-vga-dac driver by default for davinci boards.
>
> The driver is needed for tilcdc support on da850-lcdk board.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/configs/davinci_all_defconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
> index b5e978f..ab1bf18 100644
> --- a/arch/arm/configs/davinci_all_defconfig
> +++ b/arch/arm/configs/davinci_all_defconfig
> @@ -127,6 +127,8 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y
> CONFIG_REGULATOR_TPS6507X=y
> CONFIG_DRM=m
> CONFIG_DRM_TILCDC=m
> +CONFIG_DRM_BRIDGE=y
DRM_BRIDGE is a 'def_bool y'. So no need to explicitly enable it. And
actually it will get dropped with the next savedefconfig refresh anyway.
Applying this patch with this line dropped.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] drm/meson: Fix plane atomic check when no crtc for the plane
From: Neil Armstrong @ 2017-01-03 9:20 UTC (permalink / raw)
To: linux-arm-kernel
When no CRTC is associated with the plane, the meson_plane_atomic_check()
call breaks the kernel with an Oops.
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/gpu/drm/meson/meson_plane.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_plane.c b/drivers/gpu/drm/meson/meson_plane.c
index 4942ca0..7890e30 100644
--- a/drivers/gpu/drm/meson/meson_plane.c
+++ b/drivers/gpu/drm/meson/meson_plane.c
@@ -51,6 +51,9 @@ static int meson_plane_atomic_check(struct drm_plane *plane,
struct drm_crtc_state *crtc_state;
struct drm_rect clip = { 0, };
+ if (!state->crtc)
+ return 0;
+
crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
--
1.9.1
^ permalink raw reply related
* [PATCH v6 6/8] IIO: add STM32 timer trigger driver
From: Benjamin Gaignard @ 2017-01-03 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c46e6e59-b5b6-39e6-d6f4-5ca4539f746c@kernel.org>
2017-01-02 19:22 GMT+01:00 Jonathan Cameron <jic23@kernel.org>:
> On 02/01/17 08:46, Benjamin Gaignard wrote:
>> 2016-12-30 22:12 GMT+01:00 Jonathan Cameron <jic23@kernel.org>:
>>> On 09/12/16 14:15, Benjamin Gaignard wrote:
>>>> Timers IPs can be used to generate triggers for other IPs like
>>>> DAC, ADC or other timers.
>>>> Each trigger may result of timer internals signals like counter enable,
>>>> reset or edge, this configuration could be done through "master_mode"
>>>> device attribute.
>>>>
>>>> A timer device could be triggered by other timers, we use the trigger
>>>> name and is_stm32_iio_timer_trigger() function to distinguish them
>>>> and configure IP input switch.
>>>>
>>>> Timer may also decide on which event (edge, level) they could
>>>> be activated by a trigger, this configuration is done by writing in
>>>> "slave_mode" device attribute.
>>>>
>>>> Since triggers could also be used by DAC or ADC their names are defined
>>>> in include/ nux/iio/timer/stm32-timer-trigger.h so those IPs will be able
>>>> to configure themselves in valid_trigger function
>>>>
>>>> Trigger have a "sampling_frequency" attribute which allow to configure
>>>> timer sampling frequency without using PWM interface
>>>>
>>>> version 5:
>>>> - simplify tables of triggers
>>>> - only create an IIO device when needed
>>>>
>>>> version 4:
>>>> - get triggers configuration from "reg" in DT
>>>> - add tables of triggers
>>>> - sampling frequency is enable/disable when writing in trigger
>>>> sampling_frequency attribute
>>>> - no more use of interruptions
>>>>
>>>> version 3:
>>>> - change compatible to "st,stm32-timer-trigger"
>>>> - fix attributes access right
>>>> - use string instead of int for master_mode and slave_mode
>>>> - document device attributes in sysfs-bus-iio-timer-stm32
>>>>
>>>> version 2:
>>>> - keep only one compatible
>>>> - use st,input-triggers-names and st,output-triggers-names
>>>> to know which triggers are accepted and/or create by the device
>>> Firstly, sorry it has taken me so long to get back to this.
>>>
>>> I'm still not keen on this use of iio_device elements just to act as
>>> glue between triggers. I think we need to work out a more light weight
>>> way to do this. As you are only using them for validation and to provide
>>> somewhere to hang the control attibutes off, there is nothing stopping us
>>> moving that over to the iio_trigger instead which would avoid the messy
>>> duality going on here.
>>
>> I have add an iio_device because each hardware can generate multiple
>> triggers (up to 5: trgo, ch 1...4) and slave_mode attribute will impact all the
>> triggers of a device. For me it was making sense to centralize that in an
>> iio_device rather than having an attribute "shared" (from hardware
>> point of view)
>> on multiple triggers.
>> Since master_mode attribute is only used by trgo and not impact ch1...4
>> triggers I will move it to trigger instead of the iio_device.
>>
>> I also wanted to be able to connect triggers on a iio_device as I
>> could do for an
>> ADC with a command like 'echo "tim1_trgo" > iio_deviceX/trigger/current_trigger'
> This is interesting, but with a bit of refactoring I would think it would
> be possible to share some of that code thus allowing non IIO devices to
> bind to triggers. Ultimately I want to be able to bind a trigger to
> a trigger - I appreciate here the topology is more limited than that
> so some complexity comes in.
>
> My gut feeling is that representing that topology explicitly is hard
> to do in a remotely general way, but lets try it and see.
> We run into this sort of interdependency issue between different bits of
> the hardware all the time. Setting a value somewhere effects the configuration
> elsewhere - often the best plan is to just let that happen and leave it up to
> userspace to check for changes if it cares.
okay
>> If I change that to parent_trigger attribute it change this behavior
>> and I will have to
>> duplicated what is done in iio_trigger_write_current() to find and
>> validate triggers.
> I get the reasoning, but we still end up with something represented
> by an IIO device that isn't providing any channels at all. It's simply
> using some of the infrastructure. To my mind it is 'something else'
> and should be represented as such. I have no problem at all with
> you registering additional elements in /sysfs/bus/iio/ to represent
> these shared elements - we already have drivers that do that to
> provide some centralized infrastructure (e.g. the sysfs-trigger)
My hardware block are timers maybe I can add a channel type "IIO_TIMER"
and declare a channel with info_mask_separate = BIT(IIO_CHAN_INFO_SAMP_FREQ)
so I will be able to write/read sampling frequency on IIO device.
> I'm worried about the scope spread we get for an IIO device otherwise.
> They serve a well defined purpose at the moment, and that isn't what
> is happening here.
>
> So my gut feeling is we are better deliberately not representing the
> inter dependence and claiming all triggers we are creating are
> independent. That way we can have a nice generic infrastructure
> that will work in all cases (be it pushing the sanity checking to
> userspace).
>
> So each trigger has direct access to what controls it. Changing anything
> can effect other triggers in weird ways.
>
> I'm finding it hard to see anything else generalizing sufficiently
> as we'll always get cases where we can't represent the topology without
> diving into the complexity of something like the media controller
> framework.
>
> Jonathan
>>
>>> I might still be missing something though!
>>>
>>> You would only I think need 3 attributes
>>>
>>> parrent_trigger
>>> and something like your master_mode and slave_mode attributes.
>>>
>>> The parrent_trigger would need some validation etc, but if we keep it
>>> within this driver initially that won't be hard to do. Checking the device
>>> parent matches will do most of it.
>>>
>>> Jonathan
>>>>
>>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>>>> ---
>>>> .../ABI/testing/sysfs-bus-iio-timer-stm32 | 55 +++
>>>> drivers/iio/Kconfig | 2 +-
>>>> drivers/iio/Makefile | 1 +
>>>> drivers/iio/timer/Kconfig | 13 +
>>>> drivers/iio/timer/Makefile | 1 +
>>>> drivers/iio/timer/stm32-timer-trigger.c | 466 +++++++++++++++++++++
>>>> drivers/iio/trigger/Kconfig | 1 -
>>>> include/linux/iio/timer/stm32-timer-trigger.h | 62 +++
>>>> 8 files changed, 599 insertions(+), 2 deletions(-)
>>>> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>>>> create mode 100644 drivers/iio/timer/Kconfig
>>>> create mode 100644 drivers/iio/timer/Makefile
>>>> create mode 100644 drivers/iio/timer/stm32-timer-trigger.c
>>>> create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
>>>>
>>>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>>>> new file mode 100644
>>>> index 0000000..26583dd
>>>> --- /dev/null
>>>> +++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>>>> @@ -0,0 +1,55 @@
>>>> +What: /sys/bus/iio/devices/iio:deviceX/master_mode_available
>>>> +KernelVersion: 4.10
>>>> +Contact: benjamin.gaignard at st.com
>>>> +Description:
>>>> + Reading returns the list possible master modes which are:
>>>> + - "reset" : The UG bit from the TIMx_EGR register is used as trigger output (TRGO).
>>>> + - "enable" : The Counter Enable signal CNT_EN is used as trigger output.
>>>> + - "update" : The update event is selected as trigger output.
>>>> + For instance a master timer can then be used as a prescaler for a slave timer.
>>>> + - "compare_pulse" : The trigger output send a positive pulse when the CC1IF flag is to be set.
>>>> + - "OC1REF" : OC1REF signal is used as trigger output.
>>>> + - "OC2REF" : OC2REF signal is used as trigger output.
>>>> + - "OC3REF" : OC3REF signal is used as trigger output.
>>>> + - "OC4REF" : OC4REF signal is used as trigger output.
>>>> +
>>>> +What: /sys/bus/iio/devices/iio:deviceX/master_mode
>>>> +KernelVersion: 4.10
>>>> +Contact: benjamin.gaignard at st.com
>>>> +Description:
>>>> + Reading returns the current master modes.
>>>> + Writing set the master mode
>>>> +
>>>> +What: /sys/bus/iio/devices/iio:deviceX/slave_mode_available
>>>> +KernelVersion: 4.10
>>>> +Contact: benjamin.gaignard at st.com
>>>> +Description:
>>>> + Reading returns the list possible slave modes which are:
>>>> + - "disabled" : The prescaler is clocked directly by the internal clock.
>>>> + - "encoder_1" : Counter counts up/down on TI2FP1 edge depending on TI1FP2 level.
>>>> + - "encoder_2" : Counter counts up/down on TI1FP2 edge depending on TI2FP1 level.
>>>> + - "encoder_3" : Counter counts up/down on both TI1FP1 and TI2FP2 edges depending
>>>> + on the level of the other input.
>>>> + - "reset" : Rising edge of the selected trigger input reinitializes the counter
>>>> + and generates an update of the registers.
>>>> + - "gated" : The counter clock is enabled when the trigger input is high.
>>>> + The counter stops (but is not reset) as soon as the trigger becomes low.
>>>> + Both start and stop of the counter are controlled.
>>>> + - "trigger" : The counter starts at a rising edge of the trigger TRGI (but it is not
>>>> + reset). Only the start of the counter is controlled.
>>>> + - "external_clock": Rising edges of the selected trigger (TRGI) clock the counter.
>>>> +
>>>> +What: /sys/bus/iio/devices/iio:deviceX/slave_mode
>>>> +KernelVersion: 4.10
>>>> +Contact: benjamin.gaignard at st.com
>>>> +Description:
>>>> + Reading returns the current slave mode.
>>>> + Writing set the slave mode
>>>> +
>>>> +What: /sys/bus/iio/devices/triggerX/sampling_frequency
>>>> +KernelVersion: 4.10
>>>> +Contact: benjamin.gaignard at st.com
>>>> +Description:
>>>> + Reading returns the current sampling frequency.
>>>> + Writing an value different of 0 set and start sampling.
>>>> + Writing 0 stop sampling.
>>>> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
>>>> index 6743b18..2de2a80 100644
>>>> --- a/drivers/iio/Kconfig
>>>> +++ b/drivers/iio/Kconfig
>>>> @@ -90,5 +90,5 @@ source "drivers/iio/potentiometer/Kconfig"
>>>> source "drivers/iio/pressure/Kconfig"
>>>> source "drivers/iio/proximity/Kconfig"
>>>> source "drivers/iio/temperature/Kconfig"
>>>> -
>>>> +source "drivers/iio/timer/Kconfig"
>>>> endif # IIO
>>>> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
>>>> index 87e4c43..b797c08 100644
>>>> --- a/drivers/iio/Makefile
>>>> +++ b/drivers/iio/Makefile
>>>> @@ -32,4 +32,5 @@ obj-y += potentiometer/
>>>> obj-y += pressure/
>>>> obj-y += proximity/
>>>> obj-y += temperature/
>>>> +obj-y += timer/
>>>> obj-y += trigger/
>>>> diff --git a/drivers/iio/timer/Kconfig b/drivers/iio/timer/Kconfig
>>>> new file mode 100644
>>>> index 0000000..e3c21f2
>>>> --- /dev/null
>>>> +++ b/drivers/iio/timer/Kconfig
>>>> @@ -0,0 +1,13 @@
>>>> +#
>>>> +# Timers drivers
>>>> +
>>>> +menu "Timers"
>>>> +
>>>> +config IIO_STM32_TIMER_TRIGGER
>>>> + tristate "STM32 Timer Trigger"
>>>> + depends on (ARCH_STM32 && OF && MFD_STM32_TIMERS) || COMPILE_TEST
>>>> + select IIO_TRIGGERED_EVENT
>>>> + help
>>>> + Select this option to enable STM32 Timer Trigger
>>>> +
>>>> +endmenu
>>>> diff --git a/drivers/iio/timer/Makefile b/drivers/iio/timer/Makefile
>>>> new file mode 100644
>>>> index 0000000..4ad95ec9
>>>> --- /dev/null
>>>> +++ b/drivers/iio/timer/Makefile
>>>> @@ -0,0 +1 @@
>>>> +obj-$(CONFIG_IIO_STM32_TIMER_TRIGGER) += stm32-timer-trigger.o
>>>> diff --git a/drivers/iio/timer/stm32-timer-trigger.c b/drivers/iio/timer/stm32-timer-trigger.c
>>>> new file mode 100644
>>>> index 0000000..8d16e8f
>>>> --- /dev/null
>>>> +++ b/drivers/iio/timer/stm32-timer-trigger.c
>>>> @@ -0,0 +1,466 @@
>>>> +/*
>>>> + * Copyright (C) STMicroelectronics 2016
>>>> + *
>>>> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com>
>>>> + *
>>>> + * License terms: GNU General Public License (GPL), version 2
>>>> + */
>>>> +
>>>> +#include <linux/iio/iio.h>
>>>> +#include <linux/iio/sysfs.h>
>>>> +#include <linux/iio/timer/stm32-timer-trigger.h>
>>>> +#include <linux/iio/trigger.h>
>>>> +#include <linux/iio/triggered_event.h>
>>>> +#include <linux/interrupt.h>
>>>> +#include <linux/mfd/stm32-timers.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/platform_device.h>
>>>> +
>>>> +#define MAX_TRIGGERS 6
>>>> +#define MAX_VALIDS 5
>>>> +
>>>> +/* List the triggers created by each timer */
>>>> +static const void *triggers_table[][MAX_TRIGGERS] = {
>>>> + { TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4,},
>>>> + { TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4,},
>>>> + { TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4,},
>>>> + { TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4,},
>>>> + { TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4,},
>>>> + { TIM6_TRGO,},
>>>> + { TIM7_TRGO,},
>>>> + { TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4,},
>>>> + { TIM9_TRGO, TIM9_CH1, TIM9_CH2,},
>>>> + { TIM12_TRGO, TIM12_CH1, TIM12_CH2,},
>>>> +};
>>>> +
>>>> +/* List the triggers accepted by each timer */
>>>> +static const void *valids_table[][MAX_VALIDS] = {
>>>> + { TIM5_TRGO, TIM2_TRGO, TIM4_TRGO, TIM3_TRGO,},
>>>> + { TIM1_TRGO, TIM8_TRGO, TIM3_TRGO, TIM4_TRGO,},
>>>> + { TIM1_TRGO, TIM8_TRGO, TIM5_TRGO, TIM4_TRGO,},
>>>> + { TIM1_TRGO, TIM2_TRGO, TIM3_TRGO, TIM8_TRGO,},
>>>> + { TIM2_TRGO, TIM3_TRGO, TIM4_TRGO, TIM8_TRGO,},
>>>> + { }, /* timer 6 */
>>>> + { }, /* timer 7 */
>>>> + { TIM1_TRGO, TIM2_TRGO, TIM4_TRGO, TIM5_TRGO,},
>>>> + { TIM2_TRGO, TIM3_TRGO,},
>>>> + { TIM4_TRGO, TIM5_TRGO,},
>>>> +};
>>>> +
>>>> +struct stm32_timer_trigger {
>>>> + struct device *dev;
>>>> + struct regmap *regmap;
>>>> + struct clk *clk;
>>>> + u32 max_arr;
>>>> + const void *triggers;
>>>> + const void *valids;
>>>> +};
>>>> +
>>>> +static int stm32_timer_start(struct stm32_timer_trigger *priv,
>>>> + unsigned int frequency)
>>>> +{
>>>> + unsigned long long prd, div;
>>>> + int prescaler = 0;
>>>> + u32 ccer, cr1;
>>>> +
>>>> + /* Period and prescaler values depends of clock rate */
>>>> + div = (unsigned long long)clk_get_rate(priv->clk);
>>>> +
>>>> + do_div(div, frequency);
>>>> +
>>>> + prd = div;
>>>> +
>>>> + /*
>>>> + * Increase prescaler value until we get a result that fit
>>>> + * with auto reload register maximum value.
>>>> + */
>>>> + while (div > priv->max_arr) {
>>>> + prescaler++;
>>>> + div = prd;
>>>> + do_div(div, (prescaler + 1));
>>>> + }
>>>> + prd = div;
>>>> +
>>>> + if (prescaler > MAX_TIM_PSC) {
>>>> + dev_err(priv->dev, "prescaler exceeds the maximum value\n");
>>>> + return -EINVAL;
>>>> + }
>>>> +
>>>> + /* Check if nobody else use the timer */
>>>> + regmap_read(priv->regmap, TIM_CCER, &ccer);
>>>> + if (ccer & TIM_CCER_CCXE)
>>>> + return -EBUSY;
>>>> +
>>>> + regmap_read(priv->regmap, TIM_CR1, &cr1);
>>>> + if (!(cr1 & TIM_CR1_CEN))
>>>> + clk_enable(priv->clk);
>>>> +
>>>> + regmap_write(priv->regmap, TIM_PSC, prescaler);
>>>> + regmap_write(priv->regmap, TIM_ARR, prd - 1);
>>>> + regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_ARPE, TIM_CR1_ARPE);
>>>> +
>>>> + /* Force master mode to update mode */
>>>> + regmap_update_bits(priv->regmap, TIM_CR2, TIM_CR2_MMS, 0x20);
>>>> +
>>>> + /* Make sure that registers are updated */
>>>> + regmap_update_bits(priv->regmap, TIM_EGR, TIM_EGR_UG, TIM_EGR_UG);
>>>> +
>>>> + /* Enable controller */
>>>> + regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, TIM_CR1_CEN);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static void stm32_timer_stop(struct stm32_timer_trigger *priv)
>>>> +{
>>>> + u32 ccer, cr1;
>>>> +
>>>> + regmap_read(priv->regmap, TIM_CCER, &ccer);
>>>> + if (ccer & TIM_CCER_CCXE)
>>>> + return;
>>>> +
>>>> + regmap_read(priv->regmap, TIM_CR1, &cr1);
>>>> + if (cr1 & TIM_CR1_CEN)
>>>> + clk_disable(priv->clk);
>>>> +
>>>> + /* Stop timer */
>>>> + regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, 0);
>>>> + regmap_write(priv->regmap, TIM_PSC, 0);
>>>> + regmap_write(priv->regmap, TIM_ARR, 0);
>>>> +}
>>>> +
>>>> +static ssize_t stm32_tt_store_frequency(struct device *dev,
>>>> + struct device_attribute *attr,
>>>> + const char *buf, size_t len)
>>>> +{
>>>> + struct iio_trigger *trig = to_iio_trigger(dev);
>>>> + struct stm32_timer_trigger *priv = iio_trigger_get_drvdata(trig);
>>>> + unsigned int freq;
>>>> + int ret;
>>>> +
>>>> + ret = kstrtouint(buf, 10, &freq);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + if (freq == 0) {
>>>> + stm32_timer_stop(priv);
>>>> + } else {
>>>> + ret = stm32_timer_start(priv, freq);
>>>> + if (ret)
>>>> + return ret;
>>>> + }
>>>> +
>>>> + return len;
>>>> +}
>>>> +
>>>> +static ssize_t stm32_tt_read_frequency(struct device *dev,
>>>> + struct device_attribute *attr, char *buf)
>>>> +{
>>>> + struct iio_trigger *trig = to_iio_trigger(dev);
>>>> + struct stm32_timer_trigger *priv = iio_trigger_get_drvdata(trig);
>>>> + u32 psc, arr, cr1;
>>>> + unsigned long long freq = 0;
>>>> +
>>>> + regmap_read(priv->regmap, TIM_CR1, &cr1);
>>>> + regmap_read(priv->regmap, TIM_PSC, &psc);
>>>> + regmap_read(priv->regmap, TIM_ARR, &arr);
>>>> +
>>>> + if (psc && arr && (cr1 & TIM_CR1_CEN)) {
>>>> + freq = (unsigned long long)clk_get_rate(priv->clk);
>>>> + do_div(freq, psc);
>>>> + do_div(freq, arr);
>>>> + }
>>>> +
>>>> + return sprintf(buf, "%d\n", (unsigned int)freq);
>>>> +}
>>>> +
>>>> +static IIO_DEV_ATTR_SAMP_FREQ(0660,
>>>> + stm32_tt_read_frequency,
>>>> + stm32_tt_store_frequency);
>>>> +
>>>> +static struct attribute *stm32_trigger_attrs[] = {
>>>> + &iio_dev_attr_sampling_frequency.dev_attr.attr,
>>>> + NULL,
>>>> +};
>>>> +
>>>> +static const struct attribute_group stm32_trigger_attr_group = {
>>>> + .attrs = stm32_trigger_attrs,
>>>> +};
>>>> +
>>>> +static const struct attribute_group *stm32_trigger_attr_groups[] = {
>>>> + &stm32_trigger_attr_group,
>>>> + NULL,
>>>> +};
>>>> +
>>>> +static char *master_mode_table[] = {
>>>> + "reset",
>>>> + "enable",
>>>> + "update",
>>>> + "compare_pulse",
>>>> + "OC1REF",
>>>> + "OC2REF",
>>>> + "OC3REF",
>>>> + "OC4REF"
>>>> +};
>>>> +
>>>> +static ssize_t stm32_tt_show_master_mode(struct device *dev,
>>>> + struct device_attribute *attr,
>>>> + char *buf)
>>>> +{
>>>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>> + u32 cr2;
>>>> +
>>>> + regmap_read(priv->regmap, TIM_CR2, &cr2);
>>>> + cr2 = (cr2 & TIM_CR2_MMS) >> TIM_CR2_MMS_SHIFT;
>>>> +
>>>> + return snprintf(buf, PAGE_SIZE, "%s\n", master_mode_table[cr2]);
>>>> +}
>>>> +
>>>> +static ssize_t stm32_tt_store_master_mode(struct device *dev,
>>>> + struct device_attribute *attr,
>>>> + const char *buf, size_t len)
>>>> +{
>>>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>> + int i;
>>>> +
>>>> + for (i = 0; i < ARRAY_SIZE(master_mode_table); i++) {
>>>> + if (!strncmp(master_mode_table[i], buf,
>>>> + strlen(master_mode_table[i]))) {
>>>> + regmap_update_bits(priv->regmap, TIM_CR2,
>>>> + TIM_CR2_MMS, i << TIM_CR2_MMS_SHIFT);
>>>> + return len;
>>>> + }
>>>> + }
>>>> +
>>>> + return -EINVAL;
>>>> +}
>>>> +
>>>> +static IIO_CONST_ATTR(master_mode_available,
>>>> + "reset enable update compare_pulse OC1REF OC2REF OC3REF OC4REF");
>>>> +
>>>> +static IIO_DEVICE_ATTR(master_mode, 0660,
>>>> + stm32_tt_show_master_mode,
>>>> + stm32_tt_store_master_mode,
>>>> + 0);
>>>> +
>>>> +static char *slave_mode_table[] = {
>>>> + "disabled",
>>>> + "encoder_1",
>>>> + "encoder_2",
>>>> + "encoder_3",
>>>> + "reset",
>>>> + "gated",
>>>> + "trigger",
>>>> + "external_clock",
>>>> +};
>>>> +
>>>> +static ssize_t stm32_tt_show_slave_mode(struct device *dev,
>>>> + struct device_attribute *attr,
>>>> + char *buf)
>>>> +{
>>>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>> + u32 smcr;
>>>> +
>>>> + regmap_read(priv->regmap, TIM_SMCR, &smcr);
>>>> + smcr &= TIM_SMCR_SMS;
>>>> +
>>>> + return snprintf(buf, PAGE_SIZE, "%s\n", slave_mode_table[smcr]);
>>>> +}
>>>> +
>>>> +static ssize_t stm32_tt_store_slave_mode(struct device *dev,
>>>> + struct device_attribute *attr,
>>>> + const char *buf, size_t len)
>>>> +{
>>>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>> + int i;
>>>> +
>>>> + for (i = 0; i < ARRAY_SIZE(slave_mode_table); i++) {
>>>> + if (!strncmp(slave_mode_table[i], buf,
>>>> + strlen(slave_mode_table[i]))) {
>>>> + regmap_update_bits(priv->regmap,
>>>> + TIM_SMCR, TIM_SMCR_SMS, i);
>>>> + return len;
>>>> + }
>>>> + }
>>>> +
>>>> + return -EINVAL;
>>>> +}
>>>> +
>>>> +static IIO_CONST_ATTR(slave_mode_available,
>>>> +"disabled encoder_1 encoder_2 encoder_3 reset gated trigger external_clock");
>>>> +
>>>> +static IIO_DEVICE_ATTR(slave_mode, 0660,
>>>> + stm32_tt_show_slave_mode,
>>>> + stm32_tt_store_slave_mode,
>>>> + 0);
>>>> +
>>>> +static struct attribute *stm32_timer_attrs[] = {
>>>> + &iio_dev_attr_master_mode.dev_attr.attr,
>>>> + &iio_const_attr_master_mode_available.dev_attr.attr,
>>>> + &iio_dev_attr_slave_mode.dev_attr.attr,
>>>> + &iio_const_attr_slave_mode_available.dev_attr.attr,
>>>> + NULL,
>>>> +};
>>>> +
>>>> +static const struct attribute_group stm32_timer_attr_group = {
>>>> + .attrs = stm32_timer_attrs,
>>>> +};
>>>> +
>>>> +static const struct iio_trigger_ops timer_trigger_ops = {
>>>> + .owner = THIS_MODULE,
>>>> +};
>>>> +
>>>> +static int stm32_setup_iio_triggers(struct stm32_timer_trigger *priv)
>>>> +{
>>>> + int ret;
>>>> + const char * const *cur = priv->triggers;
>>>> +
>>>> + while (cur && *cur) {
>>>> + struct iio_trigger *trig;
>>>> +
>>>> + trig = devm_iio_trigger_alloc(priv->dev, "%s", *cur);
>>>> + if (!trig)
>>>> + return -ENOMEM;
>>>> +
>>>> + trig->dev.parent = priv->dev->parent;
>>>> + trig->ops = &timer_trigger_ops;
>>>> + trig->dev.groups = stm32_trigger_attr_groups;
>>>> + iio_trigger_set_drvdata(trig, priv);
>>>> +
>>>> + ret = devm_iio_trigger_register(priv->dev, trig);
>>>> + if (ret)
>>>> + return ret;
>>>> + cur++;
>>>> + }
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +/**
>>>> + * is_stm32_timer_trigger
>>>> + * @trig: trigger to be checked
>>>> + *
>>>> + * return true if the trigger is a valid stm32 iio timer trigger
>>>> + * either return false
>>>> + */
>>>> +bool is_stm32_timer_trigger(struct iio_trigger *trig)
>>>> +{
>>>> + return (trig->ops == &timer_trigger_ops);
>>>> +}
>>>> +EXPORT_SYMBOL(is_stm32_timer_trigger);
>>>> +
>>>> +static int stm32_validate_trigger(struct iio_dev *indio_dev,
>>>> + struct iio_trigger *trig)
>>>> +{
>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>> + const char * const *cur = priv->valids;
>>>> + unsigned int i = 0;
>>>> +
>>>> + if (!is_stm32_timer_trigger(trig))
>>>> + return -EINVAL;
>>>> +
>>>> + while (cur && *cur) {
>>>> + if (!strncmp(trig->name, *cur, strlen(trig->name))) {
>>>> + regmap_update_bits(priv->regmap,
>>>> + TIM_SMCR, TIM_SMCR_TS,
>>>> + i << TIM_SMCR_TS_SHIFT);
>>>> + return 0;
>>>> + }
>>>> + cur++;
>>>> + i++;
>>>> + }
>>>> +
>>>> + return -EINVAL;
>>>> +}
>>>> +
>>>> +static const struct iio_info stm32_trigger_info = {
>>>> + .driver_module = THIS_MODULE,
>>>> + .validate_trigger = stm32_validate_trigger,
>>>> + .attrs = &stm32_timer_attr_group,
>>>> +};
>>>> +
>>>> +static struct stm32_timer_trigger *stm32_setup_iio_device(struct device *dev)
>>>> +{
>>>> + struct iio_dev *indio_dev;
>>>> + int ret;
>>>> +
>>>> + indio_dev = devm_iio_device_alloc(dev,
>>>> + sizeof(struct stm32_timer_trigger));
>>>> + if (!indio_dev)
>>>> + return NULL;
>>>> +
>>>> + indio_dev->name = dev_name(dev);
>>>> + indio_dev->dev.parent = dev;
>>>> + indio_dev->info = &stm32_trigger_info;
>>>> + indio_dev->modes = INDIO_EVENT_TRIGGERED;
>>>> + indio_dev->num_channels = 0;
>>>> + indio_dev->dev.of_node = dev->of_node;
>>>> +
>>>> + ret = devm_iio_device_register(dev, indio_dev);
>>>> + if (ret)
>>>> + return NULL;
>>>> +
>>>> + return iio_priv(indio_dev);
>>>> +}
>>>> +
>>>> +static int stm32_timer_trigger_probe(struct platform_device *pdev)
>>>> +{
>>>> + struct device *dev = &pdev->dev;
>>>> + struct stm32_timer_trigger *priv;
>>>> + struct stm32_timers *ddata = dev_get_drvdata(pdev->dev.parent);
>>>> + unsigned int index;
>>>> + int ret;
>>>> +
>>>> + if (of_property_read_u32(dev->of_node, "reg", &index))
>>>> + return -EINVAL;
>>>> +
>>>> + if (index >= ARRAY_SIZE(triggers_table))
>>>> + return -EINVAL;
>>>> +
>>>> + /* Create an IIO device only if we have triggers to be validated */
>>>> + if (*valids_table[index])
>>>> + priv = stm32_setup_iio_device(dev);
>>>
>>> I still don't like this. Really feels like we shouldn't be creating an
>>> iio device with all the bagage that carries just to allow us to do the
>>> trigger trees. We ought to have a much more light weight solution for this
>>> functionality - we aren't typically even using the interrupt tree stuff
>>> that the triggers for devices are all really about.
>>>
>>> A simpler approach of allowing each trigger the option of a parent seems like
>>> it would be cleaner. Could be done entirely within this driver in the first
>>> instance. Basically it would just look like your master and slave attributes
>>> but have those under triggerX not iio:deviceX.
>>>
>>> We can work out how to make it more generic later - including perhaps the
>>> option to trigger from triggers outside this driver, using some parallel
>>> infrastructure to the device triggering.
>>>
>>>
>>>> + else
>>>> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>>>> +
>>>> + if (!priv)
>>>> + return -ENOMEM;
>>>> +
>>>> + priv->dev = dev;
>>>> + priv->regmap = ddata->regmap;
>>>> + priv->clk = ddata->clk;
>>>> + priv->max_arr = ddata->max_arr;
>>>> + priv->triggers = triggers_table[index];
>>>> + priv->valids = valids_table[index];
>>>> +
>>>> + ret = stm32_setup_iio_triggers(priv);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + platform_set_drvdata(pdev, priv);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static const struct of_device_id stm32_trig_of_match[] = {
>>>> + { .compatible = "st,stm32-timer-trigger", },
>>>> + { /* end node */ },
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, stm32_trig_of_match);
>>>> +
>>>> +static struct platform_driver stm32_timer_trigger_driver = {
>>>> + .probe = stm32_timer_trigger_probe,
>>>> + .driver = {
>>>> + .name = "stm32-timer-trigger",
>>>> + .of_match_table = stm32_trig_of_match,
>>>> + },
>>>> +};
>>>> +module_platform_driver(stm32_timer_trigger_driver);
>>>> +
>>>> +MODULE_ALIAS("platform: stm32-timer-trigger");
>>>> +MODULE_DESCRIPTION("STMicroelectronics STM32 Timer Trigger driver");
>>>> +MODULE_LICENSE("GPL v2");
>>>> diff --git a/drivers/iio/trigger/Kconfig b/drivers/iio/trigger/Kconfig
>>>> index 809b2e7..f2af4fe 100644
>>>> --- a/drivers/iio/trigger/Kconfig
>>>> +++ b/drivers/iio/trigger/Kconfig
>>>> @@ -46,5 +46,4 @@ config IIO_SYSFS_TRIGGER
>>>>
>>>> To compile this driver as a module, choose M here: the
>>>> module will be called iio-trig-sysfs.
>>>> -
>>> Clean this up.
>>
>> ok
>>
>>>> endmenu
>>>> diff --git a/include/linux/iio/timer/stm32-timer-trigger.h b/include/linux/iio/timer/stm32-timer-trigger.h
>>>> new file mode 100644
>>>> index 0000000..55535ae
>>>> --- /dev/null
>>>> +++ b/include/linux/iio/timer/stm32-timer-trigger.h
>>>> @@ -0,0 +1,62 @@
>>>> +/*
>>>> + * Copyright (C) STMicroelectronics 2016
>>>> + *
>>>> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com>
>>>> + *
>>>> + * License terms: GNU General Public License (GPL), version 2
>>>> + */
>>>> +
>>>> +#ifndef _STM32_TIMER_TRIGGER_H_
>>>> +#define _STM32_TIMER_TRIGGER_H_
>>>> +
>>>> +#define TIM1_TRGO "tim1_trgo"
>>>> +#define TIM1_CH1 "tim1_ch1"
>>>> +#define TIM1_CH2 "tim1_ch2"
>>>> +#define TIM1_CH3 "tim1_ch3"
>>>> +#define TIM1_CH4 "tim1_ch4"
>>>> +
>>>> +#define TIM2_TRGO "tim2_trgo"
>>>> +#define TIM2_CH1 "tim2_ch1"
>>>> +#define TIM2_CH2 "tim2_ch2"
>>>> +#define TIM2_CH3 "tim2_ch3"
>>>> +#define TIM2_CH4 "tim2_ch4"
>>>> +
>>>> +#define TIM3_TRGO "tim3_trgo"
>>>> +#define TIM3_CH1 "tim3_ch1"
>>>> +#define TIM3_CH2 "tim3_ch2"
>>>> +#define TIM3_CH3 "tim3_ch3"
>>>> +#define TIM3_CH4 "tim3_ch4"
>>>> +
>>>> +#define TIM4_TRGO "tim4_trgo"
>>>> +#define TIM4_CH1 "tim4_ch1"
>>>> +#define TIM4_CH2 "tim4_ch2"
>>>> +#define TIM4_CH3 "tim4_ch3"
>>>> +#define TIM4_CH4 "tim4_ch4"
>>>> +
>>>> +#define TIM5_TRGO "tim5_trgo"
>>>> +#define TIM5_CH1 "tim5_ch1"
>>>> +#define TIM5_CH2 "tim5_ch2"
>>>> +#define TIM5_CH3 "tim5_ch3"
>>>> +#define TIM5_CH4 "tim5_ch4"
>>>> +
>>>> +#define TIM6_TRGO "tim6_trgo"
>>>> +
>>>> +#define TIM7_TRGO "tim7_trgo"
>>>> +
>>>> +#define TIM8_TRGO "tim8_trgo"
>>>> +#define TIM8_CH1 "tim8_ch1"
>>>> +#define TIM8_CH2 "tim8_ch2"
>>>> +#define TIM8_CH3 "tim8_ch3"
>>>> +#define TIM8_CH4 "tim8_ch4"
>>>> +
>>>> +#define TIM9_TRGO "tim9_trgo"
>>>> +#define TIM9_CH1 "tim9_ch1"
>>>> +#define TIM9_CH2 "tim9_ch2"
>>>> +
>>>> +#define TIM12_TRGO "tim12_trgo"
>>>> +#define TIM12_CH1 "tim12_ch1"
>>>> +#define TIM12_CH2 "tim12_ch2"
>>>> +
>>>> +bool is_stm32_timer_trigger(struct iio_trigger *trig);
>>>> +
>>>> +#endif
>>>>
>>>
>>
>>
>>
>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] serial: mxs-auart: support CMSPAR termios cflag
From: Stefan Wahren @ 2017-01-03 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212072101.9909-1-weo@reccoware.de>
Hi Wolfgang,
> If CMSPAR is set in the c_cflag of termios, "stick" parity is enabled.
you can have my
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
for this version 2 from 12.12.2016.
But in order to increase the chance that your patch get merged, please
resend your patch:
* with the correct version in your subject line
* not during the merge window
* with my Acked-by
* with a copy to linux-serial at vger.kernel.org
Thanks
Stefan
^ permalink raw reply
* [PATCH] ARM: dts: r8a7791: link DU to VSPDs
From: Laurent Pinchart @ 2017-01-03 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1922293.x1RvWWSErN@wasted.cogentembedded.com>
Hi Sergei,
On Thursday 15 Dec 2016 01:07:52 Sergei Shtylyov wrote:
> Add the "vsps" property to the DU device node in order to link this node to
> the VSPD nodes.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
I'd like to first address the issues I've pointed out on the driver side of
this change.
> ---
> This patch is against the 'renesas-devel-20161212-v4.9' of Simon Horman's
> 'renesas.git' repo. It's only meaningful if the DU driver patch I've just
> posted is applied.
>
> arch/arm/boot/dts/r8a7791.dtsi | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
> ===================================================================
> --- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
> +++ renesas/arch/arm/boot/dts/r8a7791.dtsi
> @@ -989,7 +989,7 @@
> power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
> };
>
> - vsp1 at fe930000 {
> + vspd0: vsp1 at fe930000 {
> compatible = "renesas,vsp1";
> reg = <0 0xfe930000 0 0x8000>;
> interrupts = <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>;
> @@ -997,7 +997,7 @@
> power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
> };
>
> - vsp1 at fe938000 {
> + vspd1: vsp1 at fe938000 {
> compatible = "renesas,vsp1";
> reg = <0 0xfe938000 0 0x8000>;
> interrupts = <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1016,6 +1016,7 @@
> <&mstp7_clks R8A7791_CLK_DU1>,
> <&mstp7_clks R8A7791_CLK_LVDS0>;
> clock-names = "du.0", "du.1", "lvds.0";
> + vsps = <&vspd0 &vspd1>;
> status = "disabled";
>
> ports {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] ARM: dts: r8a7794: link DU to VSPD
From: Laurent Pinchart @ 2017-01-03 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1524349.7vYNCWaVjE@wasted.cogentembedded.com>
Hi Sergei,
On Thursday 29 Dec 2016 00:35:07 Sergei Shtylyov wrote:
> Add the "vsps" property to the DU device node in order to link this node to
> the (single) VSPD node.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
I'd like to first address the issues I've pointed out on the driver side of
this change.
> ---
> This patch is against the 'renesas-devel-20161220-v4.9' of Simon Horman's
> 'renesas.git' repo. It's only meaningful if the "Enable R8A7794 DU VSPD
> compositor" DU driver patches are applied...
>
> arch/arm/boot/dts/r8a7794.dtsi | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
> ===================================================================
> --- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
> +++ renesas/arch/arm/boot/dts/r8a7794.dtsi
> @@ -908,7 +908,7 @@
> power-domains = <&sysc R8A7794_PD_ALWAYS_ON>;
> };
>
> - vsp1 at fe930000 {
> + vspd0: vsp1 at fe930000 {
> compatible = "renesas,vsp1";
> reg = <0 0xfe930000 0 0x8000>;
> interrupts = <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>;
> @@ -925,6 +925,7 @@
> clocks = <&mstp7_clks R8A7794_CLK_DU0>,
> <&mstp7_clks R8A7794_CLK_DU0>;
> clock-names = "du.0", "du.1";
> + vsps = <&vspd0>;
> status = "disabled";
>
> ports {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [RFC PATCH] sched: Remove set_task_state()
From: Peter Zijlstra @ 2017-01-03 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483121873-21528-1-git-send-email-dave@stgolabs.net>
On Fri, Dec 30, 2016 at 10:17:53AM -0800, Davidlohr Bueso wrote:
> - set_task_state(current, TASK_RUNNING);
> + set_current_state(TASK_RUNNING);
Obviously good.
> - set_task_state(tsk, TASK_UNINTERRUPTIBLE);
> + set_current_state(TASK_UNINTERRUPTIBLE);
Not so much..
So while I fully support this move, should we not first clean up the
code and also remove all the local 'tsk = current' variables such that
all replacements end up being obvious?
In any case, would be good to hear from arm64 folks.
^ permalink raw reply
* [PATCH 15/20] ARM/hw_breakpoint: Convert to hotplug state machine
From: Mark Rutland @ 2017-01-03 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaxAPSU-XPQrgVRoBecAD1ZpVVP4qPe59af-yy11WqBQw@mail.gmail.com>
Hi,
On Mon, Jan 02, 2017 at 09:15:29PM +0100, Linus Walleij wrote:
> On Mon, Jan 2, 2017 at 4:00 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Mon, Jan 02, 2017 at 03:34:32PM +0100, Linus Walleij wrote:
> >> in the first line of arch_hw_breakpoint_init() in
> >> arch/arm/kernel/hw_breakpoint.c
> >>
> >> I suspect that is not an accepable solution ...
> >>
> >> It hangs at PC is at write_wb_reg+0x20c/0x330
> >> Which is c03101dc, and looks like this in objdump -d:
> >>
> >> c031020c: ee001eba mcr 14, 0, r1, cr0, cr10, {5}
> >> c0310210: eaffffb3 b c03100e4 <write_wb_reg+0x114>
> >
> > ... and this is several instructions after the address you mention above.
> > Presumably c03101dc is accessing a higher numbered register?
>
> Ah sorry. It looks like this:
>
> c03101dc: ee001ed0 mcr 14, 0, r1, cr0, cr0, {6}
> c03101e0: eaffffbf b c03100e4 <write_wb_reg+0x114>
> c03101e4: ee001ebf mcr 14, 0, r1, cr0, cr15, {5}
> c03101e8: eaffffbd b c03100e4 <write_wb_reg+0x114>
> c03101ec: ee001ebe mcr 14, 0, r1, cr0, cr14, {5}
> c03101f0: eaffffbb b c03100e4 <write_wb_reg+0x114>
> c03101f4: ee001ebd mcr 14, 0, r1, cr0, cr13, {5}
> c03101f8: eaffffb9 b c03100e4 <write_wb_reg+0x114>
FWIW, I was tracking an issue in this area before the holiday.
It looked like DBGPRSR.SPD is set unexpectedly over the default idle
path (i.e. WFI), causing the (otherwise valid) register accesses above
to be handled as undefined.
I haven't looked at the patch in detail, but I guess that it allows idle
to occur between reset_ctrl_regs() and arch_hw_breakpoint_init().
Reading DBGPRSR should clear SPD; but I'm not sure if other debug state
is affected.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v6 05/14] ACPI: platform-msi: retrieve dev id from IORT
From: Tomasz Nowicki @ 2017-01-03 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13cb0c87-e1c0-c4d6-4793-a3edd20944dc@semihalf.com>
On 03.01.2017 09:43, Tomasz Nowicki wrote:
> On 02.01.2017 14:31, Hanjun Guo wrote:
>> For devices connecting to ITS, it needs dev id to identify
>> itself, and this dev id is represented in the IORT table in
>> named componant node [1] for platform devices, so in this
>> patch we will scan the IORT to retrieve device's dev id.
>>
>> Introduce iort_pmsi_get_dev_id() with pointer dev passed
>> in for that purpose.
>>
>> [1]:
>> https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Tested-by: Sinan Kaya <okaya@codeaurora.org>
>> Tested-by: Majun <majun258@huawei.com>
>> Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Cc: Tomasz Nowicki <tn@semihalf.com>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> ---
>> drivers/acpi/arm64/iort.c | 26
>> ++++++++++++++++++++++++++
>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 4 +++-
>> include/linux/acpi_iort.h | 8 ++++++++
>> 3 files changed, 37 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index 174e983..ab7bae7 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -444,6 +444,32 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
>> }
>>
>> /**
>> + * iort_pmsi_get_dev_id() - Get the device id for a device
>> + * @dev: The device for which the mapping is to be done.
>> + * @dev_id: The device ID found.
>> + *
>> + * Returns: 0 for successful find a dev id, errors otherwise
>> + */
>> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
>> +{
>> + struct acpi_iort_node *node;
>> +
>> + if (!iort_table)
>> + return -ENODEV;
>> +
>> + node = iort_find_dev_node(dev);
>> + if (!node) {
>> + dev_err(dev, "can't find related IORT node\n");
>> + return -ENODEV;
>> + }
>> +
>> + if(!iort_node_get_id(node, dev_id, IORT_MSI_TYPE, 0))
>> + return -ENODEV;
>> +
>> + return 0;
>> +}
>> +
>> +/**
> Giving that you are extending this to NC->
> SMMU->ITS case in later patch, we can use existing helpers from iort.c,
> like that:
>
> +/**
> + * iort_pmsi_get_dev_id() - Get the device id for a device
> + * @dev: The device for which the mapping is to be done.
> + * @dev_id: The device ID found.
> + *
> + * Returns: 0 for successful find a dev id, errors otherwise
> + */
> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> +{
> + struct acpi_iort_node *node;
> +
> + node = iort_find_dev_node(dev);
> + if (!node)
> + return -ENODEV;
> +
> + if (!iort_node_map_rid(node, 0, dev_id, IORT_MSI_TYPE))
> + return -ENODEV;
> +
> + return 0;
> +}
>
> Correct me if I am wrong.
>
"0" as rid_in for iort_node_map_rid() isn't good idea, sorry...
Tomasz
^ permalink raw reply
* [PATCH v2 1/4] pinctrl: samsung: Fix the width of PINCFG_TYPE_DRV bitfields for Exynos5433
From: Andi Shyti @ 2017-01-03 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161230150932.q7kadv4ouhdrkqea@kozik-lap>
Hi Linus and Krzysztof,
> > > From: Chanwoo Choi <cw00.choi@samsung.com>
> > >
> > > This patch fixes the wrong width of PINCFG_TYPE_DRV bitfields for Exynos5433
> > > because PINCFG_TYPE_DRV of Exynos5433 has 4bit fields in the *_DRV
> > > registers. Usually, other Exynos have 2bit field for PINCFG_TYPE_DRV.
> > >
> > > Fixes: 3c5ecc9ed353 ("pinctrl: exynos: Add support for Exynos5433")
> > > Cc: stable at vger.kernel.org
> > > Cc: Tomasz Figa <tomasz.figa@gmail.com>
> > > Cc: Krzysztof Kozlowski <krzk@kernel.org>
> > > Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> > > Cc: Linus Walleij <linus.walleij@linaro.org>
> > > Cc: Kukjin Kim <kgene@kernel.org>
> > > Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> > > Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> >
> > Nominally I think you should sign this off too Andi, as you are in the delivery
> > path.
> >
> > Patch applied for fixes.
>
> That has to be signed by Andi... otherwise the chain is broken (and
> there could be changes added inside).
yes, sorry about this. If Linus wants and it's not too late, he
can add my signed off at the bottom.
Thanks,
Andi
^ permalink raw reply
* [PATCH 1/2] ARM: hyp-stub: improve ABI
From: Christoffer Dall @ 2017-01-03 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215185717.GM14217@n2100.armlinux.org.uk>
Hi Russell,
On Thu, Dec 15, 2016 at 06:57:18PM +0000, Russell King - ARM Linux wrote:
> On Thu, Dec 15, 2016 at 03:37:15PM +0000, Marc Zyngier wrote:
> > On 15/12/16 15:15, Russell King - ARM Linux wrote:
> > > On Thu, Dec 15, 2016 at 11:46:41AM +0000, Marc Zyngier wrote:
> > >> On 15/12/16 11:35, Russell King - ARM Linux wrote:
> > >>> On Thu, Dec 15, 2016 at 11:18:48AM +0000, Marc Zyngier wrote:
> > >>>> On 14/12/16 10:46, Russell King wrote:
> > >>>>> @@ -231,10 +244,14 @@ ENDPROC(__hyp_stub_do_trap)
> > >>>>> * initialisation entry point.
> > >>>>> */
> > >>>>> ENTRY(__hyp_get_vectors)
> > >>>>> - mov r0, #-1
> > >>>>> + mov r0, #HVC_GET_VECTORS
> > >>>>
> > >>>> This breaks the KVM implementation of __hyp_get_vectors, easily fixed
> > >>>> with the following patchlet:
> > >>>
> > >>> Right, so what Mark said is wrong:
> > >>>
> > >>> "The hyp-stub is part of the kernel image, and the API is private to
> > >>> that particular image, so we can change things -- there's no ABI to
> > >>> worry about."
> > >>
> > >> I think Mark is right. The API *is* private to the kernel, and KVM being
> > >> the only in-kernel hypervisor on ARM, this is not an ABI.
> > >
> > > Again, that's wrong.
> > >
> > > We have two hypervisors in the kernel. One is KVM, the other is the
> > > stub. Sure, the stub isn't a full implementation of a hypervisor, but
> > > it is nevertheless, for the purposes of _this_ discussion, a hypervisor
> > > of sorts.
> > >
> > > The reason that both are included is because they both appear to share
> > > a common interface (although that's totally not documented anywhere.)
> >
> > And this interface exists for the sole purpose of enabling KVM. Call it
> > a hypervisor if you wish, but its usefulness is doubtful on its own.
> >
> > >>> So no, I'm going with my original patch (which TI has tested) which is
> > >>> the minimal change, and if we _then_ want to rework the HYP mode
> > >>> interfaces, that's the time to do the other changes when more people
> > >>> (such as KVM folk) are paying attention and we can come to a cross-
> > >>> hypervisor agreement on what the interface should be.
> > >>
> > >> Given that there is a single in-kernel hypervisor, I can't really see
> > >> who we're going to agree anything with...
> > >
> > > As far as I can see, the hyp-stub falls under ARM arch maintanence.
> > > KVM falls under KVM people. Two different groups, we need agreement
> > > between them what a sane API for both "hypervisors" should be.
> >
> > Well, I though we had the right level of discussion by reviewing your
> > patches and coming up with improvements. If you're after something else,
> > please let me know.
>
> What I'm after is a meaningful discussion between ARM arch maintainers
> and KVM maintainers - so far all I see are people on the ARM side of
> things.
I think your patches look fine, and I agree with your suggestions on
improving the hyp ABI and documenting it.
Marc found a small problem for KVM with your patch and offered a simple
fix. I don't really see a bigger problem here?
>
> I've also yet to have any response on some of the KVM questions I raised
> earlier in this thread - again, silence from KVM people.
Sorry about my silence, I was really busy leading up to Christmas and
was offline for most of the Christmas and new years days.
I've gone back over the thread and haven't been able to spot anything
that wasn't already answered by Marc (who also maintains KVM so would be
one of the KVM people). Could you let me know which questions remain
unanswered and I can try to help?
>
> What's also coming clear is that there's very few people who understand
> all the interactions here, and the whole thing seems to be an undocumented
> mess.
I think the hyp stub has just served a very limited purpose so far, and
therefore is a somewhat immature implementation. Now we've discovered a
need to clean it up, and we're all for that. Again, I don't think the
problem is any larger than that, we just need to fix it, and it seems to
me everyone is willing to work on that. Marc even offered to work on
your suggestion to support the general hyp ABI commands in KVM.
[...]
>
> So, I want KVM further changes to come through my tree once this merge
> window is over
I think we should try to separate the discussion of fixing an immediate
problem with the hyp code, and that of how to maintain things. I think
we're already on the right track to fix the former.
Before we start changing up maintainerships (which I personally think
work fine as it is) I would encourage you to just comment on patches
touching arch/arm that you are unhappy with.
We have been cc'ing all our changes to lakml and we've tried to cc you
specifically on anything touching arch/arm, and we will listen to any
suggestions you may have.
Thanks,
-Christoffer
^ 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