* Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
From: Rob Herring @ 2016-11-29 14:51 UTC (permalink / raw)
To: Ulf Hansson
Cc: Matt Ranostay,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tony Lindgren,
Mark Rutland, Srinivas Kandagatla
In-Reply-To: <CAPDyKFr=TE+EuZ9rZV3ygsjBFN_mRrE2imkFa-wQs_ykM5d+cQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Nov 28, 2016 at 9:54 AM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> [...]
>
>>> +
>>> +Example:
>>> +
>>> + wifi_pwrseq: wifi_pwrseq {
>>> + compatible = "mmc-pwrseq-sd8787";
>>> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
>>> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
>>> + }
>>> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> index c421aba0a5bc..08fd65d35725 100644
>>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> @@ -32,6 +32,9 @@ Optional properties:
>>> so that the wifi chip can wakeup host platform under certain condition.
>>> during system resume, the irq will be disabled to make sure
>>> unnecessary interrupt is not received.
>>> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>>
>> This is why pwrseq is wrong. You have some properties in the card node
>> and some in pwrseq node. Everything should be in the card node.
>
> Put "all" in the card node, just doesn't work for MMC. Particular in
> cases when we have removable cards, as then it would be wrong to have
> a card node.
When is there a problem with removable cards? The connector is
standard and everything needed (CD, VMMC, VDDIO, etc.) is defined in
the host controller node. If that isn't sufficient, then we should
start defining a connector node.
> The mmc pwrseq DT bindings just follows the legacy approach for MMC
> and that's why the pwrseq handle is at the controller node. Yes, would
> could have done it differently, but this is the case now, so we will
> have to accept that.
We're stuck with supporting the existing cases. That doesn't mean
we're stuck with the same thing for new cases.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/5] arm64: dts: marvell: Add definition of SPI controller for Armada 3700
From: Thomas Petazzoni @ 2016-11-29 14:51 UTC (permalink / raw)
To: Romain Perier
Cc: Mark Brown, linux-spi-u79uwXL29TY76Z2rM5mHXA, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161129143939.3191-5-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hello,
On Tue, 29 Nov 2016 15:39:38 +0100, Romain Perier wrote:
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index e9bd587..84e4f57 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -98,6 +98,19 @@
> /* 32M internal register @ 0xd000_0000 */
> ranges = <0x0 0x0 0xd0000000 0x2000000>;
>
> + spi0: spi@10600 {
> + compatible = "marvell,armada-3700-spi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x10600 0x5d>;
> + clocks = <&nb_periph_clk 7>;
> + clock-frequency = <200000000>;
This property.
> + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> + max-frequency = <66000000>;
And this one no longer exist in your DT binding, so I guess they should
be removed from here as well.
(Please wait for other reviews, don't respin just for that issue.)
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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 13/13] clocksource/drivers/rockchip_timer: Prevent ftrace recursion
From: Heiko Stübner @ 2016-11-29 15:01 UTC (permalink / raw)
To: Alexander Kochetkov
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Thomas Gleixner,
Mark Rutland, Rob Herring, Russell King, Caesar Wang, Huang Tao,
Daniel Lezcano
In-Reply-To: <1480427118-5126-14-git-send-email-al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Am Dienstag, 29. November 2016, 16:45:18 schrieb Alexander Kochetkov:
> Currently rockchip_timer can be used as a scheduler clock. We properly
> marked rk_timer_sched_clock_read() as notrace but we then call another
> function rk_timer_counter_read() that _wasn't_ notrace.
>
> Having a traceable function in the sched_clock() path leads to a recursion
> within ftrace and a kernel crash.
>
> Fix this by adding an extra notrace function to keep other users of
> rk_timer_counter_read() traceable.
>
> Signed-off-by: Alexander Kochetkov <al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
you introduced the issue yourself in patch 11/13. In general any patch should
never leave the kernel in a worse state than it was before, so no patch should
ever introduce known issues itself.
In that line of thought, don't patches 10+11 introduce warnings about unused
functions as well when applied without patch 12?
Maybe merge them?
Heiko
> ---
> drivers/clocksource/rockchip_timer.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clocksource/rockchip_timer.c
> b/drivers/clocksource/rockchip_timer.c index 1af80a0..a127822 100644
> --- a/drivers/clocksource/rockchip_timer.c
> +++ b/drivers/clocksource/rockchip_timer.c
> @@ -87,7 +87,7 @@ static void rk_timer_update_counter(u64 cycles, struct
> rk_timer *timer) writel_relaxed(upper, timer->base + TIMER_LOAD_COUNT1);
> }
>
> -static u64 rk_timer_counter_read(struct rk_timer *timer)
> +static u64 notrace _rk_timer_counter_read(struct rk_timer *timer)
> {
> u64 counter;
> u32 lower;
> @@ -106,6 +106,11 @@ static u64 rk_timer_counter_read(struct rk_timer
> *timer) return counter;
> }
>
> +static u64 rk_timer_counter_read(struct rk_timer *timer)
> +{
> + return _rk_timer_counter_read(timer);
> +}
> +
> static void rk_timer_interrupt_clear(struct rk_timer *timer)
> {
> writel_relaxed(1, timer->base + TIMER_INT_STATUS);
> @@ -168,7 +173,7 @@ static u64 notrace rk_timer_sched_clock_read(void)
> {
> struct rk_clocksource *_cs = &cs_timer;
>
> - return ~rk_timer_counter_read(&_cs->timer);
> + return ~_rk_timer_counter_read(&_cs->timer);
> }
>
> static int __init rk_timer_init(struct device_node *np, u32 ctrl_reg)
--
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 08/13] clocksource/drivers/rockchip_timer: drop unused rk_base() and rk_ctrl()
From: Heiko Stübner @ 2016-11-29 15:03 UTC (permalink / raw)
To: Alexander Kochetkov
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Thomas Gleixner,
Mark Rutland, Rob Herring, Russell King, Caesar Wang, Huang Tao,
Daniel Lezcano
In-Reply-To: <1480427118-5126-9-git-send-email-al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Am Dienstag, 29. November 2016, 16:45:13 schrieb Alexander Kochetkov:
> Use of functions has been ceased by previous commit.
Then why do you need another patch to remove them and don't do that in the
patch removing their respective usage?
>
> Signed-off-by: Alexander Kochetkov <al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/clocksource/rockchip_timer.c | 10 ----------
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/clocksource/rockchip_timer.c
> b/drivers/clocksource/rockchip_timer.c index aa9ccd1..a17dc61 100644
> --- a/drivers/clocksource/rockchip_timer.c
> +++ b/drivers/clocksource/rockchip_timer.c
> @@ -53,16 +53,6 @@ static inline struct rk_timer *rk_timer(struct
> clock_event_device *ce) return &rk_clock_event_device(ce)->timer;
> }
>
> -static inline void __iomem *rk_base(struct clock_event_device *ce)
> -{
> - return rk_timer(ce)->base;
> -}
> -
> -static inline void __iomem *rk_ctrl(struct clock_event_device *ce)
> -{
> - return rk_timer(ce)->ctrl;
> -}
> -
> static inline void rk_timer_disable(struct rk_timer *timer)
> {
> writel_relaxed(TIMER_DISABLE, timer->ctrl);
--
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] of: Fix issue where code would fall through to error case.
From: Rob Herring @ 2016-11-29 15:06 UTC (permalink / raw)
To: Frank Rowand
Cc: Moritz Fischer, Moritz Fischer,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pantelis Antoniou, moritz-62aBmqa6xEOcmJEhUYGoYg,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <583C4D83.6040800-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Nov 28, 2016 at 9:30 AM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 11/26/16 13:39, Frank Rowand wrote:
>> On 11/23/16 13:58, Rob Herring wrote:
>>> On Thu, Nov 17, 2016 at 6:10 PM, Moritz Fischer
>>> <moritz.fischer.private-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> On Thu, Nov 17, 2016 at 4:02 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>> On 11/17/16 15:40, Frank Rowand wrote:
>>>>>> On 11/17/16 15:25, Moritz Fischer wrote:
>>>>>>> No longer fall through into the error case that prints out
>>>>>>> an error if no error (err = 0) occurred.
>>>>>>>
>>>>>>> Fixes d9181b20a83(of: Add back an error message, restructured)
>>>>>>> Signed-off-by: Moritz Fischer <moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org>
>>>>>>> ---
>>>>>>> drivers/of/resolver.c | 6 +++++-
>>>>>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
>>>>>>> index 783bd09..785076d 100644
>>>>>>> --- a/drivers/of/resolver.c
>>>>>>> +++ b/drivers/of/resolver.c
>>>>>>> @@ -358,9 +358,13 @@ int of_resolve_phandles(struct device_node *overlay)
>>>>>>>
>>>>>>> err = update_usages_of_a_phandle_reference(overlay, prop, phandle);
>>>>>>> if (err)
>>>>>>> - break;
>>>>>>> + goto err_out;
>>>>>>> }
>>>>>>>
>>>>>>> + of_node_put(tree_symbols);
>>>>>>> +
>>>>>>> + return 0;
>>>>>>> +
>>>>>>> err_out:
>>>>>>> pr_err("overlay phandle fixup failed: %d\n", err);
>>>>>>> out:
>>>>>>
>>>>>> Thanks for catching that.
>>>>>>
>>>>>> Rob, please apply.
>>>>>>
>>>>>> Reviewed-by: Frank Rowand <frank.rowand-mEdOJwZ7QcZBDgjK7y7TUQ@public.gmane.org>
>>>>>>
>>>>>> -Frank
>>>>>
>>>>> On second thought, isn't the common pattern when clean up is needed for
>>>>> both the no-error path and the error path something like:
>>>>>
>>>>>
>>>>> out:
>>>>> of_node_put(tree_symbols);
>>>>> return err;
>>>>>
>>>>> err_out:
>>>>> pr_err("overlay phandle fixup failed: %d\n", err);
>>>>> goto out;
>>>>> }
>>>>>
>>>>>
>>>>> I don't have a strong opinion, whatever Rob wants to take is fine with me.
>>>>
>>>> Same here. I tried to avoid the jumping back part, but if that's the
>>>> common pattern,
>>>> I can submit a v2 doing that instead.
>>>
>>> Both are ugly. Just do:
>>>
>>> if (err)
>>> pr_err(...);
>>>
>>> Rob
>>
>> Agreed. Thanks for the touch of sanity Rob.
>>
>> -Frank
>
> I succumbed to looking only at the few lines of code above and not the
> fuller context of the file that the patch applies to.
>
> The proposed patch was fixing the problem that a normal completion
> of the for loop was falling through into the err_out label. So what
> looks cleaner ("if (err) pr_err(...)") is actually not correct.
What!? The *only* problem was printing the error message in the err=0
case. All that needs to be fixed is not doing that. If we do that,
then we really only need 1 goto label.
Rob
--
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] drivers/of: Export phandle iterators
From: Rob Herring @ 2016-11-29 15:06 UTC (permalink / raw)
To: Robin Murphy
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Frank Rowand
In-Reply-To: <18302005-166c-37b9-6e6d-35804ff685ff@arm.com>
On Thu, Nov 24, 2016 at 6:33 AM, Robin Murphy <robin.murphy@arm.com> wrote:
> Hi Rob,
>
> On 23/11/16 21:49, Rob Herring wrote:
>> On Wed, Nov 23, 2016 at 1:06 PM, Robin Murphy <robin.murphy@arm.com> wrote:
>>> Modular drivers may want to use of_for_each_phandle() - export its
>>> constituent functions.
>>
>> Do you have a user?
>
> I've been experimenting with modular IOMMU drivers on top of the
> probe-deferral stuff[1], and the ARM SMMU driver in particular demands a
> whole pile of exports. I thought I'd throw this one out now since nearly
> all the other of_* functions are exported already, but I'm quite happy
> to sit on it if you'd prefer to wait for a concrete in-tree need (it'll
> be a while yet).
>
> Robin.
>
> [1]:http://www.linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/defer
^ permalink raw reply
* Re: [PATCH 4/5] arm64: dts: marvell: Add definition of SPI controller for Armada 3700
From: Romain Perier @ 2016-11-29 15:08 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Mark Rutland, Andrew Lunn, Jason Cooper, Pawel Moll, devicetree,
Ian Campbell, Rob Herring, linux-spi, Mark Brown, Kumar Gala,
Gregory Clement, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20161129155129.6f3c76b6@free-electrons.com>
Hello,
Le 29/11/2016 à 15:51, Thomas Petazzoni a écrit :
>
>> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
>> index e9bd587..84e4f57 100644
>> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
>> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
>> @@ -98,6 +98,19 @@
>> /* 32M internal register @ 0xd000_0000 */
>> ranges = <0x0 0x0 0xd0000000 0x2000000>;
>>
>> + spi0: spi@10600 {
>> + compatible = "marvell,armada-3700-spi";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0x10600 0x5d>;
>> + clocks = <&nb_periph_clk 7>;
>> + clock-frequency = <200000000>;
>
> This property.
>
>> + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
>> + max-frequency = <66000000>;
>
> And this one no longer exist in your DT binding, so I guess they should
> be removed from here as well.
>
Good point, I was pretty sure that I have removed these.
I probably did something wrong with my rebase.
Thanks,
Romain
^ permalink raw reply
* Re: [PATCH v2 01/13] devicetree/bindings: display: Document common panel properties
From: Rob Herring @ 2016-11-29 15:14 UTC (permalink / raw)
To: Laurent Pinchart
Cc: open list:MEDIA DRIVERS FOR RENESAS - FCP,
devicetree@vger.kernel.org, Tomi Valkeinen, Laurent Pinchart,
dri-devel
In-Reply-To: <2454182.olmziLZUmD@avalon>
On Tue, Nov 29, 2016 at 2:27 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Rob,
>
> On Tuesday 22 Nov 2016 11:36:55 Laurent Pinchart wrote:
>> On Monday 21 Nov 2016 10:48:15 Rob Herring wrote:
>> > On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote:
>> >> Document properties common to several display panels in a central
>> >> location that can be referenced by the panel device tree bindings.
>> >
>> > Looks good. Just one comment...
>> >
>> > [...]
>> >
>> >> +Connectivity
>> >> +------------
>> >> +
>> >> +- ports: Panels receive video data through one or multiple connections.
>> >> While
>> >> + the nature of those connections is specific to the panel type, the
>> >> + connectivity is expressed in a standard fashion using ports as
>> >> specified in
>> >> + the device graph bindings defined in
>> >> + Documentation/devicetree/bindings/graph.txt.
>> >
>> > We allow panels to either use graph binding or be a child of the display
>> > controller.
>>
>> I knew that some display controllers use a phandle to the panel (see the
>> fsl,panel and nvidia,panel properties), but I didn't know we had panels as
>> children of display controller nodes. I don't think we should allow that for
>> anything but DSI panels, as the DT hierarchy is based on control buses. Are
>> you sure we have other panels instantiated through that mechanism ?
Some panels have no control bus, so were do we place them? I would say
the hierarchy is based on buses with a preference for the control bus
when there are multiple buses. I'm not a fan of just sticking things
are the top level.
> Ping ?
>
> Please note that this file documents properties common to multiple panel DT
> bindings, but in no way makes it mandatory to use the OF graph bindings for
> panels. The decision is left to individual bindings.
It is mandatory in the sense that we don't want more cases of "fsl,panel".
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] mfd: cpcap: Add minimal support
From: Rob Herring @ 2016-11-29 15:20 UTC (permalink / raw)
To: Lee Jones
Cc: Tony Lindgren, Samuel Ortiz,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Marcel Partap,
Mark Rutland, Michael Scott
In-Reply-To: <20161124085926.GV10134-Re9dqnLqz4GzQB+pC5nmwQ@public.gmane.org>
On Thu, Nov 24, 2016 at 2:59 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Wed, 23 Nov 2016, Tony Lindgren wrote:
>
>> * Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [161121 03:43]:
>> > On Fri, 18 Nov 2016, Tony Lindgren wrote:
>> > > --- a/drivers/mfd/Makefile
>> > > +++ b/drivers/mfd/Makefile
>> > > @@ -97,6 +97,7 @@ obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o
>> > > obj-$(CONFIG_MFD_CORE) += mfd-core.o
>> > >
>> > > obj-$(CONFIG_EZX_PCAP) += ezx-pcap.o
>> > > +obj-$(CONFIG_MFD_CPCAP) += cpcap.o
>> >
>> > Who is the manufacturer?
>>
>> Hmm that I don't know. There seems to be both ST and TI versions
>> of this chip manufactured for Motorola. So my guess is that it
>> should be Motorola unless there's some similar catalog part
>> available from ST used by others. If anybody has more info
>> on this please let me know :)
>
> If this IP is shared amongst vendors, it usually means it was designed
> by someone else? Synopsis perhaps?
xCAP names originated from Motorola cellular group with parts (going
back to analog/2G days) coming from Motorola Semi, TI, and ST it
seems. All individually developed AFAIK.
Rob
--
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] iio: misc: add a generic regulator driver
From: Bartosz Golaszewski @ 2016-11-29 15:22 UTC (permalink / raw)
To: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Rob Herring, Mark Rutland
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Kevin Hilman,
Patrick Titiano, Neil Armstrong, Bartosz Golaszewski
Some iio devices are powered externally by a regulator which, for
example, can be used to power-cycle an adc.
This patch proposes to add a simple driver representing a regulator
to the iio framework which exports attributes allowing to manipulate
the underlying hardware.
The reason for connecting the regulator and the iio frameworks is that
once libiio learns to toggle iio attributes we'll be able to
power-cycle devices remotely.
Initially the driver only supports enable/disable operations, but it
should be straightforward to extend it with other regulator operations
in the future.
Tested with a baylibre-acme board for beaglebone black.
Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
.../devicetree/bindings/iio/misc/iio-regulator.txt | 18 +++
drivers/iio/Kconfig | 1 +
drivers/iio/Makefile | 1 +
drivers/iio/misc/Kconfig | 17 +++
drivers/iio/misc/Makefile | 6 +
drivers/iio/misc/iio-regulator.c | 121 +++++++++++++++++++++
6 files changed, 164 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
create mode 100644 drivers/iio/misc/Kconfig
create mode 100644 drivers/iio/misc/Makefile
create mode 100644 drivers/iio/misc/iio-regulator.c
diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
new file mode 100644
index 0000000..147458f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
@@ -0,0 +1,18 @@
+Industrial IO regulator device driver
+-------------------------------------
+
+This document describes the bindings for the iio-regulator - a dummy device
+driver representing a physical regulator within the iio framework.
+
+Required properties:
+
+- compatible: must be "iio-regulator"
+- vcc-supply: phandle of the regulator this device represents
+
+Example
+-------
+
+iio_regulator {
+ compatible = "iio-regulator";
+ vcc-supply = <&vcc0>;
+};
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 6743b18..2e896e0 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -80,6 +80,7 @@ source "drivers/iio/gyro/Kconfig"
source "drivers/iio/health/Kconfig"
source "drivers/iio/humidity/Kconfig"
source "drivers/iio/imu/Kconfig"
+source "drivers/iio/misc/Kconfig"
source "drivers/iio/light/Kconfig"
source "drivers/iio/magnetometer/Kconfig"
source "drivers/iio/orientation/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 87e4c43..4008d5a 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -25,6 +25,7 @@ obj-y += frequency/
obj-y += health/
obj-y += humidity/
obj-y += imu/
+obj-y += misc/
obj-y += light/
obj-y += magnetometer/
obj-y += orientation/
diff --git a/drivers/iio/misc/Kconfig b/drivers/iio/misc/Kconfig
new file mode 100644
index 0000000..b43a1ed
--- /dev/null
+++ b/drivers/iio/misc/Kconfig
@@ -0,0 +1,17 @@
+#
+# Miscellaneous iio drivers
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Miscellaneous iio drivers"
+
+config IIO_REGULATOR
+ tristate "IIO regulator driver"
+ depends on REGULATOR
+ help
+ Say yes here to build support for regulators powering iio devices.
+
+ To compile this driver as a module, choose M here: the module will
+ be called iio-regulator.
+
+endmenu
diff --git a/drivers/iio/misc/Makefile b/drivers/iio/misc/Makefile
new file mode 100644
index 0000000..da8f56a
--- /dev/null
+++ b/drivers/iio/misc/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for IIO misc drivers
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_IIO_REGULATOR) += iio-regulator.o
diff --git a/drivers/iio/misc/iio-regulator.c b/drivers/iio/misc/iio-regulator.c
new file mode 100644
index 0000000..0d61553
--- /dev/null
+++ b/drivers/iio/misc/iio-regulator.c
@@ -0,0 +1,121 @@
+/*
+ * Generic regulator driver for industrial IO.
+ *
+ * Copyright (C) 2016 BayLibre SAS
+ *
+ * Author:
+ * Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBpdZSXdFL2CA@public.gmane.org>
+ *
+ * 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.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+struct iio_regulator_context {
+ struct regulator *regulator;
+};
+
+static ssize_t iio_regulator_enable_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct iio_regulator_context *ctx = iio_priv(dev_to_iio_dev(dev));
+
+ return sprintf(buf, "%d\n", regulator_is_enabled(ctx->regulator));
+}
+
+static ssize_t iio_regulator_enable_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct iio_regulator_context *ctx = iio_priv(dev_to_iio_dev(dev));
+ int ret, enabled;
+ bool val;
+
+ ret = strtobool(buf, &val);
+ if (ret)
+ return ret;
+
+ enabled = regulator_is_enabled(ctx->regulator);
+ if ((val && enabled) || (!val && !enabled))
+ return -EPERM;
+
+ ret = val ? regulator_enable(ctx->regulator) :
+ regulator_disable(ctx->regulator);
+ if (ret)
+ return ret;
+
+ return len;
+}
+
+static IIO_DEVICE_ATTR(in_enable, 0644,
+ iio_regulator_enable_show,
+ iio_regulator_enable_store, 0);
+
+static struct attribute *iio_regulator_attributes[] = {
+ &iio_dev_attr_in_enable.dev_attr.attr,
+ NULL,
+};
+
+static const struct attribute_group iio_regulator_attribute_group = {
+ .attrs = iio_regulator_attributes,
+};
+
+static const struct iio_info iio_regulator_info = {
+ .driver_module = THIS_MODULE,
+ .attrs = &iio_regulator_attribute_group,
+};
+
+static int iio_regulator_probe(struct platform_device *pdev)
+{
+ struct iio_regulator_context *ctx;
+ struct iio_dev *iio_dev;
+ struct device *dev;
+
+ dev = &pdev->dev;
+
+ iio_dev = devm_iio_device_alloc(dev, sizeof(*ctx));
+ if (!iio_dev)
+ return -ENOMEM;
+
+ ctx = iio_priv(iio_dev);
+
+ ctx->regulator = devm_regulator_get(dev, "vcc");
+ if (IS_ERR(ctx->regulator)) {
+ dev_err(dev, "unable to get vcc regulator: %ld\n",
+ PTR_ERR(ctx->regulator));
+ return PTR_ERR(ctx->regulator);
+ }
+
+ iio_dev->dev.parent = dev;
+ iio_dev->dev.of_node = dev->of_node;
+ iio_dev->name = dev->driver->name;
+ iio_dev->info = &iio_regulator_info;
+
+ return devm_iio_device_register(dev, iio_dev);
+}
+
+static const struct of_device_id iio_regulator_of_match[] = {
+ { .compatible = "iio-regulator", },
+ { },
+};
+
+static struct platform_driver iio_regulator_platform_driver = {
+ .probe = iio_regulator_probe,
+ .driver = {
+ .name = "iio-regulator",
+ .of_match_table = iio_regulator_of_match,
+ },
+};
+module_platform_driver(iio_regulator_platform_driver);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>");
+MODULE_DESCRIPTION("Regulator driver for iio");
+MODULE_LICENSE("GPL v2");
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] iio: misc: add a generic regulator driver
From: Lars-Peter Clausen @ 2016-11-29 15:30 UTC (permalink / raw)
To: Bartosz Golaszewski, Jonathan Cameron, Hartmut Knaack,
Peter Meerwald-Stadler, Rob Herring, Mark Rutland
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Kevin Hilman,
Patrick Titiano, Neil Armstrong
In-Reply-To: <1480432969-20913-1-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote:
[...]
> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
> new file mode 100644
> index 0000000..147458f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
> @@ -0,0 +1,18 @@
> +Industrial IO regulator device driver
> +-------------------------------------
> +
> +This document describes the bindings for the iio-regulator - a dummy device
> +driver representing a physical regulator within the iio framework.
No bindings for drivers, only for hardware. So this wont work.
--
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 2/2] PCI: rockchip: Add quirk to disable RC's ASPM L0s
From: Rob Herring @ 2016-11-29 15:34 UTC (permalink / raw)
To: Shawn Lin
Cc: Bjorn Helgaas, linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:ARM/Rockchip SoC..., Wenrui Li, Brian Norris,
Jeffy Chen, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1479096666-112668-2-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Sun, Nov 13, 2016 at 10:11 PM, Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> Rockchip's RC outputs 100MHz reference clock but there are
> two methods for PHY to generate it.
>
> (1)One of them is to use system PLL to generate 100MHz clock and
> the PHY will relock it and filter signal noise then outputs the
> reference clock.
>
> (2)Another way is to share Soc's 24MHZ crystal oscillator with
> PHY and force PHY's DLL to generate 100MHz internally.
>
> When using case(2), the exit from L0s doesn't work fine occasionally
> due to the broken design of RC receiver's logical circuit. So even if
> we use extended-synch, it still fails for PHY to relock the bits from
> FTS sometimes. This will hang the system.
>
> Maybe we could argue that why not use case(1) to avoid it? The reason
> is that as we could see the reference clock is derived from system PLL
> and the path from it to PHY isn't so clean which means there are some
> noise introduced by power-domain and other buses can't be filterd out
> by PHY and we could see noise from the frequency spectrum by oscilloscope.
> This makes the TX compatibility test a little difficult to pass the spec.
> So case(1) and case(2) are both used indeed now. If using case(2), we
> should disable RC's L0s support, and that is why we need this property to
> indicate this quirk.
>
> Also after checking quirk.c, I noticed there is already a quirk for
> disabling L0s unconditionally, quirk_disable_aspm_l0s. But obviously we
> shouldn't do that as mentioned above that case(1) could still works fine
> with L0s.
>
> Reported-by: Jeffy Chen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Cc: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> ---
>
> Documentation/devicetree/bindings/pci/rockchip-pcie.txt | 2 ++
> drivers/pci/host/pcie-rockchip.c | 9 +++++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> index ba67b39..cfa44a7 100644
> --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> @@ -42,6 +42,8 @@ Required properties:
> Optional Property:
> - ep-gpios: contain the entry for pre-reset gpio
> - num-lanes: number of lanes to use
> +- quirk,aspm-no-l0s: RC won't support ASPM L0s. This property is needed if
quirk is not a vendor. Drop it.
> + using 24MHz OSC for RC's PHY.
> - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
> - vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe.
> - vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe.
--
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] iio: misc: add a generic regulator driver
From: Bartosz Golaszewski @ 2016-11-29 15:35 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Jonathan Cameron, Hartmut Knaack, Peter Meerwald-Stadler,
Rob Herring, Mark Rutland, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-devicetree, LKML, Kevin Hilman, Patrick Titiano,
Neil Armstrong
In-Reply-To: <44cce3d5-f65e-1a35-20a4-5eb9fda42312-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>:
> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote:
> [...]
>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>> new file mode 100644
>> index 0000000..147458f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>> @@ -0,0 +1,18 @@
>> +Industrial IO regulator device driver
>> +-------------------------------------
>> +
>> +This document describes the bindings for the iio-regulator - a dummy device
>> +driver representing a physical regulator within the iio framework.
>
> No bindings for drivers, only for hardware. So this wont work.
>
What about exporting regulator attributes analogous to the one in this
patch from the iio-core when a *-supply property is specified for a
node?
Thanks,
Bartosz
^ permalink raw reply
* Re: [PATCH v3 13/13] clocksource/drivers/rockchip_timer: Prevent ftrace recursion
From: Alexander Kochetkov @ 2016-11-29 15:36 UTC (permalink / raw)
To: Heiko Stübner
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Huang Tao,
Daniel Lezcano, LKML, Russell King,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Thomas Gleixner, LAK, Caesar Wang
In-Reply-To: <7837485.H9nfDmPu0F@diego>
Hello Heiko!
Thank you for patch review!
> 29 нояб. 2016 г., в 18:01, Heiko Stübner <heiko@sntech.de> написал(а):
>
> you introduced the issue yourself in patch 11/13. In general any patch should
> never leave the kernel in a worse state than it was before, so no patch should
> ever introduce known issues itself.
Agree.
> In that line of thought, don't patches 10+11 introduce warnings about unused
> functions as well when applied without patch 12?
7 - yes
10 - not
11 - yes
> 29 нояб. 2016 г., в 18:03, Heiko Stübner <heiko@sntech.de> написал(а):
>
> Then why do you need another patch to remove them and don't do that in the
> patch removing their respective usage?
To make 7 more readable. Overwise patch messed up and unreadable.
It’s hard to track what going on in the patch.
> Maybe merge them?
I'll merge all of them.
P.S.
here comment from another thead about the patches.
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/thread.html#470957
> 29 нояб. 2016 г., в 18:07, Robin Murphy <robin.murphy@arm.com> написал(а):
>
> 3288 (and probably anything newer) is irrelevant to this discussion, as
> it has the arch timer interface - that may be busted in other ways (such
> as not being correctly set up by firmware and not being always-on as it
> should), but frequency is not one of them. This only affects
> Cortex-A9/A5 based parts.
So I update comments for patches.
Looks, like I study archeology with my patches, as all new ARM chips not
affected by the problem anymore.
Regards,
Alexander.
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH] mfd: cpcap: Add minimal support
From: Tony Lindgren @ 2016-11-29 15:48 UTC (permalink / raw)
To: Rob Herring
Cc: Lee Jones, Samuel Ortiz, linux-kernel@vger.kernel.org, linux-omap,
devicetree@vger.kernel.org, Marcel Partap, Mark Rutland,
Michael Scott
In-Reply-To: <CAL_Jsq+8_O483raD97B8-ssaFGeVOPJcadyY4x7m0T64EbVA3g@mail.gmail.com>
* Rob Herring <robh+dt@kernel.org> [161129 07:20]:
> On Thu, Nov 24, 2016 at 2:59 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Wed, 23 Nov 2016, Tony Lindgren wrote:
> >
> >> * Lee Jones <lee.jones@linaro.org> [161121 03:43]:
> >> > On Fri, 18 Nov 2016, Tony Lindgren wrote:
> >> > > --- a/drivers/mfd/Makefile
> >> > > +++ b/drivers/mfd/Makefile
> >> > > @@ -97,6 +97,7 @@ obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o
> >> > > obj-$(CONFIG_MFD_CORE) += mfd-core.o
> >> > >
> >> > > obj-$(CONFIG_EZX_PCAP) += ezx-pcap.o
> >> > > +obj-$(CONFIG_MFD_CPCAP) += cpcap.o
> >> >
> >> > Who is the manufacturer?
> >>
> >> Hmm that I don't know. There seems to be both ST and TI versions
> >> of this chip manufactured for Motorola. So my guess is that it
> >> should be Motorola unless there's some similar catalog part
> >> available from ST used by others. If anybody has more info
> >> on this please let me know :)
> >
> > If this IP is shared amongst vendors, it usually means it was designed
> > by someone else? Synopsis perhaps?
>
> xCAP names originated from Motorola cellular group with parts (going
> back to analog/2G days) coming from Motorola Semi, TI, and ST it
> seems. All individually developed AFAIK.
OK thanks. Looking at the Motorola Linux kernel source, the child
device drivers do test for both revision and vendor and apply
different workarounds based on that. It also seems that CPCAP is
only used on Motorola devices.
So based on the above, we should call it motorola-cpcap with just
a secondary device tree compatible string for the STE part numbers.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH v2 07/13] net: ethernet: ti: cpts: rework initialization/deinitialization
From: Grygorii Strashko @ 2016-11-29 15:50 UTC (permalink / raw)
To: Richard Cochran
Cc: David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA, Mugunthan V N,
Sekhar Nori, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Murali Karicheri, Wingman Kwok
In-Reply-To: <20161129100737.GF3110-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
Hi Richard,
On 11/29/2016 04:07 AM, Richard Cochran wrote:
> On Mon, Nov 28, 2016 at 05:03:31PM -0600, Grygorii Strashko wrote:
>> +int cpts_register(struct cpts *cpts)
>> {
>> int err, i;
>>
>> - cpts->info = cpts_info;
>> - spin_lock_init(&cpts->lock);
>> -
>> - cpts->cc.read = cpts_systim_read;
>> - cpts->cc.mask = CLOCKSOURCE_MASK(32);
>> - cpts->cc_mult = mult;
>> - cpts->cc.mult = mult;
>> - cpts->cc.shift = shift;
>> -
>> INIT_LIST_HEAD(&cpts->events);
>> INIT_LIST_HEAD(&cpts->pool);
>> for (i = 0; i < CPTS_MAX_EVENTS; i++)
>> list_add(&cpts->pool_data[i].list, &cpts->pool);
>>
>> - cpts_clk_init(dev, cpts);
>> + clk_enable(cpts->refclk);
>> +
>> cpts_write32(cpts, CPTS_EN, control);
>> cpts_write32(cpts, TS_PEND_EN, int_enable);
>>
>> + cpts->cc.mult = cpts->cc_mult;
>
> It is not clear why you set cc.mult in a different place than
> cc.shift. That isn't logical, but maybe later patches make it
> clear...
cc.mult has to be reloaded to original value each time CPTS is registered(restarted)
as it can be modified by cpts_ptp_adjfreq().
While cc.shift is static.
>
>> timecounter_init(&cpts->tc, &cpts->cc, ktime_to_ns(ktime_get_real()));
>>
[...]
>> }
>> EXPORT_SYMBOL_GPL(cpts_unregister);
>>
>> +struct cpts *cpts_create(struct device *dev, void __iomem *regs,
>> + u32 mult, u32 shift)
>> +{
>> + struct cpts *cpts;
>> +
>> + if (!regs || !dev)
>> + return ERR_PTR(-EINVAL);
>
> There is no need for this test, as the caller will always pass valid
> pointers. (This isn't a user space library!)
>
ok
--
regards,
-grygorii
--
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 08/13] net: ethernet: ti: cpts: move dt props parsing to cpts driver
From: Grygorii Strashko @ 2016-11-29 15:54 UTC (permalink / raw)
To: Richard Cochran
Cc: David S. Miller, netdev, Mugunthan V N, Sekhar Nori, linux-kernel,
linux-omap, Rob Herring, devicetree, Murali Karicheri,
Wingman Kwok
In-Reply-To: <20161129101112.GG3110@localhost.localdomain>
On 11/29/2016 04:11 AM, Richard Cochran wrote:
> On Mon, Nov 28, 2016 at 05:03:32PM -0600, Grygorii Strashko wrote:
>> +static int cpts_of_parse(struct cpts *cpts, struct device_node *node)
>> +{
>> + int ret = -EINVAL;
>> + u32 prop;
>> +
>> + if (of_property_read_u32(node, "cpts_clock_mult", &prop))
>> + goto of_error;
>> + cpts->cc_mult = prop;
>
> Why not set cc.mult here at the same time?
The same reason as in prev patch - cpts->cc_mult is original/initial mult
value loaded from DT (or calculated), while cc.mult is dynamic value
which can be changed as part of freq adjustment.
>
>> +
>> + if (of_property_read_u32(node, "cpts_clock_shift", &prop))
>> + goto of_error;
>> + cpts->cc.shift = prop;
>> +
>> + return 0;
>> +
>> +of_error:
>> + dev_err(cpts->dev, "CPTS: Missing property in the DT.\n");
>> + return ret;
>> +}
>
--
regards,
-grygorii
^ permalink raw reply
* Re: [PATCH] of: Fix issue where code would fall through to error case.
From: Moritz Fischer @ 2016-11-29 15:55 UTC (permalink / raw)
To: Rob Herring
Cc: Frank Rowand, Moritz Fischer,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pantelis Antoniou, moritz-62aBmqa6xEOcmJEhUYGoYg,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_Jsq+eQYGq7ZtiQaerBk1SP=K1Wgd+b_2UGKFoRS4_s_8Fvg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob,
On Tue, Nov 29, 2016 at 09:06:08AM -0600, Rob Herring wrote:
> On Mon, Nov 28, 2016 at 9:30 AM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On 11/26/16 13:39, Frank Rowand wrote:
> >> On 11/23/16 13:58, Rob Herring wrote:
> >>> On Thu, Nov 17, 2016 at 6:10 PM, Moritz Fischer
> >>> <moritz.fischer.private-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>> On Thu, Nov 17, 2016 at 4:02 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>>> On 11/17/16 15:40, Frank Rowand wrote:
> >>>>>> On 11/17/16 15:25, Moritz Fischer wrote:
> >>>>>>> No longer fall through into the error case that prints out
> >>>>>>> an error if no error (err = 0) occurred.
> >>>>>>>
> >>>>>>> Fixes d9181b20a83(of: Add back an error message, restructured)
> >>>>>>> Signed-off-by: Moritz Fischer <moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org>
> >>>>>>> ---
> >>>>>>> drivers/of/resolver.c | 6 +++++-
> >>>>>>> 1 file changed, 5 insertions(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
> >>>>>>> index 783bd09..785076d 100644
> >>>>>>> --- a/drivers/of/resolver.c
> >>>>>>> +++ b/drivers/of/resolver.c
> >>>>>>> @@ -358,9 +358,13 @@ int of_resolve_phandles(struct device_node *overlay)
> >>>>>>>
> >>>>>>> err = update_usages_of_a_phandle_reference(overlay, prop, phandle);
> >>>>>>> if (err)
> >>>>>>> - break;
> >>>>>>> + goto err_out;
> >>>>>>> }
> >>>>>>>
> >>>>>>> + of_node_put(tree_symbols);
> >>>>>>> +
> >>>>>>> + return 0;
> >>>>>>> +
> >>>>>>> err_out:
> >>>>>>> pr_err("overlay phandle fixup failed: %d\n", err);
> >>>>>>> out:
> >>>>>>
> >>>>>> Thanks for catching that.
> >>>>>>
> >>>>>> Rob, please apply.
> >>>>>>
> >>>>>> Reviewed-by: Frank Rowand <frank.rowand-mEdOJwZ7QcZBDgjK7y7TUQ@public.gmane.org>
> >>>>>>
> >>>>>> -Frank
> >>>>>
> >>>>> On second thought, isn't the common pattern when clean up is needed for
> >>>>> both the no-error path and the error path something like:
> >>>>>
> >>>>>
> >>>>> out:
> >>>>> of_node_put(tree_symbols);
> >>>>> return err;
> >>>>>
> >>>>> err_out:
> >>>>> pr_err("overlay phandle fixup failed: %d\n", err);
> >>>>> goto out;
> >>>>> }
> >>>>>
> >>>>>
> >>>>> I don't have a strong opinion, whatever Rob wants to take is fine with me.
> >>>>
> >>>> Same here. I tried to avoid the jumping back part, but if that's the
> >>>> common pattern,
> >>>> I can submit a v2 doing that instead.
> >>>
> >>> Both are ugly. Just do:
> >>>
> >>> if (err)
> >>> pr_err(...);
> >>>
> >>> Rob
> >>
> >> Agreed. Thanks for the touch of sanity Rob.
> >>
> >> -Frank
> >
> > I succumbed to looking only at the few lines of code above and not the
> > fuller context of the file that the patch applies to.
> >
> > The proposed patch was fixing the problem that a normal completion
> > of the for loop was falling through into the err_out label. So what
> > looks cleaner ("if (err) pr_err(...)") is actually not correct.
>
> What!? The *only* problem was printing the error message in the err=0
> case. All that needs to be fixed is not doing that. If we do that,
> then we really only need 1 goto label.
I think you're right. Can you look at my v3 that I sent. I also tried to
fix cases where we can just do
return 0;
vs.
err = 0;
goto err
...
err:
of_node_put(NULL /*tree_symbols is NULL*/);
return err;
Thanks,
Moritz
--
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 v5 4/9] dt-bindings: iio: iio-mux: document iio-mux bindings
From: Peter Rosin @ 2016-11-29 15:56 UTC (permalink / raw)
To: linux-kernel
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, Arnd Bergmann, Greg Kroah-Hartman, linux-i2c,
devicetree, linux-iio, linux-doc
In-Reply-To: <1480414245-14034-5-git-send-email-peda@axentia.se>
On 2016-11-29 11:10, Peter Rosin wrote:
> +Example:
> + mux: mux-controller {
> + compatible = "mux-gpio";
> + #mux-control-cells = <0>;
> +
> + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
> + <&pioA 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + adc-mux {
> + compatible = "iio-mux";
> + io-channels = <&adc 0>;
> + io-channel-names = "parent";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mux-controls = <&mux>;
> +
> + sync@0 {
> + reg = <0>;
> + };
> +
> + in@1 {
> + reg = <1>;
> + };
> +
> + system-regulator@2 {
> + reg = <2>;
> + };
> + };
Hmmm, a more compact binding would be to just use an array of strings
instead of a list of children for the mux channels, and use the array
index as channel number, like so:
adc-mux {
compatible = "iio-mux";
io-channels = <&adc 0>;
io-channel-names = "parent";
mux-controls = <&mux>;
channels = "sync", "in", "system-regulator";
};
If you need to skip a low-number channel, you'd just put an empty string
for that channel. If you need to skip channels at the end, just stop
short.
Can anyone think of any reason to add anything to the channel nodes
that makes the string-array ineffective? If so, or if that comes up
later, it could be optional and in that case you could look for the
channels property first and then, if not present, iterate over child
nodes.
Opinions? I like it, it's a lot more compact...
Cheers,
Peter
^ permalink raw reply
* Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes
From: Peter Rosin @ 2016-11-29 16:02 UTC (permalink / raw)
To: Jonathan Cameron, Lars-Peter Clausen,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Hartmut Knaack,
Peter Meerwald-Stadler, Jonathan Corbet, Arnd Bergmann,
Greg Kroah-Hartman, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <d287dc3b-3605-d85d-1aa6-40f3bdcdc72c-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On 2016-11-27 13:00, Jonathan Cameron wrote:
> On 23/11/16 11:47, Peter Rosin wrote:
>> On 2016-11-22 21:58, Lars-Peter Clausen wrote:
>>> On 11/21/2016 02:17 PM, Peter Rosin wrote:
>>> [...]
>>>> I have a piece of hardware that is using the same 3 GPIO pins
>>>> to control four 8-way muxes. Three of them control ADC lines
>>>> to an ADS1015 chip with an iio driver, and the last one
>>>> controls the SDA line of an i2c bus. We have some deployed
>>>> code to handle this, but you do not want to see it or ever
>>>> hear about it. I'm not sure why I even mention it. Anyway,
>>>> the situation has nagged me to no end for quite some time.
>>>>
>>>> So, after first getting more intimate with the i2c muxing code
>>>> and later discovering the drivers/iio/inkern.c file and
>>>> writing a couple of drivers making use of it, I came up with
>>>> what I think is an acceptable solution; add a generic mux
>>>> controller driver (and subsystem) that is shared between all
>>>> instances, and combine that with an iio mux driver and a new
>>>> generic i2c mux driver. The new i2c mux I called "simple"
>>>> since it is only hooking the i2c muxing and the new mux
>>>> controller (much like the alsa simple card driver does for ASoC).
>>>
>>> While abstracting this properly is all nice and good and the way it should
>>> be done, but it also adds a lot of complexity and the devicetree adds a lot
>>> of restrictions on what can actually be represented.
>>
>> This is a characterization without any specifics. But is the
>> characterization true? You have two complaints, complexity
>> and restrictions with bindings.
>>
>>> There is a certain point where the fabric on a PCB becomes so complex that
>>> it deserves to be a device on its own (like the audio fabric drivers).
>>> Especially when the hardware is built with a certain application in mind and
>>> the driver is supposed to impose policy which reflects this application. The
>>> latter can often not properly be described with the primitives the
>>> devicetree can offer.
>>>
>>> And I think your setup is very borderline what can be done in a declarative
>>> way only and it adds a lot of complexity over a more imperative solution in
>>> form of a driver. I think it is worth investigating about having a driver
>>> that is specific to your fabric and handles the interdependencies of the
>>> discrete components.
>>
>> So, there are three "new" concepts:
>>
>> 1. Sticking a mux in front of an AD-converter. That's not all that
>> novel, nor complex. Quite the opposite, I'd say. In fact, I find it
>> a bit amazing that there is no in-kernel support for it.
> As ever first person who needs it and has the skills to write it gets to do it ;)
> Congratulations Peter ;)
>>
>> 2. Reusing the same GPIO-pins to drive different muxes. There are
>> obviously chips that work this way (as Jonathan pointed out) and
>> these will at some point get used in Linux devices. I guess they
>> already are used, but that people handle them in userspace. Or
>> something? If this is complex, which I question, it will still need
>> support at some point. At least that's what I believe.
>>
>> 3. Using the same GPIO pins to mux things handled by different
>> subsystems. Right, this is a bit crazy, and I'd rather not have this
>> requirement, but this HW is what it is so I'll need to handle it in
>> some way. It is also what stops me from falling back to a userspace
>> solution, which is probably connected to why #1 and #2 is not supported
>> by the kernel; everybody probably does muxing in userspace. Which is
>> not necessarily a good idea, nor how it's supposed to be done...
>>
>> So, the only thing that's out of the ordinary (as I see it), is #3.
>> The question that then needs an answer is how the in-kernel solution
>> for #1 and #2 would look if we do not consider #3.
>>
>> And I claim that the desired solution to #1 and #2 is pretty close
>> to my proposal.
>>
>> A. You do not want mux-controller drivers in every subsystem that
>> needs them.
> Agreed.
>>
>> B. You do not want every mux-consumer to know the specifics of how to
>> operate every kind of mux; there are muxes that are not controlled
>> with GPIO pins...
>>
>> C. When you implement muxing in a subsystem, there will in some cases
>> be a need to handle parallel muxing, where there is a need to share
>> mux-controllers.
>>
>> It just feels right to separate out the mux-controller and refer to
>> it from where a mux is needed. It solves #1 and #2. And, of course,
>> as a bonus #3 is also solved. But my bias is obvious.
>>
>> And that leads us to the restrictions with the bindings. And the same
>> thing happens; the solution for #2 also solves #3.
>>
>> So how do you refer to a mux-controller from where it's needed? My
>> first proposal used a dt phandle, for the second round I put them in
>> the parent node. It would be super if it was possible for the mux-
>> consumer to create the mux-controller device from the same dt
>> node that is already bound to the mux-consumer. The problem is that
>> the mux-consumer should not hard-code which mux-controller device it
>> should create. The best I can think of is some kind of 'mux-compatible'
>> attribute, that works like the standard 'compatible' attribute. That
>> would simplify the bindings for the normal case (#1) where the mux-
>> controller isn't shared (#2 and #3). Maybe it's possible to fix this
>> issue somehow? I simply don't know?
> As Lars stated, it's marginal. The question is not at what point do we
> 'have to' bother with a fabric driver, but rather at what point does it
> make a our lives easier.
>
> Take you nastiest mux case described earlier.
> The ideal would be to represent the ADC and 3 muxes as (approximately) a
> single ADC to userspace that just happens to have somewhere near 23 inputs.
>
> To do that in device tree we need to describe
>
> 1 The adc
> 2 The three muxes
> 3 The software representation to pull all of these back into a single device.
>
> That last part to my mind trips the balance to the point where a fabric driver
> would make sense. It's not complex. Just a few lines of code tying all the
> elements together without ending up with a fairly fiendish setup to describe in
> device tree.
>
> Also just wait until we have muxes stacked on muxes, with cross overs occuring.
> Some of the ASoC parts can actually have effective loops if you try all the mux
> combinations.
>
> So question is do we have a 'simple case description' in device tree or force
> fabric drivers everywhere? I think I'm in favour of the simple case - which handles
> one of your two uses nicely. The second one to do the the recombining of channels after
> the muxes, ends up looking to me like it needs a fabric driver.
>
> Note we are only talking about bindings vs code based description here. I agree
> entirely with the concept of a generic mux subsystem.
Ok, take the simple case - an adc with a mux in front of it.
We do not want to build a whole new iio-mux subsystem like the one under
i2c, so from iio we want to refer to the actual mux controller driver
which lives under the mux subsystem. Getting this far is what solves my
"second need" [2] from the v2 thread.
Agreed, doing this w/o a fabric driver spills the guts and it might be
cleaner to build a fabric driver that takes a reference to the dpot and
the mux controller and just knows the rest. In the end this fabric driver
requires two things to actually make a difference; some way to instantiate
drivers without the help of device-tree and some way make those drivers
only provide in-kernel access (and preferably it should hide the dpot from
userspace too, while at it).
But doing all that in a fabric driver is not going to change the fact that
the iio-mux driver is useful on its own. I bet someone else is going to
reuse it somewhere down the line. Which means that a fabric driver would
perhaps be nice for my "second need", but not critical, it works pretty
well to just piggyback on the general solution .
Over to my "first need" [1] from the v2 thread.
The above iio-mux driver handles the three muxed adc lines beautifully,
just refer all three iio-muxes to the same mux controller. Agreed, with
a fabric driver I could get one device with 25 channels instead of three
devices with 8 channels each plus one unmuxed line directly from the adc
device. However, that doesn't bother me at all, I may even think it is
preferable because otherwise I'd have to come up with some way to
identify which channel is which in that big 25-channel jungle. Another
drawback with having a fabric driver here is that it would need to be an
i2c-mux driver, because one of the key points of doing a fabric driver
for my first need was to hide the shared mux, right? Instead, I have the
new i2c-mux-simple driver that builds an i2c-mux using any mux controller
from the mux subsystem (something that may prove useful to others in the
future), which in my case is the same mux controller that also muxes the
three adc lines.
In short, doing fabric drivers buys me almost nothing besides having a
slightly more distinct device tree. All the components used to describe
this are either already accepted drivers or usable by others (at least
the way I see it).
Cheers,
Peter
[1] three adc lines and an i2c bus muxed with the same gpio pins
[2] mcp4561 dpot -> dpot-dac -> envelope-detector-adc -> iio-mux
--
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 v4 0/9] Implement clocksource for rockchip SoC using rockchip timer
From: Alexander Kochetkov @ 2016-11-29 16:14 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Thomas Gleixner, Heiko Stuebner, Mark Rutland, Rob Herring,
Russell King, Caesar Wang, Huang Tao, Daniel Lezcano,
Alexander Kochetkov
In-Reply-To: <1480343486-25539-1-git-send-email-al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hello,
This patch series contain:
- devicetree bindings clarification for rockchip timers
- dts files fixes for rk3228-evb, rk3229-evb and rk3188
- implementation of clocksource and sched clock for rockchip SoC
The clock supplying the arm-global-timer on the rk3188 is coming from the
the cpu clock itself and thus changes its rate everytime cpufreq adjusts
the cpu frequency making this timer unsuitable as a stable clocksource.
The rk3188, rk3288 and following socs share a separate timer block already
handled by the rockchip-timer driver. Therefore adapt this driver to also
be able to act as clocksource on rk3188.
In order to test clocksource you can run following commands and check
how much time it take in real. On rk3188 it take about ~45 seconds.
cpufreq-set -f 1.6GHZ
date; sleep 60; date
rk3288 (and probably anything newer) is irrelevant to this patch,
as it has the arch timer interface. This patch may be usefull
for Cortex-A9/A5 based parts.
Regards,
Alexander.
This is try 4. Please discard all v1, v2, v3 patches.
Changes in v4:
merged 7 and 8 from series 3
merged 10, 11, 12, 13 from series 3
fixed commit message
Changes in v3:
added patches:
ARM: dts: rockchip: disable arm-global-timer for rk3188
clocksource/drivers/rockchip_timer: Prevent ftrace recursion
devicetree v1 patches:
https://patchwork.ozlabs.org/patch/699019/
https://patchwork.ozlabs.org/patch/699020/
kernel v1 patches:
https://patchwork.kernel.org/patch/9443975/
https://patchwork.kernel.org/patch/9443971/
https://patchwork.kernel.org/patch/9443959/
https://patchwork.kernel.org/patch/9443963/
https://patchwork.kernel.org/patch/9443979/
https://patchwork.kernel.org/patch/9443989/
https://patchwork.kernel.org/patch/9443987/
https://patchwork.kernel.org/patch/9443977/
https://patchwork.kernel.org/patch/9443991/
Alexander Kochetkov (9):
dt-bindings: clarify compatible property for rockchip timers
ARM: dts: rockchip: update compatible property for rk3228 timer
ARM: dts: rockchip: update compatible property for rk3229 timer
ARM: dts: rockchip: add timer entries to rk3188 SoC
ARM: dts: rockchip: disable arm-global-timer for rk3188
clocksource/drivers/rockchip_timer: split bc_timer into rk_timer and
rk_clock_event_device
clocksource/drivers/rockchip_timer: low level routines take rk_timer
as parameter
clocksource/drivers/rockchip_timer: move TIMER_INT_UNMASK out of
rk_timer_enable()
clocksource/drivers/rockchip_timer: implement clocksource timer
.../bindings/timer/rockchip,rk-timer.txt | 12 +-
arch/arm/boot/dts/rk3188.dtsi | 17 ++
arch/arm/boot/dts/rk3228-evb.dts | 4 +
arch/arm/boot/dts/rk3229-evb.dts | 4 +
drivers/clocksource/rockchip_timer.c | 207 +++++++++++++++-----
5 files changed, 190 insertions(+), 54 deletions(-)
--
1.7.9.5
--
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 v4 1/9] dt-bindings: clarify compatible property for rockchip timers
From: Alexander Kochetkov @ 2016-11-29 16:14 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-arm-kernel, linux-rockchip
Cc: Mark Rutland, Huang Tao, Heiko Stuebner, Alexander Kochetkov,
Daniel Lezcano, Russell King, Rob Herring, Thomas Gleixner,
Caesar Wang
In-Reply-To: <1480436092-10728-1-git-send-email-al.kochet@gmail.com>
Make all properties description in form '"rockchip,<chip>-timer",
"rockchip,rk3288-timer"' for all chips found in linux kernel.
Suggested-by: Heiko Stübner <heiko@sntech.de>
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
.../bindings/timer/rockchip,rk-timer.txt | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
index a41b184..16a5f45 100644
--- a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
+++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
@@ -1,9 +1,15 @@
Rockchip rk timer
Required properties:
-- compatible: shall be one of:
- "rockchip,rk3288-timer" - for rk3066, rk3036, rk3188, rk322x, rk3288, rk3368
- "rockchip,rk3399-timer" - for rk3399
+- compatible: should be:
+ "rockchip,rk3036-timer", "rockchip,rk3288-timer": for Rockchip RK3036
+ "rockchip,rk3066-timer", "rockchip,rk3288-timer": for Rockchip RK3066
+ "rockchip,rk3188-timer", "rockchip,rk3288-timer": for Rockchip RK3188
+ "rockchip,rk3228-timer", "rockchip,rk3288-timer": for Rockchip RK3228
+ "rockchip,rk3229-timer", "rockchip,rk3288-timer": for Rockchip RK3229
+ "rockchip,rk3288-timer": for Rockchip RK3288
+ "rockchip,rk3368-timer", "rockchip,rk3288-timer": for Rockchip RK3368
+ "rockchip,rk3399-timer": for Rockchip RK3399
- reg: base address of the timer register starting with TIMERS CONTROL register
- interrupts: should contain the interrupts for Timer0
- clocks : must contain an entry for each entry in clock-names
--
1.7.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 2/9] ARM: dts: rockchip: update compatible property for rk3228 timer
From: Alexander Kochetkov @ 2016-11-29 16:14 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-arm-kernel, linux-rockchip
Cc: Thomas Gleixner, Heiko Stuebner, Mark Rutland, Rob Herring,
Russell King, Caesar Wang, Huang Tao, Daniel Lezcano,
Alexander Kochetkov
In-Reply-To: <1480436092-10728-1-git-send-email-al.kochet@gmail.com>
Property set to '"rockchip,rk3228-timer", "rockchip,rk3288-timer"'
to match devicetree bindings.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
arch/arm/boot/dts/rk3228-evb.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/rk3228-evb.dts b/arch/arm/boot/dts/rk3228-evb.dts
index 904668e..38eab87 100644
--- a/arch/arm/boot/dts/rk3228-evb.dts
+++ b/arch/arm/boot/dts/rk3228-evb.dts
@@ -70,3 +70,7 @@
&uart2 {
status = "okay";
};
+
+&timer {
+ compatible = "rockchip,rk3228-timer", "rockchip,rk3288-timer";
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 3/9] ARM: dts: rockchip: update compatible property for rk3229 timer
From: Alexander Kochetkov @ 2016-11-29 16:14 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Mark Rutland, Huang Tao, Heiko Stuebner, Alexander Kochetkov,
Daniel Lezcano, Russell King, Rob Herring, Thomas Gleixner,
Caesar Wang
In-Reply-To: <1480436092-10728-1-git-send-email-al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Property set to '"rockchip,rk3229-timer", "rockchip,rk3288-timer"'
to match devicetree bindings.
Signed-off-by: Alexander Kochetkov <al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/rk3229-evb.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/rk3229-evb.dts b/arch/arm/boot/dts/rk3229-evb.dts
index b6a1203..6629769 100644
--- a/arch/arm/boot/dts/rk3229-evb.dts
+++ b/arch/arm/boot/dts/rk3229-evb.dts
@@ -88,3 +88,7 @@
&uart2 {
status = "okay";
};
+
+&timer {
+ compatible = "rockchip,rk3229-timer", "rockchip,rk3288-timer";
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 4/9] ARM: dts: rockchip: add timer entries to rk3188 SoC
From: Alexander Kochetkov @ 2016-11-29 16:14 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Mark Rutland, Huang Tao, Heiko Stuebner, Alexander Kochetkov,
Daniel Lezcano, Russell King, Rob Herring, Thomas Gleixner,
Caesar Wang
In-Reply-To: <1480436092-10728-1-git-send-email-al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The patch add two timers to all rk3188 based boards.
The first timer is from alive subsystem and it act as a backup
for the local timers at sleep time. It act the same as other
SoC rockchip timers already present in kernel.
The second timer is from CPU subsystem and act as replacement
for the arm-global-timer clocksource and sched clock. It run
at stable frequency 24MHz.
Signed-off-by: Alexander Kochetkov <al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/rk3188.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
index 31f81b2..0dc52fe 100644
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@ -106,6 +106,22 @@
};
};
+ timer3: timer@2000e000 {
+ compatible = "rockchip,rk3188-timer", "rockchip,rk3288-timer";
+ reg = <0x2000e000 0x20>;
+ interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_TIMER3>, <&cru PCLK_TIMER3>;
+ clock-names = "timer", "pclk";
+ };
+
+ timer6: timer@200380a0 {
+ compatible = "rockchip,rk3188-timer", "rockchip,rk3288-timer";
+ reg = <0x200380a0 0x20>;
+ interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_TIMER6>, <&cru PCLK_TIMER0>;
+ clock-names = "timer", "pclk";
+ };
+
i2s0: i2s@1011a000 {
compatible = "rockchip,rk3188-i2s", "rockchip,rk3066-i2s";
reg = <0x1011a000 0x2000>;
--
1.7.9.5
^ 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