* Re: [PATCH v2 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Guillaume Tucker @ 2017-04-24 10:43 UTC (permalink / raw)
To: Rob Herring
Cc: Heiko Stuebner, Mark Rutland, Sjoerd Simons,
Enric Balletbo i Serra, John Reitan, Wookey,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b8cf7acd-83e9-49fb-0800-19a76b8dcce5-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On 18/04/17 10:15, Guillaume Tucker wrote:
> Hi Rob,
>
> On 04/04/17 03:00, Rob Herring wrote:
>> On Sun, Apr 02, 2017 at 08:59:44AM +0100, Guillaume Tucker wrote:
>>> +- operating-points : Refer to Documentation/devicetree/bindings/power/opp.txt
>>> + for details.
>>
>> Is this going to be sufficient vs. operating-points-v2? Or should it be
>> a power domain with OPPs?
>
> In principle, switching to operating-points-v2 should be very
> straightforward. I have smoke-tested the driver with an
> operating-points-v2 table and a phandle to it inside the gpu node
> in place of operating-points and it seems to be working fine. At
> least it parsed the OPPs and got initialised correctly.
>
> My understanding is that operating-points (v1) are not deprecated
> so we could keep the bindings as-is, but please let me know
> otherwise and I can try to address that in my next patch version.
> In the documentation, it should only be the case of replacing
> operating-points with operating-points-v2.
While the opp bindings documentation doesn't mention anything
about operating-points being deprecated, the code and comments in
of.c are pretty clear about this:
/*
* OPPs have two version of bindings now. The older one is deprecated,
* try for the new binding first.
*/
So I shall use operating-points-v2 in my patch v4.
Thanks,
Guillaume
--
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 v14 00/11] mux controller abstraction and iio/i2c muxes
From: Philipp Zabel @ 2017-04-24 10:52 UTC (permalink / raw)
To: Peter Rosin
Cc: Jonathan Cameron, linux-kernel, Greg Kroah-Hartman, Wolfram Sang,
Rob Herring, Mark Rutland, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Jonathan Corbet, linux-i2c, devicetree,
linux-iio, linux-doc, Andrew Morton, Colin Ian King,
Paul Gortmaker, kernel
In-Reply-To: <1493022995-16917-1-git-send-email-peda@axentia.se>
On Mon, 2017-04-24 at 10:36 +0200, Peter Rosin wrote:
> Hi!
>
> The big change since v13 is that the mux state is now locked with a mutex
> instead of an rwsem. Other that that, it is mostly restructuring and doc
> changes. There are a few other "real" changes as well, but those changes
> feel kind of minor. I guess what I'm trying to say is that although the
> list of changes for v14 is longish, it's still basically the same as last
> time.
I have hooked this up to the video-multiplexer and now I trigger
the lockdep debug_check_no_locks_held error message when selecting the
mux input from userspace:
$ media-ctl --links "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]"
[ 66.258368]
[ 66.259919] =====================================
[ 66.265369] [ BUG: media-ctl/258 still has locks held! ]
[ 66.270810] 4.11.0-rc8-20170424-1+ #1305 Not tainted
[ 66.275863] -------------------------------------
[ 66.282158] 1 lock held by media-ctl/258:
[ 66.286464] #0: (&mux->lock){+.+.+.}, at: [<8074a6c0>] mux_control_select+0x24/0x50
[ 66.294424]
[ 66.294424] stack backtrace:
[ 66.298980] CPU: 0 PID: 258 Comm: media-ctl Not tainted 4.11.0-rc8+ #1305
[ 66.306771] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 66.313334] Backtrace:
[ 66.315858] [<8010e5a4>] (dump_backtrace) from [<8010e8ac>] (show_stack+0x20/0x24)
[ 66.323473] r7:80e518d0 r6:80e518d0 r5:600d0013 r4:00000000
[ 66.329190] [<8010e88c>] (show_stack) from [<80496cf4>] (dump_stack+0xb0/0xdc)
[ 66.336470] [<80496c44>] (dump_stack) from [<8017e404>] (debug_check_no_locks_held+0xb8/0xbc)
[ 66.345043] r9:ae8566b8 r8:ad88dc84 r7:ad88df58 r6:ad88dc84 r5:ad88df58 r4:ae856400
[ 66.352837] [<8017e34c>] (debug_check_no_locks_held) from [<8012b258>] (do_exit+0x79c/0xcc8)
[ 66.361321] [<8012aabc>] (do_exit) from [<8012d25c>] (do_group_exit+0x4c/0xcc)
[ 66.368581] r7:000000f8
[ 66.371161] [<8012d210>] (do_group_exit) from [<8012d2fc>] (__wake_up_parent+0x0/0x30)
[ 66.379120] r7:000000f8 r6:76f71798 r5:00000000 r4:00000001
[ 66.384837] [<8012d2dc>] (SyS_exit_group) from [<80109380>] (ret_fast_syscall+0x0/0x1c)
That correctly warns that the media-ctl process caused the mux->lock to
be locked and still held when the process exited. Do we need a usage
counter based mechanism for muxes that are (indirectly) controlled from
userspace?
regards
Philipp
^ permalink raw reply
* Re: [PATCH RFC 0/5] *** SPI Slave mode support ***
From: Geert Uytterhoeven @ 2017-04-24 10:55 UTC (permalink / raw)
To: Jiada Wang
Cc: Mark Brown, Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer,
Fabio Estevam, linux-spi,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <58F06092.9080409-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Hi Jiada,
On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang <jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org> wrote:
> On 04/13/2017 12:47 PM, Geert Uytterhoeven wrote:
>> On Thu, Apr 13, 2017 at 2:59 PM, Mark Brown<broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>> On Thu, Apr 13, 2017 at 05:13:59AM -0700, jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org wrote:
>>>> From: Jiada Wang<jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
>>>>
>>>> v1:
>>>> add Slave mode support in SPI core
>>>> spidev create slave device when SPI controller work in slave mode
>>>> spi-imx support to work in slave mode
>>>
>>> Adding Geert who also had a series doing this in progress that was
>>> getting very near to being merged.
>>
>> Thank you!
>>
>> Actually my plan is to fix the last remaining issues and resubmit for
>> v4.13.
>
> I noticed your patch set for SPI slave support,
> (I am sure you can find out some of the change
> in this patch set is based on your work).
> we have similar requirement to add slave mode support to ecspi IP on imx6
> Soc.
>
> Our use case is to use spidev as an interface to communicate with external
> SPI master devices.
> meanwhile the SPI bus controller can also act as master device to send data
> to other
> SPI slave devices on the board.
That sounds a bit hackish to me. SPI was never meant to be a multi-master bus.
While it can be done, you will need external synchronization (signals) to
avoid conflicts between the SPI masters.
> I found in your implementation, SPI bus controller is limited to either work
> in master mode or
> slave mode, is there any reasoning to not configure SPI mode based on SPI
> devices use case?
If you really need both master and slave support, you can use 2 subnodes
in DT, the first representing the master, the second the slave.
Mark, what's your opinion about this?
Thanks!
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 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] fix ptr_ret.cocci warnings
From: Lee Jones @ 2017-04-24 10:57 UTC (permalink / raw)
To: Olimpiu Dejeu
Cc: Daniel Thompson, kbuild test robot,
fengguang.wu-ral2JQCrhuEAvxtiuMwx3w, kbuild-all-JC7UmRfGjtg,
Rob Herring, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
jingoohan1-Re5JQEeQqe8AvxtiuMwx3w, Brian Dodge,
joe-6d6DIl74uiNBDgjK7y7TUQ, Matthew D'Asaro
In-Reply-To: <CAF-XLWL_w3OqafbLzcM=kOkS1nPb0VSCAyDaudQh2UwE4Gw0gg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 17 Apr 2017, Olimpiu Dejeu wrote:
> On Tue, Mar 21, 2017 at 11:07 AM, Daniel Thompson <
> daniel.thompson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>
> > On 21/03/17 14:58, Olimpiu Dejeu wrote:
> >
> >> On Fri, Mar 17, 2017 at 10:48 AM, kbuild test robot <lkp-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >> wrote:
> >>
> >>> drivers/video/backlight/arcxcnn_bl.c:183:1-3: WARNING: PTR_ERR_OR_ZERO
> >>> can be used
> >>>
> >>>
> >>> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
> >>>
> >>> Generated by: scripts/coccinelle/api/ptr_ret.cocci
> >>>
> >>> CC: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
> >>> Signed-off-by: Fengguang Wu <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >>> ---
> >>>
> >>> arcxcnn_bl.c | 5 +----
> >>> 1 file changed, 1 insertion(+), 4 deletions(-)
> >>>
> >>> --- a/drivers/video/backlight/arcxcnn_bl.c
> >>> +++ b/drivers/video/backlight/arcxcnn_bl.c
> >>> @@ -180,10 +180,7 @@ static int arcxcnn_backlight_register(st
> >>>
> >>> lp->bl = devm_backlight_device_register(lp->dev, name, lp->dev,
> >>> lp,
> >>> &arcxcnn_bl_ops, props);
> >>> - if (IS_ERR(lp->bl))
> >>> - return PTR_ERR(lp->bl);
> >>> -
> >>> - return 0;
> >>> + return PTR_ERR_OR_ZERO(lp->bl);
> >>> }
> >>>
> >>> static void arcxcnn_parse_dt(struct arcxcnn *lp)
> >>>
> >>
> >> Acked-by: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
> >>
> >
> > Glad you approve! Could you apply this change and re-post the patch
> > series? Thanks.
> >
> >
> > Daniel.
> >
> >
> Applied change, re-posted series on March 21st. No sure what next. Please
> advise. Thanks.
Yes you did.
Daniel, do you see v9?
FYI, if this happens again, it's best to wait a couple of weeks then
send the patch again like "[RESEND v9] ..." to gain attention.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: [GIT PULL] Immutable branch between MFD and IIO due for the v4.12 merge window
From: Lee Jones @ 2017-04-24 11:02 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Quentin Schulz, sre-DgEjT+Ai2ygdnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, icenowy-ymACFijhrKM,
liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <0f30afec-ff42-e125-96d6-35893324f7ef-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Fri, 14 Apr 2017, Jonathan Cameron wrote:
> On 11/04/17 11:05, Lee Jones wrote:
> > Enjoy!
> >
> > The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
> >
> > Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-iio-v4.12
> >
> > for you to fetch changes up to f2499ab450d3052097ba53a7d763f767935c0c59:
> >
> > iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs (2017-04-11 11:02:33 +0100)
> >
> > ----------------------------------------------------------------
> > Immutable branch between MFD and IIO due for the v4.12 merge window
> >
> > ----------------------------------------------------------------
> > Quentin Schulz (1):
> > iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs
> >
> > drivers/iio/adc/Kconfig | 10 +
> > drivers/iio/adc/Makefile | 1 +
> > drivers/iio/adc/axp20x_adc.c | 617 +++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 628 insertions(+)
> > create mode 100644 drivers/iio/adc/axp20x_adc.c
> >
> Hi Lee,
>
> Thanks for doing this, but the reason it was going to go through your
> tree in the first place was a dependency on
> commit 4707274714ef ("mfd: axp20x: Correct name of temperature data ADC registers")
>
> Not present in the immutable branch.
>
> There isn't much time for anything else going on around this driver though
> so other than a possible merge conflict on the Kconfig and Makefile shouldn't
> matter if this just goes through mfd. (famous last words ;)
It's not as though you committed it to text and sent it out to a
public mailing list for us all to reference though is it? Doh!
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH RFC 1/7] clk: samsung: Add enable/disable operation for PLL36XX clocks
From: Sylwester Nawrocki @ 2017-04-24 11:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, alsa-devel, linux-samsung-soc, javier, b.zolnierkie,
sw0312.kim, dri-devel, cw00.choi, broonie, robh+dt, linux-clk
In-Reply-To: <20170422152236.tbf4iuoadqrvoc2n@kozik-lap>
On 04/22/2017 05:22 PM, Krzysztof Kozlowski wrote:
[...]
>> +static void samsung_pll3xxx_disable(struct clk_hw *hw)
>> +{
>> + struct samsung_clk_pll *pll = to_clk_pll(hw);
>> + u32 tmp;
>> +
>> + tmp = readl_relaxed(pll->con_reg);
>> + tmp |= BIT(pll->enable_offs);
>
> I think you meant here:
> tmp &= ~BIT()
Yes, I messed it up while copy/pasting from samsung_pll3xxx_enable().
>> + writel_relaxed(tmp, pll->con_reg);
>> +}
>> static unsigned long samsung_pll36xx_recalc_rate(struct clk_hw *hw,
>> unsigned long parent_rate)
>> @@ -354,10 +359,12 @@ static int samsung_pll36xx_set_rate(struct clk_hw *hw, unsigned long drate,
>> writel_relaxed(pll_con1, pll->con_reg + 4);
>>
>> /* wait_lock_time */
>> - do {
>> - cpu_relax();
>> - tmp = readl_relaxed(pll->con_reg);
>> - } while (!(tmp & (1 << PLL36XX_LOCK_STAT_SHIFT)));
I will add a comment here like:
/* Wait until the PLL is locked if it is enabled. */
>> + if (pll_con0 & BIT(pll->enable_offs)) {
>
> Why this additional if() is needed?
The PLL will never transition to a locked state if it is disabled, without
this test we would end up with an indefinite loop below.
>> + do {
>> + cpu_relax();
>> + tmp = readl_relaxed(pll->con_reg);
>> + } while (!(tmp & BIT(PLL36XX_LOCK_STAT_SHIFT)));
>
> To be consistent:
> BIT(pll->lock_offs)?
Yes, fixed.
Thanks for your review!
--
Regards,
Sylwester
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH RFC 1/7] clk: samsung: Add enable/disable operation for PLL36XX clocks
From: Sylwester Nawrocki @ 2017-04-24 11:12 UTC (permalink / raw)
To: Stephen Boyd
Cc: devicetree, alsa-devel, linux-samsung-soc, javier, b.zolnierkie,
sw0312.kim, dri-devel, cw00.choi, broonie, krzk, robh+dt,
linux-clk
In-Reply-To: <20170422025127.GS7065@codeaurora.org>
On 04/22/2017 04:51 AM, Stephen Boyd wrote:
>> +static int samsung_pll3xxx_enable(struct clk_hw *hw)
>> +{
>> + struct samsung_clk_pll *pll = to_clk_pll(hw);
>> + u32 tmp;
>> +
>> + tmp = readl_relaxed(pll->con_reg);
>> + tmp |= BIT(pll->enable_offs);
>> + writel_relaxed(tmp, pll->con_reg);
>> +
>> + /* wait lock time */
>> + do {
>> + cpu_relax();
>> + tmp = readl_relaxed(pll->con_reg);
>> + } while (!(tmp & BIT(pll->lock_offs)));
>
> Not a problem with this patch because we're moving code around,
> but this is a potential infinite loop that should have some sort
> of timeout so we don't sit here forever trying to see a bit
> toggle.
Yes, I will add some protection in new patch, like it is done
for newer PLLs. Thanks for you review.
--
Regards,
Sylwester
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH RFC 1/7] clk: samsung: Add enable/disable operation for PLL36XX clocks
From: Krzysztof Kozlowski @ 2017-04-24 11:18 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, alsa-devel, linux-samsung-soc, jy0922.shim,
Javier Martinez Canillas,
Bartłomiej Żołnierkiewicz, Seung Woo Kim,
dri-devel, Inki Dae, Chanwoo Choi, broonie, robh+dt, linux-clk
In-Reply-To: <017b3ec8-c185-c29a-2944-12f519b461fe@samsung.com>
On Mon, Apr 24, 2017 at 1:12 PM, Sylwester Nawrocki
<s.nawrocki@samsung.com> wrote:
> On 04/22/2017 05:22 PM, Krzysztof Kozlowski wrote:
>>> @@ -354,10 +359,12 @@ static int samsung_pll36xx_set_rate(struct clk_hw
>>> *hw, unsigned long drate,
>>> writel_relaxed(pll_con1, pll->con_reg + 4);
>>>
>>> /* wait_lock_time */
>>> - do {
>>> - cpu_relax();
>>> - tmp = readl_relaxed(pll->con_reg);
>>> - } while (!(tmp & (1 << PLL36XX_LOCK_STAT_SHIFT)));
>
>
> I will add a comment here like:
> /* Wait until the PLL is locked if it is enabled. */
>
>>> + if (pll_con0 & BIT(pll->enable_offs)) {
>>
>>
>> Why this additional if() is needed?
>
>
> The PLL will never transition to a locked state if it is disabled, without
> this test we would end up with an indefinite loop below.
Hmmm... shouldn't this be split from this change? Or maybe this is
needed only because you added enable/disable for pl36xx and previously
this was not existing?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] fix ptr_ret.cocci warnings
From: Daniel Thompson @ 2017-04-24 11:26 UTC (permalink / raw)
To: Lee Jones, Olimpiu Dejeu
Cc: kbuild test robot, fengguang.wu, kbuild-all, Rob Herring,
linux-kernel, linux-fbdev, devicetree, jingoohan1, Brian Dodge,
joe, Matthew D'Asaro
In-Reply-To: <20170424105756.im6hjljqvyktzh6n@dell>
On 24/04/17 11:57, Lee Jones wrote:
> On Mon, 17 Apr 2017, Olimpiu Dejeu wrote:
>
>> On Tue, Mar 21, 2017 at 11:07 AM, Daniel Thompson <
>> daniel.thompson@linaro.org> wrote:
>>
>>> On 21/03/17 14:58, Olimpiu Dejeu wrote:
>>>
>>>> On Fri, Mar 17, 2017 at 10:48 AM, kbuild test robot <lkp@intel.com>
>>>> wrote:
>>>>
>>>>> drivers/video/backlight/arcxcnn_bl.c:183:1-3: WARNING: PTR_ERR_OR_ZERO
>>>>> can be used
>>>>>
>>>>>
>>>>> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
>>>>>
>>>>> Generated by: scripts/coccinelle/api/ptr_ret.cocci
>>>>>
>>>>> CC: Olimpiu Dejeu <olimpiu@arcticsand.com>
>>>>> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
>>>>> ---
>>>>>
>>>>> arcxcnn_bl.c | 5 +----
>>>>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>>>>
>>>>> --- a/drivers/video/backlight/arcxcnn_bl.c
>>>>> +++ b/drivers/video/backlight/arcxcnn_bl.c
>>>>> @@ -180,10 +180,7 @@ static int arcxcnn_backlight_register(st
>>>>>
>>>>> lp->bl = devm_backlight_device_register(lp->dev, name, lp->dev,
>>>>> lp,
>>>>> &arcxcnn_bl_ops, props);
>>>>> - if (IS_ERR(lp->bl))
>>>>> - return PTR_ERR(lp->bl);
>>>>> -
>>>>> - return 0;
>>>>> + return PTR_ERR_OR_ZERO(lp->bl);
>>>>> }
>>>>>
>>>>> static void arcxcnn_parse_dt(struct arcxcnn *lp)
>>>>>
>>>>
>>>> Acked-by: Olimpiu Dejeu <olimpiu@arcticsand.com>
>>>>
>>>
>>> Glad you approve! Could you apply this change and re-post the patch
>>> series? Thanks.
>>>
>>>
>>> Daniel.
>>>
>>>
>> Applied change, re-posted series on March 21st. No sure what next. Please
>> advise. Thanks.
>
> Yes you did.
>
> Daniel, do you see v9?
Yep. All fine at my end... it has my Reviewed-by: which is an even more
emphatic statement than my Acked-by: ;-) .
I think from this point on I think I'll start posting
"[vX-is-still-]Acked-by:" replies so you don't have to worry about
whether I've seen new versions.
> FYI, if this happens again, it's best to wait a couple of weeks then
> send the patch again like "[RESEND v9] ..." to gain attention.
RESENDs are a good way to go. Also, if there are questions about the
code its better to reply to the code rather than the side discussion.
Daniel.
^ permalink raw reply
* Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes
From: Peter Rosin @ 2017-04-24 11:37 UTC (permalink / raw)
To: Philipp Zabel
Cc: Jonathan Cameron, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, Wolfram Sang, Rob Herring, Mark Rutland,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Andrew Morton, Colin Ian King,
Paul Gortmaker, kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <1493031179.2446.9.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 2017-04-24 12:52, Philipp Zabel wrote:
> On Mon, 2017-04-24 at 10:36 +0200, Peter Rosin wrote:
>> Hi!
>>
>> The big change since v13 is that the mux state is now locked with a mutex
>> instead of an rwsem. Other that that, it is mostly restructuring and doc
>> changes. There are a few other "real" changes as well, but those changes
>> feel kind of minor. I guess what I'm trying to say is that although the
>> list of changes for v14 is longish, it's still basically the same as last
>> time.
>
> I have hooked this up to the video-multiplexer and now I trigger
> the lockdep debug_check_no_locks_held error message when selecting the
> mux input from userspace:
>
> $ media-ctl --links "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]"
> [ 66.258368]
> [ 66.259919] =====================================
> [ 66.265369] [ BUG: media-ctl/258 still has locks held! ]
> [ 66.270810] 4.11.0-rc8-20170424-1+ #1305 Not tainted
> [ 66.275863] -------------------------------------
> [ 66.282158] 1 lock held by media-ctl/258:
> [ 66.286464] #0: (&mux->lock){+.+.+.}, at: [<8074a6c0>] mux_control_select+0x24/0x50
> [ 66.294424]
> [ 66.294424] stack backtrace:
> [ 66.298980] CPU: 0 PID: 258 Comm: media-ctl Not tainted 4.11.0-rc8+ #1305
> [ 66.306771] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [ 66.313334] Backtrace:
> [ 66.315858] [<8010e5a4>] (dump_backtrace) from [<8010e8ac>] (show_stack+0x20/0x24)
> [ 66.323473] r7:80e518d0 r6:80e518d0 r5:600d0013 r4:00000000
> [ 66.329190] [<8010e88c>] (show_stack) from [<80496cf4>] (dump_stack+0xb0/0xdc)
> [ 66.336470] [<80496c44>] (dump_stack) from [<8017e404>] (debug_check_no_locks_held+0xb8/0xbc)
> [ 66.345043] r9:ae8566b8 r8:ad88dc84 r7:ad88df58 r6:ad88dc84 r5:ad88df58 r4:ae856400
> [ 66.352837] [<8017e34c>] (debug_check_no_locks_held) from [<8012b258>] (do_exit+0x79c/0xcc8)
> [ 66.361321] [<8012aabc>] (do_exit) from [<8012d25c>] (do_group_exit+0x4c/0xcc)
> [ 66.368581] r7:000000f8
> [ 66.371161] [<8012d210>] (do_group_exit) from [<8012d2fc>] (__wake_up_parent+0x0/0x30)
> [ 66.379120] r7:000000f8 r6:76f71798 r5:00000000 r4:00000001
> [ 66.384837] [<8012d2dc>] (SyS_exit_group) from [<80109380>] (ret_fast_syscall+0x0/0x1c)
>
> That correctly warns that the media-ctl process caused the mux->lock to
> be locked and still held when the process exited. Do we need a usage
> counter based mechanism for muxes that are (indirectly) controlled from
> userspace?
Ok, so the difference is probably that the rwsem locking primitive
don't have any lockdep checking hooked up. Because the rwsem was
definitely held in the same way in v13 as the mutex is now held in
v14, so there's no fundamental difference.
So, yes, we can use some kind of refcount scheme to not hold an actual
mutex for the duration of the mux select/deselect, but that doesn't
really change anything. Userspace is still locking something, and that
seems dangerous. How do you make sure that mux_control_deselect is
called as it should?
What I don't like about abandoning the lock is that there is still a
need to support the multi-consumer case and then you need some way
of keeping track of waiters. A lock does this, and any attempt to open
code that will get messy.
What might be better is to support some kind of exclusive mux, i.e. a
mux that only allows one consumer per mux controller. Then the mux core
could trust that exclusive consumer to not fuck things up for itself and
thus have no lock at all for select/deselect for the exclusive case. Or
perhaps keep a refcount (as you suggested) for the exclusive case so
that mux_control_try_select still makes sense, because you still want
that, right?
The question then becomes how to best tell the mux core that you want
an exclusive mux. I see two options. Either you declare a mux controller
as exclusive up front somehow (in the device tree presumably), or you
add a mux_control_get_exclusive call that makes further calls to
mux_control_get{,_exclusive} fail with -EBUSY. I think I like the
latter better, if that can be made to work...
Cheers,
peda
--
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 4/7] pinctrl: armada-37xx: Add gpio support
From: Linus Walleij @ 2017-04-24 11:48 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-gpio@vger.kernel.org, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Rob Herring,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits
In-Reply-To: <83a4f4c08275b41333a2583f01ceb0453b009d9f.1491405475.git-series.gregory.clement@free-electrons.com>
On Wed, Apr 5, 2017 at 5:18 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> GPIO management is pretty simple and is part of the same IP than the pin
> controller for the Armada 37xx SoCs. This patch adds the GPIO support to
> the pinctrl-armada-37xx.c file, it also allows sharing common functions
> between the gpiolib and the pinctrl drivers.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/2] extcon: cros-ec: Add extcon-cros-ec driver to support display out.
From: Lee Jones @ 2017-04-24 11:58 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Chanwoo Choi, MyungJoo Ham, Rob Herring, linux-kernel, devicetree,
Benson Leung
In-Reply-To: <cb06a494-3bce-0240-9a87-74a7942d4bf6@collabora.com>
On Mon, 10 Apr 2017, Enric Balletbo i Serra wrote:
>
>
> On 05/04/17 03:21, Chanwoo Choi wrote:
> > Hi Enric,
> >
> > On 2017년 03월 02일 16:29, Chanwoo Choi wrote:
> >> Hi,
> >>
> >> On 2017년 03월 01일 20:19, Enric Balletbo i Serra wrote:
> >>> From: Benson Leung <bleung@chromium.org>
> >>>
> >>> This is the driver for the USB Type C cable detection mechanism
> >>> built into the ChromeOS Embedded Controller on systems that
> >>> have USB Type-C ports.
> >>>
> >>> At present, this allows for the presence of display out, but in
> >>> future, it may also be used to notify host and device type cables
> >>> and the presence of power.
> >>>
> >>> Signed-off-by: Benson Leung <bleung@chromium.org>
> >>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >>> ---
> >>> Changes since v1:
> >>> Requested by Chanwoo Choi
> >>> - Rename files changing _ for -
> >>> - Remove the unneeded blank line on bottom of header.
> >>> - Remove kobject.h and cros_ec_commands.h includes.
> >>> - Remove the debug message as is not necessary.
> >>> - Use the tab for indentation instead of space for if sentence.
> >>> - Define each variable on different lines when the variables should be
> >>> initialized.
> >>> - Remove EXTCON_USB and EXTCON_USB_HOST as are not really used for now.
> >>> - Add one blank line to split out between state and property setting.
> >>> - Add the author information (header and module)
> >>>
> >>> Enric Balletbo
> >>> - As Rob suggested to rename the compatible name to something indicating that
> >>> is USB Type C related I also renamed the file names, extcon-cros-ec ->
> >>> extcon-usbc-cros-ec, I think it's more clear.
> >>>
> >>> drivers/extcon/Kconfig | 7 +
> >>> drivers/extcon/Makefile | 1 +
> >>> drivers/extcon/extcon-usbc-cros-ec.c | 415 +++++++++++++++++++++++++++++++++++
> >>> include/linux/mfd/cros_ec_commands.h | 75 +++++++
> >>> 4 files changed, 498 insertions(+)
> >>> create mode 100644 drivers/extcon/extcon-usbc-cros-ec.c
> >>>
> >>
> >> Looks good to me.
> >> Acked-by: Chanwoo Choi <cw00.chio@samsung.com>
> >>
> >> I think this patch should be handled with patches[1].
> >> [1] https://lkml.org/lkml/2017/2/14/655
> >>
> >> I think that one maintainer among following subsystems
> >> (mfd, chrome h/w platform, rtc and extcon)
> >> will apply their git repository, and then one maintainer
> >> will send the pull request of immutable branch for these patches.
> >>
> >
> > As I mentioned, these patch should be handled with related patches[1].
> > [1] https://lkml.org/lkml/2017/2/14/655
> >
> > So, I can't apply these patch on extcon git because there is a merge conflict
> > and we should handle these patches with immutable branch between subsystem maintainer.
> >
> > The v4.11-rc5 was released, if you want to apply this patch to the v4.12-rc1,
> > please take care of these patches.
> >
>
> Thanks, unfortunately the above patch dependency is not merged yet, I'll take
> care of these an resend this series rebased again once I have the confirmation
> of the above patch is merged or in a immutable branch.
I guess this patch will have to wait until v3.13 now.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v3 03/12] dt-bindings: make AXP20X compatible strings one per line
From: Lee Jones @ 2017-04-24 12:07 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170417115747.7300-4-icenowy-h8G6r0blFSE@public.gmane.org>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> In the binding documentation of AXP20X mfd, the compatible strings used
> to be listed for three per line, which leads to some mess when trying to
> add AXP803 compatible string (as we have already AXP806 and AXP809
> compatibles, which is after AXP803 in ascending order).
>
> Make the compatible strings one per line, so that inserting a new
> compatible string will be directly a new line.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> New patch in v3.
>
> Documentation/devicetree/bindings/mfd/axp20x.txt | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index b41d2601c6ba..a3e813f6060a 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -9,9 +9,14 @@ axp223 (X-Powers)
> axp809 (X-Powers)
>
> Required properties:
> -- compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
> - "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
> - "x-powers,axp809"
> +- compatible: should be one of:
> + * "x-powers,axp152"
> + * "x-powers,axp202"
> + * "x-powers,axp209"
> + * "x-powers,axp221"
> + * "x-powers,axp223"
> + * "x-powers,axp806"
> + * "x-powers,axp809"
> - reg: The I2C slave address or RSB hardware address for the AXP chip
> - interrupt-parent: The parent interrupt controller
> - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 04/12] dt-bindings: add device tree binding for X-Powers AXP803 PMIC
From: Lee Jones @ 2017-04-24 12:08 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170417115747.7300-5-icenowy-h8G6r0blFSE@public.gmane.org>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
> bus.
>
> Add a compatible for it.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Changes in v3:
> - Make the compatible one-liner.
> Changes in v2:
> - Place AXP803 before AXP806/809.
> - Added Chen-Yu's ACK.
>
> Documentation/devicetree/bindings/mfd/axp20x.txt | 2 ++
> 1 file changed, 2 insertions(+)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index a3e813f6060a..44df88be3c89 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -6,6 +6,7 @@ axp202 (X-Powers)
> axp209 (X-Powers)
> axp221 (X-Powers)
> axp223 (X-Powers)
> +axp803 (X-Powers)
> axp809 (X-Powers)
>
> Required properties:
> @@ -15,6 +16,7 @@ Required properties:
> * "x-powers,axp209"
> * "x-powers,axp221"
> * "x-powers,axp223"
> + * "x-powers,axp803"
> * "x-powers,axp806"
> * "x-powers,axp809"
> - reg: The I2C slave address or RSB hardware address for the AXP chip
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 05/12] mfd: axp20x: support AXP803 variant
From: Lee Jones @ 2017-04-24 12:09 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170417115747.7300-6-icenowy-h8G6r0blFSE@public.gmane.org>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> AXP803 is a new PMIC chip produced by X-Powers, usually paired with A64
> via RSB bus. The PMIC itself is like AXP288, but with RSB support and
> dedicated VBUS and ACIN.
>
> Add support for it in the axp20x mfd driver.
>
> Currently only power key function is supported.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> This patch is said to be applied by Lee Jones, however, I didn't see it
> in the linux-next, so I included it in the patchset now.
>
> Changes in v2:
> - Share regmap configs with AXP288.
> - Place AXP803 bits before AXP806/809.
>
> drivers/mfd/axp20x-rsb.c | 1 +
> drivers/mfd/axp20x.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/axp20x.h | 40 ++++++++++++++++++++++-
> 3 files changed, 119 insertions(+), 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
> index a732cb50bcff..fd5c7267b136 100644
> --- a/drivers/mfd/axp20x-rsb.c
> +++ b/drivers/mfd/axp20x-rsb.c
> @@ -61,6 +61,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
>
> static const struct of_device_id axp20x_rsb_of_match[] = {
> { .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
> + { .compatible = "x-powers,axp803", .data = (void *)AXP803_ID },
> { .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
> { .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
> { },
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index e6f55079876e..1dc6235778eb 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -41,6 +41,7 @@ static const char * const axp20x_model_names[] = {
> "AXP221",
> "AXP223",
> "AXP288",
> + "AXP803",
> "AXP806",
> "AXP809",
> };
> @@ -117,6 +118,7 @@ static const struct regmap_access_table axp22x_volatile_table = {
> .n_yes_ranges = ARRAY_SIZE(axp22x_volatile_ranges),
> };
>
> +/* AXP288 ranges are shared with the AXP803, as they cover the same range */
> static const struct regmap_range axp288_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ6_STATE),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP288_FG_TUNE5),
> @@ -264,6 +266,20 @@ static struct resource axp288_fuel_gauge_resources[] = {
> },
> };
>
> +static struct resource axp803_pek_resources[] = {
> + {
> + .name = "PEK_DBR",
> + .start = AXP803_IRQ_PEK_RIS_EDGE,
> + .end = AXP803_IRQ_PEK_RIS_EDGE,
> + .flags = IORESOURCE_IRQ,
> + }, {
> + .name = "PEK_DBF",
> + .start = AXP803_IRQ_PEK_FAL_EDGE,
> + .end = AXP803_IRQ_PEK_FAL_EDGE,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> static struct resource axp809_pek_resources[] = {
> {
> .name = "PEK_DBR",
> @@ -457,6 +473,43 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
> INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG, 5, 1),
> };
>
> +static const struct regmap_irq axp803_regmap_irqs[] = {
> + INIT_REGMAP_IRQ(AXP803, ACIN_OVER_V, 0, 7),
> + INIT_REGMAP_IRQ(AXP803, ACIN_PLUGIN, 0, 6),
> + INIT_REGMAP_IRQ(AXP803, ACIN_REMOVAL, 0, 5),
> + INIT_REGMAP_IRQ(AXP803, VBUS_OVER_V, 0, 4),
> + INIT_REGMAP_IRQ(AXP803, VBUS_PLUGIN, 0, 3),
> + INIT_REGMAP_IRQ(AXP803, VBUS_REMOVAL, 0, 2),
> + INIT_REGMAP_IRQ(AXP803, BATT_PLUGIN, 1, 7),
> + INIT_REGMAP_IRQ(AXP803, BATT_REMOVAL, 1, 6),
> + INIT_REGMAP_IRQ(AXP803, BATT_ENT_ACT_MODE, 1, 5),
> + INIT_REGMAP_IRQ(AXP803, BATT_EXIT_ACT_MODE, 1, 4),
> + INIT_REGMAP_IRQ(AXP803, CHARG, 1, 3),
> + INIT_REGMAP_IRQ(AXP803, CHARG_DONE, 1, 2),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH, 2, 7),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH_END, 2, 6),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW, 2, 5),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW_END, 2, 4),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH, 2, 3),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH_END, 2, 2),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW, 2, 1),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW_END, 2, 0),
> + INIT_REGMAP_IRQ(AXP803, DIE_TEMP_HIGH, 3, 7),
> + INIT_REGMAP_IRQ(AXP803, GPADC, 3, 2),
> + INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL1, 3, 1),
> + INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL2, 3, 0),
> + INIT_REGMAP_IRQ(AXP803, TIMER, 4, 7),
> + INIT_REGMAP_IRQ(AXP803, PEK_RIS_EDGE, 4, 6),
> + INIT_REGMAP_IRQ(AXP803, PEK_FAL_EDGE, 4, 5),
> + INIT_REGMAP_IRQ(AXP803, PEK_SHORT, 4, 4),
> + INIT_REGMAP_IRQ(AXP803, PEK_LONG, 4, 3),
> + INIT_REGMAP_IRQ(AXP803, PEK_OVER_OFF, 4, 2),
> + INIT_REGMAP_IRQ(AXP803, GPIO1_INPUT, 4, 1),
> + INIT_REGMAP_IRQ(AXP803, GPIO0_INPUT, 4, 0),
> + INIT_REGMAP_IRQ(AXP803, BC_USB_CHNG, 5, 1),
> + INIT_REGMAP_IRQ(AXP803, MV_CHNG, 5, 0),
> +};
> +
> static const struct regmap_irq axp806_regmap_irqs[] = {
> INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV1, 0, 0),
> INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV2, 0, 1),
> @@ -557,6 +610,18 @@ static const struct regmap_irq_chip axp288_regmap_irq_chip = {
>
> };
>
> +static const struct regmap_irq_chip axp803_regmap_irq_chip = {
> + .name = "axp803",
> + .status_base = AXP20X_IRQ1_STATE,
> + .ack_base = AXP20X_IRQ1_STATE,
> + .mask_base = AXP20X_IRQ1_EN,
> + .mask_invert = true,
> + .init_ack_masked = true,
> + .irqs = axp803_regmap_irqs,
> + .num_irqs = ARRAY_SIZE(axp803_regmap_irqs),
> + .num_regs = 6,
> +};
> +
> static const struct regmap_irq_chip axp806_regmap_irq_chip = {
> .name = "axp806",
> .status_base = AXP20X_IRQ1_STATE,
> @@ -778,6 +843,14 @@ static struct mfd_cell axp288_cells[] = {
> },
> };
>
> +static struct mfd_cell axp803_cells[] = {
> + {
> + .name = "axp20x-pek",
> + .num_resources = ARRAY_SIZE(axp803_pek_resources),
> + .resources = axp803_pek_resources,
> + }
> +};
> +
> static struct mfd_cell axp806_cells[] = {
> {
> .id = 2,
> @@ -864,6 +937,12 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
> axp20x->regmap_irq_chip = &axp288_regmap_irq_chip;
> axp20x->irq_flags = IRQF_TRIGGER_LOW;
> break;
> + case AXP803_ID:
> + axp20x->nr_cells = ARRAY_SIZE(axp803_cells);
> + axp20x->cells = axp803_cells;
> + axp20x->regmap_cfg = &axp288_regmap_config;
> + axp20x->regmap_irq_chip = &axp803_regmap_irq_chip;
> + break;
> case AXP806_ID:
> axp20x->nr_cells = ARRAY_SIZE(axp806_cells);
> axp20x->cells = axp806_cells;
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> index dc8798cf2a24..cde56cfe8446 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp20x.h
> @@ -20,6 +20,7 @@ enum axp20x_variants {
> AXP221_ID,
> AXP223_ID,
> AXP288_ID,
> + AXP803_ID,
> AXP806_ID,
> AXP809_ID,
> NR_AXP20X_VARIANTS,
> @@ -234,7 +235,7 @@ enum axp20x_variants {
> #define AXP22X_TS_ADC_L 0x59
> #define AXP22X_BATLOW_THRES1 0xe6
>
> -/* AXP288 specific registers */
> +/* AXP288/AXP803 specific registers */
> #define AXP288_POWER_REASON 0x02
> #define AXP288_BC_GLOBAL 0x2c
> #define AXP288_BC_VBUS_CNTL 0x2d
> @@ -475,6 +476,43 @@ enum axp288_irqs {
> AXP288_IRQ_BC_USB_CHNG,
> };
>
> +enum axp803_irqs {
> + AXP803_IRQ_ACIN_OVER_V = 1,
> + AXP803_IRQ_ACIN_PLUGIN,
> + AXP803_IRQ_ACIN_REMOVAL,
> + AXP803_IRQ_VBUS_OVER_V,
> + AXP803_IRQ_VBUS_PLUGIN,
> + AXP803_IRQ_VBUS_REMOVAL,
> + AXP803_IRQ_BATT_PLUGIN,
> + AXP803_IRQ_BATT_REMOVAL,
> + AXP803_IRQ_BATT_ENT_ACT_MODE,
> + AXP803_IRQ_BATT_EXIT_ACT_MODE,
> + AXP803_IRQ_CHARG,
> + AXP803_IRQ_CHARG_DONE,
> + AXP803_IRQ_BATT_CHG_TEMP_HIGH,
> + AXP803_IRQ_BATT_CHG_TEMP_HIGH_END,
> + AXP803_IRQ_BATT_CHG_TEMP_LOW,
> + AXP803_IRQ_BATT_CHG_TEMP_LOW_END,
> + AXP803_IRQ_BATT_ACT_TEMP_HIGH,
> + AXP803_IRQ_BATT_ACT_TEMP_HIGH_END,
> + AXP803_IRQ_BATT_ACT_TEMP_LOW,
> + AXP803_IRQ_BATT_ACT_TEMP_LOW_END,
> + AXP803_IRQ_DIE_TEMP_HIGH,
> + AXP803_IRQ_GPADC,
> + AXP803_IRQ_LOW_PWR_LVL1,
> + AXP803_IRQ_LOW_PWR_LVL2,
> + AXP803_IRQ_TIMER,
> + AXP803_IRQ_PEK_RIS_EDGE,
> + AXP803_IRQ_PEK_FAL_EDGE,
> + AXP803_IRQ_PEK_SHORT,
> + AXP803_IRQ_PEK_LONG,
> + AXP803_IRQ_PEK_OVER_OFF,
> + AXP803_IRQ_GPIO1_INPUT,
> + AXP803_IRQ_GPIO0_INPUT,
> + AXP803_IRQ_BC_USB_CHNG,
> + AXP803_IRQ_MV_CHNG,
> +};
> +
> enum axp806_irqs {
> AXP806_IRQ_DIE_TEMP_HIGH_LV1,
> AXP806_IRQ_DIE_TEMP_HIGH_LV2,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 07/12] dt-bindings: add AXP803's regulator info
From: Lee Jones @ 2017-04-24 12:09 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170417115747.7300-8-icenowy-h8G6r0blFSE@public.gmane.org>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> AXP803 have the most regulators in currently supported AXP PMICs.
>
> Add info for the regulators in the dt-bindings document.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Changes in v3:
> - Added Rob's ACK.
> Changes in v2:
> - Place AXP803 regulators before AXP806/809 ones.
>
> Documentation/devicetree/bindings/mfd/axp20x.txt | 27 ++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 44df88be3c89..aca09af66514 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -96,6 +96,33 @@ LDO_IO1 : LDO : ips-supply : GPIO 1
> RTC_LDO : LDO : ips-supply : always on
> DRIVEVBUS : Enable output : drivevbus-supply : external regulator
>
> +AXP803 regulators, type, and corresponding input supply names:
> +
> +Regulator Type Supply Name Notes
> +--------- ---- ----------- -----
> +DCDC1 : DC-DC buck : vin1-supply
> +DCDC2 : DC-DC buck : vin2-supply : poly-phase capable
> +DCDC3 : DC-DC buck : vin3-supply : poly-phase capable
> +DCDC4 : DC-DC buck : vin4-supply
> +DCDC5 : DC-DC buck : vin5-supply : poly-phase capable
> +DCDC6 : DC-DC buck : vin6-supply : poly-phase capable
> +DC1SW : On/Off Switch : : DCDC1 secondary output
> +ALDO1 : LDO : aldoin-supply : shared supply
> +ALDO2 : LDO : aldoin-supply : shared supply
> +ALDO3 : LDO : aldoin-supply : shared supply
> +DLDO1 : LDO : dldoin-supply : shared supply
> +DLDO2 : LDO : dldoin-supply : shared supply
> +DLDO3 : LDO : dldoin-supply : shared supply
> +DLDO4 : LDO : dldoin-supply : shared supply
> +ELDO1 : LDO : eldoin-supply : shared supply
> +ELDO2 : LDO : eldoin-supply : shared supply
> +ELDO3 : LDO : eldoin-supply : shared supply
> +FLDO1 : LDO : fldoin-supply : shared supply
> +FLDO2 : LDO : fldoin-supply : shared supply
> +LDO_IO0 : LDO : ips-supply : GPIO 0
> +LDO_IO1 : LDO : ips-supply : GPIO 1
> +RTC_LDO : LDO : ips-supply : always on
> +
> AXP806 regulators, type, and corresponding input supply names:
>
> Regulator Type Supply Name Notes
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2017-04-24 12:14 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-gpio@vger.kernel.org, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Rob Herring,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits
In-Reply-To: <70ffe3343c13d01737bf74e5de4898d0c0be07a0.1491405475.git-series.gregory.clement@free-electrons.com>
On Wed, Apr 5, 2017 at 5:18 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> The Armada 37xx SoCs can handle interrupt through GPIO. However it can
> only manage the edge ones.
>
> The way the interrupt are managed are classical so we can use the generic
> interrupt chip model.
>
> The only unusual "feature" is that many interrupts are connected to the
> parent interrupt controller. But we do not take advantage of this and use
> the chained irq with all of them.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
There are some issues with this patch.
First:
You need to add
select GPIOLIB_IRQCHIP
to the Kconfig entry. It's only working in your setup
because something else is selecting this for you, probably.
At all places like this:
> + u32 mask = d->mask;
(...)
> + if (on)
> + val |= mask;
> + else
> + val &= ~mask;
Isn't it simpler to just use d->mask directly in the code and skip the local
variable?
if (on)
val |= d->mask;
(...)
> +static void armada_37xx_irq_handler(struct irq_desc *desc)
> +{
> + struct gpio_chip *gc = irq_desc_get_handler_data(desc);
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct armada_37xx_pinctrl *info = gpiochip_get_data(gc);
> + struct irq_domain *d = gc->irqdomain;
> + int i;
> +
> + chained_irq_enter(chip, desc);
> + for (i = 0; i <= d->revmap_size / GPIO_PER_REG; i++) {
> + u32 status;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&info->irq_lock, flags);
> + status = readl_relaxed(info->base + IRQ_STATUS + 4 * i);
> + /* Manage only the interrupt that was enabled */
> + status &= readl_relaxed(info->base + IRQ_EN + 4 * i);
> + spin_unlock_irqrestore(&info->irq_lock, flags);
> + while (status) {
> + u32 hwirq = ffs(status) - 1;
> + u32 virq = irq_find_mapping(d, hwirq +
> + i * GPIO_PER_REG);
> +
> + generic_handle_irq(virq);
> + status &= ~BIT(hwirq);
> + }
You hae a problem here is a new IRQ appears while you are inside
of this loop. You need to re-read the status register for each iteration
(and &= with the IRQ_EN I guess).
> +static int armada_37xx_irqchip_register(struct platform_device *pdev,
> + struct armada_37xx_pinctrl *info)
> +{
> + struct device_node *np = info->dev->of_node;
> + int nrirqs = info->data->nr_pins;
> + struct gpio_chip *gc = &info->gpio_chip;
> + struct irq_chip *irqchip = &info->irq_chip;
> + struct resource res;
> + int ret = -ENODEV, i, nr_irq_parent;
> +
This warrants a comment:
/* Check if we have at least one gpio-controller child node */
> + for_each_child_of_node(info->dev->of_node, np) {
> + if (of_find_property(np, "gpio-controller", NULL)) {
> + ret = 0;
> + break;
> + }
Rewrite:
if (of_property_read_bool(np, "gpio-controller"))
> + };
> + if (ret)
> + return ret;
> +
> + nr_irq_parent = of_irq_count(np);
> + spin_lock_init(&info->irq_lock);
> +
> + if (!nr_irq_parent) {
> + dev_err(&pdev->dev, "Invalid or no IRQ\n");
> + return 0;
> + }
> +
> + if (of_address_to_resource(info->dev->of_node, 1, &res)) {
> + dev_err(info->dev, "cannot find IO resource\n");
> + return -ENOENT;
> + }
> +
> + info->base = devm_ioremap_resource(info->dev, &res);
> + if (IS_ERR(info->base))
> + return PTR_ERR(info->base);
> +
> + irqchip->irq_ack = armada_37xx_irq_ack;
> + irqchip->irq_mask = armada_37xx_irq_mask;
> + irqchip->irq_unmask = armada_37xx_irq_unmask;
> + irqchip->irq_set_wake = armada_37xx_irq_set_wake;
> + irqchip->irq_set_type = armada_37xx_irq_set_type;
> + irqchip->name = info->data->name;
> +
> + ret = gpiochip_irqchip_add(gc, irqchip, 0,
> + handle_edge_irq, IRQ_TYPE_NONE);
> + if (ret) {
> + dev_info(&pdev->dev, "could not add irqchip\n");
> + return ret;
> + }
> +
> + /*
> + * Many interrupts are connected to the parent interrupt
> + * controller. But we do not take advantage of this and use
> + * the chained irq with all of them.
> + */
> + for (i = 0; i < nrirqs; i++) {
> + struct irq_data *d = irq_get_irq_data(gc->irq_base + i);
> +
> + /*
> + * The mask field is a "precomputed bitmask for
> + * accessing the chip registers" which was introduced
> + * for the generic irqchip framework. As we don't use
> + * this framework, we can reuse this field for our own
> + * usage.
> + */
> + d->mask = BIT(i % GPIO_PER_REG);
> + }
> +
> + for (i = 0; i < nr_irq_parent; i++) {
> + int irq = irq_of_parse_and_map(np, i);
> +
> + if (irq < 0)
> + continue;
> +
> + gpiochip_set_chained_irqchip(gc, irqchip, irq,
> + armada_37xx_irq_handler);
> + }
> +
> + return 0;
> +}
> +
> static int armada_37xx_gpiochip_register(struct platform_device *pdev,
> struct armada_37xx_pinctrl *info)
> {
> @@ -496,6 +714,9 @@ static int armada_37xx_gpiochip_register(struct platform_device *pdev,
> ret = devm_gpiochip_add_data(&pdev->dev, gc, info);
> if (ret)
> return ret;
> + ret = armada_37xx_irqchip_register(pdev, info);
> + if (ret)
> + return ret;
>
> return 0;
> }
> --
> git-series 0.9.1
^ permalink raw reply
* Re: [PATCH v4 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2017-04-24 12:16 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits
In-Reply-To: <CACRpkdZ=mVXBbVf1iHg8nQ6pYUkvpB+egH+stoMrkD8V_vaYpg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
So I touched something in gmail and it shot off the mail prematurely.
My apologies.
But my review was done anyways.
Yours,
Linus Walleij
--
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 1/7] pinctrl: stm32: add possibility to use gpio-ranges to declare bank range
From: Linus Walleij @ 2017-04-24 12:20 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Rob Herring, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, Lee Jones, Jonathan Corbet,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1491568984-20169-2-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
On Fri, Apr 7, 2017 at 2:42 PM, Alexandre TORGUE
<alexandre.torgue-qxv4g6HH51o@public.gmane.org> wrote:
> Use device tree entries to declare gpio range. It will allow to use
> no contiguous gpio bank and holes inside a bank.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/4] pinctrl: stm32: replace device_initcall() with arch_initcall()
From: Linus Walleij @ 2017-04-24 12:22 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Patrice Chotard, Paul Gortmaker, Rob Herring,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <1491577811-26989-3-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 5:10 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> Pinctrl has to be registered earlier. Mainly to register bank irqdomain
> earlier as other devices could use interrupts from those irqdomain.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Yeah I also see that a lot. I guess workarounds like this is
necessary.
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 13/18] arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver
From: Corentin Labbe @ 2017-04-24 12:24 UTC (permalink / raw)
To: Maxime Ripard
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170412124153.q6zvdvqkroizaxgb@lukather>
On Wed, Apr 12, 2017 at 02:41:53PM +0200, Maxime Ripard wrote:
> On Wed, Apr 12, 2017 at 01:13:55PM +0200, Corentin Labbe wrote:
> > The dwmac-sun8i is an Ethernet MAC that supports 10/100/1000 Mbit
> > connections. It is very similar to the device found in the Allwinner
> > H3, but lacks the internal 100 Mbit PHY and its associated control
> > bits.
> > This adds the necessary bits to the Allwinner A64 SoC .dtsi, but keeps
> > it disabled at this level.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 37 +++++++++++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > index 0b0f4ab..2569827 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > @@ -287,6 +287,23 @@
> > bias-pull-up;
> > };
> >
> > + rmii_pins: rmii_pins {
> > + pins = "PD10", "PD11", "PD13", "PD14",
> > + "PD17", "PD18", "PD19", "PD20",
> > + "PD22", "PD23";
>
> Please align the wrapped lines on the first pin.
>
OK
> > + function = "emac";
> > + drive-strength = <40>;
>
> Do you actually need that for all the boards, or only a few of them?
I have tried to use lower value without success on some boards. (opipc/pine64 in my memory)
Regards
Corentin Labbe
^ permalink raw reply
* Re: [PATCH v2 2/7] Documentation: dt: Remove bindings for STM32 pinctrl
From: Linus Walleij @ 2017-04-24 12:25 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Rob Herring, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, Lee Jones, Jonathan Corbet,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1491568984-20169-3-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 2:42 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> Remove "ngpios" bindings definition as it is no more used in stm32 pinctrl
> driver.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Fixed up Subject and applied with Rob's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 4/7] pinctrl: stm32: Add STM32F469 MCU support
From: Linus Walleij @ 2017-04-24 12:27 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Rob Herring, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, Lee Jones, Jonathan Corbet,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1491568984-20169-5-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
On Fri, Apr 7, 2017 at 2:43 PM, Alexandre TORGUE
<alexandre.torgue-qxv4g6HH51o@public.gmane.org> wrote:
> This patch which adds STM32F469 pinctrl and GPIO support, relies on the
> generic STM32 pinctrl driver.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
Patch applied.
Yours,
Linus Walleij
--
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 5/7] Documentation: dt: Add new compatible to STM32 pinctrl driver bindings
From: Linus Walleij @ 2017-04-24 12:29 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Rob Herring, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, Lee Jones, Jonathan Corbet,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1491568984-20169-6-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 2:43 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> Add new compatible for stm32f469 MCU.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Fixed up subject and applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 6/7] ARM: Kconfig: Introduce MACH_STM32F469 flag
From: Linus Walleij @ 2017-04-24 12:30 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Rob Herring, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, Lee Jones, Jonathan Corbet,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1491568984-20169-7-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 2:43 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> This patch introduces the MACH_STM32F469 to make possible to only select
> STM32F469 pinctrl driver
>
> By default, all the MACH_STM32Fxxx flags will be set with STM32 defconfig.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Please funnel this through the ARM SoC tree.
Yours,
Linus Walleij
^ 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