* Re: [PATCH] coresight: tmc-etr: Remove perf_data check.
From: Suzuki K Poulose @ 2019-08-09 9:22 UTC (permalink / raw)
To: yabinc, mathieu.poirier, alexander.shishkin
Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20190808193122.76679-1-yabinc@google.com>
Hi Yabin,
Thank you for the analysis and the patch.
On 08/08/2019 20:31, Yabin Cui wrote:
> When tracing etm data of multiple threads on multiple cpus through
> perf interface, each cpu has a unique etr_perf_buffer while sharing
> the same etr device. There is no guarantee that the last cpu starts
> etm tracing also stops last. So the perf_data check is no longer valid.
>
> Signed-off-by: Yabin Cui <yabinc@google.com>
> ---
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 9 ---------
> drivers/hwtracing/coresight/coresight-tmc.h | 2 --
> 2 files changed, 11 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 17006705287a..0418440e0141 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -1484,20 +1484,12 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
> goto out;
> }
>
> - if (WARN_ON(drvdata->perf_data != etr_perf)) {
> - lost = true;
> - spin_unlock_irqrestore(&drvdata->spinlock, flags);
> - goto out;
> - }
> -
I think some sort of sanity check is a good idea to make sure we don't loose the
context. Even when different CPUs have different etr_perf buffer, the underlying
etr_buf should be the same. So, we should be able to simply convert the check
to, something like :
struct etr_perf_buffer *perf_buf = drvdata->perf_data;
...
if (WARN_ON(perf_buf->etr_buf != etr_perf->buf)) {
....
}
Does that solve the problem for you ?
Suzuki
_______________________________________________
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 10/22] usb: omap: avoid mach/*.h headers
From: Greg Kroah-Hartman @ 2019-08-09 5:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Felipe Balbi, linux-usb, Aaro Koskinen, Tony Lindgren,
Linus Walleij, Bartlomiej Zolnierkiewicz, linux-kernel,
Tomi Valkeinen, Alan Stern, linux-omap, linux-arm-kernel
In-Reply-To: <20190808212234.2213262-11-arnd@arndb.de>
On Thu, Aug 08, 2019 at 11:22:19PM +0200, Arnd Bergmann wrote:
> The omap usb drivers still rely on mach/*.h headers that
> are explicitly or implicitly included, but all the required
> definitions are now in include/linux/soc/ti/, so use those
> instead and allow compile-testing on other architectures.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/usb/gadget/udc/Kconfig | 2 +-
> drivers/usb/gadget/udc/omap_udc.c | 2 ++
> drivers/usb/host/Kconfig | 2 +-
> drivers/usb/host/ohci-omap.c | 7 +++----
> drivers/usb/phy/Kconfig | 3 ++-
> drivers/usb/phy/phy-isp1301-omap.c | 4 ++--
> 6 files changed, 11 insertions(+), 9 deletions(-)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH 0/3] Add basic support for RTC on Allwinner H6 SoC
From: Ondřej Jirman @ 2019-08-09 9:16 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Mark Rutland, Alessandro Zummo, devicetree, Maxime Ripard,
linux-sunxi, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel, linux-rtc
In-Reply-To: <20190808233930.GM3600@piout.net>
On Fri, Aug 09, 2019 at 01:39:30AM +0200, Alexandre Belloni wrote:
> On 08/08/2019 14:12:37+0200, Ondřej Jirman wrote:
> > On Wed, Aug 07, 2019 at 12:55:02PM +0200, Alexandre Belloni wrote:
> > > Hi,
> > >
> > > On 06/08/2019 20:30:45+0200, Ondřej Jirman wrote:
> > > > Maybe whether XO or DCXO is used also matters if you want to do some fine
> > > > tunning of DCXO (control register has pletny of options), but that's probably
> > > > better done in u-boot. And there's still no need to read HOSC source from DT.
> > > > The driver can just check compatible, and if it is H6 and OSC_CLK_SRC_SEL is 1,
> > > > it can do it's DCXO tunning, or whatever. But neither OS nor bootloader will
> > > > be using this info to gate/disable the osciallator.
> > > >
> > >
> > > It is actually useful to be able to tweak the crystal tuning at
> > > runtime to be able to reduce clock drift and compare with a reliable
> > > source (e.g. NTP).
> >
> > I don't think there's a Linux kernel API that you can use to achieve that, so
> > that's a rather theoretical concern at the moment.
> >
>
> There is /sys/class/rtc/rtcX/offset which is even properly documented.
>
> The reason I asked is that some RTCs have both analog (changing the
> oscillator capacitance) and digital (changing the RTC counter) so I'm
> wondering whether this interface should be extended.
As I wrote below, that can't be achieved by tuning DCXO.
> > Also there are multiple clocks, that can drive the RTC, and you usually don't
> > drive it from 24MHz DCXO oscillator. The reason is that you'd have to deal with
> > the fact that the clock for RTC then becomes 24000000/750 (750 is fixed
> > divider), which is 32000.
> >
> > So if you want to get 32768Hz for RTC by tuning the DCXO, it would have to have
> > 24 576 000 Hz. And even if you could achieve that (doubtful), it would throw off
> > timings in the rest of the system (say UART, USB, CPU, display ctl) in a major way.
> >
> > I guess you can try tuning 24MHz oscillator so that it's closer to the
> > real-world 24MHz via NTP reference for other reasons. But it would be
> > complicated, and require precise interaction with other components, like using
> > HW timers sourced from 24MHz HOSC clock, because you can't use CPU's timers,
> > because of inaccuracies introduced during DVFS, for example.
> >
> > regards,
> > o.
> >
> > > I'm curious, what kind of options does this RTC have?
> > >
> > > --
> > > Alexandre Belloni, Bootlin
> > > Embedded Linux and Kernel engineering
> > > https://bootlin.com
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v8 4/4] arm64: dts: allwinner: orange-pi-3: Enable HDMI output
From: Ondřej Jirman @ 2019-08-09 9:04 UTC (permalink / raw)
To: Code Kipper
Cc: Mark Rutland, devicetree, Maxime Ripard, Chen-Yu Tsai,
Jernej Škrabec, linux-kernel, David Airlie, linux-sunxi,
Rob Herring, dri-devel, Daniel Vetter, linux-arm-kernel
In-Reply-To: <CAEKpxBn1nF0t-M34iRSy1yYEuUxgNMUXFBhtjXBY8Qk+43zbDQ@mail.gmail.com>
On Fri, Aug 09, 2019 at 10:25:32AM +0200, Code Kipper wrote:
> On Tue, 6 Aug 2019 at 17:57, <megous@megous.com> wrote:
> >
> > From: Ondrej Jirman <megous@megous.com>
> >
> > Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables the DDC
> > I2C bus voltage shifter. Before EDID can be read, we need to pull PH2 high.
> > This is realized by the ddc-en-gpios property.
> Great work. Is there any chance you can move this to the
> arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi?, as all the H6
> based orange-pi's have this feature.
I plan to do that as a followup patch, once this is merged.
regards,
o.
> BR,
> CK
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > ---
> > .../dts/allwinner/sun50i-h6-orangepi-3.dts | 26 +++++++++++++++++++
> > 1 file changed, 26 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > index 2c6807b74ff6..01bb1bafe284 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > @@ -22,6 +22,18 @@
> > stdout-path = "serial0:115200n8";
> > };
> >
> > + connector {
> > + compatible = "hdmi-connector";
> > + ddc-en-gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
> > + type = "a";
> > +
> > + port {
> > + hdmi_con_in: endpoint {
> > + remote-endpoint = <&hdmi_out_con>;
> > + };
> > + };
> > + };
> > +
> > leds {
> > compatible = "gpio-leds";
> >
> > @@ -72,6 +84,10 @@
> > cpu-supply = <®_dcdca>;
> > };
> >
> > +&de {
> > + status = "okay";
> > +};
> > +
> > &ehci0 {
> > status = "okay";
> > };
> > @@ -91,6 +107,16 @@
> > status = "okay";
> > };
> >
> > +&hdmi {
> > + status = "okay";
> > +};
> > +
> > +&hdmi_out {
> > + hdmi_out_con: endpoint {
> > + remote-endpoint = <&hdmi_con_in>;
> > + };
> > +};
> > +
> > &mdio {
> > ext_rgmii_phy: ethernet-phy@1 {
> > compatible = "ethernet-phy-ieee802.3-c22";
> > --
> > 2.22.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> > To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190806155744.10263-5-megous%40megous.com.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: drm/amdgpu: replace readq/writeq with atomic64 operations
From: Koenig, Christian @ 2019-08-09 9:04 UTC (permalink / raw)
To: Alex Deucher, Guenter Roeck
Cc: kernel-build-reports@lists.linaro.org, Mark Brown, Zhou1, Tao,
amd-gfx list, Linux-Next Mailing List, Li, Dennis,
Deucher, Alexander, Andrew Morton, linux-arm-kernel,
Zhang, Hawking
In-Reply-To: <CADnq5_ONGvL0yMybsXCyYJO6zKRAi4aEPo8LwEwQjSP3aVbdJQ@mail.gmail.com>
Am 08.08.19 um 21:33 schrieb Alex Deucher:
> On Thu, Aug 8, 2019 at 3:31 PM Guenter Roeck <linux@roeck-us.net> wrote:
>> On Wed, Aug 07, 2019 at 10:56:40AM +0800, Tao Zhou wrote:
>>> readq/writeq are not supported on all architectures
>>>
>>> Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>> Regarding the claim that this would work for 32-bit x86 builds:
> I wasn't talking about readq/writeq, I was talking about the atomic64
> interfaces.
On quite a bunch of architectures atomic64 operations are actually
implemented with spinlocks or other architecture depended special handling.
So the approach of casting an iomem pointer to an atomic64 and then hope
for the best is actually completely nonsense.
If the hardware really needs a single 64bit write for doorbells or
registers, then we absolutely need to limit the driver to 64bit
architectures.
If the hardware doesn't need 64bit writes we should actually always use
two 32bit writes to not run into random and hard to debug problems
because of this.
Christian.
>
> Alex
>
>> make ARCH=i386 allmodconfig
>> make ARCH=i386 drivers/gpu/drm/amd/amdgpu/amdgpu_device.o
>>
>> results in:
>>
>> ...
>> CC [M] drivers/gpu/drm/amd/amdgpu/amdgpu_device.o
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: In function ‘amdgpu_mm_rreg64’:
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:279:9: error: implicit declaration of function ‘readq’;
>>
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: In function ‘amdgpu_mm_wreg64’:
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:298:3: error: implicit declaration of function ‘writeq’
>>
>> This is with next-20190808.
>>
>> Guenter
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
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/cache: silence -Woverride-init warnings
From: Will Deacon @ 2019-08-09 9:04 UTC (permalink / raw)
To: Qian Cai
Cc: Mark Rutland, Catalin Marinas, Linux List Kernel Mailing,
linux-arm-kernel, clang-built-linux
In-Reply-To: <D2A2F2B9-0563-4DF6-8E77-F191A768CE4E@lca.pw>
On Thu, Aug 08, 2019 at 06:18:39PM -0400, Qian Cai wrote:
> > On Aug 8, 2019, at 6:38 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > Please just turn this off by default for clang.
>
> As mentioned before, it is very valuable to run “make W=1” given it found
> many real developer mistakes which will enable “-Woverride-init” for both
> compilers. Even “-Woverride-init” itself is useful find real issues as in,
Every single patch you've sent to me resulting from building with "W=1" has
been a false positive. Every. Single. One. That's not what I would call
"very valuable". It's probably what I'd call a "colossal waste of
everybody's time", especially as your tendancy to shoot from the hip when
writing these so-called fixes has resulted in some patches that ACTUALLY
INTRODUCED REAL BUGS. Do you see the insanity here?
> ae5e033d65a (“mfd: rk808: Fix RK818_IRQ_DISCHG_ILIM initializer”)
> 32df34d875bb (“[media] rc: img-ir: jvc: Remove unused no-leader timings”)
>
> Especially, to find redundant initializations in large structures. e.g.,
>
> e6ea0b917875 (“[media] dvb_frontend: Don't declare values twice at a table”)
>
> It is important to keep the noise-level as low as possible by keeping the
> amount of false positives under control to be truly benefit from those
> valuable compiler warnings.
So that's where you and I have a disagreement. I think maintainability
of the code is the single most important thing to consider after
correctness.
If code isn't maintainable, then it's liable to churn and be a constant
source of bugs as people keep tripping over whatever subtleties lie within.
In some cases, we have little choice and the combination of things like
performance requirements and compatibility force us down a path which we
wouldn't otherwise have considered. However, appeasing a compiler warning
that *doesn't even appear with the default build options* does not quality
for this sort of treatment in my opinion, so I will not be applying your
patch.
Please stop sending it. Real fixes, sure, but not this rubbish.
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 v19 00/15] arm64: untag user pointers passed to the kernel
From: Catalin Marinas @ 2019-08-09 9:00 UTC (permalink / raw)
To: Kees Cook
Cc: Mark Rutland, kvm, Christian Koenig, Szabolcs Nagy, Will Deacon,
dri-devel, Kostya Serebryany, Khalid Aziz, Lee Smith,
open list:KERNEL SELFTEST FRAMEWORK, Vincenzo Frascino,
Will Deacon, Jacob Bramley, Leon Romanovsky, linux-rdma, amd-gfx,
Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov, Dave Martin,
Evgeniy Stepanov, linux-media, Ruben Ayrapetyan, Andrey Konovalov,
Kevin Brodsky, Alex Williamson, Mauro Carvalho Chehab, Linux ARM,
Linux Memory Management List, Greg Kroah-Hartman, Felix Kuehling,
Dave Hansen, LKML, Jens Wiklander, Ramana Radhakrishnan,
Alexander Deucher, Andrew Morton, enh, Robin Murphy, Yishai Hadas,
Luc Van Oostenryck
In-Reply-To: <201908081608.A4F6711@keescook>
On Thu, Aug 08, 2019 at 04:09:04PM -0700, Kees Cook wrote:
> On Thu, Aug 08, 2019 at 03:33:00PM -0700, Andrew Morton wrote:
> > On Thu, 8 Aug 2019 14:12:19 -0700 Kees Cook <keescook@chromium.org> wrote:
> >
> > > > The ones that are left are the mm ones: 4, 5, 6, 7 and 8.
> > > >
> > > > Andrew, could you take a look and give your Acked-by or pick them up directly?
> > >
> > > Given the subsystem Acks, it seems like 3-10 and 12 could all just go
> > > via Andrew? I hope he agrees. :)
> >
> > I'll grab everything that has not yet appeared in linux-next. If more
> > of these patches appear in linux-next I'll drop those as well.
> >
> > The review discussion against " [PATCH v19 02/15] arm64: Introduce
> > prctl() options to control the tagged user addresses ABI" has petered
> > out inconclusively. prctl() vs arch_prctl().
>
> I've always disliked arch_prctl() existing at all. Given that tagging is
> likely to be a multi-architectural feature, it seems like the controls
> should live in prctl() to me.
It took a bit of grep'ing to figure out what Dave H meant by
arch_prctl(). It's an x86-specific syscall which we do not have on arm64
(and possibly any other architecture). Actually, we don't have any arm64
specific syscalls, only the generic unistd.h, hence the confusion. For
other arm64-specific prctls like SVE we used the generic sys_prctl() and
I can see x86 not being consistent either (PR_MPX_ENABLE_MANAGEMENT).
In general I disagree with adding any arm64-specific syscalls but in
this instance it can't even be justified. I'd rather see some clean-up
similar to arch_ptrace/ptrace_request than introducing new syscall
numbers (but as I suggested in my reply to Dave, that's for another
patch series).
--
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 1/2 v2] tracing/arm64: Have max stack tracer handle the case of return address after data
From: Mark Rutland @ 2019-08-09 8:55 UTC (permalink / raw)
To: Steven Rostedt
Cc: Jiping Ma, catalin.marinas, will.deacon, linux-kernel, mingo,
Joel Fernandes, linux-arm-kernel
In-Reply-To: <20190807172907.155165959@goodmis.org>
On Wed, Aug 07, 2019 at 01:28:27PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
>
> Most archs (well at least x86) store the function call return address on the
> stack before storing the local variables for the function. The max stack
> tracer depends on this in its algorithm to display the stack size of each
> function it finds in the back trace.
>
> Some archs (arm64), may store the return address (from its link register)
> just before calling a nested function. There's no reason to save the link
> register on leaf functions, as it wont be updated. This breaks the algorithm
> of the max stack tracer.
>
> Add a new define ARCH_RET_ADDR_AFTER_LOCAL_VARS that an architecture may set
> if it stores the return address (link register) after it stores the
> function's local variables, and have the stack trace shift the values of the
> mapped stack size to the appropriate functions.
>
> Link: 20190802094103.163576-1-jiping.ma2@windriver.com
>
> Reported-by: Jiping Ma <jiping.ma2@windriver.com>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> ---
> arch/arm64/include/asm/ftrace.h | 13 +++++++++++++
> kernel/trace/trace_stack.c | 14 ++++++++++++++
> 2 files changed, 27 insertions(+)
>
> diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
> index 5ab5200b2bdc..961e98618db4 100644
> --- a/arch/arm64/include/asm/ftrace.h
> +++ b/arch/arm64/include/asm/ftrace.h
> @@ -14,6 +14,19 @@
> #define MCOUNT_ADDR ((unsigned long)_mcount)
> #define MCOUNT_INSN_SIZE AARCH64_INSN_SIZE
>
> +/*
> + * Currently, gcc tends to save the link register after the local variables
> + * on the stack. This causes the max stack tracer to report the function
> + * frame sizes for the wrong functions. By defining
> + * ARCH_RET_ADDR_AFTER_LOCAL_VARS, it will tell the stack tracer to expect
> + * to find the return address on the stack after the local variables have
> + * been set up.
> + *
> + * Note, this may change in the future, and we will need to deal with that
> + * if it were to happen.
> + */
> +#define ARCH_RET_ADDR_AFTER_LOCAL_VARS 1
FWIW (with whatever this got renamed to):
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
_______________________________________________
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/cache: silence -Woverride-init warnings
From: Mark Rutland @ 2019-08-09 8:53 UTC (permalink / raw)
To: Qian Cai
Cc: Catalin Marinas, Will Deacon, Linux List Kernel Mailing,
linux-arm-kernel, clang-built-linux
In-Reply-To: <D2A2F2B9-0563-4DF6-8E77-F191A768CE4E@lca.pw>
On Thu, Aug 08, 2019 at 06:18:39PM -0400, Qian Cai wrote:
> > On Aug 8, 2019, at 6:38 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > On Wed, Aug 07, 2019 at 11:29:16PM -0400, Qian Cai wrote:
> >> The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
> >> VIVT I-caches") introduced some compiation warnings from GCC (and
> >> Clang) with -Winitializer-overrides),
> >>
> >> arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
> >> overwritten [-Woverride-init]
> >> [ICACHE_POLICY_VIPT] = "VIPT",
> >> ^~~~~~
> >> arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
> >> 'icache_policy_str[2]')
> >> arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
> >> overwritten [-Woverride-init]
> >> [ICACHE_POLICY_PIPT] = "PIPT",
> >> ^~~~~~
> >> arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
> >> 'icache_policy_str[3]')
> >> arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
> >> overwritten [-Woverride-init]
> >> [ICACHE_POLICY_VPIPT] = "VPIPT",
> >> ^~~~~~~
> >> arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
> >> 'icache_policy_str[0]')
> >>
> >> because it initializes icache_policy_str[0 ... 3] twice. Since
> >> arm64 developers are keen to keep the style of initializing a static
> >> array with a non-zero pattern first, just disable those warnings for
> >> both GCC and Clang of this file.
> >>
> >> Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches")
> >> Signed-off-by: Qian Cai <cai@lca.pw>
> >
> > This is _not_ a fix, and should not require backporting to stable trees.
>
> From my experience, the stable AI will pick up whatever they want to backport
> not matter if there Is a “Fixes” tag or not unless it is one of those subsystems like
> Networking that exclusively manually flag for. backporting by the maintainer.
My point is that this patch does not require backporting, and hence does
not require a fixes tag. The stable AI may choose the patch regardless,
so it's irrelevant.
[...]
> > What about all the other instances that we have in mainline?
>
> I have not had a chance to review all instances yet. It is not unusually to fix one
> warning at a time, and then go on fixing some more if time permit.
Given that:
* All the suggested code changes so far are harmful to legibility,
robustness, and maintainability of the code.
* The majority of the warnings (by orders of magnitude) occur for
intentional overrides, rather than unintentional overrides, as
assigning default values to arrays and structs is a common idiom.
* We have no known mechanism to selectively disable the warning on a
per-assignment basis.
... I do not think that is an appropriate strategy here.
For example, I'm fairly certain that if you try to "fix" the instances
in syscall tables, many more people will complain.
A much better approach would be to analyse the warnings, and either:
* find the _real_ bugs where we unintentionally override fields and fix
those first, or:
* Find the instances that produce the greatest set of false positives
(e.g. the syscall tables), and figure out how to suppress those
without harming the maintainability or robustness of the code.
> > I really don't think that we need to go down this road; we're just going
> > to end up adding this to every file that happens to include a header
> > using this scheme…
>
> How about disable them this way in a top level like arch/arm64/Makefile or
> arch/arm64/kernel/Makefile? Therefore, there is no need to add this to
> every file, but with a drawback that it could miss a few real issues there
> in the future which probably not many people are checking for them of
> the arm64 subsystem nowadays.
This isn't arm64-specific. We validly use duplicate assignments all over
the kernel, and my position is that we either:
* Find a mechanism to suppress the warning on a per-assignment (not
per-file) basis, without altering the structure of the existing code.
* Disable the warning tree-wide.
I would vastly prefer the former, as I do agree that this warning _can_
find real bugs, but similarly so can a script that warns "Line $N may
contain a bug" for every line of a C file.
> > Please just turn this off by default for clang.
>
> As mentioned before, it is very valuable to run “make W=1” given it found
> many real developer mistakes which will enable “-Woverride-init” for both
> compilers. Even “-Woverride-init” itself is useful find real issues as in,
>
> ae5e033d65a (“mfd: rk808: Fix RK818_IRQ_DISCHG_ILIM initializer”)
> 32df34d875bb (“[media] rc: img-ir: jvc: Remove unused no-leader timings”)
>
> Especially, to find redundant initializations in large structures. e.g.,
>
> e6ea0b917875 (“[media] dvb_frontend: Don't declare values twice at a table”)
>
> It is important to keep the noise-level as low as possible by keeping the
> amount of false positives under control to be truly benefit from those
> valuable compiler warnings.
I agree that we want to minimize the noise, but not at the expense of
the maintainability and robustness of the code, and not by disabling
warnings for arbitrary files.
> > If we want to enable this, we need a mechanism to permit overridable
> > assignments as we use range initializers for.
>
> I am not sure that it is worth filling a RFE for compilers of that feature.
If that's your position, then I see no point continuing this conversation.
> I feel like the range initializers just another way to initialize an array, and
> it is just easier to make mistakes with unintended double-initializations.
> The compiler developers probably recommend to enforce more of
> “-Woverride-init” for the range initializers rather than permitting it.
From my analysis in a prior reply, the vast majority of duplicate
assignments in the kernel are intentional. We do that for both arrays
and structures in order to have defaults that can be overridden.
If the compiler developers don't think that's worth supporting, then the
feature is not worth using.
Thanks,
Mark.
_______________________________________________
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 00/34] put_user_pages(): miscellaneous call sites
From: Jan Kara @ 2019-08-09 8:43 UTC (permalink / raw)
To: Weiny, Ira
Cc: linux-fbdev@vger.kernel.org, Jan Kara, kvm@vger.kernel.org,
Dave Hansen, Dave Chinner, dri-devel@lists.freedesktop.org,
Michal Hocko, linux-mm@kvack.org, amd-gfx@lists.freedesktop.org,
sparclinux@vger.kernel.org, Williams, Dan J,
devel@driverdev.osuosl.org, rds-devel@oss.oracle.com,
linux-rdma@vger.kernel.org, x86@kernel.org, Matthew Wilcox,
Christoph Hellwig, Jason Gunthorpe,
xen-devel@lists.xenproject.org, devel@lists.orangefs.org,
linux-media@vger.kernel.org, John Hubbard,
intel-gfx@lists.freedesktop.org, linux-block@vger.kernel.org,
Jérôme Glisse, linux-rpi-kernel@lists.infradead.org,
ceph-devel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-nfs@vger.kernel.org, netdev@vger.kernel.org, LKML,
linux-xfs@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Andrew Morton
In-Reply-To: <2807E5FD2F6FDA4886F6618EAC48510E79E79644@CRSMSX101.amr.corp.intel.com>
On Thu 08-08-19 16:25:04, Weiny, Ira wrote:
> > I thought I'd caught things early enough to get away with the
> > rename and deletion of that. You could either:
> >
> > a) open code an implementation of vaddr_put_pages_dirty_lock() that
> > doesn't call any of the *put_user_pages_dirty*() variants, or
> >
> > b) include my first patch ("") are part of your series, or
> >
> > c) base this on Andrews's tree, which already has merged in my first patch.
> >
>
> Yep I can do this. I did not realize that Andrew had accepted any of
> this work. I'll check out his tree. But I don't think he is going to
> accept this series through his tree. So what is the ETA on that landing
> in Linus' tree?
>
> To that point I'm still not sure who would take all this as I am now
> touching mm, procfs, rdma, ext4, and xfs.
MM tree would be one candidate for routing but there are other options that
would make sense as well - Dan's tree, VFS tree, or even I can pickup the
patches to my tree if needed. But let's worry about the routing after we
have working and reviewed patches...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
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 00/34] put_user_pages(): miscellaneous call sites
From: Jan Kara @ 2019-08-09 8:34 UTC (permalink / raw)
To: Ira Weiny
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
Michal Hocko, linux-mm, amd-gfx, sparclinux, Dan Williams, devel,
rds-devel, linux-rdma, x86, Matthew Wilcox, Christoph Hellwig,
Jason Gunthorpe, xen-devel, devel, linux-media, John Hubbard,
intel-gfx, john.hubbard, linux-block, Jérôme Glisse,
linux-rpi-kernel, ceph-devel, linux-arm-kernel, linux-nfs, netdev,
LKML, linux-xfs, linux-crypto, linux-fsdevel, Andrew Morton
In-Reply-To: <20190808023637.GA1508@iweiny-DESK2.sc.intel.com>
On Wed 07-08-19 19:36:37, Ira Weiny wrote:
> On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> > > So I think your debug option and my suggested renaming serve a bit
> > > different purposes (and thus both make sense). If you do the renaming, you
> > > can just grep to see unconverted sites. Also when someone merges new GUP
> > > user (unaware of the new rules) while you switch GUP to use pins instead of
> > > ordinary references, you'll get compilation error in case of renaming
> > > instead of hard to debug refcount leak without the renaming. And such
> > > conflict is almost bound to happen given the size of GUP patch set... Also
> > > the renaming serves against the "coding inertia" - i.e., GUP is around for
> > > ages so people just use it without checking any documentation or comments.
> > > After switching how GUP works, what used to be correct isn't anymore so
> > > renaming the function serves as a warning that something has really
> > > changed.
> >
> > Fully agreed!
>
> Ok Prior to this I've been basing all my work for the RDMA/FS DAX stuff in
> Johns put_user_pages()... (Including when I proposed failing truncate with a
> lease in June [1])
>
> However, based on the suggestions in that thread it became clear that a new
> interface was going to need to be added to pass in the "RDMA file" information
> to GUP to associate file pins with the correct processes...
>
> I have many drawings on my white board with "a whole lot of lines" on them to
> make sure that if a process opens a file, mmaps it, pins it with RDMA, _closes_
> it, and ummaps it; that the resulting file pin can still be traced back to the
> RDMA context and all the processes which may have access to it.... No matter
> where the original context may have come from. I believe I have accomplished
> that.
>
> Before I go on, I would like to say that the "imbalance" of get_user_pages()
> and put_page() bothers me from a purist standpoint... However, since this
> discussion cropped up I went ahead and ported my work to Linus' current master
> (5.3-rc3+) and in doing so I only had to steal a bit of Johns code... Sorry
> John... :-(
>
> I don't have the commit messages all cleaned up and I know there may be some
> discussion on these new interfaces but I wanted to throw this series out there
> because I think it may be what Jan and Michal are driving at (or at least in
> that direction.
>
> Right now only RDMA and DAX FS's are supported. Other users of GUP will still
> fail on a DAX file and regular files will still be at risk.[2]
>
> I've pushed this work (based 5.3-rc3+ (33920f1ec5bf)) here[3]:
>
> https://github.com/weiny2/linux-kernel/tree/linus-rdmafsdax-b0-v3
>
> I think the most relevant patch to this conversation is:
>
> https://github.com/weiny2/linux-kernel/commit/5d377653ba5cf11c3b716f904b057bee6641aaf6
>
> I stole Jans suggestion for a name as the name I used while prototyping was
> pretty bad... So Thanks Jan... ;-)
For your function, I'd choose a name like vaddr_pin_leased_pages() so that
association with a lease is clear from the name :) Also I'd choose the
counterpart to be vaddr_unpin_leased_page[s](). Especially having put_page in
the name looks confusing to me...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Explicitly marking initializer overrides (was "Re: [PATCH] arm64/cache: silence -Woverride-init warnings")
From: Mark Rutland @ 2019-08-09 8:32 UTC (permalink / raw)
To: Nathan Chancellor
Cc: catalin.marinas, linux-kernel, clang-built-linux, Qian Cai, will,
linux-arm-kernel
In-Reply-To: <20190808170916.GA32668@archlinux-threadripper>
On Thu, Aug 08, 2019 at 10:09:16AM -0700, Nathan Chancellor wrote:
> On Thu, Aug 08, 2019 at 11:38:08AM +0100, Mark Rutland wrote:
> > On Wed, Aug 07, 2019 at 11:29:16PM -0400, Qian Cai wrote:
> > > The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
> > > VIVT I-caches") introduced some compiation warnings from GCC (and
> > > Clang) with -Winitializer-overrides),
> > >
> > > arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
> > > overwritten [-Woverride-init]
> > > [ICACHE_POLICY_VIPT] = "VIPT",
> > > ^~~~~~
> > > arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
> > > 'icache_policy_str[2]')
> > > arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
> > > overwritten [-Woverride-init]
> > > [ICACHE_POLICY_PIPT] = "PIPT",
> > > ^~~~~~
> > > arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
> > > 'icache_policy_str[3]')
> > > arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
> > > overwritten [-Woverride-init]
> > > [ICACHE_POLICY_VPIPT] = "VPIPT",
> > > ^~~~~~~
> > > arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
> > > 'icache_policy_str[0]')
> > >
> > > because it initializes icache_policy_str[0 ... 3] twice. Since
> > > arm64 developers are keen to keep the style of initializing a static
> > > array with a non-zero pattern first, just disable those warnings for
> > > both GCC and Clang of this file.
> > >
> > > Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches")
> > > Signed-off-by: Qian Cai <cai@lca.pw>
> >
> > This is _not_ a fix, and should not require backporting to stable trees.
> >
> > What about all the other instances that we have in mainline?
> >
> > I really don't think that we need to go down this road; we're just going
> > to end up adding this to every file that happens to include a header
> > using this scheme...
> >
> > Please just turn this off by default for clang.
> >
> > If we want to enable this, we need a mechanism to permit overridable
> > assignments as we use range initializers for.
> >
> > Thanks,
> > Mark.
> >
>
> For what it's worth, this is disabled by default for clang in the
> kernel:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.extrawarn?h=v5.3-rc3#n69
>
> It only becomes visible with clang at W=1 because that section doesn't
> get applied. It becomes visible with GCC at W=1 because of -Wextra.
Thanks for clarifying that!
Do you know if there's any existing mechanism that we can use to silence
the warning on a per-assignment basis? Either to say that an assignment
can be overridden, or that the assignment is expected to override an
existing assignment?
If not, who would be able to look at adding a mechanism to clang for
this?
If we could have some attribute or intrinsic that we could wrap like:
struct foo f = {
.bar __defaultval = <default>,
.bar = <newval>, // no warning
.bar = <anotherval>, // warning
};
... or:
struct foo f = {
.bar = <default>,
.bar __override = <newval>, // no warning
.bar = <anotherval>, // warning
};
... or:
.bar = OVERRIDE(<newval>), // no warning
... or:
OVERRIDE(.bar) = <newval>, // no warning
... then I think it would be possible to make use of the warning
effectively, as we could distinguish intentional overrides from
unintentional ones, and annotating assignments in this way doesn't seem
onerous to me.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 6/6] arm64: dts: k3-j721e: Add gpio-keys on common processor board
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
From: Nikhil Devshatwar <nikhil.nd@ti.com>
Common processor board for K3 J721E platform has two push buttons
namely SW10 and SW11.
Add a gpio-keys device node to model them as input keys in Linux.
Add required pinmux nodes to set GPIO pins as input.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../dts/ti/k3-j721e-common-proc-board.dts | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
index 509579ca3db2..d2894d55fbbe 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
@@ -6,12 +6,49 @@
/dts-v1/;
#include "k3-j721e-som-p0.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
/ {
chosen {
stdout-path = "serial2:115200n8";
bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000";
};
+
+ gpio_keys: gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sw10_button_pins_default &sw11_button_pins_default>;
+
+ sw10: sw10 {
+ label = "GPIO Key USER1";
+ linux,code = <BTN_0>;
+ gpios = <&main_gpio0 0 GPIO_ACTIVE_LOW>;
+ };
+
+ sw11: sw11 {
+ label = "GPIO Key USER2";
+ linux,code = <BTN_1>;
+ gpios = <&wkup_gpio0 7 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&main_pmx0 {
+ sw10_button_pins_default: sw10_button_pins_default {
+ pinctrl-single,pins = <
+ J721E_IOPAD(0x0, PIN_INPUT, 7) /* (AC18) EXTINTn.GPIO0_0 */
+ >;
+ };
+};
+
+&wkup_pmx0 {
+ sw11_button_pins_default: sw11_button_pins_default {
+ pinctrl-single,pins = <
+ J721E_WKUP_IOPAD(0xcc, PIN_INPUT, 7) /* (G28) WKUP_GPIO0_7 */
+ >;
+ };
};
&wkup_uart0 {
--
2.22.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 5/6] dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
Add pinctrl macros for J721E SoC. These macro definitions are
similar to that of AM6, but adding new definitions to avoid
any naming confusions in the soc dts files.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
---
include/dt-bindings/pinctrl/k3.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/dt-bindings/pinctrl/k3.h b/include/dt-bindings/pinctrl/k3.h
index 45e11b6170ca..499de6216581 100644
--- a/include/dt-bindings/pinctrl/k3.h
+++ b/include/dt-bindings/pinctrl/k3.h
@@ -32,4 +32,7 @@
#define AM65X_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
#define AM65X_WKUP_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
+#define J721E_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
+#define J721E_WKUP_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
+
#endif
--
2.22.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 4/6] arm64: dts: ti: k3-j721e-common-proc-board: Disable unused gpio modules
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
There are 10 gpio instances inside SoC with 3 groups as below:
- Group1: main_gpio0, main_gpio2, main_gpio4, main_gpio6
- Group2: main_gpio1, main_gpio3, main_gpio5, main_gpio7
- Group3: wkup_gpio0, wkup_gpio1
Only one instance can be used in each group at a time. So use main_gpio0,
main_gpio1 and wkup_gpio0 for the current linux context and mark other
gpio nodes as disabled.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../dts/ti/k3-j721e-common-proc-board.dts | 28 +++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
index 63b47b839388..509579ca3db2 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
@@ -52,3 +52,31 @@
/* UART not brought out */
status = "disabled";
};
+
+&main_gpio2 {
+ status = "disabled";
+};
+
+&main_gpio3 {
+ status = "disabled";
+};
+
+&main_gpio4 {
+ status = "disabled";
+};
+
+&main_gpio5 {
+ status = "disabled";
+};
+
+&main_gpio6 {
+ status = "disabled";
+};
+
+&main_gpio7 {
+ status = "disabled";
+};
+
+&wkup_gpio1 {
+ status = "disabled";
+};
--
2.22.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 2/6] arm64: dts: ti: k3-j721e: Add gpio nodes in main domain
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
There are 8 instances of gpio modules in main domain divided into 2 groups:
- Group1: gpio0, gpio2, gpio4, gpio6
- Group2: gpio1, gpio3, gpio5, gpio7
Groups are created to provide protection between two different processor
virtual worlds. There are x gpio lines coming out of each group. Each module
in a group has equal x gpio lines pinned out. There is a top level mux for
selecting the module instance for each pin coming out of group. Exactly
one module can be selected to control the corresponding pin. This muxing
can be controlled along the pad mux configuration registers.
Group1 pins out 128 lines(8 banks). Group 2 pins out 36 lines(2 banks).
Add DT nodes for each module instance in the main domain. Users should
make sure that correct gpio instance is selected in their pad configuration.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 132 ++++++++++++++++++++++
1 file changed, 132 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index 01661c22c39d..199bc9a00b20 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -240,4 +240,136 @@
clocks = <&k3_clks 286 0>;
clock-names = "fclk";
};
+
+ main_gpio0: gpio@600000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00600000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <105 0>, <105 1>, <105 2>, <105 3>,
+ <105 4>, <105 5>, <105 6>, <105 7>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <128>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 105 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio1: gpio@601000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00601000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <106 0>, <106 1>, <106 2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <36>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 106 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 106 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio2: gpio@610000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00610000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <107 0>, <107 1>, <107 2>, <107 3>,
+ <107 4>, <107 5>, <107 6>, <107 7>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <128>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 107 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 107 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio3: gpio@611000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00611000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <108 0>, <108 1>, <108 2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <36>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 108 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 108 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio4: gpio@620000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00620000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <109 0>, <109 1>, <109 2>, <109 3>,
+ <109 4>, <109 5>, <109 6>, <109 7>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <128>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 109 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 109 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio5: gpio@621000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00621000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <110 0>, <110 1>, <110 2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <36>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 110 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 110 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio6: gpio@630000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00630000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <111 0>, <111 1>, <111 2>, <111 3>,
+ <111 4>, <111 5>, <111 6>, <111 7>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <128>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 111 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 111 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio7: gpio@631000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00631000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <112 0>, <112 1>, <112 2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <36>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 112 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 112 0>;
+ clock-names = "gpio";
+ };
};
--
2.22.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 3/6] arm64: dts: ti: k3-j721e: Add gpio nodes in wakeup domain
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
Similar to the gpio groups in main domain, there is one gpio group
in wakup domain with 2 module instances in it. This gpio group pins
out 84 lines(6 banks). Add DT node for these 2 gpio module instances.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 34 +++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
index e616c2481f51..555dc7b7aedc 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
@@ -87,4 +87,38 @@
ti,sci-dst-id = <14>;
ti,sci-rm-range-girq = <0x5>;
};
+
+ wkup_gpio0: gpio@42110000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x42110000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&wkup_gpio_intr>;
+ interrupts = <113 0>, <113 1>, <113 2>,
+ <113 3>, <113 4>, <113 5>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <84>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 113 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 113 0>;
+ clock-names = "gpio";
+ };
+
+ wkup_gpio1: gpio@42100000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x42100000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&wkup_gpio_intr>;
+ interrupts = <114 0>, <114 1>, <114 2>,
+ <114 3>, <114 4>, <114 5>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <84>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 114 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 114 0>;
+ clock-names = "gpio";
+ };
};
--
2.22.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 0/6] arm64: dts: ti: k3-j721e: Add gpio nodes
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
This series adds gpio nodes for J721E SoC and enable gpio keys
in J72E common process board.
Tested Boot log: https://pastebin.ubuntu.com/p/P6QqmZYtSC/
This series depends on Power-domain cells update series:
https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=152109
Lokesh Vutla (5):
dt-bindings: gpio: davinci: Add new compatible for J721E SoCs
arm64: dts: ti: k3-j721e: Add gpio nodes in main domain
arm64: dts: ti: k3-j721e: Add gpio nodes in wakeup domain
arm64: dts: ti: k3-j721e-common-proc-board: Disable unused gpio
modules
dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E
Nikhil Devshatwar (1):
arm64: dts: k3-j721e: Add gpio-keys on common processor board
.../devicetree/bindings/gpio/gpio-davinci.txt | 1 +
.../dts/ti/k3-j721e-common-proc-board.dts | 65 +++++++++
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 132 ++++++++++++++++++
.../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 34 +++++
include/dt-bindings/pinctrl/k3.h | 3 +
5 files changed, 235 insertions(+)
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/6] dt-bindings: gpio: davinci: Add new compatible for J721E SoCs
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
J721e SoCs have same gpio IP as K2G davinci gpio. Add a new compatible to
handle J721E SoCs.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
Documentation/devicetree/bindings/gpio/gpio-davinci.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index bc6b4b62df83..cd91d61eac31 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -6,6 +6,7 @@ Required Properties:
66AK2E SoCs
"ti,k2g-gpio", "ti,keystone-gpio": for 66AK2G
"ti,am654-gpio", "ti,keystone-gpio": for TI K3 AM654
+ "ti,j721e-gpio", "ti,keystone-gpio": for J721E SoCs
- reg: Physical base address of the controller and the size of memory mapped
registers.
--
2.22.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: [linux-sunxi] [PATCH v8 4/4] arm64: dts: allwinner: orange-pi-3: Enable HDMI output
From: Code Kipper @ 2019-08-09 8:25 UTC (permalink / raw)
To: megous
Cc: Mark Rutland, devicetree, Maxime Ripard, Chen-Yu Tsai,
Jernej Škrabec, linux-kernel, David Airlie, linux-sunxi,
Rob Herring, dri-devel, Daniel Vetter, linux-arm-kernel
In-Reply-To: <20190806155744.10263-5-megous@megous.com>
On Tue, 6 Aug 2019 at 17:57, <megous@megous.com> wrote:
>
> From: Ondrej Jirman <megous@megous.com>
>
> Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables the DDC
> I2C bus voltage shifter. Before EDID can be read, we need to pull PH2 high.
> This is realized by the ddc-en-gpios property.
Great work. Is there any chance you can move this to the
arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi?, as all the H6
based orange-pi's have this feature.
BR,
CK
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 26 +++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> index 2c6807b74ff6..01bb1bafe284 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> @@ -22,6 +22,18 @@
> stdout-path = "serial0:115200n8";
> };
>
> + connector {
> + compatible = "hdmi-connector";
> + ddc-en-gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&hdmi_out_con>;
> + };
> + };
> + };
> +
> leds {
> compatible = "gpio-leds";
>
> @@ -72,6 +84,10 @@
> cpu-supply = <®_dcdca>;
> };
>
> +&de {
> + status = "okay";
> +};
> +
> &ehci0 {
> status = "okay";
> };
> @@ -91,6 +107,16 @@
> status = "okay";
> };
>
> +&hdmi {
> + status = "okay";
> +};
> +
> +&hdmi_out {
> + hdmi_out_con: endpoint {
> + remote-endpoint = <&hdmi_con_in>;
> + };
> +};
> +
> &mdio {
> ext_rgmii_phy: ethernet-phy@1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> --
> 2.22.0
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190806155744.10263-5-megous%40megous.com.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [alsa-devel] Regression in next with codec unload and snd_soc_component_get/put
From: Takashi Iwai @ 2019-08-09 8:23 UTC (permalink / raw)
To: Tony Lindgren
Cc: alsa-devel, Kuninori Morimoto, linux-kernel, Jaroslav Kysela,
Mark Brown, linux-omap, linux-arm-kernel
In-Reply-To: <20190809074643.GB52127@atomide.com>
On Fri, 09 Aug 2019 09:46:43 +0200,
Tony Lindgren wrote:
>
> * Takashi Iwai <tiwai@suse.de> [190809 07:25]:
> > On Fri, 09 Aug 2019 09:00:03 +0200,
> > Tony Lindgren wrote:
> > >
> > > Hi,
> > >
> > > Looks like commit 4a81e8f30d0b ("ASoC: soc-component: add
> > > snd_soc_component_get/put()") causes a regression where trying
> > > to rmmod a codec driver fails with module is in use error after
> > > rmmod of snd-soc-audio-graph-card for example.
> > >
> > > Any ideas what goes wrong there?
> >
> > There is an obvious typo: soc_cleanup_component() should call
> > snd_soc_component_module_put_when_remove() instead of *_close().
>
> Making that change locally seems to fix it thanks.
... and it was already fixed in the later commit 0e36f36b04e7
"ASoC: soc-core: fix module_put() warning in soc_cleanup_component".
Takashi
_______________________________________________
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 1/2] drm: add cache support for arm64
From: Christoph Hellwig @ 2019-08-09 8:18 UTC (permalink / raw)
To: Rob Clark
Cc: Mark Rutland, Maxime Ripard, Catalin Marinas, David Airlie,
Maarten Lankhorst, LKML, dri-devel, Sean Paul, Rob Clark,
linux-arm-kernel, Daniel Vetter, Greg Kroah-Hartman,
Thomas Gleixner, Will Deacon, Christoph Hellwig, Allison Randal
In-Reply-To: <CAJs_Fx5fJ31CsFODBgBbhcCvoxSX_D1NHDjQs4LtJ_0GwuxMVA@mail.gmail.com>
On Thu, Aug 08, 2019 at 09:44:32AM -0700, Rob Clark wrote:
> > GFP_HIGHUSER basically just means that this is an allocation that could
> > dip into highmem, in which case it would not have a kernel mapping.
> > This can happen on arm + LPAE, but not on arm64.
>
> Just a dumb question, but why is *all* memory in the linear map on
> arm64? It would seem useful to have a source of pages that is not in
> the linear map.
> I guess it is mapped as huge pages (or something larger than 4k pages)?
In general that is just how the Linux kernel always worked, on all
architectures - we always had a linear mapping for all memory in the
kernel to make accessing it simple. That started to break down a bit
with the 32-bit x86 PAE mode that supported more physical addressing
that virtual, which required the "high" memory to not be mapped into
the kernel direct mapping. Similar schemes later showed up on various
other 32-bit architectures.
There is a patchset called XPFO that ensures memory is either in the
kernel direct map, or in userspace but not both to work around
speculation related vulnerabilities, but it has a pretty big performance
impact.
> Any recommended reading to understand how/why the kernel address space
> is setup the way it is (so I can ask fewer dumb questions)?
I don't really have a good pointer. But usually there is just dumb
answers, not dumb questions.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH V2 4/4] platform: mtk-isp: Add Mediatek FD driver
From: Tomasz Figa @ 2019-08-09 8:07 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: laurent.pinchart+renesas@ideasonboard.com,
Rynn Wu (吳育恩),
Po-Yang Huang (黃柏陽), suleiman@chromium.org,
Jerry-ch Chen, Jungo Lin (林明俊),
hans.verkuil@cisco.com, Sakari Ailus,
Frederic Chen (陳俊元),
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
Sj Huang (黃信璋), yuzhao@chromium.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
mchehab@kernel.org, linux-arm-kernel@lists.infradead.org,
Sean Cheng (鄭昇弘), srv_heupstream,
shik@chromium.org, Christie Yu (游雅惠),
zwisler@chromium.org, Hans Verkuil
In-Reply-To: <1564401491.15267.405.camel@mtksdccf07>
On Mon, Jul 29, 2019 at 8:58 PM Jerry-ch Chen
<Jerry-ch.Chen@mediatek.com> wrote:
>
> Hi Tomasz,
>
> On Mon, 2019-07-29 at 17:57 +0800, Tomasz Figa wrote:
> > On Mon, Jul 29, 2019 at 3:01 PM Jerry-ch Chen
> > <Jerry-ch.Chen@mediatek.com> wrote:
> > >
> > > Hi Enrico,
> > >
> > > On Tue, 2019-07-09 at 18:56 +0800, Enrico Weigelt, metux IT consult
> > > wrote:
> > > > On 09.07.19 10:41, Jerry-ch Chen wrote:
> > > >
> > > > Hi,
> > > >
> > > >
> > > > > diff --git a/drivers/media/platform/mtk-isp/fd/mtk_fd.h b/drivers/media/platform/mtk-isp/fd/mtk_fd.h
> > > > > new file mode 100644
> > > > > index 0000000..289999b
> > > > > --- /dev/null
> > > > > +++ b/drivers/media/platform/mtk-isp/fd/mtk_fd.h
> > > > > @@ -0,0 +1,157 @@
> > > > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > > > +//
> > > > > +// Copyright (c) 2018 MediaTek Inc.
> > > > > +
> > > > > +#ifndef __MTK_FD_HW_H__
> > > > > +#define __MTK_FD_HW_H__
> > > > > +
> > > > > +#include <linux/io.h>
> > > > > +#include <linux/types.h>
> > > > > +#include <linux/platform_device.h>
> > > > > +#include <media/v4l2-ctrls.h>
> > > > > +#include <media/v4l2-device.h>
> > > > > +#include <media/videobuf2-v4l2.h>
> > > > > +
> > > > > +#define MTK_FD_OUTPUT_MIN_WIDTH 26U
> > > > > +#define MTK_FD_OUTPUT_MIN_HEIGHT 26U
> > > > > +#define MTK_FD_OUTPUT_MAX_WIDTH 640U
> > > > > +#define MTK_FD_OUTPUT_MAX_HEIGHT 480U
> > > > > +
> > > > > +/* Control the user defined image widths and heights
> > > > > + * to be scaled and performed face detection in FD HW.
> > > > > + * MTK FD support up to 14 user defined image sizes to perform face detection.
> > > > > + */
> > > > > +#define V4L2_CID_MTK_FD_SCALE_IMG_WIDTH (V4L2_CID_USER_MTK_FD_BASE + 1)
> > > > > +#define V4L2_CID_MTK_FD_SCALE_IMG_HEIGHT (V4L2_CID_USER_MTK_FD_BASE + 2)
> > > >
> > > > I've got a *really* bad feeling about introducing chip specific
> > > > uapi stuff. (by the way: uapi stuff belongs into include/uapi/...)
> > > >
> > > Thanks for your comments,
> > >
> > > If we remain chip-specific control IDs, I will move the uapi stuff into
> > > inlcude/uapi/mtk_fd.h (filename TBD)
> > >
> > > > Maybe you could tell us what that's *really* about, so we can find some
> > > > standard / chip-independent api for these things. That's one of the
> > > > major point of the kernel: hardware abstraction.
> > > >
> > > I am not sure if it is possible for us to add some standard
> > > v4l2-controls for face detection, a further explanations of controls are
> > > listed below.
> > >
> > > In v4l2-controls, there exists V4L2_CID_DETECT_CLASS, but I haven't
> > > found the standards or api that can be used for face detection yet.
> > > https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/v4l2-controls.h#L1092
> > >
> > > For detecting certain face angle and head direction, we would need
> > > V4L2_CID_DETECT_ANGLE, V4L2_CID_DETECT_DIRECTION controls for user to
> > > specify the angle and direction to be detected.
> > > In MTK FD driver, we support the following angles and directions to be
> > > selected by user, and they are both multiple selected .
> > > FD_angle_table[] = {-90, -45, 0 , 45, 90}
> > > FD_direction_table[] = {0, 30, 60, 90, 120, 150, ..., 330}
> > >
> > > Assuming these v4l2-controls are array of V4L2_CTRL_TYPE_U16 with
> > > dimension 5 and 12.
> > > User can select the desired angle and directions to be detected into
> > > arrays and bring it to driver by these controls, however, the more they
> > > select, the longer execution time needed by HW.
> > >
> >
> > Sounds like we need some kind of a menu bitmask control here, but I
> > don't see V4L2 having anything like that.
> >
> > Hans, Sakari, any ideas?
> >
> > > For detecting different sizes of faces and increase the detection speed,
> > > FD driver might need to scales down the input image into different
> > > smaller sizes
> >
> > Do you mean the FD hardware would do the scaling or the driver code
> > itself? It would be undesirable to do such scaling in a kernel driver,
> > so if that's not something handled by the hardware, the downscaled
> > image might need to be provided from the userspace.
> >
> Thanks for your comments.
>
> Yes, FD hardware will do the scaling itself, so driver could set the
> sizes.
>
> > >, besides driver default values, user or proprietary
> > > algorithm library can manually set the desired image sizes, therefore,
> > > we would need the following controls:
> > > V4L2_CID_DETECT_SCALE_DOWN_IMG_WIDTH and
> > > V4L2_CID_DETECT_SCALE_DOWN_IMG_HEIGHT.
> > > In MTK FD driver, we implement these controls as array of
> > > V4L2_CTRL_TYPE_U16 with the dimension 15.
> >
> > Why 15?
> >
> It consists of one input image size and 14 down-scaled image sizes,
> the amount 15 (or say 14) is defined by the MTK FD algo library,
> therefore I remain the number of 15 here for communicate with the
> library.
> Maybe it should be defined as following?
> MTK_FD_MAX_SCALE_SIZE_NUM 14
> and
> MTK_FD_SCALE_ARR_NUM 15
>
> > >
> > > For controlling detection speed, we would need the
> > > V4L2_CID_DETECT_SPEED, the faster speedup implies the lower accuracy of
> > > detection, In MTK FD driver, the max level of speedup is 7, and default
> > > value is 0.
> > >
> > > For MTK FD algorithm user library, they would need select extra
> > > detection features(models) used in HW, we need
> > > V4L2_CID_MTK_FD_EXTRA_MODEL, this will be set to 1 for using extra
> > > model. However, we are considering make this control more
> > > chip-independent and can be added into standard.
> > > for example, V4L2_CID_DETECTION_FD_MODEL or ...FD_ALGO,
> > > drivers can define the detection algorithm or detection model to be used
> > > for users to select. How do you think?
> >
> > Sounds like something that could be a menu control, so it could vary
> > between drivers.
> >
> Ok, and maybe it should be created by v4l2_ctrl_new_int_menu(...)?
>
> > >
> > > In short, I summery the control IDs as following:
> > > V4L2_CID_DETECT_ANGLE: set the angle of face in degrees. 90 ~ -90
> > > degrees.
> > > V4L2_CID_DETECT_DIRECTION: set the rotation of the head in degrees.
> > > 0~330 degrees.
> > > V4L2_CID_DETECT_SCALE_DOWN_IMG_WIDTH: set the image widths for an input
> > > image to be scaled down for face detection
> > > V4L2_CID_DETECT_SCALE_DOWN_IMG_HEIGHT: set the image heights for an
> > > input image to be scaled down for face detection
> > > V4L2_CID_DETECT_SPEED: set the detection speed, usually reducing
> > > accuracy.
> > > V4L2_CID_DETECTION_FD_MODEL: select the detection model or algorithm to
> > > be used by face detection driver.
> > >
> > > > > +#define ENABLE_FD 0x111
> > > > > +#define FD_HW_ENABLE 0x4
> > > > > +#define FD_INT_EN 0x15c
> > > > > +#define FD_INT 0x168
> > > > > +#define FD_RESULT 0x178
> > > > > +#define FD_IRQ_MASK 0x001
> > > > > +
> > > > > +#define RS_MAX_BUF_SIZE 2288788
> > > > > +#define FD_MAX_SPEEDUP 7
> > > > > +#define FD_MAX_POSE_VAL 0xfffffffffffffff
> > > > > +#define FD_DEF_POSE_VAL 0x3ff
> > > > > +#define MAX_FD_SEL_NUM 1026
> > > >
> > > > If that file is supposed to be included by anything beyond the driver
> > > > itself, we need proper prefixing. (same for anything else in here)
> > > >
> > > I will fix it as following:
> > >
> > > #define FD_ENABLE 0x111
> > >
> > > #define FD_REG_OFFSET_HW_ENABLE 0x4
> > > #define FD_REG_OFFSET_INT_EN 0x15c
> > > #define FD_REG_OFFSET_INT_VAL 0x168
> > > #define FD_REG_OFFSET_RESULT 0x178
> > >
> > > #define FD_IRQ_MASK 1
> > > #define FD_MAX_RS_BUF_SIZE 2288788
> > > #define FD_MAX_SPEEDUP 7
> > > #define FD_MAX_RESULT_NUM 1026
> > >
> >
> > I'd suggest the MTK_FD_ prefix.
> >
> Ok, I will use MTK_FD_ prefix.
>
> > > > > diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> > > > > index 3dcfc61..eae876e 100644
> > > > > --- a/include/uapi/linux/v4l2-controls.h
> > > > > +++ b/include/uapi/linux/v4l2-controls.h
> > > > > @@ -192,6 +192,10 @@ enum v4l2_colorfx {
> > > > > * We reserve 16 controls for this driver. */
> > > > > #define V4L2_CID_USER_IMX_BASE (V4L2_CID_USER_BASE + 0x10b0)
> > > > >
> > > > > +/* The base for the mediatek FD driver controls */
> > > > > +/* We reserve 16 controls for this driver. */
> > > > > +#define V4L2_CID_USER_MTK_FD_BASE (V4L2_CID_USER_BASE + 0x10d0)
> > > >
> > > > Why only the base, but not the actual IDs in uapi ?
> > > >
> > > I will put actual IDs in uapi/ for user to reference.
Enrico, any thoughts on the explanation that Jerry provided and
further discussion above?
Thanks,
Tomasz
_______________________________________________
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 1/2] drm: add cache support for arm64
From: Christoph Hellwig @ 2019-08-09 8:14 UTC (permalink / raw)
To: Christoph Hellwig, Rob Clark, Rob Clark, dri-devel,
Catalin Marinas, Will Deacon, Maarten Lankhorst, Maxime Ripard,
Sean Paul, David Airlie, Allison Randal, Greg Kroah-Hartman,
Thomas Gleixner, Linux ARM, LKML
In-Reply-To: <20190808115808.GN7444@phenom.ffwll.local>
On Thu, Aug 08, 2019 at 01:58:08PM +0200, Daniel Vetter wrote:
> > > We use shmem to get at swappable pages. We generally just assume that
> > > the gpu can get at those pages, but things fall apart in fun ways:
> > > - some setups somehow inject bounce buffers. Some drivers just give
> > > up, others try to allocate a pool of pages with dma_alloc_coherent.
> > > - some devices are misdesigned and can't access as much as the cpu. We
> > > allocate using GFP_DMA32 to fix that.
> >
> > Well, for shmem you can't really call allocators directly, right?
>
> We can pass gfp flags to shmem_read_mapping_page_gfp, which is just about
> enough for the 2 cases on intel platforms where the gpu can only access
> 4G, but the cpu has way more.
Right. And that works for architectures without weird DMA offsets and
devices that exactly have a 32-bit DMA limit. It falls flat for all
the more complex ones unfortunately.
> > But userspace malloc really means dma_map_* anyway, so not really
> > relevant for memory allocations.
>
> It does tie in, since we'll want a dma_map which fails if a direct mapping
> isn't possible. It also helps the driver code a lot if we could use the
> same low-level flushing functions between our own memory (whatever that
> is) and anon pages from malloc. And in all the cases if it's not possible,
> we want a failure, not elaborate attempts at hiding the differences
> between all possible architectures out there.
At the very lowest level all goes down to the same three primitives we
talked about anyway, but there are different ways how they are combined.
For the streaming mappins looks at the table in arch/arc/mm/dma.c I
mentioned earlier. For memory that is prepared for just mmaping to
userspace without a kernel user we'll always do a wb+inv. But as the
other subthread shows we'll need to eventually look into unmapping
(or remapping with the same attributes) of that memory in kernel space
to avoid speculation bugs (or just invalid combination on x86 where
we check for that), so the API will be a little more complex.
Btw, are all DRM drivers using vmf_insert_* to pre-populate the mapping
like the MSM case, or are some doing dynamic faulting from
vm_ops->fault?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH -next] ASoC: mt6351: remove unused variable 'mt_lineout_control'
From: YueHaibing @ 2019-08-09 8:02 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai, matthias.bgg,
pierre-louis.bossart
Cc: YueHaibing, alsa-devel, linux-mediatek, linux-kernel,
linux-arm-kernel
sound/soc/codecs/mt6351.c:1070:38: warning:
mt_lineout_control defined but not used [-Wunused-const-variable=]
It is never used, so can be removed.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
sound/soc/codecs/mt6351.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/sound/soc/codecs/mt6351.c b/sound/soc/codecs/mt6351.c
index 4b3ce01..5c0536e 100644
--- a/sound/soc/codecs/mt6351.c
+++ b/sound/soc/codecs/mt6351.c
@@ -1066,11 +1066,6 @@ static int mt_mic_bias_2_event(struct snd_soc_dapm_widget *w,
return 0;
}
-/* DAPM Kcontrols */
-static const struct snd_kcontrol_new mt_lineout_control =
- SOC_DAPM_SINGLE("Switch", MT6351_AUDDEC_ANA_CON3,
- RG_AUDLOLPWRUP_VAUDP32_BIT, 1, 0);
-
/* DAPM Widgets */
static const struct snd_soc_dapm_widget mt6351_dapm_widgets[] = {
/* Digital Clock */
--
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
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