* [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 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
* 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 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 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 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
* [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
* [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 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
* 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 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
* [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 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 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 4/5] ARM: dts: imx6qdl-nitrogen6x: 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-nitrogen6x.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index 26d0604..16b14bd 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -579,8 +579,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 5/5] ARM: dts: imx6qdl-sabrelite: 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-sabrelite.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 1f9076e..452ae47 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -525,8 +525,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
* Re: [PATCH v10 2/4] dtc: Document the dynamic plugin internals
From: Pantelis Antoniou @ 2016-12-02 9:09 UTC (permalink / raw)
To: David Gibson
Cc: Frank Rowand, Jon Loeliger, Grant Likely, Rob Herring, Jan Luebbe,
Sascha Hauer, Phil Elwell, Simon Glass, Maxime Ripard,
Thomas Petazzoni, Boris Brezillon, Antoine Tenart, Stephen Boyd,
Devicetree Compiler, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161202032510.GD10089-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
Hi David,
> On Dec 2, 2016, at 05:25 , David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
>
> On Tue, Nov 29, 2016 at 01:21:40PM +0200, Pantelis Antoniou wrote:
>> Hi Frank,
>>
>>> On Nov 29, 2016, at 03:36 , Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>
>>> On 11/25/16 04:32, Pantelis Antoniou wrote:
>>>> Provides the document explaining the internal mechanics of
>>>> plugins and options.
>>>>
>>>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
>>>> ---
>>>> Documentation/dt-object-internal.txt | 318 +++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 318 insertions(+)
>>>> create mode 100644 Documentation/dt-object-internal.txt
>>>>
>>>> diff --git a/Documentation/dt-object-internal.txt b/Documentation/dt-object-internal.txt
>>>> new file mode 100644
>>>> index 0000000..d5b841e
>>>> --- /dev/null
>>>> +++ b/Documentation/dt-object-internal.txt
>>>> @@ -0,0 +1,318 @@
>>>> +Device Tree Dynamic Object format internals
>>>> +-------------------------------------------
>>>> +
>>>> +The Device Tree for most platforms is a static representation of
>>>> +the hardware capabilities. This is insufficient for many platforms
>>>> +that need to dynamically insert device tree fragments to the
>>>> +running kernel's live tree.
>>>> +
>>>> +This document explains the the device tree object format and the
>>>> +modifications made to the device tree compiler, which make it possible.
>>>> +
>>>> +1. Simplified Problem Definition
>>>> +--------------------------------
>>>> +
>>>> +Assume we have a platform which boots using following simplified device tree.
>>>> +
>>>> +---- foo.dts -----------------------------------------------------------------
>>>> + /* FOO platform */
>>>> + / {
>>>> + compatible = "corp,foo";
>>>> +
>>>> + /* shared resources */
>>>> + res: res {
>>>> + };
>>>> +
>>>> + /* On chip peripherals */
>>>> + ocp: ocp {
>>>> + /* peripherals that are always instantiated */
>>>> + peripheral1 { ... };
>>>> + };
>>>> + };
>>>> +---- foo.dts -----------------------------------------------------------------
>>>> +
>>>> +We have a number of peripherals that after probing (using some undefined method)
>>>> +should result in different device tree configuration.
>>>> +
>>>> +We cannot boot with this static tree because due to the configuration of the
>>>> +foo platform there exist multiple conficting peripherals DT fragments.
>>>
>>> ^^^^^^^^^^ conflicting
>>>
>>> I assume conflicting because, for instance, the different peripherals might
>>> occupy the same address space, use the same interrupt, or use the same gpio.
>>> Mentioning that would provide a fuller picture for the neophyte.
>>>
>>
>> Yes, thanks for bringing this to my attention. This document is heavy on the neophyte for sure.
>>
>>>> +
>>>> +So for the bar peripheral we would have this:
>>>> +
>>>> +---- foo+bar.dts -------------------------------------------------------------
>>>> + /* FOO platform + bar peripheral */
>>>> + / {
>>>> + compatible = "corp,foo";
>>>> +
>>>> + /* shared resources */
>>>> + res: res {
>>>> + };
>>>> +
>>>> + /* On chip peripherals */
>>>> + ocp: ocp {
>>>> + /* peripherals that are always instantiated */
>>>> + peripheral1 { ... };
>>>> +
>>>> + /* bar peripheral */
>>>> + bar {
>>>> + compatible = "corp,bar";
>>>> + ... /* various properties and child nodes */
>>>> + };
>>>> + };
>>>> + };
>>>> +---- foo+bar.dts -------------------------------------------------------------
>>>> +
>>>> +While for the baz peripheral we would have this:
>>>> +
>>>> +---- foo+baz.dts -------------------------------------------------------------
>>>> + /* FOO platform + baz peripheral */
>>>> + / {
>>>> + compatible = "corp,foo";
>>>> +
>>>> + /* shared resources */
>>>> + res: res {
>>>> + /* baz resources */
>>>> + baz_res: res_baz { ... };
>>>> + };
>>>> +
>>>> + /* On chip peripherals */
>>>> + ocp: ocp {
>>>> + /* peripherals that are always instantiated */
>>>> + peripheral1 { ... };
>>>> +
>>>> + /* baz peripheral */
>>>> + baz {
>>>> + compatible = "corp,baz";
>>>> + /* reference to another point in the tree */
>>>> + ref-to-res = <&baz_res>;
>>>> + ... /* various properties and child nodes */
>>>> + };
>>>> + };
>>>> + };
>>>> +---- foo+baz.dts -------------------------------------------------------------
>>>> +
>>>> +We note that the baz case is more complicated, since the baz peripheral needs to
>>>> +reference another node in the DT tree.
>>>
>>> I know that there are other situations that can justify overlays, so not
>>> contesting the basic need with this comment. But the above situation could
>>> be handled in a much simpler fashion by setting the status property of each
>>> of the conflicting devices to disabled, then after probing setting the status
>>> to ok. That method removes a lot of complexity.
>>>
>>> A big driver for the concept of overlays was being able to describe different
>>> add on boards at run time, instead of when the base dtb was created. I think
>>> we have agreed that moving to a connector model instead of a raw overlay is
>>> the proper way to address add on boards.
>>>
>>> Can you address how an overlay can be created that will work for a board
>>> plugged into any of the identical sockets that is compatible with the
>>> board?
>>>
>>>
>>
>> Yes, I will try to do so.
>>
>>>> +
>>>> +2. Device Tree Object Format Requirements
>>>> +-----------------------------------------
>>>> +
>>>> +Since the device tree is used for booting a number of very different hardware
>>>> +platforms it is imperative that we tread very carefully.
>>>> +
>>>> +2.a) No changes to the Device Tree binary format for the base tree. We cannot
>>>> +modify the tree format at all and all the information we require should be
>>>> +encoded using device tree itself. We can add nodes that can be safely ignored
>>>> +by both bootloaders and the kernel. The plugin dtb's are optionally tagged
>>>> +with a different magic number in the header but otherwise they too are simple
>>>> +blobs.
>>>> +
>>>> +2.b) Changes to the DTS source format should be absolutely minimal, and should
>>>> +only be needed for the DT fragment definitions, and not the base boot DT.
>>>> +
>>>> +2.c) An explicit option should be used to instruct DTC to generate the required
>>>> +information needed for object resolution. Platforms that don't use the
>>>> +dynamic object format can safely ignore it.
>>>> +
>>>> +2.d) Finally, DT syntax changes should be kept to a minimum. It should be
>>>> +possible to express everything using the existing DT syntax.
>>>> +
>>>> +3. Implementation
>>>> +-----------------
>>>> +
>>>> +The basic unit of addressing in Device Tree is the phandle. Turns out it's
>>>> +relatively simple to extend the way phandles are generated and referenced
>>>> +so that it's possible to dynamically convert symbolic references (labels)
>>>> +to phandle values. This is a valid assumption as long as the author uses
>>>> +reference syntax and does not assign phandle values manually (which might
>>>> +be a problem with decompiled source files).
>>>> +
>>>> +We can roughly divide the operation into two steps.
>>>> +
>>>> +3.a) Compilation of the base board DTS file using the '-@' option
>>>> +generates a valid DT blob with an added __symbols__ node at the root node,
>>>> +containing a list of all nodes that are marked with a label.
>>>> +
>>>> +Using the foo.dts file above the following node will be generated;
>>>> +
>>>> +$ dtc -@ -O dtb -o foo.dtb -b 0 foo.dts
>>>> +$ fdtdump foo.dtb
>>>> +...
>>>> +/ {
>>>> + ...
>>>> + res {
>>>> + ...
>>>> + phandle = <0x00000001>;
>>>> + ...
>>>> + };
>>>> + ocp {
>>>> + ...
>>>> + phandle = <0x00000002>;
>>>> + ...
>>>> + };
>>>> + __symbols__ {
>>>> + res="/res";
>>>> + ocp="/ocp";
>>>> + };
>>>> +};
>>>> +
>>>> +Notice that all the nodes that had a label have been recorded, and that
>>>> +phandles have been generated for them.
>>>> +
>>>> +This blob can be used to boot the board normally, the __symbols__ node will
>>>> +be safely ignored both by the bootloader and the kernel (the only loss will
>>>> +be a few bytes of memory and disk space).
>>>> +
>>>> +3.b) The Device Tree fragments must be compiled with the same option but they
>>>> +must also have a tag (/plugin/) that allows undefined references to nodes
>>>> +that are not present at compilation time to be recorded so that the runtime
>>>> +loader can fix them.
>>>> +
>>>> +So the bar peripheral's DTS format would be of the form:
>>>> +
>>>> +/dts-v1/ /plugin/; /* allow undefined references and record them */
>>>> +/ {
>>>> + .... /* various properties for loader use; i.e. part id etc. */
>>>> + fragment@0 {
>>>> + target = <&ocp>;
>>>> + __overlay__ {
>>>> + /* bar peripheral */
>>>> + bar {
>>>> + compatible = "corp,bar";
>>>> + ... /* various properties and child nodes */
>>>> + }
>>>> + };
>>>> + };
>>>> +};
>>>
>>> The last version of your patches that I tested did not require specifying
>>> the target property, the fragment node, and the __overlay__ node. dtc
>>> properly created all of those items automatically. For example, I could
>>> go to all of the trouble of creating those items in a dts like:
>>>
>>> $ cat example_1_hand_coded.dts
>>> /dts-v1/;
>>> /plugin/;
>>>
>>> / {
>>>
>>> fragment@0 {
>>> target = <&am3353x_pinmux>;
>>>
>>> __overlay__ {
>>>
>>> i2c1_pins: pinmux_i2c1_pins {
>>> pinctrl-single,pins = <
>>> 0x158 0x72
>>> 0x15c 0x72
>>> >;
>>> };
>>> };
>>> };
>>>
>>> fragment@1 {
>>> target = <&i2c1>;
>>>
>>> __overlay__ {
>>> pinctrl-names = "default";
>>> pinctrl-0 = <&i2c1_pins>;
>>> clock-frequency = <400000>;
>>> status = "okay";
>>>
>>> at24@50 {
>>> compatible = "at,24c256";
>>> pagesize = <64>;
>>> reg = <0x50>;
>>> };
>>> };
>>> };
>>> };
>>>
>>>
>>> Or I could let dtc automagically create all the special features
>>> (target, fragment, __overlay__) from an equivalent dts:
>>>
>>> $ cat example_1.dts
>>> /dts-v1/;
>>> /plugin/;
>>>
>>>
>>> &am3353x_pinmux {
>>> i2c1_pins: pinmux_i2c1_pins {
>>> pinctrl-single,pins = <
>>> 0x158 0x72
>>> 0x15c 0x72
>>> >;
>>> };
>>> };
>>>
>>> &i2c1 {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> pinctrl-names = "default";
>>> pinctrl-0 = <&i2c1_pins>;
>>> clock-frequency = <400000>;
>>> status = "okay";
>>>
>>> at24@50 {
>>> compatible = "at,24c256";
>>> pagesize = <64>;
>>> reg = <0x50>;
>>> };
>>> };
>>>
>>>
>>> I would much prefer that people never hand code the target, fragment, and
>>> __overlay__ in a dts source file. Exposing them at the source level adds
>>> complexity, confusion, and an increased chance of creating an invalid
>>> overlay dtb.
>>>
>>> If possible, I would prefer target, fragment, and __overlay__ not be valid
>>> input to dtc. It would probably be difficult to prohibit target and fragment,
>>> because however unlikely they are as property and node names, they are valid
>>> dts syntax before adding the overlay enhancements to dtc. However __overlay__
>>> is not a valid node name without the overlay enhancements and could remain
>>> invalid dts input.
>>>
>>> I prefer that target, fragment, and __overlay__ be documented as a dtb to
>>> target system API. In this case, for the normal developer, they are
>>> hidden in the binary dtb format and in the kernel (or boot loader)
>>> overlay framework code.
>>>
>>> I do recognize that if __overlay__ is not valid dtc input then it is not
>>> possible to decompile an overlay into a dts containing __overlay__ and
>>> then recompile that dts. This could be resolved by a more complex
>>> decompile that turned the overlay dtb back into the form of example_1.dts
>>> above.
>>>
>>> After reading to the end of this patch, I see that the simpler form of
>>> .dts (like example_1.dts) is also noted as "an alternative syntax to
>>> the expanded form for overlays".
>>>
>>>
>>
>> Phew.
>>
>> Let me address all that.
>>
>> When I started on this the main problem was that there was no support for applying
>> overlays in the kernel. The original patch series for dtc is meant to support the
>> encoding of the required information into device tree format.
>>
>> The syntax of overlays like this '&foo { };’ is a new thing that can be subject to
>> change.
>
> Well.. yes and no. What I'm going to call "compile time overlays"
> using that syntax have been around for ages (rather longer than
> dynamic overlays). The semantics you hve for runtime overlay
> application are pretty much identical to those for compile time
> overlays, except (duh) applied later.
>
> That's why I want to unify the syntax between the two. And, up to a
> point, to unify the concepts as well. This is why I want to treat
> this as having dtc parse the source into a bundle of overlays which it
> then decides whether it needs to apply immediately (compile time
> overlay) or encode them into the dtbo format for the bootloader or
> kernel to apply later (dynamic overlay).
>
It is a worthy goal, but it will require quite a lot of work (and time).
One thing that comes to mind is mapping the semantics of the compile time
‘overlays’ to run time will require changes in the blob format.
For instance the syntax for deleting nodes/properties has no mapping to
runtime. We will need to figure out how to encode them, etc.
It is something that can wait while we get things right, we don’t have a
pressing need right now.
>> On the last patchset I’ve split it out so that it is clear.
>
> Yeah, but you're splitting it based on the history, rather than what I
> think is the conceptually clearer approach: first, allow the overlay
> (&ref { ... }) syntax to be either compile-time or dynamic. second,
> add in backwards compatiblity hacks for manually encoded dts files.
>
I’m not sure what your point here is. First things first; encoding of runtime
overlays without changes in syntax. Next comes the new syntax for defining them.
There is no backward compatibility hack. The hack _is_ the &ref { } syntax since
nothing uses it now.
We intent to use from now on, true, but it’s been holding up the rest of the
patchset for years now.
>> Now, since we’ve settled on the internal encoding format (__overlays__, target, etc)
>> we can tackle the syntax cases and alternative target options.
>
> But that's not an internal encoding format, it's an _external_
> encoding format.
I concede that for the definition of internal/external from the viewpoint
of the dtc compiler.
>
>> So, yes we should forbid __overlay__ to be a valid node name eventually along with
>> a bunch of other syntax stuff.
>>
>> Having come to mind, we should see what we need for the connector
>> format to work.
>
> No argument there.
>
>>
>>>> +
>>>> +Note that there's a target property that specifies the location where the
>>>> +contents of the overlay node will be placed, and it references the node
>>>> +in the foo.dts file.
>>>> +
>>>> +$ dtc -@ -O dtb -o bar.dtbo -b 0 bar.dts
>>>> +$ fdtdump bar.dtbo
>>>> +...
>>>> +/ {
>>>> + ... /* properties */
>>>> + fragment@0 {
>>>> + target = <0xffffffff>;
>>>> + __overlay__ {
>>>> + bar {
>>>> + compatible = "corp,bar";
>>>> + ... /* various properties and child nodes */
>>>> + }
>>>> + };
>>>> + };
>>>> + __fixups__ {
>>>> + ocp = "/fragment@0:target:0";
>>>> + };
>>>> +};
>>>> +
>>>> +No __symbols__ has been generated (no label in bar.dts).
>>>> +Note that the target's ocp label is undefined, so the phandle handle
>>>> +value is filled with the illegal value '0xffffffff', while a __fixups__
>>>> +node has been generated, which marks the location in the tree where
>>>> +the label lookup should store the runtime phandle value of the ocp node.
>>>> +
>>>> +The format of the __fixups__ node entry is
>>>> +
>>>> + <label> = "<local-full-path>:<property-name>:<offset>";
>>>> +
>>>> +<label> Is the label we're referring
>>>> +<local-full-path> Is the full path of the node the reference is
>>>> +<property-name> Is the name of the property containing the
>>>> + reference
>>>> +<offset> The offset (in bytes) of where the property's
>>>> + phandle value is located.
>>>> +
>>>> +Doing the same with the baz peripheral's DTS format is a little bit more
>>>> +involved, since baz contains references to local labels which require
>>>> +local fixups.
>>>> +
>>>> +/dts-v1/ /plugin/; /* allow undefined label references and record them */
>>>> +/ {
>>>> + .... /* various properties for loader use; i.e. part id etc. */
>>>> + fragment@0 {
>>>> + target = <&res>;
>>>> + __overlay__ {
>>>> + /* baz resources */
>>>> + baz_res: res_baz { ... };
>>>> + };
>>>> + };
>>>> + fragment@1 {
>>>> + target = <&ocp>;
>>>> + __overlay__ {
>>>> + /* baz peripheral */
>>>> + baz {
>>>> + compatible = "corp,baz";
>>>> + /* reference to another point in the tree */
>>>> + ref-to-res = <&baz_res>;
>>>> + ... /* various properties and child nodes */
>>>> + }
>>>> + };
>>>> + };
>>>> +};
>>>> +
>>>> +Note that &bar_res reference.
>>>> +
>>>> +$ dtc -@ -O dtb -o baz.dtbo -b 0 baz.dts
>>>> +$ fdtdump baz.dtbo
>>>> +...
>>>> +/ {
>>>> + ... /* properties */
>>>> + fragment@0 {
>>>> + target = <0xffffffff>;
>>>> + __overlay__ {
>>>> + res_baz {
>>>> + ....
>>>> + phandle = <0x00000001>;
>>>> + };
>>>> + };
>>>> + };
>>>> + fragment@1 {
>>>> + target = <0xffffffff>;
>>>> + __overlay__ {
>>>> + baz {
>>>> + compatible = "corp,baz";
>>>> + ... /* various properties and child nodes */
>>>> + ref-to-res = <0x00000001>;
>>>> + }
>>>> + };
>>>> + };
>>>> + __fixups__ {
>>>> + res = "/fragment@0:target:0";
>>>> + ocp = "/fragment@1:target:0";
>>>> + };
>>>> + __local_fixups__ {
>>>> + fragment@1 {
>>>> + __overlay__ {
>>>> + baz {
>>>> + ref-to-res = <0>;
>>>> + };
>>>> + };
>>>> + };
>>>> + };
>>>> +};
>>>> +
>>>> +This is similar to the bar case, but the reference of a local label by the
>>>> +baz node generates a __local_fixups__ entry that records the place that the
>>>> +local reference is being made. No matter how phandles are allocated from dtc
>>>> +the run time loader must apply an offset to each phandle in every dynamic
>>>> +DT object loaded. The __local_fixups__ node records the place of every
>>>> +local reference so that the loader can apply the offset.
>>>> +
>>>> +There is an alternative syntax to the expanded form for overlays with phandle
>>>> +targets which makes the format similar to the one using in .dtsi include files.
>>>> +
>>>> +So for the &ocp target example above one can simply write:
>>>> +
>>>> +/dts-v1/ /plugin/;
>>>> +&ocp {
>>>> + /* bar peripheral */
>>>> + bar {
>>>> + compatible = "corp,bar";
>>>> + ... /* various properties and child nodes */
>>>> + }
>>>> +};
>>>> +
>>>> +The resulting dtb object is identical.
>>>>
>>>
>>
>> Regards
>>
>> — Pantelis
>>
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
Regards
— Pantelis
--
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 pci/next] PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar
From: Geert Uytterhoeven @ 2016-12-02 9:19 UTC (permalink / raw)
To: Simon Horman
Cc: Bjorn Helgaas, Phil Edworthy, Magnus Damm, linux-pci,
Linux-Renesas, Rob Herring, devicetree@vger.kernel.org
In-Reply-To: <1480609693-25746-1-git-send-email-horms+renesas@verge.net.au>
Hi Simon,
On Thu, Dec 1, 2016 at 5:28 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
> Add fallback compatibility string for the R-Car Gen 3 family. This is in
> keeping with the both the existing fallback compatibility string for the
> R-Car Gen 2 family and the fallback scheme being adopted wherever
> appropriate for drivers for Renesas SoCs.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
> drivers/pci/host/pcie-rcar.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> index 6cf99690eef9..eee518db90b9 100644
> --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> @@ -7,6 +7,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
> "renesas,pcie-r8a7793" for the R8A7793 SoC;
> "renesas,pcie-r8a7795" for the R8A7795 SoC;
> "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device.
> + "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device.
>
> When compatible with the generic version, nodes must list the
> SoC-specific version corresponding to the platform first
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index 62700d1896f4..962aa3942107 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -1077,6 +1077,8 @@ static const struct of_device_id rcar_pcie_of_match[] = {
> .data = rcar_pcie_hw_init_gen2 },
> { .compatible = "renesas,pcie-r8a7791",
> .data = rcar_pcie_hw_init_gen2 },
> + { .compatible = "renesas,pcie-rcar-gen3",
> + .data = rcar_pcie_hw_init_hw_init },
The family-specific handling should be inserted after the SoC-specific
handling.
Currently it doesn't matter, as both are handled exactly the same, but
it may avoid future mistakes.
BTW, can you please fix that for the existing entry for Gen2, too?
Thanks!
> { .compatible = "renesas,pcie-r8a7795", .data = rcar_pcie_hw_init },
> {},
> };
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 pci/next] PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar
From: Simon Horman @ 2016-12-02 9:33 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bjorn Helgaas, Phil Edworthy, Magnus Damm, linux-pci,
Linux-Renesas, Rob Herring, devicetree@vger.kernel.org
In-Reply-To: <CAMuHMdWwuQZq7FzDUtCj5gsdQra5PrSyoUk7-ycBN9pN-RYcrA@mail.gmail.com>
On Fri, Dec 02, 2016 at 10:19:21AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Thu, Dec 1, 2016 at 5:28 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
> > Add fallback compatibility string for the R-Car Gen 3 family. This is in
> > keeping with the both the existing fallback compatibility string for the
> > R-Car Gen 2 family and the fallback scheme being adopted wherever
> > appropriate for drivers for Renesas SoCs.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > ---
> > Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
> > drivers/pci/host/pcie-rcar.c | 2 ++
> > 2 files changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> > index 6cf99690eef9..eee518db90b9 100644
> > --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
> > +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> > @@ -7,6 +7,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
> > "renesas,pcie-r8a7793" for the R8A7793 SoC;
> > "renesas,pcie-r8a7795" for the R8A7795 SoC;
> > "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device.
> > + "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device.
> >
> > When compatible with the generic version, nodes must list the
> > SoC-specific version corresponding to the platform first
> > diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> > index 62700d1896f4..962aa3942107 100644
> > --- a/drivers/pci/host/pcie-rcar.c
> > +++ b/drivers/pci/host/pcie-rcar.c
> > @@ -1077,6 +1077,8 @@ static const struct of_device_id rcar_pcie_of_match[] = {
> > .data = rcar_pcie_hw_init_gen2 },
> > { .compatible = "renesas,pcie-r8a7791",
> > .data = rcar_pcie_hw_init_gen2 },
> > + { .compatible = "renesas,pcie-rcar-gen3",
> > + .data = rcar_pcie_hw_init_hw_init },
>
> The family-specific handling should be inserted after the SoC-specific
> handling.
> Currently it doesn't matter, as both are handled exactly the same, but
> it may avoid future mistakes.
>
> BTW, can you please fix that for the existing entry for Gen2, too?
Sure, will do.
^ permalink raw reply
* Re: [PATCH 4/6] net: ethernet: ti: cpts: add ptp pps support
From: Richard Cochran @ 2016-12-02 9:58 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Murali Karicheri, Wingman Kwok, David S. Miller, netdev,
Mugunthan V N, Sekhar Nori, linux-kernel, linux-omap, Rob Herring,
devicetree
In-Reply-To: <20161130221738.GA13099@localhost.localdomain>
On Wed, Nov 30, 2016 at 11:17:38PM +0100, Richard Cochran wrote:
> On Wed, Nov 30, 2016 at 02:43:57PM -0600, Grygorii Strashko wrote:
> > Sry, but this is questionable - code for pps comes from TI internal
> > branches (SDK releases) where it survived for a pretty long time.
Actually, there is a way to get an accurate PPS from the am335x. See
this recent thread:
https://www.mail-archive.com/linuxptp-devel@lists.sourceforge.net/msg01726.html
That is the way to go, and so, please drop this present patch.
Thanks,
Richard
^ permalink raw reply
* [PATCH v3 0/7] Add pwm and IIO timer drivers for stm32
From: Benjamin Gaignard @ 2016-12-02 10:17 UTC (permalink / raw)
To: lee.jones-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, alexandre.torgue-qxv4g6HH51o,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: fabrice.gasnier-qxv4g6HH51o, gerald.baeza-qxv4g6HH51o,
arnaud.pouliquen-qxv4g6HH51o,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A, Benjamin Gaignard
version 3:
- no change on mfd and pwm divers patches
- add cross reference between bindings
- change compatible to "st,stm32-timer-trigger"
- fix attributes access rights
- use string instead of int for master_mode and slave_mode
- document device attributes in sysfs-bus-iio-timer-stm32
- udpate DT with the new compatible
version 2:
- keep only one compatible per driver
- use DT parameters to describe hardware block configuration:
- pwm channels, complementary output, counter size, break input
- triggers accepted and create by IIO timers
- change DT to limite use of reference to the node
- interrupt is now in IIO timer driver
- rename stm32-mfd-timer to stm32-gptimer (for general purpose timer)
The following patches enable pwm and IIO Timer features for stm32 platforms.
Those two features are mixed into the registers of the same hardware block
(named general purpose timer) which lead to introduce a multifunctions driver
on the top of them to be able to share the registers.
In stm32 14 instances of timer hardware block exist, even if they all have
the same register mapping they could have a different number of pwm channels
and/or different triggers capabilities. We use various parameters in DT to
describe the differences between hardware blocks
The MFD (stm32-gptimer.c) takes care of clock and register mapping
by using regmap. stm32_gptimer_dev structure is provided to its sub-node to
share those information.
PWM driver is implemented into pwm-stm32.c. Depending of the instance we may
have up to 4 channels, sometime with complementary outputs or 32 bits counter
instead of 16 bits. Some hardware blocks may also have a break input function
which allows to stop pwm depending of a level, defined in devicetree, on an
external pin.
IIO timer driver (stm32-iio-timer.c and stm32-iio-timers.h) define a list of
hardware triggers usable by hardware blocks like ADC, DAC or other timers.
The matrix of possible connections between blocks is quite complex so we use
trigger names and is_stm32_iio_timer_trigger() function to be sure that
triggers are valid and configure the IPs.
Possible triggers ar listed in include/dt-bindings/iio/timer/st,stm32-iio-timer.h
At run time IIO timer hardware blocks can configure (through "master_mode"
IIO device attribute) which internal signal (counter enable, reset,
comparison block, etc...) is used to generate the trigger.
By using "slave_mode" IIO device attribute timer can also configure on which
event (level, rising edge) of the block is enabled.
Since we can use trigger from one hardware to control an other block, we can
use a pwm to control an other one. The following example shows how to configure
pwm1 and pwm3 to make pwm3 generate pulse only when pwm1 pulse level is high.
/sys/bus/iio/devices # ls
iio:device0 iio:device1 trigger0 trigger1
configure timer1 to use pwm1 channel 0 as output trigger
/sys/bus/iio/devices # echo 'OC1REF' > iio\:device0/master_mode
configure timer3 to enable only when input is high
/sys/bus/iio/devices # echo 'gated' > iio\:device1/slave_mode
/sys/bus/iio/devices # cat trigger0/name
tim1_trgo
configure timer2 to use timer1 trigger is input
/sys/bus/iio/devices # echo "tim1_trgo" > iio\:device1/trigger/current_trigger
configure pwm3 channel 0 to generate a signal with a period of 100ms and a
duty cycle of 50%
/sys/devices/platform/soc/40000400.gptimer3/40000400.gptimer3:pwm3@0/pwm/pwmchip4 # echo 0 > export
/sys/devices/platform/soc/40000400.gptimer3/40000400.gptimer3:pwm3@0/pwm/pwmchip4 # echo 100000000 > pwm0/period
/sys/devices/platform/soc/40000400.gptimer3/40000400.gptimer3:pwm3@0/pwm/pwmchip4 # echo 50000000 > pwm0/duty_cycle
/sys/devices/platform/soc/40000400.gptimer3/40000400.gptimer3:pwm3@0/pwm/pwmchip4# echo 1 > pwm0/enable
here pwm3 channel 0, as expected, doesn't start because has to be triggered by
pwm1 channel 0
configure pwm1 channel 0 to generate a signal with a period of 1s and a
duty cycle of 50%
/sys/devices/platform/soc/40010000.gptimer1/40010000.gptimer1:pwm1@0/pwm/pwmchip0 # echo 0 > export
/sys/devices/platform/soc/40010000.gptimer1/40010000.gptimer1:pwm1@0/pwm/pwmchip0 # echo 1000000000 > pwm0/period
/sys/devices/platform/soc/40010000.gptimer1/40010000.gptimer1:pwm1@0/pwm/pwmchip0 # echo 500000000 > pwm0/duty_cycle
/sys/devices/platform/soc/40010000.gptimer1/40010000.gptimer1:pwm1@0/pwm/pwmchip0 # echo 1 > pwm0/enable
finally pwm1 starts and pwm3 only generates pulse when pwm1 signal is high
An other example to use a timer as source of clock for another device.
Here timer1 is used a source clock for pwm3:
/sys/bus/iio/devices # echo 100000 > trigger0/sampling_frequency
/sys/bus/iio/devices # echo tim1_trgo > iio\:device1/trigger/current_trigger
/sys/bus/iio/devices # echo 'external_clock' > iio\:device1/slave_mode
/sys/devices/platform/soc/40000400.gptimer3/40000400.gptimer3:pwm3@0/pwm/pwmchip4 # echo 0 > export
/sys/devices/platform/soc/40000400.gptimer3/40000400.gptimer3:pwm3@0/pwm/pwmchip4 # echo 1000000 > pwm0/period
/sys/devices/platform/soc/40000400.gptimer3/40000400.gptimer3:pwm3@0/pwm/pwmchip4 # echo 500000 > pwm0/duty_cycle
/sys/devices/platform/soc/40000400.gptimer3/40000400.gptimer3:pwm3@0/pwm/pwmchip4 # echo 1 > pwm0/enable
Benjamin Gaignard (7):
MFD: add bindings for stm32 general purpose timer driver
MFD: add stm32 general purpose timer driver
PWM: add pwm-stm32 DT bindings
PWM: add pwm driver for stm32 plaftorm
IIO: add bindings for stm32 timer trigger driver
IIO: add STM32 timer trigger driver
ARM: dts: stm32: add stm32 general purpose timer driver in DT
.../ABI/testing/sysfs-bus-iio-timer-stm32 | 47 ++
.../bindings/iio/timer/stm32-timer-trigger.txt | 39 ++
.../bindings/mfd/stm32-general-purpose-timer.txt | 47 ++
.../devicetree/bindings/pwm/pwm-stm32.txt | 38 ++
arch/arm/boot/dts/stm32f429.dtsi | 333 +++++++++++++-
arch/arm/boot/dts/stm32f469-disco.dts | 28 ++
drivers/iio/Kconfig | 2 +-
drivers/iio/Makefile | 1 +
drivers/iio/timer/Kconfig | 15 +
drivers/iio/timer/Makefile | 1 +
drivers/iio/timer/stm32-timer-trigger.c | 477 +++++++++++++++++++++
drivers/iio/trigger/Kconfig | 1 -
drivers/mfd/Kconfig | 10 +
drivers/mfd/Makefile | 2 +
drivers/mfd/stm32-gptimer.c | 73 ++++
drivers/pwm/Kconfig | 8 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-stm32.c | 285 ++++++++++++
.../iio/timer/st,stm32-timer-triggers.h | 60 +++
include/linux/iio/timer/stm32-timer-trigger.h | 16 +
include/linux/mfd/stm32-gptimer.h | 62 +++
21 files changed, 1543 insertions(+), 3 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
create mode 100644 Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
create mode 100644 drivers/iio/timer/Kconfig
create mode 100644 drivers/iio/timer/Makefile
create mode 100644 drivers/iio/timer/stm32-timer-trigger.c
create mode 100644 drivers/mfd/stm32-gptimer.c
create mode 100644 drivers/pwm/pwm-stm32.c
create mode 100644 include/dt-bindings/iio/timer/st,stm32-timer-triggers.h
create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
create mode 100644 include/linux/mfd/stm32-gptimer.h
--
1.9.1
^ permalink raw reply
* [PATCH v3 1/7] MFD: add bindings for stm32 general purpose timer driver
From: Benjamin Gaignard @ 2016-12-02 10:17 UTC (permalink / raw)
To: lee.jones, robh+dt, mark.rutland, alexandre.torgue, devicetree,
linux-kernel, thierry.reding, linux-pwm, jic23, knaack.h, lars,
pmeerw, linux-iio, linux-arm-kernel
Cc: linaro-kernel, Benjamin Gaignard, linus.walleij, arnaud.pouliquen,
benjamin.gaignard, gerald.baeza, fabrice.gasnier
In-Reply-To: <1480673842-20804-1-git-send-email-benjamin.gaignard@st.com>
Add bindings information for stm32 general purpose timer
version 2:
- rename stm32-mfd-timer to stm32-gptimer
- only keep one compatible string
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
.../bindings/mfd/stm32-general-purpose-timer.txt | 47 ++++++++++++++++++++++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
diff --git a/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
new file mode 100644
index 0000000..4fc55d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
@@ -0,0 +1,47 @@
+STM32 general purpose timer driver
+
+Required parameters:
+- compatible: must be "st,stm32-gptimer"
+
+- reg: Physical base address and length of the controller's
+ registers.
+- clock-names: Set to "clk_int".
+- clocks: Phandle to the clock used by the timer module.
+ For Clk properties, please refer to ../clock/clock-bindings.txt
+
+Optional parameters:
+- resets: Phandle to the parent reset controller.
+ See ../reset/st,stm32-rcc.txt
+
+Optional subnodes:
+- pwm: See ../pwm/pwm-stm32.txt
+- timer: See ../iio/timer/stm32-timer-trigger.txt
+
+Example:
+ gptimer1: gptimer1@40010000 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40010000 0x400>;
+ clocks = <&rcc 0 160>;
+ clock-names = "clk_int";
+
+ pwm1@0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <4>;
+ st,breakinput;
+ st,complementary;
+ };
+
+ timer1@0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <27>;
+ st,input-triggers-names = TIM5_TRGO,
+ TIM2_TRGO,
+ TIM4_TRGO,
+ TIM3_TRGO;
+ st,output-triggers-names = TIM1_TRGO,
+ TIM1_CH1,
+ TIM1_CH2,
+ TIM1_CH3,
+ TIM1_CH4;
+ };
+ };
--
1.9.1
^ permalink raw reply related
* [PATCH v3 2/7] MFD: add stm32 general purpose timer driver
From: Benjamin Gaignard @ 2016-12-02 10:17 UTC (permalink / raw)
To: lee.jones, robh+dt, mark.rutland, alexandre.torgue, devicetree,
linux-kernel, thierry.reding, linux-pwm, jic23, knaack.h, lars,
pmeerw, linux-iio, linux-arm-kernel
Cc: fabrice.gasnier, gerald.baeza, arnaud.pouliquen, linus.walleij,
linaro-kernel, benjamin.gaignard, Benjamin Gaignard
In-Reply-To: <1480673842-20804-1-git-send-email-benjamin.gaignard@st.com>
This hardware block could at used at same time for PWM generation
and IIO timer for other IPs like DAC, ADC or other timers.
PWM and IIO timer configuration are mixed in the same registers
so we need a multi fonction driver to be able to share those registers.
version 2:
- rename driver "stm32-gptimer" to be align with SoC documentation
- only keep one compatible
- use of_platform_populate() instead of devm_mfd_add_devices()
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
drivers/mfd/Kconfig | 10 ++++++
drivers/mfd/Makefile | 2 ++
drivers/mfd/stm32-gptimer.c | 73 +++++++++++++++++++++++++++++++++++++++
include/linux/mfd/stm32-gptimer.h | 62 +++++++++++++++++++++++++++++++++
4 files changed, 147 insertions(+)
create mode 100644 drivers/mfd/stm32-gptimer.c
create mode 100644 include/linux/mfd/stm32-gptimer.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index c6df644..e75abcb 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1607,6 +1607,15 @@ config MFD_STW481X
in various ST Microelectronics and ST-Ericsson embedded
Nomadik series.
+config MFD_STM32_GP_TIMER
+ tristate "Support for STM32 General Purpose Timer"
+ select MFD_CORE
+ select REGMAP
+ depends on ARCH_STM32
+ depends on OF
+ help
+ Select this option to enable stm32 general purpose timer
+
menu "Multimedia Capabilities Port drivers"
depends on ARCH_SA1100
@@ -1644,4 +1653,5 @@ config MFD_VEXPRESS_SYSREG
on the ARM Ltd. Versatile Express board.
endmenu
+
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 9834e66..86353b9 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -211,3 +211,5 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
+
+obj-$(CONFIG_MFD_STM32_GP_TIMER) += stm32-gptimer.o
diff --git a/drivers/mfd/stm32-gptimer.c b/drivers/mfd/stm32-gptimer.c
new file mode 100644
index 0000000..54fb95c
--- /dev/null
+++ b/drivers/mfd/stm32-gptimer.c
@@ -0,0 +1,73 @@
+/*
+ * stm32-gptimer.c
+ *
+ * Copyright (C) STMicroelectronics 2016
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/reset.h>
+
+#include <linux/mfd/stm32-gptimer.h>
+
+static const struct regmap_config stm32_gptimer_regmap_cfg = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = sizeof(u32),
+ .max_register = 0x400,
+ .fast_io = true,
+};
+
+static int stm32_gptimer_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct stm32_gptimer_dev *mfd;
+ struct resource *res;
+ void __iomem *mmio;
+
+ mfd = devm_kzalloc(dev, sizeof(*mfd), GFP_KERNEL);
+ if (!mfd)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENOMEM;
+
+ mmio = devm_ioremap_resource(dev, res);
+ if (IS_ERR(mmio))
+ return PTR_ERR(mmio);
+
+ mfd->regmap = devm_regmap_init_mmio_clk(dev, "clk_int", mmio,
+ &stm32_gptimer_regmap_cfg);
+ if (IS_ERR(mfd->regmap))
+ return PTR_ERR(mfd->regmap);
+
+ mfd->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(mfd->clk))
+ return PTR_ERR(mfd->clk);
+
+ platform_set_drvdata(pdev, mfd);
+
+ return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
+}
+
+static const struct of_device_id stm32_gptimer_of_match[] = {
+ {
+ .compatible = "st,stm32-gptimer",
+ },
+};
+MODULE_DEVICE_TABLE(of, stm32_gptimer_of_match);
+
+static struct platform_driver stm32_gptimer_driver = {
+ .probe = stm32_gptimer_probe,
+ .driver = {
+ .name = "stm32-gptimer",
+ .of_match_table = stm32_gptimer_of_match,
+ },
+};
+module_platform_driver(stm32_gptimer_driver);
+
+MODULE_DESCRIPTION("STMicroelectronics STM32 general purpose timer");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/stm32-gptimer.h b/include/linux/mfd/stm32-gptimer.h
new file mode 100644
index 0000000..f8c92de
--- /dev/null
+++ b/include/linux/mfd/stm32-gptimer.h
@@ -0,0 +1,62 @@
+/*
+ * stm32-gptimer.h
+ *
+ * Copyright (C) STMicroelectronics 2016
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#ifndef _LINUX_STM32_GPTIMER_H_
+#define _LINUX_STM32_GPTIMER_H_
+
+#include <linux/clk.h>
+#include <linux/regmap.h>
+
+#define TIM_CR1 0x00 /* Control Register 1 */
+#define TIM_CR2 0x04 /* Control Register 2 */
+#define TIM_SMCR 0x08 /* Slave mode control reg */
+#define TIM_DIER 0x0C /* DMA/interrupt register */
+#define TIM_SR 0x10 /* Status register */
+#define TIM_EGR 0x14 /* Event Generation Reg */
+#define TIM_CCMR1 0x18 /* Capt/Comp 1 Mode Reg */
+#define TIM_CCMR2 0x1C /* Capt/Comp 2 Mode Reg */
+#define TIM_CCER 0x20 /* Capt/Comp Enable Reg */
+#define TIM_PSC 0x28 /* Prescaler */
+#define TIM_ARR 0x2c /* Auto-Reload Register */
+#define TIM_CCR1 0x34 /* Capt/Comp Register 1 */
+#define TIM_CCR2 0x38 /* Capt/Comp Register 2 */
+#define TIM_CCR3 0x3C /* Capt/Comp Register 3 */
+#define TIM_CCR4 0x40 /* Capt/Comp Register 4 */
+#define TIM_BDTR 0x44 /* Break and Dead-Time Reg */
+
+#define TIM_CR1_CEN BIT(0) /* Counter Enable */
+#define TIM_CR1_ARPE BIT(7) /* Auto-reload Preload Ena */
+#define TIM_CR2_MMS (BIT(4) | BIT(5) | BIT(6)) /* Master mode selection */
+#define TIM_SMCR_SMS (BIT(0) | BIT(1) | BIT(2)) /* Slave mode selection */
+#define TIM_SMCR_TS (BIT(4) | BIT(5) | BIT(6)) /* Trigger selection */
+#define TIM_DIER_UIE BIT(0) /* Update interrupt */
+#define TIM_SR_UIF BIT(0) /* Update interrupt flag */
+#define TIM_EGR_UG BIT(0) /* Update Generation */
+#define TIM_CCMR_PE BIT(3) /* Channel Preload Enable */
+#define TIM_CCMR_M1 (BIT(6) | BIT(5)) /* Channel PWM Mode 1 */
+#define TIM_CCER_CC1E BIT(0) /* Capt/Comp 1 out Ena */
+#define TIM_CCER_CC1P BIT(1) /* Capt/Comp 1 Polarity */
+#define TIM_CCER_CC1NE BIT(2) /* Capt/Comp 1N out Ena */
+#define TIM_CCER_CC1NP BIT(3) /* Capt/Comp 1N Polarity */
+#define TIM_CCER_CCXE (BIT(0) | BIT(4) | BIT(8) | BIT(12))
+#define TIM_BDTR_BKE BIT(12) /* Break input enable */
+#define TIM_BDTR_BKP BIT(13) /* Break input polarity */
+#define TIM_BDTR_AOE BIT(14) /* Automatic Output Enable */
+#define TIM_BDTR_MOE BIT(15) /* Main Output Enable */
+
+#define MAX_TIM_PSC 0xFFFF
+
+struct stm32_gptimer_dev {
+ /* Device data */
+ struct clk *clk;
+
+ /* Registers mapping */
+ struct regmap *regmap;
+};
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v3 3/7] PWM: add pwm-stm32 DT bindings
From: Benjamin Gaignard @ 2016-12-02 10:17 UTC (permalink / raw)
To: lee.jones, robh+dt, mark.rutland, alexandre.torgue, devicetree,
linux-kernel, thierry.reding, linux-pwm, jic23, knaack.h, lars,
pmeerw, linux-iio, linux-arm-kernel
Cc: fabrice.gasnier, gerald.baeza, arnaud.pouliquen, linus.walleij,
linaro-kernel, benjamin.gaignard, Benjamin Gaignard
In-Reply-To: <1480673842-20804-1-git-send-email-benjamin.gaignard@st.com>
Define bindings for pwm-stm32
version 2:
- use parameters instead of compatible of handle the hardware configuration
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
.../devicetree/bindings/pwm/pwm-stm32.txt | 38 ++++++++++++++++++++++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
new file mode 100644
index 0000000..575b9fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
@@ -0,0 +1,38 @@
+STMicroelectronics PWM driver bindings for STM32
+
+Must be a sub-node of STM32 general purpose timer driver
+Parent node properties are describe in ../mfd/stm32-general-purpose-timer.txt
+
+Required parameters:
+- compatible: Must be "st,stm32-pwm"
+- pinctrl-names: Set to "default".
+- pinctrl-0: List of phandles pointing to pin configuration nodes
+ for PWM module.
+ For Pinctrl properties, please refer to [1].
+
+Optional parameters:
+- st,breakinput: Set if the hardware have break input capabilities
+- st,breakinput-polarity: Set break input polarity. Default is 0
+ The value define the active polarity:
+ - 0 (active LOW)
+ - 1 (active HIGH)
+- st,pwm-num-chan: Number of available PWM channels. Default is 0.
+- st,32bits-counter: Set if the hardware have a 32 bits counter
+- st,complementary: Set if the hardware have complementary output channels
+
+[1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+
+Example:
+ gptimer1: gptimer1@40010000 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40010000 0x400>;
+ clocks = <&rcc 0 160>;
+ clock-names = "clk_int";
+
+ pwm1@0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <4>;
+ st,breakinput;
+ st,complementary;
+ };
+ };
--
1.9.1
^ permalink raw reply related
* [PATCH v3 4/7] PWM: add pwm driver for stm32 plaftorm
From: Benjamin Gaignard @ 2016-12-02 10:17 UTC (permalink / raw)
To: lee.jones, robh+dt, mark.rutland, alexandre.torgue, devicetree,
linux-kernel, thierry.reding, linux-pwm, jic23, knaack.h, lars,
pmeerw, linux-iio, linux-arm-kernel
Cc: fabrice.gasnier, gerald.baeza, arnaud.pouliquen, linus.walleij,
linaro-kernel, benjamin.gaignard, Benjamin Gaignard
In-Reply-To: <1480673842-20804-1-git-send-email-benjamin.gaignard@st.com>
This driver add support for pwm driver on stm32 platform.
The SoC have multiple instances of the hardware IP and each
of them could have small differences: number of channels,
complementary output, counter register size...
Use DT parameters to handle those differentes configuration
version 2:
- only keep one comptatible
- use DT paramaters to discover hardware block configuration
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
drivers/pwm/Kconfig | 8 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-stm32.c | 285 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 294 insertions(+)
create mode 100644 drivers/pwm/pwm-stm32.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index bf01288..a89fdba 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -388,6 +388,14 @@ config PWM_STI
To compile this driver as a module, choose M here: the module
will be called pwm-sti.
+config PWM_STM32
+ bool "STMicroelectronics STM32 PWM"
+ depends on ARCH_STM32
+ depends on OF
+ select MFD_STM32_GP_TIMER
+ help
+ Generic PWM framework driver for STM32 SoCs.
+
config PWM_STMPE
bool "STMPE expander PWM export"
depends on MFD_STMPE
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 1194c54..5aa9308 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
obj-$(CONFIG_PWM_SPEAR) += pwm-spear.o
obj-$(CONFIG_PWM_STI) += pwm-sti.o
+obj-$(CONFIG_PWM_STM32) += pwm-stm32.o
obj-$(CONFIG_PWM_STMPE) += pwm-stmpe.o
obj-$(CONFIG_PWM_SUN4I) += pwm-sun4i.o
obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o
diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
new file mode 100644
index 0000000..a362f63
--- /dev/null
+++ b/drivers/pwm/pwm-stm32.c
@@ -0,0 +1,285 @@
+/*
+ * Copyright (C) STMicroelectronics 2016
+ * Author: Gerald Baeza <gerald.baeza@st.com>
+ * License terms: GNU General Public License (GPL), version 2
+ *
+ * Inspired by timer-stm32.c from Maxime Coquelin
+ * pwm-atmel.c from Bo Shen
+ */
+
+#include <linux/of.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+
+#include <linux/mfd/stm32-gptimer.h>
+
+#define DRIVER_NAME "stm32-pwm"
+
+#define CAP_COMPLEMENTARY BIT(0)
+#define CAP_32BITS_COUNTER BIT(1)
+#define CAP_BREAKINPUT BIT(2)
+#define CAP_BREAKINPUT_POLARITY BIT(3)
+
+struct stm32_pwm_dev {
+ struct device *dev;
+ struct clk *clk;
+ struct regmap *regmap;
+ struct pwm_chip chip;
+ int caps;
+ int npwm;
+ u32 polarity;
+};
+
+#define to_stm32_pwm_dev(x) container_of(chip, struct stm32_pwm_dev, chip)
+
+static u32 __active_channels(struct stm32_pwm_dev *pwm_dev)
+{
+ u32 ccer;
+
+ regmap_read(pwm_dev->regmap, TIM_CCER, &ccer);
+
+ return ccer & TIM_CCER_CCXE;
+}
+
+static int write_ccrx(struct stm32_pwm_dev *dev, struct pwm_device *pwm,
+ u32 ccr)
+{
+ switch (pwm->hwpwm) {
+ case 0:
+ return regmap_write(dev->regmap, TIM_CCR1, ccr);
+ case 1:
+ return regmap_write(dev->regmap, TIM_CCR2, ccr);
+ case 2:
+ return regmap_write(dev->regmap, TIM_CCR3, ccr);
+ case 3:
+ return regmap_write(dev->regmap, TIM_CCR4, ccr);
+ }
+ return -EINVAL;
+}
+
+static int stm32_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+ struct stm32_pwm_dev *dev = to_stm32_pwm_dev(chip);
+ unsigned long long prd, div, dty;
+ int prescaler = 0;
+ u32 max_arr = 0xFFFF, ccmr, mask, shift, bdtr;
+
+ if (dev->caps & CAP_32BITS_COUNTER)
+ max_arr = 0xFFFFFFFF;
+
+ /* Period and prescaler values depends of clock rate */
+ div = (unsigned long long)clk_get_rate(dev->clk) * period_ns;
+
+ do_div(div, NSEC_PER_SEC);
+ prd = div;
+
+ while (div > max_arr) {
+ prescaler++;
+ div = prd;
+ do_div(div, (prescaler + 1));
+ }
+ prd = div;
+
+ if (prescaler > MAX_TIM_PSC) {
+ dev_err(chip->dev, "prescaler exceeds the maximum value\n");
+ return -EINVAL;
+ }
+
+ /* All channels share the same prescaler and counter so
+ * when two channels are active at the same we can't change them
+ */
+ if (__active_channels(dev) & ~(1 << pwm->hwpwm * 4)) {
+ u32 psc, arr;
+
+ regmap_read(dev->regmap, TIM_PSC, &psc);
+ regmap_read(dev->regmap, TIM_ARR, &arr);
+
+ if ((psc != prescaler) || (arr != prd - 1))
+ return -EINVAL;
+ }
+
+ regmap_write(dev->regmap, TIM_PSC, prescaler);
+ regmap_write(dev->regmap, TIM_ARR, prd - 1);
+ regmap_update_bits(dev->regmap, TIM_CR1, TIM_CR1_ARPE, TIM_CR1_ARPE);
+
+ /* Calculate the duty cycles */
+ dty = prd * duty_ns;
+ do_div(dty, period_ns);
+
+ write_ccrx(dev, pwm, dty);
+
+ /* Configure output mode */
+ shift = (pwm->hwpwm & 0x1) * 8;
+ ccmr = (TIM_CCMR_PE | TIM_CCMR_M1) << shift;
+ mask = 0xFF << shift;
+
+ if (pwm->hwpwm & 0x2)
+ regmap_update_bits(dev->regmap, TIM_CCMR2, mask, ccmr);
+ else
+ regmap_update_bits(dev->regmap, TIM_CCMR1, mask, ccmr);
+
+ if (!(dev->caps & CAP_BREAKINPUT))
+ return 0;
+
+ bdtr = TIM_BDTR_MOE | TIM_BDTR_AOE;
+
+ if (dev->caps & CAP_BREAKINPUT_POLARITY)
+ bdtr |= TIM_BDTR_BKE;
+
+ if (dev->polarity)
+ bdtr |= TIM_BDTR_BKP;
+
+ regmap_update_bits(dev->regmap, TIM_BDTR,
+ TIM_BDTR_MOE | TIM_BDTR_AOE |
+ TIM_BDTR_BKP | TIM_BDTR_BKE,
+ bdtr);
+
+ return 0;
+}
+
+static int stm32_pwm_set_polarity(struct pwm_chip *chip, struct pwm_device *pwm,
+ enum pwm_polarity polarity)
+{
+ u32 mask;
+ struct stm32_pwm_dev *dev = to_stm32_pwm_dev(chip);
+
+ mask = TIM_CCER_CC1P << (pwm->hwpwm * 4);
+ if (dev->caps & CAP_COMPLEMENTARY)
+ mask |= TIM_CCER_CC1NP << (pwm->hwpwm * 4);
+
+ regmap_update_bits(dev->regmap, TIM_CCER, mask,
+ polarity == PWM_POLARITY_NORMAL ? 0 : mask);
+
+ return 0;
+}
+
+static int stm32_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ u32 mask;
+ struct stm32_pwm_dev *dev = to_stm32_pwm_dev(chip);
+
+ clk_enable(dev->clk);
+
+ /* Enable channel */
+ mask = TIM_CCER_CC1E << (pwm->hwpwm * 4);
+ if (dev->caps & CAP_COMPLEMENTARY)
+ mask |= TIM_CCER_CC1NE << (pwm->hwpwm * 4);
+
+ regmap_update_bits(dev->regmap, TIM_CCER, mask, mask);
+
+ /* Make sure that registers are updated */
+ regmap_update_bits(dev->regmap, TIM_EGR, TIM_EGR_UG, TIM_EGR_UG);
+
+ /* Enable controller */
+ regmap_update_bits(dev->regmap, TIM_CR1, TIM_CR1_CEN, TIM_CR1_CEN);
+
+ return 0;
+}
+
+static void stm32_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ u32 mask;
+ struct stm32_pwm_dev *dev = to_stm32_pwm_dev(chip);
+
+ /* Disable channel */
+ mask = TIM_CCER_CC1E << (pwm->hwpwm * 4);
+ if (dev->caps & CAP_COMPLEMENTARY)
+ mask |= TIM_CCER_CC1NE << (pwm->hwpwm * 4);
+
+ regmap_update_bits(dev->regmap, TIM_CCER, mask, 0);
+
+ /* When all channels are disabled, we can disable the controller */
+ if (!__active_channels(dev))
+ regmap_update_bits(dev->regmap, TIM_CR1, TIM_CR1_CEN, 0);
+
+ clk_disable(dev->clk);
+}
+
+static const struct pwm_ops stm32pwm_ops = {
+ .config = stm32_pwm_config,
+ .set_polarity = stm32_pwm_set_polarity,
+ .enable = stm32_pwm_enable,
+ .disable = stm32_pwm_disable,
+};
+
+static int stm32_pwm_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct stm32_gptimer_dev *mfd = dev_get_drvdata(pdev->dev.parent);
+ struct stm32_pwm_dev *pwm;
+ int ret;
+
+ pwm = devm_kzalloc(dev, sizeof(*pwm), GFP_KERNEL);
+ if (!pwm)
+ return -ENOMEM;
+
+ pwm->regmap = mfd->regmap;
+ pwm->clk = mfd->clk;
+
+ if (!pwm->regmap || !pwm->clk)
+ return -EINVAL;
+
+ if (of_property_read_bool(np, "st,complementary"))
+ pwm->caps |= CAP_COMPLEMENTARY;
+
+ if (of_property_read_bool(np, "st,32bits-counter"))
+ pwm->caps |= CAP_32BITS_COUNTER;
+
+ if (of_property_read_bool(np, "st,breakinput"))
+ pwm->caps |= CAP_BREAKINPUT;
+
+ if (!of_property_read_u32(np, "st,breakinput-polarity", &pwm->polarity))
+ pwm->caps |= CAP_BREAKINPUT_POLARITY;
+
+ of_property_read_u32(np, "st,pwm-num-chan", &pwm->npwm);
+
+ pwm->chip.base = -1;
+ pwm->chip.dev = dev;
+ pwm->chip.ops = &stm32pwm_ops;
+ pwm->chip.npwm = pwm->npwm;
+
+ ret = pwmchip_add(&pwm->chip);
+ if (ret < 0)
+ return ret;
+
+ platform_set_drvdata(pdev, pwm);
+
+ return 0;
+}
+
+static int stm32_pwm_remove(struct platform_device *pdev)
+{
+ struct stm32_pwm_dev *pwm = platform_get_drvdata(pdev);
+ int i;
+
+ for (i = 0; i < pwm->npwm; i++)
+ pwm_disable(&pwm->chip.pwms[i]);
+
+ pwmchip_remove(&pwm->chip);
+
+ return 0;
+}
+
+static const struct of_device_id stm32_pwm_of_match[] = {
+ {
+ .compatible = "st,stm32-pwm",
+ },
+};
+MODULE_DEVICE_TABLE(of, stm32_pwm_of_match);
+
+static struct platform_driver stm32_pwm_driver = {
+ .probe = stm32_pwm_probe,
+ .remove = stm32_pwm_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+ .of_match_table = stm32_pwm_of_match,
+ },
+};
+module_platform_driver(stm32_pwm_driver);
+
+MODULE_ALIAS("platform:" DRIVER_NAME);
+MODULE_DESCRIPTION("STMicroelectronics STM32 PWM driver");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox