* [PATCH v11 8/8] interconnect: sdm845: Fix build failure after cmd_db API change
From: Georgi Djakov @ 2018-12-07 15:29 UTC (permalink / raw)
To: gregkh, linux-pm
Cc: mark.rutland, sanjayc, maxime.ripard, mturquette, daidavid1,
bjorn.andersson, skannan, abailon, lorenzo.pieralisi,
vincent.guittot, seansw, khilman, evgreen, ksitaraman, devicetree,
arnd, linux-arm-msm, robh+dt, linux-tegra, linux-arm-kernel, rjw,
dianders, amit.kucheria, linux-kernel, thierry.reding,
georgi.djakov
In-Reply-To: <20181207152917.4862-1-georgi.djakov@linaro.org>
Recently the cmd_db_read_aux_data() function was changed to avoid using
memcpy and return a pointer instead. Update the code to the new API and
fix the build failure.
Fixes: ed3cafa79ea7 ("soc: qcom: cmd-db: Stop memcpy()ing in cmd_db_read_aux_data()")
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
---
drivers/interconnect/qcom/sdm845.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/interconnect/qcom/sdm845.c b/drivers/interconnect/qcom/sdm845.c
index f594dd6f500f..06dbc99766ee 100644
--- a/drivers/interconnect/qcom/sdm845.c
+++ b/drivers/interconnect/qcom/sdm845.c
@@ -487,7 +487,9 @@ static struct qcom_icc_desc sdm845_rsc_hlos = {
static int qcom_icc_bcm_init(struct qcom_icc_bcm *bcm, struct device *dev)
{
struct qcom_icc_node *qn;
- int ret, i;
+ const struct bcm_db *data;
+ size_t data_count;
+ int i;
bcm->addr = cmd_db_read_addr(bcm->name);
if (!bcm->addr) {
@@ -496,22 +498,22 @@ static int qcom_icc_bcm_init(struct qcom_icc_bcm *bcm, struct device *dev)
return -EINVAL;
}
- if (cmd_db_read_aux_data_len(bcm->name) < sizeof(struct bcm_db)) {
+ data = cmd_db_read_aux_data(bcm->name, &data_count);
+ if (IS_ERR(data)) {
+ dev_err(dev, "%s command db read error (%ld)\n",
+ bcm->name, PTR_ERR(data));
+ return PTR_ERR(data);
+ }
+ if (!data_count) {
dev_err(dev, "%s command db missing or partial aux data\n",
bcm->name);
return -EINVAL;
}
- ret = cmd_db_read_aux_data(bcm->name, (u8 *)&bcm->aux_data,
- sizeof(struct bcm_db));
- if (ret < 0) {
- dev_err(dev, "%s command db read error (%d)\n",
- bcm->name, ret);
- return ret;
- }
-
- bcm->aux_data.unit = le32_to_cpu(bcm->aux_data.unit);
- bcm->aux_data.width = le16_to_cpu(bcm->aux_data.width);
+ bcm->aux_data.unit = le32_to_cpu(data->unit);
+ bcm->aux_data.width = le16_to_cpu(data->width);
+ bcm->aux_data.vcd = data->vcd;
+ bcm->aux_data.reserved = data->reserved;
/*
* Link Qnodes to their respective BCMs
_______________________________________________
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 2/4] arm64: Avoid masking "old" for LSE cmpxchg() implementation
From: Will Deacon @ 2018-12-07 15:49 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: Catalin Marinas, linux-arm-kernel
In-Reply-To: <CAKv+Gu9jR3EgWDzyNB3YNRrvtD2L5Xo81VJ5+FpufDTNqSs8Kw@mail.gmail.com>
Hi Ard,
On Tue, Dec 04, 2018 at 05:58:50PM +0100, Ard Biesheuvel wrote:
> On Tue, 27 Nov 2018 at 20:44, Will Deacon <will.deacon@arm.com> wrote:
> >
> > The CAS instructions implicitly access only the relevant bits of the "old"
> > argument, so there is no need for explicit masking via type-casting as
> > there is in the LL/SC implementation.
> >
> > Move the casting into the LL/SC code and remove it altogether for the LSE
> > implementation.
> >
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> > arch/arm64/include/asm/atomic_ll_sc.h | 8 ++++++++
> > arch/arm64/include/asm/atomic_lse.h | 4 ++--
> > arch/arm64/include/asm/cmpxchg.h | 4 ++--
> > 3 files changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/atomic_ll_sc.h b/arch/arm64/include/asm/atomic_ll_sc.h
> > index f02d3bf7b9e6..b53f70dd6e10 100644
> > --- a/arch/arm64/include/asm/atomic_ll_sc.h
> > +++ b/arch/arm64/include/asm/atomic_ll_sc.h
> > @@ -257,6 +257,14 @@ __LL_SC_PREFIX(__cmpxchg_case_##name##sz(volatile void *ptr, \
> > unsigned long tmp; \
> > u##sz oldval; \
> > \
> > + /* \
> > + * Sub-word sizes require explicit casting so that the compare \
> > + * part of the cmpxchg doesn't end up interpreting non-zero \
> > + * upper bits of the register containing "old". \
> > + */ \
> > + if (sz < 32) \
> > + old = (u##sz)old; \
> > + \
> > asm volatile( \
> > " prfm pstl1strm, %[v]\n" \
> > "1: ld" #acq "xr" #sfx "\t%" #w "[oldval], %[v]\n" \
> > diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
> > index 4d6f917b654e..a424355240c5 100644
> > --- a/arch/arm64/include/asm/atomic_lse.h
> > +++ b/arch/arm64/include/asm/atomic_lse.h
> > @@ -448,11 +448,11 @@ static inline long atomic64_dec_if_positive(atomic64_t *v)
> >
> > #define __CMPXCHG_CASE(w, sfx, name, sz, mb, cl...) \
> > static inline u##sz __cmpxchg_case_##name##sz(volatile void *ptr, \
> > - unsigned long old, \
> > + u##sz old, \
> > u##sz new) \
> > { \
> > register unsigned long x0 asm ("x0") = (unsigned long)ptr; \
> > - register unsigned long x1 asm ("x1") = old; \
> > + register u##sz x1 asm ("x1") = old; \
>
> This looks backwards to me, but perhaps I am missing something:
> changing from unsigned long to a narrower type makes it the compiler's
> job to perform the cast, no? Given that 'cas' ignores the upper bits
> anyway, what does this change buy us?
A narrowing cast doesn't actually result in any additional instructions --
the masking occurs if you do a widening cast. In this case, the change I'm
proposing means we avoid the redundant widening casts for the LSE operations
because, as you point out, the underlying instruction only operates on the
relevant bits.
Will
_______________________________________________
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] arm64: hibernate: Avoid sending cross-calling with interrupts disabled
From: Catalin Marinas @ 2018-12-07 15:52 UTC (permalink / raw)
To: Will Deacon; +Cc: linux-arm-kernel, james.morse, hayashi.kunihiko, stable
In-Reply-To: <1544186830-27934-1-git-send-email-will.deacon@arm.com>
On Fri, Dec 07, 2018 at 12:47:10PM +0000, Will Deacon wrote:
> Since commit 3b8c9f1cdfc50 ("arm64: IPI each CPU after invalidating the
> I-cache for kernel mappings"), a call to flush_icache_range() will use
> an IPI to cross-call other online CPUs so that any stale instructions
> are flushed from their pipelines. This triggers a WARN during the
> hibernation resume path, where flush_icache_range() is called with
> interrupts disabled and is therefore prone to deadlock:
>
> | Disabling non-boot CPUs ...
> | CPU1: shutdown
> | psci: CPU1 killed.
> | CPU2: shutdown
> | psci: CPU2 killed.
> | CPU3: shutdown
> | psci: CPU3 killed.
> | WARNING: CPU: 0 PID: 1 at ../kernel/smp.c:416 smp_call_function_many+0xd4/0x350
> | Modules linked in:
> | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc4 #1
>
> Since all secondary CPUs have been taken offline prior to invalidating
> the I-cache, there's actually no need for an IPI and we can simply call
> __flush_icache_range() instead.
>
> Cc: <stable@vger.kernel.org>
> Fixes: 3b8c9f1cdfc50 ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings")
> Reported-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> Tested-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> Tested-by: James Morse <james.morse@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Queued for 4.20. Thanks.
--
Catalin
_______________________________________________
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/4] arm64: Avoid masking "old" for LSE cmpxchg() implementation
From: Ard Biesheuvel @ 2018-12-07 16:05 UTC (permalink / raw)
To: Will Deacon; +Cc: Catalin Marinas, linux-arm-kernel
In-Reply-To: <20181207154952.GA4000@edgewater-inn.cambridge.arm.com>
On Fri, 7 Dec 2018 at 16:49, Will Deacon <will.deacon@arm.com> wrote:
>
> Hi Ard,
>
> On Tue, Dec 04, 2018 at 05:58:50PM +0100, Ard Biesheuvel wrote:
> > On Tue, 27 Nov 2018 at 20:44, Will Deacon <will.deacon@arm.com> wrote:
> > >
> > > The CAS instructions implicitly access only the relevant bits of the "old"
> > > argument, so there is no need for explicit masking via type-casting as
> > > there is in the LL/SC implementation.
> > >
> > > Move the casting into the LL/SC code and remove it altogether for the LSE
> > > implementation.
> > >
> > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > ---
> > > arch/arm64/include/asm/atomic_ll_sc.h | 8 ++++++++
> > > arch/arm64/include/asm/atomic_lse.h | 4 ++--
> > > arch/arm64/include/asm/cmpxchg.h | 4 ++--
> > > 3 files changed, 12 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/atomic_ll_sc.h b/arch/arm64/include/asm/atomic_ll_sc.h
> > > index f02d3bf7b9e6..b53f70dd6e10 100644
> > > --- a/arch/arm64/include/asm/atomic_ll_sc.h
> > > +++ b/arch/arm64/include/asm/atomic_ll_sc.h
> > > @@ -257,6 +257,14 @@ __LL_SC_PREFIX(__cmpxchg_case_##name##sz(volatile void *ptr, \
> > > unsigned long tmp; \
> > > u##sz oldval; \
> > > \
> > > + /* \
> > > + * Sub-word sizes require explicit casting so that the compare \
> > > + * part of the cmpxchg doesn't end up interpreting non-zero \
> > > + * upper bits of the register containing "old". \
> > > + */ \
> > > + if (sz < 32) \
> > > + old = (u##sz)old; \
> > > + \
> > > asm volatile( \
> > > " prfm pstl1strm, %[v]\n" \
> > > "1: ld" #acq "xr" #sfx "\t%" #w "[oldval], %[v]\n" \
> > > diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
> > > index 4d6f917b654e..a424355240c5 100644
> > > --- a/arch/arm64/include/asm/atomic_lse.h
> > > +++ b/arch/arm64/include/asm/atomic_lse.h
> > > @@ -448,11 +448,11 @@ static inline long atomic64_dec_if_positive(atomic64_t *v)
> > >
> > > #define __CMPXCHG_CASE(w, sfx, name, sz, mb, cl...) \
> > > static inline u##sz __cmpxchg_case_##name##sz(volatile void *ptr, \
> > > - unsigned long old, \
> > > + u##sz old, \
> > > u##sz new) \
> > > { \
> > > register unsigned long x0 asm ("x0") = (unsigned long)ptr; \
> > > - register unsigned long x1 asm ("x1") = old; \
> > > + register u##sz x1 asm ("x1") = old; \
> >
> > This looks backwards to me, but perhaps I am missing something:
> > changing from unsigned long to a narrower type makes it the compiler's
> > job to perform the cast, no? Given that 'cas' ignores the upper bits
> > anyway, what does this change buy us?
>
> A narrowing cast doesn't actually result in any additional instructions --
> the masking occurs if you do a widening cast. In this case, the change I'm
> proposing means we avoid the redundant widening casts for the LSE operations
> because, as you point out, the underlying instruction only operates on the
> relevant bits.
>
Playing around with some code, I found out that
static inline void foo(unsigned char x)
{
asm("" :: "r"(x));
}
void bar(unsigned long l)
{
foo(l);
}
produces different code than
static inline void foo(unsigned longr x)
{
asm("" :: "r"(x));
}
void bar(unsigned long l)
{
foo((unsigned char)l);
}
so what you are saying appears to be accurate. Whether it is correct,
is another matter, though, since the 'unsigned char' argument passed
into the asm() block may have higher bits set.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Subject: [PATCH v4 0/4] mtd: rawnand: ams-delta: Use GPIO API for data I/O
From: Tony Lindgren @ 2018-12-07 16:10 UTC (permalink / raw)
To: Miquel Raynal
Cc: linux-omap, Aaro Koskinen, Richard Weinberger, Linus Walleij,
Janusz Krzysztofik, linux-kernel, Boris Brezillon, linux-mtd,
Brian Norris, David Woodhouse, Marek Vasut, linux-arm-kernel
In-Reply-To: <20181207090425.4480d2c0@xps13>
* Miquel Raynal <miquel.raynal@bootlin.com> [181207 08:04]:
> Hi Tony,
>
> Tony Lindgren <tony@atomide.com> wrote on Fri, 23 Nov 2018 09:03:33
> -0800:
>
> > * Boris Brezillon <boris.brezillon@bootlin.com> [181121 14:56]:
> > > On Wed, 21 Nov 2018 12:08:02 +0100
> > > Janusz Krzysztofik <jmkrzyszt@gmail.com> wrote:
> > >
> > > > Finalize implementation of the idea suggested by Artem Bityutskiy and
> > > > Tony Lindgren, described in commit b027274d2e3a ("mtd: ams-delta: fix
> > > > request_mem_region() failure"). Use pure GPIO consumer API, as reqested
> > > > by Boris Brezillon.
> > > >
> > > > Janusz Krzysztofik (4):
> > > > ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port
> > > > mtd: rawnand: ams-delta: Request data port GPIO resource
> > > > mtd: rawnand: ams-delta: Use GPIO API for data I/O
> > > > ARM: OMAP1: ams-delta: Drop obsolete NAND resources
> > > >
> > > > arch/arm/mach-omap1/board-ams-delta.c | 22 ++----
> > > > drivers/mtd/nand/raw/ams-delta.c | 120 +++++++++++++++++++---------------
> > > > 2 files changed, 80 insertions(+), 62 deletions(-)
> > > >
> > > > Performance on Amstrad Delta is now acceptable after recent extensions
> > > > to GPIO API and rawnanad enhancements.
> > > >
> > > > Series intented to be merged via mtd tree, should not conflict with
> > > > other OMAP1 patches submitted for 4.21.
> > >
> > > We'll prepare an immutable tag, just in case.
> >
> > Sounds good to me thanks:
> >
> > Acked-by: Tony Lindgren <tony@atomide.com>
>
> Actually, I can't setup a topic branch with this series because it
> depends on other changes in nand/next. If a conflict happens in -next,
> I suppose we will have to send you a PR.
Hmm OK I have pretty much all the stuff applied and in next
already so if it's not conflicting now it should not conflict.
Regards,
Tony
_______________________________________________
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 v4 2/6] arm64: add basic DTS for i.MX8MQ
From: Abel Vesa @ 2018-12-07 16:17 UTC (permalink / raw)
To: Rob Herring
Cc: Aisheng Dong, devicetree@vger.kernel.org,
patchwork-lst@pengutronix.de, dl-linux-imx, kernel@pengutronix.de,
Fabio Estevam, Shawn Guo, linux-arm-kernel@lists.infradead.org,
Lucas Stach
In-Reply-To: <20181116232524.GA2013@bogus>
On Fri, Nov 16, 2018 at 05:25:24PM -0600, Rob Herring wrote:
> > +
> > + clk_ext1: clock-ext1 {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <133000000>;
> > + clock-output-names = "clk_ext1";
> > + };
> > +
> > + clk_ext2: clock-ext2 {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <133000000>;
> > + clock-output-names = "clk_ext2";
> > + };
> > +
> > + clk_ext3: clock-ext3 {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <133000000>;
> > + clock-output-names = "clk_ext3";
> > + };
> > +
> > + clk_ext4: clock-ext4 {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency= <133000000>;
> > + clock-output-names = "clk_ext4";
> > + };
>
> This is really 4 independent clocks or is 1 clock connected to 4 sinks?
According to the RM, yes, there are 4 independent clocks. Here is a link to the rm:
https://www.nxp.com/webapp/Download?colCode=IMX8MEVKBHUG (page 829)
Unfortunately, the old link (which worked without login) does not work anymore.
--
_______________________________________________
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/4] arm64: Avoid masking "old" for LSE cmpxchg() implementation
From: Will Deacon @ 2018-12-07 16:22 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: Catalin Marinas, linux-arm-kernel
In-Reply-To: <CAKv+Gu9deCArTiuGXSw3U0hzFTd27DJmr+m1vFy+VOWZa41QuA@mail.gmail.com>
On Fri, Dec 07, 2018 at 05:05:16PM +0100, Ard Biesheuvel wrote:
> On Fri, 7 Dec 2018 at 16:49, Will Deacon <will.deacon@arm.com> wrote:
> >
> > Hi Ard,
> >
> > On Tue, Dec 04, 2018 at 05:58:50PM +0100, Ard Biesheuvel wrote:
> > > On Tue, 27 Nov 2018 at 20:44, Will Deacon <will.deacon@arm.com> wrote:
> > > >
> > > > The CAS instructions implicitly access only the relevant bits of the "old"
> > > > argument, so there is no need for explicit masking via type-casting as
> > > > there is in the LL/SC implementation.
> > > >
> > > > Move the casting into the LL/SC code and remove it altogether for the LSE
> > > > implementation.
> > > >
> > > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > > ---
> > > > arch/arm64/include/asm/atomic_ll_sc.h | 8 ++++++++
> > > > arch/arm64/include/asm/atomic_lse.h | 4 ++--
> > > > arch/arm64/include/asm/cmpxchg.h | 4 ++--
> > > > 3 files changed, 12 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/include/asm/atomic_ll_sc.h b/arch/arm64/include/asm/atomic_ll_sc.h
> > > > index f02d3bf7b9e6..b53f70dd6e10 100644
> > > > --- a/arch/arm64/include/asm/atomic_ll_sc.h
> > > > +++ b/arch/arm64/include/asm/atomic_ll_sc.h
> > > > @@ -257,6 +257,14 @@ __LL_SC_PREFIX(__cmpxchg_case_##name##sz(volatile void *ptr, \
> > > > unsigned long tmp; \
> > > > u##sz oldval; \
> > > > \
> > > > + /* \
> > > > + * Sub-word sizes require explicit casting so that the compare \
> > > > + * part of the cmpxchg doesn't end up interpreting non-zero \
> > > > + * upper bits of the register containing "old". \
> > > > + */ \
> > > > + if (sz < 32) \
> > > > + old = (u##sz)old; \
> > > > + \
> > > > asm volatile( \
> > > > " prfm pstl1strm, %[v]\n" \
> > > > "1: ld" #acq "xr" #sfx "\t%" #w "[oldval], %[v]\n" \
> > > > diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
> > > > index 4d6f917b654e..a424355240c5 100644
> > > > --- a/arch/arm64/include/asm/atomic_lse.h
> > > > +++ b/arch/arm64/include/asm/atomic_lse.h
> > > > @@ -448,11 +448,11 @@ static inline long atomic64_dec_if_positive(atomic64_t *v)
> > > >
> > > > #define __CMPXCHG_CASE(w, sfx, name, sz, mb, cl...) \
> > > > static inline u##sz __cmpxchg_case_##name##sz(volatile void *ptr, \
> > > > - unsigned long old, \
> > > > + u##sz old, \
> > > > u##sz new) \
> > > > { \
> > > > register unsigned long x0 asm ("x0") = (unsigned long)ptr; \
> > > > - register unsigned long x1 asm ("x1") = old; \
> > > > + register u##sz x1 asm ("x1") = old; \
> > >
> > > This looks backwards to me, but perhaps I am missing something:
> > > changing from unsigned long to a narrower type makes it the compiler's
> > > job to perform the cast, no? Given that 'cas' ignores the upper bits
> > > anyway, what does this change buy us?
> >
> > A narrowing cast doesn't actually result in any additional instructions --
> > the masking occurs if you do a widening cast. In this case, the change I'm
> > proposing means we avoid the redundant widening casts for the LSE operations
> > because, as you point out, the underlying instruction only operates on the
> > relevant bits.
> >
>
> Playing around with some code, I found out that
>
> static inline void foo(unsigned char x)
> {
> asm("" :: "r"(x));
> }
>
> void bar(unsigned long l)
> {
> foo(l);
> }
>
> produces different code than
>
> static inline void foo(unsigned longr x)
> {
> asm("" :: "r"(x));
> }
>
> void bar(unsigned long l)
> {
> foo((unsigned char)l);
> }
>
> so what you are saying appears to be accurate. Whether it is correct,
> is another matter, though, since the 'unsigned char' argument passed
> into the asm() block may have higher bits set.
Right, which is why I've kept the casting for sizes < 32 bits in the LL/SC
code.
Will
_______________________________________________
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 v11 8/8] interconnect: sdm845: Fix build failure after cmd_db API change
From: Quentin Perret @ 2018-12-07 16:27 UTC (permalink / raw)
To: Georgi Djakov
Cc: mark.rutland, sanjayc, maxime.ripard, mturquette, daidavid1,
bjorn.andersson, skannan, abailon, lorenzo.pieralisi,
vincent.guittot, seansw, khilman, evgreen, ksitaraman, devicetree,
arnd, linux-pm, linux-arm-msm, robh+dt, linux-tegra,
linux-arm-kernel, gregkh, rjw, dianders, amit.kucheria,
linux-kernel, thierry.reding
In-Reply-To: <20181207152917.4862-9-georgi.djakov@linaro.org>
Hi Georgi,
On Friday 07 Dec 2018 at 17:29:17 (+0200), Georgi Djakov wrote:
> Recently the cmd_db_read_aux_data() function was changed to avoid using
> memcpy and return a pointer instead. Update the code to the new API and
> fix the build failure.
>
> Fixes: ed3cafa79ea7 ("soc: qcom: cmd-db: Stop memcpy()ing in cmd_db_read_aux_data()")
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
> drivers/interconnect/qcom/sdm845.c | 26 ++++++++++++++------------
IIUC this file is introduced by patch 5. Should the fix be squashed
into patch 5 directly ? Just to keep things bisectable.
Thanks,
Quentin
_______________________________________________
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] arm64: dts: clearfog-gt-8k: describe mini-PCIe CON2 USB
From: Gregory CLEMENT @ 2018-12-07 16:28 UTC (permalink / raw)
To: Baruch Siach
Cc: Russell King, Andrew Lunn, Jason Cooper, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <87ftvak2pq.fsf@tkos.co.il>
Hi Baruch,
On jeu., déc. 06 2018, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Gregory,
>
> Gregory CLEMENT writes:
>> On jeu., déc. 06 2018, Baruch Siach <baruch@tkos.co.il> wrote:
>>
>>> Enable the USB3 peripheral that is wired to CON2 on the Clearfog GT-8K
>>> board.
>>>
>>> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
>>> ---
>>> arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
>>> index dfb26661a88e..5b4a9609e31f 100644
>>> --- a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
>>> +++ b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
>>> @@ -282,6 +282,10 @@
>>> vqmmc-supply = <&v_3_3>;
>>> };
>>>
>>> +&cp0_usb3_1 {
>>
>> Don't you have any phy for this USB3 port?
>
> Not as far as I can see. Why would I need one? The serdes signals are
> connected directly to the mini-PCIe, just like the USB Type-A connector
> on the same board. I haven't tested the USB3 signals on the mini-PCIe,
> though, as I have no USB3 mini-PCIe device.
Right! I focused on the commit itself and missed the fact that it was
part of a PCI connector as stated in the title. I asked this because
usually we have a phy connected to a vcc signal.
Applied on mvebu/dt64
Thanks,
Gregory
>
> baruch
>
>>> + status = "okay";
>>> +};
>>> +
>>> &cp1_pinctrl {
>>> /*
>>> * MPP Bus:
>>> --
>>> 2.19.2
>>>
>
>
> --
> http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
_______________________________________________
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] ACPI / scan: Refactor _CCA enforcement
From: Robin Murphy @ 2018-12-07 16:31 UTC (permalink / raw)
To: hch
Cc: linux-pci, catalin.marinas, rjw, linux-kernel, will.deacon,
linux-acpi, iommu, gregkh, bhelgaas, lenb, linux-arm-kernel,
m.szyprowski
In-Reply-To: <cover.1544199754.git.robin.murphy@arm.com>
Rather than checking the DMA attribute at each callsite, just pass it
through for acpi_dma_configure() to handle directly. That can then deal
with the relatively exceptional DEV_DMA_NOT_SUPPORTED case by explicitly
installing dummy DMA ops instead of just skipping setup entirely. This
will then free up the dev->dma_ops == NULL case for some valuable
fastpath optimisations.
CC: Rafael J. Wysocki <rjw@rjwysocki.net>
CC: Len Brown <lenb@kernel.org>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/acpi/scan.c | 5 +++++
drivers/base/platform.c | 3 +--
drivers/pci/pci-driver.c | 3 +--
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index bd1c59fb0e17..b75ae34ed188 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1456,6 +1456,11 @@ int acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
const struct iommu_ops *iommu;
u64 dma_addr = 0, size = 0;
+ if (attr == DEV_DMA_NOT_SUPPORTED) {
+ set_dma_ops(dev, &dma_dummy_ops);
+ return 0;
+ }
+
iort_dma_setup(dev, &dma_addr, &size);
iommu = iort_iommu_configure(dev);
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 41b91af95afb..c6daca875c17 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1138,8 +1138,7 @@ int platform_dma_configure(struct device *dev)
ret = of_dma_configure(dev, dev->of_node, true);
} else if (has_acpi_companion(dev)) {
attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
- if (attr != DEV_DMA_NOT_SUPPORTED)
- ret = acpi_dma_configure(dev, attr);
+ ret = acpi_dma_configure(dev, attr);
}
return ret;
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index bef17c3fca67..f899a28b90f8 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1602,8 +1602,7 @@ static int pci_dma_configure(struct device *dev)
struct acpi_device *adev = to_acpi_device_node(bridge->fwnode);
enum dev_dma_attr attr = acpi_get_dma_attr(adev);
- if (attr != DEV_DMA_NOT_SUPPORTED)
- ret = acpi_dma_configure(dev, attr);
+ ret = acpi_dma_configure(dev, attr);
}
pci_put_host_bridge_device(bridge);
--
2.19.1.dirty
_______________________________________________
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] dma-mapping: Factor out dummy DMA ops
From: Robin Murphy @ 2018-12-07 16:31 UTC (permalink / raw)
To: hch
Cc: linux-pci, catalin.marinas, rjw, linux-kernel, will.deacon,
linux-acpi, iommu, gregkh, bhelgaas, lenb, linux-arm-kernel,
m.szyprowski
In-Reply-To: <cover.1544199754.git.robin.murphy@arm.com>
The dummy DMA ops are currently used by arm64 for any device which has
an invalid ACPI description and is thus barred from using DMA due to not
knowing whether is is cache-coherent or not. Factor these out into
general dma-mapping code so that they can be referenced from other
common code paths. In the process, we can prune all the optional
callbacks which just do the same thing as the default behaviour, and
fill in .map_resource for completeness.
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Will Deacon <will.deacon@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
arch/arm64/include/asm/dma-mapping.h | 4 +-
arch/arm64/mm/dma-mapping.c | 92 ----------------------------
include/linux/dma-mapping.h | 1 +
kernel/dma/mapping.c | 54 ++++++++++++++++
4 files changed, 56 insertions(+), 95 deletions(-)
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index c41f3fb1446c..273e778f7de2 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -24,15 +24,13 @@
#include <xen/xen.h>
#include <asm/xen/hypervisor.h>
-extern const struct dma_map_ops dummy_dma_ops;
-
static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
{
/*
* We expect no ISA devices, and all other DMA masters are expected to
* have someone call arch_setup_dma_ops at device creation time.
*/
- return &dummy_dma_ops;
+ return &dma_dummy_ops;
}
void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index a3ac26284845..f3af6cc52fad 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -252,98 +252,6 @@ static int __init atomic_pool_init(void)
return -ENOMEM;
}
-/********************************************
- * The following APIs are for dummy DMA ops *
- ********************************************/
-
-static void *__dummy_alloc(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t flags,
- unsigned long attrs)
-{
- return NULL;
-}
-
-static void __dummy_free(struct device *dev, size_t size,
- void *vaddr, dma_addr_t dma_handle,
- unsigned long attrs)
-{
-}
-
-static int __dummy_mmap(struct device *dev,
- struct vm_area_struct *vma,
- void *cpu_addr, dma_addr_t dma_addr, size_t size,
- unsigned long attrs)
-{
- return -ENXIO;
-}
-
-static dma_addr_t __dummy_map_page(struct device *dev, struct page *page,
- unsigned long offset, size_t size,
- enum dma_data_direction dir,
- unsigned long attrs)
-{
- return 0;
-}
-
-static void __dummy_unmap_page(struct device *dev, dma_addr_t dev_addr,
- size_t size, enum dma_data_direction dir,
- unsigned long attrs)
-{
-}
-
-static int __dummy_map_sg(struct device *dev, struct scatterlist *sgl,
- int nelems, enum dma_data_direction dir,
- unsigned long attrs)
-{
- return 0;
-}
-
-static void __dummy_unmap_sg(struct device *dev,
- struct scatterlist *sgl, int nelems,
- enum dma_data_direction dir,
- unsigned long attrs)
-{
-}
-
-static void __dummy_sync_single(struct device *dev,
- dma_addr_t dev_addr, size_t size,
- enum dma_data_direction dir)
-{
-}
-
-static void __dummy_sync_sg(struct device *dev,
- struct scatterlist *sgl, int nelems,
- enum dma_data_direction dir)
-{
-}
-
-static int __dummy_mapping_error(struct device *hwdev, dma_addr_t dma_addr)
-{
- return 1;
-}
-
-static int __dummy_dma_supported(struct device *hwdev, u64 mask)
-{
- return 0;
-}
-
-const struct dma_map_ops dummy_dma_ops = {
- .alloc = __dummy_alloc,
- .free = __dummy_free,
- .mmap = __dummy_mmap,
- .map_page = __dummy_map_page,
- .unmap_page = __dummy_unmap_page,
- .map_sg = __dummy_map_sg,
- .unmap_sg = __dummy_unmap_sg,
- .sync_single_for_cpu = __dummy_sync_single,
- .sync_single_for_device = __dummy_sync_single,
- .sync_sg_for_cpu = __dummy_sync_sg,
- .sync_sg_for_device = __dummy_sync_sg,
- .mapping_error = __dummy_mapping_error,
- .dma_supported = __dummy_dma_supported,
-};
-EXPORT_SYMBOL(dummy_dma_ops);
-
static int __init arm64_dma_init(void)
{
WARN_TAINT(ARCH_DMA_MINALIGN < cache_line_size(),
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 15bd41447025..3a1928ea23c9 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -134,6 +134,7 @@ struct dma_map_ops {
};
extern const struct dma_map_ops dma_direct_ops;
+extern const struct dma_map_ops dma_dummy_ops;
extern const struct dma_map_ops dma_virt_ops;
#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 58dec7a92b7b..957a42ebabcf 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -346,3 +346,57 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
vunmap(cpu_addr);
}
#endif
+
+/*
+ * Dummy DMA ops always fail
+ */
+
+static int dma_dummy_mmap(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ unsigned long attrs)
+{
+ return -ENXIO;
+}
+
+static dma_addr_t dma_dummy_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ return 0;
+}
+
+static int dma_dummy_map_sg(struct device *dev, struct scatterlist *sgl,
+ int nelems, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ return 0;
+}
+
+static dma_addr_t dma_dummy_map_resource(struct device *dev,
+ phys_addr_t phys_addr, size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ return 0;
+}
+
+static int dma_dummy_mapping_error(struct device *hwdev, dma_addr_t dma_addr)
+{
+ return 1;
+}
+
+static int dma_dummy_supported(struct device *hwdev, u64 mask)
+{
+ return 0;
+}
+
+const struct dma_map_ops dma_dummy_ops = {
+ .mmap = dma_dummy_mmap,
+ .map_page = dma_dummy_map_page,
+ .map_sg = dma_dummy_map_sg,
+ .map_resource = dma_dummy_map_resource,
+ .mapping_error = dma_dummy_mapping_error,
+ .dma_supported = dma_dummy_supported,
+};
+EXPORT_SYMBOL(dma_dummy_ops);
--
2.19.1.dirty
_______________________________________________
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] Refactor dummy DMA ops
From: Robin Murphy @ 2018-12-07 16:31 UTC (permalink / raw)
To: hch
Cc: linux-pci, catalin.marinas, rjw, linux-kernel, will.deacon,
linux-acpi, iommu, gregkh, bhelgaas, lenb, linux-arm-kernel,
m.szyprowski
Hi all,
Tangential to Christoph's RFC for mitigating indirect call overhead in
common DMA mapping scenarios[1], this is a little reshuffle to prevent the
CONFIG_ACPI_CCA_REQUIRED case from getting in the way. This would best go
via the dma-mapping tree, so reviews and acks welcome.
Robin.
[1] https://lore.kernel.org/lkml/20181206153720.10702-1-hch@lst.de/
Robin Murphy (2):
dma-mapping: Factor out dummy DMA ops
ACPI / scan: Refactor _CCA enforcement
arch/arm64/include/asm/dma-mapping.h | 4 +-
arch/arm64/mm/dma-mapping.c | 92 ----------------------------
drivers/acpi/scan.c | 5 ++
drivers/base/platform.c | 3 +-
drivers/pci/pci-driver.c | 3 +-
include/linux/dma-mapping.h | 1 +
kernel/dma/mapping.c | 54 ++++++++++++++++
7 files changed, 63 insertions(+), 99 deletions(-)
--
2.19.1.dirty
_______________________________________________
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 2/3] arm64: dts: allwinner: a64: Add A64 CSI controller
From: Jagan Teki @ 2018-12-07 16:36 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, linux-kernel, Chen-Yu Tsai, Rob Herring,
Michael Trimarchi, linux-amarula, linux-arm-kernel
In-Reply-To: <20181207074723.l3ykhqojfkd4y4ie@flea>
On Fri, Dec 7, 2018 at 1:17 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Thu, Dec 06, 2018 at 06:07:59PM +0100, Michael Nazzareno Trimarchi wrote:
> > On Thu, Dec 6, 2018 at 4:34 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > On Thu, Dec 06, 2018 at 06:53:05PM +0530, Jagan Teki wrote:
> > > > Allwinner A64 CSI controller has similar features as like in
> > > > H3, So add support for A64 via H3 fallback.
> > > >
> > > > Also updated CSI_SCLK to use 300MHz via assigned-clocks, since
> > > > the default clock 600MHz seems unable to drive the sensor(ov5640)
> > > > to capture the image.
> > > >
> > > > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > ---
> > > > Changes for v2:
> > > > - Use CSI_SCLK to 300MHz
> > > >
> > > > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 +++++++++++++++++++
> > > > 1 file changed, 23 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > > index 384c417cb7a2..d7ab0006ebce 100644
> > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > > @@ -532,6 +532,12 @@
> > > > interrupt-controller;
> > > > #interrupt-cells = <3>;
> > > >
> > > > + csi_pins: csi-pins {
> > > > + pins = "PE0", "PE2", "PE3", "PE4", "PE5", "PE6",
> > > > + "PE7", "PE8", "PE9", "PE10", "PE11";
> > > > + function = "csi0";
> > > > + };
> > > > +
> > > > i2c0_pins: i2c0_pins {
> > > > pins = "PH0", "PH1";
> > > > function = "i2c0";
> > > > @@ -899,6 +905,23 @@
> > > > status = "disabled";
> > > > };
> > > >
> > > > + csi: csi@1cb0000 {
> > > > + compatible = "allwinner,sun50i-a64-csi",
> > > > + "allwinner,sun8i-h3-csi";
> > > > + reg = <0x01cb0000 0x1000>;
> > > > + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> > > > + clocks = <&ccu CLK_BUS_CSI>,
> > > > + <&ccu CLK_CSI_SCLK>,
> > > > + <&ccu CLK_DRAM_CSI>;
> > > > + clock-names = "bus", "mod", "ram";
> > > > + resets = <&ccu RST_BUS_CSI>;
> > > > + pinctrl-names = "default";
> > > > + pinctrl-0 = <&csi_pins>;
> > > > + assigned-clocks = <&ccu CLK_CSI_SCLK>;
> > > > + assigned-clock-rates = <300000000>;
> > >
> > > That should be enforced in the driver.
> > >
> >
> > We are not really sure what is the best here. Our first idea was to
> > put in the board file and then Jagan
> > decide to put in dtsi. We don't have enough coverage of camera on this
> > CPU and I prefer to stay with this
> > minimal change that does not impact the driver.
>
> The thing is that:
> - in this commit log, you're stating that it depends on the sensor,
> which indicates that this would be a board level addition
> - In another patch series, Jagan reported IIRC that it actually
> depends on the resolution, so it doesn't belong in the DT at all
> - And then, you don't even have any guarantee on the clock rate. The
> sole guarantee you have is that when your driver will probe, the
> rate will be close to those 300MHz. That's it. It might completely
> change after the driver has probed, or be rounded to something
> else entirely, who knows.
Let's to be clear.
- with default clock(600MHz) the sensor get probed but image capture
has an issue.
- with 300MHz the image capture working with 320x240@30, 640x480@30,
640x480@60, 1280x720@30 with UYVY8_2X8 and YUYV8_2X8 formats but
1080p@30 seems broken (the same I have mentioned in another mail)
- since all this is verified on ov5640, I have mentioned the same
thing on commit message for future reference.
_______________________________________________
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 v4 2/6] arm64: add basic DTS for i.MX8MQ
From: Lucas Stach @ 2018-12-07 16:36 UTC (permalink / raw)
To: Abel Vesa, Rob Herring
Cc: Aisheng Dong, devicetree@vger.kernel.org,
patchwork-lst@pengutronix.de, dl-linux-imx, kernel@pengutronix.de,
Fabio Estevam, Shawn Guo, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181207161723.2u5z3sdobbpop4kz@fsr-ub1664-175>
Hi Abel,
Am Freitag, den 07.12.2018, 16:17 +0000 schrieb Abel Vesa:
> On Fri, Nov 16, 2018 at 05:25:24PM -0600, Rob Herring wrote:
>
> > > +
> > > + clk_ext1: clock-ext1 {
> > > + compatible = "fixed-clock";
> > > + #clock-cells = <0>;
> > > + clock-frequency = <133000000>;
> > > + clock-output-names = "clk_ext1";
> > > + };
> > > +
> > > + clk_ext2: clock-ext2 {
> > > + compatible = "fixed-clock";
> > > + #clock-cells = <0>;
> > > + clock-frequency = <133000000>;
> > > + clock-output-names = "clk_ext2";
> > > + };
> > > +
> > > + clk_ext3: clock-ext3 {
> > > + compatible = "fixed-clock";
> > > + #clock-cells = <0>;
> > > + clock-frequency = <133000000>;
> > > + clock-output-names = "clk_ext3";
> > > + };
> > > +
> > > + clk_ext4: clock-ext4 {
> > > + compatible = "fixed-clock";
> > > + #clock-cells = <0>;
> > > + clock-frequency= <133000000>;
> > > + clock-output-names = "clk_ext4";
> > > + };
> >
> > This is really 4 independent clocks or is 1 clock connected to 4
> > sinks?
>
> According to the RM, yes, there are 4 independent clocks. Here is a
> link to the rm:
>
> https://www.nxp.com/webapp/Download?colCode=IMX8MEVKBHUG (page 829)
>
> Unfortunately, the old link (which worked without login) does not
> work anymore.
It's really 4 clock inputs to the SoC, but they may actually be
connected to the same clock source on the board. So I really wonder if
we should even put this into the base SoC DT, but rather push this into
individual board DTs.
Regards,
Lucas
_______________________________________________
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 v6 8/8] mfd: axp20x: Add supported cells for AXP803
From: Lee Jones @ 2018-12-07 16:40 UTC (permalink / raw)
To: Oskari Lemmela
Cc: Mark Rutland, devicetree, Quentin Schulz, linux-pm, Maxime Ripard,
Sebastian Reichel, linux-kernel, Vasily Khoruzhick, Chen-Yu Tsai,
Rob Herring, linux-arm-kernel
In-Reply-To: <20181120175211.3913-9-oskari@lemmela.net>
On Tue, 20 Nov 2018, Oskari Lemmela wrote:
> Parts of the AXP803 are compatible with their counterparts on the AXP813.
> These include the GPIO, ADC, AC and battery power supplies.
>
> Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
> Reviewed-by: Chen-Yu Tsai <wens@csie.org>
> Tested-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> drivers/mfd/axp20x.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index dfc3cff1d08b..e415b967d38c 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -728,11 +728,26 @@ static const struct mfd_cell axp288_cells[] = {
>
> static const struct mfd_cell axp803_cells[] = {
> {
> + .name = "axp20x-gpio",
> + .of_compatible = "x-powers,axp813-gpio",
> + }, {
> .name = "axp221-pek",
> .num_resources = ARRAY_SIZE(axp803_pek_resources),
> .resources = axp803_pek_resources,
> },
> { .name = "axp20x-regulator" },
> + {
> + .name = "axp813-adc",
> + .of_compatible = "x-powers,axp813-adc",
> + }, {
> + .name = "axp20x-battery-power-supply",
> + .of_compatible = "x-powers,axp813-battery-power-supply",
> + }, {
> + .name = "axp20x-ac-power-supply",
> + .of_compatible = "x-powers,axp813-ac-power-supply",
> + .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> + .resources = axp20x_ac_power_supply_resources,
> + },
> };
My OCD-dar is going crazy.
Why haven't you used the same alignment as is already there?
If it starts to run over 80-chars then bring the others back.
Also why is there a single liner shoved in the middle of the
multi-line entries? Please move the singles to the top or the
bottom.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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 v6 7/8] mfd: axp20x: Add AC power supply cell for AXP813
From: Lee Jones @ 2018-12-07 16:40 UTC (permalink / raw)
To: Oskari Lemmela
Cc: Mark Rutland, devicetree, Quentin Schulz, linux-pm, Maxime Ripard,
Sebastian Reichel, linux-kernel, Vasily Khoruzhick, Chen-Yu Tsai,
Rob Herring, linux-arm-kernel
In-Reply-To: <20181120175211.3913-8-oskari@lemmela.net>
On Tue, 20 Nov 2018, Oskari Lemmela wrote:
> As axp20x-ac-power-supply now supports AXP813, add a cell for it.
>
> Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
> Reviewed-by: Quentin Schulz <quentin.schulz@bootlin.com>
> Reviewed-by: Chen-Yu Tsai <wens@csie.org>
> Tested-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> drivers/mfd/axp20x.c | 5 +++++
> 1 file changed, 5 insertions(+)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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 v11 8/8] interconnect: sdm845: Fix build failure after cmd_db API change
From: Georgi Djakov @ 2018-12-07 16:47 UTC (permalink / raw)
To: Quentin Perret
Cc: mark.rutland, sanjayc, maxime.ripard, mturquette, daidavid1,
bjorn.andersson, skannan, abailon, lorenzo.pieralisi,
vincent.guittot, seansw, khilman, evgreen, ksitaraman, devicetree,
arnd, linux-pm, linux-arm-msm, robh+dt, linux-tegra,
linux-arm-kernel, gregkh, rjw, dianders, amit.kucheria,
linux-kernel, thierry.reding
In-Reply-To: <20181207162733.pdd62qvqzd6xk4nr@queper01-lin>
Hi Quentin,
On 12/7/18 18:27, Quentin Perret wrote:
> Hi Georgi,
>
> On Friday 07 Dec 2018 at 17:29:17 (+0200), Georgi Djakov wrote:
>> Recently the cmd_db_read_aux_data() function was changed to avoid using
>> memcpy and return a pointer instead. Update the code to the new API and
>> fix the build failure.
>>
>> Fixes: ed3cafa79ea7 ("soc: qcom: cmd-db: Stop memcpy()ing in cmd_db_read_aux_data()")
>> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
>> ---
>> drivers/interconnect/qcom/sdm845.c | 26 ++++++++++++++------------
>
> IIUC this file is introduced by patch 5. Should the fix be squashed
> into patch 5 directly ? Just to keep things bisectable.
The reason why i have split it as a separate change is because as a
separate change it would be easier to review & test for the people who
are already familiar with the rest of the series.
Another minor reason is that a separate patch will also make the life a
bit easier for some people who are back-porting this to kernels using
the older version of the cmd_db API.
The commit that changed the cmd_db API is not yet in mainline, but in
linux-next. I am not sure what is preferred in this case?
Thanks,
Georgi
_______________________________________________
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: OMAP1: ams-delta: Fix audio permanently muted
From: Tony Lindgren @ 2018-12-07 16:53 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: linux-omap, linux-kernel, linux-arm-kernel, Aaro Koskinen
In-Reply-To: <20181123111945.6016-1-jmkrzyszt@gmail.com>
* Janusz Krzysztofik <jmkrzyszt@gmail.com> [181123 03:18]:
> Since commit 1137ceee76ba ("ARM: OMAP1: ams-delta: Don't request unused
> GPIOs"), on-board audio has appeared muted. Believed to be unused GPIO
> pin "hookflash1", apparently set high regardless of the corresponding
> bit of "latch2" port attempted to be set low during .init_machine(),
> has been identified as the reason.
>
> According to Amstrad E3 wiki, the purpose of the pin hasn't been
> clearly identified. Original Amstrad software used to produce a high
> pulse on it when the phone was taken off hook or recall was pressed.
> With the current finding, we can assume the pin provides a kind of
> audio mute function.
>
> Proper resolution of the issue should be done in two steps:
> - resolution of an issue with the pin state not reflecting the value
> the corresponding bit of the port was attempted to be initialized
> with,
> - extension of on-board audio driver with a new control.
>
> For now, rename the pin to "audio_mute" to reflect its function and,
> as a quick fix, hogg it as output low so on-board audio can produce
> audible sound again.
>
> Fixes: 1137ceee76ba ("ARM: OMAP1: ams-delta: Don't request unused GPIOs")
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Adding into omap-for-v4.20/fixes thanks.
Tony
_______________________________________________
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/4] arm64: Avoid masking "old" for LSE cmpxchg() implementation
From: Ard Biesheuvel @ 2018-12-07 17:03 UTC (permalink / raw)
To: Will Deacon; +Cc: Catalin Marinas, linux-arm-kernel
In-Reply-To: <20181207162224.GA4159@edgewater-inn.cambridge.arm.com>
On Fri, 7 Dec 2018 at 17:22, Will Deacon <will.deacon@arm.com> wrote:
>
> On Fri, Dec 07, 2018 at 05:05:16PM +0100, Ard Biesheuvel wrote:
> > On Fri, 7 Dec 2018 at 16:49, Will Deacon <will.deacon@arm.com> wrote:
> > >
> > > Hi Ard,
> > >
> > > On Tue, Dec 04, 2018 at 05:58:50PM +0100, Ard Biesheuvel wrote:
> > > > On Tue, 27 Nov 2018 at 20:44, Will Deacon <will.deacon@arm.com> wrote:
> > > > >
> > > > > The CAS instructions implicitly access only the relevant bits of the "old"
> > > > > argument, so there is no need for explicit masking via type-casting as
> > > > > there is in the LL/SC implementation.
> > > > >
> > > > > Move the casting into the LL/SC code and remove it altogether for the LSE
> > > > > implementation.
> > > > >
> > > > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > > > ---
> > > > > arch/arm64/include/asm/atomic_ll_sc.h | 8 ++++++++
> > > > > arch/arm64/include/asm/atomic_lse.h | 4 ++--
> > > > > arch/arm64/include/asm/cmpxchg.h | 4 ++--
> > > > > 3 files changed, 12 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm64/include/asm/atomic_ll_sc.h b/arch/arm64/include/asm/atomic_ll_sc.h
> > > > > index f02d3bf7b9e6..b53f70dd6e10 100644
> > > > > --- a/arch/arm64/include/asm/atomic_ll_sc.h
> > > > > +++ b/arch/arm64/include/asm/atomic_ll_sc.h
> > > > > @@ -257,6 +257,14 @@ __LL_SC_PREFIX(__cmpxchg_case_##name##sz(volatile void *ptr, \
> > > > > unsigned long tmp; \
> > > > > u##sz oldval; \
> > > > > \
> > > > > + /* \
> > > > > + * Sub-word sizes require explicit casting so that the compare \
> > > > > + * part of the cmpxchg doesn't end up interpreting non-zero \
> > > > > + * upper bits of the register containing "old". \
> > > > > + */ \
> > > > > + if (sz < 32) \
> > > > > + old = (u##sz)old; \
> > > > > + \
> > > > > asm volatile( \
> > > > > " prfm pstl1strm, %[v]\n" \
> > > > > "1: ld" #acq "xr" #sfx "\t%" #w "[oldval], %[v]\n" \
> > > > > diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
> > > > > index 4d6f917b654e..a424355240c5 100644
> > > > > --- a/arch/arm64/include/asm/atomic_lse.h
> > > > > +++ b/arch/arm64/include/asm/atomic_lse.h
> > > > > @@ -448,11 +448,11 @@ static inline long atomic64_dec_if_positive(atomic64_t *v)
> > > > >
> > > > > #define __CMPXCHG_CASE(w, sfx, name, sz, mb, cl...) \
> > > > > static inline u##sz __cmpxchg_case_##name##sz(volatile void *ptr, \
> > > > > - unsigned long old, \
> > > > > + u##sz old, \
> > > > > u##sz new) \
> > > > > { \
> > > > > register unsigned long x0 asm ("x0") = (unsigned long)ptr; \
> > > > > - register unsigned long x1 asm ("x1") = old; \
> > > > > + register u##sz x1 asm ("x1") = old; \
> > > >
> > > > This looks backwards to me, but perhaps I am missing something:
> > > > changing from unsigned long to a narrower type makes it the compiler's
> > > > job to perform the cast, no? Given that 'cas' ignores the upper bits
> > > > anyway, what does this change buy us?
> > >
> > > A narrowing cast doesn't actually result in any additional instructions --
> > > the masking occurs if you do a widening cast. In this case, the change I'm
> > > proposing means we avoid the redundant widening casts for the LSE operations
> > > because, as you point out, the underlying instruction only operates on the
> > > relevant bits.
> > >
> >
> > Playing around with some code, I found out that
> >
> > static inline void foo(unsigned char x)
> > {
> > asm("" :: "r"(x));
> > }
> >
> > void bar(unsigned long l)
> > {
> > foo(l);
> > }
> >
> > produces different code than
> >
> > static inline void foo(unsigned longr x)
> > {
> > asm("" :: "r"(x));
> > }
> >
> > void bar(unsigned long l)
> > {
> > foo((unsigned char)l);
> > }
> >
> > so what you are saying appears to be accurate. Whether it is correct,
> > is another matter, though, since the 'unsigned char' argument passed
> > into the asm() block may have higher bits set.
>
> Right, which is why I've kept the casting for sizes < 32 bits in the LL/SC
> code.
>
OK.
So if we are relying on the cast to occur implicitly by the cas
instruction, does it really make sense to change the prototype?
Shouldn't we keep it at unsigned long so that we explicitly pass the
whole value in (but use an explicit cast in the LL/SC implementation
as you did)
_______________________________________________
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 0/2] Refactor dummy DMA ops
From: Christoph Hellwig @ 2018-12-07 17:05 UTC (permalink / raw)
To: Robin Murphy
Cc: rjw, linux-pci, catalin.marinas, will.deacon, linux-kernel,
linux-acpi, iommu, gregkh, bhelgaas, lenb, hch, linux-arm-kernel,
m.szyprowski
In-Reply-To: <cover.1544199754.git.robin.murphy@arm.com>
So I'd really prefer if we had a separate dummy.c file, like in
my take on your previous patch here:
http://git.infradead.org/users/hch/misc.git/commitdiff/e01adddc1733fa414dc16cd22e8f58be9b64a025
http://git.infradead.org/users/hch/misc.git/commitdiff/596bde76e5944a3f4beb8c2769067ca88dda127a
Otherwise this looks fine. If you don't minde I'll take your patches,
apply the move to a separate file and merge it into the above tree.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] drm/msm/a6xx: Add support for an interconnect path
From: Jordan Crouse @ 2018-12-07 17:06 UTC (permalink / raw)
To: freedreno
Cc: linux-arm-msm, dianders, dri-devel, linux-kernel, georgi.djakov,
linux-arm-kernel
Try to get the interconnect path for the GPU and vote for the maximum
bandwidth to support all frequencies. This is needed for performance.
Later we will want to scale the bandwidth based on the frequency to
also optimize for power but that will require some device tree
infrastructure that does not yet exist.
v3: Use macros and change port string per Georgi Djakov
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 20 ++++++++++++++++++++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 9 +++++++++
drivers/gpu/drm/msm/msm_gpu.h | 3 +++
4 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 843a9d40c05e..990c4350f0c4 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -5,6 +5,7 @@ config DRM_MSM
depends on ARCH_QCOM || (ARM && COMPILE_TEST)
depends on OF && COMMON_CLK
depends on MMU
+ depends on INTERCONNECT || !INTERCONNECT
select QCOM_MDT_LOADER if ARCH_QCOM
select REGULATOR
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 546599a7ab05..f37a9bfe5c30 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -2,6 +2,7 @@
/* Copyright (c) 2017-2018 The Linux Foundation. All rights reserved. */
#include <linux/clk.h>
+#include <linux/interconnect.h>
#include <linux/pm_opp.h>
#include <soc/qcom/cmd-db.h>
@@ -63,6 +64,9 @@ static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
{
+ struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
+ struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
+ struct msm_gpu *gpu = &adreno_gpu->base;
int ret;
gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
@@ -85,6 +89,12 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
gmu->freq = gmu->gpu_freqs[index];
+
+ /*
+ * Eventually we will want to scale the path vote with the frequency but
+ * for now leave it at max so that the performance is nominal.
+ */
+ icc_set(gpu->icc_path, 0, MBps_to_icc(7216));
}
void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
@@ -680,6 +690,8 @@ int a6xx_gmu_reset(struct a6xx_gpu *a6xx_gpu)
int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
{
+ struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
+ struct msm_gpu *gpu = &adreno_gpu->base;
struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
int status, ret;
@@ -695,6 +707,9 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
if (ret)
goto out;
+ /* Set the bus quota to a reasonable value for boot */
+ icc_set(gpu->icc_path, 0, MBps_to_icc(3072));
+
a6xx_gmu_irq_enable(gmu);
/* Check to see if we are doing a cold or warm boot */
@@ -735,6 +750,8 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu)
int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
{
+ struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
+ struct msm_gpu *gpu = &adreno_gpu->base;
struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
u32 val;
@@ -781,6 +798,9 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
/* Tell RPMh to power off the GPU */
a6xx_rpmh_stop(gmu);
+ /* Remove the bus vote */
+ icc_set(gpu->icc_path, 0, 0);
+
clk_bulk_disable_unprepare(gmu->nr_clocks, gmu->clocks);
pm_runtime_put_sync(gmu->dev);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 93d70f4a2154..7403ade9aabc 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -18,6 +18,7 @@
*/
#include <linux/ascii85.h>
+#include <linux/interconnect.h>
#include <linux/kernel.h>
#include <linux/pm_opp.h>
#include <linux/slab.h>
@@ -695,6 +696,11 @@ static int adreno_get_pwrlevels(struct device *dev,
DBG("fast_rate=%u, slow_rate=27000000", gpu->fast_rate);
+ /* Check for an interconnect path for the bus */
+ gpu->icc_path = of_icc_get(dev, "gfx-mem");
+ if (IS_ERR(gpu->icc_path))
+ gpu->icc_path = NULL;
+
return 0;
}
@@ -733,10 +739,13 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
void adreno_gpu_cleanup(struct adreno_gpu *adreno_gpu)
{
+ struct msm_gpu *gpu = &adreno_gpu->base;
unsigned int i;
for (i = 0; i < ARRAY_SIZE(adreno_gpu->info->fw); i++)
release_firmware(adreno_gpu->fw[i]);
+ icc_put(gpu->icc_path);
+
msm_gpu_cleanup(&adreno_gpu->base);
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index f82bac086666..12fc5b1cb39d 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -19,6 +19,7 @@
#define __MSM_GPU_H__
#include <linux/clk.h>
+#include <linux/interconnect.h>
#include <linux/regulator/consumer.h>
#include "msm_drv.h"
@@ -119,6 +120,8 @@ struct msm_gpu {
struct clk *ebi1_clk, *core_clk, *rbbmtimer_clk;
uint32_t fast_rate;
+ struct icc_path *icc_path;
+
/* Hang and Inactivity Detection:
*/
#define DRM_MSM_INACTIVE_PERIOD 66 /* in ms (roughly four frames) */
--
2.18.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 v3 1/9] mm: Introduce new vm_insert_range API
From: Matthew Wilcox @ 2018-12-07 17:11 UTC (permalink / raw)
To: Robin Murphy
Cc: mhocko, heiko, peterz, dri-devel, linux-kernel, linux-mm,
linux1394-devel, m.szyprowski, sfr, oleksandr_andrushchenko, joro,
linux, iommu, airlied, linux-arm-kernel, linux-rockchip, treding,
linux-media, keescook, pawel, riel, rppt, boris.ostrovsky,
mchehab, iamjoonsoo.kim, vbabka, jgross, hjc, xen-devel,
kyungmin.park, stefanr, Souptick Joarder, akpm, kirill.shutemov
In-Reply-To: <53bbc095-c9f5-5d6a-6e50-6e060d17eb68@arm.com>
On Fri, Dec 07, 2018 at 03:34:56PM +0000, Robin Murphy wrote:
> > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > + struct page **pages, unsigned long page_count)
> > +{
> > + unsigned long uaddr = addr;
> > + int ret = 0, i;
>
> Some of the sites being replaced were effectively ensuring that vma and
> pages were mutually compatible as an initial condition - would it be worth
> adding something here for robustness, e.g.:
>
> + if (page_count != vma_pages(vma))
> + return -ENXIO;
I think we want to allow this to be used to populate part of a VMA.
So perhaps:
if (page_count > vma_pages(vma))
return -ENXIO;
_______________________________________________
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 v11 8/8] interconnect: sdm845: Fix build failure after cmd_db API change
From: Quentin Perret @ 2018-12-07 17:14 UTC (permalink / raw)
To: Georgi Djakov
Cc: mark.rutland, sanjayc, maxime.ripard, mturquette, daidavid1,
bjorn.andersson, skannan, abailon, lorenzo.pieralisi,
vincent.guittot, seansw, khilman, evgreen, ksitaraman, devicetree,
arnd, linux-pm, linux-arm-msm, robh+dt, linux-tegra,
linux-arm-kernel, gregkh, rjw, dianders, amit.kucheria,
linux-kernel, thierry.reding
In-Reply-To: <fb5d11cd-6729-5521-c828-9bfeedba9ce0@linaro.org>
On Friday 07 Dec 2018 at 18:47:22 (+0200), Georgi Djakov wrote:
> Hi Quentin,
>
> On 12/7/18 18:27, Quentin Perret wrote:
> > Hi Georgi,
> >
> > On Friday 07 Dec 2018 at 17:29:17 (+0200), Georgi Djakov wrote:
> >> Recently the cmd_db_read_aux_data() function was changed to avoid using
> >> memcpy and return a pointer instead. Update the code to the new API and
> >> fix the build failure.
> >>
> >> Fixes: ed3cafa79ea7 ("soc: qcom: cmd-db: Stop memcpy()ing in cmd_db_read_aux_data()")
> >> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> >> ---
> >> drivers/interconnect/qcom/sdm845.c | 26 ++++++++++++++------------
> >
> > IIUC this file is introduced by patch 5. Should the fix be squashed
> > into patch 5 directly ? Just to keep things bisectable.
>
> The reason why i have split it as a separate change is because as a
> separate change it would be easier to review & test for the people who
> are already familiar with the rest of the series.
>
> Another minor reason is that a separate patch will also make the life a
> bit easier for some people who are back-porting this to kernels using
> the older version of the cmd_db API.
>
> The commit that changed the cmd_db API is not yet in mainline, but in
> linux-next. I am not sure what is preferred in this case?
Not sure either but I guess that will depend who gets merged first ...
If that's the cmd_db change, then you'll need to squash your fix in
patch 5. If your series goes first, then the fix needs to be applied to
the cmb_db change.
I personally don't mind either way as long as we don't break bisection :-)
Thanks,
Quentin
_______________________________________________
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/4] arm64: Avoid masking "old" for LSE cmpxchg() implementation
From: Will Deacon @ 2018-12-07 17:15 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: Catalin Marinas, linux-arm-kernel
In-Reply-To: <CAKv+Gu_Pq8+JGZ9QCAj+U7JreqD3WzW68gJf5ZxY1tHjaS5ZUQ@mail.gmail.com>
On Fri, Dec 07, 2018 at 06:03:35PM +0100, Ard Biesheuvel wrote:
> On Fri, 7 Dec 2018 at 17:22, Will Deacon <will.deacon@arm.com> wrote:
> > On Fri, Dec 07, 2018 at 05:05:16PM +0100, Ard Biesheuvel wrote:
> > > On Fri, 7 Dec 2018 at 16:49, Will Deacon <will.deacon@arm.com> wrote:
> > > > On Tue, Dec 04, 2018 at 05:58:50PM +0100, Ard Biesheuvel wrote:
> > > > > On Tue, 27 Nov 2018 at 20:44, Will Deacon <will.deacon@arm.com> wrote:
> > > > > > diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
> > > > > > index 4d6f917b654e..a424355240c5 100644
> > > > > > --- a/arch/arm64/include/asm/atomic_lse.h
> > > > > > +++ b/arch/arm64/include/asm/atomic_lse.h
> > > > > > @@ -448,11 +448,11 @@ static inline long atomic64_dec_if_positive(atomic64_t *v)
> > > > > >
> > > > > > #define __CMPXCHG_CASE(w, sfx, name, sz, mb, cl...) \
> > > > > > static inline u##sz __cmpxchg_case_##name##sz(volatile void *ptr, \
> > > > > > - unsigned long old, \
> > > > > > + u##sz old, \
> > > > > > u##sz new) \
> > > > > > { \
> > > > > > register unsigned long x0 asm ("x0") = (unsigned long)ptr; \
> > > > > > - register unsigned long x1 asm ("x1") = old; \
> > > > > > + register u##sz x1 asm ("x1") = old; \
> > > > >
> > > > > This looks backwards to me, but perhaps I am missing something:
> > > > > changing from unsigned long to a narrower type makes it the compiler's
> > > > > job to perform the cast, no? Given that 'cas' ignores the upper bits
> > > > > anyway, what does this change buy us?
> > > >
> > > > A narrowing cast doesn't actually result in any additional instructions --
> > > > the masking occurs if you do a widening cast. In this case, the change I'm
> > > > proposing means we avoid the redundant widening casts for the LSE operations
> > > > because, as you point out, the underlying instruction only operates on the
> > > > relevant bits.
> > > >
> > >
> > > Playing around with some code, I found out that
> > >
> > > static inline void foo(unsigned char x)
> > > {
> > > asm("" :: "r"(x));
> > > }
> > >
> > > void bar(unsigned long l)
> > > {
> > > foo(l);
> > > }
> > >
> > > produces different code than
> > >
> > > static inline void foo(unsigned longr x)
> > > {
> > > asm("" :: "r"(x));
> > > }
> > >
> > > void bar(unsigned long l)
> > > {
> > > foo((unsigned char)l);
> > > }
> > >
> > > so what you are saying appears to be accurate. Whether it is correct,
> > > is another matter, though, since the 'unsigned char' argument passed
> > > into the asm() block may have higher bits set.
> >
> > Right, which is why I've kept the casting for sizes < 32 bits in the LL/SC
> > code.
> >
>
> OK.
>
> So if we are relying on the cast to occur implicitly by the cas
> instruction, does it really make sense to change the prototype?
> Shouldn't we keep it at unsigned long so that we explicitly pass the
> whole value in (but use an explicit cast in the LL/SC implementation
> as you did)
If we change the prototype of the __cmpxchg_case_* functions so that the
old and new parameters are unsigned long, then we'll get widening casts
(and explicit masking) for any caller of cmpxchg() that passes narrower
types such as u16.
Or are you suggesting something else?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: WIP: UFS on apq8098
From: Evan Green @ 2018-12-07 17:14 UTC (permalink / raw)
To: marc.w.gonzalez
Cc: jhugo, linux-arm-msm, sboyd, Bjorn Andersson, Andy Gross,
nicolas.dechesne, linux-arm-kernel
In-Reply-To: <bf10cc14-75f0-05b0-dea7-cb19beef5d5d@free.fr>
On Fri, Dec 7, 2018 at 4:10 AM Marc Gonzalez <marc.w.gonzalez@free.fr> wrote:
>
> On 06/12/2018 17:45, Evan Green wrote:
>
> > I'll throw my random thought into the hopper here. With one particular
> > brand of UFS part on SDM845 we needed to make sure we banged on the
> > ufs_reset pin before the device would re-initialize fully. My hunch
> > says this is not your issue, but it can't hurt to make sure this is
> > happening.
>
> You might be on to something.
>
> Downstream handles the pinctrl nodes, while upstream doesn't.
>
> $ git grep pinc vendor -- drivers/scsi/ufs/
> vendor:drivers/scsi/ufs/ufshcd-pltfrm.c:static int ufshcd_parse_pinctrl_info(struct ufs_hba *hba)
> vendor:drivers/scsi/ufs/ufshcd-pltfrm.c: /* Try to obtain pinctrl handle */
> vendor:drivers/scsi/ufs/ufshcd-pltfrm.c: hba->pctrl = devm_pinctrl_get(hba->dev);
> vendor:drivers/scsi/ufs/ufshcd-pltfrm.c: err = ufshcd_parse_pinctrl_info(hba);
> vendor:drivers/scsi/ufs/ufshcd-pltfrm.c: dev_dbg(&pdev->dev, "%s: unable to parse pinctrl data %d\n",
> vendor:drivers/scsi/ufs/ufshcd.c: ret = pinctrl_select_state(hba->pctrl,
> vendor:drivers/scsi/ufs/ufshcd.c: pinctrl_lookup_state(hba->pctrl, "dev-reset-assert"));
> vendor:drivers/scsi/ufs/ufshcd.c: ret = pinctrl_select_state(hba->pctrl,
> vendor:drivers/scsi/ufs/ufshcd.c: pinctrl_lookup_state(hba->pctrl, "dev-reset-deassert"));
> vendor:drivers/scsi/ufs/ufshcd.h: struct pinctrl *pctrl;
>
> $ git grep pinc master -- drivers/scsi/ufs/
> /* NOTHING */
We did this by abusing the "init" pinctrl state, which I think gets
handled automagically. In our board file we have something like this
(forgive the paste butchering):
&ufshc1 {
status = "okay";
pinctrl-names = "init", "default";
pinctrl-0 = <&ufs_dev_reset_assert>;
pinctrl-1 = <&ufs_dev_reset_deassert>;
vcc-supply = <&src_pp2950_l20a>;
vcc-max-microamp = <600000>;
};
&tlmm {
ufs_dev_reset_assert: ufs_dev_reset_assert {
config {
pins = "ufs_reset";
bias-pull-down; /* default: pull down */
drive-strength = <8>; /* default: 3.1 mA */
output-low; /* active low reset */
};
};
ufs_dev_reset_deassert: ufs_dev_reset_deassert {
config {
pins = "ufs_reset";
bias-pull-down; /* default: pull down */
drive-strength = <8>;
output-high; /* active low reset */
};
};
};
_______________________________________________
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