* Re: [PATCH 7/9] pinctrl: samsung: Add property to mark pad state as suitable for power down
From: Krzysztof Kozlowski @ 2016-12-30 15:05 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Krzysztof Kozlowski, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, Sylwester Nawrocki,
Linus Walleij, Tomasz Figa, Ulf Hansson,
Bartlomiej Zolnierkiewicz, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <bad5ef6a-6132-2029-8581-2e8b27f7a2bd-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Fri, Dec 30, 2016 at 12:55:27PM +0100, Marek Szyprowski wrote:
> Hi Krzysztof,
>
> On 2016-12-27 16:33, Krzysztof Kozlowski wrote:
> > On Tue, Dec 27, 2016 at 11:30:57AM +0100, Marek Szyprowski wrote:
> > > On 2016-12-25 20:19, Krzysztof Kozlowski wrote:
> > > > On Fri, Dec 23, 2016 at 01:24:47PM +0100, Marek Szyprowski wrote:
> > > > > Add support for special property "samsung,off-state", which indicates a special
> > > > > state suitable for device's "sleep" state. Its pin values/properties should
> > > > > match the configuration in power down mode. It indicates that pin controller
> > > > > can notify runtime power management subsystem, that it is ready for runtime
> > > > > suspend if its all pins are configured for such state. This in turn might
> > > > > allow to turn respective power domain off to reduce power consumption.
> > > > >
> > > > > Signed-off-by: Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> > > > > ---
> > > > > Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 8 ++++++++
> > > > > drivers/pinctrl/samsung/pinctrl-samsung.c | 4 ++++
> > > > > drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
> > > > > 3 files changed, 13 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> > > > > index b7bd2e12a269..354eea0e7798 100644
> > > > > --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> > > > > +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> > > > > @@ -105,6 +105,7 @@ Required Properties:
> > > > > - samsung,pin-drv: Drive strength configuration.
> > > > > - samsung,pin-pud-pdn: Pull up/down configuration in power down mode.
> > > > > - samsung,pin-drv-pdn: Drive strength configuration in power down mode.
> > > > > + - samsung,off-state: Mark this configuration as suitable for bank power off.
> > > > > The values specified by these config properties should be derived from the
> > > > > hardware manual and these values are programmed as-is into the pin
> > > > > @@ -113,6 +114,13 @@ Required Properties:
> > > > > Note: A child should include atleast a pin function selection property or
> > > > > pin configuration property (one or more) or both.
> > > > > + Note: Special property "samsung,off-state" indicates that this state can
> > > > > + be used for device's "sleep" pins state. Its pin values/properties should
> > > > > + match the configuration in power down mode.
> > > > Why power down values cannot be used for sleep state? Why you need
> > > > separate pin control state? If pins values should match power down
> > > > configuration, then they could just be added to default state, couldn't
> > > > they?
> > > Separate sleep state is needed because of the pin control bindings and
> > > design.
> > >
> > > A separate sleep state is required to let pin control client driver (in this
> > > case
> > > Exynos I2S driver) let to choose when it is okay to switch pads into sleep
> > > state and I see no other way to achieve this.
> > Maybe the pinctrl API should be extended for this? Doing this in DTS
> > just for purpose of passing information between drivers (consumer and
> > provider) looks odd.
>
> Well, I don't know if it is odd or not, but that's how it is used now and I
> see
> no reason to reinvent wheel. Please check it yourself:
> $ git grep \"sleep\" arch/arm/boot/dts | wc -l
> 101
These drivers, at least not all of them, are not using the existence of
sleep mode configuration as a indication of possible runtime sleep. You
are mixing here different ideas.
>
> > Anyway, you are proposing a new binding so please Cc devicetree mailing
> > list and device tree maintainers.
>
> I'm just using the generic pinctrl bindings, but it might make some sense to
> add a note to Exynos i2s driver that a sleep pin control state is needed if
> one wants to get power domain to be turned off.
The samsung,off-state is a extension of the existing binding, so please
Cc the devicetree and maintainers. Why you see a problem in it?
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches
From: Jonathan Cameron @ 2016-12-30 15:03 UTC (permalink / raw)
To: Lars-Peter Clausen, Geert Uytterhoeven, Rob Herring
Cc: Bartosz Golaszewski, Hartmut Knaack, Peter Meerwald-Stadler,
Mark Rutland, linux-iio@vger.kernel.org, linux-devicetree, LKML,
Kevin Hilman, Patrick Titiano, Neil Armstrong, Linus Walleij,
Alexandre Courbot, linux-gpio, Sebastian Reichel, linux-pm,
Mark Brown, Liam Girdwood
In-Reply-To: <505b7c02-e7dd-b0a5-8009-dca9101b0dd4@metafoo.de>
On 23/12/16 11:40, Lars-Peter Clausen wrote:
> On 12/23/2016 10:07 AM, Geert Uytterhoeven wrote:
>> BTW, I'm not an IIO expert, but from my limited knowledge, it looks like "O"
>> support in IIO is limited to DACs?
>
> Depends on what you categorize as DACs. There are also
> potentiometer/rheostat drivers. They are kind of like DACs but the unit you
> control are ohm, rather than current or voltage.
Though they are still in staging there are also things like function generators.
I've been mulling doing a driver for the st-powerstep01 parts as well which
is a smart stepper motor controller. At that level we'd need to start describing
the connected stepper motors in DT :) Whole chunk of API to define to do that
though - might well take longer than writing the driver.
So in practice yeah - dac like things, but then on the input side they are almost
all really ADCs with some funny analog stuff on the front end ;)
Arguably switches are 1 bit DACs ;)
The distinction here is whether 'what is passing through' the device is knowable.
So regulators and your power switch are well described. A relay less so unless
we know what load it is switching...
+ it's IIO. We are open to almost anything as long as we aren't stepping on
any toes!
Jonathan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v2 4/5] arm64: dts: exynos5433: Add bus dt node using VDD_INT for Exynos5433
From: Krzysztof Kozlowski @ 2016-12-30 14:51 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Krzysztof Kozlowski, javier, kgene, robh+dt, s.nawrocki,
tomasz.figa, myungjoo.ham, kyungmin.park, devicetree,
linux-samsung-soc, linux-arm-kernel, linux-kernel
In-Reply-To: <5865B165.3010203@samsung.com>
On Fri, Dec 30, 2016 at 09:59:17AM +0900, Chanwoo Choi wrote:
> Hi Krzysztof,
>
> On 2016년 12월 09일 02:52, Krzysztof Kozlowski wrote:
> > On Thu, Dec 08, 2016 at 01:58:10PM +0900, Chanwoo Choi wrote:
> >> This patch adds the bus nodes using VDD_INT for Exynos5433 SoC.
> >> Exynos5433 has the following AMBA AXI buses to translate data
> >> between DRAM and sub-blocks.
> >>
> >> Following list specify the detailed correlation between sub-block and clock:
> >> - CLK_ACLK_G2D_{400|266} : Bus clock for G2D (2D graphic engine)
> >> - CLK_ACLK_MSCL_400 : Bus clock for MSCL (Memory to memory Scaler)
> >> - CLK_ACLK_GSCL_333 : Bus clock for GSCL (General Scaler)
> >> - CLK_SCLK_JPEG_MSCL : Bus clock for JPEG
> >> - CLK_ACLK_MFC_400 : Bus clock for MFC (Multi Format Codec)
> >> - CLK_ACLK_HEVC_400 : Bus clock for HEVC (High Efficient Video Codec)
> >> - CLK_ACLK_BUS0_400 : NoC(Network On Chip)'s bus clock for PERIC/PERIS/FSYS/MSCL
> >> - CLK_ACLK_BUS1_400 : NoC's bus clock for MFC/HEVC/G3D
> >> - CLK_ACLK_BUS2_400 : NoC's bus clock for GSCL/DISP/G2D/CAM0/CAM1/ISP
> >>
> >> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> >> ---
> >> arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 197 +++++++++++++++++++++++++
> >> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 1 +
> >> 2 files changed, 198 insertions(+)
> >> create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
> >
> > For the reference:
> > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> >
> > I'll queue it for v4.11, after this merge window.
>
> Could you please pick this patch3/4/5?
> These patches were already reviewed by you.
Not yet. I wanted to apply them few days ago but arm64 build is broken
in 4.10-rc1 so I cannot auto-build them in my system. The arm64 is fixed
already so I will apply them on top of 4.10-rc2 (when released).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Heinrich Schuchardt @ 2016-12-30 14:51 UTC (permalink / raw)
To: Neil Armstrong, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483105232-6242-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 12/30/2016 02:40 PM, Neil Armstrong wrote:
> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
> this patch adds this reserved zone and redefines the usable memory range.
>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> Changes since v1 at [1] :
> - Renamed reg into linux,usable-memory to ovveride u-boot memory
> - only kept secmon memory zone
>
> [1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
>
> arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12 ++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +-
> 11 files changed, 22 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> index 7a078be..ca3c7fa 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> @@ -56,7 +56,7 @@
>
> memory@0 {
> device_type = "memory";
> - reg = <0x0 0x0 0x0 0x80000000>;
> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
> };
>
> vddio_boot: regulator-vddio_boot {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> index eada0b5..7f244b5 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -55,6 +55,18 @@
> #address-cells = <2>;
> #size-cells = <2>;
>
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* global autoconfigured region for contiguous allocations */
This comment does not make sense here. It is what you would write over a
compatible to "shared-dma-pool" region. Cf. hi6220-hikey.dts
I suggest you use
/* Amlogic Meson GXBB/GXL/GXM secure monitor reserved memory */
instead.
Doesn't firmware/meson/meson_sm.c already reserve a communication area
to secmon with quite a different address range?
So where is this new region secmon set up? And where is it used?
Best regards
Heinrich
> + secmon: secmon {
> + reg = <0x0 0x10000000 0x0 0x200000>;
> + no-map;
> + };
> + };
> +
> cpus {
> #address-cells = <0x2>;
> #size-cells = <0x0>;
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> index 4cbd626..c7f008a 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> @@ -62,7 +62,7 @@
>
> memory@0 {
> device_type = "memory";
> - reg = <0x0 0x0 0x0 0x40000000>;
> + linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
> };
>
> leds {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 238fbea..546cbe4 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -61,7 +61,7 @@
>
> memory@0 {
> device_type = "memory";
> - reg = <0x0 0x0 0x0 0x80000000>;
> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
> };
>
> usb_otg_pwr: regulator-usb-pwrs {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> index 4a96e0f..1fdf6da 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -55,7 +55,7 @@
>
> memory@0 {
> device_type = "memory";
> - reg = <0x0 0x0 0x0 0x40000000>;
> + linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
> };
>
> usb_pwr: regulator-usb-pwrs {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
> index 62fb496..6ac5c89 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
> @@ -50,6 +50,6 @@
>
> memory@0 {
> device_type = "memory";
> - reg = <0x0 0x0 0x0 0x80000000>;
> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
> };
> };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
> index 9a9663a..58be8b4 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
> @@ -50,6 +50,6 @@
>
> memory@0 {
> device_type = "memory";
> - reg = <0x0 0x0 0x0 0x40000000>;
> + linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
> };
> };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
> index 2fe167b..010cb29 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
> @@ -50,6 +50,6 @@
>
> memory@0 {
> device_type = "memory";
> - reg = <0x0 0x0 0x0 0x80000000>;
> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
> };
> };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> index cea4a3e..fb4a89b 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> @@ -60,7 +60,7 @@
>
> memory@0 {
> device_type = "memory";
> - reg = <0x0 0x0 0x0 0x80000000>;
> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
> };
>
> vddio_card: gpio-regulator {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
> index 9639f01..908894c 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
> @@ -59,7 +59,7 @@
>
> memory@0 {
> device_type = "memory";
> - reg = <0x0 0x0 0x0 0x80000000>;
> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
> };
> };
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> index 5a337d3..2077385 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> @@ -62,7 +62,7 @@
>
> memory@0 {
> device_type = "memory";
> - reg = <0x0 0x0 0x0 0x80000000>;
> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
> };
>
> vddio_boot: regulator-vddio-boot {
>
--
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: [PATCHv2 0/5] Add generic pinctrl helpers for managing groups and function
From: Linus Walleij @ 2016-12-30 14:39 UTC (permalink / raw)
To: Tony Lindgren, Gary Bisson
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <20161227172003.6517-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Tue, Dec 27, 2016 at 6:19 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> Here are some changes to add generic helpers for managing pinctrl groups and
> functions.
I applied it, screwed around with it and pushed to the build servers to see
if it survived.
I really like the look of this and I hope lots of driver start to use it.
Gary, I just applied your radix patches for i.MX, can you look if you can
use the GENERIC_PINCTRL_GROUPS and GENERIC_PINMUX_FUCNTIONS
that Tony invented and that I just merged to my devel branch in the
pinctrl tree?
It seems the i.MX could just reuse this right off and slim down quite a bit
but the devil is in the details.
Yours,
Linus Walleij
--
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 v7 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
From: M'boumba Cedric Madianga @ 2016-12-30 14:36 UTC (permalink / raw)
To: Linus Walleij
Cc: Uwe Kleine-König, Wolfram Sang, Rob Herring, Maxime Coquelin,
Alexandre Torgue, Patrice Chotard, Russell King,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdaNyL2iV+risLudW=O55w81-AuEZhMwRu9NLdXpnC2r1w@mail.gmail.com>
Hi Linus,
2016-12-30 10:07 GMT+01:00 Linus Walleij <linus.walleij@linaro.org>:
> On Fri, Dec 23, 2016 at 2:09 PM, M'boumba Cedric Madianga
> <cedric.madianga@gmail.com> wrote:
>> 2016-12-22 20:11 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
>>> On Thu, Dec 22, 2016 at 02:35:02PM +0100, M'boumba Cedric Madianga wrote:
>>>> @@ -337,6 +350,16 @@
>>>> slew-rate = <2>;
>>>> };
>>>> };
>>>> +
>>>> + i2c1_pins_b: i2c1@0 {
>>>> + pins1 {
>>>> + pinmux = <STM32F429_PB9_FUNC_I2C1_SDA>;
>>>> + drive-open-drain;
>>>> + };
>>>> + pins2 {
>>>> + pinmux = <STM32F429_PB6_FUNC_I2C1_SCL>;
>>>> + };
>>>
>>> the second doesn't need the open-drain property? Why?
>>
>> I thought that open-drain was only needed for SDA line.
>> But after double-checking I2C specification, it seems that SDA and SCL
>> lines need open-drain or open-collector to perform the wired-AND
>> function.
>
> I think I2C SDA/SCL must be open drain by definition.
>
> It also requires pull-up resistors, I guess you have these mounted on the board
> so you do not need pull-up from the pin controller?
Yes, I have 1 pull-up resistor of 1,5K ohm for each line (SDA & SCL)
on the board
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH 5/5] pinctrl: single: Use generic pinmux helpers for managing functions
From: Linus Walleij @ 2016-12-30 14:35 UTC (permalink / raw)
To: Tony Lindgren
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <20161227172003.6517-6-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Tue, Dec 27, 2016 at 6:20 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> We can now drop the driver specific code for managing functions.
>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Patch applied.
> - select PINMUX
> + select GENERIC_PINMUX
Replaced this with GENERIC_PINMUX_FUNCTIONS
Yours,
Linus Walleij
--
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 4/5] pinctrl: single: Use generic pinctrl helpers for managing groups
From: Linus Walleij @ 2016-12-30 14:32 UTC (permalink / raw)
To: Tony Lindgren
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Linux-OMAP
In-Reply-To: <20161227172003.6517-5-tony@atomide.com>
On Tue, Dec 27, 2016 at 6:20 PM, Tony Lindgren <tony@atomide.com> wrote:
> We can now drop the driver specific code for managing groups.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Patch applied!
> + select GENERIC_PINCTRL
Replaced this with GENERIC_PINCTRL_GROUPS
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/5] pinctrl: core: Add generic pinctrl functions for managing groups
From: Linus Walleij @ 2016-12-30 14:28 UTC (permalink / raw)
To: Tony Lindgren
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <20161227172003.6517-4-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Tue, Dec 27, 2016 at 6:20 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> We can add generic helpers for function handling for cases where the pin
> controller driver does not need to use static arrays.
>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Patch applied.
> +config GENERIC_PINMUX
> + bool
> + select PINMUX
I renamed this GENERIC_PINMUX_FUNCTIONS
> + INIT_RADIX_TREE(&pctldev->pin_function_tree, GFP_KERNEL);
#ifdefed this
> + struct radix_tree_root pin_function_tree;
> unsigned int num_groups;
> + unsigned int num_functions;
#ifdefed these
> /**
> + * struct function_desc - generic function descriptor
> + * @name: name of the function
> + * @group_names: array of pin group names
> + * @num_group_names: number of pin group names
> + * @data: pin controller driver specific data
> + */
> +struct function_desc {
> + const char *name;
> + const char **group_names;
> + int num_group_names;
> + void *data;
> +};
And moved this into pinmux.h
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6q-utilite-pro: enable 2nd display pipeline
From: Shawn Guo @ 2016-12-30 14:27 UTC (permalink / raw)
To: christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
grinberg-UTxiZqZC01RS1MOuV/RT9w, fabio.estevam-3arQi8VN3Tc
In-Reply-To: <ec9676f344eb4786a28a3c7b969f0e94-gtPewvpZjL8umhiu9RXYRl5UTUQ924AY@public.gmane.org>
On Fri, Dec 02, 2016 at 03:37:22PM +0100, christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org wrote:
> From: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>
>
> Apart from the already enabled Designware HDMI port, the Utilite Pro
> has a second display pipeline which has the following shape:
>
> IPU1 DI0 --> Parallel display --> tfp410 rgb24 to DVI encoder
> --> HDMI connector.
> Enable support for it.
>
> In addition, since this pipeline is hardwired to IPU1, sever the link
> between IPU1 and the SoC-internal Designware HDMI encoder forcing the
> latter to be connected to IPU2 instead of IPU1. Otherwise, it is not
> possible to drive both displays at high resolution due to the bandwidth
> limitations of a single IPU.
>
> Signed-off-by: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>
@Philipp, can you help review the changes?
> ---
>
> Hi all,
>
> the removal of the link between IPU1 and the Designware HDMI encoder is the
> result of a discussion I had with Philipp Zabel:
>
> https://lists.freedesktop.org/archives/dri-devel/2016-November/125399.html .
>
> Altough it is not possible to connect anything else to IPU1 on the Utilite, this
> approach has at least one disadvantage: if the resolution is low enough such
> that a single IPU can handle both displays then muxing both displays to IPU1
> would reduce the power consumption.
>
> However, IMHO omitting the link IPU1 <--> DW HDMI is still the preferrable
> solution since I'm not aware of any OS/driver that is capable of switching IPUs
> or can handle the bandwidth limitation in a sane way. In particular, Linux is
> unusable when both displays are supposed to be driven at high resolution and
> both muxing options for the DW HDMI are available (this is not a userspace
> issue; the system becomes almost unresponsive as soon as the kernel sets the
> initial resolution).
>
> Cheers,
> Christopher
>
> P.S.: this patch depends on the tfp410 bridge driver which has recently been
> merged into drm-next.
v4.10-rc1 has the driver, so the dependency is gone now, I guess.
>
> arch/arm/boot/dts/imx6q-utilite-pro.dts | 115 ++++++++++++++++++++++++++++++++
> 1 file changed, 115 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> index 2200994..69bdd82 100644
> --- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
> +++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> @@ -59,6 +59,33 @@
> rtc1 = &snvs_rtc;
> };
>
> + encoder {
> + compatible = "ti,tfp410";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + tfp410_in: endpoint {
> + remote-endpoint = <¶llel_display_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + tfp410_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> + };
> + };
> +
> gpio-keys {
> compatible = "gpio-keys";
> pinctrl-names = "default";
> @@ -72,6 +99,19 @@
> };
> };
>
> + hdmi-connector {
> + compatible = "hdmi-connector";
> +
The newline is unnecessary.
> + type = "a";
> + ddc-i2c-bus = <&i2c_dvi_ddc>;
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&tfp410_out>;
> + };
> + };
> + };
> +
> i2cmux {
> compatible = "i2c-mux-gpio";
> pinctrl-names = "default";
> @@ -105,8 +145,46 @@
> #size-cells = <0>;
> };
> };
> +
> + parallel-display {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ipu1>;
> +
Ditto
I can fix them up if I get a Reviewed-by tag from Philipp on this
version.
Shawn
> + interface-pix-fmt = "rgb24";
> +
> + port@0 {
> + reg = <0>;
> +
> + parallel_display_in: endpoint {
> + remote-endpoint = <&ipu1_di0_disp0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + parallel_display_out: endpoint {
> + remote-endpoint = <&tfp410_in>;
> + };
> + };
> + };
> };
>
> +/*
> + * A single IPU is not able to drive both display interfaces available on the
> + * Utilite Pro at high resolution due to its bandwidth limitation. Since the
> + * tfp410 encoder is wired up to IPU1, sever the link between IPU1 and the
> + * SoC-internal Designware HDMI encoder forcing the latter to be connected to
> + * IPU2 instead of IPU1.
> + */
> +/delete-node/&ipu1_di0_hdmi;
> +/delete-node/&hdmi_mux_0;
> +/delete-node/&ipu1_di1_hdmi;
> +/delete-node/&hdmi_mux_1;
> +
> &hdmi {
> ddc-i2c-bus = <&i2c2>;
> status = "okay";
> @@ -151,6 +229,39 @@
> >;
> };
>
> + pinctrl_ipu1: ipu1grp {
> + fsl,pins = <
> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x38
> + MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0x38
> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x38
> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x38
> + MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0x38
> + MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x38
> + MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x38
> + MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x38
> + MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x38
> + MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x38
> + MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x38
> + MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x38
> + MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x38
> + MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x38
> + MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x38
> + MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x38
> + MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x38
> + MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x38
> + MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x38
> + MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x38
> + MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x38
> + MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0x38
> + MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0x38
> + MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0x38
> + MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0x38
> + MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0x38
> + MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0x38
> + MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0x38
> + >;
> + };
> +
> pinctrl_uart2: uart2grp {
> fsl,pins = <
> MX6QDL_PAD_GPIO_7__UART2_TX_DATA 0x1b0b1
> @@ -194,6 +305,10 @@
> };
> };
>
> +&ipu1_di0_disp0 {
> + remote-endpoint = <¶llel_display_in>;
> +};
> +
> &pcie {
> pcie@0,0 {
> reg = <0x000000 0 0 0 0>;
> --
> 2.10.2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/5] pinctrl: core: Add generic pinctrl functions for managing groups
From: Linus Walleij @ 2016-12-30 14:12 UTC (permalink / raw)
To: Tony Lindgren
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <20161227172003.6517-3-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Tue, Dec 27, 2016 at 6:20 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> We can add generic helpers for pin group handling for cases where the pin
> controller driver does not need to use static arrays.
>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Patch applied.
> +config GENERIC_PINCTRL
> + bool
Then I renamed *this* to GENERIC_PINCTRL_GROUPS.
(Not the other patch, I got confused because gmail threads the
second and third patch together, sorry.)
Let's see if I manage to rebase the next patch on this.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/5] pinctrl: core: Add generic pinctrl functions for managing groups
From: Linus Walleij @ 2016-12-30 14:09 UTC (permalink / raw)
To: Tony Lindgren
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Linux-OMAP
In-Reply-To: <20161227172003.6517-4-tony@atomide.com>
On Tue, Dec 27, 2016 at 6:20 PM, Tony Lindgren <tony@atomide.com> wrote:
> We can add generic helpers for function handling for cases where the pin
> controller driver does not need to use static arrays.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Patch applied!
> +config GENERIC_PINMUX
> + bool
> + select PINMUX
I applied the first that had GENERIC_PINCTRL instead,
Then I went in and renamed this GENERIC_PINCTRL_GROUPS
since that is what it's all about.
Sent out as separate patch!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs
From: Linus Walleij @ 2016-12-30 13:46 UTC (permalink / raw)
To: Tony Lindgren
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Linux-OMAP
In-Reply-To: <20161227172003.6517-2-tony@atomide.com>
On Tue, Dec 27, 2016 at 6:19 PM, Tony Lindgren <tony@atomide.com> wrote:
> Having the pin control framework call pin controller functions
> before it's probe has finished is not nice as the pin controller
> device driver does not yet have struct pinctrl_dev handle.
> Let's fix this issue by adding deferred work for late init. This is
> needed to be able to add pinctrl generic helper functions that expect
> to know struct pinctrl_dev handle. Note that we now need to call
> create_pinctrl() directly as we don't want to add the pin controller
> to the list of controllers until the hogs are claimed. We also need
> to pass the pinctrl_dev to the device tree parser functions as they
> otherwise won't find the right controller at this point.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Patch applied.
I felt the code path needed some extra comments so I sent those
as a separate patch.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Neil Armstrong @ 2016-12-30 13:40 UTC (permalink / raw)
To: heinrich.schuchardt-Mmb7MZpHnFY, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A
Cc: Neil Armstrong, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds this reserved zone and redefines the usable memory range.
Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
Changes since v1 at [1] :
- Renamed reg into linux,usable-memory to ovveride u-boot memory
- only kept secmon memory zone
[1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +-
11 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
index 7a078be..ca3c7fa 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -56,7 +56,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
vddio_boot: regulator-vddio_boot {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index eada0b5..7f244b5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -55,6 +55,18 @@
#address-cells = <2>;
#size-cells = <2>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* global autoconfigured region for contiguous allocations */
+ secmon: secmon {
+ reg = <0x0 0x10000000 0x0 0x200000>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <0x2>;
#size-cells = <0x0>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 4cbd626..c7f008a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -62,7 +62,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
leds {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 238fbea..546cbe4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -61,7 +61,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
usb_otg_pwr: regulator-usb-pwrs {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 4a96e0f..1fdf6da 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -55,7 +55,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
usb_pwr: regulator-usb-pwrs {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
index 62fb496..6ac5c89 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
@@ -50,6 +50,6 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
index 9a9663a..58be8b4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
@@ -50,6 +50,6 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
index 2fe167b..010cb29 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
@@ -50,6 +50,6 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
index cea4a3e..fb4a89b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
@@ -60,7 +60,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
vddio_card: gpio-regulator {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
index 9639f01..908894c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
@@ -59,7 +59,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index 5a337d3..2077385 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -62,7 +62,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
vddio_boot: regulator-vddio-boot {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 0/5] ARM: dts: boundary: remove hardcoded LVDS bus format
From: Shawn Guo @ 2016-12-30 13:37 UTC (permalink / raw)
To: Gary Bisson
Cc: fabio.estevam-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161202090843.22613-1-gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
On Fri, Dec 02, 2016 at 10:08:38AM +0100, Gary Bisson wrote:
> Gary Bisson (5):
> ARM: dts: imx6qdl-nit6xlite: remove hardcoded LVDS bus format
> ARM: dts: imx6qdl-nitrogen6_max: remove hardcoded LVDS bus format
> ARM: dts: imx6qdl-nitrogen6_som2: remove hardcoded LVDS bus format
> ARM: dts: imx6qdl-nitrogen6x: remove hardcoded LVDS bus format
> ARM: dts: imx6qdl-sabrelite: remove hardcoded LVDS bus format
I squashed them and applied, thanks.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433
From: Linus Walleij @ 2016-12-30 13:32 UTC (permalink / raw)
To: Andi Shyti
Cc: Chanwoo Choi, Tomasz Figa, Krzysztof Kozlowski,
Sylwester Nawrocki, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Javier Martinez Canillas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-samsung-soc, linux-kernel@vger.kernel.org, stable,
Andi Shyti
In-Reply-To: <20161230041421.24448-4-andi.shyti@samsung.com>
On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti <andi.shyti@samsung.com> wrote:
> Use the macros defined in include/dt-bindings/pinctrl/samsung.h
> instead of hardcoded values.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
These look fine, but that this and the other DTS patch through ARM SoC.
If you also need the headerfile patch (patch 2) to go through ARM SoC
that is fine,
I can take it out of pinctrl if you want.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/4] pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433
From: Linus Walleij @ 2016-12-30 13:30 UTC (permalink / raw)
To: Andi Shyti
Cc: Chanwoo Choi, Tomasz Figa, Krzysztof Kozlowski,
Sylwester Nawrocki, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Javier Martinez Canillas,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-samsung-soc,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, stable,
Andi Shyti
In-Reply-To: <20161230041421.24448-3-andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti <andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> Commit 5db7e3bb87df ("pinctrl: dt-bindings: samsung: Add header with
> values used for configuration") has added a header file for defining the
> pinctrl values in order to avoid hardcoded settings in the Exynos
> DTS related files.
>
> Extend samsung.h to the Exynos5433 for drive strength values
> which are strictly related to the particular SoC and may defer
> from others.
>
> Signed-off-by: Andi Shyti <andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Patch applied with Chanwoo's review tag.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/4] pinctrl: samsung: Fix the width of PINCFG_TYPE_DRV bitfields for Exynos5433
From: Linus Walleij @ 2016-12-30 13:28 UTC (permalink / raw)
To: Andi Shyti
Cc: Chanwoo Choi, Tomasz Figa, Krzysztof Kozlowski,
Sylwester Nawrocki, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Javier Martinez Canillas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-samsung-soc, linux-kernel@vger.kernel.org, stable,
Andi Shyti
In-Reply-To: <20161230041421.24448-2-andi.shyti@samsung.com>
On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti <andi.shyti@samsung.com> wrote:
> From: Chanwoo Choi <cw00.choi@samsung.com>
>
> This patch fixes the wrong width of PINCFG_TYPE_DRV bitfields for Exynos5433
> because PINCFG_TYPE_DRV of Exynos5433 has 4bit fields in the *_DRV
> registers. Usually, other Exynos have 2bit field for PINCFG_TYPE_DRV.
>
> Fixes: 3c5ecc9ed353 ("pinctrl: exynos: Add support for Exynos5433")
> Cc: stable@vger.kernel.org
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Nominally I think you should sign this off too Andi, as you are in the delivery
path.
Patch applied for fixes.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 10/20] gpio: pca953x: Add optional reset gpio control
From: Linus Walleij @ 2016-12-30 13:17 UTC (permalink / raw)
To: Steve Longerbeam
Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, Rob Herring, Mark Rutland,
Russell King, Alexandre Courbot, Mauro Carvalho Chehab, Greg KH,
Philipp Zabel, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-media@vger.kernel.org,
devel@driverdev.osuosl.org
In-Reply-To: <1483050455-10683-11-git-send-email-steve_longerbeam@mentor.com>
On Thu, Dec 29, 2016 at 11:27 PM, Steve Longerbeam
<slongerbeam@gmail.com> wrote:
> Add optional reset-gpios pin control. If present, de-assert the
> specified reset gpio pin to bring the chip out of reset.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Alexandre Courbot <gnurou@gmail.com>
> Cc: linux-gpio@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
This seems like a separate patch from the other 19 patches so please send it
separately so I can handle logistics easier in the future.
> @@ -133,6 +134,7 @@ struct pca953x_chip {
> const char *const *names;
> unsigned long driver_data;
> struct regulator *regulator;
> + struct gpio_desc *reset_gpio;
Why do you even keep this around in the device state container?
As you only use it in the probe() function, use a local variable.
The descriptor will be free():ed by the devm infrastructure anyways.
> + /* see if we need to de-assert a reset pin */
> + chip->reset_gpio = devm_gpiod_get_optional(&client->dev,
> + "reset",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(chip->reset_gpio)) {
> + dev_err(&client->dev, "request for reset pin failed\n");
> + return PTR_ERR(chip->reset_gpio);
> + }
Nice.
> + if (chip->reset_gpio) {
> + /* bring chip out of reset */
> + dev_info(&client->dev, "releasing reset\n");
> + gpiod_set_value(chip->reset_gpio, 0);
> + }
Is this really needed given that you set it low in the
devm_gpiod_get_optional()?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/2] iio: misc: add support for GPIO power switches
From: Linus Walleij @ 2016-12-30 13:05 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Bartosz Golaszewski, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring,
Mark Rutland, linux-iio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Kevin Hilman, Patrick Titiano, Neil Armstrong, Alexandre Courbot,
linux-gpio@vger.kernel.org, linux-pm@vger.kernel.org, Mark Brown,
Lia
In-Reply-To: <20161229162919.j2ej2cyeuoqnxykf@earth>
n Thu, Dec 29, 2016 at 5:29 PM, Sebastian Reichel <sre@kernel.org> wrote:
> On Wed, Dec 28, 2016 at 01:50:17PM +0100, Linus Walleij wrote:
>> On Sun, Dec 11, 2016 at 11:21 PM, Bartosz Golaszewski
>> <bgolaszewski@baylibre.com> wrote:
>>
>> > Some power-measuring ADCs work together with power load switches which
>> > allow to power-cycle measured devices.
>> >
>> > An example use case would be measuring the power consumption of a
>> > development board during boot using a power monitor such as TI INA226
>> > and power-cycling the board remotely using a TPS229* power switch.
>> >
>> > Add an iio driver for simple GPIO power switches and expose a sysfs
>> > attribute allowing to toggle their state.
>> >
>> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> I don't get this, isn't this doing the same as
>> drivers/power/reset/gpio-poweroff.c
>> ?
>>
>> With the only difference that the latter uses the standard syscall
>> from pm_power_off to reboot the system instead of some random
>> sysfs file.
>
> As far as I understand it, the TPS229 is used by Barzosz to poweroff
> a remote system. The gpio-poweroff driver is used to poweroff the
> local system.
Thanks yeah I understood this from the context of later patches.
Well if such a property is used it should be the property of the remote
system per se, and the remote system should then also be desribed in
DT, not half-described by dangling references at random nodes.
So this needs to be re-architected to either describe the remote system
in DT and handle it in the kernel, or handle it all from userspace if it
is a one-off non-product thing.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: imx6ul: Add OCOTP node
From: Shawn Guo @ 2016-12-30 13:01 UTC (permalink / raw)
To: Daniel Schultz
Cc: mark.rutland, devicetree, Bai Ping, robh+dt, srinivas.kandagatla,
kernel, fabio.estevam, maxime.ripard, linux-arm-kernel
In-Reply-To: <1480689949-17957-2-git-send-email-d.schultz@phytec.de>
On Fri, Dec 02, 2016 at 03:45:48PM +0100, Daniel Schultz wrote:
> This device node adds OCOTP for the i.MX6UL SoC.
>
> Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
Bai Ping (Cc'ed here) from NXP is sending similar patches [1]. DTS
change looks good to me, but I will not apply it until the driver and
bindings get accepted.
Shawn
[1] https://www.spinics.net/lists/arm-kernel/msg540900.html
> ---
> arch/arm/boot/dts/imx6ul.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
> index c5c05fd..ee53795 100644
> --- a/arch/arm/boot/dts/imx6ul.dtsi
> +++ b/arch/arm/boot/dts/imx6ul.dtsi
> @@ -849,6 +849,12 @@
> reg = <0x021b0000 0x4000>;
> };
>
> + ocotp: ocotp@021bc000 {
> + compatible = "fsl,imx6ul-ocotp";
> + reg = <0x021bc000 0x4000>;
> + clocks = <&clks IMX6UL_CLK_OCOTP>;
> + };
> +
> lcdif: lcdif@021c8000 {
> compatible = "fsl,imx6ul-lcdif", "fsl,imx28-lcdif";
> reg = <0x021c8000 0x4000>;
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] net: stmmac: remove unused duplicate property snps,axi_all
From: Niklas Cassel @ 2016-12-30 12:56 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Eric Engestrom, Gabriel Fernandez,
Joachim Eastwood, Vincent Palatin
Cc: Niklas Cassel, netdev, devicetree, linux-kernel
From: Niklas Cassel <niklas.cassel@axis.com>
For core revision 3.x Address-Aligned Beats is available in two registers.
The DT property snps,aal was created for AAL in the DMA bus register,
which is a read/write bit.
The DT property snps,axi_all was created for AXI_AAL in the AXI bus mode
register, which is a read only bit that reflects the value of AAL in the
DMA bus register.
Since the value of snps,axi_all is never used in the driver,
and since the property was created for a bit that is read only,
it should be safe to remove the property.
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
---
Documentation/devicetree/bindings/net/stmmac.txt | 1 -
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 -
include/linux/stmmac.h | 1 -
3 files changed, 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index 128da752fec9..c3d2fd480a1b 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -65,7 +65,6 @@ Optional properties:
- snps,wr_osr_lmt: max write outstanding req. limit
- snps,rd_osr_lmt: max read outstanding req. limit
- snps,kbbe: do not cross 1KiB boundary.
- - snps,axi_all: align address
- snps,blen: this is a vector of supported burst length.
- snps,fb: fixed-burst
- snps,mb: mixed-burst
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 082cd48db6a7..60ba8993c650 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -121,7 +121,6 @@ static struct stmmac_axi *stmmac_axi_setup(struct platform_device *pdev)
axi->axi_lpi_en = of_property_read_bool(np, "snps,lpi_en");
axi->axi_xit_frm = of_property_read_bool(np, "snps,xit_frm");
axi->axi_kbbe = of_property_read_bool(np, "snps,axi_kbbe");
- axi->axi_axi_all = of_property_read_bool(np, "snps,axi_all");
axi->axi_fb = of_property_read_bool(np, "snps,axi_fb");
axi->axi_mb = of_property_read_bool(np, "snps,axi_mb");
axi->axi_rb = of_property_read_bool(np, "snps,axi_rb");
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 266dab9ad782..889e0e9a3f1c 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -103,7 +103,6 @@ struct stmmac_axi {
u32 axi_wr_osr_lmt;
u32 axi_rd_osr_lmt;
bool axi_kbbe;
- bool axi_axi_all;
u32 axi_blen[AXI_BLEN];
bool axi_fb;
bool axi_mb;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 0/2] Use macros to describe gpios on rockchip platform
From: Heiko Stuebner @ 2016-12-30 12:31 UTC (permalink / raw)
To: Andy Yan
Cc: linux-kernel, linux-rockchip, devicetree, robh+dt, mark.rutland,
linux, linux-arm-kernel
In-Reply-To: <1477140706-6886-1-git-send-email-andy.yan@rock-chips.com>
Am Samstag, 22. Oktober 2016, 20:51:46 CET schrieb Andy Yan:
> As patch 150696e2e3a4("Add GPIO pin index definition for rockchip pinctrl")
> has been applied, now we can use these macros to describe the corresponding
> gpio ranther than hard code numbers, this will make the dts easier to read
> and write.
>
> Some ideas from Krzysztof's patch on EXYNOS[0].
>
> [0]https://lkml.org/lkml/2016/9/4/71
>
>
>
> Andy Yan (2):
> ARM: dts: rockchip: use pin constants to describe gpios
> ARM64: dts: rockchip: use pin constants to describe gpios
applied to dts branches for 4.11
I've also adapted the gpio interrupts accordingly inside the patches.
Thanks
Heiko
^ permalink raw reply
* Re: [PATCH 2/2] ARM: imx: Add speed grading check for imx6ul
From: Shawn Guo @ 2016-12-30 11:57 UTC (permalink / raw)
To: Bai Ping
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, fabio.estevam-3arQi8VN3Tc,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1480475098-2037-2-git-send-email-ping.bai-3arQi8VN3Tc@public.gmane.org>
On Wed, Nov 30, 2016 at 11:04:58AM +0800, Bai Ping wrote:
> On i.MX6UL, it has two type of part, the difference
> is the max ARM frequency that can run at(528MHz/700MHz).
> The part can be identified by part marking for speed grading
> fuse. This patch add speed grading check to disable the unsupported
> OPP dynamically.
>
> Signed-off-by: Bai Ping <ping.bai-3arQi8VN3Tc@public.gmane.org>
We chose to handle such speed grading thing in IMX platform code with
the assumption that this is a special case for i.MX6Q only. No, I'm not
going to take such code for any other i.MX6 SoCs. Please patch cpufreq
driver to handle the speed grading check.
Shawn
--
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 7/9] pinctrl: samsung: Add property to mark pad state as suitable for power down
From: Marek Szyprowski @ 2016-12-30 11:55 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-gpio, linux-arm-kernel, linux-pm, linux-samsung-soc,
Sylwester Nawrocki, Linus Walleij, Tomasz Figa, Ulf Hansson,
Bartlomiej Zolnierkiewicz, devicetree
In-Reply-To: <20161227153331.jbh7ei6oh3obmnri@kozik-lap>
Hi Krzysztof,
On 2016-12-27 16:33, Krzysztof Kozlowski wrote:
> On Tue, Dec 27, 2016 at 11:30:57AM +0100, Marek Szyprowski wrote:
>> On 2016-12-25 20:19, Krzysztof Kozlowski wrote:
>>> On Fri, Dec 23, 2016 at 01:24:47PM +0100, Marek Szyprowski wrote:
>>>> Add support for special property "samsung,off-state", which indicates a special
>>>> state suitable for device's "sleep" state. Its pin values/properties should
>>>> match the configuration in power down mode. It indicates that pin controller
>>>> can notify runtime power management subsystem, that it is ready for runtime
>>>> suspend if its all pins are configured for such state. This in turn might
>>>> allow to turn respective power domain off to reduce power consumption.
>>>>
>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> ---
>>>> Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 8 ++++++++
>>>> drivers/pinctrl/samsung/pinctrl-samsung.c | 4 ++++
>>>> drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
>>>> 3 files changed, 13 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>>>> index b7bd2e12a269..354eea0e7798 100644
>>>> --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>>>> +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>>>> @@ -105,6 +105,7 @@ Required Properties:
>>>> - samsung,pin-drv: Drive strength configuration.
>>>> - samsung,pin-pud-pdn: Pull up/down configuration in power down mode.
>>>> - samsung,pin-drv-pdn: Drive strength configuration in power down mode.
>>>> + - samsung,off-state: Mark this configuration as suitable for bank power off.
>>>> The values specified by these config properties should be derived from the
>>>> hardware manual and these values are programmed as-is into the pin
>>>> @@ -113,6 +114,13 @@ Required Properties:
>>>> Note: A child should include atleast a pin function selection property or
>>>> pin configuration property (one or more) or both.
>>>> + Note: Special property "samsung,off-state" indicates that this state can
>>>> + be used for device's "sleep" pins state. Its pin values/properties should
>>>> + match the configuration in power down mode.
>>> Why power down values cannot be used for sleep state? Why you need
>>> separate pin control state? If pins values should match power down
>>> configuration, then they could just be added to default state, couldn't
>>> they?
>> Separate sleep state is needed because of the pin control bindings and
>> design.
>>
>> A separate sleep state is required to let pin control client driver (in this
>> case
>> Exynos I2S driver) let to choose when it is okay to switch pads into sleep
>> state and I see no other way to achieve this.
> Maybe the pinctrl API should be extended for this? Doing this in DTS
> just for purpose of passing information between drivers (consumer and
> provider) looks odd.
Well, I don't know if it is odd or not, but that's how it is used now
and I see
no reason to reinvent wheel. Please check it yourself:
$ git grep \"sleep\" arch/arm/boot/dts | wc -l
101
> Anyway, you are proposing a new binding so please Cc devicetree mailing
> list and device tree maintainers.
I'm just using the generic pinctrl bindings, but it might make some sense to
add a note to Exynos i2s driver that a sleep pin control state is needed if
one wants to get power domain to be turned off.
>>> In the patch 2/9, existing configuration:
>>> 716 i2s0_bus: i2s0-bus {
>>> (...)
>>> 719 samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
>>> 720 samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
>>> 721 samsung,pin-drv = <EXYNOS5420_PIN_DRV_LV1>;
>>> 722 };
>>>
>>> additional configuration:
>>> + i2s0_bus_slp: i2s0-bus-slp {
>>> + samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
>>> + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
>>> + samsung,pin-drv = <EXYNOS5420_PIN_DRV_LV1>;
>>> + samsung,pin-con-pdn = <EXYNOS_PIN_PDN_INPUT>;
>>> + samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>;
>>> + samsung,off-state;
>>> + };
>> I agree that it would be possible to get rid of "samsung,off-state" property
>> and
>> just detect off state when func/pud pair matches power down func/pud.
>>
>>>> It indicates that pin control
>>>> + can notify runtime power management subsystem, that it is ready for runtime
>>>> + suspend if its all pins are configured for such state. This in turn might
>>>> + allow to turn respective power domain off to reduce power consumption.
>>> What do you mean by "notifying RPM subsystem"? Either this is
>>> description of hardware in certain mode (sleep state) or this is not
>>> device tree property.
>> Maybe I wrote the description with a view too limited to the kernel
>> operation
>> perspective, but if we remove the need to mark state as off, the above
>> description
>> will not be needed.
> But still it wouldn't be describing any hardware property, would it?
Well, it somehow describes the hardware, because the pin state when it
is allowed
to turn off the power domain is board specific. I should move that part
to the
Odroid dts, because there might be a board which require other pin
values in power
down mode.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ 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