* Re: [PATCH v13 0/7] dtc: Dynamic DT support
From: Pantelis Antoniou @ 2016-12-09 8:16 UTC (permalink / raw)
To: David Gibson
Cc: Jon Loeliger, Grant Likely, Frank Rowand, 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: <20161209055709.GP13139-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
Hi David,
> On Dec 9, 2016, at 07:57 , David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
>
> On Wed, Dec 07, 2016 at 02:48:16PM +0200, Pantelis Antoniou wrote:
>> This patchset adds Dynamic DT support in the DTC compiler
>> as used in a number of boards like the beaglebone/rpi/chip and others.
>>
>> The first patch documents the internals of overlay generation, while
>> the second one adds dynamic object/overlay support proper.
>>
>> The third patch adds a test method that can is used by the subsequent
>> patch which adds a few overlay tests verifying operation.
>>
>> The following 3 patches add support for the syntactic sugar version
>> of &foo { }; in a similar manner.
>>
>> This patchset is against DTC mainline and is also available for a pull
>> request from https://github.com/pantoniou/dtc/tree/overlays
>
> Ok, I've merged patches 1-4 into mainline, along with a bunch of minor
> fixes of my own on top. 5..7 (the start of the new) I want to hold
> off on for now, to thrash out the details of what we want a new
> cleaner format to look like a bit more thoroughly.
>
Thank you.
My git tree contains an updated patchset of the syntactic sugar patches
for reference now.
Regards
— Pantelis
>>
>> Regards
>>
>> -- Pantelis
>>
>> Changes since v12:
>> * Dropped DTBO magic option completely.
>> * Dropped fixup generation option.
>> * Renamed dstversionflags to dstflags
>> * Drop support for the new style /plugin/ tag.
>>
>> Changes since v11:
>> * Syntax and grammatical fixes to the documentation.
>> * Renamed options and internal variables controlling generation of symbols
>> and fixups.
>> * Rename version flags to specify that they refer to DTS version.
>> * Made sure that no symbols/fixup nodes are only generated if they contain
>> entries.
>>
>> Changes since v10:
>> * Split out the syntactic sugar version of &foo { }; into a different
>> patches to make things clearer.
>> * Reworked a bit the arguments passed to fixup node generation method
>> making things simpler and utilize common methodology.
>> * Avoid string parsing the full path using the node walking instead for
>> local fixup generation.
>> * Added an option to suppress generation of fixup nodes on base trees.
>> * Added automatic generation of symbols and fixups when compiling a
>> plugin.
>> * Minor rework according to maintainer requests.
>>
>> Changes since v9:
>> * Reversed -M switch to by default use new DTBO magic value.
>> * Removed global versionflags in the parser by using inherited
>> attributes.
>> * build_node instead of malloc at add_orphan_node().
>> * Do not use escape for path copy
>> * Do not generate /plugin/ when generating a dts file even when
>> the plugin flag is set..
>>
>> Changes since v8:
>> * Removed extra member of boot_info in each node; passing boot_info
>> parameter to the check methods instead.
>> * Reworked yacc syntax that supports both old and new plugin syntax
>> * Added handling for new magic number (enabled by 'M' switch).
>> * Dropped dtbo/asmo formats.
>> * Added overlay testsuite.
>> * Addressed last version maintainer comments.
>>
>> Changes since v7:
>> * Dropped xasprintf & backward compatibility patch
>> * Rebased against dgibson's overlay branch
>> * Minor doc wording fixes.
>>
>> Changes since v6:
>> * Introduced xasprintf
>> * Added append_to_property and used it
>> * Changed some die()'s to assert
>> * Reordered node generation to respect sort
>> * Addressed remaining maintainer changes from v6
>>
>> Changes since v5:
>> * Rebase to latest dtc version.
>> * Addressed all the maintainer requested changes from v5
>> * Added new magic value for dynamic objects and new format
>>
>> Changes since v4:
>> * Rebase to latest dtc version.
>> * Completely redesigned the generation of resolution data.
>> Now instead of being generated as part of blob generation
>> they are created in the live tree.
>> * Consequently the patchset is much smaller.
>> * Added -A auto-label alias generation option.
>> * Addressed maintainer comments.
>> * Added syntactic sugar for overlays in the form of .dtsi
>> * Added /dts-v1/ /plugin/ preferred plugin form and deprecate
>> the previous form (although still works for backward compatibility)
>>
>> Changes since v3:
>> * Rebase to latest dtc version.
>>
>> Changes since v2:
>> * Split single patch to a patchset.
>> * Updated to dtc mainline.
>> * Changed __local_fixups__ format
>> * Clean up for better legibility.
>> Pantelis Antoniou (7):
>> dtc: Document the dynamic plugin internals
>> dtc: Plugin and fixup support
>> tests: Add check_path test
>> tests: Add overlay tests
>> overlay: Documentation for the overlay sugar syntax
>> overlay: Add syntactic sugar version of overlays
>> tests: Add a test for overlays syntactic sugar
>>
>> Documentation/dt-object-internal.txt | 327 +++++++++++++++++++++++++++++++++++
>> Documentation/manual.txt | 21 ++-
>> checks.c | 8 +-
>> dtc-lexer.l | 5 +
>> dtc-parser.y | 48 ++++-
>> dtc.c | 33 +++-
>> dtc.h | 17 +-
>> flattree.c | 2 +-
>> fstree.c | 2 +-
>> livetree.c | 291 ++++++++++++++++++++++++++++++-
>> tests/.gitignore | 1 +
>> tests/Makefile.tests | 3 +-
>> tests/check_path.c | 82 +++++++++
>> tests/overlay_base_fixups.dts | 22 +++
>> tests/overlay_overlay_dtc.dts | 1 +
>> tests/overlay_overlay_simple.dts | 12 ++
>> tests/run_tests.sh | 38 ++++
>> 17 files changed, 898 insertions(+), 15 deletions(-)
>> create mode 100644 Documentation/dt-object-internal.txt
>> create mode 100644 tests/check_path.c
>> create mode 100644 tests/overlay_base_fixups.dts
>> create mode 100644 tests/overlay_overlay_simple.dts
>>
>
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] arm: dts: sun8i: reuse the uart1 node of iNet D978 rev2 board
From: Maxime Ripard @ 2016-12-09 8:11 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Hans de Goede, linux-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <20161205184745.lfW8ji5w-3YhIAYTWRJA0PDqKvflMoHmW9unr2Ajn@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1787 bytes --]
On Mon, Dec 05, 2016 at 05:03:35PM +0800, Icenowy Zheng wrote:
>
> 2016年12月5日 16:50于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
> >
> > On Fri, Dec 02, 2016 at 11:19:13PM +0800, Icenowy Zheng wrote:
> > > As a uart1 node is added into sun8i-reference-design-tablet.dtsi, simply
> > > use it in iNet D978 rev2 device tree.
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> >
> > I'd like to see more consolidation before that change is needed. If we
> > find more boards using that, it will make sense, but for a single
> > board it's not worth it.
>
> At least 2~3 Q8 A33 tablets in #linux-sunxi are found to have
> rtl8703as, which contains UART bluetooth. (including mine)
Still, I'm not fond of creating a default on such a low count sample
of (out-of-tree) DTs. Support and enable the bluetooth on more boards,
and then consolidate.
> In fact, what I want to do is to get the node ready-to-be-okay in Q8
> dts, so it can be enabled by either u-boot command or (theortically)
> Hans de Goede's q8-hardwaremgr, just like what is done at
> touchscreen node.
If your plan is to enable all the combinations possible accross the Q8
tablets and let the bootloader/user figure it all out, then it's not
going to happen, sorry.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi
From: Maxime Ripard @ 2016-12-09 8:07 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Hans de Goede, Chen-Yu Tsai, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20161206080838.7523-1-icenowy@aosc.xyz>
[-- Attachment #1.1: Type: text/plain, Size: 1851 bytes --]
On Tue, Dec 06, 2016 at 04:08:38PM +0800, Icenowy Zheng wrote:
> Some SDIO Wi-Fi chips (such as RTL8703AS) have a UART bluetooth, which
> has a dedicated enable pin (PL8 in the reference design).
>
> Enable the pin in the same way as the WLAN enable pins.
>
> Tested on an A33 Q8 tablet with RTL8703AS.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
>
> This patch should be coupled with the uart1 node patch I send before:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/471997.html
>
> For RTL8703AS, the rtl8723bs bluetooth code is used, which can be retrieve from:
> https://github.com/lwfinger/rtl8723bs_bt
>
> arch/arm/boot/dts/sun8i-q8-common.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi b/arch/arm/boot/dts/sun8i-q8-common.dtsi
> index c676940..4aeb5bb 100644
> --- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
> +++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
> @@ -88,7 +88,7 @@
>
> &r_pio {
> wifi_pwrseq_pin_q8: wifi_pwrseq_pin@0 {
> - pins = "PL6", "PL7", "PL11";
> + pins = "PL6", "PL7", "PL8", "PL11";
> function = "gpio_in";
> bias-pull-up;
> };
There's several things wrong here. The first one is that you rely
solely on the pinctrl state to maintain a reset line. This is very
fragile (especially since the GPIO pinctrl state are likely to go away
at some point), but it also means that if your driver wants to recover
from that situation at some point, it won't work.
The other one is that the bluetooth and wifi chips are two devices in
linux, and you assign that pin to the wrong device (wifi).
rfkill-gpio is made just for that, so please use it.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] clk: keystone: Add sci-clk driver support
From: Tero Kristo @ 2016-12-09 8:05 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-clk-u79uwXL29TY76Z2rM5mHXA,
mturquette-rdvid1DuHRBWk0Htik3J/w,
ssantosh-DgEjT+Ai2ygdnm+yROfE0A, nm-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161208211044.GI5423-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 08/12/16 23:10, Stephen Boyd wrote:
> On 12/08, Tero Kristo wrote:
>> On 08/12/16 02:13, Stephen Boyd wrote:
>>> On 10/21, Tero Kristo wrote:
>>>> diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c
>>>> new file mode 100644
>>>> index 0000000..f6af5bd
>>>> --- /dev/null
>>>> +++ b/drivers/clk/keystone/sci-clk.c
>>
>>>
>>>> +
>>>> + handle = devm_ti_sci_get_handle(dev);
>>>> + if (IS_ERR(handle))
>>>> + return PTR_ERR(handle);
>>>> +
>>>> + provider = devm_kzalloc(dev, sizeof(*provider), GFP_KERNEL);
>>>> + if (!provider)
>>>> + return -ENOMEM;
>>>> +
>>>> + provider->clocks = data;
>>>> +
>>>> + provider->sci = handle;
>>>> + provider->ops = &handle->ops.clk_ops;
>>>> + provider->dev = dev;
>>>> +
>>>> + ti_sci_init_clocks(provider);
>>>
>>> And if this fails?
>>
>> Yea this is kind of controversial. ti_sci_init_clocks() can fail if
>> any of the clocks registered will fail. I decided to have it this
>> way so that at least some clocks might work in failure cause, and
>> you might have a booting device instead of total lock-up.
>>
>> Obviously it could be done so that if any clock fails, we would
>> de-register all clocks at that point, but personally I think this is
>> a worse option.
>>
>> ti_sci_init_clocks could probably be modified to continue
>> registering clocks when a single clock fails though. Currently it
>> aborts at first failure.
>>
>
> That sounds like a better approach if we don't care about
> failures to register a clock. Returning a value from a function
> and not using it isn't really a great design.
>
> I worry that if we start returning errors from clk_hw_register()
> that something will go wrong though, so really I don't know why
> we want to ignore errors at all. Just for debugging a boot hang?
> Can't we use early console to at least see that this driver is
> failing to probe and debug that way?
Early console can be used to debug that, but it is kind of annoying to
recompile most of the kernel when you suddenly need to use it.
How about modifying the ti_sci_init_clocks func to print an error for
each failed clock?
If you insist on aborting the probe though if a single clock fails, I
can do that also.
-Tero
--
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: [RESEND PATCH v2 0/7] drm/vc4: VEC (SDTV) output support
From: Boris Brezillon @ 2016-12-09 7:45 UTC (permalink / raw)
To: Stefan Wahren
Cc: linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Scott Branden,
Ray Jui, Lee Jones, Pawel Moll, Ian Campbell, Rob Herring,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Kumar Gala,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Daniel Vetter,
Mark Rutland, Florian Fainelli,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, David Airlie
In-Reply-To: <68783643.33021.1481268157922-7tX72C7vayboQLBSYMtkGA@public.gmane.org>
On Fri, 9 Dec 2016 08:22:37 +0100 (CET)
Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org> wrote:
> Hi,
>
> > Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> hat am 2. Dezember 2016 um 14:48 geschrieben:
> >
> >
> > Sorry for the noise, but I forgot to Cc the DT maintainers.
> >
> > Here is the 2nd version of the VC4/VEC series.
> >
> > We still miss the two clock patches mentioned by Eric in the first
> > version to make the encoder work no matter the setting applied by the
> > bootloader.
>
> are there any advices to test this feature?
Apply these patches [1][2][3][4] in addition to this series, and you
should see the SDTV output when running modetest (this is what I used
to test/debug the driver).
This is the command I use to test the SDTV output in NTSC mode
modetest -s 39:720x480
>
> Is it possible to use an old Raspberry Pi B (256 MB RAM) for this?
I did most of my test on a RPi-2, but IIRC, Eric tested it on a RPi
(don't know which model).
>
> Thanks
>
> Stefan
[1]https://patchwork.kernel.org/patch/9442127/
[2]https://patchwork.kernel.org/patch/9456911/
[3]https://patchwork.kernel.org/patch/9456909/
[4]https://patchwork.kernel.org/patch/9456731/
--
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: [RESEND PATCH v2 0/7] drm/vc4: VEC (SDTV) output support
From: Stefan Wahren @ 2016-12-09 7:22 UTC (permalink / raw)
To: Boris Brezillon,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Scott Branden, Ray Jui, Lee Jones, Pawel Moll, Ian Campbell,
Rob Herring, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
Kumar Gala, bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
Daniel Vetter, Mark Rutland, Florian Fainelli,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, David Airlie
In-Reply-To: <1480686493-4813-1-git-send-email-boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi,
> Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> hat am 2. Dezember 2016 um 14:48 geschrieben:
>
>
> Sorry for the noise, but I forgot to Cc the DT maintainers.
>
> Here is the 2nd version of the VC4/VEC series.
>
> We still miss the two clock patches mentioned by Eric in the first
> version to make the encoder work no matter the setting applied by the
> bootloader.
are there any advices to test this feature?
Is it possible to use an old Raspberry Pi B (256 MB RAM) for this?
Thanks
Stefan
--
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] arm64: ls1012a: dts: add eSDHC nodes
From: Yangbo Lu @ 2016-12-09 6:29 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Yangbo Lu
There are two eSDHC controllers in LS1012A. This patch is to add
eSDHC nodes for ls1012a dts. Also enable eSDHC for RDB/QDS boards.
Signed-off-by: Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org>
---
Changes for v2:
- Added 'broken-cd' in esdhc2 node
- Enabled esdhc in board dts
---
arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 8 ++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 8 ++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 25 +++++++++++++++++++++++
3 files changed, 41 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
index b841251..cc35114 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
@@ -126,3 +126,11 @@
&sai2 {
status = "okay";
};
+
+&esdhc0 {
+ status = "okay";
+};
+
+&esdhc1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
index 62c5c71..0eef319 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
@@ -57,3 +57,11 @@
&i2c0 {
status = "okay";
};
+
+&esdhc0 {
+ status = "okay";
+};
+
+&esdhc1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 24874d7..18310ca 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -128,6 +128,31 @@
clocks = <&sysclk>;
};
+ esdhc0: esdhc@1560000 {
+ compatible = "fsl,ls1012a-esdhc", "fsl,esdhc";
+ reg = <0x0 0x1560000 0x0 0x10000>;
+ interrupts = <0 62 0x4>;
+ clock-frequency = <0>;
+ voltage-ranges = <1800 1800 3300 3300>;
+ sdhci,auto-cmd12;
+ big-endian;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
+ esdhc1: esdhc@1580000 {
+ compatible = "fsl,ls1012a-esdhc", "fsl,esdhc";
+ reg = <0x0 0x1580000 0x0 0x10000>;
+ interrupts = <0 65 0x4>;
+ clock-frequency = <0>;
+ voltage-ranges = <1800 1800 3300 3300>;
+ sdhci,auto-cmd12;
+ big-endian;
+ broken-cd;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
i2c0: i2c@2180000 {
compatible = "fsl,vf610-i2c";
#address-cells = <1>;
--
2.1.0.27.g96db324
--
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/4] dt-bindings: input: Specify the interrupt number of TPS65217 power button
From: Milo Kim @ 2016-12-09 6:28 UTC (permalink / raw)
To: bcousson, Tony Lindgren
Cc: Arnd Bergmann, Lee Jones, Sebastian Reichel, Dmitry Torokhov,
linux-omap, devicetree, linux-arm-kernel, linux-kernel, Milo Kim
In-Reply-To: <20161209062833.5768-1-woogyom.kim@gmail.com>
Specify the power button interrupt number which is from the datasheet.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt b/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
index 3e5b979..8682ab6 100644
--- a/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
+++ b/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
@@ -8,8 +8,9 @@ This driver provides a simple power button event via an Interrupt.
Required properties:
- compatible: should be "ti,tps65217-pwrbutton" or "ti,tps65218-pwrbutton"
-Required properties for TPS65218:
+Required properties:
- interrupts: should be one of the following
+ - <2>: For controllers compatible with tps65217
- <3 IRQ_TYPE_EDGE_BOTH>: For controllers compatible with tps65218
Examples:
@@ -17,6 +18,7 @@ Examples:
&tps {
tps65217-pwrbutton {
compatible = "ti,tps65217-pwrbutton";
+ interrupts = <2>;
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH 3/4] dt-bindings: power/supply: Update TPS65217 properties
From: Milo Kim @ 2016-12-09 6:28 UTC (permalink / raw)
To: bcousson-rdvid1DuHRBWk0Htik3J/w, Tony Lindgren
Cc: Arnd Bergmann, Lee Jones, Sebastian Reichel, Dmitry Torokhov,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Milo Kim
In-Reply-To: <20161209062833.5768-1-woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Add interrupt specifiers for USB and AC charger input. Interrupt numbers
are from the datasheet.
Fix wrong property for compatible string.
Signed-off-by: Milo Kim <woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
.../devicetree/bindings/power/supply/tps65217_charger.txt | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt b/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
index 98d131a..a11072c 100644
--- a/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
+++ b/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
@@ -2,11 +2,16 @@ TPS65217 Charger
Required Properties:
-compatible: "ti,tps65217-charger"
+-interrupts: TPS65217 interrupt numbers for the AC and USB charger input change.
+ Should be <0> for the USB charger and <1> for the AC adapter.
+-interrupt-names: Should be "USB" and "AC"
This node is a subnode of the tps65217 PMIC.
Example:
tps65217-charger {
- compatible = "ti,tps65090-charger";
+ compatible = "ti,tps65217-charger";
+ interrupts = <0>, <1>;
+ interrupt-names = "USB", "AC";
};
--
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/4] dt-bindings: mfd: Remove TPS65217 interrupts
From: Milo Kim @ 2016-12-09 6:28 UTC (permalink / raw)
To: bcousson, Tony Lindgren
Cc: Arnd Bergmann, Lee Jones, Sebastian Reichel, Dmitry Torokhov,
linux-omap, devicetree, linux-arm-kernel, linux-kernel, Milo Kim
In-Reply-To: <20161209062833.5768-1-woogyom.kim@gmail.com>
Interrupt numbers are from the datasheet, so no need to keep them in
the ABI. Use the number in the DT file.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 8 +++-----
include/dt-bindings/mfd/tps65217.h | 26 --------------------------
2 files changed, 3 insertions(+), 31 deletions(-)
delete mode 100644 include/dt-bindings/mfd/tps65217.h
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 14b6269..3e32dd1 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -6,8 +6,6 @@
* published by the Free Software Foundation.
*/
-#include <dt-bindings/mfd/tps65217.h>
-
/ {
cpus {
cpu@0 {
@@ -319,13 +317,13 @@
ti,pmic-shutdown-controller;
charger {
- interrupts = <TPS65217_IRQ_AC>, <TPS65217_IRQ_USB>;
- interrupt-names = "AC", "USB";
+ interrupts = <0>, <1>;
+ interrupt-names = "USB", "AC";
status = "okay";
};
pwrbutton {
- interrupts = <TPS65217_IRQ_PB>;
+ interrupts = <2>;
status = "okay";
};
diff --git a/include/dt-bindings/mfd/tps65217.h b/include/dt-bindings/mfd/tps65217.h
deleted file mode 100644
index cafb9e6..0000000
--- a/include/dt-bindings/mfd/tps65217.h
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- * This header provides macros for TI TPS65217 DT bindings.
- *
- * Copyright (C) 2016 Texas Instruments
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see <http://www.gnu.org/licenses/>.
- */
-
-#ifndef __DT_BINDINGS_TPS65217_H__
-#define __DT_BINDINGS_TPS65217_H__
-
-#define TPS65217_IRQ_USB 0
-#define TPS65217_IRQ_AC 1
-#define TPS65217_IRQ_PB 2
-
-#endif
--
2.9.3
^ permalink raw reply related
* [PATCH 1/4] ARM: dts: am335x: Fix the interrupt name of TPS65217
From: Milo Kim @ 2016-12-09 6:28 UTC (permalink / raw)
To: bcousson, Tony Lindgren
Cc: Arnd Bergmann, Lee Jones, Sebastian Reichel, Dmitry Torokhov,
linux-omap, devicetree, linux-arm-kernel, linux-kernel, Milo Kim
In-Reply-To: <20161209062833.5768-1-woogyom.kim@gmail.com>
Use 'interrupt-names' for getting the charger interrupt number.
Fixes: 1934e89a769b ("ARM: dts: am335x: Add the charger interrupt")
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index dc561d5..14b6269 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -320,7 +320,7 @@
charger {
interrupts = <TPS65217_IRQ_AC>, <TPS65217_IRQ_USB>;
- interrupts-names = "AC", "USB";
+ interrupt-names = "AC", "USB";
status = "okay";
};
--
2.9.3
^ permalink raw reply related
* [PATCH 0/4] dt-bindings: mfd: Update TPS65217 interrupts
From: Milo Kim @ 2016-12-09 6:28 UTC (permalink / raw)
To: bcousson-rdvid1DuHRBWk0Htik3J/w, Tony Lindgren
Cc: Arnd Bergmann, Lee Jones, Sebastian Reichel, Dmitry Torokhov,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Milo Kim
This patch-set fixes wrong property name and uses TPS65217 HW interrupt
number from the datasheet instead of the DT ABI. DT bindings are also
updated.
Milo Kim (4):
ARM: dts: am335x: Fix the interrupt name of TPS65217
dt-bindings: mfd: Remove TPS65217 interrupts
dt-bindings: power/supply: Update TPS65217 properties
dt-bindings: input: Add interrupt number for TPS65217
.../bindings/input/tps65218-pwrbutton.txt | 4 +++-
.../bindings/power/supply/tps65217_charger.txt | 7 +++++-
arch/arm/boot/dts/am335x-bone-common.dtsi | 8 +++----
include/dt-bindings/mfd/tps65217.h | 26 ----------------------
4 files changed, 12 insertions(+), 33 deletions(-)
delete mode 100644 include/dt-bindings/mfd/tps65217.h
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v13 0/7] dtc: Dynamic DT support
From: David Gibson @ 2016-12-09 5:57 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Jon Loeliger, Grant Likely, Frank Rowand, 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: <1481114903-8197-1-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 5956 bytes --]
On Wed, Dec 07, 2016 at 02:48:16PM +0200, Pantelis Antoniou wrote:
> This patchset adds Dynamic DT support in the DTC compiler
> as used in a number of boards like the beaglebone/rpi/chip and others.
>
> The first patch documents the internals of overlay generation, while
> the second one adds dynamic object/overlay support proper.
>
> The third patch adds a test method that can is used by the subsequent
> patch which adds a few overlay tests verifying operation.
>
> The following 3 patches add support for the syntactic sugar version
> of &foo { }; in a similar manner.
>
> This patchset is against DTC mainline and is also available for a pull
> request from https://github.com/pantoniou/dtc/tree/overlays
Ok, I've merged patches 1-4 into mainline, along with a bunch of minor
fixes of my own on top. 5..7 (the start of the new) I want to hold
off on for now, to thrash out the details of what we want a new
cleaner format to look like a bit more thoroughly.
>
> Regards
>
> -- Pantelis
>
> Changes since v12:
> * Dropped DTBO magic option completely.
> * Dropped fixup generation option.
> * Renamed dstversionflags to dstflags
> * Drop support for the new style /plugin/ tag.
>
> Changes since v11:
> * Syntax and grammatical fixes to the documentation.
> * Renamed options and internal variables controlling generation of symbols
> and fixups.
> * Rename version flags to specify that they refer to DTS version.
> * Made sure that no symbols/fixup nodes are only generated if they contain
> entries.
>
> Changes since v10:
> * Split out the syntactic sugar version of &foo { }; into a different
> patches to make things clearer.
> * Reworked a bit the arguments passed to fixup node generation method
> making things simpler and utilize common methodology.
> * Avoid string parsing the full path using the node walking instead for
> local fixup generation.
> * Added an option to suppress generation of fixup nodes on base trees.
> * Added automatic generation of symbols and fixups when compiling a
> plugin.
> * Minor rework according to maintainer requests.
>
> Changes since v9:
> * Reversed -M switch to by default use new DTBO magic value.
> * Removed global versionflags in the parser by using inherited
> attributes.
> * build_node instead of malloc at add_orphan_node().
> * Do not use escape for path copy
> * Do not generate /plugin/ when generating a dts file even when
> the plugin flag is set..
>
> Changes since v8:
> * Removed extra member of boot_info in each node; passing boot_info
> parameter to the check methods instead.
> * Reworked yacc syntax that supports both old and new plugin syntax
> * Added handling for new magic number (enabled by 'M' switch).
> * Dropped dtbo/asmo formats.
> * Added overlay testsuite.
> * Addressed last version maintainer comments.
>
> Changes since v7:
> * Dropped xasprintf & backward compatibility patch
> * Rebased against dgibson's overlay branch
> * Minor doc wording fixes.
>
> Changes since v6:
> * Introduced xasprintf
> * Added append_to_property and used it
> * Changed some die()'s to assert
> * Reordered node generation to respect sort
> * Addressed remaining maintainer changes from v6
>
> Changes since v5:
> * Rebase to latest dtc version.
> * Addressed all the maintainer requested changes from v5
> * Added new magic value for dynamic objects and new format
>
> Changes since v4:
> * Rebase to latest dtc version.
> * Completely redesigned the generation of resolution data.
> Now instead of being generated as part of blob generation
> they are created in the live tree.
> * Consequently the patchset is much smaller.
> * Added -A auto-label alias generation option.
> * Addressed maintainer comments.
> * Added syntactic sugar for overlays in the form of .dtsi
> * Added /dts-v1/ /plugin/ preferred plugin form and deprecate
> the previous form (although still works for backward compatibility)
>
> Changes since v3:
> * Rebase to latest dtc version.
>
> Changes since v2:
> * Split single patch to a patchset.
> * Updated to dtc mainline.
> * Changed __local_fixups__ format
> * Clean up for better legibility.
> Pantelis Antoniou (7):
> dtc: Document the dynamic plugin internals
> dtc: Plugin and fixup support
> tests: Add check_path test
> tests: Add overlay tests
> overlay: Documentation for the overlay sugar syntax
> overlay: Add syntactic sugar version of overlays
> tests: Add a test for overlays syntactic sugar
>
> Documentation/dt-object-internal.txt | 327 +++++++++++++++++++++++++++++++++++
> Documentation/manual.txt | 21 ++-
> checks.c | 8 +-
> dtc-lexer.l | 5 +
> dtc-parser.y | 48 ++++-
> dtc.c | 33 +++-
> dtc.h | 17 +-
> flattree.c | 2 +-
> fstree.c | 2 +-
> livetree.c | 291 ++++++++++++++++++++++++++++++-
> tests/.gitignore | 1 +
> tests/Makefile.tests | 3 +-
> tests/check_path.c | 82 +++++++++
> tests/overlay_base_fixups.dts | 22 +++
> tests/overlay_overlay_dtc.dts | 1 +
> tests/overlay_overlay_simple.dts | 12 ++
> tests/run_tests.sh | 38 ++++
> 17 files changed, 898 insertions(+), 15 deletions(-)
> create mode 100644 Documentation/dt-object-internal.txt
> create mode 100644 tests/check_path.c
> create mode 100644 tests/overlay_base_fixups.dts
> create mode 100644 tests/overlay_overlay_simple.dts
>
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] misc: eeprom: implement compatible DT probing
From: Peter Rosin @ 2016-12-09 5:48 UTC (permalink / raw)
To: Linus Walleij
Cc: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CACRpkda+_0+y6U-gjt2ym45gi=KZ69hixMw6T=tAQGTGy5J37Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 2016-12-09 00:32, Linus Walleij wrote:
> On Thu, Dec 8, 2016 at 7:23 PM, Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org> wrote:
>> On 2016-12-08 18:47, Linus Walleij wrote:
>
>>> Before this patch, the following device tree node does not probe,
>>> which might be considered a bug:
>>>
>>> eeprom@52 {
>>> compatible = "atmel,at24c128";
>>
>> The way I read it, that should be "atmel,24c128", i.e. w/o the "at" prefix.
> (...)
>> and then lists the compatibles you have added to the match table (but you
>> have this extra "at" prefix for the atmel manufacturer).
>>
>> The way I read the above, you are free to use any manufacturer and still
>> have it work, and indeed, I have success with this node:
>>
>> eeprom@50 {
>> compatible = "nxp,24c02";
>> reg = <0x50>;
>> pagesize = <16>;
>> };
>>
>> I fear that your patch will regress this matching on the wildcard
>> manufacturer. I haven't tested that though, but there are enough
>> question marks anyway...
>
> Bah I probably just screwed up syntactically and now worked around
> a non-existing problem. I will try as you suggest, just "vendor,type"
> and see if it works. It probably does.
But it is a bit strange. Grepping for compatible.*24c finds quite
a few instances of "bad" compatible strings.
Many on the patterns at,24c256 and at24,24c256 (should be probably
be atmel,24c256) but also a few atmel,at24c16 and atmel,at24c128b.
I don't understand how those last ones ever worked, if it is not
working for you? Especially those with the trailing "b". WTF?
> Some days I feel just utterly stupid. Sorry for the fuzz.
Join the club...
Cheers,
Peter
> Wolfram: ignore the patch for now.
--
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 v9 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Joel Holdsworth @ 2016-12-09 5:35 UTC (permalink / raw)
To: atull, moritz.fischer, robh, devicetree, linux-kernel, linux-spi,
marex
Cc: Joel Holdsworth
In-Reply-To: <1481261749-15301-1-git-send-email-joel@airwebreathe.org.uk>
The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
and very regular structure, designed for low-cost, high-volume consumer
and system applications.
This patch adds support to the FPGA manager for configuring the SRAM of
iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite and iCE40
UltraPlus devices, through slave SPI.
The iCE40 family is notable because it is the first FPGA family to have
complete reverse engineered bit-stream documentation for the iCE40LP and
iCE40HX devices. Furthermore, there is now a Free Software Verilog
synthesis tool-chain: the "IceStorm" tool-chain.
This project is the work of Clifford Wolf, who is the maintainer of
Yosys Verilog RTL synthesis framework, and Mathias Lasser, with notable
contributions from "Cotton Seed", the main author of "arachne-pnr"; a
place-and-route tool for iCE40 FPGAs.
Having a Free Software synthesis tool-chain offers interesting
opportunities for embedded devices that are able reconfigure themselves
with open firmware that is generated on the device itself. For example
a mobile device might have an application processor with an iCE40 FPGA
attached, which implements slave devices, or through which the processor
communicates with other devices through the FPGA fabric.
A kernel driver for the iCE40 is useful, because in some cases, the FPGA
may need to be configured before other devices can be accessed.
An example of such a device is the icoBoard; a RaspberryPI HAT which
features an iCE40HX8K with a 1 or 8 MBit SRAM and ports for
Digilent-compatible PMOD modules. A PMOD module may contain a device
with which the kernel communicates, via the FPGA.
Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>
---
drivers/fpga/Kconfig | 6 ++
drivers/fpga/Makefile | 1 +
drivers/fpga/ice40-spi.c | 213 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 220 insertions(+)
create mode 100644 drivers/fpga/ice40-spi.c
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index ce861a2..967cda4 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -20,6 +20,12 @@ config FPGA_REGION
FPGA Regions allow loading FPGA images under control of
the Device Tree.
+config FPGA_MGR_ICE40_SPI
+ tristate "Lattice iCE40 SPI"
+ depends on OF && SPI
+ help
+ FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
+
config FPGA_MGR_SOCFPGA
tristate "Altera SOCFPGA FPGA Manager"
depends on ARCH_SOCFPGA || COMPILE_TEST
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8df07bc..cc0d364 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -6,6 +6,7 @@
obj-$(CONFIG_FPGA) += fpga-mgr.o
# FPGA Manager Drivers
+obj-$(CONFIG_FPGA_MGR_ICE40_SPI) += ice40-spi.o
obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
diff --git a/drivers/fpga/ice40-spi.c b/drivers/fpga/ice40-spi.c
new file mode 100644
index 0000000..3c99859
--- /dev/null
+++ b/drivers/fpga/ice40-spi.c
@@ -0,0 +1,213 @@
+/*
+ * FPGA Manager Driver for Lattice iCE40.
+ *
+ * Copyright (c) 2016 Joel Holdsworth
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This driver adds support to the FPGA manager for configuring the SRAM of
+ * Lattice iCE40 FPGAs through slave SPI.
+ */
+
+#include <linux/fpga/fpga-mgr.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+#include <linux/spi/spi.h>
+
+#define ICE40_SPI_FPGAMGR_RESET_DELAY 1 /* us (>200ns) */
+#define ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY 1200 /* us */
+
+#define ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES DIV_ROUND_UP(49, 8)
+
+struct ice40_fpga_priv {
+ struct spi_device *dev;
+ struct gpio_desc *reset;
+ struct gpio_desc *cdone;
+};
+
+static enum fpga_mgr_states ice40_fpga_ops_state(struct fpga_manager *mgr)
+{
+ struct ice40_fpga_priv *priv = mgr->priv;
+
+ return gpiod_get_value(priv->cdone) ? FPGA_MGR_STATE_OPERATING :
+ FPGA_MGR_STATE_UNKNOWN;
+}
+
+static int ice40_fpga_ops_write_init(struct fpga_manager *mgr,
+ struct fpga_image_info *info,
+ const char *buf, size_t count)
+{
+ struct ice40_fpga_priv *priv = mgr->priv;
+ struct spi_device *dev = priv->dev;
+ struct spi_message message;
+ struct spi_transfer assert_cs_then_reset_delay = {
+ .cs_change = 1,
+ .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY
+ };
+ struct spi_transfer housekeeping_delay_then_release_cs = {
+ .delay_usecs = ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY
+ };
+ int ret;
+
+ if ((info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
+ dev_err(&dev->dev,
+ "Partial reconfiguration is not supported\n");
+ return -ENOTSUPP;
+ }
+
+ /* Lock the bus, assert CRESET_B and SS_B and delay >200ns */
+ spi_bus_lock(dev->master);
+
+ gpiod_set_value(priv->reset, 1);
+
+ spi_message_init(&message);
+ spi_message_add_tail(&assert_cs_then_reset_delay, &message);
+ ret = spi_sync_locked(dev, &message);
+
+ /* Come out of reset */
+ gpiod_set_value(priv->reset, 0);
+
+ /* Abort if the chip-select failed */
+ if (ret)
+ goto fail;
+
+ /* Check CDONE is de-asserted i.e. the FPGA is reset */
+ if (gpiod_get_value(priv->cdone)) {
+ dev_err(&dev->dev, "Device reset failed, CDONE is asserted\n");
+ ret = -EIO;
+ goto fail;
+ }
+
+ /* Wait for the housekeeping to complete, and release SS_B */
+ spi_message_init(&message);
+ spi_message_add_tail(&housekeeping_delay_then_release_cs, &message);
+ ret = spi_sync_locked(dev, &message);
+
+fail:
+ spi_bus_unlock(dev->master);
+
+ return ret;
+}
+
+static int ice40_fpga_ops_write(struct fpga_manager *mgr,
+ const char *buf, size_t count)
+{
+ struct ice40_fpga_priv *priv = mgr->priv;
+
+ return spi_write(priv->dev, buf, count);
+}
+
+static int ice40_fpga_ops_write_complete(struct fpga_manager *mgr,
+ struct fpga_image_info *info)
+{
+ struct ice40_fpga_priv *priv = mgr->priv;
+ struct spi_device *dev = priv->dev;
+ const u8 padding[ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES] = {0};
+
+ /* Check CDONE is asserted */
+ if (!gpiod_get_value(priv->cdone)) {
+ dev_err(&dev->dev,
+ "CDONE was not asserted after firmware transfer\n");
+ return -EIO;
+ }
+
+ /* Send of zero-padding to activate the firmware */
+ return spi_write(dev, padding, sizeof(padding));
+}
+
+static const struct fpga_manager_ops ice40_fpga_ops = {
+ .state = ice40_fpga_ops_state,
+ .write_init = ice40_fpga_ops_write_init,
+ .write = ice40_fpga_ops_write,
+ .write_complete = ice40_fpga_ops_write_complete,
+};
+
+static int ice40_fpga_probe(struct spi_device *spi)
+{
+ struct device *dev = &spi->dev;
+ struct device_node *np = spi->dev.of_node;
+ struct ice40_fpga_priv *priv;
+ int ret;
+
+ if (!np) {
+ dev_err(dev, "No Device Tree entry\n");
+ return -EINVAL;
+ }
+
+ priv = devm_kzalloc(&spi->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = spi;
+
+ /* Check board setup data. */
+ if (spi->max_speed_hz > 25000000) {
+ dev_err(dev, "Speed is too high\n");
+ return -EINVAL;
+ }
+
+ if (spi->max_speed_hz < 1000000) {
+ dev_err(dev, "Speed is too low\n");
+ return -EINVAL;
+ }
+
+ if (spi->mode & SPI_CPHA) {
+ dev_err(dev, "Bad mode\n");
+ return -EINVAL;
+ }
+
+ /* Set up the GPIOs */
+ priv->cdone = devm_gpiod_get(dev, "cdone", GPIOD_IN);
+ if (IS_ERR(priv->cdone)) {
+ dev_err(dev, "Failed to get CDONE GPIO: %ld\n",
+ PTR_ERR(priv->cdone));
+ return -EINVAL;
+ }
+
+ priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(priv->reset)) {
+ dev_err(dev, "Failed to get CRESET_B GPIO: %ld\n",
+ PTR_ERR(priv->reset));
+ return -EINVAL;
+ }
+
+ /* Register with the FPGA manager */
+ ret = fpga_mgr_register(dev, "Lattice iCE40 FPGA Manager",
+ &ice40_fpga_ops, priv);
+ if (ret) {
+ dev_err(dev, "Unable to register FPGA manager");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ice40_fpga_remove(struct spi_device *spi)
+{
+ fpga_mgr_unregister(&spi->dev);
+ return 0;
+}
+
+static const struct of_device_id ice40_fpga_of_match[] = {
+ { .compatible = "lattice,ice40-fpga-mgr", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ice40_fpga_of_match);
+
+static struct spi_driver ice40_fpga_driver = {
+ .probe = ice40_fpga_probe,
+ .remove = ice40_fpga_remove,
+ .driver = {
+ .name = "ice40spi",
+ .of_match_table = of_match_ptr(ice40_fpga_of_match),
+ },
+};
+
+module_spi_driver(ice40_fpga_driver);
+
+MODULE_AUTHOR("Joel Holdsworth <joel@airwebreathe.org.uk>");
+MODULE_DESCRIPTION("Lattice iCE40 FPGA Manager");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH v9 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager
From: Joel Holdsworth @ 2016-12-09 5:35 UTC (permalink / raw)
To: atull, moritz.fischer, robh, devicetree, linux-kernel, linux-spi,
marex
Cc: Joel Holdsworth
In-Reply-To: <1481261749-15301-1-git-send-email-joel@airwebreathe.org.uk>
This adds documentation of the device tree bindings of the Lattice iCE40
FPGA driver for the FPGA manager framework.
Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Alan Tull <atull@opensource.altera.com>
Acked-by: Moritz Fischer <moritz.fischer@ettus.com>
Acked-by: Marek Vasut <marex@denx.de>
---
.../bindings/fpga/lattice-ice40-fpga-mgr.txt | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
new file mode 100644
index 0000000..7e7a78b
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
@@ -0,0 +1,21 @@
+Lattice iCE40 FPGA Manager
+
+Required properties:
+- compatible: Should contain "lattice,ice40-fpga-mgr"
+- reg: SPI chip select
+- spi-max-frequency: Maximum SPI frequency (>=1000000, <=25000000)
+- cdone-gpios: GPIO input connected to CDONE pin
+- reset-gpios: Active-low GPIO output connected to CRESET_B pin. Note
+ that unless the GPIO is held low during startup, the
+ FPGA will enter Master SPI mode and drive SCK with a
+ clock signal potentially jamming other devices on the
+ bus until the firmware is loaded.
+
+Example:
+ ice40: ice40@0 {
+ compatible = "lattice,ice40-fpga-mgr";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ cdone-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v9 1/3] of: Add vendor prefix for Lattice Semiconductor
From: Joel Holdsworth @ 2016-12-09 5:35 UTC (permalink / raw)
To: atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w,
robh-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA, marex-ynQEQJNshbs
Cc: Joel Holdsworth
Lattice Semiconductor Corporation is a manufacturer of integrated
circuits and IP products, including low-power FPGAs, video connectivity
devices and millimeter wave wireless products.
Website: http://latticesemi.com
Signed-off-by: Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Acked-by: Alan Tull <atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
Acked-by: Moritz Fischer <moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org>
---
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 64fdc8c..7a87932 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -158,6 +158,7 @@ kosagi Sutajio Ko-Usagi PTE Ltd.
kyo Kyocera Corporation
lacie LaCie
lantiq Lantiq Semiconductor
+lattice Lattice Semiconductor
lenovo Lenovo Group Ltd.
lg LG Corporation
linux Linux-specific binding
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 16/16] drivers/fsi: Add GPIO based FSI master
From: Jeremy Kerr @ 2016-12-09 4:12 UTC (permalink / raw)
To: Chris Bostic, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
sre-DgEjT+Ai2ygdnm+yROfE0A, mturquette-rdvid1DuHRBWk0Htik3J/w,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Chris Bostic, joel-U3u1mxZcP9KHXe+LvDLADg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, andrew-zrmu5oMJ5Fs,
alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r
In-Reply-To: <1481069677-53660-17-git-send-email-christopher.lee.bostic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Chris,
> +static ssize_t store_scan(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t count)
> +{
> + struct fsi_master_gpio *master = dev_get_drvdata(dev);
> +
> + fsi_master_gpio_init(master);
> +
> + /* clear out any old scan data if present */
> + fsi_master_unregister(&master->master);
> + fsi_master_register(&master->master);
> +
> + return count;
> +}
> +
> +static DEVICE_ATTR(scan, 0200, NULL, store_scan);
I think it would make more sense to have the scan attribute populated by
the fsi core; we want this on all masters, not just GPIO.
Currently, the only GPIO-master-specific functionality here is the
fsi_master_gpio_init() - but isn't this something that we can do at
probe time instead?
> +static int fsi_master_gpio_probe(struct platform_device *pdev)
> +{
> + struct fsi_master_gpio *master;
> + struct gpio_desc *gpio;
> +
> + master = devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL);
> + if (!master)
> + return -ENOMEM;
We should be populating master->dev.parent, see
https://github.com/jk-ozlabs/linux/commit/5225d6c47
> + /* Optional pins */
> +
> + gpio = devm_gpiod_get(&pdev->dev, "trans", 0);
> + if (IS_ERR(gpio))
> + dev_dbg(&pdev->dev, "probe: failed to get trans pin\n");
> + else
> + master->gpio_trans = gpio;
I found devm_gpiod_get_optional(), which might make this a little
neater.
Cheers,
Jeremy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] mtd/spi-nor: Add SPI memory controllers for Aspeed SoCs
From: Marek Vasut @ 2016-12-09 2:29 UTC (permalink / raw)
To: Cédric Le Goater, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, Cyrille Pitchen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Joel Stanley
In-Reply-To: <cd9a46ac-049f-e6b8-586c-d386f6012a51-Bxea+6Xhats@public.gmane.org>
On 12/08/2016 05:36 PM, Cédric Le Goater wrote:
> Hello Marek,
Hi!
[...]
>>> @@ -0,0 +1,72 @@
>>> +* Aspeed Static Memory controller
>>> +* Aspeed SPI Flash Controller
>>> +
>>> +The Static memory controller in the ast2400 supports 5 chip selects
>>> +each can be attached to NAND, parallel NOR, or SPI NOR attached flash.
>>
>> So this controller is supported by this driver, which behaves like a SPI
>> controller driver, yet the block can also do NAND and parallel NOR ?
>
> I think that was answered in a previous email.
Yep, thanks!
>>> +The Firmware Memory Controller in the ast2500 supports 3 chip selects,
>>> +two of which are always in SPI-NOR mode and the third can be SPI-NOR
>>> +or parallel flash. The SPI flash controller in the ast2400 supports
>>> +one of 2 chip selects selected by pinmux. The two SPI flash
>>> +controllers in the ast2500 each support two chip selects.
>>
>> This paragraph is confusing, it's hard to grok down how many different
>> controllers does this driver support and what are their properties from
>> it. It is all there, it's just hard to read.
>
> I will start with the AST2500 controllers only, which are consistent.
That works too :-)
[...]
>>> + tristate "Aspeed flash controllers in SPI mode"
>>> + depends on HAS_IOMEM && OF
>>> + depends on ARCH_ASPEED || COMPILE_TEST
>>> + # IO_SPACE_LIMIT must be equivalent to (~0UL)
>>> + depends on !NEED_MACH_IO_H
>>
>> Why?
>
> Some left over from the patch we have been keeping for too long (+1year)
> in our tree.
Hehe, I see, so it's fixed now.
>>> + help
>>> + This enables support for the New Static Memory Controller
>>> + (FMC) in the Aspeed SoCs (AST2400 and AST2500) when attached
>>> + to SPI nor chips, and support for the SPI Memory controller
>>> + (SPI) for the BIOS.
>>
>> I think there is a naming chaos between FMC, SMC (as in Static MC) and
>> SMC (as in SPI MC).
>
> I agree, I will try to clarify the naming in the next version. I will keep
> the smc suffix for the driver name though.
Thanks!
[...]
>>> +static void aspeed_smc_chip_set_4b_smc_2400(struct aspeed_smc_chip *chip);
>>> +static void aspeed_smc_chip_set_4b(struct aspeed_smc_chip *chip);
>>> +
>>> +static const struct aspeed_smc_info fmc_2400_info = {
>>> + .maxsize = 64 * 1024 * 1024,
>>> + .nce = 5,
>>> + .maxwidth = 4,
>>> + .hastype = true,
>>
>> Shouldn't all this be specified in DT ?
>
> I am not sure, these values are not configurable. I will remove a few
> of them in the next version as they are unused.
Sooo, I had a discussion with Boris (which we didn't finish yet).
Please ignore my comment for now and yes please, drop unused params.
>>> + .we0 = 16,
>>> + .ctl0 = 0x10,
>>> + .time = 0x94,
>>> + .misc = 0x54,
>>> + .set_4b = aspeed_smc_chip_set_4b,
>>> +};
[...]
>>> +static u32 spi_control_fill_opcode(u8 opcode)
>>> +{
>>> + return ((u32)(opcode)) << CONTROL_SPI_COMMAND_SHIFT;
>>
>> return opcode << CONTROL... , fix these horrible casts and parenthesis
>> globally.
>
> I killed the helper.
Nice, thanks for all the cleanups :)
>>> +}
>>> +
>>> +static inline u32 aspeed_smc_chip_write_bit(struct aspeed_smc_chip *chip)
>>> +{
>>> + return ((u32)1 << (chip->controller->info->we0 + chip->cs));
>>
>> return BIT(...)
>>
>> I'm not sure these microfunctions are even needed.
>
> well, this one is used in a couple of places.
Ah all right, then just return BIT(...) and be done with it.
>>> +}
[...]
>>> +static int aspeed_smc_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
>>> +{
>>> + struct aspeed_smc_chip *chip = nor->priv;
>>> +
>>> + mutex_lock(&chip->controller->mutex);
>>
>> Won't this have a horrid overhead ?
>
> Shall I use the prepare() and unprepare() ops instead ?
I think that'd trim down the amount of locking, yes.
>>> + aspeed_smc_start_user(nor);
>>> + aspeed_smc_write_to_ahb(chip->base, &opcode, 1);
>>> + aspeed_smc_read_from_ahb(buf, chip->base, len);
>>> + aspeed_smc_stop_user(nor);
>>> +
>>> + mutex_unlock(&chip->controller->mutex);
>>> +
>>> + return 0;
>>> +}
[...]
>>> +static int aspeed_smc_chip_setup_init(struct aspeed_smc_chip *chip,
>>> + struct resource *r)
>>> +{
>>> + struct aspeed_smc_controller *controller = chip->controller;
>>> + const struct aspeed_smc_info *info = controller->info;
>>> + u32 reg, base_reg;
>>> +
>>> + /*
>>> + * Always turn on the write enable bit to allow opcodes to be
>>> + * sent in user mode.
>>> + */
>>> + aspeed_smc_chip_enable_write(chip);
>>> +
>>> + /* The driver only supports SPI type flash for the moment */
>>> + if (info->hastype)
>>> + aspeed_smc_chip_set_type(chip, smc_type_spi);
>>> +
>>> + /*
>>> + * Configure chip base address in memory
>>> + */
>>> + chip->base = window_start(controller, r, chip->cs);
>>> + if (!chip->base) {
>>> + dev_warn(chip->nor.dev, "CE segment window closed.\n");
>>> + return -1;
>>> + }
>>> +
>>> + /*
>>> + * Read the existing control register to get basic values.
>>> + *
>>> + * XXX This register probably needs more sanitation.
>>
>> What's this comment about ?
>
> This is an initial comment about settings being done by U-Boot
> before the kernel is loaded, and some optimisations should be
> nice to keep, for the FMC controller. I will rephrase.
Shouldn't that be passed via DT instead ? We want to be bootloader
agnostic in Linux.
btw off-topic, but is U-Boot support for these aspeed devices ever be
upstreamed ?
>>> + * Do we need support for mode 3 vs mode 0 clock phasing?
>>> + */
>>> + reg = readl(chip->ctl);
>>> + dev_dbg(controller->dev, "control register: %08x\n", reg);
>>> +
>>> + base_reg = reg & CONTROL_SPI_KEEP_MASK;
>>> + if (base_reg != reg) {
>>> + dev_info(controller->dev,
>>> + "control register changed to: %08x\n",
>>> + base_reg);
>>> + }
[...]
>>> + err = mtd_device_register(&chip->nor.mtd, NULL, 0);
>>> + if (err)
>>> + continue;
>>
>> What happens if some chip fails to register ?
>
> That's not correctly handled ... I have a fix for it.
>
> Thanks,
Thanks for all the work :)
--
Best regards,
Marek Vasut
--
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] dt-bindings: Document the hi3660 reset bindings
From: Zhangfei Gao @ 2016-12-09 2:11 UTC (permalink / raw)
To: Rob Herring, Philipp Zabel, Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Zhangfei Gao
In-Reply-To: <1480989092-31847-2-git-send-email-zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Add DT bindings documentation for hi3660 SoC reset controller.
Signed-off-by: Zhangfei Gao <zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
.../bindings/reset/hisilicon,hi3660-reset.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
new file mode 100644
index 0000000..2bf3344
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
@@ -0,0 +1,43 @@
+Hisilicon System Reset Controller
+======================================
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+The reset controller registers are part of the system-ctl block on
+hi3660 SoC.
+
+Required properties:
+- compatible: should be
+ "hisilicon,hi3660-reset"
+- hisi,rst-syscon: phandle of the reset's syscon.
+- #reset-cells : Specifies the number of cells needed to encode a
+ reset source. The type shall be a <u32> and the value shall be 2.
+
+ Cell #1 : offset of the reset assert control
+ register from the syscon register base
+ offset + 4: deassert control register
+ offset + 8: status control register
+ Cell #2 : bit position of the reset in the reset control register
+
+Example:
+ iomcu: iomcu@ffd7e000 {
+ compatible = "hisilicon,hi3660-iomcu", "syscon";
+ reg = <0x0 0xffd7e000 0x0 0x1000>;
+ };
+
+ iomcu_rst: iomcu_rst_controller {
+ compatible = "hisilicon,hi3660-reset";
+ hisi,rst-syscon = <&iomcu>;
+ #reset-cells = <2>;
+ };
+
+Specifying reset lines connected to IP modules
+==============================================
+example:
+
+ i2c0: i2c@..... {
+ ...
+ resets = <&iomcu_rst 0x20 3>; /* offset: 0x20; bit: 3 */
+ ...
+ };
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v3 1/2] dt-bindings: Document the hi3660 reset bindings
From: zhangfei @ 2016-12-09 2:00 UTC (permalink / raw)
To: Philipp Zabel
Cc: Rob Herring, Arnd Bergmann, haojian.zhuang-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481031753.3202.57.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 2016年12月06日 21:42, Philipp Zabel wrote:
> Am Dienstag, den 06.12.2016, 09:51 +0800 schrieb Zhangfei Gao:
>> Add DT bindings documentation for hi3660 SoC reset controller.
>>
>> Signed-off-by: Zhangfei Gao <zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>> .../bindings/reset/hisilicon,hi3660-reset.txt | 36 ++++++++++++++++++++++
>> 1 file changed, 36 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>>
>> diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>> new file mode 100644
>> index 0000000..178e478
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>> @@ -0,0 +1,36 @@
>> +Hisilicon System Reset Controller
>> +======================================
>> +
>> +Please also refer to reset.txt in this directory for common reset
>> +controller binding usage.
>> +
>> +The reset controller registers are part of the system-ctl block on
>> +hi3660 SoC.
>> +
>> +Required properties:
>> +- compatible: should be
>> + "hisilicon,hi3660-reset"
>> +- #reset-cells: 2, see below
>> +- hisi,rst-syscon: phandle of the reset's syscon.
>> +
>> +Example:
>> + iomcu: iomcu@ffd7e000 {
>> + compatible = "hisilicon,hi3660-iomcu", "syscon";
>> + reg = <0x0 0xffd7e000 0x0 0x1000>;
>> + };
>> +
>> + iomcu_rst: iomcu_rst_controller {
>> + compatible = "hisilicon,hi3660-reset";
>> + hisi,rst-syscon = <&iomcu>;
>> + #reset-cells = <2>;
>> + };
>> +
>> +Specifying reset lines connected to IP modules
>> +==============================================
>> +example:
>> +
>> + i2c0: i2c@..... {
>> + ...
>> + resets = <&iomcu_rst 0x20 3>; /* offset: 0x20; bit: 3 */
> Should this mention somewhere what register the offset is supposed to
> point to? This is the address offset to the set register, with the
> corresponding clear register being placed at offset + 4.
How about this description.
-- #reset-cells: 2, see below
- hisi,rst-syscon: phandle of the reset's syscon.
+- #reset-cells : Specifies the number of cells needed to encode a
+ reset source. The type shall be a <u32> and the value shall be 2.
+
+ Cell #1 : offset of the reset assert control
+ register from the syscon register base
+ offset + 4: deassert control register
+ offset + 8: status control register
+ Cell #2 : bit position of the reset in the reset control register
May paste in this thread for a clear view.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] eeprom: Add IDT 89HPESx driver bindings file
From: Serge Semin @ 2016-12-09 1:57 UTC (permalink / raw)
To: Rob Herring
Cc: Greg Kroah-Hartman, Srinivas Kandagatla, Andrew Lunn,
Mark Rutland, Sergey.Semin-vHJ8rsvMqnUPfZBKTuL5GA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161205190456.GA25116@mobilestation>
Rob,
Could you please respond on these comments? I've got some free time, so I wanna
rewrite the code until I've not got busy again.
Regards,
-Sergey
On Mon, Dec 05, 2016 at 10:04:56PM +0300, Serge Semin <fancer.lancer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Dec 05, 2016 at 11:27:07AM -0600, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > On Mon, Dec 5, 2016 at 9:25 AM, Serge Semin <fancer.lancer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > On Mon, Dec 05, 2016 at 08:46:21AM -0600, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > >> On Tue, Nov 29, 2016 at 01:38:21AM +0300, Serge Semin wrote:
> > >> > See cover-letter for changelog
> > >> >
> > >> > Signed-off-by: Serge Semin <fancer.lancer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > >> >
> > >> > ---
> > >> > .../devicetree/bindings/misc/idt_89hpesx.txt | 41 ++++++++++++++++++++++
> > >>
> > >> There's not a better location for this? I can't tell because you don't
> > >> describe what the device is.
> > >>
> > >
> > > The device is PCIe-switch EEPROM driver with additional debug-interface to
> > > access the switch CSRs. EEPROM is accesses via a separate i2c-slave
> > > interface of the switch.
> > >
> > > There might be another place to put the binding file in. There is a special
> > > location for EEPROM drivers bindings - Documentation/devicetree/bindings/eeprom/ .
> > > But as far as I understood from the files put in there, it's intended for
> > > pure EEPROM drivers only. On the other hand the directory I've chosen:
> > > Documentation/devicetree/bindings/misc/
> > > mostly intended for some unusual devices. My device isn't usual, since it
> > > has CSRs debug-interface as well. Additionally I've found
> > > eeprom-93xx46.txt binding file there, which describes EEPROM bindings.
> > >
> > > Anyway if you find the file should be placed in
> > > Documentation/devicetree/bindings/eeprom/ instead, I'll move it, it's not
> > > that a big problem.
> > >
>
> What about this comment? Shall the file be left at the path I placed it?
>
> > >> > 1 file changed, 41 insertions(+)
> > >> > create mode 100644 Documentation/devicetree/bindings/misc/idt_89hpesx.txt
> > >> >
> > >> > diff --git a/Documentation/devicetree/bindings/misc/idt_89hpesx.txt b/Documentation/devicetree/bindings/misc/idt_89hpesx.txt
> > >> > index 0000000..469cc93
> > >> > --- /dev/null
> > >> > +++ b/Documentation/devicetree/bindings/misc/idt_89hpesx.txt
> > >> > @@ -0,0 +1,41 @@
> > >> > +EEPROM / CSR SMBus-slave interface of IDT 89HPESx devices
> > >> > +
> > >> > +Required properties:
> > >> > + - compatible : should be "<manufacturer>,<type>"
> > >> > + Basically there is only one manufacturer: idt, but some
> > >> > + compatible devices may be produced in future. Following devices
> > >> > + are supported: 89hpes8nt2, 89hpes12nt3, 89hpes24nt6ag2,
> > >> > + 89hpes32nt8ag2, 89hpes32nt8bg2, 89hpes12nt12g2, 89hpes16nt16g2,
> > >> > + 89hpes24nt24g2, 89hpes32nt24ag2, 89hpes32nt24bg2;
> > >> > + 89hpes12n3, 89hpes12n3a, 89hpes24n3, 89hpes24n3a;
> > >> > + 89hpes32h8, 89hpes32h8g2, 89hpes48h12, 89hpes48h12g2,
> > >> > + 89hpes48h12ag2, 89hpes16h16, 89hpes22h16, 89hpes22h16g2,
> > >> > + 89hpes34h16, 89hpes34h16g2, 89hpes64h16, 89hpes64h16g2,
> > >> > + 89hpes64h16ag2;
> > >> > + 89hpes12t3g2, 89hpes24t3g2, 89hpes16t4, 89hpes4t4g2,
> > >> > + 89hpes10t4g2, 89hpes16t4g2, 89hpes16t4ag2, 89hpes5t5,
> > >> > + 89hpes6t5, 89hpes8t5, 89hpes8t5a, 89hpes24t6, 89hpes6t6g2,
> > >> > + 89hpes24t6g2, 89hpes16t7, 89hpes32t8, 89hpes32t8g2,
> > >> > + 89hpes48t12, 89hpes48t12g2.
> > >> > + Current implementation of the driver doesn't have any device-
> > >>
> > >> Driver capabilties are irrelevant to bindings.
> > >>
> > >
> > > Why? I've told in the comment, that the devices actually differ by the CSRs
> > > map. Even though it's not reflected in the code at the moment, the CSRs
> > > read/write restrictions can be added by some concerned programmer in
> > > future. But If I left something like "compatible : idt,89hpesx" device
> > > only, it will be problematic to add that functionality.
> >
> > Bindings describe the h/w, not what the Linux, FreeBSD, etc. driver
> > does. You don't want to be changing the binding doc when the driver
> > changes.
> >
> > > Howbeit If you think it's not necessary and "compatible = idt,89hpesx" is
> > > ok, it's perfectly fine for me to make it this way. The property will be
> > > even simpler, than current approach.
> >
> > NO! That's not at all what I'm suggesting. Specific compatible strings
> > are the right way to go for the reasons you give. You just don't need
> > to state why here (because it is true for all bindings).
> >
>
> Oh, I just misunderstood what you said. I'll discard the comment.
>
> > >> > + specific functionalities. But since each of them differs
> > >> > + by registers mapping, CSRs read/write restrictions can be
> > >> > + added in future.
> > >> > + - reg : I2C address of the IDT 89HPES device.
> > >> > +
> > >> > +Optional properties:
> > >> > + - read-only : Parameterless property disables writes to the EEPROM
> > >> > + - idt,eesize : Size of EEPROM device connected to IDT 89HPES i2c-master bus
> > >> > + (default value is 4096 bytes if option isn't specified)
> > >> > + - idt,eeaddr : Custom address of EEPROM device
> > >> > + (If not specified IDT 89HPESx device will try to communicate
> > >> > + with EEPROM sited by default address - 0x50)
> > >>
> > >> Don't we already have standard EEPROM properties that could be used
> > >> here?
> > >>
> > >
> > > If we do, just tell me which one. There are standard options:
> >
> > You can grep thru bindings as easily as I can. I can't do that for
> > everyone's binding.
> >
>
> It won't be necessary due to the next comment.
>
> > > "compatible, reg, pagesize, read-only". There isn't any connected with
> > > EEPROM actual size.
> > > Why so? Because standard EEPROM-drivers determine the device size from the
> > > compatible-string name. Such approach won't work in this case, because
> > > PCIe-switch and it EEPROM are actually two different devices. Look at the
> > > chain of the usual platform board design:
> > > Host <--- i2c ----> i2c-slave iface |PCIe-switch| i2c-master iface <--- i2c ---> EEPROM
> > >
> > > As you cas see the Host reaches EEPROM through the set of PCIe-switch
> > > i2c-interfaces. In order to properly get data from it my driver needs actual
> > > EEPROM size and it address in the i2c-master bus of the PCIe-switch, in
> > > addition to the standard reg-field, which is address of PCIe-switch i2c-slave
> > > interface and read-only parameter if EEPROM-device has got WP pin asserted.
> >
> > Ah, this needs to be much different than I thought. You need to model
> > (i.e. use the same binding) the EEPROM node just like it was directly
> > attached to the host. So this means you need the 2nd i2c bus modeled
> > which means you need the PCIe switch modeled. A rough outline of the
> > nodes would look like this:
> >
> > host-i2c: i2c {
> > compatible ="host-i2c"
> > };
> >
> > pcie {
> > pcie-switch {
> > i2c-bus = <&host-i2c>;
> > i2c-bus {
> > eeprom@50 {
> > };
> > };
> > };
> > };
> >
> > So this models the PCIe switch as a PCIe device, it has a phandle back
> > to it's controller since it's not a child of the i2c controller. Then
> > the devices on switches i2c bus are modeled as children of the switch.
> >
> > Alternatively, it could be described all as children of host-i2c node.
> > It's common for i2c devices to have downstream i2c buses. I2C muxes
> > are one example and there are bindings defined for all this. There's
> > also chips like mpu-6050 that have slave buses.
> >
> > Rob
>
> I think I understand what you says. However let me just bring some details
> to make things clear.
>
> First of all the driver doesn't do any PCI-Express-related work. The device
> !IDT PCI Express switch! just has two additional i2c interfaces: i2c-slave
> and i2c-master. As it is obvious from the bus-names i2c-slave is the interface,
> where IDT PCIe-switch device is actually slave. This interface can be reached
> from the host by ordinary i2c buses. i2c-master interface is connected to an
> i2c-bus, where IDT PCIe-switch is single master. This bus can have just one
> EEPROM device to store some initialization data. Host can send some specific
> smbus-packets to i2c-slave interface of IDT PCIe-switch in order to
> preinitialize EEPROM data, connected to i2c-master interface of the device.
>
> Additionally IDT PCIe-switch handles some special smbus packets coming to it
> i2c-slave interface to read/write its internal CSR. This interface can be
> used to debug the device, when there are problems with it usual PCI Express
> related functioning.
>
> So to speak, it wouldn't be good to have PCIe-switch declared in dts as a
> PCI-device, since PCI-bus is actually dynamically populated by PCI-core
> subsystem.
>
> According to what you said and the device/driver design I described, the
> following bindings can be suggested:
>
> i2c0: i2c@FFFF0000 {
> compatible = "vendor,i2c-adapter";
> #address-cells = <1>;
> #size-cells = <0>;
>
> idt_i2c_iface: idt@60 {
> compatible = "idt,89hpes32nt8ag2";
> reg = <0x60>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> eeprom@51 {
> compatible = "at,24c64";
> reg = <0x51>;
> read-only;
> };
> };
> };
>
> Suppose there is some host-i2c adapter like "vendor,i2c-adapter" and
> i2c-slave interface of IDT PCIe-switch is connected to it. In this way
> i2c-slave interface will be visible like ordinary i2c-device with just
> one subnode. This subnode explains the actual EEPROM connected to
> IDT PCIe-switch i2c-master interface.
>
> Does it look acceptable? It seems like your last suggestion. Is it?
>
> Thanks,
> -Sergey
>
--
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] ARM: dts: sun8i: Support DTB build for NanoPi M1
From: Milo Kim @ 2016-12-09 1:47 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Milo Kim
The commit 10efbf5f1633 introduced NanoPi M1 board but it's missing in
Allwinner H3 DTB build.
Signed-off-by: Milo Kim <woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cccdbcb..4cbdf6f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -845,6 +845,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
+ sun8i-h3-nanopi-m1.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-orangepi-2.dtb \
sun8i-h3-orangepi-lite.dtb \
--
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 v3 3/3] ARM: dts: imx6: Support Savageboard quad
From: Milo Kim @ 2016-12-09 1:04 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer
Cc: Fabio Estevam, linux-arm-kernel, devicetree, linux-kernel,
Milo Kim
In-Reply-To: <20161209010436.7994-1-woogyom.kim@gmail.com>
Use common board file and support SATA interface additionally.
Specify this dtb file for i.MX6 build.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-savageboard.dts | 54 +++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-savageboard.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 64660c7..25b1e19 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -392,6 +392,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-sabreauto.dtb \
imx6q-sabrelite.dtb \
imx6q-sabresd.dtb \
+ imx6q-savageboard.dtb \
imx6q-sbc6x.dtb \
imx6q-tbs2910.dtb \
imx6q-ts4900.dtb \
diff --git a/arch/arm/boot/dts/imx6q-savageboard.dts b/arch/arm/boot/dts/imx6q-savageboard.dts
new file mode 100644
index 0000000..8d74002
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-savageboard.dts
@@ -0,0 +1,54 @@
+/*
+ * Copyright (C) 2016 Milo Kim <woogyom.kim@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-savageboard.dtsi"
+
+/ {
+ model = "Poslab SavageBoard Quad";
+ compatible = "poslab,imx6q-savageboard", "fsl,imx6q";
+};
+
+&sata {
+ status = "okay";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v3 2/3] ARM: dts: imx6: Support Savageboard dual
From: Milo Kim @ 2016-12-09 1:04 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer
Cc: Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Milo Kim
In-Reply-To: <20161209010436.7994-1-woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Common savageboard DT file is used for board support.
Specify this dtb file for i.MX6Q build.
Signed-off-by: Milo Kim <woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-savageboard.dts | 50 ++++++++++++++++++++++++++++++++
2 files changed, 51 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-savageboard.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c558ba7..64660c7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -348,6 +348,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-sabreauto.dtb \
imx6dl-sabrelite.dtb \
imx6dl-sabresd.dtb \
+ imx6dl-savageboard.dtb \
imx6dl-ts4900.dtb \
imx6dl-tx6dl-comtft.dtb \
imx6dl-tx6s-8034.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-savageboard.dts b/arch/arm/boot/dts/imx6dl-savageboard.dts
new file mode 100644
index 0000000..2cac30d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-savageboard.dts
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2016 Milo Kim <woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-savageboard.dtsi"
+
+/ {
+ model = "Poslab SavageBoard Dual";
+ compatible = "poslab,imx6dl-savageboard", "fsl,imx6dl";
+};
--
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
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