* Re: [PATCH 6/6] ARM: configs: keystone_defconfig: Enable few peripheral drivers
From: Vignesh R @ 2017-12-04 9:00 UTC (permalink / raw)
To: santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org,
Santosh Shilimkar
Cc: Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <fb0c662b-d462-c663-7cf0-443ace3565ba-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Hi,
On Sunday 03 December 2017 09:30 AM, santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org wrote:
> On 11/22/17 11:51 PM, Vignesh R wrote:
>> Enable drivers for QSPI, LEDS, gpio-decoder that are present on 66AK2G
>> EVM
>> and 66AK2G ICE boards.
>>
>> Signed-off-by: Vignesh R <vigneshr-l0cyMroinI0@public.gmane.org>
>> ---
> Please submit a patch also to enable all these peripherals
> in multi-v7 config. Just enable all remainder
> options enabled in keystone config also in multi-v7.
K2 Platforms don't boot out of multi_v7_defconfig by default, because K2
platforms require CONFIG_ARM_LPAE(which is disabled in multi-v7).
If the intention is to just have all drivers enabled in
keystone_defconfig to be added to multi_v7, I can prepare a patch for
that and test with local patch to enable LPAE.
>
> Am pushing this series to next now.
>
Thanks!
--
Regards
Vignesh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 08/10] mfd: axp20x: add pinctrl cell for AXP813
From: Lee Jones @ 2017-12-04 9:02 UTC (permalink / raw)
To: Linus Walleij
Cc: Quentin Schulz, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Russell King, Maxime Ripard, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux ARM,
Thomas Petazzoni, linux-sunxi
In-Reply-To: <CACRpkdZJ3gDqnLVW0NZMJiF7qRJSu-0Usys0tKfT-aep4bRxjg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sat, 02 Dec 2017, Linus Walleij wrote:
> On Fri, Dec 1, 2017 at 2:44 PM, Quentin Schulz
> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> > As GPIO/pinctrl driver now supports AXP813, add a cell for it.
> >
> > Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>
> Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> It doesn't seem to have any dependencies so I guess Lee can simply
> apply this separately.
Yup! Although, I'd prefer to wait for the other patches in the set to
be applied. In the mean time:
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 2/2] regulator: sc2731: Add regulator driver to support Spreadtrum SC2731 PMIC
From: Erick Chen @ 2017-12-04 9:03 UTC (permalink / raw)
To: Mark Brown
Cc: robh+dt, mark.rutland, lgirdwood, linux-kernel, devicetree,
baolin.wang, baolin.wang
In-Reply-To: <201712020333.vB23X0mT082692@TPSPAM01.spreadtrum.com>
Hi Mark,
On Fri, Dec 01, 2017 at 01:01:37PM +0000, Mark Brown wrote:
> On Fri, Dec 01, 2017 at 04:58:16PM +0800, Erick Chen wrote:
>
> > +static const struct of_device_id sc2731_regulator_of_match[] = {
> > + {.compatible = "sprd,sc2731-regulator",},
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(of, sc2731_regulator_of_match);
>
> This looks like a subdriver for one specific device that can't be reused
> with anything else as it's specific to an individual device so I'd not
> expect it to appear as a separate thing in DT - the way Linux splits
> things up might not map well onto other OSs and may even change in
> future versions of Linux (look at all the audio drivers with clock
> controllers in them for example). I'd expect the MFD to just register
> the subdevice without needing it to appear in the DT.
>
Make sense, i will remove the of_device_id table in next version.
> > +subsys_initcall(sc2731_regulator_init);
> > +module_exit(sc2731_regulator_exit);
>
> Why not module_platform_driver()? Deferred probe should sort out probe
> order.
On some Spreadtrum old platforms, we need to power on the CPU cores ASAP.
But now this issue had been fixed after some investigation, so we can change
subsys_initcall() to module_init() level as you suggested.
Very appreciated for your helpful comments.
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: mc13xxx: Add the unit address to sysled
From: Lee Jones @ 2017-12-04 9:07 UTC (permalink / raw)
To: Fabio Estevam
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
Fabio Estevam
In-Reply-To: <1512165086-25512-1-git-send-email-festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, 01 Dec 2017, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
>
> As the 'reg' property is mandatory in the subnodes, improve the
> example by adding the unit address to the sysled node.
>
> This prevents the following build warning with W=1:
>
> Node /soc/aips@70000000/spba@70000000/ecspi@70010000/pmic@0/leds/sysled0 has a reg or ranges property, but no unit name
>
> Signed-off-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mfd/mc13xxx.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Why do I have 2 identical patches in my inbox?
> diff --git a/Documentation/devicetree/bindings/mfd/mc13xxx.txt b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
> index ac235fe..8261ea7 100644
> --- a/Documentation/devicetree/bindings/mfd/mc13xxx.txt
> +++ b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
> @@ -130,7 +130,7 @@ ecspi@70010000 { /* ECSPI1 */
> #size-cells = <0>;
> led-control = <0x000 0x000 0x0e0 0x000>;
>
> - sysled {
> + sysled@3 {
> reg = <3>;
> label = "system:red:live";
> linux,default-trigger = "heartbeat";
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: mc13xxx: Add the unit address to sysled
From: Fabio Estevam @ 2017-12-04 9:09 UTC (permalink / raw)
To: Lee Jones
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Fabio Estevam
In-Reply-To: <20171204090721.tgffux64kv3hecaq@dell>
On Mon, Dec 4, 2017 at 7:07 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Fri, 01 Dec 2017, Fabio Estevam wrote:
>
>> From: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
>>
>> As the 'reg' property is mandatory in the subnodes, improve the
>> example by adding the unit address to the sysled node.
>>
>> This prevents the following build warning with W=1:
>>
>> Node /soc/aips@70000000/spba@70000000/ecspi@70010000/pmic@0/leds/sysled0 has a reg or ranges property, but no unit name
>>
>> Signed-off-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/mfd/mc13xxx.txt | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Why do I have 2 identical patches in my inbox?
There was a typo in the mailing list address in the first one, sorry.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] regulator: sc2731: Add regulator driver to support Spreadtrum SC2731 PMIC
From: Erick Chen @ 2017-12-04 9:11 UTC (permalink / raw)
To: Philippe Ombredanne
Cc: Mark, Rob Herring, Mark Rutland, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
LKML, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
baolin.wang-QSEj5FYQhm4dnm+yROfE0A,
baolin.wang-lxIno14LUO0EEoCn2XhGlw
In-Reply-To: <CAOFm3uFWhOMy=0nibOjDP_vP+m7Dcf1cGOmXXgcrSy6PDfqEWQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Philippe,
On Fri, Dec 01, 2017 at 10:13:27AM +0100, Philippe Ombredanne wrote:
> Erik,
>
> On Fri, Dec 1, 2017 at 9:58 AM, Erick Chen <erick.chen-lxIno14LUO0EEoCn2XhGlw@public.gmane.org> wrote:
> > Add regulator driver for Spreadtrum SC2731 device.
> > It has 17 general purpose LDOs, BUCKs generator and
> > digital output to control regulators.
> >
> > Signed-off-by: Erick Chen <erick.chen-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
> > Reviewed-by: Baolin Wang <baolin.wang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
> > ---
> > drivers/regulator/Kconfig | 7 +
> > drivers/regulator/Makefile | 1 +
> > drivers/regulator/sc2731-regulator.c | 276 ++++++++++++++++++++++++++++++++++
> > 3 files changed, 284 insertions(+)
> > create mode 100644 drivers/regulator/sc2731-regulator.c
> >
> > diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> > index 96cd55f..b27417c 100644
> > --- a/drivers/regulator/Kconfig
> > +++ b/drivers/regulator/Kconfig
> > @@ -744,6 +744,13 @@ config REGULATOR_S5M8767
> > via I2C bus. S5M8767A have 9 Bucks and 28 LDOs output and
> > supports DVS mode with 8bits of output voltage control.
> >
> > +config REGULATOR_SC2731
> > + tristate "Spreadtrum SC2731 power regulator driver"
> > + depends on MFD_SC27XX_PMIC || COMPILE_TEST
> > + help
> > + This driver provides support for the voltage regulators on the
> > + SC2731 PMIC.
> > +
> > config REGULATOR_SKY81452
> > tristate "Skyworks Solutions SKY81452 voltage regulator"
> > depends on MFD_SKY81452
> > diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
> > index 80ffc57..19fea09 100644
> > --- a/drivers/regulator/Makefile
> > +++ b/drivers/regulator/Makefile
> > @@ -95,6 +95,7 @@ obj-$(CONFIG_REGULATOR_RT5033) += rt5033-regulator.o
> > obj-$(CONFIG_REGULATOR_S2MPA01) += s2mpa01.o
> > obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
> > obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
> > +obj-$(CONFIG_REGULATOR_SC2731) += sc2731-regulator.o
> > obj-$(CONFIG_REGULATOR_SKY81452) += sky81452-regulator.o
> > obj-$(CONFIG_REGULATOR_STM32_VREFBUF) += stm32-vrefbuf.o
> > obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
> > diff --git a/drivers/regulator/sc2731-regulator.c b/drivers/regulator/sc2731-regulator.c
> > new file mode 100644
> > index 0000000..e56448a
> > --- /dev/null
> > +++ b/drivers/regulator/sc2731-regulator.c
> > @@ -0,0 +1,276 @@
> > +/*
> > + * Copyright (C) 2017 Spreadtrum Communications Inc.
> > + *
> > + * SPDX-License-Identifier: GPL-2.0
> > + */
>
> I think that per Linus, and Thomas doc patches for SPDX ids this
> should be instead either:
>
> > +// SPDX-License-Identifier: GPL-2.0
> > + // Copyright (c) 2017 Spreadtrum Communications Inc.
>
> or at least this with the id on the first and the // comment style
>
Thanks for pointing out this, and I will modify them in next version.
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017 Spreadtrum Communications Inc.
> > + *
> > + */
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] ARM64: dts: meson-axg: add PWM DT info for Meson-Axg SoC
From: Jerome Brunet @ 2017-12-04 9:17 UTC (permalink / raw)
To: Yixun Lan, Thierry Reding, Kevin Hilman, linux-pwm, linux-amlogic
Cc: Rob Herring, devicetree, Neil Armstrong, Mark Rutland,
Carlo Caione, Jian Hu, linux-arm-kernel, linux-kernel
In-Reply-To: <20171204060018.8856-4-yixun.lan@amlogic.com>
On Mon, 2017-12-04 at 14:00 +0800, Yixun Lan wrote:
> From: Jian Hu <jian.hu@amlogic.com>
>
> Add PWM DT info for the Amlogic's Meson-Axg SoC.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 120
> +++++++++++++++++++++++++++++
> 1 file changed, 120 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index 92f65eec3e18..f7f228701df1 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -177,6 +177,24 @@
>
[...]
>
> @@ -435,6 +537,24 @@
> clock-names = "clk_i2c";
> };
>
> + pwm_AO_ab: pwm@7000 {
> + compatible = "amlogic,meson-axg-ao-pwm";
> + reg = <0x0 0x07000 0x0 0x20>;
> + #pwm-cells = <3>;
> + clocks = <&xtal>, <&xtal>;
> + clock-names = "clkin0", "clkin1";
like gxbb, "amlogic,meson-axg-ao-pwm" does not have such clock bindings,
Later on, if we want to "correctly" get the clock from DT, it will have to gothrough a new compatible, I guess.
> + status = "disabled";
> + };
> +
> + pwm_AO_cd: pwm@2000 {
> + compatible = "amlogic,axg-ao-pwm";
> + reg = <0x0 0x02000 0x0 0x20>;
> + #pwm-cells = <3>;
> + clocks = <&xtal>, <&xtal>;
> + clock-names = "clkin0", "clkin1";
> + status = "disabled";
> + };
> +
> uart_AO: serial@3000 {
> compatible = "amlogic,meson-gx-uart",
> "amlogic,meson-ao-uart";
> reg = <0x0 0x3000 0x0 0x18>;
^ permalink raw reply
* Re: [PATCH 1/3] eeprom: at25: Add DT support for EEPROMs with odd address bits
From: Geert Uytterhoeven @ 2017-12-04 9:17 UTC (permalink / raw)
To: Ivo Sieben
Cc: Arnd Bergmann, Greg Kroah-Hartman, Rob Herring, Mark Rutland,
Chris Wright, Wolfram Sang, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1512048586-17534-2-git-send-email-geert+renesas@glider.be>
On Thu, Nov 30, 2017 at 2:29 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Certain EEPROMS have a size that is larger than the number of address
> bytes would allow, and store the MSB of the address in bit 3 of the
> instruction byte.
>
> This can be described in platform data using EE_INSTR_BIT3_IS_ADDR, or
> in DT using the obsolete legacy "at25,addr-mode" property.
> But currently there exists no non-deprecated way to describe this in DT.
>
> Hence extend the existing "address-width" DT property to allow
> specifying 9, 17, or 25 address bits, and enable support for that in the
> driver.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> EEPROMs using 9 address bits are common (e.g. M95040, 25AA040/25LC040).
> Do EEPROMs using 17 or 25 address bits, as mentioned in
> include/linux/spi/eeprom.h, really exist?
> Or should we just limit it to a single odd value (9 bits)?
At least for the real Atmel parts, only the AT25040 part uses odd (8 +
1 bit) addressing.
AT25M01 uses 3-byte addressing (it needs 17 bits).
So I tend to believe EEPROMs using 16 + 1 or 24 + 1 address bits (with the
extra bit in the instruction byte) do not exist?
> ---
> Documentation/devicetree/bindings/eeprom/at25.txt | 4 +++-
> drivers/misc/eeprom/at25.c | 4 ++++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/eeprom/at25.txt b/Documentation/devicetree/bindings/eeprom/at25.txt
> index 1d3447165c374f67..d00779e4ab4377b9 100644
> --- a/Documentation/devicetree/bindings/eeprom/at25.txt
> +++ b/Documentation/devicetree/bindings/eeprom/at25.txt
> @@ -6,7 +6,9 @@ Required properties:
> - spi-max-frequency : max spi frequency to use
> - pagesize : size of the eeprom page
> - size : total eeprom size in bytes
> -- address-width : number of address bits (one of 8, 16, or 24)
> +- address-width : number of address bits (one of 8, 9, 16, 17, 24, or 25).
> + For odd values, the MSB of the address is sent as bit 3 of the instruction
> + byte, before the address byte(s).
Alternatively, we can drop the binding change, i.e. keep on using
address-width = <8> for 512-byte '040...
> Optional properties:
> - spi-cpha : SPI shifted clock phase, as per spi-bus bindings.
> diff --git a/drivers/misc/eeprom/at25.c b/drivers/misc/eeprom/at25.c
> index 5afe4cd165699060..a50a0f16fa0e1d1d 100644
> --- a/drivers/misc/eeprom/at25.c
> +++ b/drivers/misc/eeprom/at25.c
> @@ -275,6 +275,10 @@ static int at25_fw_to_chip(struct device *dev, struct spi_eeprom *chip)
> "Error: missing \"address-width\" property\n");
> return -ENODEV;
> }
> + if (val & 1) {
> + chip->flags |= EE_INSTR_BIT3_IS_ADDR;
> + val -= 1;
> + }
... and handle it here like:
if (chip->byte_len == 2U << val)
chip->flags |= EE_INSTR_BIT3_IS_ADDR;
However, that would IMHO be a bit confusing, as the "address-width"
property is no longer the real address width, but indicates how many bits
are specified in address bytes sent after the read/write command.
So "address-bytes" = 1, 2, or 3 would be more correct ;-)
Or deprecate this whole "specify parameters using DT properties" business,
and derive them from the compatible value. But that would mean adding a
large and ever growing table to an old driver...
Thoughts?
Thanks again!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/6] cpufreq: sort the drivers in ARM part
From: Viresh Kumar @ 2017-12-04 9:18 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Rafael J. Wysocki, linux-pm, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Rob Herring, devicetree, Thomas Petazzoni,
linux-arm-kernel, Antoine Tenart, Miquèl Raynal,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits, Evan Wang
In-Reply-To: <20171201112508.14121-4-gregory.clement@free-electrons.com>
On 01-12-17, 12:25, Gregory CLEMENT wrote:
> Keep the driver files alphabetically sorted.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> drivers/cpufreq/Makefile | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 812f9e0d01a3..d762e76887e7 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -53,22 +53,24 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ) += arm_big_little.o
> obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o
>
> obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ) += brcmstb-avs-cpufreq.o
> +obj-$(CONFIG_ACPI_CPPC_CPUFREQ) += cppc_cpufreq.o
Shouldn't we add them in ascending order of the whole config name and not just
CPPC_CPUFREQ ?
--
viresh
^ permalink raw reply
* [RESEND PATCH v5 2/6] dt-bindings: Add vendor prefix for Solomon Goldentek Display Corporation
From: Neil Armstrong @ 2017-12-04 9:21 UTC (permalink / raw)
To: shawnguo, kernel, fabio.estevam
Cc: Neil Armstrong, linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <1512379270-27436-1-git-send-email-narmstrong@baylibre.com>
Solomon Goldentek Display Corporation is a Taiwanese LCD/LCM manufacturer.
Company Site: http://www.goldentek.com.tw
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 0994bdd..b0d3bef 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -305,6 +305,7 @@ seagate Seagate Technology PLC
semtech Semtech Corporation
sensirion Sensirion AG
sff Small Form Factor Committee
+sgd Solomon Goldentek Display Corporation
sgx SGX Sensortech
sharp Sharp Corporation
shimafuji Shimafuji Electric, Inc.
--
2.7.4
^ permalink raw reply related
* [RESEND PATCH v5 3/6] dt-bindings: display: Add bindings for SGD GKTW70SDAE4SE Panel
From: Neil Armstrong @ 2017-12-04 9:21 UTC (permalink / raw)
To: shawnguo, kernel, fabio.estevam
Cc: devicetree, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <1512379270-27436-1-git-send-email-narmstrong@baylibre.com>
The GKTW70SDAE4SE is an LVDS display panel.
Their bindings are modelled on the the LVDS panel bindings.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/display/panel/sgd,gktw70sdae4se.txt | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt
diff --git a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt
new file mode 100644
index 0000000..d06644b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt
@@ -0,0 +1,41 @@
+Solomon Goldentek Display GKTW70SDAE4SE LVDS Display Panel
+==========================================================
+
+The GKTW70SDAE4SE is a 7" WVGA TFT-LCD display panel.
+
+These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
+with the following device-specific properties.
+
+Required properties:
+
+- compatible: Shall contain "sgd,gktw70sdae4se" and "panel-lvds", in that order.
+
+Example
+-------
+
+panel {
+ compatible = "sgd,gktw70sdae4se", "panel-lvds";
+
+ width-mm = <153>;
+ height-mm = <86>;
+
+ data-mapping = "jeida-18";
+
+ panel-timing {
+ clock-frequency = <32000000>;
+ hactive = <800>;
+ vactive = <480>;
+ hback-porch = <39>;
+ hfront-porch = <39>;
+ vback-porch = <29>;
+ vfront-porch = <13>;
+ hsync-len = <47>;
+ vsync-len = <2>;
+ };
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds_encoder>;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 3/3] ARM64: dts: meson-axg: add PWM DT info for Meson-Axg SoC
From: Jerome Brunet @ 2017-12-04 9:29 UTC (permalink / raw)
To: Yixun Lan, Thierry Reding, Kevin Hilman,
linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA, Neil Armstrong,
Mark Rutland, Carlo Caione, Jian Hu,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512379059.2574.17.camel-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Mon, 2017-12-04 at 10:17 +0100, Jerome Brunet wrote:
> On Mon, 2017-12-04 at 14:00 +0800, Yixun Lan wrote:
> > From: Jian Hu <jian.hu-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
> >
> > Add PWM DT info for the Amlogic's Meson-Axg SoC.
> >
> > Signed-off-by: Jian Hu <jian.hu-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
> > Signed-off-by: Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
> > ---
> > arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 120
> > +++++++++++++++++++++++++++++
> > 1 file changed, 120 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > index 92f65eec3e18..f7f228701df1 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > @@ -177,6 +177,24 @@
> >
>
> [...]
>
> >
> > @@ -435,6 +537,24 @@
> > clock-names = "clk_i2c";
> > };
> >
> > + pwm_AO_ab: pwm@7000 {
> > + compatible = "amlogic,meson-axg-ao-pwm";
> > + reg = <0x0 0x07000 0x0 0x20>;
> > + #pwm-cells = <3>;
> > + clocks = <&xtal>, <&xtal>;
> > + clock-names = "clkin0", "clkin1";
>
> like gxbb, "amlogic,meson-axg-ao-pwm" does not have such clock bindings,
> Later on, if we want to "correctly" get the clock from DT, it will have to
> gothrough a new compatible, I guess.
Please ignore this comment (monday morning...)
However clock bindings for this should be defined in the board dts, not the soc
one
>
> > + status = "disabled";
> > + };
> > +
> > + pwm_AO_cd: pwm@2000 {
> > + compatible = "amlogic,axg-ao-pwm";
> > + reg = <0x0 0x02000 0x0 0x20>;
> > + #pwm-cells = <3>;
> > + clocks = <&xtal>, <&xtal>;
> > + clock-names = "clkin0", "clkin1";
> > + status = "disabled";
> > + };
> > +
> > uart_AO: serial@3000 {
> > compatible = "amlogic,meson-gx-uart",
> > "amlogic,meson-ao-uart";
> > reg = <0x0 0x3000 0x0 0x18>;
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: usb: add DT binding for RK3328 dwc3 controller
From: Heiko Stuebner @ 2017-12-04 9:40 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
balbi-DgEjT+Ai2ygdnm+yROfE0A
Cc: william.wu-TNX95d0MmH7DzftRWevZcw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Heiko Stuebner
From: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Adds the device tree bindings description for RK3328 and
compatible USB DWC3 controller.
Signed-off-by: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
---
changes in v2:
- add Rob's Ack
Ideally usb maintainers would pick up this patch to the binding
document and I'll take the devicetree changes after that.
But if so desired, I can also pick up the binding change myself
but would need an Ack for that.
Documentation/devicetree/bindings/usb/rockchip,dwc3.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
index 50a31536e975..2c3f6a467fda 100644
--- a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
@@ -1,7 +1,9 @@
Rockchip SuperSpeed DWC3 USB SoC controller
Required properties:
-- compatible: should contain "rockchip,rk3399-dwc3" for rk3399 SoC
+- compatible: should be one of the following:
+ - "rockchip,rk3399-dwc3": for rk3399 SoC
+ - "rockchip,rk3328-dwc3", "rockchip,rk3399-dwc3": for rk3328 SoC
- clocks: A list of phandle + clock-specifier pairs for the
clocks listed in clock-names
- clock-names: Should contain the following:
--
2.14.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 2/4] arm64: dts: rockchip: add usb3 controller node for RK3328 SoCs
From: Heiko Stuebner @ 2017-12-04 9:40 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
balbi-DgEjT+Ai2ygdnm+yROfE0A
Cc: william.wu-TNX95d0MmH7DzftRWevZcw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Heiko Stuebner
In-Reply-To: <20171204094041.25439-1-heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
From: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
RK3328 has one USB 3.0 OTG controller which uses DWC_USB3
core's general architecture. It can act as static xHCI host
controller, static device controller, USB 3.0/2.0 OTG basing
on ID of USB3.0 PHY.
Signed-off-by: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
---
changes in v2:
none
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 41d61840fb99..cafc572a68e0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -805,6 +805,33 @@
status = "disabled";
};
+ usbdrd3: usb@ff600000 {
+ compatible = "rockchip,rk3328-dwc3", "rockchip,rk3399-dwc3";
+ clocks = <&cru SCLK_USB3OTG_REF>, <&cru SCLK_USB3OTG_SUSPEND>,
+ <&cru ACLK_USB3OTG>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+
+ usbdrd_dwc3: dwc3@ff600000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xff600000 0x0 0x100000>;
+ interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
+ dr_mode = "otg";
+ phy_type = "utmi_wide";
+ snps,dis_enblslpm_quirk;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis_u2_susphy_quirk;
+ snps,dis_u3_susphy_quirk;
+ snps,dis-del-phy-power-chg-quirk;
+ snps,dis-tx-ipgap-linecheck-quirk;
+ status = "disabled";
+ };
+ };
+
gic: interrupt-controller@ff811000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
--
2.14.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 3/4] arm64: dts: rockchip: enable usb3 for RK3328 evaluation board
From: Heiko Stuebner @ 2017-12-04 9:40 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
balbi-DgEjT+Ai2ygdnm+yROfE0A
Cc: william.wu-TNX95d0MmH7DzftRWevZcw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Heiko Stuebner
In-Reply-To: <20171204094041.25439-1-heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
From: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Rockchip's RK3328 evaluation board has one USB 3.0 OTG controller,
we enable it and set it act as static xHCI host controller to
support USB 3.0 HOST on RK3328 evaluation board.
Signed-off-by: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
---
changes in v2:
none
arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
index 3d551e3e6c23..95fba84239a7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
@@ -306,3 +306,12 @@
&usb_host0_ohci {
status = "okay";
};
+
+&usbdrd3 {
+ status = "okay";
+};
+
+&usbdrd_dwc3 {
+ dr_mode = "host";
+ status = "okay";
+};
--
2.14.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 4/4] arm64: dts: rockchip: enable usb3 nodes on rk3328-rock64
From: Heiko Stuebner @ 2017-12-04 9:40 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
balbi-DgEjT+Ai2ygdnm+yROfE0A
Cc: william.wu-TNX95d0MmH7DzftRWevZcw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Heiko Stuebner
In-Reply-To: <20171204094041.25439-1-heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
Enable the nodes to make the usb3 port usable on that board.
Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
---
changes in v2:
- new patch
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index d4f80786e7c2..e393c3586c11 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -331,3 +331,12 @@
&usb_host0_ohci {
status = "okay";
};
+
+&usbdrd3 {
+ status = "okay";
+};
+
+&usbdrd_dwc3 {
+ dr_mode = "host";
+ status = "okay";
+};
--
2.14.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2 1/4] dt-bindings: usb: add DT binding for RK3328 dwc3 controller
From: Heiko Stuebner @ 2017-12-04 9:42 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: balbi-DgEjT+Ai2ygdnm+yROfE0A, william.wu-TNX95d0MmH7DzftRWevZcw,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171204094041.25439-1-heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
Am Montag, 4. Dezember 2017, 10:40:38 CET schrieb Heiko Stuebner:
> From: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> Adds the device tree bindings description for RK3328 and
> compatible USB DWC3 controller.
>
> Signed-off-by: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
> ---
> changes in v2:
> - add Rob's Ack
>
> Ideally usb maintainers would pick up this patch to the binding
> document and I'll take the devicetree changes after that.
>
> But if so desired, I can also pick up the binding change myself
> but would need an Ack for that.
just realized, the last version from august was actually v3, so this
should be v4, not v2 ... sorry about that.
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.
From: Yong @ 2017-12-04 9:45 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Greg Kroah-Hartman, David S. Miller, Hans Verkuil, Arnd Bergmann,
Hugues Fruchet, Yannick Fertre, Philipp Zabel, Benoit Parrot,
Benjamin Gaignard, Jean-Christophe Trotin,
Ramesh Shanmugasundaram, Minghsiu Tsai, Krzysztof Kozlowski,
Robert Jarzmik, linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-sun
In-Reply-To: <20171125160233.skefdpkjy4peh7et-ZC1Zs529Oq4@public.gmane.org>
Hi Maxime,
I just noticed that you are using the second iteration?
Have you received my third iteration?
On Sat, 25 Nov 2017 17:02:33 +0100
Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Thu, Nov 23, 2017 at 09:14:44AM +0800, Yong wrote:
> > > On Wed, Nov 22, 2017 at 09:33:06AM +0800, Yong wrote:
> > > > > On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote:
> > > > > > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > > > > > and CSI1 is used for parallel interface. This is not documented in
> > > > > > datasheet but by testing and guess.
> > > > > >
> > > > > > This patch implement a v4l2 framework driver for it.
> > > > > >
> > > > > > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > > > > > ISP's support are not included in this patch.
> > > > > >
> > > > > > Signed-off-by: Yong Deng <yong.deng-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
> > > > >
> > > > > Thanks again for this driver.
> > > > >
> > > > > It seems like at least this iteration is behaving in a weird way with
> > > > > DMA transfers for at least YU12 and NV12 (and I would assume YV12).
> > > > >
> > > > > Starting a transfer of multiple frames in either of these formats,
> > > > > using either ffmpeg (ffmpeg -f v4l2 -video_size 640x480 -framerate 30
> > > > > -i /dev/video0 output.mkv) or yavta (yavta -c80 -p -F --skip 0 -f NV12
> > > > > -s 640x480 $(media-c tl -e 'sun6i-csi')) will end up in a panic.
> > > > >
> > > > > The panic seems to be generated with random data going into parts of
> > > > > the kernel memory, the pattern being in my case something like
> > > > > 0x8287868a which is very odd (always around 0x88)
> > > > >
> > > > > It turns out that when you cover the sensor, the values change to
> > > > > around 0x28, so it really seems like it's pixels that have been copied
> > > > > there.
> > > > >
> > > > > I've looked quickly at the DMA setup, and it seems reasonable to
> > > > > me. Do you have the same issue on your side? Have you been able to
> > > > > test those formats using your hardware?
> > > >
> > > > I had tested the following formats with BT1120 input:
> > > > V4L2_PIX_FMT_NV12 -> NV12
> > > > V4L2_PIX_FMT_NV21 -> NV21
> > > > V4L2_PIX_FMT_NV16 -> NV16
> > > > V4L2_PIX_FMT_NV61 -> NV61
> > > > V4L2_PIX_FMT_YUV420 -> YU12
> > > > V4L2_PIX_FMT_YVU420 -> YV12
> > > > V4L2_PIX_FMT_YUV422P -> 422P
> > > > And they all work fine.
> > >
> > > Ok, that's good to know.
> > >
> > > > > Given that they all are planar formats and YUYV and the likes work
> > > > > just fine, maybe we can leave them aside for now?
> > > >
> > > > V4L2_PIX_FMT_YUV422P and V4L2_PIX_FMT_YUYV is OK, and V4L2_PIX_FMT_NV12
> > > > is bad? It's really weird.
> > > >
> > > > What's your input bus code format, type and width?
> > >
> > > The sensor is an ov5640, so the MBUS code for the bus is
> > > MEDIA_BUS_FMT_YUYV8_2X8.
> >
> > Did you test on V3s?
>
> No, this is on an H3, but that would be the first difference so far.
>
> > I haven't tested it with MEDIA_BUS_FMT_YUYV8_2X8.
>
> Ok, it's good to know that at least it works on your end, it's useful
> for us to debug things :)
>
> > The Allwinner CSI's DMA is definitely weird. Ondřej Jirman thought
> > that CSI has an internal queue (Ondřej's commit has explained in detail).
> > I think CSI just pick up the buffer address before the frame done
> > interrupt triggered.
> > The patch in attachment can deal with this. You can see if it is
> > useful to solve your problem.
>
> I'll test that on monday, thanks!
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Thanks,
Yong
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v6 03/17] mfd: madera: Add common support for Cirrus Logic Madera codecs
From: Richard Fitzgerald @ 2017-12-04 9:47 UTC (permalink / raw)
To: Linus Walleij
Cc: Alexandre Courbot, alsa-devel, Jason Cooper,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:WOLFSON MICROELECTRONICS DRIVERS,
linux-kernel@vger.kernel.org, Rob Herring, linux-gpio, Mark Brown,
Thomas Gleixner, Lee Jones, Charles Keepax, Nikesh Oswal
In-Reply-To: <CACRpkdZ4QuOhk1LuGftcFozUKdZ4vFAO3omkQ004k39J=jKL7g@mail.gmail.com>
On 02/12/17 12:10, Linus Walleij wrote:
> On Wed, Nov 29, 2017 at 12:36 PM, Richard Fitzgerald
> <rf@opensource.wolfsonmicro.com> wrote:
>> On 29/11/17 10:18, Linus Walleij wrote:
>>>
>>> On Thu, Nov 23, 2017 at 6:13 PM, Richard Fitzgerald
>>> <rf@opensource.wolfsonmicro.com> wrote:
>>>
>>>> +config MFD_MADERA_I2C
>>>> + bool "Cirrus Logic Madera codecs with I2C"
>>>> + select MFD_MADERA
>>>> + select REGMAP_I2C
>>>> + depends on I2C
>>>> + depends on PINCTRL
>>>> + help
>>>> + Support for the Cirrus Logic Madera platform audio SoC
>>>> + core functionality controlled via I2C.
>>>> +
>>>> +config MFD_MADERA_SPI
>>>> + bool "Cirrus Logic Madera codecs with SPI"
>>>> + select MFD_MADERA
>>>> + select REGMAP_SPI
>>>> + depends on SPI_MASTER
>>>> + depends on PINCTRL
>>>> + help
>>>> + Support for the Cirrus Logic Madera platform audio SoC
>>>> + core functionality controlled via SPI.
>>>
>>>
>>> Why do the I2C and SPI subdrivers depend on PINCTRL?
>>>
>>> They sure don't seem to be using any pinctrl-specific APIs.
>>>
>>
>> They require PINCTRL even if they don't call any functions on it because the
>> chip won't work correctly if there isn't a PINCTRL driver to apply the
>> correct pinmux configuration.
>
> Apply the configuration to what? Sorry I don't get it.
>
> You can't be referring to the internal pin controller of the Madera, since
Yes I am
> that has to come up before its pin controller can even be communicated
> with.
So?
The MFD driver powers up the chip before registering child drivers.
Also that's not entirely relevant, the pinctrl settings can still be
written with the chip off because they will go into the regmap cache and
be applied when the chip is next resumed.
>
> If you mean it is to apply the configuration to the system SoC where
> this coded is connected, this is wrong. There may very well be systems
> which have dedicated pins for the codec, atleast in theory. The fact
> that your reference board needs this is not a universal requirement,
> it should be set up in the machine-specific Kconfig for the reference
> board in that case.
>
> Yours,
> Linus Walleij
>
^ permalink raw reply
* Re: [PATCH] iio: accel: bmc150: Add OF device ID table
From: Hans de Goede @ 2017-12-04 9:47 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Javier Martinez Canillas, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Hartmut Knaack, linux-iio-u79uwXL29TY76Z2rM5mHXA,
Lars-Peter Clausen, Jonathan Cameron, Peter Meerwald-Stadler,
devicetree-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang
In-Reply-To: <20171204092259.00006250-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Hi,
On 04-12-17 10:44, Jonathan Cameron wrote:
> On Mon, 4 Dec 2017 09:29:38 +0100
> Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
>> Hi,
>>
>> On 01-12-17 12:10, Javier Martinez Canillas wrote:
>>> The driver doesn't have a struct of_device_id table but supported devices
>>> are registered via Device Trees. This is working on the assumption that a
>>> I2C device registered via OF will always match a legacy I2C device ID and
>>> that the MODALIAS reported will always be of the form i2c:<device>.
>>>
>>> But this could change in the future so the correct approach is to have an
>>> OF device ID table if the devices are registered via OF.
>>>
>>> The I2C device ID table entries have the .driver_data field set, but they
>>> are not used in the driver so weren't set in the OF device table entries.
>>>
>>> Signed-off-by: Javier Martinez Canillas <javierm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>> ---
>>>
>>> drivers/iio/accel/bmc150-accel-i2c.c | 12 ++++++++++++
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/iio/accel/bmc150-accel-i2c.c b/drivers/iio/accel/bmc150-accel-i2c.c
>>> index f85014fbaa12..8ffc308d5fd0 100644
>>> --- a/drivers/iio/accel/bmc150-accel-i2c.c
>>> +++ b/drivers/iio/accel/bmc150-accel-i2c.c
>>> @@ -81,9 +81,21 @@ static const struct i2c_device_id bmc150_accel_id[] = {
>>>
>>> MODULE_DEVICE_TABLE(i2c, bmc150_accel_id);
>>>
>>> +static const struct of_device_id bmc150_accel_of_match[] = {
>>> + { .compatible = "bosch,bmc150_accel" },
>>> + { .compatible = "bosch,bmi055_accel" },
>>
>> These look a bit weird, there is no reason to mirror the i2c_device_ids
>
> There has been a steady move for a long time to add these IDs with the plan
> that we would stop automatically matching against the manufacturer free
> i2c IDs. Mostly on the basis that was a hack that brought a lot
> of effectively unreviewed device tree bindings. As I understand it the
> eventual plan is to be able to get rid of that old path entirely...
> +CC Wolfram to see what his view is on this.
>
>> here and typically for devicetree / of we only list
>> the chip model without some postfix like _accel.
>>
>
> There is a reason for this and we've been round the houses a few times before
> with the (admittedly horrible) conclusion that we don't really have a better way.
>
> These are multiple chips in one package wired to the same i2c bus
> there is no sensible way of telling the kernel that we actually
> have two separate devices with the same part number. We could just declare
> that we will only support them under the IDs of the individual chips but,
> without scraping datasheets it's very difficult to tell which two parts
> have been combined in a given SKU (some manufacturers document this - some
> don't and we just have to figure it out).
Ack, Javier pointed this out to me too and you're both right :)
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v8 28/28] rcar-vin: enable support for r8a77970
From: Hans Verkuil @ 2017-12-04 9:48 UTC (permalink / raw)
To: Niklas Söderlund, Laurent Pinchart,
linux-media-u79uwXL29TY76Z2rM5mHXA
Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
tomoharu.fukawa.eb-zM6kxYcvzFBBDgjK7y7TUQ, Kieran Bingham,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171129194342.26239-29-niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org>
On 11/29/2017 08:43 PM, Niklas Söderlund wrote:
> Add the SoC specific information for Renesas r8a77970.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org>
Reviewed-by: Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
Regards,
Hans
> ---
> .../devicetree/bindings/media/rcar_vin.txt | 1 +
> drivers/media/platform/rcar-vin/rcar-core.c | 40 ++++++++++++++++++++++
> 2 files changed, 41 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index 314743532bbb4523..6b98f8a3398fa493 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -21,6 +21,7 @@ on Gen3 to a CSI-2 receiver.
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> - "renesas,vin-r8a7796" for the R8A7796 device
> + - "renesas,vin-r8a77970" for the R8A77970 device
> - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
> device.
> - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c
> index 62eb89b36fbb2ee1..bbdf36b5c3c8178d 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -1145,6 +1145,42 @@ static const struct rvin_info rcar_info_r8a7796 = {
> },
> };
>
> +static const struct rvin_info rcar_info_r8a77970 = {
> + .chip = RCAR_GEN3,
> + .use_mc = true,
> + .max_width = 4096,
> + .max_height = 4096,
> +
> + .num_chsels = 5,
> + .chsels = {
> + {
> + { .csi = RVIN_CSI40, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + }, {
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 1 },
> + { .csi = RVIN_NC, .chan = 0 },
> + }, {
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 2 },
> + { .csi = RVIN_NC, .chan = 0 },
> + }, {
> + { .csi = RVIN_CSI40, .chan = 1 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_NC, .chan = 0 },
> + { .csi = RVIN_CSI40, .chan = 3 },
> + { .csi = RVIN_NC, .chan = 0 },
> + },
> + },
> +};
> +
> static const struct of_device_id rvin_of_id_table[] = {
> {
> .compatible = "renesas,vin-r8a7778",
> @@ -1182,6 +1218,10 @@ static const struct of_device_id rvin_of_id_table[] = {
> .compatible = "renesas,vin-r8a7796",
> .data = &rcar_info_r8a7796,
> },
> + {
> + .compatible = "renesas,vin-r8a77970",
> + .data = &rcar_info_r8a77970,
> + },
> { },
> };
> MODULE_DEVICE_TABLE(of, rvin_of_id_table);
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: Add optional nvmem MAC address bindings to ti,wlink-st
From: Sergei Shtylyov @ 2017-12-04 9:54 UTC (permalink / raw)
To: David Lechner, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
Cc: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512357682-8911-2-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
Hello!
On 12/4/2017 6:21 AM, David Lechner wrote:
> This adds optional nvmem consumer properties to the ti,wlink-st device tree
> bindings to allow specifying the Bluetooth MAC address.
>
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/ti,wilink-st.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/ti,wilink-st.txt b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> index 1649c1f..24eb897 100644
> --- a/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> +++ b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> @@ -32,6 +32,8 @@ Optional properties:
> See ../clocks/clock-bindings.txt for details.
> - clock-names : Must include the following entry:
> "ext_clock" (External clock provided to the TI combo chip).
> + - nvmem-cells: phandle to nvmem data cell that contains a MAC address
> + - nvmem-cell-names: "mac-address" (required when nvmem-cells is specified)
>
> Example:
>
> @@ -43,5 +45,7 @@ Example:
> enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
> clocks = <&clk32k_wl18xx>;
> clock-names = "ext_clock";
> + nvmem-cells: <&mac_address>
s/:/ = /?
> + nvmem-cell-names "mac-address"
Where's =?
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: renesas: r8a77970: use CPG core clock macros
From: Geert Uytterhoeven @ 2017-12-04 10:00 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
Linux-Renesas, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Magnus Damm, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20171128202105.552196002-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On Tue, Nov 28, 2017 at 9:15 PM, Sergei Shtylyov
<sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> wrote:
> Now that the commit ecadea00f588 ("dt-bindings: clock: Add R8A77970 CPG
> core clock definitions") has hit Linus' tree, we can replace the bare
> numbers (we had to use to avoid a cross tree dependency) with these macro
> definitions...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: renesas: r8a77970: use SYSC power domain macros
From: Geert Uytterhoeven @ 2017-12-04 10:02 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
Linux-Renesas, devicetree@vger.kernel.org, Magnus Damm,
Mark Rutland, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20171128202109.031715810@cogentembedded.com>
On Tue, Nov 28, 2017 at 9:15 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Now that the commit 833bdb47c826 ("dt-bindings: power: add R8A77970 SYSC
> power domain definitions") has hit Linus' tree, we can replace the bare
> numbers (we had to use to avoid a cross tree dependency) with these macro
> definitions...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxm: fix q200 interrupt number
From: Jerome Brunet @ 2017-12-04 10:05 UTC (permalink / raw)
To: Kevin Hilman, Martin Blumenstingl
Cc: Jerome Brunet, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Correct the interrupt number assigned to the Realtek PHY in the q200
Fixes: b94d22d94ad2 ("ARM64: dts: meson-gx: add external PHY interrupt on some platforms")
Reported-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Signed-off-by: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
This change depends on the related series from Martin [0]
Thanks for catching it Martin !
[0]: https://lkml.kernel.org/r/20171202214037.17017-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org
arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts
index 9847fce443a8..388fac4f2d97 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts
@@ -111,8 +111,8 @@
reg = <0>;
max-speed = <1000>;
interrupt-parent = <&gpio_intc>;
- /* MAC_INTR on GPIOH_3 */
- interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+ /* MAC_INTR on GPIOZ_15 */
+ interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
};
};
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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