* [PATCH V5] perf tools: adding support for address filters
From: Masami Hiramatsu @ 2016-09-19 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <008718a0-13bf-8245-e2ee-562cffeba3c5@intel.com>
On Mon, 19 Sep 2016 09:15:40 +0300
Adrian Hunter <adrian.hunter@intel.com> wrote:
> On 17/09/16 16:33, Masami Hiramatsu wrote:
> > On Fri, 16 Sep 2016 09:32:43 -0600
> > Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> >
> >> On 13 September 2016 at 17:25, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >>> On Tue, 13 Sep 2016 08:18:10 -0600
> >>> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> >>>
> >>>> On 13 September 2016 at 04:01, Adrian Hunter <adrian.hunter@intel.com> wrote:
> >>>>> On 12/09/16 20:53, Mathieu Poirier wrote:
> >>>>>> This patch makes it possible to use the current filter
> >>>>>> framework with address filters. That way address filters for
> >>>>>> HW tracers such as CoreSight and IntelPT can be communicated
> >>>>>> to the kernel drivers.
> >>>>>>
> >>>>>> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> >>>>>>
> >>>>>> ---
> >>>>>> Changes for V5:
> >>>>>> - Modified perf_evsel__append_filter() to take a string format
> >>>>>> rather than an operation.
> >>>>>
> >>>>> Hope I'm not being a pain, but aren't there other places calling
> >>>>> perf_evsel__append_filter() that need to be changed. Might make
> >>>>> sense as a separate patch.
> >>>>
> >>>> No no, you're right - I completely overlooked that.
> >>>>
> >>>> But shouldn't it be in the same patch? That way a git bisect would
> >>>> stay consistent...
> >>>
> >>> You're right. Caller and callee should be changed in atomic.
> >>>
> >>> BTW, could you add document updates how the perf command line
> >>> will be changed, and also show the result in the patch description?
> >>
> >> This patch does not change anything on the perf command line. It
> >> simply allows current options to succeed (as they should) rather than
> >> fail.
> >
> > Yes, and it will make perf acceptable to pass --filter to CoreSight or
> > Intel PT events, or am I misunderstand?
> > If it is correct, could you give us an example how to pass it, since
> > tools/perf/Documentation/perf-record.txt says it is only for tracepoints?
>
> I am adding support for symbols in the address filter. I will send the
> patches soon, but the documentation will be:
>
> --filter=<filter>::
> Event filter. This option should follow a event selector (-e) which
> selects either tracepoint event(s) or a hardware trace PMU
> (e.g. Intel PT or CoreSight).
>
> - tracepoint filters
>
> In the case of tracepoints, multiple '--filter' options are combined
> using '&&'.
>
> - address filters
>
> A hardware trace PMU advertises its ability to accept a number of
> address filters by specifying a non-zero value in
> /sys/bus/event_source/devices/<pmu>/nr_addr_filters.
>
> Address filters have the format:
>
> filter|start|stop|tracestop <start> [/ <size>] [@<file name>]
>
> Where:
> - 'filter': defines a region that will be traced.
> - 'start': defines an address at which tracing will begin.
> - 'stop': defines an address at which tracing will stop.
> - 'tracestop': defines a region in which tracing will stop.
>
> <file name> is the name of the object file, <start> is the offset to the
> code to trace in that file, and <size> is the size of the region to
> trace. 'start' and 'stop' filters need not specify a <size>.
>
> If no object file is specified then the kernel is assumed, in which case
> the start address must be a current kernel memory address.
>
> <start> can also be specified by providing the name of a symbol. If the
> symbol name is not unique, it can be disambiguated by inserting #n where
> 'n' selects the n'th symbol in address order. Alternately #0, #g or #G
> select only a global symbol. <size> can also be specified by providing
> the name of a symbol, in which case the size is calculated to the end
> of that symbol. For 'filter' and 'tracestop' filters, if <size> is
> omitted and <start> is a symbol, then the size is calculated to the end
> of that symbol.
>
> If <size> is omitted and <start> is '*', then the start and size will
> be calculated from the first and last symbols, i.e. to trace the whole
> file.
>
> If symbol names (or "*") are provided, they must be surrounded by white
> space.
>
> The filter passed to the kernel is not necessarily the same as entered.
> To see the filter that is passed, use the -v option.
>
> The kernel may not be able to configure a trace region if it is not
> within a single mapping. MMAP events (or /proc/<pid>/maps) can be
> examined to determine if that is a possibility.
>
> Multiple filters can be separated with space or comma.
Perfect! :)
OK, I'll wait your patch.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* [PATCH 3/4] watchdog: sa11x0/pxa: get rid of get_clock_tick_rate
From: Russell King - ARM Linux @ 2016-09-19 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919200816.GC29242@roeck-us.net>
On Mon, Sep 19, 2016 at 01:08:16PM -0700, Guenter Roeck wrote:
> On Mon, Sep 19, 2016 at 09:12:14PM +0200, Robert Jarzmik wrote:
> > The OS timer rate used for the watchdog can now be fetched from the
> > standard clock API. This will remove the last user of
> > get_clock_tick_rate() in both pxa and sa11x0 architectures.
> >
> > Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
>
> Did you test this ? Potential problem, if built into the kernel, could be that
> the clocks might not be ready by the time the driver is instantiated. Unless
> this is converted to a platform driver, it won't be able to handle a
> -EPROBE_DEFER from the clock subsystem.
Really not a problem at all. The OSTIMER0 is required for the system
tick, and if that's not present, the kernel will be without any kind
of time keeping, so a missing watchdog driver is the least of the
problems.
Therefore, both PXA and SA11x0 register their clocks really early to
ensure that OSTIMER0 is available by the time_init() stage, which is
way before driver probe time.
--
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
* [GIT PULL] Qualcomm EBI2 bindings and bus driver
From: Andy Gross @ 2016-09-19 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4360974.U0qvolVKdi@wuerfel>
On Tue, Sep 20, 2016 at 12:12:33AM +0200, Arnd Bergmann wrote:
> On Thursday, September 8, 2016 3:34:42 PM CEST Linus Walleij wrote:
> > please pull this new EBI2 bus driver and its bindings into an
> > apropriate branch in the ARM SoC tree. The binding now has
> > Rob Herrings ACK and we have hopefully finally figured out how
> > this should be done.
> >
>
> I just noticed that you sent the pull request directly to arm at kernel.org
> rather than the Qualcomm maintainers (which are only on Cc).
>
> Usually, I'd expect to see this forwarded from Andy, is there a
> reason to do it differently here? If so, can I have an Ack
> from him?
When I looked at this last, I thought there were comments. Sorry I missed it.
If you want to pick it up Arnd, please do, otherwise I can send it along in the
next pull request.
Acked-by: Andy Gross <andy.gross@linaro.org>
^ permalink raw reply
* [GIT PULL 2/2] arm64: X-Gene platforms DTS changes queued for 4.9
From: Duc Dang @ 2016-09-19 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5369836.4ELrYOmq06@wuerfel>
On Mon, Sep 19, 2016 at 1:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Friday, September 16, 2016 12:01:28 AM CEST Duc Dang wrote:
> > This is the DTS changes for X-Gene platforms targeted for 4.9.
> >
> > The changes include:
> > + X-Gene Soc PMU DTS entry from X-Gene PMU patch set of Tai Nguyen [1]
> > + Follow up patch to enable DTS entry for SoC PMU on X-Gene v2
> > + Correct PCIe legacy interrupt mode to level-active high
> > + DTS entry for X-Gene hwmon (v4 acked by Guenter, DT binding document
> > and driver is in linux-next now [2])
> > + DTS entries for X-Gene v2 CPU clock from X-Gene PMD clock patch set
> > (v3 already accepted by Stephen into clk-next [3])
> >
> >
>
> Pulled into next/dt64, thanks!
Thanks, Arnd.
>
> Arnd
>
Regards,
Duc Dang.
^ permalink raw reply
* [RESEND PATCH] arm64: kgdb: fix single stepping
From: Jason Wessel @ 2016-09-19 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916043218.GA30248@linaro.org>
On 09/15/2016 11:32 PM, AKASHI Takahiro wrote:
> @@ -176,18 +183,14 @@ int kgdb_arch_handle_exception(int exception_vector, int signo,
>>> * over and over again.
>>> */
>>> kgdb_arch_update_addr(linux_regs, remcom_in_buffer);
>>> - atomic_set(&kgdb_cpu_doing_single_step, -1);
>>> - kgdb_single_step = 0;
>>
>> This is a subtle change, but I assume it is what you intended? All the CPUs will get released into the run state when exiting the kgdb exception handler.
> You are talking about "- kgdb_single_step = 0." Right?
Correct.
> Do you think that there is any (negative) side effect of this change?
Not at all. The kernel debugger always skids to a stop, and it is more reliable from a locking perspective if the other CPU threads are released while a single CPU is asked to single step until the next "skid" for all the other CPUs.
When you do not release the other CPUs you can end up single stepping a CPU which dead locks or never exits a lock elsewhere due to what ever it was blocking on never getting freed from another CPU.
Cheers,
Jason.
^ permalink raw reply
* [RESEND PATCH] arm64: kgdb: fix single stepping
From: Jason Wessel @ 2016-09-19 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916074513.GI3380@arm.com>
On 09/16/2016 02:45 AM, Will Deacon wrote:
> On Fri, Sep 16, 2016 at 01:32:19PM +0900, AKASHI Takahiro wrote:
>> On Thu, Sep 15, 2016 at 08:04:57AM -0500, Jason Wessel wrote:
>>> I added the patch to kgdb-next after fixing up the context since it no
>>> longer applied to the mainline (
>>> https://git.kernel.org/cgit/linux/kernel/git/jwessel/kgdb.git/log/?h=kgdb-next).
>>> If there is further discussion on the point above, another patch can be
>>> added, but it I am assuming this is the way you desire it to work as
>>> there are some other architectures that use the same behaviour. I do
>>> not presently have any ARM64 hardware to validate this particular
>>> change.
>>>
>>> I also added to the patch a "Cc: linux-stable <stable@vger.kernel.org>"
>>> so we can have this appear on some of the older kernels.
>> Since Will asked me to split this patch into a few, I need some reworks
>> to clarify which hunks in the patch are necessary for which version of kernel.
> Yes, splitting the patch would be much better for sorting out the stable
> backports too. Jason, please can you drop the patch for now? I don't mind
> whether the end result goes via arm64 or kgdb, but we should at least both
> agree on it first :)
Splitting it is a very wise idea so that we can have all the -stable kernels patched up with a working single step function.
The separated patches can easily be tagged with the CC line examples as shown below:
Cc: <stable@vger.kernel.org> # 3.15.x-
Cc: <stable@vger.kernel.org> # 4.4
Cc: <stable@vger.kernel.org> # 4.4-4.5
I had dropped the original patch.
Cheers,
Jason.
^ permalink raw reply
* [PATCH] MAINTAINERS: update list of Oxnas maintainers
From: Arnd Bergmann @ 2016-09-19 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916080917.19162-1-narmstrong@baylibre.com>
On Friday, September 16, 2016 10:09:17 AM CEST Neil Armstrong wrote:
> Add a new list address in the MAINTAINERS file for the Oxnas platform.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Applied to next/soc, thanks!
When you send a single patch to be applied, please try to be specific
about who you send it to, and put only the recipient (arm at kernel.org here)
on "To:", while the mailing lists and any other people should all be on
Cc.
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: drivers for v4.9 (#1)
From: Arnd Bergmann @ 2016-09-19 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a8fabikx.fsf@free-electrons.com>
On Wednesday, September 14, 2016 5:35:10 PM CEST Gregory CLEMENT wrote:
> mvebu drivers for 4.9 (part 1)
>
> - Add pinctrl and clk support for the Orion5x SoC mv88f5181 variant
>
> ----------------------------------------------------------------
> Jamie Lentin (2):
> clk: mvebu: Add clk support for the orion5x SoC mv88f5181
> pinctrl: mvebu: orion5x: Generalise mv88f5181l support for 88f5181
>
> .../devicetree/bindings/clock/mvebu-core-clock.txt | 1 +
> .../bindings/pinctrl/marvell,orion-pinctrl.txt | 4 +-
> drivers/clk/mvebu/orion.c | 70 ++++++++++++++++++++++
> drivers/pinctrl/mvebu/pinctrl-orion.c | 23 +++----
> 4 files changed, 86 insertions(+), 12 deletions(-)
I see this touches pinctrl and clk drivers, but none of the maintainers are
on Cc for this pull request, nor have they provided an Ack for the patches
according to your git log.
Why did you not send the driver changes to them?
Not pulled for now, until this is resolved, sorry.
Arnd
^ permalink raw reply
* [GIT PULL] Qualcomm EBI2 bindings and bus driver
From: Arnd Bergmann @ 2016-09-19 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYvowN2htUuN46JNVdfaKNw3AEbBfzAeScHQcLU5o3ZUg@mail.gmail.com>
On Thursday, September 8, 2016 3:34:42 PM CEST Linus Walleij wrote:
> please pull this new EBI2 bus driver and its bindings into an
> apropriate branch in the ARM SoC tree. The binding now has
> Rob Herrings ACK and we have hopefully finally figured out how
> this should be done.
>
I just noticed that you sent the pull request directly to arm at kernel.org
rather than the Qualcomm maintainers (which are only on Cc).
Usually, I'd expect to see this forwarded from Andy, is there a
reason to do it differently here? If so, can I have an Ack
from him?
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: soc for v4.9 (#1)
From: Arnd Bergmann @ 2016-09-19 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21718559.viYP8Vn8qc@wuerfel>
On Monday, September 19, 2016 11:46:22 PM CEST Arnd Bergmann wrote:
> On Wednesday, September 14, 2016 5:34:37 PM CEST Gregory CLEMENT wrote:
> > mvebu soc for 4.9 (part 1)
> >
> > - irq cleanup for old mvebu SoC
> > - Convert orion5x based SoC Netgear WNR854T to devicetree
> >
>
> Pulled into next/soc, thanks!
Sorry, backed out again after seeing the PCI stuff on the WNR854T in
there. I thought the plan was to leave out PCI support from the DT
based machine file, and leave the old board in place, or am I
missing something?
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: soc for v4.9 (#1)
From: Arnd Bergmann @ 2016-09-19 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87bmzqbilu.fsf@free-electrons.com>
On Wednesday, September 14, 2016 5:34:37 PM CEST Gregory CLEMENT wrote:
> mvebu soc for 4.9 (part 1)
>
> - irq cleanup for old mvebu SoC
> - Convert orion5x based SoC Netgear WNR854T to devicetree
>
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [PATCH 4/4] ARM: at91/dt: sama5d4: Add new MA5D4EVK manufacturer compat
From: Marek Vasut @ 2016-09-19 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919214044.9615-1-marex@denx.de>
The board is now manufactured by Aries Embedded GmbH, update compat string.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi | 4 ++--
arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi b/arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi
index 7c75872..b40dd9f 100644
--- a/arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi
+++ b/arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi
@@ -12,8 +12,8 @@
#include "sama5d4.dtsi"
/ {
- model = "DENX MA5D4";
- compatible = "denx,ma5d4", "atmel,sama5d4", "atmel,sama5";
+ model = "Aries/DENX MA5D4";
+ compatible = "aries,ma5d4", "denx,ma5d4", "atmel,sama5d4", "atmel,sama5";
memory {
reg = <0x20000000 0x10000000>;
diff --git a/arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts b/arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts
index a52f520..d4ebd90 100644
--- a/arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts
+++ b/arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts
@@ -13,8 +13,8 @@
#include "at91-sama5d4_ma5d4.dtsi"
/ {
- model = "DENX MA5D4EVK";
- compatible = "denx,ma5d4evk", "atmel,sama5d4", "atmel,sama5";
+ model = "Aries/DENX MA5D4EVK";
+ compatible = "aries,ma5d4evk", "denx,ma5d4evk", "atmel,sama5d4", "atmel,sama5";
chosen {
stdout-path = "serial3:115200n8";
--
2.9.3
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: socfpga: Add new MCVEVK manufacturer compat
From: Marek Vasut @ 2016-09-19 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919214044.9615-1-marex@denx.de>
The board is now manufactured by Aries Embedded GmbH, update compat string.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
---
arch/arm/boot/dts/socfpga_cyclone5_mcv.dtsi | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_mcv.dtsi b/arch/arm/boot/dts/socfpga_cyclone5_mcv.dtsi
index f86f9c0..6ad3b1e 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_mcv.dtsi
+++ b/arch/arm/boot/dts/socfpga_cyclone5_mcv.dtsi
@@ -18,7 +18,7 @@
#include "socfpga_cyclone5.dtsi"
/ {
- model = "DENX MCV";
+ model = "Aries/DENX MCV";
compatible = "altr,socfpga-cyclone5", "altr,socfpga";
memory {
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
index caa40cf..8882314 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
@@ -18,7 +18,7 @@
#include "socfpga_cyclone5_mcv.dtsi"
/ {
- model = "DENX MCV EVK";
+ model = "Aries/DENX MCV EVK";
compatible = "altr,socfpga-cyclone5", "altr,socfpga";
aliases {
--
2.9.3
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: mx5: Add new M53EVK manufacturer compat
From: Marek Vasut @ 2016-09-19 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919214044.9615-1-marex@denx.de>
The board is now manufactured by Aries Embedded GmbH, update compat string.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/boot/dts/imx53-m53.dtsi | 4 ++--
arch/arm/boot/dts/imx53-m53evk.dts | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx53-m53.dtsi b/arch/arm/boot/dts/imx53-m53.dtsi
index d259f57..ec390aa5 100644
--- a/arch/arm/boot/dts/imx53-m53.dtsi
+++ b/arch/arm/boot/dts/imx53-m53.dtsi
@@ -12,8 +12,8 @@
#include "imx53.dtsi"
/ {
- model = "DENX M53";
- compatible = "denx,imx53-m53", "fsl,imx53";
+ model = "Aries/DENX M53";
+ compatible = "aries,imx53-m53", "denx,imx53-m53", "fsl,imx53";
memory {
reg = <0x70000000 0x20000000>,
diff --git a/arch/arm/boot/dts/imx53-m53evk.dts b/arch/arm/boot/dts/imx53-m53evk.dts
index dcee1e0f..4347a32 100644
--- a/arch/arm/boot/dts/imx53-m53evk.dts
+++ b/arch/arm/boot/dts/imx53-m53evk.dts
@@ -13,8 +13,8 @@
#include "imx53-m53.dtsi"
/ {
- model = "DENX M53EVK";
- compatible = "denx,imx53-m53evk", "fsl,imx53";
+ model = "Aries/DENX M53EVK";
+ compatible = "aries,imx53-m53evk", "denx,imx53-m53evk", "fsl,imx53";
display1: display at di1 {
compatible = "fsl,imx-parallel-display";
--
2.9.3
^ permalink raw reply related
* [PATCH 1/4] ARM: dts: mxs: Add new M28EVK manufacturer compat
From: Marek Vasut @ 2016-09-19 21:40 UTC (permalink / raw)
To: linux-arm-kernel
The board is now manufactured by Aries Embedded GmbH, update compat string.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/boot/dts/imx28-m28.dtsi | 4 ++--
arch/arm/boot/dts/imx28-m28evk.dts | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx28-m28.dtsi b/arch/arm/boot/dts/imx28-m28.dtsi
index 214bb15..a69856e 100644
--- a/arch/arm/boot/dts/imx28-m28.dtsi
+++ b/arch/arm/boot/dts/imx28-m28.dtsi
@@ -12,8 +12,8 @@
#include "imx28.dtsi"
/ {
- model = "DENX M28";
- compatible = "denx,m28", "fsl,imx28";
+ model = "Aries/DENX M28";
+ compatible = "aries,m28", "denx,m28", "fsl,imx28";
memory {
reg = <0x40000000 0x08000000>;
diff --git a/arch/arm/boot/dts/imx28-m28evk.dts b/arch/arm/boot/dts/imx28-m28evk.dts
index 8d04e57..dbfb8aa 100644
--- a/arch/arm/boot/dts/imx28-m28evk.dts
+++ b/arch/arm/boot/dts/imx28-m28evk.dts
@@ -13,8 +13,8 @@
#include "imx28-m28.dtsi"
/ {
- model = "DENX M28EVK";
- compatible = "denx,m28evk", "fsl,imx28";
+ model = "Aries/DENX M28EVK";
+ compatible = "aries,m28evk", "denx,m28evk", "fsl,imx28";
apb at 80000000 {
apbh at 80000000 {
--
2.9.3
^ permalink raw reply related
* [PATCH] arm64: migrate exception table users off module.h and onto extable.h
From: Paul Gortmaker @ 2016-09-19 21:38 UTC (permalink / raw)
To: linux-arm-kernel
These files were only including module.h for exception table
related functions. We've now separated that content out into its
own file "extable.h" so now move over to that and avoid all the
extra header content in module.h that we don't really need to compile
these files.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
[see: https://lkml.org/lkml/2016/7/24/224 for additional context if needed]
arch/arm64/kernel/probes/kprobes.c | 2 +-
arch/arm64/mm/extable.c | 2 +-
arch/arm64/mm/fault.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index bf9768588288..9c1866ef3271 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -19,7 +19,7 @@
#include <linux/kasan.h>
#include <linux/kernel.h>
#include <linux/kprobes.h>
-#include <linux/module.h>
+#include <linux/extable.h>
#include <linux/slab.h>
#include <linux/stop_machine.h>
#include <linux/stringify.h>
diff --git a/arch/arm64/mm/extable.c b/arch/arm64/mm/extable.c
index 81acd4706878..c9f118cd812b 100644
--- a/arch/arm64/mm/extable.c
+++ b/arch/arm64/mm/extable.c
@@ -2,7 +2,7 @@
* Based on arch/arm/mm/extable.c
*/
-#include <linux/module.h>
+#include <linux/extable.h>
#include <linux/uaccess.h>
int fixup_exception(struct pt_regs *regs)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index c8beaa0da7df..427f2fd49463 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -18,7 +18,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
-#include <linux/module.h>
+#include <linux/extable.h>
#include <linux/signal.h>
#include <linux/mm.h>
#include <linux/hardirq.h>
--
2.8.4
^ permalink raw reply related
* [PATCH] arm: migrate exception table users off module.h and onto extable.h
From: Paul Gortmaker @ 2016-09-19 21:38 UTC (permalink / raw)
To: linux-arm-kernel
These files were only including module.h for exception table
related functions. We've now separated that content out into its
own file "extable.h" so now move over to that and avoid all the
extra header content in module.h that we don't really need to compile
these files.
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
[see: https://lkml.org/lkml/2016/7/24/224 for additional context if needed]
arch/arm/mm/extable.c | 2 +-
arch/arm/mm/fault.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/extable.c b/arch/arm/mm/extable.c
index 312e15e6d00b..f436f7439e46 100644
--- a/arch/arm/mm/extable.c
+++ b/arch/arm/mm/extable.c
@@ -1,7 +1,7 @@
/*
* linux/arch/arm/mm/extable.c
*/
-#include <linux/module.h>
+#include <linux/extable.h>
#include <linux/uaccess.h>
int fixup_exception(struct pt_regs *regs)
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 3a2e678b8d30..94de590db99e 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -8,7 +8,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-#include <linux/module.h>
+#include <linux/extable.h>
#include <linux/signal.h>
#include <linux/mm.h>
#include <linux/hardirq.h>
--
2.8.4
^ permalink raw reply related
* [PATCH] of: Add vendor prefix for Aries Embedded GmbH
From: Marek Vasut @ 2016-09-19 21:38 UTC (permalink / raw)
To: linux-arm-kernel
Add vendor prefix for Aries Embedded GmbH
http://www.aries-embedded.de/
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 69caf14..522dd65 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -27,6 +27,7 @@ analogix Analogix Semiconductor, Inc.
apm Applied Micro Circuits Corporation (APM)
aptina Aptina Imaging
arasan Arasan Chip Systems
+aries Aries Embedded GmbH
arm ARM Ltd.
armadeus ARMadeus Systems SARL
arrow Arrow Electronics
--
2.9.3
^ permalink raw reply related
* [PATCH v15 5/5] ASoC: rockchip: Add DP dai-links to the rk3399-gru machine driver
From: Rob Herring @ 2016-09-19 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473473748-22331-6-git-send-email-zyw@rock-chips.com>
On Fri, Sep 09, 2016 at 07:15:48PM -0700, Chris Zhong wrote:
> This patch adds DP audio output support to the rk3399-gru machine
> driver.
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> ---
>
> Changes in v15: None
> Changes in v14: None
> Changes in v13: None
> Changes in v12: None
> Changes in v11: None
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - change spdif to i2s2
>
> Changes in v2:
> - correct the commit message
>
> Changes in v1: None
>
> .../bindings/sound/rockchip,rk3399-gru-sound.txt | 11 +--
> sound/soc/rockchip/rk3399_gru_sound.c | 93 ++++++++++++++++++++++
> 2 files changed, 99 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
> index f19b6c8..83af540 100644
> --- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
> +++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
> @@ -1,15 +1,16 @@
> -ROCKCHIP with MAX98357A/RT5514/DA7219 codecs on GRU boards
> +ROCKCHIP with MAX98357A/RT5514/DA7219 codecs and DP via spdif on GRU boards
>
> Required properties:
> - compatible: "rockchip,rk3399-gru-sound"
> -- rockchip,cpu: The phandle of the Rockchip I2S controller that's
> +- rockchip,cpu: The phandle of the Rockchip I2S controller controller that's
Huh?
^ permalink raw reply
* [PATCH v5 1/9] Documentation: dt-bindings: Document STM32 EXTI controller bindings
From: Rob Herring @ 2016-09-19 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473432124-6784-2-git-send-email-alexandre.torgue@st.com>
On Fri, Sep 09, 2016 at 04:41:56PM +0200, Alexandre TORGUE wrote:
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 3/3] dt-bindings: reset: oxnas: Update for OX820
From: Rob Herring @ 2016-09-19 21:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473428153.3023.34.camel@pengutronix.de>
On Fri, Sep 09, 2016 at 03:35:53PM +0200, Philipp Zabel wrote:
> Hi Neil,
>
> Am Freitag, den 09.09.2016, 15:19 +0200 schrieb Neil Armstrong:
> > 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.
>
> Not sure if the OX820 reset controller should be considered "compatible"
> to OX810SE. The register layout and usage is the same, but the reset
> indices are different. Does this warrant a new compatible string, or
> should this be
> compatible = "oxsemi,ox820-reset", "oxsemi,ox810se-reset"?
Correct. Different connections are fine since the connections are
described in the DT. However you could have some connections not
described, so a new compatible may still be needed for that purpose (in
addition to other reasons you do a new compatible for new SoCs).
Rob
^ permalink raw reply
* [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization
From: Doug Anderson @ 2016-09-19 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919224352.3b84b6c0@bbrezillon>
Hi,
On Mon, Sep 19, 2016 at 1:43 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> On Mon, 19 Sep 2016 11:12:12 -0700
> Doug Anderson <dianders@chromium.org> wrote:
>
>> Hi,
>>
>> On Mon, Sep 19, 2016 at 11:06 AM, Boris Brezillon
>> <boris.brezillon@free-electrons.com> wrote:
>> > On Mon, 19 Sep 2016 10:52:51 -0700
>> > Doug Anderson <dianders@chromium.org> wrote:
>> >
>> >> Hi,
>> >>
>> >> On Mon, Sep 19, 2016 at 10:48 AM, Boris Brezillon
>> >> <boris.brezillon@free-electrons.com> wrote:
>> >> > The PWM chip has always claimed the pins and muxed them to the PWM IP.
>> >> > So, this means it's broken from the beginning, and my patch is only
>> >> > uncovering the problem (unless the pins stay configured as input until
>> >> > the PWM is enabled, which I'm not sure is the case).
>> >>
>> >> Such a solution is achievable with the pinctrl APIs pretty easily.
>> >> You might not be able to use the automatic "init" state but you can do
>> >> something similar and switch to an "active" state once the PWM is
>> >> actually turned on the first time.
>> >
>> > But is it really the case here (I don't see any code requesting a
>> > specific pinmux depending on the PWM state)?
>>
>> It is not happening right now as far as I know. ...but that's a bug.
>>
>> > Anyway, we really need to handle this case, we should define the
>> > typical voltage when the PWM is disabled. Same as what you suggested
>> > with voltage-when-input, but with a different naming (since the concept
>> > of pinmux is PWM hardware/driver specific).
>> >
>> > voltage-when-pwm-disabled = <...>;
>>
>> Voltage when disabled and voltage when input are two different states.
>> A disabled PWM will typically either drive high or low (depending on
>> where it was when you turned it off). Not all "disabled" states will
>> mean that the pin is configured as an input.
>
> Okay, after reading again your first answer, I think I understand why
> you want to differentiate the when-disabled and when-input cases. You
> want to use the "init" and "default" pinctrl states. The "init" state
> (applied at probe time) would keep the PWM pin in gpio+input mode and
> the "default" state (applied when the PWM device is enabled for the
> first time) would mux the pin to the PWM device.
> Your solution requires that the pwm-regulator device knows in which
> state the pin attached to the PWM is, which IMO is breaking the
> layering we have right now: a PWM-regulator is assigned a PWM device
> which is assigned a pin and a pinmux config.
> Another solution would be to expose an additional information in the
> pwm_state: whether the PWM is in the INIT state (probed, but not yet
> configured by its user) or DEFAULT state (probed and already
> configured by its user). But again, by doing that we also expose
> internal PWM details to its user, which I'm not sure will help keep
> the PWM API simple.
One note is that probably using the "init" state would not be a good
idea because it would make assumptions about what state the firmware
left things. Possibly a firmware update could cause a change from a
PWM being left as "input" to the PWM actually being initted.
...really we should be able to detect if the PWM was left on at
bootup.
> Actually, I had something slightly different in mind. I thought about
> having two new pinctrl states ("enabled" and "disabled"). The "enabled"
> state (pin muxed to the PWM device) would be applied each time the PWM
> is enabled, and "disabled" state (gpio+input mode) would be applied each
> time the PWM is disabled.
Adding "enabled" and "disabled" state is sane IMHO. At the moment the
PWM regulator never actually puts things in "disabled" state, but I
suppose it could in the future.
> This way we can guarantee that even when the PWM is disabled, the
> PWM-driven regulator is configured to output a non-destructive voltage.
> Hence my suggestion to name the property 'voltage-when-pwm-disabled'.
That's fine with me, as long as the PWM starts up as "enabled" if the
pinctrl happened to be left initted by the BIOS.
-Doug
^ permalink raw reply
* [PATCH] coresight: tmc: implementing TMC-ETR AUX space API
From: Mathieu Poirier @ 2016-09-19 21:14 UTC (permalink / raw)
To: linux-arm-kernel
This patch implements the AUX area interfaces required to
use the TMC-ETR (configured to work in scatter-gather mode)
from the Perf sub-system.
Some of this work was inspired from the original implementation
done by Pratik Patel at CodeAurora.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 629 +++++++++++++++++++++++-
drivers/hwtracing/coresight/coresight-tmc.h | 1 +
2 files changed, 621 insertions(+), 9 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 6d7de0309e94..581d6393bb5d 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -17,10 +17,60 @@
#include <linux/coresight.h>
#include <linux/dma-mapping.h>
+#include <linux/slab.h>
+
#include "coresight-priv.h"
#include "coresight-tmc.h"
-void tmc_etr_enable_hw(struct tmc_drvdata *drvdata)
+/**
+ * struct etr_page - DMA'able and virtual address representation for a page
+ * @daddr: DMA'able page address returned by dma_map_page()
+ * @vaddr: Virtual address returned by page_address()
+ */
+struct etr_page {
+ dma_addr_t daddr;
+ u64 vaddr;
+};
+
+/**
+ * struct cs_etr_buffer - keep track of a recording session' specifics
+ * @dev: device reference to be used with the DMA API
+ * @tmc: generic portion of the TMC buffers
+ * @etr_nr_pages: number of memory pages for the ETR-SG trace storage
+ * @pt_vaddr: the virtual address of the first page table entry
+ * @page_addr: quick access to all the pages held in the page table
+ */
+struct cs_etr_buffers {
+ struct device *dev;
+ struct cs_buffers tmc;
+ unsigned int etr_nr_pages;
+ void __iomem *pt_vaddr;
+ struct etr_page page_addr[0];
+};
+
+#define TMC_ETR_ENTRIES_PER_PT (PAGE_SIZE / sizeof(u32))
+
+/*
+ * Helpers for scatter-gather descriptors. Descriptors are defined as follow:
+ *
+ * ---Bit31------------Bit4-------Bit1-----Bit0--
+ * | Address[39:12] | SBZ | Entry Type |
+ * ----------------------------------------------
+ *
+ * Address: Bits [39:12] of a physical page address. Bits [11:0] are
+ * always zero.
+ *
+ * Entry type: b10 - Normal entry
+ * b11 - Last entry in a page table
+ * b01 - Last entry
+ */
+#define TMC_ETR_SG_LST_ENT(phys_pte) (((phys_pte >> PAGE_SHIFT) << 4) | 0x1)
+#define TMC_ETR_SG_ENT(phys_pte) (((phys_pte >> PAGE_SHIFT) << 4) | 0x2)
+#define TMC_ETR_SG_NXT_TBL(phys_pte) (((phys_pte >> PAGE_SHIFT) << 4) | 0x3)
+
+#define TMC_ETR_SG_ENT_TO_PG(entry) ((entry >> 4) << PAGE_SHIFT)
+
+void tmc_etr_enable_hw_cnt_mem(struct tmc_drvdata *drvdata)
{
u32 axictl;
@@ -57,7 +107,47 @@ void tmc_etr_enable_hw(struct tmc_drvdata *drvdata)
CS_LOCK(drvdata->base);
}
-static void tmc_etr_dump_hw(struct tmc_drvdata *drvdata)
+void tmc_etr_enable_hw_sg_mem(struct tmc_drvdata *drvdata)
+{
+ u32 axictl;
+
+ CS_UNLOCK(drvdata->base);
+
+ /* Wait for TMCSReady bit to be set */
+ tmc_wait_for_tmcready(drvdata);
+
+ writel_relaxed(TMC_MODE_CIRCULAR_BUFFER, drvdata->base + TMC_MODE);
+
+ axictl = readl_relaxed(drvdata->base + TMC_AXICTL);
+ /* half the write buffer depth */
+ axictl |= TMC_AXICTL_WR_BURST_08;
+ /* enable scatter-gather mode */
+ axictl |= TMC_AXICTL_SCT_GAT_MODE;
+ /* enable non-secure, priviledged access */
+ axictl |= (TMC_AXICTL_PROT_CTL_B0 | TMC_AXICTL_PROT_CTL_B1);
+
+ writel_relaxed(axictl, drvdata->base + TMC_AXICTL);
+
+ writel_relaxed(drvdata->paddr, drvdata->base + TMC_DBALO);
+
+ /*
+ * DBAHI Holds the upper eight bits of the 40-bit address used to
+ * locate the trace buffer in system memory.
+ */
+ writel_relaxed((drvdata->paddr >> 32) & 0xFF,
+ drvdata->base + TMC_DBAHI);
+
+ writel_relaxed(TMC_FFCR_EN_FMT | TMC_FFCR_EN_TI |
+ TMC_FFCR_FON_FLIN | TMC_FFCR_FON_TRIG_EVT |
+ TMC_FFCR_TRIGON_TRIGIN,
+ drvdata->base + TMC_FFCR);
+ writel_relaxed(drvdata->trigger_cntr, drvdata->base + TMC_TRG);
+ tmc_enable_hw(drvdata);
+
+ CS_LOCK(drvdata->base);
+}
+
+static void tmc_etr_dump_hw_cnt_mem(struct tmc_drvdata *drvdata)
{
u32 rwp, val;
@@ -87,7 +177,8 @@ static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
* read before the TMC is disabled.
*/
if (local_read(&drvdata->mode) == CS_MODE_SYSFS)
- tmc_etr_dump_hw(drvdata);
+ tmc_etr_dump_hw_cnt_mem(drvdata);
+
tmc_disable_hw(drvdata);
CS_LOCK(drvdata->base);
@@ -157,7 +248,7 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev, u32 mode)
memset(drvdata->vaddr, 0, drvdata->size);
- tmc_etr_enable_hw(drvdata);
+ tmc_etr_enable_hw_cnt_mem(drvdata);
out:
spin_unlock_irqrestore(&drvdata->spinlock, flags);
@@ -199,7 +290,7 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, u32 mode)
goto out;
}
- tmc_etr_enable_hw(drvdata);
+ tmc_etr_enable_hw_sg_mem(drvdata);
out:
spin_unlock_irqrestore(&drvdata->spinlock, flags);
@@ -241,9 +332,528 @@ static void tmc_disable_etr_sink(struct coresight_device *csdev)
dev_info(drvdata->dev, "TMC-ETR disabled\n");
}
+/*
+ * The default perf ring buffer size is 32 and 1024 pages for user and kernel
+ * space respectively. The size of the intermediate SG list is allowed
+ * to match the size of the perf ring buffer but cap it to the default
+ * kernel size.
+ */
+#define DEFAULT_NR_KERNEL_PAGES 1024
+static int tmc_get_etr_pages(int nr_pages)
+{
+ if (nr_pages <= DEFAULT_NR_KERNEL_PAGES)
+ return nr_pages;
+
+ return DEFAULT_NR_KERNEL_PAGES;
+}
+
+/*
+ * Go through all the pages in the SG list and check if @phys_addr
+ * falls within one of those. If so record the information in
+ * @page and @offset.
+ */
+static int
+tmc_get_sg_page_index(struct cs_etr_buffers *etr_buffer,
+ u64 phys_addr, u32 *page, u32 *offset)
+{
+ int i = 0, pte = 0, nr_pages = etr_buffer->etr_nr_pages;
+ u32 *page_table_itr = etr_buffer->pt_vaddr;
+ phys_addr_t phys_page_addr;
+
+ /* Circle through all the pages in the SG list */
+ while (pte < nr_pages) {
+ phys_page_addr = TMC_ETR_SG_ENT_TO_PG((u64)*page_table_itr);
+
+ /* Does @phys_addr falls within this page? */
+ if (phys_addr >= phys_page_addr &&
+ phys_addr < (phys_page_addr + PAGE_SIZE)) {
+ *page = pte;
+ *offset = phys_addr - phys_page_addr;
+ return 0;
+ }
+
+ if (pte == nr_pages - 1) {
+ /* The last page in the SG list */
+ pte++;
+ } else if (i == TMC_ETR_ENTRIES_PER_PT - 1) {
+ /*
+ * The last entry in this page table - get a reference
+ * on the next page table and do _not_ increment @pte
+ */
+ page_table_itr = phys_to_virt(phys_page_addr);
+ i = 0;
+ } else {
+ /* A normal page in the SG list */
+ page_table_itr++;
+ pte++;
+ i++;
+ }
+ }
+
+ return -EINVAL;
+}
+
+static void tmc_sg_page_sync(struct cs_etr_buffers *etr_buffer,
+ int start_page, u64 to_sync)
+{
+ int i, index;
+ int pages_to_sync = DIV_ROUND_UP_ULL(to_sync, PAGE_SIZE);
+ dma_addr_t daddr;
+ struct device *dev = etr_buffer->dev;
+
+ for (i = start_page; i < (start_page + pages_to_sync); i++) {
+ /* Wrap around the etr page list if need be */
+ index = i % etr_buffer->etr_nr_pages;
+ daddr = etr_buffer->page_addr[index].daddr;
+ dma_sync_single_for_cpu(dev, daddr, PAGE_SIZE, DMA_FROM_DEVICE);
+ }
+}
+
+static void tmc_free_sg_buffer(struct cs_etr_buffers *etr_buffer, int nr_pages)
+{
+ int i = 0, pte = 0;
+ u32 *page_addr, *page_table_itr;
+ u32 *page_table_addr = etr_buffer->pt_vaddr;
+ phys_addr_t phys_page_addr;
+ dma_addr_t daddr;
+ struct device *dev = etr_buffer->dev;
+
+ if (!page_table_addr)
+ return;
+
+ page_table_itr = page_table_addr;
+ while (pte < nr_pages) {
+ phys_page_addr = TMC_ETR_SG_ENT_TO_PG((u64)*page_table_itr);
+ page_addr = phys_to_virt(phys_page_addr);
+
+ if (pte == nr_pages - 1) {
+ /* The last page in the SG list */
+ daddr = etr_buffer->page_addr[pte].daddr;
+ page_addr = (u32 *)etr_buffer->page_addr[pte].vaddr;
+
+ dma_unmap_page(dev, daddr, PAGE_SIZE,
+ DMA_FROM_DEVICE);
+
+ /* Free the current page */
+ free_page((unsigned long)page_addr);
+ /* Free the current page table */
+ free_page((unsigned long)page_table_addr);
+
+ pte++;
+ } else if (i == TMC_ETR_ENTRIES_PER_PT - 1) {
+ /* The last entry in this page table */
+ page_addr = phys_to_virt(phys_page_addr);
+
+ /* Free the current page table */
+ free_page((unsigned long)page_table_addr);
+ /* Move along to the next one */
+ page_table_addr = page_addr;
+ page_table_itr = page_table_addr;
+
+ i = 0;
+ } else {
+ /* A normal page in the SG list */
+ daddr = etr_buffer->page_addr[pte].daddr;
+ page_addr = (u32 *)etr_buffer->page_addr[pte].vaddr;
+
+ dma_unmap_page(dev, daddr, PAGE_SIZE,
+ DMA_FROM_DEVICE);
+
+ /* Free the current page */
+ free_page((unsigned long)page_addr);
+
+ page_table_itr++;
+ pte++;
+ i++;
+ }
+ }
+}
+
+static dma_addr_t tmc_setup_dma_page(struct device *dev, struct page *page)
+{
+ dma_addr_t daddr;
+
+ /*
+ * No data is communicated to the device, as such there is no point
+ * in setting the direction to DMA_BIDIRECTIONAL. See
+ * Documentation/DMA-API-HOWTO.txt for details.
+ */
+ daddr = dma_map_page(dev, page, 0, PAGE_SIZE, DMA_FROM_DEVICE);
+ if (dma_mapping_error(dev, daddr)) {
+ __free_page(page);
+ return -EINVAL;
+ }
+
+ return daddr;
+}
+
+static int
+tmc_alloc_sg_buffer(struct cs_etr_buffers *etr_buffer, int cpu, int nr_pages)
+{
+ int i = 0, node, pte = 0, ret = 0;
+ dma_addr_t dma_page_addr;
+ u32 *page_table_addr, *page_addr;
+ struct page *page;
+ struct device *dev = etr_buffer->dev;
+
+ if (cpu == -1)
+ cpu = smp_processor_id();
+ node = cpu_to_node(cpu);
+
+ /* Allocate the first page table */
+ page = alloc_pages_node(node, GFP_KERNEL | __GFP_ZERO, 0);
+ if (!page)
+ return -ENOMEM;
+
+ page_table_addr = page_address(page);
+ /*
+ * Keep track of the first page table, the rest will be chained
+ * in the last page table entry.
+ */
+ etr_buffer->pt_vaddr = page_table_addr;
+
+ while (pte < nr_pages) {
+ page = alloc_pages_node(node,
+ GFP_KERNEL | __GFP_ZERO, 0);
+ if (!page) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ page_addr = page_address(page);
+
+ if (pte == nr_pages - 1) {
+ /* The last page in the list */
+ dma_page_addr = tmc_setup_dma_page(dev, page);
+ if (dma_page_addr == -EINVAL) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ *page_table_addr = TMC_ETR_SG_LST_ENT(dma_page_addr);
+
+ etr_buffer->page_addr[pte].vaddr = (u64)page_addr;
+ etr_buffer->page_addr[pte].daddr = dma_page_addr;
+
+ pte++;
+ } else if (i == TMC_ETR_ENTRIES_PER_PT - 1) {
+ /* The last entry in this page table */
+ *page_table_addr =
+ TMC_ETR_SG_NXT_TBL(virt_to_phys(page_addr));
+ /* Move on to the next page table */
+ page_table_addr = page_addr;
+
+ i = 0;
+ } else {
+ /* A normal page in the SG list */
+ dma_page_addr = tmc_setup_dma_page(dev, page);
+ if (dma_page_addr == -EINVAL) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ *page_table_addr = TMC_ETR_SG_ENT(dma_page_addr);
+
+ etr_buffer->page_addr[pte].vaddr = (u64)page_addr;
+ etr_buffer->page_addr[pte].daddr = dma_page_addr;
+
+ page_table_addr++;
+ pte++;
+ i++;
+ }
+ }
+
+ return 0;
+
+err:
+ tmc_free_sg_buffer(etr_buffer, pte);
+ etr_buffer->pt_vaddr = NULL;
+ return ret;
+}
+
+static void *tmc_alloc_etr_buffer(struct coresight_device *csdev, int cpu,
+ void **pages, int nr_pages, bool overwrite)
+{
+ int etr_pages, node;
+ struct device *dev = csdev->dev.parent;
+ struct cs_etr_buffers *buf;
+
+ if (cpu == -1)
+ cpu = smp_processor_id();
+ node = cpu_to_node(cpu);
+
+ /* Register DBALO and DBAHI form a 40-bit address range */
+ if (dma_set_mask(dev, DMA_BIT_MASK(40)))
+ return NULL;
+
+ /*
+ * The HW can't start collecting data in the middle of the SG list,
+ * it must start at the beginning. As such we can't use the ring
+ * buffer provided by perf as entries into the page tables since
+ * it is not guaranteed that user space will have the chance to
+ * consume the data before the next trace run begins.
+ *
+ * To work around this reserve a set of pages that will be used as
+ * and intermediate (SG) buffer. This isn't optimal but the best we
+ * can do with the current HW revision.
+ */
+ etr_pages = tmc_get_etr_pages(nr_pages);
+
+ /* Allocate memory structure for interaction with Perf */
+ buf = kzalloc_node(offsetof(struct cs_etr_buffers,
+ page_addr[etr_pages]),
+ GFP_KERNEL, node);
+ if (!buf)
+ return NULL;
+
+ buf->dev = dev;
+
+ if (tmc_alloc_sg_buffer(buf, cpu, etr_pages)) {
+ kfree(buf);
+ return NULL;
+ }
+
+ buf->etr_nr_pages = etr_pages;
+ buf->tmc.snapshot = overwrite;
+ buf->tmc.nr_pages = nr_pages;
+ buf->tmc.data_pages = pages;
+
+ return buf;
+}
+
+static void tmc_free_etr_buffer(void *config)
+{
+ struct cs_etr_buffers *buf = config;
+
+ tmc_free_sg_buffer(buf, buf->etr_nr_pages);
+ kfree(buf);
+}
+
+static int tmc_set_etr_buffer(struct coresight_device *csdev,
+ struct perf_output_handle *handle,
+ void *sink_config)
+{
+ unsigned long head;
+ struct cs_etr_buffers *buf = sink_config;
+ struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+ /* wrap head around to the amount of space we have */
+ head = handle->head & ((buf->tmc.nr_pages << PAGE_SHIFT) - 1);
+
+ /* find the page to write to */
+ buf->tmc.cur = head / PAGE_SIZE;
+
+ /* and offset within that page */
+ buf->tmc.offset = head % PAGE_SIZE;
+
+ local_set(&buf->tmc.data_size, 0);
+
+ /* Keep track of how big the internal SG list is */
+ drvdata->size = buf->etr_nr_pages << PAGE_SHIFT;
+
+ /* Tell the HW where to put the trace data */
+ drvdata->paddr = virt_to_phys(buf->pt_vaddr);
+
+ return 0;
+}
+
+static unsigned long tmc_reset_etr_buffer(struct coresight_device *csdev,
+ struct perf_output_handle *handle,
+ void *sink_config, bool *lost)
+{
+ long size = 0;
+ struct cs_etr_buffers *buf = sink_config;
+ struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+ if (buf) {
+ /*
+ * In snapshot mode ->data_size holds the new address of the
+ * ring buffer's head. The size itself is the whole address
+ * range since we want the latest information.
+ */
+ if (buf->tmc.snapshot) {
+ size = buf->tmc.nr_pages << PAGE_SHIFT;
+ handle->head = local_xchg(&buf->tmc.data_size, size);
+ }
+
+ /*
+ * Tell the tracer PMU how much we got in this run and if
+ * something went wrong along the way. Nobody else can use
+ * this cs_etr_buffers instance until we are done. As such
+ * resetting parameters here and squaring off with the ring
+ * buffer API in the tracer PMU is fine.
+ */
+ *lost = !!local_xchg(&buf->tmc.lost, 0);
+ size = local_xchg(&buf->tmc.data_size, 0);
+ }
+
+ /* Get ready for another run */
+ drvdata->vaddr = NULL;
+ drvdata->paddr = 0;
+
+ return size;
+}
+
+static void tmc_update_etr_buffer(struct coresight_device *csdev,
+ struct perf_output_handle *handle,
+ void *sink_config)
+{
+ bool full;
+ int i, rb_index, sg_index = 0;
+ u32 rwplo, rwphi, rb_offset, sg_offset = 0;
+ u32 stop_index, stop_offset, to_copy, sg_size;
+ u32 *rb_ptr, *sg_ptr;
+ u64 rwp, to_read;
+ struct cs_etr_buffers *etr_buf = sink_config;
+ struct cs_buffers *cs_buf = &etr_buf->tmc;
+ struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+ if (!etr_buf)
+ return;
+
+ /* This shouldn't happen */
+ if (WARN_ON_ONCE(local_read(&drvdata->mode) != CS_MODE_PERF))
+ return;
+
+ CS_UNLOCK(drvdata->base);
+
+ tmc_flush_and_stop(drvdata);
+
+ rwplo = readl_relaxed(drvdata->base + TMC_RWP);
+ rwphi = readl_relaxed(drvdata->base + TMC_RWPHI);
+ full = (readl_relaxed(drvdata->base + TMC_STS) & TMC_STS_FULL);
+
+ /* Combine the high and low part of the rwp to make a full address */
+ rwp = (u64)rwphi << 32;
+ rwp |= rwplo;
+
+ /* Convert the stop address in RAM to a page and an offset */
+ if (tmc_get_sg_page_index(etr_buf, rwp, &stop_index, &stop_offset))
+ goto out;
+
+ if (full) {
+ /*
+ * The buffer head has wrapped around. As such the size
+ * is the entire buffer length and the index and offset in
+ * the scatter-gather list are moved forward.
+ */
+ local_inc(&cs_buf->lost);
+ to_read = drvdata->size;
+ sg_index = stop_index;
+ sg_offset = stop_offset;
+ } else {
+ to_read = (stop_index * PAGE_SIZE) + stop_offset;
+ }
+
+ /*
+ * The TMC RAM buffer may be bigger than the space available in the
+ * perf ring buffer (handle->size). If so advance the RRP so that we
+ * get the latest trace data.
+ */
+ if (to_read > handle->size) {
+ u64 rrp;
+
+ /*
+ * Compute where we should start reading from
+ * relative to rwp.
+ */
+ rrp = rwp + drvdata->size;
+ /* Go back just enough */
+ rrp -= handle->size;
+ /* Make sure we are still within our limits */
+ rrp %= drvdata->size;
+
+ /* Get a new index and offset based on rrp */
+ if (tmc_get_sg_page_index(etr_buf, rrp,
+ &stop_index, &stop_offset))
+ goto out;
+
+ /* Tell user space we lost data */
+ local_inc(&cs_buf->lost);
+ to_read = handle->size;
+ /* Adjust start index and offset */
+ sg_index = stop_index;
+ sg_offset = stop_offset;
+ }
+
+ /* Get a handle on where the Perf ring buffer is */
+ rb_index = cs_buf->cur;
+ rb_offset = cs_buf->offset;
+
+ /* Refresh the SG list */
+ tmc_sg_page_sync(etr_buf, sg_index, to_read);
+
+ for (i = to_read; i > 0; ) {
+ /* Get current location of the perf ring buffer */
+ rb_ptr = cs_buf->data_pages[rb_index] + rb_offset;
+ /* Get current location in the ETR SG list */
+ sg_ptr = (u32 *)(etr_buf->page_addr[sg_index].vaddr +
+ sg_offset);
+
+ /*
+ * First figure out the maximum amount of data we can get out
+ * of the ETR SG list.
+ */
+ if (i < PAGE_SIZE)
+ sg_size = i;
+ else
+ sg_size = PAGE_SIZE - sg_offset;
+
+ /*
+ * We have two page table buffer, one is the Perf ring
+ * buffer while the other one is the internal ETR SG list.
+ * Get the maximum amount of information we can copy from the
+ * ETR SG list to the Perf ring buffer, which happens to be
+ * the minimum space available in the current pages
+ * (both of them).
+ */
+ to_copy = min((u32)(PAGE_SIZE - rb_offset), sg_size);
+
+ /* Transfer trace data from ETR SG list to Perf ring buffer */
+ memcpy(rb_ptr, sg_ptr, to_copy);
+
+ rb_offset += to_copy;
+ sg_offset += to_copy;
+ i -= to_copy;
+
+ /* If a page is full, move to the next one */
+ if (rb_offset == PAGE_SIZE) {
+ rb_offset = 0;
+ rb_index++;
+ rb_index %= cs_buf->nr_pages;
+ }
+
+ if (sg_offset == PAGE_SIZE) {
+ sg_offset = 0;
+ sg_index++;
+ sg_index %= etr_buf->etr_nr_pages;
+ }
+ }
+
+ /*
+ * In snapshot mode all we have to do is communicate to
+ * perf_aux_output_end() the address of the current head. In full
+ * trace mode the same function expects a size to move rb->aux_head
+ * forward.
+ */
+ if (etr_buf->tmc.snapshot)
+ local_set(&etr_buf->tmc.data_size,
+ stop_index * PAGE_SIZE + stop_offset);
+ else
+ local_add(to_read, &etr_buf->tmc.data_size);
+
+out:
+ CS_LOCK(drvdata->base);
+}
+
static const struct coresight_ops_sink tmc_etr_sink_ops = {
.enable = tmc_enable_etr_sink,
.disable = tmc_disable_etr_sink,
+ .alloc_buffer = tmc_alloc_etr_buffer,
+ .free_buffer = tmc_free_etr_buffer,
+ .set_buffer = tmc_set_etr_buffer,
+ .reset_buffer = tmc_reset_etr_buffer,
+ .update_buffer = tmc_update_etr_buffer,
};
const struct coresight_ops tmc_etr_cs_ops = {
@@ -306,11 +916,12 @@ int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata)
if (local_read(&drvdata->mode) == CS_MODE_SYSFS) {
/*
* The trace run will continue with the same allocated trace
- * buffer. The trace buffer is cleared in tmc_etr_enable_hw(),
- * so we don't have to explicitly clear it. Also, since the
- * tracer is still enabled drvdata::buf can't be NULL.
+ * buffer. The trace buffer is cleared in
+ * tmc_etr_enable_hw_cnt_mem(), so we don't have to explicitly
+ * clear it. Also, since the tracer is still enabled
+ * drvdata::buf can't be NULL.
*/
- tmc_etr_enable_hw(drvdata);
+ tmc_etr_enable_hw_cnt_mem(drvdata);
} else {
/*
* The ETR is not tracing and the buffer was just read.
diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
index 44b3ae346118..05dc00d79732 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.h
+++ b/drivers/hwtracing/coresight/coresight-tmc.h
@@ -59,6 +59,7 @@
#define TMC_AXICTL_PROT_CTL_B1 BIT(1)
#define TMC_AXICTL_SCT_GAT_MODE BIT(7)
#define TMC_AXICTL_WR_BURST_16 0xF00
+#define TMC_AXICTL_WR_BURST_08 0x700
/* TMC_FFCR - 0x304 */
#define TMC_FFCR_FLUSHMAN_BIT 6
#define TMC_FFCR_EN_FMT BIT(0)
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/2] Documentation: dt: add bindings for ti-cpufreq
From: Rob Herring @ 2016-09-19 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160901025328.376-2-d-gerlach@ti.com>
On Wed, Aug 31, 2016 at 09:53:27PM -0500, Dave Gerlach wrote:
> Add the device tree bindings document for the TI CPUFreq/OPP driver
> on AM33xx, AM43xx, DRA7, and AM57 SoCs. The operating-points-v2 binding
> allows us to provide an opp-supported-hw property for each OPP to define
> when it is available. This driver is responsible for reading and parsing
> registers to determine which OPPs can be selectively enabled based
> on the specific SoC in use by matching against the opp-supported-hw
> data.
Sorry, for the delay. Missed this somehow.
>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> v1->v2:
> - Dropped all driver/linux specific documentation
> - Fixed some typos
> - Add new compatibles for each SoC family to match against
> - Switched to use am335x example to better demonstrate field one of
> opp-supported-hw.
>
> .../devicetree/bindings/cpufreq/ti-cpufreq.txt | 130 +++++++++++++++++++++
> 1 file changed, 130 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
> new file mode 100644
> index 000000000000..6276ae494121
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
> @@ -0,0 +1,130 @@
> +TI CPUFreq and OPP bindings
> +================================
> +
> +Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
> +families support different OPPs depending on the silicon variant in use.
> +The ti_cpufreq driver can use revision and an efuse value from the SoC to
> +provide the OPP framework with supported hardware information. This is
> +used to determine which OPPs from the operating-points-v2 table get enabled
> +when it is parsed by the OPP framework.
> +
> +Required properties:
> +--------------------
> +In 'cpus' nodes:
> +- operating-points-v2: Phandle to the operating-points-v2 table to use.
> +- ti,syscon-efuse: Syscon phandle, offset to efuse register, efuse register
> + mask, and efuse register shift to get the relevant bits
> + that describe OPP availability.
> +- ti,syscon-rev: Syscon and offset used to look up revision value on SoC.
These have nothing to do with a cpu, so they don't belong here. Maybe
the first is a property of an OPP table, but the second certainly is
not.
> +
> +In 'operating-points-v2' table:
> +- compatible: Should be
> + - 'operating-points-v2-ti-am3352-cpu' for am335x SoCs
> + - 'operating-points-v2-ti-am4372-cpu' for am43xx SoCs
> + - 'operating-points-v2-ti-dra7-cpu' for dra7xx/am57xx SoCs
> +
> +- opp-supported-hw: Two bitfields indicating:
> + 1. Which revision of the SoC the OPP is supported by
> + 2. Which eFuse bits indicate this OPP is available
I tend to think you should handle this with kernel code (bootloader
really) fixing up the OPP table as necessary rather than putting in DT.
Rob
^ permalink raw reply
* [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy
From: Rob Herring @ 2016-09-19 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147407072439.8245.12292695359399379462@sboyd-linaro>
On Fri, Sep 16, 2016 at 7:05 PM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> Quoting Rob Herring (2016-09-16 08:19:51)
>> On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
>> > The high-speed phy on qcom SoCs is controlled via the ULPI
>> > viewport.
>> >
[...]
>> > +- qcom,init-seq:
>> > + Usage: optional
>> > + Value type: <u8 array>
>> > + Definition: Should contain a sequence of ULPI register and address pairs to
>> > + program into the ULPI_EXT_VENDOR_SPECIFIC area. This is related
>> > + to Device Mode Eye Diagram test.
>>
>> We generally nak this type of property. For 1 register I don't care so
>> much. For 100, that would be another story.
>>
>> Is this value per unit, per board, per SoC? Can you limit it to certain
>> registers?
>
> I'm told that this can be per board, depending on how it's wired from
> the phy pins to the usb port. Typically it's the same though for the
> boards I have, mostly because those boards are similar designs with
> respect to how USB is wired. The set of registers is not that many, 4 or
> 5 at most. My understanding is these are tuning registers. Right now the
> register part in the binding is the full register offset, and not an
> offset from ULPI_EXT_VENDOR_SPECIFIC (0x80). I could change this to be
> an offset from that area if you like so that this can't be abused to
> write into standard ULPI registers (there really isn't any way to
> enforce this in software though).
Okay, that sounds fine to me.
Rob
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox