* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Shawn Guo @ 2016-09-20 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474259324.15220.5.camel@buserror.net>
On Sun, Sep 18, 2016 at 11:28:44PM -0500, Scott Wood wrote:
> On Mon, 2016-09-12 at 13:30 +0100, Mark Rutland wrote:
> > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> > >
> > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > > >
> > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > > some cleanup [1,2] that just landed in the arm64 for-next/core branch.
> > > >
> > > > Could you please rebase atop of that?
> > > Well, we should figure out what tree this is going through first. There
> > > are a mixture of arm, arm64, driver and dts changes here and not all
> > > of it is carrying the appropriate acks for me to queue it.
> > Given that mix, I had assumed that this would all go through the arm64
> > tree -- I see that Rob has already acked the binding, and I'm happy to
> > give my ack for the driver once that's in shape.
> >
> > The dts change could go through arm-soc in parallel, I guess. It doesn't
> > look like arm-soc have been Cc'd for that, though.
>
> The arm-soc section of MAINTAINERS says to e-mail linux-arm-kernel, which I
> did. ?There doesn't appear to be a separate arm-soc mailing list, nor is there
> a request to CC Olof/Arnd. ?I did CC Shawn Guo who has been handling the
> device tree patches for these chips.
This is kind of new feature development, and there is no hard dependency
between driver and DTS changes. In this case, we normally pick up the
DTS patch only after driver part get accepted.
Shawn
^ permalink raw reply
* [PATCH v2 1/1] clk: imx53: Add clocks configuration
From: Shawn Guo @ 2016-09-20 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474281002-18868-1-git-send-email-fabien.lahoudere@collabora.co.uk>
On Mon, Sep 19, 2016 at 12:30:00PM +0200, Fabien Lahoudere wrote:
> From: Kalle Kankare <kalle.kankare@vincit.fi>
>
> Add clocks configuration for CSI, FIRI and IEEE1588.
>
> Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
Acked-by: Shawn Guo <shawnguo@kernel.org>
^ permalink raw reply
* [PATCH 2/2] clk: imx6: initialize GPU clocks
From: Shawn Guo @ 2016-09-20 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474276031.31321.0.camel@pengutronix.de>
On Mon, Sep 19, 2016 at 11:07:11AM +0200, Lucas Stach wrote:
> > > diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
> > > index 64c243173395..751c3e7d5843 100644
> > > --- a/drivers/clk/imx/clk-imx6q.c
> > > +++ b/drivers/clk/imx/clk-imx6q.c
> > > @@ -633,6 +633,24 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> > > if (IS_ENABLED(CONFIG_PCI_IMX6))
> > > clk_set_parent(clk[IMX6QDL_CLK_LVDS1_SEL], clk[IMX6QDL_CLK_SATA_REF_100M]);
> > >
> > > + /*
> > > + * Initialize the GPU clock muxes, so that the maximum specified clock
> > > + * rates for the respective SoC are not exceeded.
> > > + */
> > > + if (clk_on_imx6dl()) {
> > > + clk_set_parent(clk[IMX6QDL_CLK_GPU3D_CORE_SEL],
> > > + clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
> > > + clk_set_parent(clk[IMX6QDL_CLK_GPU2D_CORE_SEL],
> > > + clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
> > > + } else if (clk_on_imx6q()) {
> > > + clk_set_parent(clk[IMX6QDL_CLK_GPU3D_CORE_SEL],
> > > + clk[IMX6QDL_CLK_MMDC_CH0_AXI]);
> > > + clk_set_parent(clk[IMX6QDL_CLK_GPU3D_SHADER_SEL],
> > > + clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
> > > + clk_set_parent(clk[IMX6QDL_CLK_GPU2D_CORE_SEL],
> > > + clk[IMX6QDL_CLK_PLL3_USB_OTG]);
> > > + }
> > > +
> >
> > Can we handle these with assigned-clock-parents from device tree?
> >
> No, we want to get rid of the GPU overclocking even with old DTs. DT
> stability rules and all that...
Fair point. For both patches,
Acked-by: Shawn Guo <shawnguo@kernel.org>
^ permalink raw reply
* [RFC] arm64: Ensure proper addressing for ldnp/stnp
From: bdegraaf at codeaurora.org @ 2016-09-20 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c1911e82-e65a-73e4-f878-8e25f609f58b@arm.com>
On 2016-09-20 07:00, Robin Murphy wrote:
> On 19/09/16 19:25, bdegraaf at codeaurora.org wrote:
>> On 2016-09-19 14:01, Robin Murphy wrote:
>>> On 19/09/16 18:36, Brent DeGraaf wrote:
>>>> According to section 6.3.8 of the ARM Programmer's Guide,
>>>> non-temporal
>>>> loads and stores do not verify that address dependency is met
>>>> between a
>>>> load of an address to a register and a subsequent non-temporal load
>>>> or
>>>> store using that address on the executing PE. Therefore, context
>>>> switch
>>>> code and subroutine calls that use non-temporally accessed addresses
>>>> as
>>>> parameters that might depend on a load of an address into an
>>>> argument
>>>> register must ensure that ordering requirements are met by
>>>> introducing
>>>> a barrier prior to the successive non-temporal access. Add
>>>> appropriate
>>>> barriers whereever this specific situation comes into play.
>>>>
>>>> Signed-off-by: Brent DeGraaf <bdegraaf@codeaurora.org>
>>>> ---
>>>> arch/arm64/kernel/entry.S | 1 +
>>>> arch/arm64/lib/copy_page.S | 2 ++
>>>> 2 files changed, 3 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>>>> index 441420c..982c4d3 100644
>>>> --- a/arch/arm64/kernel/entry.S
>>>> +++ b/arch/arm64/kernel/entry.S
>>>> @@ -679,6 +679,7 @@ ENTRY(cpu_switch_to)
>>>> ldp x27, x28, [x8], #16
>>>> ldp x29, x9, [x8], #16
>>>> ldr lr, [x8]
>>>> + dmb nshld // Existence of instructions with loose
>>>> load-use
>>>> dependencies (e.g. ldnp/stnp) make this barrier necessary
>>>> mov sp, x9
>>>> and x9, x9, #~(THREAD_SIZE - 1)
>>>> msr sp_el0, x9
>>>> diff --git a/arch/arm64/lib/copy_page.S b/arch/arm64/lib/copy_page.S
>>>> index 4c1e700..21c6892 100644
>>>> --- a/arch/arm64/lib/copy_page.S
>>>> +++ b/arch/arm64/lib/copy_page.S
>>>> @@ -47,6 +47,8 @@ alternative_endif
>>>> ldp x14, x15, [x1, #96]
>>>> ldp x16, x17, [x1, #112]
>>>>
>>>> + dmb nshld // In case x0 (for stnp) is dependent on a load
>>>
>>> The ARMv8 ARM (B2.7.2 in issue j) says that when an address
>>> dependency
>>> exists between a load and a subsequent LDNP, *other* observers may
>>> observe those accesses in any order. How's that related to an STNP on
>>> the same CPU?
>>>
>>> Robin.
>>>
>>>> +
>>>> mov x18, #(PAGE_SIZE - 128)
>>>> add x1, x1, #128
>>>> 1:
>>>>
>>
>> Yes, I have seen the section in the ARM ARM about this. But the
>> Programmer's Guide goes further, even providing a concrete example:
>>
>> "Non-temporal loads and stores relax the memory ordering
>> requirements...the LDNP instruction might
>> be observed before the preceding LDR instruction, which can result in
>> reading from an unpredictable
>> address in X0.
>>
>> For example:
>> LDR X0, [X3]
>> LDNP X2, X1, [X0]
>> To correct the above, you need an explicit load barrier:
>> LDR X0, [X3]
>> DMB NSHLD
>> LDNP X2, X1, [X0]"
>>
>> Did the ARM ARM leave this out? Or is the Programmer's Guide section
>> incorrect?
>
> If the ARM ARM and the Programmer's Guide don't agree, then the
> Programmer's Guide is wrong (I'll raise a bug against it).
>
> All the ARM ARM says is that in this situation:
>
> P1 P2
> STP x0, x1, [x2] 1: LDR x0, <ptr>
> DMB ISH CBZ x0, 1b
> STR x2, <ptr> LDNP x1, x2, [x0]
>
> P2's address dependency still very much exists from the point of view
> of
> P2's execution, it just may not guarantee order13.2.4 against the DMB
> on P1,
> so P2's LDNP isn't guaranteed to see the data from P1's STP (as opposed
> to how a regular LDP *is*), and may still load older stale data
> instead.
>
> Robin.
>
>>
>> Thanks for your comments,
>> Brent
>>
Thank you Robin. This was concerning to me because the ARM ARM
description
does not explicitly disagree with the Programmer's Guide, it just
doesn't
touch on the PEe ordering. Meanwhile, as you can see from the quote
above,
the Programmer's Guide doesn't talk about PEy, and even includes sample
code
that would only affect PEe ordering (the "nsh" option), leaving PEy
ordering
impacts completely out of the picture, meaning some degree of thought
was
applied toward it.
I went back through older versions of both the ARM ARM last week and the
Guide and the ARM ARM has never mentioned an issue with PEe ordering of
non-temporal accesses, so I am unsure where the Guide could have gotten
its information.
Also, please be aware that this description is in the Programmer's Guide
*twice*, both in section 6.3.8 which I mentioned in the commit text and
is
duplicated in section 13.2.4.
Please keep me posted as to when the Guide will be corrected (or if it
is
discovered to be correct).
Thanks again,
Brent
^ permalink raw reply
* [PATCH] tty: amba-pl011: uart_amba_port is not available with earlycon function
From: Shawn Guo @ 2016-09-20 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474092878-30034-1-git-send-email-shawn.guo@linaro.org>
On Sat, Sep 17, 2016 at 02:14:38PM +0800, Shawn Guo wrote:
> Commit 0e125a5facf8 ("tty: amba-pl011: define flag register bits for ZTE
> device") changes earlycon function pl011_putc() to use a pointer to
> uart_amba_port. This causes a regression when earlycon is enabled,
> because uart_amba_port is not available yet at earlycon time. Let's
> revert the change on pl011_putc() to fix the regression.
>
> The earlycon support for ZTE device can probably be added later by
> declaring a new earlycon setup function with a vendor specific
> compatible.
>
> Reported-by: Sudeep Holla <sudeep.holla@arm.com>
> Fixes: 0e125a5facf8 ("tty: amba-pl011: define flag register bits for ZTE device")
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Hi Sudeep,
Can you please confirm if the patch fixes your problem, so that Greg
knows whether it should be applied? Thanks.
Shawn
^ permalink raw reply
* [PATCH V6 4/5] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Bjorn Helgaas @ 2016-09-20 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d06879a2-d6e9-5d62-77c5-47eff33d9584@semihalf.com>
On Tue, Sep 20, 2016 at 09:06:23AM +0200, Tomasz Nowicki wrote:
> On 19.09.2016 17:45, Bjorn Helgaas wrote:
> >On Fri, Sep 09, 2016 at 09:24:06PM +0200, Tomasz Nowicki wrote:
> >>ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
> >>compliant with ECAM standard. It uses non-standard configuration space
> >>accessors (see pci_thunder_pem_ops) and custom configuration space granulation
> >>(see bus_shift = 24). In order to access configuration space and
> >>probe PEM as ACPI based PCI host controller we need to add MCFG quirk
> >>infrastructure. This involves:
> >>1. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk
> >> code.
> >>2. New quirk entries for each PEM segment. Each contains platform IDs,
> >> mentioned pci_thunder_pem_ops and CFG resources.
> >>
> >>Quirk is considered for ThunderX silicon pass2.x only which is identified
> >>via MCFG revision 1.
> >
> >Is it really the case that silicon pass2.x has MCFG revision 1, and
> >silicon pass1.x has MCFG revision 2? That just seems backwards.
>
> It is weird but silicon pass2.x is more common and it had MCFG
> revision 1 from the beginning. Unless it is allowed to use MCFG
> revision 0 ? Then we could use MCFG revision 0 for pass1.x
There's no reason to avoid revision 0. The question is really what
firmware is already in the field. We need to accommodate that. We don't
want a situation where kernel version X only works with firmware version Y,
but kernel version X+1 only works with firmware version Y+1.
Bjorn
^ permalink raw reply
* ftrace function_graph causes system crash
From: Bean Huo (beanhuo) @ 2016-09-20 13:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi, all
I just use ftrace to do some latency study, found that function_graph can not
Work, as long as enable it, will cause kernel panic. I searched this online.
Found that there are also some cause the same as mine. I am a newer of ftrace.
I want to know who know what root cause? Here is some partial log:
echo function_graph > current_tracer
[ 9.583813] Unable to handle kernel paging request at virtual address b0200083
[ 9.590997] pgd = c0004000
[ 9.593683] [b0200083] *pgd=00000000
[ 9.597253] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 9.602542] Modules linked in:
[ 9.605586] CPU: 1 PID: 15 Comm: kworker/1:0 Not tainted 4.0.0-xilinx-00043-gc701690-dirty #515
[ 9.614256] Hardware name: Xilinx Zynq Platform
[ 9.618793] Workqueue: 0xe3a00001 (\x04 ??)
[ 9.622765] task: df517500 ti: df518000 task.ti: df518000
[ 9.628162] PC is at rb_update_write_stamp+0x18/0xa0
[ 9.633100] LR is at rb_commit+0x34/0xdc
[ 9.637005] pc : [<c00b6674>] lr : [<c00b716c>] psr: 60000093
[ 9.637005] sp : df51a0f0 ip : df40b00c fp : df51a104
[ 9.648456] r10: 00000000 r9 : 00000000 r8 : 00bbff80
[ 9.653666] r7 : c0edcf18 r6 : df51a190 r5 : df404100 r4 : df484680
[ 9.660175] r3 : b020006b r2 : df40b000 r1 : df40b2bc r0 : df484680
[ 9.666687] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 9.674065] Control: 18c5387d Table: 1ee7004a DAC: 00000015
[ 9.679792] Process kworker/1:0 (pid: 15, stack limit = 0xdf518210)
[ 9.686041] Stack: (0xdf51a0f0 to 0xdf51a000)
[ 9.690411] [<c00b6674>] (rb_update_write_stamp) from [<c00b716c>] (rb_commit+0x34/0xdc)
[ 9.698478] [<c00b716c>] (rb_commit) from [<c00b7968>] (ring_buffer_unlock_commit+0x30/0x18c)
[ 9.706987] [<c00b7968>] (ring_buffer_unlock_commit) from [<c00beca4>] (__buffer_unlock_commit+0x20/0x28)
[ 9.716534] [<c00beca4>] (__buffer_unlock_commit) from [<c00ca094>] (__trace_graph_entry+0x94/0xa8)
[ 9.725557] [<c00ca094>] (__trace_graph_entry) from [<c00ca260>] (trace_graph_entry+0x1b8/0x224)
[ 9.734323] [<c00ca260>] (trace_graph_entry) from [<c0020824>] (prepare_ftrace_return+0x70/0xac)
[ 9.743089] [<c0020824>] (prepare_ftrace_return) from [<c0020404>] (ftrace_graph_caller+0x18/0x20)
[ 9.752020] Code: e24cb004 e5903048 e3c1ceff e3cc200f (e5933018)
[ 9.758104] ---[ end trace 5781781938261a54 ]---
[ 9.762689] Kernel panic - not syncing: Fatal exception
[ 10.933397] SMP: failed to stop secondary CPUs
[ 10.937805] ---[ end Kernel panic - not syncing: Fatal exception
[ 10.943779] CPU1: stopping
[ 10.946471] CPU: 1 PID: 15 Comm: kworker/1:0 Tainted: G D 4.0.0-xilinx-00043-gc701690-dirty #515
[ 10.956358] Hardware name: Xilinx Zynq Platform
[ 10.960889] Workqueue: 0xe3a00001 (\x04 ??)
[ 10.964896] [<c0021d64>] (unwind_backtrace) from [<c001c1f4>] (show_stack+0x20/0x24)
[ 10.972620] [<c001c1f4>] (show_stack) from [<c0592250>] (dump_stack+0x80/0xd0)
[ 10.979822] [<c0592250>] (dump_stack) from [<c001efa4>] (ipi_cpu_stop+0x4c/0x80)
[ 10.987197] [<c001efa4>] (ipi_cpu_stop) from [<c001f728>] (handle_IPI+0x74/0xbc)
[ 10.994573] [<c001f728>] (handle_IPI) from [<c0008720>] (gic_handle_irq+0x68/0x70)
[ 11.002123] [<c0008720>] (gic_handle_irq) from [<c001cd84>] (__irq_svc+0x44/0x7c)
[ 11.009569] Exception stack(0xdf519e70 to 0xdf519eb8)
[ 11.014608] 9e60: 00000034 df518000 00000000 c08d9524
[ 11.022770] 9e80: 00000000 00000000 c00317c8 00000000 c00b6674 00000000 00000008 df519edc
[ 11.030929] 9ea0: df519eb8 df519eb8 c058f64c c058f650 60000113 ffffffff
[ 11.037541] [<c001cd84>] (__irq_svc) from [<c058f650>] (panic+0x188/0x20c)
[ 11.044399] [<c058f650>] (panic) from [<c001c578>] (die+0x380/0x3e0)
[ 11.050739] [<c001c578>] (die) from [<c0027c20>] (__do_kernel_fault+0x74/0x94)
[ 11.057941] [<c0027c20>] (__do_kernel_fault) from [<c0027f3c>] (do_page_fault+0x2fc/0x31c)
[ 11.066185] [<c0027f3c>] (do_page_fault) from [<c0028004>] (do_translation_fault+0x2c/0xc0)
^ permalink raw reply
* [PATCH] tty: amba-pl011: uart_amba_port is not available with earlycon function
From: Sudeep Holla @ 2016-09-20 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920130504.GF3744@tiger>
On 20/09/16 14:05, Shawn Guo wrote:
> On Sat, Sep 17, 2016 at 02:14:38PM +0800, Shawn Guo wrote:
>> Commit 0e125a5facf8 ("tty: amba-pl011: define flag register bits for ZTE
>> device") changes earlycon function pl011_putc() to use a pointer to
>> uart_amba_port. This causes a regression when earlycon is enabled,
>> because uart_amba_port is not available yet at earlycon time. Let's
>> revert the change on pl011_putc() to fix the regression.
>>
>> The earlycon support for ZTE device can probably be added later by
>> declaring a new earlycon setup function with a vendor specific
>> compatible.
>>
>> Reported-by: Sudeep Holla <sudeep.holla@arm.com>
>> Fixes: 0e125a5facf8 ("tty: amba-pl011: define flag register bits for ZTE device")
>> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
>
> Hi Sudeep,
>
> Can you please confirm if the patch fixes your problem, so that Greg
> knows whether it should be applied? Thanks.
>
Sorry, since it's basically what I tried first before posting some patch
using private_data, I assumed it will work.
Anyways I have now tested it, so you can add:
Tested-by: Sudeep Holla <sudeep.holla@arm.com>
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] arm64, numa: Add cpu_to_node() implementation.
From: Robert Richter @ 2016-09-20 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E11E52.8060303@linaro.org>
On 20.09.16 19:32:34, Hanjun Guo wrote:
> On 09/20/2016 06:43 PM, Robert Richter wrote:
> >Unfortunately either your nor my code does fix the BUG_ON() I see with
> >the numa kernel:
> >
> > kernel BUG at mm/page_alloc.c:1848!
> >
> >See below for the core dump. It looks like this happens due to moving
> >a mem block where first and last page are mapped to different numa
> >nodes, thus, triggering the BUG_ON().
>
> Didn't triggered it on our NUMA hardware, could you provide your
> config then we can have a try?
Config attached. Other configs with an initrd fail too.
-Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-4.8.0-rc5.vanilla5.xz
Type: application/x-xz
Size: 35316 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160920/8f9a3512/attachment-0001.xz>
^ permalink raw reply
* [PATCH v4 2/5] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
From: Michael Trimarchi @ 2016-09-20 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5B_ahBJr_Tgz_HShmG9heUwCj4K0N3FHhxja1yg0gCUGA@mail.gmail.com>
Hi Fabio
On Wed, Sep 14, 2016 at 8:00 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Wed, Sep 14, 2016 at 2:43 PM, Jagan Teki <jagan@amarulasolutions.com> wrote:
>
>> OK, but where it showed on the processor manual? I only find LDO_2P5
>
> It is not a SoC regulator. It is the regulator that powers the CAN transceiver.
Engicam use fixed regulator always on and on on boot. Their board does
not have any
external pmu. Is this answer to your comment?
Michael
^ permalink raw reply
* [PATCH] tty: amba-pl011: uart_amba_port is not available with earlycon function
From: Shawn Guo @ 2016-09-20 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5f503859-0bf3-e031-450b-2597d93e05ce@arm.com>
On Tue, Sep 20, 2016 at 9:15 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Anyways I have now tested it, so you can add:
> Tested-by: Sudeep Holla <sudeep.holla@arm.com>
Sorry for the regression, and thanks much for the effort of issue
reporting and testing.
Shawn
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Bjorn Helgaas @ 2016-09-20 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <49f53bfc-4421-a8b0-694c-bce7e61e1c9e@semihalf.com>
[+cc Rafael (maybe already cc'd; I didn't recognize rafael at kernel.org, Duc]
On Tue, Sep 20, 2016 at 09:23:21AM +0200, Tomasz Nowicki wrote:
> On 19.09.2016 20:09, Bjorn Helgaas wrote:
> >On Fri, Sep 09, 2016 at 09:24:05PM +0200, Tomasz Nowicki wrote:
> >>thunder-pem driver stands for being ACPI based PCI host controller.
> >>However, there is no standard way to describe its PEM-specific register
> >>ranges in ACPI tables. Thus we add thunder_pem_init() ACPI extension
> >>to obtain hardcoded addresses from static resource array.
> >>Although it is not pretty, it prevents from creating standard mechanism to
> >>handle similar cases in future.
> >>
> >>Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> >>---
> >> drivers/pci/host/pci-thunder-pem.c | 61 ++++++++++++++++++++++++++++++--------
> >> 1 file changed, 48 insertions(+), 13 deletions(-)
> >>
> >>diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
> >>index 6abaf80..b048761 100644
> >>--- a/drivers/pci/host/pci-thunder-pem.c
> >>+++ b/drivers/pci/host/pci-thunder-pem.c
> >>@@ -18,6 +18,7 @@
> >> #include <linux/init.h>
> >> #include <linux/of_address.h>
> >> #include <linux/of_pci.h>
> >>+#include <linux/pci-acpi.h>
> >> #include <linux/pci-ecam.h>
> >> #include <linux/platform_device.h>
> >>
> >>@@ -284,6 +285,40 @@ static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
> >> return pci_generic_config_write(bus, devfn, where, size, val);
> >> }
> >>
> >>+#ifdef CONFIG_ACPI
> >>+static struct resource thunder_pem_reg_res[] = {
> >>+ [4] = DEFINE_RES_MEM(0x87e0c0000000UL, SZ_16M),
> >>+ [5] = DEFINE_RES_MEM(0x87e0c1000000UL, SZ_16M),
> >>+ [6] = DEFINE_RES_MEM(0x87e0c2000000UL, SZ_16M),
> >>+ [7] = DEFINE_RES_MEM(0x87e0c3000000UL, SZ_16M),
> >>+ [8] = DEFINE_RES_MEM(0x87e0c4000000UL, SZ_16M),
> >>+ [9] = DEFINE_RES_MEM(0x87e0c5000000UL, SZ_16M),
> >>+ [14] = DEFINE_RES_MEM(0x97e0c0000000UL, SZ_16M),
> >>+ [15] = DEFINE_RES_MEM(0x97e0c1000000UL, SZ_16M),
> >>+ [16] = DEFINE_RES_MEM(0x97e0c2000000UL, SZ_16M),
> >>+ [17] = DEFINE_RES_MEM(0x97e0c3000000UL, SZ_16M),
> >>+ [18] = DEFINE_RES_MEM(0x97e0c4000000UL, SZ_16M),
> >>+ [19] = DEFINE_RES_MEM(0x97e0c5000000UL, SZ_16M),
> >
> >1) The "correct" way to discover the resources consumed by an ACPI
> > device is to use the _CRS method. I know there are some issues
> > there for bridges (not the fault of ThunderX!) because there's not
> > a good way to distinguish windows from resources consumed directly
> > by the bridge.
> >
> > But we should either do this correctly, or include a comment about
> > why we're doing it wrong, so we don't give the impression that this
> > is the right way to do it.
> >
> > I seem to recall some discussion about why we're doing it this way,
> > but I don't remember the details. It'd be nice to include a
> > summary here.
>
> OK I will. The reason why we cannot use _CRS for this case is that
> CONSUMER flag was not use consistently for the bridge so far.
Yes, I'm aware of that problem, but hard-coding resources into drivers
is just a disaster. The PCI and ACPI cores need generic ways to learn
what resources are consumed by devices. For PCI devices, that's done
with BARs. For ACPI devices, it's done with _CRS. Without generic
resource discovery, we can't manage resources reliably at the system
level [1].
You have a PNP0A03/PNP0A08 device for the PCI host bridge. Because of
the BIOS bugs in CONSUMER flag usage, we assume everything in its _CRS
is a window and not consumed by the bridge itself. What if you added
a companion ACPI device with a _CRS that contained the bridge
resources? Then you'd have some driver ugliness to find that device,
but at least the ACPI core could tell what resources were in use.
Maybe Rafael has a better idea?
Bjorn
[1] I know the ACPI core currently doesn't actually *do* anything with
_CRS. But I think it *should*, and someday it might, so I want to
preserve the principle of using _CRS to document all the resources.
^ permalink raw reply
* [PATCH v5 2/9] drivers: irqchip: Add STM32 external interrupts support
From: Alexandre Torgue @ 2016-09-20 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1609201439440.6905@nanos>
Thomas,
On 09/20/2016 02:44 PM, Thomas Gleixner wrote:
> On Tue, 20 Sep 2016, Alexandre Torgue wrote:
>
>> Thomas,
>>
>> On 09/20/2016 11:51 AM, Thomas Gleixner wrote:
>>> On Tue, 20 Sep 2016, Alexandre Torgue wrote:
>>>>> On 09/14/2016 03:34 PM, Thomas Gleixner wrote:
>>>>>> Well, you just used some function in some context which is not
>>>>>> relevant to
>>>>>> the normal operation. So adding that mask() is just paranoia for no
>>>>>> value.
>>>>>
>>>> A gentle reminder ping...
>>>> If ".free" callback is not relevant then I 'll remove it from exti domain.
>>
>> Sorry for discussing about the same thing again (and again) but I just want to
>> be sure before sending a new version. As you know I have 2 domains: EXTI
>> domain (parent) and stm32-pinctrl-bank domain (child one).
>>
>> There does it make sens to have ".free" callbacks defined in both domain
>> (actually if I define one for the child domain I have to define also ".free"
>> callback for parent domain (EXTI) as it is hierarchical) ?
>> If ".free" have no chance to be called then I will send a new version by
>> removing .free callbacks (in both domain).
>
> Free will be called when a interrupt in the child domain is torn down,
> i.e. when irq_domain_free_irqs() is called. And it will be called for both
> domains like the alloc callback is invoked on both domains via
> irq_domain_alloc_irqs().
Thanks Thomas for this clarification (I'm sure now that we need .free
callbacks).
irq_domain_free_irqs() is called in 2 scenario:
1- when issue occurs in irq_create_fwspec_mapping()
2- when irq_dispose_mapping() is called
Case 2 is the one I tested some times ago. In this case, I need to mask
interrupts in .free callback of EXTI (parent) domain to avoid spurious
interrupts.
Regards
Alex
>
> Thanks,
>
> tglx
>
>
>
>
^ permalink raw reply
* [PATCH] arm64, numa: Add cpu_to_node() implementation.
From: Robert Richter @ 2016-09-20 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E11E52.8060303@linaro.org>
On 20.09.16 19:32:34, Hanjun Guo wrote:
> On 09/20/2016 06:43 PM, Robert Richter wrote:
> >Instead we need to make sure the set_*numa_node() functions are called
> >earlier before secondary cpus are booted. My suggested change for that
> >is this:
> >
> >
> >diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> >index d93d43352504..952365c2f100 100644
> >--- a/arch/arm64/kernel/smp.c
> >+++ b/arch/arm64/kernel/smp.c
> >@@ -204,7 +204,6 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> > static void smp_store_cpu_info(unsigned int cpuid)
> > {
> > store_cpu_topology(cpuid);
> >- numa_store_cpu_info(cpuid);
> > }
> >
> > /*
> >@@ -719,6 +718,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
> > continue;
> >
> > set_cpu_present(cpu, true);
> >+ numa_store_cpu_info(cpu);
> > }
> > }
>
> We tried a similar approach which add numa_store_cpu_info() in
> early_map_cpu_to_node(), and remove it from smp_store_cpu_info,
> but didn't work for us, we will try your approach to see if works.
Calling it in early_map_cpu_to_node() is probably too early since
setup_node_to_cpumask_map() is called in numa_init() afterwards
overwriting it again.
Actually, early_map_cpu_to_node() is used to temporarily store the
mapping until it can be setup in numa_store_cpu_info().
-Robert
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Ard Biesheuvel @ 2016-09-20 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920133327.GB13855@localhost>
On 20 September 2016 at 14:33, Bjorn Helgaas <helgaas@kernel.org> wrote:
> [+cc Rafael (maybe already cc'd; I didn't recognize rafael at kernel.org, Duc]
>
> On Tue, Sep 20, 2016 at 09:23:21AM +0200, Tomasz Nowicki wrote:
>> On 19.09.2016 20:09, Bjorn Helgaas wrote:
>> >On Fri, Sep 09, 2016 at 09:24:05PM +0200, Tomasz Nowicki wrote:
>> >>thunder-pem driver stands for being ACPI based PCI host controller.
>> >>However, there is no standard way to describe its PEM-specific register
>> >>ranges in ACPI tables. Thus we add thunder_pem_init() ACPI extension
>> >>to obtain hardcoded addresses from static resource array.
>> >>Although it is not pretty, it prevents from creating standard mechanism to
>> >>handle similar cases in future.
>> >>
>> >>Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> >>---
>> >> drivers/pci/host/pci-thunder-pem.c | 61 ++++++++++++++++++++++++++++++--------
>> >> 1 file changed, 48 insertions(+), 13 deletions(-)
>> >>
>> >>diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
>> >>index 6abaf80..b048761 100644
>> >>--- a/drivers/pci/host/pci-thunder-pem.c
>> >>+++ b/drivers/pci/host/pci-thunder-pem.c
>> >>@@ -18,6 +18,7 @@
>> >> #include <linux/init.h>
>> >> #include <linux/of_address.h>
>> >> #include <linux/of_pci.h>
>> >>+#include <linux/pci-acpi.h>
>> >> #include <linux/pci-ecam.h>
>> >> #include <linux/platform_device.h>
>> >>
>> >>@@ -284,6 +285,40 @@ static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
>> >> return pci_generic_config_write(bus, devfn, where, size, val);
>> >> }
>> >>
>> >>+#ifdef CONFIG_ACPI
>> >>+static struct resource thunder_pem_reg_res[] = {
>> >>+ [4] = DEFINE_RES_MEM(0x87e0c0000000UL, SZ_16M),
>> >>+ [5] = DEFINE_RES_MEM(0x87e0c1000000UL, SZ_16M),
>> >>+ [6] = DEFINE_RES_MEM(0x87e0c2000000UL, SZ_16M),
>> >>+ [7] = DEFINE_RES_MEM(0x87e0c3000000UL, SZ_16M),
>> >>+ [8] = DEFINE_RES_MEM(0x87e0c4000000UL, SZ_16M),
>> >>+ [9] = DEFINE_RES_MEM(0x87e0c5000000UL, SZ_16M),
>> >>+ [14] = DEFINE_RES_MEM(0x97e0c0000000UL, SZ_16M),
>> >>+ [15] = DEFINE_RES_MEM(0x97e0c1000000UL, SZ_16M),
>> >>+ [16] = DEFINE_RES_MEM(0x97e0c2000000UL, SZ_16M),
>> >>+ [17] = DEFINE_RES_MEM(0x97e0c3000000UL, SZ_16M),
>> >>+ [18] = DEFINE_RES_MEM(0x97e0c4000000UL, SZ_16M),
>> >>+ [19] = DEFINE_RES_MEM(0x97e0c5000000UL, SZ_16M),
>> >
>> >1) The "correct" way to discover the resources consumed by an ACPI
>> > device is to use the _CRS method. I know there are some issues
>> > there for bridges (not the fault of ThunderX!) because there's not
>> > a good way to distinguish windows from resources consumed directly
>> > by the bridge.
>> >
>> > But we should either do this correctly, or include a comment about
>> > why we're doing it wrong, so we don't give the impression that this
>> > is the right way to do it.
>> >
>> > I seem to recall some discussion about why we're doing it this way,
>> > but I don't remember the details. It'd be nice to include a
>> > summary here.
>>
>> OK I will. The reason why we cannot use _CRS for this case is that
>> CONSUMER flag was not use consistently for the bridge so far.
>
> Yes, I'm aware of that problem, but hard-coding resources into drivers
> is just a disaster. The PCI and ACPI cores need generic ways to learn
> what resources are consumed by devices. For PCI devices, that's done
> with BARs. For ACPI devices, it's done with _CRS. Without generic
> resource discovery, we can't manage resources reliably at the system
> level [1].
>
> You have a PNP0A03/PNP0A08 device for the PCI host bridge. Because of
> the BIOS bugs in CONSUMER flag usage, we assume everything in its _CRS
> is a window and not consumed by the bridge itself. What if you added
> a companion ACPI device with a _CRS that contained the bridge
> resources? Then you'd have some driver ugliness to find that device,
> but at least the ACPI core could tell what resources were in use.
>
> Maybe Rafael has a better idea?
>
In the discussions leading up to this, we tried very hard to make this
arm64/acpi quirks mechanism just as flexible as we need it to be to
cover the current crop of incompatible hardware, but not more so.
Going forward, we intend to require all arm64/acpi hardware to be spec
compliant, and so any parametrization beyond what is required for the
currently known broken hardware is only going to make it easier for
others to ship with tweaked ACPI descriptions so that an existing
quirk is triggered for hardware that it was not intended for. It also
implies that we have to deal with the ACPI descriptions as they were
shipped with the current hardware.
That does not mean, of course, that we should use bare constants
rather than symbolic ones, but anything beyond that exceeds the
desired scope of quirks handling.
--
Ard.
^ permalink raw reply
* [PATCH v2 4/6] net: ethernet: bgmac: convert to feature flags
From: Jon Mason @ 2016-09-20 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACna6rymVcKV1h_PEvRuCQrtOd4rsqV34bMWzVOof15fdc8KEA@mail.gmail.com>
On Tue, Sep 20, 2016 at 1:19 AM, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> On 17 August 2016 at 13:34, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>> On 8 July 2016 at 01:08, Jon Mason <jon.mason@broadcom.com> wrote:
>>> mode = (bgmac_read(bgmac, BGMAC_DEV_STATUS) & BGMAC_DS_MM_MASK) >>
>>> BGMAC_DS_MM_SHIFT;
>>> - if (ci->id != BCMA_CHIP_ID_BCM47162 || mode != 0)
>>> + if (bgmac->feature_flags & BGMAC_FEAT_CLKCTLST || mode != 0)
>>> bgmac_set(bgmac, BCMA_CLKCTLST, BCMA_CLKCTLST_FORCEHT);
>>> - if (ci->id == BCMA_CHIP_ID_BCM47162 && mode == 2)
>>> + if (bgmac->feature_flags & BGMAC_FEAT_CLKCTLST && mode == 2)
>>> bcma_chipco_chipctl_maskset(&bgmac->core->bus->drv_cc, 1, ~0,
>>> BGMAC_CHIPCTL_1_RXC_DLL_BYPASS);
>>
>> Jon, it looks to me you translated two following conditions:
>> ci->id != BCMA_CHIP_ID_BCM47162
>> and
>> ci->id == BCMA_CHIP_ID_BCM47162
>> into the same flag check:
>> bgmac->feature_flags & BGMAC_FEAT_CLKCTLST
>>
>> I don't think it's intentional, is it? Do you have a moment to fix this?
>
> Ping
Sorry, just seeing this now. I'll double check the original code and
verify it (or fix it).
Thanks,
Jon
>
> --
> Rafa?
^ permalink raw reply
* [PATCH v5 2/9] drivers: irqchip: Add STM32 external interrupts support
From: Thomas Gleixner @ 2016-09-20 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c2c8ad5f-e679-8522-808f-e940b8c6954d@st.com>
On Tue, 20 Sep 2016, Alexandre Torgue wrote:
> On 09/20/2016 02:44 PM, Thomas Gleixner wrote:
> > Free will be called when a interrupt in the child domain is torn down,
> > i.e. when irq_domain_free_irqs() is called. And it will be called for both
> > domains like the alloc callback is invoked on both domains via
> > irq_domain_alloc_irqs().
>
> Thanks Thomas for this clarification (I'm sure now that we need .free
> callbacks).
> irq_domain_free_irqs() is called in 2 scenario:
> 1- when issue occurs in irq_create_fwspec_mapping()
> 2- when irq_dispose_mapping() is called
>
> Case 2 is the one I tested some times ago. In this case, I need to mask
> interrupts in .free callback of EXTI (parent) domain to avoid spurious
> interrupts.
And why would irq_dispose_mapping() be called on an unmasked, i.e. active,
interrupt? The masking is just papering over that.
Thanks,
tglx
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Bjorn Helgaas @ 2016-09-20 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-AE7fft_j2cqBCN=xrsf5Yh=mePf5x3dZJuKAmdxF-Gg@mail.gmail.com>
Hi Ard,
On Tue, Sep 20, 2016 at 02:40:13PM +0100, Ard Biesheuvel wrote:
> On 20 September 2016 at 14:33, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > [+cc Rafael (maybe already cc'd; I didn't recognize rafael at kernel.org, Duc]
> >
> > On Tue, Sep 20, 2016 at 09:23:21AM +0200, Tomasz Nowicki wrote:
> >> On 19.09.2016 20:09, Bjorn Helgaas wrote:
> >> >On Fri, Sep 09, 2016 at 09:24:05PM +0200, Tomasz Nowicki wrote:
> >> >>thunder-pem driver stands for being ACPI based PCI host controller.
> >> >>However, there is no standard way to describe its PEM-specific register
> >> >>ranges in ACPI tables. Thus we add thunder_pem_init() ACPI extension
> >> >>to obtain hardcoded addresses from static resource array.
> >> >>Although it is not pretty, it prevents from creating standard mechanism to
> >> >>handle similar cases in future.
> >> >>
> >> >>Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> >> >>---
> >> >> drivers/pci/host/pci-thunder-pem.c | 61 ++++++++++++++++++++++++++++++--------
> >> >> 1 file changed, 48 insertions(+), 13 deletions(-)
> >> >>
> >> >>diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
> >> >>index 6abaf80..b048761 100644
> >> >>--- a/drivers/pci/host/pci-thunder-pem.c
> >> >>+++ b/drivers/pci/host/pci-thunder-pem.c
> >> >>@@ -18,6 +18,7 @@
> >> >> #include <linux/init.h>
> >> >> #include <linux/of_address.h>
> >> >> #include <linux/of_pci.h>
> >> >>+#include <linux/pci-acpi.h>
> >> >> #include <linux/pci-ecam.h>
> >> >> #include <linux/platform_device.h>
> >> >>
> >> >>@@ -284,6 +285,40 @@ static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
> >> >> return pci_generic_config_write(bus, devfn, where, size, val);
> >> >> }
> >> >>
> >> >>+#ifdef CONFIG_ACPI
> >> >>+static struct resource thunder_pem_reg_res[] = {
> >> >>+ [4] = DEFINE_RES_MEM(0x87e0c0000000UL, SZ_16M),
> >> >>+ [5] = DEFINE_RES_MEM(0x87e0c1000000UL, SZ_16M),
> >> >>+ [6] = DEFINE_RES_MEM(0x87e0c2000000UL, SZ_16M),
> >> >>+ [7] = DEFINE_RES_MEM(0x87e0c3000000UL, SZ_16M),
> >> >>+ [8] = DEFINE_RES_MEM(0x87e0c4000000UL, SZ_16M),
> >> >>+ [9] = DEFINE_RES_MEM(0x87e0c5000000UL, SZ_16M),
> >> >>+ [14] = DEFINE_RES_MEM(0x97e0c0000000UL, SZ_16M),
> >> >>+ [15] = DEFINE_RES_MEM(0x97e0c1000000UL, SZ_16M),
> >> >>+ [16] = DEFINE_RES_MEM(0x97e0c2000000UL, SZ_16M),
> >> >>+ [17] = DEFINE_RES_MEM(0x97e0c3000000UL, SZ_16M),
> >> >>+ [18] = DEFINE_RES_MEM(0x97e0c4000000UL, SZ_16M),
> >> >>+ [19] = DEFINE_RES_MEM(0x97e0c5000000UL, SZ_16M),
> >> >
> >> >1) The "correct" way to discover the resources consumed by an ACPI
> >> > device is to use the _CRS method. I know there are some issues
> >> > there for bridges (not the fault of ThunderX!) because there's not
> >> > a good way to distinguish windows from resources consumed directly
> >> > by the bridge.
> >> >
> >> > But we should either do this correctly, or include a comment about
> >> > why we're doing it wrong, so we don't give the impression that this
> >> > is the right way to do it.
> >> >
> >> > I seem to recall some discussion about why we're doing it this way,
> >> > but I don't remember the details. It'd be nice to include a
> >> > summary here.
> >>
> >> OK I will. The reason why we cannot use _CRS for this case is that
> >> CONSUMER flag was not use consistently for the bridge so far.
> >
> > Yes, I'm aware of that problem, but hard-coding resources into drivers
> > is just a disaster. The PCI and ACPI cores need generic ways to learn
> > what resources are consumed by devices. For PCI devices, that's done
> > with BARs. For ACPI devices, it's done with _CRS. Without generic
> > resource discovery, we can't manage resources reliably at the system
> > level [1].
> >
> > You have a PNP0A03/PNP0A08 device for the PCI host bridge. Because of
> > the BIOS bugs in CONSUMER flag usage, we assume everything in its _CRS
> > is a window and not consumed by the bridge itself. What if you added
> > a companion ACPI device with a _CRS that contained the bridge
> > resources? Then you'd have some driver ugliness to find that device,
> > but at least the ACPI core could tell what resources were in use.
> >
> > Maybe Rafael has a better idea?
>
> In the discussions leading up to this, we tried very hard to make this
> arm64/acpi quirks mechanism just as flexible as we need it to be to
> cover the current crop of incompatible hardware, but not more so.
> Going forward, we intend to require all arm64/acpi hardware to be spec
> compliant, and so any parametrization beyond what is required for the
> currently known broken hardware is only going to make it easier for
> others to ship with tweaked ACPI descriptions so that an existing
> quirk is triggered for hardware that it was not intended for. It also
> implies that we have to deal with the ACPI descriptions as they were
> shipped with the current hardware.
>
> That does not mean, of course, that we should use bare constants
> rather than symbolic ones, but anything beyond that exceeds the
> desired scope of quirks handling.
Symbolic vs bare constants is the least of my worries. I'm pretty
happy with the current quirk implementation. It's pretty simple and
straightforward.
Apparently you shipped broken firmware that doesn't accurately
describe system resource usage. Presumably that firmware could be
updated, but maybe it's worthwhile to work around it in the kernel,
depending on where it got shipped.
I'd like to step back and come up with some understanding of how
non-broken firmware *should* deal with this issue. Then, if we *do*
work around this particular broken firmware in the kernel, it would be
nice to do it in a way that fits in with that understanding.
For example, if a companion ACPI device is the preferred solution, an
ACPI quirk could fabricate a device with the required resources. That
would address the problem closer to the source and make it more likely
that the rest of the system will work correctly: /proc/iomem could
make sense, things that look at _CRS generically would work (e.g,
/sys/, an admittedly hypothetical "lsacpi", etc.)
Hard-coding stuff in drivers is a point solution that doesn't provide
any guidance for future platforms and makes it likely that the hack
will get copied into even more drivers.
Bjorn
^ permalink raw reply
* [PATCH] gpio: Added zynq specific check for special pins on bank zero
From: Sören Brinkmann @ 2016-09-20 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474360324-8168-1-git-send-email-navam@xilinx.com>
On Tue, 2016-09-20 at 14:02:04 +0530, Nava kishore Manne wrote:
> From: Nava kishore Manne <nava.manne@xilinx.com>
>
> This patch adds zynq specific check for bank 0 pins 7 and 8
> are special and cannot be used as inputs
>
> Signed-off-by: Nava kishore Manne <navam@xilinx.com>
> ---
> drivers/gpio/gpio-zynq.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
> index e72794e..eae9d24 100644
> --- a/drivers/gpio/gpio-zynq.c
> +++ b/drivers/gpio/gpio-zynq.c
> @@ -96,6 +96,10 @@
> /* GPIO upper 16 bit mask */
> #define ZYNQ_GPIO_UPPER_MASK 0xFFFF0000
>
> +/* For GPIO quirks */
> +#define ZYNQ_GPIO BIT(0)
> +#define ZYNQMP_GPIO BIT(1)
I'd make sure all quirks are easily identifiable and call them something
like 'ZYNQ_GPIO_QUIRK_FOO'
Apart from that:
Acked-by: S?ren Brinkmann <soren.brinkmann@xilinx.com>
S?ren
^ permalink raw reply
* ftrace function_graph causes system crash
From: Steven Rostedt @ 2016-09-20 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7d0e88fff8e64591ac31be3adbbf763c@SIWEX5A.sing.micron.com>
On Tue, 20 Sep 2016 13:10:39 +0000
"Bean Huo (beanhuo)" <beanhuo@micron.com> wrote:
> Hi, all
> I just use ftrace to do some latency study, found that function_graph can not
> Work, as long as enable it, will cause kernel panic. I searched this online.
> Found that there are also some cause the same as mine. I am a newer of ftrace.
> I want to know who know what root cause? Here is some partial log:
>
>
Can you do a function bisect to find what function this is.
This script is used to help find functions that are being traced by
function tracer or function graph tracing that causes the machine to
reboot, hang, or crash. Here's the steps to take.
First, determine if function graph is working with a single function:
# cd /sys/kernel/debug/tracing
# echo schedule > set_ftrace_filter
# echo function_graph > current_tracer
If this works, then we know that something is being traced that
shouldn't be.
# echo nop > current_tracer
# cat available_filter_functions > ~/full-file
# ftrace-bisect ~/full-file ~/test-file ~/non-test-file
# cat ~/test-file > set_ftrace_filter
*** Note *** this will take several minutes. Setting multiple functions
is an O(n^2) operation, and we are dealing with thousands of functions.
So go have coffee, talk with your coworkers, read facebook. And
eventually, this operation will end.
# echo function_graph > current_tracer
If it crashes, we know that ~/test-file has a bad function.
Reboot back to test kernel.
# cd /sys/kernel/debug/tracing
# mv ~/test-file ~/full-file
If it didn't crash.
# echo nop > current_tracer
# mv ~/non-test-file ~/full-file
Get rid of the other test file from previous run (or save them off
somewhere.
# rm -f ~/test-file ~/non-test-file
And start again:
# ftrace-bisect ~/full-file ~/test-file ~/non-test-file
The good thing is, because this cuts the number of functions in
~/test-file by half, the cat of it into set_ftrace_filter takes half as
long each iteration, so don't talk so much at the water cooler the
second time.
Eventually, if you did this correctly, you will get down to the problem
function, and all we need to do is to notrace it.
The way to figure out if the problem function is bad, just do:
# echo <problem-function> > set_ftrace_notrace
# echo > set_ftrace_filter
# echo function_graph > current_tracer
And if it doesn't crash, we are done.
-- Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ftrace-bisect
Type: application/octet-stream
Size: 1487 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160920/de1e152c/attachment.obj>
^ permalink raw reply
* [PATCH] arm64, numa: Add cpu_to_node() implementation.
From: Hanjun Guo @ 2016-09-20 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920133813.GR25086@rric.localdomain>
On 09/20/2016 09:38 PM, Robert Richter wrote:
> On 20.09.16 19:32:34, Hanjun Guo wrote:
>> On 09/20/2016 06:43 PM, Robert Richter wrote:
>
>>> Instead we need to make sure the set_*numa_node() functions are called
>>> earlier before secondary cpus are booted. My suggested change for that
>>> is this:
>>>
>>>
>>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>>> index d93d43352504..952365c2f100 100644
>>> --- a/arch/arm64/kernel/smp.c
>>> +++ b/arch/arm64/kernel/smp.c
>>> @@ -204,7 +204,6 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
>>> static void smp_store_cpu_info(unsigned int cpuid)
>>> {
>>> store_cpu_topology(cpuid);
>>> - numa_store_cpu_info(cpuid);
>>> }
>>>
>>> /*
>>> @@ -719,6 +718,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>>> continue;
>>>
>>> set_cpu_present(cpu, true);
>>> + numa_store_cpu_info(cpu);
>>> }
>>> }
>>
>> We tried a similar approach which add numa_store_cpu_info() in
>> early_map_cpu_to_node(), and remove it from smp_store_cpu_info,
>> but didn't work for us, we will try your approach to see if works.
And it works :)
>
> Calling it in early_map_cpu_to_node() is probably too early since
> setup_node_to_cpumask_map() is called in numa_init() afterwards
> overwriting it again.
>
> Actually, early_map_cpu_to_node() is used to temporarily store the
> mapping until it can be setup in numa_store_cpu_info().
Thanks for the clarify, let's wait for David's reply on this one.
Thanks
Hanjun
^ permalink raw reply
* [PATCH 0/2] ARM: Do not mess with CCI if booted from HYP
From: Marc Zyngier @ 2016-09-20 14:13 UTC (permalink / raw)
To: linux-arm-kernel
Some systems (such as the VExpress TC2) are built around a CCI-400,
which is only accessible from secure mode. This obviously breaks if
the system is booted in non-secure mode. Detecting non-secure is
pretty hard to do, unless the system is booted from HYP.
This small patch series makes sure that:
- The CCI ports are not accessed when the kernel is booted from HYP
- MCPM (which depends on CCI) is not enabled on VExpress if booted
from HYP.
This allows a multi_v7_defconfig kernel to be booted on a TC2 booting
from HYP, instead of miserably dying very early on.
Marc Zyngier (2):
ARM: vexpress: Do not enable MCPM if booted from HYP
arm-cci: Do not probe the CCI ports if booted from HYP
arch/arm/mach-vexpress/platsmp.c | 8 ++++++--
drivers/bus/arm-cci.c | 11 +++++++++++
2 files changed, 17 insertions(+), 2 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 1/2] ARM: vexpress: Do not enable MCPM if booted from HYP
From: Marc Zyngier @ 2016-09-20 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474380833-30121-1-git-send-email-marc.zyngier@arm.com>
Using MCPM implies being able to tweak the CCI at runtime, which
is impossible to do when running non-secure. Since HYP implies
running non-secure, let's not enable MCPM in that case.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/mach-vexpress/platsmp.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
index 8b8d072..09819f1 100644
--- a/arch/arm/mach-vexpress/platsmp.c
+++ b/arch/arm/mach-vexpress/platsmp.c
@@ -17,6 +17,7 @@
#include <asm/mcpm.h>
#include <asm/smp_scu.h>
+#include <asm/virt.h>
#include <asm/mach/map.h>
#include <plat/platsmp.h>
@@ -29,11 +30,14 @@ bool __init vexpress_smp_init_ops(void)
/*
* The best way to detect a multi-cluster configuration at the moment
* is to look for the presence of a CCI in the system.
- * Override the default vexpress_smp_ops if so.
+ * Override the default vexpress_smp_ops if so, but only if
+ * the kernel is not booted from HYP mode (which indicates
+ * that we're running in non-secure mode, where the CCI is not
+ * accessible).
*/
struct device_node *node;
node = of_find_compatible_node(NULL, NULL, "arm,cci-400");
- if (node && of_device_is_available(node)) {
+ if (node && of_device_is_available(node) && !is_hyp_mode_available()) {
mcpm_smp_set_ops();
return true;
}
--
2.1.4
^ permalink raw reply related
* [PATCH 2/2] arm-cci: Do not probe the CCI ports if booted from HYP
From: Marc Zyngier @ 2016-09-20 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474380833-30121-1-git-send-email-marc.zyngier@arm.com>
Poking the CCI ports from non-secure is likely to end up in fireworks,
so let's not try our luck here, and skip the driver initialization
if booted from HYP (which is always non-secure).
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/bus/arm-cci.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index ffa7c9d..70f51a9 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -28,6 +28,7 @@
#include <asm/cacheflush.h>
#include <asm/smp_plat.h>
+#include <asm/virt.h>
static void __iomem *cci_ctrl_base;
static unsigned long cci_ctrl_phys;
@@ -2184,6 +2185,16 @@ static int cci_probe_ports(struct device_node *np)
const char *match_str;
bool is_ace;
+ /*
+ * If we booted in HYP mode, then we're running non-secure,
+ * and there is zero chance that we'll be able to configure
+ * anything on the CCI. Gracefully leave the room...
+ */
+ if (is_hyp_mode_available()) {
+ pr_info("%s: skipping probe (running non-secure)\n",
+ np->full_name);
+ return -ENODEV;
+ }
cci_config = of_match_node(arm_cci_matches, np)->data;
if (!cci_config)
--
2.1.4
^ permalink raw reply related
* [PATCH v2 1/2] Documentation: dt: add bindings for ti-cpufreq
From: Dave Gerlach @ 2016-09-20 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919211400.GA4276@rob-hp-laptop>
Rob,
On 09/19/2016 04:14 PM, Rob Herring wrote:
> On Wed, Aug 31, 2016 at 09:53:27PM -0500, Dave Gerlach wrote:
>> Add the device tree bindings document for the TI CPUFreq/OPP driver
>> on AM33xx, AM43xx, DRA7, and AM57 SoCs. The operating-points-v2 binding
>> allows us to provide an opp-supported-hw property for each OPP to define
>> when it is available. This driver is responsible for reading and parsing
>> registers to determine which OPPs can be selectively enabled based
>> on the specific SoC in use by matching against the opp-supported-hw
>> data.
>
> Sorry, for the delay. Missed this somehow.
>
>>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> ---
>> v1->v2:
>> - Dropped all driver/linux specific documentation
>> - Fixed some typos
>> - Add new compatibles for each SoC family to match against
>> - Switched to use am335x example to better demonstrate field one of
>> opp-supported-hw.
>>
>> .../devicetree/bindings/cpufreq/ti-cpufreq.txt | 130 +++++++++++++++++++++
>> 1 file changed, 130 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>> new file mode 100644
>> index 000000000000..6276ae494121
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>> @@ -0,0 +1,130 @@
>> +TI CPUFreq and OPP bindings
>> +================================
>> +
>> +Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
>> +families support different OPPs depending on the silicon variant in use.
>> +The ti_cpufreq driver can use revision and an efuse value from the SoC to
>> +provide the OPP framework with supported hardware information. This is
>> +used to determine which OPPs from the operating-points-v2 table get enabled
>> +when it is parsed by the OPP framework.
>> +
>> +Required properties:
>> +--------------------
>> +In 'cpus' nodes:
>> +- operating-points-v2: Phandle to the operating-points-v2 table to use.
>> +- ti,syscon-efuse: Syscon phandle, offset to efuse register, efuse register
>> + mask, and efuse register shift to get the relevant bits
>> + that describe OPP availability.
>> +- ti,syscon-rev: Syscon and offset used to look up revision value on SoC.
>
> These have nothing to do with a cpu, so they don't belong here. Maybe
> the first is a property of an OPP table, but the second certainly is
> not.
Yes, I have no issue with this and will move the ti properties into the
operating points table for v3 of the series.
>
>> +
>> +In 'operating-points-v2' table:
>> +- compatible: Should be
>> + - 'operating-points-v2-ti-am3352-cpu' for am335x SoCs
>> + - 'operating-points-v2-ti-am4372-cpu' for am43xx SoCs
>> + - 'operating-points-v2-ti-dra7-cpu' for dra7xx/am57xx SoCs
>> +
>> +- opp-supported-hw: Two bitfields indicating:
>> + 1. Which revision of the SoC the OPP is supported by
>> + 2. Which eFuse bits indicate this OPP is available
>
> I tend to think you should handle this with kernel code (bootloader
> really) fixing up the OPP table as necessary rather than putting in DT.
>
The operating-points-v2 binding here [1] was designed with doing this in
mind, and others are using it and the corresponding functionality
offered by the OPP core to selectively enable OPPs. Why hide this in
u-boot when we already have kernel framework support to do it?
Thanks for your comments, will send v3 moving the appropriate properties
into the OPP table.
Regards,
Dave
[1] Documentation/devicetree/bindings/opp/opp.txt
> Rob
>
^ 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