* Re: [PATCH net-next v4 3/3] dt-bindings: net: ethernet: Update mt7622 docs and dts to reflect the new phylink API
From: Matthias Brugger @ 2019-08-29 7:03 UTC (permalink / raw)
To: David Miller
Cc: nelson.chang, frank-w, netdev, sean.wang, linux-mips, linux,
opensource, linux-mediatek, john, sr, linux-arm-kernel
In-Reply-To: <20190828.125658.1743313522645522716.davem@davemloft.net>
On 28/08/2019 21:56, David Miller wrote:
> From: Matthias Brugger <matthias.bgg@gmail.com>
> Date: Wed, 28 Aug 2019 11:29:45 +0200
>
>> Thanks for taking this patch. For the next time, please make sure that dts[i]
>> patches are independent from the binding description, as dts[i] should go
>> through my tree. No problem for this round, just saying for the future.
>
> That's not always possible nor reasonable, to be quite honest.
>
Right now no case comes to my mind. What would be a case where this is not
reasonable or possible?
Regards,
Matthias
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/3] arm: Add support for function error injection
From: Russell King - ARM Linux admin @ 2019-08-29 6:57 UTC (permalink / raw)
To: Leo Yan
Cc: Song Liu, Benjamin Herrenschmidt, Alexei Starovoitov,
Oleg Nesterov, Paul Mackerras, H. Peter Anvin, Will Deacon,
linux-arch, Daniel Borkmann, Michael Ellerman, x86,
clang-built-linux, Ingo Molnar, Catalin Marinas, Yonghong Song,
Naveen N. Rao, Arnd Bergmann, Borislav Petkov, Thomas Gleixner,
linux-arm-kernel, netdev, linux-kernel, Masami Hiramatsu, bpf,
linuxppc-dev, Martin KaFai Lau
In-Reply-To: <20190819091808.GB5599@leoy-ThinkPad-X240s>
I'm sorry, I can't apply this, it produces loads of:
include/linux/error-injection.h:7:10: fatal error: asm/error-injection.h: No such file or directory
Since your patch 1 has been merged by the ARM64 people, I can't take
it until next cycle.
On Mon, Aug 19, 2019 at 05:18:08PM +0800, Leo Yan wrote:
> Hi Russell,
>
> On Tue, Aug 06, 2019 at 06:00:15PM +0800, Leo Yan wrote:
> > This patch implements arm specific functions regs_set_return_value() and
> > override_function_with_return() to support function error injection.
> >
> > In the exception flow, it updates pt_regs::ARM_pc with pt_regs::ARM_lr
> > so can override the probed function return.
>
> Gentle ping ... Could you review this patch?
>
> Thanks,
> Leo.
>
> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > ---
> > arch/arm/Kconfig | 1 +
> > arch/arm/include/asm/ptrace.h | 5 +++++
> > arch/arm/lib/Makefile | 2 ++
> > arch/arm/lib/error-inject.c | 19 +++++++++++++++++++
> > 4 files changed, 27 insertions(+)
> > create mode 100644 arch/arm/lib/error-inject.c
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 33b00579beff..2d3d44a037f6 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -77,6 +77,7 @@ config ARM
> > select HAVE_EXIT_THREAD
> > select HAVE_FAST_GUP if ARM_LPAE
> > select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
> > + select HAVE_FUNCTION_ERROR_INJECTION if !THUMB2_KERNEL
> > select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
> > select HAVE_FUNCTION_TRACER if !XIP_KERNEL
> > select HAVE_GCC_PLUGINS
> > diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
> > index 91d6b7856be4..3b41f37b361a 100644
> > --- a/arch/arm/include/asm/ptrace.h
> > +++ b/arch/arm/include/asm/ptrace.h
> > @@ -89,6 +89,11 @@ static inline long regs_return_value(struct pt_regs *regs)
> > return regs->ARM_r0;
> > }
> >
> > +static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
> > +{
> > + regs->ARM_r0 = rc;
> > +}
> > +
> > #define instruction_pointer(regs) (regs)->ARM_pc
> >
> > #ifdef CONFIG_THUMB2_KERNEL
> > diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> > index b25c54585048..8f56484a7156 100644
> > --- a/arch/arm/lib/Makefile
> > +++ b/arch/arm/lib/Makefile
> > @@ -42,3 +42,5 @@ ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
> > CFLAGS_xor-neon.o += $(NEON_FLAGS)
> > obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o
> > endif
> > +
> > +obj-$(CONFIG_FUNCTION_ERROR_INJECTION) += error-inject.o
> > diff --git a/arch/arm/lib/error-inject.c b/arch/arm/lib/error-inject.c
> > new file mode 100644
> > index 000000000000..2d696dc94893
> > --- /dev/null
> > +++ b/arch/arm/lib/error-inject.c
> > @@ -0,0 +1,19 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#include <linux/error-injection.h>
> > +#include <linux/kprobes.h>
> > +
> > +void override_function_with_return(struct pt_regs *regs)
> > +{
> > + /*
> > + * 'regs' represents the state on entry of a predefined function in
> > + * the kernel/module and which is captured on a kprobe.
> > + *
> > + * 'regs->ARM_lr' contains the the link register for the probed
> > + * function, when kprobe returns back from exception it will override
> > + * the end of probed function and directly return to the predefined
> > + * function's caller.
> > + */
> > + instruction_pointer_set(regs, regs->ARM_lr);
> > +}
> > +NOKPROBE_SYMBOL(override_function_with_return);
> > --
> > 2.17.1
> >
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [arm:for-next 13/25] include/linux/error-injection.h:7:10: fatal error: asm/error-injection.h: No such file or directory
From: Leo Yan @ 2019-08-29 6:43 UTC (permalink / raw)
To: kbuild test robot; +Cc: Russell King, Will Deacon, kbuild-all, linux-arm-kernel
In-Reply-To: <201908290809.FsnDYulr%lkp@intel.com>
Hi Russell,
On Thu, Aug 29, 2019 at 08:49:16AM +0800, kbuild test robot wrote:
> tree: git://git.armlinux.org.uk/~rmk/linux-arm.git for-next
> head: d0d54dc04e37be14a9e51d9a2e431f302948e99d
> commit: 566c290c6498b2fdc04a54556c4e8747f0298c7b [13/25] ARM: 8899/1: arm/arm64: Add support for function error injection
> config: arm-allmodconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 566c290c6498b2fdc04a54556c4e8747f0298c7b
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=arm
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> In file included from include/linux/module.h:22:0,
> from drivers/pps/pps.c:11:
> >> include/linux/error-injection.h:7:10: fatal error: asm/error-injection.h: No such file or directory
> #include <asm/error-injection.h>
> ^~~~~~~~~~~~~~~~~~~~~~~
> compilation terminated.
This building error is caused by there have a dependent patch:
error-injection: Consolidate override function definition
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?h=for-next/error-injection&id=45880f7b7b19e043ce0aaa4cb7d05369425c82fa
This patch has been picked up by Will in one of arm64's next branch:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/error-injection
I don't know what's the best practice for the dependency between
two branches, if need me to follow up anything, please let me know.
Thanks,
Leo.
> vim +7 include/linux/error-injection.h
>
> 540adea3809f61 Masami Hiramatsu 2018-01-13 6
> 540adea3809f61 Masami Hiramatsu 2018-01-13 @7 #include <asm/error-injection.h>
> 540adea3809f61 Masami Hiramatsu 2018-01-13 8
>
> :::::: The code at line 7 was first introduced by commit
> :::::: 540adea3809f61115d2a1ea4ed6e627613452ba1 error-injection: Separate error-injection from kprobe
>
> :::::: TO: Masami Hiramatsu <mhiramat@kernel.org>
> :::::: CC: Alexei Starovoitov <ast@kernel.org>
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: Emit __gnu_mcount_nc when using Clang 10.0.0 or newer
From: Nathan Chancellor @ 2019-08-29 6:26 UTC (permalink / raw)
To: Russell King
Cc: Arnd Bergmann, Nick Desaulniers, linux-kernel, Stefan Agner,
clang-built-linux, Matthias Kaehlcke, Nathan Chancellor,
linux-arm-kernel
Currently, multi_v7_defconfig + CONFIG_FUNCTION_TRACER fails to build
with clang:
arm-linux-gnueabi-ld: kernel/softirq.o: in function `_local_bh_enable':
softirq.c:(.text+0x504): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `__local_bh_enable_ip':
softirq.c:(.text+0x58c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `do_softirq':
softirq.c:(.text+0x6c8): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_enter':
softirq.c:(.text+0x75c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_exit':
softirq.c:(.text+0x840): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o:softirq.c:(.text+0xa50): more undefined references to `mcount' follow
clang can emit a working mcount symbol, __gnu_mcount_nc, when
'-meabi gnu' is passed to it. Until r369147 in LLVM, this was
broken and caused the kernel not to boot because the calling
convention was not correct. Now that it is fixed, add this to
the command line when clang is 10.0.0 or newer so everything
works properly.
Link: https://github.com/ClangBuiltLinux/linux/issues/35
Link: https://bugs.llvm.org/show_bug.cgi?id=33845
Link: https://github.com/llvm/llvm-project/commit/16fa8b09702378bacfa3d07081afe6b353b99e60
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
arch/arm/Makefile | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c3624ca6c0bc..7b5a26a866fc 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -112,6 +112,12 @@ ifeq ($(CONFIG_ARM_UNWIND),y)
CFLAGS_ABI +=-funwind-tables
endif
+ifeq ($(CONFIG_CC_IS_CLANG),y)
+ifeq ($(shell test $(CONFIG_CLANG_VERSION) -ge 100000; echo $$?),0)
+CFLAGS_ABI +=-meabi gnu
+endif
+endif
+
# Accept old syntax despite ".syntax unified"
AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: Aw: Re: [BUG] [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver
From: Hsin-hsiung Wang @ 2019-08-29 6:24 UTC (permalink / raw)
To: Frank Wunderlich, Matthias Brugger
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Greg Kroah-Hartman, Mark Brown, Sean Wang,
Liam Girdwood, linux-kernel, Richard Fontana, Rob Herring,
linux-mediatek, Kate Stewart, "René van Dorst",
Thomas Gleixner, Eddie Huang, Lee Jones, linux-arm-kernel,
linux-rtc
In-Reply-To: <trinity-a57f08bb-e30e-4e74-911c-c40e335d00da-1566580580817@3c-app-gmx-bs75>
Hi Frank/Matthias,
On Fri, 2019-08-23 at 19:16 +0200, Frank Wunderlich wrote:
> > Gesendet: Freitag, 23. August 2019 um 17:42 Uhr
> > Von: "Matthias Brugger" <matthias.bgg@gmail.com>
>
> > I suppose that's because 3/10 has code that should be in 2/10 and for some
> > reason 3/10 was not pushed for linux-next inclusion. Although it has the same
> > Acked-for-mfd-by tag.
> >
> > @Frank, can you test if adding 3/10 to your code base fixes the issue?
>
> adding part 3 [1] seems to fix the issue too
>
> [ 4.960051] mt6323-regulator mt6323-regulator: Chip ID = 0x2023
>
> thanks
>
> [1] https://patchwork.kernel.org/patch/11110509/
Thanks for your comments.
The root cause seems I didn't split the code well.
I will fix it in the next version.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
From: Jurgen Lambrecht @ 2019-08-29 6:23 UTC (permalink / raw)
To: Robin Gong, Leonard Crestez
Cc: Aisheng Dong, dl-linux-imx, linux-arm-kernel@lists.infradead.org
In-Reply-To: <VE1PR04MB663818AE90C9997DC340250989A30@VE1PR04MB6638.eurprd04.prod.outlook.com>
On 8/28/19 4:05 PM, Robin Gong wrote:
> Could you help check if below commit in your side?
> commit ebb853b1bd5f659b92c71dc6a9de44cfc37c78c0
> Author: Lucas Stach<l.stach@pengutronix.de>
> Date: Tue Nov 6 03:40:28 2018 +0000
yes, it's in.
Also the 2 follow-up commits of Lucas Stach:
9063f5a99ea76f85935e3e453422d15e7be89b9e and
374f384bc66f7a928f11eb20c0518f0f3fc1ffd6.
And that are the last commits on drivers/dma/imx-sdma.c for my
4.19.x+fslc branch. But I have already tried 5.1.x+fslc, and it also got
stuck.
Kind regards,
Jürgen
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 07/10] regulator: mt6358: Add support for MT6358 regulator
From: Hsin-hsiung Wang @ 2019-08-29 6:09 UTC (permalink / raw)
To: Mark Brown
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Greg Kroah-Hartman, Sean Wang, Liam Girdwood,
linux-kernel, Richard Fontana, Rob Herring, linux-mediatek,
linux-arm-kernel, Matthias Brugger, Thomas Gleixner, Eddie Huang,
Lee Jones, Kate Stewart, linux-rtc
In-Reply-To: <20190828104555.GE4298@sirena.co.uk>
Hi Mark,
On Wed, 2019-08-28 at 11:45 +0100, Mark Brown wrote:
> On Fri, Aug 23, 2019 at 11:45:28AM +0800, Hsin-Hsiung Wang wrote:
> > The MT6358 is a regulator found on boards based on MediaTek MT8183 and
> > probably other SoCs. It is a so called pmic and connects as a slave to
> > SoC using SPI, wrapped inside the pmic-wrapper.
>
> This looks good - since there was only one small issue with the example
> in the binding document I'll apply both patches, please send a followup
> fixing the binding document.
Thanks for your comment.
I will update the binding document in the next patch.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 2/2] clk: imx: disable i.mx7ulp composite clock during initialization
From: Anson Huang @ 2019-08-29 5:52 UTC (permalink / raw)
To: Stephen Boyd, festevam@gmail.com, gustavo@embeddedor.com,
kernel@pengutronix.de, linux-arm-kernel@lists.infradead.org,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
mturquette@baylibre.com, s.hauer@pengutronix.de,
shawnguo@kernel.org, Aisheng Dong
Cc: dl-linux-imx
In-Reply-To: <DB3PR0402MB3916F96CD6F3E874204E6972F5D50@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Hi, Stephen
> Subject: RE: [PATCH 2/2] clk: imx: disable i.mx7ulp composite clock during
> initialization
>
> Hi, Stephen
> I think we should resume this thread, without this patch, mainline
> kernel boot up will cause mmc timeout all the time. If it is NOT good to
> disabling those peripheral devices' clock in i.MX7ULP's clock driver, then we
> have to change the core framework to disable clock explicitly if the
> CLK_SET_RATE_GATE/CLK_SET_PARENT_GATE is present, most likely it will
> impact other platforms I think, so the most safe way is just to do it inside our
> i.MX7ULP composite clock driver. What do you think?
What is your opinion on this?
Thanks,
Anson
>
> Thanks,
> Anson
>
> > Hi, Stephen
> >
> > > Quoting Anson Huang (2019-04-24 22:19:12)
> > > > i.MX7ULP peripheral clock ONLY allow parent/rate to be changed
> > > > with clock gated, however, during clock tree initialization, the
> > > > peripheral clock could be enabled by bootloader, but the prepare
> > > > count in clock tree is still zero, so clock core driver will allow
> > > > parent/rate changed even with
> > CLK_SET_RATE_GATE/CLK_SET_PARENT_GATE
> > >
> > > That's a bug. Can you send a patch to fix the core framework code to
> > > fail an assigned rate or parent change if those flags are set? Or is
> > > that because the core doesn't respect these flags when they're
> > > buried in the middle of the clk tree and some rate or parent change
> > > comes in and affects the middle of the tree that has the flag set on it?
> >
> > If changing the core framework code to return fail for clk parent/rate
> > assignment, that means clk assignment in DT will NOT work for
> > i.MX7ULP, then all the clk rate/parent settings will be done in
> > driver? That will lead to more issues/changes.
> >
> > It is just because core framework ONLY checks the prepare_count and
> > CLK_SET_PARENT_GATE flag to determine if the parent switch is allowed,
> > however, during clock tree initialization, the prepare_count is always
> > 0 but the HW status could be enabled actually, so the core framework
> > will allow the parent switch while HW status does NOT allow the parent
> > switch, so core framework will treat the parent switch successfully but HW
> is actually NOT.
> >
> > I think we can treat it as platform specific issue, if bootloader can
> > guarantee all peripheral clocks are disabled before jumping to kernel,
> > then there will be no issue, but we can NOT assume that, so I have to
> > find some place in early kernel phase to disable those peripheral clocks.
> >
> > >
> > > > set, but the change will fail due to HW NOT allow parent/rate
> > > > change with clock enabled. It will cause clock HW status mismatch
> > > > with clock tree info and lead to function issue. Below is an example:
> > > >
> > > > usdhc0's pcc clock value is 0xC5000000 during kernel boot up, it
> > > > means
> > > > usdhc0 clock is enabled, its parent is APLL_PFD1. In DT file, the
> > > > usdhc0 clock settings are as below:
> > > >
> > > > assigned-clocks = <&pcc2 IMX7ULP_CLK_USDHC0>;
> > > > assigned-clock-parents =
> > > > <&scg1 IMX7ULP_CLK_NIC1_DIV>;
> > > >
> > > > when kernel boot up, the clock tree info is as below, but the
> > > > usdhc0 PCC register is still 0xC5000000, which means its parent is
> > > > still from APLL_PFD1, which is incorrect and cause usdhc0 NOT work.
> > > >
> > > > nic1_clk 2 2 0 176000000 0 0 50000
> > > > usdhc0 0 0 0 176000000 0 0 50000
> > > >
> > > > After making sure the peripheral clock is disabled during clock
> > > > tree initialization, the usdhc0 is working, and this change is
> > > > necessary for all i.MX7ULP peripheral clocks.
> > > >
> > > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > > > ---
> > > > drivers/clk/imx/clk-composite-7ulp.c | 13 +++++++++++++
> > > > 1 file changed, 13 insertions(+)
> > > >
> > > > diff --git a/drivers/clk/imx/clk-composite-7ulp.c
> > > > b/drivers/clk/imx/clk-composite-7ulp.c
> > > > index 060f860..1a05411 100644
> > > > --- a/drivers/clk/imx/clk-composite-7ulp.c
> > > > +++ b/drivers/clk/imx/clk-composite-7ulp.c
> > > > @@ -32,6 +32,7 @@ struct clk_hw *imx7ulp_clk_composite(const char
> > > *name,
> > > > struct clk_gate *gate = NULL;
> > > > struct clk_mux *mux = NULL;
> > > > struct clk_hw *hw;
> > > > + u32 val;
> > > >
> > > > if (mux_present) {
> > > > mux = kzalloc(sizeof(*mux), GFP_KERNEL); @@ -70,6
> > > > +71,18 @@ struct clk_hw *imx7ulp_clk_composite(const char *name,
> > > > gate_hw = &gate->hw;
> > > > gate->reg = reg;
> > > > gate->bit_idx = PCG_CGC_SHIFT;
> > > > + /*
> > > > + * make sure clock is gated during clock tree initialization,
> > > > + * the HW ONLY allow clock parent/rate changed
> > > > + with clock
> > gated,
> > > > + * during clock tree initialization, clocks could be enabled
> > > > + * by bootloader, so the HW status will mismatch with clock
> tree
> > > > + * prepare count, then clock core driver will allow parent/rate
> > > > + * change since the prepare count is zero, but HW actually
> > > > + * prevent the parent/rate change due to the clock is enabled.
> > > > + */
> > >
> > > Is it OK to forcibly gate the clk like this at init time? If so, why
> > > can't we force the clk off when we change the rate and then restore
> > > the on state after changing the rate? That would be more "robust"
> > > than doing it once here. Plus then we could remove the
> > > CLK_SET_RATE_GATE
> > flag.
> >
> > Yes, it is ONLY for composite clocks which are for peripheral clocks,
> > ONLY earlycon could be impacted but we can add
> > imx_register_uart_clocks() call to make earlycon also work.
> >
> > Forcing the clk off and restore them ON for rate/parent change will
> > need to change common composite clock ops, currently i.MX7ULP all use
> > common ops, so unless i.MX7ULP implements composite clock ops, and the
> > change will be very significant.
> >
> > Thanks,
> > Anson
> >
> > >
> > > > + val = readl_relaxed(reg);
> > > > + val &= ~(1 << PCG_CGC_SHIFT);
> > > > + writel_relaxed(val, reg);
> > > > }
> > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 09/10] rtc: mt6397: fix alarm register overwrite
From: Hsin-hsiung Wang @ 2019-08-29 5:34 UTC (permalink / raw)
To: Matthias Brugger
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Greg Kroah-Hartman, Ran Bi, Sean Wang, Liam Girdwood,
Rob Herring, linux-kernel, Richard Fontana, Mark Brown,
linux-mediatek, Kate Stewart, Thomas Gleixner, Eddie Huang,
Lee Jones, linux-arm-kernel, linux-rtc
In-Reply-To: <bf8435a7-db97-5ed8-bccc-9d197396aeb6@gmail.com>
Hi Matthias,
On Fri, 2019-08-23 at 17:35 +0200, Matthias Brugger wrote:
>
> On 23/08/2019 05:45, Hsin-Hsiung Wang wrote:
> > From: Ran Bi <ran.bi@mediatek.com>
> >
> > Alarm registers high byte was reserved for other functions.
> > This add mask in alarm registers operation functions.
> > This also fix error condition in interrupt handler.
> >
> > Fixes: fc2979118f3f ("rtc: mediatek: Add MT6397 RTC driver")
> >
> > Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > Signed-off-by: Ran Bi <ran.bi@mediatek.com>
>
> Misses your Signed-off-by.
>
I will add it in the next patch, thanks.
> Regards,
> Matthias
>
> > ---
> > drivers/rtc/rtc-mt6397.c | 47 +++++++++++++++++++++++++++++++++--------------
> > 1 file changed, 33 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
> > index b46ed4d..828def7 100644
> > --- a/drivers/rtc/rtc-mt6397.c
> > +++ b/drivers/rtc/rtc-mt6397.c
> > @@ -47,6 +47,14 @@
> >
> > #define RTC_AL_SEC 0x0018
> >
> > +#define RTC_AL_SEC_MASK 0x003f
> > +#define RTC_AL_MIN_MASK 0x003f
> > +#define RTC_AL_HOU_MASK 0x001f
> > +#define RTC_AL_DOM_MASK 0x001f
> > +#define RTC_AL_DOW_MASK 0x0007
> > +#define RTC_AL_MTH_MASK 0x000f
> > +#define RTC_AL_YEA_MASK 0x007f
> > +
> > #define RTC_PDN2 0x002e
> > #define RTC_PDN2_PWRON_ALARM BIT(4)
> >
> > @@ -103,7 +111,7 @@ static irqreturn_t mtk_rtc_irq_handler_thread(int irq, void *data)
> > irqen = irqsta & ~RTC_IRQ_EN_AL;
> > mutex_lock(&rtc->lock);
> > if (regmap_write(rtc->regmap, rtc->addr_base + RTC_IRQ_EN,
> > - irqen) < 0)
> > + irqen) == 0)
> > mtk_rtc_write_trigger(rtc);
> > mutex_unlock(&rtc->lock);
> >
> > @@ -225,12 +233,12 @@ static int mtk_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
> > alm->pending = !!(pdn2 & RTC_PDN2_PWRON_ALARM);
> > mutex_unlock(&rtc->lock);
> >
> > - tm->tm_sec = data[RTC_OFFSET_SEC];
> > - tm->tm_min = data[RTC_OFFSET_MIN];
> > - tm->tm_hour = data[RTC_OFFSET_HOUR];
> > - tm->tm_mday = data[RTC_OFFSET_DOM];
> > - tm->tm_mon = data[RTC_OFFSET_MTH];
> > - tm->tm_year = data[RTC_OFFSET_YEAR];
> > + tm->tm_sec = data[RTC_OFFSET_SEC] & RTC_AL_SEC_MASK;
> > + tm->tm_min = data[RTC_OFFSET_MIN] & RTC_AL_MIN_MASK;
> > + tm->tm_hour = data[RTC_OFFSET_HOUR] & RTC_AL_HOU_MASK;
> > + tm->tm_mday = data[RTC_OFFSET_DOM] & RTC_AL_DOM_MASK;
> > + tm->tm_mon = data[RTC_OFFSET_MTH] & RTC_AL_MTH_MASK;
> > + tm->tm_year = data[RTC_OFFSET_YEAR] & RTC_AL_YEA_MASK;
> >
> > tm->tm_year += RTC_MIN_YEAR_OFFSET;
> > tm->tm_mon--;
> > @@ -251,14 +259,25 @@ static int mtk_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
> > tm->tm_year -= RTC_MIN_YEAR_OFFSET;
> > tm->tm_mon++;
> >
> > - data[RTC_OFFSET_SEC] = tm->tm_sec;
> > - data[RTC_OFFSET_MIN] = tm->tm_min;
> > - data[RTC_OFFSET_HOUR] = tm->tm_hour;
> > - data[RTC_OFFSET_DOM] = tm->tm_mday;
> > - data[RTC_OFFSET_MTH] = tm->tm_mon;
> > - data[RTC_OFFSET_YEAR] = tm->tm_year;
> > -
> > mutex_lock(&rtc->lock);
> > + ret = regmap_bulk_read(rtc->regmap, rtc->addr_base + RTC_AL_SEC,
> > + data, RTC_OFFSET_COUNT);
> > + if (ret < 0)
> > + goto exit;
> > +
> > + data[RTC_OFFSET_SEC] = ((data[RTC_OFFSET_SEC] & ~(RTC_AL_SEC_MASK)) |
> > + (tm->tm_sec & RTC_AL_SEC_MASK));
> > + data[RTC_OFFSET_MIN] = ((data[RTC_OFFSET_MIN] & ~(RTC_AL_MIN_MASK)) |
> > + (tm->tm_min & RTC_AL_MIN_MASK));
> > + data[RTC_OFFSET_HOUR] = ((data[RTC_OFFSET_HOUR] & ~(RTC_AL_HOU_MASK)) |
> > + (tm->tm_hour & RTC_AL_HOU_MASK));
> > + data[RTC_OFFSET_DOM] = ((data[RTC_OFFSET_DOM] & ~(RTC_AL_DOM_MASK)) |
> > + (tm->tm_mday & RTC_AL_DOM_MASK));
> > + data[RTC_OFFSET_MTH] = ((data[RTC_OFFSET_MTH] & ~(RTC_AL_MTH_MASK)) |
> > + (tm->tm_mon & RTC_AL_MTH_MASK));
> > + data[RTC_OFFSET_YEAR] = ((data[RTC_OFFSET_YEAR] & ~(RTC_AL_YEA_MASK)) |
> > + (tm->tm_year & RTC_AL_YEA_MASK));
> > +
> > if (alm->enabled) {
> > ret = regmap_bulk_write(rtc->regmap,
> > rtc->addr_base + RTC_AL_SEC,
> >
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 13/13] arm64: dts: Add power controller device node of MT8183
From: CK Hu @ 2019-08-29 5:15 UTC (permalink / raw)
To: Weiyi Lu
Cc: Rob Herring, Nicolas Boichat, srv_heupstream, James Liao,
linux-kernel, Fan Chen, linux-mediatek, linux-arm-kernel,
Matthias Brugger, Yong Wu
In-Reply-To: <1566983506-26598-14-git-send-email-weiyi.lu@mediatek.com>
Hi, Weiyi:
On Wed, 2019-08-28 at 17:11 +0800, Weiyi Lu wrote:
> Add power controller node and smi-common node for MT8183
> In scpsys node, it contains clocks and regmapping of
> infracfg and smi-common for bus protection.
>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> ---
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 62 ++++++++++++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index c2749c4..66aaa07 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -8,6 +8,7 @@
> #include <dt-bindings/clock/mt8183-clk.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/power/mt8183-power.h>
> #include "mt8183-pinfunc.h"
>
> / {
> @@ -238,6 +239,62 @@
> #interrupt-cells = <2>;
> };
>
> + scpsys: syscon@10006000 {
> + compatible = "mediatek,mt8183-scpsys", "syscon";
> + #power-domain-cells = <1>;
> + reg = <0 0x10006000 0 0x1000>;
> + clocks = <&topckgen CLK_TOP_MUX_AUD_INTBUS>,
> + <&infracfg CLK_INFRA_AUDIO>,
> + <&infracfg CLK_INFRA_AUDIO_26M_BCLK>,
> + <&topckgen CLK_TOP_MUX_MFG>,
> + <&topckgen CLK_TOP_MUX_MM>,
> + <&topckgen CLK_TOP_MUX_CAM>,
> + <&topckgen CLK_TOP_MUX_IMG>,
> + <&topckgen CLK_TOP_MUX_IPU_IF>,
> + <&topckgen CLK_TOP_MUX_DSP>,
> + <&topckgen CLK_TOP_MUX_DSP1>,
> + <&topckgen CLK_TOP_MUX_DSP2>,
> + <&mmsys CLK_MM_SMI_COMMON>,
> + <&mmsys CLK_MM_SMI_LARB0>,
> + <&mmsys CLK_MM_SMI_LARB1>,
> + <&mmsys CLK_MM_GALS_COMM0>,
> + <&mmsys CLK_MM_GALS_COMM1>,
> + <&mmsys CLK_MM_GALS_CCU2MM>,
> + <&mmsys CLK_MM_GALS_IPU12MM>,
> + <&mmsys CLK_MM_GALS_IMG2MM>,
> + <&mmsys CLK_MM_GALS_CAM2MM>,
> + <&mmsys CLK_MM_GALS_IPU2MM>,
Just mention the discussion in [1], we need to confirm this is hardware
limitation or not.
[1] https://patchwork.kernel.org/patch/11005731/
Regards,
CK
> + <&imgsys CLK_IMG_LARB5>,
> + <&imgsys CLK_IMG_LARB2>,
> + <&camsys CLK_CAM_LARB6>,
> + <&camsys CLK_CAM_LARB3>,
> + <&camsys CLK_CAM_SENINF>,
> + <&camsys CLK_CAM_CAMSV0>,
> + <&camsys CLK_CAM_CAMSV1>,
> + <&camsys CLK_CAM_CAMSV2>,
> + <&camsys CLK_CAM_CCU>,
> + <&ipu_conn CLK_IPU_CONN_IPU>,
> + <&ipu_conn CLK_IPU_CONN_AHB>,
> + <&ipu_conn CLK_IPU_CONN_AXI>,
> + <&ipu_conn CLK_IPU_CONN_ISP>,
> + <&ipu_conn CLK_IPU_CONN_CAM_ADL>,
> + <&ipu_conn CLK_IPU_CONN_IMG_ADL>;
> + clock-names = "audio", "audio1", "audio2",
> + "mfg", "mm", "cam",
> + "isp", "vpu", "vpu1",
> + "vpu2", "vpu3", "mm-0",
> + "mm-1", "mm-2", "mm-3",
> + "mm-4", "mm-5", "mm-6",
> + "mm-7", "mm-8", "mm-9",
> + "isp-0", "isp-1", "cam-0",
> + "cam-1", "cam-2", "cam-3",
> + "cam-4", "cam-5", "cam-6",
> + "vpu-0", "vpu-1", "vpu-2",
> + "vpu-3", "vpu-4", "vpu-5";
> + infracfg = <&infracfg>;
> + smi_comm = <&smi_common>;
> + };
> +
> apmixedsys: syscon@1000c000 {
> compatible = "mediatek,mt8183-apmixedsys", "syscon";
> reg = <0 0x1000c000 0 0x1000>;
> @@ -396,6 +453,11 @@
> #clock-cells = <1>;
> };
>
> + smi_common: smi@14019000 {
> + compatible = "mediatek,mt8183-smi-common", "syscon";
> + reg = <0 0x14019000 0 0x1000>;
> + };
> +
> imgsys: syscon@15020000 {
> compatible = "mediatek,mt8183-imgsys", "syscon";
> reg = <0 0x15020000 0 0x1000>;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 07/10] PCI: layerscape: Modify the MSIX to the doorbell way
From: Kishon Vijay Abraham I @ 2019-08-29 5:13 UTC (permalink / raw)
To: Andrew Murray, Xiaowei Bao, gustavo.pimentel@synopsys.com
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.co,
arnd@arndb.de, devicetree@vger.kernel.org,
gregkh@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
M.h. Lian, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, jingoohan1@gmail.com,
bhelgaas@google.com, shawnguo@kernel.org, Mingkai Hu
In-Reply-To: <20190827132504.GL14582@e119886-lin.cambridge.arm.com>
Gustavo,
On 27/08/19 6:55 PM, Andrew Murray wrote:
> On Sat, Aug 24, 2019 at 12:08:40AM +0000, Xiaowei Bao wrote:
>>
>>
>>> -----Original Message-----
>>> From: Andrew Murray <andrew.murray@arm.com>
>>> Sent: 2019年8月23日 21:58
>>> To: Xiaowei Bao <xiaowei.bao@nxp.com>
>>> Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
>>> shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
>>> lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org; M.h.
>>> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
>>> Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
>>> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
>>> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
>>> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
>>> Subject: Re: [PATCH v2 07/10] PCI: layerscape: Modify the MSIX to the
>>> doorbell way
>>>
>>> On Thu, Aug 22, 2019 at 07:22:39PM +0800, Xiaowei Bao wrote:
>>>> The layerscape platform use the doorbell way to trigger MSIX interrupt
>>>> in EP mode.
>>>>
>>>
>>> I have no problems with this patch, however...
>>>
>>> Are you able to add to this message a reason for why you are making this
>>> change? Did dw_pcie_ep_raise_msix_irq not work when func_no != 0? Or did
>>> it work yet dw_pcie_ep_raise_msix_irq_doorbell is more efficient?
>>
>> The fact is that, this driver is verified in ls1046a platform of NXP before, and ls1046a don't
>> support MSIX feature, so I set the msix_capable of pci_epc_features struct is false,
>> but in other platform, e.g. ls1088a, it support the MSIX feature, I verified the MSIX
>> feature in ls1088a, it is not OK, so I changed to another way. Thanks.
>
> Right, so the existing pci-layerscape-ep.c driver never supported MSIX yet it
> erroneously had a switch case statement to call dw_pcie_ep_raise_msix_irq which
> would never get used.
>
> Now that we're adding a platform with MSIX support the existing
> dw_pcie_ep_raise_msix_irq doesn't work (for this platform) so we are adding a
> different method.
Gustavo, can you confirm dw_pcie_ep_raise_msix_irq() works for designware as it
didn't work for both me and Xiaowei?
Thanks
Kishon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] gpio: iproc-gpio: Handle interrupts for multiple instances
From: Srinath Mannam @ 2019-08-29 4:52 UTC (permalink / raw)
To: Linus Walleij, Ray Jui, Scott Branden
Cc: Rayagonda Kokatanur, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel
In-Reply-To: <1567054348-19685-1-git-send-email-srinath.mannam@broadcom.com>
From: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
When multiple instance of iproc-gpio chips are present, a fix up
message[1] is printed during the probe of second and later instances.
This issue is because driver sharing same irq_chip data structure
among multiple instances of driver.
Fix this by allocating irq_chip data structure per instance of
iproc-gpio.
[1] fix up message addressed by this patch
[ 7.862208] gpio gpiochip2: (689d0000.gpio): detected irqchip that
is shared with multiple gpiochips: please fix the driver.
Fixes: 616043d58a89 ("pinctrl: Rename gpio driver from cygnus to iproc")
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index 20b9864..8729f47 100644
--- a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -114,6 +114,7 @@ struct iproc_gpio {
raw_spinlock_t lock;
+ struct irq_chip irqchip;
struct gpio_chip gc;
unsigned num_banks;
@@ -302,14 +303,6 @@ static int iproc_gpio_irq_set_type(struct irq_data *d, unsigned int type)
return 0;
}
-static struct irq_chip iproc_gpio_irq_chip = {
- .name = "bcm-iproc-gpio",
- .irq_ack = iproc_gpio_irq_ack,
- .irq_mask = iproc_gpio_irq_mask,
- .irq_unmask = iproc_gpio_irq_unmask,
- .irq_set_type = iproc_gpio_irq_set_type,
-};
-
/*
* Request the Iproc IOMUX pinmux controller to mux individual pins to GPIO
*/
@@ -875,14 +868,22 @@ static int iproc_gpio_probe(struct platform_device *pdev)
/* optional GPIO interrupt support */
irq = platform_get_irq(pdev, 0);
if (irq) {
- ret = gpiochip_irqchip_add(gc, &iproc_gpio_irq_chip, 0,
+ chip->irqchip.name = "bcm-iproc-gpio";
+ chip->irqchip.irq_ack = iproc_gpio_irq_ack;
+ chip->irqchip.irq_mask = iproc_gpio_irq_mask;
+ chip->irqchip.irq_unmask = iproc_gpio_irq_unmask;
+ chip->irqchip.irq_set_type = iproc_gpio_irq_set_type;
+ chip->irqchip.irq_enable = iproc_gpio_irq_unmask;
+ chip->irqchip.irq_disable = iproc_gpio_irq_mask;
+
+ ret = gpiochip_irqchip_add(gc, &chip->irqchip, 0,
handle_simple_irq, IRQ_TYPE_NONE);
if (ret) {
dev_err(dev, "no GPIO irqchip\n");
goto err_rm_gpiochip;
}
- gpiochip_set_chained_irqchip(gc, &iproc_gpio_irq_chip, irq,
+ gpiochip_set_chained_irqchip(gc, &chip->irqchip, irq,
iproc_gpio_irq_handler);
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] gpio: iproc-gpio: Fix incorrect pinconf configurations
From: Srinath Mannam @ 2019-08-29 4:52 UTC (permalink / raw)
To: Linus Walleij, Ray Jui, Scott Branden
Cc: Li Jin, bcm-kernel-feedback-list, linux-kernel, linux-arm-kernel
In-Reply-To: <1567054348-19685-1-git-send-email-srinath.mannam@broadcom.com>
From: Li Jin <li.jin@broadcom.com>
Fix drive strength for AON/CRMU controller; fix pull-up/down setting
for CCM/CDRU controller.
Fixes: 616043d58a89 ("pinctrl: Rename gpio driver from cygnus to iproc")
Signed-off-by: Li Jin <li.jin@broadcom.com>
---
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 96 +++++++++++++++++++++++++-------
1 file changed, 77 insertions(+), 19 deletions(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index b70058c..20b9864 100644
--- a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -54,8 +54,12 @@
/* drive strength control for ASIU GPIO */
#define IPROC_GPIO_ASIU_DRV0_CTRL_OFFSET 0x58
-/* drive strength control for CCM/CRMU (AON) GPIO */
-#define IPROC_GPIO_DRV0_CTRL_OFFSET 0x00
+/* pinconf for CCM GPIO */
+#define IPROC_GPIO_PULL_DN_OFFSET 0x10
+#define IPROC_GPIO_PULL_UP_OFFSET 0x14
+
+/* pinconf for CRMU(aon) GPIO and CCM GPIO*/
+#define IPROC_GPIO_DRV_CTRL_OFFSET 0x00
#define GPIO_BANK_SIZE 0x200
#define NGPIOS_PER_BANK 32
@@ -76,6 +80,12 @@ enum iproc_pinconf_param {
IPROC_PINCON_MAX,
};
+enum iproc_pinconf_ctrl_type {
+ IOCTRL_TYPE_AON = 1,
+ IOCTRL_TYPE_CDRU,
+ IOCTRL_TYPE_INVALID,
+};
+
/*
* Iproc GPIO core
*
@@ -100,6 +110,7 @@ struct iproc_gpio {
void __iomem *base;
void __iomem *io_ctrl;
+ enum iproc_pinconf_ctrl_type io_ctrl_type;
raw_spinlock_t lock;
@@ -461,20 +472,44 @@ static const struct pinctrl_ops iproc_pctrl_ops = {
static int iproc_gpio_set_pull(struct iproc_gpio *chip, unsigned gpio,
bool disable, bool pull_up)
{
+ void __iomem *base;
unsigned long flags;
+ unsigned int shift;
+ u32 val_1, val_2;
raw_spin_lock_irqsave(&chip->lock, flags);
-
- if (disable) {
- iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio, false);
+ if (chip->io_ctrl_type == IOCTRL_TYPE_CDRU) {
+ base = chip->io_ctrl;
+ shift = IPROC_GPIO_SHIFT(gpio);
+
+ val_1 = readl(base + IPROC_GPIO_PULL_UP_OFFSET);
+ val_2 = readl(base + IPROC_GPIO_PULL_DN_OFFSET);
+ if (disable) {
+ /* no pull-up or pull-down */
+ val_1 &= ~BIT(shift);
+ val_2 &= ~BIT(shift);
+ } else if (pull_up) {
+ val_1 |= BIT(shift);
+ val_2 &= ~BIT(shift);
+ } else {
+ val_1 &= ~BIT(shift);
+ val_2 |= BIT(shift);
+ }
+ writel(val_1, base + IPROC_GPIO_PULL_UP_OFFSET);
+ writel(val_2, base + IPROC_GPIO_PULL_DN_OFFSET);
} else {
- iproc_set_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio,
- pull_up);
- iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio, true);
+ if (disable) {
+ iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio,
+ false);
+ } else {
+ iproc_set_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio,
+ pull_up);
+ iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio,
+ true);
+ }
}
raw_spin_unlock_irqrestore(&chip->lock, flags);
-
dev_dbg(chip->dev, "gpio:%u set pullup:%d\n", gpio, pull_up);
return 0;
@@ -483,14 +518,35 @@ static int iproc_gpio_set_pull(struct iproc_gpio *chip, unsigned gpio,
static void iproc_gpio_get_pull(struct iproc_gpio *chip, unsigned gpio,
bool *disable, bool *pull_up)
{
+ void __iomem *base;
unsigned long flags;
+ unsigned int shift;
+ u32 val_1, val_2;
raw_spin_lock_irqsave(&chip->lock, flags);
- *disable = !iproc_get_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio);
- *pull_up = iproc_get_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio);
+ if (chip->io_ctrl_type == IOCTRL_TYPE_CDRU) {
+ base = chip->io_ctrl;
+ shift = IPROC_GPIO_SHIFT(gpio);
+
+ val_1 = readl(base + IPROC_GPIO_PULL_UP_OFFSET) & BIT(shift);
+ val_2 = readl(base + IPROC_GPIO_PULL_DN_OFFSET) & BIT(shift);
+
+ *pull_up = val_1 ? true : false;
+ *disable = (val_1 | val_2) ? false : true;
+
+ } else {
+ *disable = !iproc_get_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio);
+ *pull_up = iproc_get_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio);
+ }
raw_spin_unlock_irqrestore(&chip->lock, flags);
}
+#define DRV_STRENGTH_OFFSET(gpio, bit, type) ((type) == IOCTRL_TYPE_AON ? \
+ ((2 - (bit)) * 4 + IPROC_GPIO_DRV_CTRL_OFFSET) : \
+ ((type) == IOCTRL_TYPE_CDRU) ? \
+ ((bit) * 4 + IPROC_GPIO_DRV_CTRL_OFFSET) : \
+ ((bit) * 4 + IPROC_GPIO_REG(gpio, IPROC_GPIO_ASIU_DRV0_CTRL_OFFSET)))
+
static int iproc_gpio_set_strength(struct iproc_gpio *chip, unsigned gpio,
unsigned strength)
{
@@ -505,11 +561,8 @@ static int iproc_gpio_set_strength(struct iproc_gpio *chip, unsigned gpio,
if (chip->io_ctrl) {
base = chip->io_ctrl;
- offset = IPROC_GPIO_DRV0_CTRL_OFFSET;
} else {
base = chip->base;
- offset = IPROC_GPIO_REG(gpio,
- IPROC_GPIO_ASIU_DRV0_CTRL_OFFSET);
}
shift = IPROC_GPIO_SHIFT(gpio);
@@ -520,11 +573,11 @@ static int iproc_gpio_set_strength(struct iproc_gpio *chip, unsigned gpio,
raw_spin_lock_irqsave(&chip->lock, flags);
strength = (strength / 2) - 1;
for (i = 0; i < GPIO_DRV_STRENGTH_BITS; i++) {
+ offset = DRV_STRENGTH_OFFSET(gpio, i, chip->io_ctrl_type);
val = readl(base + offset);
val &= ~BIT(shift);
val |= ((strength >> i) & 0x1) << shift;
writel(val, base + offset);
- offset += 4;
}
raw_spin_unlock_irqrestore(&chip->lock, flags);
@@ -541,11 +594,8 @@ static int iproc_gpio_get_strength(struct iproc_gpio *chip, unsigned gpio,
if (chip->io_ctrl) {
base = chip->io_ctrl;
- offset = IPROC_GPIO_DRV0_CTRL_OFFSET;
} else {
base = chip->base;
- offset = IPROC_GPIO_REG(gpio,
- IPROC_GPIO_ASIU_DRV0_CTRL_OFFSET);
}
shift = IPROC_GPIO_SHIFT(gpio);
@@ -553,10 +603,10 @@ static int iproc_gpio_get_strength(struct iproc_gpio *chip, unsigned gpio,
raw_spin_lock_irqsave(&chip->lock, flags);
*strength = 0;
for (i = 0; i < GPIO_DRV_STRENGTH_BITS; i++) {
+ offset = DRV_STRENGTH_OFFSET(gpio, i, chip->io_ctrl_type);
val = readl(base + offset) & BIT(shift);
val >>= shift;
*strength += (val << i);
- offset += 4;
}
/* convert to mA */
@@ -734,6 +784,7 @@ static int iproc_gpio_probe(struct platform_device *pdev)
u32 ngpios, pinconf_disable_mask = 0;
int irq, ret;
bool no_pinconf = false;
+ enum iproc_pinconf_ctrl_type io_ctrl_type = IOCTRL_TYPE_INVALID;
/* NSP does not support drive strength config */
if (of_device_is_compatible(dev->of_node, "brcm,iproc-nsp-gpio"))
@@ -764,8 +815,15 @@ static int iproc_gpio_probe(struct platform_device *pdev)
dev_err(dev, "unable to map I/O memory\n");
return PTR_ERR(chip->io_ctrl);
}
+ if (of_device_is_compatible(dev->of_node,
+ "brcm,cygnus-ccm-gpio"))
+ io_ctrl_type = IOCTRL_TYPE_CDRU;
+ else
+ io_ctrl_type = IOCTRL_TYPE_AON;
}
+ chip->io_ctrl_type = io_ctrl_type;
+
if (of_property_read_u32(dev->of_node, "ngpios", &ngpios)) {
dev_err(&pdev->dev, "missing ngpios DT property\n");
return -ENODEV;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/2] Add fixes to iProc GPIO driver
From: Srinath Mannam @ 2019-08-29 4:52 UTC (permalink / raw)
To: Linus Walleij, Ray Jui, Scott Branden
Cc: Srinath Mannam, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel
This patch series adds the following fixes to the iProc GPIO driver
- Fix Warning message given for shared irqchip data structure
- Fix pinconfig of pull-up/down and drive strength for AON/CRMU GPIOs
This patch set is based on Linux-5.2-rc4.
Changes from v1:
- Add Fixes tags in both patches
Li Jin (1):
gpio: iproc-gpio: Fix incorrect pinconf configurations
Rayagonda Kokatanur (1):
gpio: iproc-gpio: Handle interrupts for multiple instances
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 117 +++++++++++++++++++++++--------
1 file changed, 88 insertions(+), 29 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] [RFC] tty/serial: imx: make use of format specifier %dE
From: Uwe Kleine-König @ 2019-08-29 4:37 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: Jani Nikula, Petr Mladek, linux-serial, Jonathan Corbet,
Shawn Guo, linux-doc, linux-kernel, Steven Rostedt,
Enrico Weigelt, NXP Linux Team, kernel, Andrew Morton,
Fabio Estevam, linux-arm-kernel, Sergey Senozhatsky
I created a patch that teaches printk et al to emit a symbolic error
name for an error valued integer[1]. With that applied
dev_err(&pdev->dev, "failed to get ipg clk: %dE\n", ret);
emits
... failed to get ipg clk: EPROBE_DEFER
if ret is -EPROBE_DEFER. Petr Mladek (i.e. one of the printk
maintainers) had concerns if this would be well received and worth the
effort. He asked to present it to a few subsystems. So for now, this
patch converting the imx UART driver shouldn't be applied yet but it
would be great to get some feedback about if you think that being able
to easily printk (for example) "EIO" instead of "-5" is a good idea.
Would it help you? Do you think it helps your users?
Thanks
Uwe
[1] https://lkml.org/lkml/2019/8/27/1456
---
drivers/tty/serial/imx.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 57d6e6ba556e..a3dbb9378e8b 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2143,7 +2143,7 @@ static int imx_uart_probe_dt(struct imx_port *sport,
ret = of_alias_get_id(np, "serial");
if (ret < 0) {
- dev_err(&pdev->dev, "failed to get alias id, errno %d\n", ret);
+ dev_err(&pdev->dev, "failed to get alias id, error %dE\n", ret);
return ret;
}
sport->port.line = ret;
@@ -2236,14 +2236,14 @@ static int imx_uart_probe(struct platform_device *pdev)
sport->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
if (IS_ERR(sport->clk_ipg)) {
ret = PTR_ERR(sport->clk_ipg);
- dev_err(&pdev->dev, "failed to get ipg clk: %d\n", ret);
+ dev_err(&pdev->dev, "failed to get ipg clk: %dE\n", ret);
return ret;
}
sport->clk_per = devm_clk_get(&pdev->dev, "per");
if (IS_ERR(sport->clk_per)) {
ret = PTR_ERR(sport->clk_per);
- dev_err(&pdev->dev, "failed to get per clk: %d\n", ret);
+ dev_err(&pdev->dev, "failed to get per clk: %dE\n", ret);
return ret;
}
@@ -2252,7 +2252,7 @@ static int imx_uart_probe(struct platform_device *pdev)
/* For register access, we only need to enable the ipg clock. */
ret = clk_prepare_enable(sport->clk_ipg);
if (ret) {
- dev_err(&pdev->dev, "failed to enable per clk: %d\n", ret);
+ dev_err(&pdev->dev, "failed to enable per clk: %dE\n", ret);
return ret;
}
@@ -2330,7 +2330,7 @@ static int imx_uart_probe(struct platform_device *pdev)
ret = devm_request_irq(&pdev->dev, rxirq, imx_uart_rxint, 0,
dev_name(&pdev->dev), sport);
if (ret) {
- dev_err(&pdev->dev, "failed to request rx irq: %d\n",
+ dev_err(&pdev->dev, "failed to request rx irq: %dE\n",
ret);
return ret;
}
@@ -2338,7 +2338,7 @@ static int imx_uart_probe(struct platform_device *pdev)
ret = devm_request_irq(&pdev->dev, txirq, imx_uart_txint, 0,
dev_name(&pdev->dev), sport);
if (ret) {
- dev_err(&pdev->dev, "failed to request tx irq: %d\n",
+ dev_err(&pdev->dev, "failed to request tx irq: %dE\n",
ret);
return ret;
}
@@ -2346,7 +2346,7 @@ static int imx_uart_probe(struct platform_device *pdev)
ret = devm_request_irq(&pdev->dev, rtsirq, imx_uart_rtsint, 0,
dev_name(&pdev->dev), sport);
if (ret) {
- dev_err(&pdev->dev, "failed to request rts irq: %d\n",
+ dev_err(&pdev->dev, "failed to request rts irq: %dE\n",
ret);
return ret;
}
@@ -2354,7 +2354,7 @@ static int imx_uart_probe(struct platform_device *pdev)
ret = devm_request_irq(&pdev->dev, rxirq, imx_uart_int, 0,
dev_name(&pdev->dev), sport);
if (ret) {
- dev_err(&pdev->dev, "failed to request irq: %d\n", ret);
+ dev_err(&pdev->dev, "failed to request irq: %dE\n", ret);
return ret;
}
}
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] drm: dw-hdmi-i2s: enable audio clock in audio_startup
From: Cheng-Yi Chiang @ 2019-08-29 4:29 UTC (permalink / raw)
To: linux-kernel
Cc: alsa-devel, tzungbi, zhengxing, kuninori.morimoto.gx, a.hajda,
airlied, jeffy.chen, dianders, dri-devel, cain.cai,
linux-rockchip, eddie.cai, Laurent.pinchart, daniel,
enric.balletbo, dgreid, sam, linux-arm-kernel, cychiang
In the designware databook, the sequence of enabling audio clock and
setting format is not clearly specified.
Currently, audio clock is enabled in the end of hw_param ops after
setting format.
On some monitors, there is a possibility that audio does not come out.
Fix this by enabling audio clock in audio_startup ops
before hw_param ops setting format.
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index 5cbb71a866d5..08b4adbb1ddc 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -69,6 +69,14 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data,
hdmi_write(audio, conf0, HDMI_AUD_CONF0);
hdmi_write(audio, conf1, HDMI_AUD_CONF1);
+ return 0;
+}
+
+static int dw_hdmi_i2s_audio_startup(struct device *dev, void *data)
+{
+ struct dw_hdmi_i2s_audio_data *audio = data;
+ struct dw_hdmi *hdmi = audio->hdmi;
+
dw_hdmi_audio_enable(hdmi);
return 0;
@@ -105,6 +113,7 @@ static int dw_hdmi_i2s_get_dai_id(struct snd_soc_component *component,
}
static struct hdmi_codec_ops dw_hdmi_i2s_ops = {
+ .audio_startup = dw_hdmi_i2s_audio_startup,
.hw_params = dw_hdmi_i2s_hw_params,
.audio_shutdown = dw_hdmi_i2s_audio_shutdown,
.get_dai_id = dw_hdmi_i2s_get_dai_id,
--
2.23.0.187.g17f5b7556c-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] [RFC] i2c: imx: make use of format specifier %dE
From: Uwe Kleine-König @ 2019-08-29 4:29 UTC (permalink / raw)
To: Wolfram Sang, Oleksij Rempel
Cc: Jani Nikula, Petr Mladek, Sergey Senozhatsky, Jonathan Corbet,
Shawn Guo, linux-doc, linux-kernel, Steven Rostedt,
Enrico Weigelt, NXP Linux Team, kernel, Andrew Morton,
Fabio Estevam, linux-arm-kernel, linux-i2c
I created a patch that teaches printk et al to emit a symbolic error
name for an error valued integer[1]. With that applied
dev_err(&pdev->dev, "can't enable I2C clock, ret=%dE\n", ret);
emits
... can't enable I2C clock, ret=EIO
if ret is -EIO. Petr Mladek (i.e. one of the printk maintainers) had
concerns if this would be well received and worth the effort. He asked
to present it to a few subsystems. So for now, this patch converting the
i2c-imx driver shouldn't be applied yet but it would be great to get
some feedback about if you think that being able to easily printk (for
example) "EIO" instead of "-5" is a good idea. Would it help you? Do you
think it helps your users?
Thanks
Uwe
[1] https://lkml.org/lkml/2019/8/27/1456
---
drivers/i2c/busses/i2c-imx.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 15f6cde6452f..359e911cb891 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -289,7 +289,7 @@ static void i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
if (IS_ERR(dma->chan_tx)) {
ret = PTR_ERR(dma->chan_tx);
if (ret != -ENODEV && ret != -EPROBE_DEFER)
- dev_err(dev, "can't request DMA tx channel (%d)\n", ret);
+ dev_err(dev, "can't request DMA tx channel (%dE)\n", ret);
goto fail_al;
}
@@ -300,7 +300,7 @@ static void i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
dma_sconfig.direction = DMA_MEM_TO_DEV;
ret = dmaengine_slave_config(dma->chan_tx, &dma_sconfig);
if (ret < 0) {
- dev_err(dev, "can't configure tx channel (%d)\n", ret);
+ dev_err(dev, "can't configure tx channel (%dE)\n", ret);
goto fail_tx;
}
@@ -308,7 +308,7 @@ static void i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
if (IS_ERR(dma->chan_rx)) {
ret = PTR_ERR(dma->chan_rx);
if (ret != -ENODEV && ret != -EPROBE_DEFER)
- dev_err(dev, "can't request DMA rx channel (%d)\n", ret);
+ dev_err(dev, "can't request DMA rx channel (%dE)\n", ret);
goto fail_tx;
}
@@ -319,7 +319,7 @@ static void i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
dma_sconfig.direction = DMA_DEV_TO_MEM;
ret = dmaengine_slave_config(dma->chan_rx, &dma_sconfig);
if (ret < 0) {
- dev_err(dev, "can't configure rx channel (%d)\n", ret);
+ dev_err(dev, "can't configure rx channel (%dE)\n", ret);
goto fail_rx;
}
@@ -964,7 +964,7 @@ static int i2c_imx_xfer(struct i2c_adapter *adapter,
pm_runtime_put_autosuspend(i2c_imx->adapter.dev.parent);
out:
- dev_dbg(&i2c_imx->adapter.dev, "<%s> exit with: %s: %d\n", __func__,
+ dev_dbg(&i2c_imx->adapter.dev, "<%s> exit with: %s: %dE\n", __func__,
(result < 0) ? "error" : "success msg",
(result < 0) ? result : num);
return (result < 0) ? result : num;
@@ -1100,7 +1100,7 @@ static int i2c_imx_probe(struct platform_device *pdev)
ret = clk_prepare_enable(i2c_imx->clk);
if (ret) {
- dev_err(&pdev->dev, "can't enable I2C clock, ret=%d\n", ret);
+ dev_err(&pdev->dev, "can't enable I2C clock, ret=%dE\n", ret);
return ret;
}
@@ -1108,7 +1108,7 @@ static int i2c_imx_probe(struct platform_device *pdev)
ret = devm_request_irq(&pdev->dev, irq, i2c_imx_isr, IRQF_SHARED,
pdev->name, i2c_imx);
if (ret) {
- dev_err(&pdev->dev, "can't claim irq %d\n", irq);
+ dev_err(&pdev->dev, "can't claim irq %dE\n", irq);
goto clk_disable;
}
@@ -1230,7 +1230,7 @@ static int __maybe_unused i2c_imx_runtime_resume(struct device *dev)
ret = clk_enable(i2c_imx->clk);
if (ret)
- dev_err(dev, "can't enable I2C clock, ret=%d\n", ret);
+ dev_err(dev, "can't enable I2C clock, ret=%dE\n", ret);
return ret;
}
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH v2 0/7] soc: renesas: rcar-gen3-sysc: Fix power request conflicts
From: Yoshihiro Shimoda @ 2019-08-29 4:14 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm
Cc: linux-renesas-soc@vger.kernel.org, Simon Horman,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190828113618.6672-1-geert+renesas@glider.be>
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, August 28, 2019 8:36 PM
>
> Hi all,
>
> Recent R-Car Gen3 SoCs added an External Request Mask Register to the
> System Controller (SYSC). This register allows to mask external power
> requests for CPU or 3DG domains, to prevent conflicts between powering
> off CPU cores or the 3D Graphics Engine, and changing the state of
> another power domain through SYSC, which could lead to CPG state machine
> lock-ups.
>
> This patch series starts making use of this register. Note that the
> register is optional, and that its location and contents are
> SoC-specific.
>
> This was inspired by a patch in the BSP by Dien Pham
> <dien.pham.ry@renesas.com>.
>
> Note that the issue fixed cannot happen in the upstream kernel, as
> upstream has no support for graphics acceleration yet. SoCs lacking the
> External Request Mask Register may need a different mitigation in the
> future.
>
> Changes compared to v1[1]:
> - Improve description of cover letter and first patch.
>
> Changes compared to RFC[2]:
> - Rebased.
>
> This has been boot-tested on R-Car H3 ES1.0, H3 ES2.0, M3-W ES1.0, M3-N,
> V3M, and E3 (only the last 3 have this register!), and regression-tested
> on R-Car Gen2.
>
> This has not been tested on R-Car H3 ES3.0, M3-W ES2.0, and V3H.
I also boot-tested on R-Car H3 ES3.0 and M3-W ES3.0.
And I reviewed all patches, so:
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Best regards,
Yoshihiro Shimoda
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH netdev] net: stmmac: dwmac-rk: Don't fail if phy regulator is absent
From: Chen-Yu Tsai @ 2019-08-29 3:17 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Heiko Stuebner
Cc: linux-rockchip, Chen-Yu Tsai, linux-kernel, linux-arm-kernel,
netdev
From: Chen-Yu Tsai <wens@csie.org>
The devicetree binding lists the phy phy as optional. As such, the
driver should not bail out if it can't find a regulator. Instead it
should just skip the remaining regulator related code and continue
on normally.
Skip the remainder of phy_power_on() if a regulator supply isn't
available. This also gets rid of the bogus return code.
Fixes: 2e12f536635f ("net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
On a separate note, maybe we should add this file to the Rockchip
entry in MAINTAINERS?
---
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 4644b2aeeba1..e2e469c37a4d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -1194,10 +1194,8 @@ static int phy_power_on(struct rk_priv_data *bsp_priv, bool enable)
int ret;
struct device *dev = &bsp_priv->pdev->dev;
- if (!ldo) {
- dev_err(dev, "no regulator found\n");
- return -1;
- }
+ if (!ldo)
+ return 0;
if (enable) {
ret = regulator_enable(ldo);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/1] sched/rt: avoid contend with CFS task
From: Jing-Ting Wu @ 2019-08-29 3:15 UTC (permalink / raw)
To: Peter Zijlstra, Matthias Brugger
Cc: linux-arm-kernel, Jing-Ting Wu, linux-mediatek, linux-kernel,
wsd_upstream
At original linux design, RT & CFS scheduler are independent.
Current RT task placement policy will select the first cpu in
lowest_mask, even if the first CPU is running a CFS task.
This may put RT task to a running cpu and let CFS task runnable.
So we select idle cpu in lowest_mask first to avoid preempting
CFS task.
Signed-off-by: Jing-Ting Wu <jing-ting.wu@mediatek.com>
---
kernel/sched/rt.c | 42 +++++++++++++++++-------------------------
1 file changed, 17 insertions(+), 25 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index a532558..626ca27 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1388,7 +1388,6 @@ static void yield_task_rt(struct rq *rq)
static int
select_task_rq_rt(struct task_struct *p, int cpu, int sd_flag, int flags)
{
- struct task_struct *curr;
struct rq *rq;
/* For anything but wake ups, just return the task_cpu */
@@ -1398,33 +1397,15 @@ static void yield_task_rt(struct rq *rq)
rq = cpu_rq(cpu);
rcu_read_lock();
- curr = READ_ONCE(rq->curr); /* unlocked access */
/*
- * If the current task on @p's runqueue is an RT task, then
- * try to see if we can wake this RT task up on another
- * runqueue. Otherwise simply start this RT task
- * on its current runqueue.
- *
- * We want to avoid overloading runqueues. If the woken
- * task is a higher priority, then it will stay on this CPU
- * and the lower prio task should be moved to another CPU.
- * Even though this will probably make the lower prio task
- * lose its cache, we do not want to bounce a higher task
- * around just because it gave up its CPU, perhaps for a
- * lock?
- *
- * For equal prio tasks, we just let the scheduler sort it out.
- *
- * Otherwise, just let it ride on the affined RQ and the
- * post-schedule router will push the preempted task away
- *
- * This test is optimistic, if we get it wrong the load-balancer
- * will have to sort it out.
+ * If the task p is allowed to put more than one CPU or
+ * it is not allowed to put on this CPU.
+ * Let p use find_lowest_rq to choose other idle CPU first,
+ * instead of choose this cpu and preempt curr cfs task.
*/
- if (curr && unlikely(rt_task(curr)) &&
- (curr->nr_cpus_allowed < 2 ||
- curr->prio <= p->prio)) {
+ if ((p->nr_cpus_allowed > 1) ||
+ (!cpumask_test_cpu(cpu, p->cpus_ptr))) {
int target = find_lowest_rq(p);
/*
@@ -1648,6 +1629,7 @@ static int find_lowest_rq(struct task_struct *task)
struct cpumask *lowest_mask = this_cpu_cpumask_var_ptr(local_cpu_mask);
int this_cpu = smp_processor_id();
int cpu = task_cpu(task);
+ int i;
/* Make sure the mask is initialized first */
if (unlikely(!lowest_mask))
@@ -1659,6 +1641,16 @@ static int find_lowest_rq(struct task_struct *task)
if (!cpupri_find(&task_rq(task)->rd->cpupri, task, lowest_mask))
return -1; /* No targets found */
+ /* Choose previous cpu if it is idle and it fits lowest_mask */
+ if (cpumask_test_cpu(cpu, lowest_mask) && idle_cpu(cpu))
+ return cpu;
+
+ /* Choose idle_cpu among lowest_mask */
+ for_each_cpu(i, lowest_mask) {
+ if (idle_cpu(i))
+ return i;
+ }
+
/*
* At this point we have built a mask of CPUs representing the
* lowest priority tasks in the system. Now we want to elect
--
1.7.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [arm:for-next 13/25] include/linux/error-injection.h:7:10: fatal error: asm/error-injection.h: No such file or directory
From: kbuild test robot @ 2019-08-29 0:49 UTC (permalink / raw)
To: Leo Yan; +Cc: Russell King, kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git for-next
head: d0d54dc04e37be14a9e51d9a2e431f302948e99d
commit: 566c290c6498b2fdc04a54556c4e8747f0298c7b [13/25] ARM: 8899/1: arm/arm64: Add support for function error injection
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 566c290c6498b2fdc04a54556c4e8747f0298c7b
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
In file included from include/linux/module.h:22:0,
from drivers/pps/pps.c:11:
>> include/linux/error-injection.h:7:10: fatal error: asm/error-injection.h: No such file or directory
#include <asm/error-injection.h>
^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
vim +7 include/linux/error-injection.h
540adea3809f61 Masami Hiramatsu 2018-01-13 6
540adea3809f61 Masami Hiramatsu 2018-01-13 @7 #include <asm/error-injection.h>
540adea3809f61 Masami Hiramatsu 2018-01-13 8
:::::: The code at line 7 was first introduced by commit
:::::: 540adea3809f61115d2a1ea4ed6e627613452ba1 error-injection: Separate error-injection from kprobe
:::::: TO: Masami Hiramatsu <mhiramat@kernel.org>
:::::: CC: Alexei Starovoitov <ast@kernel.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 71416 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] KVM: arm/arm64: vgic: Allow more than 256 vcpus for KVM_IRQ_LINE
From: Zenghui Yu @ 2019-08-29 2:46 UTC (permalink / raw)
To: Marc Zyngier, Peter Maydell, James Morse, Julien Thierry,
Suzuki K Poulose
Cc: Eric Auger, qemu-arm, kvmarm, linux-arm-kernel, kvm
In-Reply-To: <20190818140710.23920-1-maz@kernel.org>
Hi Marc,
On 2019/8/18 22:07, Marc Zyngier wrote:
> While parts of the VGIC support a large number of vcpus (we
> bravely allow up to 512), other parts are more limited.
>
> One of these limits is visible in the KVM_IRQ_LINE ioctl, which
> only allows 256 vcpus to be signalled when using the CPU or PPI
> types. Unfortunately, we've cornered ourselves badly by allocating
> all the bits in the irq field.
>
> Since the irq_type subfield (8 bit wide) is currently only taking
> the values 0, 1 and 2 (and we have been careful not to allow anything
> else), let's reduce this field to only 4 bits, and allocate the
> remaining 4 bits to a vcpu2_index, which acts as a multiplier:
>
> vcpu_id = 256 * vcpu2_index + vcpu_index
>
> With that, and a new capability (KVM_CAP_ARM_IRQ_LINE_LAYOUT_2)
> allowing this to be discovered, it becomes possible to inject
> PPIs to up to 4096 vcpus. But please just don't.
>
> Reported-by: Zenghui Yu <yuzenghui@huawei.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
And tested together with Eric's patches (KVM+QEMU).
Thanks,
zenghui
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
From: Peng Fan @ 2019-08-29 2:46 UTC (permalink / raw)
To: Stefano Stabellini
Cc: linux@armlinux.org.uk, linux-kernel@vger.kernel.org, dl-linux-imx,
van.freenix@gmail.com, xen-devel@lists.xenproject.org,
Robin Murphy, linux-arm-kernel@lists.infradead.org
In-Reply-To: <alpine.DEB.2.21.1908281103290.25361@sstabellini-ThinkPad-T480s>
Hi Stefano,
> Subject: RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
>
> On Wed, 28 Aug 2019, Peng Fan wrote:
> > Hi Robin,
> >
> > > Subject: Re: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
> > >
> > > On 09/07/2019 09:22, Peng Fan wrote:
> > > > arm64 shares some code under arch/arm/xen, including mm.c.
> > > > However ZONE_DMA is removed by commit
> > > > ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> > > > So to ARM64, need use __GFP_DMA32.
>
> Hi Peng,
>
> Sorry for being so late in replying, this email got lost in the noise.
>
>
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > ---
> > > > arch/arm/xen/mm.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > > > e1d44b903dfc..a95e76d18bf9 100644
> > > > --- a/arch/arm/xen/mm.c
> > > > +++ b/arch/arm/xen/mm.c
> > > > @@ -27,7 +27,7 @@ unsigned long
> > > > xen_get_swiotlb_free_pages(unsigned
> > > > int order)
> > > >
> > > > for_each_memblock(memory, reg) {
> > > > if (reg->base < (phys_addr_t)0xffffffff) {
> > > > - flags |= __GFP_DMA;
> > > > + flags |= __GFP_DMA | __GFP_DMA32;
> > >
> > > Given the definition of GFP_ZONE_BAD, I'm not sure this combination
> > > of flags is strictly valid, but rather is implicitly reliant on only
> > > one of those zones ever actually existing. As such, it seems liable
> > > to blow up if the plans to add ZONE_DMA to arm64[1] go ahead.
> >
> > How about this, or do you have any suggestions?
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > d33b77e9add3..f61c29a4430f 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -28,7 +28,11 @@ unsigned long xen_get_swiotlb_free_pages(unsigned
> > int order)
> >
> > for_each_memblock(memory, reg) {
> > if (reg->base < (phys_addr_t)0xffffffff) {
> > +#ifdef CONFIG_ARM64
> > + flags |= __GFP_DMA32; #else
> > flags |= __GFP_DMA;
> > +#endif
> > break;
> > }
> > }
>
> Yes I think this is the way to go, but we are trying not to add any #ifdef
> CONFIG_ARM64 under arch/arm. Maybe you could introduce a static inline
> function to set GFP_DMA:
>
> static inline void xen_set_gfp_dma(gfp_t *flags)
>
> it could be implemented under arch/arm/include/asm/xen/page.h for arm
> and under arch/arm64/include/asm/xen/page.h for arm64 using __GFP_DMA
> for the former and __GFP_DMA32 for the latter.
Thanks for your suggestion. I'll use this in V2.
Thanks,
Peng.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] PCI: rockchip: Properly handle optional regulators【请注意，邮件由linux-rockchip-bounces+shawn.lin=rock-chips.com@lists.infradead.org代发】
From: Shawn Lin @ 2019-08-29 2:31 UTC (permalink / raw)
To: Thierry Reding, Lorenzo Pieralisi, Bjorn Helgaas
Cc: Heiko Stuebner, linux-pci, shawn.lin, Vidya Sagar, linux-rockchip,
Andrew Murray, linux-arm-kernel
In-Reply-To: <20190828150737.30285-1-thierry.reding@gmail.com>
On 2019/8/28 23:07, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> regulator_get_optional() can fail for a number of reasons besides probe
> deferral. It can for example return -ENOMEM if it runs out of memory as
> it tries to allocate data structures. Propagating only -EPROBE_DEFER is
> problematic because it results in these legitimately fatal errors being
> treated as "regulator not specified in DT".
>
> What we really want is to ignore the optional regulators only if they
> have not been specified in DT. regulator_get_optional() returns -ENODEV
> in this case, so that's the special case that we need to handle. So we
> propagate all errors, except -ENODEV, so that real failures will still
> cause the driver to fail probe.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
LGTM,
Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
> ---
> drivers/pci/controller/pcie-rockchip-host.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
> index 8d20f1793a61..ef8e677ce9d1 100644
> --- a/drivers/pci/controller/pcie-rockchip-host.c
> +++ b/drivers/pci/controller/pcie-rockchip-host.c
> @@ -608,29 +608,29 @@ static int rockchip_pcie_parse_host_dt(struct rockchip_pcie *rockchip)
>
> rockchip->vpcie12v = devm_regulator_get_optional(dev, "vpcie12v");
> if (IS_ERR(rockchip->vpcie12v)) {
> - if (PTR_ERR(rockchip->vpcie12v) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> + if (PTR_ERR(rockchip->vpcie12v) != -ENODEV)
> + return PTR_ERR(rockchip->vpcie12v);
> dev_info(dev, "no vpcie12v regulator found\n");
> }
>
> rockchip->vpcie3v3 = devm_regulator_get_optional(dev, "vpcie3v3");
> if (IS_ERR(rockchip->vpcie3v3)) {
> - if (PTR_ERR(rockchip->vpcie3v3) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> + if (PTR_ERR(rockchip->vpcie3v3) != -ENODEV)
> + return PTR_ERR(rockchip->vpcie3v3);
> dev_info(dev, "no vpcie3v3 regulator found\n");
> }
>
> rockchip->vpcie1v8 = devm_regulator_get_optional(dev, "vpcie1v8");
> if (IS_ERR(rockchip->vpcie1v8)) {
> - if (PTR_ERR(rockchip->vpcie1v8) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> + if (PTR_ERR(rockchip->vpcie1v8) != -ENODEV)
> + return PTR_ERR(rockchip->vpcie1v8);
> dev_info(dev, "no vpcie1v8 regulator found\n");
> }
>
> rockchip->vpcie0v9 = devm_regulator_get_optional(dev, "vpcie0v9");
> if (IS_ERR(rockchip->vpcie0v9)) {
> - if (PTR_ERR(rockchip->vpcie0v9) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> + if (PTR_ERR(rockchip->vpcie0v9) != -ENODEV)
> + return PTR_ERR(rockchip->vpcie0v9);
> dev_info(dev, "no vpcie0v9 regulator found\n");
> }
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 08/10] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
From: Xiaowei Bao @ 2019-08-29 2:03 UTC (permalink / raw)
To: Andrew Murray
Cc: mark.rutland@arm.com, Roy Zang, arnd@arndb.de,
devicetree@vger.kernel.org, gregkh@linuxfoundation.org,
linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, kishon@ti.com, M.h. Lian,
robh+dt@kernel.org, gustavo.pimentel@synopsys.com,
jingoohan1@gmail.com, bhelgaas@google.com, Leo Li,
shawnguo@kernel.org, Mingkai Hu,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190828090105.GR14582@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年8月28日 17:01
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org; M.h.
> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support for
> ls1088a and ls2088a
>
> On Wed, Aug 28, 2019 at 04:29:32AM +0000, Xiaowei Bao wrote:
> >
> >
> > > -----Original Message-----
> > > From: Andrew Murray <andrew.murray@arm.com>
> > > Sent: 2019年8月27日 21:34
> > > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> > > lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org;
> M.h.
> > > Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> > > Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > > gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support
> > > for ls1088a and ls2088a
> > >
> > > On Mon, Aug 26, 2019 at 09:49:35AM +0000, Xiaowei Bao wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Andrew Murray <andrew.murray@arm.com>
> > > > > Sent: 2019年8月23日 22:28
> > > > > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > > > Cc: bhelgaas@google.com; robh+dt@kernel.org;
> > > > > mark.rutland@arm.com; shawnguo@kernel.org; Leo Li
> > > > > <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.co;
> > > > > arnd@arndb.de; gregkh@linuxfoundation.org;
> > > M.h.
> > > > > Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>;
> > > > > Roy Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > > > > gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > > > > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > > > linux-arm-kernel@lists.infradead.org;
> > > > > linuxppc-dev@lists.ozlabs.org
> > > > > Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode
> > > > > support for ls1088a and ls2088a
> > > > >
> > > > > On Thu, Aug 22, 2019 at 07:22:40PM +0800, Xiaowei Bao wrote:
> > > > > > Add PCIe EP mode support for ls1088a and ls2088a, there are
> > > > > > some difference between LS1 and LS2 platform, so refactor the
> > > > > > code of the EP driver.
> > > > > >
> > > > > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > > > > ---
> > > > > > v2:
> > > > > > - New mechanism for layerscape EP driver.
> > > > >
> > > > > Was there a v1 of this patch?
> > > > >
> > > > > >
> > > > > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 76
> > > > > > ++++++++++++++++++++------
> > > > > > 1 file changed, 58 insertions(+), 18 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > > index 7ca5fe8..2a66f07 100644
> > > > > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > > @@ -20,27 +20,29 @@
> > > > > >
> > > > > > #define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
> > > > > >
> > > > > > -struct ls_pcie_ep {
> > > > > > - struct dw_pcie *pci;
> > > > > > - struct pci_epc_features *ls_epc;
> > > > > > +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > > > > +
> > > > > > +struct ls_pcie_ep_drvdata {
> > > > > > + u32 func_offset;
> > > > > > + const struct dw_pcie_ep_ops *ops;
> > > > > > + const struct dw_pcie_ops *dw_pcie_ops;
> > > > > > };
> > > > > >
> > > > > > -#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > > > > +struct ls_pcie_ep {
> > > > > > + struct dw_pcie *pci;
> > > > > > + struct pci_epc_features *ls_epc;
> > > > > > + const struct ls_pcie_ep_drvdata *drvdata; };
> > > > > >
> > > > > > static int ls_pcie_establish_link(struct dw_pcie *pci) {
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > -static const struct dw_pcie_ops ls_pcie_ep_ops = {
> > > > > > +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
> > > > > > .start_link = ls_pcie_establish_link, };
> > > > > >
> > > > > > -static const struct of_device_id ls_pcie_ep_of_match[] = {
> > > > > > - { .compatible = "fsl,ls-pcie-ep",},
> > > > > > - { },
> > > > > > -};
> > > > > > -
> > > > > > static const struct pci_epc_features*
> > > > > > ls_pcie_ep_get_features(struct dw_pcie_ep *ep) { @@ -82,10
> > > > > > +84,44 @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep,
> u8 func_no,
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > -static const struct dw_pcie_ep_ops pcie_ep_ops = {
> > > > > > +static unsigned int ls_pcie_ep_func_conf_select(struct
> > > > > > +dw_pcie_ep
> > > *ep,
> > > > > > + u8 func_no)
> > > > > > +{
> > > > > > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > > > > + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > > > > > + u8 header_type;
> > > > > > +
> > > > > > + header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
> > > > > > +
> > > > > > + if (header_type & (1 << 7))
> > > > > > + return pcie->drvdata->func_offset * func_no;
> > > > > > + else
> > > > > > + return 0;
> > > > >
> > > > > It looks like there isn't a PCI define for multi function, the
> > > > > nearest I could find was PCI_HEADER_TYPE_MULTIDEVICE in
> > > > > hotplug/ibmphp.h. A comment above the test might be helpful to
> > > > > explain
> > > the test.
> > > >
> > > > OK, I will add a comment above this code.
> > > >
> > > > >
> > > > > As the ls_pcie_ep_drvdata structures are static, the unset
> > > > > .func_offset will be initialised to 0, so you could just drop the test
> above.
> > > >
> > > > Due to the different PCIe controller have different property, e.g.
> > > > PCIe controller1 support multiple function feature, but PCIe
> > > > controller2 don't support this feature, so I need to check which
> > > > controller support it and return the correct offset value, but
> > > > each board only
> > > have one ls_pcie_ep_drvdata, ^_^.
> > >
> > > Yes but if they don't support the feature then func_offset will be 0.
> > >
> > > >
> > > > >
> > > > > However something to the effect of the following may help spot
> > > > > misconfiguration:
> > > > >
> > > > > WARN_ON(func_no && !pcie->drvdata->func_offset); return
> > > > > pcie->drvdata->func_offset * func_no;
> > > > >
> > > > > The WARN is probably quite useful as if you are attempting to
> > > > > use non-zero functions and func_offset isn't set - then things
> > > > > may appear to work normally but actually will break horribly.
> > > >
> > > > As discussion before, I think the func_offset should not depends
> > > > on the function number, even if other platforms of NXP may be use
> > > > write registers way to access the different function config space.
> > >
> > > I agree that func_offset is an optional parameter. But if you are
> > > attempting to determine the offset of a function and you are given a
> > > non-zero function number - then something has gone wrong if func_offset
> is 0.
> >
> > I have understood you means, maybe I need to set a flag in the
> > driver_data struct, because I may add other platform of NXP, these
> > platform use the write register method to access different function, e.g.
> > write func_num to register, then we can access this func_num config space.
> >
> > I will modify the code like this? Do you have better advice?
> > Case1:
> > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > index 004a7e8..8a0d6df 100644
> > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > @@ -23,6 +23,7 @@
> > #define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> >
> > struct ls_pcie_ep_drvdata {
> > + u8 func_config_flag;
> > u32 func_offset;
> > const struct dw_pcie_ep_ops *ops;
> > const struct dw_pcie_ops *dw_pcie_ops;
> > @@ -97,8 +98,14 @@ static unsigned int
> ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
> > * Read the Header Type register of config space to check
> > * whether this PCI device support the multiple function.
> > */
> > - if (header_type & (1 << 7))
> > - return pcie->drvdata->func_offset * func_no;
> > + if (header_type & (1 << 7)) {
> > + if (pcie->drvdata->func_config_flag) {
> > + iowrite32((func_num << n), pci->dbi_base +
> PCI_XXXX_XXX);
> > + } else {
> > + WARN_ON(func_no
> && !pcie->drvdata->func_offset);
> > + return pcie->drvdata->func_offset * func_no;
> > + }
> > + }
> >
> > return 0;
> > }
> >
> > Of course, I don't need to set the flag this time, because I don't use
> > the second method(write register method), so the code like this:
> > case2:
> > +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep
> > +*ep,
> > u8 func_no) {
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > u8 header_type;
> >
> > of course, this code is not requied, due to the
> > pcie->drvdata->func_offset is 0, but I think this is more clear
> > if use this code.
> > header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
> >
> > /*
> > * Read the Header Type register of config space to check
> > * whether this PCI device support the multiple function.
> > */
> > if (header_type & (1 << 7)) {
> > WARN_ON(func_no && !pcie->drvdata->func_offset);
> > return pcie->drvdata->func_offset * func_no;
> > }
> >
> > return 0;
> > }
> >
> > Or like this:
> > Case3:
> > +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep
> > +*ep,
> > u8 func_no) {
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> >
> > WARN_ON(func_no && !pcie->drvdata->func_offset);
> > return pcie->drvdata->func_offset * func_no;
>
> This is better. Given there is only currently one method of calculating an offset
> for layerscape, I'd recommend you add additional methods when the need
> arises.
OK, thanks
>
> Thanks,
>
> Andrew Murray
>
> >
> > }
> > Of course, we can return a -1 by adjuring the (func_no &&
> > !pcie->drvdata->func_offset) Valu in case1
> >
> > Thanks
> > Xiaowei
> >
> > >
> > > Thanks,
> > >
> > > Andrew Murray
> > >
> > > >
> > > > I have added the comments above the code, as follow, do you have
> > > > any
> > > advice?
> > > > +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep
> *ep,
> > > > + u8 func_no)
> {
> > > > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > > + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > > > + u8 header_type;
> > > > +
> > > > + header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
> > > > +
> > > > + /*
> > > > + * Read the Header Type register of config space to check
> > > > + * whether this PCI device support the multiple function.
> > > > + */
> > > > + if (header_type & (1 << 7))
> > > > + return pcie->drvdata->func_offset * func_no;
> > > > +
> > > > + return 0;
> > > > +}
> > > >
> > > > Thanks a lot for your detail comments.
> > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Andrew Murray
> > > > >
> > > > > > +}
> > > > > > +
> > > > > > +static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
> > > > > > .ep_init = ls_pcie_ep_init,
> > > > > > .raise_irq = ls_pcie_ep_raise_irq,
> > > > > > .get_features = ls_pcie_ep_get_features,
> > > > > > + .func_conf_select = ls_pcie_ep_func_conf_select, };
> > > > > > +
> > > > > > +static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
> > > > > > + .ops = &ls_pcie_ep_ops,
> > > > > > + .dw_pcie_ops = &dw_ls_pcie_ep_ops, };
> > > > > > +
> > > > > > +static const struct ls_pcie_ep_drvdata ls2_ep_drvdata = {
> > > > > > + .func_offset = 0x20000,
> > > > > > + .ops = &ls_pcie_ep_ops,
> > > > > > + .dw_pcie_ops = &dw_ls_pcie_ep_ops, };
> > > > > > +
> > > > > > +static const struct of_device_id ls_pcie_ep_of_match[] = {
> > > > > > + { .compatible = "fsl,ls1046a-pcie-ep", .data =
> &ls1_ep_drvdata },
> > > > > > + { .compatible = "fsl,ls1088a-pcie-ep", .data =
> &ls2_ep_drvdata },
> > > > > > + { .compatible = "fsl,ls2088a-pcie-ep", .data =
> &ls2_ep_drvdata },
> > > > > > + { },
> > > > > > };
> > > > > >
> > > > > > static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie, @@
> > > > > > -98,7
> > > > > > +134,7 @@ static int __init ls_add_pcie_ep(struct ls_pcie_ep
> > > > > > +*pcie,
> > > > > > int ret;
> > > > > >
> > > > > > ep = &pci->ep;
> > > > > > - ep->ops = &pcie_ep_ops;
> > > > > > + ep->ops = pcie->drvdata->ops;
> > > > > >
> > > > > > res = platform_get_resource_byname(pdev,
> IORESOURCE_MEM,
> > > > > "addr_space");
> > > > > > if (!res)
> > > > > > @@ -137,14 +173,11 @@ static int __init
> > > > > > ls_pcie_ep_probe(struct
> > > > > platform_device *pdev)
> > > > > > if (!ls_epc)
> > > > > > return -ENOMEM;
> > > > > >
> > > > > > - dbi_base = platform_get_resource_byname(pdev,
> > > IORESOURCE_MEM,
> > > > > "regs");
> > > > > > - pci->dbi_base = devm_pci_remap_cfg_resource(dev,
> dbi_base);
> > > > > > - if (IS_ERR(pci->dbi_base))
> > > > > > - return PTR_ERR(pci->dbi_base);
> > > > > > + pcie->drvdata = of_device_get_match_data(dev);
> > > > > >
> > > > > > - pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > > > > > pci->dev = dev;
> > > > > > - pci->ops = &ls_pcie_ep_ops;
> > > > > > + pci->ops = pcie->drvdata->dw_pcie_ops;
> > > > > > +
> > > > > > pcie->pci = pci;
> > > > > >
> > > > > > ls_epc->linkup_notifier = false, @@ -152,6 +185,13 @@ static
> > > > > > int __init ls_pcie_ep_probe(struct platform_device *pdev)
> > > > > >
> > > > > > pcie->ls_epc = ls_epc;
> > > > > >
> > > > > > + dbi_base = platform_get_resource_byname(pdev,
> > > IORESOURCE_MEM,
> > > > > "regs");
> > > > > > + pci->dbi_base = devm_pci_remap_cfg_resource(dev,
> dbi_base);
> > > > > > + if (IS_ERR(pci->dbi_base))
> > > > > > + return PTR_ERR(pci->dbi_base);
> > > > > > +
> > > > > > + pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > > > > > +
> > > > > > platform_set_drvdata(pdev, pcie);
> > > > > >
> > > > > > ret = ls_add_pcie_ep(pcie, pdev);
> > > > > > --
> > > > > > 2.9.5
> > > > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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