kisskb: OK linux-next/axs103_smp_defconfig/arcv2 Wed Nov 15, 20:44
OK linux-next/axs103_smp_defconfig/arcv2 Wed Nov 15, 20:44
http://kisskb.ellerman.id.au/kisskb/buildresult/13205920/
Commit: Add linux-next specific files for 20171114
c9b945f2a731076ad5c634b6ca65a8916e127ba3
Compiler: arc-linux-gcc.br_real (Buildroot 2016.11-git-00613-ge98b4dd) 6.2.1
20160824
Possible errors
---
#define KERN_ERR KERN_SOH "3" /* error conditions */
#define KERN_ERR KERN_SOH "3" /* error conditions */
pr_err("ASN.1 decoder error: Found reserved opcode (%u) pc=%zu\n",
#define KERN_ERR KERN_SOH "3" /* error conditions */
#define KERN_ERR KERN_SOH "3" /* error conditions */
Possible warnings (121)
--
drivers/bluetooth/Kconfig:35:warning: multi-line strings not supported
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 4 has type 'unsigned int' [-Wformat=]
drivers/base/component.c:101:24: warning: format '%zu' expects argument of type
'size_t', but argument 4 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 5 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 6 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 4 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 5 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 6 has type 'unsigned int' [-Wformat=]
security/keys/request_key_auth.c:77:31: warning: format '%zu' expects argument
of type 'size_t', but argument 4 has type 'unsigned int' [-Wformat=]
include/linux/kernel.h:792:16: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:792:16: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:792:16: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:792:16: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:792:16: warning: comparison of distinct pointer types
lacks a cast
include/linux/kernel.h:792:16: warning: comparison of distinct pointer types
lacks a cast
mm/percpu.c:1367:17: warning: format '%zu' expects argument of type 'size_t',
but argument 4 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1367:17: warning: format '%zu' expects argument of type 'size_t',
but argument 5 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
#define KERN_WARNING KERN_SOH "4" /* warning conditions */
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 3 has type 'unsigned int' [-Wformat=]
#define KERN_WARNING KERN_SOH "4" /* warning conditions */
mm/percpu.c:1916:27: warning: format '%zu' expects argument of type 'size_t',
but argument 3 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1916:32: warning: format '%zu' expects argument of type 'size_t',
but argument 4 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1916:37: warning: format '%zu' expects argument of type 'size_t',
but argument 5 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1916:42: warning: format '%zu' expects argument of type 'size_t',
but argument 6 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1916:52: warning: format '%zu' expects argument of type 'size_t',
but argument 7 has type 'unsigned int' [-Wformat=]
mm/percpu.c:1916:56: warning: format '%zu' expects argument of type 'size_t',
but argument 8 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 4 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 5 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 6 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of
type 'size_t', but argument 7 has type 'unsigned int' [-Wformat=]
mm/slab_common.c:925:45: warning: format '%zu' expects argument of type
'size_t', but argument 3 has type 'unsigned int' [-Wformat=]
include/linux/kern_levels.h:5:18: warning: format '%zd' expects argument of
type 'signed size_t', but argument 3 has type 'size_t {aka unsigned int}'
[-Wformat=]
include/linux/kernel.h:792:16: warning: comparison of distinct pointer types
lacks a cast
kerne
kisskb: OK linux-next/axs101_defconfig/arcompact Wed Nov 15, 20:44
OK linux-next/axs101_defconfig/arcompact Wed Nov 15, 20:44 http://kisskb.ellerman.id.au/kisskb/buildresult/13205921/ Commit: Add linux-next specific files for 20171114 c9b945f2a731076ad5c634b6ca65a8916e127ba3 Compiler: arc-buildroot-linux-uclibc-gcc (Buildroot 2015.08.1) 4.8.4 No errors found in log Possible warnings (18) -- drivers/bluetooth/Kconfig:35:warning: multi-line strings not supported kernel/sched/core.c:3247:1: warning: control reaches end of non-void function [-Wreturn-type] include/linux/kernel.h:792:16: warning: comparison of distinct pointer types lacks a cast [enabled by default] fs/ext4/ext4_jbd2.h:426:1: warning: control reaches end of non-void function [-Wreturn-type] fs/ext4/ext4_jbd2.h:426:1: warning: control reaches end of non-void function [-Wreturn-type] block/cfq-iosched.c:3804:1: warning: control reaches end of non-void function [-Wreturn-type] fs/ext4/ext4_jbd2.h:426:1: warning: control reaches end of non-void function [-Wreturn-type] fs/ext4/ext4_jbd2.h:426:1: warning: control reaches end of non-void function [-Wreturn-type] net/core/ethtool.c:311:1: warning: control reaches end of non-void function [-Wreturn-type] fs/ext4/ext4_jbd2.h:426:1: warning: control reaches end of non-void function [-Wreturn-type] fs/ext4/ext4_jbd2.h:426:1: warning: control reaches end of non-void function [-Wreturn-type] fs/ext4/ext4_jbd2.h:426:1: warning: control reaches end of non-void function [-Wreturn-type] fs/ext4/ext4_jbd2.h:426:1: warning: control reaches end of non-void function [-Wreturn-type] lib/string.c:1053:1: warning: 'noreturn' function does return [enabled by default] drivers/scsi/sd.c:1310:1: warning: control reaches end of non-void function [-Wreturn-type] include/linux/sunrpc/svc_xprt.h:180:1: warning: control reaches end of non-void function [-Wreturn-type] fs/ext4/ext4_jbd2.h:426:1: warning: control reaches end of non-void function [-Wreturn-type] net/ipv4/tcp_input.c:4228:49: warning: array subscript is above array bounds [-Warray-bounds] ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 4/4] ARCv2: entry: Reduce perf intr return path
On Tue, Nov 14, 2017 at 03:01:26PM -0800, Vineet Gupta wrote: > On 11/14/2017 02:28 AM, Peter Zijlstra wrote: > > On Tue, Nov 07, 2017 at 02:13:04PM -0800, Vineet Gupta wrote: > > > In the more likely case of returning to kernel from perf interrupt, do a > > > fast path returning w/o bothering about CONFIG_PREEMPT etc > > > > I think this needs more explaining and certainly also deserves a code > > comment. > > Sure ! It was a quick hack mainly to solicit feedback. > > > > Is the argument something along these lines? > > > >Assumes the interrupt will never set TIF_NEED_RESCHED; > >therefore no preemption is ever required on return from > >the interrupt. > > No. I don't think we can assume that. Well, given we run that code from NMI context on a number of platforms (x86 being one of them) it can not in fact do things like wakeups. So the pure perf-interrupt part should never set TIF_NEED_RESCHED. I think we can actually make that assumption. > But I was choosing to ignore it mainly to reduce the overhead of a > perf intr in general. A subsequent real interrupt could go thru thru > the gyrations of preemption etc. So that's dangerous thinking... People that run a PREEMPT kernel generally tend to care about latency (esp. when combined with PREEMPT_RT). And ignoring a preemption point gets these people upset (and missed preemptions are a royal friggin pain to debug). > > What do you (on ARC) do about irq_work ? > > Nothing ATM. So the reason I'm asking is that some architectures that don't have NMIs call irq_work_run() at the very end of their perf-interrupt handler (ARM does this for instance). And the thing is, _that_ can and does do things like wakeups and will thus require doing the PREEMPT thing. > Although I'm sure it is, can you please explain how irq_work is relevant in > the context of this patch. Since the perf interrupt (in general) cannot call a whole lot of things for it needs to assume running from NMI context, it needs to defer things to a more regular context. It does this with irq_work. So for instance, when the output buffer reaches its watermark, we'll raise the irq_work to issue the wakeup of tasks that poll() on that. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arc: Flush and invalidate caches on start
On Thu, 2017-08-31 at 16:34 +, Alexey Brodkin wrote: > Hi Vineet, > > On Thu, 2017-08-31 at 09:31 -0700, Vineet Gupta wrote: > > > > On 08/31/2017 07:22 AM, Alexey Brodkin wrote: > > > > > > > > > This is useful to make sure no stale data exists in caches after > > > bootloaders. > > > The worst thing could be some lines of cache were locked in a bootloader > > > for example during DDR recalibration and never unlocked. This may lead > > > to really unpredictable issues later down the line. > > > > > > Signed-off-by: Alexey Brodkin > > > --- > > > arch/arc/kernel/head.S | 16 > > > 1 file changed, 16 insertions(+) > > > > > > diff --git a/arch/arc/kernel/head.S b/arch/arc/kernel/head.S > > > index 8b90d25a15cc..04e28b664183 100644 > > > --- a/arch/arc/kernel/head.S > > > +++ b/arch/arc/kernel/head.S > > > @@ -34,6 +34,10 @@ > > > #endif > > > sr r5, [ARC_REG_IC_CTRL] > > > > > > + ; Invalidate entire I$ > > > + mov r5, 1 > > > + sr r5, [ARC_REG_IC_IVIC] > > > + > > > 1: > > > lr r5, [ARC_REG_DC_BCR] > > > breqr5, 0, 1f ; D$ doesn't exist > > > @@ -46,6 +50,18 @@ > > > #endif > > > sr r5, [ARC_REG_DC_CTRL] > > > > > > + ; Flush entire D$ > > > + mov r5, 1 > > > + sr r5, [ARC_REG_DC_FLSH] > > > + ; Wait for flush operation to complete > > > +1: > > > + lr r5, [ARC_REG_DC_CTRL] > > > + bbit1 r5, DC_CTRL_FLUSH_STATUS, 1b Looking more at this stuff I think that on that early stage there's no point in flushing of D$, moreover it could be dangerous as if there's some garbage in there it will contaminate DDR with good data. > > > + ; Invalidate entire D$ > > > + mov r5, 1 > > > + sr r5, [ARC_REG_DC_IVDC] > > > + > > > > AFAIK uboot already flushes the caches before handing control over to > > kernel - so > > why do we need it here. > > If uboot is locking lines, it needs to fix that and not penalize the > > general case > > with or w/o uboot ! > > U-Boot indeed flushes caches.. but doesn't invalidate them! > And only invalidation unlocks locked lines. > > That indeed should be added in U-Boot but I'd say above stuff doesn't > influence a lot code size or execution time while makes system more > fool-proof. As for invalidation that IMHO is really important especially for I$. See even if we do proper invalidation of both caches in say U-Boot but keep caches enabled at least the last I$ line that contained last "jump" instruction will left in the cache. And now if we're unlucky enough we may execute code that overlaps location of that last "jump" and instead of expected instruction freshly loaded from DDR we'll execute garbage left-over. Note this is not just a theory, we hit that problem trying to execute U-Boot from u-Boot (not kidding - we do self-upgrade that way). Similar idea could be valid for D$ even though not very likely but still... Given code in U-boot writen in C even in between dcache_flush() and icache_invalidate() might happen some data accesses hidden in implementations of those functions. In fact currently we do checks if SLC exist in those functions and that check is done via polling a global var, so for sure some LD instructions are executed there. That said if my explanation now makes more sense I'd be willing to send a v2 with invalidation of all caches (I$, D$ and SLC). -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
etnaviv: PHYS_OFFSET usage
Hi Lucas, As we discussed on ELCE last month in Prague we have Vivante GPU built-in our new ARC HSDK development board. And even though [thanks to your suggestions] I got Etnaviv driver working perfectly fine on our board I faced one quite a tricky situation [which I dirty worked-around for now]. Etnaviv driver uses some PHYS_OFFSET define which is not very usual across all architectures and platforms supported by Linux kernel. In fact for ARC we don't have PHYS_OFFSET defined [yet]. And I'm wondering how to get this resolved. Essentially we have 2 options: 1. Define PHYS_OFFSET for ARC (and later for other arches once needed) 2. Replace PHYS_OFFSET with something else in etnaviv sources. Even though (1) seems to be the simplest solution is doesn't look very nice because it seems to be quite ARM-specific but not something really generic and portable. As for (2) frankly I din't quite understand why do we really care about DDR start offset in the GPU driver. If some more light could be shed on this topic probably we'll figure out what would be more elegant solution. Regards, Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: etnaviv: PHYS_OFFSET usage
Hi Alexey, Am Mittwoch, den 15.11.2017, 16:24 + schrieb Alexey Brodkin: > Hi Lucas, > > As we discussed on ELCE last month in Prague we have Vivante GPU > built-in our new ARC HSDK development board. > > And even though [thanks to your suggestions] I got Etnaviv driver > working perfectly fine on our board I faced one quite a tricky > situation [which I dirty worked-around for now]. > > Etnaviv driver uses some PHYS_OFFSET define which is not very > usual across all architectures and platforms supported by Linux kernel. > > In fact for ARC we don't have PHYS_OFFSET defined [yet]. > And I'm wondering how to get this resolved. > > Essentially we have 2 options: > 1. Define PHYS_OFFSET for ARC (and later for other arches once needed) > 2. Replace PHYS_OFFSET with something else in etnaviv sources. > > Even though (1) seems to be the simplest solution is doesn't look very nice > because it seems to be quite ARM-specific but not something really generic > and portable. > > As for (2) frankly I din't quite understand why do we really care about > DDR start offset in the GPU driver. If some more light could be shed on this > topic probably we'll figure out what would be more elegant solution. Basically the GPU has a linear address window which is 2GB in size and all GPU command buffers must be mapped through this window. The window has a base offset, so we can move it to point to different locations in the physical address space of the system. Etnaviv uses the PHYS_OFFSET to find out where in the physical address space the RAM starts. If the start of RAM is above the 2GB mark we _must_ use the linear window in order to make the command buffers available to the GPU. I'm not aware of any other kernel API that would allow us to find the start of RAM. If there is I would be happy to replace the PHYS_OFFSET stuff. If you don't like to copy the PHYS_OFFSET stuff to ARC, you would need to introduce some new API, which allows us to retrieve this information. Regards, Lucas ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: etnaviv: PHYS_OFFSET usage
Hi Lucas,
On Wed, 2017-11-15 at 17:44 +0100, Lucas Stach wrote:
> Hi Alexey,
>
> Am Mittwoch, den 15.11.2017, 16:24 + schrieb Alexey Brodkin:
> >
> > Hi Lucas,
> >
> > As we discussed on ELCE last month in Prague we have Vivante GPU
> > built-in our new ARC HSDK development board.
> >
> > And even though [thanks to your suggestions] I got Etnaviv driver
> > working perfectly fine on our board I faced one quite a tricky
> > situation [which I dirty worked-around for now].
> >
> > Etnaviv driver uses some PHYS_OFFSET define which is not very
> > usual across all architectures and platforms supported by Linux kernel.
> >
> > In fact for ARC we don't have PHYS_OFFSET defined [yet].
> > And I'm wondering how to get this resolved.
> >
> > Essentially we have 2 options:
> > 1. Define PHYS_OFFSET for ARC (and later for other arches once needed)
> > 2. Replace PHYS_OFFSET with something else in etnaviv sources.
> >
> > Even though (1) seems to be the simplest solution is doesn't look very nice
> > because it seems to be quite ARM-specific but not something really generic
> > and portable.
> >
> > As for (2) frankly I din't quite understand why do we really care about
> > DDR start offset in the GPU driver. If some more light could be shed on this
> > topic probably we'll figure out what would be more elegant solution.
>
> Basically the GPU has a linear address window which is 2GB in size and
> all GPU command buffers must be mapped through this window. The window
> has a base offset, so we can move it to point to different locations in
> the physical address space of the system.
Wow, what a design decision :)
> Etnaviv uses the PHYS_OFFSET to find out where in the physical address
> space the RAM starts. If the start of RAM is above the 2GB mark we
> _must_ use the linear window in order to make the command buffers
> available to the GPU.
Well that looks not super safe and versatile solution to me.
What if used RAM is much more than 2Gb? I guess in that case it's
possible to to set PHYS_OFFSET to say 0 and then kernel might allocate
command buffer above 2Gb which will make that buffer not visible for
GPU I guess.
> I'm not aware of any other kernel API that would allow us to find the
> start of RAM. If there is I would be happy to replace the PHYS_OFFSET
> stuff. If you don't like to copy the PHYS_OFFSET stuff to ARC, you
> would need to introduce some new API, which allows us to retrieve this
> information.
I'd say we may use so-called "reserved memory" here as a nice an elegant
solution.
In device tree we describe this memory area like this:
-->8---
gpu_3d: gpu@9 {
compatible = "vivante,gc";
reg = <0x9 0x4000>;
interrupts = <28>;
memory-region = <&gpu_memory>;
};
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
gpu_memory: gpu_memory@be00 {
compatible = "shared-dma-pool";
reg = <0xbe00 0x200>;
no-map;
};
};
-->8---
And then in the driver code we just need to do 2 things:
1) Start using this memory for allocations in the driver
with help of of_reserved_mem_device_init()
2) Get the region start. Not sure what's the best way to do it
but I guess we'll be able to get "reg" property of the "gpu_memory"
node in the worst case. And then use that base instead of PHYS_OFFSET.
If of any interest I'll be willing to send you an RFC shortly so you
may see real implementation in details.
-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: etnaviv: PHYS_OFFSET usage
Am Mittwoch, den 15.11.2017, 17:36 + schrieb Alexey Brodkin:
> Hi Lucas,
>
> On Wed, 2017-11-15 at 17:44 +0100, Lucas Stach wrote:
> > Hi Alexey,
> >
> > Am Mittwoch, den 15.11.2017, 16:24 + schrieb Alexey Brodkin:
> > >
> > > Hi Lucas,
> > >
> > > As we discussed on ELCE last month in Prague we have Vivante GPU
> > > built-in our new ARC HSDK development board.
> > >
> > > And even though [thanks to your suggestions] I got Etnaviv driver
> > > working perfectly fine on our board I faced one quite a tricky
> > > situation [which I dirty worked-around for now].
> > >
> > > Etnaviv driver uses some PHYS_OFFSET define which is not very
> > > usual across all architectures and platforms supported by Linux kernel.
> > >
> > > In fact for ARC we don't have PHYS_OFFSET defined [yet].
> > > And I'm wondering how to get this resolved.
> > >
> > > Essentially we have 2 options:
> > > 1. Define PHYS_OFFSET for ARC (and later for other arches once needed)
> > > 2. Replace PHYS_OFFSET with something else in etnaviv sources.
> > >
> > > Even though (1) seems to be the simplest solution is doesn't look very
> > > nice
> > > because it seems to be quite ARM-specific but not something really generic
> > > and portable.
> > >
> > > As for (2) frankly I din't quite understand why do we really care about
> > > DDR start offset in the GPU driver. If some more light could be shed on
> > > this
> > > topic probably we'll figure out what would be more elegant solution.
> >
> > Basically the GPU has a linear address window which is 2GB in size and
> > all GPU command buffers must be mapped through this window. The window
> > has a base offset, so we can move it to point to different locations in
> > the physical address space of the system.
>
> Wow, what a design decision :)
>
> > Etnaviv uses the PHYS_OFFSET to find out where in the physical address
> > space the RAM starts. If the start of RAM is above the 2GB mark we
> > _must_ use the linear window in order to make the command buffers
> > available to the GPU.
>
> Well that looks not super safe and versatile solution to me.
> What if used RAM is much more than 2Gb? I guess in that case it's
> possible to to set PHYS_OFFSET to say 0 and then kernel might allocate
> command buffer above 2Gb which will make that buffer not visible for
> GPU I guess.
GPU command buffer allocations is done through the dma_alloc_*
function, which will respect the GPU requirements.
Also the linear window is not normally moved to the start of RAM but to
the system CMA region, see below.
> > I'm not aware of any other kernel API that would allow us to find the
> > start of RAM. If there is I would be happy to replace the PHYS_OFFSET
> > stuff. If you don't like to copy the PHYS_OFFSET stuff to ARC, you
> > would need to introduce some new API, which allows us to retrieve this
> > information.
>
> I'd say we may use so-called "reserved memory" here as a nice an elegant
> solution.
> In device tree we describe this memory area like this:
> -->8---
> > gpu_3d: gpu@9 {
> > compatible = "vivante,gc";
> > reg = <0x9 0x4000>;
> > interrupts = <28>;
> > memory-region = <&gpu_memory>;
> };
>
> reserved-memory {
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges;
> > > gpu_memory: gpu_memory@be00 {
> > compatible = "shared-dma-pool";
> > reg = <0xbe00 0x200>;
> > no-map;
> > };
> };
> -->8---
>
> And then in the driver code we just need to do 2 things:
> 1) Start using this memory for allocations in the driver
> with help of of_reserved_mem_device_init()
> 2) Get the region start. Not sure what's the best way to do it
> but I guess we'll be able to get "reg" property of the "gpu_memory"
> node in the worst case. And then use that base instead of PHYS_OFFSET.
>
> If of any interest I'll be willing to send you an RFC shortly so you
> may see real implementation in details.
I'm not keen on having a private memory region for the GPU. Normally we
just use the shared system CMA memory region (and we will point the
linear memory window there on MC2.0 GPUs), which has the added benefit
that we can map the contiguous framebuffers allocated by another device
through the linear window, which is a crucial performance optimization
for the MMUv1 GPUs.
The only time where we really need to know the start of RAM is on MC1.0
GPUs which have a hardware bug in the TS unit, so we try to avoid
moving the linear window at all to work around that. In that case the
PHYS_OFFSET check is really there to avoid the situation where the
linear window would not allow any RAM to be reached at all. Then we
need to move the window, but disable any TS functionality, impacting
perfor
