* [PATCH] ARM64: dts: meson-gx: Add missing L2 cache node
From: Neil Armstrong @ 2016-10-05 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In order to remove the boot warning :
[ 2.290933] Unable to detect cache hierarchy from DT for CPU 0
And add missing L2 cache hierarchy information, add a simple l2 cache node
and reference it from the A53 cpu nodes.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 0737056..a6cd953 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -64,6 +64,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
+ next-level-cache = <&l2>;
};
cpu1: cpu at 1 {
@@ -71,6 +72,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x1>;
enable-method = "psci";
+ next-level-cache = <&l2>;
};
cpu2: cpu at 2 {
@@ -78,6 +80,7 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x2>;
enable-method = "psci";
+ next-level-cache = <&l2>;
};
cpu3: cpu at 3 {
@@ -85,6 +88,11 @@
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x3>;
enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache0 {
+ compatible = "cache";
};
};
--
1.9.1
^ permalink raw reply related
* kernel-doc-rst-lint (was: Re: [PATCH 00/15] improve function-level documentation)
From: Jani Nikula @ 2016-10-05 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKMK7uHT3FutHQuQQ3iwXmYbidB3AOs7AxnpaJD4MTqy0-QehQ@mail.gmail.com>
On Wed, 05 Oct 2016, Daniel Vetter <daniel@ffwll.ch> wrote:
> Jani Nikula has a patch with a scrip to make the one kernel-doc parser
> into a lint/checker pass over the entire kernel. I think that'd would
> be more robust instead of trying to approximate the real kerneldoc
> parser. Otoh that parser is a horror show of a perl/regex driven state
> machine ;-)
>
> Jani, can you pls digg out these patches? Can't find them right now ...
Expanding the massive Cc: with linux-doc list...
Here goes. It's a quick hack from months ago, but still seems to
somewhat work. At least for the kernel-doc parts. The reStructuredText
lint part isn't all that great, and doesn't have mapping to line numbers
like the Sphinx kernel-doc extension does. Anyway I'm happy how this
integrates with kernel build CHECK and C=1/C=2.
I guess Julia's goal is to automate the *fixing* of some of the error
classes from kernel-doc. Not sure how well this could be made to
integrate with any of that.
BR,
Jani.
>From 1244efa0f63a7b13795e8c37f81733a3c8bfc56a Mon Sep 17 00:00:00 2001
From: Jani Nikula <jani.nikula@intel.com>
Date: Tue, 31 May 2016 18:11:33 +0300
Subject: [PATCH] kernel-doc-rst-lint: add tool to check kernel-doc and rst
correctness
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Cc: Jani Nikula <jani.nikula@intel.com>
Simple kernel-doc and reStructuredText lint tool that can be used
independently and as a kernel build CHECK tool to validate kernel-doc
comments.
Independent usage:
$ kernel-doc-rst-lint FILE
Kernel CHECK usage:
$ make CHECK=scripts/kernel-doc-rst-lint C=1 # (or C=2)
Depends on docutils and the rst-lint package
https://pypi.python.org/pypi/restructuredtext_lint
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
scripts/kernel-doc-rst-lint | 106 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 106 insertions(+)
create mode 100755 scripts/kernel-doc-rst-lint
diff --git a/scripts/kernel-doc-rst-lint b/scripts/kernel-doc-rst-lint
new file mode 100755
index 000000000000..7e0157679f83
--- /dev/null
+++ b/scripts/kernel-doc-rst-lint
@@ -0,0 +1,106 @@
+#!/usr/bin/env python
+# coding=utf-8
+#
+# Copyright ? 2016 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+# IN THE SOFTWARE.
+#
+# Authors:
+# Jani Nikula <jani.nikula@intel.com>
+#
+# Simple kernel-doc and reStructuredText lint tool that can be used
+# independently and as a kernel build CHECK tool to validate kernel-doc
+# comments.
+#
+# Independent usage:
+# $ kernel-doc-rst-lint FILE
+#
+# Kernel CHECK usage:
+# $ make CHECK=scripts/kernel-doc-rst-lint C=1 # (or C=2)
+#
+# Depends on docutils and the rst-lint package
+# https://pypi.python.org/pypi/restructuredtext_lint
+#
+
+import os
+import subprocess
+import sys
+
+from docutils.parsers.rst import directives
+from docutils.parsers.rst import Directive
+from docutils.parsers.rst import roles
+from docutils import nodes, statemachine
+import restructuredtext_lint
+
+class DummyDirective(Directive):
+ required_argument = 1
+ optional_arguments = 0
+ option_spec = { }
+ has_content = True
+
+ def run(self):
+ return []
+
+# Fake the Sphinx C Domain directives and roles
+directives.register_directive('c:function', DummyDirective)
+directives.register_directive('c:type', DummyDirective)
+roles.register_generic_role('c:func', nodes.emphasis)
+roles.register_generic_role('c:type', nodes.emphasis)
+
+# We accept but ignore parameters to be compatible with how the kernel build
+# invokes CHECK.
+if len(sys.argv) < 2:
+ sys.stderr.write('usage: kernel-doc-rst-lint [IGNORED OPTIONS] FILE\n');
+ sys.exit(1)
+
+infile = sys.argv[len(sys.argv) - 1]
+cmd = ['scripts/kernel-doc', '-rst', infile]
+
+try:
+ p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, universal_newlines=True)
+ out, err = p.communicate()
+
+ # python2 needs conversion to unicode.
+ # python3 with universal_newlines=True returns strings.
+ if sys.version_info.major < 3:
+ out, err = unicode(out, 'utf-8'), unicode(err, 'utf-8')
+
+ # kernel-doc errors
+ sys.stderr.write(err)
+ if p.returncode != 0:
+ sys.exit(p.returncode)
+
+ # restructured text errors
+ lines = statemachine.string2lines(out, 8, convert_whitespace=True)
+ lint_errors = restructuredtext_lint.lint(out, infile)
+ for error in lint_errors:
+ # Ignore INFO
+ if error.level <= 1:
+ continue
+
+ print(error.source + ': ' + error.type + ': ' + error.full_message)
+ if error.line is not None:
+ print('Context:')
+ print('\t' + lines[error.line - 1])
+ print('\t' + lines[error.line])
+
+except Exception as e:
+ sys.stderr.write(str(e) + '\n')
+ sys.exit(1)
--
2.1.4
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply related
* [PATCH 02/11] DOCUMENTATION: dt-bindings: Document the STM32 USART bindings
From: Gerald Baeza @ 2016-10-05 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923152907.GA19206@rob-hp-laptop>
On 09/23/2016 05:29 PM, Rob Herring wrote:
> On Thu, Sep 15, 2016 at 06:42:34PM +0200, Alexandre TORGUE wrote:
>> This adds documentation of device tree bindings for the
>> STM32 USART
>
> Please make your subject prefixes consistent and drop "DOCUMENTATION".
>
Ok, thanks
>>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>>
>> diff --git a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
>> new file mode 100644
>> index 0000000..75b1400
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
>> @@ -0,0 +1,34 @@
>> +* STMicroelectronics STM32 USART
>> +
>> +Required properties:
>> +- compatible: Can be either "st,stm32-usart", "st,stm32-uart",
>> +"st,stm32f7-usart" or "st,stm32f7-uart" depending on whether
>> +the device supports synchronous mode and is compatible with
>> +stm32(f4) or stm32f7.
>
> Why not put f4 in the compatible string. stm32 is too generic.
The initial binding is not in current kernel so it has been put in this
serie as PATCH 07/11. It will be squashed with this one, as you requested.
But the driver tty/serial/stm32-usart.c was already upstreamed and it
already mentions the "st,stm32-usart" and "st,stm32-uart" for stm32f4 so
I kept this as it for backward compatibility for those who already use
the driver.
I do not have the history to explain this inconsistency but can you
confirm that keeping the existing compatible values from the driver is
the good approach please?
> What determines sync mode or not? If it is IP configuration fixed in the
> design, then this is fine. If it is user choice or board dependent, then
> use a separate property.
This is IP configuration fixed in the design, indeed.
>> +- reg: The address and length of the peripheral registers space
>> +- interrupts: The interrupt line of the USART instance
>> +- clocks: The input clock of the USART instance
>> +
>> +Optional properties:
>> +- pinctrl: The reference on the pins configuration
>> +- st,hw-flow-ctrl: bool flag to enable hardware flow control.
>> +
>> +Examples:
>> +usart4: serial at 40004c00 {
>> + compatible = "st,stm32-uart";
>> + reg = <0x40004c00 0x400>;
>> + interrupts = <52>;
>> + clocks = <&clk_pclk1>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_usart4>;
>> +};
>> +
>> +usart2: serial at 40004400 {
>> + compatible = "st,stm32-usart", "st,stm32-uart";
>
> What are valid combinations? usart is sync only, not sync and async?
usart (sync and async) is a superset of uart (async).
But the current driver does not use the synchronous mode, so the
distinction is just here to be consistent with the reference manual
instances naming (so configuration).
>> + reg = <0x40004400 0x400>;
>> + interrupts = <38>;
>> + clocks = <&clk_pclk1>;
>> + st,hw-flow-ctrl;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_usart2 &pinctrl_usart2_rtscts>;
>> +};
>> --
>> 1.9.1
>>
^ permalink raw reply
* [PATCH] ARM: dts: lpc32xx: set pwm1 & pwm2 default clock rate
From: Sylvain Lemieux @ 2016-10-05 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1443ec62-4936-c70a-b323-6980a9240a1e@mleia.com>
Hi Vladimir,
On Wed, 2016-10-05 at 05:08 +0300, Vladimir Zapolskiy wrote:
> Hi Sylvain,
>
> On 26.09.2016 21:54, Sylvain Lemieux wrote:
> > From: Sylvain Lemieux <slemieux@tycoint.com>
> >
> > Probably most of NXP LPC32xx boards have 13MHz main oscillator
> > and therefore for HCLK PLL and ARM core clock rate default
> > hardware setting of 16 * 13MHz = 208MHz and the AHB bus clock
> > rate of 208MHz / 2 = 104MHz.
> >
> > The change explicitly defines the peripheral PWM1/PWM2 default
> > clock output rate of 104MHz. If needed it can be redefined
> > in a board DTS file.
> >
> > Signed-off-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
> > ---
> > Note:
> > * There is a dependency on the following patch:
> > "ARM: dts: lpc32xx: set default parent clock for pwm1 & pwm2"
> > http://www.spinics.net/lists/arm-kernel/msg530277.html
> > * This patch should be apply after
> > "ARM: dts: lpc32xx: add pwm-cells to base dts file"
> > http://www.spinics.net/lists/arm-kernel/msg534050.html
> > - There is no dependency between the patches.
> >
> > arch/arm/boot/dts/lpc32xx.dtsi | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
> > index c031c94..d669200 100644
> > --- a/arch/arm/boot/dts/lpc32xx.dtsi
> > +++ b/arch/arm/boot/dts/lpc32xx.dtsi
> > @@ -471,6 +471,7 @@
> > clocks = <&clk LPC32XX_CLK_PWM1>;
> > assigned-clocks = <&clk LPC32XX_CLK_PWM1>;
> > assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
> > + assigned-clock-rates = <104000000>;
>
> PWM controller clock source can be 32KHz or CLK_PERIPH, the latter is
> equal either to SYSCLK or HCLK PLL divided by HCLKDIV_CTRL[6:2].
>
> Do you set the divider to 1? If yes, then I would say
>
> 1) this is very specific to your board, generally CLK_PERIPH
> is set to be about 10-13MHz,
> 2) HCLKDIV or PERIPH clock configuration shall not be done in pwm device node.
>
> 104MHz is too high value to be set by default for PWM clock.
>
This is a good catch; it was an error on my side.
The purpose of the patch was to setup the output of the
PWM clock to the default CLK_PERIPH value (13325000).
This change does not modify the HCLKDIV or the PERIPH clock.
I can submit a version 2 with the proper value and update
the patch description to list the default peripheral clock
setup of 13MHz.
This change is adding a default value for the PWM clock
(setup to CLK_PERIPH) to the PWM device node, allowing the
board specific DTS to only enable the PWM to get it work.
If the PWM clock output is not setup with a default value,
only enabling the PWM in the board specific DTS file is not
enough; the PWM divider will keep the default value of zero
(i.e. PWM clock off).
> --
> With best wishes,
> Vladimir
Sylvain
^ permalink raw reply
* arm64: kernel BUG at mm/page_alloc.c:1844!
From: Robert Richter @ 2016-10-05 14:13 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I am looking into a memory setup problem on ThunderX systems under
certain memory configurations. The symptom is
kernel BUG at mm/page_alloc.c:1848!
It happens for some configs with 64k page size enabled (at least since
4.5). The bug triggers for page zones with some pages in the zone not
assigned to this particular zone. In my case some pages that are
marked as nomap were not reassigned to the new zone of node 1, so
those are still assigned to node 0. Mark also reported something
similar for non-numa configs. I think this is a related problem where
not all pages of a zone have been reassigned to the new zone during
setup.
Now, the reason for the mis-configuration is a change in pfn_valid()
which reports pages marked nomap as invalid. In memmap_init_zone()
nomap-pages are not reassigned to that node (__init_single_pfn()).
I tried various changes to fix that, but without success so far:
a) I modified reserve_regions() to use memblock_reserve() instead of
memblock_mark_nomap(). This marked efi regions as reserved instead of
unmap. pfn_valid() now worked as before the nomap change. I could boot
the system but noticed the following malloc assertion which looks like
there is some mem corruption:
emacs: malloc.c:2395: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
Other than that the system looked ok so far.
I checked pfn used by the process with kmem:mm_page_alloc_zone_locked,
it looked correct with all pfn allocated from free memory, mem ranges
reported by efi as reserved were not used.
b) I found a quote that for sparsemem the entire memmap (all pages have a
struct *page) for single section (include/linux/mmzone.h):
"In SPARSEMEM, it is assumed that a valid section has a memmap for
the entire section."
So I implemented a arm64 private __early_pfn_valid() function that
uses memblock_is_memory() to setup all pages of a zone. I got the same
result as for a).
c) I modified (almost) all arch arm64 users of pfn_valid() to use
memblock_mark_nomap() instead of pfn_valid() and changed pfn_valid()
to use memblock_is_memory(). Same problem as a).
d) Enabling HOLES_IN_ZONE config option does not looks correct for
sparsemem, trying it anyway causes VM_BUG_ON_PAGE() in in line 1849
since (uninitialized) struct *page is accessed. This did not work
either.
I also noticed the efi ranges to be only 4k page aligned, I checked
reserved mem regions, its transformation to 64k alignment looked ok
too. See below for efi and memblock address ranges.
Is there anything else I could do here? Am I missing something? Could
the malloc assertion be another bug which was uncovered after fixing
the first? Any help is appreciated.
Thanks,
-Robert
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: System Table: 0x0000010fffffef18
[ 0.000000] efi: MemMap Address: 0x0000010ff788e018
[ 0.000000] efi: MemMap Size: 0x000006c0
[ 0.000000] efi: MemMap Desc. Size: 0x00000030
[ 0.000000] efi: MemMap Desc. Version: 0x00000001
[ 0.000000] efi: EFI v2.40 by Cavium Thunder cn88xx EFI ThunderX-Firmware-Release-1.22.10-0-g4e85766 Aug 24 2016 15:59:03
[ 0.000000] efi: ACPI=0xfffff000 ACPI 2.0=0xfffff014 SMBIOS 3.0=0x10ffafcf000
[ 0.000000] efi: Processing EFI memory map:
[ 0.000000] efi: 0x000001400000-0x00000147ffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000001480000-0x0000024affff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000024b0000-0x0000211fffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000021200000-0x00002121ffff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000021220000-0x0000fffecfff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x0000fffed000-0x0000ffff4fff [ACPI Reclaim Memory| | | | | | | | |WB|WT|WC|UC]*
[ 0.000000] efi: 0x0000ffff5000-0x0000ffff5fff [ACPI Memory NVS | | | | | | | | |WB|WT|WC|UC]*
[ 0.000000] efi: 0x0000ffff6000-0x0000ffffffff [ACPI Reclaim Memory| | | | | | | | |WB|WT|WC|UC]*
[ 0.000000] efi: 0x000100000000-0x000ff7ffffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000ff8000000-0x000ff801ffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000ff8020000-0x000fffa9cfff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x000fffa9d000-0x000fffffffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010000400000-0x010f8465ffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010f84660000-0x010f8568ffff [Loader Code | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010f85690000-0x010ff788afff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ff788b000-0x010ff788dfff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ff788e000-0x010ff7890fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ff7891000-0x010ff78adfff [Loader Code | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ff78ae000-0x010ff9e97fff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ff9e98000-0x010ff9f20fff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]*
[ 0.000000] efi: 0x010ff9f21000-0x010ffaeb5fff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ffaeb6000-0x010ffafc8fff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]*
[ 0.000000] efi: 0x010ffafc9000-0x010ffafccfff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]*
[ 0.000000] efi: 0x010ffafcd000-0x010ffaff4fff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]*
[ 0.000000] efi: 0x010ffaff5000-0x010ffb008fff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ffb009000-0x010ffeb6cfff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ffeb6d000-0x010ffec94fff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ffec95000-0x010fffe28fff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010fffe29000-0x010fffe3ffff [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010fffe40000-0x010fffe53fff [Loader Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010fffe54000-0x010ffffb8fff [Boot Code | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x010ffffb9000-0x010ffffccfff [Runtime Code |RUN| | | | | | | |WB|WT|WC|UC]*
[ 0.000000] efi: 0x010ffffcd000-0x010fffffefff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]*
[ 0.000000] efi: 0x010ffffff000-0x010fffffffff [Boot Data | | | | | | | | |WB|WT|WC|UC]
[ 0.000000] efi: 0x804000001000-0x804000001fff [Memory Mapped I/O |RUN| | | | | | | | | | |UC]
[ 0.000000] efi: 0x87e0d0001000-0x87e0d0001fff [Memory Mapped I/O |RUN| | | | | | | | | | |UC]
[ 0.000000] MEMBLOCK configuration:
[ 0.000000] memory size = 0x1ffe800000 reserved size = 0x36506a21
[ 0.000000] memory.cnt = 0x9
[ 0.000000] memory[0x0] [0x00000001400000-0x000000fffdffff], 0xfebe0000 bytes on node 0 flags: 0x0
[ 0.000000] memory[0x1] [0x000000fffe0000-0x000000ffffffff], 0x20000 bytes on node 0 flags: 0x4
[ 0.000000] memory[0x2] [0x00000100000000-0x00000fffffffff], 0xf00000000 bytes on node 0 flags: 0x0
[ 0.000000] memory[0x3] [0x00010000400000-0x00010ff9e8ffff], 0xff9a90000 bytes on node 1 flags: 0x0
[ 0.000000] memory[0x4] [0x00010ff9e90000-0x00010ff9f2ffff], 0xa0000 bytes on node 1 flags: 0x4
[ 0.000000] memory[0x5] [0x00010ff9f30000-0x00010ffaeaffff], 0xf80000 bytes on node 1 flags: 0x0
[ 0.000000] memory[0x6] [0x00010ffaeb0000-0x00010ffaffffff], 0x150000 bytes on node 1 flags: 0x4
[ 0.000000] memory[0x7] [0x00010ffb000000-0x00010ffffaffff], 0x4fb0000 bytes on node 1 flags: 0x0
[ 0.000000] memory[0x8] [0x00010ffffb0000-0x00010fffffffff], 0x50000 bytes on node 1 flags: 0x4
[ 0.000000] reserved.cnt = 0xd
[ 0.000000] reserved[0x0] [0x00000001480000-0x0000000248ffff], 0x1010000 bytes flags: 0x0
[ 0.000000] reserved[0x1] [0x00000021200000-0x00000021210536], 0x10537 bytes flags: 0x0
[ 0.000000] reserved[0x2] [0x000000c0000000-0x000000dfffffff], 0x20000000 bytes flags: 0x0
[ 0.000000] reserved[0x3] [0x00000ffbfb8000-0x00000ffffdffff], 0x4028000 bytes flags: 0x0
[ 0.000000] reserved[0x4] [0x00000ffffecb00-0x00000fffffffff], 0x13500 bytes flags: 0x0
[ 0.000000] reserved[0x5] [0x00010f856a0000-0x00010f92a6ffff], 0xd3d0000 bytes flags: 0x0
[ 0.000000] reserved[0x6] [0x00010ff7880000-0x00010ff788ffff], 0x10000 bytes flags: 0x0
[ 0.000000] reserved[0x7] [0x00010ffbce0000-0x00010fffceffff], 0x4010000 bytes flags: 0x0
[ 0.000000] reserved[0x8] [0x00010fffee6d80-0x00010ffff2fffb], 0x4927c bytes flags: 0x0
[ 0.000000] reserved[0x9] [0x00010ffff30000-0x00010ffffa000f], 0x70010 bytes flags: 0x0
[ 0.000000] reserved[0xa] [0x00010ffffae280-0x00010ffffaff7f], 0x1d00 bytes flags: 0x0
[ 0.000000] reserved[0xb] [0x00010ffffaffa0-0x00010ffffaffce], 0x2f bytes flags: 0x0
[ 0.000000] reserved[0xc] [0x00010ffffaffd0-0x00010ffffafffe], 0x2f bytes flags: 0x0
^ permalink raw reply
* [PATCH 1/2] ARM: exynos_defconfig: Enable exynos-gsc driver as module
From: Javier Martinez Canillas @ 2016-10-05 14:24 UTC (permalink / raw)
To: linux-arm-kernel
Exynos5 SoCs have a General SCALER (GSCALER) IP block that can be used
to do video streams scaling and color space conversions by hardware.
Enable support for its driver as a module so the GSCALER can be tested.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm/configs/exynos_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index c58f6841f8aa..79c415c33f69 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -155,6 +155,7 @@ CONFIG_VIDEO_EXYNOS4_FIMC_IS=m
CONFIG_V4L_MEM2MEM_DRIVERS=y
CONFIG_VIDEO_SAMSUNG_S5P_JPEG=m
CONFIG_VIDEO_SAMSUNG_S5P_MFC=m
+CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC=m
CONFIG_V4L_TEST_DRIVERS=y
CONFIG_DRM=y
CONFIG_DRM_EXYNOS=y
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM: multi_v7_defconfig: Enable exynos-gsc driver as module
From: Javier Martinez Canillas @ 2016-10-05 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475677469-1524-1-git-send-email-javier@osg.samsung.com>
Exynos5 SoCs have a General SCALER (GSCALER) IP block that can be used
to do video streams scaling and color space conversions by hardware.
Enable support for its driver as a module so the GSCALER can be tested.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 437d0740dec6..bd2f06d334e7 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -561,6 +561,7 @@ CONFIG_VIDEO_EXYNOS4_FIMC_IS=m
CONFIG_V4L_MEM2MEM_DRIVERS=y
CONFIG_VIDEO_SAMSUNG_S5P_JPEG=m
CONFIG_VIDEO_SAMSUNG_S5P_MFC=m
+CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC=m
CONFIG_VIDEO_STI_BDISP=m
CONFIG_VIDEO_RENESAS_JPU=m
CONFIG_VIDEO_RENESAS_VSP1=m
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: dts: marvell: Add definition for the Globalscale Marvell ESPRESSOBin Board
From: Romain Perier @ 2016-10-05 14:27 UTC (permalink / raw)
To: linux-arm-kernel
This adds a basic definition for this board.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
arch/arm64/boot/dts/marvell/Makefile | 1 +
.../boot/dts/marvell/armada-3720-espressobin.dts | 78 ++++++++++++++++++++++
2 files changed, 79 insertions(+)
create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index 308468d..392eeb6 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
# Mvebu SoC Family
dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-7040-db.dtb
always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
new file mode 100644
index 0000000..57035a3
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
@@ -0,0 +1,78 @@
+/*
+ * Device Tree file for Globalscale Marvell ESPRESSOBin Board
+ * Copyright (C) 2016 Marvell
+ *
+ * Romain Perier <romain.perier@free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "armada-372x.dtsi"
+
+/ {
+ model = "Globalscale Marvell ESPRESSOBin Board";
+ compatible = "globalscale,espressobin", "marvell,armada3720", "marvell,armada3710";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x00000000 0x00000000 0x20000000>;
+ };
+};
+
+&pcie0 {
+ status = "okay";
+};
+
+&sata {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&usb3 {
+ status = "okay";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v7 0/7] arm/arm64: vgic: Implement API for vGICv3 live migration
From: Vijay Kilari @ 2016-10-05 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474645482-28131-1-git-send-email-vijay.kilari@gmail.com>
Hi Marc, Christoffer,
Do you have any review comments on this patch set?.
Regards
Vijay
On Fri, Sep 23, 2016 at 9:14 PM, <vijay.kilari@gmail.com> wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>
> This patchset adds API for saving and restoring
> of VGICv3 registers to support live migration with new vgic feature.
> This API definition is as per version of VGICv3 specification
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>
> The patch 3 & 4 are picked from the Pavel's previous implementation.
> http://www.spinics.net/lists/kvm/msg122040.html
>
> v6 => v7:
> - Rename all patches heading from vgic-new to vgic
> - Moved caching of priority and ID bits from vgic global struct
> to vgic_cpu struct.
>
> v5 => v6:
> - Collated all register definitions to single patch (4)
> - Introduce macro to convert userspace MPIDR format to MPIDR reg format
> - Check on ICC_CTLR_EL1.CBPR value is made while accessing ICC_BPR1_EL1
> - Cached ich_vtr_el2 and guests priority and ID bits
> - Check on number of priority and ID bits when ICC_CTRL_EL1 write is made
> - Check is made on SRE bit for ICC_SRE_EL1 write
>
> v4 => v5:
> - ICC_CTLR_EL1 access is updated to reflect HW values
> - Updated ICC reg access mask and shift macros
> - Introduced patch 4 for VMCR changes
> - Other minor fixes.
> v3 => v4:
> - Rebased to latest code base
> - Moved vgic_uaccess() from vgic-mmio-v2.c to vgic-mmio.c
> - Dropped macro REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED_UACCESS
> - Dropped LE conversion for userspace access
> - Introduced vgic_uaccess_write_pending() for ISPENDR write
> - Change macro KVM_DEV_ARM_VGIC_V3_CPUID_MASK to KVM_DEV_ARM_VGIC_V3_MIDR_MASK
> - Refactored some code as common code.
> - Changed handing of ICC_* registers
> - Allowed ICC_SRE_EL1 read by userspace
> - Fixed KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_* macros
>
> v2 => v3:
> - Implemented separate API for ISPENDR and ICPENDR to
> read soft_pending instead of pending for level triggerred interrupts
> - Implemented ioctl KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO to access line level
> - Rebased on top of Christoffer's patch set
> http://www.spinics.net/lists/kvm/msg136840.html
>
> NOTE: GICD_STATUSR and GICR_STATUSR are implemented as RAZ/WI.
>
> v1 => v2:
> - The init sequence change patch is no more required.
> Fixed in patch 2 by using static vgic_io_dev regions structure instead
> of using dynamic allocation pointer.
> - Updated commit message of patch 4.
> - Dropped usage of union to manage 32-bit and 64-bit access in patch 1.
> Used local variable for 32-bit access.
> - Updated macro __ARM64_SYS_REG and ARM64_SYS_REG in
> arch/arm64/include/uapi/asm/kvm.h as per qemu requirements.
>
>
> Vijaya Kumar K (7):
> arm/arm64: vgic: Implement support for userspace access
> arm/arm64: vgic: Add distributor and redistributor access
> arm/arm64: vgic: Introduce find_reg_by_id()
> irqchip/gic-v3: Add missing system register definitions
> arm/arm64: vgic: Introduce VENG0 and VENG1 fields to vmcr struct
> arm/arm64: vgic: Implement VGICv3 CPU interface access
> arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl
>
> arch/arm64/include/uapi/asm/kvm.h | 13 ++
> arch/arm64/kvm/Makefile | 1 +
> arch/arm64/kvm/sys_regs.c | 22 ++-
> arch/arm64/kvm/sys_regs.h | 4 +
> include/kvm/arm_vgic.h | 9 +
> include/linux/irqchip/arm-gic-v3.h | 45 ++++-
> virt/kvm/arm/vgic/vgic-kvm-device.c | 224 +++++++++++++++++++++++--
> virt/kvm/arm/vgic/vgic-mmio-v2.c | 57 +------
> virt/kvm/arm/vgic/vgic-mmio-v3.c | 200 ++++++++++++++++++++--
> virt/kvm/arm/vgic/vgic-mmio.c | 149 ++++++++++++++++-
> virt/kvm/arm/vgic/vgic-mmio.h | 28 ++++
> virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 324 ++++++++++++++++++++++++++++++++++++
> virt/kvm/arm/vgic/vgic-v3.c | 18 +-
> virt/kvm/arm/vgic/vgic.h | 45 +++++
> 14 files changed, 1035 insertions(+), 104 deletions(-)
> create mode 100644 virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] clk: lpc32xx: fix pwm clock divider computation
From: Sylvain Lemieux @ 2016-10-05 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <78c1e683-ac17-437b-289f-113ea842f62b@mleia.com>
On Wed, 2016-10-05 at 05:38 +0300, Vladimir Zapolskiy wrote:
> Hi Sylvain,
>
> On 26.09.2016 21:44, Sylvain Lemieux wrote:
> > From: Sylvain Lemieux <slemieux@tycoint.com>
> >
> > A zero value in the PWM clock divider register
> > (PWM1_FREQ/PWM2_FREQ) turn off the PWM clock.
> >
> > The "CLK_DIVIDER_ALLOW_ZERO" option is used for hardware that handle
> > the zero divider by not modifying their clock input (i.e. bypass).
> > See "/include/linux/clk-provider.h" for details.
>
> the problem is that the divider value is not set to some non-zero
> value when the clock is enabled, right?
>
The "clk_divider_set_rate" function is working properly and
setup the divider properly. There is no need to perform any
special process when enabling or initializing the PWM clock.
The problem occur when the PWM is enable in the project specific
device tree and the PWM output clock is not explicitly setup.
With the actual implementation, the function that compute the
output rate, based on the actual divider, return the parent clock
rate, which is inaccurate, since the clock is off. The core driver
will than call the enable function, which should not take place.
This patch ensure that the compute output rate for the PWM clock
handle properly the special case for a 0 divider. By returning 0,
the core driver do not try to enable the clock, which is the
expected behavior.
I still think the current patch is the proper way to fix the
issue created by the "CLK_DIVIDER_ALLOW_ZERO" flag of the PWM clock.
> I think it does not matter if the clock rate value is set to parent
> clock rate or any other value when divider is 0 *and* clock is gated.
> Enabling or disabling a clock is a gate control, so I suggest two
> alternative options at your choice (my preference is option 2):
>
> 1) add a custom clk_pwm_gate_enable(), clk_pwm_gate_disable() and
> clk_pwm_gate_is_enabled() functions combined under lpc32xx_clk_pwm_gate_ops.
>
> Next instead of adding one more define for a single exception
> please reassign .ops for two PWM clocks in runtime in
> lpc32xx_clk_init() function before calling lpc32xx_clk_register()
> in a loop.
>
> But this option is too invasive, a simpler solution is below.
>
> 2) in lpc32xx_clk_init() before clock registrations check for zero
> dividers of PWM clocks, then if a divider is 0 and clock is gated
> set divider to 1, if the divider is 0 and clock is not gated then
> gate the clock and set divider to 1, in other cases do nothing.
>
> > Remove the CLK_DIVIDER_ALLOW_ZERO option and add support to handle
> > the clock rate computation of the PWM clock divider 0 value.
> >
> > Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
> > ---
> > Note:
> > * Should we include a new CLK_DIVIDER option for this case
> > (i.e. clock off when zero ) in "clk-provider.h"?
> >
> > drivers/clk/nxp/clk-lpc32xx.c | 52 +++++++++++++++++++++++++++++++++++++++----
> > 1 file changed, 48 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
> > index 34c9735..3ca3a14 100644
> > --- a/drivers/clk/nxp/clk-lpc32xx.c
> > +++ b/drivers/clk/nxp/clk-lpc32xx.c
> > @@ -959,6 +959,25 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
> > divider->flags);
> > }
> >
> > +static unsigned long clk_divider_pwm_recalc_rate(struct clk_hw *hw,
> > + unsigned long parent_rate)
> > +{
> > + struct lpc32xx_clk_div *divider = to_lpc32xx_div(hw);
> > + unsigned int val;
> > +
> > + regmap_read(clk_regmap, divider->reg, &val);
> > +
> > + val >>= divider->shift;
> > + val &= div_mask(divider->width);
> > +
> > + /* Handle 0 divider -> PWM clock is off. */
> > + if(val == 0)
>
> No space in front of the open parenthesis.
>
> > + return 0;
> > +
> > + return divider_recalc_rate(hw, parent_rate, val, divider->table,
> > + divider->flags);
> > +}
> > +
> > static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
> > unsigned long *prate)
> > {
> > @@ -999,6 +1018,12 @@ static const struct clk_ops lpc32xx_clk_divider_ops = {
> > .set_rate = clk_divider_set_rate,
> > };
> >
> > +static const struct clk_ops lpc32xx_clk_pwm_divider_ops = {
> > + .recalc_rate = clk_divider_pwm_recalc_rate,
> > + .round_rate = clk_divider_round_rate,
> > + .set_rate = clk_divider_set_rate,
> > +};
> > +
> > static u8 clk_mux_get_parent(struct clk_hw *hw)
> > {
> > struct lpc32xx_clk_mux *mux = to_lpc32xx_mux(hw);
> > @@ -1151,6 +1176,25 @@ struct clk_hw_proto {
> > }, \
> > }
> >
> > +#define LPC32XX_DEFINE_PWM_DIV(_idx, _reg, _shift, _width, _tab, _fl) \
> > +[CLK_PREFIX(_idx)] = { \
> > + .type = CLK_DIV, \
> > + { \
> > + .hw0 = { \
> > + .ops = &lpc32xx_clk_pwm_divider_ops, \
> > + { \
> > + .div = { \
> > + .reg = LPC32XX_CLKPWR_ ## _reg, \
> > + .shift = (_shift), \
> > + .width = (_width), \
> > + .table = (_tab), \
> > + .flags = (_fl), \
> > + }, \
> > + }, \
> > + }, \
> > + }, \
> > +}
> > +
> > #define LPC32XX_DEFINE_GATE(_idx, _reg, _bit, _flags) \
> > [CLK_PREFIX(_idx)] = { \
> > .type = CLK_GATE, \
> > @@ -1281,14 +1325,14 @@ static struct clk_hw_proto clk_hw_proto[LPC32XX_CLK_HW_MAX] = {
> > LPC32XX_DEFINE_GATE(MCPWM, TIMCLK_CTRL1, 6, 0),
> >
> > LPC32XX_DEFINE_MUX(PWM1_MUX, PWMCLK_CTRL, 1, 0x1, NULL, 0),
> > - LPC32XX_DEFINE_DIV(PWM1_DIV, PWMCLK_CTRL, 4, 4, NULL,
> > - CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO),
> > + LPC32XX_DEFINE_PWM_DIV(PWM1_DIV, PWMCLK_CTRL, 4, 4, NULL,
> > + CLK_DIVIDER_ONE_BASED),
> > LPC32XX_DEFINE_GATE(PWM1_GATE, PWMCLK_CTRL, 0, 0),
> > LPC32XX_DEFINE_COMPOSITE(PWM1, PWM1_MUX, PWM1_DIV, PWM1_GATE),
> >
> > LPC32XX_DEFINE_MUX(PWM2_MUX, PWMCLK_CTRL, 3, 0x1, NULL, 0),
> > - LPC32XX_DEFINE_DIV(PWM2_DIV, PWMCLK_CTRL, 8, 4, NULL,
> > - CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO),
> > + LPC32XX_DEFINE_PWM_DIV(PWM2_DIV, PWMCLK_CTRL, 8, 4, NULL,
> > + CLK_DIVIDER_ONE_BASED),
> > LPC32XX_DEFINE_GATE(PWM2_GATE, PWMCLK_CTRL, 2, 0),
> > LPC32XX_DEFINE_COMPOSITE(PWM2, PWM2_MUX, PWM2_DIV, PWM2_GATE),
> >
> >
>
> --
> With best wishes,
> Vladimir
Regards,
Sylvain
^ permalink raw reply
* [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
From: Jassi Brar @ 2016-10-05 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475670705.335.27.camel@mtksdaap41>
On 5 October 2016 at 18:01, Horng-Shyang Liao <hs.liao@mediatek.com> wrote:
> On Wed, 2016-10-05 at 09:07 +0530, Jassi Brar wrote:
>> On 5 October 2016 at 08:24, Horng-Shyang Liao <hs.liao@mediatek.com> wrote:
>> > On Fri, 2016-09-30 at 17:47 +0800, Horng-Shyang Liao wrote:
>> >> On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:
>>
>> >
>> > After I trace mailbox driver, I realize that CMDQ driver cannot use
>> > tx_done.
>> >
>> > CMDQ clients will flush many tasks into CMDQ driver, and then CMDQ
>> > driver will apply these tasks into GCE HW "immediately". These tasks,
>> > which are queued in GCE HW, may not execute immediately since they
>> > may need to wait event(s), e.g. vsync.
>> >
>> > However, in mailbox driver, mailbox uses a software buffer to queue
>> > sent messages. It only sends next message until previous message is
>> > done. This cannot fulfill CMDQ's requirement.
>> >
>> I understand
>> a) GCE HW can internally queue many tasks in some 'FIFO'
>> b) Execution of some task may have to wait until some external event
>> occurs (like vsync)
>> c) GCE does not generate irq/flag for each task executed (?)
>>
>> If so, may be your tx_done should return 'true' so long as the GCE HW
>> can accept tasks in its 'FIFO'. For mailbox api, any task that is
>> queued on GCE, is assumed to be transmitted.
>>
>> > Quote some code from mailbox driver. Please notice "active_req" part.
>> >
>> > static void msg_submit(struct mbox_chan *chan)
>> > {
>> > ...
>> > if (!chan->msg_count || chan->active_req)
>> > goto exit;
>> > ...
>> > err = chan->mbox->ops->send_data(chan, data);
>> > if (!err) {
>> > chan->active_req = data;
>> > chan->msg_count--;
>> > }
>> > ...
>> > }
>> >
>> > static void tx_tick(struct mbox_chan *chan, int r)
>> > {
>> > ...
>> > spin_lock_irqsave(&chan->lock, flags);
>> > mssg = chan->active_req;
>> > chan->active_req = NULL;
>> > spin_unlock_irqrestore(&chan->lock, flags);
>> > ...
>> > }
>> >
>> > Current workable CMDQ driver uses mbox_client_txdone() to prevent
>> > this issue, and then uses self callback functions to handle done tasks.
>> >
>> > int cmdq_task_flush_async(struct cmdq_client *client, struct cmdq_task
>> > *task, cmdq_async_flush_cb cb, void *data)
>> > {
>> > ...
>> > mbox_send_message(client->chan, task);
>> > /* We can send next task immediately, so just call txdone. */
>> > mbox_client_txdone(client->chan, 0);
>> > ...
>> > }
>> >
>> > Another solution is to use rx_callback; i.e. CMDQ mailbox controller
>> > call mbox_chan_received_data() when CMDQ task is done. But, this may
>> > violate the design of mailbox. What do you think?
>> >
>> If my point (c) above does not hold, maybe look at implementing
>> tx_done() callback and submit next task from the callback of last
>> done.
>
>
> Hi Jassi,
>
> For point (c), GCE irq means 1~n tasks done or
> 0~n tasks done + 1 task error.
> In irq, we can know which tasks are done by register and GCE pc.
>
> As I mentioned before, we cannot submit next task after previous task
> call tx_done. We need to submit multiple tasks to GCE HW immediately
> and queue them in GCE HW.
> Let me explain this requirement by mouse
> cursor example. User may move mouse quickly between two vsync, so DRM
> may update display registers frequently. For CMDQ, that means many tasks
> are flushed into CMDQ driver, and CMDQ driver needs to process all of
> them in next vblank. Therefore, we cannot block any CMDQ task in SW
> buffer.
>
We are interested only in the current position of cursor and not its
trail. Also the current position should be updated at next vsync (and
not the one after it).
Going by this example, if the GCE HW can take in 'N' tasks at a time,
then the N+1th submission should shift out (drop) the 1st task queued.
So that at any time GCE HW has only the latest N tasks. Right?
If yes, maybe you don't need to care about tx-done and simply keep
shoving tasks as you generate them.
If no, maybe your client driver need to emulate such a circular
buffer where oldest task is overwritten by newest submission. And you
submit the circular buffer (most relevant tasks) at one go to the GCE
HW.
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxbb: Add rmii pinctrl node and rename rgmii node
From: Neil Armstrong @ 2016-10-05 14:44 UTC (permalink / raw)
To: linux-arm-kernel
For boards only supporting 10/100 ethernet over a RMII PHY link, add
a separate pinctrl node. By the way, rename the existing node to rgmii
specific naming in all boards dts.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 17 ++++++++++++++++-
4 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index e6e3491..325b9c5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -83,7 +83,7 @@
ðmac {
status = "okay";
- pinctrl-0 = <ð_pins>;
+ pinctrl-0 = <ð_rgmii_pins>;
pinctrl-names = "default";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 06a34dc..031d69b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -81,7 +81,7 @@
ðmac {
status = "okay";
- pinctrl-0 = <ð_pins>;
+ pinctrl-0 = <ð_rgmii_pins>;
pinctrl-names = "default";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index 73f1593..e93221a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -82,7 +82,7 @@
ðmac {
status = "okay";
- pinctrl-0 = <ð_pins>;
+ pinctrl-0 = <ð_rgmii_pins>;
pinctrl-names = "default";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 443811b..aad639a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -443,7 +443,7 @@
};
};
- eth_pins: eth_c {
+ eth_rgmii_pins: eth-rgmii {
mux {
groups = "eth_mdio",
"eth_mdc",
@@ -463,6 +463,21 @@
};
};
+ eth_rmii_pins: eth-rmii {
+ mux {
+ groups = "eth_mdio",
+ "eth_mdc",
+ "eth_clk_rx_clk",
+ "eth_rx_dv",
+ "eth_rxd0",
+ "eth_rxd1",
+ "eth_tx_en",
+ "eth_txd0",
+ "eth_txd1";
+ function = "eth";
+ };
+ };
+
pwm_a_x_pins: pwm_a_x {
mux {
groups = "pwm_a_x";
--
1.9.1
^ permalink raw reply related
* [PATCH 00/15] improve function-level documentation
From: Julia Lawall @ 2016-10-05 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKMK7uHT3FutHQuQQ3iwXmYbidB3AOs7AxnpaJD4MTqy0-QehQ@mail.gmail.com>
On Wed, 5 Oct 2016, Daniel Vetter wrote:
> Jani Nikula has a patch with a scrip to make the one kernel-doc parser
> into a lint/checker pass over the entire kernel. I think that'd would
> be more robust instead of trying to approximate the real kerneldoc
> parser. Otoh that parser is a horror show of a perl/regex driven state
> machine ;-)
Sure. To my recollection, I found around 2000 issues. Many I ignored, eg
functions that simply have no documentation abuot the parameters,
functions that document their local variables, when these were more
interesting than the parameters etc. But the set of patches is not
exhaustive with respect to the remaining interesting ones either.
julia
>
> Jani, can you pls digg out these patches? Can't find them right now ...
> -Daniel
>
>
> On Sat, Oct 1, 2016 at 9:46 PM, Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> > These patches fix cases where the documentation above a function definition
> > is not consistent with the function header. Issues are detected using the
> > semantic patch below (http://coccinelle.lip6.fr/). Basically, the semantic
> > patch parses a file to find comments, then matches each function header,
> > and checks that the name and parameter list in the function header are
> > compatible with the comment that preceeds it most closely.
> >
> > // <smpl>
> > @initialize:ocaml@
> > @@
> >
> > let tbl = ref []
> > let fnstart = ref []
> > let success = Hashtbl.create 101
> > let thefile = ref ""
> > let parsed = ref []
> > let nea = ref []
> >
> > let parse file =
> > thefile := List.nth (Str.split (Str.regexp "linux-next/") file) 1;
> > let i = open_in file in
> > let startline = ref 0 in
> > let fn = ref "" in
> > let ids = ref [] in
> > let rec inside n =
> > let l = input_line i in
> > let n = n + 1 in
> > match Str.split_delim (Str.regexp_string "*/") l with
> > before::after::_ ->
> > (if not (!fn = "")
> > then tbl := (!startline,n,!fn,List.rev !ids)::!tbl);
> > startline := 0;
> > fn := "";
> > ids := [];
> > outside n
> > | _ ->
> > (match Str.split (Str.regexp "[ \t]+") l with
> > "*"::name::rest ->
> > let len = String.length name in
> > (if !fn = "" && len > 2 && String.sub name (len-2) 2 = "()"
> > then fn := String.sub name 0 (len-2)
> > else if !fn = "" && (not (rest = [])) && List.hd rest = "-"
> > then
> > if String.get name (len-1) = ':'
> > then fn := String.sub name 0 (len-1)
> > else fn := name
> > else if not(!fn = "") && len > 2 &&
> > String.get name 0 = '@' && String.get name (len-1) = ':'
> > then ids := (String.sub name 1 (len-2)) :: !ids);
> > | _ -> ());
> > inside n
> > and outside n =
> > let l = input_line i in
> > let n = n + 1 in
> > if String.length l > 2 && String.sub l 0 3 = "/**"
> > then
> > begin
> > startline := n;
> > inside n
> > end
> > else outside n in
> > try outside 0 with End_of_file -> ()
> >
> > let hashadd tbl k v =
> > let cell =
> > try Hashtbl.find tbl k
> > with Not_found ->
> > let cell = ref [] in
> > Hashtbl.add tbl k cell;
> > cell in
> > cell := v :: !cell
> >
> > @script:ocaml@
> > @@
> >
> > tbl := [];
> > fnstart := [];
> > Hashtbl.clear success;
> > parsed := [];
> > nea := [];
> > parse (List.hd (Coccilib.files()))
> >
> > @r@
> > identifier f;
> > position p;
> > @@
> >
> > f at p(...) { ... }
> >
> > @script:ocaml@
> > p << r.p;
> > f << r.f;
> > @@
> >
> > parsed := f :: !parsed;
> > fnstart := (List.hd p).line :: !fnstart
> >
> > @param@
> > identifier f;
> > type T;
> > identifier i;
> > parameter list[n] ps;
> > parameter list[n1] ps1;
> > position p;
> > @@
> >
> > f at p(ps,T i,ps1) { ... }
> >
> > @script:ocaml@
> > @@
> >
> > tbl := List.rev (List.sort compare !tbl)
> >
> > @script:ocaml@
> > p << param.p;
> > f << param.f;
> > @@
> >
> > let myline = (List.hd p).line in
> > let prevline =
> > List.fold_left
> > (fun prev x ->
> > if x < myline
> > then max x prev
> > else prev)
> > 0 !fnstart in
> > let _ =
> > List.exists
> > (function (st,fn,nm,ids) ->
> > if prevline < st && myline > st && prevline < fn && myline > fn
> > then
> > begin
> > (if not (String.lowercase f = String.lowercase nm)
> > then
> > Printf.printf "%s:%d %s doesn't match preceding comment: %s\n"
> > !thefile myline f nm);
> > true
> > end
> > else false)
> > !tbl in
> > ()
> >
> > @script:ocaml@
> > p << param.p;
> > n << param.n;
> > n1 << param.n1;
> > i << param.i;
> > f << param.f;
> > @@
> >
> > let myline = (List.hd p).line in
> > let prevline =
> > List.fold_left
> > (fun prev x ->
> > if x < myline
> > then max x prev
> > else prev)
> > 0 !fnstart in
> > let _ =
> > List.exists
> > (function (st,fn,nm,ids) ->
> > if prevline < st && myline > st && prevline < fn && myline > fn
> > then
> > begin
> > (if List.mem i ids then hashadd success (st,fn,nm) i);
> > (if ids = [] (* arg list seems not obligatory *)
> > then ()
> > else if not (List.mem i ids)
> > then
> > Printf.printf "%s:%d %s doesn't appear in ids: %s\n"
> > !thefile myline i (String.concat " " ids)
> > else if List.length ids <= n || List.length ids <= n1
> > then
> > (if not (List.mem f !nea)
> > then
> > begin
> > nea := f :: !nea;
> > Printf.printf "%s:%d %s not enough args\n" !thefile myline f;
> > end)
> > else
> > let foundid = List.nth ids n in
> > let efoundid = List.nth (List.rev ids) n1 in
> > if not(foundid = i || efoundid = i)
> > then
> > Printf.printf "%s:%d %s wrong arg in position %d: %s\n"
> > !thefile myline i n foundid);
> > true
> > end
> > else false)
> > !tbl in
> > ()
> >
> > @script:ocaml@
> > @@
> > List.iter
> > (function (st,fn,nm,ids) ->
> > if List.mem nm !parsed
> > then
> > let entry =
> > try !(Hashtbl.find success (st,fn,nm))
> > with Not_found -> [] in
> > List.iter
> > (fun id ->
> > if not (List.mem id entry) && not (id = "...")
> > then Printf.printf "%s:%d %s not used\n" !thefile st id)
> > ids)
> > !tbl
> > // </smpl>
> >
> >
> > ---
> >
> > drivers/clk/keystone/pll.c | 4 ++--
> > drivers/clk/sunxi/clk-mod0.c | 2 +-
> > drivers/clk/tegra/cvb.c | 10 +++++-----
> > drivers/dma-buf/sw_sync.c | 6 +++---
> > drivers/gpu/drm/gma500/intel_i2c.c | 3 +--
> > drivers/gpu/drm/omapdrm/omap_drv.c | 4 ++--
> > drivers/irqchip/irq-metag-ext.c | 1 -
> > drivers/irqchip/irq-vic.c | 1 -
> > drivers/mfd/tc3589x.c | 4 ++--
> > drivers/power/supply/ab8500_fg.c | 8 ++++----
> > drivers/power/supply/abx500_chargalg.c | 1 +
> > drivers/power/supply/intel_mid_battery.c | 2 +-
> > drivers/power/supply/power_supply_core.c | 4 ++--
> > fs/crypto/crypto.c | 4 ++--
> > fs/crypto/fname.c | 4 ++--
> > fs/ubifs/file.c | 2 +-
> > fs/ubifs/gc.c | 2 +-
> > fs/ubifs/lprops.c | 2 +-
> > fs/ubifs/lpt_commit.c | 4 +---
> > fs/ubifs/replay.c | 2 +-
> > lib/kobject_uevent.c | 6 +++---
> > lib/lru_cache.c | 4 ++--
> > lib/nlattr.c | 2 +-
> > 23 files changed, 39 insertions(+), 43 deletions(-)
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [RFC] arm64: Enforce observed order for spinlock and data
From: bdegraaf at codeaurora.org @ 2016-10-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004191159.GA32596@leverpostej>
On 2016-10-04 15:12, Mark Rutland wrote:
> Hi Brent,
>
> Could you *please* clarify if you are trying to solve:
>
> (a) a correctness issue (e.g. data corruption) seen in practice.
> (b) a correctness issue (e.g. data corruption) found by inspection.
> (c) A performance issue, seen in practice.
> (d) A performance issue, found by inspection.
>
> Any one of these is fine; we just need to know in order to be able to
> help effectively, and so far it hasn't been clear.
>
> On Tue, Oct 04, 2016 at 01:53:35PM -0400, bdegraaf at codeaurora.org
> wrote:
>> After looking at this, the problem is not with the lockref code per
>> se: it is a problem with arch_spin_value_unlocked(). In the
>> out-of-order case, arch_spin_value_unlocked() can return TRUE for a
>> spinlock that is in fact locked but the lock is not observable yet via
>> an ordinary load.
>
> Given arch_spin_value_unlocked() doesn't perform any load itself, I
> assume the ordinary load that you are referring to is the READ_ONCE()
> early in CMPXCHG_LOOP().
>
> It's worth noting that even if we ignore ordering and assume a
> sequentially-consistent machine, READ_ONCE() can give us a stale value.
> We could perform the read, then another agent can acquire the lock,
> then
> we can move onto the cmpxchg(), i.e.
>
> CPU0 CPU1
> old = READ_ONCE(x.lock_val)
> spin_lock(x.lock)
> cmpxchg(x.lock_val, old, new)
> spin_unlock(x.lock)
>
> If the 'old' value is stale, the cmpxchg *must* fail, and the cmpxchg
> should return an up-to-date value which we will then retry with.
>
>> Other than ensuring order on the locking side (as the prior patch
>> did), there is a way to make arch_spin_value_unlock's TRUE return
>> value deterministic,
>
> In general, this cannot be made deterministic. As above, there is a
> race
> that cannot be avoided.
>
>> but it requires that it does a write-back to the lock to ensure we
>> didn't observe the unlocked value while another agent was in process
>> of writing back a locked value.
>
> The cmpxchg gives us this guarantee. If it successfully stores, then
> the
> value it observed was the same as READ_ONCE() saw, and the update was
> atomic.
>
> There *could* have been an intervening sequence between the READ_ONCE
> and cmpxchg (e.g. put(); get()) but that's not problematic for lockref.
> Until you've taken your reference it was possible that things changed
> underneath you.
>
> Thanks,
> Mark.
Mark,
I found the problem.
Back in September of 2013, arm64 atomics were broken due to missing
barriers
in certain situations, but the problem at that time was undiscovered.
Will Deacon's commit d2212b4dce596fee83e5c523400bf084f4cc816c went in at
that
time and changed the correct cmpxchg64 in lockref.c to
cmpxchg64_relaxed.
d2212b4 appeared to be OK at that time because the additional barrier
requirements of this specific code sequence were not yet discovered, and
this change was consistent with the arm64 atomic code of that time.
Around February of 2014, some discovery led Will to correct the problem
with
the atomic code via commit 8e86f0b409a44193f1587e87b69c5dcf8f65be67,
which
has an excellent explanation of potential ordering problems with the
same
code sequence used by lockref.c.
With this updated understanding, the earlier commit
(d2212b4dce596fee83e5c523400bf084f4cc816c) should be reverted.
Because acquire/release semantics are insufficient for the full
ordering,
the single barrier after the store exclusive is the best approach,
similar
to Will's atomic barrier fix.
Best regards,
Brent
^ permalink raw reply
* [PATCH] ARM: dts: lpc32xx: add pwm-cells to base dts file
From: Sylvain Lemieux @ 2016-10-05 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474979658.10588.18.camel@localhost>
Hi Vladimir,
On Tue, 2016-09-27 at 08:34 -0400, Sylvain Lemieux (gmail) wrote:
> Hi Vladimir,
>
> On Tue, 2016-09-27 at 01:07 +0300, Vladimir Zapolskiy wrote:
> > Hi Sylvain,
> >
> > On 26.09.2016 21:47, Sylvain Lemieux wrote:
> > > From: Sylvain Lemieux <slemieux@tycoint.com>
> > >
> > > There is no need to define the "pwm-cells" in the board
> > > specific dts file; move the entry to the base dts file.
> > >
> > > Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
> > > ---
> > > Note:
> > > * This patch should be apply after
> > > "ARM: dts: lpc32xx: set default parent clock for pwm1 & pwm2"
> > > http://www.spinics.net/lists/arm-kernel/msg530277.html
> > > - There is no dependency between the patches.
> > >
> > > arch/arm/boot/dts/lpc32xx.dtsi | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> [...]
> >
> > that's something I have done locally and in a different manner, but I haven't
> > published it yet, please find below a draft.
> >
> > First of all from multiple places in the User's Manual you can find that there
> > are "two single output PWM blocks" or "the LPC32x0 provides two 8-bit PWMs" etc.
> >
> > In this case it does not make sense to set PWM cells to 2 (there is only one
> > channel), and 1 cell for frequency is good enough, and that's the proposed
> > change to support it:
> >
[..]
> >
> > What is your opinion about this proposal?
> >
> I agree with you, this clean-up make sense; the PWM cell should be 1.
>
> > If this change is applied, then lpc32xx.dtsi should contain #pwm-cells = <1>.
> >
> Can you submit your change on the mailing list?
> I will send a version 2 of this patch after.
>
> If it is helping, I can take care of submitting a patch
> to update the documentation (lpc32xx-pwm.txt).
>
Just doing a quick follow-up;
when do you think you can submit your change to the mailling list?
> > --
> > With best wishes,
> > Vladimir
>
> Sylvain
>
Regards,
Sylvain
^ permalink raw reply
* [PATCH 0/6] clk: oxnas: Rework driver to add support for OX820
From: Neil Armstrong @ 2016-10-05 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In order to to support the Oxford Semiconductor OX820 Soc clock gates,
rework the original driver with a structure inspired from the Qcom or Meson
drivers and using the new devm_clk_hw_register() call.
The first patches add dt-bindings include file to clarify the clock indices.
In future work, OX820 PLLs should also be handled by this driver.
Neil Armstrong (6):
clk: oxnas: Add dt-bindings include file for OX810SE
clk: oxnas: Add dt-bindings include file for OX820
clk: oxnas: Rename to clk_oxnas_gate
clk: oxnas: Refactor to make use of devm_clk_hw_register()
clk: oxnas: Add OX820 Gate clocks
dt-bindings: clk: oxnas,stdclk: Add OX820 bindings
.../devicetree/bindings/clock/oxnas,stdclk.txt | 19 +-
drivers/clk/clk-oxnas.c | 232 ++++++++++++++-------
include/dt-bindings/clock/oxsemi,ox810se.h | 30 +++
include/dt-bindings/clock/oxsemi,ox820.h | 40 ++++
4 files changed, 231 insertions(+), 90 deletions(-)
create mode 100644 include/dt-bindings/clock/oxsemi,ox810se.h
create mode 100644 include/dt-bindings/clock/oxsemi,ox820.h
--
2.7.0
^ permalink raw reply
* [PATCH 1/6] clk: oxnas: Add dt-bindings include file for OX810SE
From: Neil Armstrong @ 2016-10-05 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005150752.22618-1-narmstrong@baylibre.com>
In order to prepare support for the Oxford Semiconductor OX820, add
a dt-bindings include file used by the ox810se dtsi.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
include/dt-bindings/clock/oxsemi,ox810se.h | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 include/dt-bindings/clock/oxsemi,ox810se.h
diff --git a/include/dt-bindings/clock/oxsemi,ox810se.h b/include/dt-bindings/clock/oxsemi,ox810se.h
new file mode 100644
index 0000000..d5facb5
--- /dev/null
+++ b/include/dt-bindings/clock/oxsemi,ox810se.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef DT_CLOCK_OXSEMI_OX810SE_H
+#define DT_CLOCK_OXSEMI_OX810SE_H
+
+#define CLK_810_LEON 0
+#define CLK_810_DMA_SGDMA 1
+#define CLK_810_CIPHER 2
+#define CLK_810_SATA 3
+#define CLK_810_AUDIO 4
+#define CLK_810_USBMPH 5
+#define CLK_810_ETHA 6
+#define CLK_810_PCIEA 7
+#define CLK_810_NAND 8
+
+#endif /* DT_CLOCK_OXSEMI_OX810SE_H */
--
2.7.0
^ permalink raw reply related
* [PATCH 2/6] clk: oxnas: Add dt-bindings include file for OX820
From: Neil Armstrong @ 2016-10-05 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005150752.22618-1-narmstrong@baylibre.com>
In order to support the Oxford Semiconductor Gate clocks, add a
dedicated dt-binding include file for gate indexes.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
include/dt-bindings/clock/oxsemi,ox820.h | 40 ++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
create mode 100644 include/dt-bindings/clock/oxsemi,ox820.h
diff --git a/include/dt-bindings/clock/oxsemi,ox820.h b/include/dt-bindings/clock/oxsemi,ox820.h
new file mode 100644
index 0000000..f661ecc
--- /dev/null
+++ b/include/dt-bindings/clock/oxsemi,ox820.h
@@ -0,0 +1,40 @@
+/*
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef DT_CLOCK_OXSEMI_OX820_H
+#define DT_CLOCK_OXSEMI_OX820_H
+
+/* PLLs */
+#define CLK_820_PLLA 0
+#define CLK_820_PLLB 1
+
+/* Gate Clocks */
+#define CLK_820_LEON 2
+#define CLK_820_DMA_SGDMA 3
+#define CLK_820_CIPHER 4
+#define CLK_820_SD 5
+#define CLK_820_SATA 6
+#define CLK_820_AUDIO 7
+#define CLK_820_USBMPH 8
+#define CLK_820_ETHA 9
+#define CLK_820_PCIEA 10
+#define CLK_820_NAND 11
+#define CLK_820_PCIEB 12
+#define CLK_820_ETHB 13
+#define CLK_820_REF600 14
+#define CLK_820_USBDEV 15
+
+#endif /* DT_CLOCK_OXSEMI_OX820_H */
--
2.7.0
^ permalink raw reply related
* [PATCH 3/6] clk: oxnas: Rename to clk_oxnas_gate
From: Neil Armstrong @ 2016-10-05 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005150752.22618-1-narmstrong@baylibre.com>
Rename clock ops to clk_oxnas_gate in ops and structures.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/clk/clk-oxnas.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/clk/clk-oxnas.c b/drivers/clk/clk-oxnas.c
index 47649ac..a76c7fb 100644
--- a/drivers/clk/clk-oxnas.c
+++ b/drivers/clk/clk-oxnas.c
@@ -26,7 +26,7 @@
#include <linux/mfd/syscon.h>
/* Standard regmap gate clocks */
-struct clk_oxnas {
+struct clk_oxnas_gate {
struct clk_hw hw;
signed char bit;
struct regmap *regmap;
@@ -37,14 +37,14 @@ struct clk_oxnas {
#define CLK_SET_REGOFFSET 0x2c
#define CLK_CLR_REGOFFSET 0x30
-static inline struct clk_oxnas *to_clk_oxnas(struct clk_hw *hw)
+static inline struct clk_oxnas_gate *to_clk_oxnas_gate(struct clk_hw *hw)
{
- return container_of(hw, struct clk_oxnas, hw);
+ return container_of(hw, struct clk_oxnas_gate, hw);
}
-static int oxnas_clk_is_enabled(struct clk_hw *hw)
+static int oxnas_clk_gate_is_enabled(struct clk_hw *hw)
{
- struct clk_oxnas *std = to_clk_oxnas(hw);
+ struct clk_oxnas_gate *std = to_clk_oxnas_gate(hw);
int ret;
unsigned int val;
@@ -55,26 +55,26 @@ static int oxnas_clk_is_enabled(struct clk_hw *hw)
return val & BIT(std->bit);
}
-static int oxnas_clk_enable(struct clk_hw *hw)
+static int oxnas_clk_gate_enable(struct clk_hw *hw)
{
- struct clk_oxnas *std = to_clk_oxnas(hw);
+ struct clk_oxnas_gate *std = to_clk_oxnas_gate(hw);
regmap_write(std->regmap, CLK_SET_REGOFFSET, BIT(std->bit));
return 0;
}
-static void oxnas_clk_disable(struct clk_hw *hw)
+static void oxnas_clk_gate_disable(struct clk_hw *hw)
{
- struct clk_oxnas *std = to_clk_oxnas(hw);
+ struct clk_oxnas_gate *std = to_clk_oxnas_gate(hw);
regmap_write(std->regmap, CLK_CLR_REGOFFSET, BIT(std->bit));
}
-static const struct clk_ops oxnas_clk_ops = {
- .enable = oxnas_clk_enable,
- .disable = oxnas_clk_disable,
- .is_enabled = oxnas_clk_is_enabled,
+static const struct clk_ops oxnas_clk_gate_ops = {
+ .enable = oxnas_clk_gate_enable,
+ .disable = oxnas_clk_gate_disable,
+ .is_enabled = oxnas_clk_gate_is_enabled,
};
static const char *const oxnas_clk_parents[] = {
@@ -88,7 +88,7 @@ static const char *const eth_parents[] = {
#define DECLARE_STD_CLKP(__clk, __parent) \
static const struct clk_init_data clk_##__clk##_init = { \
.name = __stringify(__clk), \
- .ops = &oxnas_clk_ops, \
+ .ops = &oxnas_clk_gate_ops, \
.parent_names = __parent, \
.num_parents = ARRAY_SIZE(__parent), \
}
@@ -127,7 +127,7 @@ static const struct clk_oxnas_init_data clk_oxnas_init[] = {
};
struct clk_oxnas_data {
- struct clk_oxnas clk_oxnas[ARRAY_SIZE(clk_oxnas_init)];
+ struct clk_oxnas_gate clk_oxnas[ARRAY_SIZE(clk_oxnas_init)];
struct clk_onecell_data onecell_data[ARRAY_SIZE(clk_oxnas_init)];
struct clk *clks[ARRAY_SIZE(clk_oxnas_init)];
};
@@ -150,7 +150,7 @@ static int oxnas_stdclk_probe(struct platform_device *pdev)
}
for (i = 0; i < ARRAY_SIZE(clk_oxnas_init); i++) {
- struct clk_oxnas *_clk;
+ struct clk_oxnas_gate *_clk;
_clk = &clk_oxnas->clk_oxnas[i];
_clk->bit = clk_oxnas_init[i].bit;
--
2.7.0
^ permalink raw reply related
* [PATCH 4/6] clk: oxnas: Refactor to make use of devm_clk_hw_register()
From: Neil Armstrong @ 2016-10-05 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005150752.22618-1-narmstrong@baylibre.com>
Make usage of static tables identified by the OF match table to
feed devm_clk_hw_register() and use of_clk_add_hw_provider().
This structure is cleaner and simplifies adding new SoC support while
having common probe and gate ops code.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/clk/clk-oxnas.c | 148 +++++++++++++++++++++++++++---------------------
1 file changed, 84 insertions(+), 64 deletions(-)
diff --git a/drivers/clk/clk-oxnas.c b/drivers/clk/clk-oxnas.c
index a76c7fb..b1ef3ea9 100644
--- a/drivers/clk/clk-oxnas.c
+++ b/drivers/clk/clk-oxnas.c
@@ -20,18 +20,29 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/stringify.h>
#include <linux/regmap.h>
#include <linux/mfd/syscon.h>
+#include <dt-bindings/clock/oxsemi,ox810se.h>
+
/* Standard regmap gate clocks */
struct clk_oxnas_gate {
struct clk_hw hw;
- signed char bit;
+ unsigned int bit;
struct regmap *regmap;
};
+struct oxnas_stdclk_data {
+ struct clk_hw_onecell_data *onecell_data;
+ struct clk_oxnas_gate **gates;
+ unsigned int ngates;
+ struct clk_oxnas_pll **plls;
+ unsigned int nplls;
+};
+
/* Regmap offsets */
#define CLK_STAT_REGOFFSET 0x24
#define CLK_SET_REGOFFSET 0x2c
@@ -77,7 +88,7 @@ static const struct clk_ops oxnas_clk_gate_ops = {
.is_enabled = oxnas_clk_gate_is_enabled,
};
-static const char *const oxnas_clk_parents[] = {
+static const char *const osc_parents[] = {
"oscillator",
};
@@ -85,63 +96,81 @@ static const char *const eth_parents[] = {
"gmacclk",
};
-#define DECLARE_STD_CLKP(__clk, __parent) \
-static const struct clk_init_data clk_##__clk##_init = { \
- .name = __stringify(__clk), \
- .ops = &oxnas_clk_gate_ops, \
- .parent_names = __parent, \
- .num_parents = ARRAY_SIZE(__parent), \
+#define OXNAS_GATE(_name, _bit, _parents) \
+struct clk_oxnas_gate _name = { \
+ .bit = (_bit), \
+ .hw.init = &(struct clk_init_data) { \
+ .name = #_name, \
+ .ops = &oxnas_clk_gate_ops, \
+ .parent_names = _parents, \
+ .num_parents = ARRAY_SIZE(_parents), \
+ .flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED), \
+ }, \
}
-#define DECLARE_STD_CLK(__clk) DECLARE_STD_CLKP(__clk, oxnas_clk_parents)
+static OXNAS_GATE(ox810se_leon, 0, osc_parents);
+static OXNAS_GATE(ox810se_dma_sgdma, 1, osc_parents);
+static OXNAS_GATE(ox810se_cipher, 2, osc_parents);
+static OXNAS_GATE(ox810se_sata, 4, osc_parents);
+static OXNAS_GATE(ox810se_audio, 5, osc_parents);
+static OXNAS_GATE(ox810se_usbmph, 6, osc_parents);
+static OXNAS_GATE(ox810se_etha, 7, eth_parents);
+static OXNAS_GATE(ox810se_pciea, 8, osc_parents);
+static OXNAS_GATE(ox810se_nand, 9, osc_parents);
+
+static struct clk_oxnas_gate *ox810se_gates[] = {
+ &ox810se_leon,
+ &ox810se_dma_sgdma,
+ &ox810se_cipher,
+ &ox810se_sata,
+ &ox810se_audio,
+ &ox810se_usbmph,
+ &ox810se_etha,
+ &ox810se_pciea,
+ &ox810se_nand,
+};
-/* Hardware Bit - Clock association */
-struct clk_oxnas_init_data {
- unsigned long bit;
- const struct clk_init_data *clk_init;
+static struct clk_hw_onecell_data ox810se_hw_onecell_data = {
+ .hws = {
+ [CLK_810_LEON] = &ox810se_leon.hw,
+ [CLK_810_DMA_SGDMA] = &ox810se_dma_sgdma.hw,
+ [CLK_810_CIPHER] = &ox810se_cipher.hw,
+ [CLK_810_SATA] = &ox810se_sata.hw,
+ [CLK_810_AUDIO] = &ox810se_audio.hw,
+ [CLK_810_USBMPH] = &ox810se_usbmph.hw,
+ [CLK_810_ETHA] = &ox810se_etha.hw,
+ [CLK_810_PCIEA] = &ox810se_pciea.hw,
+ [CLK_810_NAND] = &ox810se_nand.hw,
+ },
+ .num = ARRAY_SIZE(ox810se_gates),
};
-/* Clk init data declaration */
-DECLARE_STD_CLK(leon);
-DECLARE_STD_CLK(dma_sgdma);
-DECLARE_STD_CLK(cipher);
-DECLARE_STD_CLK(sata);
-DECLARE_STD_CLK(audio);
-DECLARE_STD_CLK(usbmph);
-DECLARE_STD_CLKP(etha, eth_parents);
-DECLARE_STD_CLK(pciea);
-DECLARE_STD_CLK(nand);
-
-/* Table index is clock indice */
-static const struct clk_oxnas_init_data clk_oxnas_init[] = {
- [0] = {0, &clk_leon_init},
- [1] = {1, &clk_dma_sgdma_init},
- [2] = {2, &clk_cipher_init},
- /* Skip & Do not touch to DDR clock */
- [3] = {4, &clk_sata_init},
- [4] = {5, &clk_audio_init},
- [5] = {6, &clk_usbmph_init},
- [6] = {7, &clk_etha_init},
- [7] = {8, &clk_pciea_init},
- [8] = {9, &clk_nand_init},
+
+static struct oxnas_stdclk_data ox810se_stdclk_data = {
+ .onecell_data = &ox810se_hw_onecell_data,
+ .gates = ox810se_gates,
+ .ngates = ARRAY_SIZE(ox810se_gates),
};
-struct clk_oxnas_data {
- struct clk_oxnas_gate clk_oxnas[ARRAY_SIZE(clk_oxnas_init)];
- struct clk_onecell_data onecell_data[ARRAY_SIZE(clk_oxnas_init)];
- struct clk *clks[ARRAY_SIZE(clk_oxnas_init)];
+
+static const struct of_device_id oxnas_stdclk_dt_ids[] = {
+ { .compatible = "oxsemi,ox810se-stdclk", &ox810se_stdclk_data },
+ { }
};
static int oxnas_stdclk_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
- struct clk_oxnas_data *clk_oxnas;
+ const struct oxnas_stdclk_data *data;
+ const struct of_device_id *id;
struct regmap *regmap;
+ int ret;
int i;
- clk_oxnas = devm_kzalloc(&pdev->dev, sizeof(*clk_oxnas), GFP_KERNEL);
- if (!clk_oxnas)
- return -ENOMEM;
+ id = of_match_device(oxnas_stdclk_dt_ids, &pdev->dev);
+ if (!id)
+ return -ENODEV;
+ data = id->data;
regmap = syscon_node_to_regmap(of_get_parent(np));
if (IS_ERR(regmap)) {
@@ -149,32 +178,23 @@ static int oxnas_stdclk_probe(struct platform_device *pdev)
return PTR_ERR(regmap);
}
- for (i = 0; i < ARRAY_SIZE(clk_oxnas_init); i++) {
- struct clk_oxnas_gate *_clk;
+ for (i = 0 ; i < data->ngates ; ++i)
+ data->gates[i]->regmap = regmap;
- _clk = &clk_oxnas->clk_oxnas[i];
- _clk->bit = clk_oxnas_init[i].bit;
- _clk->hw.init = clk_oxnas_init[i].clk_init;
- _clk->regmap = regmap;
+ for (i = 0; i < data->onecell_data->num; i++) {
+ if (!data->onecell_data->hws[i])
+ continue;
- clk_oxnas->clks[i] =
- devm_clk_register(&pdev->dev, &_clk->hw);
- if (WARN_ON(IS_ERR(clk_oxnas->clks[i])))
- return PTR_ERR(clk_oxnas->clks[i]);
+ ret = devm_clk_hw_register(&pdev->dev,
+ data->onecell_data->hws[i]);
+ if (ret)
+ return ret;
}
- clk_oxnas->onecell_data->clks = clk_oxnas->clks;
- clk_oxnas->onecell_data->clk_num = ARRAY_SIZE(clk_oxnas_init);
-
- return of_clk_add_provider(np, of_clk_src_onecell_get,
- clk_oxnas->onecell_data);
+ return of_clk_add_hw_provider(np, of_clk_hw_onecell_get,
+ data->onecell_data);
}
-static const struct of_device_id oxnas_stdclk_dt_ids[] = {
- { .compatible = "oxsemi,ox810se-stdclk" },
- { }
-};
-
static struct platform_driver oxnas_stdclk_driver = {
.probe = oxnas_stdclk_probe,
.driver = {
--
2.7.0
^ permalink raw reply related
* [PATCH 5/6] clk: oxnas: Add OX820 Gate clocks
From: Neil Armstrong @ 2016-10-05 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005150752.22618-1-narmstrong@baylibre.com>
Add support for the Oxford Semiconductor OX820 SoC gate clocks
along the OX810SE SoC support.
This rework on concerns the gate clocks since they are different.
Future PLL handling code will be added for OX820.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/clk/clk-oxnas.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/drivers/clk/clk-oxnas.c b/drivers/clk/clk-oxnas.c
index b1ef3ea9..e51e002 100644
--- a/drivers/clk/clk-oxnas.c
+++ b/drivers/clk/clk-oxnas.c
@@ -27,6 +27,7 @@
#include <linux/mfd/syscon.h>
#include <dt-bindings/clock/oxsemi,ox810se.h>
+#include <dt-bindings/clock/oxsemi,ox820.h>
/* Standard regmap gate clocks */
struct clk_oxnas_gate {
@@ -130,6 +131,38 @@ static struct clk_oxnas_gate *ox810se_gates[] = {
&ox810se_nand,
};
+static OXNAS_GATE(ox820_leon, 0, osc_parents);
+static OXNAS_GATE(ox820_dma_sgdma, 1, osc_parents);
+static OXNAS_GATE(ox820_cipher, 2, osc_parents);
+static OXNAS_GATE(ox820_sd, 3, osc_parents);
+static OXNAS_GATE(ox820_sata, 4, osc_parents);
+static OXNAS_GATE(ox820_audio, 5, osc_parents);
+static OXNAS_GATE(ox820_usbmph, 6, osc_parents);
+static OXNAS_GATE(ox820_etha, 7, eth_parents);
+static OXNAS_GATE(ox820_pciea, 8, osc_parents);
+static OXNAS_GATE(ox820_nand, 9, osc_parents);
+static OXNAS_GATE(ox820_ethb, 10, eth_parents);
+static OXNAS_GATE(ox820_pcieb, 11, osc_parents);
+static OXNAS_GATE(ox820_ref600, 12, osc_parents);
+static OXNAS_GATE(ox820_usbdev, 13, osc_parents);
+
+static struct clk_oxnas_gate *ox820_gates[] = {
+ &ox820_leon,
+ &ox820_dma_sgdma,
+ &ox820_cipher,
+ &ox820_sd,
+ &ox820_sata,
+ &ox820_audio,
+ &ox820_usbmph,
+ &ox820_etha,
+ &ox820_pciea,
+ &ox820_nand,
+ &ox820_etha,
+ &ox820_pciea,
+ &ox820_ref600,
+ &ox820_usbdev,
+};
+
static struct clk_hw_onecell_data ox810se_hw_onecell_data = {
.hws = {
[CLK_810_LEON] = &ox810se_leon.hw,
@@ -145,6 +178,25 @@ static struct clk_hw_onecell_data ox810se_hw_onecell_data = {
.num = ARRAY_SIZE(ox810se_gates),
};
+static struct clk_hw_onecell_data ox820_hw_onecell_data = {
+ .hws = {
+ [CLK_820_LEON] = &ox820_leon.hw,
+ [CLK_820_DMA_SGDMA] = &ox820_dma_sgdma.hw,
+ [CLK_820_CIPHER] = &ox820_cipher.hw,
+ [CLK_820_SD] = &ox820_sd.hw,
+ [CLK_820_SATA] = &ox820_sata.hw,
+ [CLK_820_AUDIO] = &ox820_audio.hw,
+ [CLK_820_USBMPH] = &ox820_usbmph.hw,
+ [CLK_820_ETHA] = &ox820_etha.hw,
+ [CLK_820_PCIEA] = &ox820_pciea.hw,
+ [CLK_820_NAND] = &ox820_nand.hw,
+ [CLK_820_ETHB] = &ox820_ethb.hw,
+ [CLK_820_PCIEB] = &ox820_pcieb.hw,
+ [CLK_820_REF600] = &ox820_ref600.hw,
+ [CLK_820_USBDEV] = &ox820_usbdev.hw,
+ },
+ .num = ARRAY_SIZE(ox820_gates),
+};
static struct oxnas_stdclk_data ox810se_stdclk_data = {
.onecell_data = &ox810se_hw_onecell_data,
@@ -152,9 +204,15 @@ static struct oxnas_stdclk_data ox810se_stdclk_data = {
.ngates = ARRAY_SIZE(ox810se_gates),
};
+static struct oxnas_stdclk_data ox820_stdclk_data = {
+ .onecell_data = &ox820_hw_onecell_data,
+ .gates = ox820_gates,
+ .ngates = ARRAY_SIZE(ox820_gates),
+};
static const struct of_device_id oxnas_stdclk_dt_ids[] = {
{ .compatible = "oxsemi,ox810se-stdclk", &ox810se_stdclk_data },
+ { .compatible = "oxsemi,ox820-stdclk", &ox820_stdclk_data },
{ }
};
--
2.7.0
^ permalink raw reply related
* [PATCH 6/6] dt-bindings: clk: oxnas,stdclk: Add OX820 bindings
From: Neil Armstrong @ 2016-10-05 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005150752.22618-1-narmstrong@baylibre.com>
Add OX820 bindings and remove clock indices from bindings since they are present
in the dt-bindings headers files.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/clock/oxnas,stdclk.txt | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt b/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt
index 208cca6..b652f3f 100644
--- a/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt
+++ b/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt
@@ -5,22 +5,15 @@ Please also refer to clock-bindings.txt in this directory for common clock
bindings usage.
Required properties:
-- compatible: Should be "oxsemi,ox810se-stdclk"
+- compatible: For OX810SE, should be "oxsemi,ox810se-stdclk"
+ For OX820, should be "oxsemi,ox820-stdclk"
- #clock-cells: 1, see below
Parent node should have the following properties :
-- compatible: Should be "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
-
-For OX810SE, the clock indices are :
- - 0: LEON
- - 1: DMA_SGDMA
- - 2: CIPHER
- - 3: SATA
- - 4: AUDIO
- - 5: USBMPH
- - 6: ETHA
- - 7: PCIA
- - 8: NAND
+- compatible: For OX810SE, should be
+ "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
+ For OX820, should be
+ "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd"
example:
--
2.7.0
^ permalink raw reply related
* [RFC] arm64: Enforce observed order for spinlock and data
From: Peter Zijlstra @ 2016-10-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54b18de220f61747bf1c3cdf2a1b9447@codeaurora.org>
On Wed, Oct 05, 2016 at 10:55:57AM -0400, bdegraaf at codeaurora.org wrote:
> On 2016-10-04 15:12, Mark Rutland wrote:
> >Hi Brent,
> >
> >Could you *please* clarify if you are trying to solve:
> >
> >(a) a correctness issue (e.g. data corruption) seen in practice.
> >(b) a correctness issue (e.g. data corruption) found by inspection.
> >(c) A performance issue, seen in practice.
> >(d) A performance issue, found by inspection.
> >
> >Any one of these is fine; we just need to know in order to be able to
> >help effectively, and so far it hasn't been clear.
Brent, you forgot to state which: 'a-d' is the case here.
> I found the problem.
>
> Back in September of 2013, arm64 atomics were broken due to missing barriers
> in certain situations, but the problem at that time was undiscovered.
>
> Will Deacon's commit d2212b4dce596fee83e5c523400bf084f4cc816c went in at
> that
> time and changed the correct cmpxchg64 in lockref.c to cmpxchg64_relaxed.
>
> d2212b4 appeared to be OK at that time because the additional barrier
> requirements of this specific code sequence were not yet discovered, and
> this change was consistent with the arm64 atomic code of that time.
>
> Around February of 2014, some discovery led Will to correct the problem with
> the atomic code via commit 8e86f0b409a44193f1587e87b69c5dcf8f65be67, which
> has an excellent explanation of potential ordering problems with the same
> code sequence used by lockref.c.
>
> With this updated understanding, the earlier commit
> (d2212b4dce596fee83e5c523400bf084f4cc816c) should be reverted.
>
> Because acquire/release semantics are insufficient for the full ordering,
> the single barrier after the store exclusive is the best approach, similar
> to Will's atomic barrier fix.
This again does not in fact describe the problem.
What is the problem with lockref, and how (refer the earlier a-d
multiple choice answer) was this found.
Now, I have been looking, and we have some idea what you _might_ be
alluding to, but please explain which accesses get reordered how and
cause problems.
^ permalink raw reply
* [RFC] arm64: Enforce observed order for spinlock and data
From: bdegraaf at codeaurora.org @ 2016-10-05 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54b18de220f61747bf1c3cdf2a1b9447@codeaurora.org>
On 2016-10-05 10:55, bdegraaf at codeaurora.org wrote:
> On 2016-10-04 15:12, Mark Rutland wrote:
>> Hi Brent,
>>
>> Could you *please* clarify if you are trying to solve:
>>
>> (a) a correctness issue (e.g. data corruption) seen in practice.
>> (b) a correctness issue (e.g. data corruption) found by inspection.
>> (c) A performance issue, seen in practice.
>> (d) A performance issue, found by inspection.
>>
>> Any one of these is fine; we just need to know in order to be able to
>> help effectively, and so far it hasn't been clear.
>>
>> On Tue, Oct 04, 2016 at 01:53:35PM -0400, bdegraaf at codeaurora.org
>> wrote:
>>> After looking at this, the problem is not with the lockref code per
>>> se: it is a problem with arch_spin_value_unlocked(). In the
>>> out-of-order case, arch_spin_value_unlocked() can return TRUE for a
>>> spinlock that is in fact locked but the lock is not observable yet
>>> via
>>> an ordinary load.
>>
>> Given arch_spin_value_unlocked() doesn't perform any load itself, I
>> assume the ordinary load that you are referring to is the READ_ONCE()
>> early in CMPXCHG_LOOP().
>>
>> It's worth noting that even if we ignore ordering and assume a
>> sequentially-consistent machine, READ_ONCE() can give us a stale
>> value.
>> We could perform the read, then another agent can acquire the lock,
>> then
>> we can move onto the cmpxchg(), i.e.
>>
>> CPU0 CPU1
>> old = READ_ONCE(x.lock_val)
>> spin_lock(x.lock)
>> cmpxchg(x.lock_val, old, new)
>> spin_unlock(x.lock)
>>
>> If the 'old' value is stale, the cmpxchg *must* fail, and the cmpxchg
>> should return an up-to-date value which we will then retry with.
>>
>>> Other than ensuring order on the locking side (as the prior patch
>>> did), there is a way to make arch_spin_value_unlock's TRUE return
>>> value deterministic,
>>
>> In general, this cannot be made deterministic. As above, there is a
>> race
>> that cannot be avoided.
>>
>>> but it requires that it does a write-back to the lock to ensure we
>>> didn't observe the unlocked value while another agent was in process
>>> of writing back a locked value.
>>
>> The cmpxchg gives us this guarantee. If it successfully stores, then
>> the
>> value it observed was the same as READ_ONCE() saw, and the update was
>> atomic.
>>
>> There *could* have been an intervening sequence between the READ_ONCE
>> and cmpxchg (e.g. put(); get()) but that's not problematic for
>> lockref.
>> Until you've taken your reference it was possible that things changed
>> underneath you.
>>
>> Thanks,
>> Mark.
>
> Mark,
>
> I found the problem.
>
> Back in September of 2013, arm64 atomics were broken due to missing
> barriers
> in certain situations, but the problem at that time was undiscovered.
>
> Will Deacon's commit d2212b4dce596fee83e5c523400bf084f4cc816c went in
> at that
> time and changed the correct cmpxchg64 in lockref.c to
> cmpxchg64_relaxed.
>
> d2212b4 appeared to be OK at that time because the additional barrier
> requirements of this specific code sequence were not yet discovered,
> and
> this change was consistent with the arm64 atomic code of that time.
>
> Around February of 2014, some discovery led Will to correct the problem
> with
> the atomic code via commit 8e86f0b409a44193f1587e87b69c5dcf8f65be67,
> which
> has an excellent explanation of potential ordering problems with the
> same
> code sequence used by lockref.c.
>
> With this updated understanding, the earlier commit
> (d2212b4dce596fee83e5c523400bf084f4cc816c) should be reverted.
>
> Because acquire/release semantics are insufficient for the full
> ordering,
> the single barrier after the store exclusive is the best approach,
> similar
> to Will's atomic barrier fix.
>
> Best regards,
> Brent
FYI, this is a "b" type fix (correctness fix based on code inspection).
^ permalink raw reply
* [PATCH 02/11] DOCUMENTATION: dt-bindings: Document the STM32 USART bindings
From: Rob Herring @ 2016-10-05 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dd28f224-3e3b-0a00-f978-16861b946fd1@st.com>
On Wed, Oct 5, 2016 at 9:09 AM, Gerald Baeza <gerald.baeza@st.com> wrote:
> On 09/23/2016 05:29 PM, Rob Herring wrote:
>>
>> On Thu, Sep 15, 2016 at 06:42:34PM +0200, Alexandre TORGUE wrote:
>>>
>>> This adds documentation of device tree bindings for the
>>> STM32 USART
>>
>>
>> Please make your subject prefixes consistent and drop "DOCUMENTATION".
>>
>
> Ok, thanks
>
>>>
>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
>>> b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
>>> new file mode 100644
>>> index 0000000..75b1400
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
>>> @@ -0,0 +1,34 @@
>>> +* STMicroelectronics STM32 USART
>>> +
>>> +Required properties:
>>> +- compatible: Can be either "st,stm32-usart", "st,stm32-uart",
>>> +"st,stm32f7-usart" or "st,stm32f7-uart" depending on whether
>>> +the device supports synchronous mode and is compatible with
>>> +stm32(f4) or stm32f7.
>>
>>
>> Why not put f4 in the compatible string. stm32 is too generic.
>
>
> The initial binding is not in current kernel so it has been put in this
> serie as PATCH 07/11. It will be squashed with this one, as you requested.
>
> But the driver tty/serial/stm32-usart.c was already upstreamed and it
> already mentions the "st,stm32-usart" and "st,stm32-uart" for stm32f4 so I
> kept this as it for backward compatibility for those who already use the
> driver.
>
> I do not have the history to explain this inconsistency but can you confirm
> that keeping the existing compatible values from the driver is the good
> approach please?
Yes, keep it as it. Please reformat 1 valid combination per line.
>> What determines sync mode or not? If it is IP configuration fixed in the
>> design, then this is fine. If it is user choice or board dependent, then
>> use a separate property.
>
>
> This is IP configuration fixed in the design, indeed.
>
>>> +- reg: The address and length of the peripheral registers space
>>> +- interrupts: The interrupt line of the USART instance
>>> +- clocks: The input clock of the USART instance
>>> +
>>> +Optional properties:
>>> +- pinctrl: The reference on the pins configuration
>>> +- st,hw-flow-ctrl: bool flag to enable hardware flow control.
>>> +
>>> +Examples:
>>> +usart4: serial at 40004c00 {
>>> + compatible = "st,stm32-uart";
>>> + reg = <0x40004c00 0x400>;
>>> + interrupts = <52>;
>>> + clocks = <&clk_pclk1>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_usart4>;
>>> +};
>>> +
>>> +usart2: serial at 40004400 {
>>> + compatible = "st,stm32-usart", "st,stm32-uart";
>>
>>
>> What are valid combinations? usart is sync only, not sync and async?
>
>
> usart (sync and async) is a superset of uart (async).
> But the current driver does not use the synchronous mode, so the distinction
> is just here to be consistent with the reference manual instances naming (so
> configuration).
Okay, but this point is not clear in the compatible text. The
description should allow me to validate the example or a dts file.
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