* Re: [PATCH] clk: Provide dummy of_clk_get_from_provider() for compile-testing
From: Geert Uytterhoeven @ 2017-04-27 12:43 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Michael Turquette, Stephen Boyd, Russell King, Rob Herring,
Mark Rutland, linux-clk,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, John Crispin
In-Reply-To: <1493141328-28201-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
On Tue, Apr 25, 2017 at 7:28 PM, Geert Uytterhoeven
<geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> wrote:
> When CONFIG_ON=n, dummies are provided for of_clk_get() and
> of_clk_get_by_name(), but not for of_clk_get_from_provider().
>
> Provide a dummy for the latter, to improve the ability to do
> compile-testing.
>
> Fixes: 766e6a4ec602d0c1 ("clk: add DT clock binding support")
> Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
> ---
> include/linux/clk.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index e9d36b3e49de5b1b..3ed97abb5cbb7f94 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -539,6 +539,10 @@ static inline struct clk *of_clk_get_by_name(struct device_node *np,
> {
> return ERR_PTR(-ENOENT);
> }
> +static inline struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
> +{
> + return ERR_PTR(-ENOENT);
> +}
> #endif
0day reported an issue with arch/mips/lantiq/clk.c, which defines its own
dummy version:
| arch/mips//lantiq/clk.c:163:13: error: redefinition of
'of_clk_get_from_provider'
I will add its removal to my v2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver
From: Eugeniy Paltsev @ 2017-04-27 13:21 UTC (permalink / raw)
To: andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
Cc: vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Alexey.Brodkin-HKixBCOQz3hWk0Htik3J/w@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1493219075.24567.211.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Wed, 2017-04-26 at 18:04 +0300, Andy Shevchenko wrote:
> On Tue, 2017-04-25 at 21:12 +0300, Andy Shevchenko wrote:
> > On Tue, 2017-04-25 at 15:16 +0000, Eugeniy Paltsev wrote:
> > > On Mon, 2017-04-24 at 19:56 +0300, Andy Shevchenko wrote:
> > > > On Mon, 2017-04-24 at 15:55 +0000, Eugeniy Paltsev wrote:
> > > > Descriptor is active until terminate_all() is called or new
> > > > descriptor
> > > > is supplied. So, the caller has a quite time to check on it.
> > > >
> > > > So, what's wrong on it by your opinion?
> > >
> > > Hmm, this looks OK. (In my example (hsu/hsu.c driver) error
> > > descriptors
> > > are not freed even after terminate_all is called)
> >
> > If it's active it will be freed.
> > Otherwise caller should check somewhere that descriptor fails.
> >
> > But actually this is fragile and we need to monitor failed
> > descriptors.
> > Thanks for reporting.
> >
> > >
> > > > Of course, if you want to keep by some reason (should be stated
> > > > what
> > > > the reason in comment) erred descriptors, you can do that.
> > >
> > > So, I'll create desc_error list and store failed descriptors in
> > > this
> > > list until terminate_all() is called.
> > > Is it OK implementation?
> >
> > Nope, we need to amend virt-chan API for that. I'm on it. Will send
> > a series soon.
>
> I have to correct what I wrote before.
>
> We have two options:
> a) one I proposed above;
> b) move descriptor to complete list and call complete callback with
> result.
>
> So, it looks like the b) variant is what is done already in 4 (did I
> calculate correctly?) drivers and respective users.
In my opinion we should call error descriptor complete callback.
But I don't think we should move error descriptor to desc_completed
list.
When descriptor following our error descriptor will be completed
successfully vchan tasklet will be called.
So all descriptors from desc_completed list will be freed (including
our error descriptor)
We'll lost information about error descriptors and we'll not be able to
return correct status from dma_async_is_tx_complete().
In my opinion, we should create desc_error list.
When we get error we'll move descriptor to desc_error list and call
complete callback.
--
Eugeniy Paltsev
^ permalink raw reply
* Re: [PATCH v5 01/10] arm64: allwinner: a64: enable RSB on A64
From: Maxime Ripard @ 2017-04-27 13:28 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Thomas Gleixner, Rob Herring, Chen-Yu Tsai, Lee Jones,
Liam Girdwood, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170426152023.41567-2-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]
On Wed, Apr 26, 2017 at 11:20:14PM +0800, Icenowy Zheng wrote:
> Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
>
> Add it and its pinmux.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> ---
> Changes in v2:
> - Removed bonus properties in pio node.
> - Added Chen-Yu's ACK.
>
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index c7f669f5884f..05ec9fc5e81f 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -422,6 +422,25 @@
> #gpio-cells = <3>;
> interrupt-controller;
> #interrupt-cells = <3>;
> +
> + r_rsb_pins: rsb@0 {
> + pins = "PL0", "PL1";
> + function = "s_rsb";
> + };
> + };
> +
> + r_rsb: rsb@1f03400 {
> + compatible = "allwinner,sun8i-a23-rsb";
> + reg = <0x01f03400 0x400>;
> + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&r_ccu 6>;
Please use the defines here..
> + clock-frequency = <3000000>;
> + resets = <&r_ccu 2>;
And here.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC 0/5] arm64: dts: renesas: Break out common board support
From: Geert Uytterhoeven @ 2017-04-27 13:32 UTC (permalink / raw)
To: Simon Horman
Cc: Geert Uytterhoeven, Magnus Damm, Kuninori Morimoto,
Yoshihiro Shimoda, Rob Herring, Mark Rutland, Linux-Renesas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Vladimir Barinov
In-Reply-To: <CAMuHMdXbe=rkeS+-teg7nqbjULWY0_5pBO1XEzCGdYA4gB57oA@mail.gmail.com>
Hi Simon,
On Wed, Apr 26, 2017 at 10:11 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> CC Vladimir (which I forgot to CC initially, sorry for that)
>
> On Wed, Apr 26, 2017 at 10:06 AM, Simon Horman <horms@verge.net.au> wrote:
>> On Fri, Apr 21, 2017 at 02:55:16PM +0200, Geert Uytterhoeven wrote:
>>> The Renesas Salvator-X and ULCB development board can be equipped with
>>> either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
>>> use separate DTBs, but currently there's no sharing of board-specific
>>> devices in DTS.
>>>
>>> This series reduces duplication by extracting common board support into
>>> their own .dtsi files. As the level of support varies across boards and
>>> SoCs, this requires the addition of a few external clocks and
>>> placeholder devices on R-Car M3-W, so the common board support DTS can
>>> refer to them.
>>>
>>> - Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
>>> M3-W, which are present in r8a7795.dtsi, and used in
>>> r8a7795-salvator-x.dts,
>>> - RFC patch 3 adds placeholders for devices that are not yet supported
>>> and/or tested on R-Car M3-W, but used on R-Car H3,
>>> - RFC patch 4 extracts common Salvator-X board support,
>>> - RFC patch 5 extracts common ULCB board support.
>>>
>>> For R-Car H3 based boards, there are no functional changes.
>>> For R-Car M3-W based boards, some new devices are now described in DT.
>>>
>>> Dependencies:
>>> - renesas-devel-20170420-v4.11-rc7,
>>> - Patches 1 and 2 can be applied as-is,
>>> - Patches 4 and 5 depend on "[PATCH 0/8] arm64: dts: renesas: Break
>>> out R-Car H3 and M3-W SiP"
>>> (http://www.spinics.net/lists/devicetree/msg173820.html).
>>>
>>> DTB changes have been inspected using scripts/dtc/dtx_diff.
>>> This has been tested on Salvator-X (both H3 and M3-W).
>>> This has not been tested on H3ULCB and M3ULCB due to lack of hardware.
>>>
>>> Thanks for your comments!
>>
>> Thanks for tackling this important problem. I have looked over the changes
>> and they seem nice to me. I would, however, be more comfortable applying
>> them if they were rested on the ULCB boards.
>
> tested?
>
> I've pushed a branch for testing to topic/rcar3-dtsi-sharing in
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
I managed to test it on the new H3ULCB and M3ULCB baords in Magnus' farm.
No issues detected.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver
From: Andy Shevchenko @ 2017-04-27 13:33 UTC (permalink / raw)
To: Eugeniy Paltsev, Lars-Peter Clausen
Cc: vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Alexey.Brodkin-HKixBCOQz3hWk0Htik3J/w@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1493299300.25985.17.camel-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Thu, 2017-04-27 at 13:21 +0000, Eugeniy Paltsev wrote:
> On Wed, 2017-04-26 at 18:04 +0300, Andy Shevchenko wrote:
> > On Tue, 2017-04-25 at 21:12 +0300, Andy Shevchenko wrote:
> > > On Tue, 2017-04-25 at 15:16 +0000, Eugeniy Paltsev wrote:
> > > > On Mon, 2017-04-24 at 19:56 +0300, Andy Shevchenko wrote:
> > > > > On Mon, 2017-04-24 at 15:55 +0000, Eugeniy Paltsev wrote:
> > > > Hmm, this looks OK. (In my example (hsu/hsu.c driver) error
> > > > descriptors
> > > > are not freed even after terminate_all is called)
> > >
> > > If it's active it will be freed.
> > > Otherwise caller should check somewhere that descriptor fails.
> > >
> > > But actually this is fragile and we need to monitor failed
> > > descriptors.
> > > Thanks for reporting.
> > >
> > > >
> > > > > Of course, if you want to keep by some reason (should be
> > > > > stated
> > > > > what
> > > > > the reason in comment) erred descriptors, you can do that.
> > > >
> > > > So, I'll create desc_error list and store failed descriptors in
> > > > this
> > > > list until terminate_all() is called.
> > > > Is it OK implementation?
> > >
> > > Nope, we need to amend virt-chan API for that. I'm on it. Will
> > > send
> > > a series soon.
> >
> > I have to correct what I wrote before.
> >
> > We have two options:
> > a) one I proposed above;
> > b) move descriptor to complete list and call complete callback with
> > result.
> >
> > So, it looks like the b) variant is what is done already in 4 (did I
> > calculate correctly?) drivers and respective users.
>
> In my opinion we should call error descriptor complete callback.
> But I don't think we should move error descriptor to desc_completed
> list.
>
> When descriptor following our error descriptor will be completed
> successfully vchan tasklet will be called.
> So all descriptors from desc_completed list will be freed (including
> our error descriptor)
> We'll lost information about error descriptors and we'll not be able
> to
> return correct status from dma_async_is_tx_complete().
While I more agree on the point that we better to have explicit list of
failed descriptors, here is another point that user (which is interested
in error checking) has to provide callback_result instead of callback.
> In my opinion, we should create desc_error list.
> When we get error we'll move descriptor to desc_error list and call
> complete callback.
Vinod, Lars, others, what is(are) your opinion(s)?
--
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3] NFC: trf7970a: Correct register settings for 27MHz clock
From: Geoff Lansberry @ 2017-04-27 14:41 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
sameo-VuQAYsv1563Yd54FQh9/CA
Cc: kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-nfc-hn68Rpc1hR1g9hUCZPvPmw,
devicetree-u79uwXL29TY76Z2rM5mHXA, mgreer-luAo+O/VEmrlveNOaEYElw,
justin-R+k406RtEhcAvxtiuMwx3w, colin.king-Z7WLFzj8eWMS+FvcfC7Uqw,
wharms-fPG8STNUNVg, Geoff Lansberry
In prior commits the selected clock frequency does not propagate
correctly to what is written the the TRF7970A_MODULATOR_SYS_CLK_CTRL
register.
Signed-off-by: Geoff Lansberry <geoff-R+k406RtEhcAvxtiuMwx3w@public.gmane.org>
---
drivers/nfc/trf7970a.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index 6ed5d7e..f7fee7d 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -2067,6 +2067,13 @@ static int trf7970a_probe(struct spi_device *spi)
return -EINVAL;
}
+ if (clk_freq == TRF7970A_27MHZ_CLOCK_FREQUENCY) {
+ trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_27MHZ;
+ dev_dbg(trf->dev, "trf7970a configured for 27MHz crystal\n");
+ } else {
+ trf->modulator_sys_clk_ctrl = 0;
+ }
+
ret = devm_request_threaded_irq(trf->dev, spi->irq, NULL,
trf7970a_irq,
IRQF_TRIGGER_RISING | IRQF_ONESHOT,
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] [media] mtk-mdp: Fix g_/s_selection capture/compose logic
From: Stanimir Varbanov @ 2017-04-27 14:42 UTC (permalink / raw)
To: Minghsiu Tsai, Hans Verkuil, daniel.thompson, Rob Herring,
Mauro Carvalho Chehab, Matthias Brugger, Daniel Kurtz,
Pawel Osciak, Houlong Wei
Cc: srv_heupstream, Eddie Huang, Yingjoe Chen, Wu-Cheng Li,
devicetree, linux-kernel, linux-arm-kernel, linux-media,
linux-mediatek
In-Reply-To: <1492057130-1194-1-git-send-email-minghsiu.tsai@mediatek.com>
Hi,
On 04/13/2017 07:18 AM, Minghsiu Tsai wrote:
> From: Daniel Kurtz <djkurtz@chromium.org>
>
> Experiments show that the:
> (1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT
> (2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets
>
> Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
>
> ---
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> index 13afe48..8ab7ca0 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> @@ -837,12 +837,12 @@ static int mtk_mdp_m2m_g_selection(struct file *file, void *fh,
> struct mtk_mdp_ctx *ctx = fh_to_ctx(fh);
> bool valid = false;
>
> - if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
> - if (mtk_mdp_is_target_compose(s->target))
> - valid = true;
> - } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> if (mtk_mdp_is_target_crop(s->target))
> valid = true;
> + } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> + if (mtk_mdp_is_target_compose(s->target))
> + valid = true;
> }
Using MPLANE formats in g/s_selection violates the v4l2 spec. See [1].
<snip>
--
regards,
Stan
[1]
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-g-selection.html
^ permalink raw reply
* Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
From: Andy Shevchenko @ 2017-04-27 14:56 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Linus Walleij, geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
Laurent Pinchart, chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ,
Rob Herring, Mark Rutland, Russell King - ARM Linux,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1493281194-5200-2-git-send-email-jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
On Thu, Apr 27, 2017 at 11:19 AM, Jacopo Mondi
<jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org> wrote:
> Add bi-directional and output-enable pin configuration properties.
>
> bi-directional allows to specify when a pin shall operate in input and
> output mode at the same time. This is particularly useful in platforms
> where input and output buffers have to be manually enabled.
>
> output-enable is just syntactic sugar to specify that a pin shall
> operate in output mode, ignoring the provided argument.
> This pairs with input-enable pin configuration option.
For me it looks like you are trying to alias open-drain + bias or
alike. Don't actually see the benefit of it.
> Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt | 2 ++
> drivers/pinctrl/pinconf-generic.c | 3 +++
> include/linux/pinctrl/pinconf-generic.h | 3 +++
> 3 files changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> index bf3f7b0..f2ed458 100644
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> @@ -222,6 +222,7 @@ bias-bus-hold - latch weakly
> bias-pull-up - pull up the pin
> bias-pull-down - pull down the pin
> bias-pull-pin-default - use pin-default pull state
> +bi-directional - pin supports simultaneous input/output operations
> drive-push-pull - drive actively high and low
> drive-open-drain - drive with open drain
> drive-open-source - drive with open source
> @@ -234,6 +235,7 @@ input-debounce - debounce mode with debound time X
> power-source - select between different power supplies
> low-power-enable - enable low power mode
> low-power-disable - disable low power mode
> +output-enable - enable output on pin regardless of output value
> output-low - set the pin to output mode with low level
> output-high - set the pin to output mode with high level
> slew-rate - set the slew rate
> diff --git a/drivers/pinctrl/pinconf-generic.c b/drivers/pinctrl/pinconf-generic.c
> index ce3335a..03e6808 100644
> --- a/drivers/pinctrl/pinconf-generic.c
> +++ b/drivers/pinctrl/pinconf-generic.c
> @@ -35,6 +35,7 @@ static const struct pin_config_item conf_items[] = {
> PCONFDUMP(PIN_CONFIG_BIAS_PULL_PIN_DEFAULT,
> "input bias pull to pin specific state", NULL, false),
> PCONFDUMP(PIN_CONFIG_BIAS_PULL_UP, "input bias pull up", NULL, false),
> + PCONFDUMP(PIN_CONFIG_BIDIRECTIONAL, "bi-directional pin operations", NULL, false),
> PCONFDUMP(PIN_CONFIG_DRIVE_OPEN_DRAIN, "output drive open drain", NULL, false),
> PCONFDUMP(PIN_CONFIG_DRIVE_OPEN_SOURCE, "output drive open source", NULL, false),
> PCONFDUMP(PIN_CONFIG_DRIVE_PUSH_PULL, "output drive push pull", NULL, false),
> @@ -160,6 +161,7 @@ static const struct pinconf_generic_params dt_params[] = {
> { "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 1 },
> { "bias-pull-pin-default", PIN_CONFIG_BIAS_PULL_PIN_DEFAULT, 1 },
> { "bias-pull-down", PIN_CONFIG_BIAS_PULL_DOWN, 1 },
> + { "bi-directional", PIN_CONFIG_BIDIRECTIONAL, 1 },
> { "drive-open-drain", PIN_CONFIG_DRIVE_OPEN_DRAIN, 0 },
> { "drive-open-source", PIN_CONFIG_DRIVE_OPEN_SOURCE, 0 },
> { "drive-push-pull", PIN_CONFIG_DRIVE_PUSH_PULL, 0 },
> @@ -172,6 +174,7 @@ static const struct pinconf_generic_params dt_params[] = {
> { "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
> { "low-power-disable", PIN_CONFIG_LOW_POWER_MODE, 0 },
> { "low-power-enable", PIN_CONFIG_LOW_POWER_MODE, 1 },
> + { "output-enable", PIN_CONFIG_OUTPUT, 1, },
> { "output-high", PIN_CONFIG_OUTPUT, 1, },
> { "output-low", PIN_CONFIG_OUTPUT, 0, },
> { "power-source", PIN_CONFIG_POWER_SOURCE, 0 },
> diff --git a/include/linux/pinctrl/pinconf-generic.h b/include/linux/pinctrl/pinconf-generic.h
> index 7620eb1..279e3c5 100644
> --- a/include/linux/pinctrl/pinconf-generic.h
> +++ b/include/linux/pinctrl/pinconf-generic.h
> @@ -42,6 +42,8 @@
> * @PIN_CONFIG_BIAS_PULL_UP: the pin will be pulled up (usually with high
> * impedance to VDD). If the argument is != 0 pull-up is enabled,
> * if it is 0, pull-up is total, i.e. the pin is connected to VDD.
> + * @PIN_CONFIG_BIDIRECTIONAL: the pin will be configured to allow simultaneous
> + * input and output operations.
> * @PIN_CONFIG_DRIVE_OPEN_DRAIN: the pin will be driven with open drain (open
> * collector) which means it is usually wired with other output ports
> * which are then pulled up with an external resistor. Setting this
> @@ -96,6 +98,7 @@ enum pin_config_param {
> PIN_CONFIG_BIAS_PULL_DOWN,
> PIN_CONFIG_BIAS_PULL_PIN_DEFAULT,
> PIN_CONFIG_BIAS_PULL_UP,
> + PIN_CONFIG_BIDIRECTIONAL,
> PIN_CONFIG_DRIVE_OPEN_DRAIN,
> PIN_CONFIG_DRIVE_OPEN_SOURCE,
> PIN_CONFIG_DRIVE_PUSH_PULL,
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
--
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 v4 1/2] of: per-file dtc compiler flags
From: Masahiro Yamada @ 2017-04-27 15:09 UTC (permalink / raw)
To: Frank Rowand
Cc: Rob Herring, Stephen Boyd, Michal Marek,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List,
Linux Kbuild mailing list
In-Reply-To: <1493165394-29367-2-git-send-email-frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-04-26 9:09 GMT+09:00 <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> From: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
>
> The dtc compiler version that adds initial support was available
> in 4.11-rc1. Add the ability to set an additional dtc compiler
> flag is needed by overlays.
>
> Signed-off-by: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
> ---
Acked-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver
From: Eugeniy Paltsev @ 2017-04-27 15:34 UTC (permalink / raw)
To: andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
Cc: vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Alexey.Brodkin-HKixBCOQz3hWk0Htik3J/w@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1493143941.24567.196.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2555 bytes --]
On Tue, 2017-04-25 at 21:12 +0300, Andy Shevchenko wrote:
> On Tue, 2017-04-25 at 15:16 +0000, Eugeniy Paltsev wrote:
> > On Mon, 2017-04-24 at 19:56 +0300, Andy Shevchenko wrote:
> > > On Mon, 2017-04-24 at 15:55 +0000, Eugeniy Paltsev wrote:
> > > > Hi,
> > > > On Fri, 2017-04-21 at 18:13 +0300, Andy Shevchenko wrote:
> > > > > On Fri, 2017-04-21 at 14:29 +0000, Eugeniy Paltsev wrote:
> > > > > > On Tue, 2017-04-18 at 15:31 +0300, Andy Shevchenko wrote:
> > > > > > > On Fri, 2017-04-07 at 17:04 +0300, Eugeniy Paltsev wrote:
> > > > This IP can be (ans is) configured with small block size.
> > > > (note, that I am not saying about runtime HW configuration)
> > > >
> > > > And there is opportunity what we can't use sg_list directly and
> > > > need
> > > > to
> > > > split sg_list to a smaller chunks.
> > >
> > > That's what I have referred quite ago. The driver should provide
> > > an
> > > interface to tell potential caller what maximum block (number of
> > > items
> > > with given bus width) it supports.
> > >
> > > We have struct dma_parms in struct device, but what we actually
> > > need
> > > is
> > > to support similar on per channel basis in DMAengine framework.
> > >
> > > So, instead of working around this I recommend either to
> > > implement
> > > it
> > > properly or rely on the fact that in the future someone
> > > eventually
> > > does that for you.
> > >
> > > Each driver which has this re-splitting mechanism should be
> > > cleaned
> > > up and refactored.
> >
> > I still can't see any pros of this implementation.
> > There is no performance profit: we anyway need to re-splitt sg_list
> > (but now in dma-user driver instead of dma driver)
--->---
> > If we want to use same descriptors several times we just can use
> > DMA_CTRL_REUSE option - the descriptors will be created one time
> > and re-splitting will be Ñompleted only one time.
>
> There are two type of descriptors: SW and HW. That flag about SW
> descriptor, so, it in most cases has nothing to do with the actual
> entry size.
Hmm, I checked all virt-dma code attentively and I don't see this
limitation.
The only existing limitation I can see is that we can use
DMA_CTRL_REUSE only for channels supporting slave transfers. (But it is
irrelevant to our discussion)
So, we can use DMA_CTRL_REUSE for both HW/SW descriptor types.
--
 Eugeniy PaltsevN‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: Document STM32 I2S bindings
From: Olivier MOYSAN @ 2017-04-27 15:57 UTC (permalink / raw)
To: Mark Brown
Cc: mark.rutland@arm.com, Rob Herring, alsa-devel@alsa-project.org,
Alexandre TORGUE, devicetree@vger.kernel.org, Arnaud POULIQUEN,
tiwai@suse.com, lgirdwood@gmail.com, mcoquelin.stm32@gmail.com,
linux-arm-kernel@lists.infradead.org, Benjamin GAIGNARD
In-Reply-To: <20170426161553.oc5pozga53ttypyq@sirena.org.uk>
Hello Mark,
On 04/26/2017 06:15 PM, Mark Brown wrote:
> On Thu, Apr 13, 2017 at 08:01:34AM +0000, Olivier MOYSAN wrote:
>
>> 1) 2 static dais NOT exclusive
>> - dai tx
>> - dai rx
>> The IP exhibits a mode register, where you select mode TX, RX or FD.
>> There are 2 two options to manage this register.
>> option 1:
>> start first channel with mode RX or TX
>> when second channel is started, mode has to be changed to FD.
>> Transfers have to be stopped before changing configuration
>> registers, so this leads to cuts in audio stream.
>> option 2:
>> start a first channel with mode FD.
>> In this case, we may have unpredictable behavior for the stream
>> which is not already started. probably underrun/overrun.
>> So, this solution rises problem for full-duplex management.
>
>> 2) 3 static dais exclusive
>> - dai tx
>> - dai rx
>> - dai rx-tx (fd)
>> This is the current implementation.
>> The choice of the dai is done at probe time. It is provided by DT
>> through sound-dai parameter.
>> When dai fd is selected, after starting first stream, we assume that
>> second stream will be started. In this case we wait for second stream
>> to be available before enabling IP and starting transfers.
>
>> 3) 1 dynamic dai
>> - dai rx or tx or fd (according to dma conf in IP node)
>> Here the driver exposes only a single dai constructed from dma
>> configuration provided by IP DT node.
>> This allows to get ride of sound-dai parameter.
>
> None of these options reflect how normal I2S controllers present
> themselves in DT. To repeat, you should present a single bidirectional
> DAI for the single physical bidirectional I2S controller that your
> hardware has.
>
> If it's not possible to figure out a way to make the controller support
> simultaneous playback and record with the two started independently then
> the driver should just return an error if userspace tries to start the
> second direction up. This will severely limit the utility of the driver
> as Linux generally treats playback and record independently but that's
> going to apply just as much with any of the options involving multiple
> DAIs or configuration in DT. You might be able to do something with
> feeding it dummy data I guess?
>
Ok. I will implement a single bidirectional DAI in v2.
Best regards
Olivier
^ permalink raw reply
* Re: [PATCH 1/2] thermal: broadcom: Allow for NSP to use ns-thermal driver
From: Eduardo Valentin @ 2017-04-27 16:37 UTC (permalink / raw)
To: Jon Mason
Cc: Florian Fainelli, Zhang Rui, Rob Herring, Mark Rutland,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493153351-12698-2-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2462 bytes --]
Hey Jason,
On Tue, Apr 25, 2017 at 04:49:10PM -0400, Jon Mason wrote:
> Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows
> the ns-thermal driver to be selected via menuconfig. Also, change the
> ns-thermal driver to work on any iProc based SoC. Finally, tweak the
> Kconfig description to mention support for NSP and make the default on
> for iProc based platforms.
Thanks for the patch, but..
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> arch/arm/mach-bcm/Kconfig | 2 ++
> drivers/thermal/broadcom/Kconfig | 9 +++++----
> 2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index a0e66d8..da2bfeb 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -19,6 +19,8 @@ config ARCH_BCM_IPROC
> select GPIOLIB
> select ARM_AMBA
> select PINCTRL
> + select THERMAL
> + select THERMAL_OF
> help
> This enables support for systems based on Broadcom IPROC architected SoCs.
> The IPROC complex contains one or more ARM CPUs along with common
It would be better if this is split and sent through your arch tree, to
avoid conflicts. I could also pick it if you get an ack from one of your
maintainers. Still, first option is preferable.
> diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
> index f0dea8a..26d706c 100644
> --- a/drivers/thermal/broadcom/Kconfig
> +++ b/drivers/thermal/broadcom/Kconfig
> @@ -1,8 +1,9 @@
> config BCM_NS_THERMAL
> tristate "Northstar thermal driver"
> depends on ARCH_BCM_IPROC || COMPILE_TEST
> + default ARCH_BCM_IPROC
Not sure if this is really what you wanted. Based on your commit log
message, you meant the following, perhaps?
+ default y if ARCH_BCM_IPROC
> help
> - Northstar is a family of SoCs that includes e.g. BCM4708, BCM47081,
> - BCM4709 and BCM47094. It contains DMU (Device Management Unit) block
> - with a thermal sensor that allows checking CPU temperature. This
> - driver provides support for it.
> + Support for the Northstar and Northstar Plus family of SoCs (e.g.
> + BCM4708, BCM4709, BCM5301x, BCM95852X, etc). It contains DMU (Device
Did we look BCM47094 somehow on this patch?
> + Management Unit) block with a thermal sensor that allows checking CPU
> + temperature.
> --
> 2.7.4
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: NSP: Add Thermal Support
From: Eduardo Valentin @ 2017-04-27 16:38 UTC (permalink / raw)
To: Jon Mason
Cc: Florian Fainelli, Zhang Rui, Rob Herring, Mark Rutland,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493153351-12698-3-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]
On Tue, Apr 25, 2017 at 04:49:11PM -0400, Jon Mason wrote:
> Add thermal support via the ns-thermal driver and create a single
> thermal zone for the entire SoC.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Acked-by: Eduardo Valentin <edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> arch/arm/boot/dts/bcm-nsp.dtsi | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
> index 832795b..be6fcfb 100644
> --- a/arch/arm/boot/dts/bcm-nsp.dtsi
> +++ b/arch/arm/boot/dts/bcm-nsp.dtsi
> @@ -383,6 +383,12 @@
> <0x3f408 0x04>;
> };
>
> + thermal: thermal@3f2c0 {
> + compatible = "brcm,ns-thermal";
> + reg = <0x3f2c0 0x10>;
> + #thermal-sensor-cells = <0>;
> + };
> +
> sata_phy: sata_phy@40100 {
> compatible = "brcm,iproc-nsp-sata-phy";
> reg = <0x40100 0x340>;
> @@ -533,4 +539,24 @@
> brcm,pcie-msi-inten;
> };
> };
> +
> + thermal-zones {
> + cpu-thermal {
> + polling-delay-passive = <0>;
> + polling-delay = <1000>;
> + coefficients = <(-556) 418000>;
> + thermal-sensors = <&thermal>;
> +
> + trips {
> + cpu-crit {
> + temperature = <125000>;
> + hysteresis = <0>;
> + type = "critical";
> + };
> + };
> +
> + cooling-maps {
> + };
> + };
> + };
> };
> --
> 2.7.4
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3] NFC: trf7970a: Correct register settings for 27MHz clock
From: Mark Greer @ 2017-04-27 17:19 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
sameo-VuQAYsv1563Yd54FQh9/CA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-nfc-hn68Rpc1hR1g9hUCZPvPmw,
devicetree-u79uwXL29TY76Z2rM5mHXA, mgreer-luAo+O/VEmrlveNOaEYElw,
justin-R+k406RtEhcAvxtiuMwx3w, colin.king-Z7WLFzj8eWMS+FvcfC7Uqw,
wharms-fPG8STNUNVg
In-Reply-To: <1493304119-16605-1-git-send-email-geoff-R+k406RtEhcAvxtiuMwx3w@public.gmane.org>
On Thu, Apr 27, 2017 at 10:41:59AM -0400, Geoff Lansberry wrote:
> In prior commits the selected clock frequency does not propagate
> correctly to what is written the the TRF7970A_MODULATOR_SYS_CLK_CTRL
^^^^^^^
s/the the/to the/
> register.
>
> Signed-off-by: Geoff Lansberry <geoff-R+k406RtEhcAvxtiuMwx3w@public.gmane.org>
> ---
> drivers/nfc/trf7970a.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
> index 6ed5d7e..f7fee7d 100644
> --- a/drivers/nfc/trf7970a.c
> +++ b/drivers/nfc/trf7970a.c
> @@ -2067,6 +2067,13 @@ static int trf7970a_probe(struct spi_device *spi)
> return -EINVAL;
> }
>
> + if (clk_freq == TRF7970A_27MHZ_CLOCK_FREQUENCY) {
> + trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_27MHZ;
> + dev_dbg(trf->dev, "trf7970a configured for 27MHz crystal\n");
> + } else {
> + trf->modulator_sys_clk_ctrl = 0;
> + }
> +
> ret = devm_request_threaded_irq(trf->dev, spi->irq, NULL,
> trf7970a_irq,
> IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> --
> 2.7.4
With the suggested fix above:
Acked-by: Mark Greer <mgreer-luAo+O/VEmrlveNOaEYElw@public.gmane.org>
--
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 v8 1/3] backlight arcxcnn add arc to vendor prefix
From: Jingoo Han @ 2017-04-27 17:41 UTC (permalink / raw)
To: 'Geert Uytterhoeven', 'Olimpiu Dejeu'
Cc: 'Rob Herring', 'Lee Jones',
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
'Linux Fbdev development list',
devicetree-u79uwXL29TY76Z2rM5mHXA, 'Brian Dodge',
'Joe Perches', 'Matthew D'Asaro',
'Daniel Thompson'
In-Reply-To: <CAMuHMdXbKH5hojvj+N8W0h7znw8iAGo1Y1NyFHjrfQ1n0-XQKA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thursday, April 27, 2017 8:37 AM, Geert Uytterhoeven wrote:
> On Tue, Apr 25, 2017 at 6:36 PM, Jingoo Han <jingoohan1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Monday, April 24, 2017 1:56 PM, Olimpiu Dejeu wrote:
> >>
> >> On Mon, April 24, 2017 11:10 AM, Rob Herring < robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >>
> >> > On Wed, Mar 15, 2017 at 2:45 PM, Olimpiu Dejeu
> <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
> >> wrote:
> >> >> backlight: Add arc to vendor prefixes
> >> >> Signed-off-by: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
> >> >> ---
> >> >> v8:
> >> >> - Version to match other patches in set
> >> >>
> >> >> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> >> >> 1 file changed, 1 insertion(+)
> >> >>
> >> >> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> >> >> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> >> >> index 16d3b5e..6f33a4b 100644
> >> >> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> >> >> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> >> >> @@ -28,6 +28,7 @@ andestech Andes Technology Corporation
> >> >> apm Applied Micro Circuits Corporation (APM)
> >> >> aptina Aptina Imaging
> >> >> arasan Arasan Chip Systems
> >> >> +arc Arctic Sand
> >>
> >> >arc is also a cpu arch. While not a vendor, it could be confusing. How
> >> about "arctic" >instead?
> >>
> >> Rob, will do, i.e. I will change it to "arctic"
> >
> > Hi Olimpiu,
> >
> > Oh, "arc" and "arctic" is totally different.
> > In my opinion, one of the purposes of DT is to describe hardware stuffs.
> > So, please use more detailed words.
>
> Already acquired by Murata?
Yes, Murata already announced the agreement of acquisition. [1]
To Olimpiu Dejeu,
What is your company's plan about naming?
The brand name 'Artic Sand' will be continued or not?
If not, you should replace 'Artic Sand' with 'Murata'.
As you said earlier, changing DT names is not easy after merging.
Best regards,
Jingoo Han
[1] http://www.murata.com/about/newsroom/news/irnews/irnews/2017/0317
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-
> m68k.org
>
> In personal conversations with technical people, I call myself a hacker.
> But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] thermal: broadcom: Allow for NSP to use ns-thermal driver
From: Jon Mason @ 2017-04-27 17:42 UTC (permalink / raw)
To: Eduardo Valentin
Cc: Florian Fainelli, Zhang Rui, Rob Herring, Mark Rutland,
BCM Kernel Feedback, linux-arm-kernel, open list,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20170427163658.GC18276-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Thu, Apr 27, 2017 at 12:37 PM, Eduardo Valentin <edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hey Jason,
It's Jon :)
>
> On Tue, Apr 25, 2017 at 04:49:10PM -0400, Jon Mason wrote:
>> Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows
>> the ns-thermal driver to be selected via menuconfig. Also, change the
>> ns-thermal driver to work on any iProc based SoC. Finally, tweak the
>> Kconfig description to mention support for NSP and make the default on
>> for iProc based platforms.
>
>
> Thanks for the patch, but..
>>
>> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>> ---
>> arch/arm/mach-bcm/Kconfig | 2 ++
>> drivers/thermal/broadcom/Kconfig | 9 +++++----
>> 2 files changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>> index a0e66d8..da2bfeb 100644
>> --- a/arch/arm/mach-bcm/Kconfig
>> +++ b/arch/arm/mach-bcm/Kconfig
>> @@ -19,6 +19,8 @@ config ARCH_BCM_IPROC
>> select GPIOLIB
>> select ARM_AMBA
>> select PINCTRL
>> + select THERMAL
>> + select THERMAL_OF
>> help
>> This enables support for systems based on Broadcom IPROC architected SoCs.
>> The IPROC complex contains one or more ARM CPUs along with common
>
> It would be better if this is split and sent through your arch tree, to
> avoid conflicts. I could also pick it if you get an ack from one of your
> maintainers. Still, first option is preferable.
Sure, I'll be happy to split this off. I should've thought to split
it up before sending. Thanks for the suggestion.
>
>> diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
>> index f0dea8a..26d706c 100644
>> --- a/drivers/thermal/broadcom/Kconfig
>> +++ b/drivers/thermal/broadcom/Kconfig
>> @@ -1,8 +1,9 @@
>> config BCM_NS_THERMAL
>> tristate "Northstar thermal driver"
>> depends on ARCH_BCM_IPROC || COMPILE_TEST
>> + default ARCH_BCM_IPROC
>
> Not sure if this is really what you wanted. Based on your commit log
> message, you meant the following, perhaps?
>
> + default y if ARCH_BCM_IPROC
IIUC, my original default works, as we have used it frequently in
other places in the kernel.
grep -rI "default ARCH_BCM_IPROC" * | wc -l
15
However, if the above is preferred (or the other 15 massively broken),
I'll be happy to do it that way.
>> help
>> - Northstar is a family of SoCs that includes e.g. BCM4708, BCM47081,
>> - BCM4709 and BCM47094. It contains DMU (Device Management Unit) block
>> - with a thermal sensor that allows checking CPU temperature. This
>> - driver provides support for it.
>> + Support for the Northstar and Northstar Plus family of SoCs (e.g.
>> + BCM4708, BCM4709, BCM5301x, BCM95852X, etc). It contains DMU (Device
>
> Did we look BCM47094 somehow on this patch?
Naa, just trying to be more concise, while adding the NSP products to
the list.. BCM47094 is a type of BCM4709. So, it is still there :)
>
>> + Management Unit) block with a thermal sensor that allows checking CPU
>> + temperature.
>> --
>> 2.7.4
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 01/10] arm64: allwinner: a64: enable RSB on A64
From: icenowy-h8G6r0blFSE @ 2017-04-27 18:14 UTC (permalink / raw)
To: Maxime Ripard
Cc: Thomas Gleixner, Rob Herring, Chen-Yu Tsai, Lee Jones,
Liam Girdwood, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-owner-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170427132805.izv6xfktlhfc4yty@lukather>
在 2017-04-27 21:28，Maxime Ripard 写道：
> On Wed, Apr 26, 2017 at 11:20:14PM +0800, Icenowy Zheng wrote:
>> Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
>>
>> Add it and its pinmux.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>> ---
>> Changes in v2:
>> - Removed bonus properties in pio node.
>> - Added Chen-Yu's ACK.
>>
>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 19
>> +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index c7f669f5884f..05ec9fc5e81f 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -422,6 +422,25 @@
>> #gpio-cells = <3>;
>> interrupt-controller;
>> #interrupt-cells = <3>;
>> +
>> + r_rsb_pins: rsb@0 {
>> + pins = "PL0", "PL1";
>> + function = "s_rsb";
>> + };
>> + };
>> +
>> + r_rsb: rsb@1f03400 {
>> + compatible = "allwinner,sun8i-a23-rsb";
>> + reg = <0x01f03400 0x400>;
>> + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&r_ccu 6>;
>
> Please use the defines here..
Linux-4.12 doesn't yet enter rc1, and the defines are still not in
Linus's tree.
Please note that I have already mentioned that this patch is necessary
to be merged into 4.12, otherwise poweroff won't work properly at 4.12 .
So I think it shouldn't still use defines.
I will fix here after 4.12-rc1 is out, along with other r_ccu
usages.
>
>> + clock-frequency = <3000000>;
>> + resets = <&r_ccu 2>;
>
> And here.
>
> Thanks!
> Maxime
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors
From: Markus Mayer @ 2017-04-27 18:28 UTC (permalink / raw)
To: Rob Herring
Cc: Jean Delvare, Guenter Roeck, Mark Rutland, Florian Fainelli,
Broadcom Kernel List, Linux HWMON List, Device Tree List,
ARM Kernel List, Linux Kernel Mailing List
In-Reply-To: <CAGt4E5susQWWNZPbNh8AoWtK-4yu50VL=GqOw+_2w_FA+2V68Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 25 April 2017 at 12:29, Markus Mayer <markus.mayer-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> Hi Rob,
>
> On 18 April 2017 at 13:17, Markus Mayer <code-7CzEARzsJhSsTnJN9+BGXg@public.gmane.org> wrote:
>> From: Markus Mayer <mmayer-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>
>> Provide bindings for the Broadcom STB DDR PHY Front End (DPFE).
>
> Would you be able to have a look at this binding? The driver won't be
> upstreamed as hwmon driver (as per Guenter's comments). I am currently
> converting the driver to a "soc" driver instead, but the proposed
> binding remains unchanged.
>
> If you have comments or suggestions, I would like to incorporate them
> with the new series I will be sending out.
To explain a bit more what we are looking for: we had a internal
discussions how to structure this binding and are looking for some
guidance.
Should we create three different nodes for the three different memory
areas (dpfe-cpu@..., dpfe-dmem@..., dpfe-imem@...), each with a single
"reg" property (which is the proposal below) or should this be one
single property with 3 "reg" cells, i.e. something like this:
dpfe-cpu@f1132000 {
...
reg = <0xf1132000 0x180 /* register space */
0xf1134000 0x1000 /* data memory */
0xf1138000 0x4000>; /* instruction memory */
...
};
Regards,
-Markus
>> Signed-off-by: Markus Mayer <mmayer-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>> ---
>> .../devicetree/bindings/hwmon/brcmstb-dpfe.txt | 68 ++++++++++++++++++++++
>> 1 file changed, 68 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt b/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
>> new file mode 100644
>> index 0000000..3519197
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
>> @@ -0,0 +1,68 @@
>> +DDR PHY Front End (DPFE) for Broadcom STB
>> +=========================================
>> +
>> +DPFE and the DPFE firmware provide an interface for the host CPU to
>> +communicate with the DCPU, which resides inside the DDR PHY.
>> +
>> +There are three memory regions for interacting with the DCPU.
>> +
>> +The DCPU Register Space
>> +-----------------------
>> +
>> +Required properties:
>> + - compatible: must be one of brcm,bcm7271-dpfe-cpu, brcm,dpfe-cpu-v12.0.0.0
>> + or brcm,dpfe-cpu
>> + - reg: must reference the start address and length of the DCPU register
>> + space
>> +
>> +Optional properties:
>> + - cell-index: the index of the DPFE instance; will default to 0 if not set
>> +
>> +Example:
>> + dpfe_cpu0: dpfe-cpu@f1132000 {
>> + compatible = "brcm,bcm7271-dpfe-cpu",
>> + "brcm,dpfe-cpu-v12.0.0.0",
>> + "brcm,dpfe-cpu";
>> + reg = <0xf1132000 0x180>;
>> + cell-index = <0>;
>> + };
>> +
>> +The DCPU Data Memory Space
>> +--------------------------
>> +
>> +Required properties:
>> + - compatible: must be one of brcm,bcm7271-dpfe-dmem, brcm,dpfe-dmem-v12.0.0.0
>> + or brcm,dpfe-dmem
>> + - reg: must reference the start address and length of the DCPU DMEM space
>> +
>> +Optional properties:
>> + - cell-index: the index of the DPFE instance; will default to 0 if not set
>> +
>> +Example:
>> + dpfe_dmem0: dpfe-dmem@f1134000 {
>> + compatible = "brcm,bcm7271-dpfe-dmem",
>> + "brcm,dpfe-dmem-v12.0.0.0",
>> + "brcm,dpfe-dmem";
>> + reg = <0xf1134000 0x1000>;
>> + cell-index = <0>;
>> + };
>> +
>> +The DCPU Instruction Memory Space
>> +---------------------------------
>> +
>> +Required properties:
>> + - compatible: must be one of brcm,bcm7271-dpfe-imem, brcm,dpfe-imem-v12.0.0.0
>> + or brcm,dpfe-imem
>> + - reg: must reference the start address and length of the DCPU IMEM space
>> +
>> +Optional properties:
>> + - cell-index: the index of the DPFE instance; will default to 0 if not set
>> +
>> +Example:
>> + dpfe_imem0: dpfe-imem@f1138000 {
>> + compatible = "brcm,bcm7271-dpfe-imem",
>> + "brcm,dpfe-imem-v12.0.0.0",
>> + "brcm,dpfe-imem";
>> + reg = <0xf1138000 0x4000>;
>> + cell-index = <0>;
>> + };
>> --
>> 2.7.4
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback
From: Jose Abreu @ 2017-04-27 18:42 UTC (permalink / raw)
To: Vineet Gupta,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: Carlos Palminha, Alexey Brodkin, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <ae3f1150-f8da-9a34-d929-6964f91c06ae-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Hi Vineet,
On 27-04-2017 00:31, Vineet Gupta wrote:
> On 04/26/2017 01:55 AM, Jose Abreu wrote:
>> Hi Vineet,
>>
>>
>> On 24-04-2017 18:36, Vineet Gupta wrote:
>>> On 04/21/2017 03:15 AM, Jose Abreu wrote:
>>>> This patch adds the necessary DT bindings to get HDMI audio
>>>> output in ARC AXS10x SDP. The bindings for I2S controller were
>>>> added as well as the bindings for simple audio card.
>>> Are these waiting on Rob or is it OK for me to pick these up for 4.12 ?
>> Yes, I was waiting for Rob ack but he has been silent. It would
>> be nice if these went for 4.12.
> Ok lets wait another couple of days before I pick those up.
> In the mean time, can you please restest the series against 4.11-rcX and report
> here that patches are still valid and do as intended !
I tested based on drm-next of today (which is based on 4.11-rc7)
and the patches work okay.
Best regards,
Jose Miguel Abreu
>
> Thx,
> -Vineet
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] PCI: mediatek: Add Mediatek PCIe host controller support
From: Arnd Bergmann @ 2017-04-27 18:55 UTC (permalink / raw)
To: Ryder Lee
Cc: devicetree, linux-pci, Linux Kernel Mailing List, Rob Herring,
linux-mediatek, Bjorn Helgaas, Linux ARM
In-Reply-To: <1493194200.27023.79.camel@mtkswgap22>
On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> On Tue, 2017-04-25 at 14:38 +0200, Arnd Bergmann wrote:
>> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
>> > +static int mtk_pcie_enable_ports(struct mtk_pcie *pcie)
>> > +{
>> > + struct device *dev = pcie->dev;
>> > + struct mtk_pcie_port *port, *tmp;
>> > + int err, linkup = 0;
>> > +
>> > + list_for_each_entry_safe(port, tmp, &pcie->ports, list) {
>> > + err = clk_prepare_enable(port->sys_ck);
>> > + if (err) {
>> > + dev_err(dev, "failed to enable port%d clock\n",
>> > + port->index);
>> > + continue;
>> > + }
>> > +
>> > + /* assert RC */
>> > + reset_control_assert(port->reset);
>> > + /* de-assert RC */
>> > + reset_control_deassert(port->reset);
>> > +
>> > + /* power on PHY */
>> > + err = phy_power_on(port->phy);
>> > + if (err) {
>> > + dev_err(dev, "failed to power on port%d phy\n",
>> > + port->index);
>> > + goto err_phy_on;
>> > + }
>> > +
>> > + mtk_pcie_assert_ports(port);
>> > +
>>
>> Similar to the comment I had for the binding, I wonder if it would be
>> better to keep all the information about the ports in one place and
>> then just deal with it at the root level.
>>
>> Alternatively, we could decide to standardize on the properties
>> you have added to the pcie port node, but then I would handle
>> them in the pcieport driver rather than in the host bridge driver.
>
> Sorry, I'm not sure what you want me to do here.
>
> I could move all clock operation in root level. But we need to keep the
> reset and PHY operation sequence in the loop, In addition, we could
> easily free resources if ports link fail.
>
> How about moving this function to mtk_pcie_parse_and_add_res()?
That could work, please try it out and see if the code gets better or
worse. This may depend on what we end up doing with the DT
properties.
>> > +/*
>> > + * This IP lacks interrupt status register to check or map INTx from
>> > + * different devices at the same time.
>> > + */
>> > +static int __init mtk_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
>> > +{
>> > + struct mtk_pcie *pcie = dev->bus->sysdata;
>> > + struct mtk_pcie_port *port;
>> > +
>> > + list_for_each_entry(port, &pcie->ports, list)
>> > + if (port->index == slot)
>> > + return port->irq;
>> > +
>> > + return -1;
>> > +}
>>
>> This looks odd, what is it needed for specifically? It looks like
>> it's broken for devices behind bridges, and the interrupt mapping
>> should normally come from the interrupt-map property, without
>> the need for a driver specific map_irq override.
>
> Our hardware just has a GIC for each port and lacks interrupt status for
> host driver to distinguish INTx. So I return port IRQ here.
You should still be able to express this with standard interrupt-map
DT property, without having to resort to your own map_irq
callback handler.
In the interrupt-map-mask, you can ignore the interrupt line
only list the devfn of the root ports for each entry.
>> > +static int mtk_pcie_register_ports(struct mtk_pcie *pcie)
>> > +{
>> > + struct pci_bus *bus, *child;
>> > +
>> > + bus = pci_scan_root_bus(pcie->dev, 0, &mtk_pcie_ops, pcie,
>> > + &pcie->resources);
>>
>> Can you use the new pci_register_host_bridge() method instead of
>> pci_scan_root_bus() here?
>
> May I know what's difference between pci_scan_root_bus() and using
> pci_register_host_bridge() directly? What situation should we use it?
> It seems that just tegra use this new method currently.
We introduced the new function for tegra for now, in the long run
I would hope we can convert all other drivers to it as well, to make it
easier to add further parameters.
The new function also has a cleaner way of dealing with the memory
allocations, similar to how other subsystems work.
Arnd
^ permalink raw reply
* Re: [PATCH v2] leds-pca963x: add bindings to invert polarity
From: Jacek Anaszewski @ 2017-04-27 19:01 UTC (permalink / raw)
To: Anders Darander, pavel, robh+dt, mark.rutland, linux-leds,
devicetree, linux-kernel
Cc: rpurdie
In-Reply-To: <20170427063733.32323-1-anders@chargestorm.se>
Hi Anders,
On 04/27/2017 08:37 AM, Anders Darander wrote:
> Add a new DT property, nxp,inverted-out, to invert the polarity of the output.
>
> Tested on PCA9634.
>
> Signed-off-by: Anders Darander <anders@chargestorm.se>
> ---
> Documentation/devicetree/bindings/leds/pca963x.txt | 1 +
> drivers/leds/leds-pca963x.c | 17 +++++++++++++++--
> include/linux/platform_data/leds-pca963x.h | 6 ++++++
> 3 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/pca963x.txt b/Documentation/devicetree/bindings/leds/pca963x.txt
> index dfbdb123a9bf..4eee41482041 100644
> --- a/Documentation/devicetree/bindings/leds/pca963x.txt
> +++ b/Documentation/devicetree/bindings/leds/pca963x.txt
> @@ -10,6 +10,7 @@ Optional properties:
> - nxp,period-scale : In some configurations, the chip blinks faster than expected.
> This parameter provides a scaling ratio (fixed point, decimal divided
> by 1000) to compensate, e.g. 1300=1.3x and 750=0.75x.
> +- nxp,inverted-out: invert the polarity of the generated PWM
>
> Each led is represented as a sub-node of the nxp,pca963x device.
>
> diff --git a/drivers/leds/leds-pca963x.c b/drivers/leds/leds-pca963x.c
> index ded1e4dac36a..3bf9a1271819 100644
> --- a/drivers/leds/leds-pca963x.c
> +++ b/drivers/leds/leds-pca963x.c
> @@ -342,6 +342,12 @@ pca963x_dt_init(struct i2c_client *client, struct pca963x_chipdef *chip)
> if (of_property_read_u32(np, "nxp,period-scale", &chip->scaling))
> chip->scaling = 1000;
>
> + /* default to non-inverted output, unless inverted is specified */
> + if (of_property_read_bool(np, "nxp,inverted-out"))
> + pdata->dir = PCA963X_INVERTED;
> + else
> + pdata->dir = PCA963X_NORMAL;
> +
> return pdata;
> }
>
> @@ -452,11 +458,18 @@ static int pca963x_probe(struct i2c_client *client,
> i2c_smbus_write_byte_data(client, PCA963X_MODE1, BIT(4));
>
> if (pdata) {
> + u8 mode2 = i2c_smbus_read_byte_data(pca963x->chip->client,
> + PCA963X_MODE2);
> /* Configure output: open-drain or totem pole (push-pull) */
> if (pdata->outdrv == PCA963X_OPEN_DRAIN)
> - i2c_smbus_write_byte_data(client, PCA963X_MODE2, 0x01);
> + mode2 |= 0x01;
> else
> - i2c_smbus_write_byte_data(client, PCA963X_MODE2, 0x05);
> + mode2 |= 0x05;
> + /* Configure direction: normal or inverted */
> + if (pdata->dir == PCA963X_INVERTED)
> + mode2 |= 0x10;
> + i2c_smbus_write_byte_data(pca963x->chip->client, PCA963X_MODE2,
> + mode2);
> }
>
> return 0;
> diff --git a/include/linux/platform_data/leds-pca963x.h b/include/linux/platform_data/leds-pca963x.h
> index e731f0036329..54e845ffb5ed 100644
> --- a/include/linux/platform_data/leds-pca963x.h
> +++ b/include/linux/platform_data/leds-pca963x.h
> @@ -33,10 +33,16 @@ enum pca963x_blink_type {
> PCA963X_HW_BLINK,
> };
>
> +enum pca963x_direction {
> + PCA963X_NORMAL,
> + PCA963X_INVERTED,
> +};
> +
> struct pca963x_platform_data {
> struct led_platform_data leds;
> enum pca963x_outdrv outdrv;
> enum pca963x_blink_type blink_type;
> + enum pca963x_direction dir;
> };
>
> #endif /* __LINUX_PCA963X_H*/
>
Thanks for the patch.
Applied to the for-4.13 branch of linux-leds.git.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [SPAM]Re: [PATCH 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe
From: Arnd Bergmann @ 2017-04-27 19:06 UTC (permalink / raw)
To: Ryder Lee
Cc: devicetree, linux-pci, Linux Kernel Mailing List, Rob Herring,
linux-mediatek, Bjorn Helgaas, Linux ARM
In-Reply-To: <1493194205.27023.80.camel@mtkswgap22>
On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> Hi
>
> On Tue, 2017-04-25 at 14:18 +0200, Arnd Bergmann wrote:
>> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
>> > Add documentation for PCIe host driver available in MT7623
>> > series SoCs.
>> >
>> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
>> > ---
>> > .../bindings/pci/mediatek,mt7623-pcie.txt | 153 +++++++++++++++++++++
>> > 1 file changed, 153 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
>> > new file mode 100644
>> > index 0000000..ee93ba2
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
>> > @@ -0,0 +1,153 @@
>> > +Mediatek MT7623 PCIe controller
>> > +
>> > +Required properties:
>> > +- compatible: Should contain "mediatek,mt7623-pcie".
>>
>> Did mediatek license the IP block from someone else or was it
>> developed in-house? Is there a name and/or version identifier
>> for the block itself other than identifying it as the one in mt7623?
>
> Originally, it license from synopsys. Our designer add a wrapper to hide
> the DBI detail so that we cannot use them directly. Perhaps I can call
> it "mediatek,gen2v1-pcie", because we have a plan to upstream a in-house
> Gen2 IP in the future.
Ok, so this is the same hardware that drivers/pci/dwc/ handles, but
it needs a separate driver because the wrapper that was added uses
a completely different register layout, right?
Are any of the registers the same at all, e.g. for MSI handling?
>> > +Required properties:
>> > +- device_type: Must be "pci"
>> > +- assigned-addresses: Address and size of the port configuration registers
>> > +- reg: Only the first four bytes are used to refer to the correct bus number
>> > + and device number.
>> > +- #address-cells: Must be 3
>> > +- #size-cells: Must be 2
>> > +- ranges: Sub-ranges distributed from the PCIe controller node. An empty
>> > + property is sufficient.
>> > +- clocks: Must contain an entry for each entry in clock-names.
>> > + See ../clocks/clock-bindings.txt for details.
>> > +- clock-names: Must include the following entries:
>> > + - sys_ck
>> > +- resets: Must contain an entry for each entry in reset-names.
>> > + See ../reset/reset.txt for details.
>>
>> This seems odd: you have a device that is simply identified as "pci"
>> without any more specific ID, but you require additional properties
>> (clocks, reset, ...) that are not part of the standard PCI binding.
>>
>> Can you clarify how the port devices related to the root device in
>> this hardware design?
>
> I will write clarify like this:
>
> PCIe subsys includes one Host/PCI bridge and 3 PCIe MAC port. There
> are 3 bus master for data access and 1 slave for configuration and
> status register access. Each port has PIPE interface to PHY and
If I understand this right, then each of the ports in your hardware
is what we normally drive using the drivers/pci/dwc/ driver framework,
but your implementation actually made it more PCI standard compliant
by implementing the normal PCIe host bridge registers for all ports
combined, something that most others don't.
>> Have you considered moving the nonstandard properties into the host
>> bridge node and having that device deal with setting up the links
>> to the other drivers? That way we could use the regular pcie
>> port driver for the children.
>>
>
> OK, but I still want to use port->reset to catch reset properties in
> driver.
Do you mean in drivers/pci/pcie/portdrv_pci.c? I see that it
has a function called pcie_portdrv_slot_reset(), but I don't see
how that relates to your reset line at the moment. Is this
something you have submitted in a different series?
Or do you mean in this host driver? The problem I see with
that approach is that the port device is owned by portdrv_pci,
so the host bridge driver should not look at the properties of
the port.
>> > +- reset-names: Must include the following entries:
>> > + - pcie-reset
>> > +- num-lanes: Number of lanes to use for this port.
>> > +- phys: Must contain an entry for each entry in phy-names.
>> > +- phy-names: Must include an entry for each sub node. Entries are of the form
>> > + "pcie-phyN": where N ranges from 0 to the value specified for port number.
>> > + See ../phy/phy-mt7623-pcie.txt for details.
>>
>> I think the name should not include the number of the port but rather
>> be always the same here.
>>
>
> Hmm, I think it's better to keep the name here. It's more readable for
> user to understand the relationship between port0 and phy0.
No, I would argue that it's confusing for the reader because it
is different from how most other DT bindings work: In each device
node, you tend to have a set of properties with well-known names
that are documented. When your reference is called "pcie-phy1"
in one node and "pcie-phy2", I would interpret that as both ports
having two phys each, but only one of them being used.
Arnd
^ permalink raw reply
* [PATCH] ARM: dts: r7s72100: add usb clocks to device tree
From: Chris Brandt @ 2017-04-27 19:10 UTC (permalink / raw)
To: Simon Horman, Geert Uytterhoeven, Rob Herring, Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Chris Brandt
This adds the USB0 and USB1 clocks to the device tree.
Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/r7s72100.dtsi | 6 +++---
include/dt-bindings/clock/r7s72100-clock.h | 2 ++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index fb54cb5d3fad..4ed12a4d9d51 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -144,9 +144,9 @@
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks", "renesas,cpg-mstp-clocks";
reg = <0xfcfe0430 4>;
- clocks = <&b_clk>;
- clock-indices = <R7S72100_CLK_ETHER>;
- clock-output-names = "ether";
+ clocks = <&b_clk>, <&p1_clk>, <&p1_clk>;
+ clock-indices = <R7S72100_CLK_ETHER R7S72100_CLK_USB0 R7S72100_CLK_USB1>;
+ clock-output-names = "ether", "usb0", "usb1";
};
mstp8_clks: mstp8_clks@fcfe0434 {
diff --git a/include/dt-bindings/clock/r7s72100-clock.h b/include/dt-bindings/clock/r7s72100-clock.h
index bc256d31099a..dcd2072151fc 100644
--- a/include/dt-bindings/clock/r7s72100-clock.h
+++ b/include/dt-bindings/clock/r7s72100-clock.h
@@ -34,6 +34,8 @@
/* MSTP7 */
#define R7S72100_CLK_ETHER 4
+#define R7S72100_CLK_USB0 1
+#define R7S72100_CLK_USB1 0
/* MSTP8 */
#define R7S72100_CLK_MMCIF 4
--
2.11.0
--
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: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback
From: Vineet Gupta @ 2017-04-27 19:13 UTC (permalink / raw)
To: Jose Abreu,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: Carlos Palminha, Alexey Brodkin, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <f1e3621d-3dbd-116d-d9c1-3aeb9bd40c2a-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On 04/27/2017 11:42 AM, Jose Abreu wrote:
> Hi Vineet,
>
>
> On 27-04-2017 00:31, Vineet Gupta wrote:
>> On 04/26/2017 01:55 AM, Jose Abreu wrote:
>>> Hi Vineet,
>>>
>>>
>>> On 24-04-2017 18:36, Vineet Gupta wrote:
>>>> On 04/21/2017 03:15 AM, Jose Abreu wrote:
>>>>> This patch adds the necessary DT bindings to get HDMI audio
>>>>> output in ARC AXS10x SDP. The bindings for I2S controller were
>>>>> added as well as the bindings for simple audio card.
>>>> Are these waiting on Rob or is it OK for me to pick these up for 4.12 ?
>>> Yes, I was waiting for Rob ack but he has been silent. It would
>>> be nice if these went for 4.12.
>> Ok lets wait another couple of days before I pick those up.
>> In the mean time, can you please restest the series against 4.11-rcX and report
>> here that patches are still valid and do as intended !
> I tested based on drm-next of today (which is based on 4.11-rc7)
> and the patches work okay.
Pushed to for-curr for 4.12 !
Thx,
-Vineet
--
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 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G
From: Arnd Bergmann @ 2017-04-27 19:56 UTC (permalink / raw)
To: Chunyan Zhang
Cc: arm-soc, Mathieu Poirier, Orson Zhai (翟京),
Linux Kernel Mailing List, devicetree-u79uwXL29TY76Z2rM5mHXA,
Linux ARM, zhang.lyra-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1492746440-11071-1-git-send-email-chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
On Fri, Apr 21, 2017 at 5:47 AM, Chunyan Zhang
<chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org> wrote:
> From: Orson Zhai <orson.zhai-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
>
> SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.
>
> According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
> peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
> and sp9860g dts is for the board level.
>
> Signed-off-by: Orson Zhai <orson.zhai-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
> Signed-off-by: Chunyan Zhang <chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
> Reviewed-by: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Applied to next/dt64 now, thanks!
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox