* [PATCH v4 00/12] Armada thermal: improvements and A7K/A8K SoCs support
From: Miquel Raynal @ 2017-12-18 14:36 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Catalin Marinas, Will Deacon
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Antoine Tenart, Nadav Haklai, Miquel Raynal,
Baruch Siach, David Sniatkiwicz
Hi,
This series takes over Baruch's series by integrating his patches about
supporting thermal on Armada 7K and 8K SoCs within a larger series with
several improvements on the armada_thermal.c driver.
For now, Armada 380 and CP110 compatibles share the same initialization
routine but this will probably change in the near future when adding
support for overheat interrupts.
DT bindings documentation is updated to match existing code.
Armada AP806 and CP110 DT are also updated with thermal nodes.
Thank you,
Miquèl
Changes since v3:
- Added Gregory's Reviewed-by tags
- Detailed what I have changed over Baruch's series in the commit logs
- Removed the list of every supported SoC, used "Marvell EBU Armada
SoCs" instead as suggested by Thomas (unless for the Kconfig
description, where having the list is useful).
- Changed the comment about the Armada 380 reset section in the
armada380_init() callback.
- Removed the freshly introduced marvell,thermal-zone-name property in
favor of the use of dev_name(dev) to name the thermal zone.
- Introduced the needs_control0 capability and removed checks in the
init routines (probe will fail if the bindings used are not
appropriate).
- Changed coefficients type to s64 to handle signed values, as well as
some local variables around in the get_temp() callback
- Used a do_div() instead of the traditionnal "/" to handle 64-bit
values.
- Split the patch renaiming the registers to do the "status" renaiming
aside.
Baruch Siach (4):
dt-bindings: thermal: Describe Armada AP806 and CP110
thermal: armada: Use msleep for long delays
thermal: armada: Add support for Armada AP806
thermal: armada: Add support for Armada CP110
Miquel Raynal (8):
thermal: armada: Simplify the check of the validity bit
thermal: armada: Clarify control registers accesses
thermal: armada: Use real status register name
thermal: armada: Update Kconfig and module description
thermal: armada: Change sensors trim default value
thermal: armada: Wait sensors validity before exiting the init
callback
thermal: armada: Give meaningful names to the thermal zones
ARM64: dts: marvell: Add thermal support for A7K/A8K
.../devicetree/bindings/thermal/armada-thermal.txt | 24 +-
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 6 +
.../boot/dts/marvell/armada-cp110-master.dtsi | 6 +
.../arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 6 +
drivers/thermal/Kconfig | 4 +-
drivers/thermal/armada_thermal.c | 252 +++++++++++++++------
6 files changed, 226 insertions(+), 72 deletions(-)
--
2.11.0
--
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/2] eeprom: at24: convert magic numbers to structs.
From: Bartosz Golaszewski @ 2017-12-18 14:29 UTC (permalink / raw)
To: Sven Van Asbroeck
Cc: Wolfram Sang, nsekhar-l0cyMroinI0, Sakari Ailus,
Javier Martinez Canillas, Divagar Mohandass,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List,
linux-i2c
In-Reply-To: <1512768306-14816-2-git-send-email-svendev-fuHqz3Nb1YI@public.gmane.org>
2017-12-08 22:25 GMT+01:00 Sven Van Asbroeck <svendev-fuHqz3Nb1YI@public.gmane.org>:
> Fundamental properties such as capacity and page size differ
> among at24-type chips. But these chips do not have an id register,
> so this can't be discovered at runtime.
>
> Traditionally, at24-type eeprom properties were determined in two ways:
> - by passing a 'struct at24_platform_data' via platform_data, or
> - by naming the chip type in the devicetree, which passes a
> 'magic number' to probe(), which is then converted to
> a 'struct at24_platform_data'.
>
> Recently a bug was discovered because the magic number rounds down
> all chip sizes to the lowest power of two. This was addressed by
> a work-around, with the wish that magic numbers should over time
> be converted to structs.
>
> This patch replaces the magic numbers with 'struct at24_chip_data'.
>
> Signed-off-by: Sven Van Asbroeck <svendev-fuHqz3Nb1YI@public.gmane.org>
> ---
> drivers/misc/eeprom/at24.c | 230 ++++++++++++++++++++++-----------------------
> 1 file changed, 110 insertions(+), 120 deletions(-)
>
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index 06ffa11..c3759cb 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -105,16 +105,6 @@ struct at24_data {
> module_param(write_timeout, uint, 0);
> MODULE_PARM_DESC(write_timeout, "Time (in ms) to try writes (default 25)");
>
> -#define AT24_SIZE_BYTELEN 5
> -#define AT24_SIZE_FLAGS 8
> -
> -#define AT24_BITMASK(x) (BIT(x) - 1)
> -
> -/* create non-zero magic value for given eeprom parameters */
> -#define AT24_DEVICE_MAGIC(_len, _flags) \
> - ((1 << AT24_SIZE_FLAGS | (_flags)) \
> - << AT24_SIZE_BYTELEN | ilog2(_len))
> -
> /*
> * Both reads and writes fail if the previous write didn't complete yet. This
> * macro loops a few times waiting at least long enough for one entire page
> @@ -131,113 +121,119 @@ struct at24_data {
> op_time ? time_before(op_time, tout) : true; \
> usleep_range(1000, 1500), op_time = jiffies)
>
> +struct at24_chip_data {
> + /*
> + * these fields mirror their equivalents in
> + * struct at24_platform_data
> + */
> + u32 byte_len;
> + u8 flags;
> +};
> +
> +#define AT24_CHIP_DATA(_name, _len, _flags) \
> + static const struct at24_chip_data at24_data_##_name = { \
> + .byte_len = _len, .flags = _flags, \
> + }
> +
> +#define AT24_I2C_DEVICE_ID(_name) \
> + { #_name, (kernel_ulong_t)&at24_data_##_name }
> +
> +#define AT24_ACPI_DEVICE_ID(_name) \
> + { #_name, (kernel_ulong_t)&at24_data_##_name }
> +
> +#define AT24_OF_DEVICE_ID(_of_compat, _name) \
> + { .compatible = _of_compat, .data = &at24_data_##_name }
> +
> +/* needs 8 addresses as A0-A2 are ignored */
> +AT24_CHIP_DATA(24c00, 128 / 8, AT24_FLAG_TAKE8ADDR);
> +/* old variants can't be handled with this generic entry! */
> +AT24_CHIP_DATA(24c01, 1024 / 8, 0);
> +AT24_CHIP_DATA(24cs01, 16, AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
> +AT24_CHIP_DATA(24c02, 2048 / 8, 0);
> +AT24_CHIP_DATA(24cs02, 16, AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
> +AT24_CHIP_DATA(24mac402, 48 / 8,
> + AT24_FLAG_MAC | AT24_FLAG_READONLY);
> +AT24_CHIP_DATA(24mac602, 64 / 8,
> + AT24_FLAG_MAC | AT24_FLAG_READONLY);
> +/* spd is a 24c02 in memory DIMMs */
> +AT24_CHIP_DATA(spd, 2048 / 8,
> + AT24_FLAG_READONLY | AT24_FLAG_IRUGO);
> +AT24_CHIP_DATA(24c04, 4096 / 8, 0);
> +AT24_CHIP_DATA(24cs04, 16,
> + AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
> +/* 24rf08 quirk is handled at i2c-core */
> +AT24_CHIP_DATA(24c08, 8192 / 8, 0);
> +AT24_CHIP_DATA(24cs08, 16,
> + AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
> +AT24_CHIP_DATA(24c16, 16384 / 8, 0);
> +AT24_CHIP_DATA(24cs16, 16,
> + AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
> +AT24_CHIP_DATA(24c32, 32768 / 8, AT24_FLAG_ADDR16);
> +AT24_CHIP_DATA(24cs32, 16,
> + AT24_FLAG_ADDR16 |
> + AT24_FLAG_SERIAL |
> + AT24_FLAG_READONLY);
> +AT24_CHIP_DATA(24c64, 65536 / 8, AT24_FLAG_ADDR16);
> +AT24_CHIP_DATA(24cs64, 16,
> + AT24_FLAG_ADDR16 |
> + AT24_FLAG_SERIAL |
> + AT24_FLAG_READONLY);
> +AT24_CHIP_DATA(24c128, 131072 / 8, AT24_FLAG_ADDR16);
> +AT24_CHIP_DATA(24c256, 262144 / 8, AT24_FLAG_ADDR16);
> +AT24_CHIP_DATA(24c512, 524288 / 8, AT24_FLAG_ADDR16);
> +AT24_CHIP_DATA(24c1024, 1048576 / 8, AT24_FLAG_ADDR16);
> +/* identical to 24c08 ? */
> +AT24_CHIP_DATA(INT3499, 8192 / 8, 0);
> +
> static const struct i2c_device_id at24_ids[] = {
> - /* needs 8 addresses as A0-A2 are ignored */
> - { "24c00", AT24_DEVICE_MAGIC(128 / 8, AT24_FLAG_TAKE8ADDR) },
> - /* old variants can't be handled with this generic entry! */
> - { "24c01", AT24_DEVICE_MAGIC(1024 / 8, 0) },
> - { "24cs01", AT24_DEVICE_MAGIC(16,
> - AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
> - { "24c02", AT24_DEVICE_MAGIC(2048 / 8, 0) },
> - { "24cs02", AT24_DEVICE_MAGIC(16,
> - AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
> - { "24mac402", AT24_DEVICE_MAGIC(48 / 8,
> - AT24_FLAG_MAC | AT24_FLAG_READONLY) },
> - { "24mac602", AT24_DEVICE_MAGIC(64 / 8,
> - AT24_FLAG_MAC | AT24_FLAG_READONLY) },
> - /* spd is a 24c02 in memory DIMMs */
> - { "spd", AT24_DEVICE_MAGIC(2048 / 8,
> - AT24_FLAG_READONLY | AT24_FLAG_IRUGO) },
> - { "24c04", AT24_DEVICE_MAGIC(4096 / 8, 0) },
> - { "24cs04", AT24_DEVICE_MAGIC(16,
> - AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
> - /* 24rf08 quirk is handled at i2c-core */
> - { "24c08", AT24_DEVICE_MAGIC(8192 / 8, 0) },
> - { "24cs08", AT24_DEVICE_MAGIC(16,
> - AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
> - { "24c16", AT24_DEVICE_MAGIC(16384 / 8, 0) },
> - { "24cs16", AT24_DEVICE_MAGIC(16,
> - AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
> - { "24c32", AT24_DEVICE_MAGIC(32768 / 8, AT24_FLAG_ADDR16) },
> - { "24cs32", AT24_DEVICE_MAGIC(16,
> - AT24_FLAG_ADDR16 |
> - AT24_FLAG_SERIAL |
> - AT24_FLAG_READONLY) },
> - { "24c64", AT24_DEVICE_MAGIC(65536 / 8, AT24_FLAG_ADDR16) },
> - { "24cs64", AT24_DEVICE_MAGIC(16,
> - AT24_FLAG_ADDR16 |
> - AT24_FLAG_SERIAL |
> - AT24_FLAG_READONLY) },
> - { "24c128", AT24_DEVICE_MAGIC(131072 / 8, AT24_FLAG_ADDR16) },
> - { "24c256", AT24_DEVICE_MAGIC(262144 / 8, AT24_FLAG_ADDR16) },
> - { "24c512", AT24_DEVICE_MAGIC(524288 / 8, AT24_FLAG_ADDR16) },
> - { "24c1024", AT24_DEVICE_MAGIC(1048576 / 8, AT24_FLAG_ADDR16) },
> + AT24_I2C_DEVICE_ID(24c00),
> + AT24_I2C_DEVICE_ID(24c01),
> + AT24_I2C_DEVICE_ID(24cs01),
> + AT24_I2C_DEVICE_ID(24c02),
> + AT24_I2C_DEVICE_ID(24cs02),
> + AT24_I2C_DEVICE_ID(24mac402),
> + AT24_I2C_DEVICE_ID(24mac602),
> + AT24_I2C_DEVICE_ID(spd),
> + AT24_I2C_DEVICE_ID(24c04),
> + AT24_I2C_DEVICE_ID(24cs04),
> + AT24_I2C_DEVICE_ID(24c08),
> + AT24_I2C_DEVICE_ID(24cs08),
> + AT24_I2C_DEVICE_ID(24c16),
> + AT24_I2C_DEVICE_ID(24cs16),
> + AT24_I2C_DEVICE_ID(24c32),
> + AT24_I2C_DEVICE_ID(24cs32),
> + AT24_I2C_DEVICE_ID(24c64),
> + AT24_I2C_DEVICE_ID(24cs64),
> + AT24_I2C_DEVICE_ID(24c128),
> + AT24_I2C_DEVICE_ID(24c256),
> + AT24_I2C_DEVICE_ID(24c512),
> + AT24_I2C_DEVICE_ID(24c1024),
> { "at24", 0 },
> { /* END OF LIST */ }
> };
> MODULE_DEVICE_TABLE(i2c, at24_ids);
>
> static const struct of_device_id at24_of_match[] = {
> - {
> - .compatible = "atmel,24c00",
> - .data = (void *)AT24_DEVICE_MAGIC(128 / 8, AT24_FLAG_TAKE8ADDR)
> - },
> - {
> - .compatible = "atmel,24c01",
> - .data = (void *)AT24_DEVICE_MAGIC(1024 / 8, 0)
> - },
> - {
> - .compatible = "atmel,24c02",
> - .data = (void *)AT24_DEVICE_MAGIC(2048 / 8, 0)
> - },
> - {
> - .compatible = "atmel,spd",
> - .data = (void *)AT24_DEVICE_MAGIC(2048 / 8,
> - AT24_FLAG_READONLY | AT24_FLAG_IRUGO)
> - },
> - {
> - .compatible = "atmel,24c04",
> - .data = (void *)AT24_DEVICE_MAGIC(4096 / 8, 0)
> - },
> - {
> - .compatible = "atmel,24c08",
> - .data = (void *)AT24_DEVICE_MAGIC(8192 / 8, 0)
> - },
> - {
> - .compatible = "atmel,24c16",
> - .data = (void *)AT24_DEVICE_MAGIC(16384 / 8, 0)
> - },
> - {
> - .compatible = "atmel,24c32",
> - .data = (void *)AT24_DEVICE_MAGIC(32768 / 8, AT24_FLAG_ADDR16)
> - },
> - {
> - .compatible = "atmel,24c64",
> - .data = (void *)AT24_DEVICE_MAGIC(65536 / 8, AT24_FLAG_ADDR16)
> - },
> - {
> - .compatible = "atmel,24c128",
> - .data = (void *)AT24_DEVICE_MAGIC(131072 / 8, AT24_FLAG_ADDR16)
> - },
> - {
> - .compatible = "atmel,24c256",
> - .data = (void *)AT24_DEVICE_MAGIC(262144 / 8, AT24_FLAG_ADDR16)
> - },
> - {
> - .compatible = "atmel,24c512",
> - .data = (void *)AT24_DEVICE_MAGIC(524288 / 8, AT24_FLAG_ADDR16)
> - },
> - {
> - .compatible = "atmel,24c1024",
> - .data = (void *)AT24_DEVICE_MAGIC(1048576 / 8, AT24_FLAG_ADDR16)
> - },
> - { },
> + AT24_OF_DEVICE_ID("atmel,24c00", 24c00),
> + AT24_OF_DEVICE_ID("atmel,24c01", 24c01),
> + AT24_OF_DEVICE_ID("atmel,24c02", 24c02),
> + AT24_OF_DEVICE_ID("atmel,spd", spd),
> + AT24_OF_DEVICE_ID("atmel,24c04", 24c04),
> + AT24_OF_DEVICE_ID("atmel,24c08", 24c08),
> + AT24_OF_DEVICE_ID("atmel,24c16", 24c16),
> + AT24_OF_DEVICE_ID("atmel,24c32", 24c32),
> + AT24_OF_DEVICE_ID("atmel,24c64", 24c64),
> + AT24_OF_DEVICE_ID("atmel,24c128", 24c128),
> + AT24_OF_DEVICE_ID("atmel,24c256", 24c256),
> + AT24_OF_DEVICE_ID("atmel,24c512", 24c512),
> + AT24_OF_DEVICE_ID("atmel,24c1024", 24c1024),
> + { /* END OF LIST */ },
> };
> MODULE_DEVICE_TABLE(of, at24_of_match);
Hi Sven,
I have given this patch a thought over the weekend and decided that we
should not hide everything behind macros. We're decreasing the
readability while not winning anything.
Let's leave the macros defining the chip data in place (for code
brevity), but for everything else let's just use designated struct
initializers ( .compatible = "vendor,device" etc.), so drop the
AT24_OF_DEVICE_ID macros etc. in the next version.
Thanks,
Bartosz
--
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 3/6] arm: dts: sun8i: a83t: Add the cir pin for the A83T
From: Maxime Ripard @ 2017-12-18 14:23 UTC (permalink / raw)
To: Philipp Rossak
Cc: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171218141146.23746-4-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 866 bytes --]
On Mon, Dec 18, 2017 at 03:11:43PM +0100, Philipp Rossak wrote:
> The CIR Pin of the A83T is located at PL12.
>
> Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index de5119a2a91c..feffca8a9a24 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -623,6 +623,11 @@
> drive-strength = <20>;
> bias-pull-up;
> };
> +
> + cir_pins: cir-pins@0 {
> + pins = "PL12";
> + function = "s_cir_rx";
> + };
Sorry for not noticing this earlier, but the nodes should be ordered
alphabetically.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 2/6] media: dt: bindings: Update binding documentation for sunxi IR controller
From: Maxime Ripard @ 2017-12-18 14:22 UTC (permalink / raw)
To: Philipp Rossak
Cc: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171218141146.23746-3-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]
On Mon, Dec 18, 2017 at 03:11:42PM +0100, Philipp Rossak wrote:
> This patch updates documentation for Device-Tree bindings for sunxi IR
> controller and adds the new optional property for the base clock
> frequency.
>
> Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/media/sunxi-ir.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt
> index 91648c569b1e..3d7f18780fae 100644
> --- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
> +++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
> @@ -11,6 +11,8 @@ Required properties:
> Optional properties:
> - linux,rc-map-name: see rc.txt file in the same directory.
> - resets : phandle + reset specifier pair
> +- clock-frequency : IR Receiver clock frequency, in Herz. Defaults to 8 MHz
^ Hertz
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/4] rtc: add mxc driver for i.MX53 SRTC
From: Philippe Ombredanne @ 2017-12-18 14:17 UTC (permalink / raw)
To: linux-kernel-dev
Cc: Patrick Bruenn, Alessandro Zummo, Alexandre Belloni, Rob Herring,
Mark Rutland, open list:REAL TIME CLOCK (RTC) SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Fabio Estevam, Juergen Borleis, Noel Vellemans,
Shawn Guo, Sascha Hauer, Russell King,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20171218115133.16371-1-linux-kernel-dev-QonKdJ6Bx35Wk0Htik3J/w@public.gmane.org>
On Mon, Dec 18, 2017 at 12:51 PM, <linux-kernel-dev-QonKdJ6Bx35Wk0Htik3J/w@public.gmane.org> wrote:
> From: Patrick Bruenn <p.bruenn-QonKdJ6Bx35Wk0Htik3J/w@public.gmane.org>
>
> Neither rtc-imxdi, rtc-mxc nor rtc-snvs are compatible with i.MX53.
>
> This is driver enables support for the low power domain SRTC features:
> - 32-bit MSB of non-rollover time counter
> - 32-bit alarm register
>
> Select the new config option RTC_DRV_MXC_V2 to build this driver
>
> Based on:
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/rtc/rtc-mxc_v2.c?h=imx_2.6.35_11.09.01
>
> Signed-off-by: Patrick Bruenn <p.bruenn-QonKdJ6Bx35Wk0Htik3J/w@public.gmane.org>
>
> ---
>
> v4:
> - rename "srtc" node into generic "rtc" keep the label as "srtc" to avoid
> duplication with imx53-m53.dtsi
> - fix Signed-off-by: in bindings-patch
>
> v3:
> - introduce new config option with the same patch, which adds the driver
> - call rtc_update_irq() only if necessary
> - merge mxc_rtc_write_alarm_locked() with mxc_rtc_set_alarm()
> - only use clk_enable/disable (without "prepare") during operation
> - rebase on v4.15-rc3
> - consistently use rtc_tm_to_time64() and time64_t
> - refactor mxc_rtc_read_time(): don't lock for readl() only;
> don't rtc_valid_tm(); use time64_t
> - check returncode of mxc_rtc_wait_for_flag()
> - restructure mxc_rtc_sync_lp_locked() to replace pr_err() with
> dev_err_once(); remove explicit 'inline'
> - don't touch imx_v4_v5_defconfig, instead add to imx_v6_v7_defconfig
>
> v2:
> - have seperate patches for dt-binding, CONFIG option, imx53.dtsi and driver
> - add SPDX-License-Identifier and cleanup copyright notice
> - replace __raw_readl/writel() with readl/writel()
> - fix PM_SLEEP callbacks
> - add CONFIG_RTC_DRV_MXC_V2 to build rtc-mxc_v2.c
> - remove misleading or obvious comments and fix style of the remaining
> - avoid endless loop while waiting for hw
> - implement consistent locking; make spinlock a member of dev struct
> - enable clk only for register accesses
> - remove all udelay() calls since they are obsolete or redundant
> (we are already waiting for register flags to change)
> - init platform_data before registering irq callback
> - let set_time() fail, when 32 bit rtc counter exceeded
> - make names more consistent
> - cleanup and reorder includes
> - cleanup and remove unused defines
>
> Cc: Alessandro Zummo <a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org>
> Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
> Cc: linux-rtc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list:REAL TIME CLOCK (RTC) SUBSYSTEM)
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list)
> Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> Cc: Juergen Borleis <jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Cc: Noel Vellemans <Noel.Vellemans-8UENEgx6w+makBO8gow8eQ@public.gmane.org>
> Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> (maintainer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
> Cc: Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> (maintainer:ARM PORT)
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
>
> Cc: Philippe Ombredanne <pombredanne-od1rfyK75/E@public.gmane.org>
> Cc: Lothar Waßmann <LW-bxm8fMRDkQLDiMYJYoSAnRvVK+yQ3ZXh@public.gmane.org>
> ---
>
> Patrick Bruenn (4):
> dt-bindings: rtc: add bindings for i.MX53 SRTC
> ARM: dts: imx53: add srtc node
> rtc: add mxc driver for i.MX53 SRTC
> ARM: imx_v6_v7_defconfig: enable RTC_DRV_MXC_V2
>
> .../devicetree/bindings/rtc/rtc-mxc_v2.txt | 17 +
> arch/arm/boot/dts/imx53.dtsi | 7 +
> arch/arm/configs/imx_v6_v7_defconfig | 1 +
> drivers/rtc/Kconfig | 10 +
> drivers/rtc/Makefile | 1 +
> drivers/rtc/rtc-mxc_v2.c | 422 +++++++++++++++++++++
> 6 files changed, 458 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
> create mode 100644 drivers/rtc/rtc-mxc_v2.c
>
> --
> 2.11.0
For the use of SPDX license tags in this patch set:
Acked-by: Philippe Ombredanne <pombredanne-od1rfyK75/E@public.gmane.org>
--
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 6/6] arm: dts: sun8i: h3-h8: ir register size should be the whole memory block
From: Philipp Rossak @ 2017-12-18 14:11 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171218141146.23746-1-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The size of the register should be the size of the whole memory block,
not just the registers, that are needed.
Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 8d40c00d64bb..a9caeda4a574 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -674,7 +674,7 @@
clock-names = "apb", "ir";
resets = <&r_ccu RST_APB0_IR>;
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x01f02000 0x40>;
+ reg = <0x01f02000 0x400>;
status = "disabled";
};
--
2.11.0
^ permalink raw reply related
* [PATCH v2 5/6] arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller
From: Philipp Rossak @ 2017-12-18 14:11 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171218141146.23746-1-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The Bananapi M3 has an onboard IR receiver.
This enables the onboard IR receiver subnode.
Unlike the other IR receivers this one needs a base clock frequency
of 3000000 Hz (3 MHz), to be able to work.
Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 6550bf0e594b..ffc6445fd281 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -82,6 +82,13 @@
};
};
+&cir {
+ pinctrl-names = "default";
+ pinctrl-0 = <&cir_pins>;
+ clock-frequency = <3000000>;
+ status = "okay";
+};
+
&ehci0 {
/* Terminus Tech FE 1.1s 4-port USB 2.0 hub here */
status = "okay";
--
2.11.0
^ permalink raw reply related
* [PATCH v2 4/6] arm: dts: sun8i: a83t: Add support for the cir interface
From: Philipp Rossak @ 2017-12-18 14:11 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171218141146.23746-1-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The cir interface is like on the H3 located at 0x01f02000 and is exactly
the same. This patch adds support for the ir interface on the A83T.
Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index feffca8a9a24..089c270a7f3c 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -605,6 +605,16 @@
#reset-cells = <1>;
};
+ cir: cir@01f02000 {
+ compatible = "allwinner,sun5i-a13-ir";
+ clocks = <&r_ccu CLK_APB0_IR>, <&r_ccu CLK_IR>;
+ clock-names = "apb", "ir";
+ resets = <&r_ccu RST_APB0_IR>;
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x01f02000 0x400>;
+ status = "disabled";
+ };
+
r_pio: pinctrl@1f02c00 {
compatible = "allwinner,sun8i-a83t-r-pinctrl";
reg = <0x01f02c00 0x400>;
--
2.11.0
^ permalink raw reply related
* [PATCH v2 3/6] arm: dts: sun8i: a83t: Add the cir pin for the A83T
From: Philipp Rossak @ 2017-12-18 14:11 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171218141146.23746-1-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The CIR Pin of the A83T is located at PL12.
Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index de5119a2a91c..feffca8a9a24 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -623,6 +623,11 @@
drive-strength = <20>;
bias-pull-up;
};
+
+ cir_pins: cir-pins@0 {
+ pins = "PL12";
+ function = "s_cir_rx";
+ };
};
r_rsb: rsb@1f03400 {
--
2.11.0
^ permalink raw reply related
* [PATCH v2 2/6] media: dt: bindings: Update binding documentation for sunxi IR controller
From: Philipp Rossak @ 2017-12-18 14:11 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171218141146.23746-1-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This patch updates documentation for Device-Tree bindings for sunxi IR
controller and adds the new optional property for the base clock
frequency.
Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Documentation/devicetree/bindings/media/sunxi-ir.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 91648c569b1e..3d7f18780fae 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -11,6 +11,8 @@ Required properties:
Optional properties:
- linux,rc-map-name: see rc.txt file in the same directory.
- resets : phandle + reset specifier pair
+- clock-frequency : IR Receiver clock frequency, in Herz. Defaults to 8 MHz
+ if missing.
Example:
@@ -18,6 +20,7 @@ ir0: ir@1c21800 {
compatible = "allwinner,sun4i-a10-ir";
clocks = <&apb0_gates 6>, <&ir0_clk>;
clock-names = "apb", "ir";
+ clock-frequency = <3000000>;
resets = <&apb0_rst 1>;
interrupts = <0 5 1>;
reg = <0x01C21800 0x40>;
--
2.11.0
^ permalink raw reply related
* [PATCH v2 1/6] media: rc: update sunxi-ir driver to get base clock frequency from devicetree
From: Philipp Rossak @ 2017-12-18 14:11 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171218141146.23746-1-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This patch updates the sunxi-ir driver to set the base clock frequency from
devicetree.
This is necessary since there are different ir receivers on the
market, that operate with different frequencies. So this value could be
set if the attached ir receiver needs a different base clock frequency,
than the default 8 MHz.
Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/media/rc/sunxi-cir.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 97f367b446c4..f500cea228a9 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -72,12 +72,8 @@
/* CIR_REG register idle threshold */
#define REG_CIR_ITHR(val) (((val) << 8) & (GENMASK(15, 8)))
-/* Required frequency for IR0 or IR1 clock in CIR mode */
+/* Required frequency for IR0 or IR1 clock in CIR mode (default) */
#define SUNXI_IR_BASE_CLK 8000000
-/* Frequency after IR internal divider */
-#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
-/* Sample period in ns */
-#define SUNXI_IR_SAMPLE (1000000000ul / SUNXI_IR_CLK)
/* Noise threshold in samples */
#define SUNXI_IR_RXNOISE 1
/* Idle Threshold in samples */
@@ -122,7 +118,8 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
/* for each bit in fifo */
dt = readb(ir->base + SUNXI_IR_RXFIFO_REG);
rawir.pulse = (dt & 0x80) != 0;
- rawir.duration = ((dt & 0x7f) + 1) * SUNXI_IR_SAMPLE;
+ rawir.duration = ((dt & 0x7f) + 1) *
+ ir->rc->rx_resolution;
ir_raw_event_store_with_filter(ir->rc, &rawir);
}
}
@@ -148,6 +145,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
struct device_node *dn = dev->of_node;
struct resource *res;
struct sunxi_ir *ir;
+ u32 b_clk_freq = SUNXI_IR_BASE_CLK;
ir = devm_kzalloc(dev, sizeof(struct sunxi_ir), GFP_KERNEL);
if (!ir)
@@ -172,6 +170,9 @@ static int sunxi_ir_probe(struct platform_device *pdev)
return PTR_ERR(ir->clk);
}
+ /* Base clock frequency (optional) */
+ of_property_read_u32(dn, "clock-frequency", &b_clk_freq);
+
/* Reset (optional) */
ir->rst = devm_reset_control_get_optional_exclusive(dev, NULL);
if (IS_ERR(ir->rst))
@@ -180,11 +181,12 @@ static int sunxi_ir_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = clk_set_rate(ir->clk, SUNXI_IR_BASE_CLK);
+ ret = clk_set_rate(ir->clk, b_clk_freq);
if (ret) {
dev_err(dev, "set ir base clock failed!\n");
goto exit_reset_assert;
}
+ dev_dbg(dev, "set base clock frequency to %d Hz.\n", b_clk_freq);
if (clk_prepare_enable(ir->apb_clk)) {
dev_err(dev, "try to enable apb_ir_clk failed\n");
@@ -225,7 +227,8 @@ static int sunxi_ir_probe(struct platform_device *pdev)
ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
ir->rc->dev.parent = dev;
ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
- ir->rc->rx_resolution = SUNXI_IR_SAMPLE;
+ /* Frequency after IR internal divider with sample period in ns */
+ ir->rc->rx_resolution = (1000000000ul / (b_clk_freq / 64));
ir->rc->timeout = MS_TO_NS(SUNXI_IR_TIMEOUT);
ir->rc->driver_name = SUNXI_IR_DEV;
--
2.11.0
^ permalink raw reply related
* [PATCH v2 0/6] arm: sunxi: IR support for A83T
From: Philipp Rossak @ 2017-12-18 14:11 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
This patch series adds support for the sunxi A83T ir module and enhances
the sunxi-ir driver. Right now the base clock frequency for the ir driver
is a hard coded define and is set to 8 MHz.
This works for the most common ir receivers. On the Sinovoip Bananapi M3
the ir receiver needs, a 3 MHz base clock frequency to work without
problems with this driver.
This patch series adds support for an optinal property that makes it able
to override the default base clock frequency and enables the ir interface
on the a83t and the Bananapi M3.
changes since v1:
* fix typos, reword Documentation
* initialize 'b_clk_freq' to 'SUNXI_IR_BASE_CLK' & remove if statement
* change dev_info() to dev_dbg()
* change naming to cir* in dts/dtsi
* Added acked Ackedi-by to related patch
* use whole memory block instead of registers needed + fix for h3/h5
changes since rfc:
* The property is now optinal. If the property is not available in
the dtb the driver uses the default base clock frequency.
* the driver prints out the the selected base clock frequency.
* changed devicetree property from base-clk-frequency to clock-frequency
Regards,
Philipp
Philipp Rossak (6):
media: rc: update sunxi-ir driver to get base clock frequency from
devicetree
media: dt: bindings: Update binding documentation for sunxi IR
controller
arm: dts: sun8i: a83t: Add the cir pin for the A83T
arm: dts: sun8i: a83t: Add support for the cir interface
arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller
arm: dts: sun8i: h3-h8: ir register size should be the whole memory
block
Documentation/devicetree/bindings/media/sunxi-ir.txt | 3 +++
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++++++
arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +++++++++++++++
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +-
drivers/media/rc/sunxi-cir.c | 19 +++++++++++--------
5 files changed, 37 insertions(+), 9 deletions(-)
--
2.11.0
^ permalink raw reply
* Re: [PATCH v4 2/2] misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver
From: Arnd Bergmann @ 2017-12-18 14:05 UTC (permalink / raw)
To: Michal Simek
Cc: Dhaval Shah, gregkh, Rob Herring, Mark Rutland, Randy Dunlap,
DTML, Linux Kernel Mailing List, Hyun Kwon, Dhaval Shah
In-Reply-To: <b3b41b04-7f93-1c20-2e62-817b4c743b89-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
On Mon, Dec 18, 2017 at 2:13 PM, Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
> On 15.12.2017 14:26, Arnd Bergmann wrote:
>> In Fri, Dec 15, 2017 at 8:24 AM, Dhaval Shah <dhaval.shah-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
>>> Xilinx ZYNQMP logicoreIP Init driver is based on the new
>>> LogiCoreIP design created. This driver provides the processing system
>>> and programmable logic isolation. Set the frequency based on the clock
>>> information get from the logicoreIP register set.
>>>
>>> It is put in drivers/misc as there is no subsystem for this logicoreIP.
>>>
>>> Signed-off-by: Dhaval Shah <dshah-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
>>
>> After giving this some more thought, I'd suggest you move the driver to
>> drivers/soc/xilinx or drivers/soc/zynq instead of drivers/misc/, and have
>> it merged by Michal Simek as a driver patch that will go through arm-soc.
>
> I have not a problem of creating drivers/soc/xilinx/ location for this
> driver. It is not zynq (arm32) but zynqmp(arm64) device where this
> driver can be used. As far as I understand it is memory mapped soft IP
> which could be also accessed by soft core CPU.
Ok. I wouldn't be worried about having a zynq directory for stuff that
is common between zynq and zynqmp, but the soft code CPU case
wouldn't make that ideal.
> It means drivers/soc/xilinx could be shared by all xilinx platforms anyway.
> We have been discussing that openrisc cases and for sure if someone
> wants to enable this driver there using misc location would be one
> option but I also think that using drivers/soc/xilinx location is not a
> bad option because it is very unlikely that anybody tries it.
>
> Arnd: misc or drivers/soc/xilinx?
drivers/soc/xilinx please, thanks for the clarification.
Arnd
--
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: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.
From: Daniel Thompson @ 2017-12-18 13:53 UTC (permalink / raw)
To: Enric Balletbo Serra
Cc: Pavel Machek, Doug Anderson, Enric Balletbo i Serra, Jingoo Han,
Richard Purdie, Jacek Anaszewski, Rob Herring, Brian Norris,
Guenter Roeck, Lee Jones, Alexandru Stan, linux-leds,
devicetree@vger.kernel.org, LKML
In-Reply-To: <CAFqH_52z9O+0ZVB-rMTCNzw+55m26fDGKeaj-Fz-ccO74+j_MA@mail.gmail.com>
On Mon, Dec 18, 2017 at 11:40:59AM +0100, Enric Balletbo Serra wrote:
> Hi Pavel,
>
> 2017-12-15 21:57 GMT+01:00 Pavel Machek <pavel@ucw.cz>:
> > Hi!
> >
> >> Yes, I think that how you describe luminance and lightness is right,
> >> and sounds good improve the doc.
> >>
> >> To be clear the correction table for PWM values can be calculated with
> >> this code.
> >>
> >> OUTPUT_SIZE = 65535 # Output integer size
> >> INPUT_SIZE = 2047
> >>
> >> def cie1931(L):
> >> L = L*100.0
> >> if L <= 8:
> >> return (L/902.3)
> >> else:
> >> return ((L+16.0)/116.0)**3
> >>
> >> x = range(0,int(INPUT_SIZE+1))
> >> y = [int(round(cie1931(float(L)/INPUT_SIZE)*(OUTPUT_SIZE))) for L in x]
> >
> > Can we just generate the table on the fly? Should not be hard to do in
> > fixed point, right?
>
> This was discussed a bit in previous RFC which had the code to
> generate the table on the fly, see [1]. The use of a fixed table or an
> on the fly table is something that I'll let the maintainers to decide.
> I've no strong opinion on use the on the fly table if someone takes
> care to review deeply the fixed point maths :)
The last time we discussed this we concluded we would introduce linear
interpolation to make it easier enlarge the small tables we typically
see in devicetree.
Having done that it seemed attractive (at least to me) to reuse any
interpolation code we get and then simply provide a "sane" default look
up table for use by DT authors who don't really know how to map PWM on/
off times to luminance.
I did review the original fixed point code for the first RFC. IIRC some
of the low level functions *looked* they could overflow but, on closer
inspection, were never actually overflowed in practice due to the
number ranges used by the callers. To be honest part of the attraction
of a LUT instead was that I wouldn't have to closely review nor ensure
all the fixed point code was properly commented ;-) .
The other item in favour of LUT was that (as Doug A. pointed out) PWM
duty-cycle to luminance is not strictly linear. Whilst at the moment I
am OK to discount this effect it is possible we might want to combined
the luminance to human perception values with values read out from
graphs in a datasheet.
Enric: Having said all that I don't want to give you a really heavy
handed steer here. If you think the code was cleaner or clearer
when using the formulae then I'd be happy to review the fixed
point code.
Daniel.
^ permalink raw reply
* Re: [PATCH v3 04/11] thermal: armada: Rationalize register accesses
From: Miquel RAYNAL @ 2017-12-18 13:48 UTC (permalink / raw)
To: Baruch Siach
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Catalin Marinas, Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Antoine Tenart, Nadav Haklai, David Sniatkiwicz
In-Reply-To: <20171215085622.6u4dmvyaph3mbb66@tarshish>
On Fri, 15 Dec 2017 10:56:22 +0200
Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> Hi Miquèl,
>
> On Thu, Dec 14, 2017 at 11:30:04AM +0100, Miquel Raynal wrote:
> > Bindings were incomplete for a long time by only exposing one of
> > the two available control registers. To ease the migration to the
> > full bindings (already in use for the Armada 375 SoC), rename the
> > pointers for clarification. This way, it will only be needed to add
> > another pointer to access the other control register when the time
> > comes.
> >
> > This avoids dangerous situations where the offset 0 of the control
> > area can be either one register or the other depending on the
> > bindings used. After this change, device trees of other SoCs could
> > be migrated to the "full" bindings if they may benefit from
> > features from the unaccessible register, without any change in the
> > driver.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> > drivers/thermal/armada_thermal.c | 86
> > +++++++++++++++++++++++++--------------- 1 file changed, 55
> > insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/thermal/armada_thermal.c
> > b/drivers/thermal/armada_thermal.c index 26698f2d3ca7..e5b184cee79b
> > 100644 --- a/drivers/thermal/armada_thermal.c
> > +++ b/drivers/thermal/armada_thermal.c
> > @@ -39,12 +39,21 @@
> > #define A375_HW_RESETn BIT(8)
> > #define A380_HW_RESET BIT(8)
> >
> > +/* Legacy bindings */
> > +#define LEGACY_CONTROL_MEM_LEN 0x4
> > +
> > +/* Current bindings with the 2 control registers under the same
> > memory area */ +#define LEGACY_CONTROL1_OFFSET 0x0
> > +#define CONTROL0_OFFSET 0x0
> > +#define CONTROL1_OFFSET 0x4
> > +
> > struct armada_thermal_data;
> >
> > /* Marvell EBU Thermal Sensor Dev Structure */
> > struct armada_thermal_priv {
> > - void __iomem *sensor;
> > - void __iomem *control;
> > + void __iomem *status;
> > + void __iomem *control0;
> > + void __iomem *control1;
>
> The 'status' -> 'sensor' rename is not mentioned in the commit log.
> I'd say it is a matter for a separate patch.
Sure, I'll split.
>
> Otherwise, good cleanup.
Thanks!
Miquèl
>
> baruch
>
> > struct armada_thermal_data *data;
> > };
> >
> > @@ -71,45 +80,45 @@ struct armada_thermal_data {
> > static void armadaxp_init_sensor(struct platform_device *pdev,
> > struct armada_thermal_priv *priv)
> > {
> > - unsigned long reg;
> > + u32 reg;
> >
> > - reg = readl_relaxed(priv->control);
> > + reg = readl_relaxed(priv->control1);
> > reg |= PMU_TDC0_OTF_CAL_MASK;
> > - writel(reg, priv->control);
> > + writel(reg, priv->control1);
> >
> > /* Reference calibration value */
> > reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> > reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> > - writel(reg, priv->control);
> > + writel(reg, priv->control1);
> >
> > /* Reset the sensor */
> > - reg = readl_relaxed(priv->control);
> > - writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
> > + reg = readl_relaxed(priv->control1);
> > + writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
> >
> > - writel(reg, priv->control);
> > + writel(reg, priv->control1);
> >
> > /* Enable the sensor */
> > - reg = readl_relaxed(priv->sensor);
> > + reg = readl_relaxed(priv->status);
> > reg &= ~PMU_TM_DISABLE_MASK;
> > - writel(reg, priv->sensor);
> > + writel(reg, priv->status);
> > }
> >
> > static void armada370_init_sensor(struct platform_device *pdev,
> > struct armada_thermal_priv *priv)
> > {
> > - unsigned long reg;
> > + u32 reg;
> >
> > - reg = readl_relaxed(priv->control);
> > + reg = readl_relaxed(priv->control1);
> > reg |= PMU_TDC0_OTF_CAL_MASK;
> > - writel(reg, priv->control);
> > + writel(reg, priv->control1);
> >
> > /* Reference calibration value */
> > reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> > reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> > - writel(reg, priv->control);
> > + writel(reg, priv->control1);
> >
> > reg &= ~PMU_TDC0_START_CAL_MASK;
> > - writel(reg, priv->control);
> > + writel(reg, priv->control1);
> >
> > msleep(10);
> > }
> > @@ -117,37 +126,37 @@ static void armada370_init_sensor(struct
> > platform_device *pdev, static void armada375_init_sensor(struct
> > platform_device *pdev, struct armada_thermal_priv *priv)
> > {
> > - unsigned long reg;
> > + u32 reg;
> >
> > - reg = readl(priv->control + 4);
> > + reg = readl(priv->control1);
> > reg &= ~(A375_UNIT_CONTROL_MASK <<
> > A375_UNIT_CONTROL_SHIFT); reg &= ~A375_READOUT_INVERT;
> > reg &= ~A375_HW_RESETn;
> >
> > - writel(reg, priv->control + 4);
> > + writel(reg, priv->control1);
> > msleep(20);
> >
> > reg |= A375_HW_RESETn;
> > - writel(reg, priv->control + 4);
> > + writel(reg, priv->control1);
> > msleep(50);
> > }
> >
> > static void armada380_init_sensor(struct platform_device *pdev,
> > struct armada_thermal_priv *priv)
> > {
> > - unsigned long reg = readl_relaxed(priv->control);
> > + u32 reg = readl_relaxed(priv->control1);
> >
> > /* Reset hardware once */
> > if (!(reg & A380_HW_RESET)) {
> > reg |= A380_HW_RESET;
> > - writel(reg, priv->control);
> > + writel(reg, priv->control1);
> > msleep(10);
> > }
> > }
> >
> > static bool armada_is_valid(struct armada_thermal_priv *priv)
> > {
> > - unsigned long reg = readl_relaxed(priv->sensor);
> > + u32 reg = readl_relaxed(priv->status);
> >
> > return reg & priv->data->is_valid_bit;
> > }
> > @@ -156,7 +165,7 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, int *temp)
> > {
> > struct armada_thermal_priv *priv = thermal->devdata;
> > - unsigned long reg;
> > + u32 reg;
> > unsigned long m, b, div;
> >
> > /* Valid check */
> > @@ -166,7 +175,7 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, return -EIO;
> > }
> >
> > - reg = readl_relaxed(priv->sensor);
> > + reg = readl_relaxed(priv->status);
> > reg = (reg >> priv->data->temp_shift) &
> > priv->data->temp_mask;
> > /* Get formula coeficients */
> > @@ -253,6 +262,7 @@ MODULE_DEVICE_TABLE(of,
> > armada_thermal_id_table);
> > static int armada_thermal_probe(struct platform_device *pdev)
> > {
> > + void __iomem *control = NULL;
> > struct thermal_zone_device *thermal;
> > const struct of_device_id *match;
> > struct armada_thermal_priv *priv;
> > @@ -267,14 +277,28 @@ static int armada_thermal_probe(struct
> > platform_device *pdev) return -ENOMEM;
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > - priv->sensor = devm_ioremap_resource(&pdev->dev, res);
> > - if (IS_ERR(priv->sensor))
> > - return PTR_ERR(priv->sensor);
> > + priv->status = devm_ioremap_resource(&pdev->dev, res);
> > + if (IS_ERR(priv->status))
> > + return PTR_ERR(priv->status);
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > - priv->control = devm_ioremap_resource(&pdev->dev, res);
> > - if (IS_ERR(priv->control))
> > - return PTR_ERR(priv->control);
> > + control = devm_ioremap_resource(&pdev->dev, res);
> > + if (IS_ERR(control))
> > + return PTR_ERR(control);
> > +
> > + /*
> > + * Legacy DT bindings only described "control1" register
> > (also referred
> > + * as "control MSB" on old documentation). New bindings
> > cover
> > + * "control0/control LSB" and "control1/control MSB"
> > registers within
> > + * the same resource, which is then of size 8 instead of 4.
> > + */
> > + if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> > + /* ->control0 unavailable in this configuration */
> > + priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> > + } else {
> > + priv->control0 = control + CONTROL0_OFFSET;
> > + priv->control1 = control + CONTROL1_OFFSET;
> > + }
> >
> > priv->data = (struct armada_thermal_data *)match->data;
> > priv->data->init_sensor(pdev, priv);
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.
From: Daniel Thompson @ 2017-12-18 13:31 UTC (permalink / raw)
To: Enric Balletbo Serra
Cc: Enric Balletbo i Serra, Jingoo Han, Richard Purdie,
Jacek Anaszewski, Pavel Machek, Rob Herring, Doug Anderson,
Brian Norris, Guenter Roeck, Lee Jones, Alexandru Stan,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel
In-Reply-To: <CAFqH_50Jqs5_5n7D019_ZxvQD1FPCZAYhaLunNm6qzj_cH3tiw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Dec 18, 2017 at 11:27:22AM +0100, Enric Balletbo Serra wrote:
> Hi Daniel,
>
> 2017-12-15 15:51 GMT+01:00 Daniel Thompson <daniel.thompson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
> > On Thu, Nov 16, 2017 at 03:11:51PM +0100, Enric Balletbo i Serra wrote:
> >> When you want to change the brightness using a PWM signal, one thing you
> >> need to consider is how human perceive the brightness. Human perceive the
> >> brightness change non-linearly, we have better sensitivity at low
> >> luminance than high luminance, so to achieve perceived linear dimming, the
> >> brightness must be matches to the way our eyes behave. The CIE 1931
> >> lightness formula is what actually describes how we perceive light.
> >>
> >> This patch adds support to compute the brightness levels based on a static
> >> table filled with the numbers provided by the CIE 1931 algorithm, for now
> >> it only supports PWM resolutions up to 65535 (16 bits) with 1024 steps.
> >> Lower PWM resolutions are implemented using the same curve but with less
> >> steps, e.g. For a PWM resolution of 256 (8 bits) we have 37 steps.
> >>
> >> The calculation of the duty cycle using the CIE 1931 algorithm is enabled by
> >> default when you do not define the 'brightness-levels' propriety in your
> >> device tree.
> >>
> >> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> >> ---
> >> drivers/video/backlight/pwm_bl.c | 160 +++++++++++++++++++++++++++++++++++----
> >> include/linux/pwm_backlight.h | 1 +
> >> 2 files changed, 147 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> >> index 59b1bfb..ea96358 100644
> >> --- a/drivers/video/backlight/pwm_bl.c
> >> +++ b/drivers/video/backlight/pwm_bl.c
> >> @@ -26,6 +26,112 @@
> >>
> >> #define NSTEPS 256
> >>
> >> +/*
> >> + * CIE lightness to PWM conversion table. The CIE 1931 lightness formula is what
> >> + * actually describes how we perceive light:
> >> + *
> >> + * Y = (L* / 902.3) if L* ≤ 0.08856
> >> + * Y = ((L* + 16) / 116)^3 if L* > 0.08856
> >> + *
> >> + * Where Y is the luminance (output) between 0.0 and 1.0, and L* is the
> >> + * lightness (input) between 0 and 100.
> >> + */
> >> +const unsigned int cie1931_table[1024] = {
> >
> > I'm a little surprised to see such a large table. I thought we'd be able
> > to use the linear interpolation logic to smooth a smaller table.
> >
>
> oh, I didn't catch that you wanted use linear interpolation for that
> table too, that table is directly the output of the CIE 1931
> algorithm. And yes 1024 step looks like lots of steps but based on
> the tests 1024 steps for a 16 bit resolution PWM is reasonable, I
> guess (though it's a personal perception and opinion as I don't know
> how to calculate the number of really needed steps).
I think two different values on the userspace side should always map to
different values on the kernel side. This should make it possible
to calculate the maximal number of steps by scaling up the table to the
PWM resolution and then scanning for the smallest interval between
table steps.
Once we have a maximal value we could either use it directly or we
might want to push it through min(calculated_max, 1024), on the
assumption that even for animated changes to backlight level that
1024 is a sensible limit[1]
[1] I think it is... I'd be interested to know of Doug A. shares this
view..
> >
> >> + 0, 7, 14, 21, 28, 35, 43, 50, 57, 64, 71, 78, 85, 92, 99, 106, 114, 121,
> >> + 128, 135, 142, 149, 156, 163, 170, 177, 185, 192, 199, 206, 213, 220,
> >> + 227, 234, 241, 248, 256, 263, 270, 277, 284, 291, 298, 305, 312, 319,
> >> + 327, 334, 341, 348, 355, 362, 369, 376, 383, 390, 398, 405, 412, 419,
> >> + 426, 433, 440, 447, 454, 461, 469, 476, 483, 490, 497, 504, 511, 518,
> >> + 525, 532, 540, 547, 554, 561, 568, 575, 582, 589, 596, 603, 610, 618,
> >> + 625, 633, 640, 648, 655, 663, 671, 679, 687, 695, 703, 711, 719, 727,
> >> + 735, 744, 752, 761, 769, 778, 786, 795, 804, 813, 822, 831, 840, 849,
> >> + 858, 867, 876, 886, 895, 905, 914, 924, 934, 943, 953, 963, 973, 983,
> >> + 993, 1004, 1014, 1024, 1034, 1045, 1055, 1066, 1077, 1087, 1098, 1109,
> >> + 1120, 1131, 1142, 1153, 1165, 1176, 1187, 1199, 1210, 1222, 1234, 1245,
> >> + 1257, 1269, 1281, 1293, 1305, 1318, 1330, 1342, 1355, 1367, 1380, 1392,
> >> + 1405, 1418, 1431, 1444, 1457, 1470, 1483, 1497, 1510, 1523, 1537, 1551,
> >> + 1564, 1578, 1592, 1606, 1620, 1634, 1648, 1662, 1677, 1691, 1706, 1720,
> >> + 1735, 1750, 1765, 1780, 1795, 1810, 1825, 1840, 1855, 1871, 1886, 1902,
> >> + 1918, 1933, 1949, 1965, 1981, 1997, 2014, 2030, 2046, 2063, 2079, 2096,
> >> + 2113, 2130, 2146, 2163, 2181, 2198, 2215, 2232, 2250, 2267, 2285, 2303,
> >> + 2321, 2338, 2356, 2375, 2393, 2411, 2429, 2448, 2466, 2485, 2504, 2523,
> >> + 2542, 2561, 2580, 2599, 2618, 2638, 2657, 2677, 2697, 2716, 2736, 2756,
> >> + 2776, 2796, 2817, 2837, 2858, 2878, 2899, 2920, 2941, 2961, 2983, 3004,
> >> + 3025, 3046, 3068, 3089, 3111, 3133, 3155, 3177, 3199, 3221, 3243, 3266,
> >> + 3288, 3311, 3333, 3356, 3379, 3402, 3425, 3448, 3472, 3495, 3519, 3542,
> >> + 3566, 3590, 3614, 3638, 3662, 3686, 3711, 3735, 3760, 3784, 3809, 3834,
> >> + 3859, 3884, 3910, 3935, 3960, 3986, 4012, 4037, 4063, 4089, 4115, 4142,
> >> + 4168, 4194, 4221, 4248, 4274, 4301, 4328, 4356, 4383, 4410, 4438, 4465,
> >> + 4493, 4521, 4549, 4577, 4605, 4633, 4661, 4690, 4719, 4747, 4776, 4805,
> >> + 4834, 4863, 4893, 4922, 4952, 4981, 5011, 5041, 5071, 5101, 5131, 5162,
> >> + 5192, 5223, 5254, 5285, 5316, 5347, 5378, 5409, 5441, 5472, 5504, 5536,
> >> + 5568, 5600, 5632, 5664, 5697, 5729, 5762, 5795, 5828, 5861, 5894, 5928,
> >> + 5961, 5995, 6028, 6062, 6096, 6130, 6164, 6199, 6233, 6268, 6302, 6337,
> >> + 6372, 6407, 6442, 6478, 6513, 6549, 6585, 6621, 6657, 6693, 6729, 6765,
> >> + 6802, 6839, 6875, 6912, 6949, 6986, 7024, 7061, 7099, 7137, 7174, 7212,
> >> + 7250, 7289, 7327, 7366, 7404, 7443, 7482, 7521, 7560, 7600, 7639, 7679,
> >> + 7718, 7758, 7798, 7838, 7879, 7919, 7960, 8000, 8041, 8082, 8123, 8165,
> >> + 8206, 8248, 8289, 8331, 8373, 8415, 8457, 8500, 8542, 8585, 8628, 8671,
> >> + 8714, 8757, 8800, 8844, 8887, 8931, 8975, 9019, 9064, 9108, 9152, 9197,
> >> + 9242, 9287, 9332, 9377, 9423, 9468, 9514, 9560, 9606, 9652, 9698, 9745,
> >> + 9791, 9838, 9885, 9932, 9979, 10026, 10074, 10121, 10169, 10217, 10265,
> >> + 10313, 10362, 10410, 10459, 10508, 10557, 10606, 10655, 10704, 10754,
> >> + 10804, 10854, 10904, 10954, 11004, 11055, 11105, 11156, 11207, 11258,
> >> + 11310, 11361, 11413, 11464, 11516, 11568, 11620, 11673, 11725, 11778,
> >> + 11831, 11884, 11937, 11990, 12044, 12097, 12151, 12205, 12259, 12314,
> >> + 12368, 12423, 12477, 12532, 12587, 12643, 12698, 12754, 12809, 12865,
> >> + 12921, 12977, 13034, 13090, 13147, 13204, 13261, 13318, 13375, 13433,
> >> + 13491, 13548, 13606, 13665, 13723, 13781, 13840, 13899, 13958, 14017,
> >> + 14077, 14136, 14196, 14256, 14316, 14376, 14436, 14497, 14557, 14618,
> >> + 14679, 14740, 14802, 14863, 14925, 14987, 15049, 15111, 15173, 15236,
> >> + 15299, 15362, 15425, 15488, 15551, 15615, 15679, 15743, 15807, 15871,
> >> + 15935, 16000, 16065, 16130, 16195, 16260, 16326, 16392, 16457, 16523,
> >> + 16590, 16656, 16723, 16789, 16856, 16923, 16991, 17058, 17126, 17194,
> >> + 17261, 17330, 17398, 17467, 17535, 17604, 17673, 17742, 17812, 17881,
> >> + 17951, 18021, 18091, 18162, 18232, 18303, 18374, 18445, 18516, 18588,
> >> + 18659, 18731, 18803, 18875, 18947, 19020, 19093, 19166, 19239, 19312,
> >> + 19385, 19459, 19533, 19607, 19681, 19755, 19830, 19905, 19980, 20055,
> >> + 20130, 20206, 20281, 20357, 20433, 20510, 20586, 20663, 20740, 20817,
> >> + 20894, 20971, 21049, 21127, 21205, 21283, 21361, 21440, 21519, 21598,
> >> + 21677, 21756, 21836, 21915, 21995, 22075, 22156, 22236, 22317, 22398,
> >> + 22479, 22560, 22642, 22723, 22805, 22887, 22969, 23052, 23135, 23217,
> >> + 23300, 23384, 23467, 23551, 23635, 23719, 23803, 23887, 23972, 24057,
> >> + 24142, 24227, 24313, 24398, 24484, 24570, 24656, 24743, 24829, 24916,
> >> + 25003, 25091, 25178, 25266, 25354, 25442, 25530, 25618, 25707, 25796,
> >> + 25885, 25974, 26064, 26153, 26243, 26334, 26424, 26514, 26605, 26696,
> >> + 26787, 26879, 26970, 27062, 27154, 27246, 27338, 27431, 27524, 27617,
> >> + 27710, 27804, 27897, 27991, 28085, 28179, 28274, 28369, 28463, 28559,
> >> + 28654, 28749, 28845, 28941, 29037, 29134, 29230, 29327, 29424, 29521,
> >> + 29619, 29717, 29815, 29913, 30011, 30110, 30208, 30307, 30406, 30506,
> >> + 30605, 30705, 30805, 30906, 31006, 31107, 31208, 31309, 31410, 31512,
> >> + 31614, 31716, 31818, 31920, 32023, 32126, 32229, 32332, 32436, 32540,
> >> + 32644, 32748, 32852, 32957, 33062, 33167, 33272, 33378, 33484, 33590,
> >> + 33696, 33802, 33909, 34016, 34123, 34230, 34338, 34446, 34554, 34662,
> >> + 34770, 34879, 34988, 35097, 35206, 35316, 35426, 35536, 35646, 35757,
> >> + 35867, 35978, 36090, 36201, 36313, 36425, 36537, 36649, 36762, 36874,
> >> + 36987, 37101, 37214, 37328, 37442, 37556, 37671, 37785, 37900, 38015,
> >> + 38131, 38246, 38362, 38478, 38594, 38711, 38828, 38945, 39062, 39179,
> >> + 39297, 39415, 39533, 39651, 39770, 39889, 40008, 40127, 40247, 40367,
> >> + 40487, 40607, 40728, 40848, 40969, 41091, 41212, 41334, 41456, 41578,
> >> + 41700, 41823, 41946, 42069, 42193, 42316, 42440, 42564, 42689, 42813,
> >> + 42938, 43063, 43189, 43314, 43440, 43566, 43692, 43819, 43946, 44073,
> >> + 44200, 44328, 44456, 44584, 44712, 44840, 44969, 45098, 45227, 45357,
> >> + 45487, 45617, 45747, 45877, 46008, 46139, 46270, 46402, 46534, 46666,
> >> + 46798, 46930, 47063, 47196, 47329, 47463, 47596, 47730, 47865, 47999,
> >> + 48134, 48269, 48404, 48540, 48675, 48811, 48948, 49084, 49221, 49358,
> >> + 49495, 49633, 49771, 49909, 50047, 50185, 50324, 50463, 50603, 50742,
> >> + 50882, 51022, 51162, 51303, 51444, 51585, 51726, 51868, 52010, 52152,
> >> + 52294, 52437, 52580, 52723, 52867, 53010, 53154, 53299, 53443, 53588,
> >> + 53733, 53878, 54024, 54169, 54315, 54462, 54608, 54755, 54902, 55050,
> >> + 55197, 55345, 55493, 55642, 55790, 55939, 56089, 56238, 56388, 56538,
> >> + 56688, 56839, 56989, 57140, 57292, 57443, 57595, 57747, 57900, 58053,
> >> + 58205, 58359, 58512, 58666, 58820, 58974, 59129, 59284, 59439, 59594,
> >> + 59750, 59906, 60062, 60218, 60375, 60532, 60689, 60847, 61005, 61163,
> >> + 61321, 61480, 61639, 61798, 61957, 62117, 62277, 62437, 62598, 62759,
> >> + 62920, 63081, 63243, 63405, 63567, 63729, 63892, 64055, 64219, 64382,
> >> + 64546, 64710, 64875, 65039, 65204, 65369, 65535,
> >> +};
> >> +
> >> struct pwm_bl_data {
> >> struct pwm_device *pwm;
> >> struct device *dev;
> >> @@ -38,6 +144,7 @@ struct pwm_bl_data {
> >> unsigned int scale;
> >> bool legacy;
> >> bool piecewise;
> >> + bool use_lth_table;
> >
> > Again, I didn't think we'd need to special case the lookup table except
> > in the probe method. It's "just" a built-in levels table (ideally
> > reinforced with with code to figure out how many steps to interpolate).
> >
>
> Ok.
>
> >
> >> int (*notify)(struct device *,
> >> int brightness);
> >> void (*notify_after)(struct device *,
> >> @@ -104,6 +211,8 @@ static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness)
> >> } else {
> >> duty_cycle = scale(pb, pb->levels[brightness]);
> >> }
> >> + } else if (pb->use_lth_table) {
> >> + duty_cycle = cie1931_table[brightness];
> >> } else {
> >> duty_cycle = scale(pb, brightness);
> >> }
> >> @@ -169,9 +278,9 @@ static int pwm_backlight_parse_dt(struct device *dev,
> >> /* determine the number of brightness levels */
> >> prop = of_find_property(node, "brightness-levels", &length);
> >> if (!prop)
> >> - return -EINVAL;
> >> -
> >> - data->levels_count = length / sizeof(u32);
> >> + data->use_lth_table = true;
> >> + else
> >> + data->levels_count = length / sizeof(u32);
> >>
> >> /* read brightness levels from DT property */
> >> if (data->levels_count > 0) {
> >> @@ -181,24 +290,28 @@ static int pwm_backlight_parse_dt(struct device *dev,
> >> if (!data->levels)
> >> return -ENOMEM;
> >>
> >> - ret = of_property_read_u32_array(node, "brightness-levels",
> >> - data->levels,
> >> - data->levels_count);
> >> - if (ret < 0)
> >> - return ret;
> >> -
> >> - ret = of_property_read_u32(node, "default-brightness-level",
> >> - &value);
> >> - if (ret < 0)
> >> - return ret;
> >> + if (prop) {
> >> + ret = of_property_read_u32_array(node,
> >> + "brightness-levels",
> >> + data->levels,
> >> + data->levels_count);
> >> + if (ret < 0)
> >> + return ret;
> >> + }
> >>
> >> data->piecewise = of_property_read_bool(node,
> >> "use-linear-interpolation");
> >>
> >> - data->dft_brightness = value;
> >> data->levels_count--;
> >> }
> >>
> >> + ret = of_property_read_u32(node, "default-brightness-level",
> >> + &value);
> >> + if (ret < 0)
> >> + return ret;
> >> +
> >> + data->dft_brightness = value;
> >> +
> >> if (data->piecewise)
> >> data->max_brightness = data->levels_count * NSTEPS;
> >> else
> >> @@ -260,8 +373,10 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> >> struct backlight_device *bl;
> >> struct device_node *node = pdev->dev.of_node;
> >> struct pwm_bl_data *pb;
> >> + struct pwm_state state;
> >> struct pwm_args pargs;
> >> int ret;
> >> + int i;
> >>
> >> if (!data) {
> >> ret = pwm_backlight_parse_dt(&pdev->dev, &defdata);
> >> @@ -303,6 +418,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> >> pb->dev = &pdev->dev;
> >> pb->enabled = false;
> >> pb->piecewise = data->piecewise;
> >> + pb->use_lth_table = data->use_lth_table;
> >>
> >> pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
> >> GPIOD_ASIS);
> >> @@ -361,6 +477,22 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> >>
> >> dev_dbg(&pdev->dev, "got pwm for backlight\n");
> >>
> >> + if (pb->use_lth_table) {
> >> + /* Get PWM resolution */
> >> + pwm_get_state(pb->pwm, &state);
> >> + if (state.period > 65535) {
> >> + dev_err(&pdev->dev, "PWM resolution not supported\n");
> >> + goto err_alloc;
> >> + }
> >> + /* Find the number of steps based on the PWM resolution */
> >> + for (i = 0; i < ARRAY_SIZE(cie1931_table); i++)
> >> + if (cie1931_table[i] >= state.period) {
> >> + data->max_brightness = i;
> >> + break;
> >> + }
> >> + pb->scale = data->max_brightness;
> >> + }
> >> +
> >> /*
> >> * FIXME: pwm_apply_args() should be removed when switching to
> >> * the atomic PWM API.
> >> diff --git a/include/linux/pwm_backlight.h b/include/linux/pwm_backlight.h
> >> index 444a91b..4ec3b0d 100644
> >> --- a/include/linux/pwm_backlight.h
> >> +++ b/include/linux/pwm_backlight.h
> >> @@ -15,6 +15,7 @@ struct platform_pwm_backlight_data {
> >> unsigned int pwm_period_ns;
> >> unsigned int *levels;
> >> unsigned int levels_count;
> >> + bool use_lth_table;
> >
> > Why not just "if (!levels)"?
> >
>
> Yep, should work.
>
> >> bool piecewise;
> >> /* TODO remove once all users are switched to gpiod_* API */
> >> int enable_gpio;
> >> --
> >> 2.9.3
> >>
>
> If it's ok I'll send a first version (no RFC) of the patchet adding
> your comments.
Yes, I think this is more than practical enough to lose the RFC.
Daniel.
--
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: [RFC v2 1/2] backlight: pwm_bl: linear interpolation between values of brightness-levels
From: Daniel Thompson @ 2017-12-18 13:15 UTC (permalink / raw)
To: Enric Balletbo Serra
Cc: Enric Balletbo i Serra, Jingoo Han, Richard Purdie,
Jacek Anaszewski, Pavel Machek, Rob Herring, Doug Anderson,
Brian Norris, Guenter Roeck, Lee Jones, Alexandru Stan,
linux-leds, devicetree@vger.kernel.org, linux-kernel
In-Reply-To: <CAFqH_51O5zqDUJiRp5nktM-ks=URkgCwMSy9fhbZG6D0qarJrg@mail.gmail.com>
On Mon, Dec 18, 2017 at 10:47:24AM +0100, Enric Balletbo Serra wrote:
> Hi Daniel,
>
> 2017-12-15 15:40 GMT+01:00 Daniel Thompson <daniel.thompson@linaro.org>:
> > On Thu, Nov 16, 2017 at 03:11:50PM +0100, Enric Balletbo i Serra wrote:
> >>
> >> Setting use-linear-interpolation in the dts will allow you to have linear
> >> interpolation between values of brightness-levels.
> >>
> >> There are now 256 between each of the values of brightness-levels. If
> >> something is requested halfway between 2 values, we'll use linear
> >> interpolation.
> >
> > Why 256?
>
> To be honest there isn't a strong reason, I thought that 256 was a
> good value because is the minimum number of steps possible (8 bits
> pwm). But yeah, guess the discussion is more if this value should be
> calculated, or specified in the the DT more than the value itself.
>
> >>
> >> This way a high resolution pwm duty cycle can be used without having to
> >> list out every possible value in the dts. This system also allows for
> >> gamma corrected values (eg: "brightness-levels = <0 2 4 8 16 32>;").
> >>
> >> Patch based on the Alexandru M Stan work done for ChromeOS kernels.
> >>
> >> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >> ---
> >> .../bindings/leds/backlight/pwm-backlight.txt | 2 +
> >> drivers/video/backlight/pwm_bl.c | 55 +++++++++++++++++-----
> >> include/linux/pwm_backlight.h | 2 +
> >> 3 files changed, 47 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> >> index 764db86..7c48f20 100644
> >> --- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> >> +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> >> @@ -17,6 +17,8 @@ Optional properties:
> >> "pwms" property (see PWM binding[0])
> >> - enable-gpios: contains a single GPIO specifier for the GPIO which enables
> >> and disables the backlight (see GPIO binding[1])
> >> + - use-linear-interpolation: set this propriety to enable linear interpolation
> >> + between each of the values of brightness-levels.
> >
> > Deciding whether or not this deployment of interpolation is a property
> > of the hardware is a finely balanced judgement. On the whole I conclude
> > that since the lookup table is a property of the hardware so too is the
> > deployment of interpolation.
> >
> > Following up on the "why 256?" comment. IMHO either the number of
> > interpolated steps should be calculated from the underlying PWM
> > resolution or it could simply be specified in the DT (e.g. replace
> > use-linear-interpolation with num-interpolated-steps).
> >
>
> Personally I like the idea to have the possibility to specify the
> number of interpolated steps in the DT, I think that will be more
> flexible for the user. If it's ok let me send a first version using
> num-interpolated-steps, and continue the discussion about if makes
> sense to have that in the DT or not.
It's ok from my side.
Daniel.
^ permalink raw reply
* Re: [PATCH v4 2/2] misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver
From: Michal Simek @ 2017-12-18 13:13 UTC (permalink / raw)
To: Arnd Bergmann, Dhaval Shah
Cc: gregkh, Rob Herring, Mark Rutland, Randy Dunlap, DTML,
Linux Kernel Mailing List, Michal Simek, Hyun Kwon, Dhaval Shah
In-Reply-To: <CAK8P3a0nm_-pxGWXHx_FAXgXt1msE2bK0D4paBMWgryPyeS9xA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 15.12.2017 14:26, Arnd Bergmann wrote:
> In Fri, Dec 15, 2017 at 8:24 AM, Dhaval Shah <dhaval.shah-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
>> Xilinx ZYNQMP logicoreIP Init driver is based on the new
>> LogiCoreIP design created. This driver provides the processing system
>> and programmable logic isolation. Set the frequency based on the clock
>> information get from the logicoreIP register set.
>>
>> It is put in drivers/misc as there is no subsystem for this logicoreIP.
>>
>> Signed-off-by: Dhaval Shah <dshah-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
>
> After giving this some more thought, I'd suggest you move the driver to
> drivers/soc/xilinx or drivers/soc/zynq instead of drivers/misc/, and have
> it merged by Michal Simek as a driver patch that will go through arm-soc.
I have not a problem of creating drivers/soc/xilinx/ location for this
driver. It is not zynq (arm32) but zynqmp(arm64) device where this
driver can be used. As far as I understand it is memory mapped soft IP
which could be also accessed by soft core CPU.
It means drivers/soc/xilinx could be shared by all xilinx platforms anyway.
We have been discussing that openrisc cases and for sure if someone
wants to enable this driver there using misc location would be one
option but I also think that using drivers/soc/xilinx location is not a
bad option because it is very unlikely that anybody tries it.
Arnd: misc or drivers/soc/xilinx?
Thanks,
Michal
--
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 2/6] dt: bindings: lp8860: Update DT label binding
From: Dan Murphy @ 2017-12-18 13:08 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland, rpurdie, jacek.anaszewski, pavel, devicetree,
linux-kernel, linux-leds
In-Reply-To: <20171215225914.62lqxhcmwajf4hpy@rob-hp-laptop>
Rob
On 12/15/2017 04:59 PM, Rob Herring wrote:
> On Tue, Dec 12, 2017 at 04:01:39PM -0600, Dan Murphy wrote:
>> Update the lp8860 label binding to the LED
>> standard as documented in
>>
>> Documentation/devicetree/bindings/leds/common.txt
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
>>
>> v4 - No changes
>>
>> v3 - Added address and size cells, updated label with color and inserted spaces
>> around the reg node - https://patchwork.kernel.org/patch/10093749/
>> v2 - Added reg to child node and made it required
>>
>> Documentation/devicetree/bindings/leds/leds-lp8860.txt | 17 +++++++++++++++--
>> 1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
>> index b9d09acbaa73..c3d64ade1e26 100644
>> --- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
>> +++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
>> @@ -9,20 +9,33 @@ Required properties:
>> - compatible :
>> "ti,lp8860"
>> - reg : I2C slave address
>> - - label : Used for naming LEDs
>> + - #address-cells : 1
>> + - #size-cells : 0
>>
>> Optional properties:
>> - enable-gpios : gpio pin to enable (active high)/disable the device.
>> - vled-supply : LED supply
>>
>> +Required child properties:
>> + - reg : 0
>> +
>
> This should be in previous patch?
No this is the reg node for the child property. The child property is
introduced in this patch. So this should be correct
Dan
>
>> +Optional child properties:
>> + - label : see Documentation/devicetree/bindings/leds/common.txt
>> +
>> Example:
>>
>> led-controller@2d {
>> compatible = "ti,lp8860";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> reg = <0x2d>;
>> - label = "display_cluster";
>> enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
>> vled-supply = <&vbatt>;
>> +
>> + led@0 {
>> + reg = <0>;
>> + label = "white:display_cluster";
>> + };
>> }
>>
>> For more product information please see the link below:
>> --
>> 2.15.0.124.g7668cbc60
>>
--
------------------
Dan Murphy
^ permalink raw reply
* Re: [PATCH v2 9/9] ARM: dts: imx7: add Toradex Colibri iMX7D 1GB (eMMC) support
From: Stefan Agner @ 2017-12-18 12:58 UTC (permalink / raw)
To: Philippe Ombredanne
Cc: Fabio Estevam, Shawn Guo, Sascha Hauer, Fabio Estevam,
Rob Herring, Mark Rutland,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel
In-Reply-To: <CAOFm3uHFcHnh-CHLfJwgeB1M8niWBtdpVv-f+Dr7b43f70zwbw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 2017-12-17 23:55, Philippe Ombredanne wrote:
> Fabio,
>
> On Sun, Dec 17, 2017 at 10:59 PM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Hi Stefan,
>>
>> On Sun, Dec 17, 2017 at 6:37 PM, Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> wrote:
>>
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts
>>> @@ -0,0 +1,20 @@
>>> +/*
>>> + * Copyright 2017 Toradex AG
>>> + *
>>> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>>> + */
>>
>> In the previous patch you used GPL-2.0 text, instead of GPL-2.0+.
>>
>> The SPDX line should be the first one and start with a // style comment:
>>
>> // SPDX-License-Identifier: (GPL-2.0 OR MIT)
Hm, good catch, I copied the above from some uniphier device tree. Will
fix.
>
> Yes this line as the top line is the correct way as explained in
> Thomas doc patches [1]
> I cannot comment of whether the author wants GPL 2 or 2+ though KISS is best.
>
> [1] https://lkml.org/lkml/2017/12/4/934
>
Oh, I see now, you refer to that patch in particular:
https://lkml.org/lkml/2017/12/4/942
>> Philippe, please confirm this is the correct way.
>>
>> With this fixed you can add:
>>
>> Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
Thank!
--
Stefan
--
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] touchscreen: mms114: add support for mms152
From: Simon Shields @ 2017-12-18 12:49 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Simon Shields
MMS152 has no configuration registers, but the packet format used in
interrupts is identical to mms114.
Signed-off-by: Simon Shields <simon-WP75azK+jQYgsBAKwltoeQ@public.gmane.org>
---
.../bindings/input/touchscreen/mms114.txt | 8 ++--
drivers/input/touchscreen/mms114.c | 55 +++++++++++++++++++---
include/linux/platform_data/mms114.h | 6 +++
3 files changed, 58 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/mms114.txt b/Documentation/devicetree/bindings/input/touchscreen/mms114.txt
index 89d4c56c5671..733411020ced 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/mms114.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/mms114.txt
@@ -1,15 +1,15 @@
-* MELFAS MMS114 touchscreen controller
+* MELFAS MMS114/MMS152 touchscreen controller
Required properties:
-- compatible: must be "melfas,mms114"
+- compatible: "melfas,mms114" for MMS114, or "melfas,mms152" for MMS152
- reg: I2C address of the chip
- interrupts: interrupt to which the chip is connected
- x-size: horizontal resolution of touchscreen
- y-size: vertical resolution of touchscreen
Optional properties:
-- contact-threshold:
-- moving-threshold:
+- contact-threshold: only with "melfas,mms114"
+- moving-threshold: only with "melfas,mms114"
- x-invert: invert X axis
- y-invert: invert Y axis
diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
index e5eeb6311f7d..d01f36442788 100644
--- a/drivers/input/touchscreen/mms114.c
+++ b/drivers/input/touchscreen/mms114.c
@@ -10,6 +10,7 @@
#include <linux/module.h>
#include <linux/delay.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/i2c.h>
#include <linux/input/mt.h>
#include <linux/interrupt.h>
@@ -33,6 +34,9 @@
#define MMS114_INFOMATION 0x10
#define MMS114_TSP_REV 0xF0
+#define MMS152_FW_REV 0xE1
+#define MMS152_COMPAT_GROUP 0xF2
+
/* Minimum delay time is 50us between stop and start signal of i2c */
#define MMS114_I2C_DELAY 50
@@ -251,12 +255,27 @@ static int mms114_get_version(struct mms114_data *data)
u8 buf[6];
int error;
- error = __mms114_read_reg(data, MMS114_TSP_REV, 6, buf);
- if (error < 0)
- return error;
+ switch (data->pdata->type) {
+ case TYPE_MMS152:
+ error = __mms114_read_reg(data, MMS152_FW_REV, 3, buf);
+ if (error < 0)
+ return error;
+ buf[3] = i2c_smbus_read_byte_data(data->client,
+ MMS152_COMPAT_GROUP);
+ if (buf[3] < 0)
+ return buf[3];
+ dev_info(dev, "TSP FW Rev: bootloader 0x%x / core 0x%x / config 0x%x, Compat group: %c\n",
+ buf[0], buf[1], buf[2], buf[3]);
+ break;
+ case TYPE_MMS114:
+ error = __mms114_read_reg(data, MMS114_TSP_REV, 6, buf);
+ if (error < 0)
+ return error;
- dev_info(dev, "TSP Rev: 0x%x, HW Rev: 0x%x, Firmware Ver: 0x%x\n",
- buf[0], buf[1], buf[3]);
+ dev_info(dev, "TSP Rev: 0x%x, HW Rev: 0x%x, Firmware Ver: 0x%x\n",
+ buf[0], buf[1], buf[3]);
+ break;
+ }
return 0;
}
@@ -271,6 +290,11 @@ static int mms114_setup_regs(struct mms114_data *data)
if (error < 0)
return error;
+ if (data->pdata->type == TYPE_MMS152) {
+ /* MMS152 has no configuration or power on registers */
+ return 0;
+ }
+
error = mms114_set_active(data, true);
if (error < 0)
return error;
@@ -391,6 +415,8 @@ static struct mms114_platform_data *mms114_parse_dt(struct device *dev)
return NULL;
}
+ pdata->type = (enum mms_type)of_device_get_match_data(dev);
+
if (of_property_read_u32(np, "x-size", &pdata->x_size)) {
dev_err(dev, "failed to get x-size property\n");
return NULL;
@@ -411,6 +437,7 @@ static struct mms114_platform_data *mms114_parse_dt(struct device *dev)
if (of_find_property(np, "y-invert", NULL))
pdata->y_invert = true;
+
return pdata;
}
#else
@@ -456,7 +483,15 @@ static int mms114_probe(struct i2c_client *client,
data->input_dev = input_dev;
data->pdata = pdata;
- input_dev->name = "MELFAS MMS114 Touchscreen";
+ switch (pdata->type) {
+ case TYPE_MMS114:
+ input_dev->name = "MELFAS MMS114 Touchscreen";
+ break;
+ case TYPE_MMS152:
+ input_dev->name = "MELFAS MMS152 Touchscreen";
+ break;
+ }
+
input_dev->id.bustype = BUS_I2C;
input_dev->dev.parent = &client->dev;
input_dev->open = mms114_input_open;
@@ -569,7 +604,13 @@ MODULE_DEVICE_TABLE(i2c, mms114_id);
#ifdef CONFIG_OF
static const struct of_device_id mms114_dt_match[] = {
- { .compatible = "melfas,mms114" },
+ {
+ .compatible = "melfas,mms114",
+ .data = (void *)TYPE_MMS114,
+ }, {
+ .compatible = "melfas,mms152",
+ .data = (void *)TYPE_MMS152,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, mms114_dt_match);
diff --git a/include/linux/platform_data/mms114.h b/include/linux/platform_data/mms114.h
index 5722ebfb2738..58e4c463bf0c 100644
--- a/include/linux/platform_data/mms114.h
+++ b/include/linux/platform_data/mms114.h
@@ -10,6 +10,11 @@
#ifndef __LINUX_MMS114_H
#define __LINUX_MMS114_H
+enum mms_type {
+ TYPE_MMS114,
+ TYPE_MMS152,
+};
+
struct mms114_platform_data {
unsigned int x_size;
unsigned int y_size;
@@ -17,6 +22,7 @@ struct mms114_platform_data {
unsigned int moving_threshold;
bool x_invert;
bool y_invert;
+ enum mms_type type;
void (*cfg_pin)(bool);
};
--
2.15.1
--
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 v6] mfd: syscon: Add hardware spinlock support
From: Arnd Bergmann @ 2017-12-18 12:44 UTC (permalink / raw)
To: Baolin Wang
Cc: Lee Jones, Rob Herring, Mark Rutland, Mark Brown,
Linux Kernel Mailing List, DTML
In-Reply-To: <CAMz4ku+KfQRoLTO-T3ciS-1Z9oD=y0LJ25n-YDUMr+aYetbt9A@mail.gmail.com>
On Mon, Dec 18, 2017 at 7:54 AM, Baolin Wang <baolin.wang@linaro.org> wrote:
> On 15 December 2017 at 21:13, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Fri, Dec 15, 2017 at 11:42 AM, Lee Jones <lee.jones@linaro.org> wrote:
>>
>>>> @@ -87,6 +88,30 @@ static struct syscon *of_syscon_register(struct device_node *np)
>>>> if (ret)
>>>> reg_io_width = 4;
>>>>
>>>> + ret = of_hwspin_lock_get_id(np, 0);
>>>> + if (ret > 0) {
>>>> + syscon_config.hwlock_id = ret;
>>>> + syscon_config.hwlock_mode = HWLOCK_IRQSTATE;
>>>> + } else {
>>>> + switch (ret) {
>>>> + case -ENOENT:
>>>> + /* Ignore missing hwlock, it's optional. */
>>>> + break;
>>>> + case 0:
>>>> + /* In case of the HWSPINLOCK is not enabled. */
>>>> + if (!IS_ENABLED(CONFIG_HWSPINLOCK))
>>>> + break;
>>>> +
>>>> + ret = -EINVAL;
>>>> + /* fall-through */
>>>> + default:
>>>> + pr_err("Failed to retrieve valid hwlock: %d\n", ret);
>>>> + /* fall-through */
>>>> + case -EPROBE_DEFER:
>>>> + goto err_regmap;
>>>> + }
>>
>> The 'case 0' seems odd here, are we sure that this is always a failure?
>> From the of_hwspin_lock_get_id() definition it looks like zero might
>> be valid, and the !CONFIG_HWSPINLOCK implementation appears
>> to be written so that we should consider '0' valid but unused and
>> silently continue with that. If that is generally not the intended
>> use, it should probably return -EINVAL or something like that.
>
> Yes, 0 is valid for of_hwspin_lock_get_id(), but if we pass 'hwlock id
> = 0' to regmap, the regmap core will not regard it as a valid hwlock
> id to request the hwlock and will use default mutex lock instead of
> hwlock, which will cause problems. Meanwhile if we silently continue
> with case 0, users will not realize that they set one invalid hwlock
> id to regmap core, so here we regarded case 0 as one invalid id to
> print error messages for users.
Something else still seems wrong then: If regmap doesn't accept a zero
lock-id, then of_hwspin_lock_get_id() should never return that as a
valid ID, right?
Arnd
^ permalink raw reply
* Re: [PATCH 1/5] media: rc: update sunxi-ir driver to get base clock frequency from devicetree
From: Philipp Rossak @ 2017-12-18 12:43 UTC (permalink / raw)
To: Andi Shyti
Cc: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171218024444.GA9140-8vUhnHFVuGn35fTxX1Dczw@public.gmane.org>
Hey Andi,
thanks for the feedback. I will fix that in the next version of this
patch series!
On 18.12.2017 03:44, Andi Shyti wrote:
> Hi Philipp,
>
> just a couple of small nitpicks.
>
>> + u32 b_clk_freq;
>
> [...]
>
>> + /* Base clock frequency (optional) */
>> + if (of_property_read_u32(dn, "clock-frequency", &b_clk_freq)) {
>> + b_clk_freq = SUNXI_IR_BASE_CLK;
>> + }
>> +
>
> how about you intialize 'b_clk_freq' to 'SUNXI_IR_BASE_CLK' and
> just call 'of_property_read_u32' without if statement.
> 'b_clk_freq' value should not be changed if "clock-frequency"
> is not present in the DTS.
>
> This might avoid misinterpretation from static analyzers that
> might think that 'b_clk_freq' is used uninitialized.
>
>> + dev_info(dev, "set base clock frequency to %d Hz.\n", b_clk_freq);
>
> Please use dev_dbg().
>
> Andi
>
--
Philipp
^ permalink raw reply
* [PATCH v3 4/4] ARM: exynos: extend cpuidle support to midas boards
From: Simon Shields @ 2017-12-18 12:38 UTC (permalink / raw)
To: linux-samsung-soc
Cc: Kukjin Kim, Krzysztof Kozlowski, devicetree, Marek Szyprowski,
Bartłomiej Żołnierkiewicz, Simon Shields
In-Reply-To: <20171218123805.26345-1-simon@lineageos.org>
Exynos4412 can only use cpuidle when running under a compatible
bootloader/firmware. The midas family of boards, including trats2,
have such a firmware, so allow them to use cpuidle.
Leave the trats2 check there in order to preserve the ABI.
Signed-off-by: Simon Shields <simon@lineageos.org>
---
arch/arm/mach-exynos/exynos.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 9a9caac1125a..4ee60e31ea48 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -196,7 +196,8 @@ static void __init exynos_dt_machine_init(void)
#endif
if (of_machine_is_compatible("samsung,exynos4210") ||
(of_machine_is_compatible("samsung,exynos4412") &&
- of_machine_is_compatible("samsung,trats2")) ||
+ (of_machine_is_compatible("samsung,trats2") ||
+ of_machine_is_compatible("samsung,midas"))) ||
of_machine_is_compatible("samsung,exynos3250") ||
of_machine_is_compatible("samsung,exynos5250"))
platform_device_register(&exynos_cpuidle);
--
2.15.1
^ permalink raw reply related
* [PATCH v3 3/4] ARM: dts: add Samsung's exynos4412-based midas boards
From: Simon Shields @ 2017-12-18 12:38 UTC (permalink / raw)
To: linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA
Cc: Kukjin Kim, Krzysztof Kozlowski,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marek Szyprowski,
Bartłomiej Żołnierkiewicz, Simon Shields
In-Reply-To: <20171218123805.26345-1-simon-WP75azK+jQYgsBAKwltoeQ@public.gmane.org>
"midas" is the codename for a family of smartphones released by Samsung
Mobile. It includes the Galaxy S3 (GT-I9300/I9305) and the Galaxy
Note 2 (GT-N7100/N7105). The boards largely have the same peripherals:
the main differences are touchscreen, display panel and cellular modem.
Signed-off-by: Simon Shields <simon-WP75azK+jQYgsBAKwltoeQ@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 3 +++
arch/arm/boot/dts/exynos4412-m0.dts | 27 +++++++++++++++++++++++++
arch/arm/boot/dts/exynos4412-m3.dts | 14 +++++++++++++
arch/arm/boot/dts/exynos4412-t0.dts | 40 +++++++++++++++++++++++++++++++++++++
4 files changed, 84 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos4412-m0.dts
create mode 100644 arch/arm/boot/dts/exynos4412-m3.dts
create mode 100644 arch/arm/boot/dts/exynos4412-t0.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 66e28af289da..035abd66b472 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -164,11 +164,14 @@ dtb-$(CONFIG_ARCH_EXYNOS4) += \
exynos4210-trats.dtb \
exynos4210-universal_c210.dtb \
exynos4412-itop-elite.dtb \
+ exynos4412-m0.dtb \
+ exynos4412-m3.dtb \
exynos4412-odroidu3.dtb \
exynos4412-odroidx.dtb \
exynos4412-odroidx2.dtb \
exynos4412-origen.dtb \
exynos4412-smdk4412.dtb \
+ exynos4412-t0.dtb \
exynos4412-tiny4412.dtb \
exynos4412-trats2.dtb
dtb-$(CONFIG_ARCH_EXYNOS5) += \
diff --git a/arch/arm/boot/dts/exynos4412-m0.dts b/arch/arm/boot/dts/exynos4412-m0.dts
new file mode 100644
index 000000000000..56c1ea6b5695
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-m0.dts
@@ -0,0 +1,27 @@
+/*
+ * Samsung's Exynos4412 based M0 (GT-I9300) board device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Device tree source file for Samsung's M0 board which is based on
+ * Samsung's Exynos4412 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+#include "exynos4412-galaxy-s3.dtsi"
+
+/ {
+ model = "Samsung M0 (GT-I9300) based on Exynos4412";
+ compatible = "samsung,m0", "samsung,midas", "samsung,exynos4412", "samsung,exynos4";
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0x40000000 0x40000000>;
+ };
+
+};
diff --git a/arch/arm/boot/dts/exynos4412-m3.dts b/arch/arm/boot/dts/exynos4412-m3.dts
new file mode 100644
index 000000000000..80431044f07a
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-m3.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+#include "exynos4412-galaxy-s3.dtsi"
+
+/ {
+ model = "Samsung M3 (GT-I9305) based on Exynos4412";
+ compatible = "samsung,m3", "samsung,midas", "samsung,exynos4412", "samsung,exynos4";
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0x40000000 0x80000000>;
+ };
+
+};
diff --git a/arch/arm/boot/dts/exynos4412-t0.dts b/arch/arm/boot/dts/exynos4412-t0.dts
new file mode 100644
index 000000000000..1444e893fb0e
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-t0.dts
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+#include "exynos4412-midas.dtsi"
+
+/ {
+ compatible = "samsung,t0", "samsung,midas", "samsung,exynos4412", "samsung,exynos4";
+ model = "Samsung T0 (GT-N7100, GT-N7105) based on Exynos4412";
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0x40000000 0x80000000>;
+ };
+};
+
+&buck9_reg {
+ maxim,ena-gpios = <&gpm1 0 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+&cam_io_reg {
+ gpio = <&gpm0 7 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+&cam_af_reg {
+ gpio = <&gpm1 1 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+&ldo13_reg {
+ regulator-name = "VCC_1.8V_LCD";
+ regulator-always-on;
+};
+
+&ldo25_reg {
+ regulator-name = "VCI_3.0V_LCD";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ status = "okay";
+};
--
2.15.1
--
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