* Re: [PATCH v3 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
From: Maxime Ripard @ 2017-12-18 9:24 UTC (permalink / raw)
To: Yong
Cc: wens-jdAy2FN1RRM, Mauro Carvalho Chehab, Rob Herring,
Mark Rutland, David S. Miller, Greg Kroah-Hartman, Hans Verkuil,
Randy Dunlap, Benoit Parrot, Stanimir Varbanov, Arnd Bergmann,
Hugues Fruchet, Philipp Zabel, Benjamin Gaignard,
Ramesh Shanmugasundaram, Yannick Fertre, Sakari Ailus, Rick Chang,
Linux Media Mailing List, devicetree, linux-arm-kernel
In-Reply-To: <20171218164921.227b82349c778283f5e5eba8-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 708 bytes --]
Hi,
On Mon, Dec 18, 2017 at 04:49:21PM +0800, Yong wrote:
> > > + compatible = "allwinner,sun8i-v3s-csi";
> > > + reg = <0x01cb4000 0x1000>;
> > > + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&ccu CLK_BUS_CSI>,
> > > + <&ccu CLK_CSI1_SCLK>,
> >
> > CSI also has an MCLK. Do you need that one?
>
> MCLK is not needed if the front end is not a sensor (like adv7611).
> I will add it as an option.
I guess this should always be needed then. And the driver will make
the decision to enable it or not.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 03/19] ARM: dts: aspeed: Add LPC and child devices
From: Cédric Le Goater @ 2017-12-18 9:25 UTC (permalink / raw)
To: Joel Stanley, Rob Herring, Mark Rutland, Arnd Bergmann,
Andrew Jeffery, Patrick Venture, Xo Wang, Lei YU
Cc: Benjamin Herrenschmidt, Jeremy Kerr, devicetree, linux-arm-kernel,
linux-kernel, linux-aspeed
In-Reply-To: <20171215062443.23059-4-joel@jms.id.au>
On 12/15/2017 07:24 AM, Joel Stanley wrote:
> From: Andrew Jeffery <andrew@aj.id.au>
>
> Ensure the ordering is correct and add all of the children in the SoC
> device trees for the ast2400 and ast2500.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> arch/arm/boot/dts/aspeed-g4.dtsi | 35 +++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/aspeed-g5.dtsi | 27 +++++++++++++++++----------
> 2 files changed, 52 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
> index 100d092e6c07..a3bc5da7d42c 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -226,6 +226,41 @@
> status = "disabled";
> };
>
> + lpc: lpc@1e789000 {
> + compatible = "aspeed,ast2400-lpc", "simple-mfd";
> + reg = <0x1e789000 0x1000>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x1e789000 0x1000>;
> +
> + lpc_bmc: lpc-bmc@0 {
> + compatible = "aspeed,ast2400-lpc-bmc";
> + reg = <0x0 0x80>;
> + };
> +
> + lpc_host: lpc-host@80 {
> + compatible = "aspeed,ast2400-lpc-host", "simple-mfd", "syscon";
> + reg = <0x80 0x1e0>;
> + reg-io-width = <4>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x80 0x1e0>;
> +
> + lpc_ctrl: lpc-ctrl@0 {
> + compatible = "aspeed,ast2400-lpc-ctrl";
> + reg = <0x0 0x80>;
> + status = "disabled";
> + };
> +
> + lhc: lhc@20 {
> + compatible = "aspeed,ast2500-lhc";
aspeed,ast2400-lhc
The layout of the registers are the same but there a couple of differences
in the bit definitions between the two SoCs.
a part from that :
Reviewed-by: Cédric Le Goater <clg@kaod.org>
C.
> + reg = <0x20 0x24 0x48 0x8>;
> + };
> + };
> + };
> +
> uart2: serial@1e78d000 {
> compatible = "ns16550a";
> reg = <0x1e78d000 0x20>;
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 1f9d28313f82..7861631940fe 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -266,6 +266,16 @@
> status = "disabled";
> };
>
> + vuart: serial@1e787000 {
> + compatible = "aspeed,ast2500-vuart";
> + reg = <0x1e787000 0x40>;
> + reg-shift = <2>;
> + interrupts = <10>;
> + clocks = <&clk_uart>;
> + no-loopback-test;
> + status = "disabled";
> + };
> +
> lpc: lpc@1e789000 {
> compatible = "aspeed,ast2500-lpc", "simple-mfd";
> reg = <0x1e789000 0x1000>;
> @@ -289,6 +299,13 @@
>
> reg-io-width = <4>;
>
> + lpc_ctrl: lpc-ctrl@0 {
> + compatible = "aspeed,ast2500-lpc-ctrl";
> + reg = <0x0 0x80>;
> + status = "disabled";
> + };
> +
> +
> lhc: lhc@20 {
> compatible = "aspeed,ast2500-lhc";
> reg = <0x20 0x24 0x48 0x8>;
> @@ -296,16 +313,6 @@
> };
> };
>
> - vuart: serial@1e787000 {
> - compatible = "aspeed,ast2500-vuart";
> - reg = <0x1e787000 0x40>;
> - reg-shift = <2>;
> - interrupts = <10>;
> - clocks = <&clk_uart>;
> - no-loopback-test;
> - status = "disabled";
> - };
> -
> uart2: serial@1e78d000 {
> compatible = "ns16550a";
> reg = <0x1e78d000 0x20>;
>
^ permalink raw reply
* Re: [PATCH 1/1] arm: sunxi: Add alternative pins for spi0
From: Maxime Ripard @ 2017-12-18 9:28 UTC (permalink / raw)
To: Stefan Mavrodiev
Cc: Stefan Mavrodiev, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Rob Herring,
Mark Rutland, Russell King, Chen-Yu Tsai,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM PORT, open list
In-Reply-To: <ca648552-cefb-e19d-72cf-8b56e97b013d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]
On Mon, Dec 18, 2017 at 08:24:21AM +0200, Stefan Mavrodiev wrote:
> On 12/15/2017 05:08 PM, Maxime Ripard wrote:
> > Hi,
> >
> > On Thu, Dec 14, 2017 at 08:24:54AM +0200, Stefan Mavrodiev wrote:
> > > On 12/13/2017 05:40 PM, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > On Wed, Dec 13, 2017 at 09:44:34AM +0200, Stefan Mavrodiev wrote:
> > > > > Allwinner A10/A13/A20 SoCs have pinmux for spi0
> > > > > on port C. The patch adds these pins in the respective
> > > > > dts includes.
> > > > >
> > > > > Signed-off-by: Stefan Mavrodiev <stefan-kyXcfZUBQGPQT0dZR+AlfA@public.gmane.org>
> > > > Do you have any boards that are using these?
> > > >
> > > > We won't merge that patch if there's no users for it.
> > > A20-OLinuXino-Lime/Lime2 and A10-OLinuXino-Lime with spi flash.
> > > For A13 we still doesn't have that option.
> > If this bus is exposed on the headers, you can add those to the DT but
> > leave them disabled if you want. Buf if there's no users of those
> > nodes, our policy is not to merge them.
>
> So basically I should resend the patch, enabling the those pins only for
> sun4i and sun7i platform?
I'm not quite sure what you mean, but you should do something like
77df9d66b0b1ad01c685fd6341ce501493899658
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 v2 18/19] ARM: dts: aspeed-romulus: Update Romulus system
From: Cédric Le Goater @ 2017-12-18 9:32 UTC (permalink / raw)
To: Joel Stanley, Rob Herring, Mark Rutland, Arnd Bergmann,
Andrew Jeffery, Patrick Venture, Xo Wang, Lei YU
Cc: Benjamin Herrenschmidt, Jeremy Kerr, devicetree, linux-arm-kernel,
linux-kernel, linux-aspeed
In-Reply-To: <20171215062443.23059-19-joel@jms.id.au>
Some comments below,
On 12/15/2017 07:24 AM, Joel Stanley wrote:
> - Fix incorrect RAM size
> - Remove alias; these are now specified in the dtsi
> - Add newly upstreamed devices
> - Include OpenBMC flash layout
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 153 ++++++++++++++++++++++++++-
> 1 file changed, 148 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> index a7a9386f964d..bfdf643584df 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> @@ -7,17 +7,13 @@
> model = "Romulus BMC";
> compatible = "ibm,romulus-bmc", "aspeed,ast2500";
>
> - aliases {
> - serial4 = &uart5;
> - };
> -
> chosen {
> stdout-path = &uart5;
> bootargs = "console=ttyS4,115200 earlyprintk";
> };
>
> memory {
> - reg = <0x80000000 0x40000000>;
> + reg = <0x80000000 0x20000000>;
> };
>
> reserved-memory {
> @@ -29,6 +25,73 @@
> no-map;
> reg = <0xbf000000 0x01000000>; /* 16M */
> };
> +
> + flash_memory: region@98000000 {
> + no-map;
> + reg = <0x98000000 0x04000000>; /* 64M */
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + fault {
> + gpios = <&gpio ASPEED_GPIO(N, 2) GPIO_ACTIVE_LOW>;
> + };
> +
> + identify {
> + gpios = <&gpio ASPEED_GPIO(N, 4) GPIO_ACTIVE_HIGH>;
> + };
> +
> + power {
> + gpios = <&gpio ASPEED_GPIO(R, 5) GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + fsi: gpio-fsi {
> + compatible = "fsi-master-gpio", "fsi-master";
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + clock-gpios = <&gpio ASPEED_GPIO(AA, 0) GPIO_ACTIVE_HIGH>;
> + data-gpios = <&gpio ASPEED_GPIO(AA, 2) GPIO_ACTIVE_HIGH>;
> + mux-gpios = <&gpio ASPEED_GPIO(A, 6) GPIO_ACTIVE_HIGH>;
> + enable-gpios = <&gpio ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
> + trans-gpios = <&gpio ASPEED_GPIO(R, 2) GPIO_ACTIVE_HIGH>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + checkstop {
> + label = "checkstop";
> + gpios = <&gpio ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
> + linux,code = <ASPEED_GPIO(J, 2)>;
> + };
> + };
> +};
> +
> +&fmc {
> + status = "okay";
> +
> + flash@0 {
> + status = "okay";
> + label = "pnor";
> + m25p,fast-read;
> +#include "openbmc-flash-layout.dtsi"
> + };
> +};
> +
> +&spi1 {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_spi1_default>;
> +
> + flash@0 {
> + status = "okay";
> + label = "pnor";
> + m25p,fast-read;
> };
> };
hmm, the fmc and spi1 bindings were already added in commit 1142aea9ff9d.
> @@ -38,6 +101,7 @@
> status = "okay";
> m25p,fast-read;
> label = "bmc";
> +#include "openbmc-flash-layout.dtsi"
This looks like an extra "fmc" node ?
> };
> };
>
> @@ -53,6 +117,12 @@
> };
> };
>
> +&lpc_ctrl {
> + status = "okay";
> + memory-region = <&flash_memory>;
> + flash = <&spi1>;
> +};
> +
> &uart1 {
> /* Rear RS-232 connector */
> status = "okay";
> @@ -81,6 +151,10 @@
> pinctrl-0 = <&pinctrl_rmii1_default>;
> };
>
> +&i2c1 {
> + status = "okay";
> +};
> +
> &i2c2 {
> status = "okay";
> };
> @@ -133,8 +207,77 @@
>
> &i2c12 {
> status = "okay";
> +
> + max31785@52 {
> + compatible = "maxim,max31785";
> + reg = <0x52>;
> + };
> +};
> +
> +&gpio {
> + nic_func_mode0 {
> + gpio-hog;
> + gpios = <ASPEED_GPIO(D, 3) GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "nic_func_mode0";
> + };
> + nic_func_mode1 {
> + gpio-hog;
> + gpios = <ASPEED_GPIO(D, 4) GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "nic_func_mode1";
> + };
> };
>
> &vuart {
> status = "okay";
> };
> +
> +&gfx {
> + status = "okay";
> +};
> +
> +&pinctrl {
> + aspeed,external-nodes = <&gfx &lhc>;
> +};
> +
> +&pwm_tacho {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm0_default &pinctrl_pwm1_default>;
> +
> + fan@0 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x08>;
> + };
> +
> + fan@1 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x09>;
> + };
> +
> + fan@2 {
> + reg = <0x01>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0a>;
> + };
> +
> + fan@3 {
> + reg = <0x01>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0b>;
> + };
> +
> + fan@4 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0c>;
> + };
> +
> + fan@5 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0d>;
> + };
> +
> + fan@6 {
> + reg = <0x01>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0e>;
> + };
> +};
>
^ permalink raw reply
* Re: [PATCH 04/25] arm: exynos/s3c: dts: Remove leading 0x and 0s from bindings notation
From: Krzysztof Kozlowski @ 2017-12-18 9:40 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Rob Herring, Mark Rutland, Russell King, Kukjin Kim,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215124630.30082-1-malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
On Fri, Dec 15, 2017 at 1:46 PM, Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> Suggested-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Acked-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Ack was for different patchset, touching only three files...
> Signed-off-by: Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
> ---
> arch/arm/boot/dts/exynos3250.dtsi | 34 ++++++------
> arch/arm/boot/dts/exynos4.dtsi | 56 +++++++++----------
> arch/arm/boot/dts/exynos4210.dtsi | 8 +--
> arch/arm/boot/dts/exynos4412-pinctrl.dtsi | 2 +-
> arch/arm/boot/dts/exynos4412.dtsi | 22 ++++----
> arch/arm/boot/dts/exynos5.dtsi | 22 ++++----
> arch/arm/boot/dts/exynos5250.dtsi | 64 +++++++++++-----------
> arch/arm/boot/dts/exynos5260.dtsi | 26 ++++-----
> arch/arm/boot/dts/exynos5420.dtsi | 78 +++++++++++++--------------
> arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 2 +-
> arch/arm/boot/dts/exynos5440.dtsi | 14 ++---
> arch/arm/boot/dts/s3c2416.dtsi | 8 +--
> 12 files changed, 168 insertions(+), 168 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
> index 2bd3872221a1..8d47571b3984 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -164,31 +164,31 @@
> syscon = <&pmu_system_controller>;
> };
>
> - pd_cam: cam-power-domain@10023C00 {
> + pd_cam: cam-power-domain@10023c00 {
This is not related to this patch and it was not present in the
version I acked. I also already fixed this here:
https://patchwork.kernel.org/patch/10113323/
There is no changelog explaining the difference in patches. Original
patch was okay, why changing it?
Best regards,
Krzysztof
--
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 v3 05/11] thermal: armada: Add support for Armada AP806
From: Miquel RAYNAL @ 2017-12-18 9:41 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Catalin Marinas,
Will Deacon, Thomas Petazzoni, devicetree, Baruch Siach, linux-pm,
Antoine Tenart, Nadav Haklai, David Sniatkiwicz, linux-arm-kernel
In-Reply-To: <87y3m5o9h4.fsf@free-electrons.com>
Hello Gregory & Baruch,
On Thu, 14 Dec 2017 12:05:43 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> > @@ -184,9 +214,9 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, div = priv->data->coef_div;
> >
> > if (priv->data->inverted)
> > - *temp = ((m * reg) - b) / div;
> > + *temp = ((m * sample) - b) / div;
> > else
> > - *temp = (b - (m * reg)) / div;
> > + *temp = (b - (m * sample)) / div;
> > return 0;
> > }
> >
> > @@ -237,6 +267,19 @@ static const struct armada_thermal_data
> > armada380_data = { .inverted = true,
> > };
> >
> > +static const struct armada_thermal_data armada_ap806_data = {
> > + .is_valid = armada_is_valid,
> > + .init_sensor = armada_ap806_init_sensor,
> > + .is_valid_bit = BIT(16),
> > + .temp_shift = 0,
> > + .temp_mask = 0x3ff,
> > + .coef_b = -150000,
>
> Don't you expect any side effect by storing a negative value in a
> unsigned variable?
That is a fair question, I did not spot that.
As other values are really close to 2^32 I don't know what is the best
option for us in this case. Should I:
- don't care?
- use signed values? (dangerous IMHO)
- use a union with a signed and an unsigned value? (problem moved to
->get_temp())
Thanks for your input.
Miquèl
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
From: Yong @ 2017-12-18 9:43 UTC (permalink / raw)
To: Maxime Ripard
Cc: wens-jdAy2FN1RRM, Mauro Carvalho Chehab, Rob Herring,
Mark Rutland, David S. Miller, Greg Kroah-Hartman, Hans Verkuil,
Randy Dunlap, Benoit Parrot, Stanimir Varbanov, Arnd Bergmann,
Hugues Fruchet, Philipp Zabel, Benjamin Gaignard,
Ramesh Shanmugasundaram, Yannick Fertre, Sakari Ailus, Rick Chang,
Linux Media Mailing List, devicetree, linux-arm-kernel
In-Reply-To: <20171218092437.ksczam5h7hirmpcv-ZC1Zs529Oq4@public.gmane.org>
Hi,
On Mon, 18 Dec 2017 10:24:37 +0100
Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi,
>
> On Mon, Dec 18, 2017 at 04:49:21PM +0800, Yong wrote:
> > > > + compatible = "allwinner,sun8i-v3s-csi";
> > > > + reg = <0x01cb4000 0x1000>;
> > > > + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> > > > + clocks = <&ccu CLK_BUS_CSI>,
> > > > + <&ccu CLK_CSI1_SCLK>,
> > >
> > > CSI also has an MCLK. Do you need that one?
> >
> > MCLK is not needed if the front end is not a sensor (like adv7611).
> > I will add it as an option.
>
> I guess this should always be needed then. And the driver will make
> the decision to enable it or not.
But how the driver to know if it should be enabled?
I think MCLK should be added in DT just if the subdev need it.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Thanks,
Yong
^ permalink raw reply
* Re: [PATCH V7 00/12] add clock driver for Spreadtrum platforms
From: Chunyan Zhang @ 2017-12-18 9:46 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Stephen Boyd, Michael Turquette, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, linux-clk, linux-kernel, devicetree,
linux-arm-kernel, Arnd Bergmann, Mark Brown, Xiaolong Zhang,
Ben Li, Orson Zhai
In-Reply-To: <20171207125715.16160-1-chunyan.zhang@spreadtrum.com>
Hi,
Since holidays are comming for many people, and then the next merge
window will come soon after holidays?
If you have any comments, please let me know, I hope this patchset can
be merged into the following merge window.
Wish you all a Merry Christmas and Happy New Year!
Thanks,
Chunyan
On 7 December 2017 at 20:57, Chunyan Zhang <chunyan.zhang@spreadtrum.com> wrote:
> From: Chunyan Zhang <zhang.chunyan@linaro.org>
>
> This series adds Spreadtrum clock support together with its binding
> documentation and devicetree data.
>
> Any comments would be greatly appreciated.
>
> Thanks,
> Chunyan
>
> Changes from V6: (https://lkml.org/lkml/2017/11/27/217)
> * Changed to use "//" format for the file header
> * Addressed Stephen's comments:
> - Put the common macros in clk-provider.h instead of clk_common.h, also removed
> the same macros from sunxi-ng/ccu_common.h and zte/clk.h;
> - Removed CLK_FIXED_RATE(), and moved the fixed rate clocks from driver to DT;
> - Use devm_of_clk_add_hw_provider() instead;
> - Removed sprd_regmap_{read|write}(), use regmap API directly;
> - Removed all full stop on error messages.
> * Use IS_ERR_OR_NULL() instead of IS_ERR() for checking regmap pointers;
>
> Changes from V5: (https://lkml.org/lkml/2017/11/20/21)
> * Rebased the whole patch-set to 4.15-rc1;
> * Fixed kbuild-test warnings;
> * Switched to use devm_clk_hw_register() instead of clk_hw_register();
> * Removed useless debug information from sc9860-clk.c.
>
> Changes from V4: (https://lkml.org/lkml/2017/11/10/30)
> * Added acked-by of Rob Herring;
> * Removed spin lock from Spreadtrum's gate, mux, div drivers, since we have
> switched to use regmap.
>
> Changes from V3: (https://lkml.org/lkml/2017/11/2/61)
> * Addressed comments from Julien Thierry:
> - Clean the if branch of sprd_mux_helper_get_parent()
> - Have the Gate clock macros and ops for both mode (i.e. sc_gate and gate) separate;
> - Have the Mux clock macros with/without table separate, and same changes
> for the composite clock.
> * Switched the function name from _endisable to _toggle;
> * Fixed Kbuild test error:
> - Added exporting sprd_clk_regmap_init() which would be used in other module(s);
> * Change the function sprd_clk_set_regmap() to the static one, and removed the
> declear from the include file;
> * Addressed comments from Rob:
> - Separate the dt-binding include file from the driver patch;
> - Documented more for the property "clocks"
> * Changed the syscon device names;
> * Changed the name of 'sprd_mux_internal' to 'sprd_mux_ssel'
>
>
> Changes from V2: (http://lkml.iu.edu/hypermail/linux/kernel/1707.1/01504.html)
> * Switch to use regmap to access registers;
> * Splited all clocks into 16 separated nodes, for each belongs to a single address area;
> * Rearranged the order of clock declaration in sc9860-clk.c, sorted them upon the address area;
> * Added syscon device tree nodes which will be quoted by the node of clocks which are in
> the same address area with the syscon device;
> * Revised the binding documentation according to the dt modification.
>
> Changes from V1: (https://lkml.org/lkml/2017/6/17/356)
> * Address Stephen's comments:
> - Switch to use platform device driver instead of the DT probing mechanism.
> - Move the common clock macro out from vendor directory, but need to remove those
> overlap code from other vendors (such as sunxi-ng) once this get merged.
> - Add support to be built as a module.
> - Add 'sprd_' prefix for all spin locks used in these drivers.
> - Mark input parameter of sprd_x with const.
> - Remove unreasonable dependencies to CONFIG_64BIT.
> - Add readl() after writing the same register.
> - Remove CLK_IS_BASIC which is no longer used.
> - Remove unnecessery CLK_IGNORE_UNUSED when defining a clock.
> - Change to expose all clock index.
> - Use clk_ instead of ccu.
> - Add Kconfig for sprd clocks.
> - Move the fixed clocks out from the soc node.
> - Switch to use 64-bit math in pll driver instead of 32-bit math.
> * Revise binding documentation according to dt modification.
> * Rename sc9860.c to sc9860-clk.c
>
>
> Chunyan Zhang (12):
> drivers: move clock common macros out from vendor directories
> clk: sprd: Add common infrastructure
> clk: sprd: add gate clock support
> clk: sprd: add mux clock support
> clk: sprd: add divider clock support
> clk: sprd: add composite clock support
> clk: sprd: add adjustable pll support
> dt-bindings: Add Spreadtrum clock binding documentation
> clk: sprd: Add dt-bindings include file for SC9860
> clk: sprd: add clocks support for SC9860
> arm64: dts: add syscon for whale2 platform
> arm64: dts: add clocks for SC9860
>
> Documentation/devicetree/bindings/clock/sprd.txt | 63 +
> arch/arm64/boot/dts/sprd/sc9860.dtsi | 115 ++
> arch/arm64/boot/dts/sprd/whale2.dtsi | 62 +-
> drivers/clk/Kconfig | 1 +
> drivers/clk/Makefile | 1 +
> drivers/clk/sprd/Kconfig | 14 +
> drivers/clk/sprd/Makefile | 11 +
> drivers/clk/sprd/common.c | 96 ++
> drivers/clk/sprd/common.h | 38 +
> drivers/clk/sprd/composite.c | 60 +
> drivers/clk/sprd/composite.h | 51 +
> drivers/clk/sprd/div.c | 90 +
> drivers/clk/sprd/div.h | 75 +
> drivers/clk/sprd/gate.c | 111 ++
> drivers/clk/sprd/gate.h | 59 +
> drivers/clk/sprd/mux.c | 76 +
> drivers/clk/sprd/mux.h | 74 +
> drivers/clk/sprd/pll.c | 266 +++
> drivers/clk/sprd/pll.h | 108 ++
> drivers/clk/sprd/sc9860-clk.c | 1974 ++++++++++++++++++++++
> drivers/clk/sunxi-ng/ccu_common.h | 29 -
> drivers/clk/zte/clk.h | 18 -
> include/dt-bindings/clock/sprd,sc9860-clk.h | 404 +++++
> include/linux/clk-provider.h | 38 +
> 24 files changed, 3785 insertions(+), 49 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/sprd.txt
> create mode 100644 drivers/clk/sprd/Kconfig
> create mode 100644 drivers/clk/sprd/Makefile
> create mode 100644 drivers/clk/sprd/common.c
> create mode 100644 drivers/clk/sprd/common.h
> create mode 100644 drivers/clk/sprd/composite.c
> create mode 100644 drivers/clk/sprd/composite.h
> create mode 100644 drivers/clk/sprd/div.c
> create mode 100644 drivers/clk/sprd/div.h
> create mode 100644 drivers/clk/sprd/gate.c
> create mode 100644 drivers/clk/sprd/gate.h
> create mode 100644 drivers/clk/sprd/mux.c
> create mode 100644 drivers/clk/sprd/mux.h
> create mode 100644 drivers/clk/sprd/pll.c
> create mode 100644 drivers/clk/sprd/pll.h
> create mode 100644 drivers/clk/sprd/sc9860-clk.c
> create mode 100644 include/dt-bindings/clock/sprd,sc9860-clk.h
>
> --
> 2.7.4
>
^ permalink raw reply
* Re: [RFC v2 1/2] backlight: pwm_bl: linear interpolation between values of brightness-levels
From: Enric Balletbo Serra @ 2017-12-18 9:47 UTC (permalink / raw)
To: Daniel Thompson
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: <20171215144052.3b62gd3bkiqtuvk7@oak.lan>
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.
>
>> [0]: Documentation/devicetree/bindings/pwm/pwm.txt
>> [1]: Documentation/devicetree/bindings/gpio/gpio.txt
>> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
>> index 9bd1768..59b1bfb 100644
>> --- a/drivers/video/backlight/pwm_bl.c
>> +++ b/drivers/video/backlight/pwm_bl.c
>> @@ -24,6 +24,8 @@
>> #include <linux/regulator/consumer.h>
>> #include <linux/slab.h>
>>
>> +#define NSTEPS 256
>> +
>> struct pwm_bl_data {
>> struct pwm_device *pwm;
>> struct device *dev;
>> @@ -35,6 +37,7 @@ struct pwm_bl_data {
>> struct gpio_desc *enable_gpio;
>> unsigned int scale;
>> bool legacy;
>> + bool piecewise;
>> int (*notify)(struct device *,
>> int brightness);
>> void (*notify_after)(struct device *,
>> @@ -76,17 +79,36 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb)
>> pb->enabled = false;
>> }
>>
>> -static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness)
>> +static int scale(struct pwm_bl_data *pb, int x)
>> {
>> unsigned int lth = pb->lth_brightness;
>> +
>> + return (x * (pb->period - lth) / pb->scale) + lth;
>> +}
>> +
>> +static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness)
>> +{
>> + int coarse = brightness / NSTEPS;
>> + int fine = brightness % NSTEPS;
>> int duty_cycle;
>>
>> - if (pb->levels)
>> - duty_cycle = pb->levels[brightness];
>> - else
>> - duty_cycle = brightness;
>> + if (pb->levels) {
>> + if (pb->piecewise) {
>> + duty_cycle = scale(pb, pb->levels[coarse]);
>> + if (fine > 0)
>> + duty_cycle += (scale(pb, pb->levels[coarse + 1])
>> + - scale(pb, pb->levels[coarse]))
>> + * fine / NSTEPS;
>> + dev_dbg(pb->dev, "brightness=%d coarse=%d fine=%d\n",
>> + brightness, coarse, fine);
>> + } else {
>> + duty_cycle = scale(pb, pb->levels[brightness]);
>> + }
>> + } else {
>> + duty_cycle = scale(pb, brightness);
>> + }
>>
>> - return (duty_cycle * (pb->period - lth) / pb->scale) + lth;
>> + return duty_cycle;
>> }
>>
>> static int pwm_backlight_update_status(struct backlight_device *bl)
>> @@ -149,11 +171,11 @@ static int pwm_backlight_parse_dt(struct device *dev,
>> if (!prop)
>> return -EINVAL;
>>
>> - data->max_brightness = length / sizeof(u32);
>> + data->levels_count = length / sizeof(u32);
>>
>> /* read brightness levels from DT property */
>> - if (data->max_brightness > 0) {
>> - size_t size = sizeof(*data->levels) * data->max_brightness;
>> + if (data->levels_count > 0) {
>> + size_t size = sizeof(*data->levels) * data->levels_count;
>>
>> data->levels = devm_kzalloc(dev, size, GFP_KERNEL);
>> if (!data->levels)
>> @@ -161,7 +183,7 @@ static int pwm_backlight_parse_dt(struct device *dev,
>>
>> ret = of_property_read_u32_array(node, "brightness-levels",
>> data->levels,
>> - data->max_brightness);
>> + data->levels_count);
>> if (ret < 0)
>> return ret;
>>
>> @@ -170,10 +192,18 @@ static int pwm_backlight_parse_dt(struct device *dev,
>> if (ret < 0)
>> return ret;
>>
>> + data->piecewise = of_property_read_bool(node,
>> + "use-linear-interpolation");
>> +
>> data->dft_brightness = value;
>> - data->max_brightness--;
>> + data->levels_count--;
>> }
>>
>> + if (data->piecewise)
>> + data->max_brightness = data->levels_count * NSTEPS;
>> + else
>> + data->max_brightness = data->levels_count;
>
> I think we lost a -1 here?
>
Good catch, I think so.
Regards,
Enric
>
> Daniel.
^ permalink raw reply
* Re: [RESEND PATCH v2 13/15] dt-bindings: sound: qcom: Add devicetree bindings for apq8096
From: Srinivas Kandagatla @ 2017-12-18 9:49 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, alsa-devel, Banajit Goswami,
linux-arm-msm, Patrick Lai, Takashi Iwai, sboyd, Liam Girdwood,
David Brown, Mark Brown, linux-arm-kernel, Andy Gross, linux-soc,
linux-kernel
In-Reply-To: <20171216174433.dzjftpz6zcyyq4ph@rob-hp-laptop>
Thanks for your review comments.
On 16/12/17 17:44, Rob Herring wrote:
> On Thu, Dec 14, 2017 at 05:34:00PM +0000, srinivas.kandagatla@linaro.org wrote:
>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>
>> Add devicetree bindings documentation file for Qualcomm apq8096 sound card.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>> .../devicetree/bindings/sound/qcom,apq8096.txt | 22 ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/sound/qcom,apq8096.txt
>>
>> diff --git a/Documentation/devicetree/bindings/sound/qcom,apq8096.txt b/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
>> new file mode 100644
>> index 000000000000..27b511dab533
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
>> @@ -0,0 +1,22 @@
>> +* Qualcomm Technologies APQ8096 ASoC sound card driver
>> +
>> +This binding describes the APQ8096 sound card, which uses qdsp for audio.
>> +
>> +- compatible:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: must be "qcom,apq8096-sndcard"
>> +
>> +- qcom,audio-routing:
>> + Usage: Optional
>> + Value type: <stringlist>
>> + Definition: A list of the connections between audio components.
>> + Each entry is a pair of strings, the first being the
>> + connection's sink, the second being the connection's
>> + source. Valid names could be power supplies, MicBias
>> + of codec and the jacks on the board:
>> +Example:
>> + sound {
>> + compatible = "qcom,snd-apq8096";
>> + qcom,model = "DB820c";
>
> Not documented, but just use "model".
Yep, I will use that in next version.
>
> This doesn't look complete. No codec, etc.?
All the dai links are done in non-DT way directly in the sound card driver.
Thanks,
Srini
>
> Rob
>
^ permalink raw reply
* Re: [RESEND PATCH v2 01/15] dt-bindings: soc: qcom: Add bindings for APR bus
From: Srinivas Kandagatla @ 2017-12-18 9:50 UTC (permalink / raw)
To: Rob Herring
Cc: Andy Gross, Mark Brown, linux-arm-msm, alsa-devel, David Brown,
Mark Rutland, Liam Girdwood, Patrick Lai, Banajit Goswami,
Jaroslav Kysela, Takashi Iwai, linux-soc, devicetree,
linux-kernel, linux-arm-kernel, sboyd
In-Reply-To: <20171216172722.avtipt5evmreayyc@rob-hp-laptop>
On 16/12/17 17:27, Rob Herring wrote:
> On Thu, Dec 14, 2017 at 05:33:48PM +0000, srinivas.kandagatla@linaro.org wrote:
>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>
>> This patch add dt bindings for Qualcomm APR bus driver
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>> .../devicetree/bindings/soc/qcom/qcom,apr.txt | 28 ++++++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
>>
>> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
>> new file mode 100644
>> index 000000000000..4e93213ae98d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
>> @@ -0,0 +1,28 @@
>> +Qualcomm APR (Asynchronous Packet Router) binding
>> +
>> +This binding describes the Qualcomm APR. APR is a IPC protocol for
>> +communication between Application processor and QDSP. APR is mainly
>> +used for audio/voice services on the QDSP.
>> +
>> +- compatible:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: must be "qcom,apr-<SOC-NAME>" example: "qcom,apr-msm8996"
>
> <soc>-apr is the more standard order. With that,
Yes, it makes sense, will do that in next version.
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Thanks for reviewed-by tag.
Rgrds,
Srini
>
^ permalink raw reply
* [PATCH v2 1/2] media: dt-bindings: coda: Add compatible for CodaHx4 on i.MX51
From: Philipp Zabel @ 2017-12-18 10:16 UTC (permalink / raw)
To: linux-media
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Fabio Estevam,
Chris Healy, devicetree, kernel, Philipp Zabel
Add a compatible for the CodaHx4 VPU used on i.MX51.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes since v1 [1]:
- Fix list enumerators, suggested by Baruch
[1] https://patchwork.linuxtv.org/patch/45929/
---
Documentation/devicetree/bindings/media/coda.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/coda.txt b/Documentation/devicetree/bindings/media/coda.txt
index 2865d04e40305..90eb74cc1993f 100644
--- a/Documentation/devicetree/bindings/media/coda.txt
+++ b/Documentation/devicetree/bindings/media/coda.txt
@@ -7,8 +7,9 @@ called VPU (Video Processing Unit).
Required properties:
- compatible : should be "fsl,<chip>-src" for i.MX SoCs:
(a) "fsl,imx27-vpu" for CodaDx6 present in i.MX27
- (b) "fsl,imx53-vpu" for CODA7541 present in i.MX53
- (c) "fsl,imx6q-vpu" for CODA960 present in i.MX6q
+ (b) "fsl,imx51-vpu" for CodaHx4 present in i.MX51
+ (c) "fsl,imx53-vpu" for CODA7541 present in i.MX53
+ (d) "fsl,imx6q-vpu" for CODA960 present in i.MX6q
- reg: should be register base and length as documented in the
SoC reference manual
- interrupts : Should contain the VPU interrupt. For CODA960,
--
2.11.0
^ permalink raw reply related
* [PATCH v2 2/2] media: coda: Add i.MX51 (CodaHx4) support
From: Philipp Zabel @ 2017-12-18 10:16 UTC (permalink / raw)
To: linux-media
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Fabio Estevam,
Chris Healy, devicetree, kernel, Philipp Zabel
In-Reply-To: <20171218101629.31395-1-p.zabel@pengutronix.de>
Add support for the CodaHx4 VPU used on i.MX51.
Decoding h.264, MPEG-4, and MPEG-2 video works, as well as encoding
h.264. MPEG-4 encoding is not enabled, it currently produces visual
artifacts.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
No changes since v1 [1].
[1] https://patchwork.linuxtv.org/patch/45930/
---
drivers/media/platform/coda/coda-bit.c | 45 ++++++++++++++++++++++---------
drivers/media/platform/coda/coda-common.c | 44 +++++++++++++++++++++++++++---
drivers/media/platform/coda/coda.h | 1 +
3 files changed, 74 insertions(+), 16 deletions(-)
diff --git a/drivers/media/platform/coda/coda-bit.c b/drivers/media/platform/coda/coda-bit.c
index bfc4ecf6f068b..393d8a1a2a67c 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -68,8 +68,9 @@ static void coda_command_async(struct coda_ctx *ctx, int cmd)
{
struct coda_dev *dev = ctx->dev;
- if (dev->devtype->product == CODA_960 ||
- dev->devtype->product == CODA_7541) {
+ if (dev->devtype->product == CODA_HX4 ||
+ dev->devtype->product == CODA_7541 ||
+ dev->devtype->product == CODA_960) {
/* Restore context related registers to CODA */
coda_write(dev, ctx->bit_stream_param,
CODA_REG_BIT_BIT_STREAM_PARAM);
@@ -505,7 +506,8 @@ static int coda_alloc_context_buffers(struct coda_ctx *ctx,
goto err;
}
- if (!ctx->psbuf.vaddr && dev->devtype->product == CODA_7541) {
+ if (!ctx->psbuf.vaddr && (dev->devtype->product == CODA_HX4 ||
+ dev->devtype->product == CODA_7541)) {
ret = coda_alloc_context_buf(ctx, &ctx->psbuf,
CODA7_PS_BUF_SIZE, "psbuf");
if (ret < 0)
@@ -593,6 +595,7 @@ static void coda_setup_iram(struct coda_ctx *ctx)
int dbk_bits;
int bit_bits;
int ip_bits;
+ int me_bits;
memset(iram_info, 0, sizeof(*iram_info));
iram_info->next_paddr = dev->iram.paddr;
@@ -602,10 +605,17 @@ static void coda_setup_iram(struct coda_ctx *ctx)
return;
switch (dev->devtype->product) {
+ case CODA_HX4:
+ dbk_bits = CODA7_USE_HOST_DBK_ENABLE;
+ bit_bits = CODA7_USE_HOST_BIT_ENABLE;
+ ip_bits = CODA7_USE_HOST_IP_ENABLE;
+ me_bits = CODA7_USE_HOST_ME_ENABLE;
+ break;
case CODA_7541:
dbk_bits = CODA7_USE_HOST_DBK_ENABLE | CODA7_USE_DBK_ENABLE;
bit_bits = CODA7_USE_HOST_BIT_ENABLE | CODA7_USE_BIT_ENABLE;
ip_bits = CODA7_USE_HOST_IP_ENABLE | CODA7_USE_IP_ENABLE;
+ me_bits = CODA7_USE_HOST_ME_ENABLE | CODA7_USE_ME_ENABLE;
break;
case CODA_960:
dbk_bits = CODA9_USE_HOST_DBK_ENABLE | CODA9_USE_DBK_ENABLE;
@@ -625,7 +635,8 @@ static void coda_setup_iram(struct coda_ctx *ctx)
w64 = mb_width * 64;
/* Prioritize in case IRAM is too small for everything */
- if (dev->devtype->product == CODA_7541) {
+ if (dev->devtype->product == CODA_HX4 ||
+ dev->devtype->product == CODA_7541) {
iram_info->search_ram_size = round_up(mb_width * 16 *
36 + 2048, 1024);
iram_info->search_ram_paddr = coda_iram_alloc(iram_info,
@@ -634,8 +645,7 @@ static void coda_setup_iram(struct coda_ctx *ctx)
pr_err("IRAM is smaller than the search ram size\n");
goto out;
}
- iram_info->axi_sram_use |= CODA7_USE_HOST_ME_ENABLE |
- CODA7_USE_ME_ENABLE;
+ iram_info->axi_sram_use |= me_bits;
}
/* Only H.264BP and H.263P3 are considered */
@@ -687,7 +697,8 @@ static void coda_setup_iram(struct coda_ctx *ctx)
v4l2_dbg(1, coda_debug, &ctx->dev->v4l2_dev,
"IRAM smaller than needed\n");
- if (dev->devtype->product == CODA_7541) {
+ if (dev->devtype->product == CODA_HX4 ||
+ dev->devtype->product == CODA_7541) {
/* TODO - Enabling these causes picture errors on CODA7541 */
if (ctx->inst_type == CODA_INST_DECODER) {
/* fw 1.4.50 */
@@ -705,6 +716,7 @@ static void coda_setup_iram(struct coda_ctx *ctx)
static u32 coda_supported_firmwares[] = {
CODA_FIRMWARE_VERNUM(CODA_DX6, 2, 2, 5),
+ CODA_FIRMWARE_VERNUM(CODA_HX4, 1, 4, 50),
CODA_FIRMWARE_VERNUM(CODA_7541, 1, 4, 50),
CODA_FIRMWARE_VERNUM(CODA_960, 2, 1, 5),
CODA_FIRMWARE_VERNUM(CODA_960, 2, 3, 10),
@@ -889,6 +901,7 @@ static int coda_start_encoding(struct coda_ctx *ctx)
case CODA_960:
coda_write(dev, 0, CODA9_GDI_WPROT_RGN_EN);
/* fallthrough */
+ case CODA_HX4:
case CODA_7541:
coda_write(dev, CODA7_STREAM_BUF_DYNALLOC_EN |
CODA7_STREAM_BUF_PIC_RESET, CODA_REG_BIT_STREAM_CTRL);
@@ -918,6 +931,7 @@ static int coda_start_encoding(struct coda_ctx *ctx)
value |= (q_data_src->height & CODADX6_PICHEIGHT_MASK)
<< CODA_PICHEIGHT_OFFSET;
break;
+ case CODA_HX4:
case CODA_7541:
if (dst_fourcc == V4L2_PIX_FMT_H264) {
value = (round_up(q_data_src->width, 16) &
@@ -1085,6 +1099,7 @@ static int coda_start_encoding(struct coda_ctx *ctx)
value = FMO_SLICE_SAVE_BUF_SIZE << 7;
coda_write(dev, value, CODADX6_CMD_ENC_SEQ_FMO);
break;
+ case CODA_HX4:
case CODA_7541:
coda_write(dev, ctx->iram_info.search_ram_paddr,
CODA7_CMD_ENC_SEQ_SEARCH_BASE);
@@ -1130,7 +1145,8 @@ static int coda_start_encoding(struct coda_ctx *ctx)
coda_write(dev, num_fb, CODA_CMD_SET_FRAME_BUF_NUM);
coda_write(dev, stride, CODA_CMD_SET_FRAME_BUF_STRIDE);
- if (dev->devtype->product == CODA_7541) {
+ if (dev->devtype->product == CODA_HX4 ||
+ dev->devtype->product == CODA_7541) {
coda_write(dev, q_data_src->bytesperline,
CODA7_CMD_SET_FRAME_SOURCE_BUF_STRIDE);
}
@@ -1569,7 +1585,8 @@ static bool coda_reorder_enable(struct coda_ctx *ctx)
struct coda_dev *dev = ctx->dev;
int profile, level;
- if (dev->devtype->product != CODA_7541 &&
+ if (dev->devtype->product != CODA_HX4 &&
+ dev->devtype->product != CODA_7541 &&
dev->devtype->product != CODA_960)
return false;
@@ -1663,7 +1680,8 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
CODA_CMD_DEC_SEQ_MP4_ASP_CLASS);
}
if (src_fourcc == V4L2_PIX_FMT_H264) {
- if (dev->devtype->product == CODA_7541) {
+ if (dev->devtype->product == CODA_HX4 ||
+ dev->devtype->product == CODA_7541) {
coda_write(dev, ctx->psbuf.paddr,
CODA_CMD_DEC_SEQ_PS_BB_START);
coda_write(dev, (CODA7_PS_BUF_SIZE / 1024),
@@ -1790,7 +1808,8 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
CODA_CMD_SET_FRAME_SLICE_BB_SIZE);
}
- if (dev->devtype->product == CODA_7541) {
+ if (dev->devtype->product == CODA_HX4 ||
+ dev->devtype->product == CODA_7541) {
int max_mb_x = 1920 / 16;
int max_mb_y = 1088 / 16;
int max_mb_num = max_mb_x * max_mb_y;
@@ -1908,6 +1927,7 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
switch (dev->devtype->product) {
case CODA_DX6:
/* TBD */
+ case CODA_HX4:
case CODA_7541:
coda_write(dev, CODA_PRE_SCAN_EN, CODA_CMD_DEC_PIC_OPTION);
break;
@@ -2048,7 +2068,8 @@ static void coda_finish_decode(struct coda_ctx *ctx)
v4l2_err(&dev->v4l2_dev,
"errors in %d macroblocks\n", err_mb);
- if (dev->devtype->product == CODA_7541) {
+ if (dev->devtype->product == CODA_HX4 ||
+ dev->devtype->product == CODA_7541) {
val = coda_read(dev, CODA_RET_DEC_PIC_OPTION);
if (val == 0) {
/* not enough bitstream data */
diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c
index 15eb5dc4dff9a..3573fb2599ea6 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -128,7 +128,8 @@ void coda_write_base(struct coda_ctx *ctx, struct coda_q_data *q_data,
/*
* Arrays of codecs supported by each given version of Coda:
* i.MX27 -> codadx6
- * i.MX5x -> coda7
+ * i.MX51 -> codahx4
+ * i.MX53 -> coda7
* i.MX6 -> coda960
* Use V4L2_PIX_FMT_YUV420 as placeholder for all supported YUV 4:2:0 variants
*/
@@ -137,6 +138,13 @@ static const struct coda_codec codadx6_codecs[] = {
CODA_CODEC(CODADX6_MODE_ENCODE_MP4, V4L2_PIX_FMT_YUV420, V4L2_PIX_FMT_MPEG4, 720, 576),
};
+static const struct coda_codec codahx4_codecs[] = {
+ CODA_CODEC(CODA7_MODE_ENCODE_H264, V4L2_PIX_FMT_YUV420, V4L2_PIX_FMT_H264, 720, 576),
+ CODA_CODEC(CODA7_MODE_DECODE_H264, V4L2_PIX_FMT_H264, V4L2_PIX_FMT_YUV420, 1920, 1088),
+ CODA_CODEC(CODA7_MODE_DECODE_MP2, V4L2_PIX_FMT_MPEG2, V4L2_PIX_FMT_YUV420, 1920, 1088),
+ CODA_CODEC(CODA7_MODE_DECODE_MP4, V4L2_PIX_FMT_MPEG4, V4L2_PIX_FMT_YUV420, 1280, 720),
+};
+
static const struct coda_codec coda7_codecs[] = {
CODA_CODEC(CODA7_MODE_ENCODE_H264, V4L2_PIX_FMT_YUV420, V4L2_PIX_FMT_H264, 1280, 720),
CODA_CODEC(CODA7_MODE_ENCODE_MP4, V4L2_PIX_FMT_YUV420, V4L2_PIX_FMT_MPEG4, 1280, 720),
@@ -234,6 +242,11 @@ static const struct coda_video_device *codadx6_video_devices[] = {
&coda_bit_encoder,
};
+static const struct coda_video_device *codahx4_video_devices[] = {
+ &coda_bit_encoder,
+ &coda_bit_decoder,
+};
+
static const struct coda_video_device *coda7_video_devices[] = {
&coda_bit_jpeg_encoder,
&coda_bit_jpeg_decoder,
@@ -332,6 +345,8 @@ const char *coda_product_name(int product)
switch (product) {
case CODA_DX6:
return "CodaDx6";
+ case CODA_HX4:
+ return "CodaHx4";
case CODA_7541:
return "CODA7541";
case CODA_960:
@@ -1774,7 +1789,8 @@ static void coda_encode_ctrls(struct coda_ctx *ctx)
V4L2_CID_MPEG_VIDEO_H264_PROFILE,
V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE, 0x0,
V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE);
- if (ctx->dev->devtype->product == CODA_7541) {
+ if (ctx->dev->devtype->product == CODA_HX4 ||
+ ctx->dev->devtype->product == CODA_7541) {
v4l2_ctrl_new_std_menu(&ctx->ctrls, &coda_ctrl_ops,
V4L2_CID_MPEG_VIDEO_H264_LEVEL,
V4L2_MPEG_VIDEO_H264_LEVEL_3_1,
@@ -1802,7 +1818,8 @@ static void coda_encode_ctrls(struct coda_ctx *ctx)
V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE,
V4L2_MPEG_VIDEO_MPEG4_PROFILE_SIMPLE, 0x0,
V4L2_MPEG_VIDEO_MPEG4_PROFILE_SIMPLE);
- if (ctx->dev->devtype->product == CODA_7541 ||
+ if (ctx->dev->devtype->product == CODA_HX4 ||
+ ctx->dev->devtype->product == CODA_7541 ||
ctx->dev->devtype->product == CODA_960) {
v4l2_ctrl_new_std_menu(&ctx->ctrls, &coda_ctrl_ops,
V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL,
@@ -1997,6 +2014,7 @@ static int coda_open(struct file *file)
if (enable_bwb || ctx->inst_type == CODA_INST_ENCODER)
ctx->frame_mem_ctrl = CODA9_FRAME_ENABLE_BWB;
/* fallthrough */
+ case CODA_HX4:
case CODA_7541:
ctx->reg_idx = 0;
break;
@@ -2175,7 +2193,8 @@ static int coda_hw_init(struct coda_dev *dev)
/* Tell the BIT where to find everything it needs */
if (dev->devtype->product == CODA_960 ||
- dev->devtype->product == CODA_7541) {
+ dev->devtype->product == CODA_7541 ||
+ dev->devtype->product == CODA_HX4) {
coda_write(dev, dev->tempbuf.paddr,
CODA_REG_BIT_TEMP_BUF_ADDR);
coda_write(dev, 0, CODA_REG_BIT_BIT_STREAM_PARAM);
@@ -2380,6 +2399,7 @@ static void coda_fw_callback(const struct firmware *fw, void *context)
enum coda_platform {
CODA_IMX27,
+ CODA_IMX51,
CODA_IMX53,
CODA_IMX6Q,
CODA_IMX6DL,
@@ -2400,6 +2420,21 @@ static const struct coda_devtype coda_devdata[] = {
.workbuf_size = 288 * 1024 + FMO_SLICE_SAVE_BUF_SIZE * 8 * 1024,
.iram_size = 0xb000,
},
+ [CODA_IMX51] = {
+ .firmware = {
+ "vpu_fw_imx51.bin",
+ "vpu/vpu_fw_imx51.bin",
+ "v4l-codahx4-imx51.bin"
+ },
+ .product = CODA_HX4,
+ .codecs = codahx4_codecs,
+ .num_codecs = ARRAY_SIZE(codahx4_codecs),
+ .vdevs = codahx4_video_devices,
+ .num_vdevs = ARRAY_SIZE(codahx4_video_devices),
+ .workbuf_size = 128 * 1024,
+ .tempbuf_size = 304 * 1024,
+ .iram_size = 0x14000,
+ },
[CODA_IMX53] = {
.firmware = {
"vpu_fw_imx53.bin",
@@ -2456,6 +2491,7 @@ MODULE_DEVICE_TABLE(platform, coda_platform_ids);
#ifdef CONFIG_OF
static const struct of_device_id coda_dt_ids[] = {
{ .compatible = "fsl,imx27-vpu", .data = &coda_devdata[CODA_IMX27] },
+ { .compatible = "fsl,imx51-vpu", .data = &coda_devdata[CODA_IMX51] },
{ .compatible = "fsl,imx53-vpu", .data = &coda_devdata[CODA_IMX53] },
{ .compatible = "fsl,imx6q-vpu", .data = &coda_devdata[CODA_IMX6Q] },
{ .compatible = "fsl,imx6dl-vpu", .data = &coda_devdata[CODA_IMX6DL] },
diff --git a/drivers/media/platform/coda/coda.h b/drivers/media/platform/coda/coda.h
index c5f504d8cf67f..12fab3f1dbfed 100644
--- a/drivers/media/platform/coda/coda.h
+++ b/drivers/media/platform/coda/coda.h
@@ -43,6 +43,7 @@ enum coda_inst_type {
enum coda_product {
CODA_DX6 = 0xf001,
+ CODA_HX4 = 0xf00a,
CODA_7541 = 0xf012,
CODA_960 = 0xf020,
};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 04/25] arm: exynos/s3c: dts: Remove leading 0x and 0s from bindings notation
From: Mathieu Malaterre @ 2017-12-18 10:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Mark Rutland, Russell King, Kukjin Kim,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAJKOXPdkYLisej5965rh2SbOjbFms-RK2VnXt=L==MW_JcA+OA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Dec 18, 2017 at 10:40 AM, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Dec 15, 2017 at 1:46 PM, Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> wrote:
>> Improve the DTS files by removing all the leading "0x" and zeros to fix the
>> following dtc warnings:
>>
>> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>>
>> and
>>
>> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>>
>> Converted using the following command:
>>
>> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>>
>> For simplicity, two sed expressions were used to solve each warnings separately.
>>
>> To make the regex expression more robust a few other issues were resolved,
>> namely setting unit-address to lower case, and adding a whitespace before the
>> the opening curly brace:
>>
>> https://elinux.org/Device_Tree_Linux#Linux_conventions
>>
>> This will solve as a side effect warning:
>>
>> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>>
>> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>>
>> Reported-by: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
>> Suggested-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Acked-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Ack was for different patchset, touching only three files...
So sorry, when I read your email:
https://lkml.org/lkml/2017/12/15/152
I assumed you meant for all the Exynos* and S3C* DTS files, but I did
not check carefully which files were touched originally.
>> Signed-off-by: Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
>> ---
>> arch/arm/boot/dts/exynos3250.dtsi | 34 ++++++------
>> arch/arm/boot/dts/exynos4.dtsi | 56 +++++++++----------
>> arch/arm/boot/dts/exynos4210.dtsi | 8 +--
>> arch/arm/boot/dts/exynos4412-pinctrl.dtsi | 2 +-
>> arch/arm/boot/dts/exynos4412.dtsi | 22 ++++----
>> arch/arm/boot/dts/exynos5.dtsi | 22 ++++----
>> arch/arm/boot/dts/exynos5250.dtsi | 64 +++++++++++-----------
>> arch/arm/boot/dts/exynos5260.dtsi | 26 ++++-----
>> arch/arm/boot/dts/exynos5420.dtsi | 78 +++++++++++++--------------
>> arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 2 +-
>> arch/arm/boot/dts/exynos5440.dtsi | 14 ++---
>> arch/arm/boot/dts/s3c2416.dtsi | 8 +--
>> 12 files changed, 168 insertions(+), 168 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
>> index 2bd3872221a1..8d47571b3984 100644
>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>> @@ -164,31 +164,31 @@
>> syscon = <&pmu_system_controller>;
>> };
>>
>> - pd_cam: cam-power-domain@10023C00 {
>> + pd_cam: cam-power-domain@10023c00 {
>
> This is not related to this patch and it was not present in the
> version I acked. I also already fixed this here:
> https://patchwork.kernel.org/patch/10113323/
>
> There is no changelog explaining the difference in patches. Original
> patch was okay, why changing it?
Accept my sincere apologizes I really messed this series. I discover
my original ARM patch did not apply lower case to all unit-address
equally, so I added at last minute a sed expression to make all
unit-address lower case.
I guess you can just drop this one for now.
-M
--
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 V8 0/3] OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-12-18 10:21 UTC (permalink / raw)
To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Kevin Hilman,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Nishanth Menon, Rafael J. Wysocki,
Stephen Boyd, Viresh Kumar
Cc: Viresh Kumar, linux-pm-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ, sudeep.holla-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Hi,
Now that the performance state of PM domains are supported by the kernel
(merged in linux-next), I am trying once again to define the bindings
which we dropped until the code is merged first.
Summary:
Power-domains can also have their active states and this patchset
enhances the OPP binding to define those.
The power domains can use the OPP bindings mostly as is. Though there
are some changes required to support special cases:
- Allow "operating-points-v2" to contain multiple phandles for power
domain providers providing multiple domains.
- A new property "required-opp" is added for the devices to specify the
minimum required OPP of the master domain or any other type of device.
- Allow some of the OPP properties to accept magic values (firmware
dependent) as the OS doesn't know the real freq/voltage values.
V7->V8:
- V7 1/2 divided into two patches. 1/3 is unchanged from V7.
- 2/3 renamed the property from "power-domain-opp" to "required-opp", as
suggested by Rob.
- Added Ulf's reviewed-by for 1/3 and 3/3.
--
viresh
Viresh Kumar (3):
OPP: Allow OPP table to be used for power-domains
OPP: Introduce "required-opp" property
OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values
Documentation/devicetree/bindings/opp/opp.txt | 19 +++++++
.../devicetree/bindings/power/power_domain.txt | 65 ++++++++++++++++++++++
2 files changed, 84 insertions(+)
--
2.15.0.194.g9af6a3dea062
--
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 V8 1/3] OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-12-18 10:21 UTC (permalink / raw)
To: ulf.hansson, Kevin Hilman, robh+dt, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Rafael J. Wysocki
Cc: Viresh Kumar, linux-pm, Vincent Guittot, rnayak, sudeep.holla,
devicetree, linux-kernel
In-Reply-To: <cover.1513591822.git.viresh.kumar@linaro.org>
Power-domains can also have their active states and this patch enhances
the OPP binding to define those. The power domains can use the OPP
bindings as is, with one additional change to Allow
"operating-points-v2" property to contain multiple phandles for power
domain providers providing multiple domains.
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
Documentation/devicetree/bindings/opp/opp.txt | 5 +++++
Documentation/devicetree/bindings/power/power_domain.txt | 6 ++++++
2 files changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index 9d733af26be7..a3953a1bb1a1 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -45,6 +45,11 @@ Devices supporting OPPs must set their "operating-points-v2" property with
phandle to a OPP table in their DT node. The OPP core will use this phandle to
find the operating points for the device.
+This can contain more than one phandle for power domain providers that provide
+multiple power domains. That is, one phandle for each power domain. If only one
+phandle is available, then the same OPP table will be used for all power domains
+provided by the power domain provider.
+
If required, this can be extended for SoC vendor specific bindings. Such bindings
should be documented as Documentation/devicetree/bindings/power/<vendor>-opp.txt
and should have a compatible description like: "operating-points-v2-<vendor>".
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 14bd9e945ff6..61549840ab3b 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -40,6 +40,12 @@ phandle arguments (so called PM domain specifiers) of length specified by the
domain's idle states. In the absence of this property, the domain would be
considered as capable of being powered-on or powered-off.
+- operating-points-v2 : Phandles to the OPP tables of power domains provided by
+ a power domain provider. If the provider provides a single power domain only
+ or all the power domains provided by the provider have identical OPP tables,
+ then this shall contain a single phandle. Refer to ../opp/opp.txt for more
+ information.
+
Example:
power: power-controller@12340000 {
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH V8 2/3] OPP: Introduce "required-opp" property
From: Viresh Kumar @ 2017-12-18 10:21 UTC (permalink / raw)
To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Kevin Hilman,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Rafael J. Wysocki
Cc: Viresh Kumar, linux-pm-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ, sudeep.holla-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1513591822.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Devices have inter-dependencies some times. For example a device that
needs to run at 800 MHz, needs another device (e.g. Its power domain) to
be configured at a particular operating performance point.
This patch introduces a new property "required-opp" which can be present
directly in a device's node (if it doesn't need to change its OPPs), or
in device's OPP nodes. More details on the property can be seen in the
binding itself.
Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/opp/opp.txt | 8 +++
.../devicetree/bindings/power/power_domain.txt | 59 ++++++++++++++++++++++
2 files changed, 67 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index a3953a1bb1a1..4e4f30288c8b 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -159,6 +159,14 @@ properties.
- status: Marks the node enabled/disabled.
+- required-opp: This contains phandle to an OPP node in another device's OPP
+ table. It may contain an array of phandles, where each phandle points to an
+ OPP of a different device. It should not contain multiple phandles to the OPP
+ nodes in the same OPP table. This specifies the minimum required OPP of the
+ device(s), whose OPP's phandle is present in this property, for the
+ functioning of the current device at the current OPP (where this property is
+ present).
+
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
/ {
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 61549840ab3b..f824763b202e 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -126,4 +126,63 @@ The node above defines a typical PM domain consumer device, which is located
inside a PM domain with index 0 of a power controller represented by a node
with the label "power".
+Optional properties:
+- required-opp: This contains phandle to an OPP node in another device's OPP
+ table. It may contain an array of phandles, where each phandle points to an
+ OPP of a different device. It should not contain multiple phandles to the OPP
+ nodes in the same OPP table. This specifies the minimum required OPP of the
+ device(s), whose OPP's phandle is present in this property, for the
+ functioning of the current device at the current OPP (where this property is
+ present).
+
+Example:
+- OPP table for domain provider that provides two domains.
+
+ domain0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ domain0_opp_0: opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <975000 970000 985000>;
+ };
+ domain0_opp_1: opp-1100000000 {
+ opp-hz = /bits/ 64 <1100000000>;
+ opp-microvolt = <1000000 980000 1010000>;
+ };
+ };
+
+ domain1_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+
+ domain1_opp_0: opp-1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-microvolt = <975000 970000 985000>;
+ };
+ domain1_opp_1: opp-1300000000 {
+ opp-hz = /bits/ 64 <1300000000>;
+ opp-microvolt = <1000000 980000 1010000>;
+ };
+ };
+
+ parent: power-controller@12340000 {
+ compatible = "foo,power-controller";
+ reg = <0x12340000 0x1000>;
+ #power-domain-cells = <1>;
+ operating-points-v2 = <&domain0_opp_table>, <&domain1_opp_table>;
+ };
+
+ leaky-device0@12350000 {
+ compatible = "foo,i-leak-current";
+ reg = <0x12350000 0x1000>;
+ power-domains = <&parent 0>;
+ required-opp = <&domain0_opp_0>;
+ };
+
+ leaky-device1@12350000 {
+ compatible = "foo,i-leak-current";
+ reg = <0x12350000 0x1000>;
+ power-domains = <&parent 1>;
+ required-opp = <&domain1_opp_1>;
+ };
+
[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
--
2.15.0.194.g9af6a3dea062
--
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 V8 3/3] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values
From: Viresh Kumar @ 2017-12-18 10:21 UTC (permalink / raw)
To: ulf.hansson, Kevin Hilman, robh+dt, Viresh Kumar, Nishanth Menon,
Stephen Boyd
Cc: Viresh Kumar, Rafael Wysocki, linux-pm, Vincent Guittot, rnayak,
sudeep.holla, devicetree, linux-kernel
In-Reply-To: <cover.1513591822.git.viresh.kumar@linaro.org>
On some platforms the exact frequency or voltage may be hidden from the
OS by the firmware. Allow such configurations to pass magic values in
the "opp-hz" or the "opp-microvolt" properties, which should be
interpreted in a platform dependent way.
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
Documentation/devicetree/bindings/opp/opp.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index 4e4f30288c8b..00a3bdbd0f1f 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -167,6 +167,12 @@ properties.
functioning of the current device at the current OPP (where this property is
present).
+
+On some platforms the exact frequency or voltage may be hidden from the OS by
+the firmware and the "opp-hz" or the "opp-microvolt" properties may contain
+magic values that represent the frequency or voltage in a firmware dependent
+way, for example an index of an array in the firmware.
+
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
/ {
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH] ARM64: dts: meson-gxl: add internal ethernet PHY irq
From: Jerome Brunet @ 2017-12-18 10:27 UTC (permalink / raw)
To: Kevin Hilman, Carlo Caione
Cc: Jerome Brunet, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Add the interrupt of the internal ethernet PHY
Signed-off-by: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
Hi Kevin,
This changes depends on the net-next changes adding interrupt support [0].
It is really important that this change is not merged before its
dependency.
If it is merged before, instead of polling, the phy would wait for an
interrupt which has not been configured and will never fire.
Tested on the libretech-cc and khadas VIM.
Cheers
Jerome
https://lkml.kernel.org/r/20171218094446.31912-7-jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 4a316a11a00e..8bc404508a4f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -631,6 +631,7 @@
internal_phy: ethernet-phy@8 {
compatible = "ethernet-phy-id0181.4400", "ethernet-phy-ieee802.3-c22";
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
reg = <8>;
max-speed = <100>;
};
--
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
* Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.
From: Enric Balletbo Serra @ 2017-12-18 10:27 UTC (permalink / raw)
To: Daniel Thompson
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: <20171215145120.2d2o33tqlechp45h@oak.lan>
Hi Daniel,
2017-12-15 15:51 GMT+01:00 Daniel Thompson <daniel.thompson@linaro.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@collabora.com>
>> ---
>> 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).
>
>> + 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.
Thanks,
Enric
^ permalink raw reply
* Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.
From: Enric Balletbo Serra @ 2017-12-18 10:40 UTC (permalink / raw)
To: Pavel Machek
Cc: Daniel Thompson, Doug Anderson, Enric Balletbo i Serra,
Jingoo Han, Richard Purdie, Jacek Anaszewski, Rob Herring,
Brian Norris, Guenter Roeck, Lee Jones, Alexandru Stan,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, LKML
In-Reply-To: <20171215205735.GB19442@amd>
Hi Pavel,
2017-12-15 21:57 GMT+01:00 Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>:
> 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 :)
[1] https://lkml.org/lkml/2017/9/4/335
Regards,
Enric
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: [linux-sunxi] [PATCH v3 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
From: Chen-Yu Tsai @ 2017-12-18 10:46 UTC (permalink / raw)
To: Yong
Cc: Maxime Ripard, Chen-Yu Tsai, Mauro Carvalho Chehab, Rob Herring,
Mark Rutland, David S. Miller, Greg Kroah-Hartman, Hans Verkuil,
Randy Dunlap, Benoit Parrot, Stanimir Varbanov, Arnd Bergmann,
Hugues Fruchet, Philipp Zabel, Benjamin Gaignard,
Ramesh Shanmugasundaram, Yannick Fertre, Sakari Ailus
In-Reply-To: <20171218174309.9170c971c5acac0d14dd782d-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
On Mon, Dec 18, 2017 at 5:43 PM, Yong <yong.deng-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org> wrote:
> Hi,
>
> On Mon, 18 Dec 2017 10:24:37 +0100
> Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
>> Hi,
>>
>> On Mon, Dec 18, 2017 at 04:49:21PM +0800, Yong wrote:
>> > > > + compatible = "allwinner,sun8i-v3s-csi";
>> > > > + reg = <0x01cb4000 0x1000>;
>> > > > + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
>> > > > + clocks = <&ccu CLK_BUS_CSI>,
>> > > > + <&ccu CLK_CSI1_SCLK>,
>> > >
>> > > CSI also has an MCLK. Do you need that one?
>> >
>> > MCLK is not needed if the front end is not a sensor (like adv7611).
>> > I will add it as an option.
>>
>> I guess this should always be needed then. And the driver will make
>> the decision to enable it or not.
>
> But how the driver to know if it should be enabled?
> I think MCLK should be added in DT just if the subdev need it.
Looking around the docs, there doesn't seem to be anything related
to MCLK within the CSI section.
Furthermore, camera sensor bindings, such as for the OV5640, in fact
do have a property for a reference clock, which is called XCLK or
XVCLK.
Since the clock is already exported from the CCU, I suppose it's
just a matter of referencing the clock from the camera node, with
the proper pinctrl for that pin.
So to summarize, just ignore my comment about the missing MCLK. :)
ChenYu
--
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/6] dt-bindings: pwm: rcar: Document r8a774[35] PWM bindings
From: Geert Uytterhoeven @ 2017-12-18 10:57 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Thierry Reding, Rob Herring, Mark Rutland, Simon Horman,
Geert Uytterhoeven, Chris Paterson, Biju Das, Linux PWM List,
devicetree, Linux-Renesas
In-Reply-To: <1513248976-26700-3-git-send-email-fabrizio.castro@bp.renesas.com>
On Thu, Dec 14, 2017 at 11:56 AM, Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> This patch adds compatible strings specific to r8a774[35], no driver
> change is needed as the fallback compatible string will activate the
> right code. Also, this patch replaces the example with a DT snippet used
> for adding PWM0 support to an r8a7743 based platform.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.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
* Re: [PATCH 4/6] dt-bindings: pwm: renesas-tpu: Document r8a774[35] support
From: Geert Uytterhoeven @ 2017-12-18 10:58 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Thierry Reding, Rob Herring, Mark Rutland, Simon Horman,
Geert Uytterhoeven, Chris Paterson, Biju Das, Linux PWM List,
devicetree, Linux-Renesas
In-Reply-To: <1513248976-26700-5-git-send-email-fabrizio.castro@bp.renesas.com>
On Thu, Dec 14, 2017 at 11:56 AM, Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> Document r8a774[35] specific compatible strings. No driver change is
> needed as the fallback compatible string "renesas,tpu" activates the
> right code in the driver.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.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
* Re: [PATCH 1/1] arm: sunxi: Add alternative pins for spi0
From: Stefan Mavrodiev @ 2017-12-18 11:00 UTC (permalink / raw)
To: Maxime Ripard
Cc: Stefan Mavrodiev, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Rob Herring,
Mark Rutland, Russell King, Chen-Yu Tsai,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM PORT, open list
In-Reply-To: <20171218092814.n5ptd5mhvo4nkjgq-ZC1Zs529Oq4@public.gmane.org>
On 12/18/2017 11:28 AM, Maxime Ripard wrote:
> On Mon, Dec 18, 2017 at 08:24:21AM +0200, Stefan Mavrodiev wrote:
>> On 12/15/2017 05:08 PM, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Thu, Dec 14, 2017 at 08:24:54AM +0200, Stefan Mavrodiev wrote:
>>>> On 12/13/2017 05:40 PM, Maxime Ripard wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, Dec 13, 2017 at 09:44:34AM +0200, Stefan Mavrodiev wrote:
>>>>>> Allwinner A10/A13/A20 SoCs have pinmux for spi0
>>>>>> on port C. The patch adds these pins in the respective
>>>>>> dts includes.
>>>>>>
>>>>>> Signed-off-by: Stefan Mavrodiev <stefan-kyXcfZUBQGPQT0dZR+AlfA@public.gmane.org>
>>>>> Do you have any boards that are using these?
>>>>>
>>>>> We won't merge that patch if there's no users for it.
>>>> A20-OLinuXino-Lime/Lime2 and A10-OLinuXino-Lime with spi flash.
>>>> For A13 we still doesn't have that option.
>>> If this bus is exposed on the headers, you can add those to the DT but
>>> leave them disabled if you want. Buf if there's no users of those
>>> nodes, our policy is not to merge them.
>> So basically I should resend the patch, enabling the those pins only for
>> sun4i and sun7i platform?
> I'm not quite sure what you mean, but you should do something like
> 77df9d66b0b1ad01c685fd6341ce501493899658
>
> Maxime
>
I guess, since this patch actually supports optional component, it
shouldn't be applied.
(This is already commented here:
https://patchwork.kernel.org/patch/10076721/ )
Thanks,
Stefan Mavrodiev
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox