* [PATCH 2/8] PM / Domain: Add residency property to genpd states
From: Lina Iyer @ 2016-10-05 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475699519-109623-1-git-send-email-lina.iyer@linaro.org>
Residency of a domain's idle state indicates that the minimum idle time
for the domain's idle state to be beneficial for power. Add the
parameter to the state node. Future patches, will use the residency
value in the genpd governor to determine if it is worth while to enter
an idle state.
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
include/linux/pm_domain.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index bd1ffb9..c113713 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -38,6 +38,7 @@ struct gpd_dev_ops {
struct genpd_power_state {
s64 power_off_latency_ns;
s64 power_on_latency_ns;
+ s64 residency_ns;
};
struct generic_pm_domain {
--
2.7.4
^ permalink raw reply related
* [PATCH 1/8] PM / Domains: Make genpd state allocation dynamic
From: Lina Iyer @ 2016-10-05 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475699519-109623-1-git-send-email-lina.iyer@linaro.org>
Allow PM Domain states to be defined dynamically by the drivers. This
removes the limitation on the maximum number of states possible for a
domain.
Cc: Axel Haslam <ahaslam+renesas@baylibre.com>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
arch/arm/mach-imx/gpc.c | 17 ++++++++++-------
drivers/base/power/domain.c | 10 ----------
include/linux/pm_domain.h | 4 +---
3 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index 0df062d..b92dad5 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -380,13 +380,6 @@ static struct pu_domain imx6q_pu_domain = {
.name = "PU",
.power_off = imx6q_pm_pu_power_off,
.power_on = imx6q_pm_pu_power_on,
- .states = {
- [0] = {
- .power_off_latency_ns = 25000,
- .power_on_latency_ns = 2000000,
- },
- },
- .state_count = 1,
},
};
@@ -430,6 +423,16 @@ static int imx_gpc_genpd_init(struct device *dev, struct regulator *pu_reg)
if (!IS_ENABLED(CONFIG_PM_GENERIC_DOMAINS))
return 0;
+ imx6q_pu_domain.base.states = devm_kzalloc(dev,
+ sizeof(*imx6q_pu_domain.base.states),
+ GFP_KERNEL);
+ if (!imx6q_pu_domain.base.states)
+ return -ENOMEM;
+
+ imx6q_pu_domain.base.states[0].power_off_latency_ns = 25000;
+ imx6q_pu_domain.base.states[0].power_on_latency_ns = 2000000;
+ mx6q_pu_domain.base.state_count = 1,
+
pm_genpd_init(&imx6q_pu_domain.base, NULL, false);
return of_genpd_add_provider_onecell(dev->of_node,
&imx_gpc_onecell_data);
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index e023066..740afa9 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1325,16 +1325,6 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
genpd->dev_ops.start = pm_clk_resume;
}
- if (genpd->state_idx >= GENPD_MAX_NUM_STATES) {
- pr_warn("Initial state index out of bounds.\n");
- genpd->state_idx = GENPD_MAX_NUM_STATES - 1;
- }
-
- if (genpd->state_count > GENPD_MAX_NUM_STATES) {
- pr_warn("Limiting states to %d\n", GENPD_MAX_NUM_STATES);
- genpd->state_count = GENPD_MAX_NUM_STATES;
- }
-
/* Use only one "off" state if there were no states declared */
if (genpd->state_count == 0)
genpd->state_count = 1;
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index a09fe5c..bd1ffb9 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -19,8 +19,6 @@
/* Defines used for the flags field in the struct generic_pm_domain */
#define GENPD_FLAG_PM_CLK (1U << 0) /* PM domain uses PM clk */
-#define GENPD_MAX_NUM_STATES 8 /* Number of possible low power states */
-
enum gpd_status {
GPD_STATE_ACTIVE = 0, /* PM domain is active */
GPD_STATE_POWER_OFF, /* PM domain is off */
@@ -70,7 +68,7 @@ struct generic_pm_domain {
void (*detach_dev)(struct generic_pm_domain *domain,
struct device *dev);
unsigned int flags; /* Bit field of configs for genpd */
- struct genpd_power_state states[GENPD_MAX_NUM_STATES];
+ struct genpd_power_state *states;
unsigned int state_count; /* number of states */
unsigned int state_idx; /* state that genpd will go to when off */
--
2.7.4
^ permalink raw reply related
* [PATCH 0/8] PM / Domains: DT support for domain idle states & atomic PM domains
From: Lina Iyer @ 2016-10-05 20:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This is the first set of patches of [1], sent now seperately. The CPU PM
domains part of the series is under discussion and was gating this set of
patches which have already been looked at by many and has no objections. Hence,
I split the series and sending out the PM domains changes now.
The patches [1 - 3] add DT support for reading domain idle states. The second
set of patches [4 - 8] enable PM domains to be used in atomic context.
The changes from [1] are -
- Allocating memory for domain idle states dynamically
- Conform to naming conventions for internal and exported genpd functions
- DT binding example for domain-idle-state
- Use fwnode instead of of_node
- Handle atomic case for removal of PM Domain
- Rebase on top of Rafael's pm/genpd tree
Thanks,
Lina
Lina Iyer (8):
PM / Domains: Make genpd state allocation dynamic
PM / Domain: Add residency property to genpd states
PM / Domains: Allow domain power states to be read from DT
PM / Domains: Add fwnode provider to genpd states
dt/bindings: Update binding for PM domain idle states
PM / Domains: Abstract genpd locking
PM / Domains: Support IRQ safe PM domains
PM / doc: Update device documentation for devices in IRQ safe PM
domains
.../devicetree/bindings/power/power_domain.txt | 36 +++
Documentation/power/devices.txt | 12 +-
arch/arm/mach-imx/gpc.c | 17 +-
drivers/base/power/domain.c | 338 +++++++++++++++++----
include/linux/pm_domain.h | 27 +-
5 files changed, 360 insertions(+), 70 deletions(-)
--
2.7.4
[1]. https://www.spinics.net/lists/arm-kernel/msg526814.html
^ permalink raw reply
* kernel-doc-rst-lint (was: Re: [PATCH 00/15] improve function-level documentation)
From: Julia Lawall @ 2016-10-05 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87h98quc1w.fsf@intel.com>
On Wed, 5 Oct 2016, Jani Nikula wrote:
> 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.
No, my work doesn't fix anything. Coccinelle can't actually process
comments. I just correlated the parsed comment with the function header.
julia
>
> 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
> --
> 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
* [PATCH v2] arm: Added support for getcpu() vDSO using TPIDRURW
From: Mark Rutland @ 2016-10-05 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKdL+dS4_My6hyMEGNc65mzDapia_tMiVzZ9DMw=ddZM+XiwAw@mail.gmail.com>
On Wed, Oct 05, 2016 at 02:25:22PM +0200, Fredrik Markstr?m wrote:
> On Tue, Oct 4, 2016 at 7:08 PM Mark Rutland <mark.rutland@arm.com> wrote:
> > On Tue, Oct 04, 2016 at 05:35:33PM +0200, Fredrik Markstrom wrote:
> The way I was trying to defend the breakage was by reasoning that that if it
> was an ABI we broke it both with a4780ad and with 6a1c531, and since we don't
> break ABI:s, it can't be one.
Prior to commit 6a1c531, other programs and/or cpuidle could have corrupted
TPIDRURW to arbitrary values at any point in time, so it couldn't have been
relied upon.
Arguably, someone could have (ab)used TPIDRURW between commits 6a1c531 and
a4780ad to detect context switches, but in practice they don't appear to have,
and we know of an established user relying on the current behaviour.
For better or worse, the current behaviour is ABI.
> > I was under the impression that other mechanisms were being considered
> > for fast userspace access to per-cpu data structures, e.g. restartable
> > sequences. What is the state of those? Why is this better?
> >
> > If getcpu() specifically is necessary, is there no other way to
> > implement it?
>
> If you are referring to the user space stuff can probably be implemented
> other ways, it's just convenient since the interface is there and it will
> speed up stuff like lttng without modifications (well, except glibc). It's
> also already implemented as a vDSO on other major architectures (like x86,
> x86_64, ppc32 and ppc64).
>
> If you are referring to the implementation of the vdso call, there are other
> possibilities, but I haven't found any that doesn't introduce overhead in
> context switching.
>
> But if TPIDRURW is definitely a no go, I can work on a patch that does this
> with a thread notifier and the vdso data page. Would that be a viable option?
As pointed out, that won't work for SMP, but perhaps we can come up with
something that does.
> > > +notrace int __vdso_getcpu(unsigned int *cpup, unsigned int *nodep,
> > > + struct getcpu_cache *tcache)
> > > +{
> > > + unsigned long node_and_cpu;
> > > +
> > > + asm("mrc p15, 0, %0, c13, c0, 2\n" : "=r"(node_and_cpu));
> > > +
> > > + if (nodep)
> > > + *nodep = cpu_to_node(node_and_cpu >> 16);
> > > + if (cpup)
> > > + *cpup = node_and_cpu & 0xffffUL;
> >
> > Given this is directly user-accessible, this format is a de-facto ABI,
> > even if it's not documented as such. Is this definitely the format you
> > want long-term?
>
> Yes, this (the interface) is indeed the important part and therefore I tried
> not to invent anything on my own. This is the interface used by ppc32,
> ppc64, x86, x86_64. It's also this is how the getcpu(2) system call is
> documented.
I was referring to the value in TPIDRURW specifically. If an application
started reading that directly (rather than going through the vDSO), we wouldn't
be able to change the register value in future.
That's all moot, given we can't repurpose TPIDRURW.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2] arm: Added support for getcpu() vDSO using TPIDRURW
From: Russell King - ARM Linux @ 2016-10-05 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50e025e0-7052-9b15-3b3e-36d1d9dfd695@arm.com>
On Wed, Oct 05, 2016 at 06:48:05PM +0100, Robin Murphy wrote:
> On 05/10/16 17:39, Fredrik Markstr?m wrote:
> > The approach I suggested below with the vDSO data page will obviously
> > not work on smp, so suggestions are welcome.
>
> Well, given that it's user-writeable, is there any reason an application
> which cares couldn't simply run some per-cpu threads to call getcpu()
> once and cache the result in TPIDRURW themselves? That would appear to
> both raise no compatibility issues and work with existing kernels.
There is - the contents of TPIDRURW is thread specific, and it moves
with the thread between CPU cores. So, if a thread was running on CPU0
when it cached the getcpu() value in TPIDRURW, and then migrated to CPU1,
TPIDRURW would still contain 0.
I'm also not in favour of changing the TPIDRURW usage to be a storage
repository for the CPU number - it's far too specific a usage and seems
like a waste of hardware resources to solve one problem. As Mark says,
it's an ABI breaking change too, even if it is under a config option.
Take a moment to consider distro kernels: how should they set this
config option - should they enable it to get faster getcpu() or should
they disable it to retain existing compatibility to prevent userspace
breakage. Who can advise them to make the right decision? Kernel
developers can't, because the usage of this register is purely a
userspace issue right now, and kernels devs don't know what use it's
been put to.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v2] arm: Added support for getcpu() vDSO using TPIDRURW
From: Robin Murphy @ 2016-10-05 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKdL+dTGDqgpnMTkAj=N4cY-cZF_U+bkH1v1vUA4umZoSbWHKQ@mail.gmail.com>
On 05/10/16 17:39, Fredrik Markstr?m wrote:
> The approach I suggested below with the vDSO data page will obviously
> not work on smp, so suggestions are welcome.
Well, given that it's user-writeable, is there any reason an application
which cares couldn't simply run some per-cpu threads to call getcpu()
once and cache the result in TPIDRURW themselves? That would appear to
both raise no compatibility issues and work with existing kernels.
Robin.
> /Fredrik
>
>
> On Wed, Oct 5, 2016 at 2:25 PM, Fredrik Markstr?m
> <fredrik.markstrom@gmail.com> wrote:
>> On Tue, Oct 4, 2016 at 7:08 PM Mark Rutland <mark.rutland@arm.com> wrote:
>>>
>>> On Tue, Oct 04, 2016 at 05:35:33PM +0200, Fredrik Markstrom wrote:
>>>> This makes getcpu() ~1000 times faster, this is very useful when
>>>> implementing per-cpu buffers in userspace (to avoid cache line
>>>> bouncing). As an example lttng ust becomes ~30% faster.
>>>>
>>>> The patch will break applications using TPIDRURW (which is context switched
>>>> since commit 4780adeefd042482f624f5e0d577bf9cdcbb760 ("ARM: 7735/2:
>>>
>>> It looks like you dropped the leading 'a' from the commit ID. For
>>> everyone else's benefit, the full ID is:
>>>
>>> a4780adeefd042482f624f5e0d577bf9cdcbb760
>>
>>
>> Sorry for that and thanks for fixing it.
>>
>>>
>>>
>>> Please note that arm64 has done similar for compat tasks since commit:
>>>
>>> d00a3810c16207d2 ("arm64: context-switch user tls register tpidr_el0 for
>>> compat tasks")
>>>
>>>> Preserve the user r/w register TPIDRURW on context switch and fork")) and
>>>> is therefore made configurable.
>>>
>>> As you note above, this is an ABI break and *will* break some existing
>>> applications. That's generally a no-go.
>>
>>
>> Ok, I wasn't sure this was considered an ABI (but I'm not entirely
>> surprised ;) ). The way I was
>> trying to defend the breakage was by reasoning that that if it was an
>> ABI we broke it both with a4780ad
>> and with 6a1c531, and since we don't break ABI:s, it can't be one.
>>
>> But hey, I'm humble here and ready to back off.
>>
>>>
>>> This also leaves arm64's compat with the existing behaviour, differing
>>> from arm.
>>>
>>> I was under the impression that other mechanisms were being considered
>>> for fast userspace access to per-cpu data structures, e.g. restartable
>>> sequences. What is the state of those? Why is this better?
>>>
>>> If getcpu() specifically is necessary, is there no other way to
>>> implement it?
>>
>> If you are referring to the user space stuff can probably be
>> implemented other ways,
>> it's just convenient since the interface is there and it will speed up
>> stuff like lttng without
>> modifications (well, except glibc). It's also already implemented as a
>> vDSO on other
>> major architectures (like x86, x86_64, ppc32 and ppc64).
>>
>> If you are referring to the implementation of the vdso call, there are
>> other possibilities, but
>> I haven't found any that doesn't introduce overhead in context switching.
>>
>> But if TPIDRURW is definitely a no go, I can work on a patch that does
>> this with a thread notifier
>> and the vdso data page. Would that be a viable option ?
>>
>>>
>>>> +notrace int __vdso_getcpu(unsigned int *cpup, unsigned int *nodep,
>>>> + struct getcpu_cache *tcache)
>>>> +{
>>>> + unsigned long node_and_cpu;
>>>> +
>>>> + asm("mrc p15, 0, %0, c13, c0, 2\n" : "=r"(node_and_cpu));
>>>> +
>>>> + if (nodep)
>>>> + *nodep = cpu_to_node(node_and_cpu >> 16);
>>>> + if (cpup)
>>>> + *cpup = node_and_cpu & 0xffffUL;
>>>
>>> Given this is directly user-accessible, this format is a de-facto ABI,
>>> even if it's not documented as such. Is this definitely the format you
>>> want long-term?
>>
>> Yes, this (the interface) is indeed the important part and therefore I
>> tried not to invent anything
>> on my own.
>> This is the interface used by ppc32, ppc64, x86, x86_64. It's also this is
>> how the getcpu(2) system call is documented.
>>
>> /Fredrik
>>
>>
>>>
>>>
>>> Thanks,
>>> Mark.
>
>
>
^ permalink raw reply
* [PATCH] efi/arm: fix absolute relocation detection for older toolchains
From: Ard Biesheuvel @ 2016-10-05 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004213045.GT16071@codeblueprint.co.uk>
On 4 October 2016 at 22:30, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Tue, 04 Oct, at 11:34:31AM, Ard Biesheuvel wrote:
>>
>> These relocations are harmless, since the debug ones are only
>> interpreted by the debugger, and the ones generated by
>> EXPORT_SYMBOL(sort) will never be referenced, since the symbols they
>> contain are either renamed to __efistub_xxx (arm64), or they are not
>> part of the kernel proper (arm)
>>
>> So both cases are false positives, but the diagnostic is important,
>> and so breaking the build is appropriate for any other absolute
>> relocation that may appear.
>>
>> The effect of the patch is not that the diagnostic is ignored, but
>> that these relocations are not generated in the first place (-g0) or
>> removed explicitly (ksymtab/krcrctab+sort) rather than via a wildcard.
>> So other than not breaking the build, this patch should have no user
>> observeable differences.
>
> Thanks Ard, sounds reasonable. Feel free to take this through
> whichever tree you think is best.
>
> Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
Thanks Matt.
Arnd: could you take this on top of the patch that adds CONFIG_EFI to
multi_v7_defconfig? That would minimize the breakage, I think.
^ permalink raw reply
* kernel-doc-rst-lint (was: Re: [PATCH 00/15] improve function-level documentation)
From: Markus Heiser @ 2016-10-05 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87h98quc1w.fsf@intel.com>
Am 05.10.2016 um 16:04 schrieb Jani Nikula <jani.nikula@linux.intel.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.
Another lint alternative:
use the lint from the linuxdoc project
install the linuxdoc package:
* https://return42.github.io/linuxdoc/install.html
e.g.::
pip install --user git+http://github.com/return42/linuxdoc.git
and run kernel-lintdoc with the file/folder to lint as argument / e.g.::
kernel-lintdoc include/media/
-- Markus --
>
>
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" 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
* [PATCH v14 0/9] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
From: Fu Wei @ 2016-10-05 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5efae47c-e9b8-a93a-a040-a38fc388390f@huawei.com>
Hi Xiongfeng Wang,
On 30 September 2016 at 08:40, Xiongfeng Wang <wangxiongfeng2@huawei.com> wrote:
> for sbsa watchdog part, Tested-by: wangxiongfeng2 at huawei.com on D05 board.
Got it, thanks again for your help
>
> On 2016/9/29 2:17, fu.wei at linaro.org wrote:
>> From: Fu Wei <fu.wei@linaro.org>
>>
>> This patchset:
>> (1)Preparation for adding GTDT support in arm_arch_timer:
>> 1. Move some enums and marcos to header file;
>> 2. Add a new enum for spi type;
>> 3. Improve printk relevant code.
>>
>> (2)Introduce ACPI GTDT parser: drivers/acpi/arm64/acpi_gtdt.c
>> Parse all kinds of timer in GTDT table of ACPI:arch timer,
>> memory-mapped timer and SBSA Generic Watchdog timer.
>> This driver can help to simplify all the relevant timer drivers,
>> and separate all the ACPI GTDT knowledge from them.
>>
>> (3)Simplify ACPI code for arm_arch_timer
>>
>> (4)Add GTDT support for ARM memory-mapped timer, also refactor
>> original memory-mapped timer dt support for reusing some common
>> code.
>>
>> This patchset depends on the following patchset:
>> [UPDATE PATCH V11 1/8] ACPI: I/O Remapping Table (IORT) initial support
>> https://lkml.org/lkml/2016/9/12/949
>>
>> This patchset has been tested on the following platforms:
>> (1)ARM Foundation v8 model
>>
>> Changelog:
>> v14: https://lkml.org/lkml/2016/9/28/
>> Separate memory-mapped timer GTDT support into two patches
>> 1. Refactor the timer init code to prepare for GTDT
>> 2. Add GTDT support for memory-mapped timer
>>
>> v13: http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1231717.html
>> Improve arm_arch_timer code for memory-mapped
>> timer GTDT support, refactor original memory-mapped timer
>> dt support for reusing some common code.
>>
>> v12: https://lkml.org/lkml/2016/9/13/250
>> Rebase to latest Linux 4.8-rc6
>> Delete the confusing "skipping" in the error message.
>>
>> V11: https://lkml.org/lkml/2016/9/6/354
>> Rebase to latest Linux 4.8-rc5
>> Delete typedef (suggested by checkpatch.pl)
>>
>> V10: https://lkml.org/lkml/2016/7/26/215
>> Drop the "readq" patch.
>> Rebase to latest Linux 4.7.
>>
>> V9: https://lkml.org/lkml/2016/7/25/345
>> Improve pr_err message in acpi gtdt driver.
>> Update Commit message for 7/9
>> shorten the irq mapping function name
>> Improve GTDT driver for memory-mapped timer
>>
>> v8: https://lkml.org/lkml/2016/7/19/660
>> Improve "pr_fmt(fmt)" definition: add "ACPI" in front of "GTDT",
>> and also improve printk message.
>> Simplify is_timer_block and is_watchdog.
>> Merge acpi_gtdt_desc_init and gtdt_arch_timer_init into acpi_gtdt_init();
>> Delete __init in include/linux/acpi.h for GTDT API
>> Make ARM64 select GTDT.
>> Delete "#include <linux/module.h>" from acpi_gtdt.c
>> Simplify GT block parse code.
>>
>> v7: https://lkml.org/lkml/2016/7/13/769
>> Move the GTDT driver to drivers/acpi/arm64
>> Add add the ARM64-specific ACPI Support maintainers in MAINTAINERS
>> Merge 3 patches of GTDT parser driver.
>> Fix the for_each_platform_timer bug.
>>
>> v6: https://lkml.org/lkml/2016/6/29/580
>> split the GTDT driver to 4 parts: basic, arch_timer, memory-mapped timer,
>> and SBSA Generic Watchdog timer
>> Improve driver by suggestions and example code from Daniel Lezcano
>>
>> v5: https://lkml.org/lkml/2016/5/24/356
>> Sorting out all patches, simplify the API of GTDT driver:
>> GTDT driver just fills the data struct for arm_arch_timer driver.
>>
>> v4: https://lists.linaro.org/pipermail/linaro-acpi/2016-March/006667.html
>> Delete the kvm relevant patches
>> Separate two patches for sorting out the code for arm_arch_timer.
>> Improve irq info export code to allow missing irq info in GTDT table.
>>
>> v3: https://lkml.org/lkml/2016/2/1/658
>> Improve GTDT driver code:
>> (1)improve pr_* by defining pr_fmt(fmt)
>> (2)simplify gtdt_sbsa_gwdt_init
>> (3)improve gtdt_arch_timer_data_init, if table is NULL, it will try
>> to get GTDT table.
>> Move enum ppi_nr to arm_arch_timer.h, and add enum spi_nr.
>> Add arm_arch_timer get ppi from DT and GTDT support for kvm.
>>
>> v2: https://lkml.org/lkml/2015/12/2/10
>> Rebase to latest kernel version(4.4-rc3).
>> Fix the bug about the config problem,
>> use CONFIG_ACPI_GTDT instead of CONFIG_ACPI in arm_arch_timer.c
>>
>> v1: The first upstreaming version: https://lkml.org/lkml/2015/10/28/553
>>
>> Fu Wei (9):
>> clocksource/drivers/arm_arch_timer: Move enums and defines to header
>> file
>> clocksource/drivers/arm_arch_timer: Add a new enum for spi type
>> clocksource/drivers/arm_arch_timer: Improve printk relevant code
>> acpi/arm64: Add GTDT table parse driver
>> clocksource/drivers/arm_arch_timer: Simplify ACPI support code.
>> acpi/arm64: Add memory-mapped timer support in GTDT driver
>> clocksource/drivers/arm_arch_timer: Refactor the timer init code to
>> prepare for GTDT
>> clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped
>> timer
>> acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver
>>
>> arch/arm64/Kconfig | 1 +
>> drivers/acpi/arm64/Kconfig | 3 +
>> drivers/acpi/arm64/Makefile | 1 +
>> drivers/acpi/arm64/gtdt.c | 309 ++++++++++++++++++++++++++++++++
>> drivers/clocksource/Kconfig | 2 +-
>> drivers/clocksource/arm_arch_timer.c | 331 +++++++++++++++++++++--------------
>> drivers/watchdog/Kconfig | 1 +
>> include/clocksource/arm_arch_timer.h | 32 ++++
>> include/linux/acpi.h | 7 +
>> 9 files changed, 558 insertions(+), 129 deletions(-)
>> create mode 100644 drivers/acpi/arm64/gtdt.c
>>
>
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* Coresight ETF trace dump failed in Juno r1 with 4.8-rc8
From: Suzuki K Poulose @ 2016-10-05 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGhh56GeZkLT=sN4cEhUJMeuz+ZD6jMnU2sbb3yRVLESUcWrtg@mail.gmail.com>
On 05/10/16 06:27, Venkatesh Vivekanandan wrote:
> On Tue, Oct 4, 2016 at 7:59 PM, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
>> On 04/10/16 06:37, Venkatesh Vivekanandan wrote:
>>>
>>> On Mon, Oct 3, 2016 at 6:44 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>
>>>> Hi Venkatesh,
>>>>
>>>> On 03/10/16 12:36, Venkatesh Vivekanandan wrote:
>>>>>
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I am trying to collect ETF trace from Juno R1 and could see "cpu
>>>>> stall" while dumping the trace. Attached is the log of sequence
>>>>> followed. Was trying to collect the trace data from hardware and see
>>>>> if it is any valid data. Am I missing anything here?.
>>>>>
>>>>
>>>> There are few fixes from me and Suzuki queued for v4.9.
>>>> Can you check if this issue persists even on linux-next ?
>>>
>>>
>>> Issue is the same in linux-next as well. Please find the attached log.
>>>
>>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>>> [ 120.009698] INFO: rcu_preempt detected stalls on CPUs/tasks:
>>> [ 120.015307] 2-...: (1 GPs behind) idle=f11/140000000000000/0
>>> softirq=224/224 fqs=1903
>>> [ 120.023226] (detected by 1, t=5255 jiffies, g=-1, c=-2, q=19)
>>> [ 120.029001] Task dump for CPU 2:
>>> [ 120.032190] dd R running task 0 1270 1267
>>> 0x00000002
>>> [ 120.039172] Call trace:
>>> [ 120.041594] [<ffff000008085534>] __switch_to+0xc8/0xd4
>>> [ 120.046675] [<0000000000020000>] 0x20000
>>>
>>> Steps followed,
>>> # git clone
>>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>>> linux-next
>>> # cd linux-next
>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig <---
>>> enable coresight
>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 Image
>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs
>>> # arch/arm64/boot/Image <--- copied this kernel
>>> # arch/arm64/boot/dts/arm/juno-r1.dtb <--- copied this dtb
>>>
>>> Top commit in linux-next is,
>>>
>>> commit c7d3b912180a9bb0733e5cfab84e5a7493dd3599
>>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
>>> Date: Tue Oct 4 14:52:03 2016 +1100
>>>
>>> Add linux-next specific files for 20161004
>>
>>
>> Can't reproduce it here either.
>>
>> root at localhost:/sys/bus/coresight/devices# echo 1 > 20010000.etf/enable_sink
>> root at localhost:/sys/bus/coresight/devices# echo 1 >
>> 22140000.etm/enable_source
>> root at localhost:/sys/bus/coresight/devices# dd if=/dev/20010000.etf bs=1
>> of=/root/etr.bin
>> 65536+0 records in
>> 65536+0 records out
>> 65536 bytes (66 kB) copied, 0.227546 s, 288 kB/s
>> root at localhost:/sys/bus/coresight/devices# dd if=/dev/20010000.etf bs=1
>> of=/root/etr.bin
>> 65536+0 records in
>> 65536+0 records out
>> 65536 bytes (66 kB) copied, 0.233527 s, 281 kB/s
>> root at localhost:/sys/bus/coresight/devices# echo 0 > 20010000.etf/enable_sink
>> root at localhost:/sys/bus/coresight/devices# dd if=/dev/20010000.etf bs=1
>> of=/root/etr.bin
>> 65536+0 records in
>> 65536+0 records out
>> 65536 bytes (66 kB) copied, 0.474943 s, 138 kB/s
>>
>> FWIW, here is my firmware version :
>>
>> NOTICE: Booting Trusted Firmware
>> NOTICE: BL1: v1.1(release):e04723e21362
>> NOTICE: BL1: Built : 15:39:56, Sep 1 2015
>> NOTICE: BL1: Booting BL2
>> NOTICE: BL2: v1.1(release):e04723e21362
>> NOTICE: BL2: Built : 15:42:30, Sep 1 2015
>> NOTICE: BL1: Booting BL3-1
>> NOTICE: BL3-1: v1.1(release):604d5da6f2aa
>> NOTICE: BL3-1: Built : 14:50:36, Sep 10 2015
>> UEFI firmware (version ea31f8e built at 16:35:17 on Aug 5 2015)
>>
>
> Hang is seen while trying to dump trace _after_ disabling the ETM
> source. Is it not supposed to work?.
> It works fine, when dumped before disabling ETM source. Please find
> the log below.
>
> linaro-test [rc=0]# echo 1 > 20010000.etf/enable_sink
> linaro-test [rc=0]# echo 1 > 22140000.etm/enable_source
> [ 91.792145] coresight-tmc 20010000.etf: TMC-ETB/ETF enabled
> [ 91.797719] coresight-funnel 20040000.main-funnel: FUNNEL inport 0 enabled
> [ 91.804552] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
> inport 1 enabled
> [ 91.815990] coresight-etm4x 22140000.etm: ETM tracing enabled
> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
> [ 108.105492] coresight-tmc 20010000.etf: TMC read start
> [ 108.404335] coresight-tmc 20010000.etf: TMC read end
> 65536+0 records in
> 65536+0 records out
> linaro-test [rc=0]# echo 0 > 20010000.etf/enable_sink
> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
> [ 125.069740] coresight-tmc 20010000.etf: TMC read start
> [ 125.184370] coresight-tmc 20010000.etf: TMC read end
> 65536+0 records in
> 65536+0 records out
> linaro-test [rc=0]# echo 0 > 22140000.etm/enable_source
> [ 140.271163] coresight-etm4x 22140000.etm: ETM tracing disabled
> [ 140.276964] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
> inport 1 disabled
> [ 140.284211] coresight-funnel 20040000.main-funnel: FUNNEL inport 0 disabled
> [ 140.291128] coresight-tmc 20010000.etf: TMC-ETB/ETF disabled
> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
> <---- It hangs here...
The point is once you disable the source, which eventually disables
all the components upto the sink, the data in the ETF is already captured
into a buffer, so there is no coresight hardware access involved.
Also, looks like the open(/dev/20010000.etf,..) from the dd didn't complete,
as we don't see a "TMC read start" line.
Could you please :
a) Try the patch [0] and see if it helps ?
b) If a doesn't help, after disabling the source, run any other command
instead of the trace collection. e.g,
dd if=/dev/zero of=/dev/null
and see if it hangs the system in a similar way ?
Thanks
Suzuki
[0] test patch
----8>----
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index 1ffdab8..ef72ed8 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -511,13 +511,6 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
goto out;
}
- /* There is no point in reading a TMC in HW FIFO mode */
- mode = readl_relaxed(drvdata->base + TMC_MODE);
- if (mode != TMC_MODE_CIRCULAR_BUFFER) {
- ret = -EINVAL;
- goto out;
- }
-
/* Don't interfere if operated from Perf */
if (drvdata->mode == CS_MODE_PERF) {
ret = -EINVAL;
^ permalink raw reply related
* [PATCH 1/1] ARM: at91/dt: sama5d2: enable FIFOs for high-speed i2c controllers
From: Cyrille Pitchen @ 2016-10-05 16:53 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables the RX and TX FIFOs (16 data each) of the two
high-speed i2c controllers (i2c0 and i2c1).
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
---
arch/arm/boot/dts/sama5d2.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index 35bf72d57f7c..20e5bc182c2d 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -1052,6 +1052,7 @@
#address-cells = <1>;
#size-cells = <0>;
clocks = <&twi0_clk>;
+ atmel,fifo-size = <16>;
status = "disabled";
};
@@ -1253,6 +1254,7 @@
#address-cells = <1>;
#size-cells = <0>;
clocks = <&twi1_clk>;
+ atmel,fifo-size = <16>;
status = "disabled";
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/6] Support PWM polarity control
From: Stefan Agner @ 2016-10-05 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004094805.466ebc6d@jawa>
Hi Lukasz,
On 2016-10-04 00:48, Lukasz Majewski wrote:
> Dear Bhuvanchandra,
>
> Thank you for your effort to send those patches to ML.
>
>> Changes since v2:
>>
>> - Picked the stalled patchset[1] from Lothar Wassmann which adds the
>> basic support for polarity control on imx-pwm driver and adds
>> backward compatibility support for devices which does not have
>> polarity control feature.
>>
>> Changes since Lothars v6:
>>
>> - Squash Lukasz patch[2].
>>
>> [1] http://thread.gmane.org/gmane.linux.pwm/1621
>> [2] https://www.spinics.net/lists/arm-kernel/msg530818.html
>>
>> Bhuvanchandra DV (3):
>> arm: dts: imx7: Update #pwm-cells for PWM polarity control
>> arm: dts: imx7-colibri: Use pwm polarity control
>> arm: dts: imx7-colibri: Use enable-gpios for BL_ON
>>
>> Lothar Wassmann (3):
>> pwm: print error messages with pr_err() instead of pr_debug()
>> pwm: core: make the PWM_POLARITY flag in DTB optional
>> pwm: imx: support output polarity inversion
>
> For some reason this patchset works differently than the one developed
> by Lothar.
>
> The difference is with the brightness level control.
>
> My brightness definition in DTS:
>
> pwms = <&pwm2 0 5000000 PWM_POLARITY_INVERTED>;
>
> brightness-levels = < 0 1 2 3 4 5 6 7 8 9
>
> .. ............
> 250 251 252 253 254 255>;
> default-brightness-level = <50>;
> enable-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
>
If you are using something else than i.MX 7 you also want to update the
SoC level device tree, specifically change the pwm-cells property:
#pwm-cells = <3>;
> When I go to the backlight sysfs entry:
>
> cd /sys/devices/soc0/backlight/backlight/backlight
>
> It seems like the brightness level control is inverted - i.e.
> 'echo 20 > brightness" makes picture on the screen very bright, and
> 'echo 200 > brightness' makes the picture diminish.
>
> With my "internal" patches the situation is opposite (and I've checked it with
> my HW connections).
Just to check whether the driver actually applies the polarity you can
add a #define DEBUG at the top of the driver (drivers/pwm/pwm-imx.c) and
pass ignore_loglevel as kernel command line. This should give you "PWM
supports output inversion" at startup and a "... polarity set to .."
message whenever the polarity is set.
--
Stefan
>
> Could you check on your setup if similar situation takes place? I mean
> if the brightness control works as expected?
>
> Thanks in advance,
> ?ukasz Majewski
>
>>
>> Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +--
>> arch/arm/boot/dts/imx7-colibri.dtsi | 12 +++++-
>> arch/arm/boot/dts/imx7s.dtsi | 8 ++--
>> drivers/pwm/core.c | 31 ++++++++------
>> drivers/pwm/pwm-imx.c | 51
>> +++++++++++++++++++++-- 5 files changed, 83 insertions(+), 25
>> deletions(-)
>>
^ permalink raw reply
* [PATCH 5/7] arm64/kvm: hyp: tlb: use __tlbi() helper
From: Matthias Brugger @ 2016-10-05 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473761769-30572-6-git-send-email-punit.agrawal@arm.com>
On 13/09/16 12:16, Punit Agrawal wrote:
> From: Mark Rutland <mark.rutland@arm.com>
>
> Now that we have a __tlbi() helper, make use of this in the arm64 KVM hyp
> code to get rid of asm() boilerplate. At the same time, we simplify
> __tlb_flush_vm_context by using __flush_icache_all(), as this has the
> appropriate instruction cache maintenance and barrier.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> [ rename tlbi -> __tlbi, convert additional sites, update commit log ]
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
> arch/arm64/kvm/hyp/tlb.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/tlb.c b/arch/arm64/kvm/hyp/tlb.c
> index be8177c..4cda100 100644
> --- a/arch/arm64/kvm/hyp/tlb.c
> +++ b/arch/arm64/kvm/hyp/tlb.c
> @@ -16,6 +16,7 @@
> */
>
> #include <asm/kvm_hyp.h>
> +#include <asm/tlbflush.h>
>
> static void __hyp_text __tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
> {
> @@ -32,7 +33,7 @@ static void __hyp_text __tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
> * whole of Stage-1. Weep...
> */
> ipa >>= 12;
> - asm volatile("tlbi ipas2e1is, %0" : : "r" (ipa));
> + __tlbi(ipas2e1is, ipa);
>
> /*
> * We have to ensure completion of the invalidation at Stage-2,
> @@ -41,7 +42,7 @@ static void __hyp_text __tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
> * the Stage-1 invalidation happened first.
> */
> dsb(ish);
> - asm volatile("tlbi vmalle1is" : : );
> + __tlbi(vmalle1is);
> dsb(ish);
> isb();
>
> @@ -60,7 +61,7 @@ static void __hyp_text __tlb_flush_vmid(struct kvm *kvm)
> write_sysreg(kvm->arch.vttbr, vttbr_el2);
> isb();
>
> - asm volatile("tlbi vmalls12e1is" : : );
> + __tlbi(vmalls12e1is);
> dsb(ish);
> isb();
>
> @@ -72,9 +73,8 @@ __alias(__tlb_flush_vmid) void __kvm_tlb_flush_vmid(struct kvm *kvm);
> static void __hyp_text __tlb_flush_vm_context(void)
> {
> dsb(ishst);
> - asm volatile("tlbi alle1is \n"
> - "ic ialluis ": : );
> - dsb(ish);
> + __tlbi(alle1is);
> + __flush_icache_all(); /* contains a dsb(ish) */
> }
>
> __alias(__tlb_flush_vm_context) void __kvm_flush_vm_context(void);
>
^ permalink raw reply
* [PATCH v2] arm: Added support for getcpu() vDSO using TPIDRURW
From: Fredrik Markström @ 2016-10-05 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKdL+dS4_My6hyMEGNc65mzDapia_tMiVzZ9DMw=ddZM+XiwAw@mail.gmail.com>
The approach I suggested below with the vDSO data page will obviously
not work on smp, so suggestions are welcome.
/Fredrik
On Wed, Oct 5, 2016 at 2:25 PM, Fredrik Markstr?m
<fredrik.markstrom@gmail.com> wrote:
> On Tue, Oct 4, 2016 at 7:08 PM Mark Rutland <mark.rutland@arm.com> wrote:
>>
>> On Tue, Oct 04, 2016 at 05:35:33PM +0200, Fredrik Markstrom wrote:
>> > This makes getcpu() ~1000 times faster, this is very useful when
>> > implementing per-cpu buffers in userspace (to avoid cache line
>> > bouncing). As an example lttng ust becomes ~30% faster.
>> >
>> > The patch will break applications using TPIDRURW (which is context switched
>> > since commit 4780adeefd042482f624f5e0d577bf9cdcbb760 ("ARM: 7735/2:
>>
>> It looks like you dropped the leading 'a' from the commit ID. For
>> everyone else's benefit, the full ID is:
>>
>> a4780adeefd042482f624f5e0d577bf9cdcbb760
>
>
> Sorry for that and thanks for fixing it.
>
>>
>>
>> Please note that arm64 has done similar for compat tasks since commit:
>>
>> d00a3810c16207d2 ("arm64: context-switch user tls register tpidr_el0 for
>> compat tasks")
>>
>> > Preserve the user r/w register TPIDRURW on context switch and fork")) and
>> > is therefore made configurable.
>>
>> As you note above, this is an ABI break and *will* break some existing
>> applications. That's generally a no-go.
>
>
> Ok, I wasn't sure this was considered an ABI (but I'm not entirely
> surprised ;) ). The way I was
> trying to defend the breakage was by reasoning that that if it was an
> ABI we broke it both with a4780ad
> and with 6a1c531, and since we don't break ABI:s, it can't be one.
>
> But hey, I'm humble here and ready to back off.
>
>>
>> This also leaves arm64's compat with the existing behaviour, differing
>> from arm.
>>
>> I was under the impression that other mechanisms were being considered
>> for fast userspace access to per-cpu data structures, e.g. restartable
>> sequences. What is the state of those? Why is this better?
>>
>> If getcpu() specifically is necessary, is there no other way to
>> implement it?
>
> If you are referring to the user space stuff can probably be
> implemented other ways,
> it's just convenient since the interface is there and it will speed up
> stuff like lttng without
> modifications (well, except glibc). It's also already implemented as a
> vDSO on other
> major architectures (like x86, x86_64, ppc32 and ppc64).
>
> If you are referring to the implementation of the vdso call, there are
> other possibilities, but
> I haven't found any that doesn't introduce overhead in context switching.
>
> But if TPIDRURW is definitely a no go, I can work on a patch that does
> this with a thread notifier
> and the vdso data page. Would that be a viable option ?
>
>>
>> > +notrace int __vdso_getcpu(unsigned int *cpup, unsigned int *nodep,
>> > + struct getcpu_cache *tcache)
>> > +{
>> > + unsigned long node_and_cpu;
>> > +
>> > + asm("mrc p15, 0, %0, c13, c0, 2\n" : "=r"(node_and_cpu));
>> > +
>> > + if (nodep)
>> > + *nodep = cpu_to_node(node_and_cpu >> 16);
>> > + if (cpup)
>> > + *cpup = node_and_cpu & 0xffffUL;
>>
>> Given this is directly user-accessible, this format is a de-facto ABI,
>> even if it's not documented as such. Is this definitely the format you
>> want long-term?
>
> Yes, this (the interface) is indeed the important part and therefore I
> tried not to invent anything
> on my own.
> This is the interface used by ppc32, ppc64, x86, x86_64. It's also this is
> how the getcpu(2) system call is documented.
>
> /Fredrik
>
>
>>
>>
>> Thanks,
>> Mark.
--
/Fredrik
^ permalink raw reply
* [PATCH v2] ARM: dts: rockchip: Reserve unusable memory region on rk3066
From: =?UTF-8?q?Pawe=C5=82=20Jarosz?= @ 2016-10-05 16:18 UTC (permalink / raw)
To: linux-arm-kernel
For some reason accessing memory region above 0x9F000000 freezes
system on rk3066. There is similiar bug on later rockchip soc (rk3288)
solved same way.
Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
---
Changes in v2:
- updated commit message.
arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 0d0dae3..44c8956 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -93,6 +93,19 @@
};
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ /*
+ * The rk3066 cannot use the memory area above 0x9F000000
+ * for some unknown reason.
+ */
+ unusable at 9F000000 {
+ reg = <0x9F000000 0x1000000>;
+ };
+ };
+
i2s0: i2s at 10118000 {
compatible = "rockchip,rk3066-i2s";
reg = <0x10118000 0x2000>;
--
2.7.4
^ permalink raw reply related
* [PATCH] mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
From: Hans de Goede @ 2016-10-05 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005155112.13774-1-hdegoede@redhat.com>
The i2c subsys does not load modules by compatible, only by
i2c-id, with e.g. a modalias of: "i2c:axp209".
Populate the axp20x_i2c_id[] table with supported ids, so that
module auto-loading will work.
Reported-by: Dennis Gilmore <dennis@ausil.us>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/mfd/axp20x-i2c.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/axp20x-i2c.c b/drivers/mfd/axp20x-i2c.c
index b1b8658..d35a5fe 100644
--- a/drivers/mfd/axp20x-i2c.c
+++ b/drivers/mfd/axp20x-i2c.c
@@ -69,10 +69,11 @@ static const struct of_device_id axp20x_i2c_of_match[] = {
};
MODULE_DEVICE_TABLE(of, axp20x_i2c_of_match);
-/*
- * This is useless for OF-enabled devices, but it is needed by I2C subsystem
- */
static const struct i2c_device_id axp20x_i2c_id[] = {
+ { "axp152", 0 },
+ { "axp202", 0 },
+ { "axp209", 0 },
+ { "axp221", 0 },
{ },
};
MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
--
2.9.3
^ permalink raw reply related
* [PATCH 0/1] mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
From: Hans de Goede @ 2016-10-05 15:51 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Dennis Gilmore (in the Cc) reports that axp20x-i2c does not auto-load
on e.g. the CHIP. I believe this is caused by the i2c-ids table not being
populated.
I believe the patch in the next mail should fix this.
Regards,
Hans
^ permalink raw reply
* [PATCH] arm64: dts: marvell: Add definition for the Globalscale Marvell ESPRESSOBin Board
From: Gregory CLEMENT @ 2016-10-05 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005172837.5ea130a1@free-electrons.com>
Hi Thomas,
On mer., oct. 05 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Wed, 05 Oct 2016 17:14:49 +0200, Gregory CLEMENT wrote:
>
>> > + memory {
>> > + device_type = "memory";
>>
>>
>> According to the kickstarter page the boards will came with different
>> amount of memory (from 512MB to 2GB). So we could put a comment
>> here about tuning this value depending of the board.
>
> U-Boot does this tuning automatically, so there is no need for the user
> to tune anything here.
Great!
It was not the case with the first Armada XP and 370 boards, but at this
time we appended the dtb to the kernel and the U-Boot on these board was
not dt capable.
Thanks,
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [RFC] arm64: Enforce observed order for spinlock and data
From: bdegraaf at codeaurora.org @ 2016-10-05 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005151057.GJ3142@twins.programming.kicks-ass.net>
On 2016-10-05 11:10, Peter Zijlstra wrote:
> 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.
Sorry for the confusion, this was a "b" item (correctness fix based on
code
inspection. I had sent an answer to this yesterday, but didn't realize
that
it was in a separate, private email thread.
I'll work out the before/after problem scenarios and send them along
once
I've hashed them out (it may take a while for me to paint a clear
picture).
In the meantime, however, consider that even without the spinlock code
in
the picture, lockref needs to treat the cmpxchg as a full system-level
atomic,
because multiple agents could access the value in a variety of timings.
Since
atomics similar to this are barriered on arm64 since 8e86f0b, the access
to
lockref should be similar.
Brent
^ permalink raw reply
* [PATCH] arm64: dts: marvell: Add definition for the Globalscale Marvell ESPRESSOBin Board
From: Thomas Petazzoni @ 2016-10-05 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fuoaygie.fsf@free-electrons.com>
Hello,
On Wed, 05 Oct 2016 17:14:49 +0200, Gregory CLEMENT wrote:
> > + memory {
> > + device_type = "memory";
>
>
> According to the kickstarter page the boards will came with different
> amount of memory (from 512MB to 2GB). So we could put a comment
> here about tuning this value depending of the board.
U-Boot does this tuning automatically, so there is no need for the user
to tune anything here.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [RESEND PATCH v2 3/3] dt-bindings: reset: oxnas: Update for OX820
From: Neil Armstrong @ 2016-10-05 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005152710.2898-1-narmstrong@baylibre.com>
Add new compatible string for reset and sys-ctrl for the Oxford
Semiconductor OX820 Support.
Drop the OX810SE indices since they moved in a dedicated include file.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/reset/oxnas,reset.txt | 44 +++++-----------------
1 file changed, 9 insertions(+), 35 deletions(-)
diff --git a/Documentation/devicetree/bindings/reset/oxnas,reset.txt b/Documentation/devicetree/bindings/reset/oxnas,reset.txt
index 6f06db9..d27ccb5 100644
--- a/Documentation/devicetree/bindings/reset/oxnas,reset.txt
+++ b/Documentation/devicetree/bindings/reset/oxnas,reset.txt
@@ -5,45 +5,19 @@ Please also refer to reset.txt in this directory for common reset
controller binding usage.
Required properties:
-- compatible: Should be "oxsemi,ox810se-reset"
+- compatible: For OX810SE, should be "oxsemi,ox810se-reset"
+ For OX820, should be "oxsemi,ox820-reset"
- #reset-cells: 1, see below
Parent node should have the following properties :
-- compatible: Should be "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
+- compatible: For OX810SE, should be :
+ "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
+ For OX820, should be :
+ "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd"
-For OX810SE, the indices are :
- - 0 : ARM
- - 1 : COPRO
- - 2 : Reserved
- - 3 : Reserved
- - 4 : USBHS
- - 5 : USBHSPHY
- - 6 : MAC
- - 7 : PCI
- - 8 : DMA
- - 9 : DPE
- - 10 : DDR
- - 11 : SATA
- - 12 : SATA_LINK
- - 13 : SATA_PHY
- - 14 : Reserved
- - 15 : NAND
- - 16 : GPIO
- - 17 : UART1
- - 18 : UART2
- - 19 : MISC
- - 20 : I2S
- - 21 : AHB_MON
- - 22 : UART3
- - 23 : UART4
- - 24 : SGDMA
- - 25 : Reserved
- - 26 : Reserved
- - 27 : Reserved
- - 28 : Reserved
- - 29 : Reserved
- - 30 : Reserved
- - 31 : BUS
+Reset indices are in dt-bindings include files :
+- For OX810SE: include/dt-bindings/reset/oxsemi,ox810se.h
+- For OX820: include/dt-bindings/reset/oxsemi,ox820.h
example:
--
2.7.0
^ permalink raw reply related
* [RESEND PATCH v2 2/3] dt-bindings: reset: oxnas: Add include file with reset indexes
From: Neil Armstrong @ 2016-10-05 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005152710.2898-1-narmstrong@baylibre.com>
Add DT include file for Oxford Semiconductor OX810SE and OX820 reset
controller support.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
include/dt-bindings/reset/oxsemi,ox810se.h | 53 ++++++++++++++++++++++++++++++
include/dt-bindings/reset/oxsemi,ox820.h | 53 ++++++++++++++++++++++++++++++
2 files changed, 106 insertions(+)
create mode 100644 include/dt-bindings/reset/oxsemi,ox810se.h
create mode 100644 include/dt-bindings/reset/oxsemi,ox820.h
diff --git a/include/dt-bindings/reset/oxsemi,ox810se.h b/include/dt-bindings/reset/oxsemi,ox810se.h
new file mode 100644
index 0000000..960c26e
--- /dev/null
+++ b/include/dt-bindings/reset/oxsemi,ox810se.h
@@ -0,0 +1,53 @@
+/*
+ * 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_RESET_OXSEMI_OX810SE_H
+#define DT_RESET_OXSEMI_OX810SE_H
+
+#define RESET_ARM 0
+#define RESET_COPRO 1
+/* Reserved 2 */
+/* Reserved 3 */
+#define RESET_USBHS 4
+#define RESET_USBHSPHY 5
+#define RESET_MAC 6
+#define RESET_PCI 7
+#define RESET_DMA 8
+#define RESET_DPE 9
+#define RESET_DDR 10
+#define RESET_SATA 11
+#define RESET_SATA_LINK 12
+#define RESET_SATA_PHY 13
+ /* Reserved 14 */
+#define RESET_NAND 15
+#define RESET_GPIO 16
+#define RESET_UART1 17
+#define RESET_UART2 18
+#define RESET_MISC 19
+#define RESET_I2S 20
+#define RESET_AHB_MON 21
+#define RESET_UART3 22
+#define RESET_UART4 23
+#define RESET_SGDMA 24
+/* Reserved 25 */
+/* Reserved 26 */
+/* Reserved 27 */
+/* Reserved 28 */
+/* Reserved 29 */
+/* Reserved 30 */
+#define RESET_BUS 31
+
+#endif /* DT_RESET_OXSEMI_OX810SE_H */
diff --git a/include/dt-bindings/reset/oxsemi,ox820.h b/include/dt-bindings/reset/oxsemi,ox820.h
new file mode 100644
index 0000000..cc6797b
--- /dev/null
+++ b/include/dt-bindings/reset/oxsemi,ox820.h
@@ -0,0 +1,53 @@
+/*
+ * 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_RESET_OXSEMI_OX820_H
+#define DT_RESET_OXSEMI_OX820_H
+
+#define RESET_SCU 0
+#define RESET_LEON 1
+#define RESET_ARM0 2
+#define RESET_ARM1 3
+#define RESET_USBHS 4
+#define RESET_USBPHYA 5
+#define RESET_MAC 6
+#define RESET_PCIEA 7
+#define RESET_SGDMA 8
+#define RESET_CIPHER 9
+#define RESET_DDR 10
+#define RESET_SATA 11
+#define RESET_SATA_LINK 12
+#define RESET_SATA_PHY 13
+#define RESET_PCIEPHY 14
+#define RESET_NAND 15
+#define RESET_GPIO 16
+#define RESET_UART1 17
+#define RESET_UART2 18
+#define RESET_MISC 19
+#define RESET_I2S 20
+#define RESET_SD 21
+#define RESET_MAC_2 22
+#define RESET_PCIEB 23
+#define RESET_VIDEO 24
+#define RESET_DDR_PHY 25
+#define RESET_USBPHYB 26
+#define RESET_USBDEV 27
+/* Reserved 29 */
+#define RESET_ARMDBG 29
+#define RESET_PLLA 30
+#define RESET_PLLB 31
+
+#endif /* DT_RESET_OXSEMI_OX820_H */
--
2.7.0
^ permalink raw reply related
* [RESEND PATCH v2 1/3] reset: oxnas: Add OX820 support
From: Neil Armstrong @ 2016-10-05 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005152710.2898-1-narmstrong@baylibre.com>
In order to support the Oxford Semiconductor OX820 SoC, add a new
compatible string.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/reset/reset-oxnas.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/reset/reset-oxnas.c b/drivers/reset/reset-oxnas.c
index 9449805..0d9036d 100644
--- a/drivers/reset/reset-oxnas.c
+++ b/drivers/reset/reset-oxnas.c
@@ -80,6 +80,7 @@ static const struct reset_control_ops oxnas_reset_ops = {
static const struct of_device_id oxnas_reset_dt_ids[] = {
{ .compatible = "oxsemi,ox810se-reset", },
+ { .compatible = "oxsemi,ox820-reset", },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, oxnas_reset_dt_ids);
--
2.7.0
^ permalink raw reply related
* [RESEND PATCH v2 0/3]
From: Neil Armstrong @ 2016-10-05 15:27 UTC (permalink / raw)
To: linux-arm-kernel
This is a resend of v2 with the actual changes on patch number 3.
This patchset adds support for the reset controller in the Oxford
Semiconductor OX820 SoC, big brother of the OX810SE.
Since this driver uses a regmap access, it's important to tag each
compatible SoC since the regmap offset could differ in later SoCs.
This patchet also moves the reset indices to a clean DT include file.
Changes since v1 at: http://lkml.kernel.org/r/20160909131955.27334-1-narmstrong at baylibre.com
- Reformat bindings
- Add reference to include files in bindings
Neil Armstrong (3):
reset: oxnas: Add OX820 support
dt-bindings: reset: oxnas: Add include file with reset indexes
dt-bindings: reset: oxnas: Update for OX820
.../devicetree/bindings/reset/oxnas,reset.txt | 44 ++++--------------
drivers/reset/reset-oxnas.c | 1 +
include/dt-bindings/reset/oxsemi,ox810se.h | 53 ++++++++++++++++++++++
include/dt-bindings/reset/oxsemi,ox820.h | 53 ++++++++++++++++++++++
4 files changed, 116 insertions(+), 35 deletions(-)
create mode 100644 include/dt-bindings/reset/oxsemi,ox810se.h
create mode 100644 include/dt-bindings/reset/oxsemi,ox820.h
--
2.7.0
^ 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