* Re: [PATCH 0/2] meson: Fix IRQ trigger type
From: Emiliano Ingrassia @ 2018-12-06 15:52 UTC (permalink / raw)
To: Carlo Caione, Martin Blumenstingl
Cc: mark.rutland, devicetree, khilman, robh+dt, linux-amlogic,
linux-arm-kernel
In-Reply-To: <85973a9cd43c677ffa5c80853e86d79f36a9eb3a.camel@baylibre.com>
Hi Carlo,
thanks for the answer.
On Thu, Dec 06, 2018 at 01:17:58PM +0000, Carlo Caione wrote:
> On Thu, 2018-12-06 at 13:43 +0100, Emiliano Ingrassia wrote:
> > Hi all,
>
> Hi Emiliano,
>
> > thank you for involving me.
> >
> > I applied Carlo's patches[0] on a kernel vanilla 4.19.6
> > and tested it with kernel packet generator, monitoring
> > bandwidth usage with "nload".
> >
> > All tests were conducted on an Odroid-C1+ Rev. 0.4-20150930 board
> > with a short ethernet cable directly attached to a laptop with
> > 1G ethernet interface, with "nload" running on the board.
> >
> > The tests I performed are composed by the following steps:
> >
> > 1) Start packet generator with "rate 1000M" on laptop;
> >
> > 2) Keep packet generator active on the laptop and
> > start the packet generator on the board with "rate 1000M";
> >
> > 3) Stop both packet generators;
> >
> > 4) Start packet generator on the board;
> >
> > 5) Keep packet generator active on the board and
> > start the packet generator on the laptop.
>
> out of curiosity: why do you expect to see something different from
> point (2)?
>
I did not expect it indeed, I tried and got different results.
> > Test results without Carlo's patches applied:
> >
> > 1) "nload" shows an incoming traffic of ~950Mbps;
> >
> > 2) "nload" shows an incoming traffic of ~400Mbps
> > and an outgoing traffic of ~250Mbps;
> >
> > 3) "nload" shows 0Mbps both for incoming and outgoing traffic;
> >
> > 4) "nload" shows an outgoing traffic of ~950Mbps from the board;
> >
> > 5) "nload" shows incoming traffic of 0Mbps
> > and an outgoing traffic of ~950Mbps.
> >
> > Applying only the first patch (change mac IRQ type) I got the same
> > results.
>
> This is expected. The change in the IRQ type is solving an issue that
> you can see if the run a stress test involving multiple components for
> several hours.
>
OK, did you use "stress-ng" tool for tests?
> > Applying only the second patch (drop eee-broken-1000t) I got the same
> > results!
>
> I am a bit confused here. Wasn't the eee-broken-1000t added to fix a
> problem with the ethernet? Are you suggesting that for some reason you
> cannot reproduce anymore the problem for which the quirk was
> introduced?
>
Problems without the "eee-broken-1000t" flags were experimented
one and a half years ago on a Amlogic development kernel from [0],
probably a 4.14 version.
Many patches about Meson8b SoC, dwmac-meson8b and dwmac driver
were introduced so yes, the "eee-broken-1000t" was added
to fix a problem with the ethernet (one and a half years ago),
but new tests are needed to say if it still necessary.
> > With both patches applied I got the same results but with an incoming
> > traffic
> > of ~3Mbps on the board.
>
> On all the tests and immediately from the start of the tests?
>
Yes, in all the 5 steps immediately from the start.
I also tried to execute "nload" on both sides to see the bandwidth
usage.
With bot patches applied, after starting kernel packet generator
on my laptop with 1Gbps rate, "nload" on the laptop side shows me
an outgoing traffic of ~940Mbps while "nload" on the board side shows
me an incoming traffic of ~3Mbps.
Also consider that a pinging test from my laptop to the board shows
a packet loss of about 90%.
> When you hit the problem con you check in /proc/interrupts if you see
> the IRQ counter for the eth0 incrementing or not?
>
The eth0 IRQ counter is incremented during the test.
> Cheers,
>
> --
> Carlo Caione
>
>
I would like to conduct other tests with iperf3 to be sure about
the obtained results. What do you think?
Should I apply your patches on the latest Amlogic development kernel?
Regards,
Emiliano
[0] https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: dmapool regression in next
From: Robin Murphy @ 2018-12-06 15:51 UTC (permalink / raw)
To: Tony Battersby, Krzysztof Kozlowski, tony
Cc: Stephen Rothwell, john.garry, linux, linux-kernel,
andy.shevchenko, akpm, linux-omap, hch, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <09e73d24-467a-52bb-0433-a9596d4d6f02@cybernetics.com>
On 06/12/2018 15:11, Tony Battersby wrote:
> On 12/6/18 4:25 AM, Krzysztof Kozlowski wrote:
>> On Thu, 6 Dec 2018 at 02:31, Tony Lindgren <tony@atomide.com> wrote:
>>> Hi,
>>>
>>> Looks like with commit 26abe88e830d ("mm/dmapool.c: improve scalability
>>> of dma_pool_free()") I'm now getting spammed with lots of "(bad vaddr)"
>>> on at least omap4 pandaboard, see below.
>>>
>>> Any ideas what might be going wrong?
>>>
>>> Regards,
>>>
>>> Tony
>>>
>>> 8< ---------------------
>>> omap-dma-engine 4a056000.dma-controller: dma_pool_free 4a056000.dma-controller, (ptrval) (bad vaddr)/0xbe800000
>>> omap-dma-engine 4a056000.dma-controller: dma_pool_free 4a056000.dma-controller, (ptrval) (bad vaddr)/0xbe80001c
>>> omap-dma-engine 4a056000.dma-controller: dma_pool_free 4a056000.dma-controller, (ptrval) (bad vaddr)/0xbe800038
>>> ...
>> I see it as well on all my Exynos boards, since yesterday's next. In
>> my case it is the USB EHCI driver:
>> exynos-ehci 12110000.usb: dma_pool_free ehci_qtd, (ptrval) (bad
>> vaddr)/0xb8844180
>> Full log here:
>> https://krzk.eu/#/builders/1/builds/2937/steps/12/logs/serial0
>>
>> Best regards,
>> Krzysztof
>>
> Here is the prototype:
>
> void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t dma);
>
> With the old code, the 'dma' value had to be correct for use with
> pool_find_page(), or else you would get an error. If the 'vaddr' value
> was incorrect, it would corrupt the dmapool freelist, but you wouldn't
> get an error unless DMAPOOL_DEBUG was enabled.
>
> With my patch applied, 'vaddr' has to be correct for virt_to_page(). My
> code also checks that 'dma' is consistent with 'vaddr' even if
> DMAPOOL_DEBUG is disabled, since the check is fast and it will prevent
> problems like this in the future.
Unfortunately that logic has a fatal flaw - DMA pools are backed by
dma_alloc_coherent(), and there is absolutely no guarantee that the
memory dma_alloc_coherent() returns is backed by a struct page at all.
Even if it is, there is still absolutely no guarantee that the vaddr
value it returns is valid for virt_to_page() - on many systems it will
be in vmalloc or some architecture-specific region of address space.
The problem is not that these drivers are buggy (they're not - the arch
code is returning a vmalloc()ed non-cacheable remap in the first place),
it's that 26abe88e830d is fundamentally unworkable and needs reverting.
Apparently the original patches managed not to catch my eye as something
I needed to review, sorry about that :(
Robin.
>
> So if a buggy driver passes in a good value for 'dma' but a bad value
> for 'vaddr', then it may have appeared to work previously (but with
> possible data corruption, depending on the circumstances), but my patch
> will expose the problem. You can confirm by reverting my dmapool
> patches and enabling DMAPOOL_DEBUG, which is at the top of mm/dmapool.c:
>
> #if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_SLUB_DEBUG_ON)
> #define DMAPOOL_DEBUG 1
> #endif
>
> Tony Battersby
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] PCI: controller: dwc: Make PCI_IMX6 depend on PCIEPORTBUS
From: Lucas Stach @ 2018-12-06 15:50 UTC (permalink / raw)
To: Robert Hancock, Baruch Siach, Andrey Smirnov
Cc: A.s. Dong, Richard Zhu, linux-pci, linux-kernel, linux-imx,
bhelgaas, Leonard Crestez, cphealy, linux-arm-kernel,
Trent Piepho
In-Reply-To: <5a3543f2-fe58-221d-694f-0f98a643edfc@sedsystems.ca>
Am Donnerstag, den 06.12.2018, 09:45 -0600 schrieb Robert Hancock:
> On 2018-12-06 2:10 a.m., Baruch Siach wrote:
> > Hi Andrey,
> >
> > Adding Robert Hancock who reported[1] on a PCIe MSI issue with i.MX6.
> >
> > Andrey Smirnov writes:
> >
> > > Building a kernel with CONFIG_PCI_IMX6=y, but CONFIG_PCIEPORTBUS=n
> > > produces a system where built-in PCIE bridge (16c3:abcd) isn't bound
> > > to pcieport driver. This, in turn, results in a PCIE bus that is
> > > capable of enumerating attached PCIE device, but lacks functional
> > > interrupt support.
> >
> > Robert, does that fix your issue?
>
> Unfortunately, no.. in fact the situation on my setup is even worse with
> CONFIG_PCIEPORTBUS enabled: Not only does MSI still not function, but
> now INTx interrupts are somehow broken as well - no interrupts are
> received. The IRQ information shown in /proc/interrupts is correct, but
> the count remains stubbornly at 0.
That's expected. The port services will use an MSI IRQ when available
and due to a design issue with the DWC PCIe it will not forward any
legacy IRQs if any MSI is in use. If any of the PCIe devices in your
system are unable to work with MSI IRQs, you must boot with "nomsi" on
the kernel command line set.
Regards,
Lucas
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/4] iio: adc: add STMPE ADC devicetree bindings
From: Philippe Schenker @ 2018-12-06 15:49 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Mark Rutland, devicetree, Dmitry Torokhov, Alexandre Torgue,
marcel.ziswiler, Peter Meerwald-Stadler, linux-input,
linux-kernel, stefan, linux-iio, Rob Herring, linux-arm-kernel,
Max Krummenacher, Hartmut Knaack, Lee Jones, linux-stm32,
Maxime Coquelin, Lars-Peter Clausen
In-Reply-To: <20181125100413.73bc729f@archlinux>
On Sun, 2018-11-25 at 10:04 +0000, Jonathan Cameron wrote:
> On Fri, 23 Nov 2018 15:24:10 +0100
> Philippe Schenker <dev@pschenker.ch> wrote:
>
> > From: Stefan Agner <stefan@agner.ch>
> >
> > This adds the devicetree bindings for the STMPE ADC.
> >
> > Signed-off-by: Stefan Agner <stefan@agner.ch>
> > Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
> > Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> Clearly this will need review from input and mfd.
>
> I've suggested inline that you split the realignment out to a
> separate patch for reviewability reasons.
Thank you again Jonathan for your feedback, and of course also all the others!
I will split it much more so everything will be much more readable in v4. You
suggested again, to use the naming 'adc {'. I know that this is standard naming,
but unfortunately, this naming is given by drivers/mfd/stmpe.c (line 1311).
What do you suggest to do? break the naming scheme in mfd, or just use
'stmpe_adc {' ?
>
> > ---
> >
> > Changes in v3:
> > - Reformatted documentation for touchscreen to use tabs and have a better
> > overview of the settings.
> > - Added note which adc-settings will take precedence.
> > - changed typo in sample-time setting from 144 clocks to 124 clocks, as
> > stated
> > in the datasheet.
> >
> > Changes in v2:
> > - Moved the bindings for ADC to the overlying mfd.
> > - Reformatted for better readability
> >
> > .../devicetree/bindings/iio/adc/stmpe-adc.txt | 21 +++++++
> > .../bindings/input/touchscreen/stmpe.txt | 60 ++++++++++++-------
> > .../devicetree/bindings/mfd/stmpe.txt | 28 ++++++---
> > 3 files changed, 80 insertions(+), 29 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> >
> > diff --git a/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> > b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> > new file mode 100644
> > index 000000000000..480e66422625
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> > @@ -0,0 +1,21 @@
> > +STMPE ADC driver
> > +----------------
> > +
> > +Required properties:
> > + - compatible: "st,stmpe-adc"
> > +
> > +Optional properties:
> > +Note that the ADC is shared with the STMPE touchscreen. ADC related
> > settings
> > +have to be done in the mfd.
> > +- st,norequest-mask: bitmask specifying which ADC channels should _not_ be
> > + requestable due to different usage (e.g. touch)
> > +
> > +Node name must be stmpe_adc and should be child node of stmpe node to
> > +which it belongs.
> > +
> > +Example:
> > +
> > + stmpe_adc {
>
> Can we use adc { here to match standard naming?
>
> > + compatible = "st,stmpe-adc";
> > + st,norequest-mask = <0x0F>; /* dont use ADC CH3-0 */
> > + };
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> > b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> > index 127baa31a77a..414586513a02 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> > @@ -5,36 +5,52 @@ Required properties:
> > - compatible: "st,stmpe-ts"
> >
> > Optional properties:
> > -- st,sample-time: ADC converstion time in number of clock. (0 -> 36
> > clocks, 1 ->
> > - 44 clocks, 2 -> 56 clocks, 3 -> 64 clocks, 4 -> 80 clocks, 5 -> 96
> > clocks, 6
> > - -> 144 clocks), recommended is 4.
> > -- st,mod-12b: ADC Bit mode (0 -> 10bit ADC, 1 -> 12bit ADC)
> > -- st,ref-sel: ADC reference source (0 -> internal reference, 1 -> external
> > - reference)
> > -- st,adc-freq: ADC Clock speed (0 -> 1.625 MHz, 1 -> 3.25 MHz, 2 || 3 ->
> > 6.5 MHz)
> > -- st,ave-ctrl: Sample average control (0 -> 1 sample, 1 -> 2 samples, 2 ->
> > 4
> > - samples, 3 -> 8 samples)
> > -- st,touch-det-delay: Touch detect interrupt delay (0 -> 10 us, 1 -> 50 us,
> > 2 ->
> > - 100 us, 3 -> 500 us, 4-> 1 ms, 5 -> 5 ms, 6 -> 10 ms, 7 -> 50 ms)
> > recommended
> > - is 3
> > -- st,settling: Panel driver settling time (0 -> 10 us, 1 -> 100 us, 2 ->
> > 500 us, 3
> > - -> 1 ms, 4 -> 5 ms, 5 -> 10 ms, 6 for 50 ms, 7 -> 100 ms) recommended is
> > 2
> > -- st,fraction-z: Length of the fractional part in z (fraction-z ([0..7]) =
> > Count of
> > - the fractional part) recommended is 7
> > -- st,i-drive: current limit value of the touchscreen drivers (0 -> 20 mA
> > typical 35
> > - mA max, 1 -> 50 mA typical 80 mA max)
> > +- st,ave-ctrl : Sample average control
> > + 0 -> 1 sample
> > + 1 -> 2 samples
> > + 2 -> 4 samples
> > + 3 -> 8 samples
> > +- st,touch-det-delay : Touch detect interrupt delay (recommended is
> > 3)
> > + 0 -> 10 us 5 -> 5 ms
> > + 1 -> 50 us 6 -> 10 ms
> > + 2 -> 100 us 7 -> 50 ms
> > + 3 -> 500 us
> > + 4-> 1 ms
> > +- st,settling : Panel driver settling time (recommended is 2)
> > + 0 -> 10 us 5 -> 10 ms
> > + 1 -> 100 us 6 for 50 ms
> > + 2 -> 500 us 7 -> 100 ms
> > + 3 -> 1 ms
> > + 4 -> 5 ms
> > +- st,fraction-z : Length of the fractional part in z
> > (recommended is 7)
> > + (fraction-z ([0..7]) = Count of the fractional part)
> > +- st,i-drive : current limit value of the touchscreen drivers
> > + 0 -> 20 mA (typical 35mA max)
> > + 1 -> 50 mA (typical 80 mA max)
> > +
> > +Optional properties common with MFD (deprecated):
> > + - st,sample-time : ADC conversion time in number of clock.
> > + 0 -> 36 clocks 4 -> 80 clocks
> > (recommended)
> > + 1 -> 44 clocks 5 -> 96 clocks
> > + 2 -> 56 clocks 6 -> 124 clocks
> > + 3 -> 64 clocks
> > + - st,mod-12b : ADC Bit mode
> > + 0 -> 10bit ADC 1 -> 12bit ADC
> > + - st,ref-sel : ADC reference source
> > + 0 -> internal 1 -> external
> > + - st,adc-freq : ADC Clock speed
> > + 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> > + 1 -> 3.25 MHz
> >
> > Node name must be stmpe_touchscreen and should be child node of stmpe node
> > to
> > which it belongs.
> >
> > +Note that common ADC settings of stmpe_touchscreen will take precedence.
> > +
> > Example:
> >
> > stmpe_touchscreen {
> > compatible = "st,stmpe-ts";
> > - st,sample-time = <4>;
> > - st,mod-12b = <1>;
> > - st,ref-sel = <0>;
> > - st,adc-freq = <1>;
> > st,ave-ctrl = <1>;
> > st,touch-det-delay = <2>;
> > st,settling = <2>;
> > diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt
> > b/Documentation/devicetree/bindings/mfd/stmpe.txt
> > index c797c05cd3c2..d4408a417193 100644
> > --- a/Documentation/devicetree/bindings/mfd/stmpe.txt
> > +++ b/Documentation/devicetree/bindings/mfd/stmpe.txt
> > @@ -4,15 +4,29 @@ STMPE is an MFD device which may expose the following
> > inbuilt devices: gpio,
> > keypad, touchscreen, adc, pwm, rotator.
> >
> > Required properties:
> > - - compatible :
> > "st,stmpe[610|801|811|1600|1601|2401|2403]"
> > - - reg : I2C/SPI address of the device
> > + - compatible :
> > "st,stmpe[610|801|811|1600|1601|2401|2403]"
> > + - reg : I2C/SPI address of the device
>
> Nothing wrong with correcting alignment, but it shouldn't be in the same patch
> as a fundamental change lie this. Just adds noise.
>
> If that means you first have to introduce the new block missaligned, then
> fix up the alignment in a follow up patch, then do that as we can then
> effectively ignore the realignment as obviously correct and focus on
> the real changes.
>
> >
> > Optional properties:
> > - - interrupts : The interrupt outputs from the controller
> > - - interrupt-controller : Marks the device node as an interrupt
> > controller
> > - - wakeup-source : Marks the input device as wakable
> > - - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128,
> > 256, 512 and 1024
> > - - irq-gpio : If present, which GPIO to use for event
> > IRQ
> > + - interrupts : The interrupt outputs from the
> > controller
> > + - interrupt-controller : Marks the device node as an interrupt
> > controller
> > + - wakeup-source : Marks the input device as wakable
> > + - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64,
> > 128, 256, 512 and 1024
> > + - irq-gpio : If present, which GPIO to use for
> > event IRQ
> > +
> > +Optional properties for devices with touch and ADC (STMPE811|STMPE610):
> > + - st,sample-time : ADC conversion time in number of clock.
> > + 0 -> 36 clocks 4 -> 80
> > clocks (recommended)
> > + 1 -> 44 clocks 5 -> 96
> > clocks
> > + 2 -> 56 clocks 6 -> 124
> > clocks
> > + 3 -> 64 clocks
> > + - st,mod-12b : ADC Bit mode
> > + 0 -> 10bit ADC 1 -> 12bit
> > ADC
> > + - st,ref-sel : ADC reference source
> > + 0 -> internal 1 ->
> > external
> > + - st,adc-freq : ADC Clock speed
> > + 0 -> 1.625 MHz 2 || 3 ->
> > 6.5 MHz
> > + 1 -> 3.25 MHz
> >
> > Example:
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [for-next][PATCH 05/30] arm64: function_graph: Remove use of FTRACE_NOTRACE_DEPTH
From: Will Deacon @ 2018-12-06 15:49 UTC (permalink / raw)
To: Steven Rostedt
Cc: Tom Zanussi, Catalin Marinas, linux-kernel, Ravi Bangoria,
Masami Hiramatsu, Joel Fernandes (Google), Namhyung Kim,
Andrew Morton, Ingo Molnar, linux-arm-kernel
In-Reply-To: <20181205234829.164618323@goodmis.org>
On Wed, Dec 05, 2018 at 06:47:54PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
>
> Functions in the set_graph_notrace no longer subtract FTRACE_NOTRACE_DEPTH
> from curr_ret_stack, as that is now implemented via the trace_recursion
> flags. Access to curr_ret_stack no longer needs to worry about checking for
> this. curr_ret_stack is still initialized to -1, when there's not a shadow
> stack allocated.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> ---
> arch/arm64/kernel/stacktrace.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
> index 4989f7ea1e59..7723dadf25be 100644
> --- a/arch/arm64/kernel/stacktrace.c
> +++ b/arch/arm64/kernel/stacktrace.c
> @@ -61,9 +61,6 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
> (frame->pc == (unsigned long)return_to_handler)) {
> if (WARN_ON_ONCE(frame->graph == -1))
> return -EINVAL;
> - if (frame->graph < -1)
> - frame->graph += FTRACE_NOTRACE_DEPTH;
> -
Acked-by: Will Deacon <will.deacon@arm.com>
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] pinctrl: sunxi: Account for per-bank GPIO regulators
From: Maxime Ripard @ 2018-12-06 15:47 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: linux-gpio, Linus Walleij, Mylène Josserand,
linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <CAGb2v672oGHpeKEb4HV8ecZro2v-NPC9cV_DKPdNv9dy2OTREQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1539 bytes --]
Hi,
On Thu, Dec 06, 2018 at 11:28:21PM +0800, Chen-Yu Tsai wrote:
> On Thu, Dec 6, 2018 at 10:02 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > The main interogation I have currently is whether we should always try to
> > get the regulator for the current branch, or if we should restrict it to
> > the one available on the SoCs.
>
> Not sure what you mean here, but we should probably just list the actual
> names.
The A20 for example doesn't have a VCC-PB regulator, so do we want to
try to grab it if we request a PB* pin, or should we just know that
somehow and not do it?
> For pre-A20 SoCs (A10/A10s/A13), they aren't even named VCC-Px. Instead
> they are named after the primary function of the pin bank, such as
> VCC-CARD, VCC-NAND, VCC-CSI0, VCC-CSI1.
I'd really prefer to stick to vcc-pX, that's pretty obvious even for
those older SoCs, and we can maintain some consistency that way.
> For pin banks that don't have per-bank power inputs, you should fall back
> to VCC-IO, or VCC-RTC in the case of the PL pins.
>
> So here's the rub: On A33 and later SoCs that are paired with a PMIC, VCC-PL
> or VCC-RTC is powered by the RTC regulator of the PMIC, which only gets
> registered when the PMIC regulator driver is probed, which needs the RSB
> controller, which needs the pin controller and the PL pins...
I haven't seen any VCC-P* on the A33, do you have a reference?
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] PCI: controller: dwc: Make PCI_IMX6 depend on PCIEPORTBUS
From: Robert Hancock @ 2018-12-06 15:45 UTC (permalink / raw)
To: Baruch Siach, Andrey Smirnov
Cc: A.s. Dong, Trent Piepho, Richard Zhu, linux-pci, linux-kernel,
linux-imx, bhelgaas, Leonard Crestez, cphealy, linux-arm-kernel,
l.stach
In-Reply-To: <87o99zjcsc.fsf@tkos.co.il>
On 2018-12-06 2:10 a.m., Baruch Siach wrote:
> Hi Andrey,
>
> Adding Robert Hancock who reported[1] on a PCIe MSI issue with i.MX6.
>
> Andrey Smirnov writes:
>
>> Building a kernel with CONFIG_PCI_IMX6=y, but CONFIG_PCIEPORTBUS=n
>> produces a system where built-in PCIE bridge (16c3:abcd) isn't bound
>> to pcieport driver. This, in turn, results in a PCIE bus that is
>> capable of enumerating attached PCIE device, but lacks functional
>> interrupt support.
>
> Robert, does that fix your issue?
Unfortunately, no.. in fact the situation on my setup is even worse with
CONFIG_PCIEPORTBUS enabled: Not only does MSI still not function, but
now INTx interrupts are somehow broken as well - no interrupts are
received. The IRQ information shown in /proc/interrupts is correct, but
the count remains stubbornly at 0.
So given that outcome, I don't think we should add this as a hard
dependency until we can figure out what is going on, as it seems to
regress working setups.
>
>> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
>> ---
>>
>> Assuming this is a reasonable dependency, shold this be done to more
>> than just i.MX6 driver?
>>
>> drivers/pci/controller/dwc/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
>> index 2b139acccf32..44ededbeab85 100644
>> --- a/drivers/pci/controller/dwc/Kconfig
>> +++ b/drivers/pci/controller/dwc/Kconfig
>> @@ -92,6 +92,7 @@ config PCI_IMX6
>> bool "Freescale i.MX6 PCIe controller"
>> depends on SOC_IMX8MQ || SOC_IMX6Q || (ARM && COMPILE_TEST)
>> depends on PCI_MSI_IRQ_DOMAIN
>> + depends on PCIEPORTBUS
>
> This effectively disables PCIe in imx_v6_v7_defconfig, since
> CONFIG_PCIEPORTBUS is not enabled there. Maybe do 'select' instead?
>
>> Select PCIE_DW_HOST
>>
>> config PCIE_SPEAR13XX
>
> baruch
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/614800.html
>
> --
> http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
>
--
Robert Hancock
Senior Software Developer
SED Systems
Email: hancock@sedsystems.ca
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: a64: Add pinmux setting for CSI MCLK on PE1
From: Maxime Ripard @ 2018-12-06 15:35 UTC (permalink / raw)
To: Jagan Teki
Cc: Mark Rutland, devicetree, linux-kernel, Chen-Yu Tsai, Rob Herring,
Michael Trimarchi, linux-amarula, linux-arm-kernel
In-Reply-To: <20181206132306.11843-3-jagan@amarulasolutions.com>
[-- Attachment #1.1: Type: text/plain, Size: 1140 bytes --]
On Thu, Dec 06, 2018 at 06:53:06PM +0530, Jagan Teki wrote:
> Some camera modules have the SoC feeding a master clock to the sensor
> instead of having a standalone crystal. This clock signal is generated
> from the clock control unit and output from the CSI MCLK function of
> pin PE1.
>
> Add a pinmux setting for it for camera sensors to reference.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v2:
> - new patch
>
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index d7ab0006ebce..902b5238f1dd 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -538,6 +538,11 @@
> function = "csi0";
> };
>
> + csi_mclk_pin: csi-mclk {
> + pins = "PE1";
> + function = "csi0";
> + };
> +
We're not merging nodes that have no users.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: allwinner: a64: Add A64 CSI controller
From: Maxime Ripard @ 2018-12-06 15:34 UTC (permalink / raw)
To: Jagan Teki
Cc: Mark Rutland, devicetree, linux-kernel, Chen-Yu Tsai, Rob Herring,
Michael Trimarchi, linux-amarula, linux-arm-kernel
In-Reply-To: <20181206132306.11843-2-jagan@amarulasolutions.com>
[-- Attachment #1.1: Type: text/plain, Size: 1928 bytes --]
On Thu, Dec 06, 2018 at 06:53:05PM +0530, Jagan Teki wrote:
> Allwinner A64 CSI controller has similar features as like in
> H3, So add support for A64 via H3 fallback.
>
> Also updated CSI_SCLK to use 300MHz via assigned-clocks, since
> the default clock 600MHz seems unable to drive the sensor(ov5640)
> to capture the image.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v2:
> - Use CSI_SCLK to 300MHz
>
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 +++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 384c417cb7a2..d7ab0006ebce 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -532,6 +532,12 @@
> interrupt-controller;
> #interrupt-cells = <3>;
>
> + csi_pins: csi-pins {
> + pins = "PE0", "PE2", "PE3", "PE4", "PE5", "PE6",
> + "PE7", "PE8", "PE9", "PE10", "PE11";
> + function = "csi0";
> + };
> +
> i2c0_pins: i2c0_pins {
> pins = "PH0", "PH1";
> function = "i2c0";
> @@ -899,6 +905,23 @@
> status = "disabled";
> };
>
> + csi: csi@1cb0000 {
> + compatible = "allwinner,sun50i-a64-csi",
> + "allwinner,sun8i-h3-csi";
> + reg = <0x01cb0000 0x1000>;
> + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_CSI>,
> + <&ccu CLK_CSI_SCLK>,
> + <&ccu CLK_DRAM_CSI>;
> + clock-names = "bus", "mod", "ram";
> + resets = <&ccu RST_BUS_CSI>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&csi_pins>;
> + assigned-clocks = <&ccu CLK_CSI_SCLK>;
> + assigned-clock-rates = <300000000>;
That should be enforced in the driver.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems
From: Russell King - ARM Linux @ 2018-12-06 15:31 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: mark.rutland, julien.thierry, marc.zyngier, will.deacon,
Morten.Rasmussen, Qais.Yousef, dietmar.eggemann, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <CAJKOXPchTZtFKtycEEhYoxZR53VckqZYQfOrGNhDvUARxBS4fw@mail.gmail.com>
On Thu, Dec 06, 2018 at 04:03:27PM +0100, Krzysztof Kozlowski wrote:
> On Thu, 6 Dec 2018 at 15:37, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> >
> > On Thu, Dec 06, 2018 at 03:30:22PM +0100, Krzysztof Kozlowski wrote:
> > > On Thu, 6 Dec 2018 at 15:07, Russell King - ARM Linux
> > > > That basically means that the dcache_clean_area method for CPU1
> > > > differs from the dcache_clean_area method for CPU0. If all your
> > > > CPUs are identical, that definitely should not be happening.
> > > >
> > > > Hmm. Interestingly, OMAP4430 passes hotplug tests just fine.
> > > >
> > > > Please try this patch.
> > >
> > > This fixes both hotplug and suspend to RAM. I was trying to narrow why
> > > the pointers to all processor functions differ. During first boot they
> > > were OK but it seems they were changed just before suspend.
> >
> > Thanks for testing. I think this is probably a better patch which
> > should end up with the same result.
> >
> > I suspect no one else has noticed because most people have big.Little
> > support disabled - that'd explain why it doesn't show up on OMAP4.
> >
> > diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
> > index 81d0efb055c6..44f9776139a8 100644
> > --- a/arch/arm/mm/proc-macros.S
> > +++ b/arch/arm/mm/proc-macros.S
> > @@ -274,6 +274,13 @@
> > .endm
> >
> > .macro define_processor_functions name:req, dabort:req, pabort:req, nommu=0, suspend=0, bugs=0
> > +/*
> > + * If we are building for big.Little with branch predictor hardening,
> > + * we need the processor function tables to remain available after boot.
> > + */
> > +#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
> > + .rodata
> > +#endif
> > .type \name\()_processor_functions, #object
> > .align 2
> > ENTRY(\name\()_processor_functions)
> > @@ -309,6 +316,9 @@ ENTRY(\name\()_processor_functions)
> > .endif
> >
> > .size \name\()_processor_functions, . - \name\()_processor_functions
> > +#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
> > + .previous
> > +#endif
> > .endm
> >
> > .macro define_cache_functions name:req
>
> Does not compile:
> ../arch/arm/mm/proc-v7.S: Assembler messages:
> ../arch/arm/mm/proc-v7.S:560: Error: unknown pseudo-op: `.rodata'
> ../arch/arm/mm/proc-v7.S:575: Error: unknown pseudo-op: `.rodata'
> ../arch/arm/mm/proc-v7.S:596: Error: unknown pseudo-op: `.rodata'
> ../arch/arm/mm/proc-v7.S:611: Error: unknown pseudo-op: `.rodata'
> ../arch/arm/mm/proc-v7.S:629: Error: unknown pseudo-op: `.rodata'
It should be .section ".rodata", sorry.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] pinctrl: sunxi: Account for per-bank GPIO regulators
From: Chen-Yu Tsai @ 2018-12-06 15:28 UTC (permalink / raw)
To: Maxime Ripard
Cc: linux-gpio, Linus Walleij, Mylène Josserand,
linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <cover.50931fbda5c95345087740e4c1ef5a57fdd53480.1544104801.git-series.maxime.ripard@bootlin.com>
On Thu, Dec 6, 2018 at 10:02 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi,
>
> Here is a first attempt at getting the regulators properly accounted for
> the GPIO banks on the Allwinner SoCs.
Cool. This is better than what I had in mind, which involved a deferred
task to grab the regulators.
> The main interogation I have currently is whether we should always try to
> get the regulator for the current branch, or if we should restrict it to
> the one available on the SoCs.
Not sure what you mean here, but we should probably just list the actual
names.
For pre-A20 SoCs (A10/A10s/A13), they aren't even named VCC-Px. Instead
they are named after the primary function of the pin bank, such as
VCC-CARD, VCC-NAND, VCC-CSI0, VCC-CSI1.
For pin banks that don't have per-bank power inputs, you should fall back
to VCC-IO, or VCC-RTC in the case of the PL pins.
So here's the rub: On A33 and later SoCs that are paired with a PMIC, VCC-PL
or VCC-RTC is powered by the RTC regulator of the PMIC, which only gets
registered when the PMIC regulator driver is probed, which needs the RSB
controller, which needs the pin controller and the PL pins...
ChenYu
>
> Let me know what you think,
> Maxime
>
> Maxime Ripard (2):
> pinctrl: sunxi: Deal with per-bank regulators
> ARM: dts: sun7i: bananapi: Add GPIO banks regulators
>
> arch/arm/boot/dts/sun7i-a20-bananapi.dts | 5 ++-
> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 63 +++++++++++++++++++++++++-
> drivers/pinctrl/sunxi/pinctrl-sunxi.h | 6 ++-
> 3 files changed, 74 insertions(+)
>
> base-commit: 651022382c7f8da46cb4872a545ee1da6d097d2a
> --
> git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] i.MX fixes for 4.20, round 3
From: Shawn Guo @ 2018-12-06 15:16 UTC (permalink / raw)
To: arm; +Cc: Fabio Estevam, linux-imx, kernel, linux-arm-kernel
The following changes since commit 512cab3e7e0be11234f965d9898936dce2325382:
ARM: dts: imx51-zii-rdu1: Remove EEPROM node (2018-11-19 22:35:45 +0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-4.20-3
for you to fetch changes up to f15096f12a4e9340168df5fdd9201aa8ed60d59e:
ARM: dts: imx7d-nitrogen7: Fix the description of the Wifi clock (2018-12-06 15:38:28 +0800)
----------------------------------------------------------------
i.MX fixes for 4.20, round 3:
- A couple of fixes on imx7d-pico and imx7d-nitrogen7 boards to correct
the description of the Wifi clock.
- Change SW2ISO count to get a safer ARM LDO ramp-up time, so that
different boards can be covered. This fixes the ARM LDO failure seen
on some customer boards.
----------------------------------------------------------------
Anson Huang (1):
ARM: imx: update the cpu power up timing setting on i.mx6sx
Fabio Estevam (2):
ARM: dts: imx7d-pico: Describe the Wifi clock
ARM: dts: imx7d-nitrogen7: Fix the description of the Wifi clock
arch/arm/boot/dts/imx7d-nitrogen7.dts | 9 +++++++--
arch/arm/boot/dts/imx7d-pico.dtsi | 22 +++++++++++++++++++++-
arch/arm/mach-imx/cpuidle-imx6sx.c | 2 +-
3 files changed, 29 insertions(+), 4 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V3 1/2] mmc: mmci: add variant property to set command stop bit
From: Ludovic Barre @ 2018-12-06 15:13 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: devicetree, Alexandre Torgue, linux-mmc, linux-kernel,
srinivas.kandagatla, Ludovic Barre, Maxime Coquelin, linux-stm32,
linux-arm-kernel
In-Reply-To: <1544109212-12621-1-git-send-email-ludovic.Barre@st.com>
From: Ludovic Barre <ludovic.barre@st.com>
On cmd12 (STOP_TRANSMISSION), STM32 sdmmc variant needs to set
cmdstop bit in command register. The CPSM ("Command Path State Machine")
treats the command as a Stop Transmission command and signals
abort to the DPSM ("Data Path State Machine").
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
---
drivers/mmc/host/mmci.c | 6 ++++++
drivers/mmc/host/mmci.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 13fa640..e352f5a 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -21,6 +21,7 @@
#include <linux/err.h>
#include <linux/highmem.h>
#include <linux/log2.h>
+#include <linux/mmc/mmc.h>
#include <linux/mmc/pm.h>
#include <linux/mmc/host.h>
#include <linux/mmc/card.h>
@@ -274,6 +275,7 @@ static struct variant_data variant_stm32_sdmmc = {
.cmdreg_lrsp_crc = MCI_CPSM_STM32_LRSP_CRC,
.cmdreg_srsp_crc = MCI_CPSM_STM32_SRSP_CRC,
.cmdreg_srsp = MCI_CPSM_STM32_SRSP,
+ .cmdreg_stop = MCI_CPSM_STM32_CMDSTOP,
.data_cmd_enable = MCI_CPSM_STM32_CMDTRANS,
.irq_pio_mask = MCI_IRQ_PIO_STM32_MASK,
.datactrl_first = true,
@@ -1100,6 +1102,10 @@ mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
mmci_reg_delay(host);
}
+ if (host->variant->cmdreg_stop &&
+ cmd->opcode == MMC_STOP_TRANSMISSION)
+ c |= host->variant->cmdreg_stop;
+
c |= cmd->opcode | host->variant->cmdreg_cpsm_enable;
if (cmd->flags & MMC_RSP_PRESENT) {
if (cmd->flags & MMC_RSP_136)
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 550dd39..2422909 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -264,6 +264,7 @@ struct mmci_host;
* @cmdreg_lrsp_crc: enable value for long response with crc
* @cmdreg_srsp_crc: enable value for short response with crc
* @cmdreg_srsp: enable value for short response without crc
+ * @cmdreg_stop: enable value for stop and abort transmission
* @datalength_bits: number of bits in the MMCIDATALENGTH register
* @fifosize: number of bytes that can be written when MMCI_TXFIFOEMPTY
* is asserted (likewise for RX)
@@ -316,6 +317,7 @@ struct variant_data {
unsigned int cmdreg_lrsp_crc;
unsigned int cmdreg_srsp_crc;
unsigned int cmdreg_srsp;
+ unsigned int cmdreg_stop;
unsigned int datalength_bits;
unsigned int fifosize;
unsigned int fifohalfsize;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V3 2/2] mmc: mmci: send stop command to clear the dpsm
From: Ludovic Barre @ 2018-12-06 15:13 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: devicetree, Alexandre Torgue, linux-mmc, linux-kernel,
srinivas.kandagatla, Ludovic Barre, Maxime Coquelin, linux-stm32,
linux-arm-kernel
In-Reply-To: <1544109212-12621-1-git-send-email-ludovic.Barre@st.com>
From: Ludovic Barre <ludovic.barre@st.com>
The current approach with sending a CMD12 (STOP_TRANSMISSION) to
complete a data transfer request, either because of using the open
ended transmission type or because of receiving an error during a data
transfer, isn't sufficient for the STM32 sdmmc variant.
More precisely, for STM32 sdmmc the DPSM ("Data Path State Machine")
needs to be cleared by sending a CMD12, also for the so called ADTC
commands. For this reason, let the driver send a CMD12 to complete
ADTC commands, in case it's set (depend of cmdreg_stop variant property).
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
---
drivers/mmc/host/mmci.c | 37 +++++++++++++++++++++++++++++++++++++
drivers/mmc/host/mmci.h | 2 ++
2 files changed, 39 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index e352f5a..4e5643d 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -58,6 +58,8 @@ void sdmmc_variant_init(struct mmci_host *host);
#else
static inline void sdmmc_variant_init(struct mmci_host *host) {}
#endif
+static void
+mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c);
static unsigned int fmax = 515633;
@@ -572,9 +574,37 @@ void mmci_dma_error(struct mmci_host *host)
host->ops->dma_error(host);
}
+static int mmci_stop_command(struct mmci_host *host, struct mmc_request *mrq)
+{
+ u32 dpsm;
+
+ /*
+ * If an error happens on command or data transmission
+ * the DPSM stay enabled. The CPSM required a stop command
+ * to reinitialize the DPSM.
+ */
+ dpsm = readl_relaxed(host->base + MMCISTATUS);
+ dpsm &= MCI_STM32_DPSMACTIVE;
+
+ if (dpsm && ((mrq->cmd && mrq->cmd->error) ||
+ (mrq->data && mrq->data->error))) {
+ mmci_start_command(host, &host->stop_abort, 0);
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
static void
mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
{
+ /*
+ * For variant with cmdstop bit, a stop command could be needed
+ * to finish the request.
+ */
+ if (host->variant->cmdreg_stop && mmci_stop_command(host, mrq))
+ return;
+
writel(0, host->base + MMCICOMMAND);
BUG_ON(host->data);
@@ -1956,6 +1986,13 @@ static int mmci_probe(struct amba_device *dev,
mmc->max_busy_timeout = 0;
}
+ /* prepare the stop command, used to abort and reinitialized the DPSM */
+ if (variant->cmdreg_stop) {
+ host->stop_abort.opcode = MMC_STOP_TRANSMISSION;
+ host->stop_abort.arg = 0;
+ host->stop_abort.flags = MMC_RSP_R1B | MMC_CMD_AC;
+ }
+
mmc->ops = &mmci_ops;
/* We support these PM capabilities. */
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 2422909..35372cd 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -161,6 +161,7 @@
#define MCI_ST_CEATAEND (1 << 23)
#define MCI_ST_CARDBUSY (1 << 24)
/* Extended status bits for the STM32 variants */
+#define MCI_STM32_DPSMACTIVE BIT(12)
#define MCI_STM32_BUSYD0 BIT(20)
#define MMCICLEAR 0x038
@@ -377,6 +378,7 @@ struct mmci_host {
void __iomem *base;
struct mmc_request *mrq;
struct mmc_command *cmd;
+ struct mmc_command stop_abort;
struct mmc_data *data;
struct mmc_host *mmc;
struct clk *clk;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V3 0/2] mmc: mmci: add stop command
From: Ludovic Barre @ 2018-12-06 15:13 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: devicetree, Alexandre Torgue, linux-mmc, linux-kernel,
srinivas.kandagatla, Ludovic Barre, Maxime Coquelin, linux-stm32,
linux-arm-kernel
From: Ludovic Barre <ludovic.barre@st.com>
This patch series adds variant property to:
-Set cmdstop bit on STOP_TRANSMISSION command.
-On command or data error, send a stop command.
to clear DPSM if it's yet activated.
change v3:
-Move the cmdstop bit in separate patch.
-Use Ulf re-wording for patch 2/2.
-Move specific part in a separate function.
Ludovic Barre (2):
mmc: mmci: add variant property to set command stop bit
mmc: mmci: send stop command to clear the dpsm
drivers/mmc/host/mmci.c | 43 +++++++++++++++++++++++++++++++++++++++++++
drivers/mmc/host/mmci.h | 4 ++++
2 files changed, 47 insertions(+)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/1] stackleak: Register the 'stackleak_cleanup' pass before the '*free_cfg' pass
From: Alexander Popov @ 2018-12-06 15:13 UTC (permalink / raw)
To: kernel-hardening, Kees Cook, Jann Horn, Andy Lutomirski,
Borislav Petkov, Thomas Gleixner, Dave Hansen, Steven Rostedt,
Peter Zijlstra, Masami Hiramatsu, Florian Weimer,
Richard Sandiford, Segher Boessenkool, Alexander Monakov,
Tycho Andersen, Laura Abbott, Mark Rutland, Emese Revfy,
Thomas Garnier, Ingo Molnar, Will Deacon, Alexei Starovoitov,
Ard Biesheuvel, H Peter Anvin, David S Miller, linux-arm-kernel,
gcc, alex.popov, linux-kernel
Currently the 'stackleak_cleanup' pass deleting a CALL insn is executed
after the 'reload' pass. That allows gcc to do some weird optimization in
function prologues and epilogues, which are generated later [1].
Let's avoid that by registering the 'stackleak_cleanup' pass before
the '*free_cfg' pass. It's the moment when the stack frame size is
already final, function prologues and epilogues are generated, and the
machine-dependent code transformations are not done.
[1] https://www.openwall.com/lists/kernel-hardening/2018/11/23/2
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Alexander Popov <alex.popov@linux.com>
---
scripts/gcc-plugins/stackleak_plugin.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/scripts/gcc-plugins/stackleak_plugin.c b/scripts/gcc-plugins/stackleak_plugin.c
index 2f48da9..dbd3746 100644
--- a/scripts/gcc-plugins/stackleak_plugin.c
+++ b/scripts/gcc-plugins/stackleak_plugin.c
@@ -363,10 +363,12 @@ __visible int plugin_init(struct plugin_name_args *plugin_info,
PASS_POS_INSERT_BEFORE);
/*
- * The stackleak_cleanup pass should be executed after the
- * "reload" pass, when the stack frame size is final.
+ * The stackleak_cleanup pass should be executed before the "*free_cfg"
+ * pass. It's the moment when the stack frame size is already final,
+ * function prologues and epilogues are generated, and the
+ * machine-dependent code transformations are not done.
*/
- PASS_INFO(stackleak_cleanup, "reload", 1, PASS_POS_INSERT_AFTER);
+ PASS_INFO(stackleak_cleanup, "*free_cfg", 1, PASS_POS_INSERT_BEFORE);
if (!plugin_default_version_check(version, &gcc_version)) {
error(G_("incompatible gcc/plugin versions"));
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: dmapool regression in next
From: Tony Battersby @ 2018-12-06 15:11 UTC (permalink / raw)
To: Krzysztof Kozlowski, tony
Cc: Stephen Rothwell, john.garry, linux, linux-kernel,
andy.shevchenko, akpm, linux-omap, hch, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <CAJKOXPcoK5SsXfXjdAWPHLX2KZRCqOv61HVf2DK9wm4_m+vJ0w@mail.gmail.com>
On 12/6/18 4:25 AM, Krzysztof Kozlowski wrote:
> On Thu, 6 Dec 2018 at 02:31, Tony Lindgren <tony@atomide.com> wrote:
>> Hi,
>>
>> Looks like with commit 26abe88e830d ("mm/dmapool.c: improve scalability
>> of dma_pool_free()") I'm now getting spammed with lots of "(bad vaddr)"
>> on at least omap4 pandaboard, see below.
>>
>> Any ideas what might be going wrong?
>>
>> Regards,
>>
>> Tony
>>
>> 8< ---------------------
>> omap-dma-engine 4a056000.dma-controller: dma_pool_free 4a056000.dma-controller, (ptrval) (bad vaddr)/0xbe800000
>> omap-dma-engine 4a056000.dma-controller: dma_pool_free 4a056000.dma-controller, (ptrval) (bad vaddr)/0xbe80001c
>> omap-dma-engine 4a056000.dma-controller: dma_pool_free 4a056000.dma-controller, (ptrval) (bad vaddr)/0xbe800038
>> ...
> I see it as well on all my Exynos boards, since yesterday's next. In
> my case it is the USB EHCI driver:
> exynos-ehci 12110000.usb: dma_pool_free ehci_qtd, (ptrval) (bad
> vaddr)/0xb8844180
> Full log here:
> https://krzk.eu/#/builders/1/builds/2937/steps/12/logs/serial0
>
> Best regards,
> Krzysztof
>
Here is the prototype:
void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t dma);
With the old code, the 'dma' value had to be correct for use with
pool_find_page(), or else you would get an error. If the 'vaddr' value
was incorrect, it would corrupt the dmapool freelist, but you wouldn't
get an error unless DMAPOOL_DEBUG was enabled.
With my patch applied, 'vaddr' has to be correct for virt_to_page(). My
code also checks that 'dma' is consistent with 'vaddr' even if
DMAPOOL_DEBUG is disabled, since the check is fast and it will prevent
problems like this in the future.
So if a buggy driver passes in a good value for 'dma' but a bad value
for 'vaddr', then it may have appeared to work previously (but with
possible data corruption, depending on the circumstances), but my patch
will expose the problem. You can confirm by reverting my dmapool
patches and enabling DMAPOOL_DEBUG, which is at the top of mm/dmapool.c:
#if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_SLUB_DEBUG_ON)
#define DMAPOOL_DEBUG 1
#endif
Tony Battersby
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] stackleak: Register the 'stackleak_cleanup' pass before the 'mach' pass
From: Alexander Popov @ 2018-12-06 15:10 UTC (permalink / raw)
To: Kees Cook
Cc: Mark Rutland, Kernel Hardening, Peter Zijlstra, Richard Sandiford,
Dave Hansen, Will Deacon, Alexei Starovoitov, H. Peter Anvin,
Ingo Molnar, Tycho Andersen, Emese Revfy, Laura Abbott,
Segher Boessenkool, Jann Horn, amonakov, Steven Rostedt,
Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Florian Weimer, gcc, Ard Biesheuvel, LKML,
David S. Miller, Masami Hiramatsu, Thomas Garnier
In-Reply-To: <e1259720-423c-c1ca-1fe5-b9ef89ad19a3@linux.com>
On 03.12.2018 21:25, Alexander Popov wrote:
> But I think it's better to register the 'stackleak_cleanup' pass just one pass
> earlier -- before the '*free_cfg' pass. I'll double check it for different
> versions of gcc on all supported architectures and return with a new patch.
I've tested this idea for gcc-5,6,7,8 on x86_64, x86_32, and arm64.
I'll send the patch soon.
Best regards,
Alexander
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/2] arm64: Only call into preempt_schedule() if need_resched()
From: Peter Zijlstra @ 2018-12-06 15:08 UTC (permalink / raw)
To: Will Deacon
Cc: ard.biesheuvel, catalin.marinas, rml, linux-kernel, schwidefsky,
tglx, linux-arm-kernel
In-Reply-To: <1543599271-14339-1-git-send-email-will.deacon@arm.com>
On Fri, Nov 30, 2018 at 05:34:29PM +0000, Will Deacon wrote:
> Hi all,
>
> This is version two of the patches I originally posted here:
>
> http://lkml.kernel.org/r/1543347902-21170-1-git-send-email-will.deacon@arm.com
>
> The only change since v1 is that __preempt_count_dec_and_test() now
> reloads the need_resched flag if it initially saw that it was set. This
> resolves the issue spotted by Peter, where an IRQ coming in during the
> decrement can cause a reschedule to be missed.
Yes, I think this one will work, so:
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
However, this leaves me wondering if the sequence is actually much
better than what you had?
I suppose there's a win due to cache locality -- you only have to load a
single line -- but I'm thinking that on pure instruction count, you're
not actually winning much.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems
From: Krzysztof Kozlowski @ 2018-12-06 15:03 UTC (permalink / raw)
To: linux
Cc: mark.rutland, julien.thierry, marc.zyngier, will.deacon,
Morten.Rasmussen, Qais.Yousef, dietmar.eggemann, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <20181206143703.GV30658@n2100.armlinux.org.uk>
On Thu, 6 Dec 2018 at 15:37, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
>
> On Thu, Dec 06, 2018 at 03:30:22PM +0100, Krzysztof Kozlowski wrote:
> > On Thu, 6 Dec 2018 at 15:07, Russell King - ARM Linux
> > > That basically means that the dcache_clean_area method for CPU1
> > > differs from the dcache_clean_area method for CPU0. If all your
> > > CPUs are identical, that definitely should not be happening.
> > >
> > > Hmm. Interestingly, OMAP4430 passes hotplug tests just fine.
> > >
> > > Please try this patch.
> >
> > This fixes both hotplug and suspend to RAM. I was trying to narrow why
> > the pointers to all processor functions differ. During first boot they
> > were OK but it seems they were changed just before suspend.
>
> Thanks for testing. I think this is probably a better patch which
> should end up with the same result.
>
> I suspect no one else has noticed because most people have big.Little
> support disabled - that'd explain why it doesn't show up on OMAP4.
>
> diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
> index 81d0efb055c6..44f9776139a8 100644
> --- a/arch/arm/mm/proc-macros.S
> +++ b/arch/arm/mm/proc-macros.S
> @@ -274,6 +274,13 @@
> .endm
>
> .macro define_processor_functions name:req, dabort:req, pabort:req, nommu=0, suspend=0, bugs=0
> +/*
> + * If we are building for big.Little with branch predictor hardening,
> + * we need the processor function tables to remain available after boot.
> + */
> +#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
> + .rodata
> +#endif
> .type \name\()_processor_functions, #object
> .align 2
> ENTRY(\name\()_processor_functions)
> @@ -309,6 +316,9 @@ ENTRY(\name\()_processor_functions)
> .endif
>
> .size \name\()_processor_functions, . - \name\()_processor_functions
> +#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
> + .previous
> +#endif
> .endm
>
> .macro define_cache_functions name:req
Does not compile:
../arch/arm/mm/proc-v7.S: Assembler messages:
../arch/arm/mm/proc-v7.S:560: Error: unknown pseudo-op: `.rodata'
../arch/arm/mm/proc-v7.S:575: Error: unknown pseudo-op: `.rodata'
../arch/arm/mm/proc-v7.S:596: Error: unknown pseudo-op: `.rodata'
../arch/arm/mm/proc-v7.S:611: Error: unknown pseudo-op: `.rodata'
../arch/arm/mm/proc-v7.S:629: Error: unknown pseudo-op: `.rodata'
I am building with exynos_defconfig.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: remove the ->mapping_error method from dma_map_ops V3
From: Christoph Hellwig @ 2018-12-06 14:57 UTC (permalink / raw)
To: iommu
Cc: linux-arch, linux-ia64, linux-parisc, Robin Murphy, x86,
linux-kernel, linux-alpha, xen-devel, Linus Torvalds,
David Woodhouse, linux-arm-kernel
In-Reply-To: <20181130132231.16512-1-hch@lst.de>
I've pulled this into the dma-mapping for-next tree, with the suggestion
from Robin that improves bisectability, and two unused variables found
by the build bot.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 0/8] Introduce on-chip interconnect API
From: Greg KH @ 2018-12-06 14:55 UTC (permalink / raw)
To: Evan Green
Cc: mark.rutland, Doug Anderson, sanjayc, maxime.ripard,
Michael Turquette, daidavid1, Bjorn Andersson, Saravana Kannan,
Alexandre Bailon, lorenzo.pieralisi, Vincent Guittot, seansw,
khilman, ksitaraman, devicetree, Arnd Bergmann, linux-pm,
linux-arm-msm, robh+dt, linux-tegra, linux-arm-kernel, rjw,
linux-kernel, amit.kucheria, Thierry Reding, georgi.djakov
In-Reply-To: <CAE=gft4jUjr3oDAZrM=-orLM-YoVAwa+e=crDDC_p9ArGE1dig@mail.gmail.com>
On Wed, Dec 05, 2018 at 12:41:35PM -0800, Evan Green wrote:
> On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
> >
> > Modern SoCs have multiple processors and various dedicated cores (video, gpu,
> > graphics, modem). These cores are talking to each other and can generate a
> > lot of data flowing through the on-chip interconnects. These interconnect
> > buses could form different topologies such as crossbar, point to point buses,
> > hierarchical buses or use the network-on-chip concept.
> >
> > These buses have been sized usually to handle use cases with high data
> > throughput but it is not necessary all the time and consume a lot of power.
> > Furthermore, the priority between masters can vary depending on the running
> > use case like video playback or CPU intensive tasks.
> >
> > Having an API to control the requirement of the system in terms of bandwidth
> > and QoS, so we can adapt the interconnect configuration to match those by
> > scaling the frequencies, setting link priority and tuning QoS parameters.
> > This configuration can be a static, one-time operation done at boot for some
> > platforms or a dynamic set of operations that happen at run-time.
> >
> > This patchset introduce a new API to get the requirement and configure the
> > interconnect buses across the entire chipset to fit with the current demand.
> > The API is NOT for changing the performance of the endpoint devices, but only
> > the interconnect path in between them.
>
> For what it's worth, we are ready to land this in Chrome OS. I think
> this series has been very well discussed and reviewed, hasn't changed
> much in the last few spins, and is in good enough shape to use as a
> base for future patches. Georgi's also done a great job reaching out
> to other SoC vendors, and there appears to be enough consensus that
> this framework will be usable by more than just Qualcomm. There are
> also several drivers out on the list trying to add patches to use this
> framework, with more to come, so it made sense (to us) to get this
> base framework nailed down. In my experiments this is an important
> piece of the overall power management story, especially on systems
> that are mostly idle.
>
> I'll continue to track changes to this series and we will ultimately
> reconcile with whatever happens upstream, but I thought it was worth
> sending this note to express our "thumbs up" towards this framework.
Looks like a v11 will be forthcoming, so I'll wait for that one to apply
it to the tree if all looks good.
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V5 6/6] ARM: imx_v6_v7_defconfig: add imx7ulp support
From: Shawn Guo @ 2018-12-06 14:55 UTC (permalink / raw)
To: A.s. Dong
Cc: dongas86@gmail.com, linux@armlinux.org.uk, robh+dt@kernel.org,
dl-linux-imx, kernel@pengutronix.de, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1541862478-7839-7-git-send-email-aisheng.dong@nxp.com>
On Sat, Nov 10, 2018 at 03:13:16PM +0000, A.s. Dong wrote:
> Select CONFIG_SOC_IMX7ULP by default.
> Patch generated via make ARCH=arm savedefconfig
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Reviewed-by: Fabio Estevam <festevam@gmail.com>
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V5 5/6] dts: fsl: add imx7ulp evk support
From: Shawn Guo @ 2018-12-06 14:54 UTC (permalink / raw)
To: A.s. Dong
Cc: devicetree@vger.kernel.org, dongas86@gmail.com,
linux@armlinux.org.uk, robh+dt@kernel.org, dl-linux-imx,
kernel@pengutronix.de, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1541862478-7839-6-git-send-email-aisheng.dong@nxp.com>
On Sat, Nov 10, 2018 at 03:13:12PM +0000, A.s. Dong wrote:
> The NXP i.MX 7ULP Evaluation Kit (EVK) provides a platform for rapid
> evaluation of the i.MX 7ULP, which features NXP's advanced implementation
> of the Arm Cortex-A7 core, the Arm Cortex-M4 core, as well as a 3D and
> 2D Graphics Processing Units (GPUs).
>
> The EVK enables HDMI output for simple out-of-the-box to bring up but
> allows reconfiguration for MIPI displays. The EVK is designed as a
> System-On-Module(SOM) board that connects to an associated baseboard.
> The SOM provides 1 GB LPDDR3, 8 MB Quad SPI flash, Micro SD 3.0 card
> socket, WiFi/ Bluetooth capability, USB 2.0 OTG with Type C connector
> and an NXP PF1550 power management IC (PMIC). The baseboard provides
> additional capabilities including a full SD/MMC 3.0 card socket, audio
> codec, multiple sensors, an HDMI connector, and an alternate MIPI display
> connector. Additionally, the EVK facilitates software development with the
> ultimate goal of faster time to market through the support of both
> Linux OS and AndroidTM rich operating systems, as well as FreeRTOS.
>
> This patch aims to support the preliminary booting up features
> as follows:
> GPIO
> LPUART
> FEC
> SD/MMC
>
> See more board details:
> https://www.nxp.com/products/processors-and-microcontrollers/
> arm-based-processors-and-mcus/i.mx-applications-processors/
> i.mx-7-processors/evaluation-kit-for-the-i.mx-7ulp-applications
> -processor:MCIMX7ULP-EVK
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Reviewed-by: Fabio Estevam <festevam@gmail.com>
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Changed the subject prefix like 'ARM: dts: imx: ...', and applied the
patch.
Shawn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V4 5/6] arm64: mm: introduce 52-bit userspace support
From: Steve Capper @ 2018-12-06 14:52 UTC (permalink / raw)
To: Suzuki Poulose
Cc: ard.biesheuvel@linaro.org, jcm@redhat.com, Will Deacon,
linux-mm@kvack.org, Catalin Marinas, nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <c87c833a-7dfc-6cd4-aad7-119df9bd7178@arm.com>
On Thu, Dec 06, 2018 at 02:35:20PM +0000, Suzuki K Poulose wrote:
>
>
> On 06/12/2018 12:26, Steve Capper wrote:
> > On Wed, Dec 05, 2018 at 06:22:27PM +0000, Suzuki K Poulose wrote:
> > > Hi Steve,
> > >
> > [...]
> > > I think we may need a check for the secondary CPUs to make sure that they have
> > > the 52bit support once the boot CPU has decided to use the feature and fail the
> > > CPU bring up (just like we do for the granule support).
> > >
> > > Suzuki
> >
> > Hi Suzuki,
> > I have just written a patch to detect a mismatch between 52-bit VA that
> > is being tested now.
> >
> > As 52-bit kernel VA support is coming in future, the patch checks for a
> > mismatch during the secondary boot path and, if one is found, prevents
> > the secondary from booting (and displays an error message to the user).
>
> Right now, it is the boot CPU which decides the Userspace 52bit VA, isn't it ?
> Irrespective of the kernel VA support, the userspace must be able to run on
> all the CPUs on the system, right ? So don't we need it now, with this series ?
Hi Suzuki,
Yes the boot CPU determines vabits_user. My idea was to have the
secondary CPUs check to see if vabits_user was 52, and if so, then check
to see if it's capable of supporting 52-bit. If not, then it stops
booting (and sets a flag to indicate why).
This check will be valid for 52-bit userspace support and also valid for
52-bit kernel support (as the check is performed before the secondary
mmu is enabled). I didn't want to write a higher level detection
routine for the userspace support and then have to re-write it later
when introducing 52-bit kernel support.
I'm happy to do what works though, I thought this way was simplest :-).
Cheers,
--
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox