* [RFC v3 PATCH 00/25] Allow NOMMU for MULTIPLATFORM
From: mickael guene @ 2016-12-12 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fulus094.fsf@dell.be.48ers.dk>
Hi all,
You can find an R toolchain here:
https://github.com/mickael-guene/fdpic_manifest/releases/download/v7-r-1.0.1/toolset-v7-r-1.0.1-0-gbdcc6a7c-armv7-r.tgz
It's an fdpic toolset for cortex-r cpu class. gcc version is
quite old (4.7).
Note also that generated code may crash on class A cpu due to
generation of udiv/sdiv which is optional for class A.
(cortex a15 is ok but not a9).
Hope it helps
Regards
Mickael
On 12/11/2016 09:01 PM, Peter Korsgaard wrote:
>>>>>> "Afzal" == Afzal Mohammed <afzal.mohd.ma@gmail.com> writes:
>
> Hi,
>
> >> You can build a toolchain and initramfs with Buildroot. Have a look at
> >> the stm32f429 nommu config:
> >>
> >> https://git.buildroot.net/buildroot/tree/configs/stm32f429_disco_defconfig
>
> > iiuc, it builds one for Cortex-M. i already had a file system w/
> > busybox compiled using a Cortex-M toolchain (stolen from
> > Pengutronix's OSELAS.Toolchain), which works on Cortex M4 (Vybrid
> > VF610 M4 core). But it does not work here, i.e. on Cortex A, seems the
> > above mentioned also would have the same effect.
>
> Hmm, I'm not sure why a cortex-M toolchain wouldn't work on cortex-A, I
> thought the 'M' instruction set was a pure subset of the 'A'.
>
> > And in buildroot, couldn't see Cortex R option in menuconfig, and
> > selecting Cortex-A's excludes flat binary target & presents only with
> > ELF.
>
> We indeed don't have cortex-R support. I'm not aware of any cortex-R
> Linux support.
>
> When you select a cortex-A variant, then we enable MMU support by
> default, but you can disable it under toolchain options (Enable MMU) and
> then the flat binary option is available.
>
^ permalink raw reply
* [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support
From: Jiancheng Xue @ 2016-12-12 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fb89c03e-ea67-d339-b222-6f0e08988563@gmail.com>
On 2016/12/9 23:07, Marty Plummer wrote:
> On 12/04/2016 08:03 PM, Jiancheng Xue wrote:
>> Hi Arnd,
>>
>> On 2016/10/17 21:48, Arnd Bergmann wrote:
>>> On Monday, October 17, 2016 8:07:03 PM CEST Pan Wen wrote:
>>>> Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5.
>>>>
>>>> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
>>>>
>>>
>>> Looks ok. I've added Marty Plummer to Cc, he was recently proposing
>>> patches for Hi3520, which I think is closely related to this one.
>>> Please try to work together so the patches don't conflict. It should
>>> be fairly straightforward since you are basically doing the same
>>> change here.
>>>
>> Marty hasn't give any replies about this thread until now. I reviewed
>> the patch for Hi3520. And I think this patch won't conflict with Hi3520.
>> Could you help us to ack this patch?
>>
>> Thanks,
>> Jiancheng
>>
>>
> Hello all
>
> Sorry for my lack of activity, I've just been very busy lately with real
> world considerations (well, real world but related to this; I have
> another board based on hi3521a I've been tinkering with, trying to get
> the manuf. to release gpl source via the sfconfservancy). I've not given
> up on the project, however, since devices like this really need updates
> in light of the recent botnets targeting devices of this sort as
> manpower.
Do you have any objections to this patch? If not, I hope this patch can
be merged in 4.10. Thank you.
Regards,
Jiancheng
^ permalink raw reply
* [PATCH] serial: mxs-auart: support CMSPAR termios cflag
From: Wolfgang Ocker @ 2016-12-12 7:21 UTC (permalink / raw)
To: linux-arm-kernel
If CMSPAR is set in the c_cflag of termios, "stick" parity is enabled.
Tested on an i.MX28 system
Signed-off-by: Wolfgang Ocker <weo@reccoware.de>
---
v2: require PARENB to be also set in termios' c_cflag for CMSPAR
---
drivers/tty/serial/mxs-auart.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 770454e0dfa3..fd819ea26762 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -95,6 +95,7 @@
#define AUART_LINECTRL_BAUD_DIVFRAC_SHIFT 8
#define AUART_LINECTRL_BAUD_DIVFRAC_MASK 0x00003f00
#define AUART_LINECTRL_BAUD_DIVFRAC(v) (((v) & 0x3f) << 8)
+#define AUART_LINECTRL_SPS (1 << 7)
#define AUART_LINECTRL_WLEN_MASK 0x00000060
#define AUART_LINECTRL_WLEN(v) (((v) & 0x3) << 5)
#define AUART_LINECTRL_FEN (1 << 4)
@@ -1014,6 +1015,8 @@ static void mxs_auart_settermios(struct uart_port *u,
ctrl |= AUART_LINECTRL_PEN;
if ((cflag & PARODD) == 0)
ctrl |= AUART_LINECTRL_EPS;
+ if (cflag & CMSPAR)
+ ctrl |= AUART_LINECTRL_SPS;
}
u->read_status_mask = 0;
--
2.10.0
^ permalink raw reply related
* [PATCH v8 3/3] iio: adc: add support for Allwinner SoCs ADC
From: Quentin Schulz @ 2016-12-12 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161210094429.yp26sfoz54oqy3dz@lukather>
Hi Maxime,
On 10/12/2016 10:44, Maxime Ripard wrote:
> Hi,
>
> Just some minor comments.
>
> On Fri, Dec 09, 2016 at 11:22:36AM +0100, Quentin Schulz wrote:
>> + /*
>> + * Since the thermal sensor needs the IP to be in touchscreen mode and
>> + * there is no register to know if the IP has finished its transition
>> + * between the two modes, a delay is required when switching modes. This
>> + * slows down ADC readings while the latter are critical data to the
>
> The latter between what and what?
>
>> + * user. Disabling CONFIG_THERMAL_OF in kernel configuration allows the
>> + * user to avoid registering the thermal sensor (thus unavailable) and
>
> Isn't it obvious that it's not going to be available if you do not
> register it?
>
>> + * does not switch between modes thus "quicken" the ADC readings.
>> + * The thermal sensor should be enabled by default since the SoC
>> + * temperature is usually more critical than ADC readings.
>
> This last sentence should be in the Kconfig help. You cannot expect
> that all your users will read all the source code they want to compile
> :)
>
> Overall, I think this comment is kind of missing the point, maybe
> something like:
>
> /*
> * Since the controller needs to be in touchscreen mode for its
> * thermal sensor to operate properly, and that switching between the
> * two modes needs a delay, always registering in the thermal
> * framework will significantly slow down the conversion rate of the
> * ADCs.
> *
> * Therefore, instead of depending on THERMAL_OF in Kconfig, we only
> * register the sensor if that option is enabled, eventually leaving
> * that choice to the user.
> */
>
> Would be much clearer.
>
>> + */
>> +
>> + if (IS_ENABLED(CONFIG_THERMAL_OF)) {
>> + /*
>> + * This driver is a child of an MFD which has a node in the DT but not
>> + * its children. Therefore, the resulting devices of this driver do not
>
> Wrong indentation for the comment, and saying why the MFD children
> don't have a node in the DT (backward compatibility) would be nice.
>
Thanks for the comments, that's indeed much clearer.
>> + * have an of_node variable.
>> + * However, its parent (the MFD driver) has an of_node variable and
>> + * since devm_thermal_zone_of_sensor_register uses its first argument to
>> + * match the phandle defined in the node of the thermal driver with the
>> + * of_node of the device passed as first argument and the third argument
>> + * to call ops from thermal_zone_of_device_ops, the solution is to use
>> + * the parent device as first argument to match the phandle with its
>> + * of_node, and the device from this driver as third argument to return
>> + * the temperature.
>> + */
>> + tzd = devm_thermal_zone_of_sensor_register(pdev->dev.parent, 0,
>> + info,
>> + &sun4i_ts_tz_ops);
>
> I don't think tzd is used anywhere else in your function, it can be
> made local to this block.
>
ACK.
Thanks,
Quentin
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161212/a1ddfd4a/attachment.sig>
^ permalink raw reply
* [PATCH v6 1/8] MFD: add bindings for STM32 Timers driver
From: Lee Jones @ 2016-12-12 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481292919-26587-2-git-send-email-benjamin.gaignard@st.com>
On Fri, 09 Dec 2016, Benjamin Gaignard wrote:
> Add bindings information for STM32 Timers
>
> version 6:
> - rename stm32-gtimer to stm32-timers
> - change compatible
> - add description about the IPs
>
> version 2:
> - rename stm32-mfd-timer to stm32-gptimer
> - only keep one compatible string
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/mfd/stm32-timers.txt | 46 ++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> new file mode 100644
> index 0000000..b30868e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> @@ -0,0 +1,46 @@
> +STM32 Timers driver bindings
> +
> +This IP provides 3 types of timer along with PWM functionality:
> +- advanced-control timers consist of a 16-bit auto-reload counter driven by a programmable
> + prescaler, break input feature, PWM outputs and complementary PWM ouputs channels.
> +- general-purpose timers consist of a 16-bit or 32-bit auto-reload counter driven by a
> + programmable prescaler and PWM outputs.
> +- basic timers consist of a 16-bit auto-reload counter driven by a programmable prescaler.
> +
> +Required parameters:
> +- compatible: must be "st,stm32-timers"
> +
> +- reg: Physical base address and length of the controller's
> + registers.
> +- clock-names: Set to "clk_int".
> +- clocks: Phandle to the clock used by the timer module.
> + For Clk properties, please refer to ../clock/clock-bindings.txt
> +
> +Optional parameters:
> +- resets: Phandle to the parent reset controller.
> + See ../reset/st,stm32-rcc.txt
> +
> +Optional subnodes:
> +- pwm: See ../pwm/pwm-stm32.txt
> +- timer: See ../iio/timer/stm32-timer-trigger.txt
> +
> +Example:
> + timers at 40010000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + pinctrl-0 = <&pwm1_pins>;
> + pinctrl-names = "default";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <0>;
> + };
> + };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v6 2/8] MFD: add STM32 Timers driver
From: Lee Jones @ 2016-12-12 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481292919-26587-3-git-send-email-benjamin.gaignard@st.com>
On Fri, 09 Dec 2016, Benjamin Gaignard wrote:
> This hardware block could at used at same time for PWM generation
> and IIO timers.
> PWM and IIO timer configuration are mixed in the same registers
> so we need a multi fonction driver to be able to share those registers.
>
> version 6:
> - rename files to stm32-timers
> - rename functions to stm32_timers_xxx
>
> version 5:
> - fix Lee comments about detect function
> - add missing dependency on REGMAP_MMIO
>
> version 4:
> - add a function to detect Auto Reload Register (ARR) size
> - rename the structure shared with other drivers
>
> version 2:
> - rename driver "stm32-gptimer" to be align with SoC documentation
> - only keep one compatible
> - use of_platform_populate() instead of devm_mfd_add_devices()
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> drivers/mfd/Kconfig | 11 ++++++
> drivers/mfd/Makefile | 2 +
> drivers/mfd/stm32-timers.c | 80 ++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/stm32-timers.h | 71 +++++++++++++++++++++++++++++++++++
> 4 files changed, 164 insertions(+)
> create mode 100644 drivers/mfd/stm32-timers.c
> create mode 100644 include/linux/mfd/stm32-timers.h
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index c6df644..4ec1906 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1607,6 +1607,17 @@ config MFD_STW481X
> in various ST Microelectronics and ST-Ericsson embedded
> Nomadik series.
>
> +config MFD_STM32_TIMERS
> + tristate "Support for STM32 Timers"
> + depends on (ARCH_STM32 && OF) || COMPILE_TEST
> + select MFD_CORE
> + select REGMAP
> + select REGMAP_MMIO
> + help
> + Select this option to enable STM32 timers driver used
> + for PWM and IIO Timer. This driver allow to share the
> + registers between the others drivers.
> +
> menu "Multimedia Capabilities Port drivers"
> depends on ARCH_SA1100
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 9834e66..11a52f8 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -211,3 +211,5 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> +
> +obj-$(CONFIG_MFD_STM32_TIMERS) += stm32-timers.o
> diff --git a/drivers/mfd/stm32-timers.c b/drivers/mfd/stm32-timers.c
> new file mode 100644
> index 0000000..68d115e
> --- /dev/null
> +++ b/drivers/mfd/stm32-timers.c
> @@ -0,0 +1,80 @@
> +/*
> + * Copyright (C) STMicroelectronics 2016
> + *
> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com>
> + *
> + * License terms: GNU General Public License (GPL), version 2
> + */
> +
> +#include <linux/mfd/stm32-timers.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/reset.h>
> +
> +static const struct regmap_config stm32_timers_regmap_cfg = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = sizeof(u32),
> + .max_register = 0x400,
> +};
> +
> +static void stm32_timers_get_arr_size(struct stm32_timers *ddata)
> +{
> + /*
> + * Only the available bits will be written so when readback
> + * we get the maximum value of auto reload register
> + */
> + regmap_write(ddata->regmap, TIM_ARR, ~0L);
> + regmap_read(ddata->regmap, TIM_ARR, &ddata->max_arr);
> + regmap_write(ddata->regmap, TIM_ARR, 0x0);
> +}
> +
> +static int stm32_timers_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct stm32_timers *ddata;
> + struct resource *res;
> + void __iomem *mmio;
> +
> + ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> + if (!ddata)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + mmio = devm_ioremap_resource(dev, res);
> + if (IS_ERR(mmio))
> + return PTR_ERR(mmio);
> +
> + ddata->regmap = devm_regmap_init_mmio_clk(dev, "clk_int", mmio,
> + &stm32_timers_regmap_cfg);
> + if (IS_ERR(ddata->regmap))
> + return PTR_ERR(ddata->regmap);
> +
> + ddata->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(ddata->clk))
> + return PTR_ERR(ddata->clk);
> +
> + stm32_timers_get_arr_size(ddata);
> +
> + platform_set_drvdata(pdev, ddata);
> +
> + return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> +}
> +
> +static const struct of_device_id stm32_timers_of_match[] = {
> + { .compatible = "st,stm32-timers", },
> + { /* end node */ },
> +};
> +MODULE_DEVICE_TABLE(of, stm32_timers_of_match);
> +
> +static struct platform_driver stm32_timers_driver = {
> + .probe = stm32_timers_probe,
> + .driver = {
> + .name = "stm32-timers",
> + .of_match_table = stm32_timers_of_match,
> + },
> +};
> +module_platform_driver(stm32_timers_driver);
> +
> +MODULE_DESCRIPTION("STMicroelectronics STM32 Timers");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/mfd/stm32-timers.h b/include/linux/mfd/stm32-timers.h
> new file mode 100644
> index 0000000..d030004
> --- /dev/null
> +++ b/include/linux/mfd/stm32-timers.h
> @@ -0,0 +1,71 @@
> +/*
> + * Copyright (C) STMicroelectronics 2016
> + *
> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com>
> + *
> + * License terms: GNU General Public License (GPL), version 2
> + */
> +
> +#ifndef _LINUX_STM32_GPTIMER_H_
> +#define _LINUX_STM32_GPTIMER_H_
> +
> +#include <linux/clk.h>
> +#include <linux/regmap.h>
> +
> +#define TIM_CR1 0x00 /* Control Register 1 */
> +#define TIM_CR2 0x04 /* Control Register 2 */
> +#define TIM_SMCR 0x08 /* Slave mode control reg */
> +#define TIM_DIER 0x0C /* DMA/interrupt register */
> +#define TIM_SR 0x10 /* Status register */
> +#define TIM_EGR 0x14 /* Event Generation Reg */
> +#define TIM_CCMR1 0x18 /* Capt/Comp 1 Mode Reg */
> +#define TIM_CCMR2 0x1C /* Capt/Comp 2 Mode Reg */
> +#define TIM_CCER 0x20 /* Capt/Comp Enable Reg */
> +#define TIM_PSC 0x28 /* Prescaler */
> +#define TIM_ARR 0x2c /* Auto-Reload Register */
> +#define TIM_CCR1 0x34 /* Capt/Comp Register 1 */
> +#define TIM_CCR2 0x38 /* Capt/Comp Register 2 */
> +#define TIM_CCR3 0x3C /* Capt/Comp Register 3 */
> +#define TIM_CCR4 0x40 /* Capt/Comp Register 4 */
> +#define TIM_BDTR 0x44 /* Break and Dead-Time Reg */
> +
> +#define TIM_CR1_CEN BIT(0) /* Counter Enable */
> +#define TIM_CR1_ARPE BIT(7) /* Auto-reload Preload Ena */
> +#define TIM_CR2_MMS (BIT(4) | BIT(5) | BIT(6)) /* Master mode selection */
> +#define TIM_SMCR_SMS (BIT(0) | BIT(1) | BIT(2)) /* Slave mode selection */
> +#define TIM_SMCR_TS (BIT(4) | BIT(5) | BIT(6)) /* Trigger selection */
> +#define TIM_DIER_UIE BIT(0) /* Update interrupt */
> +#define TIM_SR_UIF BIT(0) /* Update interrupt flag */
> +#define TIM_EGR_UG BIT(0) /* Update Generation */
> +#define TIM_CCMR_PE BIT(3) /* Channel Preload Enable */
> +#define TIM_CCMR_M1 (BIT(6) | BIT(5)) /* Channel PWM Mode 1 */
> +#define TIM_CCER_CC1E BIT(0) /* Capt/Comp 1 out Ena */
> +#define TIM_CCER_CC1P BIT(1) /* Capt/Comp 1 Polarity */
> +#define TIM_CCER_CC1NE BIT(2) /* Capt/Comp 1N out Ena */
> +#define TIM_CCER_CC1NP BIT(3) /* Capt/Comp 1N Polarity */
> +#define TIM_CCER_CC2E BIT(4) /* Capt/Comp 2 out Ena */
> +#define TIM_CCER_CC3E BIT(8) /* Capt/Comp 3 out Ena */
> +#define TIM_CCER_CC4E BIT(12) /* Capt/Comp 4 out Ena */
> +#define TIM_CCER_CCXE (BIT(0) | BIT(4) | BIT(8) | BIT(12))
> +#define TIM_BDTR_BKE BIT(12) /* Break input enable */
> +#define TIM_BDTR_BKP BIT(13) /* Break input polarity */
> +#define TIM_BDTR_AOE BIT(14) /* Automatic Output Enable */
> +#define TIM_BDTR_MOE BIT(15) /* Main Output Enable */
> +#define TIM_BDTR_BKF (BIT(16) | BIT(17) | BIT(18) | BIT(19))
> +#define TIM_BDTR_BK2F (BIT(20) | BIT(21) | BIT(22) | BIT(23))
> +#define TIM_BDTR_BK2E BIT(24) /* Break 2 input enable */
> +#define TIM_BDTR_BK2P BIT(25) /* Break 2 input polarity */
> +
> +#define MAX_TIM_PSC 0xFFFF
> +#define TIM_CR2_MMS_SHIFT 4
> +#define TIM_SMCR_TS_SHIFT 4
> +#define TIM_BDTR_BKF_MASK 0xF
> +#define TIM_BDTR_BKF_SHIFT 16
> +#define TIM_BDTR_BK2F_SHIFT 20
> +
> +struct stm32_timers {
> + struct clk *clk;
> + struct regmap *regmap;
> + u32 max_arr;
> +};
> +#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v6 0/8] Add PWM and IIO timer drivers for STM32
From: Lee Jones @ 2016-12-12 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481292919-26587-1-git-send-email-benjamin.gaignard@st.com>
On Fri, 09 Dec 2016, Benjamin Gaignard wrote:
> version 6:
> - rename stm32-gptimer in stm32-timers.
> - change "st,stm32-gptimer" compatible to "st,stm32-timers".
> - modify "st,breakinput" parameter in pwm part.
> - split DT patch in 2
>
> version 5:
> - fix comments done on version 4
> - rebased on kernel 4.9-rc8
> - change nodes names and re-order then by addresses
>
> version 4:
> - fix comments done on version 3
> - don't use interrupts anymore in IIO timer
> - detect hardware capabilities at probe time to simplify binding
>
> version 3:
> - no change on mfd and pwm divers patches
> - add cross reference between bindings
> - change compatible to "st,stm32-timer-trigger"
> - fix attributes access rights
> - use string instead of int for master_mode and slave_mode
> - document device attributes in sysfs-bus-iio-timer-stm32
> - update DT with the new compatible
>
> version 2:
> - keep only one compatible per driver
> - use DT parameters to describe hardware block configuration:
> - pwm channels, complementary output, counter size, break input
> - triggers accepted and create by IIO timers
> - change DT to limite use of reference to the node
> - interrupt is now in IIO timer driver
> - rename stm32-mfd-timer to stm32-timers (for general purpose timer)
>
> The following patches enable PWM and IIO Timer features for STM32 platforms.
>
> Those two features are mixed into the registers of the same hardware block
> (named general purpose timer) which lead to introduce a multifunctions driver
> on the top of them to be able to share the registers.
>
> In STM32f4 14 instances of timer hardware block exist, even if they all have
> the same register mapping they could have a different number of pwm channels
> and/or different triggers capabilities. We use various parameters in DT to
> describe the differences between hardware blocks
>
> The MFD (stm32-timers.c) takes care of clock and register mapping
> by using regmap. stm32_timers structure is provided to its sub-node to
> share those information.
>
> PWM driver is implemented into pwm-stm32.c. Depending of the instance we may
> have up to 4 channels, sometime with complementary outputs or 32 bits counter
> instead of 16 bits. Some hardware blocks may also have a break input function
> which allows to stop pwm depending of a level, defined in devicetree, on an
> external pin.
>
> IIO timer driver (stm32-timer-trigger.c and stm32-timer-trigger.h) define a list
> of hardware triggers usable by hardware blocks like ADC, DAC or other timers.
>
> The matrix of possible connections between blocks is quite complex so we use
> trigger names and is_stm32_iio_timer_trigger() function to be sure that
> triggers are valid and configure the IPs.
>
> At run time IIO timer hardware blocks can configure (through "master_mode"
> IIO device attribute) which internal signal (counter enable, reset,
> comparison block, etc...) is used to generate the trigger.
>
> By using "slave_mode" IIO device attribute timer can also configure on which
> event (level, rising edge) of the block is enabled.
>
> Since we can use trigger from one hardware to control an other block, we can
> use a pwm to control an other one. The following example shows how to configure
> pwm1 and pwm3 to make pwm3 generate pulse only when pwm1 pulse level is high.
>
> /sys/bus/iio/devices # ls
> iio:device0 iio:device1 trigger0 trigger1
>
> configure timer1 to use pwm1 channel 0 as output trigger
> /sys/bus/iio/devices # echo 'OC1REF' > iio\:device0/master_mode
> configure timer3 to enable only when input is high
> /sys/bus/iio/devices # echo 'gated' > iio\:device1/slave_mode
> /sys/bus/iio/devices # cat trigger0/name
> tim1_trgo
> configure timer2 to use timer1 trigger is input
> /sys/bus/iio/devices # echo "tim1_trgo" > iio\:device1/trigger/current_trigger
>
> configure pwm3 channel 0 to generate a signal with a period of 100ms and a
> duty cycle of 50%
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 0 > export
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 100000000 > pwm0/period
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 50000000 > pwm0/duty_cycle
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 1 > pwm0/enable
> here pwm3 channel 0, as expected, doesn't start because has to be triggered by
> pwm1 channel 0
>
> configure pwm1 channel 0 to generate a signal with a period of 1s and a
> duty cycle of 50%
> /sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 0 > export
> /sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 1000000000 > pwm0/period
> /sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 500000000 > pwm0/duty_cycle
> /sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 1 > pwm0/enable
> finally pwm1 starts and pwm3 only generates pulse when pwm1 signal is high
>
> An other example to use a timer as source of clock for another device.
> Here timer1 is used a source clock for pwm3:
>
> /sys/bus/iio/devices # echo 100000 > trigger0/sampling_frequency
> /sys/bus/iio/devices # echo "tim1_trgo" > iio\:device1/trigger/current_trigger
> /sys/bus/iio/devices # echo 'external_clock' > iio\:device1/slave_mode
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 0 > export
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 1000000 > pwm0/period
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 500000 > pwm0/duty_cycle
> /sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 1 > pwm0/enable
>
> Benjamin Gaignard (8):
> MFD: add bindings for STM32 Timers driver
> MFD: add STM32 Timers driver
> PWM: add pwm-stm32 DT bindings
> PWM: add PWM driver for STM32 plaftorm
> IIO: add bindings for STM32 timer trigger driver
> IIO: add STM32 timer trigger driver
> ARM: dts: stm32: add Timers driver for stm32f429 MCU
> ARM: dts: stm32: Enable pw1 and pwm3 for stm32f469-disco
>
> .../ABI/testing/sysfs-bus-iio-timer-stm32 | 55 +++
> .../bindings/iio/timer/stm32-timer-trigger.txt | 23 +
> .../devicetree/bindings/mfd/stm32-timers.txt | 46 ++
> .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++
> arch/arm/boot/dts/stm32f429.dtsi | 275 ++++++++++++
> arch/arm/boot/dts/stm32f469-disco.dts | 28 ++
> 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 -
> drivers/mfd/Kconfig | 11 +
> drivers/mfd/Makefile | 2 +
> drivers/mfd/stm32-timers.c | 80 ++++
> drivers/pwm/Kconfig | 9 +
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-stm32.c | 434 +++++++++++++++++++
> include/linux/iio/timer/stm32-timer-trigger.h | 62 +++
> include/linux/mfd/stm32-timers.h | 71 ++++
> 20 files changed, 1612 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> 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 drivers/mfd/stm32-timers.c
> create mode 100644 drivers/pwm/pwm-stm32.c
> create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
> create mode 100644 include/linux/mfd/stm32-timers.h
This has really come together nicely.
Great work Benjamin.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] clk: bcm: Fix 'maybe-uninitialized' warning in bcm2835_clock_choose_div_and_prate()
From: Boris Brezillon @ 2016-12-12 8:00 UTC (permalink / raw)
To: linux-arm-kernel
best_rate is reported as potentially uninitialized by gcc.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: 155e8b3b0ee3 ("clk: bcm: Support rate change propagation on bcm2835 clocks")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/clk/bcm/clk-bcm2835.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index eaf82f49dede..0d14409097e7 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -1029,7 +1029,7 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
struct bcm2835_clock *clock = bcm2835_clock_from_hw(hw);
struct bcm2835_cprman *cprman = clock->cprman;
const struct bcm2835_clock_data *data = clock->data;
- unsigned long best_rate;
+ unsigned long best_rate = 0;
u32 curdiv, mindiv, maxdiv;
struct clk_hw *parent;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 00/11] add support for VBUS max current and min voltage limits AXP20X and AXP22X PMICs
From: Quentin Schulz @ 2016-12-12 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
Hi all,
I forgot to add a question to my cover letter so here it is:
The X-Powers AXP209 and AXP223 PMICs allow to not limit the maximal
current for the VBUS power supply.[1]
(If a Chinese-speaking person could check it's the same for the AXP221
that would be great also[2]).
In the get_property (axp20x_usb_power_get_property) of the power supply
driver, I see that we use -1 as value for "no limit". Should we use the
same (-1) value for the set_property (axp20x_usb_power_set_property) to
disable max current limit?
[1] http://dl.linux-sunxi.org/AXP/AXP209_Datasheet_v1.0en.pdf page 33,
REG 30H, BITS 0 & 1
[2]
http://dl.linux-sunxi.org/AXP/AXP221%20Datasheet%20V1.2%2020130326%20.pdf
page 33, REG 30H, BITS 0 & 1 => ??? is written for when the BIT(1) is
set.
Thanks,
Quentin
On 09/12/2016 12:04, Quentin Schulz wrote:
> The X-Powers AXP209 and AXP20X PMICs are able to set a limit for the
> VBUS power supply for both max current and min voltage supplied. This
> series of patch adds the possibility to set these limits from sysfs.
>
> Also, the AXP223 PMIC shares most of its behaviour with the AXP221 but
> the former can set the VBUS power supply max current to 100mA, unlike
> the latter. The AXP223 VBUS power supply driver used to probe on the
> AXP221 compatible. This series of patch introduces a new compatible for
> the AXP223 to be able to set the current max limit to 100mA.
>
> With that new compatible, boards having the AXP223 see their DT updated
> to use the VBUS power supply driver with the correct compatible.
>
> This series of patch also migrates from of_device_is_compatible function
> to the data field of of_device_id to identify the compatible used to
> probe. This improves the code readability.
>
> Mostly cosmetic changes in v2 and adding volatile and writeable regs to
> AXP20X and AXP22X MFD cells for the VBUS power supply driver.
>
> Quentin Schulz (11):
> power: supply: axp20x_usb_power: use of_device_id data field instead
> of device_is_compatible
> mfd: axp20x: add volatile and writeable reg ranges for VBUS power
> supply driver
> power: supply: axp20x_usb_power: set min voltage and max current from
> sysfs
> Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
> power: supply: axp20x_usb_power: add 100mA max current limit for
> AXP223
> mfd: axp20x: add separate MFD cell for AXP223
> ARM: dtsi: add DTSI for AXP223
> ARM: dts: sun8i-a33-olinuxino: use AXP223 DTSI
> ARM: dts: sun8i-a33-sinlinx-sina33: use AXP223 DTSI
> ARM: dts: sun8i-r16-parrot: use AXP223 DTSI
> ARM: dtsi: sun8i-reference-design-tablet: use AXP223 DTSI
>
> .../bindings/power/supply/axp20x_usb_power.txt | 5 +
> arch/arm/boot/dts/axp223.dtsi | 58 +++++++++++
> arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 2 +-
> arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 2 +-
> arch/arm/boot/dts/sun8i-r16-parrot.dts | 2 +-
> .../boot/dts/sun8i-reference-design-tablet.dtsi | 2 +-
> drivers/mfd/axp20x.c | 32 +++++-
> drivers/power/supply/axp20x_usb_power.c | 116 ++++++++++++++++++---
> 8 files changed, 197 insertions(+), 22 deletions(-)
> create mode 100644 arch/arm/boot/dts/axp223.dtsi
>
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] clk: bcm: Fix 'maybe-uninitialized' warning in bcm2835_clock_choose_div_and_prate()
From: Arnd Bergmann @ 2016-12-12 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481529653-28133-1-git-send-email-boris.brezillon@free-electrons.com>
On Monday, December 12, 2016 9:00:53 AM CET Boris Brezillon wrote:
> best_rate is reported as potentially uninitialized by gcc.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> Fixes: 155e8b3b0ee3 ("clk: bcm: Support rate change propagation on bcm2835 clocks")
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
I wonder why I didn't get that. Which compiler version did you use?
Arnd
^ permalink raw reply
* [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Auger Eric @ 2016-12-12 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <584CB481.3040902@redhat.com>
Hi Don,
On 11/12/2016 03:05, Don Dutile wrote:
> On 12/08/2016 04:36 AM, Auger Eric wrote:
>> Hi,
>>
>> On 15/11/2016 14:09, Eric Auger wrote:
>>> Following LPC discussions, we now report reserved regions through
>>> iommu-group sysfs reserved_regions attribute file.
>>
>>
>> While I am respinning this series into v4, here is a tentative summary
>> of technical topics for which no consensus was reached at this point.
>>
>> 1) Shall we report the usable IOVA range instead of reserved IOVA
>> ranges. Not discussed at/after LPC.
>> x I currently report reserved regions. Alex expressed the need to
>> report the full usable IOVA range instead (x86 min-max range
>> minus MSI APIC window). I think this is meaningful for ARM
>> too where arm-smmu might not support the full 64b range.
>> x Any objection we report the usable IOVA regions instead?
>>
>> 2) Shall the kernel check collision with MSI window* when userspace
>> calls VFIO_IOMMU_MAP_DMA?
>> Joerg/Will No; Alex yes
>> *for IOVA regions consumed downstream to the IOMMU: everyone says NO
>>
>> 3) RMRR reporting in the iommu group sysfs? Joerg: yes; Don: no
> Um, I'm missing context, but the only thing I recall saying no to wrt RMRR
> is that _any_ device that has an RMRR cannot be assigned to a guest.
Yes that was my understanding
> Or, are you saying, RMRR's should be exposed in the guest os? if so, then
> you have my 'no' there.
>
>> My current series does not expose them in iommu group sysfs.
>> I understand we can expose the RMRR regions in the iomm group sysfs
>> without necessarily supporting RMRR requiring device assignment.
> This sentence doesn't make sense to me.
> Can you try re-wording it?
> I can't tell what RMRR has to do w/device assignment, other than what I
> said above.
> Exposing RMRR's in sysfs is not an issue in general.
Sorry for the confusion. I Meant we can expose RMRR regions as part of
the reserved regions through the iommu group sysfs API without
supporting device assignment of devices that has RMRR.
Hope it clarifies
Eric
>
>> We can also add this support later.
>>
>> Thanks
>>
>> Eric
>>
>>
>>>
>>> Reserved regions are populated through the IOMMU get_resv_region
>>> callback
>>> (former get_dm_regions), now implemented by amd-iommu, intel-iommu and
>>> arm-smmu.
>>>
>>> The intel-iommu reports the [FEE0_0000h - FEF0_000h] MSI window as an
>>> IOMMU_RESV_NOMAP reserved region.
>>>
>>> arm-smmu reports the MSI window (arbitrarily located at 0x8000000 and
>>> 1MB large) and the PCI host bridge windows.
>>>
>>> The series integrates a not officially posted patch from Robin:
>>> "iommu/dma: Allow MSI-only cookies".
>>>
>>> This series currently does not address IRQ safety assessment.
>>>
>>> Best Regards
>>>
>>> Eric
>>>
>>> Git: complete series available at
>>> https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3
>>>
>>> History:
>>> RFC v2 -> v3:
>>> - switch to an iommu-group sysfs API
>>> - use new dummy allocator provided by Robin
>>> - dummy allocator initialized by vfio-iommu-type1 after enumerating
>>> the reserved regions
>>> - at the moment ARM MSI base address/size is left unchanged compared
>>> to v2
>>> - we currently report reserved regions and not usable IOVA regions as
>>> requested by Alex
>>>
>>> RFC v1 -> v2:
>>> - fix intel_add_reserved_regions
>>> - add mutex lock/unlock in vfio_iommu_type1
>>>
>>>
>>> Eric Auger (10):
>>> iommu/dma: Allow MSI-only cookies
>>> iommu: Rename iommu_dm_regions into iommu_resv_regions
>>> iommu: Add new reserved IOMMU attributes
>>> iommu: iommu_alloc_resv_region
>>> iommu: Do not map reserved regions
>>> iommu: iommu_get_group_resv_regions
>>> iommu: Implement reserved_regions iommu-group sysfs file
>>> iommu/vt-d: Implement reserved region get/put callbacks
>>> iommu/arm-smmu: Implement reserved region get/put callbacks
>>> vfio/type1: Get MSI cookie
>>>
>>> drivers/iommu/amd_iommu.c | 20 +++---
>>> drivers/iommu/arm-smmu.c | 52 +++++++++++++++
>>> drivers/iommu/dma-iommu.c | 116
>>> ++++++++++++++++++++++++++-------
>>> drivers/iommu/intel-iommu.c | 50 ++++++++++----
>>> drivers/iommu/iommu.c | 141
>>> ++++++++++++++++++++++++++++++++++++----
>>> drivers/vfio/vfio_iommu_type1.c | 26 ++++++++
>>> include/linux/dma-iommu.h | 7 ++
>>> include/linux/iommu.h | 49 ++++++++++----
>>> 8 files changed, 391 insertions(+), 70 deletions(-)
>>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] clk: bcm: Fix 'maybe-uninitialized' warning in bcm2835_clock_choose_div_and_prate()
From: Stephen Rothwell @ 2016-12-12 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3107859.uaKLk6DMRd@wuerfel>
Hi Arnd,
On Mon, 12 Dec 2016 09:12:36 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Monday, December 12, 2016 9:00:53 AM CET Boris Brezillon wrote:
> > best_rate is reported as potentially uninitialized by gcc.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > Fixes: 155e8b3b0ee3 ("clk: bcm: Support rate change propagation on bcm2835 clocks")
> > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> I wonder why I didn't get that. Which compiler version did you use?
Gcc-5.2.0 powerpc-le hosted cross compiler.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC Fixes for v4.10
From: Simon Horman @ 2016-12-12 8:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Kevin, Hi Arnd,
Please consider these Renesas ARM based SoC fixes for v4.10.
This provides an sd0_uhs node rather than duplicate sdh0 nodes
resolving an error introduced in a clean-up patch.
This pull request is based on "Second Round of Renesas ARM Based SoC DT
Updates for v4.10", tagged as renesas-arm64-dt2-for-v4.10,
which you have already pulled. The error corrected by this change
was introduced in that pull-request.
The following changes since commit 5de68961cf5618c1ce5bb15848b36121247f23d5:
arm64: dts: r8a7796: Add device node for PRR (2016-11-21 10:18:53 +0100)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-fixes-for-v4.10
for you to fetch changes up to 8ebcb400af619ee0ddeb39c06fc35511b20cc697:
arm64: dts: h3ulcb: Provide sd0_uhs node (2016-12-08 14:29:17 +0100)
----------------------------------------------------------------
Renesas ARM Based SoC Fixes for v4.10
* Provide sd0_uhs node
----------------------------------------------------------------
Simon Horman (1):
arm64: dts: h3ulcb: Provide sd0_uhs node
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* [PATCH] arm64: dts: h3ulcb: Provide sd0_uhs node
From: Simon Horman @ 2016-12-12 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1481530910.git.horms+renesas@verge.net.au>
Provide separaate sd0 and sd0_uhs nodes rather than duplicate sd0 nodes.
Cc: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Fixes: 93373c309a70 ("arm64: dts: h3ulcb: rename SDHI0 pins")
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index 6ffb0517421a..dbea2c3d8f0c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -169,7 +169,7 @@
power-source = <3300>;
};
- sdhi0_pins_uhs: sd0 {
+ sdhi0_pins_uhs: sd0_uhs {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
power-source = <1800>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH] clk: bcm: Fix 'maybe-uninitialized' warning in bcm2835_clock_choose_div_and_prate()
From: Boris Brezillon @ 2016-12-12 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3107859.uaKLk6DMRd@wuerfel>
On Mon, 12 Dec 2016 09:12:36 +0100
Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, December 12, 2016 9:00:53 AM CET Boris Brezillon wrote:
> > best_rate is reported as potentially uninitialized by gcc.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > Fixes: 155e8b3b0ee3 ("clk: bcm: Support rate change propagation on bcm2835 clocks")
> > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> I wonder why I didn't get that. Which compiler version did you use?
>
In case you're interested, my gcc [1] failed to detect it as well, and
this is not the first time it happens :-/.
[1]gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
^ permalink raw reply
* [PATCH] clk: bcm: Fix 'maybe-uninitialized' warning in bcm2835_clock_choose_div_and_prate()
From: Arnd Bergmann @ 2016-12-12 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212093130.6e348a61@bbrezillon>
On Monday, December 12, 2016 9:31:30 AM CET Boris Brezillon wrote:
> On Mon, 12 Dec 2016 09:12:36 +0100
> Arnd Bergmann <arnd@arndb.de> wrote:
>
> > On Monday, December 12, 2016 9:00:53 AM CET Boris Brezillon wrote:
> > > best_rate is reported as potentially uninitialized by gcc.
> > >
> > > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > > Fixes: 155e8b3b0ee3 ("clk: bcm: Support rate change propagation on bcm2835 clocks")
> > > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> >
> > I wonder why I didn't get that. Which compiler version did you use?
> >
>
> In case you're interested, my gcc [1] failed to detect it as well, and
> this is not the first time it happens :-/.
>
> [1]gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
No, I see it now with gcc-7, it only just turned up in linux-next.
I ran into it right away with an allmodconfig build. You were
probably testing based on an earlier v4.9-rc release that had
the warning globally disabled.
Arnd
^ permalink raw reply
* [PATCH v5 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2016-12-12 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211214232.GA2552@katana>
Hi Wolfram,
Thanks for your comments.
I will fix all of them + build errors reported by build-bot in the V6.
Best regards,
Cedric Madianga
2016-12-11 22:42 GMT+01:00 Wolfram Sang <wsa@the-dreams.de>:
> Hi,
>
>> +config I2C_STM32F4
>> + tristate "STMicroelectronics STM32F4 I2C support"
>> + depends on ARCH_STM32 || COMPILE_TEST
>
> Double space.
>
>> +#define STM32F4_I2C_MIN_FREQ 2
>> +#define STM32F4_I2C_MAX_FREQ 42
>
> Those two must be unsigned to fix the build error (e.g. 2U) reported by
> build-bot.
>
> Also, I get the following build warnings:
>
> CC drivers/i2c/busses/i2c-stm32f4.o
> drivers/i2c/busses/i2c-stm32f4.c: In function ?stm32f4_i2c_handle_rx_addr?:
> drivers/i2c/busses/i2c-stm32f4.c:445:6: warning: variable ?sr2? set but not used [-Wunused-but-set-variable]
> u32 sr2;
> ^~~
> drivers/i2c/busses/i2c-stm32f4.c: In function ?stm32f4_i2c_isr_event?:
> drivers/i2c/busses/i2c-stm32f4.c:496:41: warning: variable ?sr2? set but not used [-Wunused-but-set-variable]
> u32 real_status, possible_status, ien, sr2;
>
> I assume those are reads to clear the register, so we really don't need
> to save the value in a variable.
>
> Rest is looking good.
>
> Thanks,
>
> Wolfram
>
^ permalink raw reply
* [PATCH] media: platform: xilinx: xilinx-tpg: constify v4l2_subdev_* structures
From: Laurent Pinchart @ 2016-12-12 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481449952-26119-1-git-send-email-bhumirks@gmail.com>
Hi Bhumika,
Thank you for the patch.
On Sunday 11 Dec 2016 15:22:32 Bhumika Goyal wrote:
> v4l2_subdev_{core/pad/video}_ops structures are stored in the
> fields of the v4l2_subdev_ops structure which are of type const.
> Also, v4l2_subdev_ops structure is passed to a function
> having its argument of type const. As these structures are never
> modified, so declare them as const.
> Done using Coccinelle: (One of the scripts used)
>
> @r1 disable optional_qualifier @
> identifier i;
> position p;
> @@
> static struct v4l2_subdev_video_ops i at p = {...};
>
> @ok1@
> identifier r1.i;
> position p;
> struct v4l2_subdev_ops obj;
> @@
> obj.video=&i at p;
>
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i at p
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct v4l2_subdev_video_ops i;
>
> File size before:
> text data bss dec hex filename
> 6170 2752 144 9066 236a media/platform/xilinx/xilinx-
tpg.o
>
> File size after:
> text data bss dec hex filename
> 6666 2384 8 9058 2362 media/platform/xilinx/xilinx-
tpg.o
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/media/platform/xilinx/xilinx-tpg.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/xilinx/xilinx-tpg.c
> b/drivers/media/platform/xilinx/xilinx-tpg.c index 2ec1f6c..9c49d1d 100644
> --- a/drivers/media/platform/xilinx/xilinx-tpg.c
> +++ b/drivers/media/platform/xilinx/xilinx-tpg.c
> @@ -460,21 +460,21 @@ static int xtpg_s_ctrl(struct v4l2_ctrl *ctrl)
> .s_ctrl = xtpg_s_ctrl,
> };
>
> -static struct v4l2_subdev_core_ops xtpg_core_ops = {
> +static const struct v4l2_subdev_core_ops xtpg_core_ops = {
> };
>
> -static struct v4l2_subdev_video_ops xtpg_video_ops = {
> +static const struct v4l2_subdev_video_ops xtpg_video_ops = {
> .s_stream = xtpg_s_stream,
> };
>
> -static struct v4l2_subdev_pad_ops xtpg_pad_ops = {
> +static const struct v4l2_subdev_pad_ops xtpg_pad_ops = {
> .enum_mbus_code = xvip_enum_mbus_code,
> .enum_frame_size = xtpg_enum_frame_size,
> .get_fmt = xtpg_get_format,
> .set_fmt = xtpg_set_format,
> };
>
> -static struct v4l2_subdev_ops xtpg_ops = {
> +static const struct v4l2_subdev_ops xtpg_ops = {
> .core = &xtpg_core_ops,
> .video = &xtpg_video_ops,
> .pad = &xtpg_pad_ops,
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v7 1/2] provide lock-less versions of clk_{enable|disable}
From: Sekhar Nori @ 2016-12-12 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209185421.fybpk4bdq6b7yglf@pengutronix.de>
Hi Uwe,
On Saturday 10 December 2016 12:24 AM, Uwe Kleine-K?nig wrote:
> Hello,
>
> On Fri, Dec 09, 2016 at 05:59:32PM +0100, Alexandre Bailon wrote:
>> Rename __clk_{enable|disble} in davinci_clk_{enable|disable}.
>> davinci_clk_{enable|disable} is a lock-less version of
>> clk_{enable|disable}.
>> This is useful to recursively enable clock without doing recursive call
>> to clk_enable(), which would cause a recursive locking issue.
>> The lock-less version could be used by example by the usb20 phy clock,
>> that need to enable the usb20 clock before to start.
>
> I wouldn't call that lock-less. The difference is that the newly exposed
> funcion requires the caller to already hold the lock. So maybe a better
Right.
> name would be clk_enable_locked.
I am not sure the new name you propose is much clearer. Unless I am
missing an obvious naming pattern in kernel. Besides, I want to have the
"davinci_" prefix for consistency with how other mach-davinci internal
functions are named. FWIW, the equivalent function in common-clk is
called clk_core_enable().
>
> Would it be more sensible to convert davinci to common-clk?
Yes, but there is no work going on on that and AFAIK, know one is
planning on working on it too. These patches are needed anyway since we
need to fix the existing issue on v4.10
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] clk: bcm: Fix 'maybe-uninitialized' warning in bcm2835_clock_choose_div_and_prate()
From: Boris Brezillon @ 2016-12-12 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2237053.NkkLiYIyzc@wuerfel>
On Mon, 12 Dec 2016 09:34:28 +0100
Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, December 12, 2016 9:31:30 AM CET Boris Brezillon wrote:
> > On Mon, 12 Dec 2016 09:12:36 +0100
> > Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > > On Monday, December 12, 2016 9:00:53 AM CET Boris Brezillon wrote:
> > > > best_rate is reported as potentially uninitialized by gcc.
> > > >
> > > > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > > > Fixes: 155e8b3b0ee3 ("clk: bcm: Support rate change propagation on bcm2835 clocks")
> > > > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > >
> > > I wonder why I didn't get that. Which compiler version did you use?
> > >
> >
> > In case you're interested, my gcc [1] failed to detect it as well, and
> > this is not the first time it happens :-/.
> >
> > [1]gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>
> No, I see it now with gcc-7, it only just turned up in linux-next.
>
> I ran into it right away with an allmodconfig build. You were
> probably testing based on an earlier v4.9-rc release that had
> the warning globally disabled.
Indeed, I was testing on a 4.9-rc.
^ permalink raw reply
* [PATCH v8 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver
From: Rick Chang @ 2016-12-12 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAJzSMfNyMiia==mXKo6aBw1VxMBxGE20LB870Zm1u9mCoioyQ@mail.gmail.com>
Hi Ricky,
Thanks for your feedback. We will fix the problem in another patch.
On Mon, 2016-12-12 at 12:34 +0800, Ricky Liang wrote:
> Hi Rick,
>
> On Wed, Nov 30, 2016 at 11:08 AM, Rick Chang <rick.chang@mediatek.com> wrote:
> > Add v4l2 driver for Mediatek JPEG Decoder
> >
> > Signed-off-by: Rick Chang <rick.chang@mediatek.com>
> > Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
>
> <snip...>
>
> > +static bool mtk_jpeg_check_resolution_change(struct mtk_jpeg_ctx *ctx,
> > + struct mtk_jpeg_dec_param *param)
> > +{
> > + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> > + struct mtk_jpeg_q_data *q_data;
> > +
> > + q_data = &ctx->out_q;
> > + if (q_data->w != param->pic_w || q_data->h != param->pic_h) {
> > + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "Picture size change\n");
> > + return true;
> > + }
> > +
> > + q_data = &ctx->cap_q;
> > + if (q_data->fmt != mtk_jpeg_find_format(ctx, param->dst_fourcc,
> > + MTK_JPEG_FMT_TYPE_CAPTURE)) {
> > + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "format change\n");
> > + return true;
> > + }
> > + return false;
>
> <snip...>
>
> > +static void mtk_jpeg_device_run(void *priv)
> > +{
> > + struct mtk_jpeg_ctx *ctx = priv;
> > + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> > + struct vb2_buffer *src_buf, *dst_buf;
> > + enum vb2_buffer_state buf_state = VB2_BUF_STATE_ERROR;
> > + unsigned long flags;
> > + struct mtk_jpeg_src_buf *jpeg_src_buf;
> > + struct mtk_jpeg_bs bs;
> > + struct mtk_jpeg_fb fb;
> > + int i;
> > +
> > + src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > + dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > + jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(src_buf);
> > +
> > + if (jpeg_src_buf->flags & MTK_JPEG_BUF_FLAGS_LAST_FRAME) {
> > + for (i = 0; i < dst_buf->num_planes; i++)
> > + vb2_set_plane_payload(dst_buf, i, 0);
> > + buf_state = VB2_BUF_STATE_DONE;
> > + goto dec_end;
> > + }
> > +
> > + if (mtk_jpeg_check_resolution_change(ctx, &jpeg_src_buf->dec_param)) {
> > + mtk_jpeg_queue_src_chg_event(ctx);
> > + ctx->state = MTK_JPEG_SOURCE_CHANGE;
> > + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> > + return;
> > + }
>
> This only detects source change if multiple OUPUT buffers are queued.
> It does not catch the source change in the following scenario:
>
> - OUPUT buffers for jpeg1 enqueued
> - OUTPUT queue STREAMON
> - userspace creates CAPTURE buffers
> - CAPTURE buffers enqueued
> - CAPTURE queue STREAMON
> - decode
> - OUTPUT queue STREAMOFF
> - userspace recreates OUTPUT buffers for jpeg2
> - OUTPUT buffers for jpeg2 enqueued
> - OUTPUT queue STREAMON
>
> In the above sequence if jpeg2's decoded size is larger than jpeg1 the
> function fails to detect that the existing CAPTURE buffers are not big
> enough to hold the decoded data.
>
> A possible fix is to pass *dst_buf to
> mtk_jpeg_check_resolution_change(), and check in the function that all
> the dst_buf planes are large enough to hold the decoded data.
>
> > +
> > + mtk_jpeg_set_dec_src(ctx, src_buf, &bs);
> > + if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, dst_buf, &fb))
> > + goto dec_end;
> > +
> > + spin_lock_irqsave(&jpeg->hw_lock, flags);
> > + mtk_jpeg_dec_reset(jpeg->dec_reg_base);
> > + mtk_jpeg_dec_set_config(jpeg->dec_reg_base,
> > + &jpeg_src_buf->dec_param, &bs, &fb);
> > +
> > + mtk_jpeg_dec_start(jpeg->dec_reg_base);
> > + spin_unlock_irqrestore(&jpeg->hw_lock, flags);
> > + return;
> > +
> > +dec_end:
> > + v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> > + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf), buf_state);
> > + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(dst_buf), buf_state);
> > + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> > +}
>
> <snip...>
^ permalink raw reply
* [PATCH renesas/devel 00/13] ARM, arm64: dts: Use R-Car fallback bindings for i2c/iic nodes
From: Simon Horman @ 2016-12-12 9:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this short series makes use of newly added R-Car fallback bindings in
i2c and iic nodes of the DTs for SoCs where the drivers in question are
already used.
This should have no run-time effect at this time as the current
driver implementations use the same initialisation squeuences for
SoC-specific and R-Car fallback bindings for all the cases covered by
this patch-set.
Based on renesas-devel-20161212-v4.9
Simon Horman (13):
ARM: dts: r8a7779: Use R-Car Gen 1 fallback binding for i2c nodes
ARM: dts: r8a7778: Use R-Car Gen 1 fallback binding for i2c nodes
ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for i2c nodes
ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for i2c nodes
ARM: dts: r8a7792: Use R-Car Gen 2 fallback binding for i2c nodes
ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for i2c nodes
ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for i2c nodes
arm64: dts: r8a7795: Use R-Car Gen 3 fallback binding for i2c nodes
arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for i2c nodes
ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for i2c nodes
ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for i2c nodes
ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for i2c nodes
ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for i2c nodes
arch/arm/boot/dts/r8a7778.dtsi | 8 ++++----
arch/arm/boot/dts/r8a7779.dtsi | 8 ++++----
arch/arm/boot/dts/r8a7790.dtsi | 20 ++++++++++++--------
arch/arm/boot/dts/r8a7791.dtsi | 21 ++++++++++++---------
arch/arm/boot/dts/r8a7792.dtsi | 18 ++++++++++++------
arch/arm/boot/dts/r8a7793.dtsi | 21 ++++++++++++---------
arch/arm/boot/dts/r8a7794.dtsi | 18 ++++++++++--------
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 21 ++++++++++++++-------
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 21 ++++++++++++++-------
9 files changed, 94 insertions(+), 62 deletions(-)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* [PATCH renesas/devel 01/13] ARM: dts: r8a7779: Use R-Car Gen 1 fallback binding for i2c nodes
From: Simon Horman @ 2016-12-12 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-1-git-send-email-horms+renesas@verge.net.au>
Use recently added R-Car Gen 1 fallback binding for i2c nodes in
DT for r8a7779 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7779 and the
fallback binding for R-Car Gen 1.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7779.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 55a7c1e37c57..f47a0edc26d4 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -173,7 +173,7 @@
i2c0: i2c at ffc70000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7779";
+ compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc70000 0x1000>;
interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7779_CLK_I2C0>;
@@ -184,7 +184,7 @@
i2c1: i2c at ffc71000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7779";
+ compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc71000 0x1000>;
interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7779_CLK_I2C1>;
@@ -195,7 +195,7 @@
i2c2: i2c at ffc72000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7779";
+ compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc72000 0x1000>;
interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7779_CLK_I2C2>;
@@ -206,7 +206,7 @@
i2c3: i2c at ffc73000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7779";
+ compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc73000 0x1000>;
interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7779_CLK_I2C3>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH renesas/devel 02/13] ARM: dts: r8a7778: Use R-Car Gen 1 fallback binding for i2c nodes
From: Simon Horman @ 2016-12-12 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-1-git-send-email-horms+renesas@verge.net.au>
Use recently added R-Car Gen 1 fallback binding for i2c nodes in
DT for r8a7778 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7778 and the
fallback binding for R-Car Gen 1.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7778.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index b0c9674fad17..1e93c94a9eac 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -150,7 +150,7 @@
i2c0: i2c at ffc70000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7778";
+ compatible = "renesas,i2c-r8a7778", "renesas,rcar-gen1-i2c";
reg = <0xffc70000 0x1000>;
interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7778_CLK_I2C0>;
@@ -161,7 +161,7 @@
i2c1: i2c at ffc71000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7778";
+ compatible = "renesas,i2c-r8a7778", "renesas,rcar-gen1-i2c";
reg = <0xffc71000 0x1000>;
interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7778_CLK_I2C1>;
@@ -172,7 +172,7 @@
i2c2: i2c at ffc72000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7778";
+ compatible = "renesas,i2c-r8a7778", "renesas,rcar-gen1-i2c";
reg = <0xffc72000 0x1000>;
interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7778_CLK_I2C2>;
@@ -183,7 +183,7 @@
i2c3: i2c at ffc73000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7778";
+ compatible = "renesas,i2c-r8a7778", "renesas,rcar-gen1-i2c";
reg = <0xffc73000 0x1000>;
interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7778_CLK_I2C3>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH renesas/devel 03/13] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for i2c nodes
From: Simon Horman @ 2016-12-12 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-1-git-send-email-horms+renesas@verge.net.au>
Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7790 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7790 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7790.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index b7ed7466308b..823ab536175d 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -480,7 +480,7 @@
i2c0: i2c at e6508000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7790";
+ compatible = "renesas,i2c-r8a7790", "renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7790_CLK_I2C0>;
@@ -492,7 +492,7 @@
i2c1: i2c at e6518000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7790";
+ compatible = "renesas,i2c-r8a7790", "renesas,rcar-gen2-i2c";
reg = <0 0xe6518000 0 0x40>;
interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7790_CLK_I2C1>;
@@ -504,7 +504,7 @@
i2c2: i2c at e6530000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7790";
+ compatible = "renesas,i2c-r8a7790", "renesas,rcar-gen2-i2c";
reg = <0 0xe6530000 0 0x40>;
interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7790_CLK_I2C2>;
@@ -516,7 +516,7 @@
i2c3: i2c at e6540000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7790";
+ compatible = "renesas,i2c-r8a7790", "renesas,rcar-gen2-i2c";
reg = <0 0xe6540000 0 0x40>;
interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7790_CLK_I2C3>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox