* [PATCH 3/5] ARM: dts: imx6qdl-nitrogen6_som2: remove hardcoded LVDS bus format
From: Gary Bisson @ 2016-12-02 9:08 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: fabio.estevam-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Gary Bisson
In-Reply-To: <20161202090843.22613-1-gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
The bus format is therefore retrieved from the connected panel
information.
Signed-off-by: Gary Bisson <gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
index d80f21a..0521986 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
@@ -640,8 +640,6 @@
status = "okay";
lvds-channel@0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <18>;
status = "okay";
port@4 {
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: imx6qdl-nitrogen6_max: remove hardcoded LVDS bus format
From: Gary Bisson @ 2016-12-02 9:08 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: fabio.estevam-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Gary Bisson
In-Reply-To: <20161202090843.22613-1-gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
The bus format is therefore retrieved from the connected panel
information.
Signed-off-by: Gary Bisson <gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
index 34887a1..c43c36e 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
@@ -739,8 +739,6 @@
status = "okay";
lvds-channel@0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <18>;
status = "okay";
port@4 {
@@ -753,8 +751,6 @@
};
lvds-channel@1 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <18>;
status = "okay";
port@4 {
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/5] ARM: dts: imx6qdl-nit6xlite: remove hardcoded LVDS bus format
From: Gary Bisson @ 2016-12-02 9:08 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: fabio.estevam-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Gary Bisson
In-Reply-To: <20161202090843.22613-1-gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
The bus format is therefore retrieved from the connected panel
information.
Signed-off-by: Gary Bisson <gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi b/arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi
index 63acd54..a784593 100644
--- a/arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi
@@ -515,8 +515,6 @@
status = "okay";
lvds-channel@0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <18>;
status = "okay";
port@4 {
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/5] ARM: dts: boundary: remove hardcoded LVDS bus format
From: Gary Bisson @ 2016-12-02 9:08 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: fabio.estevam-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Gary Bisson
Hi all,
This series removes the hardcoded bus format for the LVDS display nodes of our
platforms.
The reason is that our latest 7" display uses a 24-bit interface and therefore
can't work properly without this series.
https://patchwork.kernel.org/patch/9458053/
Regards,
Gary
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
arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi | 2 --
arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 4 ----
arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 2 --
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 2 --
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 2 --
5 files changed, 12 deletions(-)
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/4] mmc: pwrseq-simple: add disable-post-power-on option
From: Matt Ranostay @ 2016-12-02 9:06 UTC (permalink / raw)
To: Ulf Hansson, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren, Liam Breck
In-Reply-To: <CAPDyKFp9t1SEwQZ=uTHegbpgxxevQEy4kC=wPkc8Bo16030MNg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Dec 2, 2016 at 12:28 AM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 2 December 2016 at 08:22, Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org> wrote:
>>
>>
>>> On Dec 1, 2016, at 23:13, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>
>>>> On 2 December 2016 at 07:17, Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org> wrote:
>>>> Add optional device-post-power-on parameters to disable post_power_on
>>>> function from being called since this breaks some device.
>>>>
>>>> Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>>>> Cc: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>> Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
>>>> ---
>>>> Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 2 ++
>>>> drivers/mmc/core/pwrseq_simple.c | 7 +++++++
>>>> 2 files changed, 9 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>>>> index bea306d772d1..09fa153f743e 100644
>>>> --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>>>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>>>> @@ -24,6 +24,8 @@ Optional properties:
>>>> de-asserting the reset-gpios (if any)
>>>> - invert-off-state: Invert the power down state for the reset-gpios (if any)
>>>> and pwrdn-gpios (if any)
>>>> +- disable-post-power-on : Avoid post_power_on function from being called since
>>>> + this breaks some devices
>>>
>>> This is a bit weird. I would like to avoid this, if possible.
>>>
>>> Perhaps if you simply describe the sequence in detail for your device
>>> we can figure out the best option together.
>>
>> Yeah I know it is a bit weird but we need to keep that reset pin high for at least some time after pre power on. So any case it would be another property
>
> This went offlist, please resend.
>
> Moreover, please try to describe the sequence you need in detail
> according to your HW spec.
>
Yeah oops....
So basically we need to drive the reset and powerdown lines high with
a 300 milliseconds delay between both...
can't have the reset line low with post power on (pretty sure but
would need a delay anyway), and we need both reset + powerdown line
set low on powerdown.
So the power down sequence would need to be reversed for this
application in pwrseq-simple.
> Br
> Uffe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] drm/panel: simple: Add support for Tianma TM070JDHG30
From: Gary Bisson @ 2016-12-02 8:52 UTC (permalink / raw)
To: dri-devel; +Cc: devicetree, linux-kernel, robh+dt, Gary Bisson
In-Reply-To: <20161202085208.19459-1-gary.bisson@boundarydevices.com>
The Tianma TM070JDHG30 is a 7" LVDS display with a resolution of
1280x800.
http://usa.tianma.com/products-technology/product/tm070jdhg30-00
You can also find this product along with a FT5x06 touch controller
from Boundary Devices:
https://boundarydevices.com/product/bd070lic2/
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
---
.../bindings/display/panel/tianma,tm070jdhg30.txt | 7 ++++++
drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
2 files changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt
diff --git a/Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt b/Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt
new file mode 100644
index 0000000..eb9501a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt
@@ -0,0 +1,7 @@
+Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "tianma,tm070jdhg30"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 113db3c..bc3dd46 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1471,6 +1471,30 @@ static const struct panel_desc starry_kr122ea0sra = {
},
};
+static const struct display_timing tianma_tm070jdhg30_timing = {
+ .pixelclock = { 62600000, 68200000, 78100000 },
+ .hactive = { 1280, 1280, 1280 },
+ .hfront_porch = { 15, 64, 159 },
+ .hback_porch = { 5, 5, 5 },
+ .hsync_len = { 1, 1, 256 },
+ .vactive = { 800, 800, 800 },
+ .vfront_porch = { 3, 40, 99 },
+ .vback_porch = { 2, 2, 2 },
+ .vsync_len = { 1, 1, 128 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc tianma_tm070jdhg30 = {
+ .timings = &tianma_tm070jdhg30_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 151,
+ .height = 95,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+};
+
static const struct drm_display_mode tpk_f07a_0102_mode = {
.clock = 33260,
.hdisplay = 800,
@@ -1689,6 +1713,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "starry,kr122ea0sra",
.data = &starry_kr122ea0sra,
}, {
+ .compatible = "tianma,tm070jdhg30",
+ .data = &tianma_tm070jdhg30,
+ }, {
.compatible = "tpk,f07a-0102",
.data = &tpk_f07a_0102,
}, {
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 1/2] of: Add vendor prefix for Tianma Micro-electronics
From: Gary Bisson @ 2016-12-02 8:52 UTC (permalink / raw)
To: dri-devel
Cc: thierry.reding, airlied, robh+dt, devicetree, linux-kernel,
Gary Bisson
In-Reply-To: <20161202085208.19459-1-gary.bisson@boundarydevices.com>
Tianma Micro-electronics Co., Ltd. (Tianma) specializes in providing
display solutions and efficient support services worldwide.
More info:
http://en.tianma.com/about.shtml
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 163f84b..3d1ec68 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -291,6 +291,7 @@ technologic Technologic Systems
terasic Terasic Inc.
thine THine Electronics, Inc.
ti Texas Instruments
+tianma Tianma Micro-electronics Co., Ltd.
tlm Trusted Logic Mobility
topeet Topeet
toradex Toradex AG
--
2.9.3
^ permalink raw reply related
* [PATCH 0/2] Add support for Tianma TM070JDHG30 display
From: Gary Bisson @ 2016-12-02 8:52 UTC (permalink / raw)
To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Cc: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, airlied-cv59FeDIM0c,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Gary Bisson
Hi all,
This series adds support for the Tianma TM070JDHG30 7" display (1280x800).
http://usa.tianma.com/products-technology/product/tm070jdhg30-00
https://boundarydevices.com/product/bd070lic2/
The first patch adds Tianma as a new vendor prefix whereas the second patch
adds the display to the simple panel driver.
Regards,
Gary
Gary Bisson (2):
of: Add vendor prefix for Tianma Micro-electronics
drm/panel: simple: Add support for Tianma TM070JDHG30
.../bindings/display/panel/tianma,tm070jdhg30.txt | 7 ++++++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
3 files changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/4] bindings: net: stmmac: correct note about TSO
From: Giuseppe CAVALLARO @ 2016-12-02 8:48 UTC (permalink / raw)
To: Niklas Cassel, Rob Herring, Mark Rutland, David S. Miller,
Alexandre TORGUE, Phil Reid, Niklas Cassel, Eric Engestrom
Cc: netdev, devicetree, linux-kernel
In-Reply-To: <1479911066-19752-1-git-send-email-niklass@axis.com>
On 11/23/2016 3:24 PM, Niklas Cassel wrote:
> From: Niklas Cassel <niklas.cassel@axis.com>
>
> snps,tso was previously placed under AXI BUS Mode parameters,
> suggesting that the property should be in the stmmac-axi-config node.
>
> TSO (TCP Segmentation Offloading) has nothing to do with AXI BUS Mode
> parameters, and the parser actually expects it to be in the root node,
> not in the stmmac-axi-config.
>
> Also added a note about snps,tso only being available on GMAC4 and newer.
>
> Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> ---
> Documentation/devicetree/bindings/net/stmmac.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
> index 41b49e6075f5..b95ff998ba73 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -1,7 +1,7 @@
> * STMicroelectronics 10/100/1000 Ethernet driver (GMAC)
>
> Required properties:
> -- compatible: Should be "snps,dwmac-<ip_version>" "snps,dwmac"
> +- compatible: Should be "snps,dwmac-<ip_version>", "snps,dwmac"
> For backwards compatibility: "st,spear600-gmac" is also supported.
> - reg: Address and length of the register set for the device
> - interrupt-parent: Should be the phandle for the interrupt controller
> @@ -50,6 +50,8 @@ Optional properties:
> - snps,ps-speed: port selection speed that can be passed to the core when
> PCS is supported. For example, this is used in case of SGMII
> and MAC2MAC connection.
> +- snps,tso: this enables the TSO feature otherwise it will be managed by
> + MAC HW capability register. Only for GMAC4 and newer.
> - AXI BUS Mode parameters: below the list of all the parameters to program the
> AXI register inside the DMA module:
> - snps,lpi_en: enable Low Power Interface
> @@ -62,8 +64,6 @@ Optional properties:
> - snps,fb: fixed-burst
> - snps,mb: mixed-burst
> - snps,rb: rebuild INCRx Burst
> - - snps,tso: this enables the TSO feature otherwise it will be managed by
> - MAC HW capability register.
> - mdio: with compatible = "snps,dwmac-mdio", create and register mdio bus.
>
> Examples:
>
^ permalink raw reply
* Re: [PATCH v3 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
From: Geert Uytterhoeven @ 2016-12-02 8:42 UTC (permalink / raw)
To: Simon Horman
Cc: Wolfram Sang, Magnus Damm, Linux I2C, Linux-Renesas, Rob Herring,
devicetree@vger.kernel.org
In-Reply-To: <1480666227-7622-1-git-send-email-horms+renesas@verge.net.au>
On Fri, Dec 2, 2016 at 9:10 AM, Simon Horman <horms+renesas@verge.net.au> wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
it's
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
is being
> drivers for Renesas SoCs.
>
> Also:
> * Deprecate renesas,i2c-rcar. It seems poorly named as it is only
> compatible with R-Car Gen 1. It also appears unused in mainline.
> * Add some text to describe per-SoC bindings
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/4] mmc: pwrseq-simple: allow inverting of off state logic
From: Matt Ranostay @ 2016-12-02 8:24 UTC (permalink / raw)
To: Ulf Hansson
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tony Lindgren
In-Reply-To: <313A249C-2BB9-487E-AF75-02ADB8AE83CC-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
On Thu, Dec 1, 2016 at 11:28 PM, Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org> wrote:
>
>
>
>>> On Dec 1, 2016, at 22:57, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>
>>> On 2 December 2016 at 07:17, Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org> wrote:
>>> Some devices need a logic level low instead of high to be in the
>>> off state.
>>>
>>> Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>>> Cc: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
>>> ---
>>> .../devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 2 ++
>>> drivers/mmc/core/pwrseq_simple.c | 15 +++++++++++----
>>> 2 files changed, 13 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>>> index 703a714201d8..bea306d772d1 100644
>>> --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>>> @@ -22,6 +22,8 @@ Optional properties:
>>> the reset-gpios (if any) are asserted
>>> - post-power-on-delay-ms : Delay in ms after powering the card and
>>> de-asserting the reset-gpios (if any)
>>> +- invert-off-state: Invert the power down state for the reset-gpios (if any)
>>> + and pwrdn-gpios (if any)
>>
>> We already have DT bindings to describe GPIO pins as active high or
>> low. I think we should be able to use that instead, don't you think?
>
> Ah issue is we are using inverse logic in the power down from anything else. But I guess we could read the gpios active high and low stats from device tree and deduce it from that
>
BTW this quirkiness is which why me and Lindgren went the route of an
another pwrseq driver versus hacking the pwrseq-simple initially...
In any case we can change the active high or low in the gpio
descriptors but doesn't change the timing we need or the inverse state
for power down.
Thanks,
Matt
>
>>
>> [...]
>>
>> Kind regards
>> Uffe
--
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/3] Documentation: dt: Add TI SCI clock driver
From: Tero Kristo @ 2016-12-02 8:19 UTC (permalink / raw)
To: Rob Herring
Cc: linux-clk, Michael Turquette, Stephen Boyd, Santosh Shilimkar,
Nishanth Menon, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org
In-Reply-To: <0fe81866-8bfd-f3a7-d808-9cb23841f504@ti.com>
On 21/11/16 10:14, Tero Kristo wrote:
> On 18/11/16 19:20, Rob Herring wrote:
>> On Mon, Oct 31, 2016 at 7:50 AM, Tero Kristo <t-kristo@ti.com> wrote:
>>> On 30/10/16 22:41, Rob Herring wrote:
>>>>
>>>> On Fri, Oct 21, 2016 at 03:45:59PM +0300, Tero Kristo wrote:
>>>>>
>>>>> Add a clock implementation, TI SCI clock, that will hook to the common
>>>>> clock framework, and allow each clock to be controlled via TI SCI
>>>>> protocol.
>>>>>
>>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>>> ---
>>>>> .../devicetree/bindings/clock/ti,sci-clk.txt | 37
>>>>> ++++++++++++++++++++++
>>>>> MAINTAINERS | 1 +
>>>>> 2 files changed, 38 insertions(+)
>>>>> create mode 100644
>>>>> Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>>>> b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>>>> new file mode 100644
>>>>> index 0000000..bfc3ca4
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>>>> @@ -0,0 +1,37 @@
>>>>> +Texas Instruments TI-SCI Clocks
>>>>> +===============================
>>>>> +
>>>>> +All clocks on Texas Instruments' SoCs that contain a System
>>>>> Controller,
>>>>> +are only controlled by this entity. Communication between a host
>>>>> processor
>>>>> +running an OS and the System Controller happens through a protocol
>>>>> known
>>>>> +as TI-SCI[1]. This clock implementation plugs into the common clock
>>>>> +framework and makes use of the TI-SCI protocol on clock API requests.
>>>>> +
>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>> +
>>>>> +Required properties:
>>>>> +-------------------
>>>>> +- compatible: Must be "ti,k2g-sci-clk"
>>>>> +- #clock-cells: Shall be 2.
>>>>> + In clock consumers, this cell represents the device ID and clock ID
>>>>> + exposed by the PM firmware. The assignments can be found in the
>>>>> header
>>>>> + files <dt-bindings/genpd/<soc>.h> (which covers the device IDs) and
>>>>> + <dt-bindings/clock/<soc>.h> (which covers the clock IDs), where
>>>>> <soc>
>>>>> + is the SoC involved, for example 'k2g'.
>>>>> +
>>>>> +Examples:
>>>>> +--------
>>>>> +
>>>>> +pmmc: pmmc {
>>>>> + compatible = "ti,k2g-sci";
>>>>> +
>>>>> + k2g_clks: k2g_clks {
>>>>
>>>>
>>>> Use "clocks" for node name instead.
>>>>
>>>>> + compatible = "ti,k2g-sci-clk";
>>>>
>>>>
>>>> I'm starting to think all these child nodes for SCI are pointless. Is
>>>> there any reason why the parent node can't be the clock provider (along
>>>> with all the other providers it acks as)?
>>>
>>>
>>> I believe the only reason to keep them separate is to have kernel
>>> side of
>>> things modular. If we have separate nodes, the drivers can be probed
>>> separately.
>>>
>>> If not, we need to build one huge blob with all the features in it,
>>> so the
>>> main driver can probe everything in one go, with annoying back-and-forth
>>> callbacks in place (assuming we still want to keep stuff somehow
>>> modular.)
>>
>> Since when is DT the only way to create a device? The main driver can
>> create devices for all the sub-functions like clocks. This is the same
>> as MFDs which have been done both ways.
>
> Yes obviously this can be done, my main point was that it will require
> building some sort of infra within the driver to handle this. With
> separate nodes, none of this is going to be needed. Also, we will lose
> any kind of configurability via DT if we don't have separate nodes; now
> we can select the available clocks / genpds via the compatible string of
> the clocks/genpd nodes themselves (this isn't clearly evident as of now
> as we only support a grand total of one device, which is k2g-evm.)
> Otherwise we need to probe against the main node and add a separate
> compatible string for every device, and carry this information to the
> sibling devices also somehow. It is just so much simpler if we can just
> keep separate nodes for them.
>
> Also, plenty of things are doing this kind of stuff already in
> DT/kernel, having a parent node in place and sub-functions added
> separately for ease of use, with apparently no visible point for having
> the nodes within the DT.
Rob, any response on this one? I see you have acked the reset part of
the bindings which is doing pretty much the same thing as the clock part
is doing here, namely adding child node under the main SCI node. Is it
okay to do this same for other parts of the TI SCI?
-Tero
^ permalink raw reply
* Re: [PATCH 1/2] Add crypto driver support for some MediaTek chips
From: Corentin Labbe @ 2016-12-02 8:18 UTC (permalink / raw)
To: Ryder Lee
Cc: Herbert Xu, David S. Miller, Matthias Brugger,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Sean Wang,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1480649205-52695-2-git-send-email-ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Hello
I have some minor comment inline
On Fri, Dec 02, 2016 at 11:26:44AM +0800, Ryder Lee wrote:
> This adds support for the MediaTek hardware accelerator on
> mt7623/mt2701/mt8521p SoC.
>
> This driver currently implement:
> - SHA1 and SHA2 family(HMAC) hash alogrithms.
> - AES block cipher in CBC/ECB mode with 128/196/256 bits keys.
I see also a PRNG but is seems not really used.
>
> Signed-off-by: Ryder Lee <ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> drivers/crypto/Kconfig | 17 +
> drivers/crypto/Makefile | 1 +
> drivers/crypto/mediatek/Makefile | 2 +
> drivers/crypto/mediatek/mtk-aes.c | 734 +++++++++++++++++
> drivers/crypto/mediatek/mtk-platform.c | 575 +++++++++++++
> drivers/crypto/mediatek/mtk-platform.h | 230 ++++++
> drivers/crypto/mediatek/mtk-regs.h | 194 +++++
> drivers/crypto/mediatek/mtk-sha.c | 1384 ++++++++++++++++++++++++++++++++
> 8 files changed, 3137 insertions(+)
> create mode 100644 drivers/crypto/mediatek/Makefile
> create mode 100644 drivers/crypto/mediatek/mtk-aes.c
> create mode 100644 drivers/crypto/mediatek/mtk-platform.c
> create mode 100644 drivers/crypto/mediatek/mtk-platform.h
> create mode 100644 drivers/crypto/mediatek/mtk-regs.h
> create mode 100644 drivers/crypto/mediatek/mtk-sha.c
>
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 4d2b81f..5d9c803 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -553,6 +553,23 @@ config CRYPTO_DEV_ROCKCHIP
> This driver interfaces with the hardware crypto accelerator.
> Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
>
> +config CRYPTO_DEV_MEDIATEK
> + tristate "MediaTek's Cryptographic Engine driver"
> + depends on ARM && ARCH_MEDIATEK
> + select NEON
> + select KERNEL_MODE_NEON
> + select ARM_CRYPTO
> + select CRYPTO_AES
> + select CRYPTO_BLKCIPHER
> + select CRYPTO_SHA1_ARM_NEON
> + select CRYPTO_SHA256_ARM
> + select CRYPTO_SHA512_ARM
> + select CRYPTO_HMAC
Why do you select accelerated algos ?
Adding COMPILE_TEST could be helpfull also.
[...]
> +
> +#include <linux/dma-mapping.h>
> +#include <linux/scatterlist.h>
> +#include <crypto/scatterwalk.h>
> +#include <crypto/algapi.h>
> +#include <crypto/aes.h>
> +#include "mtk-platform.h"
> +#include "mtk-regs.h"
> +
Sort headers in alphabetical order
[...]
> +
> + mtk_aes_unregister_algs();
> + mtk_aes_record_free(cryp);
> +}
> +EXPORT_SYMBOL(mtk_cipher_alg_release);
Why not EXPORT_SYMBOL_GPL ?
Furthermore do you really need it to be exported ?
[...]
> +
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/clk.h>
> +#include <linux/platform_device.h>
> +#include "mtk-platform.h"
> +#include "mtk-regs.h"
> +
Sort headers in alphabetical order
[...]
> +
> +static void mtk_prng_reseed(struct mtk_cryp *cryp)
> +{
> + /* 8 words to seed the PRNG to provide IVs */
> + void __iomem *base = cryp->base;
> + const u32 prng_key[8] = {0x48c24cfd, 0x6c07f742,
> + 0xaee75681, 0x0f27c239,
> + 0x79947198, 0xe2991275,
> + 0x21ac3c7c, 0xd008c4b4};
Why do you seed with thoses constant ?
[...]
> +
> +static int mtk_accelerator_init(struct mtk_cryp *cryp)
> +{
> + int i, err;
> +
> + /* Initialize advanced interrupt controller(AIC) */
> + for (i = 0; i < 5; i++) {
I see this 5 for interrupt away, so perhaps a define could be used
[...]
here
> + for (i = 0; i < 5; i++) {
> + cryp->irq[i] = platform_get_irq(pdev, i);
> + if (cryp->irq[i] < 0) {
> + dev_err(cryp->dev, "no IRQ:%d resource info\n", i);
> + return -ENXIO;
> + }
> + }
[...]
> +#ifndef __MTK_PLATFORM_H_
> +#define __MTK_PLATFORM_H_
> +
> +#include <linux/crypto.h>
> +#include <crypto/internal/hash.h>
> +#include <linux/interrupt.h>
Sort headers in alphabetical order
[...]
> +#define MTK_DESC_FIRST BIT(23)
> +#define MTK_DESC_BUF_LEN(x) ((x) & 0x1ffff)
> +#define MTK_DESC_CT_LEN(x) (((x) & 0xff) << 24)
> +
> +#define WORD(x) ((x) >> 2)
dangerous and ambigous define
[...]
> +
> +#include <linux/dma-mapping.h>
> +#include <linux/scatterlist.h>
> +#include <linux/crypto.h>
> +#include <crypto/scatterwalk.h>
> +#include <crypto/algapi.h>
> +#include <crypto/sha.h>
> +#include <crypto/internal/hash.h>
Sort headers in alphabetical order
[...]
Generally more function comment could be helpfull.
Regards
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
From: Simon Horman @ 2016-12-02 8:10 UTC (permalink / raw)
To: Wolfram Sang
Cc: Magnus Damm, linux-i2c, linux-renesas-soc, Rob Herring,
devicetree, Simon Horman
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
descendant of the former or vice versa.
We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.
For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme being adopted for
drivers for Renesas SoCs.
Also:
* Deprecate renesas,i2c-rcar. It seems poorly named as it is only
compatible with R-Car Gen 1. It also appears unused in mainline.
* Add some text to describe per-SoC bindings
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v3
* Consistently use renesas,<family>-<module> for new compat strings
* Drop RFC designation
v2
* Include accidently omitted i2c-rcar.c portion of patch
---
Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 32 ++++++++++++++--------
drivers/i2c/busses/i2c-rcar.c | 5 +++-
2 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
index 239632a0d709..50c378ccb8e7 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
@@ -1,17 +1,25 @@
I2C for R-Car platforms
Required properties:
-- compatible: Must be one of
- "renesas,i2c-rcar"
- "renesas,i2c-r8a7778"
- "renesas,i2c-r8a7779"
- "renesas,i2c-r8a7790"
- "renesas,i2c-r8a7791"
- "renesas,i2c-r8a7792"
- "renesas,i2c-r8a7793"
- "renesas,i2c-r8a7794"
- "renesas,i2c-r8a7795"
- "renesas,i2c-r8a7796"
+- compatible:
+ "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
+ "renesas,i2c-r8a7779" if the device is a part of a R8A7797 SoC.
+ "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
+ "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
+ "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC.
+ "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC.
+ "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC.
+ "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
+ "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
+ "renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device.
+ "renesas,rcar-gen2-i2c" for a generic R-Car Gen2 compatible device.
+ "renesas,rcar-gen3-i2c" for a generic R-Car Gen3 compatible device.
+ "renesas,i2c-rcar" (deprecated)
+
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first followed
+ by the generic version.
+
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt specifier.
@@ -33,7 +41,7 @@ Examples :
i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7791";
+ compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 726615e54f2a..622def6b43e2 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -793,7 +793,6 @@ static const struct i2c_algorithm rcar_i2c_algo = {
};
static const struct of_device_id rcar_i2c_dt_ids[] = {
- { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7778", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7779", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7790", .data = (void *)I2C_RCAR_GEN2 },
@@ -803,6 +802,10 @@ static const struct of_device_id rcar_i2c_dt_ids[] = {
{ .compatible = "renesas,i2c-r8a7794", .data = (void *)I2C_RCAR_GEN2 },
{ .compatible = "renesas,i2c-r8a7795", .data = (void *)I2C_RCAR_GEN3 },
{ .compatible = "renesas,i2c-r8a7796", .data = (void *)I2C_RCAR_GEN3 },
+ { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 }, // Deprecated
+ { .compatible = "renesas,rcar-gen1-i2c", .data = (void *)I2C_RCAR_GEN1 },
+ { .compatible = "renesas,rcar-gen2-i2c", .data = (void *)I2C_RCAR_GEN2 },
+ { .compatible = "renesas,rcar-gen3-i2c", .data = (void *)I2C_RCAR_GEN3 },
{},
};
MODULE_DEVICE_TABLE(of, rcar_i2c_dt_ids);
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* Re: [PATCH v4 1/3] lib: add bitrev8x4()
From: Anatolij Gustschin @ 2016-12-02 7:51 UTC (permalink / raw)
To: Joshua Clayton
Cc: Alan Tull, Moritz Fischer, Rob Herring, Mark Rutland,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <8fb2f1c2-c39c-b74f-d5c8-d6731cbd67c8-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Joshua,
On Thu, 1 Dec 2016 16:04:09 -0800
Joshua Clayton stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
...
>>> +static __always_inline __attribute_const__ u32 __arch_bitrev8x4(u32 x)
>>> +{
>>> + __asm__ ("rbit %0, %1; rev %0, %0" : "=r" (x) : "r" (x));
>> return x;
>Oops thats a little embarrassing;
>I'll add a return.
>>> +}
>> otherwise you get
>>
>> In function '__arch_bitrev8x4':
>> warning: no return statement in function returning non-void [-Wreturn-type]
>>
>
>I wonder why I do not see this warning when compiling. The inlining, maybe?
do you have CONFIG_HAVE_ARCH_BITREVERSE=y in your .config?
Probably not optimized code is used, otherwise you will send wrong
data to FPGA (due to wrong return values from __arch_bitrev8x4).
Anatolij
--
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/4] mmc: pwrseq-simple: allow inverting of off state logic
From: Matt Ranostay @ 2016-12-02 7:28 UTC (permalink / raw)
To: Ulf Hansson
Cc: devicetree@vger.kernel.org, linux-mmc@vger.kernel.org,
Tony Lindgren
In-Reply-To: <CAPDyKFrYVL52N22JVDA3wiWLAwUhht+6-=fi9kbGA8DYu=zPiA@mail.gmail.com>
Sent from my iPhone
> On Dec 1, 2016, at 22:57, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
>> On 2 December 2016 at 07:17, Matt Ranostay <matt@ranostay.consulting> wrote:
>> Some devices need a logic level low instead of high to be in the
>> off state.
>>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
>> ---
>> .../devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 2 ++
>> drivers/mmc/core/pwrseq_simple.c | 15 +++++++++++----
>> 2 files changed, 13 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>> index 703a714201d8..bea306d772d1 100644
>> --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>> @@ -22,6 +22,8 @@ Optional properties:
>> the reset-gpios (if any) are asserted
>> - post-power-on-delay-ms : Delay in ms after powering the card and
>> de-asserting the reset-gpios (if any)
>> +- invert-off-state: Invert the power down state for the reset-gpios (if any)
>> + and pwrdn-gpios (if any)
>
> We already have DT bindings to describe GPIO pins as active high or
> low. I think we should be able to use that instead, don't you think?
Ah issue is we are using inverse logic in the power down from anything else. But I guess we could read the gpios active high and low stats from device tree and deduce it from that
>
> [...]
>
> Kind regards
> Uffe
^ permalink raw reply
* [PATCH 5/5] arm64: dts: exynos5433: Add support of bus frequency using VDD_INT on TM2
From: Chanwoo Choi @ 2016-12-02 7:18 UTC (permalink / raw)
To: krzk, javier, kgene, robh+dt, s.nawrocki, tomasz.figa
Cc: cw00.choi, myungjoo.ham, kyungmin.park, devicetree,
linux-samsung-soc, linux-arm-kernel, linux-kernel
In-Reply-To: <1480663087-4590-1-git-send-email-cw00.choi@samsung.com>
This patch adds the bus Device-tree nodes for INT (Internal) block
to enable the bus frequency scaling.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 72 +++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index c08589970134..7b37aae336b1 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -170,6 +170,58 @@
};
};
+&bus_g2d_400 {
+ devfreq-events = <&ppmu_event0_d0_general>, <&ppmu_event0_d1_general>;
+ vdd-supply = <&buck4_reg>;
+ exynos,saturation-ratio = <10>;
+ status = "okay";
+};
+
+&bus_mscl {
+ devfreq = <&bus_g2d_400>;
+ status = "okay";
+};
+
+&bus_jpeg {
+ devfreq = <&bus_g2d_400>;
+ status = "okay";
+};
+
+&bus_mfc {
+ devfreq = <&bus_g2d_400>;
+ status = "okay";
+};
+
+&bus_g2d_266 {
+ devfreq = <&bus_g2d_400>;
+ status = "okay";
+};
+
+&bus_gscl {
+ devfreq = <&bus_g2d_400>;
+ status = "okay";
+};
+
+&bus_hevc {
+ devfreq = <&bus_g2d_400>;
+ status = "okay";
+};
+
+&bus_bus0 {
+ devfreq = <&bus_g2d_400>;
+ status = "okay";
+};
+
+&bus_bus1 {
+ devfreq = <&bus_g2d_400>;
+ status = "okay";
+};
+
+&bus_bus2 {
+ devfreq = <&bus_g2d_400>;
+ status = "okay";
+};
+
&cmu_aud {
assigned-clocks = <&cmu_aud CLK_MOUT_AUD_PLL_USER>;
assigned-clock-parents = <&cmu_top CLK_FOUT_AUD_PLL>;
@@ -794,6 +846,26 @@
bus-width = <4>;
};
+&ppmu_d0_general {
+ status = "okay";
+
+ events {
+ ppmu_event0_d0_general: ppmu-event0-d0-general {
+ event-name = "ppmu-event0-d0-general";
+ };
+ };
+};
+
+&ppmu_d1_general {
+ status = "okay";
+
+ events {
+ ppmu_event0_d1_general: ppmu-event0-d1-general {
+ event-name = "ppmu-event0-d1-general";
+ };
+ };
+};
+
&pinctrl_alive {
pinctrl-names = "default";
pinctrl-0 = <&initial_alive>;
--
1.9.1
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: exynos5433: Add bus dt node using VDD_INT for Exynos5433
From: Chanwoo Choi @ 2016-12-02 7:18 UTC (permalink / raw)
To: krzk, javier, kgene, robh+dt, s.nawrocki, tomasz.figa
Cc: cw00.choi, myungjoo.ham, kyungmin.park, devicetree,
linux-samsung-soc, linux-arm-kernel, linux-kernel
In-Reply-To: <1480663087-4590-1-git-send-email-cw00.choi@samsung.com>
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
- CLK_ACLK_MSCL_400 : Bus clock for MSCL (Mobile 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 Effective 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 | 208 +++++++++++++++++++++++++
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 1 +
2 files changed, 209 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
new file mode 100644
index 000000000000..b1e1d9c622e1
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
@@ -0,0 +1,208 @@
+/*
+ * Samsung's Exynos5433 SoC Memory interface and AMBA bus device tree source
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Chanwoo Choi <cw00.choi@samsung.com>
+ *
+ * Samsung's Exynos5433 SoC Memory interface and AMBA buses are listed
+ * as device tree nodes are listed in this file.
+ *
+ * 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.
+ */
+
+/ {
+ /* INT (Internal) block using VDD_INT */
+ bus_g2d_400: bus_g2d_400 {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu_top CLK_ACLK_G2D_400>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_g2d_400_opp_table>;
+ status ="disable";
+ };
+
+ bus_mscl: bus_mscl {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu_top CLK_ACLK_MSCL_400>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_g2d_400_opp_table>;
+ status ="disable";
+ };
+
+ bus_jpeg: bus_jpeg {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu_top CLK_SCLK_JPEG_MSCL>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_g2d_400_opp_table>;
+ status ="disable";
+ };
+
+ bus_mfc: bus_mfc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu_top CLK_ACLK_MFC_400>;
+
+ clock-names = "bus";
+ operating-points-v2 = <&bus_g2d_400_opp_table>;
+ status ="disable";
+ };
+
+ bus_g2d_266: bus_g2d_266 {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu_top CLK_ACLK_G2D_266>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_g2d_266_opp_table>;
+ status ="disable";
+ };
+
+ bus_gscl: bus_gscl {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu_top CLK_ACLK_GSCL_333>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_gscl_opp_table>;
+ status ="disable";
+ };
+
+ bus_hevc: bus_hevc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu_top CLK_ACLK_HEVC_400>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_hevc_opp_table>;
+ status ="disable";
+ };
+
+ bus_bus0: bus_bus0 {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu_top CLK_ACLK_BUS0_400>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_hevc_opp_table>;
+ status ="disable";
+ };
+
+ bus_bus1: bus_bus1 {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu_top CLK_ACLK_BUS1_400>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_hevc_opp_table>;
+ status ="disable";
+ };
+
+ bus_bus2: bus_bus2 {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu_mif CLK_ACLK_BUS2_400>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_bus2_opp_table>;
+ status ="disable";
+ };
+
+ bus_g2d_400_opp_table: opp_table2 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <1075000>;
+ };
+ opp@267000000 {
+ opp-hz = /bits/ 64 <267000000>;
+ opp-microvolt = <1000000>;
+ };
+ opp@200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ opp-microvolt = <975000>;
+ };
+ opp@160000000 {
+ opp-hz = /bits/ 64 <160000000>;
+ opp-microvolt = <962500>;
+ };
+ opp@134000000 {
+ opp-hz = /bits/ 64 <134000000>;
+ opp-microvolt = <950000>;
+ };
+ opp@100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ opp-microvolt = <937500>;
+ };
+ };
+
+ bus_g2d_266_opp_table: opp_table3 {
+ compatible = "operating-points-v2";
+
+ opp@267000000 {
+ opp-hz = /bits/ 64 <267000000>;
+ };
+ opp@200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ };
+ opp@160000000 {
+ opp-hz = /bits/ 64 <160000000>;
+ };
+ opp@134000000 {
+ opp-hz = /bits/ 64 <134000000>;
+ };
+ opp@100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ };
+ };
+
+ bus_gscl_opp_table: opp_table4 {
+ compatible = "operating-points-v2";
+
+ opp@333000000 {
+ opp-hz = /bits/ 64 <333000000>;
+ };
+ opp@222000000 {
+ opp-hz = /bits/ 64 <222000000>;
+ };
+ opp@166500000 {
+ opp-hz = /bits/ 64 <166500000>;
+ };
+ };
+
+ bus_hevc_opp_table: opp_table5 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <1075000>;
+ };
+ opp@267000000 {
+ opp-hz = /bits/ 64 <267000000>;
+ opp-microvolt = <1075000>;
+ };
+ opp@200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ opp-microvolt = <1075000>;
+ };
+ opp@160000000 {
+ opp-hz = /bits/ 64 <160000000>;
+ opp-microvolt = <1075000>;
+ };
+ opp@134000000 {
+ opp-hz = /bits/ 64 <134000000>;
+ opp-microvolt = <1075000>;
+ };
+ opp@100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ opp-microvolt = <1075000>;
+ };
+ };
+
+ bus_bus2_opp_table: opp_table6 {
+ compatible = "operating-points-v2";
+
+ opp@400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ };
+ opp@200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ };
+ opp@134000000 {
+ opp-hz = /bits/ 64 <134000000>;
+ };
+ opp@100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 8c4ee84d5232..68f764e5851c 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -1482,5 +1482,6 @@
};
};
+#include "exynos5433-bus.dtsi"
#include "exynos5433-pinctrl.dtsi"
#include "exynos5433-tmu.dtsi"
--
1.9.1
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: exynos5433: Add PPMU dt node
From: Chanwoo Choi @ 2016-12-02 7:18 UTC (permalink / raw)
To: krzk-DgEjT+Ai2ygdnm+yROfE0A, javier-JPH+aEBZ4P+UEJcrhfAQsw,
kgene-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ,
tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w
Cc: cw00.choi-Sze3O3UU22JBDgjK7y7TUQ,
myungjoo.ham-Sze3O3UU22JBDgjK7y7TUQ,
kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480663087-4590-1-git-send-email-cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
This patch adds PPMU (Platform Performance Monitoring Unit) Device-tree node
to measure the utilization of each IP in Exynos SoC.
- PPMU_D{0|1}_CPU are used to measure the utilization of MIF (Memory Interface)
block with VDD_MIF power source.
- PPMU_D{0|1}_GENERAL are used to measure the utilization of INT(Internal)
block with VDD_INT power source.
Signed-off-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 64226d5ae471..8c4ee84d5232 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -599,6 +599,30 @@
clock-names = "fin_pll", "mct";
};
+ ppmu_d0_cpu: ppmu@10480000 {
+ compatible = "samsung,exynos-ppmu-v2";
+ reg = <0x10480000 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_d0_general: ppmu@10490000 {
+ compatible = "samsung,exynos-ppmu-v2";
+ reg = <0x10490000 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_d1_cpu: ppmu@104b0000 {
+ compatible = "samsung,exynos-ppmu-v2";
+ reg = <0x104b0000 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_d1_general: ppmu@104c0000 {
+ compatible = "samsung,exynos-ppmu-v2";
+ reg = <0x104c0000 0x2000>;
+ status = "disabled";
+ };
+
pinctrl_alive: pinctrl@10580000 {
compatible = "samsung,exynos5433-pinctrl";
reg = <0x10580000 0x1a20>, <0x11090000 0x100>;
--
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
* [PATCH 2/5] PM / devfreq: exynos-bus: Add the detailed correlation for Exynos5433
From: Chanwoo Choi @ 2016-12-02 7:18 UTC (permalink / raw)
To: krzk, javier, kgene, robh+dt, s.nawrocki, tomasz.figa
Cc: devicetree, linux-samsung-soc, linux-kernel, cw00.choi,
kyungmin.park, myungjoo.ham, linux-arm-kernel
In-Reply-To: <1480663087-4590-1-git-send-email-cw00.choi@samsung.com>
This patch adds the detailed corrleation between sub-blocks and VDD_INT power
line for Exynos5433. VDD_INT provided the power source to INT (Internal) block.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
---
Documentation/devicetree/bindings/devfreq/exynos-bus.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index d3ec8e676b6b..d085ef90d27c 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -123,6 +123,20 @@ Detailed correlation between sub-blocks and power line according to Exynos SoC:
|--- FSYS
|--- FSYS2
+- In case of Exynos5433, there is VDD_INT power line as following:
+ VDD_INT |--- G2D (parent device)
+ |--- MSCL
+ |--- GSCL
+ |--- JPEG
+ |--- MFC
+ |--- HEVC
+ |--- BUS0
+ |--- BUS1
+ |--- BUS2
+ |--- PERIS (Fixed clock rate)
+ |--- PERIC (Fixed clock rate)
+ |--- FSYS (Fixed clock rate)
+
Example1:
Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
power line (regulator). The MIF (Memory Interface) AXI bus is used to
--
1.9.1
^ permalink raw reply related
* [PATCH 1/5] clk: samsung: exynos5433: Set NoC (Network On Chip) clocks as critical
From: Chanwoo Choi @ 2016-12-02 7:18 UTC (permalink / raw)
To: krzk, javier, kgene, robh+dt, s.nawrocki, tomasz.figa
Cc: cw00.choi, myungjoo.ham, kyungmin.park, devicetree,
linux-samsung-soc, linux-arm-kernel, linux-kernel,
Michael Turquette, Stephen Boyd
In-Reply-To: <1480663087-4590-1-git-send-email-cw00.choi@samsung.com>
The ACLK_BUS0/1/2 are used for NoC (Network on Chip). If NoC's clocks are
disabled, the system halt happen. Following clock must be always enabled.
- CLK_ACLK_BUS0_400 : NoC'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
Also, this patch adds the CLK_SET_RATE_PARENT flag to the CLK_SCLK_JPEG_MSCL
because this clock should be used for bus frequency scaling. This clock need to
be changed on the fly with CLK_SET_RATE_PARENT flag.
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc:linux-clk@vger.kernel.org
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
---
drivers/clk/samsung/clk-exynos5433.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5433.c b/drivers/clk/samsung/clk-exynos5433.c
index f096bd7df40c..0db5204c307c 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -549,10 +549,10 @@
29, CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK_BUS0_400, "aclk_bus0_400", "div_aclk_bus0_400",
ENABLE_ACLK_TOP, 26,
- CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
+ CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
GATE(CLK_ACLK_BUS1_400, "aclk_bus1_400", "div_aclk_bus1_400",
ENABLE_ACLK_TOP, 25,
- CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
+ CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
GATE(CLK_ACLK_IMEM_200, "aclk_imem_200", "div_aclk_imem_266",
ENABLE_ACLK_TOP, 24,
CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
@@ -616,7 +616,7 @@
/* ENABLE_SCLK_TOP_MSCL */
GATE(CLK_SCLK_JPEG_MSCL, "sclk_jpeg_mscl", "div_sclk_jpeg",
- ENABLE_SCLK_TOP_MSCL, 0, 0, 0),
+ ENABLE_SCLK_TOP_MSCL, 0, CLK_SET_RATE_PARENT, 0),
/* ENABLE_SCLK_TOP_CAM1 */
GATE(CLK_SCLK_ISP_SENSOR2, "sclk_isp_sensor2", "div_sclk_isp_sensor2_b",
@@ -1382,7 +1382,7 @@ static void __init exynos5433_cmu_cpif_init(struct device_node *np)
/* ENABLE_ACLK_MIF3 */
GATE(CLK_ACLK_BUS2_400, "aclk_bus2_400", "div_aclk_bus2_400",
ENABLE_ACLK_MIF3, 4,
- CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
+ CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
GATE(CLK_ACLK_DISP_333, "aclk_disp_333", "div_aclk_disp_333",
ENABLE_ACLK_MIF3, 1,
CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
--
1.9.1
^ permalink raw reply related
* [PATCH 0/5] arm64: dts: Enable bus frequency scaling on Exynos5433-based TM2 board
From: Chanwoo Choi @ 2016-12-02 7:18 UTC (permalink / raw)
To: krzk-DgEjT+Ai2ygdnm+yROfE0A, javier-JPH+aEBZ4P+UEJcrhfAQsw,
kgene-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ,
tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w
Cc: cw00.choi-Sze3O3UU22JBDgjK7y7TUQ,
myungjoo.ham-Sze3O3UU22JBDgjK7y7TUQ,
kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
This patches add the AMBA bus Device-tree node unsing VDD_INT
to enable the bus frequency scaling on Exynos5433-based TM2 board.
There are two kind of bus device with devfreq framework.
- Parent bus device : Change the frequency/voltage according to bus's utilization.
- Passive bus device : Change only frequency according to the new level
of parent bus device.
The VDD_INT regulator provides the power source to INT (Internal) block as
following. The sub-blocks in the INT block share the one power source.
VDD_INT |--- G2D (parent device)
|--- MSCL
|--- GSCL
|--- JPEG
|--- MFC
|--- HEVC
|--- BUS0
|--- BUS1
|--- BUS2
|--- PERIS (Fixed clock rate)
|--- PERIC (Fixed clock rate)
|--- FSYS (Fixed clock rate)
Each sub-block has the bus clock as following:
- CLK_ACLK_G2D_{400|266} : Bus clock for G2D
- CLK_ACLK_MSCL_400 : Bus clock for MSCL (Mobile 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 Effective 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
Chanwoo Choi (5):
clk: samsung: exynos5433: Set NoC (Network On Chip) clocks as critical
PM / devfreq: exynos-bus: Add the detailed correlation for Exynos5433
arm64: dts: exynos5433: Add PPMU dt node
arm64: dts: exynos5433: Add bus dt node using VDD_INT for Exynos5433
arm64: dts: exynos5433: Add support of bus frequency using VDD_INT on TM2
.../devicetree/bindings/devfreq/exynos-bus.txt | 14 ++
arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 208 +++++++++++++++++++++
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 72 +++++++
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 25 +++
drivers/clk/samsung/clk-exynos5433.c | 8 +-
5 files changed, 323 insertions(+), 4 deletions(-)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
--
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
* Re: [PATCH 4/4] mmc: pwrseq-simple: add disable-post-power-on option
From: Ulf Hansson @ 2016-12-02 7:13 UTC (permalink / raw)
To: Matt Ranostay
Cc: devicetree@vger.kernel.org, linux-mmc@vger.kernel.org,
Tony Lindgren
In-Reply-To: <1480659462-29536-5-git-send-email-matt@ranostay.consulting>
On 2 December 2016 at 07:17, Matt Ranostay <matt@ranostay.consulting> wrote:
> Add optional device-post-power-on parameters to disable post_power_on
> function from being called since this breaks some device.
>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
> ---
> Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 2 ++
> drivers/mmc/core/pwrseq_simple.c | 7 +++++++
> 2 files changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> index bea306d772d1..09fa153f743e 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> @@ -24,6 +24,8 @@ Optional properties:
> de-asserting the reset-gpios (if any)
> - invert-off-state: Invert the power down state for the reset-gpios (if any)
> and pwrdn-gpios (if any)
> +- disable-post-power-on : Avoid post_power_on function from being called since
> + this breaks some devices
This is a bit weird. I would like to avoid this, if possible.
Perhaps if you simply describe the sequence in detail for your device
we can figure out the best option together.
[...]
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v4] of: Fix issue where code would fall through to error case.
From: Frank Rowand @ 2016-12-02 7:11 UTC (permalink / raw)
To: Moritz Fischer, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w, Moritz Fischer
In-Reply-To: <1480659025-18836-1-git-send-email-moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org>
On 12/01/16 22:10, Moritz Fischer wrote:
> From: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> No longer fall through into the error case that prints out
> an error if no error (err = 0) occurred.
>
> Fixes d9181b20a83(of: Add back an error message, restructured)
> Signed-off-by: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Reviewed-by: Frank Rowand <frank.rowand-mEdOJwZ7QcZBDgjK7y7TUQ@public.gmane.org>
> ---
> Hi Frank, Rob
>
> sorry for the noise before.
I'm sure I created much more noise than you did. Thanks for
persisting.
I am confirming that this still applies for v4:
Reviewed-by: Frank Rowand <frank.rowand-mEdOJwZ7QcZBDgjK7y7TUQ@public.gmane.org>
-Frank
>
> Thanks,
> Moritz
> ---
> drivers/of/resolver.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
> index 783bd09..8bf12e9 100644
> --- a/drivers/of/resolver.c
> +++ b/drivers/of/resolver.c
> @@ -298,12 +298,12 @@ int of_resolve_phandles(struct device_node *overlay)
> if (!overlay) {
> pr_err("null overlay\n");
> err = -EINVAL;
> - goto err_out;
> + goto out;
> }
> if (!of_node_check_flag(overlay, OF_DETACHED)) {
> pr_err("overlay not detached\n");
> err = -EINVAL;
> - goto err_out;
> + goto out;
> }
>
> phandle_delta = live_tree_max_phandle() + 1;
> @@ -315,7 +315,7 @@ int of_resolve_phandles(struct device_node *overlay)
>
> err = adjust_local_phandle_references(local_fixups, overlay, phandle_delta);
> if (err)
> - goto err_out;
> + goto out;
>
> overlay_fixups = NULL;
>
> @@ -333,7 +333,7 @@ int of_resolve_phandles(struct device_node *overlay)
> if (!tree_symbols) {
> pr_err("no symbols in root of device tree.\n");
> err = -EINVAL;
> - goto err_out;
> + goto out;
> }
>
> for_each_property_of_node(overlay_fixups, prop) {
> @@ -345,12 +345,12 @@ int of_resolve_phandles(struct device_node *overlay)
> err = of_property_read_string(tree_symbols,
> prop->name, &refpath);
> if (err)
> - goto err_out;
> + goto out;
>
> refnode = of_find_node_by_path(refpath);
> if (!refnode) {
> err = -ENOENT;
> - goto err_out;
> + goto out;
> }
>
> phandle = refnode->phandle;
> @@ -361,9 +361,9 @@ int of_resolve_phandles(struct device_node *overlay)
> break;
> }
>
> -err_out:
> - pr_err("overlay phandle fixup failed: %d\n", err);
> out:
> + if (err)
> + pr_err("overlay phandle fixup failed: %d\n", err);
> of_node_put(tree_symbols);
>
> return err;
>
--
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/4] mmc: pwrseq-simple: allow inverting of off state logic
From: Ulf Hansson @ 2016-12-02 6:57 UTC (permalink / raw)
To: Matt Ranostay
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tony Lindgren
In-Reply-To: <1480659462-29536-4-git-send-email-matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
On 2 December 2016 at 07:17, Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org> wrote:
> Some devices need a logic level low instead of high to be in the
> off state.
>
> Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> Cc: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
> ---
> .../devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 2 ++
> drivers/mmc/core/pwrseq_simple.c | 15 +++++++++++----
> 2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> index 703a714201d8..bea306d772d1 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> @@ -22,6 +22,8 @@ Optional properties:
> the reset-gpios (if any) are asserted
> - post-power-on-delay-ms : Delay in ms after powering the card and
> de-asserting the reset-gpios (if any)
> +- invert-off-state: Invert the power down state for the reset-gpios (if any)
> + and pwrdn-gpios (if any)
We already have DT bindings to describe GPIO pins as active high or
low. I think we should be able to use that instead, don't you think?
[...]
Kind regards
Uffe
--
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