* Re: [PATCH v1 0/8] clk: meson: gxbb: more clock controller update for audio support
From: Neil Armstrong @ 2017-03-30 8:15 UTC (permalink / raw)
To: Michael Turquette, Jerome Brunet, Stephen Boyd, Kevin Hilman,
Carlo Caione
Cc: linux-clk, linux-amlogic, linux-kernel, devicetree
In-Reply-To: <149082017390.31513.12254031076684821992@resonance>
On 03/29/2017 10:42 PM, Michael Turquette wrote:
> Hi Jerome,
>
> Adding Neil Armstong to Cc.
>
> Quoting Jerome Brunet (2017-03-28 07:45:57)
>> The patchset is the 2nd round of update to the meson gxbb clock controller
>> to add initial audio support. The patchset is based on clk-next.
>>
>> There is not much out of the ordinary here (adding new clocks and exposing
>> them) except maybe for 2 patches:
>> Patch #2: Adds a safety check while registering clocks to protect against
>> holes in clk_hw_onecell_data, if it ever happens. Same thing is
>> done for the meson8b clock controller.
>> Patch #3: Adds a new clock divider driver to implement the necessary
>> policy for the i2s master clock (see patch changelog)
>>
>> This patchset has been test on the gxbb p200 and gxl p230.
>
> First off, this series looks fine to me. Please add,
>
> Acked-by: Michael Turquette <mturquette@baylibre.com>
>
> Secondly, it seems the AmLogic clock drivers have mostly calmed down and
> things are in the "add new clocks when we need them" phase, which is
> nice. Since you and Neil are doing a lot of this work, might I suggest
> that you both start collecting patches for the AmLogic/meson clock
> drivers begin submitting pull requests to Stephen and myself?
>
> As usual the rules are the same as always: all patches in the PR must
> first be posted for review on the list. PRs should correspond to signed
> tags. Stephen and I might ignore PRs sent after -rc4, and will
> definitely ignore PRs sent after -rc6 since we want some stabilization
> time before the merge window. Base your branch on -rc1, not on clk-next.
>
> Also feel free to submit a patch to MAINTAINERS with either one or both
> of you maintaining the meson clk stuff, assuming that you're OK to
> review all of those patches and collect them into a PR.
>
> Thoughts?
Thanks Mike, I'll be glad to co-maintain this with jerome !
Neil
>
> If it sounds good to you then I suggest grabbing the clk-meson branch
> from the clk tree and using that as a baseline for your first PR. In the
> future you'll just Linus' -rc1, but I have already created a branch for
> this cycle. You can apply these 8 patches with my Ack and send a PR by
> -rc6 (possibly with other stuff collected from Martin, etc).
Acked !
>
> Thanks,
> Mike
>
>>
>> Jerome Brunet (8):
>> dt-bindings: clock: gxbb: expose spdif clock gates
>> clk: meson: gxbb: protect against holes in the onecell_data array
>> clk: meson: add audio clock divider support
>> clk: meson: gxbb: add cts_amclk
>> clk: meson: gxbb: add cts_mclk_i958
>> clk: meson: gxbb: add cts_i958 clock
>> dt-bindings: clock: gxbb: expose i2s master clock
>> dt-bindings: clock: gxbb: expose spdif master clock
>>
>> drivers/clk/meson/Makefile | 2 +-
>> drivers/clk/meson/clk-audio-divider.c | 149 ++++++++++++++++++++++++++++++++++
>> drivers/clk/meson/clkc.h | 10 +++
>> drivers/clk/meson/gxbb.c | 144 ++++++++++++++++++++++++++++++++
>> drivers/clk/meson/gxbb.h | 13 ++-
>> include/dt-bindings/clock/gxbb-clkc.h | 5 ++
>> 6 files changed, 319 insertions(+), 4 deletions(-)
>> create mode 100644 drivers/clk/meson/clk-audio-divider.c
>>
>> --
>> 2.9.3
>>
^ permalink raw reply
* Re: [PATCH v3 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header
From: Linus Walleij @ 2017-03-30 8:15 UTC (permalink / raw)
To: Chris Brandt
Cc: Jacopo Mondi, Bjorn Andersson, Geert Uytterhoeven,
Laurent Pinchart, Rob Herring, Mark Rutland, Russell King,
Linux-Renesas, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <SG2PR06MB11659AB956F83E8DCE2C9AA18A350@SG2PR06MB1165.apcprd06.prod.outlook.com>
On Wed, Mar 29, 2017 at 4:55 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Wednesday, March 29, 2017, Linus Walleij wrote:
>> On Fri, Mar 24, 2017 at 4:22 PM, Jacopo Mondi <jacopo+renesas@jmondi.org>
>> wrote:
>>
>> > Add dt-bindings for Renesas r7s72100 pin controller header file.
>> >
>> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>>
>> > +/*
>> > + * Pin is bi-directional.
>> > + * An alternate function that needs both input/output functionalities
>> > +shall
>> > + * be configured as bidirectional.
>> > + * Eg. SDA/SCL pins of an I2c interface.
>> > + */
>> > +#define BI_DIR (1 << 3)
>>
>> Any specific reason why this should not simply be added to
>> include/linux/pinctrl/pinconf-generic.h
>> as PIN_CONFIG_BIDIRECTIONAL and parsed in drivers/pinctrl/pinconf-
>> generic.c from the (new) DT property "bidirectional" simply?
>
> I see your point. It would cut down from every driver out there
> inventing some new property or config instead of everyone just sharing
> a fixed set.
> Maybe someone else out there will end up having a need for a
> "bidirectional" option.
I was thinking about that one. It is a bit weird electrically, like what
kind of electronics is really bidirectional?
It seems like a fancy name for open drain/open source, what we
call "single ended" configuration. (See docs in
Documentation/gpio/driver.txt)
It would be great if you could check if that is what they mean,
actually.
> But, what do we do for Ethernet? All the pins are "normal" except just
> the MDIO pin needs to be bidirectional.
I see Geert clarified what we could do here.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v12 00/10] mux controller abstraction and iio/i2c muxes
From: Greg Kroah-Hartman @ 2017-03-30 8:09 UTC (permalink / raw)
To: Peter Rosin
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, linux-i2c, devicetree, linux-kernel, linux-iio,
linux-doc, Andrew Morton, Colin Ian King, Paul Gortmaker
In-Reply-To: <c321dad0-4c0e-b192-ee93-45359e29f61b@axentia.se>
On Thu, Mar 30, 2017 at 09:34:52AM +0200, Peter Rosin wrote:
> On 2017-03-27 16:21, Peter Rosin wrote:
> > Hi Greg!
> >
> > Please apply.
> >
>
> *snip snip*
>
> > v10 -> v11 changes
> > - added a new patch (12) with a fix for messed up error path reported
> > by Paul Gortmaker.
>
> Oops, should be Dan Carpenter. Sorry about that...
>
> And, I forgot to high-light this:
>
> > v4 -> v5 changes
> > - driver for Analog Devices ADG792A/G, literally the first mux chip
> > I found on the Internet with an i2c interface (that was not a
> > dedicated i2c multiplexer like PCA9547) which I used to verify
> > that the abstractions in the mux core are up to the task. Untested,
> > just proof of concept that at least looks pretty and compiles...
>
> Maybe the patches related to adg792 (last two patches in v12) should
> not be applied? I don't care much either way, your call Greg...
Give me a chance to catch up on reviews, your patch series is behind
400+ other emails...
greg k-h
^ permalink raw reply
* [PATCH 1/5 v3] iio: xoadc: augment DT bindings a bit
From: Linus Walleij @ 2017-03-30 8:05 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA, Rob Herring
Cc: Linus Walleij, devicetree-u79uwXL29TY76Z2rM5mHXA
In order to accommodate in a logical manner for the premuxed channels
in PM8921 and the similarly addressed channels in later PMICs, we
need a twocell arrangement with premux and analog mux setting as
a tuple to uniquely identify a hardware channel.
These bindings are not yet in use, so it should be fine to augment
them before we actually start using it in drivers and device trees.
This scheme came out of lengthy discussions and reverse-engineering
and reading of the few information sources we have.
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Suggested-by: Björn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
ChangeLog v2->v3:
- Drop leading zeroes on unit addresses.
ChangeLog v1->v2:
- Name nodes with <01 02> in a foo@0102 pattern.
- Minor spelling nits.
- Delete flimsy leftover docs from an interrim development path.
---
.../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 76 ++++++++++++----------
1 file changed, 42 insertions(+), 34 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
index 53cd146d8096..69c404112df1 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
@@ -19,32 +19,42 @@ Required properties:
with PMIC variant but is typically something like 2.2 or 1.8V.
The following required properties are standard for IO channels, see
-iio-bindings.txt for more details:
+iio-bindings.txt for more details, but noitice that this particular
+ADC has a special adressing scheme that require two cells for
+identifying each ADC channel:
-- #address-cells: should be set to <1>
+- #address-cells: should be set to <2>, the first cell is the
+ prescaler (on PM8058) or premux (on PM8921) with two valid bits
+ so legal values are 0x00, 0x01 or 0x02. The second cell
+ is the main analog mux setting (0x00..0x0f). The combination
+ of prescaler/premux and analog mux uniquely addresses a hardware
+ channel on all systems.
- #size-cells: should be set to <0>
-- #io-channel-cells: should be set to <1>
+- #io-channel-cells: should be set to <2>, again the cells are
+ precaler or premux followed by the analog muxing line.
- interrupts: should refer to the parent PMIC interrupt controller
and reference the proper ADC interrupt.
Required subnodes:
-The ADC channels are configured as subnodes of the ADC. Since some of
-them are used for calibrating the ADC, these nodes are compulsory:
+The ADC channels are configured as subnodes of the ADC.
+
+Since some of them are used for calibrating the ADC, these nodes are
+compulsory:
adc-channel@c {
- reg = <0x0c>;
+ reg = <0x00 0x0c>;
};
adc-channel@d {
- reg = <0x0d>;
+ reg = <0x00 0x0d>;
};
adc-channel@f {
- reg = <0x0f>;
+ reg = <0x00 0x0f>;
};
These three nodes are used for absolute and ratiometric calibration
@@ -52,13 +62,13 @@ and only need to have these reg values: they are by hardware definition
1:1 ratio converters that sample 625, 1250 and 0 milliV and create
an interpolation calibration for all other ADCs.
-Optional subnodes: any channels other than channel 0x0c, 0x0d and
-0x0f are optional.
+Optional subnodes: any channels other than channels [0x00 0x0c],
+[0x00 0x0d] and [0x00 0x0f] are optional.
Required channel node properties:
- reg: should contain the hardware channel number in the range
- 0 .. 0x0f (4 bits). The hardware only supports 16 channels.
+ 0 .. 0xff (8 bits).
Optional channel node properties:
@@ -94,56 +104,54 @@ Example:
xoadc: xoadc@197 {
compatible = "qcom,pm8058-adc";
reg = <0x197>;
- interrupt-parent = <&pm8058>;
- interrupts = <76 1>;
- #address-cells = <1>;
+ interrupts-extended = <&pm8058 76 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <2>;
#size-cells = <0>;
- #io-channel-cells = <1>;
+ #io-channel-cells = <2>;
vcoin: adc-channel@0 {
- reg = <0x00>;
+ reg = <0x00 0x00>;
};
vbat: adc-channel@1 {
- reg = <0x01>;
+ reg = <0x00 0x01>;
};
dcin: adc-channel@2 {
- reg = <0x02>;
+ reg = <0x00 0x02>;
};
ichg: adc-channel@3 {
- reg = <0x03>;
+ reg = <0x00 0x03>;
};
vph_pwr: adc-channel@4 {
- reg = <0x04>;
+ reg = <0x00 0x04>;
};
usb_vbus: adc-channel@a {
- reg = <0x0a>;
+ reg = <0x00 0x0a>;
};
die_temp: adc-channel@b {
- reg = <0x0b>;
+ reg = <0x00 0x0b>;
};
ref_625mv: adc-channel@c {
- reg = <0x0c>;
+ reg = <0x00 0x0c>;
};
ref_1250mv: adc-channel@d {
- reg = <0x0d>;
+ reg = <0x00 0x0d>;
};
ref_325mv: adc-channel@e {
- reg = <0x0e>;
+ reg = <0x00 0x0e>;
};
ref_muxoff: adc-channel@f {
- reg = <0x0f>;
+ reg = <0x00 0x0f>;
};
};
-
/* IIO client node */
iio-hwmon {
compatible = "iio-hwmon";
- io-channels = <&xoadc 0x01>, /* Battery */
- <&xoadc 0x02>, /* DC in (charger) */
- <&xoadc 0x04>, /* VPH the main system voltage */
- <&xoadc 0x0b>, /* Die temperature */
- <&xoadc 0x0c>, /* Reference voltage 1.25V */
- <&xoadc 0x0d>, /* Reference voltage 0.625V */
- <&xoadc 0x0e>; /* Reference voltage 0.325V */
+ io-channels = <&xoadc 0x00 0x01>, /* Battery */
+ <&xoadc 0x00 0x02>, /* DC in (charger) */
+ <&xoadc 0x00 0x04>, /* VPH the main system voltage */
+ <&xoadc 0x00 0x0b>, /* Die temperature */
+ <&xoadc 0x00 0x0c>, /* Reference voltage 1.25V */
+ <&xoadc 0x00 0x0d>, /* Reference voltage 0.625V */
+ <&xoadc 0x00 0x0e>; /* Reference voltage 0.325V */
};
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 2/4] ARM: dts: rockchip: add ARM Mali GPU node for rk3288
From: Enric Balletbo i Serra @ 2017-03-30 8:03 UTC (permalink / raw)
To: Guillaume Tucker, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Sjoerd Simons, John Reitan
In-Reply-To: <46d14d3c969a35e800b1c06da0ddb652986e6827.1490789802.git.guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On 29/03/17 14:44, Guillaume Tucker wrote:
> Add Mali GPU device tree node for the rk3288 SoC, with devfreq
> opp table.
>
> Signed-off-by: Guillaume Tucker <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> ---
> arch/arm/boot/dts/rk3288.dtsi | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index df8a0dbe9d91..213224ea309e 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -43,6 +43,7 @@
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/pinctrl/rockchip.h>
> #include <dt-bindings/clock/rk3288-cru.h>
> +#include <dt-bindings/power/rk3288-power.h>
> #include <dt-bindings/thermal/thermal.h>
> #include <dt-bindings/power/rk3288-power.h>
> #include <dt-bindings/soc/rockchip,boot-mode.h>
> @@ -227,6 +228,28 @@
> ports = <&vopl_out>, <&vopb_out>;
> };
>
> + gpu: mali@ffa30000 {
> + compatible = "arm,mali-midgard";
> + reg = <0xffa30000 0x10000>;
> + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "JOB", "MMU", "GPU";
> + clocks = <&cru ACLK_GPU>;
> + clock-names = "clk_mali";
> + operating-points = <
> + /* KHz uV */
> + 100000 950000
> + 200000 950000
> + 300000 1000000
> + 400000 1100000
> + 500000 1200000
> + 600000 1250000
> + >;
> + power-domains = <&power RK3288_PD_GPU>;
> + status = "disabled";
> + };
> +
> sdmmc: dwmmc@ff0c0000 {
> compatible = "rockchip,rk3288-dw-mshc";
> max-frequency = <150000000>;
>
This works on a veyron-minnie and a veyron-jerry, so
Tested-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Enric Balletbo i Serra @ 2017-03-30 8:00 UTC (permalink / raw)
To: Guillaume Tucker, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Sjoerd Simons, John Reitan
In-Reply-To: <db45d0d68957d699f13a0d92f4f84d8ebfd0270e.1490789802.git.guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On 29/03/17 14:44, Guillaume Tucker wrote:
> The ARM Mali Midgard GPU family is present in a number of SoCs
> from many different vendors such as Samsung Exynos and Rockchip.
>
> Import the device tree bindings documentation from the r16p0
> release of the Mali Midgard GPU kernel driver:
>
> https://developer.arm.com/-/media/Files/downloads/mali-drivers/kernel/mali-midgard-gpu/TX011-SW-99002-r16p0-00rel0.tgz
>
> The following optional bindings have been omitted in this initial
> version as they are only used in very specific cases:
>
> * snoop_enable_smc
> * snoop_disable_smc
> * jm_config
> * power_model
> * system-coherency
> * ipa-model
>
> The example has been simplified accordingly.
>
> The compatible string definition has been limited to
> "arm,mali-midgard" to avoid checkpatch.pl warnings and to match
> what the driver actually expects (as of r16p0 out-of-tree).
>
> CC: John Reitan <john.reitan-5wv7dgnIgG8@public.gmane.org>
> Signed-off-by: Guillaume Tucker <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> ---
> .../devicetree/bindings/gpu/arm,mali-midgard.txt | 53 ++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> new file mode 100644
> index 000000000000..da8fc6d21bbf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> @@ -0,0 +1,53 @@
> +#
> +# (C) COPYRIGHT 2013-2016 ARM Limited.
> +# Copyright (C) 2017 Collabora Ltd
> +#
> +# This program is free software and is provided to you under the terms of the
> +# GNU General Public License version 2 as published by the Free Software
> +# Foundation, and any use by you of this program is subject to the terms
> +# of such GNU licence.
> +#
> +
> +
> +ARM Mali Midgard GPU
> +====================
> +
> +Required properties:
> +
> +- compatible : Should be "arm,mali-midgard".
> +- reg : Physical base address of the device and length of the register area.
> +- interrupts : Contains the three IRQ lines required by Mali Midgard devices.
> +- interrupt-names : Contains the names of IRQ resources in the order they were
> + provided in the interrupts property. Must contain: "JOB, "MMU", "GPU".
> +
> +Optional:
> +
> +- clocks : Phandle to clock for the Mali Midgard device.
> +- clock-names : Shall be "clk_mali".
> +- mali-supply : Phandle to regulator for the Mali device. Refer to
> + Documentation/devicetree/bindings/regulator/regulator.txt for details.
> +- operating-points : Refer to Documentation/devicetree/bindings/power/opp.txt
> + for details.
> +
> +Example for a Mali-T602:
> +
> +gpu@0xfc010000 {
> + compatible = "arm,mali-midgard";
> + reg = <0xfc010000 0x4000>;
> + interrupts = <0 36 4>, <0 37 4>, <0 38 4>;
> + interrupt-names = "JOB", "MMU", "GPU";
> +
> + clocks = <&pclk_mali>;
> + clock-names = "clk_mali";
> + mali-supply = <&vdd_mali>;
> + operating-points = <
> + /* KHz uV */
> + 533000 1250000,
> + 450000 1150000,
> + 400000 1125000,
> + 350000 1075000,
> + 266000 1025000,
> + 160000 925000,
> + 100000 912500,
> + >;
> +};
>
This works with veyron-minnie and veyron-jerry too, so
Tested-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG
From: Pavel Machek @ 2017-03-30 7:43 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Richard Purdie, Jacek Anaszewski, linux-kernel,
linux-leds, linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <20170330000955.GP20094@minitux>
[-- Attachment #1: Type: text/plain, Size: 3143 bytes --]
Hi!
> > > There is a binding for ti,lp55xx, but there's nothing I can reuse from
> > > that binding...because it's completely different hardware.
> >
> > Agreed, if you drop the pattern stuff from the binding, at least for now.
>
> I do not have a strong preference to expose these knobs in devicetree
> and I do fear that finding some common "pattern" bindings that suits
> everyone will be very difficult.
>
> So I'll drop them from the binding for now.
Ok.
> > If you want driver merged quickly, I believe the best way would be to
> > leave out pattern support for now. We can merge the basic driver
> > easily to 4.12.
> >
>
> I'm not that much in a hurry and would rather see that we resolve any
> outstanding issues with the implementation of the pattern handling.
Ok, good.
> But regardless of this we still have the problem that the typical
> Qualcomm PMIC has 8 LPG-blocks and any triple could be driving a
> RGB-LED. So we would have to create some sort of in-driver-wrapper
> around any three instances exposing them as a single LED to the user.
Yes, I believe we should do the wrapping. In N900 case,
> I rather expose the individual channels and make sure that when we
> trigger a blink operation or enable a pattern (i.e. the two operations
> that do require synchronization) we will perform that synchronization
> under the hood.
First, we need a way to tell userspace which LEDs are synchronized,
because otherwise it will be confusing.
Second, there are more issues than just patterns with the RGB
LED. Most important is ability to set particular colors. You want to
set the RGB LED to "white", but that does not mean you can set
red=green=blue=1.0. You want color to look the same on LCD and on the
LED, which means coefficients for white and some kind of function for
brightness-to-PWM conversion.
> > Incremental patches sound like a good idea, yes.
> >
> > I'd say that testing with actual RGB LED is not a requirement... as
> > long as we design reasonable interface where the synchronizaction will
> > be easy.
> >
>
> As this relates to the board layout (which LPG-channels are hooked to a
> RGB) I think it makes sense to expose a mechanism in devicetree to
> indicate which channels should have their pattern/blink synchronized.
>
> We should be able to extend the LUT (the hardware that actually
> implements the pattern-walker logic) with a DT-property like:
>
> qcom,synchronize-group-0 = <1, 2, 3>;
> qcom,synchronize-group-1 = <5, 6, 7>;
>
> And whenever we configure a pattern involving one of the affected LEDs
> from a group we start all of them.
Yes we need some kind of grouping.
Additional complexity in the N900 case... groups can actually be
configured at run time. Original Maemo used that ability to group 6
keyboard backlight leds, and then run pattern on them. OTOH... I don't
think we _need_ to support that functionality.
Best regards,
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: [PATCHv5 11/11] arm: sti: update sti-cec for CEC notifier support
From: Benjamin Gaignard @ 2017-03-30 7:41 UTC (permalink / raw)
To: Hans Verkuil
Cc: devicetree, moderated list:ARM/S5P EXYNOS AR..., Russell King,
Krzysztof Kozlowski, Patrice.chotard, Javier Martinez Canillas,
Hans Verkuil, dri-devel@lists.freedesktop.org, Daniel Vetter,
Marek Szyprowski, linux-media@vger.kernel.org
In-Reply-To: <20170329141543.32935-12-hverkuil@xs4all.nl>
+ Patrice for sti DT
2017-03-29 16:15 GMT+02:00 Hans Verkuil <hverkuil@xs4all.nl>:
> From: Benjamin Gaignard <benjamin.gaignard@linaro.org>
>
> To use CEC notifier sti CEC driver needs to get phandle
> of the hdmi device.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> CC: devicetree@vger.kernel.org
> ---
> arch/arm/boot/dts/stih407-family.dtsi | 12 ------------
> arch/arm/boot/dts/stih410.dtsi | 13 +++++++++++++
> 2 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index d753ac36788f..044184580326 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -742,18 +742,6 @@
> <&clk_s_c0_flexgen CLK_ETH_PHY>;
> };
>
> - cec: sti-cec@094a087c {
> - compatible = "st,stih-cec";
> - reg = <0x94a087c 0x64>;
> - clocks = <&clk_sysin>;
> - clock-names = "cec-clk";
> - interrupts = <GIC_SPI 140 IRQ_TYPE_NONE>;
> - interrupt-names = "cec-irq";
> - pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_cec0_default>;
> - resets = <&softreset STIH407_LPM_SOFTRESET>;
> - };
> -
> rng10: rng@08a89000 {
> compatible = "st,rng";
> reg = <0x08a89000 0x1000>;
> diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
> index 3c9672c5b09f..21fe72b183d8 100644
> --- a/arch/arm/boot/dts/stih410.dtsi
> +++ b/arch/arm/boot/dts/stih410.dtsi
> @@ -281,5 +281,18 @@
> <&clk_s_c0_flexgen CLK_ST231_DMU>,
> <&clk_s_c0_flexgen CLK_FLASH_PROMIP>;
> };
> +
> + sti-cec@094a087c {
> + compatible = "st,stih-cec";
> + reg = <0x94a087c 0x64>;
> + clocks = <&clk_sysin>;
> + clock-names = "cec-clk";
> + interrupts = <GIC_SPI 140 IRQ_TYPE_NONE>;
> + interrupt-names = "cec-irq";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_cec0_default>;
> + resets = <&softreset STIH407_LPM_SOFTRESET>;
> + hdmi-phandle = <&sti_hdmi>;
> + };
> };
> };
> --
> 2.11.0
>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v12 00/10] mux controller abstraction and iio/i2c muxes
From: Peter Rosin @ 2017-03-30 7:34 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Andrew Morton, Colin Ian King,
Paul Gortmaker
In-Reply-To: <1490624525-15865-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On 2017-03-27 16:21, Peter Rosin wrote:
> Hi Greg!
>
> Please apply.
>
*snip snip*
> v10 -> v11 changes
> - added a new patch (12) with a fix for messed up error path reported
> by Paul Gortmaker.
Oops, should be Dan Carpenter. Sorry about that...
And, I forgot to high-light this:
> v4 -> v5 changes
> - driver for Analog Devices ADG792A/G, literally the first mux chip
> I found on the Internet with an i2c interface (that was not a
> dedicated i2c multiplexer like PCA9547) which I used to verify
> that the abstractions in the mux core are up to the task. Untested,
> just proof of concept that at least looks pretty and compiles...
Maybe the patches related to adg792 (last two patches in v12) should
not be applied? I don't care much either way, your call Greg...
Cheers,
peda
^ permalink raw reply
* Re: [PATCH 0/2] mtd: spi-nor: add stm32 qspi driver
From: Ludovic BARRE @ 2017-03-30 7:31 UTC (permalink / raw)
To: Cyrille Pitchen, Cyrille Pitchen, Marek Vasut
Cc: Boris Brezillon, Alexandre Torgue,
devicetree-u79uwXL29TY76Z2rM5mHXA, Richard Weinberger,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Brian Norris,
David Woodhouse
In-Reply-To: <5224f3cd-a128-9e72-c0c8-62a137ceeb79-yU5RGvR974pGWvitb5QawA@public.gmane.org>
hi Cyrille
I see your patch series
[PATCH v5 0/6] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories
No problem, I rebase my V2 onto your patch
BR
Ludo
On 03/29/2017 06:51 PM, Cyrille Pitchen wrote:
> Hi Ludovic,
>
> Le 27/03/2017 à 14:54, Ludovic Barre a écrit :
>> From: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>>
>> This patch set adds a SPI-NOR driver for stm32 QSPI controller.
>> It is a specialized SPI interface for serial Flash devices.
>> It supports 1 or 2 Flash device with single, dual and quad SPI Flash memories.
>>
>> It can operate in any of the following modes:
>> -indirect mode: all the operations are performed using the quadspi
>> registers
>> -read memory-mapped mode: the external Flash memory is mapped to the
>> microcontroller address space and is seen by the system as if it was
>> an internal memory
>>
>> Ludovic Barre (2):
>> dt-bindings: Document the STM32 QSPI bindings
>> mtd: spi-nor: add driver for STM32 quad spi flash controller
>>
>> .../devicetree/bindings/mtd/stm32-quadspi.txt | 45 ++
>> drivers/mtd/spi-nor/Kconfig | 7 +
>> drivers/mtd/spi-nor/Makefile | 1 +
>> drivers/mtd/spi-nor/stm32-quadspi.c | 679 +++++++++++++++++++++
>> 4 files changed, 732 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mtd/stm32-quadspi.txt
>> create mode 100644 drivers/mtd/spi-nor/stm32-quadspi.c
>>
> Just a small word to warn you that I'm likely to ask you to rebase this
> series onto the patch "mtd: spi-nor: introduce more SPI protocols and
> the Dual Transfer Mode". Indeed, I need to synchronize with Marek first
> but I plan to merge this patch within few days.
>
>
> Best regards,
>
> Cyrille
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 01/18] dt-bindings: power: battery: add constant-charge-current property
From: Liam Breck @ 2017-03-30 7:30 UTC (permalink / raw)
To: Quentin Schulz; +Cc: Sebastian Reichel, robh+dt, linux-pm, devicetree
In-Reply-To: <614aa4ef-6900-0c56-a364-0ef4e8af2f97@free-electrons.com>
On Wed, Mar 29, 2017 at 11:41 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> Hi,
>
> On 29/03/2017 11:26, Liam Breck wrote:
>> On Wed, Mar 29, 2017 at 12:54 AM, Quentin Schulz
>> <quentin.schulz@free-electrons.com> wrote:
>>> Hi,
>>>
>>> On 29/03/2017 09:39, Liam Breck wrote:
>>>> On Wed, Mar 29, 2017 at 12:09 AM, Quentin Schulz
>>>> <quentin.schulz@free-electrons.com> wrote:
>>>>> Hi Liam,
>>>>>
>>>>> On 29/03/2017 08:55, Liam Breck wrote:
>>>>>> Hi Quentin,
>>>>>>
>>>>>> On Thu, Mar 16, 2017 at 12:42 AM, Liam Breck <liam@networkimprov.net> wrote:
>>>>>>> On Thu, Mar 16, 2017 at 12:03 AM, Quentin Schulz
>>>>>>> <quentin.schulz@free-electrons.com> wrote:
>>>>>>>> Hi Liam,
>>>>>>>>
>>>>>>>> On 16/03/2017 07:27, Liam Breck wrote:
>>>>>>>>> Hi Rob,
>>>>>>>>>
>>>>>>>>> On Wed, Mar 15, 2017 at 6:10 AM, Quentin Schulz
>>>>>>>>> <quentin.schulz@free-electrons.com> wrote:
>>>>>>>>>> Hi Liam,
>>>>>>>>>>
>>>>>>>>>> On 15/03/2017 13:08, Liam Breck wrote:
>>>>>>>>>>> I dropped most of the CCs, pls re-add anyone essential. Use Cc lines
>>>>>>>>>>> in patch description to direct a patch to interested parties and
>>>>>>>>>>> relevant lists. I don't want to see all 19 patches in this series.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 15, 2017 at 3:55 AM, Quentin Schulz
>>>>>>>>>>> <quentin.schulz@free-electrons.com> wrote:
>>>>>>>>>>>> This adds the constant-charge-current property to the list of optional
>>>>>>>>>>>> properties of the battery.
>>>>>>>>>>>>
>>>>>>>>>>>> The constant charge current is critical for batteries as they can't
>>>>>>>>>>>> handle all charge currents.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>>>>>>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> v4:
>>>>>>>>>>>> - switch from constant-charge-current-microamp to constant-charge-microamp,
>>>>>>>>>
>>>>>>>>> Sebastian is on record supporting name alignment between DT:battery
>>>>>>>>> properties and enum power_supply_property.
>>>>>>>>>
>>>>>>>>> Could you OK a change back to constant-charge-current-microamp in this patch?
>>>>>>>>>
>>>>>>>>> Note that the following could appear in DT:battery in future:
>>>>>>>>>
>>>>>>>>> constant-charge-current-microamp
>>>>>>>>> constant-charge-current-max-microamp
>>>>>>>>
>>>>>>>> OK. I am actually setting max constant charge current and constant
>>>>>>>> current charge with the same DT property so I might need to adapt my
>>>>>>>> patches.
>>>>>>>
>>>>>>> I suspect you should set battery:*-current-max with DT, as -current is
>>>>>>> "programmed by charger" so seems to be a stat, not a fixed
>>>>>>> characteristic.
>>>>>>
>>>>>> Did you resolve this issue?
>>>>>>
>>>>>
>>>>> Sorry, completely missed your first mail.
>>>>>
>>>>> Constant charge current is actually what I set in the PMIC. The maximum
>>>>> constant charge current is completely PMIC-agnostic in my driver as it
>>>>> is used to tell the user that (s)he shouldn't really have a constant
>>>>> charge current over the maximum limit as the battery might not be able
>>>>> to handle such high current.
>>>>>
>>>>> What I suggest is to have both properties in DT. I'll set the maximum as
>>>>> I do today and we can give the user the ability to set a "default"
>>>>> constant charge current (below maximum constant charge current) in the
>>>>> DT. Maybe we do not want to recharge your battery with the maximum value
>>>>> by default?
>>>>
>>>> The scope here is just static battery characteristics. For the battery
>>>> node, I think constant-charge-current-max-microamp is the relevant
>>>> term.
>>>
>>> If it's only for static battery characteristics, I agree.
>>>
>>>
>>>> If we added both properties, one would be an alias for the
>>>> other, which doesn't seem useful.
>>
>> Meaning if both properties describe static characteristics of the
>> battery, they wouldn't have different meaning.
>>
>>> Hum. Not really an alias. In my driver, I have a maximum which avoids to
>>> set a constant charge current higher than what the battery is supposed
>>> to be able to handle. The maximum can be increased via sysfs if ever the
>>> user decides to go wild (or if (s)he changes the battery for example).
>>> The maximum is never input in any of PMIC registers, it is not dealing
>>> with the PMIC at all.
>>
>> Using the battery's -max as the default for your user-adjustable max
>> sounds sensible. However the user-adjustable max should perhaps appear
>> in a custom sysfs attribute, not
>> /sys/class.../constant_charge_current_max (see comment re regulator).
>>
>
> Why?
Because charger's ccc_max should refer to its electrical
characteristics, not a user-adjustable setting. Maybe
/sys/class.../constant_charge_current_max_local or similar.
>> If the battery changes, the DT battery node should also change, esp if
>> its -max drops. I realize that's not nec trivial.
>>
>
> Disagree. That's definitely not user friendly.
There are ways to field-upgrade the dtb, tho that might not be
workable in all cases :-)
>>> If I have only the max constant charge current in the DT, I'll set the
>>> max and constant charge current with the same DT entry. That's perfectly
>>> fine.
>>
>> I assume the pmic ccc setting is adjustable via
>> /sys/class.../constant_charge_current?
>>
>
> Yes, it is then limited by a user-modifiable constant_charge_current_max.
>
>>> However, what I was thinking is to have a "default" value taken from DT
>>> for constant charge current (which will be below maximum ccc) if ever
>>> someone wants to set a maximum but use a lower ccc value. Anyway, I
>>> guess it's more a "fancy" feature than a requirement (unlike max-ccc).
>>
>> Maybe a lower default ccc than battery's -max could be provided via a
>> % value in the pmic DT node? Then multiply battery -max by that to set
>> ccc.
>>
>
> That's battery-specific, why would you want to put it in the PMIC node?
A % modifier is not too battery-specific. If you want a specific
alternate default ccc, you could certainly put it in the battery node,
and read it from your driver the way power_supply_get_battery_info()
does. But if you are expecting battery changes which alter
characteristics, the less you hard-wire into DT, the better.
>>>> The pmic can report both independently of the battery characteristic,
>>>> and take a driver-specific DT property for
>>>> constant-charge-current-microamp which it applies if less than the
>>>> battery's -max setting.
>>>
>>> Indeed.
>>>
>>>> Or you could set that in userspace via
>>>> /sys/class.../constant_charge_current.
>>>
>>> The goal is to have both. The DT for default values (given by the
>>> vendor/upstream) and sysfs for custom values (interesting if you don't
>>> want to/can't recompile a DT.
>>>
>>>> The charger's -max value would
>>>> be a characteristic of its regulator.
>>>>
>>>
>>> I don't really understand what you mean by that.
>>
>> I believe the pmic's -max value is a characteristic of its electrical
>> design, the max current it can deliver. The power_supply_class docs
>> are not very clear - "maximum charge current supported by the power
>> supply object".
>>
>
> This PMIC can deliver a maximum of 1.8A or 2.5A depending on the variant
> for constant charge current but you do not want to easily allow your
> user to put such a high value as the battery is most likely not able to
> handle such a high current.
Right, and /sys/class.../constant_charge_current_max should probably
report exactly that. Hence the suggestion for ccc_max_local for the
adjustable ccc_max.
We really shouldn't be wondering what do do here, but alas, the kernel
power-supply framework is a bit under-developed :-p
Anyway I plan to add constant-charge-current-max-microamp in the
forthcoming patchset.
>>>> Or am I missing something...?
>>>>
>>>>>> Rob & Sebastian want me to merge all items for
>>>>>> bindings/power/supply/battery.txt. If I do that I'll also roll up
>>>>>> their counterparts in power_supply_core.c and submit a patchset for
>>>>>> those two files.
>>>>>>
>>>>>
>>>>> I guess that adding the two properties make sense, don't you think?
>>>>>
>>>>> Also, could you Cc me on your next version of your patches? So I know
>>>>> when to rebase and slightly rework my patches once your patch series is
>>>>> merged.
>>>>
>>>> Surely.
>>>>
>>>>> Thanks,
>>>>> Quentin
>>>>>
>>>>>>> You may program your charger's -current with the battery's
>>>>>>> -current-max, of course.
>>>>>>>
>>>>>>> Note that your charger also has a -current-max characteristic, likely
>>>>>>> different than your battery. You may not need that in DT tho.
>>>>>>>
>>>>>>>>> constant-charge-voltage-microvolt
>>>>>>>>> constant-charge-voltage-max-microvolt
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>>>> Must be constant-charge-current-microamp for the reasons discussed in
>>>>>>>>>>> battery.txt - consistency with sysfs names.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hum. Just nitpicking, but I disagree with the use of 'must'. IIRC there
>>>>>>>>>> is nothing in the code that would require the property to be named after
>>>>>>>>>> a property from the enum power_supply_property.
>>>>>>>>>>
>>>>>>>>>> I would say that you _want_ it to be named like that because it
>>>>>>>>>> underlines the relation between the DT property and the actual impacted
>>>>>>>>>> property in the power supply subsystem. I'm fine with this reason but in
>>>>>>>>>> the end, the maintainer's opinion prevails (if (s)he does not want it,
>>>>>>>>>> (s)he will not take it). So, basically, I actually don't mind either
>>>>>>>>>> option and I see arguments on each side.
>>>>>>>>>>
>>>>>>>>>> So, just waiting for maintainer's opinion to make the final version of
>>>>>>>>>> this patch.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Quentin
>>>>>>>>>>
>>>>>>>>>>> Also applies to power_supply_core.c patch.
>>>>>>>>>>>
>>>>>>>>>>> Rob: enum power_supply_property also lists constant-charge-voltage,
>>>>>>>>>>> hence the -current
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> added in v3
>>>>>>>>>>>>
>>>>>>>>>>>> Documentation/devicetree/bindings/power/supply/battery.txt | 2 ++
>>>>>>>>>>>> 1 file changed, 2 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>>>>>>> index 0278617..9594e1e 100644
>>>>>>>>>>>> --- a/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>>>>>>> +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>>>>>>> @@ -7,6 +7,7 @@ Optional Properties:
>>>>>>>>>>>> - voltage-min-design-microvolt: drained battery voltage
>>>>>>>>>>>> - energy-full-design-microwatt-hours: battery design energy
>>>>>>>>>>>> - charge-full-design-microamp-hours: battery design capacity
>>>>>>>>>>>> + - constant-charge-microamp: battery constant charge current
>>>>>>>>>>>>
>>>>>>>>>>>> Because drivers surface properties in sysfs using names derived
>>>>>>>>>>>> from enum power_supply_property, e.g.
>>>>>>>>>>>> @@ -30,6 +31,7 @@ Example:
>>>>>>>>>>>> voltage-min-design-microvolt = <3200000>;
>>>>>>>>>>>> energy-full-design-microwatt-hours = <5290000>;
>>>>>>>>>>>> charge-full-design-microamp-hours = <1430000>;
>>>>>>>>>>>> + constant-charge-microamp = <300000>;
>>>>>>>>>>>> };
>>>>>>>>>>>>
>>>>>>>>>>>> charger: charger@11 {
>>>>>>>>>>>> --
>>>>>>>>>>>> 2.9.3
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Quentin Schulz, Free Electrons
>>>>>>>>>> Embedded Linux and Kernel engineering
>>>>>>>>>> http://free-electrons.com
>>>>>>>>
>>>>>>>> --
>>>>>>>> Quentin Schulz, Free Electrons
>>>>>>>> Embedded Linux and Kernel engineering
>>>>>>>> http://free-electrons.com
>>>>>
>>>>> --
>>>>> Quentin Schulz, Free Electrons
>>>>> Embedded Linux and Kernel engineering
>>>>> http://free-electrons.com
>>>
>>> --
>>> Quentin Schulz, Free Electrons
>>> Embedded Linux and Kernel engineering
>>> http://free-electrons.com
>
> --
> Quentin Schulz, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v7 1/2] dt-bindings: Add GPCv2 power gating driver
From: Dong Aisheng @ 2017-03-30 7:15 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Shawn Guo, Andrey Yurovsky, Lucas Stach, Rob Herring,
Mark Rutland, Fabio Estevam, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <CAHQ1cqH4HnVsiAT6wxVJ=b-AJKWCK6L7kTxLZ7JFrZ4B-t2PQg@mail.gmail.com>
On Mon, Mar 27, 2017 at 11:42:51AM -0700, Andrey Smirnov wrote:
> On Thu, Mar 23, 2017 at 11:32 PM, Dong Aisheng <dongas86@gmail.com> wrote:
> > On Tue, Mar 21, 2017 at 07:50:03AM -0700, Andrey Smirnov wrote:
> >> Add DT bindings for power domain driver for GPCv2 IP block found in
> >> i.MX7 SoCs.
> >>
> >> Cc: yurovsky@gmail.com
> >> Cc: Lucas Stach <l.stach@pengutronix.de>
> >> Cc: Rob Herring <robh+dt@kernel.org>
> >> Cc: Mark Rutland <mark.rutland@arm.com>
> >> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> >> Cc: Dong Aisheng <dongas86@gmail.com>
> >> Cc: devicetree@vger.kernel.org
> >> Cc: linux-arm-kernel@lists.infradead.org
> >> Cc: linux-kernel@vger.kernel.org
> >> Acked-by: Rob Herring <robh@kernel.org>
> >> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> >> ---
> >> .../devicetree/bindings/power/fsl,imx-gpcv2.txt | 71 ++++++++++++++++++++++
> >> include/dt-bindings/power/imx7-power.h | 18 ++++++
> >> 2 files changed, 89 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
> >> create mode 100644 include/dt-bindings/power/imx7-power.h
> >>
> >> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
> >> new file mode 100644
> >> index 0000000..02f45c6
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
> >> @@ -0,0 +1,71 @@
> >> +Freescale i.MX General Power Controller v2
> >> +==========================================
> >> +
> >> +The i.MX7S/D General Power Control (GPC) block contains Power Gating
> >> +Control (PGC) for various power domains.
> >> +
> >> +Required properties:
> >> +
> >> +- compatible: Should be "fsl,imx7d-gpc"
> >> +
> >> +- reg: should be register base and length as documented in the
> >> + datasheet
> >> +
> >> +- interrupts: Should contain GPC interrupt request 1
> >> +
> >> +Power domains contained within GPC node are generic power domain
> >> +providers, documented in
> >> +Documentation/devicetree/bindings/power/power_domain.txt, which are
> >> +described as subnodes of the power gating controller 'pgc' node,
> >> +which, in turn, is expected to contain the following:
> >> +
> >> +Required properties:
> >> +
> >> +- reg: Power domain index. Valid values are defined in
> >> + include/dt-bindings/power/imx7-power.h
> >> +
> >> +- #power-domain-cells: Should be 0
> >> +
> >> +Optional properties:
> >> +
> >> +- power-supply: Power supply used to power the domain
> >> +
> >> +Example:
> >> +
> >> + gpc: gpc@303a0000 {
> >> + compatible = "fsl,imx7d-gpc";
> >> + reg = <0x303a0000 0x1000>;
> >> + interrupt-controller;
> >> + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
> >> + #interrupt-cells = <3>;
> >> + interrupt-parent = <&intc>;
> >> +
> >> + pgc {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + pgc_pcie_phy: power-domain@3 {
> >> + #power-domain-cells = <0>;
> >> +
> >> + reg = <IMX7_POWER_DOMAIN_PCIE_PHY>;
> >> + power-supply = <®_1p0d>;
> >> + };
> >> + };
> >> + };
> >> +
> >> +
> >> +Specifying power domain for IP modules
> >> +======================================
> >> +
> >> +IP cores belonging to a power domain should contain a 'power-domains'
> >> +property that is a phandle for PGC node representing the domain.
> >> +
> >> +Example of a device that is part of the PCIE_PHY power domain:
> >> +
> >> + pcie: pcie@33800000 {
> >> + reg = <0x33800000 0x4000>,
> >> + <0x4ff00000 0x80000>;
> >> + /* ... */
> >> + power-domains = <&pgc_pcie_phy>;
> >> + /* ... */
> >> + };
> >> diff --git a/include/dt-bindings/power/imx7-power.h b/include/dt-bindings/power/imx7-power.h
> >> new file mode 100644
> >> index 0000000..eb70023
> >> --- /dev/null
> >> +++ b/include/dt-bindings/power/imx7-power.h
> >> @@ -0,0 +1,18 @@
> >> +/*
> >> + * Copyright (C) 2017 Impinj
> >> + *
> >> + * 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.
> >> + */
> >> +
> >> +#ifndef __DT_BINDINGS_IMX7_POWER_H__
> >> +#define __DT_BINDINGS_IMX7_POWER_H__
> >> +
> >> +#define IMX7_POWER_DOMAIN_USB_HSIC_PHY 0
> >> +#define IMX7_POWER_DOMAIN_USB_OTG2_PHY 1
> >> +#define IMX7_POWER_DOMAIN_USB_OTG1_PHY 2
> >> +#define IMX7_POWER_DOMAIN_PCIE_PHY 3
> >> +#define IMX7_POWER_DOMAIN_MIPI_PHY 4
> >
> > Nitpick: Probably better to define according to the reference manual
> > defined order.
> >
> > 0x800 ~ 0x83F : PGC for A7 core0
> > 0x840 ~ 0x87F: PGC for A7 core1
> > 0x880 ~ 0x8BF: PGC for A7 SCU
> > 0xA00 ~ 0xA3F: PGC for fastmix/megamix
> > 0xC00 ~ 0xC3F: PGC for MIPI PHY
> > 0xC40 ~ 0xC7F: PGC for PCIE_PHY
> > 0xC80 ~ 0xCBF: Reserved
> > 0xCC0 ~ 0xCFF: Reserved
> > 0xD00 ~ 0xD3F: PGC for USB HSIC PHY
> >
> > You can drop A7 core/scu/fastmix/megamix as well.
> >
>
> Sure, will do.
>
BTW, i read some other SoC power domain implementations,
they keep the CPU domains although not used in kernel.
e.g.
include/dt-bindings/power/rk3288-power.h
include/soc/tegra/pmc.h
That probably is a good reference in case we may need them in the future.
And device tree actually is describe HW.
I wonder we may be better to keep them as well.
Regards
Dong Aisheng
> Thanks,
> Andrey Smirnov
^ permalink raw reply
* Re: [PATCH 2/2] soc/imx: add workaround for i.MX6QP to the GPC PD driver
From: Lothar Waßmann @ 2017-03-30 7:08 UTC (permalink / raw)
To: Lucas Stach
Cc: A.S. Dong, devicetree@vger.kernel.org,
patchwork-lst@pengutronix.de, kernel@pengutronix.de,
Fabio Estevam, Shawn Guo, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1490804026.29083.29.camel@pengutronix.de>
Hi,
On Wed, 29 Mar 2017 18:13:46 +0200 Lucas Stach wrote:
> Am Mittwoch, den 29.03.2017, 16:08 +0000 schrieb A.S. Dong:
> > Hi Lucas,
> >
> > > -----Original Message-----
> > > From: Lucas Stach [mailto:l.stach@pengutronix.de]
> > > Sent: Thursday, March 23, 2017 10:44 PM
> > > To: Shawn Guo
> > > Cc: Fabio Estevam; A.S. Dong; devicetree@vger.kernel.org; linux-arm-
> > > kernel@lists.infradead.org; kernel@pengutronix.de; patchwork-
> > > lst@pengutronix.de
> > > Subject: [PATCH 2/2] soc/imx: add workaround for i.MX6QP to the GPC PD
> > > driver
> > >
> > > On i.MX6QP, due to hardware erratum ERR009619, the PRE clocks may be
> > > stalled during the power up sequencing of the PU power domain. As this may
> > > lead to a complete loss of display output, the recommended workaround is
> > > to keep the PU domain enabled during normal system operation.
> > >
> > > Implement this by rejecting the domain power down request on the affected
> > > SoC.
> > >
> > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > > ---
> > > drivers/soc/imx/gpc.c | 19 +++++++++++++++++++
> > > 1 file changed, 19 insertions(+)
> > >
> > > diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c index
> > > 4294287e5f6c..599e1e46f694 100644
> > > --- a/drivers/soc/imx/gpc.c
> > > +++ b/drivers/soc/imx/gpc.c
> > > @@ -45,6 +45,7 @@ struct imx_pm_domain {
> > > unsigned int reg_offs;
> > > signed char cntr_pdn_bit;
> > > unsigned int ipg_rate_mhz;
> > > + bool allow_dynamic_pd;
> > > };
> > >
> > > static inline struct imx_pm_domain *
> > > @@ -59,6 +60,9 @@ static int imx6_pm_domain_power_off(struct
> > > generic_pm_domain *genpd)
> > > int iso, iso2sw;
> > > u32 val;
> > >
> > > + if (!pd->allow_dynamic_pd)
> > > + return -EBUSY;
> > > +
> > > /* Read ISO and ISO2SW power down delays */
> > > regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PUPSCR_OFFS, &val);
> > > iso = val & 0x3f;
> > > @@ -255,6 +259,7 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> > > },
> > > .reg_offs = 0x260,
> > > .cntr_pdn_bit = 0,
> > > + .allow_dynamic_pd = true,
> > > }, {
> > > .base = {
> > > .name = "DISPLAY",
> > > @@ -263,23 +268,33 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> > > },
> > > .reg_offs = 0x240,
> > > .cntr_pdn_bit = 4,
> > > + .allow_dynamic_pd = true,
> >
> > Just a Nitpick, besides shawn's comment in another mail,
> > if we use a domain flag like IMX_PD_ALWAYS_ON set by SoC errata flag,
> > then probably we can save all the default allow_dynamic_pd lines.
> > This also release the life when adding new domains.
>
> If other things like that show up we can certainly switch to a flags
> field. In the meantime I like that the current style is more explicit
> about it.
>
Since the purpose of the driver is all about dynamic power management,
I would rather add a 'disable_dynamic_pd' for the case(s) where it's
not allowed, rather than having to state the obvious over and over
again.
Lothar Waßmann
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] arm64: dts: add pinctrl dtsi file for HiKey960 development board
From: Wang Xiaoyin @ 2017-03-30 6:48 UTC (permalink / raw)
To: xuwei5, robh+dt, mark.rutland, catalin.marinas, will.deacon,
linux-arm-kernel, devicetree, linux-kernel
Cc: hw.wangxiaoyin, chenya99
In-Reply-To: <20170330064803.18648-1-hw.wangxiaoyin@hisilicon.com>
Add pinctrl dtsi file for HiKey960 development board, enable
5 pinmux devices and 1 pinconf device, also include some nodes
of configurations for pins.
Signed-off-by: Wang Xiaoyin <hw.wangxiaoyin@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 1 +
.../arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi | 407 +++++++++++++++++++++
2 files changed, 408 insertions(+)
create mode 100644 arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index ff37f0a0aa93..186251ffc6b2 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include "hi3660.dtsi"
+#include "hikey960-pinctrl.dtsi"
/ {
model = "HiKey960";
diff --git a/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi b/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi
new file mode 100644
index 000000000000..c2096c6f46c4
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi
@@ -0,0 +1,407 @@
+/*
+ * pinctrl dts fils for Hislicon HiKey960 development board
+ *
+ */
+
+#include <dt-bindings/pinctrl/hisi.h>
+
+/ {
+ soc {
+ /* [IOMG_000, IOMG_123] */
+ range: gpio-range {
+ #pinctrl-single,gpio-range-cells = <3>;
+ };
+ pmx0: pinmux@e896c000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0xe896c000 0x0 0x1f0>;
+ #pinctrl-cells = <1>;
+ #gpio-range-cells = <0x3>;
+ pinctrl-single,register-width = <0x20>;
+ pinctrl-single,function-mask = <0x7>;
+ /* pin base, nr pins & gpio function */
+ pinctrl-single,gpio-range = <
+ &range 0 7 0
+ &range 8 116 0>;
+
+ isp0_pmx_func: isp0_pmx_func {
+ pinctrl-single,pins = <
+ 0x058 MUX_M1 /* ISP_CLK0 */
+ 0x064 MUX_M1 /* ISP_SCL0 */
+ 0x068 MUX_M1 /* ISP_SDA0 */
+ >;
+ };
+
+ isp1_pmx_func: isp1_pmx_func {
+ pinctrl-single,pins = <
+ 0x05c MUX_M1 /* ISP_CLK1 */
+ 0x06c MUX_M1 /* ISP_SCL1 */
+ 0x070 MUX_M1 /* ISP_SDA1 */
+ >;
+ };
+
+ i2c3_pmx_func: i2c3_pmx_func {
+ pinctrl-single,pins = <
+ 0x02c MUX_M1 /* I2C3_SCL */
+ 0x030 MUX_M1 /* I2C3_SDA */
+ >;
+ };
+
+ i2c4_pmx_func: i2c4_pmx_func {
+ pinctrl-single,pins = <
+ 0x090 MUX_M1 /* I2C4_SCL */
+ 0x094 MUX_M1 /* I2C4_SDA */
+ >;
+ };
+
+ pcie_perstn_pmx_func: pcie_perstn_pmx_func {
+ pinctrl-single,pins = <
+ 0x15c MUX_M1 /* PCIE_PERST_N */
+ >;
+ };
+
+ usbhub5734_pmx_func: usbhub5734_pmx_func {
+ pinctrl-single,pins = <
+ 0x11c MUX_M0 /* GPIO_073 */
+ 0x120 MUX_M0 /* GPIO_074 */
+ >;
+ };
+
+ spi1_pmx_func: spi1_pmx_func {
+ pinctrl-single,pins = <
+ 0x034 MUX_M1 /* SPI1_CLK */
+ 0x038 MUX_M1 /* SPI1_DI */
+ 0x03c MUX_M1 /* SPI1_DO */
+ 0x040 MUX_M1 /* SPI1_CS_N */
+ >;
+ };
+
+ uart0_pmx_func: uart0_pmx_func {
+ pinctrl-single,pins = <
+ 0x0cc MUX_M2 /* UART0_RXD */
+ 0x0d0 MUX_M2 /* UART0_TXD */
+ 0x0d4 MUX_M2 /* UART0_RXD_M */
+ 0x0d8 MUX_M2 /* UART0_TXD_M */
+ >;
+ };
+
+ uart1_pmx_func: uart1_pmx_func {
+ pinctrl-single,pins = <
+ 0x0b0 MUX_M2 /* UART1_CTS_N */
+ 0x0b4 MUX_M2 /* UART1_RTS_N */
+ 0x0a8 MUX_M2 /* UART1_RXD */
+ 0x0ac MUX_M2 /* UART1_TXD */
+ >;
+ };
+
+ uart2_pmx_func: uart2_pmx_func {
+ pinctrl-single,pins = <
+ 0x0bc MUX_M2 /* UART2_CTS_N */
+ 0x0c0 MUX_M2 /* UART2_RTS_N */
+ 0x0c8 MUX_M2 /* UART2_RXD */
+ 0x0c4 MUX_M2 /* UART2_TXD */
+ >;
+ };
+
+ uart3_pmx_func: uart3_pmx_func {
+ pinctrl-single,pins = <
+ 0x0dc MUX_M1 /* UART3_CTS_N */
+ 0x0e0 MUX_M1 /* UART3_RTS_N */
+ 0x0e4 MUX_M1 /* UART3_RXD */
+ 0x0e8 MUX_M1 /* UART3_TXD */
+ >;
+ };
+
+ uart4_pmx_func: uart4_pmx_func {
+ pinctrl-single,pins = <
+ 0x0ec MUX_M1 /* UART4_CTS_N */
+ 0x0f0 MUX_M1 /* UART4_RTS_N */
+ 0x0f4 MUX_M1 /* UART4_RXD */
+ 0x0f8 MUX_M1 /* UART4_TXD */
+ >;
+ };
+
+ uart5_pmx_func: uart5_pmx_func {
+ pinctrl-single,pins = <
+ 0x0c4 MUX_M3 /* UART5_CTS_N */
+ 0x0c8 MUX_M3 /* UART5_RTS_N */
+ 0x0bc MUX_M3 /* UART5_RXD */
+ 0x0c0 MUX_M3 /* UART5_TXD */
+ >;
+ };
+
+ uart6_pmx_func: uart6_pmx_func {
+ pinctrl-single,pins = <
+ 0x0cc MUX_M1 /* UART6_CTS_N */
+ 0x0d0 MUX_M1 /* UART6_RTS_N */
+ 0x0d4 MUX_M1 /* UART6_RXD */
+ 0x0d8 MUX_M1 /* UART6_TXD */
+ >;
+ };
+ };
+
+ /* [IOMG_MMC0_000, IOMG_MMC0_005] */
+ pmx1: pinmux@ff37e000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0xff37e000 0x0 0x18>;
+ #gpio-range-cells = <0x3>;
+ #pinctrl-cells = <1>;
+ pinctrl-single,register-width = <0x20>;
+ pinctrl-single,function-mask = <0x7>;
+ /* pin base, nr pins & gpio function */
+ pinctrl-single,gpio-range = <&range 0 6 0>;
+
+ sd_pmx_func: sd_pmx_func {
+ pinctrl-single,pins = <
+ 0x000 MUX_M1 /* SD_CLK */
+ 0x004 MUX_M1 /* SD_CMD */
+ 0x008 MUX_M1 /* SD_DATA0 */
+ 0x00c MUX_M1 /* SD_DATA1 */
+ 0x010 MUX_M1 /* SD_DATA2 */
+ 0x014 MUX_M1 /* SD_DATA3 */
+ >;
+ };
+ };
+
+ /* [IOMG_FIX_000, IOMG_FIX_011] */
+ pmx2: pinmux@ff3b6000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0xff3b6000 0x0 0x30>;
+ #pinctrl-cells = <1>;
+ #gpio-range-cells = <0x3>;
+ pinctrl-single,register-width = <0x20>;
+ pinctrl-single,function-mask = <0x7>;
+ /* pin base, nr pins & gpio function */
+ pinctrl-single,gpio-range = <&range 0 12 0>;
+
+ spi3_pmx_func: spi3_pmx_func {
+ pinctrl-single,pins = <
+ 0x008 MUX_M1 /* SPI3_CLK */
+ 0x00c MUX_M1 /* SPI3_DI */
+ 0x010 MUX_M1 /* SPI3_DO */
+ 0x014 MUX_M1 /* SPI3_CS0_N */
+ >;
+ };
+ };
+
+ /* [IOMG_MMC1_000, IOMG_MMC1_005] */
+ pmx3: pinmux@ff3fd000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0xff3fd000 0x0 0x18>;
+ #pinctrl-cells = <1>;
+ #gpio-range-cells = <0x3>;
+ pinctrl-single,register-width = <0x20>;
+ pinctrl-single,function-mask = <0x7>;
+ /* pin base, nr pins & gpio function */
+ pinctrl-single,gpio-range = <&range 0 6 0>;
+
+ sdio_pmx_func: sdio_pmx_func {
+ pinctrl-single,pins = <
+ 0x000 MUX_M1 /* SDIO_CLK */
+ 0x004 MUX_M1 /* SDIO_CMD */
+ 0x008 MUX_M1 /* SDIO_DATA0 */
+ 0x00c MUX_M1 /* SDIO_DATA1 */
+ 0x010 MUX_M1 /* SDIO_DATA2 */
+ 0x014 MUX_M1 /* SDIO_DATA3 */
+ >;
+ };
+ };
+
+ /* [IOMG_AO_000, IOMG_AO_041] */
+ pmx4: pinmux@fff11000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0xfff11000 0x0 0xa8>;
+ #pinctrl-cells = <1>;
+ #gpio-range-cells = <0x3>;
+ pinctrl-single,register-width = <0x20>;
+ pinctrl-single,function-mask = <0x7>;
+ /* pin base in node, nr pins & gpio function */
+ pinctrl-single,gpio-range = <&range 0 42 0>;
+
+ i2s2_pmx_func: i2s2_pmx_func {
+ pinctrl-single,pins = <
+ 0x044 MUX_M1 /* I2S2_DI */
+ 0x048 MUX_M1 /* I2S2_DO */
+ 0x04c MUX_M1 /* I2S2_XCLK */
+ 0x050 MUX_M1 /* I2S2_XFS */
+ >;
+ };
+
+ slimbus_pmx_func: slimbus_pmx_func {
+ pinctrl-single,pins = <
+ 0x02c MUX_M1 /* SLIMBUS_CLK */
+ 0x030 MUX_M1 /* SLIMBUS_DATA */
+ >;
+ };
+
+ i2c0_pmx_func: i2c0_pmx_func {
+ pinctrl-single,pins = <
+ 0x014 MUX_M1 /* I2C0_SCL */
+ 0x018 MUX_M1 /* I2C0_SDA */
+ >;
+ };
+
+ i2c1_pmx_func: i2c1_pmx_func {
+ pinctrl-single,pins = <
+ 0x01c MUX_M1 /* I2C1_SCL */
+ 0x020 MUX_M1 /* I2C1_SDA */
+ >;
+ };
+
+ i2c2_pmx_func: i2c2_pmx_func {
+ pinctrl-single,pins = <
+ 0x024 MUX_M1 /* I2C2_SCL */
+ 0x028 MUX_M1 /* I2C2_SDA */
+ >;
+ };
+
+ i2c7_pmx_func: i2c7_pmx_func {
+ pinctrl-single,pins = <
+ 0x024 MUX_M3 /* I2C7_SCL */
+ 0x028 MUX_M3 /* I2C7_SDA */
+ >;
+ };
+
+ spi2_pmx_func: spi2_pmx_func {
+ pinctrl-single,pins = <
+ 0x08c MUX_M1 /* SPI2_CLK */
+ 0x090 MUX_M1 /* SPI2_DI */
+ 0x094 MUX_M1 /* SPI2_DO */
+ 0x098 MUX_M1 /* SPI2_CS0_N */
+ >;
+ };
+
+ spi4_pmx_func: spi4_pmx_func {
+ pinctrl-single,pins = <
+ 0x08c MUX_M4 /* SPI4_CLK */
+ 0x090 MUX_M4 /* SPI4_DI */
+ 0x094 MUX_M4 /* SPI4_DO */
+ 0x098 MUX_M4 /* SPI4_CS0_N */
+ >;
+ };
+
+ i2s0_pmx_func: i2s0_pmx_func {
+ pinctrl-single,pins = <
+ 0x034 MUX_M1 /* I2S0_DI */
+ 0x038 MUX_M1 /* I2S0_DO */
+ 0x03c MUX_M1 /* I2S0_XCLK */
+ 0x040 MUX_M1 /* I2S0_XFS */
+ >;
+ };
+ };
+
+ pmx5: pinmux@ff3fd800 {
+ compatible = "pinconf-single";
+ reg = <0x0 0xff3fd800 0x0 0x18>;
+ #pinctrl-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ pinctrl-single,register-width = <32>;
+
+ sdio_clk_cfg_func: sdio_clk_cfg_func {
+ pinctrl-single,pins = <
+ 0x000 0x0 /* SDIO_CLK */
+ >;
+ pinctrl-single,bias-pulldown = <
+ PULL_DIS
+ PULL_DOWN
+ PULL_DIS
+ PULL_DOWN
+ >;
+ pinctrl-single,bias-pullup = <
+ PULL_DIS
+ PULL_UP
+ PULL_DIS
+ PULL_UP
+ >;
+ pinctrl-single,drive-strength = <
+ DRIVE6_32MA
+ DRIVE6_MASK
+ >;
+ };
+
+ sdio_cfg_func: sdio_cfg_func {
+ pinctrl-single,pins = <
+ 0x004 0x0 /* SDIO_CMD */
+ 0x008 0x0 /* SDIO_DATA0 */
+ 0x00c 0x0 /* SDIO_DATA1 */
+ 0x010 0x0 /* SDIO_DATA2 */
+ 0x014 0x0 /* SDIO_DATA3 */
+ >;
+ pinctrl-single,bias-pulldown = <
+ PULL_DIS
+ PULL_DOWN
+ PULL_DIS
+ PULL_DOWN
+ >;
+ pinctrl-single,bias-pullup = <
+ PULL_UP
+ PULL_UP
+ PULL_DIS
+ PULL_UP
+ >;
+ pinctrl-single,drive-strength = <
+ DRIVE6_19MA
+ DRIVE6_MASK
+ >;
+ };
+ };
+
+ pmx6: pinmux@ff37e800 {
+ compatible = "pinconf-single";
+ reg = <0x0 0xff37e800 0x0 0x18>;
+ #pinctrl-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ pinctrl-single,register-width = <32>;
+
+ sd_clk_cfg_func: sd_clk_cfg_func {
+ pinctrl-single,pins = <
+ 0x000 0x0 /* SD_CLK */
+ >;
+ pinctrl-single,bias-pulldown = <
+ PULL_DIS
+ PULL_DOWN
+ PULL_DIS
+ PULL_DOWN
+ >;
+ pinctrl-single,bias-pullup = <
+ PULL_DIS
+ PULL_UP
+ PULL_DIS
+ PULL_UP
+ >;
+ pinctrl-single,drive-strength = <
+ DRIVE6_32MA
+ DRIVE6_MASK
+ >;
+ };
+
+ sd_cfg_func: sd_cfg_func {
+ pinctrl-single,pins = <
+ 0x004 0x0 /* SD_CMD */
+ 0x008 0x0 /* SD_DATA0 */
+ 0x00c 0x0 /* SD_DATA1 */
+ 0x010 0x0 /* SD_DATA2 */
+ 0x014 0x0 /* SD_DATA3 */
+ >;
+ pinctrl-single,bias-pulldown = <
+ PULL_DIS
+ PULL_DOWN
+ PULL_DIS
+ PULL_DOWN
+ >;
+ pinctrl-single,bias-pullup = <
+ PULL_UP
+ PULL_UP
+ PULL_DIS
+ PULL_UP
+ >;
+ pinctrl-single,drive-strength = <
+ DRIVE6_19MA
+ DRIVE6_MASK
+ >;
+ };
+ };
+
+ };
+};
--
2.11.0-rc2
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: add drive-strength levels of pin for Hi3660 SoC
From: Wang Xiaoyin @ 2017-03-30 6:48 UTC (permalink / raw)
To: xuwei5, robh+dt, mark.rutland, catalin.marinas, will.deacon,
linux-arm-kernel, devicetree, linux-kernel
Cc: hw.wangxiaoyin, chenya99
Add drive-strength levels of pin for Hi3660 Soc.
Signed-off-by: Wang Xiaoyin <hw.wangxiaoyin@hisilicon.com>
---
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
--
2.11.0-rc2
^ permalink raw reply related
* [PATCH v3 16/37] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
From: Masahiro Yamada @ 2017-03-30 6:46 UTC (permalink / raw)
To: linux-mtd
Cc: Enrico Jorns, Artem Bityutskiy, Dinh Nguyen, Boris Brezillon,
Marek Vasut, Graham Moore, David Woodhouse, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, Masahiro Yamada, devicetree,
linux-kernel, Brian Norris, Richard Weinberger, Cyrille Pitchen,
Rob Herring, Mark Rutland
In-Reply-To: <1490856383-31560-1-git-send-email-yamada.masahiro@socionext.com>
Add two compatible strings for UniPhier SoCs.
"socionext,uniphier-denali-nand-v5a" is used on UniPhier sLD3, LD4,
Pro4, sLD8 SoCs.
"socionext,uniphier-denali-nand-v5b" is used on UniPhier Pro5, PXs2,
LD6b, LD11, LD20 SoCs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v3: None
Changes in v2:
- Change the compatible strings
- Fix the ecc_strength_capability
- Override revision number for the newer one
.../devicetree/bindings/mtd/denali-nand.txt | 6 ++++++
drivers/mtd/nand/denali_dt.c | 23 ++++++++++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index 647618e..0b08ea5 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -3,6 +3,8 @@
Required properties:
- compatible : should be one of the following:
"altr,socfpga-denali-nand" - for Altera SOCFPGA
+ "socionext,uniphier-denali-nand-v5a" - for Socionext UniPhier (v5a)
+ "socionext,uniphier-denali-nand-v5b" - for Socionext UniPhier (v5b)
- reg : should contain registers location and length for data and reg.
- reg-names: Should contain the reg names "nand_data" and "denali_reg"
- interrupts : The interrupt number.
@@ -10,9 +12,13 @@ Required properties:
Optional properties:
- nand-ecc-step-size: must be 512 or 1024. If not specified, default to:
512 for "altr,socfpga-denali-nand"
+ 1024 for "socionext,uniphier-denali-nand-v5a"
+ 1024 for "socionext,uniphier-denali-nand-v5b"
see nand.txt for details.
- nand-ecc-strength: see nand.txt for details. Available values are:
8, 15 for "altr,socfpga-denali-nand"
+ 8, 16, 24 for "socionext,uniphier-denali-nand-v5a"
+ 8, 16 for "socionext,uniphier-denali-nand-v5b"
- nand-ecc-maximize: see nand.txt for details
Note:
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
index c3bc333..1f2f68a 100644
--- a/drivers/mtd/nand/denali_dt.c
+++ b/drivers/mtd/nand/denali_dt.c
@@ -41,11 +41,34 @@ static const struct denali_dt_data denali_socfpga_data = {
DENALI_CAP_ECC_SIZE_512,
};
+static const struct denali_dt_data denali_uniphier_v5a_data = {
+ .ecc_strength_avail = BIT(24) | BIT(16) | BIT(8),
+ .caps = DENALI_CAP_HW_ECC_FIXUP |
+ DENALI_CAP_DMA_64BIT |
+ DENALI_CAP_ECC_SIZE_1024,
+};
+
+static const struct denali_dt_data denali_uniphier_v5b_data = {
+ .revision = 0x0501,
+ .ecc_strength_avail = BIT(16) | BIT(8),
+ .caps = DENALI_CAP_HW_ECC_FIXUP |
+ DENALI_CAP_DMA_64BIT |
+ DENALI_CAP_ECC_SIZE_1024,
+};
+
static const struct of_device_id denali_nand_dt_ids[] = {
{
.compatible = "altr,socfpga-denali-nand",
.data = &denali_socfpga_data,
},
+ {
+ .compatible = "socionext,uniphier-denali-nand-v5a",
+ .data = &denali_uniphier_v5a_data,
+ },
+ {
+ .compatible = "socionext,uniphier-denali-nand-v5b",
+ .data = &denali_uniphier_v5b_data,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, denali_nand_dt_ids);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 14/37] mtd: nand: denali: support "nand-ecc-strength" DT property
From: Masahiro Yamada @ 2017-03-30 6:46 UTC (permalink / raw)
To: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Enrico Jorns, Artem Bityutskiy, Dinh Nguyen, Boris Brezillon,
Marek Vasut, Graham Moore, David Woodhouse, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, Masahiro Yamada,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland
In-Reply-To: <1490856383-31560-1-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Historically, this driver tried to choose as big ECC strength as
possible, but it would be reasonable to allow DT to set a particular
ECC strength with "nand-ecc-strength" property. This is useful
when a particular ECC setting is hard-coded by firmware (or hard-
wired by boot ROM).
If no ECC strength is specified in DT, "nand-ecc-maximize" is implied
since this was the original behavior.
Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Changes in v3: None
Changes in v2:
- Add available values in the binding document
Documentation/devicetree/bindings/mtd/denali-nand.txt | 6 ++++++
drivers/mtd/nand/denali.c | 18 ++++++++++++++++--
drivers/mtd/nand/denali_pci.c | 1 +
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index 25313c7..647618e 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -11,6 +11,12 @@ Optional properties:
- nand-ecc-step-size: must be 512 or 1024. If not specified, default to:
512 for "altr,socfpga-denali-nand"
see nand.txt for details.
+ - nand-ecc-strength: see nand.txt for details. Available values are:
+ 8, 15 for "altr,socfpga-denali-nand"
+ - nand-ecc-maximize: see nand.txt for details
+
+Note:
+Either nand-ecc-strength or nand-ecc-maximize should be specified.
The device tree may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index ce87b95..2f796e3 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1641,9 +1641,23 @@ int denali_init(struct denali_nand_info *denali)
goto failed_req_irq;
}
- ret = denali_set_max_ecc_strength(denali);
- if (ret)
+ if (!chip->ecc.strength && !(chip->ecc.options & NAND_ECC_MAXIMIZE)) {
+ dev_info(denali->dev,
+ "No ECC strength strategy is specified. Maximizing ECC strength\n");
+ chip->ecc.options |= NAND_ECC_MAXIMIZE;
+ }
+
+ if (chip->ecc.options & NAND_ECC_MAXIMIZE) {
+ ret = denali_set_max_ecc_strength(denali);
+ if (ret)
+ goto failed_req_irq;
+ } else if (!(denali->ecc_strength_avail & BIT(chip->ecc.strength))) {
+ dev_err(denali->dev,
+ "ECC strength %d is not supported on this controller.\n",
+ chip->ecc.strength);
+ ret = -EINVAL;
goto failed_req_irq;
+ }
chip->ecc.bytes = denali_calc_ecc_bytes(chip->ecc.size,
chip->ecc.strength);
diff --git a/drivers/mtd/nand/denali_pci.c b/drivers/mtd/nand/denali_pci.c
index a1ee9f8..a39682a5 100644
--- a/drivers/mtd/nand/denali_pci.c
+++ b/drivers/mtd/nand/denali_pci.c
@@ -87,6 +87,7 @@ static int denali_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
denali->ecc_strength_avail = BIT(15) | BIT(8);
denali->caps |= DENALI_CAP_ECC_SIZE_512;
+ denali->nand.ecc.options |= NAND_ECC_MAXIMIZE;
ret = denali_init(denali);
if (ret)
--
2.7.4
--
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 v3 12/37] mtd: nand: denali: support 1024 byte ECC step size
From: Masahiro Yamada @ 2017-03-30 6:45 UTC (permalink / raw)
To: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Enrico Jorns, Artem Bityutskiy, Dinh Nguyen, Boris Brezillon,
Marek Vasut, Graham Moore, David Woodhouse, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, Masahiro Yamada,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland
In-Reply-To: <1490856383-31560-1-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
This driver was originally written for the Intel MRST platform with
several platform specific parameters hard-coded. Another thing we
need to fix is the hard-coded ECC step size. Currently, it is
defined as follows:
#define ECC_SECTOR_SIZE 512
(somehow, it is defined in both denali.c and denali.h)
This must be avoided because the Denali IP supports 1024B ECC size
as well. The Denali User's Guide also says supporting both 512B and
1024B ECC sectors is possible, though it would require instantiation
of two different ECC circuits. So, possible cases are:
[1] only 512B ECC size is supported
[2] only 1024B ECC size is supported
[3] both 512B and 1024B ECC sizes are supported
Newer versions of this IP need ecc.size and ecc.steps explicitly
set up via the following registers:
CFG_DATA_BLOCK_SIZE (0x6b0)
CFG_LAST_DATA_BLOCK_SIZE (0x6c0)
CFG_NUM_DATA_BLOCKS (0x6d0)
Older versions do not have such registers (they were reserved), so
write accesses are safely ignored.
This commit adds new flags DENALI_CAP_ECC_SIZE_{512,1024}.
The DT property "nand-ecc-step-size" is still optional; a reasonable
default will be chosen for [1] and [2]. For case [3], users can
force ECC size via DT in case firmware hard-codes ECC settings.
If not specified, the driver will use chip's ECC requirement as a
hint to decide the ECC size.
Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Changes in v3:
- Move DENALI_CAP_ define out of struct denali_nand_info
- Use chip->ecc_step_ds as a hint to choose chip->ecc.size
where possible
Changes in v2:
- Change the capability prefix DENALI_CAPS_ -> DENALI_CAP_
- Make ECC 512 cap and ECC 1024 cap independent
- Set up three CFG_... registers
.../devicetree/bindings/mtd/denali-nand.txt | 5 +++
drivers/mtd/nand/denali.c | 51 ++++++++++++++++------
drivers/mtd/nand/denali.h | 12 ++++-
drivers/mtd/nand/denali_dt.c | 3 +-
drivers/mtd/nand/denali_pci.c | 2 +
5 files changed, 57 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index e593bbe..25313c7 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -7,6 +7,11 @@ Required properties:
- reg-names: Should contain the reg names "nand_data" and "denali_reg"
- interrupts : The interrupt number.
+Optional properties:
+ - nand-ecc-step-size: must be 512 or 1024. If not specified, default to:
+ 512 for "altr,socfpga-denali-nand"
+ see nand.txt for details.
+
The device tree may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 16634df..78d3b18 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -886,8 +886,6 @@ static int denali_hw_ecc_fixup(struct mtd_info *mtd,
return max_bitflips;
}
-#define ECC_SECTOR_SIZE 512
-
#define ECC_SECTOR(x) (((x) & ECC_ERROR_ADDRESS__SECTOR_NR) >> 12)
#define ECC_BYTE(x) (((x) & ECC_ERROR_ADDRESS__OFFSET))
#define ECC_CORRECTION_VALUE(x) ((x) & ERR_CORRECTION_INFO__BYTEMASK)
@@ -899,6 +897,7 @@ static int denali_sw_ecc_fixup(struct mtd_info *mtd,
struct denali_nand_info *denali,
unsigned long *uncor_ecc_flags, uint8_t *buf)
{
+ unsigned int ecc_size = denali->nand.ecc.size;
unsigned int bitflips = 0;
unsigned int max_bitflips = 0;
uint32_t err_addr, err_cor_info;
@@ -928,9 +927,9 @@ static int denali_sw_ecc_fixup(struct mtd_info *mtd,
* an erased sector.
*/
*uncor_ecc_flags |= BIT(err_sector);
- } else if (err_byte < ECC_SECTOR_SIZE) {
+ } else if (err_byte < ecc_size) {
/*
- * If err_byte is larger than ECC_SECTOR_SIZE, means error
+ * If err_byte is larger than ecc_size, means error
* happened in OOB, so we ignore it. It's no need for
* us to correct it err_device is represented the NAND
* error bits are happened in if there are more than
@@ -939,7 +938,7 @@ static int denali_sw_ecc_fixup(struct mtd_info *mtd,
int offset;
unsigned int flips_in_byte;
- offset = (err_sector * ECC_SECTOR_SIZE + err_byte) *
+ offset = (err_sector * ecc_size + err_byte) *
denali->devnum + err_device;
/* correct the ECC error */
@@ -1587,21 +1586,43 @@ int denali_init(struct denali_nand_info *denali)
chip->options |= NAND_NO_SUBPAGE_WRITE;
/*
+ * If the controller supports both 512B and 1024B ECC, and DT does not
+ * specify "nand-ecc-step-size", use the chip's requirement for a hint
+ * to choose ECC size.
+ */
+ if (!chip->ecc.size &&
+ denali->caps & DENALI_CAP_ECC_SIZE_512 &&
+ denali->caps & DENALI_CAP_ECC_SIZE_1024)
+ chip->ecc.size = chip->ecc_step_ds;
+
+ if (!chip->ecc.size) {
+ if (denali->caps & DENALI_CAP_ECC_SIZE_512)
+ chip->ecc.size = 512;
+ if (denali->caps & DENALI_CAP_ECC_SIZE_1024)
+ chip->ecc.size = 1024;
+ }
+
+ if (!(chip->ecc.size == 512 && denali->caps & DENALI_CAP_ECC_SIZE_512) &&
+ !(chip->ecc.size == 1024 && denali->caps & DENALI_CAP_ECC_SIZE_1024)) {
+ dev_err(denali->dev, "ECC size %d is not supported on this controller",
+ chip->ecc.size);
+ goto failed_req_irq;
+ }
+
+ /*
* Denali Controller only support 15bit and 8bit ECC in MRST,
* so just let controller do 15bit ECC for MLC and 8bit ECC for
* SLC if possible.
* */
if (!nand_is_slc(chip) &&
- (mtd->oobsize > (denali->bbtskipbytes +
- ECC_15BITS * (mtd->writesize /
- ECC_SECTOR_SIZE)))) {
+ mtd->oobsize > denali->bbtskipbytes +
+ ECC_15BITS * (mtd->writesize / chip->ecc.size)) {
/* if MLC OOB size is large enough, use 15bit ECC*/
chip->ecc.strength = 15;
chip->ecc.bytes = ECC_15BITS;
iowrite32(15, denali->flash_reg + ECC_CORRECTION);
- } else if (mtd->oobsize < (denali->bbtskipbytes +
- ECC_8BITS * (mtd->writesize /
- ECC_SECTOR_SIZE))) {
+ } else if (mtd->oobsize <
+ denali->bbtskipbytes + ECC_8BITS * (mtd->writesize / chip->ecc.size)) {
pr_err("Your NAND chip OOB is not large enough to contain 8bit ECC correction codes");
goto failed_req_irq;
} else {
@@ -1610,10 +1631,14 @@ int denali_init(struct denali_nand_info *denali)
iowrite32(8, denali->flash_reg + ECC_CORRECTION);
}
+ iowrite32(chip->ecc.size, denali->flash_reg + CFG_DATA_BLOCK_SIZE);
+ iowrite32(chip->ecc.size, denali->flash_reg + CFG_LAST_DATA_BLOCK_SIZE);
+ /* chip->ecc.steps is set by nand_scan_tail(); not available here */
+ iowrite32(mtd->writesize / chip->ecc.size,
+ denali->flash_reg + CFG_NUM_DATA_BLOCKS);
+
mtd_set_ooblayout(mtd, &denali_ooblayout_ops);
- /* override the default read operations */
- chip->ecc.size = ECC_SECTOR_SIZE;
chip->ecc.read_page = denali_read_page;
chip->ecc.read_page_raw = denali_read_page_raw;
chip->ecc.write_page = denali_write_page;
diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h
index ec00485..7c24d82 100644
--- a/drivers/mtd/nand/denali.h
+++ b/drivers/mtd/nand/denali.h
@@ -265,6 +265,14 @@
#define ECC_COR_INFO__MAX_ERRORS 0x007f
#define ECC_COR_INFO__UNCOR_ERR 0x0080
+#define CFG_DATA_BLOCK_SIZE 0x6b0
+
+#define CFG_LAST_DATA_BLOCK_SIZE 0x6c0
+
+#define CFG_NUM_DATA_BLOCKS 0x6d0
+
+#define CFG_META_DATA_SIZE 0x6e0
+
#define DMA_ENABLE 0x700
#define DMA_ENABLE__FLAG 0x0001
@@ -307,8 +315,6 @@
#define MODE_10 0x08000000
#define MODE_11 0x0C000000
-#define ECC_SECTOR_SIZE 512
-
struct nand_buf {
int head;
int tail;
@@ -347,6 +353,8 @@ struct denali_nand_info {
#define DENALI_CAP_HW_ECC_FIXUP BIT(0)
#define DENALI_CAP_DMA_64BIT BIT(1)
+#define DENALI_CAP_ECC_SIZE_512 BIT(2)
+#define DENALI_CAP_ECC_SIZE_1024 BIT(3)
extern int denali_init(struct denali_nand_info *denali);
extern void denali_remove(struct denali_nand_info *denali);
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
index df9ef36..1681a30 100644
--- a/drivers/mtd/nand/denali_dt.c
+++ b/drivers/mtd/nand/denali_dt.c
@@ -35,7 +35,8 @@ struct denali_dt_data {
};
static const struct denali_dt_data denali_socfpga_data = {
- .caps = DENALI_CAP_HW_ECC_FIXUP,
+ .caps = DENALI_CAP_HW_ECC_FIXUP |
+ DENALI_CAP_ECC_SIZE_512,
};
static const struct of_device_id denali_nand_dt_ids[] = {
diff --git a/drivers/mtd/nand/denali_pci.c b/drivers/mtd/nand/denali_pci.c
index ac84323..5202a11 100644
--- a/drivers/mtd/nand/denali_pci.c
+++ b/drivers/mtd/nand/denali_pci.c
@@ -85,6 +85,8 @@ static int denali_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
goto failed_remap_reg;
}
+ denali->caps |= DENALI_CAP_ECC_SIZE_512;
+
ret = denali_init(denali);
if (ret)
goto failed_remap_mem;
--
2.7.4
--
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 v3 09/37] mtd: nand: denali_dt: remove dma-mask DT property
From: Masahiro Yamada @ 2017-03-30 6:45 UTC (permalink / raw)
To: linux-mtd
Cc: Enrico Jorns, Artem Bityutskiy, Dinh Nguyen, Boris Brezillon,
Marek Vasut, Graham Moore, David Woodhouse, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, Masahiro Yamada, devicetree,
linux-kernel, Brian Norris, Richard Weinberger, Cyrille Pitchen,
Rob Herring, Mark Rutland
In-Reply-To: <1490856383-31560-1-git-send-email-yamada.masahiro@socionext.com>
The driver sets appropriate DMA mask. Delete the "dma-mask" DT
property. See [1] for negative comments for this binding.
[1] https://lkml.org/lkml/2016/2/8/57
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v3: None
Changes in v2: None
Documentation/devicetree/bindings/mtd/denali-nand.txt | 2 --
drivers/mtd/nand/denali_dt.c | 9 ---------
2 files changed, 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index 6f4ab4c..e593bbe 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -6,7 +6,6 @@ Required properties:
- reg : should contain registers location and length for data and reg.
- reg-names: Should contain the reg names "nand_data" and "denali_reg"
- interrupts : The interrupt number.
- - dm-mask : DMA bit mask
The device tree may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
@@ -20,5 +19,4 @@ nand: nand@ff900000 {
reg = <0xff900000 0x100000>, <0xffb80000 0x10000>;
reg-names = "nand_data", "denali_reg";
interrupts = <0 144 4>;
- dma-mask = <0xffffffff>;
};
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
index 9577bfd..b8a8284 100644
--- a/drivers/mtd/nand/denali_dt.c
+++ b/drivers/mtd/nand/denali_dt.c
@@ -46,8 +46,6 @@ static const struct of_device_id denali_nand_dt_ids[] = {
};
MODULE_DEVICE_TABLE(of, denali_nand_dt_ids);
-static u64 denali_dma_mask;
-
static int denali_dt_probe(struct platform_device *ofdev)
{
struct resource *denali_reg, *nand_data;
@@ -83,13 +81,6 @@ static int denali_dt_probe(struct platform_device *ofdev)
if (IS_ERR(denali->flash_mem))
return PTR_ERR(denali->flash_mem);
- if (!of_property_read_u32(ofdev->dev.of_node,
- "dma-mask", (u32 *)&denali_dma_mask)) {
- denali->dev->dma_mask = &denali_dma_mask;
- } else {
- denali->dev->dma_mask = NULL;
- }
-
dt->clk = devm_clk_get(&ofdev->dev, NULL);
if (IS_ERR(dt->clk)) {
dev_err(&ofdev->dev, "no clk available\n");
--
2.7.4
^ permalink raw reply related
* [PATCH v3 07/37] mtd: nand: denali_dt: enable HW_ECC_FIXUP for Altera SOCFPGA variant
From: Masahiro Yamada @ 2017-03-30 6:45 UTC (permalink / raw)
To: linux-mtd
Cc: Enrico Jorns, Artem Bityutskiy, Dinh Nguyen, Boris Brezillon,
Marek Vasut, Graham Moore, David Woodhouse, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, Masahiro Yamada, devicetree,
linux-kernel, Brian Norris, Richard Weinberger, Cyrille Pitchen,
Rob Herring, Mark Rutland
In-Reply-To: <1490856383-31560-1-git-send-email-yamada.masahiro@socionext.com>
There are various customizable parameters, so several variants for
this IP. A generic compatible like "denali,denali-nand-dt" is
useless. Moreover, there are multiple things wrong with this string.
(Refer to Rob's comment [1])
The "denali,denali-nand-dt" was added by Altera for the SOCFPGA port.
Replace it with a more specific string "altr,socfpga-denali-nand".
There are no users (in upstream) of the old compatible string.
The Denali IP on SOCFPGA incorporates the hardware ECC fixup engine.
So, this capability should be associated with the compatible.
[1] https://lkml.org/lkml/2016/12/1/450
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v3:
- Update git-log to mention there are no users of the old binding.
Changes in v2:
- Add caps flag to of_device_id data, not hard-code in driver code
- Add Altera-specific compatible.
Documentation/devicetree/bindings/mtd/denali-nand.txt | 5 +++--
drivers/mtd/nand/denali_dt.c | 14 ++++++++++----
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index b04d03a..6f4ab4c 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -1,7 +1,8 @@
* Denali NAND controller
Required properties:
- - compatible : should be "denali,denali-nand-dt"
+ - compatible : should be one of the following:
+ "altr,socfpga-denali-nand" - for Altera SOCFPGA
- reg : should contain registers location and length for data and reg.
- reg-names: Should contain the reg names "nand_data" and "denali_reg"
- interrupts : The interrupt number.
@@ -15,7 +16,7 @@ Examples:
nand: nand@ff900000 {
#address-cells = <1>;
#size-cells = <1>;
- compatible = "denali,denali-nand-dt";
+ compatible = "altr,socfpga-denali-nand";
reg = <0xff900000 0x100000>, <0xffb80000 0x10000>;
reg-names = "nand_data", "denali_reg";
interrupts = <0 144 4>;
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
index 293ddb8..9577bfd 100644
--- a/drivers/mtd/nand/denali_dt.c
+++ b/drivers/mtd/nand/denali_dt.c
@@ -33,11 +33,17 @@ struct denali_dt_data {
unsigned int caps;
};
-static const struct of_device_id denali_nand_dt_ids[] = {
- { .compatible = "denali,denali-nand-dt" },
- { /* sentinel */ }
- };
+static const struct denali_dt_data denali_socfpga_data = {
+ .caps = DENALI_CAP_HW_ECC_FIXUP,
+};
+static const struct of_device_id denali_nand_dt_ids[] = {
+ {
+ .compatible = "altr,socfpga-denali-nand",
+ .data = &denali_socfpga_data,
+ },
+ { /* sentinel */ }
+};
MODULE_DEVICE_TABLE(of, denali_nand_dt_ids);
static u64 denali_dma_mask;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 00/37] mtd: nand: denali: 2nd round of Denali NAND IP patch bomb
From: Masahiro Yamada @ 2017-03-30 6:45 UTC (permalink / raw)
To: linux-mtd
Cc: Mark Rutland, Boris Brezillon, Richard Weinberger, Dinh Nguyen,
Masahiro Yamada, Artem Bityutskiy, Cyrille Pitchen, linux-kernel,
Marek Vasut, devicetree, Rob Herring, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, Brian Norris, Enrico Jorns,
David Woodhouse, Graham Moore
This driver includes many problems.
One of the biggest one is a bunch of hard-coded parameters. This IP
has many parameters that can be customized when a delivery RTL is
generated. However, this driver was upstreamed by Intel, with
Intel parameters hard-coded. Later, Altera added denali_dt.c to use
this driver for embedded boards, but they did not fix the code in
denali.c So, this driver has never worked. Even some DT bindings
actually turned out wrong.
There are more problems: [1] The driver just retrieves the OOB area as-is
whereas the controller uses syndrome page layout. [2] Many NAND chip
specific parameters are hard-coded in the driver. [3] ONFi devices are
not working [4] It can not read Bad Block Marker
This patch series intends to solve those problems.
Outstanding changes are:
- Fix raw/oob callbacks for syndrome page layout
- Implement setup_data_interface() callback
- Fix/implement more commands for ONFi devices
- Allow to skip the driver internal bounce buffer
- Support PIO in case DMA is not supported
- Switch from ->cmdfunc over to ->cmd_ctrl
18 patches were merged at v2.
Here is the rest of the series.
v1: https://lkml.org/lkml/2016/11/26/144
v2: https://lkml.org/lkml/2017/3/22/804
Masahiro Yamada (37):
mtd: nand: relax ecc.read_page() return value for uncorrectable ECC
mtd: nand: denali: allow to override mtd->name from label DT property
mtd: nand: denali: remove meaningless pipeline read-ahead operation
mtd: nand: denali: fix bitflips calculation in handle_ecc()
mtd: nand: denali: fix erased page checking
mtd: nand: denali: support HW_ECC_FIXUP capability
mtd: nand: denali_dt: enable HW_ECC_FIXUP for Altera SOCFPGA variant
mtd: nand: denali: support 64bit capable DMA engine
mtd: nand: denali_dt: remove dma-mask DT property
mtd: nand: denali_dt: use pdev instead of ofdev for platform_device
mtd: nand: denali: allow to override revision number
mtd: nand: denali: support 1024 byte ECC step size
mtd: nand: denali: avoid hard-coding ecc.strength and ecc.bytes
mtd: nand: denali: support "nand-ecc-strength" DT property
mtd: nand: denali: remove Toshiba and Hynix specific fixup code
mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
mtd: nand: denali: set NAND_ECC_CUSTOM_PAGE_ACCESS
mtd: nand: denali: do not propagate NAND_STATUS_FAIL to waitfunc()
mtd: nand: denali: use BIT() and GENMASK() for register macros
mtd: nand: denali: remove unneeded find_valid_banks()
mtd: nand: denali: handle timing parameters by setup_data_interface()
mtd: nand: denali: rework interrupt handling
mtd: nand: denali: fix NAND_CMD_STATUS handling
mtd: nand: denali: fix NAND_CMD_PARAM handling
mtd: nand: denali: switch over to cmd_ctrl instead of cmdfunc
mtd: nand: denali: fix bank reset function
mtd: nand: denali: use interrupt instead of polling for bank reset
mtd: nand: denali: propagate page to helpers via function argument
mtd: nand: denali: merge struct nand_buf into struct denali_nand_info
mtd: nand: denali: use flag instead of register macro for direction
mtd: nand: denali: fix raw and oob accessors for syndrome page layout
mtd: nand: denali: support hardware-assisted erased page detection
mtd: nand: allocate aligned buffers if NAND_OWN_BUFFERS is unset
mtd: nand: allow drivers to request minimum alignment for passed
buffer
mtd: nand: denali: skip driver internal bounce buffer when possible
mtd: nand: denali: use non-managed kmalloc() for DMA buffer
mtd: nand: denali: enable bad block table scan
.../devicetree/bindings/mtd/denali-nand.txt | 24 +-
drivers/mtd/nand/denali.c | 1971 ++++++++++----------
drivers/mtd/nand/denali.h | 308 +--
drivers/mtd/nand/denali_dt.c | 90 +-
drivers/mtd/nand/denali_pci.c | 10 +-
drivers/mtd/nand/nand_base.c | 49 +-
include/linux/mtd/nand.h | 4 +-
7 files changed, 1234 insertions(+), 1222 deletions(-)
--
2.7.4
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v4 01/18] dt-bindings: power: battery: add constant-charge-current property
From: Quentin Schulz @ 2017-03-30 6:41 UTC (permalink / raw)
To: Liam Breck
Cc: Sebastian Reichel, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAKvHMgQf=Zod-F9SMPDDj5Eq3v=JHGh7uns-T_=ynQM0dMtEvw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On 29/03/2017 11:26, Liam Breck wrote:
> On Wed, Mar 29, 2017 at 12:54 AM, Quentin Schulz
> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> Hi,
>>
>> On 29/03/2017 09:39, Liam Breck wrote:
>>> On Wed, Mar 29, 2017 at 12:09 AM, Quentin Schulz
>>> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>>>> Hi Liam,
>>>>
>>>> On 29/03/2017 08:55, Liam Breck wrote:
>>>>> Hi Quentin,
>>>>>
>>>>> On Thu, Mar 16, 2017 at 12:42 AM, Liam Breck <liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org> wrote:
>>>>>> On Thu, Mar 16, 2017 at 12:03 AM, Quentin Schulz
>>>>>> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>>>>>>> Hi Liam,
>>>>>>>
>>>>>>> On 16/03/2017 07:27, Liam Breck wrote:
>>>>>>>> Hi Rob,
>>>>>>>>
>>>>>>>> On Wed, Mar 15, 2017 at 6:10 AM, Quentin Schulz
>>>>>>>> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>>>>>>>>> Hi Liam,
>>>>>>>>>
>>>>>>>>> On 15/03/2017 13:08, Liam Breck wrote:
>>>>>>>>>> I dropped most of the CCs, pls re-add anyone essential. Use Cc lines
>>>>>>>>>> in patch description to direct a patch to interested parties and
>>>>>>>>>> relevant lists. I don't want to see all 19 patches in this series.
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 15, 2017 at 3:55 AM, Quentin Schulz
>>>>>>>>>> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>>>>>>>>>>> This adds the constant-charge-current property to the list of optional
>>>>>>>>>>> properties of the battery.
>>>>>>>>>>>
>>>>>>>>>>> The constant charge current is critical for batteries as they can't
>>>>>>>>>>> handle all charge currents.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>>>>>>>>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> v4:
>>>>>>>>>>> - switch from constant-charge-current-microamp to constant-charge-microamp,
>>>>>>>>
>>>>>>>> Sebastian is on record supporting name alignment between DT:battery
>>>>>>>> properties and enum power_supply_property.
>>>>>>>>
>>>>>>>> Could you OK a change back to constant-charge-current-microamp in this patch?
>>>>>>>>
>>>>>>>> Note that the following could appear in DT:battery in future:
>>>>>>>>
>>>>>>>> constant-charge-current-microamp
>>>>>>>> constant-charge-current-max-microamp
>>>>>>>
>>>>>>> OK. I am actually setting max constant charge current and constant
>>>>>>> current charge with the same DT property so I might need to adapt my
>>>>>>> patches.
>>>>>>
>>>>>> I suspect you should set battery:*-current-max with DT, as -current is
>>>>>> "programmed by charger" so seems to be a stat, not a fixed
>>>>>> characteristic.
>>>>>
>>>>> Did you resolve this issue?
>>>>>
>>>>
>>>> Sorry, completely missed your first mail.
>>>>
>>>> Constant charge current is actually what I set in the PMIC. The maximum
>>>> constant charge current is completely PMIC-agnostic in my driver as it
>>>> is used to tell the user that (s)he shouldn't really have a constant
>>>> charge current over the maximum limit as the battery might not be able
>>>> to handle such high current.
>>>>
>>>> What I suggest is to have both properties in DT. I'll set the maximum as
>>>> I do today and we can give the user the ability to set a "default"
>>>> constant charge current (below maximum constant charge current) in the
>>>> DT. Maybe we do not want to recharge your battery with the maximum value
>>>> by default?
>>>
>>> The scope here is just static battery characteristics. For the battery
>>> node, I think constant-charge-current-max-microamp is the relevant
>>> term.
>>
>> If it's only for static battery characteristics, I agree.
>>
>>
>>> If we added both properties, one would be an alias for the
>>> other, which doesn't seem useful.
>
> Meaning if both properties describe static characteristics of the
> battery, they wouldn't have different meaning.
>
>> Hum. Not really an alias. In my driver, I have a maximum which avoids to
>> set a constant charge current higher than what the battery is supposed
>> to be able to handle. The maximum can be increased via sysfs if ever the
>> user decides to go wild (or if (s)he changes the battery for example).
>> The maximum is never input in any of PMIC registers, it is not dealing
>> with the PMIC at all.
>
> Using the battery's -max as the default for your user-adjustable max
> sounds sensible. However the user-adjustable max should perhaps appear
> in a custom sysfs attribute, not
> /sys/class.../constant_charge_current_max (see comment re regulator).
>
Why?
> If the battery changes, the DT battery node should also change, esp if
> its -max drops. I realize that's not nec trivial.
>
Disagree. That's definitely not user friendly.
>> If I have only the max constant charge current in the DT, I'll set the
>> max and constant charge current with the same DT entry. That's perfectly
>> fine.
>
> I assume the pmic ccc setting is adjustable via
> /sys/class.../constant_charge_current?
>
Yes, it is then limited by a user-modifiable constant_charge_current_max.
>> However, what I was thinking is to have a "default" value taken from DT
>> for constant charge current (which will be below maximum ccc) if ever
>> someone wants to set a maximum but use a lower ccc value. Anyway, I
>> guess it's more a "fancy" feature than a requirement (unlike max-ccc).
>
> Maybe a lower default ccc than battery's -max could be provided via a
> % value in the pmic DT node? Then multiply battery -max by that to set
> ccc.
>
That's battery-specific, why would you want to put it in the PMIC node?
>>> The pmic can report both independently of the battery characteristic,
>>> and take a driver-specific DT property for
>>> constant-charge-current-microamp which it applies if less than the
>>> battery's -max setting.
>>
>> Indeed.
>>
>>> Or you could set that in userspace via
>>> /sys/class.../constant_charge_current.
>>
>> The goal is to have both. The DT for default values (given by the
>> vendor/upstream) and sysfs for custom values (interesting if you don't
>> want to/can't recompile a DT.
>>
>>> The charger's -max value would
>>> be a characteristic of its regulator.
>>>
>>
>> I don't really understand what you mean by that.
>
> I believe the pmic's -max value is a characteristic of its electrical
> design, the max current it can deliver. The power_supply_class docs
> are not very clear - "maximum charge current supported by the power
> supply object".
>
This PMIC can deliver a maximum of 1.8A or 2.5A depending on the variant
for constant charge current but you do not want to easily allow your
user to put such a high value as the battery is most likely not able to
handle such a high current.
>
>>> Or am I missing something...?
>>>
>>>>> Rob & Sebastian want me to merge all items for
>>>>> bindings/power/supply/battery.txt. If I do that I'll also roll up
>>>>> their counterparts in power_supply_core.c and submit a patchset for
>>>>> those two files.
>>>>>
>>>>
>>>> I guess that adding the two properties make sense, don't you think?
>>>>
>>>> Also, could you Cc me on your next version of your patches? So I know
>>>> when to rebase and slightly rework my patches once your patch series is
>>>> merged.
>>>
>>> Surely.
>>>
>>>> Thanks,
>>>> Quentin
>>>>
>>>>>> You may program your charger's -current with the battery's
>>>>>> -current-max, of course.
>>>>>>
>>>>>> Note that your charger also has a -current-max characteristic, likely
>>>>>> different than your battery. You may not need that in DT tho.
>>>>>>
>>>>>>>> constant-charge-voltage-microvolt
>>>>>>>> constant-charge-voltage-max-microvolt
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>>>> Must be constant-charge-current-microamp for the reasons discussed in
>>>>>>>>>> battery.txt - consistency with sysfs names.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hum. Just nitpicking, but I disagree with the use of 'must'. IIRC there
>>>>>>>>> is nothing in the code that would require the property to be named after
>>>>>>>>> a property from the enum power_supply_property.
>>>>>>>>>
>>>>>>>>> I would say that you _want_ it to be named like that because it
>>>>>>>>> underlines the relation between the DT property and the actual impacted
>>>>>>>>> property in the power supply subsystem. I'm fine with this reason but in
>>>>>>>>> the end, the maintainer's opinion prevails (if (s)he does not want it,
>>>>>>>>> (s)he will not take it). So, basically, I actually don't mind either
>>>>>>>>> option and I see arguments on each side.
>>>>>>>>>
>>>>>>>>> So, just waiting for maintainer's opinion to make the final version of
>>>>>>>>> this patch.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Quentin
>>>>>>>>>
>>>>>>>>>> Also applies to power_supply_core.c patch.
>>>>>>>>>>
>>>>>>>>>> Rob: enum power_supply_property also lists constant-charge-voltage,
>>>>>>>>>> hence the -current
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> added in v3
>>>>>>>>>>>
>>>>>>>>>>> Documentation/devicetree/bindings/power/supply/battery.txt | 2 ++
>>>>>>>>>>> 1 file changed, 2 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>>>>>> index 0278617..9594e1e 100644
>>>>>>>>>>> --- a/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>>>>>> +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>>>>>> @@ -7,6 +7,7 @@ Optional Properties:
>>>>>>>>>>> - voltage-min-design-microvolt: drained battery voltage
>>>>>>>>>>> - energy-full-design-microwatt-hours: battery design energy
>>>>>>>>>>> - charge-full-design-microamp-hours: battery design capacity
>>>>>>>>>>> + - constant-charge-microamp: battery constant charge current
>>>>>>>>>>>
>>>>>>>>>>> Because drivers surface properties in sysfs using names derived
>>>>>>>>>>> from enum power_supply_property, e.g.
>>>>>>>>>>> @@ -30,6 +31,7 @@ Example:
>>>>>>>>>>> voltage-min-design-microvolt = <3200000>;
>>>>>>>>>>> energy-full-design-microwatt-hours = <5290000>;
>>>>>>>>>>> charge-full-design-microamp-hours = <1430000>;
>>>>>>>>>>> + constant-charge-microamp = <300000>;
>>>>>>>>>>> };
>>>>>>>>>>>
>>>>>>>>>>> charger: charger@11 {
>>>>>>>>>>> --
>>>>>>>>>>> 2.9.3
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Quentin Schulz, Free Electrons
>>>>>>>>> Embedded Linux and Kernel engineering
>>>>>>>>> http://free-electrons.com
>>>>>>>
>>>>>>> --
>>>>>>> Quentin Schulz, Free Electrons
>>>>>>> Embedded Linux and Kernel engineering
>>>>>>> http://free-electrons.com
>>>>
>>>> --
>>>> Quentin Schulz, Free Electrons
>>>> Embedded Linux and Kernel engineering
>>>> http://free-electrons.com
>>
>> --
>> Quentin Schulz, Free Electrons
>> Embedded Linux and Kernel engineering
>> http://free-electrons.com
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V11 6/6] thermal: bcm2835: add thermal driver for bcm2835 SoC
From: Stefan Wahren @ 2017-03-30 6:30 UTC (permalink / raw)
To: Eduardo Valentin
Cc: Frank Rowand, kernel-TqfNSX0MhmxHKSADF0wUEw, Eric Anholt,
Zhang Rui, Rob Herring, Florian Fainelli,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170330045725.GA12995-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
> Eduardo Valentin <edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> hat am 30. März 2017 um 06:57 geschrieben:
>
>
> On Tue, Mar 28, 2017 at 09:58:09PM -0700, Eduardo Valentin wrote:
> > On Sun, Mar 12, 2017 at 10:11:05PM +0000, Stefan Wahren wrote:
> > > Add basic thermal driver for bcm2835 SoC.
> > >
> > > This driver currently make sure that tsense HW block is set up
> > > correctly.
> > >
> > > Signed-off-by: Martin Sperl <kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
> > > Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> > > Acked-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
> >
> > I see no issue with this driver at this point.
> >
> > As I mentioned, the full series needs to go together. You either get an
> > Ack from OF maintainers, and I take the series, or you can add my
> >
> > Acked-by: Eduardo Valentin <edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >
> > after fixing the small comment from Nobuhiro.
> >
>
> Based on other drivers that require negative values, I assume patches 1
> and 2 of these series are needed, but more for enforcing the API, given
> that the current of-thermal driver still retrieves the negative values
> from DTB [1].
>
> [1] - https://patchwork.kernel.org/patch/9612613/
I can't see that the OMAP5 thermal driver is using thermal_zone_get_slope() [2]. I got the wrong values without patch 1 and 2. So i wouldn't rely on that statement. But i will doublecheck it.
[2] - http://elixir.free-electrons.com/ident?v=4.11-rc4&i=thermal_zone_get_slope
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] nvmem: imx-ocotp: add write support
From: Sascha Hauer @ 2017-03-30 6:16 UTC (permalink / raw)
To: Fabio Estevam
Cc: Richard Leitner, Sascha Hauer, Shawn Guo, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Srinivas Kandagatla, Maxime Ripard, dev-M/VWbR8SM2SsTnJN9+BGXg
In-Reply-To: <CAOMZO5DV+80np5qsq9JdKwmKFL1AkeqJ09S3o0XjQzAqYw0rYg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Mar 27, 2017 at 10:42:06AM -0300, Fabio Estevam wrote:
> [Adding Pengutronix folks and Shawn on Cc]
>
> On Mon, Mar 27, 2017 at 10:31 AM, Richard Leitner
> <richard.leitner-WcANXNA0UjBBDgjK7y7TUQ@public.gmane.org> wrote:
> > Implement write routine for OCOTP controller found in i.MX6 SoC's.
> > Furthermore add locking to the read function to prevent race conditions.
> > The write routine code is based on the fsl_otp driver from Freescale.
> >
> > Signed-off-by: Richard Leitner <richard.leitner-WcANXNA0UjBBDgjK7y7TUQ@public.gmane.org>
>
> Do we really want to have write support in the driver?
Why not? The fuses must be written somewhere and some like to do it
under Linux.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
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 RFC 1/3] thermal: allow hwmon devices to be created for of-thermal zones
From: Eduardo Valentin @ 2017-03-30 5:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Rob Herring, Mark Rutland, Andrew Lunn, Jason Cooper,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Gregory Clement, Zhang Rui,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sebastian Hesselbarth
In-Reply-To: <20170324144029.GG7909-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Hello,
On Fri, Mar 24, 2017 at 02:40:29PM +0000, Russell King - ARM Linux wrote:
> On Fri, Mar 24, 2017 at 01:23:13PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Mar 20, 2017 at 12:15:52PM -0500, Rob Herring wrote:
> > > On Sun, Mar 12, 2017 at 07:07:40PM +0000, Russell King wrote:
> > > > Allow hwmon devices to be optionally created for of-thermal zones,
> > > > rather than permanently denying them "in case" there is a hwmon
> > > > driver duplicating the thermal driver.
> > > >
> > > > Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
> > > > ---
> > > > Without this, "sensors" is unable to report the temperature of the
> > > > Dove SoC when it supports thermal zones.
> > > >
> > > > Documentation/devicetree/bindings/thermal/thermal.txt | 3 +++
> > > > arch/arm/boot/dts/dove.dtsi | 1 +
> > > > drivers/thermal/of-thermal.c | 3 ++-
> > > > 3 files changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
> > > > index 88b6ea1ad290..1478735fff85 100644
> > > > --- a/Documentation/devicetree/bindings/thermal/thermal.txt
> > > > +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> > > > @@ -175,6 +175,9 @@ containing trip nodes and one sub-node containing all the zone cooling maps.
> > > > 2000mW, while on a 10'' tablet is around
> > > > 4500mW.
> > > >
> > > > +- linux,hwmon: Allow Linux to create hwmon devices for the thermal
> > > > + Type: bool zone.
> > > > +
> > > > Note: The delay properties are bound to the maximum dT/dt (temperature
> > > > derivative over time) in two situations for a thermal zone:
> > > > (i) - when passive cooling is activated (polling-delay-passive); and
> > > > diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
> > > > index 40fb98687230..00f5971cd039 100644
> > > > --- a/arch/arm/boot/dts/dove.dtsi
> > > > +++ b/arch/arm/boot/dts/dove.dtsi
> > > > @@ -804,6 +804,7 @@
> > > >
> > > > thermal-zones {
> > > > soc-thermal {
> > > > + linux,hwmon;
New DT properties have to get an Ack from OF maintainers.
> > >
> > > I'd prefer to see a black or white list of sensor compatibles here. Then
> > > the dtb doesn't need to change if things move between hwmon and thermal
> > > zones.
> >
> > I'm not sure what you mean, and I can't see how that would be coded up.
> > The thermal layer doesn't give the option of individually selecting
> > which sensors have hwmon stuff created - it seems to be all or nothing.
> > I suspect what you're asking would require something of a rewrite of
> > the thermal code. The sensors are registered completely independently
> > of parsing the thermal zone data.
>
I agree here that Rob could have been more clear. Maybe he just wants to
avoid DTB changes if the driver decides to move from one subsystem to
the other.
> Okay, I'm convinced that what you're asking for (if I'm understanding
> correctly) is just not possible with how the thermal code is (horribly)
> architected at the moment.
>
> While trying to understand how all the thermal zone stuff fits together,
> I found this comment:
>
> /* For now, thermal framework supports only 1 sensor per zone */
> ret = of_parse_phandle_with_args(child, "thermal-sensors",
> "#thermal-sensor-cells",
> 0, &sensor_specs);
>
> so it's really not setup to deal with multiple sensors in DT right now
> (and there's no checking by the code that this is even the case.)
>
Yes, the thermal core code still does not really support multiple
sensors per zone. Its original design decision to have one sensor
representing one zone is still kept, even though there has been attempts
to change this. So, the of thermal code, although the DT thermal
descriptors support multiple sensors per zone, is still limited to one
sensor per zone, otherwise it would be pretty much a fork from thermal
core.
> The way the code is architected, the thermal zone devices and hwmon
> support is setup _completely_ independently from attaching the single
> sensor to the zone - the setup of the thermal zone devices and
> registering the sysfs entry happens before the sensors.
>
> The hwmon support is coded such that there is one hwmon device for all
> thermal zones. Each thermal zone device exports exactly one hwmon
> temperature sensor value with one set of trip points.
>
Based on git log, the hwmon support was historically written some time
before some of the recent changes on the hwmon subsystem. Looking at
both of them now, I must say the thermal_hwmon.c needs to be rewritten,
given that most of the sysfs interfaces are already handled by the hwmon
core. Also, there seams to be thermal subsystem awareness now on hwmon
core.
> A thermal zone device can support multiple sensors, but from the code
> and the above comment, the code does not support this - the sensors
> are not individually exported through hwmon.
As I mentioned above, the DT thermal descriptor does not limit the
relationship to 1:1, but the code is limited, yes.
>
> So, I think what you're asking for is not possible and is based upon
> a mis-understanding - thermal does not export sensors, but exports the
> _zone_ itself as a hwmon sensor. The zone temperature is exported,
> along with its thresholds.
>
> Obviously, the separation of thermal vs hwmon is purely a Linux
> phenomenon, and I've wondered why people have to rewrite hwmon drivers
> as thermal drivers just to make use of the thermal subsystem - it seems
> to me like NIH syndrome. I can't see why hwmon isn't able to export
> individual temperature sensors to thermal and have thermal import the
> values from there.
>
Not sure if I got this point, but I do not see drivers being rewritten.
That is more like, organically, some drivers went into hwmon, some went
into thermal subsystem. I believe most of the drivers in the thermal
subsystem decided to go that route due to the control algorithm to keep
up on silicon temperature, given that most of them are on zones to
control temperature of cores.
> For example, you could have a hwmon device that has multiple temperature
> sensors (some do) which monitor different parts of the system, and a
> hwmon device should be able to be incorporated into a thermal zone for
> management.
>
I think this is the idea behind the most recent changes related to
thermal on the hwmon core, so hwmon temperature sensors could be exposed
as zones, and therefore, system engineers could benefit of the
temperature control in kernel. But I frankly did not really use this
late support to really judge to which extent we get on the control.
> That doesn't seem possible, you have to implement a thermal driver to
> interface your sensor to the thermal stuff, and then have the _zone_
> statistics exported through hwmon.
>
> If you want individual sensors exported, you have to implement a driver
> which has a dual-personality, it has to register with hwmon and thermal.
>
> I'd say that, arguably, the whole "no_hwmon" thing in thermal is also
> wrong - it may _seem_ to be correct because thermal only supports one
> sensor, and we don't want such a dual-personality driver to have two
> entries in sysfs, but that's rather moot when you consider that one is
> exporting the zone (which has DT configured thresholds) and one is
> exporting the sensor itself.
>
> So, my conclusion is that this is all rather messed up, and certainly
> beyond my willingness to put in a lot of effort, creating lots of
> patches to try and bring the code to a point where what you're asking
> for is possible (iow, where we export individual sensors to hwmon,
> and make individual sensors exportable.)
>
> Therefore, I believe that my implementation is entirely reasonable -
> the linux,hwmon flag indicates whether the state of the thermal _zone_
> (not the _sensors_) should be exported via hwmon.
>
Yeah, here your patch seams to be willing to use the thermal_hwmon
support, which goes from thermal subsystem to hwmon. And yes, the
no_hwmon, in this case, is used to avoid having two hwmon sysfs entry
for the same sensor, one coming from a real hwmon driver, another one
exported from the thermal zone.
The only reason one would still want to have both hwmon interfaces, it
would be in case a thermal zone has, for example, some extrapolation
rule defined in DT, and therefore reading the raw hwmon sysfs entry
would not necessarily mean you have the same thermal zone temperature
value. Then again, the zone temperature value can still, be read from
the thermal zone sysfs entry. But,...
Thinking of this use case, and considering that more and more drivers
are now using extrapolation rules on DT, at least the simple linear
extrapolation, then I would suggest simply always adding the hwmon interface
from of thermal, instead. In this way, userspace that knows only about
hwmon entries may be able to know of the raw values and the extrapolated
values based on the zone. Then again, this needs to be clear to avoid
confusion, so people understand the differentiation.
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
--
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
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