* [PATCH 4/4] ARM: dts: imx: drop 'clocks' container for board level clocks
From: Shawn Guo @ 2018-05-04 0:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525395446-1953-1-git-send-email-shawnguo@kernel.org>
For soc level of clocks which are input to Clock Control Module, clock
driver expects them to be under 'clocks' container node. But for board
level clocks, this container is not really necessary. Let's drop it and
use an unique name for fixed rate clock, so that 'reg' property can be
saved as well.
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/boot/dts/imx28-tx28.dts | 13 ++++---------
arch/arm/boot/dts/imx53-tx53.dtsi | 11 +++++------
arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 15 ++++++---------
arch/arm/boot/dts/imx6q-bx50v3.dtsi | 11 ++++-------
4 files changed, 19 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts
index 687186358c18..e4f19f9be6d0 100644
--- a/arch/arm/boot/dts/imx28-tx28.dts
+++ b/arch/arm/boot/dts/imx28-tx28.dts
@@ -140,15 +140,10 @@
regulator-boot-on;
};
- clocks {
- #address-cells = <1>;
- #size-cells = <0>;
- mclk: clock at 0 {
- compatible = "fixed-clock";
- reg = <0>;
- #clock-cells = <0>;
- clock-frequency = <26000000>;
- };
+ mclk: clock-mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
};
sound {
diff --git a/arch/arm/boot/dts/imx53-tx53.dtsi b/arch/arm/boot/dts/imx53-tx53.dtsi
index 77f2ce9f1e41..5dd3dd3a2fd0 100644
--- a/arch/arm/boot/dts/imx53-tx53.dtsi
+++ b/arch/arm/boot/dts/imx53-tx53.dtsi
@@ -67,13 +67,12 @@
ckih1 {
clock-frequency = <0>;
};
+ };
- mclk: clock at 0 {
- compatible = "fixed-clock";
- reg = <0>;
- #clock-cells = <0>;
- clock-frequency = <26000000>;
- };
+ mclk: clock-mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
};
gpio-keys {
diff --git a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
index ea184d108491..3dee3af1a4c1 100644
--- a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
+++ b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
@@ -72,15 +72,12 @@
stdout-path = "serial0:115200n8";
};
- clocks {
- /* Fixed crystal dedicated to mcp251x */
- clk16m: clk at 1 {
- compatible = "fixed-clock";
- reg = <1>;
- #clock-cells = <0>;
- clock-frequency = <16000000>;
- clock-output-names = "clk16m";
- };
+ /* Fixed crystal dedicated to mcp251x */
+ clk16m: clock-16m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <16000000>;
+ clock-output-names = "clk16m";
};
gpio-keys {
diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
index d0e7dab4d72b..d3cba09be0cb 100644
--- a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
+++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
@@ -43,13 +43,10 @@
#include "imx6q-ba16.dtsi"
/ {
- clocks {
- mclk: clock at 0 {
- compatible = "fixed-clock";
- reg = <0>;
- #clock-cells = <0>;
- clock-frequency = <22000000>;
- };
+ mclk: clock-mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <22000000>;
};
gpio-poweroff {
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: imx27: use lable to override osc26m clock setting
From: Shawn Guo @ 2018-05-04 0:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525395446-1953-1-git-send-email-shawnguo@kernel.org>
Instead of copying the whole node hierarchy, let's define a label for
clock osc26m in soc dtsi and use it for overriding clock-frequency.
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/boot/dts/imx27-apf27.dts | 13 +++----------
arch/arm/boot/dts/imx27.dtsi | 2 +-
2 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/imx27-apf27.dts b/arch/arm/boot/dts/imx27-apf27.dts
index 66941cdbf244..3eddd805a793 100644
--- a/arch/arm/boot/dts/imx27-apf27.dts
+++ b/arch/arm/boot/dts/imx27-apf27.dts
@@ -22,17 +22,10 @@
memory at a0000000 {
reg = <0xa0000000 0x04000000>;
};
+};
- clocks {
- #address-cells = <1>;
- #size-cells = <0>;
-
- osc26m {
- compatible = "fsl,imx-osc26m", "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <0>;
- };
- };
+&clk_osc26m {
+ clock-frequency = <0>;
};
&iomuxc {
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index 389c9288b4ed..6c28b9cf802c 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -57,7 +57,7 @@
};
clocks {
- osc26m {
+ clk_osc26m: osc26m {
compatible = "fsl,imx-osc26m", "fixed-clock";
#clock-cells = <0>;
clock-frequency = <26000000>;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: imx1: move clk32 clock into soc dtsi
From: Shawn Guo @ 2018-05-04 0:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525395446-1953-1-git-send-email-shawnguo@kernel.org>
The clk32 clock is an input clock to CCM module, and should be defined
in soc dtsi rather than a board level dts. Let's move it into
imx1.dtsi.
While at it, let's drop unnecessary #address-cells/#size-cells from
'clocks' node to DTC warning avoid_unnecessary_addr_size seen with W=1
switch.
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/boot/dts/imx1-ads.dts | 11 -----------
arch/arm/boot/dts/imx1.dtsi | 8 ++++++++
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/imx1-ads.dts b/arch/arm/boot/dts/imx1-ads.dts
index 6354e4c87313..a1d81badb5c8 100644
--- a/arch/arm/boot/dts/imx1-ads.dts
+++ b/arch/arm/boot/dts/imx1-ads.dts
@@ -23,17 +23,6 @@
memory at 8000000 {
reg = <0x08000000 0x04000000>;
};
-
- clocks {
- #address-cells = <1>;
- #size-cells = <0>;
-
- clk32 {
- compatible = "fsl,imx-clk32", "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <32000>;
- };
- };
};
&cspi1 {
diff --git a/arch/arm/boot/dts/imx1.dtsi b/arch/arm/boot/dts/imx1.dtsi
index f7b9edf93f5e..78cba9435f8e 100644
--- a/arch/arm/boot/dts/imx1.dtsi
+++ b/arch/arm/boot/dts/imx1.dtsi
@@ -62,6 +62,14 @@
};
};
+ clocks {
+ clk32 {
+ compatible = "fsl,imx-clk32", "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32000>;
+ };
+ };
+
soc {
#address-cells = <1>;
#size-cells = <1>;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] ARM: dts: imx: drop unnecessary #address-cells/#size-cells
From: Shawn Guo @ 2018-05-04 0:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525395446-1953-1-git-send-email-shawnguo@kernel.org>
It drops unnecessary #address-cells/#size-cells from <soc>.dtsi 'clocks'
node to fix DTC warning avoid_unnecessary_addr_size seen with W=1
switch.
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/boot/dts/imx25.dtsi | 3 ---
arch/arm/boot/dts/imx27.dtsi | 3 ---
arch/arm/boot/dts/imx50.dtsi | 3 ---
arch/arm/boot/dts/imx51.dtsi | 3 ---
arch/arm/boot/dts/imx53.dtsi | 3 ---
arch/arm/boot/dts/imx6qdl.dtsi | 3 ---
arch/arm/boot/dts/imx6sl.dtsi | 3 ---
7 files changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index cf70df20b19c..67606dd334bf 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -70,9 +70,6 @@
};
clocks {
- #address-cells = <1>;
- #size-cells = <0>;
-
osc {
compatible = "fsl,imx-osc", "fixed-clock";
#clock-cells = <0>;
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index 6585b00c3917..389c9288b4ed 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -57,9 +57,6 @@
};
clocks {
- #address-cells = <1>;
- #size-cells = <0>;
-
osc26m {
compatible = "fsl,imx-osc26m", "fixed-clock";
#clock-cells = <0>;
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index 7954e79d0a16..a9b712db9f6c 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -60,9 +60,6 @@
};
clocks {
- #address-cells = <1>;
- #size-cells = <0>;
-
ckil {
compatible = "fsl,imx-ckil", "fixed-clock";
#clock-cells = <0>;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 5d390a64e976..b5db83cd7439 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -56,9 +56,6 @@
};
clocks {
- #address-cells = <1>;
- #size-cells = <0>;
-
ckil {
compatible = "fsl,imx-ckil", "fixed-clock";
#clock-cells = <0>;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 7d647d043f52..d0db80150db7 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -88,9 +88,6 @@
};
clocks {
- #address-cells = <1>;
- #size-cells = <0>;
-
ckil {
compatible = "fsl,imx-ckil", "fixed-clock";
#clock-cells = <0>;
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 5332fe78cc8a..69648e205dca 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -58,9 +58,6 @@
};
clocks {
- #address-cells = <1>;
- #size-cells = <0>;
-
ckil {
compatible = "fsl,imx-ckil", "fixed-clock";
#clock-cells = <0>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index ab6a7e2e7e8f..2002db2feb00 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -86,9 +86,6 @@
};
clocks {
- #address-cells = <1>;
- #size-cells = <0>;
-
ckil {
compatible = "fixed-clock";
#clock-cells = <0>;
--
1.9.1
^ permalink raw reply related
* [PATCH 0/4] Fix avoid_unnecessary_addr_size DTC warning with 'clocks' node
From: Shawn Guo @ 2018-05-04 0:57 UTC (permalink / raw)
To: linux-arm-kernel
The series is to clean up avoid_unnecessary_addr_size DTC warning seen
with 'clocks' container node in i.MX dts files.
Shawn Guo (4):
ARM: dts: imx: drop unnecessary #address-cells/#size-cells
ARM: dts: imx1: move clk32 clock into soc dtsi
ARM: dts: imx27: use lable to override osc26m clock setting
ARM: dts: imx: drop 'clocks' container for board level clocks
arch/arm/boot/dts/imx1-ads.dts | 11 -----------
arch/arm/boot/dts/imx1.dtsi | 8 ++++++++
arch/arm/boot/dts/imx25.dtsi | 3 ---
arch/arm/boot/dts/imx27-apf27.dts | 13 +++----------
arch/arm/boot/dts/imx27.dtsi | 5 +----
arch/arm/boot/dts/imx28-tx28.dts | 13 ++++---------
arch/arm/boot/dts/imx50.dtsi | 3 ---
arch/arm/boot/dts/imx51.dtsi | 3 ---
arch/arm/boot/dts/imx53-tx53.dtsi | 11 +++++------
arch/arm/boot/dts/imx53.dtsi | 3 ---
arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 15 ++++++---------
arch/arm/boot/dts/imx6q-bx50v3.dtsi | 11 ++++-------
arch/arm/boot/dts/imx6qdl.dtsi | 3 ---
arch/arm/boot/dts/imx6sl.dtsi | 3 ---
14 files changed, 31 insertions(+), 74 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH] ARM: dts: BCM5301X: Relicense most DTS files to the GPL 2.0+ / MIT
From: Florian Fainelli @ 2018-05-04 0:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502141102.31769-1-zajec5@gmail.com>
On Wed, 2 May 2018 16:11:02 +0200, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> From: Rafa? Mi?ecki <rafal@milecki.pl>
>
> These files were created and ever touched by a group of three people
> only: Dan, Hauke and me. They were licensed under GNU/GPL or ISC.
>
> Introducing and discussing SPDX-License-Identifier resulted in a
> conclusion that ISC is a not recommended license (see also a
> license-rules.rst). Moveover an old e-mail from Alan Cox was pointed
> which explained that dual licensing is a safer solution than depending
> on a common compatibility belief.
>
> This commit switches most of BCM5301X DTS files to dual licensing using:
> 1) GPL 2.0+ to make sure they are compatible with Linux kernel
> 2) MIT to allow sharing with more permissive projects
> Both licenses belong to the preferred ones (see LICENSES/preferred/).
>
> An attempt to relicense remaining files will be made separately and will
> require approve from more/other developers.
>
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
> ---
Applied to devicetree/next, thanks!
--
Florian
^ permalink raw reply
* [PATCH v4 2/2] ThunderX2: Add Cavium ThunderX2 SoC UNCORE PMU driver
From: Kim Phillips @ 2018-05-04 0:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501115405.GE25237@arm.com>
On Tue, 1 May 2018 12:54:05 +0100
Will Deacon <will.deacon@arm.com> wrote:
> Hi Kim,
Hi Will, thanks for responding.
> On Fri, Apr 27, 2018 at 11:56:25AM -0500, Kim Phillips wrote:
> > On Fri, 27 Apr 2018 17:09:14 +0100
> > Will Deacon <will.deacon@arm.com> wrote:
> > > On Fri, Apr 27, 2018 at 10:46:29AM -0500, Kim Phillips wrote:
> > > > On Fri, 27 Apr 2018 15:37:20 +0100
> > > > Will Deacon <will.deacon@arm.com> wrote:
> > > > > For anything under drivers/perf/, I'd prefer not to have these prints
> > > > > and instead see efforts to improve error reporting via the perf system
> > > > > call interface.
> > > >
> > > > We'd all prefer that, and for all PMU drivers, why should ones under
> > > > drivers/perf be treated differently?
> > >
> > > Because they're the ones I maintain...
> >
> > You represent a minority on your opinion on this matter though.
>
> I'm not sure that's true
I haven't seen another arch/PMU driver maintainer actively oppose it
other than you (and Mark).
> -- you tend to be the only one raising this issue;
If you're basing that on list activity, I wouldn't, since most Arm perf
users don't subscribe to LKML. I'm trying to represent current and
future Arm perf users that shouldn't be expected to hang out here on
LKML and review PMU drivers. Couldn't tell you why PMU driver authors
themselves don't chime in, but will note that some drivers in
drivers/perf do print things from their event_init functions.
Also, you have been cc'd on off-list email threads where SPE users had
to debug the SPE driver's event_init() manually. There are other SPE
users I know that have had to go through the same painstaking process of
debugging the SPE driver. Last but not least, there's me, and I'd sure
appreciate more verbose PMU drivers, based on my real-life performance
monitoring experience(s).
> I think most people don't actually care one way or the other. If you know of
Like I said, I think you're limiting your audience to LKML subscribers,
who are more amenable to being convinced they need to debug their
kernel.
> others who care about it too then I suggest you work together as a group to
> solve the problem in a way which is amenable to the upstream maintainers.
I know a few off-list people that would like a more user-friendly Arm
perf experience, but we're not qualified to solve the larger problem
that perf has had since its inception, and I think it's a little unfair
for you to suggest that, esp. given you're one of the maintainers, and
there's Linus on top of you.
> Then you won't have to worry about fixing it personally. You could even
> propose a topic for plumbers if there is enough interest in a general
> framework for propagating error messages to userspace.
I'm not worried about fixing it personally or not. I'm worried about
our perf users' experience given your objection to using the vehicle
already in use on other architectures and PMU drivers.
If you - or anyone else for that matter - know of a way that'll get us
past this, by all means, say something.
If it helps, I recently asked acme if we could borrow bits from struct
perf_event and got no response.
> > > > As you are already aware, I've personally tried to fix this problem -
> > > > that has existed since before the introduction of the perf tool (I
> > > > consider it a syscall-independent enhanced error interface), multiple
> > > > times, and failed.
> > >
> > > Why is that my problem? Try harder?
> >
> > It's your problem because we're here reviewing a patch that happens to
> > fall under your maintainership. I'll be the first person to tell you
> > I'm obviously incompetent and haven't been able to come up with a
> > solution that is acceptable for everyone up to and including Linus
> > Torvalds. I'm just noticing a chronic usability problem that can be
> > easily alleviated in the context of this patch review.
>
> I don't see how incompetence has anything to do with it and, like most
Well you told me to try harder, and I'm trying to let you know that I
can try harder - ad infinitum - and still not get it, so telling me to
try harder isn't going to necessarily resolve the issue.
> people (lucky gits...), I doubt Torvalds cares too deeply about PMU driver
> internals. No arguments on the usability problem, but this ain't the fix
Like acme, I doubt Linus runs perf on real Arm h/w, so yes, I don't
think they care that much, but if they did try to do it one day, I'd
like to that they'd be able to have dmesg contain that extra error
information for them.
As you know, David Howells wrote a supplemental error syscall facility
[1], that Linus nacked (off list no less). Does Linus care about what
David Howells was developing it for? I don't know, but he does have
enough experience to know whether a certain approach to a problem is
sustainable in his kernel or not.
> you're looking for: it's a bodge. We've been over this many times before.
I think it's OK - necessary even - until this error infrastructure
problem perf has is fixed, and I think you're being unrealistic if you
think it will be fixed anytime soon.
> > > > So until someone comes up with a solution that works for everyone
> > > > up to and including Linus Torvalds (who hasn't put up a problem
> > > > pulling PMU drivers emitting things to dmesg so far, by the way), this
> > > > keep PMU drivers' errors silent preference of yours is unnecessarily
> > > > impeding people trying to measure system performance on Arm based
> > > > machines - all other archs' maintainers are fine with PMU drivers using
> > > > dmesg.
> > >
> > > Good for them, although I'm pretty sure that at least the x86 folks are
> > > against this crap too.
> >
> > Unfortunately, it doesn't affect them nearly as much as it does our
> > more diverse platforms, which is why I don't think they care to do
> > much about it.
>
> x86 has its fair share of PMUs too, so I don't think we're special in this
> regard. The main difference seems to be that they have better support in
> the perf tool for diagnosing problems.
Indeed, their software is as vertically integrated as their hardware,
and, well, they have more people with more experience working and caring
about perf running and being more usable.
> > > > > Anyway, I think this driver has bigger problems that need addressing.
> > > >
> > > > To me it represents yet another PMU driver submission - as the years go
> > > > by - that is lacking in the user messaging area. Which reminds me, can
> > > > you take another look at applying this?:
> > >
> > > As I said before, I'm not going to take anything that logs above pr_debug
> > > for things that are directly triggerable from userspace. Spin a version
> >
> > Why? There are plenty of things that emit stuff into dmesg that are
> > directly triggerable from userspace. Is it because it upsets fuzzing
> > tests? How about those be run with a patched kernel that somehow
> > mitigates the printing?
>
> [we've been over this before]
> There are two camps that might find this information useful:
>
> 1. People writing userspace support for a new PMU using the
> perf_event_open syscall
>
> 2. People trying to use a tool which abstracts the PMU details to some
> degree (e.g. perf tool)
>
> Those in (1) can get by with pr_debug. Sure, they have to recompile, but
> it's not like there are many people in this camp and they'll probably be
> working with the PMU driver writer to some degree anyway and taking new
> kernel drops.
No, please, that's a worse user experience than necessary.
FWIW, I see this type of person as e.g., a JIT developer - a
compiler/toolchain person - who has decided to use h/w monitoring to
help the JIT engine find hotspots. The first place they should start
is to start using the perf tool itself, experimenting with events and
PMUs of interest. When satisfied, they should clone the parameters
the tool makes to the perf_event_open syscall in their JIT engine. We
should not be wasting their time forcing them to hack around in the
kernel trying to debug perf driver semantics.
> Those in (2) may not have access to dmesg, absolutely should not be able
I don't think you're being realistic here: we're talking about people
trying to improve performance: They would likely have kptr_restrict ==
0 (unrestricted), so why would they have dmesg_restrict set? Btw, the
rationale for dmesg_restrict was kernel pointer visibility [2], but now
%Kp hashes addresses before printing them, so it's even less likely to
be used. Curious, where have you seen dmesg_restrict being set?
> to spam it (since this could hide other important messages), will probably
How will it hide other important messages? Run a logging daemon?
We're not talking about a lot of messages here: one line per perf
invocation: see e.g. runs in [2].
> struggle to match an internal message from the PMU driver to their
> invocation of the high-level tool and may well be in a multi-user
> environment so will struggle to identify the messages that they are
> responsible for.
Again, I think you're being unrealistic. My experience - in
multiple performance analysis roles - was that I was always the only
person using the machine at the time, and can easily correlate perf
invocations with dmesg output, particularly if I run 'dmesg -w &' prior
to invoking perf. In one of those roles, having to mess with the
kernel was almost inconceivable - it literally 'just worked' for
everything else. I was lucky that I had prior kernel experience in
order to debug the driver and be able find out how to invoke perf.
> What they actually want is for the perf tool to give
> them more information, and dmesg is not the right channel for that, for
> similar reasons.
We'd all like the perf tool to do things better, and dmesg is all we
have for now, and now I'm sounding like I did 1 1/2 years ago.
> > > using pr_debug and I'll queue it.
> >
> > How about using a ratelimited dev_err variant?
>
> Nah, I don't want dmesg being parsed by users of perf tool. pr_debug should
> be sufficient for perf tool developers working with a new PMU type.
OK the question was to the ratelimited part, but I think that even
might be the default these days [4].
For reasons (different perceptions?) already mentioned above, I also
don't agree that this has to do with just perf tool developers, and
only when working with a new PMU type. My main concern is new/future
users to perf on Arm, working with any PMU type - new or old. If there
is a perf tool-side component to this driver, I don't see it. Having
said that, I think the owners of this and other PMU drivers should have
a say in what type of experience they want for their users in this
regard...is that fair?
Thanks,
Kim
[1] https://patchwork.kernel.org/patch/9907463/
[2] https://lwn.net/Articles/414813/
[3] https://lkml.org/lkml/2017/11/21/385
[4] https://lwn.net/Articles/693010/
^ permalink raw reply
* [PATCH v2] tty: implement led triggers
From: kbuild test robot @ 2018-05-04 0:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503201952.16592-1-u.kleine-koenig@pengutronix.de>
Hi Uwe,
I love your patch! Yet something to improve:
[auto build test ERROR on tty/tty-testing]
[also build test ERROR on v4.17-rc3 next-20180503]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Uwe-Kleine-K-nig/tty-implement-led-triggers/20180504-075232
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
config: i386-randconfig-x014-201817 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/tty/tty_io.c: In function 'do_tty_write':
>> drivers/tty/tty_io.c:962:38: error: 'struct tty_port' has no member named 'led_trigger_tx'
led_trigger_blink_oneshot(tty->port->led_trigger_tx, &delay, &delay, 0);
^~
--
drivers/tty/tty_buffer.c: In function 'flush_to_ldisc':
>> drivers/tty/tty_buffer.c:526:33: error: 'struct tty_port' has no member named 'led_trigger_rx'
led_trigger_blink_oneshot(port->led_trigger_rx, &delay, &delay, 0);
^~
vim +962 drivers/tty/tty_io.c
893
894 /*
895 * Split writes up in sane blocksizes to avoid
896 * denial-of-service type attacks
897 */
898 static inline ssize_t do_tty_write(
899 ssize_t (*write)(struct tty_struct *, struct file *, const unsigned char *, size_t),
900 struct tty_struct *tty,
901 struct file *file,
902 const char __user *buf,
903 size_t count)
904 {
905 ssize_t ret, written = 0;
906 unsigned int chunk;
907
908 ret = tty_write_lock(tty, file->f_flags & O_NDELAY);
909 if (ret < 0)
910 return ret;
911
912 /*
913 * We chunk up writes into a temporary buffer. This
914 * simplifies low-level drivers immensely, since they
915 * don't have locking issues and user mode accesses.
916 *
917 * But if TTY_NO_WRITE_SPLIT is set, we should use a
918 * big chunk-size..
919 *
920 * The default chunk-size is 2kB, because the NTTY
921 * layer has problems with bigger chunks. It will
922 * claim to be able to handle more characters than
923 * it actually does.
924 *
925 * FIXME: This can probably go away now except that 64K chunks
926 * are too likely to fail unless switched to vmalloc...
927 */
928 chunk = 2048;
929 if (test_bit(TTY_NO_WRITE_SPLIT, &tty->flags))
930 chunk = 65536;
931 if (count < chunk)
932 chunk = count;
933
934 /* write_buf/write_cnt is protected by the atomic_write_lock mutex */
935 if (tty->write_cnt < chunk) {
936 unsigned char *buf_chunk;
937
938 if (chunk < 1024)
939 chunk = 1024;
940
941 buf_chunk = kmalloc(chunk, GFP_KERNEL);
942 if (!buf_chunk) {
943 ret = -ENOMEM;
944 goto out;
945 }
946 kfree(tty->write_buf);
947 tty->write_cnt = chunk;
948 tty->write_buf = buf_chunk;
949 }
950
951 /* Do the write .. */
952 for (;;) {
953 size_t size = count;
954 unsigned long delay = 50 /* ms */;
955
956 if (size > chunk)
957 size = chunk;
958 ret = -EFAULT;
959 if (copy_from_user(tty->write_buf, buf, size))
960 break;
961
> 962 led_trigger_blink_oneshot(tty->port->led_trigger_tx, &delay, &delay, 0);
963
964 ret = write(tty, file, tty->write_buf, size);
965 if (ret <= 0)
966 break;
967 written += ret;
968 buf += ret;
969 count -= ret;
970 if (!count)
971 break;
972 ret = -ERESTARTSYS;
973 if (signal_pending(current))
974 break;
975 cond_resched();
976 }
977 if (written) {
978 tty_update_time(&file_inode(file)->i_mtime);
979 ret = written;
980 }
981 out:
982 tty_write_unlock(tty);
983 return ret;
984 }
985
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 28533 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180504/6fa32491/attachment-0001.gz>
^ permalink raw reply
* [PATCH v7 06/24] ASoC: qdsp6: dt-bindings: Add q6asm dt bindings
From: Banajit Goswami @ 2018-05-03 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-7-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:
> This patch add DT bindings for ASM (Audio Stream Manager) DSP module.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-and-tested-by: Rohit kumar <rohitkr@codeaurora.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/sound/qcom,q6asm.txt | 33 ++++++++++++++++++++++
> include/dt-bindings/sound/qcom,q6asm.h | 22 +++++++++++++++
> 2 files changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/qcom,q6asm.txt
> create mode 100644 include/dt-bindings/sound/qcom,q6asm.h
Reviewed-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v7 05/24] ASoC: qdsp6: dt-bindings: Add q6adm dt bindings
From: Banajit Goswami @ 2018-05-03 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-6-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:
> This patch add DT bindings for ADM (Audio Device Manager) DSP module.
> This module implements mixer controls to setup the connections between
> AFE ports and ASM streams.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-and-tested-by: Rohit kumar <rohitkr@codeaurora.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/sound/qcom,q6adm.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/qcom,q6adm.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6adm.txt b/Documentation/devicetree/bindings/sound/qcom,q6adm.txt
> new file mode 100644
> index 000000000000..cb709e5dbc44
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/qcom,q6adm.txt
> @@ -0,0 +1,33 @@
> +Qualcomm Audio Device Manager (Q6ADM) binding
> +
> +Q6ADM is one of the APR audio service on Q6DSP.
> +Please refer to qcom,apr.txt for details of the coommon apr service bindings
Correct "coommon" to "common". Otherwise looks good.
Reviewed-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v7 04/24] ASoC: qdsp6: dt-bindings: Add q6afe dt bindings
From: Banajit Goswami @ 2018-05-03 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-5-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:
> This patch add DT bindings for AFE (Audio Frontend) DSP module.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-and-tested-by: Rohit kumar <rohitkr@codeaurora.org>
> ---
> .../devicetree/bindings/sound/qcom,q6afe.txt | 104 +++++++++++++++++++++
> include/dt-bindings/sound/qcom,q6afe.h | 31 ++++++
> 2 files changed, 135 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/qcom,q6afe.txt
> create mode 100644 include/dt-bindings/sound/qcom,q6afe.h
>
Reviewed-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v7 03/24] ASoC: qdsp6: dt-bindings: Add q6core dt bindings
From: Banajit Goswami @ 2018-05-03 23:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-4-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:07 AM, Srinivas Kandagatla wrote:
> This patch add DT bindings for Q6CORE DSP module.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-and-tested-by: Rohit kumar <rohitkr@codeaurora.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/sound/qcom,q6core.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/qcom,q6core.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6core.txt b/Documentation/devicetree/bindings/sound/qcom,q6core.txt
> new file mode 100644
> index 000000000000..bd14e9a93490
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/qcom,q6core.txt
> @@ -0,0 +1,21 @@
> +Qualcomm ADSP Core service binding
> +
> +Q6CORE is one of the APR audio service on Q6DSP.
> +Please refer to qcom,apr.txt for details of the coommon apr service bindings
Correct "coommon" to "common". Otherwise looks good.
Reviewed-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Applied "spi: pxa2xx: check clk_prepare_enable() return value" to the spi tree
From: Mark Brown @ 2018-05-03 23:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180430143006.ckcbicijw2to2ghl@agrajag.zerfleddert.de>
The patch
spi: pxa2xx: check clk_prepare_enable() return value
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 62bbc864d1946c715063bd481bff3641fd1324e2 Mon Sep 17 00:00:00 2001
From: Tobias Jordan <Tobias.Jordan@elektrobit.com>
Date: Mon, 30 Apr 2018 16:30:06 +0200
Subject: [PATCH] spi: pxa2xx: check clk_prepare_enable() return value
clk_prepare_enable() can fail, so its return value should be checked and
acted upon.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 3343b7a6d2cd ("spi/pxa2xx: convert to the common clk framework")
Signed-off-by: Tobias Jordan <Tobias.Jordan@elektrobit.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-pxa2xx.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 40f1346b8188..0b2d60d30f69 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1612,7 +1612,9 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
}
/* Enable SOC clock */
- clk_prepare_enable(ssp->clk);
+ status = clk_prepare_enable(ssp->clk);
+ if (status)
+ goto out_error_dma_irq_alloc;
master->max_speed_hz = clk_get_rate(ssp->clk);
@@ -1716,6 +1718,8 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
pm_runtime_put_noidle(&pdev->dev);
pm_runtime_disable(&pdev->dev);
clk_disable_unprepare(ssp->clk);
+
+out_error_dma_irq_alloc:
pxa2xx_spi_dma_release(drv_data);
free_irq(ssp->irq, drv_data);
@@ -1789,8 +1793,11 @@ static int pxa2xx_spi_resume(struct device *dev)
int status;
/* Enable the SSP clock */
- if (!pm_runtime_suspended(dev))
- clk_prepare_enable(ssp->clk);
+ if (!pm_runtime_suspended(dev)) {
+ status = clk_prepare_enable(ssp->clk);
+ if (status)
+ return status;
+ }
/* Restore LPSS private register bits */
if (is_lpss_ssp(drv_data))
@@ -1819,9 +1826,10 @@ static int pxa2xx_spi_runtime_suspend(struct device *dev)
static int pxa2xx_spi_runtime_resume(struct device *dev)
{
struct driver_data *drv_data = dev_get_drvdata(dev);
+ int status;
- clk_prepare_enable(drv_data->ssp->clk);
- return 0;
+ status = clk_prepare_enable(drv_data->ssp->clk);
+ return status;
}
#endif
--
2.17.0
^ permalink raw reply related
* [alsa-devel] [PATCH v7 01/24] soc: qcom dt-bindings: Add APR bus bindings
From: Banajit Goswami @ 2018-05-03 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-2-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:07 AM, Srinivas Kandagatla wrote:
> This patch add dt bindings for Qualcomm APR (Asynchronous Packet Router)
> bus driver. This bus is used for communicating with DSP which provides
> audio and various other services to cpu.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/soc/qcom/qcom,apr.txt | 84 ++++++++++++++++++++++
> include/dt-bindings/soc/qcom,apr.h | 28 ++++++++
> 2 files changed, 112 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
> create mode 100644 include/dt-bindings/soc/qcom,apr.h
>
Reviewed-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Applied "spi: bcm2835aux: ensure interrupts are enabled for shared handler" to the spi tree
From: Mark Brown @ 2018-05-03 23:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503180945.3502-1-robh@kernel.org>
The patch
spi: bcm2835aux: ensure interrupts are enabled for shared handler
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From bc519d9574618e47a0c788000fb78da95e18d953 Mon Sep 17 00:00:00 2001
From: Rob Herring <robh@kernel.org>
Date: Thu, 3 May 2018 13:09:44 -0500
Subject: [PATCH] spi: bcm2835aux: ensure interrupts are enabled for shared
handler
The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
DT change which breaks compatibility with older kernels. The AUX irqchip
was already rejected for upstream[1] and the DT change would break
working systems if the DTB is updated to a newer one. The latter issue
was brought to my attention by Alex Graf.
The root cause however is a bug in the shared handler. Shared handlers
must check that interrupts are actually enabled before servicing the
interrupt. Add a check that the TXEMPTY or IDLE interrupts are enabled.
[1] https://patchwork.kernel.org/patch/9781221/
Cc: Alexander Graf <agraf@suse.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list at broadcom.com
Cc: linux-spi at vger.kernel.org
Cc: linux-rpi-kernel at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-bcm2835aux.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
index 1431cb98fe40..3094d818cf06 100644
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -184,6 +184,11 @@ static irqreturn_t bcm2835aux_spi_interrupt(int irq, void *dev_id)
struct bcm2835aux_spi *bs = spi_master_get_devdata(master);
irqreturn_t ret = IRQ_NONE;
+ /* IRQ may be shared, so return if our interrupts are disabled */
+ if (!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_CNTL1) &
+ (BCM2835_AUX_SPI_CNTL1_TXEMPTY | BCM2835_AUX_SPI_CNTL1_IDLE)))
+ return ret;
+
/* check if we have data to read */
while (bs->rx_len &&
(!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_STAT) &
--
2.17.0
^ permalink raw reply related
* [PATCH 3/3] spi: meson-axg: add a linear clock divider support
From: Mark Brown @ 2018-05-03 23:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503213645.20694-4-yixun.lan@amlogic.com>
On Thu, May 03, 2018 at 09:36:44PM +0000, Yixun Lan wrote:
> From: Sunny Luo <sunny.luo@amlogic.com>
>
> The SPICC controller in Meson-AXG SoC is capable of using
> a linear clock divider to reach a much fine tuned range of clocks,
> while the old controller only use a power of two clock divider,
> result at a more coarse clock range.
>
> Also convert the clock registeration into Common Clock Framework.
This would be better split into two patches - one adding the new linear
clock divider and the other one doing the CCF conversion. Splitting
things out like that makes them much easier to review as each change is
only doing one thing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180504/61bbff46/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] spi: meson-axg: support MAX 80M clock
From: Mark Brown @ 2018-05-03 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503213645.20694-2-yixun.lan@amlogic.com>
On Thu, May 03, 2018 at 09:36:42PM +0000, Yixun Lan wrote:
> static const struct of_device_id meson_spicc_of_match[] = {
> - { .compatible = "amlogic,meson-gx-spicc", },
> - { .compatible = "amlogic,meson-axg-spicc", },
> + {
> + .compatible = "amlogic,meson-gx-spicc",
> + .data = &meson_spicc_gx_data,
> + },
> + {
> + .compatible = "amlogic,meson-axg-spicc",
> + .data = &meson_spicc_axg_data,
> + },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, meson_spicc_of_match);
This is changing the DT bindings but there's no update to the DT binding
documentation, please add an update there.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180504/bfd45740/attachment.sig>
^ permalink raw reply
* [PATCH] spi: bcm2835aux: ensure interrupts are enabled for shared handler
From: Mark Brown @ 2018-05-03 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503180945.3502-1-robh@kernel.org>
On Thu, May 03, 2018 at 01:09:44PM -0500, Rob Herring wrote:
> The root cause however is a bug in the shared handler. Shared handlers
> must check that interrupts are actually enabled before servicing the
> interrupt. Add a check that the TXEMPTY or IDLE interrupts are enabled.
The requirement is more that the handler should correctly identify if it
actually handled an interrupt - especially if the driver doesn't enable
and disable the interrupt at runtime it's not going to upset anything to
always run the interrupt handling (and of course some hardware can't
disable things anyway) but if nohing happened then the handler needs to
return IRQ_NONE.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180504/fb07c019/attachment.sig>
^ permalink raw reply
* [PATCH] spi: bcm2835aux: ensure interrupts are enabled for shared handler
From: Eric Anholt @ 2018-05-03 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+pf0y7+mV8o3t=Uvgo9ZbmVNB9PyS2E3BktR8BZ_ecQQ@mail.gmail.com>
Rob Herring <robh@kernel.org> writes:
> On Thu, May 3, 2018 at 4:15 PM, Eric Anholt <eric@anholt.net> wrote:
>> Rob Herring <robh@kernel.org> writes:
>>
>>> The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
>>> Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
>>> DT change which breaks compatibility with older kernels. The AUX irqchip
>>> was already rejected for upstream[1] and the DT change would break
>>> working systems if the DTB is updated to a newer one. The latter issue
>>> was brought to my attention by Alex Graf.
>>>
>>> The root cause however is a bug in the shared handler. Shared handlers
>>> must check that interrupts are actually enabled before servicing the
>>> interrupt. Add a check that the TXEMPTY or IDLE interrupts are enabled.
>>
>> It looks to me like we'd only return IRQ_HANDLED if we did work that
>> needed doing. Is this check effectively doing some interlock to make
>> sure that we've already started bcm2835aux_spi_transfer_one_irq() and
>> aren't just racing against transaction setup?
>
> What if you are in polled mode for the SPI and the 8250 irq (or other
> SPI instance) causes the SPI irq handler to run?
>
> Is checking whether the interrupt is pending in the aux reg any
> different than checking for interrupt being enabled in the device? I
> could have checked the status bits too, but as you say that is handled
> farther down.
It seems clearly different to me, in that one is about allowing the
interrupt line to go high and the other is about whether the interrupt
line is actually high right now.
However, the polled mode note explains to me what was going wrong, so:
Reviewed-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180503/f9180838/attachment.sig>
^ permalink raw reply
* [PATCH] PCI: Check whether bridges allow access to extended config space
From: Bjorn Helgaas @ 2018-05-03 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5AEB033A.4060407@kontron.com>
[+cc LKML]
On Thu, May 03, 2018 at 12:40:27PM +0000, Gilles Buloz wrote:
> Subject: [PATCH] For exception at PCI probe due to bridge reporting UR
>
> Even if a device supports extended config access, no such access must be
> done to this device If there's a bridge not supporting that in the path
> to this device. Doing such access with UR reporting enabled on the root
> bridge leads to an exception.
>
> This is the case on a LS1043A CPU (NXP QorIQ Layerscape) platform with
> the following bus topology :
> LS1043 PCIe root
> -> PEX8112 PCIe-to-PCI bridge (not supporting ext cfg on PCI side)
> -> PMC slot connector (for legacy PMC modules)
> With a PMC module topology as follows :
> PMC connector
> -> PCI-to-PCIe bridge
> -> PCIe switch (4 ports)
> -> 4 PCIe devices (one on each port)
> In this case all devices behind the PEX8112 are supporting extended config
> access but this is prohibited by the PEX8112. Without this patch, an
> exception (synchronous abort) occurs in pci_cfg_space_size_ext().
>
> This patch checks the parent bridge of each allocated child bus to know if
> extended config access is supported on the child bus, and sets a flag in
> child->bus_flags if not supported. This flag is inherited by all children
> buses of this child bus and then is checked to avoid this unsupported
> accesses to every device on these buses.
Hi Gilles,
Thanks for the patch! I reworked it a little bit to simplify the code
in pci_alloc_child_bus(). Can you test it and make sure I didn't
break anything?
commit cbaaa85b558a8f974e301fa0364d568efaf491ce
Author: Gilles Buloz <Gilles.Buloz@kontron.com>
Date: Thu May 3 15:21:44 2018 -0500
PCI: Check whether bridges allow access to extended config space
Even if a device supports extended config space, i.e., it is a PCI-X Mode 2
or a PCI Express device, the extended space may not be accessible if
there's a conventional PCI bus in the path to it.
We currently figure that out in pci_cfg_space_size() by reading the first
dword of extended config space. On most platforms that returns ~0 data if
the space is inaccessible, but it may set error bits in PCI status
registers, and on some platforms it causes exceptions that we currently
don't recover from.
For example, a PCIe-to-conventional PCI bridge treats config transactions
with a non-zero Extended Register Address as an Unsupported Request on PCIe
and a received Master-Abort on the destination bus (see PCI Express to
PCI/PCI-X Bridge spec, r1.0, sec 4.1.3).
A sample case is a LS1043A CPU (NXP QorIQ Layerscape) platform with the
following bus topology:
LS1043 PCIe Root Port
-> PEX8112 PCIe-to-PCI bridge (doesn't support ext cfg on PCI side)
-> PMC slot connector (for legacy PMC modules)
With a PMC module topology as follows:
PMC connector
-> PCI-to-PCIe bridge
-> PCIe switch (4 ports)
-> 4 PCIe devices (one on each port)
The PCIe devices on the PMC module support extended config space, but we
can't reach it because the PEX8112 can't generate accesses to the extended
space on its secondary bus. Attempts to access it cause Unsupported
Request errors, which result in synchronous aborts on this platform.
To avoid these errors, check whether bridges are capable of generating
extended config space addresses on their secondary interfaces. If they
can't, we restrict devices below the bridge to only the 256-byte
PCI-compatible config space.
Signed-off-by: Gilles Buloz <gilles.buloz@kontron.com>
[bhelgaas: changelog, rework patch so bus_flags testing is all in
pci_bridge_child_ext_cfg_accessible()]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ac91b6fd0bcd..7b1b7b2e01e4 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -882,6 +882,45 @@ static int pci_register_host_bridge(struct pci_host_bridge *bridge)
return err;
}
+static bool pci_bridge_child_ext_cfg_accessible(struct pci_dev *bridge)
+{
+ int pos;
+ u32 status;
+
+ /*
+ * If extended config space isn't accessible on a bridge's primary
+ * bus, we certainly can't access it on the secondary bus.
+ */
+ if (bridge->bus->bus_flags & PCI_BUS_FLAGS_NO_EXTCFG)
+ return false;
+
+ /*
+ * PCIe Root Ports and switch ports are PCIe on both sides, so if
+ * extended config space is accessible on the primary, it's also
+ * accessible on the secondary.
+ */
+ if (pci_is_pcie(bridge) &&
+ (pci_pcie_type(bridge) == PCI_EXP_TYPE_ROOT_PORT ||
+ pci_pcie_type(bridge) == PCI_EXP_TYPE_UPSTREAM ||
+ pci_pcie_type(bridge) == PCI_EXP_TYPE_DOWNSTREAM))
+ return true;
+
+ /*
+ * For the other bridge types:
+ * - PCI-to-PCI bridges
+ * - PCIe-to-PCI/PCI-X forward bridges
+ * - PCI/PCI-X-to-PCIe reverse bridges
+ * extended config space on the secondary side is only accessible
+ * if the bridge supports PCI-X Mode 2.
+ */
+ pos = pci_find_capability(bridge, PCI_CAP_ID_PCIX);
+ if (!pos)
+ return false;
+
+ pci_read_config_dword(bridge, pos + PCI_X_STATUS, &status);
+ return status & (PCI_X_STATUS_266MHZ | PCI_X_STATUS_533MHZ);
+}
+
static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
struct pci_dev *bridge, int busnr)
{
@@ -923,6 +962,16 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
pci_set_bus_of_node(child);
pci_set_bus_speed(child);
+ /*
+ * Check whether extended config space is accessible on the child
+ * bus. Note that we currently assume it is always accessible on
+ * the root bus.
+ */
+ if (!pci_bridge_child_ext_cfg_accessible(bridge)) {
+ child->bus_flags |= PCI_BUS_FLAGS_NO_EXTCFG;
+ pci_info(child, "extended config space not accessible on secondary bus\n");
+ }
+
/* Set up default resource pointers and names */
for (i = 0; i < PCI_BRIDGE_RESOURCE_NUM; i++) {
child->resource[i] = &bridge->resource[PCI_BRIDGE_RESOURCES+i];
@@ -1393,6 +1442,9 @@ int pci_cfg_space_size(struct pci_dev *dev)
u32 status;
u16 class;
+ if (dev->bus->bus_flags & PCI_BUS_FLAGS_NO_EXTCFG)
+ return PCI_CFG_SPACE_SIZE;
+
class = dev->class >> 8;
if (class == PCI_CLASS_BRIDGE_HOST)
return pci_cfg_space_size_ext(dev);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 230615620a4a..f7aa6d9f8999 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -217,6 +217,7 @@ enum pci_bus_flags {
PCI_BUS_FLAGS_NO_MSI = (__force pci_bus_flags_t) 1,
PCI_BUS_FLAGS_NO_MMRBC = (__force pci_bus_flags_t) 2,
PCI_BUS_FLAGS_NO_AERSID = (__force pci_bus_flags_t) 4,
+ PCI_BUS_FLAGS_NO_EXTCFG = (__force pci_bus_flags_t) 8,
};
/* Values from Link Status register, PCIe r3.1, sec 7.8.8 */
^ permalink raw reply related
* [PATCH] ARM: multi_v7_defconfig: enable STM32 analog & timer drivers
From: Arnd Bergmann @ 2018-05-03 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cc934eb9-f9e4-3c52-7f38-413a1b63fce2@st.com>
On Thu, May 3, 2018 at 10:05 AM, Alexandre Torgue
<alexandre.torgue@st.com> wrote:
> Hi Fabrice,
>
> On 05/02/2018 05:24 PM, Fabrice Gasnier wrote:
>>
>> This enables drivers for STM32 timer, low power timer and analog hardware
>> that can be used on STM32MP1 SoC:
>> - Timer & LP Timer MFD core, PWM, trigger & encoder drivers
>> - IIO ADC/DAC/DFSDM
>> - vrefbuf regu driver (voltage reference buffer).
>>
>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
>> ---
>> arch/arm/configs/multi_v7_defconfig | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>
> Applied on stm32-next.
>
> Arnd,
> Do you agree if I take multi_v7_defconfig related patches in my stm32 pull
> requests ?
Yes, just make sure that all drivers that can reasonably be loadable
modules are configured that way rather than as built-in, so a defconfig
build doesn't become too big.
Arnd
^ permalink raw reply
* Droid 4: very confusing config around OHCI_OMAP3_HCD
From: Tony Lindgren @ 2018-05-03 22:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503193837.GC32572@amd>
* Pavel Machek <pavel@ucw.cz> [180503 19:40]:
> On Thu 2018-05-03 12:28:38, Tony Lindgren wrote:
> Ok, what about this? (Should I do the same for the other drivers?)
> Or at least put (DEPRECATED) as other drivers do?
>
> Situation is quite confusing if you already have PLATFORM=y. OMAP=m
> can be selected, but nothing happens.
Sure works for me, let's see what linux-usb people think.
Regards,
Tony
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 5d958da..67c151a 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -455,7 +455,7 @@ config USB_OHCI_HCD_AT91
> Atmel chips.
>
> config USB_OHCI_HCD_OMAP3
> - tristate "OHCI support for OMAP3 and later chips"
> + tristate "dummy option for backwards compatibility"
> depends on (ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5)
> select USB_OHCI_HCD_PLATFORM
> default y
> @@ -463,9 +463,6 @@ config USB_OHCI_HCD_OMAP3
> This option is deprecated now and the driver was removed, use
> USB_OHCI_HCD_PLATFORM instead.
>
> - Enables support for the on-chip OHCI controller on
> - OMAP3 and later chips.
> -
> config USB_OHCI_HCD_DAVINCI
> tristate "OHCI support for TI DaVinci DA8xx"
> depends on ARCH_DAVINCI_DA8XX
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH] spi: bcm2835aux: ensure interrupts are enabled for shared handler
From: Rob Herring @ 2018-05-03 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87efiso2yz.fsf@anholt.net>
On Thu, May 3, 2018 at 4:15 PM, Eric Anholt <eric@anholt.net> wrote:
> Rob Herring <robh@kernel.org> writes:
>
>> The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
>> Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
>> DT change which breaks compatibility with older kernels. The AUX irqchip
>> was already rejected for upstream[1] and the DT change would break
>> working systems if the DTB is updated to a newer one. The latter issue
>> was brought to my attention by Alex Graf.
>>
>> The root cause however is a bug in the shared handler. Shared handlers
>> must check that interrupts are actually enabled before servicing the
>> interrupt. Add a check that the TXEMPTY or IDLE interrupts are enabled.
>
> It looks to me like we'd only return IRQ_HANDLED if we did work that
> needed doing. Is this check effectively doing some interlock to make
> sure that we've already started bcm2835aux_spi_transfer_one_irq() and
> aren't just racing against transaction setup?
What if you are in polled mode for the SPI and the 8250 irq (or other
SPI instance) causes the SPI irq handler to run?
The way I look at it is, this change in the irq handler was also said
to fix the problem[1]:
u32 irq_flags = readl(bcm2835_aux_irq_reg);
if(!(irq_flags & (1<<master->bus_num)))
{
return IRQ_NONE;
}
Is checking whether the interrupt is pending in the aux reg any
different than checking for interrupt being enabled in the device? I
could have checked the status bits too, but as you say that is handled
farther down.
Rob
[1] https://github.com/raspberrypi/linux/issues/1573
^ permalink raw reply
* [PATCH 3/3] spi: meson-axg: add a linear clock divider support
From: Yixun Lan @ 2018-05-03 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503213645.20694-1-yixun.lan@amlogic.com>
From: Sunny Luo <sunny.luo@amlogic.com>
The SPICC controller in Meson-AXG SoC is capable of using
a linear clock divider to reach a much fine tuned range of clocks,
while the old controller only use a power of two clock divider,
result at a more coarse clock range.
Also convert the clock registeration into Common Clock Framework.
Signed-off-by: Sunny Luo <sunny.luo@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
drivers/spi/spi-meson-spicc.c | 209 +++++++++++++++++++++++++++-------
1 file changed, 169 insertions(+), 40 deletions(-)
diff --git a/drivers/spi/spi-meson-spicc.c b/drivers/spi/spi-meson-spicc.c
index 90b15f7d50dd..e8389d7e62e5 100644
--- a/drivers/spi/spi-meson-spicc.c
+++ b/drivers/spi/spi-meson-spicc.c
@@ -116,6 +116,9 @@
#define SPICC_DWADDR 0x24 /* Write Address of DMA */
#define SPICC_ENH_CTL0 0x38 /* Enhanced Feature */
+#define SPICC_ENH_CLK_CS_DELAY_MASK GENMASK(15, 0)
+#define SPICC_ENH_DATARATE_MASK GENMASK(23, 16)
+#define SPICC_ENH_DATARATE_EN BIT(24)
#define SPICC_ENH_MOSI_OEN BIT(25)
#define SPICC_ENH_CLK_OEN BIT(26)
#define SPICC_ENH_CS_OEN BIT(27)
@@ -131,6 +134,7 @@
struct meson_spicc_data {
unsigned int max_speed_hz;
bool has_oen;
+ bool has_enhance_clk_div;
};
struct meson_spicc_device {
@@ -138,6 +142,7 @@ struct meson_spicc_device {
struct platform_device *pdev;
void __iomem *base;
struct clk *core;
+ struct clk *clk;
struct spi_message *message;
struct spi_transfer *xfer;
const struct meson_spicc_data *data;
@@ -325,40 +330,6 @@ static irqreturn_t meson_spicc_irq(int irq, void *data)
return IRQ_HANDLED;
}
-static u32 meson_spicc_setup_speed(struct meson_spicc_device *spicc, u32 conf,
- u32 speed)
-{
- unsigned long parent, value;
- unsigned int i, div;
-
- parent = clk_get_rate(spicc->core);
-
- /* Find closest inferior/equal possible speed */
- for (i = 0 ; i < 7 ; ++i) {
- /* 2^(data_rate+2) */
- value = parent >> (i + 2);
-
- if (value <= speed)
- break;
- }
-
- /* If provided speed it lower than max divider, use max divider */
- if (i > 7) {
- div = 7;
- dev_warn_once(&spicc->pdev->dev, "unable to get close to speed %u\n",
- speed);
- } else
- div = i;
-
- dev_dbg(&spicc->pdev->dev, "parent %lu, speed %u -> %lu (%u)\n",
- parent, speed, value, div);
-
- conf &= ~SPICC_DATARATE_MASK;
- conf |= FIELD_PREP(SPICC_DATARATE_MASK, div);
-
- return conf;
-}
-
static void meson_spicc_setup_xfer(struct meson_spicc_device *spicc,
struct spi_transfer *xfer)
{
@@ -367,9 +338,6 @@ static void meson_spicc_setup_xfer(struct meson_spicc_device *spicc,
/* Read original configuration */
conf = conf_orig = readl_relaxed(spicc->base + SPICC_CONREG);
- /* Select closest divider */
- conf = meson_spicc_setup_speed(spicc, conf, xfer->speed_hz);
-
/* Setup word width */
conf &= ~SPICC_BITLENGTH_MASK;
conf |= FIELD_PREP(SPICC_BITLENGTH_MASK,
@@ -378,6 +346,8 @@ static void meson_spicc_setup_xfer(struct meson_spicc_device *spicc,
/* Ignore if unchanged */
if (conf != conf_orig)
writel_relaxed(conf, spicc->base + SPICC_CONREG);
+
+ clk_set_rate(spicc->clk, xfer->speed_hz);
}
static int meson_spicc_transfer_one(struct spi_master *master,
@@ -486,9 +456,6 @@ static int meson_spicc_unprepare_transfer(struct spi_master *master)
/* Disable all IRQs */
writel(0, spicc->base + SPICC_INTREG);
- /* Disable controller */
- writel_bits_relaxed(SPICC_ENABLE, 0, spicc->base + SPICC_CONREG);
-
device_reset_optional(&spicc->pdev->dev);
return 0;
@@ -528,6 +495,157 @@ static void meson_spicc_cleanup(struct spi_device *spi)
spi->controller_state = NULL;
}
+/*
+ * The Clock Mux
+ * x-----------------x x------------x x------\
+ * |---| 0) fixed factor |---| 1) old div |----| |
+ * | x-----------------x x------------x | |
+ * src ---| |5) mux|-- out
+ * | x-----------------x x------------x | |
+ * |---| 2) fixed factor |---| 3) new div |0---| |
+ * x-----------------x x------------x x------/
+ *
+ * Clk path for GX series:
+ * src -> 0 -> 1 -> out
+ *
+ * Clk path for AXG series:
+ * src -> 0 -> 1 -> 5 -> out
+ * src -> 2 -> 3 -> 5 -> out
+ */
+
+/* algorithm for div0 + div1: rate = freq / 4 / (2 ^ N) */
+static struct clk_fixed_factor meson_spicc_div0 = {
+ .mult = 1,
+ .div = 4,
+};
+
+static struct clk_divider meson_spicc_div1 = {
+ .reg = (void *) SPICC_CONREG,
+ .shift = 16,
+ .width = 3,
+ .flags = CLK_DIVIDER_POWER_OF_TWO,
+};
+
+/* algorithm for div2 + div3: rate = freq / 2 / (N + 1) */
+static struct clk_fixed_factor meson_spicc_div2 = {
+ .mult = 1,
+ .div = 2,
+};
+
+static struct clk_divider meson_spicc_div3 = {
+ .reg = (void *) SPICC_ENH_CTL0,
+ .shift = 16,
+ .width = 8,
+};
+
+static struct clk_mux meson_spicc_sel = {
+ .reg = (void *) SPICC_ENH_CTL0,
+ .mask = 0x1,
+ .shift = 24,
+};
+
+static int meson_spicc_clk_init(struct meson_spicc_device *spicc)
+{
+ struct device *dev = &spicc->pdev->dev;
+ struct clk_fixed_factor *div0;
+ struct clk_divider *div1;
+ struct clk_mux *mux;
+ struct clk_init_data init;
+ struct clk *clk;
+ const char *parent_names[1];
+ const char *mux_parent_names[2];
+ char name[32];
+
+ div0 = &meson_spicc_div0;
+ snprintf(name, sizeof(name), "%s#_div0", dev_name(dev));
+ init.name = name;
+ init.ops = &clk_fixed_factor_ops;
+ init.flags = 0;
+ parent_names[0] = __clk_get_name(spicc->core);
+ init.parent_names = parent_names;
+ init.num_parents = 1;
+
+ div0->hw.init = &init;
+
+ clk = devm_clk_register(dev, &div0->hw);
+ if (WARN_ON(IS_ERR(clk)))
+ return PTR_ERR(clk);
+
+ div1 = &meson_spicc_div1;
+ snprintf(name, sizeof(name), "%s#_div1", dev_name(dev));
+ init.name = name;
+ init.ops = &clk_divider_ops;
+ init.flags = CLK_SET_RATE_PARENT;
+ parent_names[0] = __clk_get_name(clk);
+ init.parent_names = parent_names;
+ init.num_parents = 1;
+
+ div1->reg = spicc->base + (u64) div1->reg;
+ div1->hw.init = &init;
+
+ clk = devm_clk_register(dev, &div1->hw);
+ if (WARN_ON(IS_ERR(clk)))
+ return PTR_ERR(clk);
+
+ if (spicc->data->has_enhance_clk_div == false) {
+ spicc->clk = clk;
+ return 0;
+ }
+
+ mux_parent_names[0] = __clk_get_name(clk);
+
+ div0 = &meson_spicc_div2;
+ snprintf(name, sizeof(name), "%s#_div2", dev_name(dev));
+ init.name = name;
+ init.ops = &clk_fixed_factor_ops;
+ init.flags = 0;
+ parent_names[0] = __clk_get_name(spicc->core);
+ init.parent_names = parent_names;
+ init.num_parents = 1;
+
+ div0->hw.init = &init;
+
+ clk = devm_clk_register(dev, &div0->hw);
+ if (WARN_ON(IS_ERR(clk)))
+ return PTR_ERR(clk);
+
+ div1 = &meson_spicc_div3;
+ snprintf(name, sizeof(name), "%s#_div3", dev_name(dev));
+ init.name = name;
+ init.ops = &clk_divider_ops;
+ init.flags = CLK_SET_RATE_PARENT;
+ parent_names[0] = __clk_get_name(clk);
+ init.parent_names = parent_names;
+ init.num_parents = 1;
+
+ div1->reg = spicc->base + (u64) div1->reg;
+ div1->hw.init = &init;
+
+ clk = devm_clk_register(dev, &div1->hw);
+ if (WARN_ON(IS_ERR(clk)))
+ return PTR_ERR(clk);
+
+ mux_parent_names[1] = __clk_get_name(clk);
+
+ mux = &meson_spicc_sel;
+ snprintf(name, sizeof(name), "%s#_sel", dev_name(dev));
+ init.name = name;
+ init.ops = &clk_mux_ops;
+ init.parent_names = mux_parent_names;
+ init.num_parents = 2;
+ init.flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT;
+
+ mux->reg = spicc->base + (u64) mux->reg;
+ mux->hw.init = &init;
+
+ spicc->clk = devm_clk_register(dev, &mux->hw);
+ if (WARN_ON(IS_ERR(spicc->clk)))
+ return PTR_ERR(spicc->clk);
+
+ clk_set_parent(spicc->clk, clk);
+ return 0;
+}
+
static int meson_spicc_probe(struct platform_device *pdev)
{
struct spi_master *master;
@@ -557,6 +675,10 @@ static int meson_spicc_probe(struct platform_device *pdev)
goto out_master;
}
+ /* Set master mode and enable controller */
+ writel_relaxed(SPICC_ENABLE | SPICC_MODE_MASTER,
+ spicc->base + SPICC_CONREG);
+
/* Disable all IRQs */
writel_relaxed(0, spicc->base + SPICC_INTREG);
@@ -603,6 +725,12 @@ static int meson_spicc_probe(struct platform_device *pdev)
master->max_speed_hz = min_t(unsigned int, rate >> 1,
spicc->data->max_speed_hz);
+ ret = meson_spicc_clk_init(spicc);
+ if (ret) {
+ dev_err(&pdev->dev, "clock registration failed\n");
+ goto out_master;
+ }
+
ret = devm_spi_register_master(&pdev->dev, master);
if (!ret)
return 0;
@@ -634,6 +762,7 @@ static const struct meson_spicc_data meson_spicc_gx_data = {
static const struct meson_spicc_data meson_spicc_axg_data = {
.max_speed_hz = 80000000,
.has_oen = true,
+ .has_enhance_clk_div = true,
};
static const struct of_device_id meson_spicc_of_match[] = {
--
2.17.0
^ permalink raw reply related
* [PATCH 2/3] spi: meson-axg: enhance output enable feature
From: Yixun Lan @ 2018-05-03 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503213645.20694-1-yixun.lan@amlogic.com>
From: Sunny Luo <sunny.luo@amlogic.com>
The SPICC controller in Meson-AXG is capable of driving the CLK/MOSI/SS
signal lines through the idle state (between two transmission operation),
which avoid the signals floating in unexpected state.
Signed-off-by: Sunny Luo <sunny.luo@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
drivers/spi/spi-meson-spicc.c | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-meson-spicc.c b/drivers/spi/spi-meson-spicc.c
index 8489f4c9f465..90b15f7d50dd 100644
--- a/drivers/spi/spi-meson-spicc.c
+++ b/drivers/spi/spi-meson-spicc.c
@@ -115,6 +115,13 @@
#define SPICC_DWADDR 0x24 /* Write Address of DMA */
+#define SPICC_ENH_CTL0 0x38 /* Enhanced Feature */
+#define SPICC_ENH_MOSI_OEN BIT(25)
+#define SPICC_ENH_CLK_OEN BIT(26)
+#define SPICC_ENH_CS_OEN BIT(27)
+#define SPICC_ENH_CLK_CS_DELAY_EN BIT(28)
+#define SPICC_ENH_MAIN_CLK_AO BIT(29)
+
#define writel_bits_relaxed(mask, val, addr) \
writel_relaxed((readl_relaxed(addr) & ~(mask)) | (val), addr)
@@ -123,6 +130,7 @@
struct meson_spicc_data {
unsigned int max_speed_hz;
+ bool has_oen;
};
struct meson_spicc_device {
@@ -145,6 +153,19 @@ struct meson_spicc_device {
bool is_last_burst;
};
+static void meson_spicc_oen_enable(struct meson_spicc_device *spicc)
+{
+ u32 conf;
+
+ if (!spicc->data->has_oen)
+ return;
+
+ conf = readl_relaxed(spicc->base + SPICC_ENH_CTL0) |
+ SPICC_ENH_MOSI_OEN | SPICC_ENH_CLK_OEN | SPICC_ENH_CS_OEN;
+
+ writel_relaxed(conf, spicc->base + SPICC_ENH_CTL0);
+}
+
static inline bool meson_spicc_txfull(struct meson_spicc_device *spicc)
{
return !!FIELD_GET(SPICC_TF,
@@ -453,6 +474,8 @@ static int meson_spicc_prepare_message(struct spi_master *master,
writel_bits_relaxed(BIT(24), BIT(24), spicc->base + SPICC_TESTREG);
+ meson_spicc_oen_enable(spicc);
+
return 0;
}
@@ -605,11 +628,12 @@ static int meson_spicc_remove(struct platform_device *pdev)
}
static const struct meson_spicc_data meson_spicc_gx_data = {
- .max_speed_hz = 30000000,
+ .max_speed_hz = 30000000,
};
static const struct meson_spicc_data meson_spicc_axg_data = {
- .max_speed_hz = 80000000,
+ .max_speed_hz = 80000000,
+ .has_oen = true,
};
static const struct of_device_id meson_spicc_of_match[] = {
--
2.17.0
^ permalink raw reply related
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