* [PATCH v5 2/2] arm64: signal: Report signal frame size to userspace via auxv
From: Will Deacon @ 2018-05-29 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527261428-6662-3-git-send-email-Dave.Martin@arm.com>
Hi Dave,
Cheers for respinning this. Just one observation below, which I only just
thought about.
On Fri, May 25, 2018 at 04:17:08PM +0100, Dave Martin wrote:
> Stateful CPU architecture extensions may require the signal frame
> to grow to a size that exceeds the arch's MINSIGSTKSZ #define.
> However, changing this #define is an ABI break.
>
> To allow userspace the option of determining the signal frame size
> in a more forwards-compatible way, this patch adds a new auxv entry
> tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame
> size that the process can observe during its lifetime.
>
> If AT_MINSIGSTKSZ is absent from the aux vector, the caller can
> assume that the MINSIGSTKSZ #define is sufficient. This allows for
> a consistent interface with older kernels that do not provide
> AT_MINSIGSTKSZ.
>
> The idea is that libc could expose this via sysconf() or some
> similar mechanism.
>
> There is deliberately no AT_SIGSTKSZ. The kernel knows nothing
> about userspace's own stack overheads and should not pretend to
> know.
[...]
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index fac1c4d..8cf112b 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -121,6 +121,9 @@
>
> #ifndef __ASSEMBLY__
>
> +#include <linux/bug.h>
> +#include <asm/processor.h> /* for signal_minsigstksz, used by ARCH_DLINFO */
> +
> typedef unsigned long elf_greg_t;
>
> #define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))
> @@ -148,6 +151,14 @@ typedef struct user_fpsimd_state elf_fpregset_t;
> do { \
> NEW_AUX_ENT(AT_SYSINFO_EHDR, \
> (elf_addr_t)current->mm->context.vdso); \
> + \
> + /* \
> + * Should always be nonzero unless there's a kernel bug. \
> + * If we haven't determined a sensible value to give to \
> + * userspace, omit the entry: \
> + */ \
> + if (likely(signal_minsigstksz)) \
> + NEW_AUX_ENT(AT_MINSIGSTKSZ, signal_minsigstksz); \
> } while (0)
I think this is the desired behaviour, but now I'm worried that we're forced
to have AT_VECTOR_SIZE_ARCH defined as 2 and, whilst you're correct that the
ELF loader deals with this gracefuly, the FDPIC loader looks a lot less
robust (in particular, my reading is that it decrements the stack pointer
and then pushes these entries in reverse order by overloading NEW_AUX_ENT).
There's also some checkpoint save/restore code in kernel/sys.c that looks
like it could end up with uninitialised stack for the omitted entry.
Can we spit out an AT_IGNORE entry as an else clause if signal_minsigstksz
is zero?
Will
^ permalink raw reply
* v4.17-rc1: regressions on N900, N950
From: Pavel Machek @ 2018-05-29 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524094705.GA16705@amd>
Hi!
> > > still results in working touchscreen, removing any of the three fields
> > > breaks it again.
> >
> > I bisected one regression down, see "omapdrm regression in v4.17-rc series"
> > not sure if it covers all the issues being discussed here though.
>
> Reverting 24aac6011f70 fixes screen on n900 in v4.17-rc for me. (But
> strange dependency on tsc2005 at 0 is still there).
Laurent, your patch looks pretty obvious, but unfortunately breaks
display on Nokia N900.
The patch is pretty big as is, perhaps you have version split to sdi
=> *sdi and then static => dynamic allocation?
Thanks,
Pavel
commit 24aac6011f704d69b5f34514923413f85669f282
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: Tue Feb 13 14:00:47 2018 +0200
drm: omapdrm: sdi: Allocate the sdi private data structure
dynamically
The sdi private data structure is currently stored as a global
variable. While no platform with multiple SDI encoders
currently exists
nor is planned, this doesn't comply with the kernel device
model and
should thus be fixed.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180529/4beb1f9c/attachment.sig>
^ permalink raw reply
* [PATCH v4 5/7] scsi: ipr: Eliminate duplicate barriers on weakly-ordered archs
From: Brian King @ 2018-05-29 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1521514207-10695-6-git-send-email-okaya@codeaurora.org>
On 03/19/2018 09:50 PM, Sinan Kaya wrote:
> Code includes barrier() followed by writel(). writel() already has a
> barrier
> on some architectures like arm64.
>
> This ends up CPU observing two barriers back to back before executing the
> register write.
>
> Since code already has an explicit barrier call, changing writeX() to
> writeX_relaxed().
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/scsi/ipr.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
> index e07dd99..209adac 100644
> --- a/drivers/scsi/ipr.c
> +++ b/drivers/scsi/ipr.c
> @@ -762,9 +762,9 @@ static void ipr_mask_and_clear_interrupts(struct ipr_ioa_cfg *ioa_cfg,
>
> /* Set interrupt mask to stop all new interrupts */
> if (ioa_cfg->sis64)
> - writeq(~0, ioa_cfg->regs.set_interrupt_mask_reg);
> + writeq_relaxed(~0, ioa_cfg->regs.set_interrupt_mask_reg);
> else
> - writel(~0, ioa_cfg->regs.set_interrupt_mask_reg);
> + writel_relaxed(~0, ioa_cfg->regs.set_interrupt_mask_reg);
>
> /* Clear any pending interrupts */
> if (ioa_cfg->sis64)
> @@ -8435,7 +8435,8 @@ static int ipr_reset_enable_ioa(struct ipr_cmnd *ipr_cmd)
> wmb();
> if (ioa_cfg->sis64) {
> /* Set the adapter to the correct endian mode. */
> - writel(IPR_ENDIAN_SWAP_KEY, ioa_cfg->regs.endian_swap_reg);
> + writel_relaxed(IPR_ENDIAN_SWAP_KEY,
> + ioa_cfg->regs.endian_swap_reg);
> int_reg = readl(ioa_cfg->regs.endian_swap_reg);
> }
>
Looks fine to me. Thanks.
Acked-by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* [PATCH v9 00/12] Support PPTT for ARM64
From: Jeremy Linton @ 2018-05-29 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529201623.GA591@arm.com>
On 05/29/2018 03:16 PM, Will Deacon wrote:
> Hi Geert,
>
> On Tue, May 29, 2018 at 05:51:29PM +0200, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>>
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> Damn, sorry for wasting your time. For the record, Catalin's been seeing
> boot failures under KVM on a non-big/LITTLE machine that bisect reliably
> to this patch, but we've also not been able to explain them. Worse, adding
> so much as a printk makes the problem disappear.
I was about to post a patch to remove the numa check if CONFIG_NUMA
disabled. But that seems pointless if the its happening with numa
enabled. So assuming, its the removal of the core from the numa mask
which is causing problems. It looks like numa_clear_node() might cause
similar problems when numa is enabled. In my case the problem I see is
NULL dereference in __bitmap_intersect called from select_task_rq_fair.
That said, I only see the problem when CONFIG_NUMA isn't set.
So, I've also got another work around which caches the numa node to the
cpu_topology and then only builds it when store_cpu_topology() is
called. That should stabilize the numa mask, and assure that the bit
maps are correct when the scheduler requests them.
Do you guys want that patch, or are we looking for a deeper root cause?
^ permalink raw reply
* v4.17-rc1: regressions on N900, N950
From: Sebastian Reichel @ 2018-05-29 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529204517.GA6765@amd>
Hi Pavel,
On Tue, May 29, 2018 at 10:45:17PM +0200, Pavel Machek wrote:
> > > > still results in working touchscreen, removing any of the three fields
> > > > breaks it again.
> > >
> > > I bisected one regression down, see "omapdrm regression in v4.17-rc series"
> > > not sure if it covers all the issues being discussed here though.
> >
> > Reverting 24aac6011f70 fixes screen on n900 in v4.17-rc for me. (But
> > strange dependency on tsc2005 at 0 is still there).
>
> Laurent, your patch looks pretty obvious, but unfortunately breaks
> display on Nokia N900.
>
> The patch is pretty big as is, perhaps you have version split to sdi
> => *sdi and then static => dynamic allocation?
There is a queued fix:
https://github.com/freedesktop/drm-misc/commit/2bc5ff0bdc00d81d719dad74589317a260d583ed
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180529/77c08194/attachment.sig>
^ permalink raw reply
* [PATCH 4/4] arm64: cpufeature: always log KPTI setting on boot
From: Laura Abbott @ 2018-05-29 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524190932.32118-5-mlangsdo@redhat.com>
On 05/24/2018 12:09 PM, Mark Langsdorf wrote:
> Always log KPTI setting at boot time, whether or not KPTI was forced
> by a kernel parameter.
>
> Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
> ---
> arch/arm64/kernel/cpufeature.c | 22 +++++++++++++---------
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 697a6ef..e50bf3c 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -889,16 +889,20 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
> __pti_enabled = __kpti_forced > 0;
> pr_info_once("kernel page table isolation forced %s by %s\n",
> __pti_enabled ? "ON" : "OFF", str);
> + } else {
> + /* Useful for KASLR robustness */
> + if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> + __pti_enabled = true;
> + /* Don't force KPTI for CPUs that are not vulnerable */
> + else if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
> + __pti_enabled = false;
> + /* Defer to CPU feature registers */
> + else
> + __pti_enabled = !has_cpuid_feature(entry, scope);
> +
> + pr_info_once("kernel page table isolation %s by %s\n",
> + __pti_enabled ? "ON" : "OFF", str);
I think this needs an update for the default logged, otherwise it
incorrectly states it was set by command line:
# dmesg | grep isolation
[ 0.000000] CPU features: kernel page table isolation ON by command line option
[ 0.000000] CPU features: detected: Kernel page table isolation (KPTI)
# cat /proc/cmdline
nokaslr slub_debug=- console=ttyAMA0 debug_pagealloc=on earlycon=pl011,0x9000000
> }
> - /* Useful for KASLR robustness */
> - else if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> - __pti_enabled = true;
> - /* Don't force KPTI for CPUs that are not vulnerable */
> - else if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
> - __pti_enabled = false;
> - /* Defer to CPU feature registers */
> - else
> - __pti_enabled = !has_cpuid_feature(entry, scope);
>
> return __pti_enabled;
> }
>
^ permalink raw reply
* [PATCH 0/4] arm64: align KPTI interface with x86
From: Laura Abbott @ 2018-05-29 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524190932.32118-1-mlangsdo@redhat.com>
On 05/24/2018 12:09 PM, Mark Langsdorf wrote:
> ARM64 supports KPTI, but is missing some user interface features such as
> a debugfs entry compared to the x86 implementation.
I don't see an x86 debugfs entry for PTI, only the sysfs files. Was
this something that was discussed bug never merged?
Thanks,
Laura
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Peter Rosin @ 2018-05-29 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529195708.1fa41027@bbrezillon>
Hi again!
I have spent some hours bringing out the old hardware with the 1024x768
panel from underneath the usual piles of junk and layers of dust...and
tried the current kernel on that one. And the display was stable even
when stressing with lots of NAND accesses. *boggle*
Then I remembered that I had lowered the pixel clock (from 71.1 MHz to
65 MHz (and reduced the vertical blanking to maintain the refresh rate).
I didn't notice that this fixed the NAND interference, probably because
I ran NAND without DMA at the time? Anyway, if I reset the pixel clock
to 71.1 MHz (without increasing the vertical blanking, just to be nasty)
I can get the artifacts easily. But running with a pixel clock of 65 MHz
is not a problem at all, so we can consider NAND-DMA with that panel
solved.
However, now we know that this setup needs relatively little to start
working, and that might be good if we want to see if other changes has
any effect. I will look into that tomorrow. And we can also get a grip
on the critical bandwidth.
But first, answers to some random questions...
On 2018-05-29 09:25, Eugen Hristev wrote:
> One more thing: what are the actual nand commands which you use when you
> get the glitches? read/write/erase ... ?
Erase seems to be least sensitive, read or write are worse (and similar)
according to my unscientific observations.
> What happens if you try to minimize the nand access? you also said at
> some point that only *some* nand accesses cause glitches.
These systems will normally not access the NAND, but the displays look
like total crap when this happens. It can happen even when sync()ing
small files, but doesn't happen for every little file. Writing out or
reading a large file to/from NAND invariably triggers the issue.
> Another thing : even if the LCD displays a still image, the DMA still
> feeds data to the LCD right ?
Absolutely. But since we are not playing some large video file (which
could have been stored on the NAND) we typically don't see the problem. It
only turns up in special circumstances. But these circumstances can't be
avoided and the display looks so freaking ugly when it happens...
On 2018-05-29 17:01, Eugen Hristev wrote:
> Then we can then try to force NFC SRAM DMA channels to use just DDR port
> 1 or 2 for memcpy ?
I *think* my "horrid" patch does that. Specifically this line
+ desc->txd.phys = (desc->txd.phys & ~3) | 1;
On 2018-05-28 18:09, Nicolas Ferre wrote:
> Can you try to make all that you can to maximize the blanking period of
> your screen (some are more tolerant than others according to that). By
> doing so, you would allow the LCD FIFO to recover better after each
> line. You might loose some columns on the side of your display but it
> would give us a good idea of how far we are from getting rid of those
> annoying LCD reset glitches (that are due to underruns on LCD FIFO).
I noticed that the 1024x768 panel is using 24bpp, not 16bpp as I
stated previously. Also, the horizontal blanking is 320 pixels, so a
total of 1024+320=1344 pixels/row and a pixel clock of 71.1 Mhz yields
18.9 us/row. The needed data during that time is 1024*24 bits so
1.30 Gbit/s. For the 65 MHz pixel clock, I get 1.19 Gbit/s. Assuming,
of course, that the pixel clock is actually what was requested... What
is the granularity of the pixel clock anyway?
For the bigger 1920x1080 panel, I have a horizontal blanking of 200
pixels and a pixel clock of 144 MHz, so 14.7 us/row -> 2.09 Gbit/s.
I suspect that no amount of fiddling with blanking is going to get
that anyway near the needed ~1.25 Gbit/s. Besides, the specs of the
panel say that the maximum horizontal blanking time is 280 pixels.
Seems futile to even try since this horizontal blanking time is so
much shorter for the larger panel (fewer and faster pixels) and the
longer time wasn't enough for the smaller panel to catch up. But ok,
in combination with something else it might be just enough. Will try
tomorrow...
On 2018-05-28 18:09, Boris Brezillon wrote:
> On Mon, 28 May 2018 17:52:53 +0200 Peter Rosin <peda@axentia.se> wrote:
>> The panels we are using only supports one resolution (each), but the issue
>> is there with both 1920x1080 at 16bpp and 1024x768 at 8bpp (~60Hz).
>
> Duh! This adds to the weirdness of this issue. I'd thought that by
> dividing the required bandwidth by 2 you would get a reliable setup.
I think I might have misremembered seeing the issue with 1024x768 at 8bpp.
Sorry. But it *is* there for (the old variant of) 1024x768 at 24bpp, and
that is still only 60% or so of the bandwidth compared to 1920x1080 at 16bpp.
Cheers,
Peter
^ permalink raw reply
* [PATCH v9 00/12] Support PPTT for ARM64
From: Jeremy Linton @ 2018-05-29 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdU0yET6+-FfS8e9HJdKB7h0gDn7kzWGpJZV=UiWn5fLkA@mail.gmail.com>
Hi,
On 05/29/2018 10:51 AM, Geert Uytterhoeven wrote:
> Hi Will,
>
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>> System supend still works fine on systems with big cores only:
>>>>>>
>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>> R-Car M3-N (2xCA57)
>>>>>>
>>>>>> Reverting this commit fixes the issue for me.
>>>>>
>>>>> I can't find anything that relates to system suspend in these patches
>>>>> unless they are messing with something during CPU hot plug-in back
>>>>> during resume.
>>>>
>>>> It's only the last patch that introduces the breakage.
>>>>
>>>
>>> As specified in the commit log, it won't change any behavior for DT
>>> systems if it's non-NUMA or single node system. So I am still wondering
>>> what could trigger this regression.
>>
>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>> to the scheduler, although I can't see how this would happen.
>>
>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>> do you see anything shouting in dmesg?
>
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.
I suspect most of the problem is related to the node mask changing at
unexpected times (particularly cores being removed from the mask). Once
I understand that more, there may be a simpler patch.
OTOH, I've been testing with this, and with it, I can't seem to
duplicate the problem with CONFIG_NUMA disabled I found.
diff --git a/arch/arm64/include/asm/topology.h
b/arch/arm64/include/asm/topology.h
index df48212f767b..7450ef5ed733 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -12,6 +12,7 @@ struct cpu_topology {
cpumask_t thread_sibling;
cpumask_t core_sibling;
cpumask_t llc_siblings;
+ cpumask_t node_siblings; /* maintain a stable node sibling list */
};
extern struct cpu_topology cpu_topology[NR_CPUS];
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index f3e2e3aec0b0..f4eb80852d78 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -677,8 +677,9 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
init_cpu_topology();
this_cpu = smp_processor_id();
- store_cpu_topology(this_cpu);
numa_store_cpu_info(this_cpu);
+ store_cpu_topology(this_cpu);
+
/*
* If UP is mandated by "nosmp" (which implies "maxcpus=0"),
don't set
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 7415c166281f..6819c764537d 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -215,7 +215,7 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
+ const cpumask_t *core_mask = &cpu_topology[cpu].node_siblings;
/* Find the smaller of NUMA, core or LLC siblings */
if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
@@ -233,12 +233,16 @@ const struct cpumask *cpu_coregroup_mask(int cpu)
static void update_siblings_masks(unsigned int cpuid)
{
struct cpu_topology *cpu_topo, *cpuid_topo = &cpu_topology[cpuid];
+ int node = cpu_to_node(cpuid);
int cpu;
/* update core and thread sibling masks */
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
+ if (cpu_to_node(cpu) == node)
+ cpumask_set_cpu(cpu, &cpu_topo->node_siblings);
+
if (cpuid_topo->llc_id == cpu_topo->llc_id)
cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
@@ -311,6 +315,9 @@ static void __init reset_cpu_topology(void)
cpumask_clear(&cpu_topo->llc_siblings);
cpumask_set_cpu(cpu, &cpu_topo->llc_siblings);
+ cpumask_clear(&cpu_topo->node_siblings);
+ cpumask_set_cpu(cpu, &cpu_topo->node_siblings);
+
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
--
2.14.3
^ permalink raw reply related
* [PATCH 0/6] PAXB INTx support with proper model
From: Ray Jui @ 2018-05-29 21:58 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds PCIe legacy interrupt (INTx) support to the iProc
PCIe driver by modeling it with its own IRQ domain. All 4 interrupts INTA,
INTB, INTC, INTD share the same interrupt line connected to the GIC
in the system. This is now modeled by using its own IRQ domain.
Also update all relevant devicetree files to adapt to the new model
This patch series is available on GIHUB:
repo: https://github.com/Broadcom/arm64-linux.git
branch: pcie-intx-v1
Ray Jui (6):
PCI: iproc: Update iProc PCI binding for INTx support
PCI: iproc: Add INTx support with better modeling
arm: dts: Change PCIe INTx mapping for Cygnus
arm: dts: Change PCIe INTx mapping for NSP
arm: dts: Change PCIe INTx mapping for HR2
arm64: dts: Change PCIe INTx mapping for NS2
.../devicetree/bindings/pci/brcm,iproc-pcie.txt | 31 +++++--
arch/arm/boot/dts/bcm-cygnus.dtsi | 18 +++-
arch/arm/boot/dts/bcm-hr2.dtsi | 18 +++-
arch/arm/boot/dts/bcm-nsp.dtsi | 27 ++++--
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 19 +++--
drivers/pci/host/pcie-iproc-platform.c | 2 +
drivers/pci/host/pcie-iproc.c | 95 +++++++++++++++++++++-
drivers/pci/host/pcie-iproc.h | 6 ++
8 files changed, 188 insertions(+), 28 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 1/6] PCI: iproc: Update iProc PCI binding for INTx support
From: Ray Jui @ 2018-05-29 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-1-git-send-email-ray.jui@broadcom.com>
Update the iProc PCIe binding document for better modeling of the legacy
interrupt (INTx) support
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
.../devicetree/bindings/pci/brcm,iproc-pcie.txt | 31 +++++++++++++++++-----
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
index b8e48b4..7ea24dc 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@ -13,9 +13,6 @@ controller, used in Stingray
PAXB-based root complex is used for external endpoint devices. PAXC-based
root complex is connected to emulated endpoint devices internal to the ASIC
- reg: base address and length of the PCIe controller I/O register space
-- #interrupt-cells: set to <1>
-- interrupt-map-mask and interrupt-map, standard PCI properties to define the
- mapping of the PCIe interface to interrupt numbers
- linux,pci-domain: PCI domain ID. Should be unique for each host controller
- bus-range: PCI bus numbers covered
- #address-cells: set to <3>
@@ -41,6 +38,16 @@ Required:
- brcm,pcie-ob-axi-offset: The offset from the AXI address to the internal
address used by the iProc PCIe core (not the PCIe address)
+Legacy interrupt (INTx) support (optional):
+
+Note INTx is for PAXB only.
+
+- interrupt-controller: claims itself as an interrupt controller for INTx
+- #interrupt-cells: set to <1>
+- interrupt-map-mask and interrupt-map, standard PCI properties to define
+the mapping of the PCIe interface to interrupt numbers
+- interrupts: interrupt line wired to the generic GIC for INTx support
+
MSI support (optional):
For older platforms without MSI integrated in the GIC, iProc PCIe core provides
@@ -77,9 +84,14 @@ Example:
compatible = "brcm,iproc-pcie";
reg = <0x18012000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0 1>,
+ <0 0 0 2 &pcie0 2>,
+ <0 0 0 3 &pcie0 3>,
+ <0 0 0 4 &pcie0 4>;
+ interrupts = <GIC_SPI 100 IRQ_TYPE_NONE>;
linux,pci-domain = <0>;
@@ -115,9 +127,14 @@ Example:
compatible = "brcm,iproc-pcie";
reg = <0x18013000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie1 1>,
+ <0 0 0 2 &pcie1 2>,
+ <0 0 0 3 &pcie1 3>,
+ <0 0 0 4 &pcie1 4>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_NONE>;
linux,pci-domain = <1>;
--
2.1.4
^ permalink raw reply related
* [PATCH 2/6] PCI: iproc: Add INTx support with better modeling
From: Ray Jui @ 2018-05-29 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-1-git-send-email-ray.jui@broadcom.com>
Add PCIe legacy interrupt INTx support to the iProc PCIe driver by
modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC,
INTD share the same interrupt line connected to the GIC in the system,
while the status of each INTx can be obtained through the INTX CSR
register
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
drivers/pci/host/pcie-iproc-platform.c | 2 +
drivers/pci/host/pcie-iproc.c | 95 +++++++++++++++++++++++++++++++++-
drivers/pci/host/pcie-iproc.h | 6 +++
3 files changed, 101 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/host/pcie-iproc-platform.c b/drivers/pci/host/pcie-iproc-platform.c
index e764a2a..7a51e6c 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -70,6 +70,8 @@ static int iproc_pcie_pltfm_probe(struct platform_device *pdev)
}
pcie->base_addr = reg.start;
+ pcie->irq = platform_get_irq(pdev, 0);
+
if (of_property_read_bool(np, "brcm,pcie-ob")) {
u32 val;
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 14f374d..0bd2c14 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -14,6 +14,7 @@
#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/irqchip/arm-gic-v3.h>
+#include <linux/irqchip/chained_irq.h>
#include <linux/platform_device.h>
#include <linux/of_address.h>
#include <linux/of_pci.h>
@@ -264,6 +265,7 @@ enum iproc_pcie_reg {
/* enable INTx */
IPROC_PCIE_INTX_EN,
+ IPROC_PCIE_INTX_CSR,
/* outbound address mapping */
IPROC_PCIE_OARR0,
@@ -305,6 +307,7 @@ static const u16 iproc_pcie_reg_paxb_bcma[] = {
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
[IPROC_PCIE_CFG_DATA] = 0x1fc,
[IPROC_PCIE_INTX_EN] = 0x330,
+ [IPROC_PCIE_INTX_CSR] = 0x334,
[IPROC_PCIE_LINK_STATUS] = 0xf0c,
};
@@ -316,6 +319,7 @@ static const u16 iproc_pcie_reg_paxb[] = {
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
[IPROC_PCIE_CFG_DATA] = 0x1fc,
[IPROC_PCIE_INTX_EN] = 0x330,
+ [IPROC_PCIE_INTX_CSR] = 0x334,
[IPROC_PCIE_OARR0] = 0xd20,
[IPROC_PCIE_OMAP0] = 0xd40,
[IPROC_PCIE_OARR1] = 0xd28,
@@ -332,6 +336,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
[IPROC_PCIE_CFG_DATA] = 0x1fc,
[IPROC_PCIE_INTX_EN] = 0x330,
+ [IPROC_PCIE_INTX_CSR] = 0x334,
[IPROC_PCIE_OARR0] = 0xd20,
[IPROC_PCIE_OMAP0] = 0xd40,
[IPROC_PCIE_OARR1] = 0xd28,
@@ -782,9 +787,90 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie)
return link_is_active ? 0 : -ENODEV;
}
-static void iproc_pcie_enable(struct iproc_pcie *pcie)
+static int iproc_pcie_intx_map(struct irq_domain *domain, unsigned int irq,
+ irq_hw_number_t hwirq)
{
+ irq_set_chip_and_handler(irq, &dummy_irq_chip, handle_simple_irq);
+ irq_set_chip_data(irq, domain->host_data);
+
+ return 0;
+}
+
+static const struct irq_domain_ops intx_domain_ops = {
+ .map = iproc_pcie_intx_map,
+};
+
+static void iproc_pcie_isr(struct irq_desc *desc)
+{
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct iproc_pcie *pcie;
+ struct device *dev;
+ unsigned long status;
+ u32 bit, virq;
+
+ chained_irq_enter(chip, desc);
+ pcie = irq_desc_get_handler_data(desc);
+ dev = pcie->dev;
+
+ /* go through INTx A, B, C, D until all interrupts are handled */
+ while ((status = iproc_pcie_read_reg(pcie, IPROC_PCIE_INTX_CSR) &
+ SYS_RC_INTX_MASK) != 0) {
+ for_each_set_bit(bit, &status, PCI_NUM_INTX) {
+ virq = irq_find_mapping(pcie->irq_domain, bit + 1);
+ if (virq)
+ generic_handle_irq(virq);
+ else
+ dev_err(dev, "unexpected INTx%u\n", bit);
+ }
+ }
+
+ chained_irq_exit(chip, desc);
+}
+
+static int iproc_pcie_intx_enable(struct iproc_pcie *pcie)
+{
+ struct device *dev = pcie->dev;
+ struct device_node *node = dev->of_node;
+ int ret;
+
iproc_pcie_write_reg(pcie, IPROC_PCIE_INTX_EN, SYS_RC_INTX_MASK);
+
+ /*
+ * BCMA devices do not map INTx the same way as platform devices. All
+ * BCMA needs is the above code to enable INTx
+ */
+ if (pcie->irq <= 0)
+ return 0;
+
+ /* set IRQ handler */
+ irq_set_chained_handler_and_data(pcie->irq, iproc_pcie_isr, pcie);
+
+ /* add IRQ domain for INTx */
+ pcie->irq_domain = irq_domain_add_linear(node, PCI_NUM_INTX + 1,
+ &intx_domain_ops, pcie);
+ if (!pcie->irq_domain) {
+ dev_err(dev, "failed to add INTx IRQ domain\n");
+ ret = -ENOMEM;
+ goto err_rm_handler_data;
+ }
+
+ return 0;
+
+err_rm_handler_data:
+ irq_set_chained_handler_and_data(pcie->irq, NULL, NULL);
+
+ return ret;
+}
+
+static void iproc_pcie_intx_disable(struct iproc_pcie *pcie)
+{
+ iproc_pcie_write_reg(pcie, IPROC_PCIE_INTX_EN, 0x0);
+
+ if (pcie->irq <= 0)
+ return;
+
+ irq_domain_remove(pcie->irq_domain);
+ irq_set_chained_handler_and_data(pcie->irq, NULL, NULL);
}
static inline bool iproc_pcie_ob_is_valid(struct iproc_pcie *pcie,
@@ -1410,7 +1496,11 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)
goto err_power_off_phy;
}
- iproc_pcie_enable(pcie);
+ ret = iproc_pcie_intx_enable(pcie);
+ if (ret) {
+ dev_err(dev, "failed to enable INTx\n");
+ goto err_power_off_phy;
+ }
if (IS_ENABLED(CONFIG_PCI_MSI))
if (iproc_pcie_msi_enable(pcie))
@@ -1455,6 +1545,7 @@ int iproc_pcie_remove(struct iproc_pcie *pcie)
pci_remove_root_bus(pcie->root_bus);
iproc_pcie_msi_disable(pcie);
+ iproc_pcie_intx_disable(pcie);
phy_power_off(pcie->phy);
phy_exit(pcie->phy);
diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
index 67081cb..cbcaf9d 100644
--- a/drivers/pci/host/pcie-iproc.h
+++ b/drivers/pci/host/pcie-iproc.h
@@ -72,6 +72,9 @@ struct iproc_msi;
* @ib: inbound mapping related parameters
* @ib_map: outbound mapping region related parameters
*
+ * @irq: interrupt line wired to the generic GIC for INTx
+ * @irq_domain: IRQ domain for INTx
+ *
* @need_msi_steer: indicates additional configuration of the iProc PCIe
* controller is required to steer MSI writes to external interrupt controller
* @msi: MSI data
@@ -99,6 +102,9 @@ struct iproc_pcie {
struct iproc_pcie_ib ib;
const struct iproc_pcie_ib_map *ib_map;
+ int irq;
+ struct irq_domain *irq_domain;
+
bool need_msi_steer;
struct iproc_msi *msi;
};
--
2.1.4
^ permalink raw reply related
* [PATCH 3/6] arm: dts: Change PCIe INTx mapping for Cygnus
From: Ray Jui @ 2018-05-29 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-1-git-send-email-ray.jui@broadcom.com>
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 699fdf9..6de21ef 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -254,9 +254,14 @@
compatible = "brcm,iproc-pcie";
reg = <0x18012000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0 1>,
+ <0 0 0 2 &pcie0 2>,
+ <0 0 0 3 &pcie0 3>,
+ <0 0 0 4 &pcie0 4>;
+ interrupts = <GIC_SPI 100 IRQ_TYPE_NONE>;
linux,pci-domain = <0>;
@@ -289,9 +294,14 @@
compatible = "brcm,iproc-pcie";
reg = <0x18013000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie1 1>,
+ <0 0 0 2 &pcie1 2>,
+ <0 0 0 3 &pcie1 3>,
+ <0 0 0 4 &pcie1 4>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_NONE>;
linux,pci-domain = <1>;
--
2.1.4
^ permalink raw reply related
* [PATCH 4/6] arm: dts: Change PCIe INTx mapping for NSP
From: Ray Jui @ 2018-05-29 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-1-git-send-email-ray.jui@broadcom.com>
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 27 +++++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index dcc55aa..8c4c8b2 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -494,9 +494,14 @@
compatible = "brcm,iproc-pcie";
reg = <0x18012000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 131 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0 1>,
+ <0 0 0 2 &pcie0 2>,
+ <0 0 0 3 &pcie0 3>,
+ <0 0 0 4 &pcie0 4>;
+ interrupts = <GIC_SPI 131 IRQ_TYPE_NONE>;
linux,pci-domain = <0>;
@@ -531,9 +536,14 @@
compatible = "brcm,iproc-pcie";
reg = <0x18013000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 137 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie1 1>,
+ <0 0 0 2 &pcie1 2>,
+ <0 0 0 3 &pcie1 3>,
+ <0 0 0 4 &pcie1 4>;
+ interrupts = <GIC_SPI 137 IRQ_TYPE_NONE>;
linux,pci-domain = <1>;
@@ -568,9 +578,14 @@
compatible = "brcm,iproc-pcie";
reg = <0x18014000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 143 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie2 1>,
+ <0 0 0 2 &pcie2 2>,
+ <0 0 0 3 &pcie2 3>,
+ <0 0 0 4 &pcie2 4>;
+ interrupts = <GIC_SPI 143 IRQ_TYPE_NONE>;
linux,pci-domain = <2>;
--
2.1.4
^ permalink raw reply related
* [PATCH 5/6] arm: dts: Change PCIe INTx mapping for HR2
From: Ray Jui @ 2018-05-29 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-1-git-send-email-ray.jui@broadcom.com>
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm/boot/dts/bcm-hr2.dtsi | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-hr2.dtsi b/arch/arm/boot/dts/bcm-hr2.dtsi
index 3f9cedd..20e3161 100644
--- a/arch/arm/boot/dts/bcm-hr2.dtsi
+++ b/arch/arm/boot/dts/bcm-hr2.dtsi
@@ -298,9 +298,14 @@
compatible = "brcm,iproc-pcie";
reg = <0x18012000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 186 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0 1>,
+ <0 0 0 2 &pcie0 2>,
+ <0 0 0 3 &pcie0 3>,
+ <0 0 0 4 &pcie0 4>;
+ interrupts = <GIC_SPI 186 IRQ_TYPE_NONE>;
linux,pci-domain = <0>;
@@ -334,9 +339,14 @@
compatible = "brcm,iproc-pcie";
reg = <0x18013000 0x1000>;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 192 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie1 1>,
+ <0 0 0 2 &pcie1 2>,
+ <0 0 0 3 &pcie1 3>,
+ <0 0 0 4 &pcie1 4>;
+ interrupts = <GIC_SPI 192 IRQ_TYPE_NONE>;
linux,pci-domain = <1>;
--
2.1.4
^ permalink raw reply related
* [PATCH 6/6] arm64: dts: Change PCIe INTx mapping for NS2
From: Ray Jui @ 2018-05-29 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-1-git-send-email-ray.jui@broadcom.com>
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
index 4a2a6af..0373ebe 100644
--- a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
@@ -116,9 +116,14 @@
reg = <0 0x20020000 0 0x1000>;
dma-coherent;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 281 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0 1>,
+ <0 0 0 2 &pcie0 2>,
+ <0 0 0 3 &pcie0 3>,
+ <0 0 0 4 &pcie0 4>;
+ interrupts = <GIC_SPI 281 IRQ_TYPE_NONE>;
linux,pci-domain = <0>;
@@ -147,9 +152,14 @@
reg = <0 0x50020000 0 0x1000>;
dma-coherent;
+ interrupt-controller;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 305 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie4 1>,
+ <0 0 0 2 &pcie4 2>,
+ <0 0 0 3 &pcie4 3>,
+ <0 0 0 4 &pcie4 4>;
+ interrupts = <GIC_SPI 305 IRQ_TYPE_NONE>;
linux,pci-domain = <4>;
@@ -169,7 +179,6 @@
phys = <&pci_phy1>;
phy-names = "pcie-phy";
-
msi-parent = <&v2m0>;
};
--
2.1.4
^ permalink raw reply related
* Regression in Linux next again
From: Tony Lindgren @ 2018-05-29 22:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Linux next has a regression at least on beaglebone-x15 where
booting Linux hangs shortly after starting init when loading
modules with no output. I bisected it down to commit
456e7cdf3b1a ("regulator: core: Change voltage setting path")
I think I bisected this same issue for the second time now
but for a different merge window. What's up with that?
And then we also have commit 696861761a58 ("regulator: core: Add
voltage balancing mechanism") that fails to compile breaking
git bisect:
drivers/regulator/core.c: In function 'regulator_balance_voltage':
drivers/regulator/core.c:3284:9: error: implicit declaration of
function 'regulator_set_voltage'.
Reverting both patches fixes the issue for me. I could
not debug it further because of the compile error(s).
Regards,
Tony
^ permalink raw reply
* v4.17-rc1: regressions on N900, N950
From: Pavel Machek @ 2018-05-29 22:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529210909.7m4cyhh524xqipju@earth.universe>
On Tue 2018-05-29 23:09:09, Sebastian Reichel wrote:
> Hi Pavel,
>
> On Tue, May 29, 2018 at 10:45:17PM +0200, Pavel Machek wrote:
> > > > > still results in working touchscreen, removing any of the three fields
> > > > > breaks it again.
> > > >
> > > > I bisected one regression down, see "omapdrm regression in v4.17-rc series"
> > > > not sure if it covers all the issues being discussed here though.
> > >
> > > Reverting 24aac6011f70 fixes screen on n900 in v4.17-rc for me. (But
> > > strange dependency on tsc2005 at 0 is still there).
> >
> > Laurent, your patch looks pretty obvious, but unfortunately breaks
> > display on Nokia N900.
> >
> > The patch is pretty big as is, perhaps you have version split to sdi
> > => *sdi and then static => dynamic allocation?
>
> There is a queued fix:
>
> https://github.com/freedesktop/drm-misc/commit/2bc5ff0bdc00d81d719dad74589317a260d583ed
Thanks for the pointer! I hope it makes it in time for v4.17...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/1dd6ade5/attachment.sig>
^ permalink raw reply
* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
From: Frank Rowand @ 2018-05-29 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529173314.GN17671@n2100.armlinux.org.uk>
On 05/29/18 10:33, Russell King - ARM Linux wrote:
> On Tue, May 29, 2018 at 10:05:37AM -0700, Frank Rowand wrote:
>> On 05/22/18 13:01, Rob Herring wrote:
>>> I'll tell you up front, I'm not a fan of FIT image (nor uImage,
>>> Android boot image, $bootloader image). If you want a collection of
>>> files and some configuration data, use a filesystem and a text file.
>
> Me neither.
>
>> My gut feel is that using a filesystem and a text file is the easier way
>> to create the boot info. But that also makes applying the overlay(s)
>> during early Linux boot (at the point of FDT unflattening) impractical
>> (can't access the file system without a driver, the driver depends on
>> the devicetree, the devicetree depends upon the overlay).
>
> Why do you want to apply overlays during the kernel boot? The boot
> loader should be providing the kernel with the merged DT to describe
> the system that the kernel is running on - it's not the kernel's
> job to put that together.
I would much prefer that overlays get applied before the unflattened
devicetree is made available to the kernel instead of applying overlays
late in the boot (after many susbsystems and drivers are initialized)
or after boot.
If overlays are applied before the unflattened devicetree is made
available to the kernel then subsystems and drivers do not have to be
aware of the possibility of the data in the devicetree changing instead
of being invariant. (I will call this "apply early overlays" later in
this email.)
There are use cases of overlays where the overlay is not available until
late in the boot, or after the boot completes. I am not suggesting that
those use cases be ignored. That is a completely different conversation.
If overlays are applied before the unflattened devicetree is made
available to the kernel, there are at least two obvious methods
(and I can think of at least one more) -- either the kernel does it
or the bootloader does it. I do not see either of the two as being
the obvious and only correct choice. If the kernel does it, then
there is no need for multiple bootloaders to implement the same code.
If the bootloaders do it, then there is no need for multiple kernels
(Linux, BSD, etc) to implement the same code. I do not have a
strong opinion about whether the bootloaders or the kernels are a
better place to apply early overlays.
> The whole point of DT is to make the kernel _less_ tied to the hardware
> and more generic. If we're going to introduce an entirely new set of
> drivers into the kernel to "probe" the hardware to determine which
> overlays are required, then that's really defeating the purpose of DT.
If you read my circular dependency sentence carefully, I said a kernel
driver is impractical for the task of getting the overlay. So I agree.
If the kernel applies the overlay, an alternative to drivers is that the
kernel could receive the overlay(s) in a similar manner as the method it
currently receives the base devicetree. (The overlay(s) could be
appended to the base devicetree, a wrapper could be placed around the
base devicetree and the overlay(s), or some other implementation. There
are multiple ways to achieve the same result.)
^ permalink raw reply
* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
From: Russell King - ARM Linux @ 2018-05-29 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a43ce521-ed7f-6126-4ebf-5e0e303d00a3@gmail.com>
On Tue, May 29, 2018 at 03:45:12PM -0700, Frank Rowand wrote:
> If the kernel applies the overlay, an alternative to drivers is that the
> kernel could receive the overlay(s) in a similar manner as the method it
> currently receives the base devicetree. (The overlay(s) could be
> appended to the base devicetree, a wrapper could be placed around the
No wrappers, sorry. We already have too many places in the Linux
kernel and its decompressor that try to work out whether a device
tree or ATAGs are present and how large, and that is done in assembly
code. We don't need more complexity to deal with some kind of
wrapping of device trees as well.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] soc: imx: gpcv2: correct PGC offset
From: Andrey Smirnov @ 2018-05-29 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527580944-10043-1-git-send-email-Anson.Huang@nxp.com>
On Tue, May 29, 2018 at 1:02 AM, Anson Huang <Anson.Huang@nxp.com> wrote:
> Correct MIPI/PCIe/USB_HSIC's PGC offset based on
> design RTL, the value on Reference Manual are incorrect.
>
Nit: I'd s/the value on/the values in the/ here.
> The correct offset should be as below:
>
> 0x800 ~ 0x83F: PGC for core0 of A7 platform;
> 0x840 ~ 0x87F: PGC for core1 of A7 platform;
> 0x880 ~ 0x8BF: PGC for SCU of A7 platform;
> 0xA00 ~ 0xA3F: PGC for fastmix/megamix;
> 0xC00 ~ 0xC3F: PGC for MIPI PHY;
> 0xC40 ~ 0xC7F: PGC for PCIe_PHY;
> 0xC80 ~ 0xCBF: PGC for USB OTG1 PHY;
> 0xCC0 ~ 0xCFF: PGC for USB OTG2 PHY;
> 0xD00 ~ 0xD3F: PGC for USB HSIC PHY;
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> drivers/soc/imx/gpcv2.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> index afc7ecc..132c946 100644
> --- a/drivers/soc/imx/gpcv2.c
> +++ b/drivers/soc/imx/gpcv2.c
> @@ -40,9 +40,9 @@
> #define GPC_M4_PU_PDN_FLG 0x1bc
>
>
> -#define PGC_MIPI 4
> -#define PGC_PCIE 5
> -#define PGC_USB_HSIC 8
> +#define PGC_MIPI 16
> +#define PGC_PCIE 17
> +#define PGC_USB_HSIC 20
As a suggestion, please add a comment explicitly saying that those
values might differ from what some version of the RM might specify.
Explanation in commit message is great, but seeing a note in the code
might save quite a bit of digging for someone who is reading the code,
double checking those values and thinking that they might be wrong.
Other than that:
Acked-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Thanks,
Andrey Smirnov
^ permalink raw reply
* [PATCH] soc: imx: gpcv2: correct PGC offset
From: Andrey Smirnov @ 2018-05-29 23:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0e0690c89b24b4b028e4a0dab63334af4b37fdd3.camel@nxp.com>
On Tue, May 29, 2018 at 7:02 AM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:
> On Tue, 2018-05-29 at 16:02 +0800, Anson Huang wrote:
>> Correct MIPI/PCIe/USB_HSIC's PGC offset based on
>> design RTL, the value on Reference Manual are incorrect.
>>
>> The correct offset should be as below:
>>
>> -#define PGC_MIPI 4
>> -#define PGC_PCIE 5
>> -#define PGC_USB_HSIC 8
>> +#define PGC_MIPI 16
>> +#define PGC_PCIE 17
>> +#define PGC_USB_HSIC 20
>> #define GPC_PGC_CTRL(n) (0x800 + (n) * 0x40)
>> #define GPC_PGC_SR(n) (GPC_PGC_CTRL(n) + 0xc)
>
> This gpcv2 driver is currently only used for PCI, it probably only
> works because domains happen to be turned on by default?
>
That'd be my guess as well. I just tried commenting all of the code
related to GPC_PGC_CTRL in gpcv2 drive and PCIe still worked on my
SabreSD board.
> On imx7d upstream platform suspend is not yet supported but even doing
> device-level suspend causes a hang on resume somewhere in PCI on first
> read. This patch fixes that immediate hang.
>
> After suspend/resume lspci is broken (device doesn't properly resume),
> that probably requires more imx pci patches and unrelated to pgc.
>
Yeah, suspend of any kind was not a part of the use-case for me when I
was working on this driver, so it's not surprising to hear that it
doesn't work very well.
Thanks,
Andrey Smirnov
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the arm tree
From: Stephen Rothwell @ 2018-05-29 23:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in:
arch/arm/include/asm/cputype.h
between commit:
1067a8130b17 ("ARM: add more CPU part numbers for Cortex and Brahma B15 CPUs")
from the arm tree and commits:
9e35ddc962a6 ("ARM: add Broadcom Brahma-B53 main ID definition")
842fa17d6c95 ("ARM: add Broadcom Brahma-B15 main ID definition")
from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/include/asm/cputype.h
index 26021980504d,d1b62ee69f3b..000000000000
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@@ -77,15 -75,11 +75,16 @@@
#define ARM_CPU_PART_CORTEX_A12 0x4100c0d0
#define ARM_CPU_PART_CORTEX_A17 0x4100c0e0
#define ARM_CPU_PART_CORTEX_A15 0x4100c0f0
+#define ARM_CPU_PART_CORTEX_A53 0x4100d030
+#define ARM_CPU_PART_CORTEX_A57 0x4100d070
+#define ARM_CPU_PART_CORTEX_A72 0x4100d080
+#define ARM_CPU_PART_CORTEX_A73 0x4100d090
+#define ARM_CPU_PART_CORTEX_A75 0x4100d0a0
#define ARM_CPU_PART_MASK 0xff00fff0
- /* Broadcom cores */
+ /* Broadcom implemented processors */
#define ARM_CPU_PART_BRAHMA_B15 0x420000f0
+ #define ARM_CPU_PART_BRAHMA_B53 0x42001000
/* DEC implemented cores */
#define ARM_CPU_PART_SA1100 0x4400a110
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/9058fefc/attachment.sig>
^ permalink raw reply
* [RFT v3 1/4] perf cs-etm: Generate branch sample for missed packets
From: Leo Yan @ 2018-05-30 0:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkzEU90aVtPMRqf=YHzee8DHq8JZttRuxjLKGz-gRYiBuw@mail.gmail.com>
Hi Mathieu,
On Tue, May 29, 2018 at 10:04:49AM -0600, Mathieu Poirier wrote:
[...]
> > As now this patch is big with more complex logic, so I consider to
> > split it into small patches:
> >
> > - Define CS_ETM_INVAL_ADDR;
> > - Fix for CS_ETM_TRACE_ON packet;
> > - Fix for exception packet;
> >
> > Does this make sense for you? I have concern that this patch is a
> > fixing patch, so not sure after spliting patches will introduce
> > trouble for applying them for other stable kernels ...
>
> Reverse the order:
>
> - Fix for CS_ETM_TRACE_ON packet;
> - Fix for exception packet;
> - Define CS_ETM_INVAL_ADDR;
>
> But you may not need to - see next comment.
>From the discussion context, I think here 'you may not need to' is
referring to my concern for applying patches on stable kernel, so I
should take this patch series as an enhancement and don't need to
consider much for stable kernel.
On the other hand, your suggestion is possible to mean 'not need
to' split into small patches (though I guess this is misunderstanding
for your meaning).
Could you clarify which is your meaning?
> >> > +
> >> > + /*
> >> > * The packet records the execution range with an exclusive end address
> >> > *
> >> > * A64 instructions are constant size, so the last executed
> >> > @@ -505,6 +519,18 @@ static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet *packet)
> >> > return packet->end_addr - A64_INSTR_SIZE;
> >> > }
> >> >
> >> > +static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
> >> > +{
> >> > + /*
> >> > + * The packet is the CS_ETM_TRACE_ON packet if the start_addr is
> >> > + * magic number 0xdeadbeefdeadbeefUL, returns 0 for this case.
> >> > + */
> >> > + if (packet->start_addr == 0xdeadbeefdeadbeefUL)
> >> > + return 0;
> >>
> >> Same comment as above.
> >
> > Will do this.
> >
> >> > +
> >> > + return packet->start_addr;
> >> > +}
> >> > +
> >> > static inline u64 cs_etm__instr_count(const struct cs_etm_packet *packet)
> >> > {
> >> > /*
> >> > @@ -546,7 +572,7 @@ static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq)
> >> >
> >> > be = &bs->entries[etmq->last_branch_pos];
> >> > be->from = cs_etm__last_executed_instr(etmq->prev_packet);
> >> > - be->to = etmq->packet->start_addr;
> >> > + be->to = cs_etm__first_executed_instr(etmq->packet);
> >> > /* No support for mispredict */
> >> > be->flags.mispred = 0;
> >> > be->flags.predicted = 1;
> >> > @@ -701,7 +727,7 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq)
> >> > sample.ip = cs_etm__last_executed_instr(etmq->prev_packet);
> >> > sample.pid = etmq->pid;
> >> > sample.tid = etmq->tid;
> >> > - sample.addr = etmq->packet->start_addr;
> >> > + sample.addr = cs_etm__first_executed_instr(etmq->packet);
> >> > sample.id = etmq->etm->branches_id;
> >> > sample.stream_id = etmq->etm->branches_id;
> >> > sample.period = 1;
> >> > @@ -897,13 +923,28 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
> >> > etmq->period_instructions = instrs_over;
> >> > }
> >> >
> >> > - if (etm->sample_branches &&
> >> > - etmq->prev_packet &&
> >> > - etmq->prev_packet->sample_type == CS_ETM_RANGE &&
> >> > - etmq->prev_packet->last_instr_taken_branch) {
> >> > - ret = cs_etm__synth_branch_sample(etmq);
> >> > - if (ret)
> >> > - return ret;
> >> > + if (etm->sample_branches && etmq->prev_packet) {
> >> > + bool generate_sample = false;
> >> > +
> >> > + /* Generate sample for start tracing packet */
> >> > + if (etmq->prev_packet->sample_type == 0 ||
> >>
> >> What kind of packet is sample_type == 0 ?
> >
> > Just as explained above, sample_type == 0 is the packet which
> > initialized in the function cs_etm__alloc_queue().
> >
> >> > + etmq->prev_packet->sample_type == CS_ETM_TRACE_ON)
> >> > + generate_sample = true;
> >> > +
> >> > + /* Generate sample for exception packet */
> >> > + if (etmq->prev_packet->exc == true)
> >> > + generate_sample = true;
> >>
> >> Please don't do that. Exception packets have a type of their own and can be
> >> added to the decoder packet queue the same way INST_RANGE and TRACE_ON packets
> >> are. Moreover exception packet containt an address that, if I'm reading the
> >> documenation properly, can be used to keep track of instructions that were
> >> executed between the last address of the previous range packet and the address
> >> executed just before the exception occurred. Mike and Rob will have to confirm
> >> this as the decoder may be doing all that hard work for us.
> >
> > Sure, will wait for Rob and Mike to confirm for this.
> >
> > At my side, I dump the packet, the exception packet isn't passed to
> > cs-etm.c layer, the decoder layer only sets the flag
> > 'packet->exc = true' when exception packet is coming [1].
>
> That's because we didn't need the information. Now that we do a
> function that will insert a packet in the decoder packet queue and
> deal with the new packet type in the main decoder loop [2]. At that
> point your work may not be eligible for stable anymore and I think it
> is fine. Robert's work was an enhancement over mine and yours is an
> enhancement over his.
>
> [2]. https://elixir.bootlin.com/linux/v4.17-rc7/source/tools/perf/util/cs-etm.c#L999
Agree, will look into for exception packet and try to add new packet
type for this.
[...]
Thanks,
Leo Yan
^ permalink raw reply
* [PATCH 2/6] PCI: iproc: Add INTx support with better modeling
From: Andy Shevchenko @ 2018-05-30 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-3-git-send-email-ray.jui@broadcom.com>
On Wed, May 30, 2018 at 12:58 AM, Ray Jui <ray.jui@broadcom.com> wrote:
> Add PCIe legacy interrupt INTx support to the iProc PCIe driver by
> modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC,
> INTD share the same interrupt line connected to the GIC in the system,
> while the status of each INTx can be obtained through the INTX CSR
> register
> + while ((status = iproc_pcie_read_reg(pcie, IPROC_PCIE_INTX_CSR) &
> + SYS_RC_INTX_MASK) != 0) {
> + for_each_set_bit(bit, &status, PCI_NUM_INTX) {
> + virq = irq_find_mapping(pcie->irq_domain, bit + 1);
> + if (virq)
> + generic_handle_irq(virq);
> + else
> + dev_err(dev, "unexpected INTx%u\n", bit);
> + }
> + }
do {
status = ...;
for_each_set_bit() {
...
}
} while (status);
would look slightly better for my opinion.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox