* 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
* 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: [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: [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 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 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 v3 -next 2/2] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-12-09 8:17 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Rob Herring, Russell King, Andre Przywara,
Hans de Goede, Arnd Bergmann, Vishnu Patekar,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161202150513.34691-2-icenowy-ymACFijhrKM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
On Fri, Dec 02, 2016 at 11:05:13PM +0800, Icenowy Zheng wrote:
> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC and a
> SDIO Wi-Fi chip by Allwinner (XR819).
>
> Add a device tree file for it.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] misc: eeprom: implement compatible DT probing
From: Wolfram Sang @ 2016-12-09 8:18 UTC (permalink / raw)
To: Peter Rosin
Cc: Linus Walleij, Wolfram Sang,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <806f55f3-3fed-572d-4859-7c7dc76c5e08-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 736 bytes --]
> Many on the patterns at,24c256 and at24,24c256 (should be probably
> be atmel,24c256)
I remember patches fixing that. Since I usually don't take DTS patches,
I can't recall what happened to them. It might well be that those were
accepted and meanwhile new bad bindings got in.
> 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?
I'd simply assume it was never tested. EEPROMs are often convenience
storage and not essential for a working board. Also, for historic
reasons, they are often used via the i2c-dev interface directly, so a
wrong binding with the kernel driver might simply go unnoticed.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/6] net: ethernet: ti: cpts: add support of cpts HW_TS_PUSH
From: Richard Cochran @ 2016-12-09 8:50 UTC (permalink / raw)
To: Grygorii Strashko
Cc: David S. Miller, netdev, Mugunthan V N, Sekhar Nori, linux-kernel,
linux-omap, Rob Herring, devicetree, Murali Karicheri,
Wingman Kwok
In-Reply-To: <58eea45f-b8fe-6892-e784-b41638c62fd8@ti.com>
On Thu, Dec 08, 2016 at 01:04:11PM -0600, Grygorii Strashko wrote:
> huh. Seems this is not really good idea, because MISC Irq will be
> triggered for *any* CPTS event and there is no way to enable it just for
> HW_TS_PUSH.
So what? That is not a problem.
> So, this doesn't work will with current code for RX/TX timestamping
> (which uses polling mode).
Why doesn't it work?
> + runtime overhead in net RX/TX caused by
> triggering more interrupts.
This is not relevant. Without HW_TS_PUSH, there is no need for
enabling the interrupt simply because we don't need it. Now, with
HW_TS_PUSH, we do need it.
> May be, overflow check/polling timeout can be made configurable (module parameter).
No, it should just work without any user space fiddling.
I getting a bit tired of your half-baked implementations of the
ancillary clock functions. Either do it right, or just leave it
unsupported.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH v5 1/7] MFD: add bindings for STM32 General Purpose Timer driver
From: Lee Jones @ 2016-12-09 8:53 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: robh+dt, mark.rutland, alexandre.torgue, devicetree, linux-kernel,
thierry.reding, linux-pwm, jic23, knaack.h, lars, pmeerw,
linux-iio, linux-arm-kernel, fabrice.gasnier, gerald.baeza,
arnaud.pouliquen, linus.walleij, linaro-kernel, Benjamin Gaignard
In-Reply-To: <1481199650-22484-2-git-send-email-benjamin.gaignard@st.com>
Sorry to do this Ben. Not much to do now though!
> 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 | 39 ++++++++++++++++++++++
> 1 file changed, 39 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..ce67755
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
> @@ -0,0 +1,39 @@
> +STM32 General Purpose Timer driver bindings
This is a great place to describe what we're *actually* trying to
achieve with this driver, and the worst place to use the term "general
purpose", since this IP is so much more than that.
"STM32 Timers
This IP provides 3 types of timer along with PWM functionality.
[...]"
... then go on to explain what the 3 types are and how they can be
used.
> +Required parameters:
> +- compatible: must be "st,stm32-gptimer"
I vehemently disagree that this entire IP is a GP Timer. It contains
GP timers, sure, but it also contains Advanced and Basic timers.
IMHO this compatible should be "st,stm32-timers".
And the file name of both this and the *.c file should reflect that
too.
Remainder looks nice.
> +- 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:
> + timers@40010000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-gptimer";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm@0 {
Out of interest, do you use the "@0", "@1" for anything now?
> + compatible = "st,stm32-pwm";
> + pinctrl-0 = <&pwm1_pins>;
> + pinctrl-names = "default";
> + };
> +
> + timer@0 {
> + compatible = "st,stm32-timer-trigger";
> + reg = <0>;
> + };
> + };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v13 0/7] dtc: Dynamic DT support
From: David Gibson @ 2016-12-09 8:54 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: <3C4DD870-3736-42A7-A110-0975C31E74A4-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]
On Fri, Dec 09, 2016 at 10:16:51AM +0200, Pantelis Antoniou wrote:
> 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.
Ok. Note that one of the patches I merged afterwards was a big rename
of struct boot_info, so your patches will probably need a fair bit of
fiddly though straightforward rebasing.
--
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 v4 6/7] IIO: add STM32 timer trigger driver
From: Lee Jones @ 2016-12-09 8:59 UTC (permalink / raw)
To: Daniel Thompson
Cc: Benjamin Gaignard, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Mark Rutland,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List, Thierry Reding,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, Jonathan Cameron,
knaack.h-Mmb7MZpHnFY, Lars-Peter Clausen, Peter Meerwald-Stadler,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Fabrice Gasnier, Gerald Baeza, Arnaud Pouliquen, Linus Walleij,
Linaro Kernel Mailman List, Benjamin Gaignard
In-Reply-To: <5dcec09c-8b4b-4cc2-ce3f-fde86366ec05-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Wed, 07 Dec 2016, Daniel Thompson wrote:
> On 07/12/16 11:00, Benjamin Gaignard wrote:
> > 2016-12-07 11:50 GMT+01:00 Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
> > > On Tue, 06 Dec 2016, Benjamin Gaignard wrote:
> > >
> > > > [snip]
> > > > > > +
> > > > > > +static const char * const triggers0[] = {
> > > > > > + TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers1[] = {
> > > > > > + TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers2[] = {
> > > > > > + TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers3[] = {
> > > > > > + TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers4[] = {
> > > > > > + TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers5[] = {
> > > > > > + TIM6_TRGO, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers6[] = {
> > > > > > + TIM7_TRGO, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers7[] = {
> > > > > > + TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers8[] = {
> > > > > > + TIM9_TRGO, TIM9_CH1, TIM9_CH2, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers9[] = {
> > > > > > + TIM12_TRGO, TIM12_CH1, TIM12_CH2, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const void *triggers_table[] = {
> > > > > > + triggers0,
> > > > > > + triggers1,
> > > > > > + triggers2,
> > > > > > + triggers3,
> > > > > > + triggers4,
> > > > > > + triggers5,
> > > > > > + triggers6,
> > > > > > + triggers7,
> > > > > > + triggers8,
> > > > > > + triggers9,
> > > > > > +};
> > > > >
> > > > > What about:
> > > > >
> > > > > static const char * const triggers[][] = {
> > > > > { TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4, NULL },
> > > > > { TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4, NULL },
> > > > > { TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4, NULL },
> > > > > { TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4, NULL },
> > > > > { TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4, NULL },
> > > > > { TIM6_TRGO, NULL },
> > > > > { TIM7_TRGO, NULL },
> > > > > { TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4, NULL },
> > > > > { TIM9_TRGO, TIM9_CH1, TIM9_CH2, NULL },
> > > > > { TIM12_TRGO, TIM12_CH1, TIM12_CH2, NULL }
> > > > > };
> > > >
> > > > I can't because the second dimension of the array isn't fix.
> > > > I could have between 2 and 6 elements per row... to create a dual dimension
> > > > array I would have to add NULL entries like that:
> > > >
> > > > #define MAX_TRIGGERS 6
> > > >
> > > > static const void *triggers_table[][MAX_TRIGGERS] = {
> > > > { TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4, NULL,},
> > > > { TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4, NULL,},
> > > > { TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4, NULL,},
> > > > { TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4, NULL,},
> > > > { TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4, NULL,},
> > > > { TIM6_TRGO, NULL, NULL, NULL, NULL, NULL,},
> > > > { TIM7_TRGO, NULL, NULL, NULL, NULL, NULL,},
> > > > { TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4, NULL,},
> > > > { TIM9_TRGO, TIM9_CH1, TIM9_CH2, NULL, NULL, NULL,},
> > > > { TIM12_TRGO, TIM12_CH1, TIM12_CH2, NULL, NULL, NULL,},
> > > > };
> > >
> > > It was just an idea, not a tested implementation.
> > >
> > > I don't understand why you have to pad with NULLs, but either way, it
> > > looks much better than before and saves lots of lines of code.
> >
> > I have tested it this morning and it works fine so I will include it in v5.
> > I use NULL as limit when iterate in the table and for table padding too.
>
> If the initializer is shorter than the array then the array will be
> implicitly zero/NULL padded. I don't think there is any need to type out all
> the NULLs (not even at -Wall).
+1. My point precisely.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [RESEND-PATCH] ARM: EXYNOS: remove smp hook from machine descriptor
From: pankaj.dubey @ 2016-12-09 9:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, arnd, kgene,
javier, thomas.ab
In-Reply-To: <20161208173349.GA8522@kozik-lap>
Hi Krzysztof,
On Thursday 08 December 2016 11:03 PM, Krzysztof Kozlowski wrote:
> On Thu, Dec 08, 2016 at 08:32:15AM +0530, Pankaj Dubey wrote:
>> Use CPU_METHOD_OF_DECLARE() for smp_ops instead of using it
>> via machine descriptor.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> ---
>>
>> Resending as I missed to include samsung mailing list.
>>
>> arch/arm/boot/dts/exynos3250.dtsi | 1 +
>> arch/arm/boot/dts/exynos4210.dtsi | 1 +
>> arch/arm/boot/dts/exynos4212.dtsi | 1 +
>> arch/arm/boot/dts/exynos4412.dtsi | 1 +
>> arch/arm/boot/dts/exynos5250.dtsi | 1 +
>> arch/arm/boot/dts/exynos5260.dtsi | 1 +
>> arch/arm/boot/dts/exynos5410.dtsi | 1 +
>> arch/arm/boot/dts/exynos5420-cpus.dtsi | 1 +
>> arch/arm/boot/dts/exynos5422-cpus.dtsi | 1 +
>> arch/arm/boot/dts/exynos5440.dtsi | 1 +
>> arch/arm/mach-exynos/common.h | 2 --
>> arch/arm/mach-exynos/exynos.c | 1 -
>> arch/arm/mach-exynos/platsmp.c | 2 ++
>> 13 files changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
>> index ba17ee1..f28f669 100644
>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>> @@ -53,6 +53,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
>> index 7f3a18c..6dfd98d 100644
>> --- a/arch/arm/boot/dts/exynos4210.dtsi
>> +++ b/arch/arm/boot/dts/exynos4210.dtsi
>> @@ -35,6 +35,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@900 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
>> index 5389011..3e8982e 100644
>> --- a/arch/arm/boot/dts/exynos4212.dtsi
>> +++ b/arch/arm/boot/dts/exynos4212.dtsi
>> @@ -25,6 +25,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@A00 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
>> index 40beede..faf2fb8 100644
>> --- a/arch/arm/boot/dts/exynos4412.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412.dtsi
>> @@ -25,6 +25,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@A00 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
>> index b6d7444..580897c 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -52,6 +52,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi
>> index 5818718..1af6e76 100644
>> --- a/arch/arm/boot/dts/exynos5260.dtsi
>> +++ b/arch/arm/boot/dts/exynos5260.dtsi
>> @@ -32,6 +32,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu@0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
>> index 2b6adaf..b092cdc 100644
>> --- a/arch/arm/boot/dts/exynos5410.dtsi
>> +++ b/arch/arm/boot/dts/exynos5410.dtsi
>> @@ -33,6 +33,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> index 5c052d7..a587704 100644
>> --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> @@ -24,6 +24,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi b/arch/arm/boot/dts/exynos5422-cpus.dtsi
>> index bf3c6f1..7fcdfd0 100644
>> --- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
>> @@ -23,6 +23,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@100 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
>> index 2a2e570..0a958e8 100644
>> --- a/arch/arm/boot/dts/exynos5440.dtsi
>> +++ b/arch/arm/boot/dts/exynos5440.dtsi
>> @@ -50,6 +50,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu@0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
>> index fb12d11..051e1ab 100644
>> --- a/arch/arm/mach-exynos/common.h
>> +++ b/arch/arm/mach-exynos/common.h
>> @@ -143,8 +143,6 @@ static inline void exynos_pm_init(void) {}
>> extern void exynos_cpu_resume(void);
>> extern void exynos_cpu_resume_ns(void);
>>
>> -extern const struct smp_operations exynos_smp_ops;
>> -
>> extern void exynos_cpu_power_down(int cpu);
>> extern void exynos_cpu_power_up(int cpu);
>> extern int exynos_cpu_power_state(int cpu);
>> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
>> index fa08ef9..f0a766e 100644
>> --- a/arch/arm/mach-exynos/exynos.c
>> +++ b/arch/arm/mach-exynos/exynos.c
>> @@ -211,7 +211,6 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
>> /* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
>> .l2c_aux_val = 0x3c400001,
>> .l2c_aux_mask = 0xc20fffff,
>> - .smp = smp_ops(exynos_smp_ops),
>> .map_io = exynos_init_io,
>> .init_early = exynos_firmware_init,
>> .init_irq = exynos_init_irq,
>> diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
>> index 94405c7..43eec10 100644
>> --- a/arch/arm/mach-exynos/platsmp.c
>> +++ b/arch/arm/mach-exynos/platsmp.c
>> @@ -474,3 +474,5 @@ const struct smp_operations exynos_smp_ops __initconst = {
>> .cpu_die = exynos_cpu_die,
>> #endif
>> };
>> +
>> +CPU_METHOD_OF_DECLARE(exynos_smp, "samsung,exynos-smp", &exynos_smp_ops);
>
> Three issues:
> 1. This has to be documented. Checkpatch did not complain about it?
No it didn't.
> 2. I think this breaks the ABI with existing DTBs because now the
> enable-method of cpus becomes mandatory. But the
> Documentation/devicetree/bindings/arm/cpus.txt is saying that:
> "On ARM 32-bit systems this property is optional and can be one of"
>
I am not very sure that this is an ABI break, as other platforms (e.g
hisilicon,hip01-smp) also adopted this as some later stage and they also
removed smp hook support from their machine files when they adopted to
this enable-method in DTS files.
If we want to keep older DTBs keep working with new Kernel image, then I
need to drop patch from mach-exynos and keep smp_ops hook in machine
descriptor as it is to keep supporting older DTBs. I can see some
platforms have adopted this way as well.
Surely I will add new bindings details in
Documentation/devicetree/bindings/arm/cpus.txt file. I am not sure why
checkpatch did not complain about this?
> 3. Please split DTS changes to separate patches. This is, by the way,
> connected with #2 above: if there was no ABI break, then the DTS
> could go to separate branch easily.
>
Since I am not sure if this will considered as ABI break or not, I just
looked how this was handled in other platforms, I can see some platforms
have clubbed DTS change along with mach files, and some have done in
separate patch as well. So I will look for suggestion from you for this
how we can go for exynos platform?
Thanks,
Pankaj Dubey
> Best regards,
> Krzysztof
>
>
>
^ permalink raw reply
* Re: [PATCH v13 0/7] dtc: Dynamic DT support
From: Pantelis Antoniou @ 2016-12-09 9:12 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: <20161209085432.GR13139-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
Hi David,
> On Dec 9, 2016, at 10:54 , David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
>
> On Fri, Dec 09, 2016 at 10:16:51AM +0200, Pantelis Antoniou wrote:
>> 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.
>
> Ok. Note that one of the patches I merged afterwards was a big rename
> of struct boot_info, so your patches will probably need a fair bit of
> fiddly though straightforward rebasing.
>
Fortunately not. The syntax sugar stuff do not rely on boot_info at all now
that the rule uses the inherited attribute trick.
> --
> 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 v1 2/2] crypto: mediatek - add DT bindings documentation
From: Matthias Brugger @ 2016-12-09 9:45 UTC (permalink / raw)
To: Ryder Lee
Cc: Herbert Xu, David S. Miller, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sean Wang,
Roy Luo
In-Reply-To: <1481188776.14860.26.camel@mtkswgap22>
On 08/12/16 10:19, Ryder Lee wrote:
> Hello,
>
> On Mon, 2016-12-05 at 11:18 +0100, Matthias Brugger wrote:
>>
>> On 05/12/16 08:01, Ryder Lee wrote:
>>> Add DT bindings documentation for the crypto driver
>>>
>>> Signed-off-by: Ryder Lee <ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>> ---
>>> .../devicetree/bindings/crypto/mediatek-crypto.txt | 32 ++++++++++++++++++++++
>>> 1 file changed, 32 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
>>> new file mode 100644
>>> index 0000000..8b1db08
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
>>> @@ -0,0 +1,32 @@
>>> +MediaTek cryptographic accelerators
>>> +
>>> +Required properties:
>>> +- compatible: Should be "mediatek,mt7623-crypto"
>>
>> Do you know how big the difference is between the crypto engine for
>> mt7623/mt2701/mt8521p in comparison, let's say mt8173 or mt6797?
>> Do this SoCs have a crypot engine? If so and they are quite similar, we
>> might think of adding a mtk-crypto binding and add soc specific bindings.
>
> This engine is just available in mt7623/mt2701/mt8521p series SoCs and
> they have no difference.
>
> But there are still other crypto IPs in MTK, i think maybe we could use
> "mediatek,{IP name}-crypto” to distinguish them ?
>
Sounds good, thanks for the clarification.
Matthias
>> Regards,
>> Matthias
>>
>>> +- reg: Address and length of the register set for the device
>>> +- interrupts: Should contain the five crypto engines interrupts in numeric
>>> + order. These are global system and four descriptor rings.
>>> +- clocks: the clock used by the core
>>> +- clock-names: the names of the clock listed in the clocks property. These are
>>> + "ethif", "cryp"
>>> +- power-domains: Must contain a reference to the PM domain.
>>> +
>>> +
>>> +Optional properties:
>>> +- interrupt-parent: Should be the phandle for the interrupt controller
>>> + that services interrupts for this device
>>> +
>>> +
>>> +Example:
>>> + crypto: crypto@1b240000 {
>>> + compatible = "mediatek,mt7623-crypto";
>>> + reg = <0 0x1b240000 0 0x20000>;
>>> + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_LOW>,
>>> + <GIC_SPI 83 IRQ_TYPE_LEVEL_LOW>,
>>> + <GIC_SPI 84 IRQ_TYPE_LEVEL_LOW>,
>>> + <GIC_SPI 91 IRQ_TYPE_LEVEL_LOW>,
>>> + <GIC_SPI 97 IRQ_TYPE_LEVEL_LOW>;
>>> + clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
>>> + <ðsys CLK_ETHSYS_CRYPTO>;
>>> + clock-names = "ethif","cryp";
>>> + power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
>>> + };
>>>
>
>
--
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] Documentation: ti-syscon-reset: fix header path
From: yegorslists-gM/Ye1E23mwN+BqQ9rBEUg @ 2016-12-09 10:11 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
Yegor Yefremov
From: Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
'include' was missing from path.
Signed-off-by: Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
index 164c7f3..5b20e20 100644
--- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
+++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
@@ -44,7 +44,7 @@ Required properties:
reset status register
Cell #7 : Flags used to control reset behavior,
availible flags defined in the DT include
- file <dt-bindings/reset/ti-syscon.h>
+ file <include/dt-bindings/reset/ti-syscon.h>
SysCon Reset Consumer Nodes
===========================
--
2.1.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 v2] mtd/spi-nor: Add SPI memory controllers for Aspeed SoCs
From: Cédric Le Goater @ 2016-12-09 10:42 UTC (permalink / raw)
To: Marek Vasut, 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: <6d1bb5a6-3a99-3320-297b-311d359294f6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 12/09/2016 03:29 AM, Marek Vasut wrote:
> On 12/08/2016 05:36 PM, Cédric Le Goater wrote:
>> Hello Marek,
>
> Hi!
Hello Hello,
[...]
>>>> + /*
>>>> + * 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.
Yes, clearly, Linux should do its own timing calibration and not depend
on the bootloader but I am not sure how to do that correctly, yet, in
the driver for all controllers. It depends on the controller type and
a lot on the flash model being used, which can vary for the same board.
U-Boot uses specific registers of the FMC controller to evaluate the
best SPI clock frequency. So, for the moment, keeping the previous
setting for :
bits [11:8] SPI clock frequency selection
is a nice thing to have. we can replace this setting when calibration
is handled from Linux.
The SPI controllers are different, they don't have the specific registers
for calibration, and so the algo is bit more painful.
> btw off-topic, but is U-Boot support for these aspeed devices ever
> be upstreamed ?
It is the plan to.
This year, we have spent quite sometime porting, fixing, cleaning
up the original code and getting ready to send a minimal framework,
cpu and console, to mainline (flash and net drivers can come later).
The code is operational on various boards but there is a major task
we have not completed yet, which is to rewrite the 2/3 KLOC of
assembly doing the DDR initialization :/ Once this is done, we
should send.
Here is the tree we use on OpenBMC :
https://github.com/openbmc/u-boot/commits/v2016.07-aspeed-openbmc
and a more recent branch with some extra cleanups :
https://github.com/legoater/u-boot/commits/v2016.11-aspeed-openbmc
Thanks,
C.
--
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/2] irqchip/renesas-intc-irqpin: fallback enhancements
From: Simon Horman @ 2016-12-09 10:50 UTC (permalink / raw)
To: Thomas Gleixner, Jason Cooper, Marc Zyngier
Cc: Rob Herring, Magnus Damm, linux-kernel, linux-renesas-soc,
devicetree, Simon Horman
Hi,
this short series aims to improve the fallback compatibility strings
for the renesas-intc-irqpin driver.
Based on v4.9-rc1.
Simon Horman (2):
irqchip/renesas-intc-irqpin: List fallback compatibility last
irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding
.../interrupt-controller/renesas,intc-irqpin.txt | 44 ++++++++++++----------
drivers/irqchip/irq-renesas-intc-irqpin.c | 4 +-
2 files changed, 27 insertions(+), 21 deletions(-)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* [PATCH 1/2] irqchip/renesas-intc-irqpin: List fallback compatibility last
From: Simon Horman @ 2016-12-09 10:50 UTC (permalink / raw)
To: Thomas Gleixner, Jason Cooper, Marc Zyngier
Cc: Rob Herring, Magnus Damm, linux-kernel, linux-renesas-soc,
devicetree, Simon Horman
In-Reply-To: <1481280650-9258-1-git-send-email-horms+renesas@verge.net.au>
Improve readability by listing the rmobile fallback compatibility string
after the more-specific compatibility strings they provide a fallback for.
This does not effect run-time behaviour as it is the order in the DTB that
determines which compatibility string is used.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
drivers/irqchip/irq-renesas-intc-irqpin.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c b/drivers/irqchip/irq-renesas-intc-irqpin.c
index 713177d97c7a..5fe1207a079c 100644
--- a/drivers/irqchip/irq-renesas-intc-irqpin.c
+++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
@@ -374,7 +374,6 @@ static const struct intc_irqpin_config intc_irqpin_rmobile = {
};
static const struct of_device_id intc_irqpin_dt_ids[] = {
- { .compatible = "renesas,intc-irqpin", },
{ .compatible = "renesas,intc-irqpin-r8a7778",
.data = &intc_irqpin_irlm_r8a777x },
{ .compatible = "renesas,intc-irqpin-r8a7779",
@@ -383,6 +382,7 @@ static const struct of_device_id intc_irqpin_dt_ids[] = {
.data = &intc_irqpin_rmobile },
{ .compatible = "renesas,intc-irqpin-sh73a0",
.data = &intc_irqpin_rmobile },
+ { .compatible = "renesas,intc-irqpin", },
{},
};
MODULE_DEVICE_TABLE(of, intc_irqpin_dt_ids);
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 2/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding
From: Simon Horman @ 2016-12-09 10:50 UTC (permalink / raw)
To: Thomas Gleixner, Jason Cooper, Marc Zyngier
Cc: Rob Herring, Magnus Damm, linux-kernel, linux-renesas-soc,
devicetree, Simon Horman
In-Reply-To: <1481280650-9258-1-git-send-email-horms+renesas@verge.net.au>
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 1, Gen 2 and Gen 3. But beyond that its not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7779 is older than r8a7778 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.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
.../interrupt-controller/renesas,intc-irqpin.txt | 44 ++++++++++++----------
drivers/irqchip/irq-renesas-intc-irqpin.c | 2 +
2 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
index 772c550d3b4b..e5a5251be9f5 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
@@ -2,13 +2,19 @@ DT bindings for the R-/SH-Mobile irqpin controller
Required properties:
-- compatible: has to be "renesas,intc-irqpin-<soctype>", "renesas,intc-irqpin"
- as fallback.
- Examples with soctypes are:
+- compatible:
- "renesas,intc-irqpin-r8a7740" (R-Mobile A1)
- "renesas,intc-irqpin-r8a7778" (R-Car M1A)
- "renesas,intc-irqpin-r8a7779" (R-Car H1)
- "renesas,intc-irqpin-sh73a0" (SH-Mobile AG5)
+ - "renesas,rcar-gen1-intc-irqpin" (generic R-Car Gen1 compatible device)
+ - "renesas,intc-irqpin" (generic device)
+
+ When compatible with a generic R-Car version, nodes must list the
+ SoC-specific version corresponding to the platform first followed by
+ the generic R-Car version.
+
+ "renesas,intc-irqpin" must be present and last.
- reg: Base address and length of each register bank used by the external
IRQ pins driven by the interrupt controller hardware module. The base
@@ -39,24 +45,22 @@ Optional properties:
Example
-------
- irqpin1: interrupt-controller@e6900004 {
- compatible = "renesas,intc-irqpin-r8a7740",
+ irqpin0: interrupt-controller@fe78001c {
+ compatible = "renesas,intc-irqpin-r8a7779",
+ "renesas,rcar-gen1-intc-irqpin",
"renesas,intc-irqpin";
#interrupt-cells = <2>;
+ status = "disabled";
interrupt-controller;
- reg = <0xe6900004 4>,
- <0xe6900014 4>,
- <0xe6900024 1>,
- <0xe6900044 1>,
- <0xe6900064 1>;
- interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH
- 0 149 IRQ_TYPE_LEVEL_HIGH
- 0 149 IRQ_TYPE_LEVEL_HIGH
- 0 149 IRQ_TYPE_LEVEL_HIGH
- 0 149 IRQ_TYPE_LEVEL_HIGH
- 0 149 IRQ_TYPE_LEVEL_HIGH
- 0 149 IRQ_TYPE_LEVEL_HIGH
- 0 149 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp2_clks R8A7740_CLK_INTCA>;
- power-domains = <&pd_a4s>;
+ reg = <0xfe78001c 4>,
+ <0xfe780010 4>,
+ <0xfe780024 4>,
+ <0xfe780044 4>,
+ <0xfe780064 4>,
+ <0xfe780000 4>;
+ interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ sense-bitfield-width = <2>;
};
diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c b/drivers/irqchip/irq-renesas-intc-irqpin.c
index 5fe1207a079c..70095b61a90a 100644
--- a/drivers/irqchip/irq-renesas-intc-irqpin.c
+++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
@@ -378,6 +378,8 @@ static const struct of_device_id intc_irqpin_dt_ids[] = {
.data = &intc_irqpin_irlm_r8a777x },
{ .compatible = "renesas,intc-irqpin-r8a7779",
.data = &intc_irqpin_irlm_r8a777x },
+ { .compatible = "renesas,rcar-gen1-intc-irqpin",
+ .data = &intc_irqpin_irlm_r8a777x },
{ .compatible = "renesas,intc-irqpin-r8a7740",
.data = &intc_irqpin_rmobile },
{ .compatible = "renesas,intc-irqpin-sh73a0",
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH v2 00/11] add support for VBUS max current and min voltage limits AXP20X and AXP22X PMICs
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
The X-Powers AXP209 and AXP20X PMICs are able to set a limit for the
VBUS power supply for both max current and min voltage supplied. This
series of patch adds the possibility to set these limits from sysfs.
Also, the AXP223 PMIC shares most of its behaviour with the AXP221 but
the former can set the VBUS power supply max current to 100mA, unlike
the latter. The AXP223 VBUS power supply driver used to probe on the
AXP221 compatible. This series of patch introduces a new compatible for
the AXP223 to be able to set the current max limit to 100mA.
With that new compatible, boards having the AXP223 see their DT updated
to use the VBUS power supply driver with the correct compatible.
This series of patch also migrates from of_device_is_compatible function
to the data field of of_device_id to identify the compatible used to
probe. This improves the code readability.
Mostly cosmetic changes in v2 and adding volatile and writeable regs to
AXP20X and AXP22X MFD cells for the VBUS power supply driver.
Quentin Schulz (11):
power: supply: axp20x_usb_power: use of_device_id data field instead
of device_is_compatible
mfd: axp20x: add volatile and writeable reg ranges for VBUS power
supply driver
power: supply: axp20x_usb_power: set min voltage and max current from
sysfs
Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
power: supply: axp20x_usb_power: add 100mA max current limit for
AXP223
mfd: axp20x: add separate MFD cell for AXP223
ARM: dtsi: add DTSI for AXP223
ARM: dts: sun8i-a33-olinuxino: use AXP223 DTSI
ARM: dts: sun8i-a33-sinlinx-sina33: use AXP223 DTSI
ARM: dts: sun8i-r16-parrot: use AXP223 DTSI
ARM: dtsi: sun8i-reference-design-tablet: use AXP223 DTSI
.../bindings/power/supply/axp20x_usb_power.txt | 5 +
arch/arm/boot/dts/axp223.dtsi | 58 +++++++++++
arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 2 +-
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 2 +-
arch/arm/boot/dts/sun8i-r16-parrot.dts | 2 +-
.../boot/dts/sun8i-reference-design-tablet.dtsi | 2 +-
drivers/mfd/axp20x.c | 32 +++++-
drivers/power/supply/axp20x_usb_power.c | 116 ++++++++++++++++++---
8 files changed, 197 insertions(+), 22 deletions(-)
create mode 100644 arch/arm/boot/dts/axp223.dtsi
--
2.9.3
^ permalink raw reply
* [PATCH v2 01/11] power: supply: axp20x_usb_power: use of_device_id data field instead of device_is_compatible
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: thomas.petazzoni, devicetree, linux-pm, linux-kernel,
Quentin Schulz, linux-arm-kernel
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
This replaces calls to of_device_is_compatible to check data field of
of_device_id matched when probing the driver.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
drivers/power/supply/axp20x_usb_power.c | 26 +++++++++++++++-----------
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c
index 6af6feb..8985646 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -17,6 +17,7 @@
#include <linux/mfd/axp20x.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/power_supply.h>
#include <linux/regmap.h>
@@ -45,6 +46,7 @@ struct axp20x_usb_power {
struct device_node *np;
struct regmap *regmap;
struct power_supply *supply;
+ int axp20x_id;
};
static irqreturn_t axp20x_usb_power_irq(int irq, void *devid)
@@ -86,8 +88,7 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
switch (v & AXP20X_VBUS_CLIMIT_MASK) {
case AXP20X_VBUC_CLIMIT_100mA:
- if (of_device_is_compatible(power->np,
- "x-powers,axp202-usb-power-supply")) {
+ if (power->axp20x_id == AXP202_ID) {
val->intval = 100000;
} else {
val->intval = -1; /* No 100mA limit */
@@ -130,8 +131,7 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
val->intval = POWER_SUPPLY_HEALTH_GOOD;
- if (of_device_is_compatible(power->np,
- "x-powers,axp202-usb-power-supply")) {
+ if (power->axp20x_id == AXP202_ID) {
ret = regmap_read(power->regmap,
AXP20X_USB_OTG_STATUS, &v);
if (ret)
@@ -214,11 +214,12 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
if (!power)
return -ENOMEM;
+ power->axp20x_id = (int)of_device_get_match_data(&pdev->dev);
+
power->np = pdev->dev.of_node;
power->regmap = axp20x->regmap;
- if (of_device_is_compatible(power->np,
- "x-powers,axp202-usb-power-supply")) {
+ if (power->axp20x_id == AXP202_ID) {
/* Enable vbus valid checking */
ret = regmap_update_bits(power->regmap, AXP20X_VBUS_MON,
AXP20X_VBUS_MON_VBUS_VALID,
@@ -235,8 +236,7 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
usb_power_desc = &axp20x_usb_power_desc;
irq_names = axp20x_irq_names;
- } else if (of_device_is_compatible(power->np,
- "x-powers,axp221-usb-power-supply")) {
+ } else if (power->axp20x_id == AXP221_ID) {
usb_power_desc = &axp22x_usb_power_desc;
irq_names = axp22x_irq_names;
} else {
@@ -273,9 +273,13 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
}
static const struct of_device_id axp20x_usb_power_match[] = {
- { .compatible = "x-powers,axp202-usb-power-supply" },
- { .compatible = "x-powers,axp221-usb-power-supply" },
- { }
+ {
+ .compatible = "x-powers,axp202-usb-power-supply",
+ .data = (void *)AXP202_ID,
+ }, {
+ .compatible = "x-powers,axp221-usb-power-supply",
+ .data = (void *)AXP221_ID,
+ }, { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
--
2.9.3
^ permalink raw reply related
* [PATCH v2 02/11] mfd: axp20x: add volatile and writeable reg ranges for VBUS power supply driver
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
The X-Powers AXP20X and AXP22X PMICs allow to choose the maximum voltage
and minimum current delivered by the VBUS power supply.
This adds the register used by the VBUS power supply driver to the range
of volatile and writeable regs ranges.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
added in v2
drivers/mfd/axp20x.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index ba130be..6ee2cc6 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -65,12 +65,14 @@ static const struct regmap_access_table axp152_volatile_table = {
static const struct regmap_range axp20x_writeable_ranges[] = {
regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
+ regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
};
static const struct regmap_range axp20x_volatile_ranges[] = {
regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_USB_OTG_STATUS),
+ regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL2),
regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
regmap_reg_range(AXP20X_ACIN_V_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
@@ -91,11 +93,13 @@ static const struct regmap_access_table axp20x_volatile_table = {
/* AXP22x ranges are shared with the AXP809, as they cover the same range */
static const struct regmap_range axp22x_writeable_ranges[] = {
regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
+ regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
};
static const struct regmap_range axp22x_volatile_ranges[] = {
regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_PWR_OP_MODE),
+ regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
regmap_reg_range(AXP22X_GPIO_STATE, AXP22X_GPIO_STATE),
regmap_reg_range(AXP20X_FG_RES, AXP20X_FG_RES),
--
2.9.3
^ permalink raw reply related
* [PATCH v2 03/11] power: supply: axp20x_usb_power: set min voltage and max current from sysfs
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
AXP20X and AXP22X PMICs allow setting the min voltage and max current of
VBUS power supply. This adds entries in sysfs to allow to do so.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
v2:
- moving defines from header mfd/axp20x.h to the driver,
- adding two functions to reduce indentation in axp20x_usb_power_set_property,
- adding new define for VBUS register VHOLD bits offset,
- switching return values in case of invalid value from 0 to -EINVAL,
drivers/power/supply/axp20x_usb_power.c | 81 +++++++++++++++++++++++++++++++++
1 file changed, 81 insertions(+)
diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c
index 8985646..9e3f4ae 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -31,6 +31,8 @@
#define AXP20X_USB_STATUS_VBUS_VALID BIT(2)
#define AXP20X_VBUS_VHOLD_uV(b) (4000000 + (((b) >> 3) & 7) * 100000)
+#define AXP20X_VBUS_VHOLD_MASK GENMASK(5, 3)
+#define AXP20X_VBUS_VHOLD_OFFSET 3
#define AXP20X_VBUS_CLIMIT_MASK 3
#define AXP20X_VBUC_CLIMIT_900mA 0
#define AXP20X_VBUC_CLIMIT_500mA 1
@@ -155,6 +157,81 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
return 0;
}
+static int axp20x_usb_power_set_voltage_min(struct axp20x_usb_power *power,
+ int intval)
+{
+ int val;
+
+ switch (intval) {
+ case 4000000:
+ case 4100000:
+ case 4200000:
+ case 4300000:
+ case 4400000:
+ case 4500000:
+ case 4600000:
+ case 4700000:
+ val = (intval - 4000000) / 100000;
+ return regmap_update_bits(power->regmap,
+ AXP20X_VBUS_IPSOUT_MGMT,
+ AXP20X_VBUS_VHOLD_MASK,
+ val << AXP20X_VBUS_VHOLD_OFFSET);
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static int axp20x_usb_power_set_current_max(struct axp20x_usb_power *power,
+ int intval)
+{
+ int val;
+
+ switch (intval) {
+ case 100000:
+ if (power->axp20x_id == AXP221_ID)
+ return -EINVAL;
+ case 500000:
+ case 900000:
+ val = (900000 - intval) / 400000;
+ return regmap_update_bits(power->regmap,
+ AXP20X_VBUS_IPSOUT_MGMT,
+ AXP20X_VBUS_CLIMIT_MASK, val);
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static int axp20x_usb_power_set_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ const union power_supply_propval *val)
+{
+ struct axp20x_usb_power *power = power_supply_get_drvdata(psy);
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_VOLTAGE_MIN:
+ return axp20x_usb_power_set_voltage_min(power, val->intval);
+
+ case POWER_SUPPLY_PROP_CURRENT_MAX:
+ return axp20x_usb_power_set_current_max(power, val->intval);
+
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static int axp20x_usb_power_prop_writeable(struct power_supply *psy,
+ enum power_supply_property psp)
+{
+ return psp == POWER_SUPPLY_PROP_VOLTAGE_MIN ||
+ psp == POWER_SUPPLY_PROP_CURRENT_MAX;
+}
+
static enum power_supply_property axp20x_usb_power_properties[] = {
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_PRESENT,
@@ -178,7 +255,9 @@ static const struct power_supply_desc axp20x_usb_power_desc = {
.type = POWER_SUPPLY_TYPE_USB,
.properties = axp20x_usb_power_properties,
.num_properties = ARRAY_SIZE(axp20x_usb_power_properties),
+ .property_is_writeable = axp20x_usb_power_prop_writeable,
.get_property = axp20x_usb_power_get_property,
+ .set_property = axp20x_usb_power_set_property,
};
static const struct power_supply_desc axp22x_usb_power_desc = {
@@ -186,7 +265,9 @@ static const struct power_supply_desc axp22x_usb_power_desc = {
.type = POWER_SUPPLY_TYPE_USB,
.properties = axp22x_usb_power_properties,
.num_properties = ARRAY_SIZE(axp22x_usb_power_properties),
+ .property_is_writeable = axp20x_usb_power_prop_writeable,
.get_property = axp20x_usb_power_get_property,
+ .set_property = axp20x_usb_power_set_property,
};
static int axp20x_usb_power_probe(struct platform_device *pdev)
--
2.9.3
^ permalink raw reply related
* [PATCH v2 04/11] Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
This adds the "x-powers,axp223-usb-power-supply" to the list of
compatibles for AXP20X VBUS power supply driver.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
v2:
- adding small explanation on AXP223 variation compared to the AXP221,
Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
index f1d7bee..ba8d35f 100644
--- a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
+++ b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
@@ -3,6 +3,11 @@ AXP20x USB power supply
Required Properties:
-compatible: One of: "x-powers,axp202-usb-power-supply"
"x-powers,axp221-usb-power-supply"
+ "x-powers,axp223-usb-power-supply"
+
+The AXP223 PMIC shares most of its behaviour with the AXP221 but has slight
+variations such as the former being able to set the VBUS power supply max
+current to 100mA, unlike the latter.
This node is a subnode of the axp20x PMIC.
--
2.9.3
^ 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