* Re: [PATCH v5 2/4] iio: Documentation: Add max9611 sysfs documentation
From: Jonathan Cameron @ 2017-04-08 16:00 UTC (permalink / raw)
To: Jacopo Mondi, geert-Td1EMuHUCqxL1ZNQvxDV9g,
wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491488454-22468-3-git-send-email-jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
On 06/04/17 15:20, Jacopo Mondi wrote:
> Add documentation for max9611 driver.
> Document attributes describing value of shunt resistor installed between
> RS+ and RS- voltage sense inputs.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
Looks good to me. There is the small matter that when we generalize this
we will probably loose some detail, but such is life.
Applied to the togreg branch of iio.git and pushed out as testing.
Thanks,
Jonathan
> ---
> Documentation/ABI/testing/sysfs-bus-iio-adc-max9611 | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-max9611
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611 b/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611
> new file mode 100644
> index 0000000..6d2d2b0
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611
> @@ -0,0 +1,17 @@
> +What: /sys/bus/iio/devices/iio:deviceX/in_power_shunt_resistor
> +Date: March 2017
> +KernelVersion: 4.12
> +Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +Description: The value of the shunt resistor used to compute power drain on
> + common input voltage pin (RS+). In Ohms.
> +
> +What: /sys/bus/iio/devices/iio:deviceX/in_current_shunt_resistor
> +Date: March 2017
> +KernelVersion: 4.12
> +Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +Description: The value of the shunt resistor used to compute current flowing
> + between RS+ and RS- voltage sense inputs. In Ohms.
> +
> +These attributes describe a single physical component, exposed as two distinct
> +attributes as it is used to calculate two different values: power load and
> +current flowing between RS+ and RS- inputs.
>
^ permalink raw reply
* Re: [PATCH v5 1/4] Documentation: dt-bindings: iio: Add max9611 ADC
From: Jonathan Cameron @ 2017-04-08 15:59 UTC (permalink / raw)
To: Geert Uytterhoeven, Jacopo Mondi
Cc: Wolfram Sang, Magnus Damm, Laurent Pinchart, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald, Rob Herring, Mark Rutland,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Linux-Renesas,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdUNWJ2C9b9Xzod5HRU_ZG3mVamN6a-ZdOywODJqv6TxQw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 06/04/17 15:43, Geert Uytterhoeven wrote:
> On Thu, Apr 6, 2017 at 4:20 PM, Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org> wrote:
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/max9611.txt
>> @@ -0,0 +1,27 @@
>> +* Maxim max9611/max9612 current sense amplifier with 12-bits ADC interface
>> +
>> +Maxim max9611/max9612 is an high-side current sense amplifier with integrated
>> +12-bits ADC communicating over I2c bus.
>> +The device node for this driver shall be a child of a I2c controller.
>> +
>> +Required properties
>> + - compatible: Should be "maxim,max9611" or "maxim,max9612"
>> + - reg: The 7-bits long I2c address of the device
>> + - shunt-resistor-micro-homs: Value, in micro Ohms, of the current sense shunt
>
> s/homs/ohms/
I'll fix the title as Rob requested and this.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks for your hard work on this one!
Jonathan
>
>> + resistor
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG
From: Pavel Machek @ 2017-04-08 13:39 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Jacek Anaszewski, Rob Herring, Richard Purdie, linux-kernel,
linux-leds, linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <20170407202603.GC15143@minitux>
[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]
Hi!
> [..]
> > > For the patterns I don't know how a trigger for this would look like,
> > > how would setting the pattern of a trigger be propagated down to the
> > > hardware?
> >
> > We'd need a new op and API similar to blink_set()/led_blink_set().
> >
>
> I've tried to find different LED circuits with some sort of pattern
> generator in an attempt to figure out how to design this interface, but
> turned out to be quite hard to find examples; the three I can compare
> are:
>
> * LP5xx series "implements" pattern generation by executing code.
>
> * Qualcomm LPG iterates over 2-64 brightness-values in a pattern, at a
> fixed rate with knobs to configure what happens before starting and
> after finishing iterating over the defined values. It does not support
> smooth transitions between values.
>
> * AS3676 supports a pattern of 32 values controlling if the output
> should be enabled or disabled for each 32.5ms (or 250ms) time period.
> The delay before repeating the pattern can be configured. It support
> smooth transitions between the states.
>
>
> So, while I think I see how you would like to architect this interface I
> am not sure how to figure out the details.
>
> The pattern definition would have to be expressive enough to support the
> features of LP5xx and direct enough to support the limited AS3676. It
> would likely have to express transitions, so that the LPG could generate
> intermediate steps (and we will have to adapt the resolution of the
> ramps based on the other LPGs in the system).
>
> How do we do with patterns that are implementable by the LP5xx but are
> not with the LPG? Should we reject those or should we do some sort of
> best-effort approach in the kernel?
Lets say you get series of
(red, green, blue, delta_t )
points, meaning "in delta_t msec, change color to red, green,
blue. Lets ignore other channels for now. delta_t of 0 would be step
change. Would such interface work for you?
Simple compiler from this to LP5XX code should not be hard to
do. AS3676 ... I'm not sure what to do, AFAICT it is too limited.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] arm64: renesas: enable M3ULCB board peripherals
From: Simon Horman @ 2017-04-08 13:18 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Vladimir Barinov, Magnus Damm, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas,
Sjoerd Simons
In-Reply-To: <20170407135212.GA24096-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
On Fri, Apr 07, 2017 at 09:52:13AM -0400, Simon Horman wrote:
> On Thu, Apr 06, 2017 at 11:53:45AM +0200, Geert Uytterhoeven wrote:
> > Hi Simon,
> >
> > On Fri, Mar 17, 2017 at 11:02 PM, Sjoerd Simons
> > <sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> wrote:
> > > On Thu, 2017-01-26 at 17:53 +0300, Vladimir Barinov wrote:
> > >> This adds the folowing:
> > >> - R8A7796 SoC based M3ULCB board peripherals
> > >>
> > >> Vladimir Barinov (4):
> > >> [1/4] arm64: dts: m3ulcb: enable I2C
> > >> [2/4] arm64: dts: m3ulcb: Update memory node to 2 GiB map
>
> I have queued up the above two patches.
> > >> [3/4] arm64: dts: m3ulcb: enable EthernetAVB
>
> Please update the above patch to reflect the changes made in
> ef3f08c83fd1 ("arm64: dts: r8a7796: salvator-x: Fix EthernetAVB PHY timing")
>
> > >> [4/4] arm64: dts: m3ulcb: enable HS200 for eMMC
>
> I will look at queuing this up in the near future
> with other HS200 enablement patches.
I have now done so; patches 1,2,4 are queued up for v4.13.
--
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 2/6] dma: pl08x: Add Faraday FTDMAC020 to compatible list
From: Linus Walleij @ 2017-04-08 12:04 UTC (permalink / raw)
To: Vinod Koul, dmaengine-u79uwXL29TY76Z2rM5mHXA
Cc: Janos Laube, Paulius Zaleckas,
openwrt-devel-p3rKhJxN3npAfugRpC6u6w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Hans Ulli Kroll, Florian Fainelli, Kuo-Jung Su, Linus Walleij,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170408120457.22750-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This augments the PL08x bindings to include the Faraday Technology
FTDMAC020 DMA engine, as it is clearly a derivative of the PL08x
PrimeCell. Also specify that it needs the special peripheral ID
specified to work properly.
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Seeking a DT maintainer ACK on this.
---
Documentation/devicetree/bindings/dma/arm-pl08x.txt | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/arm-pl08x.txt b/Documentation/devicetree/bindings/dma/arm-pl08x.txt
index 8a0097a029d3..0ba81f79266f 100644
--- a/Documentation/devicetree/bindings/dma/arm-pl08x.txt
+++ b/Documentation/devicetree/bindings/dma/arm-pl08x.txt
@@ -3,6 +3,11 @@
Required properties:
- compatible: "arm,pl080", "arm,primecell";
"arm,pl081", "arm,primecell";
+ "faraday,ftdmac020", "arm,primecell"
+- arm,primecell-periphid: on the FTDMAC020 the primecell ID is not hard-coded
+ in the hardware and must be specified here as <0x0003b080>. This number
+ follows the PrimeCell standard numbering using the JEP106 vendor code 0x38
+ for Faraday Technology.
- reg: Address range of the PL08x registers
- interrupt: The PL08x interrupt number
- clocks: The clock running the IP core clock
@@ -20,8 +25,8 @@ Optional properties:
- dma-requests: contains the total number of DMA requests supported by the DMAC
- memcpy-burst-size: the size of the bursts for memcpy: 1, 4, 8, 16, 32
64, 128 or 256 bytes are legal values
-- memcpy-bus-width: the bus width used for memcpy: 8, 16 or 32 are legal
- values
+- memcpy-bus-width: the bus width used for memcpy in bits: 8, 16 or 32 are legal
+ values, the Faraday FTDMAC020 can also accept 64 bits
Clients
Required properties:
--
2.9.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
* I expect your urgent communication.
From: Mr. Mudi Feez @ 2017-04-08 11:39 UTC (permalink / raw)
--
Dear Friend,
Good day. I am Mr. Mudi Feez. I am working with one of the prime banks
in Burkina Faso. I have decided to contact you for a financial
transaction which values $14,500,000.00 (Fourteen Million Five Hundred
Thousand USA Dollars). This is an abandoned fund that belongs to a
late foreign customer of our bank. I want a foreign account where the
bank will transfer this fund.
I was very fortunate to come across the deceased customer's security
file; during documentation of old and abandoned customers files for an
official re-documentation and audit of the year 2017.
If you are really sure of your trustworthiness, accountability and
confidentiality over this transaction, contact me urgently. I will let
you know the next step and procedure to follow in order to finalize
this transaction successfully.
I expect your urgent communication.
Yours sincerely,
Mr. Mudi Feez
--
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
* I expect your urgent communication.
From: Mr. Mudi Feez @ 2017-04-08 11:11 UTC (permalink / raw)
--
Dear Friend,
Good day. I am Mr. Mudi Feez. I am working with one of the prime banks
in Burkina Faso. I have decided to contact you for a financial
transaction which values $14,500,000.00 (Fourteen Million Five Hundred
Thousand USA Dollars). This is an abandoned fund that belongs to a
late foreign customer of our bank. I want a foreign account where the
bank will transfer this fund.
I was very fortunate to come across the deceased customer's security
file; during documentation of old and abandoned customers files for an
official re-documentation and audit of the year 2017.
If you are really sure of your trustworthiness, accountability and
confidentiality over this transaction, contact me urgently. I will let
you know the next step and procedure to follow in order to finalize
this transaction successfully.
I expect your urgent communication.
Yours sincerely,
Mr. Mudi Feez
--
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] dt-bindings: Add documentation for GP10B GPU
From: Alexandre Courbot @ 2017-04-08 10:20 UTC (permalink / raw)
To: Thierry Reding
Cc: Alexandre Courbot, Jonathan Hunter, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel Mailing List,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170331125607.GA29779-EkSeR96xj6Pcmrwk2tT4+A@public.gmane.org>
On Fri, Mar 31, 2017 at 9:56 PM, Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Mar 30, 2017 at 06:26:44PM +0900, Alexandre Courbot wrote:
>> GP10B's definition is mostly similar to GK20A's and GM20B's. The only
>> noticeable difference is the use of power domains instead of a regulator
>> for power supply.
>>
>> Signed-off-by: Alexandre Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>> ---
>> Changes since v1:
>> - It's much better when it compiles.
>>
>> .../devicetree/bindings/gpu/nvidia,gk20a.txt | 25 +++++++++++++++++++++-
>> 1 file changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
>> index ff3db65e50de..b7e4c7444510 100644
>> --- a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
>> +++ b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
>> @@ -5,6 +5,7 @@ Required properties:
>> Currently recognized values:
>> - nvidia,gk20a
>> - nvidia,gm20b
>> + - nvidia,gp10b
>> - reg: Physical base address and length of the controller's registers.
>> Must contain two entries:
>> - first entry for bar0
>> @@ -14,7 +15,8 @@ Required properties:
>> - interrupt-names: Must include the following entries:
>> - stall
>> - nonstall
>> -- vdd-supply: regulator for supply voltage.
>> +- vdd-supply: regulator for supply voltage. Only required for GPUs not using
>> + power domains.
>> - clocks: Must contain an entry for each entry in clock-names.
>> See ../clocks/clock-bindings.txt for details.
>> - clock-names: Must include the following entries:
>> @@ -27,6 +29,8 @@ is also required:
>> See ../reset/reset.txt for details.
>> - reset-names: Must include the following entries:
>> - gpu
>> +- power-domains: GPUs that make use of power domains can define this property
>> + instead of vdd-supply. Currently "nvidia,gp10b" makes use of this.
>>
>> Optional properties:
>> - iommus: A reference to the IOMMU. See ../iommu/iommu.txt for details.
>> @@ -68,3 +72,22 @@ Example for GM20B:
>> iommus = <&mc TEGRA_SWGROUP_GPU>;
>> status = "disabled";
>> };
>> +
>> +Example for GP10B:
>> +
>> + gpu@17000000 {
>> + compatible = "nvidia,gp10b";
>> + reg = <0x0 0x17000000 0x0 0x1000000>,
>> + <0x0 0x18000000 0x0 0x1000000>;
>
> Would it make sense to add a reg-names property to give these meaning? I
> know that the binding describes what each entry is, but having the names
> specified in a property would make it more immediately obvious.
Would certainly work, especially since we have been doing this for
other properties. Is there an obvious pro to doing this though?
^ permalink raw reply
* [PATCH v2] ARM: dts: armada-38x: label USB and SATA nodes
From: Ralph Sennhauser @ 2017-04-08 10:16 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Ralph Sennhauser, Jason Cooper, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Recently most nodes got labels to make them referenceable. The USB 3.0
nodes as well as the nodes for the SATA controllers were left out,
rectify the omission.
The labels "sataX" are already used by some boards for the SATA ports,
therefore use "ahciX" to label the SATA controller nodes.
To avoid potential confusion by labeling an USB3.0 controller "usb2" use
usb3_X as labels. This also coincides with the node names themselves
(usb@xxxxx vs usb3@xxxxx).
Signed-off-by: Ralph Sennhauser <ralph.sennhauser-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Hi everybody,
Using satacX for controllers with satacXpY for ports might have been a
possiblity, since ahciX is already used similarly (to avoid a conflict
with current use of sataX) ahciX seems the better choice. Works well me
thinks.
The usb3_X labels still seem the best choice even though they aren't
perfectly consitent, however, I don't see an alternative which would fit
this requirement either.
Regards
Ralph
---
Changes v1 -> v2:
* use ahciX instead of satacX for the SATA controller nodes (suggested
by Andrew Lunn)
arch/arm/boot/dts/armada-38x.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
index ba27ec1..8b165c3 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -530,7 +530,7 @@
interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
};
- sata@a8000 {
+ ahci0: sata@a8000 {
compatible = "marvell,armada-380-ahci";
reg = <0xa8000 0x2000>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
@@ -546,7 +546,7 @@
status = "disabled";
};
- sata@e0000 {
+ ahci1: sata@e0000 {
compatible = "marvell,armada-380-ahci";
reg = <0xe0000 0x2000>;
interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
@@ -590,7 +590,7 @@
status = "disabled";
};
- usb3@f0000 {
+ usb3_0: usb3@f0000 {
compatible = "marvell,armada-380-xhci";
reg = <0xf0000 0x4000>,<0xf4000 0x4000>;
interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
@@ -598,7 +598,7 @@
status = "disabled";
};
- usb3@f8000 {
+ usb3_1: usb3@f8000 {
compatible = "marvell,armada-380-xhci";
reg = <0xf8000 0x4000>,<0xfc000 0x4000>;
interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG
From: Pavel Machek @ 2017-04-08 9:57 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Jacek Anaszewski, Rob Herring, Richard Purdie, linux-kernel,
linux-leds, linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <20170407202603.GC15143@minitux>
[-- Attachment #1: Type: text/plain, Size: 3467 bytes --]
Hi!
> > On 04/03/2017 09:00 PM, Bjorn Andersson wrote:
> [..]
> > > For the patterns I don't know how a trigger for this would look like,
> > > how would setting the pattern of a trigger be propagated down to the
> > > hardware?
> >
> > We'd need a new op and API similar to blink_set()/led_blink_set().
> >
>
> I've tried to find different LED circuits with some sort of pattern
> generator in an attempt to figure out how to design this interface, but
> turned out to be quite hard to find examples; the three I can compare
> are:
>
> * LP5xx series "implements" pattern generation by executing code.
It supports "linear" and "exponential" transitions between
values. Variable number of steps.
> * Qualcomm LPG iterates over 2-64 brightness-values in a pattern, at a
> fixed rate with knobs to configure what happens before starting and
> after finishing iterating over the defined values. It does not support
> smooth transitions between values.
>
> * AS3676 supports a pattern of 32 values controlling if the output
> should be enabled or disabled for each 32.5ms (or 250ms) time period.
> The delay before repeating the pattern can be configured. It support
> smooth transitions between the states.
Ok, that's "really interesting" one. As far as I can see, the pattern
really should only contain justtwo intensities...
> So, while I think I see how you would like to architect this interface I
> am not sure how to figure out the details.
>
> The pattern definition would have to be expressive enough to support the
> features of LP5xx and direct enough to support the limited AS3676. It
> would likely have to express transitions, so that the LPG could generate
> intermediate steps (and we will have to adapt the resolution of the
> ramps based on the other LPGs in the system).
That's why I believe it is important to present whole pattern engine
as one unit to the userspace. Userspace should always upload pattern
for _all_ the LEDs at once.
> How do we do with patterns that are implementable by the LP5xx but are
> not with the LPG? Should we reject those or should we do some sort of
> best-effort approach in the kernel?
Up to you, I guess. Both rejecting and best-effort make some sense.
OTOH if pattern is "(off, 0msec), (white, +1000msec), (off,
+0msec)"... you can't really do it "exactly" even on LP5xx, due to
non-trivial conversion between PWM and what user sees....
So on LPG you'd really do "(off, 0msec), (10% white, +100msec), (20%
white, +100msec), ..."
AS3676... I guess after we reject all patterns that have more than 0
and one specific brightness, we can use similar approximation we'd do
on LPG?
> > This is what we have now, so we can live with it. Addition of a new
> > RGB trigger would be an improvement of the existing state.
> >
>
> If we do the brightness compensation (for e.g. white balance
> adjustments) in a trigger then there's added value.
>
> The part where I see this affects the LPG driver is that the brightness
> of the patterns might have to be adjusted accordingly - which probably
> would be easier to implement if the kernel just exposed the compensation
> values to user space.
Well, compensation needs to happen "during the transitions",
too.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG
From: Pavel Machek @ 2017-04-08 9:33 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Jacek Anaszewski, Rob Herring, Richard Purdie,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170407203649.GD15143@minitux>
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]
On Fri 2017-04-07 13:36:49, Bjorn Andersson wrote:
> On Fri 07 Apr 06:32 PDT 2017, Pavel Machek wrote:
>
> > > For the patterns I don't know how a trigger for this would look like,
> > > how would setting the pattern of a trigger be propagated down to the
> > > hardware?
> >
> > Well... I'm not sure if we _want_ to do triggers for
> > patterns. LED triggers change rather quickly (100 times a second?) so
> > doing them in kernel makes sense. Patterns take 10s of seconds, so we
> > do not need to handle them in kernel.
> >
>
> On any current Qualcomm based phone (using the Qualcomm PMIC to drive
> the RGB notification LED) the patterns are hard coded in DeviceTree and
> the option you have in runtime is to enable/disable the usage of the
> configured pattern and a few knobs of how to traverse the configured
> pattern.
Yes... that's easy, but I believe too limiting. Users will want to
configure their own patterns for their own events.
> When you enter e.g. a low-battery scenario you trigger the red LED to
> run its low-battery-pattern and you don't touch it until there's a
> higher prio notification (e.g. someone connects the charger).
Yes, I have something like that, too.
https://gitlab.com/tui/tui/blob/master/ofone/watchdog.py
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH 1/3] gpio - Add EXAR XRA1403 SPI GPIO expander driver
From: Han, Nandor (GE Healthcare) @ 2017-04-08 7:38 UTC (permalink / raw)
To: Linus Walleij
Cc: Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Malinen, Semi (GE Healthcare)
In-Reply-To: <CACRpkdYZVy2t9=K0jVm5=BxhWWUwiNsGDTMVBbSiB9+1+uafJQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2429 bytes --]
> -----Original Message-----
> From: Linus Walleij [mailto:linus.walleij@linaro.org]
> Sent: 07 April 2017 13:07
> To: Han, Nandor (GE Healthcare) <nandor.han@ge.com>
> Cc: Alexandre Courbot <gnurou@gmail.com>; Rob Herring <robh+dt@kernel.org>; Mark Rutland
> <mark.rutland@arm.com>; linux-gpio@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> Malinen, Semi (GE Healthcare) <semi.malinen@ge.com>
> Subject: EXT: Re: [PATCH 1/3] gpio - Add EXAR XRA1403 SPI GPIO expander driver
>
> On Wed, Apr 5, 2017 at 3:24 PM, Han, Nandor (GE Healthcare)
> <nandor.han@ge.com> wrote:
> > [Me]
> >> > + /* bring the chip out of reset */
> >> > + reset_gpio = gpiod_get_optional(&spi->dev, "reset", GPIOD_OUT_LOW);
> >> > + if (IS_ERR(reset_gpio))
> >> > + dev_warn(&spi->dev, "could not get reset-gpios\n");
> >> > + else if (reset_gpio)
> >> > + gpiod_put(reset_gpio);
> >>
> >> I don't think you should put it, other than in the remove()
> >> function and in that case you need to have it in the
> >> state container.
> >
> > Can you please be more explicit here.
> >
> > Currently I'm trying to bring the device out from reset in case reset GPIO is provided.
> > I don't see how this could be done in remove() :)
>
> If you issue gpiod_put() you release the GPIO hande so something else
> can go in and grab the GPIO and assert the reset.
>
> This is not what you want to make possible: you want to hold this gpiod handle
> as long as the driver is running. devm_gpiod_get_optional() will do the
> trick if you don't want to put the handle under explicit control.
>
That was my first intention to release the reset line in case somebody else wants to control it. I did it
like that because usually reset line controls multiple devices and probably some upper layer wants to
control that.
After your comment I did some analysing and I will follow your advice and change the reset line handling.
Once the GPIO is provided to the driver the driver will own it and bring out the device from reset. In case not
provided the reset line is somebody else responsibility.
This way we are able to cover multiple use-cases.
Thanks Linus,
Nandy
> Yours,
> Linus Walleij
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i
^ permalink raw reply
* 33011 devicetree
From: john.faust-H4SBLDCxrCifRvmTrFJqzg @ 2017-04-08 7:03 UTC (permalink / raw)
To: devicetree
[-- Attachment #1: 886869958978.zip --]
[-- Type: application/zip, Size: 2486 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] arm64: dts: hisi: add NIC, RoCE and SAS support for hip07
From: Wei Xu @ 2017-04-08 6:51 UTC (permalink / raw)
To: robh+dt, mark.rutland, catalin.marinas, will.deacon, arnd
Cc: wangkefeng.wang, gabriele.paoloni, charles.chenxin, linuxarm,
guohanjun, yankejian, yimin, huangdaode, liudongdong3,
yisen.zhuang, devicetree, john.garry, tanxiaofei, lipeng321,
linux-arm-kernel, salil.mehta, chenxiang66, linux-kernel,
shameerali.kolothum.thodi, wangzhou1, liguozhu, majun258
In-Reply-To: <1491530876-109791-1-git-send-email-xuwei5@hisilicon.com>
Hi All,
On 2017/4/7 10:07, Wei.Xu wrote:
> This patch series adds Mbigen, NIC, RoCE and SAS nodes for the hip07
> SoC and enables the NIC, RoCE and SAS on the hip07 d05 board.
>
> Wei Xu (5):
> arm64: dts: hisi: add mbigen nodes for the hip07 SoC
> arm64: dts: hisi: add network related nodes for the hip07 SoC
> arm64: dts: hisi: add RoCE nodes for the hip07 SoC
> arm64: dts: hisi: add SAS nodes for the hip07 SoC
> arm64: dts: hisi: enalbe the NIC and SAS for the hip07-d05 board
>
> arch/arm64/boot/dts/hisilicon/hip07-d05.dts | 24 ++
> arch/arm64/boot/dts/hisilicon/hip07.dtsi | 479 ++++++++++++++++++++++++++++
> 2 files changed, 503 insertions(+)
>
After removed the PCIe node in the patch 5, the series has been applied
to the hisilicon arm64
dt tree since this series patches just to add the nodes and the binding
has been reviewed before.
Best Regards,
Wei
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: arm: hisilicon: add bindings for hi3798cv200 SoC and Poplar board
From: Wei Xu @ 2017-04-08 6:46 UTC (permalink / raw)
To: Jiancheng Xue, robh+dt, arnd, catalin.marinas, will.deacon
Cc: devicetree, linux-kernel, yanhaifeng, peter.griffin, elder,
hermit.wangheming, afaerber, linux-arm-kernel
In-Reply-To: <1490769009-12552-2-git-send-email-xuejiancheng@hisilicon.com>
Hi Jiancheng,
On 2017/3/29 14:30, Jiancheng Xue wrote:
> Add bindings for HiSilicon hi3798cv200 SoC and Poplar Board.
>
> Signed-off-by: Jiancheng Xue <xuejiancheng@hisilicon.com>
> Reviewed-by: Alex Elder <elder@linaro.org>
> Acked-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
Thanks!
Applied both to the hisilicon arm64 dt tree but added hi3798cv200 soc
binding to avoid the patch checking warning.
Best Regards,
Wei
> ---
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
> index f1c1e21..1fd3dd7 100644
> --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
> @@ -4,6 +4,10 @@ Hi3660 SoC
> Required root node properties:
> - compatible = "hisilicon,hi3660";
>
> +Hi3798cv200 Poplar Board
> +Required root node properties:
> + - compatible = "hisilicon,hi3798cv200-poplar", "hisilicon,hi3798cv200";
> +
> Hi4511 Board
> Required root node properties:
> - compatible = "hisilicon,hi3620-hi4511";
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: add drive-strength levels of pin for Hi3660 SoC
From: Wei Xu @ 2017-04-08 6:42 UTC (permalink / raw)
To: Wang Xiaoyin, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: chenya99-C8/M+/jPZTeaMJb+Lgu22Q
In-Reply-To: <20170330064803.18648-1-hw.wangxiaoyin-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
Hi Xiaoyin,
On 2017/3/30 14:48, Wang Xiaoyin wrote:
> Add drive-strength levels of pin for Hi3660 Soc.
>
> Signed-off-by: Wang Xiaoyin <hw.wangxiaoyin-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
Thanks!
Applied both to the hisilicon arm64 dt tree.
Best Regards,
Wei
> ---
> include/dt-bindings/pinctrl/hisi.h | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/dt-bindings/pinctrl/hisi.h b/include/dt-bindings/pinctrl/hisi.h
> index 38f1ea879ea1..0359bfdc9119 100644
> --- a/include/dt-bindings/pinctrl/hisi.h
> +++ b/include/dt-bindings/pinctrl/hisi.h
> @@ -56,4 +56,19 @@
> #define DRIVE4_08MA (4 << 4)
> #define DRIVE4_10MA (6 << 4)
>
> +/* drive strength definition for hi3660 */
> +#define DRIVE6_MASK (15 << 4)
> +#define DRIVE6_04MA (0 << 4)
> +#define DRIVE6_12MA (4 << 4)
> +#define DRIVE6_19MA (8 << 4)
> +#define DRIVE6_27MA (10 << 4)
> +#define DRIVE6_32MA (15 << 4)
> +#define DRIVE7_02MA (0 << 4)
> +#define DRIVE7_04MA (1 << 4)
> +#define DRIVE7_06MA (2 << 4)
> +#define DRIVE7_08MA (3 << 4)
> +#define DRIVE7_10MA (4 << 4)
> +#define DRIVE7_12MA (5 << 4)
> +#define DRIVE7_14MA (6 << 4)
> +#define DRIVE7_16MA (7 << 4)
> #endif
--
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] ARM: dts: hi6220: Reset the mmc hosts
From: Wei Xu @ 2017-04-08 6:38 UTC (permalink / raw)
To: Daniel Lezcano
Cc: stable, linux-kernel, linux-arm-kernel, guodong.xu, devicetree
In-Reply-To: <1489673004-11075-1-git-send-email-daniel.lezcano@linaro.org>
Hi Daniel,
On 2017/3/16 22:03, Daniel Lezcano wrote:
> The MMC hosts could be left in an unconsistent or uninitialized state from
> the firmware. Instead of assuming, the firmware did the right things, let's
> reset the host controllers.
>
> This change fixes a bug when the mmc2/sdio is initialized leading to a hung
> task:
>
> [ 242.704294] INFO: task kworker/7:1:675 blocked for more than 120 seconds.
> [ 242.711129] Not tainted 4.9.0-rc8-00017-gcf0251f #3
> [ 242.716571] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 242.724435] kworker/7:1 D 0 675 2 0x00000000
> [ 242.729973] Workqueue: events_freezable mmc_rescan
> [ 242.734796] Call trace:
> [ 242.737269] [<ffff00000808611c>] __switch_to+0xa8/0xb4
> [ 242.742437] [<ffff000008d07c04>] __schedule+0x1c0/0x67c
> [ 242.747689] [<ffff000008d08254>] schedule+0x40/0xa0
> [ 242.752594] [<ffff000008d0b284>] schedule_timeout+0x1c4/0x35c
> [ 242.758366] [<ffff000008d08e38>] wait_for_common+0xd0/0x15c
> [ 242.763964] [<ffff000008d09008>] wait_for_completion+0x28/0x34
> [ 242.769825] [<ffff000008a1a9f4>] mmc_wait_for_req_done+0x40/0x124
> [ 242.775949] [<ffff000008a1ab98>] mmc_wait_for_req+0xc0/0xf8
> [ 242.781549] [<ffff000008a1ac3c>] mmc_wait_for_cmd+0x6c/0x84
> [ 242.787149] [<ffff000008a26610>] mmc_io_rw_direct_host+0x9c/0x114
> [ 242.793270] [<ffff000008a26aa0>] sdio_reset+0x34/0x7c
> [ 242.798347] [<ffff000008a1d46c>] mmc_rescan+0x2fc/0x360
>
> [ ... ]
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Thanks!
Applied to the hisilicon arm64 dt tree.
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 470461d..1e5129b 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -774,6 +774,7 @@
> clocks = <&sys_ctrl 2>, <&sys_ctrl 1>;
> clock-names = "ciu", "biu";
> resets = <&sys_ctrl PERIPH_RSTDIS0_MMC0>;
> + reset-names = "reset";
> bus-width = <0x8>;
> vmmc-supply = <&ldo19>;
> pinctrl-names = "default";
> @@ -797,6 +798,7 @@
> clocks = <&sys_ctrl 4>, <&sys_ctrl 3>;
> clock-names = "ciu", "biu";
> resets = <&sys_ctrl PERIPH_RSTDIS0_MMC1>;
> + reset-names = "reset";
> vqmmc-supply = <&ldo7>;
> vmmc-supply = <&ldo10>;
> bus-width = <0x4>;
> @@ -815,6 +817,7 @@
> clocks = <&sys_ctrl HI6220_MMC2_CIUCLK>, <&sys_ctrl HI6220_MMC2_CLK>;
> clock-names = "ciu", "biu";
> resets = <&sys_ctrl PERIPH_RSTDIS0_MMC2>;
> + reset-names = "reset";
> bus-width = <0x4>;
> broken-cd;
> pinctrl-names = "default", "idle";
^ permalink raw reply
* RE: Device Tree Binding for Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong @ 2017-04-08 5:25 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ong, Hean Loong
In-Reply-To: <CAL_JsqLFbHHcVYs4a+-WS7yUEMsFR6-Y_4gootxoAwxD+RRF1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
First of all thank you Rob for your time and patience. Especially on how this patch was sent out. I would ensure it would not happen again for the subsequent patches.
On the issue of why the DT has certain resolution fixed is due to the fact that our Quartus system generates these attributes in according to the specific display resolution as desired by the user. The values here are the ideal resolution supported by the hardware for the reference design.
On the other hand my bad on the vendor prefix as I misunderstood the "altr," as the vendor prefix
Thanks
Hean Loong
>-----Original Message-----
>From: Rob Herring [mailto:robh+dt@kernel.org]
>Sent: Saturday, April 8, 2017 5:53 AM
>To: Ong, Hean Loong <hean.loong.ong@intel.com>
>Cc: devicetree@vger.kernel.org
>Subject: Re: Device Tree Binding for Intel FPGA Video and Image Processing Suite
>
>On Thu, Apr 6, 2017 at 1:42 AM, Ong, Hean Loong <hean.loong.ong@intel.com>
>wrote:
>> Hi Rob,
>>
>> Any comments on the patch?
>
>Yes, the same ones I provided 5 months ago to you. Repeated below.
>
>>
>> BR
>>
>> Hean Loong
>>
>> On Tue, 2017-04-04 at 03:57 +0000, Ong, Hean Loong wrote:
>>> Hi Rob,
>>>
>>> Apologies for the mistake. Below are the bindings
>>>
>>> From 23a9e274bb517b8e232c5aa4cf9737de1644b708 Mon Sep 17 00:00:00
>>> 2001
>>> From: Ong, Hean Loong <hean.loong.ong@intel.com>
>>> Date: Thu, 30 Mar 2017 17:59:37 +0800
>>> Subject: [PATCHv0] Intel FPGA Video and Image Processing Suite device
>>> tree binding
>
>This is still not how you email patches. The easiest way is git-send-email.
>
>>> Device tree binding for Intel FPGA Video and Image
>>> Processing Suite. The binding involved would be generated
>>> from the Altera (Intel) Qsys system. The bindings would
>>> set the max width, max height, buts per pixel and memory
>>> port width. The device tree binding only supports the Intel
>>> Arria10 devkit and its variants. Vendor name retained as
>>> altr.
>
>There should be no indentation here.
>
>>>
>>> Signed-off-by: Ong, Hean Loong <hean.loong.ong@intel.com>
>>> ---
>>> .../devicetree/bindings/gpu/altr,vip-fb2.txt | 24
>>> ++++++++++++++++++++
>
>bindings/display/. This is not a GPU.
>
>>> 1 files changed, 24 insertions(+), 0 deletions(-) create mode
>>> 100644 Documentation/devicetree/bindings/gpu/altr,vip-
>>> fb2.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt
>>> b/Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt
>>> new file mode 100644
>>> index 0000000..9ba3209
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt
>>> @@ -0,0 +1,24 @@
>>> +Intel Video and Image Processing(VIP) Frame Buffer II bindings
>>> +
>>> +Supported hardware: Arria 10 and above with display port IP
>>> +
>>> +Required properties:
>>> +- compatible: "altr,vip-frame-buffer-2.0"
>>> +- reg: Physical base address and length of the framebuffer
>>> controller's
>>> + registers.
>
>>> +- max-width: The width of the framebuffer in pixels.
>>> +- max-height: The height of the framebuffer in pixels.
>>> +- bits-per-symbol: only "8" is currently supported
>
>Why do these need to be in DT?
>
>>> +- mem-port-width = the bus width of the avalon master port on the
>>> frame reader
>
>Still needs a vendor prefix.
>
>>> +
>>> +Example:
>>> +
>>> +dp_0_frame_buf: vip@0x100000280 {
>
>display-controller@100000280
>
>>> + compatible = "altr,vip-frame-buffer-2.0";
>>> + reg = <0x00000001 0x00000280 0x00000040>;
>>> + altr,max-width = <1280>;
>>> + altr,max-height = <720>;
>>> + altr,bits-per-symbol = <8>;
>>> + altr,mem-port-width = <128>;
>>> +};
>>> +
>>> --
>>> 1.7.1
>>>
^ permalink raw reply
* Re: [PATCH 2/2] gpio: arizona: Add support for GPIOs that need to be maintained
From: kbuild test robot @ 2017-04-08 4:06 UTC (permalink / raw)
To: Charles Keepax
Cc: kbuild-all, linus.walleij, lee.jones, gnurou, robh+dt,
mark.rutland, linux-gpio, devicetree, linux-kernel, patches
In-Reply-To: <1491568725-14882-2-git-send-email-ckeepax@opensource.wolfsonmicro.com>
[-- Attachment #1: Type: text/plain, Size: 7265 bytes --]
Hi Charles,
[auto build test ERROR on gpio/for-next]
[also build test ERROR on v4.11-rc5 next-20170407]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Charles-Keepax/mfd-arizona-Add-GPIO-maintain-state-flag/20170408-111119
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next
config: x86_64-randconfig-x009-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
drivers/gpio/gpio-arizona.c: In function 'arizona_gpio_direction_in':
>> drivers/gpio/gpio-arizona.c:44:3: error: implicit declaration of function 'pm_runtime_mark_last_busy' [-Werror=implicit-function-declaration]
pm_runtime_mark_last_busy(chip->parent);
^~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/gpio/gpio-arizona.c:45:3: error: implicit declaration of function 'pm_runtime_put_autosuspend' [-Werror=implicit-function-declaration]
pm_runtime_put_autosuspend(chip->parent);
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpio/gpio-arizona.c: In function 'arizona_gpio_set':
>> drivers/gpio/gpio-arizona.c:93:9: error: implicit declaration of function 'pm_runtime_get_sync' [-Werror=implicit-function-declaration]
ret = pm_runtime_get_sync(chip->parent);
^~~~~~~~~~~~~~~~~~~
>> drivers/gpio/gpio-arizona.c:96:11: warning: 'return' with a value, in function returning void
return ret;
^~~
drivers/gpio/gpio-arizona.c:82:13: note: declared here
static void arizona_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
^~~~~~~~~~~~~~~~
drivers/gpio/gpio-arizona.c: In function 'arizona_gpio_probe':
>> drivers/gpio/gpio-arizona.c:185:2: error: implicit declaration of function 'pm_runtime_enable' [-Werror=implicit-function-declaration]
pm_runtime_enable(&pdev->dev);
^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/pm_runtime_mark_last_busy +44 drivers/gpio/gpio-arizona.c
38 int status = arizona_gpio->status[offset];
39
40 status &= (ARIZONA_GP_MAINTAIN | ARIZONA_GP_STATE_OUTPUT);
41 if (status == (ARIZONA_GP_MAINTAIN | ARIZONA_GP_STATE_OUTPUT)) {
42 arizona_gpio->status[offset] &= ~ARIZONA_GP_STATE_OUTPUT;
43
> 44 pm_runtime_mark_last_busy(chip->parent);
> 45 pm_runtime_put_autosuspend(chip->parent);
46 }
47
48 return regmap_update_bits(arizona->regmap, ARIZONA_GPIO1_CTRL + offset,
49 ARIZONA_GPN_DIR, ARIZONA_GPN_DIR);
50 }
51
52 static int arizona_gpio_get(struct gpio_chip *chip, unsigned offset)
53 {
54 struct arizona_gpio *arizona_gpio = gpiochip_get_data(chip);
55 struct arizona *arizona = arizona_gpio->arizona;
56 unsigned int val;
57 int ret;
58
59 ret = regmap_read(arizona->regmap, ARIZONA_GPIO1_CTRL + offset, &val);
60 if (ret < 0)
61 return ret;
62
63 if (val & ARIZONA_GPN_LVL)
64 return 1;
65 else
66 return 0;
67 }
68
69 static int arizona_gpio_direction_out(struct gpio_chip *chip,
70 unsigned offset, int value)
71 {
72 struct arizona_gpio *arizona_gpio = gpiochip_get_data(chip);
73 struct arizona *arizona = arizona_gpio->arizona;
74
75 if (value)
76 value = ARIZONA_GPN_LVL;
77
78 return regmap_update_bits(arizona->regmap, ARIZONA_GPIO1_CTRL + offset,
79 ARIZONA_GPN_DIR | ARIZONA_GPN_LVL, value);
80 }
81
82 static void arizona_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
83 {
84 struct arizona_gpio *arizona_gpio = gpiochip_get_data(chip);
85 struct arizona *arizona = arizona_gpio->arizona;
86 int status = arizona_gpio->status[offset];
87 int ret;
88
89 status &= (ARIZONA_GP_MAINTAIN | ARIZONA_GP_STATE_OUTPUT);
90 if (status == ARIZONA_GP_MAINTAIN) {
91 arizona_gpio->status[offset] |= ARIZONA_GP_STATE_OUTPUT;
92
> 93 ret = pm_runtime_get_sync(chip->parent);
94 if (ret < 0) {
95 dev_err(chip->parent, "Failed to resume: %d\n", ret);
> 96 return ret;
97 }
98 }
99
100 if (value)
101 value = ARIZONA_GPN_LVL;
102
103 regmap_update_bits(arizona->regmap, ARIZONA_GPIO1_CTRL + offset,
104 ARIZONA_GPN_LVL, value);
105 }
106
107 static int arizona_gpio_of_xlate(struct gpio_chip *chip,
108 const struct of_phandle_args *gpiospec,
109 u32 *flags)
110 {
111 struct arizona_gpio *arizona_gpio = gpiochip_get_data(chip);
112 u32 offset = gpiospec->args[0];
113 u32 bits = gpiospec->args[1];
114
115 if (gpiospec->args_count < chip->of_gpio_n_cells)
116 return -EINVAL;
117
118 if (offset >= chip->ngpio)
119 return -EINVAL;
120
121 if (flags)
122 *flags = bits & ~ARIZONA_GP_MAINTAIN;
123
124 if (bits & ARIZONA_GP_MAINTAIN)
125 arizona_gpio->status[offset] |= ARIZONA_GP_MAINTAIN;
126
127 return offset;
128 }
129
130 static const struct gpio_chip template_chip = {
131 .label = "arizona",
132 .owner = THIS_MODULE,
133 .direction_input = arizona_gpio_direction_in,
134 .get = arizona_gpio_get,
135 .direction_output = arizona_gpio_direction_out,
136 .set = arizona_gpio_set,
137 .can_sleep = true,
138 .of_xlate = arizona_gpio_of_xlate,
139 .of_gpio_n_cells = 2,
140 };
141
142 static int arizona_gpio_probe(struct platform_device *pdev)
143 {
144 struct arizona *arizona = dev_get_drvdata(pdev->dev.parent);
145 struct arizona_pdata *pdata = dev_get_platdata(arizona->dev);
146 struct arizona_gpio *arizona_gpio;
147 int ret;
148
149 arizona_gpio = devm_kzalloc(&pdev->dev, sizeof(*arizona_gpio),
150 GFP_KERNEL);
151 if (!arizona_gpio)
152 return -ENOMEM;
153
154 arizona_gpio->arizona = arizona;
155 arizona_gpio->gpio_chip = template_chip;
156 arizona_gpio->gpio_chip.parent = &pdev->dev;
157 #ifdef CONFIG_OF_GPIO
158 arizona_gpio->gpio_chip.of_node = arizona->dev->of_node;
159 #endif
160
161 switch (arizona->type) {
162 case WM5102:
163 case WM5110:
164 case WM8280:
165 case WM8997:
166 case WM8998:
167 case WM1814:
168 arizona_gpio->gpio_chip.ngpio = 5;
169 break;
170 case WM1831:
171 case CS47L24:
172 arizona_gpio->gpio_chip.ngpio = 2;
173 break;
174 default:
175 dev_err(&pdev->dev, "Unknown chip variant %d\n",
176 arizona->type);
177 return -EINVAL;
178 }
179
180 if (pdata && pdata->gpio_base)
181 arizona_gpio->gpio_chip.base = pdata->gpio_base;
182 else
183 arizona_gpio->gpio_chip.base = -1;
184
> 185 pm_runtime_enable(&pdev->dev);
186
187 ret = devm_gpiochip_add_data(&pdev->dev, &arizona_gpio->gpio_chip,
188 arizona_gpio);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27784 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] gpio: arizona: Add support for GPIOs that need to be maintained
From: kbuild test robot @ 2017-04-08 3:41 UTC (permalink / raw)
To: Charles Keepax
Cc: kbuild-all-JC7UmRfGjtg, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, gnurou-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E
In-Reply-To: <1491568725-14882-2-git-send-email-ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 9491 bytes --]
Hi Charles,
[auto build test ERROR on gpio/for-next]
[also build test ERROR on v4.11-rc5 next-20170407]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Charles-Keepax/mfd-arizona-Add-GPIO-maintain-state-flag/20170408-111119
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next
config: x86_64-randconfig-x003-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
drivers//gpio/gpio-arizona.c: In function 'arizona_gpio_direction_in':
drivers//gpio/gpio-arizona.c:44:3: error: implicit declaration of function 'pm_runtime_mark_last_busy' [-Werror=implicit-function-declaration]
pm_runtime_mark_last_busy(chip->parent);
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers//gpio/gpio-arizona.c:45:3: error: implicit declaration of function 'pm_runtime_put_autosuspend' [-Werror=implicit-function-declaration]
pm_runtime_put_autosuspend(chip->parent);
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers//gpio/gpio-arizona.c: In function 'arizona_gpio_set':
drivers//gpio/gpio-arizona.c:93:9: error: implicit declaration of function 'pm_runtime_get_sync' [-Werror=implicit-function-declaration]
ret = pm_runtime_get_sync(chip->parent);
^~~~~~~~~~~~~~~~~~~
drivers//gpio/gpio-arizona.c:96:11: warning: 'return' with a value, in function returning void
return ret;
^~~
drivers//gpio/gpio-arizona.c:82:13: note: declared here
static void arizona_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
^~~~~~~~~~~~~~~~
In file included from include/linux/linkage.h:4:0,
from include/linux/kernel.h:6,
from drivers//gpio/gpio-arizona.c:15:
drivers//gpio/gpio-arizona.c: In function 'arizona_gpio_of_xlate':
>> drivers//gpio/gpio-arizona.c:115:33: error: 'struct gpio_chip' has no member named 'of_gpio_n_cells'
if (gpiospec->args_count < chip->of_gpio_n_cells)
^
include/linux/compiler.h:160:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers//gpio/gpio-arizona.c:115:2: note: in expansion of macro 'if'
if (gpiospec->args_count < chip->of_gpio_n_cells)
^~
>> drivers//gpio/gpio-arizona.c:115:33: error: 'struct gpio_chip' has no member named 'of_gpio_n_cells'
if (gpiospec->args_count < chip->of_gpio_n_cells)
^
include/linux/compiler.h:160:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers//gpio/gpio-arizona.c:115:2: note: in expansion of macro 'if'
if (gpiospec->args_count < chip->of_gpio_n_cells)
^~
>> drivers//gpio/gpio-arizona.c:115:33: error: 'struct gpio_chip' has no member named 'of_gpio_n_cells'
if (gpiospec->args_count < chip->of_gpio_n_cells)
^
include/linux/compiler.h:171:16: note: in definition of macro '__trace_if'
______r = !!(cond); \
^~~~
>> drivers//gpio/gpio-arizona.c:115:2: note: in expansion of macro 'if'
if (gpiospec->args_count < chip->of_gpio_n_cells)
^~
drivers//gpio/gpio-arizona.c: At top level:
>> drivers//gpio/gpio-arizona.c:138:2: error: unknown field 'of_xlate' specified in initializer
.of_xlate = arizona_gpio_of_xlate,
^
>> drivers//gpio/gpio-arizona.c:138:15: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.of_xlate = arizona_gpio_of_xlate,
^~~~~~~~~~~~~~~~~~~~~
drivers//gpio/gpio-arizona.c:138:15: note: (near initialization for 'template_chip.read_reg')
>> drivers//gpio/gpio-arizona.c:139:2: error: unknown field 'of_gpio_n_cells' specified in initializer
.of_gpio_n_cells = 2,
^
>> drivers//gpio/gpio-arizona.c:139:21: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
.of_gpio_n_cells = 2,
^
drivers//gpio/gpio-arizona.c:139:21: note: (near initialization for 'template_chip.write_reg')
drivers//gpio/gpio-arizona.c: In function 'arizona_gpio_probe':
drivers//gpio/gpio-arizona.c:185:2: error: implicit declaration of function 'pm_runtime_enable' [-Werror=implicit-function-declaration]
pm_runtime_enable(&pdev->dev);
^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +115 drivers//gpio/gpio-arizona.c
9 * under the terms of the GNU General Public License as published by the
10 * Free Software Foundation; either version 2 of the License, or (at your
11 * option) any later version.
12 *
13 */
14
> 15 #include <linux/kernel.h>
16 #include <linux/slab.h>
17 #include <linux/module.h>
18 #include <linux/gpio.h>
19 #include <linux/platform_device.h>
20 #include <linux/seq_file.h>
21
22 #include <linux/mfd/arizona/core.h>
23 #include <linux/mfd/arizona/pdata.h>
24 #include <linux/mfd/arizona/registers.h>
25
26 #define ARIZONA_GP_STATE_OUTPUT 0x00000001
27
28 struct arizona_gpio {
29 struct arizona *arizona;
30 struct gpio_chip gpio_chip;
31 int status[ARIZONA_MAX_GPIO];
32 };
33
34 static int arizona_gpio_direction_in(struct gpio_chip *chip, unsigned offset)
35 {
36 struct arizona_gpio *arizona_gpio = gpiochip_get_data(chip);
37 struct arizona *arizona = arizona_gpio->arizona;
38 int status = arizona_gpio->status[offset];
39
40 status &= (ARIZONA_GP_MAINTAIN | ARIZONA_GP_STATE_OUTPUT);
41 if (status == (ARIZONA_GP_MAINTAIN | ARIZONA_GP_STATE_OUTPUT)) {
42 arizona_gpio->status[offset] &= ~ARIZONA_GP_STATE_OUTPUT;
43
44 pm_runtime_mark_last_busy(chip->parent);
45 pm_runtime_put_autosuspend(chip->parent);
46 }
47
48 return regmap_update_bits(arizona->regmap, ARIZONA_GPIO1_CTRL + offset,
49 ARIZONA_GPN_DIR, ARIZONA_GPN_DIR);
50 }
51
52 static int arizona_gpio_get(struct gpio_chip *chip, unsigned offset)
53 {
54 struct arizona_gpio *arizona_gpio = gpiochip_get_data(chip);
55 struct arizona *arizona = arizona_gpio->arizona;
56 unsigned int val;
57 int ret;
58
59 ret = regmap_read(arizona->regmap, ARIZONA_GPIO1_CTRL + offset, &val);
60 if (ret < 0)
61 return ret;
62
63 if (val & ARIZONA_GPN_LVL)
64 return 1;
65 else
66 return 0;
67 }
68
69 static int arizona_gpio_direction_out(struct gpio_chip *chip,
70 unsigned offset, int value)
71 {
72 struct arizona_gpio *arizona_gpio = gpiochip_get_data(chip);
73 struct arizona *arizona = arizona_gpio->arizona;
74
75 if (value)
76 value = ARIZONA_GPN_LVL;
77
78 return regmap_update_bits(arizona->regmap, ARIZONA_GPIO1_CTRL + offset,
79 ARIZONA_GPN_DIR | ARIZONA_GPN_LVL, value);
80 }
81
> 82 static void arizona_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
83 {
84 struct arizona_gpio *arizona_gpio = gpiochip_get_data(chip);
85 struct arizona *arizona = arizona_gpio->arizona;
86 int status = arizona_gpio->status[offset];
87 int ret;
88
89 status &= (ARIZONA_GP_MAINTAIN | ARIZONA_GP_STATE_OUTPUT);
90 if (status == ARIZONA_GP_MAINTAIN) {
91 arizona_gpio->status[offset] |= ARIZONA_GP_STATE_OUTPUT;
92
93 ret = pm_runtime_get_sync(chip->parent);
94 if (ret < 0) {
95 dev_err(chip->parent, "Failed to resume: %d\n", ret);
96 return ret;
97 }
98 }
99
100 if (value)
101 value = ARIZONA_GPN_LVL;
102
103 regmap_update_bits(arizona->regmap, ARIZONA_GPIO1_CTRL + offset,
104 ARIZONA_GPN_LVL, value);
105 }
106
107 static int arizona_gpio_of_xlate(struct gpio_chip *chip,
108 const struct of_phandle_args *gpiospec,
109 u32 *flags)
110 {
111 struct arizona_gpio *arizona_gpio = gpiochip_get_data(chip);
112 u32 offset = gpiospec->args[0];
113 u32 bits = gpiospec->args[1];
114
> 115 if (gpiospec->args_count < chip->of_gpio_n_cells)
116 return -EINVAL;
117
118 if (offset >= chip->ngpio)
119 return -EINVAL;
120
121 if (flags)
122 *flags = bits & ~ARIZONA_GP_MAINTAIN;
123
124 if (bits & ARIZONA_GP_MAINTAIN)
125 arizona_gpio->status[offset] |= ARIZONA_GP_MAINTAIN;
126
127 return offset;
128 }
129
130 static const struct gpio_chip template_chip = {
131 .label = "arizona",
132 .owner = THIS_MODULE,
133 .direction_input = arizona_gpio_direction_in,
134 .get = arizona_gpio_get,
135 .direction_output = arizona_gpio_direction_out,
136 .set = arizona_gpio_set,
137 .can_sleep = true,
> 138 .of_xlate = arizona_gpio_of_xlate,
> 139 .of_gpio_n_cells = 2,
140 };
141
142 static int arizona_gpio_probe(struct platform_device *pdev)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 20332 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/8] v4l: flash led class: Use fwnode_handle instead of device_node in init
From: kbuild test robot @ 2017-04-08 1:59 UTC (permalink / raw)
To: Sakari Ailus
Cc: kbuild-all, linux-media, linux-acpi, devicetree, laurent.pinchart
In-Reply-To: <1491484330-12040-2-git-send-email-sakari.ailus@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2635 bytes --]
Hi Sakari,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.11-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sakari-Ailus/v4l-flash-led-class-Use-fwnode_handle-instead-of-device_node-in-init/20170408-051139
base: git://linuxtv.org/media_tree.git master
config: tile-allmodconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile
Note: the linux-review/Sakari-Ailus/v4l-flash-led-class-Use-fwnode_handle-instead-of-device_node-in-init/20170408-051139 HEAD 86b5e432c352250540fcd89854fa7ad55ba9e749 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/media/v4l2-core/v4l2-flash-led-class.c: In function 'v4l2_flash_init':
>> drivers/media/v4l2-core/v4l2-flash-led-class.c:642:4: error: 'struct v4l2_subdev' has no member named 'fwnode'
drivers/media/v4l2-core/v4l2-flash-led-class.c:642:2: error: implicit declaration of function 'dev_fwnode'
drivers/media/v4l2-core/v4l2-flash-led-class.c:642:25: warning: pointer/integer type mismatch in conditional expression [enabled by default]
drivers/media/v4l2-core/v4l2-flash-led-class.c:658:2: error: implicit declaration of function 'fwnode_handle_get'
drivers/media/v4l2-core/v4l2-flash-led-class.c:658:22: error: 'struct v4l2_subdev' has no member named 'fwnode'
drivers/media/v4l2-core/v4l2-flash-led-class.c:667:22: error: 'struct v4l2_subdev' has no member named 'fwnode'
drivers/media/v4l2-core/v4l2-flash-led-class.c: In function 'v4l2_flash_release':
drivers/media/v4l2-core/v4l2-flash-led-class.c:687:22: error: 'struct v4l2_subdev' has no member named 'fwnode'
cc1: some warnings being treated as errors
vim +642 drivers/media/v4l2-core/v4l2-flash-led-class.c
636
637 sd = &v4l2_flash->sd;
638 v4l2_flash->fled_cdev = fled_cdev;
639 v4l2_flash->iled_cdev = iled_cdev;
640 v4l2_flash->ops = ops;
641 sd->dev = dev;
> 642 sd->fwnode = fwn ? fwn : dev_fwnode(led_cdev->dev);
643 v4l2_subdev_init(sd, &v4l2_flash_subdev_ops);
644 sd->internal_ops = &v4l2_flash_subdev_internal_ops;
645 sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 48035 bytes --]
^ permalink raw reply
* [PATCH v4 10/10] arm64: dts: mediatek: add clk and scp nodes for MT6797
From: Mars Cheng @ 2017-04-08 1:20 UTC (permalink / raw)
To: Stephen Boyd, Matthias Brugger
Cc: CC Hwang, Loda Chou, Miles Chen, Jades Shih, Yingjoe Chen,
Kevin-CW Chen, linux-clk, linux-kernel, linux-mediatek,
devicetree, wsd_upstream, Mars Cheng
In-Reply-To: <1491614435-23754-1-git-send-email-mars.cheng@mediatek.com>
This adds clk and scp nodes for MT6797
Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt6797.dtsi | 71 ++++++++++++++++++++++++++++--
1 file changed, 67 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
index cf4529e..3512c8e 100644
--- a/arch/arm64/boot/dts/mediatek/mt6797.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
@@ -11,6 +11,8 @@
* GNU General Public License for more details.
*/
+#include <dt-bindings/clock/mt6797-clk.h>
+#include <dt-bindings/power/mt6797-power.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -123,6 +125,35 @@
<GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
};
+ topckgen: topckgen@10000000 {
+ compatible = "mediatek,mt6797-topckgen";
+ reg = <0 0x10000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ infrasys: infracfg_ao@10001000 {
+ compatible = "mediatek,mt6797-infracfg", "syscon";
+ reg = <0 0x10001000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ scpsys: scpsys@10006000 {
+ compatible = "mediatek,mt6797-scpsys";
+ #power-domain-cells = <1>;
+ reg = <0 0x10006000 0 0x1000>;
+ clocks = <&topckgen CLK_TOP_MUX_MFG>,
+ <&topckgen CLK_TOP_MUX_MM>,
+ <&topckgen CLK_TOP_MUX_VDEC>;
+ clock-names = "mfg", "mm", "vdec";
+ infracfg = <&infrasys>;
+ };
+
+ apmixedsys: apmixed@1000c000 {
+ compatible = "mediatek,mt6797-apmixedsys";
+ reg = <0 0x1000c000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
sysirq: intpol-controller@10200620 {
compatible = "mediatek,mt6797-sysirq",
"mediatek,mt6577-sysirq";
@@ -138,7 +169,9 @@
"mediatek,mt6577-uart";
reg = <0 0x11002000 0 0x400>;
interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&clk26m>;
+ clocks = <&infrasys CLK_INFRA_UART0>,
+ <&infrasys CLK_INFRA_AP_DMA>;
+ clock-names = "baud", "bus";
status = "disabled";
};
@@ -147,7 +180,9 @@
"mediatek,mt6577-uart";
reg = <0 0x11003000 0 0x400>;
interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&clk26m>;
+ clocks = <&infrasys CLK_INFRA_UART1>,
+ <&infrasys CLK_INFRA_AP_DMA>;
+ clock-names = "baud", "bus";
status = "disabled";
};
@@ -156,7 +191,9 @@
"mediatek,mt6577-uart";
reg = <0 0x11004000 0 0x400>;
interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&clk26m>;
+ clocks = <&infrasys CLK_INFRA_UART2>,
+ <&infrasys CLK_INFRA_AP_DMA>;
+ clock-names = "baud", "bus";
status = "disabled";
};
@@ -165,10 +202,36 @@
"mediatek,mt6577-uart";
reg = <0 0x11005000 0 0x400>;
interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&clk26m>;
+ clocks = <&infrasys CLK_INFRA_UART3>,
+ <&infrasys CLK_INFRA_AP_DMA>;
+ clock-names = "baud", "bus";
status = "disabled";
};
+ mmsys: mmsys_config@14000000 {
+ compatible = "mediatek,mt6797-mmsys", "syscon";
+ reg = <0 0x14000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ imgsys: imgsys_config@15000000 {
+ compatible = "mediatek,mt6797-imgsys", "syscon";
+ reg = <0 0x15000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ vdecsys: vdec_gcon@16000000 {
+ compatible = "mediatek,mt6797-vdecsys", "syscon";
+ reg = <0 0x16000000 0 0x10000>;
+ #clock-cells = <1>;
+ };
+
+ vencsys: venc_gcon@17000000 {
+ compatible = "mediatek,mt6797-vencsys", "syscon";
+ reg = <0 0x17000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
gic: interrupt-controller@19000000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 09/10] soc: mediatek: add MT6797 scpsys support
From: Mars Cheng @ 2017-04-08 1:20 UTC (permalink / raw)
To: Stephen Boyd, Matthias Brugger
Cc: CC Hwang, Loda Chou, Miles Chen, Jades Shih, Yingjoe Chen,
Kevin-CW Chen, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
wsd_upstream-NuS5LvNUpcJWk0Htik3J/w, Mars Cheng
In-Reply-To: <1491614435-23754-1-git-send-email-mars.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
This adds scpsys support for MT6797
Signed-off-by: Mars Cheng <mars.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Signed-off-by: Kevin-CW Chen <kevin-cw.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/soc/mediatek/mtk-scpsys.c | 114 ++++++++++++++++++++++++++++++
include/dt-bindings/power/mt6797-power.h | 30 ++++++++
2 files changed, 144 insertions(+)
create mode 100644 include/dt-bindings/power/mt6797-power.h
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index a8ba800..ceb2cc4 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -21,6 +21,7 @@
#include <linux/soc/mediatek/infracfg.h>
#include <dt-bindings/power/mt2701-power.h>
+#include <dt-bindings/power/mt6797-power.h>
#include <dt-bindings/power/mt8173-power.h>
#define SPM_VDE_PWR_CON 0x0210
@@ -585,6 +586,116 @@ static int __init scpsys_probe_mt2701(struct platform_device *pdev)
}
/*
+ * MT6797 power domain support
+ */
+
+static const struct scp_domain_data scp_domain_data_mt6797[] = {
+ [MT6797_POWER_DOMAIN_VDEC] = {
+ .name = "vdec",
+ .sta_mask = BIT(7),
+ .ctl_offs = 0x300,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ .clk_id = {CLK_VDEC},
+ },
+ [MT6797_POWER_DOMAIN_VENC] = {
+ .name = "venc",
+ .sta_mask = BIT(21),
+ .ctl_offs = 0x304,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(15, 12),
+ .clk_id = {CLK_NONE},
+ },
+ [MT6797_POWER_DOMAIN_ISP] = {
+ .name = "isp",
+ .sta_mask = BIT(5),
+ .ctl_offs = 0x308,
+ .sram_pdn_bits = GENMASK(9, 8),
+ .sram_pdn_ack_bits = GENMASK(13, 12),
+ .clk_id = {CLK_NONE},
+ },
+ [MT6797_POWER_DOMAIN_MM] = {
+ .name = "mm",
+ .sta_mask = BIT(3),
+ .ctl_offs = 0x30C,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ .clk_id = {CLK_MM},
+ .bus_prot_mask = (BIT(1) | BIT(2)),
+ },
+ [MT6797_POWER_DOMAIN_AUDIO] = {
+ .name = "audio",
+ .sta_mask = BIT(24),
+ .ctl_offs = 0x314,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(15, 12),
+ .clk_id = {CLK_NONE},
+ },
+ [MT6797_POWER_DOMAIN_MFG_ASYNC] = {
+ .name = "mfg_async",
+ .sta_mask = BIT(13),
+ .ctl_offs = 0x334,
+ .sram_pdn_bits = 0,
+ .sram_pdn_ack_bits = 0,
+ .clk_id = {CLK_MFG},
+ },
+ [MT6797_POWER_DOMAIN_MJC] = {
+ .name = "mjc",
+ .sta_mask = BIT(20),
+ .ctl_offs = 0x310,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ .clk_id = {CLK_NONE},
+ },
+};
+
+#define NUM_DOMAINS_MT6797 ARRAY_SIZE(scp_domain_data_mt6797)
+#define SPM_PWR_STATUS_MT6797 0x0180
+#define SPM_PWR_STATUS_2ND_MT6797 0x0184
+
+static int __init scpsys_probe_mt6797(struct platform_device *pdev)
+{
+ struct scp *scp;
+ struct genpd_onecell_data *pd_data;
+ int ret;
+ struct scp_ctrl_reg scp_reg;
+
+ scp_reg.pwr_sta_offs = SPM_PWR_STATUS_MT6797;
+ scp_reg.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND_MT6797;
+
+ scp = init_scp(pdev, scp_domain_data_mt6797, NUM_DOMAINS_MT6797,
+ &scp_reg);
+ if (IS_ERR(scp))
+ return PTR_ERR(scp);
+
+ mtk_register_power_domains(pdev, scp, NUM_DOMAINS_MT6797);
+
+ pd_data = &scp->pd_data;
+
+ ret = pm_genpd_add_subdomain(pd_data->domains[MT6797_POWER_DOMAIN_MM],
+ pd_data->domains[MT6797_POWER_DOMAIN_VDEC]);
+ if (ret && IS_ENABLED(CONFIG_PM))
+ dev_err(&pdev->dev, "Failed to add subdomain: %d\n", ret);
+
+ ret = pm_genpd_add_subdomain(pd_data->domains[MT6797_POWER_DOMAIN_MM],
+ pd_data->domains[MT6797_POWER_DOMAIN_ISP]);
+ if (ret && IS_ENABLED(CONFIG_PM))
+ dev_err(&pdev->dev, "Failed to add subdomain: %d\n", ret);
+
+ ret = pm_genpd_add_subdomain(pd_data->domains[MT6797_POWER_DOMAIN_MM],
+ pd_data->domains[MT6797_POWER_DOMAIN_VENC]);
+ if (ret && IS_ENABLED(CONFIG_PM))
+ dev_err(&pdev->dev, "Failed to add subdomain: %d\n", ret);
+
+ ret = pm_genpd_add_subdomain(pd_data->domains[MT6797_POWER_DOMAIN_MM],
+ pd_data->domains[MT6797_POWER_DOMAIN_MJC]);
+ if (ret && IS_ENABLED(CONFIG_PM))
+ dev_err(&pdev->dev, "Failed to add subdomain: %d\n", ret);
+
+ return 0;
+}
+
+/*
* MT8173 power domain support
*/
@@ -721,6 +832,9 @@ static int __init scpsys_probe_mt8173(struct platform_device *pdev)
.compatible = "mediatek,mt2701-scpsys",
.data = scpsys_probe_mt2701,
}, {
+ .compatible = "mediatek,mt6797-scpsys",
+ .data = scpsys_probe_mt6797,
+ }, {
.compatible = "mediatek,mt8173-scpsys",
.data = scpsys_probe_mt8173,
}, {
diff --git a/include/dt-bindings/power/mt6797-power.h b/include/dt-bindings/power/mt6797-power.h
new file mode 100644
index 0000000..d54b377
--- /dev/null
+++ b/include/dt-bindings/power/mt6797-power.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Mars.C <mars.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_POWER_MT6797_POWER_H
+#define _DT_BINDINGS_POWER_MT6797_POWER_H
+
+#define MT6797_POWER_DOMAIN_VDEC 0
+#define MT6797_POWER_DOMAIN_VENC 1
+#define MT6797_POWER_DOMAIN_ISP 2
+#define MT6797_POWER_DOMAIN_MM 3
+#define MT6797_POWER_DOMAIN_AUDIO 4
+#define MT6797_POWER_DOMAIN_MFG_ASYNC 5
+#define MT6797_POWER_DOMAIN_MFG 6
+#define MT6797_POWER_DOMAIN_MFG_CORE0 7
+#define MT6797_POWER_DOMAIN_MFG_CORE1 8
+#define MT6797_POWER_DOMAIN_MFG_CORE2 9
+#define MT6797_POWER_DOMAIN_MFG_CORE3 10
+#define MT6797_POWER_DOMAIN_MJC 11
+
+#endif /* _DT_BINDINGS_POWER_MT6797_POWER_H */
--
1.7.9.5
--
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 v4 08/10] dt-bindings: mediatek: add MT6797 power dt-bindings
From: Mars Cheng @ 2017-04-08 1:20 UTC (permalink / raw)
To: Stephen Boyd, Matthias Brugger
Cc: CC Hwang, Loda Chou, Miles Chen, Jades Shih, Yingjoe Chen,
Kevin-CW Chen, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
wsd_upstream-NuS5LvNUpcJWk0Htik3J/w, Mars Cheng
In-Reply-To: <1491614435-23754-1-git-send-email-mars.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
This adds power dt-bindings for MT6797
Signed-off-by: Mars Cheng <mars.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Signed-off-by: Kevin-CW Chen <kevin-cw.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
.../devicetree/bindings/soc/mediatek/scpsys.txt | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
index 16fe94d..b1d165b 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -9,11 +9,14 @@ domain control.
The driver implements the Generic PM domain bindings described in
power/power_domain.txt. It provides the power domains defined in
-include/dt-bindings/power/mt8173-power.h and mt2701-power.h.
+- include/dt-bindings/power/mt8173-power.h
+- include/dt-bindings/power/mt6797-power.h
+- include/dt-bindings/power/mt2701-power.h
Required properties:
- compatible: Should be one of:
- "mediatek,mt2701-scpsys"
+ - "mediatek,mt6797-scpsys"
- "mediatek,mt8173-scpsys"
- #power-domain-cells: Must be 1
- reg: Address range of the SCPSYS unit
@@ -22,6 +25,7 @@ Required properties:
These are clocks which hardware needs to be
enabled before enabling certain power domains.
Required clocks for MT2701: "mm", "mfg", "ethif"
+ Required clocks for MT6797: "mm", "mfg", "vdec"
Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt"
Optional properties:
--
1.7.9.5
--
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 v4 07/10] soc: mediatek: add vdec item for scpsys
From: Mars Cheng @ 2017-04-08 1:20 UTC (permalink / raw)
To: Stephen Boyd, Matthias Brugger
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, CC Hwang,
wsd_upstream-NuS5LvNUpcJWk0Htik3J/w, Mars Cheng, Loda Chou,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jades Shih, Miles Chen,
Kevin-CW Chen, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Yingjoe Chen, linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491614435-23754-1-git-send-email-mars.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
for some chips, there is vdec item in scpsys, this patch adds it.
Signed-off-by: Mars Cheng <mars.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/soc/mediatek/mtk-scpsys.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index eadbf0d..a8ba800 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -71,6 +71,7 @@ enum clk_id {
CLK_VENC,
CLK_VENC_LT,
CLK_ETHIF,
+ CLK_VDEC,
CLK_MAX,
};
@@ -81,6 +82,7 @@ enum clk_id {
"venc",
"venc_lt",
"ethif",
+ "vdec",
NULL,
};
--
1.7.9.5
^ 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