Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] arm64: dts: marvell: Add definition for the Globalscale Marvell ESPRESSOBin Board
From: Romain Perier @ 2016-10-05 14:27 UTC (permalink / raw)
  To: linux-arm-kernel

This adds a basic definition for this board.

Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
 arch/arm64/boot/dts/marvell/Makefile               |  1 +
 .../boot/dts/marvell/armada-3720-espressobin.dts   | 78 ++++++++++++++++++++++
 2 files changed, 79 insertions(+)
 create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts

diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index 308468d..392eeb6 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
 
 # Mvebu SoC Family
 dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-7040-db.dtb
 
 always		:= $(dtb-y)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
new file mode 100644
index 0000000..57035a3
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
@@ -0,0 +1,78 @@
+/*
+ * Device Tree file for Globalscale Marvell ESPRESSOBin Board
+ * Copyright (C) 2016 Marvell
+ *
+ * Romain Perier <romain.perier@free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "armada-372x.dtsi"
+
+/ {
+	model = "Globalscale Marvell ESPRESSOBin Board";
+	compatible = "globalscale,espressobin", "marvell,armada3720", "marvell,armada3710";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x00000000 0x00000000 0x20000000>;
+	};
+};
+
+&pcie0 {
+	status = "okay";
+};
+
+&sata {
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&usb3 {
+	status = "okay";
+};
-- 
2.9.3

^ permalink raw reply related

* [PATCH 2/2] ARM: multi_v7_defconfig: Enable exynos-gsc driver as module
From: Javier Martinez Canillas @ 2016-10-05 14:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475677469-1524-1-git-send-email-javier@osg.samsung.com>

Exynos5 SoCs have a General SCALER (GSCALER) IP block that can be used
to do video streams scaling and color space conversions by hardware.
Enable support for its driver as a module so the GSCALER can be tested.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---

 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 437d0740dec6..bd2f06d334e7 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -561,6 +561,7 @@ CONFIG_VIDEO_EXYNOS4_FIMC_IS=m
 CONFIG_V4L_MEM2MEM_DRIVERS=y
 CONFIG_VIDEO_SAMSUNG_S5P_JPEG=m
 CONFIG_VIDEO_SAMSUNG_S5P_MFC=m
+CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC=m
 CONFIG_VIDEO_STI_BDISP=m
 CONFIG_VIDEO_RENESAS_JPU=m
 CONFIG_VIDEO_RENESAS_VSP1=m
-- 
2.7.4

^ permalink raw reply related

* [PATCH 1/2] ARM: exynos_defconfig: Enable exynos-gsc driver as module
From: Javier Martinez Canillas @ 2016-10-05 14:24 UTC (permalink / raw)
  To: linux-arm-kernel

Exynos5 SoCs have a General SCALER (GSCALER) IP block that can be used
to do video streams scaling and color space conversions by hardware.
Enable support for its driver as a module so the GSCALER can be tested.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---

 arch/arm/configs/exynos_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index c58f6841f8aa..79c415c33f69 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -155,6 +155,7 @@ CONFIG_VIDEO_EXYNOS4_FIMC_IS=m
 CONFIG_V4L_MEM2MEM_DRIVERS=y
 CONFIG_VIDEO_SAMSUNG_S5P_JPEG=m
 CONFIG_VIDEO_SAMSUNG_S5P_MFC=m
+CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC=m
 CONFIG_V4L_TEST_DRIVERS=y
 CONFIG_DRM=y
 CONFIG_DRM_EXYNOS=y
-- 
2.7.4

^ permalink raw reply related

* arm64: kernel BUG at mm/page_alloc.c:1844!
From: Robert Richter @ 2016-10-05 14:13 UTC (permalink / raw)
  To: linux-arm-kernel

Hi all,

I am looking into a memory setup problem on ThunderX systems under
certain memory configurations. The symptom is

 kernel BUG at mm/page_alloc.c:1848!

It happens for some configs with 64k page size enabled (at least since
4.5). The bug triggers for page zones with some pages in the zone not
assigned to this particular zone. In my case some pages that are
marked as nomap were not reassigned to the new zone of node 1, so
those are still assigned to node 0. Mark also reported something
similar for non-numa configs. I think this is a related problem where
not all pages of a zone have been reassigned to the new zone during
setup.

Now, the reason for the mis-configuration is a change in pfn_valid()
which reports pages marked nomap as invalid. In memmap_init_zone()
nomap-pages are not reassigned to that node (__init_single_pfn()).

I tried various changes to fix that, but without success so far:

a) I modified reserve_regions() to use memblock_reserve() instead of
memblock_mark_nomap(). This marked efi regions as reserved instead of
unmap. pfn_valid() now worked as before the nomap change. I could boot
the system but noticed the following malloc assertion which looks like
there is some mem corruption:

  emacs: malloc.c:2395: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.

Other than that the system looked ok so far.

I checked pfn used by the process with kmem:mm_page_alloc_zone_locked,
it looked correct with all pfn allocated from free memory, mem ranges
reported by efi as reserved were not used.

b) I found a quote that for sparsemem the entire memmap (all pages have a
struct *page) for single section (include/linux/mmzone.h):

 "In SPARSEMEM, it is assumed that a valid section has a memmap for
 the entire section."

So I implemented a arm64 private __early_pfn_valid() function that
uses memblock_is_memory() to setup all pages of a zone. I got the same
result as for a).

c) I modified (almost) all arch arm64 users of pfn_valid() to use
memblock_mark_nomap() instead of pfn_valid() and changed pfn_valid()
to use memblock_is_memory(). Same problem as a).

d) Enabling HOLES_IN_ZONE config option does not looks correct for
sparsemem, trying it anyway causes VM_BUG_ON_PAGE() in in line 1849
since (uninitialized) struct *page is accessed. This did not work
either.

I also noticed the efi ranges to be only 4k page aligned, I checked
reserved mem regions, its transformation to 64k alignment looked ok
too. See below for efi and memblock address ranges.

Is there anything else I could do here? Am I missing something? Could
the malloc assertion be another bug which was uncovered after fixing
the first? Any help is appreciated.

Thanks,

-Robert




[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi:   System Table: 0x0000010fffffef18
[    0.000000] efi:   MemMap Address: 0x0000010ff788e018
[    0.000000] efi:   MemMap Size: 0x000006c0
[    0.000000] efi:   MemMap Desc. Size: 0x00000030
[    0.000000] efi:   MemMap Desc. Version: 0x00000001
[    0.000000] efi: EFI v2.40 by Cavium Thunder cn88xx EFI ThunderX-Firmware-Release-1.22.10-0-g4e85766 Aug 24 2016 15:59:03
[    0.000000] efi:  ACPI=0xfffff000  ACPI 2.0=0xfffff014  SMBIOS 3.0=0x10ffafcf000 
[    0.000000] efi: Processing EFI memory map:
[    0.000000] efi:   0x000001400000-0x00000147ffff [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x000001480000-0x0000024affff [Loader Data        |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x0000024b0000-0x0000211fffff [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x000021200000-0x00002121ffff [Loader Data        |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x000021220000-0x0000fffecfff [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x0000fffed000-0x0000ffff4fff [ACPI Reclaim Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0000ffff5000-0x0000ffff5fff [ACPI Memory NVS    |   |  |  |  |  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x0000ffff6000-0x0000ffffffff [ACPI Reclaim Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x000100000000-0x000ff7ffffff [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x000ff8000000-0x000ff801ffff [Boot Data          |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x000ff8020000-0x000fffa9cfff [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x000fffa9d000-0x000fffffffff [Boot Data          |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010000400000-0x010f8465ffff [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010f84660000-0x010f8568ffff [Loader Code        |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010f85690000-0x010ff788afff [Loader Data        |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010ff788b000-0x010ff788dfff [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010ff788e000-0x010ff7890fff [Loader Data        |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010ff7891000-0x010ff78adfff [Loader Code        |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010ff78ae000-0x010ff9e97fff [Boot Data          |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010ff9e98000-0x010ff9f20fff [Runtime Data       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x010ff9f21000-0x010ffaeb5fff [Boot Data          |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010ffaeb6000-0x010ffafc8fff [Runtime Data       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x010ffafc9000-0x010ffafccfff [Runtime Code       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x010ffafcd000-0x010ffaff4fff [Runtime Data       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x010ffaff5000-0x010ffb008fff [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010ffb009000-0x010ffeb6cfff [Boot Data          |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010ffeb6d000-0x010ffec94fff [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010ffec95000-0x010fffe28fff [Boot Data          |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010fffe29000-0x010fffe3ffff [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010fffe40000-0x010fffe53fff [Loader Data        |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010fffe54000-0x010ffffb8fff [Boot Code          |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x010ffffb9000-0x010ffffccfff [Runtime Code       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x010ffffcd000-0x010fffffefff [Runtime Data       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]*
[    0.000000] efi:   0x010ffffff000-0x010fffffffff [Boot Data          |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x804000001000-0x804000001fff [Memory Mapped I/O  |RUN|  |  |  |  |  |  |   |  |  |  |UC]
[    0.000000] efi:   0x87e0d0001000-0x87e0d0001fff [Memory Mapped I/O  |RUN|  |  |  |  |  |  |   |  |  |  |UC]

[    0.000000] MEMBLOCK configuration:
[    0.000000]  memory size = 0x1ffe800000 reserved size = 0x36506a21
[    0.000000]  memory.cnt  = 0x9
[    0.000000]  memory[0x0]     [0x00000001400000-0x000000fffdffff], 0xfebe0000 bytes on node 0 flags: 0x0
[    0.000000]  memory[0x1]     [0x000000fffe0000-0x000000ffffffff], 0x20000 bytes on node 0 flags: 0x4
[    0.000000]  memory[0x2]     [0x00000100000000-0x00000fffffffff], 0xf00000000 bytes on node 0 flags: 0x0
[    0.000000]  memory[0x3]     [0x00010000400000-0x00010ff9e8ffff], 0xff9a90000 bytes on node 1 flags: 0x0
[    0.000000]  memory[0x4]     [0x00010ff9e90000-0x00010ff9f2ffff], 0xa0000 bytes on node 1 flags: 0x4
[    0.000000]  memory[0x5]     [0x00010ff9f30000-0x00010ffaeaffff], 0xf80000 bytes on node 1 flags: 0x0
[    0.000000]  memory[0x6]     [0x00010ffaeb0000-0x00010ffaffffff], 0x150000 bytes on node 1 flags: 0x4
[    0.000000]  memory[0x7]     [0x00010ffb000000-0x00010ffffaffff], 0x4fb0000 bytes on node 1 flags: 0x0
[    0.000000]  memory[0x8]     [0x00010ffffb0000-0x00010fffffffff], 0x50000 bytes on node 1 flags: 0x4
[    0.000000]  reserved.cnt  = 0xd
[    0.000000]  reserved[0x0]   [0x00000001480000-0x0000000248ffff], 0x1010000 bytes flags: 0x0
[    0.000000]  reserved[0x1]   [0x00000021200000-0x00000021210536], 0x10537 bytes flags: 0x0
[    0.000000]  reserved[0x2]   [0x000000c0000000-0x000000dfffffff], 0x20000000 bytes flags: 0x0
[    0.000000]  reserved[0x3]   [0x00000ffbfb8000-0x00000ffffdffff], 0x4028000 bytes flags: 0x0
[    0.000000]  reserved[0x4]   [0x00000ffffecb00-0x00000fffffffff], 0x13500 bytes flags: 0x0
[    0.000000]  reserved[0x5]   [0x00010f856a0000-0x00010f92a6ffff], 0xd3d0000 bytes flags: 0x0
[    0.000000]  reserved[0x6]   [0x00010ff7880000-0x00010ff788ffff], 0x10000 bytes flags: 0x0
[    0.000000]  reserved[0x7]   [0x00010ffbce0000-0x00010fffceffff], 0x4010000 bytes flags: 0x0
[    0.000000]  reserved[0x8]   [0x00010fffee6d80-0x00010ffff2fffb], 0x4927c bytes flags: 0x0
[    0.000000]  reserved[0x9]   [0x00010ffff30000-0x00010ffffa000f], 0x70010 bytes flags: 0x0
[    0.000000]  reserved[0xa]   [0x00010ffffae280-0x00010ffffaff7f], 0x1d00 bytes flags: 0x0
[    0.000000]  reserved[0xb]   [0x00010ffffaffa0-0x00010ffffaffce], 0x2f bytes flags: 0x0
[    0.000000]  reserved[0xc]   [0x00010ffffaffd0-0x00010ffffafffe], 0x2f bytes flags: 0x0

^ permalink raw reply

* [PATCH] ARM: dts: lpc32xx: set pwm1 & pwm2 default clock rate
From: Sylvain Lemieux @ 2016-10-05 14:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1443ec62-4936-c70a-b323-6980a9240a1e@mleia.com>

Hi Vladimir,

On Wed, 2016-10-05 at 05:08 +0300, Vladimir Zapolskiy wrote:
> Hi Sylvain,
> 
> On 26.09.2016 21:54, Sylvain Lemieux wrote:
> > From: Sylvain Lemieux <slemieux@tycoint.com>
> > 
> > Probably most of NXP LPC32xx boards have 13MHz main oscillator
> > and therefore for HCLK PLL and ARM core clock rate default
> > hardware setting of 16 * 13MHz = 208MHz and the AHB bus clock
> > rate of 208MHz / 2 = 104MHz.
> > 
> > The change explicitly defines the peripheral PWM1/PWM2 default
> > clock output rate of 104MHz. If needed it can be redefined
> > in a board DTS file.
> > 
> > Signed-off-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
> > ---
> > Note:
> > * There is a dependency on the following patch:
> >   "ARM: dts: lpc32xx: set default parent clock for pwm1 & pwm2"
> >   http://www.spinics.net/lists/arm-kernel/msg530277.html
> > * This patch should be apply after
> >   "ARM: dts: lpc32xx: add pwm-cells to base dts file"
> >   http://www.spinics.net/lists/arm-kernel/msg534050.html
> >   - There is no dependency between the patches.
> > 
> >  arch/arm/boot/dts/lpc32xx.dtsi | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
> > index c031c94..d669200 100644
> > --- a/arch/arm/boot/dts/lpc32xx.dtsi
> > +++ b/arch/arm/boot/dts/lpc32xx.dtsi
> > @@ -471,6 +471,7 @@
> >  				clocks = <&clk LPC32XX_CLK_PWM1>;
> >  				assigned-clocks = <&clk LPC32XX_CLK_PWM1>;
> >  				assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
> > +				assigned-clock-rates = <104000000>;
> 
> PWM controller clock source can be 32KHz or CLK_PERIPH, the latter is
> equal either to SYSCLK or HCLK PLL divided by HCLKDIV_CTRL[6:2].
> 
> Do you set the divider to 1? If yes, then I would say
> 
> 1) this is very specific to your board, generally CLK_PERIPH
>    is set to be about 10-13MHz,
> 2) HCLKDIV or PERIPH clock configuration shall not be done in pwm device node.
> 
> 104MHz is too high value to be set by default for PWM clock.
> 
This is a good catch; it was an error on my side.
The purpose of the patch was to setup the output of the
PWM clock to the default CLK_PERIPH value (13325000).

This change does not modify the HCLKDIV or the PERIPH clock.

I can submit a version 2 with the proper value and update
the patch description to list the default peripheral clock
setup of 13MHz.

This change is adding a default value for the PWM clock
(setup to CLK_PERIPH) to the PWM device node, allowing the
board specific DTS to only enable the PWM to get it work.

If the PWM clock output is not setup with a default value,
only enabling the PWM in the board specific DTS file is not
enough; the PWM divider will keep the default value of zero
(i.e. PWM clock off).

> --
> With best wishes,
> Vladimir

Sylvain

^ permalink raw reply

* [PATCH 02/11] DOCUMENTATION: dt-bindings: Document the STM32 USART bindings
From: Gerald Baeza @ 2016-10-05 14:09 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160923152907.GA19206@rob-hp-laptop>

On 09/23/2016 05:29 PM, Rob Herring wrote:
> On Thu, Sep 15, 2016 at 06:42:34PM +0200, Alexandre TORGUE wrote:
>> This adds documentation of device tree bindings for the
>> STM32 USART
>
> Please make your subject prefixes consistent and drop "DOCUMENTATION".
>

Ok, thanks

>>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>>
>> diff --git a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
>> new file mode 100644
>> index 0000000..75b1400
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
>> @@ -0,0 +1,34 @@
>> +* STMicroelectronics STM32 USART
>> +
>> +Required properties:
>> +- compatible: Can be either "st,stm32-usart", "st,stm32-uart",
>> +"st,stm32f7-usart" or "st,stm32f7-uart" depending on whether
>> +the device supports synchronous mode and is compatible with
>> +stm32(f4) or stm32f7.
>
> Why not put f4 in the compatible string. stm32 is too generic.

The initial binding is not in current kernel so it has been put in this 
serie as PATCH 07/11. It will be squashed with this one, as you requested.

But the driver tty/serial/stm32-usart.c was already upstreamed and it 
already mentions the "st,stm32-usart" and "st,stm32-uart" for stm32f4 so 
I kept this as it for backward compatibility for those who already use 
the driver.

I do not have the history to explain this inconsistency but can you 
confirm that keeping the existing compatible values from the driver is 
the good approach please?

> What determines sync mode or not? If it is IP configuration fixed in the
> design, then this is fine. If it is user choice or board dependent, then
> use a separate property.

This is IP configuration fixed in the design, indeed.

>> +- reg: The address and length of the peripheral registers space
>> +- interrupts: The interrupt line of the USART instance
>> +- clocks: The input clock of the USART instance
>> +
>> +Optional properties:
>> +- pinctrl: The reference on the pins configuration
>> +- st,hw-flow-ctrl: bool flag to enable hardware flow control.
>> +
>> +Examples:
>> +usart4: serial at 40004c00 {
>> +	compatible = "st,stm32-uart";
>> +	reg = <0x40004c00 0x400>;
>> +	interrupts = <52>;
>> +	clocks = <&clk_pclk1>;
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_usart4>;
>> +};
>> +
>> +usart2: serial at 40004400 {
>> +	compatible = "st,stm32-usart", "st,stm32-uart";
>
> What are valid combinations? usart is sync only, not sync and async?

usart (sync and async) is a superset of uart (async).
But the current driver does not use the synchronous mode, so the 
distinction is just here to be consistent with the reference manual 
instances naming (so configuration).

>> +	reg = <0x40004400 0x400>;
>> +	interrupts = <38>;
>> +	clocks = <&clk_pclk1>;
>> +	st,hw-flow-ctrl;
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_usart2 &pinctrl_usart2_rtscts>;
>> +};
>> --
>> 1.9.1
>>

^ permalink raw reply

* kernel-doc-rst-lint (was: Re: [PATCH 00/15] improve function-level documentation)
From: Jani Nikula @ 2016-10-05 14:04 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAKMK7uHT3FutHQuQQ3iwXmYbidB3AOs7AxnpaJD4MTqy0-QehQ@mail.gmail.com>

On Wed, 05 Oct 2016, Daniel Vetter <daniel@ffwll.ch> wrote:
> Jani Nikula has a patch with a scrip to make the one kernel-doc parser
> into a lint/checker pass over the entire kernel. I think that'd would
> be more robust instead of trying to approximate the real kerneldoc
> parser. Otoh that parser is a horror show of a perl/regex driven state
> machine ;-)
>
> Jani, can you pls digg out these patches? Can't find them right now ...

Expanding the massive Cc: with linux-doc list...

Here goes. It's a quick hack from months ago, but still seems to
somewhat work. At least for the kernel-doc parts. The reStructuredText
lint part isn't all that great, and doesn't have mapping to line numbers
like the Sphinx kernel-doc extension does. Anyway I'm happy how this
integrates with kernel build CHECK and C=1/C=2.

I guess Julia's goal is to automate the *fixing* of some of the error
classes from kernel-doc. Not sure how well this could be made to
integrate with any of that.

BR,
Jani.


>From 1244efa0f63a7b13795e8c37f81733a3c8bfc56a Mon Sep 17 00:00:00 2001
From: Jani Nikula <jani.nikula@intel.com>
Date: Tue, 31 May 2016 18:11:33 +0300
Subject: [PATCH] kernel-doc-rst-lint: add tool to check kernel-doc and rst
 correctness
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Cc: Jani Nikula <jani.nikula@intel.com>

Simple kernel-doc and reStructuredText lint tool that can be used
independently and as a kernel build CHECK tool to validate kernel-doc
comments.

Independent usage:
$ kernel-doc-rst-lint FILE

Kernel CHECK usage:
$ make CHECK=scripts/kernel-doc-rst-lint C=1		# (or C=2)

Depends on docutils and the rst-lint package
https://pypi.python.org/pypi/restructuredtext_lint

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 scripts/kernel-doc-rst-lint | 106 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 106 insertions(+)
 create mode 100755 scripts/kernel-doc-rst-lint

diff --git a/scripts/kernel-doc-rst-lint b/scripts/kernel-doc-rst-lint
new file mode 100755
index 000000000000..7e0157679f83
--- /dev/null
+++ b/scripts/kernel-doc-rst-lint
@@ -0,0 +1,106 @@
+#!/usr/bin/env python
+# coding=utf-8
+#
+# Copyright ? 2016 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+# IN THE SOFTWARE.
+#
+# Authors:
+#    Jani Nikula <jani.nikula@intel.com>
+#
+# Simple kernel-doc and reStructuredText lint tool that can be used
+# independently and as a kernel build CHECK tool to validate kernel-doc
+# comments.
+#
+# Independent usage:
+# $ kernel-doc-rst-lint FILE
+#
+# Kernel CHECK usage:
+# $ make CHECK=scripts/kernel-doc-rst-lint C=1		# (or C=2)
+#
+# Depends on docutils and the rst-lint package
+# https://pypi.python.org/pypi/restructuredtext_lint
+#
+
+import os
+import subprocess
+import sys
+
+from docutils.parsers.rst import directives
+from docutils.parsers.rst import Directive
+from docutils.parsers.rst import roles
+from docutils import nodes, statemachine
+import restructuredtext_lint
+
+class DummyDirective(Directive):
+    required_argument = 1
+    optional_arguments = 0
+    option_spec = { }
+    has_content = True
+
+    def run(self):
+        return []
+
+# Fake the Sphinx C Domain directives and roles
+directives.register_directive('c:function', DummyDirective)
+directives.register_directive('c:type', DummyDirective)
+roles.register_generic_role('c:func', nodes.emphasis)
+roles.register_generic_role('c:type', nodes.emphasis)
+
+# We accept but ignore parameters to be compatible with how the kernel build
+# invokes CHECK.
+if len(sys.argv) < 2:
+    sys.stderr.write('usage: kernel-doc-rst-lint [IGNORED OPTIONS] FILE\n');
+    sys.exit(1)
+
+infile = sys.argv[len(sys.argv) - 1]
+cmd = ['scripts/kernel-doc', '-rst', infile]
+
+try:
+    p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, universal_newlines=True)
+    out, err = p.communicate()
+
+    # python2 needs conversion to unicode.
+    # python3 with universal_newlines=True returns strings.
+    if sys.version_info.major < 3:
+        out, err = unicode(out, 'utf-8'), unicode(err, 'utf-8')
+
+    # kernel-doc errors
+    sys.stderr.write(err)
+    if p.returncode != 0:
+        sys.exit(p.returncode)
+
+    # restructured text errors
+    lines = statemachine.string2lines(out, 8, convert_whitespace=True)
+    lint_errors = restructuredtext_lint.lint(out, infile)
+    for error in lint_errors:
+        # Ignore INFO
+        if error.level <= 1:
+            continue
+
+        print(error.source + ': ' + error.type + ': ' + error.full_message)
+        if error.line is not None:
+            print('Context:')
+            print('\t' + lines[error.line - 1])
+            print('\t' + lines[error.line])
+
+except Exception as e:
+    sys.stderr.write(str(e) + '\n')
+    sys.exit(1)
-- 
2.1.4


-- 
Jani Nikula, Intel Open Source Technology Center

^ permalink raw reply related

* [PATCH] ARM64: dts: meson-gx: Add missing L2 cache node
From: Neil Armstrong @ 2016-10-05 13:53 UTC (permalink / raw)
  To: linux-arm-kernel

In order to remove the boot warning :
[    2.290933] Unable to detect cache hierarchy from DT for CPU 0
And add missing L2 cache hierarchy information, add a simple l2 cache node
and reference it from the A53 cpu nodes.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 0737056..a6cd953 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -64,6 +64,7 @@
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0x0 0x0>;
 			enable-method = "psci";
+			next-level-cache = <&l2>;
 		};
 
 		cpu1: cpu at 1 {
@@ -71,6 +72,7 @@
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0x0 0x1>;
 			enable-method = "psci";
+			next-level-cache = <&l2>;
 		};
 
 		cpu2: cpu at 2 {
@@ -78,6 +80,7 @@
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0x0 0x2>;
 			enable-method = "psci";
+			next-level-cache = <&l2>;
 		};
 
 		cpu3: cpu at 3 {
@@ -85,6 +88,11 @@
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0x0 0x3>;
 			enable-method = "psci";
+			next-level-cache = <&l2>;
+		};
+
+		l2: l2-cache0 {
+			compatible = "cache";
 		};
 	};
 
-- 
1.9.1

^ permalink raw reply related

* [PATCH] ARM: shmobile: Consolidate R8A779[234] machine definitions
From: Laurent Pinchart @ 2016-10-05 13:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475663489-4789-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

On Wednesday 05 Oct 2016 13:31:29 Laurent Pinchart wrote:
> The three SoCs use the exact same machine definition, consolidate them
> into a single one.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
>  arch/arm/mach-shmobile/Makefile          |  3 ---
>  arch/arm/mach-shmobile/setup-r8a7792.c   | 35
> -------------------------------- arch/arm/mach-shmobile/setup-r8a7793.c   |
> 33 ------------------------------ arch/arm/mach-shmobile/setup-r8a7794.c  
> | 33 ------------------------------
> arch/arm/mach-shmobile/setup-rcar-gen2.c | 20 ++++++++++++++++++
>  5 files changed, 20 insertions(+), 104 deletions(-)
>  delete mode 100644 arch/arm/mach-shmobile/setup-r8a7792.c
>  delete mode 100644 arch/arm/mach-shmobile/setup-r8a7793.c
>  delete mode 100644 arch/arm/mach-shmobile/setup-r8a7794.c
> 
> I don't have access to any R8A779[234] board, I'd appreciate if someone
> could test the patch series.
> 
> diff --git a/arch/arm/mach-shmobile/Makefile
> b/arch/arm/mach-shmobile/Makefile index 3fc48b02eb4f..64611a1b4276 100644
> --- a/arch/arm/mach-shmobile/Makefile
> +++ b/arch/arm/mach-shmobile/Makefile
> @@ -13,9 +13,6 @@ obj-$(CONFIG_ARCH_R8A7778)	+= setup-r8a7778.o
>  obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o pm-r8a7779.o
>  obj-$(CONFIG_ARCH_R8A7790)	+= setup-r8a7790.o
>  obj-$(CONFIG_ARCH_R8A7791)	+= setup-r8a7791.o
> -obj-$(CONFIG_ARCH_R8A7792)	+= setup-r8a7792.o
> -obj-$(CONFIG_ARCH_R8A7793)	+= setup-r8a7793.o
> -obj-$(CONFIG_ARCH_R8A7794)	+= setup-r8a7794.o
>  obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o
>  obj-$(CONFIG_ARCH_R7S72100)	+= setup-r7s72100.o
> 
> diff --git a/arch/arm/mach-shmobile/setup-r8a7792.c
> b/arch/arm/mach-shmobile/setup-r8a7792.c deleted file mode 100644
> index a0910395da09..000000000000
> --- a/arch/arm/mach-shmobile/setup-r8a7792.c
> +++ /dev/null
> @@ -1,35 +0,0 @@
> -/*
> - * r8a7792 processor support
> - *
> - * Copyright (C) 2014 Renesas Electronics Corporation
> - * Copyright (C) 2016 Cogent  Embedded, Inc.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; version 2 of the License.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - */
> -
> -#include <linux/of_platform.h>
> -
> -#include <asm/mach/arch.h>
> -
> -#include "common.h"
> -#include "rcar-gen2.h"
> -
> -static const char * const r8a7792_boards_compat_dt[] __initconst = {
> -	"renesas,r8a7792",
> -	NULL,
> -};
> -
> -DT_MACHINE_START(R8A7792_DT, "Generic R8A7792 (Flattened Device Tree)")
> -	.init_early	= shmobile_init_delay,
> -	.init_late	= shmobile_init_late,
> -	.init_time	= rcar_gen2_timer_init,
> -	.reserve	= rcar_gen2_reserve,
> -	.dt_compat	= r8a7792_boards_compat_dt,
> -MACHINE_END
> diff --git a/arch/arm/mach-shmobile/setup-r8a7793.c
> b/arch/arm/mach-shmobile/setup-r8a7793.c deleted file mode 100644
> index 5fce87f7f254..000000000000
> --- a/arch/arm/mach-shmobile/setup-r8a7793.c
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -/*
> - * r8a7793 processor support
> - *
> - * Copyright (C) 2015  Ulrich Hecht
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; version 2 of the License.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - */
> -
> -#include <linux/init.h>
> -#include <asm/mach/arch.h>
> -
> -#include "common.h"
> -#include "rcar-gen2.h"
> -
> -static const char * const r8a7793_boards_compat_dt[] __initconst = {
> -	"renesas,r8a7793",
> -	NULL,
> -};
> -
> -DT_MACHINE_START(R8A7793_DT, "Generic R8A7793 (Flattened Device Tree)")
> -	.init_early	= shmobile_init_delay,
> -	.init_time	= rcar_gen2_timer_init,
> -	.init_late	= shmobile_init_late,
> -	.reserve	= rcar_gen2_reserve,
> -	.dt_compat	= r8a7793_boards_compat_dt,
> -MACHINE_END
> diff --git a/arch/arm/mach-shmobile/setup-r8a7794.c
> b/arch/arm/mach-shmobile/setup-r8a7794.c deleted file mode 100644
> index d2b093033132..000000000000
> --- a/arch/arm/mach-shmobile/setup-r8a7794.c
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -/*
> - * r8a7794 processor support
> - *
> - * Copyright (C) 2014  Renesas Electronics Corporation
> - * Copyright (C) 2014  Ulrich Hecht
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; version 2 of the License.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - */
> -
> -#include <linux/of_platform.h>
> -#include "common.h"
> -#include "rcar-gen2.h"
> -#include <asm/mach/arch.h>
> -
> -static const char * const r8a7794_boards_compat_dt[] __initconst = {
> -	"renesas,r8a7794",
> -	NULL,
> -};
> -
> -DT_MACHINE_START(R8A7794_DT, "Generic R8A7794 (Flattened Device Tree)")
> -	.init_early	= shmobile_init_delay,
> -	.init_late	= shmobile_init_late,
> -	.init_time	= rcar_gen2_timer_init,
> -	.reserve	= rcar_gen2_reserve,
> -	.dt_compat	= r8a7794_boards_compat_dt,
> -MACHINE_END
> diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c
> b/arch/arm/mach-shmobile/setup-rcar-gen2.c index afb9fdcd3d90..4d5052564f21
> 100644
> --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
> +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
> @@ -24,6 +24,7 @@
>  #include <linux/memblock.h>
>  #include <linux/of.h>
>  #include <linux/of_fdt.h>
> +#include <linux/of_platform.h>
>  #include <asm/mach/arch.h>
>  #include "common.h"
>  #include "rcar-gen2.h"
> @@ -203,3 +204,22 @@ void __init rcar_gen2_reserve(void)
>  	}
>  #endif
>  }
> +
> +static const char * const rcar_gen2_boards_compat_dt[] __initconst = {
> +	/*
> +	 * R8A7790 and R8A7791 can't be handled here as long as they need SMP
> +	 * initialization fallback.
> +	 */
> +	"renesas,r8a7792",
> +	"renesas,r8a7793",
> +	"renesas,r8a7794",
> +	NULL,
> +};
> +
> +DT_MACHINE_START(RCAR_GEN2_DT, "Generic Gen2 (Flattened Device Tree)")

This should of course read "Generic R-Car Gen2 (Flattened Device Tree)". I'll 
fix it in the next version, after getting initial review.

> +	.init_early	= shmobile_init_delay,
> +	.init_late	= shmobile_init_late,
> +	.init_time	= rcar_gen2_timer_init,
> +	.reserve	= rcar_gen2_reserve,
> +	.dt_compat	= rcar_gen2_boards_compat_dt,
> +MACHINE_END

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* [PATCH V2 3/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"
From: Thomas Gleixner @ 2016-10-05 13:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475615720-31047-4-git-send-email-okaya@codeaurora.org>

On Tue, 4 Oct 2016, Sinan Kaya wrote:

> The SCI function was removed in two steps (first refactor and then remove).
> This patch does the revert in one step.
> 
> The commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> refactored the original code so that SCI penalty is calculated dynamically
> by the time get_penalty function is called. This patch does a partial
> revert for the SCI functionality only.
> 
> The commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize function") is
> for the removal of the function. SCI penalty API was replaced by the
> runtime penalty calculation based on the value of
> acpi_gbl_FADT.sci_interrupt.
> 
> The IRQ type does not get updated at the right time for some platforms and
> results in incorrect penalty assignment for PCI IRQs as
> irq_get_trigger_type returns the wrong type.
> 
> The register_gsi function delivers the IRQ found in the ACPI table to
> the interrupt controller driver.  Penalties are calculated before a
> link object is enabled to find out which interrupt has the least number
> of users. By the time penalties are calculated, the IRQ is not registered
> yet and the API returns the wrong type.
> 
> Tested-by: Jonathan Liu <net147@gmail.com>
> Tested-by: Ondrej Zary <linux@rainbow-software.org>
> Link: https://lkml.org/lkml/2016/10/4/283
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>

Acked-by: Thomas Gleixner <tglx@linutronix.de>

^ permalink raw reply

* [PATCH 00/15] improve function-level documentation
From: Daniel Vetter @ 2016-10-05 13:15 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475351192-27079-1-git-send-email-Julia.Lawall@lip6.fr>

Jani Nikula has a patch with a scrip to make the one kernel-doc parser
into a lint/checker pass over the entire kernel. I think that'd would
be more robust instead of trying to approximate the real kerneldoc
parser. Otoh that parser is a horror show of a perl/regex driven state
machine ;-)

Jani, can you pls digg out these patches? Can't find them right now ...
-Daniel


On Sat, Oct 1, 2016 at 9:46 PM, Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> These patches fix cases where the documentation above a function definition
> is not consistent with the function header.  Issues are detected using the
> semantic patch below (http://coccinelle.lip6.fr/).  Basically, the semantic
> patch parses a file to find comments, then matches each function header,
> and checks that the name and parameter list in the function header are
> compatible with the comment that preceeds it most closely.
>
> // <smpl>
> @initialize:ocaml@
> @@
>
> let tbl = ref []
> let fnstart = ref []
> let success = Hashtbl.create 101
> let thefile = ref ""
> let parsed = ref []
> let nea = ref []
>
> let parse file =
>   thefile := List.nth (Str.split (Str.regexp "linux-next/") file) 1;
>   let i = open_in file in
>   let startline = ref 0 in
>   let fn = ref "" in
>   let ids = ref [] in
>   let rec inside n =
>     let l = input_line i in
>     let n = n + 1 in
>     match Str.split_delim (Str.regexp_string "*/") l with
>       before::after::_ ->
>         (if not (!fn = "")
>         then tbl := (!startline,n,!fn,List.rev !ids)::!tbl);
>         startline := 0;
>         fn := "";
>         ids := [];
>         outside n
>     | _ ->
>         (match Str.split (Str.regexp "[ \t]+") l with
>           "*"::name::rest ->
>             let len = String.length name in
>             (if !fn = "" && len > 2 && String.sub name (len-2) 2 = "()"
>             then fn := String.sub name 0 (len-2)
>             else if !fn = "" && (not (rest = [])) && List.hd rest = "-"
>             then
>               if String.get name (len-1) = ':'
>               then fn := String.sub name 0 (len-1)
>               else fn := name
>             else if not(!fn = "") && len > 2 &&
>               String.get name 0 = '@' && String.get name (len-1) = ':'
>             then ids := (String.sub name 1 (len-2)) :: !ids);
>         | _ -> ());
>         inside n
>   and outside n =
>     let l = input_line i in
>     let n = n + 1 in
>     if String.length l > 2 && String.sub l 0 3 = "/**"
>     then
>       begin
>         startline := n;
>         inside n
>       end
>     else outside n in
>   try outside 0 with End_of_file -> ()
>
> let hashadd tbl k v =
>   let cell =
>     try Hashtbl.find tbl k
>     with Not_found ->
>       let cell = ref [] in
>       Hashtbl.add tbl k cell;
>       cell in
>   cell := v :: !cell
>
> @script:ocaml@
> @@
>
> tbl := [];
> fnstart := [];
> Hashtbl.clear success;
> parsed := [];
> nea := [];
> parse (List.hd (Coccilib.files()))
>
> @r@
> identifier f;
> position p;
> @@
>
> f at p(...) { ... }
>
> @script:ocaml@
> p << r.p;
> f << r.f;
> @@
>
> parsed := f :: !parsed;
> fnstart := (List.hd p).line :: !fnstart
>
> @param@
> identifier f;
> type T;
> identifier i;
> parameter list[n] ps;
> parameter list[n1] ps1;
> position p;
> @@
>
> f at p(ps,T i,ps1) { ... }
>
> @script:ocaml@
> @@
>
> tbl := List.rev (List.sort compare !tbl)
>
> @script:ocaml@
> p << param.p;
> f << param.f;
> @@
>
> let myline = (List.hd p).line in
> let prevline =
>   List.fold_left
>     (fun prev x ->
>       if x < myline
>       then max x prev
>       else prev)
>     0 !fnstart in
> let _ =
>   List.exists
>     (function (st,fn,nm,ids) ->
>       if prevline < st && myline > st && prevline < fn && myline > fn
>       then
>         begin
>           (if not (String.lowercase f = String.lowercase nm)
>           then
>             Printf.printf "%s:%d %s doesn't match preceding comment: %s\n"
>               !thefile myline f nm);
>           true
>         end
>       else false)
>     !tbl in
> ()
>
> @script:ocaml@
> p << param.p;
> n << param.n;
> n1 << param.n1;
> i << param.i;
> f << param.f;
> @@
>
> let myline = (List.hd p).line in
> let prevline =
>   List.fold_left
>     (fun prev x ->
>       if x < myline
>       then max x prev
>       else prev)
>     0 !fnstart in
> let _ =
>   List.exists
>     (function (st,fn,nm,ids) ->
>       if prevline < st && myline > st && prevline < fn && myline > fn
>       then
>         begin
>           (if List.mem i ids then hashadd success (st,fn,nm) i);
>           (if ids = [] (* arg list seems not obligatory *)
>           then ()
>           else if not (List.mem i ids)
>           then
>             Printf.printf "%s:%d %s doesn't appear in ids: %s\n"
>               !thefile myline i (String.concat " " ids)
>           else if List.length ids <= n || List.length ids <= n1
>           then
>             (if not (List.mem f !nea)
>             then
>               begin
>                 nea := f :: !nea;
>                 Printf.printf "%s:%d %s not enough args\n" !thefile myline f;
>               end)
>           else
>             let foundid = List.nth ids n in
>             let efoundid = List.nth (List.rev ids) n1 in
>             if not(foundid = i || efoundid = i)
>             then
>               Printf.printf "%s:%d %s wrong arg in position %d: %s\n"
>                 !thefile myline i n foundid);
>           true
>         end
>       else false)
>     !tbl in
> ()
>
> @script:ocaml@
> @@
> List.iter
>   (function (st,fn,nm,ids) ->
>     if List.mem nm !parsed
>     then
>       let entry =
>         try !(Hashtbl.find success (st,fn,nm))
>         with Not_found -> [] in
>       List.iter
>         (fun id ->
>           if not (List.mem id entry) && not (id = "...")
>           then Printf.printf "%s:%d %s not used\n" !thefile st id)
>         ids)
>   !tbl
> // </smpl>
>
>
> ---
>
>  drivers/clk/keystone/pll.c               |    4 ++--
>  drivers/clk/sunxi/clk-mod0.c             |    2 +-
>  drivers/clk/tegra/cvb.c                  |   10 +++++-----
>  drivers/dma-buf/sw_sync.c                |    6 +++---
>  drivers/gpu/drm/gma500/intel_i2c.c       |    3 +--
>  drivers/gpu/drm/omapdrm/omap_drv.c       |    4 ++--
>  drivers/irqchip/irq-metag-ext.c          |    1 -
>  drivers/irqchip/irq-vic.c                |    1 -
>  drivers/mfd/tc3589x.c                    |    4 ++--
>  drivers/power/supply/ab8500_fg.c         |    8 ++++----
>  drivers/power/supply/abx500_chargalg.c   |    1 +
>  drivers/power/supply/intel_mid_battery.c |    2 +-
>  drivers/power/supply/power_supply_core.c |    4 ++--
>  fs/crypto/crypto.c                       |    4 ++--
>  fs/crypto/fname.c                        |    4 ++--
>  fs/ubifs/file.c                          |    2 +-
>  fs/ubifs/gc.c                            |    2 +-
>  fs/ubifs/lprops.c                        |    2 +-
>  fs/ubifs/lpt_commit.c                    |    4 +---
>  fs/ubifs/replay.c                        |    2 +-
>  lib/kobject_uevent.c                     |    6 +++---
>  lib/lru_cache.c                          |    4 ++--
>  lib/nlattr.c                             |    2 +-
>  23 files changed, 39 insertions(+), 43 deletions(-)
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply

* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Bartosz Golaszewski @ 2016-10-05 13:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475672732-17111-1-git-send-email-bgolaszewski@baylibre.com>

From: Karl Beldan <kbeldan@baylibre.com>

Add pins used by the LCD controller and a disabled LCDC node to be
reused in device trees including da850.dtsi.

Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
[Bartosz:
  - added the commit description
  - changed the dt node name to a generic one
  - added a da850-specific compatible string
  - removed the tilcdc,panel node
  - moved the pins definitions to da850.dtsi as suggested by
    Sekhar Nori (was in: da850-lcdk.dts)]
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 arch/arm/boot/dts/da850.dtsi | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b9..32908ae 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -186,6 +186,27 @@
 					0xc 0x88888888 0xffffffff
 				>;
 			};
+			lcd_pins: pinmux_lcd_pins {
+				pinctrl-single,bits = <
+					/*
+					 * LCD_D[2], LCD_D[3], LCD_D[4], LCD_D[5],
+					 * LCD_D[6], LCD_D[7]
+					 */
+					0x40 0x22222200 0xffffff00
+					/*
+					 * LCD_D[10], LCD_D[11], LCD_D[12], LCD_D[13],
+					 * LCD_D[14], LCD_D[15], LCD_D[0], LCD_D[1]
+					 */
+					0x44 0x22222222 0xffffffff
+					/* LCD_D[8], LCD_D[9] */
+					0x48 0x00000022 0x000000ff
+
+					/* LCD_PCLK */
+					0x48 0x02000000 0x0f000000
+					/* LCD_AC_ENB_CS, LCD_VSYNC, LCD_HSYNC */
+					0x4c 0x02000022 0x0f0000ff
+				>;
+			};
 
 		};
 		edma0: edma at 0 {
@@ -399,6 +420,14 @@
 				<&edma0 0 1>;
 			dma-names = "tx", "rx";
 		};
+
+		display: display at 213000 {
+			compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
+			reg = <0x213000 0x1000>;
+			interrupt-parent = <&intc>;
+			interrupts = <52>;
+			status = "disabled";
+		};
 	};
 	aemif: aemif at 68000000 {
 		compatible = "ti,da850-aemif";
-- 
2.9.3

^ permalink raw reply related

* [PATCH 1/2] ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for lcdc
From: Bartosz Golaszewski @ 2016-10-05 13:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475672732-17111-1-git-send-email-bgolaszewski@baylibre.com>

From: Karl Beldan <kbeldan@baylibre.com>

This is required for tilcdc to be able to acquire a functional clock
on da850 SoCs.

Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
[Bartosz:
  - added the commit description
  - changed the compatible string to 'ti,da850-tilcdc']
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 arch/arm/mach-davinci/da8xx-dt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index c9f7e92..697da3d 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -38,6 +38,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
 		       NULL),
 	OF_DEV_AUXDATA("ti,da830-mcasp-audio", 0x01d00000, "davinci-mcasp.0", NULL),
 	OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", NULL),
+	OF_DEV_AUXDATA("ti,da850-tilcdc", 0x01e13000, "da8xx_lcdc.0", NULL),
 	{}
 };
 
-- 
2.9.3

^ permalink raw reply related

* [PATCH 0/2] ARM: davinci: initial infrastructure for LCDC
From: Bartosz Golaszewski @ 2016-10-05 13:05 UTC (permalink / raw)
  To: linux-arm-kernel

After discussing the matter with Laurent Pinchart it turned out that
using ti,tilcdc,panel was wrong and we should go with the new
simple-vga-dac driver proposed by Maxime Ripard and currently being
reviewed.

The da850-lcdk board on which I'm working has a THS8135 video DAC for
which the new driver seems to be best suited and we'll be able to
query the connected display for supported modes instead of hardcoding
them in the dt as is needed for the panel driver.

In the meantime I'm posting two patches based on Karl Beldan's
previous work that can already be merged.

The first one adds OF_DEV_AUXDATA entry to da8xx-dt.c. I changed the
compatible string to the new one we're introducing in the tilcdc
driver.

The second adds the lcd pins and the display node to da850.dtsi. As
suggested by Sekhar: I moved the pins node, which was previously in
da850-lcdk.dts, to da850.dtsi. I also squashed Karl's two patches and
removed the panel node.

Tested on a da850-lcdk with an LCD display connected over VGA with
two patches already posted to the drm mailing list:

  drm: tilcdc: add a da850-specific compatible string
  drm: tilcdc: add a workaround for failed clk_set_rate()

and some additional work-in-progress/hacks on top of that.

Karl Beldan (2):
  ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for lcdc
  ARM: dts: da850: add a node for the LCD controller

 arch/arm/boot/dts/da850.dtsi     | 29 +++++++++++++++++++++++++++++
 arch/arm/mach-davinci/da8xx-dt.c |  1 +
 2 files changed, 30 insertions(+)

-- 
2.9.3

^ permalink raw reply

* [PATCH v5] devicetree: bindings: uart: Add new compatible string for ZynqMP
From: Rob Herring @ 2016-10-05 12:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <C89496FEAE474D468F30D558A9468D9F26D2AB89@XAP-PVEXMBX01.xlnx.xilinx.com>

On Wed, Oct 5, 2016 at 7:23 AM, Nava kishore Manne
<nava.manne@xilinx.com> wrote:
> Hi Rob,
>
>         Thanks for the review...
>
>> > Changes for v5:
>> >             -Fixed some minor comments.
>>
>> Not a useful changelog. The point of these comments is to remind the
>> reviewers of what they commented on.
>
> Ok will take care from next version onwards...
>
>> >  Required properties:
>> > -- compatible : should be "cdns,uart-r1p8", or "xlnx,xuartps"
>> > +- compatible :
>> > +  Use "cdns,uart-r1p8", or "xlnx,xuartps" for Zynq-7xxx SoC.
>>
>> This is still not right. It was wrong before, but you are touching it so make it
>> right.
>>
>> OR doesn't match the dts files. It is AND and the opposite order.
>>
>> xlnx,xuartps wasn't the best naming, but it's in use so we'll have to live with it
>> for zynq-7xxx.
>>
>> > +  Use "cdns,uart-r1p12" for Zynq Ultrascale+ MPSoC.
>>
>> What I meant here was this should have something like "xlnx,mpsoc-uart"
>> as the first compatible with "cdns,uart-r1p12" as the second. Not sure if
>> "mpsoc" is the best name here.
>
> You mean something like below
>  Use "xlnx,xuartps" or "cdns,uart-r1p8" for Zynq-7xxx SoC.

As I said, it is not an OR condition. 'Use "xlnx,xuartps",
"cdns,uart-r1p8" for Zynq-7xxx SoC

> Use "xlnx,zynqmp-uart" or " cdns,uart-r1p12" for Zynq Ultrascale+ MPSoC.

Yes, but as above.

Rob

^ permalink raw reply

* [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
From: Horng-Shyang Liao @ 2016-10-05 12:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAJe_ZhcXw1-MOEiiix5VTtKEVr9Z23s_OyikboDYCd0RQwS5pg@mail.gmail.com>

On Wed, 2016-10-05 at 09:07 +0530, Jassi Brar wrote:
> On 5 October 2016 at 08:24, Horng-Shyang Liao <hs.liao@mediatek.com> wrote:
> > On Fri, 2016-09-30 at 17:47 +0800, Horng-Shyang Liao wrote:
> >> On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:
> 
> >
> > After I trace mailbox driver, I realize that CMDQ driver cannot use
> > tx_done.
> >
> > CMDQ clients will flush many tasks into CMDQ driver, and then CMDQ
> > driver will apply these tasks into GCE HW "immediately". These tasks,
> > which are queued in GCE HW, may not execute immediately since they
> > may need to wait event(s), e.g. vsync.
> >
> > However, in mailbox driver, mailbox uses a software buffer to queue
> > sent messages. It only sends next message until previous message is
> > done. This cannot fulfill CMDQ's requirement.
> >
> I understand
>  a) GCE HW can internally queue many tasks in some 'FIFO'
>  b) Execution of some task may have to wait until some external event
> occurs (like vsync)
>  c) GCE does not generate irq/flag for each task executed (?)
> 
> If so, may be your tx_done should return 'true' so long as the GCE HW
> can accept tasks in its 'FIFO'. For mailbox api, any task that is
> queued on GCE, is assumed to be transmitted.
> 
> > Quote some code from mailbox driver. Please notice "active_req" part.
> >
> > static void msg_submit(struct mbox_chan *chan)
> > {
> >         ...
> >         if (!chan->msg_count || chan->active_req)
> >                 goto exit;
> >         ...
> >         err = chan->mbox->ops->send_data(chan, data);
> >         if (!err) {
> >                 chan->active_req = data;
> >                 chan->msg_count--;
> >         }
> >         ...
> > }
> >
> > static void tx_tick(struct mbox_chan *chan, int r)
> > {
> >         ...
> >         spin_lock_irqsave(&chan->lock, flags);
> >         mssg = chan->active_req;
> >         chan->active_req = NULL;
> >         spin_unlock_irqrestore(&chan->lock, flags);
> >         ...
> > }
> >
> > Current workable CMDQ driver uses mbox_client_txdone() to prevent
> > this issue, and then uses self callback functions to handle done tasks.
> >
> > int cmdq_task_flush_async(struct cmdq_client *client, struct cmdq_task
> > *task, cmdq_async_flush_cb cb, void *data)
> > {
> >         ...
> >         mbox_send_message(client->chan, task);
> >         /* We can send next task immediately, so just call txdone. */
> >         mbox_client_txdone(client->chan, 0);
> >         ...
> > }
> >
> > Another solution is to use rx_callback; i.e. CMDQ mailbox controller
> > call mbox_chan_received_data() when CMDQ task is done. But, this may
> > violate the design of mailbox. What do you think?
> >
> If my point (c) above does not hold, maybe look at implementing
> tx_done() callback and submit next task from the callback of last
> done.


Hi Jassi,

For point (c), GCE irq means 1~n tasks done or
0~n tasks done + 1 task error.
In irq, we can know which tasks are done by register and GCE pc.

As I mentioned before, we cannot submit next task after previous task
call tx_done. We need to submit multiple tasks to GCE HW immediately
and queue them in GCE HW. Let me explain this requirement by mouse
cursor example. User may move mouse quickly between two vsync, so DRM
may update display registers frequently. For CMDQ, that means many tasks
are flushed into CMDQ driver, and CMDQ driver needs to process all of
them in next vblank. Therefore, we cannot block any CMDQ task in SW
buffer.

CMDQ needs to call callback function to notice clients which tasks are
done. In my previous e-mail, I mentioned that rx_callback may be an
alternative solution. However, it seems to violate the design of
mailbox. Therefore, I think mailbox may not have a good solution for
CMDQ callback currently. IMHO, the better way is to use CMDQ self
callback for now.

Thanks,
HS

^ permalink raw reply

* [PATCH v2] arm: Added support for getcpu() vDSO using TPIDRURW
From: Fredrik Markström @ 2016-10-05 12:25 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161004170741.GC29008@leverpostej>

On Tue, Oct 4, 2016 at 7:08 PM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Tue, Oct 04, 2016 at 05:35:33PM +0200, Fredrik Markstrom wrote:
> > This makes getcpu() ~1000 times faster, this is very useful when
> > implementing per-cpu buffers in userspace (to avoid cache line
> > bouncing). As an example lttng ust becomes ~30% faster.
> >
> > The patch will break applications using TPIDRURW (which is context switched
> > since commit 4780adeefd042482f624f5e0d577bf9cdcbb760 ("ARM: 7735/2:
>
> It looks like you dropped the leading 'a' from the commit ID. For
> everyone else's benefit, the full ID is:
>
>   a4780adeefd042482f624f5e0d577bf9cdcbb760


Sorry for that and thanks for fixing it.

>
>
> Please note that arm64 has done similar for compat tasks since commit:
>
>   d00a3810c16207d2 ("arm64: context-switch user tls register tpidr_el0 for
>   compat tasks")
>
> > Preserve the user r/w register TPIDRURW on context switch and fork")) and
> > is therefore made configurable.
>
> As you note above, this is an ABI break and *will* break some existing
> applications. That's generally a no-go.


Ok, I wasn't sure this was considered an ABI (but I'm not entirely
surprised ;) ). The way I was
trying to defend the breakage was by reasoning that that if it was an
ABI we broke it both with a4780ad
and with 6a1c531, and since we don't break ABI:s, it can't be one.

But hey, I'm humble here and ready to back off.

>
> This also leaves arm64's compat with the existing behaviour, differing
> from arm.
>
> I was under the impression that other mechanisms were being considered
> for fast userspace access to per-cpu data structures, e.g. restartable
> sequences. What is the state of those? Why is this better?
>
> If getcpu() specifically is necessary, is there no other way to
> implement it?

If you are referring to the user space stuff can probably be
implemented other ways,
it's just convenient since the interface is there and it will speed up
stuff like lttng without
modifications (well, except glibc). It's also already implemented as a
vDSO on other
major architectures (like x86, x86_64, ppc32 and ppc64).

If you are referring to the implementation of the vdso call, there are
other possibilities, but
I haven't found any that doesn't introduce overhead in context switching.

But if TPIDRURW is definitely a no go, I can work on a patch that does
this with a thread notifier
and the vdso data page. Would that be a viable option ?

>
> > +notrace int __vdso_getcpu(unsigned int *cpup, unsigned int *nodep,
> > +                       struct getcpu_cache *tcache)
> > +{
> > +     unsigned long node_and_cpu;
> > +
> > +     asm("mrc p15, 0, %0, c13, c0, 2\n" : "=r"(node_and_cpu));
> > +
> > +     if (nodep)
> > +             *nodep = cpu_to_node(node_and_cpu >> 16);
> > +     if (cpup)
> > +             *cpup  = node_and_cpu & 0xffffUL;
>
> Given this is directly user-accessible, this format is a de-facto ABI,
> even if it's not documented as such. Is this definitely the format you
> want long-term?

Yes, this (the interface) is indeed the important part and therefore I
tried not to invent anything
on my own.
This is the interface used by ppc32, ppc64, x86, x86_64. It's also this is
how the getcpu(2) system call is documented.

/Fredrik


>
>
> Thanks,
> Mark.

^ permalink raw reply

* [PATCH v5] devicetree: bindings: uart: Add new compatible string for ZynqMP
From: Nava kishore Manne @ 2016-10-05 12:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161003184234.GA13165@rob-hp-laptop>

Hi Rob,

	Thanks for the review...

> > Changes for v5:
> > 		-Fixed some minor comments.
> 
> Not a useful changelog. The point of these comments is to remind the
> reviewers of what they commented on.

Ok will take care from next version onwards...

> >  Required properties:
> > -- compatible : should be "cdns,uart-r1p8", or "xlnx,xuartps"
> > +- compatible :
> > +  Use "cdns,uart-r1p8", or "xlnx,xuartps" for Zynq-7xxx SoC.
> 
> This is still not right. It was wrong before, but you are touching it so make it
> right.
> 
> OR doesn't match the dts files. It is AND and the opposite order.
> 
> xlnx,xuartps wasn't the best naming, but it's in use so we'll have to live with it
> for zynq-7xxx.
> 
> > +  Use "cdns,uart-r1p12" for Zynq Ultrascale+ MPSoC.
> 
> What I meant here was this should have something like "xlnx,mpsoc-uart"
> as the first compatible with "cdns,uart-r1p12" as the second. Not sure if
> "mpsoc" is the best name here.

You mean something like below
 Use "xlnx,xuartps" or "cdns,uart-r1p8" for Zynq-7xxx SoC.
Use "xlnx,zynqmp-uart" or " cdns,uart-r1p12" for Zynq Ultrascale+ MPSoC.

Please correct me if my understanding is wrong.

Regards,
Navakishore.

^ permalink raw reply

* [PATCH/RFC 4/4] soc: renesas: Identify SoC and register with the SoC bus
From: Dirk Behme @ 2016-10-05 12:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475572167-29581-5-git-send-email-geert+renesas@glider.be>

Hi Geert,

I've been offline some weeks, so sorry if I'm not completely up to date, 
yet, or miss anything.

Overall, having a quick look, the proposal in this patch series and your 
second series "arm64: renesas: r8a7795: R-Car H3 ES2.0 Prototype" looks 
nice to me. At least much better than encoding the ESx.x in the device 
tree as discussed some month ago ;)

Two minor comments below:


On 04.10.2016 11:09, Geert Uytterhoeven wrote:
> Identify the SoC type and revision, and register this information with
> the SoC bus, so it is available under /sys/devices/soc0/, and can be
> checked where needed using soc_device_match().
>
> In addition, on SoCs that support it, the product ID is read from a
> hardware register and validated, to catch accidental use of a DTB for a
> different SoC.
>
> Example:
>
>     Detected Renesas r8a7791 ES1.0
>     ...
>     # cat /sys/devices/soc0/{family,machine,soc_id,revision}
>     R-Car Gen2
>     Koelsch
>     r8a7791
>     ES1.0
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> This patch does NOT add a call to
>
>         of_platform_default_populate(NULL, NULL,
>                                      soc_device_to_device(soc_dev));
>
> Contrary to suggested by commit 74d1d82cdaaec727 ("drivers/base: add bus
> for System-on-Chip devices), doing so would not only move on-SoC devices
> from /sys/devices/platform/ to /sys/devices/soc0/, but also all other
> board (off-SoC) devices specified in the DTB.
> ---
>  arch/arm/mach-shmobile/Kconfig    |   1 +
>  arch/arm64/Kconfig.platforms      |   1 +
>  drivers/soc/renesas/Makefile      |   2 +
>  drivers/soc/renesas/renesas-soc.c | 266 ++++++++++++++++++++++++++++++++++++++
>  4 files changed, 270 insertions(+)
>  create mode 100644 drivers/soc/renesas/renesas-soc.c
>
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index b5a3cbe81dd1d1f0..e41d2cbb2c825981 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -42,6 +42,7 @@ menuconfig ARCH_RENESAS
>  	select HAVE_ARM_TWD if SMP
>  	select NO_IOPORT_MAP
>  	select PINCTRL
> +	select SOC_BUS
>  	select ZONE_DMA if ARM_LPAE
>
>  if ARCH_RENESAS
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index be5d824ebdba2dab..a2675afc61baba8d 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -131,6 +131,7 @@ config ARCH_RENESAS
>  	select PM
>  	select PM_GENERIC_DOMAINS
>  	select RENESAS_IRQC
> +	select SOC_BUS
>  	help
>  	  This enables support for the ARMv8 based Renesas SoCs.
>
> diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
> index 623039c3514cdc34..ae6ae8a11f98aba1 100644
> --- a/drivers/soc/renesas/Makefile
> +++ b/drivers/soc/renesas/Makefile
> @@ -1,3 +1,5 @@
> +obj-y				+= renesas-soc.o
> +
>  obj-$(CONFIG_ARCH_R8A7779)	+= rcar-sysc.o r8a7779-sysc.o
>  obj-$(CONFIG_ARCH_R8A7790)	+= rcar-sysc.o r8a7790-sysc.o
>  obj-$(CONFIG_ARCH_R8A7791)	+= rcar-sysc.o r8a7791-sysc.o
> diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c
> new file mode 100644
> index 0000000000000000..74b72e4112b8889e
> --- /dev/null
> +++ b/drivers/soc/renesas/renesas-soc.c
> @@ -0,0 +1,266 @@
> +/*
> + * Renesas SoC Identification
> + *
> + * Copyright (C) 2014-2016 Glider bvba
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <linux/sys_soc.h>
> +
> +
> +struct renesas_family {
> +	const char name[16];
> +	u32 reg;			/* CCCR, PVR, or PRR */


I'm wondering if we want to encode this information in the device tree?

 From the structs below it looks like this is information would be 
typically given in the device tree, and not hard coded in this C code?

On the other hand, above you mention

"catch accidental use of a DTB for a different SoC"

which is a nice feature, too.

So I just want to talk about the pros & cons, most probably both ways 
are fine.


> +};
> +
> +static const struct renesas_family fam_emev2 __initconst = {
> +	.name	= "Emma Mobile EV2",
> +};
> +
> +static const struct renesas_family fam_rmobile __initconst = {
> +	.name	= "R-Mobile",
> +	.reg	= 0xe600101c,		/* CCCR (Common Chip Code Register) */
> +};
> +
> +static const struct renesas_family fam_rcar_gen1 __initconst = {
> +	.name	= "R-Car Gen1",
> +	.reg	= 0xff000044,		/* PRR (Product Register) */
> +};
> +
> +static const struct renesas_family fam_rcar_gen2 __initconst = {
> +	.name	= "R-Car Gen2",
> +	.reg	= 0xff000044,		/* PRR (Product Register) */
> +};
> +
> +static const struct renesas_family fam_rcar_gen3 __initconst = {
> +	.name	= "R-Car Gen3",
> +	.reg	= 0xfff00044,		/* PRR (Product Register) */
> +};
> +
> +static const struct renesas_family fam_rza __initconst = {
> +	.name	= "RZ/A",
> +};
> +
> +static const struct renesas_family fam_rzg __initconst = {
> +	.name	= "RZ/G",
> +	.reg	= 0xff000044,		/* PRR (Product Register) */
> +};
> +
> +static const struct renesas_family fam_shmobile __initconst = {
> +	.name	= "SH-Mobile",
> +	.reg	= 0xe600101c,		/* CCCR (Common Chip Code Register) */
> +};
> +
> +
> +struct renesas_soc {
> +	const struct renesas_family *family;
> +	u8 id;
> +};
> +
> +static const struct renesas_soc soc_emev2 __initconst = {
> +	.family	= &fam_emev2,
> +};
> +
> +static const struct renesas_soc soc_rz_a1h __initconst = {
> +	.family	= &fam_rza,
> +};
> +
> +static const struct renesas_soc soc_rmobile_ape6 __initconst = {
> +	.family	= &fam_rmobile,
> +	.id	= 0x3f,
> +};
> +
> +static const struct renesas_soc soc_rmobile_a1 __initconst = {
> +	.family	= &fam_rmobile,
> +	.id	= 0x40,
> +};
> +
> +static const struct renesas_soc soc_rz_g1m __initconst = {
> +	.family	= &fam_rzg,
> +	.id	= 0x47,
> +};
> +
> +static const struct renesas_soc soc_rz_g1e __initconst = {
> +	.family	= &fam_rzg,
> +	.id	= 0x4c,
> +};
> +
> +static const struct renesas_soc soc_rcar_m1a __initconst = {
> +	.family	= &fam_rcar_gen1,
> +};
> +
> +static const struct renesas_soc soc_rcar_h1 __initconst = {
> +	.family	= &fam_rcar_gen1,
> +	.id	= 0x3b,
> +};
> +
> +static const struct renesas_soc soc_rcar_h2 __initconst = {
> +	.family	= &fam_rcar_gen2,
> +	.id	= 0x45,
> +};
> +
> +static const struct renesas_soc soc_rcar_m2_w __initconst = {
> +	.family	= &fam_rcar_gen2,
> +	.id	= 0x47,
> +};
> +
> +static const struct renesas_soc soc_rcar_v2h __initconst = {
> +	.family	= &fam_rcar_gen2,
> +	.id	= 0x4a,
> +};
> +
> +static const struct renesas_soc soc_rcar_m2_n __initconst = {
> +	.family	= &fam_rcar_gen2,
> +	.id	= 0x4b,
> +};
> +
> +static const struct renesas_soc soc_rcar_e2 __initconst = {
> +	.family	= &fam_rcar_gen2,
> +	.id	= 0x4c,
> +};
> +
> +static const struct renesas_soc soc_rcar_h3 __initconst = {
> +	.family	= &fam_rcar_gen3,
> +	.id	= 0x4f,
> +};
> +
> +static const struct renesas_soc soc_rcar_m3_w __initconst = {
> +	.family	= &fam_rcar_gen3,
> +	.id	= 0x52,
> +};
> +
> +static const struct renesas_soc soc_shmobile_ag5 __initconst = {
> +	.family	= &fam_shmobile,
> +	.id	= 0x37,
> +};
> +
> +static const struct of_device_id renesas_socs[] __initconst = {
> +#ifdef CONFIG_ARCH_EMEV2
> +	{ .compatible = "renesas,emev2",	.data = &soc_emev2 },
> +#endif
> +#ifdef CONFIG_ARCH_R7S72100
> +	{ .compatible = "renesas,r7s72100",	.data = &soc_rz_a1h },
> +#endif
> +#ifdef CONFIG_ARCH_R8A73A4
> +	{ .compatible = "renesas,r8a73a4",	.data = &soc_rmobile_ape6 },
> +#endif
> +#ifdef CONFIG_ARCH_R8A7740
> +	{ .compatible = "renesas,r8a7740",	.data = &soc_rmobile_a1 },
> +#endif
> +#ifdef CONFIG_ARCH_R8A7743
> +	{ .compatible = "renesas,r8a7743",	.data = &soc_rz_g1m },
> +#endif
> +#ifdef CONFIG_ARCH_R8A7745
> +	{ .compatible = "renesas,r8a7745",	.data = &soc_rz_g1e },
> +#endif
> +#ifdef CONFIG_ARCH_R8A7778
> +	{ .compatible = "renesas,r8a7778",	.data = &soc_rcar_m1a },
> +#endif
> +#ifdef CONFIG_ARCH_R8A7779
> +	{ .compatible = "renesas,r8a7779",	.data = &soc_rcar_h1 },
> +#endif
> +#ifdef CONFIG_ARCH_R8A7790
> +	{ .compatible = "renesas,r8a7790",	.data = &soc_rcar_h2 },
> +#endif
> +#ifdef CONFIG_ARCH_R8A7791
> +	{ .compatible = "renesas,r8a7791",	.data = &soc_rcar_m2_w },
> +#endif
> +#ifdef CONFIG_ARCH_R8A7792
> +	{ .compatible = "renesas,r8a7792",	.data = &soc_rcar_v2h },
> +#endif
> +#ifdef CONFIG_ARCH_R8A7793
> +	{ .compatible = "renesas,r8a7793",	.data = &soc_rcar_m2_n },
> +#endif
> +#ifdef CONFIG_ARCH_R8A7794
> +	{ .compatible = "renesas,r8a7794",	.data = &soc_rcar_e2 },
> +#endif
> +#ifdef CONFIG_ARCH_R8A7795
> +	{ .compatible = "renesas,r8a7795",	.data = &soc_rcar_h3 },
> +#endif
> +#ifdef CONFIG_ARCH_R8A7796
> +	{ .compatible = "renesas,r8a7796",	.data = &soc_rcar_m3_w },
> +#endif
> +#ifdef CONFIG_ARCH_SH73A0
> +	{ .compatible = "renesas,sh73a0",	.data = &soc_shmobile_ag5 },
> +#endif
> +	{ /* sentinel */ }
> +};
> +
> +static int __init renesas_soc_init(void)
> +{
> +	struct soc_device_attribute *soc_dev_attr;
> +	const struct renesas_family *family;
> +	unsigned int product, esi = 0, esf;
> +	const struct of_device_id *match;
> +	const struct renesas_soc *soc;
> +	struct soc_device *soc_dev;
> +	struct device_node *np;
> +	void __iomem *mapped;
> +
> +	np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
> +	if (!np)
> +		return -ENODEV;
> +
> +	of_node_put(np);
> +	soc = match->data;
> +	family = soc->family;
> +
> +	if (soc->id) {
> +		mapped = ioremap(family->reg, 4);
> +		if (!mapped)
> +			return -ENOMEM;
> +
> +		product = readl(mapped);
> +		iounmap(mapped);
> +
> +		if (((product >> 8) & 0xff) != soc->id) {
> +			pr_crit("SoC mismatch (product = 0x%x)\n", product);
> +			return -ENODEV;
> +		}
> +
> +		esi = ((product >> 4) & 0x0f) + 1;
> +		esf = product & 0xf;


I'm somehow surprised to see that all SoCs covered here use the same way 
to encode esi and esf? I would have expected that we need different 
decoding for different SoCs. But if this isn't the case, even better :)


Best regards

Dirk

^ permalink raw reply

* [PATCH 08/14] dt-bindings: sound: Add sun8i analog codec documentation
From: Mylene Josserand @ 2016-10-05 12:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAGb2v67gT9j6-NYj04+et2PNHRGFUzhgCnVgX+eoPGybArL60A@mail.gmail.com>

Hello,


On 05/10/2016 04:59, Chen-Yu Tsai wrote:
> On Wed, Oct 5, 2016 at 12:24 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>> Hi,
>>
>> On Tue, Oct 04, 2016 at 11:46:21AM +0200, Myl?ne Josserand wrote:
>>> Add the documentation for dt-binding of the analog audiocodec
>>> driver for SUN8I SoC.
>>>
>>> Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>
>>> ---
>>>  .../devicetree/bindings/sound/sun8i-codec-analog.txt | 20 ++++++++++++++++++++
>>>  1 file changed, 20 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
>>> new file mode 100644
>>> index 0000000..a03ec20
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
>>> @@ -0,0 +1,20 @@
>>> +* Allwinner A23/A33 Analog Codec
>>> +
>>> +This codec must be handled as a PRCM subnode.
>>
>> Like Mark was saying, you should probably reference the sun6i-prcm.txt
>> binding here


Okay, I will explain more how it works.


>>
>>> +Required properties:
>>> +- compatible: must be either "allwinner,sun8i-codec-analog"
>>
>> Our compatible prefix is <family>-<soc>, and using the older SoC that
>> introduced that block.
>>
>> In this case, that would be sun6i-a31, I think?
>
> sun6i-a31s actually, but a31s has extra line out controls,
> so the right one would be sun8i-a23. Both are listed in my
> original driver.


It is noted.

Thanks!


-- 
Myl?ne Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [PATCH 06/14] ASoC: Add sun8i digital audio codec
From: Mylene Josserand @ 2016-10-05 11:54 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161004144008.0d07d18c@free-electrons.com>

Hello,


On 04/10/2016 14:40, Thomas Petazzoni wrote:
> Hello,
>
> On Tue,  4 Oct 2016 11:46:19 +0200, Myl?ne Josserand wrote:
>> Add the digital sun8i audio codec which handles the base register
>> (without DAI).
>
> I'm not sure what you mean by "which handles the base register".

I wanted to explain that it is registers for audio codec and not PRCM 
ones. This is, maybe, unclear (and useless ?).

>
>> diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
>> index 7aee95a..9e287b0 100644
>> --- a/sound/soc/sunxi/Kconfig
>> +++ b/sound/soc/sunxi/Kconfig
>> @@ -27,6 +27,15 @@ config SND_SUN4I_SPDIF
>>  	  Say Y or M to add support for the S/PDIF audio block in the Allwinner
>>  	  A10 and affiliated SoCs.
>>
>> +config SND_SUN8I_CODEC
>> +	tristate "Allwinner SUN8I audio codec"
>> +	select REGMAP_MMIO
>> +        help
>
> Indentation issue here, it should be intended with one tab, not spaces.
>
> You probably also want a "depends on OF" here.

Yes, thanks !

>
>> +/* CODEC_OFFSET represents the offset of the codec registers
>> + * and not all the DAI registers
>> + */
>
> This is not the proper comment style I believe for audio code, it
> should be:
>
> /*
>  * ...
>  */
>
>> +#define CODEC_OFFSET				0x200
>
> Do you really need this CODEC_OFFSET macro? Why not simply use directly
> the right offsets? I.e instead of:
>
>   #define SUN8I_SYSCLK_CTL			(0x20c - CODEC_OFFSET)
>
> use:
>
>   #define SUN8I_SYSCLK_CTL			0xc

I thought it could be easier to find registers using offset but I guess 
that register's names are enough.

>
>> +#define CODEC_BASSADDRESS			0x01c22c00
>
> This define is not used anywhere.

Yes, sorry, I forgot to remove it.

>
>> +#define SUN8I_SYSCLK_CTL			(0x20c - CODEC_OFFSET)
>> +#define SUN8I_SYSCLK_CTL_AIF1CLK_ENA		(11)
>> +#define SUN8I_SYSCLK_CTL_SYSCLK_ENA		(3)
>> +#define SUN8I_SYSCLK_CTL_SYSCLK_SRC		(0)
>
> Parenthesis around single values are not really useful.
>
>> +#define SUN8I_MOD_CLK_ENA			(0x210 - CODEC_OFFSET)
>> +#define SUN8I_MOD_CLK_ENA_AIF1			(15)
>> +#define SUN8I_MOD_CLK_ENA_DAC			(2)
>> +#define SUN8I_MOD_RST_CTL			(0x214 - CODEC_OFFSET)
>> +#define SUN8I_MOD_RST_CTL_AIF1			(15)
>> +#define SUN8I_MOD_RST_CTL_DAC			(2)
>> +#define SUN8I_SYS_SR_CTRL			(0x218 - CODEC_OFFSET)
>> +#define SUN8I_SYS_SR_CTRL_AIF1_FS		(12)
>> +#define SUN8I_SYS_SR_CTRL_AIF2_FS		(8)
>> +#define SUN8I_AIF1CLK_CTRL			(0x240 - CODEC_OFFSET)
>> +#define SUN8I_AIF1CLK_CTRL_AIF1_MSTR_MOD	(15)
>> +#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV	(14)
>> +#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV	(13)
>> +#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV	(9)
>> +#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV	(6)
>> +#define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ	(4)
>> +#define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT	(2)
>> +#define SUN8I_AIF1_DACDAT_CTRL			(0x248 - CODEC_OFFSET)
>> +#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA	(15)
>> +#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA	(14)
>> +#define SUN8I_DAC_DIG_CTRL			(0x320 - CODEC_OFFSET)
>> +#define SUN8I_DAC_DIG_CTRL_ENDA		(15)
>> +#define SUN8I_DAC_MXR_SRC			(0x330 - CODEC_OFFSET)
>> +#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA0L (15)
>> +#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA1L (14)
>> +#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF2DACL (13)
>> +#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_ADCL	(12)
>> +#define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA0R (11)
>> +#define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA1R (10)
>> +#define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF2DACR (9)
>> +#define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR	(8)
>
> Indentation of the value is not very clean for those last defines.
>
>> +static int sun8i_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
>> +{
>> +	struct sun8i_codec *scodec = snd_soc_codec_get_drvdata(dai->codec);
>> +	unsigned long value;
>
> I'm not sure "unsigned long" is a very good choice here, it's going to
> be a 64 bits integer on 64 bits platform. I'd suggest to use "u32",
> which also seems to be what's used in _set_fmt() function of the
> sun4i-i2s.c driver.

Agreed, thanks !

>
>
>> +static int sun8i_codec_hw_params(struct snd_pcm_substream *substream,
>> +				 struct snd_pcm_hw_params *params,
>> +				 struct snd_soc_dai *dai)
>> +{
>> +	int rs_value  = 0;
>
> Two spaces before the = sign, not needed. Is the initialization to 0
> really needed? Also, this should be a u32.

ditto

>
>> +	regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
>> +			   0x3 << SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ,
>
> Maybe a #define value to replace the hardcoded 0x3 ?
>
>> +			   rs_value << SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ);
>> +
>> +	/* calculate bclk_lrck_div Ratio */
>> +	bclk_lrck_div = sample_resolution * 2;
>> +	switch (bclk_lrck_div) {
>> +	case 16:
>> +		bclk_lrck_div = 0;
>> +		break;
>> +	case 32:
>> +		bclk_lrck_div = 1;
>> +		break;
>> +	case 64:
>> +		bclk_lrck_div = 2;
>> +		break;
>> +	case 128:
>> +		bclk_lrck_div = 3;
>> +		break;
>> +	case 256:
>> +		bclk_lrck_div = 4;
>> +		break;
>
> This could quite easily be replaced by a formula, if you don't care
> about error checking:
>
> 	bclk_lrck_div = log2(bclk_lrck_div) - 4;
>
> Of course, if you care about error checking, this switch is nicer.
>
>> +	default:
>
> So there's no error checking if the value is not supported?

You are right. I guess it should return -EINVAL.

[snip]

>
>
>> +static struct snd_soc_dai_driver sun8i_codec_dai = {
>> +	.name = "sun8i",
>> +	/* playback capabilities */
>> +	.playback = {
>> +		.stream_name = "Playback",
>> +		.channels_min = 1,
>> +		.channels_max = 2,
>> +		.rates = SNDRV_PCM_RATE_8000_192000 |
>> +			SNDRV_PCM_RATE_KNOT,
>> +		.formats = SNDRV_PCM_FMTBIT_S8 |
>> +			SNDRV_PCM_FMTBIT_S16_LE |
>> +			SNDRV_PCM_FMTBIT_S18_3LE |
>> +			SNDRV_PCM_FMTBIT_S20_3LE |
>> +			SNDRV_PCM_FMTBIT_S24_LE |
>> +			SNDRV_PCM_FMTBIT_S32_LE,
>> +	},
>> +	/* pcm operations */
>> +	.ops = &sun8i_codec_dai_ops,
>> +};
>> +EXPORT_SYMBOL(sun8i_codec_dai);
>
> This EXPORT_SYMBOL looks wrong. First because it doesn't seem to be
> used outside of this module. And second because using EXPORT_SYMBOL on
> a function defined as static doesn't make much sense, as the "static"
> qualifier limits the visibility of the symbol to the current
> compilation unit.
>

Yes, sorry, I missed it from the clean-up of the original driver.

[snip]

>> +static int sun8i_codec_probe(struct platform_device *pdev)
>> +{
>> +	struct resource *res_base;
>> +	struct sun8i_codec *scodec;
>> +	void __iomem *base;
>> +
>> +	scodec = devm_kzalloc(&pdev->dev, sizeof(*scodec), GFP_KERNEL);
>> +	if (!scodec)
>> +		return -ENOMEM;
>> +
>> +	scodec->dev = &pdev->dev;
>> +
>> +	/* Get the clocks from the DT */
>> +	scodec->clk_module = devm_clk_get(&pdev->dev, "codec");
>> +	if (IS_ERR(scodec->clk_module)) {
>> +		dev_err(&pdev->dev, "Failed to get the module clock\n");
>> +		return PTR_ERR(scodec->clk_module);
>> +	}
>> +	if (clk_prepare_enable(scodec->clk_module))
>> +		pr_err("err:open failed;\n");
>
> Grr, pr_err, not good. Plus you want to return with an error from the
> probe() function.

Oh, sorry for that ugly use :(

>
>> +
>> +	scodec->clk_apb = devm_clk_get(&pdev->dev, "apb");
>> +	if (IS_ERR(scodec->clk_apb)) {
>> +		dev_err(&pdev->dev, "Failed to get the apb clock\n");
>> +		return PTR_ERR(scodec->clk_apb);
>> +	}
>> +	if (clk_prepare_enable(scodec->clk_apb))
>> +		pr_err("err:open failed;\n");
>
> Ditto. + unprepare/disable the previous clock.

[snip]

ack, thank you for the review!


-- 
Myl?ne Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [PATCH v2] Adding missing features of Coresight PTM components
From: Muhammad Abdul WAHAB @ 2016-10-05 11:42 UTC (permalink / raw)
  To: linux-arm-kernel

In the current driver for Coresight components, two features of PTM
components are missing:

1. Branch Broadcasting (present also in ETM but called Branch Output)
2. Return Stack (only present in PTM v1.0 and PTMv1.1)

These features can be added simply to the code using `mode` field of
`etm_config` struct.

1. **Branch Broadcast** : The branch broadcast feature is present in ETM
components as well and is called Branch output. It allows to retrieve
addresses for direct branch addresses alongside the indirect branch
addresses. For example, it could be useful in cases when tracing without
source code.
2. **Return Stack** : The return stack option allows to retrieve the return
  addresses of function calls. It can be useful to avoid CRA
(Code Reuse Attacks) by keeping a shadowstack.

Signed-off-by: Muhammad Abdul Wahab <muhammadabdul.wahab@centralesupelec.fr>
---
changes in v2 :
	- modified patch description
	- removed additional comments on testing
	- removed a check on architecture version of ETM
	- generated using "git format-patch"
	- same email address in from: and SOB
	
  drivers/hwtracing/coresight/coresight-etm.h         |  3 +++
  drivers/hwtracing/coresight/coresight-etm3x-sysfs.c | 12 ++++++++++++
  2 files changed, 15 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-etm.h 
b/drivers/hwtracing/coresight/coresight-etm.h
index 4a18ee4..7a34860 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -110,8 +110,11 @@
  #define ETM_MODE_STALL		BIT(2)
  #define ETM_MODE_TIMESTAMP	BIT(3)
  #define ETM_MODE_CTXID		BIT(4)
+#define ETM_MODE_BBROAD		BIT(5)
+#define ETM_MODE_RET_STACK	BIT(6)
  #define ETM_MODE_ALL		(ETM_MODE_EXCLUDE | ETM_MODE_CYCACC | \
  				 ETM_MODE_STALL | ETM_MODE_TIMESTAMP | \
+				 ETM_MODE_BBROAD | ETM_MODE_RET_STACK | \
  				 ETM_MODE_CTXID | ETM_MODE_EXCL_KERN | \
  				 ETM_MODE_EXCL_USER)

diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c 
b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
index 5ea0909..4e0eab7 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
@@ -164,6 +164,18 @@ static ssize_t mode_store(struct device *dev,
  	else
  		config->ctrl &= ~ETMCR_CTXID_SIZE;

+	if (config->mode & ETM_MODE_BBROAD)
+		config->ctrl |= ETMCR_BRANCH_BROADCAST;
+	else
+		config->ctrl &= ~ETMCR_BRANCH_BROADCAST;
+
+	if (config->mode & ETM_MODE_RET_STACK) {
+		if (config->mode & ETM_MODE_BBROAD)
+			dev_warn(drvdata->dev, "behavior is unpredictable\n");
+		config->ctrl |= ETMCR_RETURN_STACK_EN;
+	} else
+		config->ctrl &= ~ETMCR_RETURN_STACK_EN;
+
  	if (config->mode & (ETM_MODE_EXCL_KERN | ETM_MODE_EXCL_USER))
  		etm_config_trace_mode(config);

-- 
1.9.1

^ permalink raw reply related

* [PATCH] indentation fix (extra space removed)
From: Muhammad Abdul WAHAB @ 2016-10-05 11:41 UTC (permalink / raw)
  To: linux-arm-kernel

An extra space is removed.

Signed-off-by: Muhammad Abdul Wahab <muhammadabdul.wahab@centralesupelec.fr>
---
  drivers/hwtracing/coresight/coresight-etm3x-sysfs.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c 
b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
index e9b0719..5ea0909 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
@@ -146,7 +146,7 @@ static ssize_t mode_store(struct device *dev,
  			goto err_unlock;
  		}
  		config->ctrl |= ETMCR_STALL_MODE;
-	 } else
+	} else
  		config->ctrl &= ~ETMCR_STALL_MODE;

  	if (config->mode & ETM_MODE_TIMESTAMP) {
-- 
1.9.1

^ permalink raw reply related

* [PATCH v7 21/22] iommu/dma: Add support for mapping MSIs
From: Nipun Gupta @ 2016-10-05 11:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <6ec9519b-01df-3be8-2967-7556bd306909@arm.com>



> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Wednesday, October 05, 2016 15:26
> To: Nipun Gupta <nipun.gupta@nxp.com>
> Cc: will.deacon at arm.com; joro at 8bytes.org; iommu at lists.linux-
> foundation.org; linux-arm-kernel at lists.infradead.org;
> devicetree at vger.kernel.org; punit.agrawal at arm.com;
> thunder.leizhen at huawei.com
> Subject: Re: [PATCH v7 21/22] iommu/dma: Add support for mapping MSIs
> 
> On 05/10/16 08:00, Nipun Gupta wrote:
> >
> >
> >> -----Original Message-----
> >> From: iommu-bounces at lists.linux-foundation.org [mailto:iommu-
> >> bounces at lists.linux-foundation.org] On Behalf Of Robin Murphy
> >> Sent: Monday, September 12, 2016 21:44
> >> To: will.deacon at arm.com; joro at 8bytes.org; iommu at lists.linux-
> >> foundation.org; linux-arm-kernel at lists.infradead.org
> >> Cc: devicetree at vger.kernel.org; punit.agrawal at arm.com;
> >> thunder.leizhen at huawei.com
> >> Subject: [PATCH v7 21/22] iommu/dma: Add support for mapping MSIs
> >>
> >> When an MSI doorbell is located downstream of an IOMMU, attaching
> >> devices to a DMA ops domain and switching on translation leads to a
> >> rude shock when their attempt to write to the physical address
> >> returned by the irqchip driver faults (or worse, writes into some
> >> already-mapped
> >> buffer) and no interrupt is forthcoming.
> >>
> >> Address this by adding a hook for relevant irqchip drivers to call
> >> from their
> >> compose_msi_msg() callback, to swizzle the physical address with an
> >> appropriatly-mapped IOVA for any device attached to one of our DMA
> >> ops domains.
> >>
> >> Acked-by: Thomas Gleixner <tglx@linutronix.de>
> >> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> >> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >> ---
> >>  drivers/iommu/dma-iommu.c        | 136
> >> ++++++++++++++++++++++++++++++++++-----
> >>  drivers/irqchip/irq-gic-v2m.c    |   3 +
> >>  drivers/irqchip/irq-gic-v3-its.c |   3 +
> >>  include/linux/dma-iommu.h        |   9 +++
> >>  4 files changed, 136 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> >> index 00c8a08d56e7..4329d18080cf 100644
> >> --- a/drivers/iommu/dma-iommu.c
> >> +++ b/drivers/iommu/dma-iommu.c
> >> @@ -25,10 +25,28 @@
> >>  #include <linux/huge_mm.h>
> >>  #include <linux/iommu.h>
> >>  #include <linux/iova.h>
> >> +#include <linux/irq.h>
> >>  #include <linux/mm.h>
> >>  #include <linux/scatterlist.h>
> >>  #include <linux/vmalloc.h>
> >>
> >> +struct iommu_dma_msi_page {
> >> +	struct list_head	list;
> >> +	dma_addr_t		iova;
> >> +	phys_addr_t		phys;
> >> +};
> >> +
> >> +struct iommu_dma_cookie {
> >> +	struct iova_domain	iovad;
> >> +	struct list_head	msi_page_list;
> >> +	spinlock_t		msi_lock;
> >> +};
> >> +
> >> +static inline struct iova_domain *cookie_iovad(struct iommu_domain
> >> +*domain) {
> >> +	return &((struct iommu_dma_cookie *)domain->iova_cookie)->iovad; }
> >> +
> >>  int iommu_dma_init(void)
> >>  {
> >>  	return iova_cache_get();
> >> @@ -43,15 +61,19 @@ int iommu_dma_init(void)
> >>   */
> >>  int iommu_get_dma_cookie(struct iommu_domain *domain)  {
> >> -	struct iova_domain *iovad;
> >> +	struct iommu_dma_cookie *cookie;
> >>
> >>  	if (domain->iova_cookie)
> >>  		return -EEXIST;
> >>
> >> -	iovad = kzalloc(sizeof(*iovad), GFP_KERNEL);
> >> -	domain->iova_cookie = iovad;
> >> +	cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
> >> +	if (!cookie)
> >> +		return -ENOMEM;
> >>
> >> -	return iovad ? 0 : -ENOMEM;
> >> +	spin_lock_init(&cookie->msi_lock);
> >> +	INIT_LIST_HEAD(&cookie->msi_page_list);
> >> +	domain->iova_cookie = cookie;
> >> +	return 0;
> >>  }
> >>  EXPORT_SYMBOL(iommu_get_dma_cookie);
> >>
> >> @@ -63,14 +85,20 @@ EXPORT_SYMBOL(iommu_get_dma_cookie);
> >>   */
> >>  void iommu_put_dma_cookie(struct iommu_domain *domain)  {
> >> -	struct iova_domain *iovad = domain->iova_cookie;
> >> +	struct iommu_dma_cookie *cookie = domain->iova_cookie;
> >> +	struct iommu_dma_msi_page *msi, *tmp;
> >>
> >> -	if (!iovad)
> >> +	if (!cookie)
> >>  		return;
> >>
> >> -	if (iovad->granule)
> >> -		put_iova_domain(iovad);
> >> -	kfree(iovad);
> >> +	if (cookie->iovad.granule)
> >> +		put_iova_domain(&cookie->iovad);
> >> +
> >> +	list_for_each_entry_safe(msi, tmp, &cookie->msi_page_list, list) {
> >> +		list_del(&msi->list);
> >> +		kfree(msi);
> >> +	}
> >> +	kfree(cookie);
> >>  	domain->iova_cookie = NULL;
> >>  }
> >>  EXPORT_SYMBOL(iommu_put_dma_cookie);
> >> @@ -88,7 +116,7 @@ EXPORT_SYMBOL(iommu_put_dma_cookie);
> >>   */
> >>  int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t
> >> base, u64 size)  {
> >> -	struct iova_domain *iovad = domain->iova_cookie;
> >> +	struct iova_domain *iovad = cookie_iovad(domain);
> >>  	unsigned long order, base_pfn, end_pfn;
> >>
> >>  	if (!iovad)
> >> @@ -155,7 +183,7 @@ int dma_direction_to_prot(enum
> dma_data_direction
> >> dir, bool coherent)  static struct iova *__alloc_iova(struct
> >> iommu_domain *domain, size_t size,
> >>  		dma_addr_t dma_limit)
> >>  {
> >> -	struct iova_domain *iovad = domain->iova_cookie;
> >> +	struct iova_domain *iovad = cookie_iovad(domain);
> >>  	unsigned long shift = iova_shift(iovad);
> >>  	unsigned long length = iova_align(iovad, size) >> shift;
> >>
> >> @@ -171,7 +199,7 @@ static struct iova *__alloc_iova(struct
> >> iommu_domain *domain, size_t size,
> >>  /* The IOVA allocator knows what we mapped, so just unmap whatever
> >> that was */  static void __iommu_dma_unmap(struct iommu_domain
> >> *domain, dma_addr_t dma_addr)  {
> >> -	struct iova_domain *iovad = domain->iova_cookie;
> >> +	struct iova_domain *iovad = cookie_iovad(domain);
> >>  	unsigned long shift = iova_shift(iovad);
> >>  	unsigned long pfn = dma_addr >> shift;
> >>  	struct iova *iova = find_iova(iovad, pfn); @@ -294,7 +322,7 @@
> >> struct page **iommu_dma_alloc(struct device *dev, size_t size, gfp_t gfp,
> >>  		void (*flush_page)(struct device *, const void *, phys_addr_t))  {
> >>  	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> >> -	struct iova_domain *iovad = domain->iova_cookie;
> >> +	struct iova_domain *iovad = cookie_iovad(domain);
> >>  	struct iova *iova;
> >>  	struct page **pages;
> >>  	struct sg_table sgt;
> >> @@ -386,7 +414,7 @@ dma_addr_t iommu_dma_map_page(struct device
> *dev,
> >> struct page *page,  {
> >>  	dma_addr_t dma_addr;
> >>  	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> >> -	struct iova_domain *iovad = domain->iova_cookie;
> >> +	struct iova_domain *iovad = cookie_iovad(domain);
> >>  	phys_addr_t phys = page_to_phys(page) + offset;
> >>  	size_t iova_off = iova_offset(iovad, phys);
> >>  	size_t len = iova_align(iovad, size + iova_off); @@ -495,7 +523,7
> >> @@ int iommu_dma_map_sg(struct device *dev, struct scatterlist *sg,
> >>  		int nents, int prot)
> >>  {
> >>  	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> >> -	struct iova_domain *iovad = domain->iova_cookie;
> >> +	struct iova_domain *iovad = cookie_iovad(domain);
> >>  	struct iova *iova;
> >>  	struct scatterlist *s, *prev = NULL;
> >>  	dma_addr_t dma_addr;
> >> @@ -587,3 +615,81 @@ int iommu_dma_mapping_error(struct device *dev,
> >> dma_addr_t dma_addr)  {
> >>  	return dma_addr == DMA_ERROR_CODE;
> >>  }
> >> +
> >> +static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct
> >> +device
> >> *dev,
> >> +		phys_addr_t msi_addr, struct iommu_domain *domain) {
> >> +	struct iommu_dma_cookie *cookie = domain->iova_cookie;
> >> +	struct iommu_dma_msi_page *msi_page;
> >> +	struct iova_domain *iovad = &cookie->iovad;
> >> +	struct iova *iova;
> >> +	int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
> >> +
> >> +	msi_addr &= ~(phys_addr_t)iova_mask(iovad);
> >> +	list_for_each_entry(msi_page, &cookie->msi_page_list, list)
> >> +		if (msi_page->phys == msi_addr)
> >> +			return msi_page;
> >> +
> >> +	msi_page = kzalloc(sizeof(*msi_page), GFP_ATOMIC);
> >> +	if (!msi_page)
> >> +		return NULL;
> >> +
> >> +	iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev));
> >
> > I think this should be 'iova = __alloc_iova(domain, iovad->granule,
> dma_get_mask(dev));'
> 
> Er, yes... I fully agree. That's why it is exactly that.
> 
> > as __alloc_iova takes input parameter as 'struct iova_domain *'
> 
> Joking aside, though, I guess you've overlooked the change introduced by
> c987ff0d3cb3 ("iommu/dma: Respect IOMMU aperture when allocating")?

Ooops!! My bad. That's right, I missed out this change.

Thanks,
Nipun

> 
> Robin.
> 
> >
> > Regards,
> > Nipun
> >
> >> +	if (!iova)
> >> +		goto out_free_page;
> >> +
> >> +	msi_page->phys = msi_addr;
> >> +	msi_page->iova = iova_dma_addr(iovad, iova);
> >> +	if (iommu_map(domain, msi_page->iova, msi_addr, iovad->granule,
> >> prot))
> >> +		goto out_free_iova;
> >> +
> >> +	INIT_LIST_HEAD(&msi_page->list);
> >> +	list_add(&msi_page->list, &cookie->msi_page_list);
> >> +	return msi_page;
> >> +
> >> +out_free_iova:
> >> +	__free_iova(iovad, iova);
> >> +out_free_page:
> >> +	kfree(msi_page);
> >> +	return NULL;
> >> +}
> >> +
> >> +void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg) {
> >> +	struct device *dev = msi_desc_to_dev(irq_get_msi_desc(irq));
> >> +	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> >> +	struct iommu_dma_cookie *cookie;
> >> +	struct iommu_dma_msi_page *msi_page;
> >> +	phys_addr_t msi_addr = (u64)msg->address_hi << 32 | msg->address_lo;
> >> +	unsigned long flags;
> >> +
> >> +	if (!domain || !domain->iova_cookie)
> >> +		return;
> >> +
> >> +	cookie = domain->iova_cookie;
> >> +
> >> +	/*
> >> +	 * We disable IRQs to rule out a possible inversion against
> >> +	 * irq_desc_lock if, say, someone tries to retarget the affinity
> >> +	 * of an MSI from within an IPI handler.
> >> +	 */
> >> +	spin_lock_irqsave(&cookie->msi_lock, flags);
> >> +	msi_page = iommu_dma_get_msi_page(dev, msi_addr, domain);
> >> +	spin_unlock_irqrestore(&cookie->msi_lock, flags);
> >> +
> >> +	if (WARN_ON(!msi_page)) {
> >> +		/*
> >> +		 * We're called from a void callback, so the best we can do is
> >> +		 * 'fail' by filling the message with obviously bogus values.
> >> +		 * Since we got this far due to an IOMMU being present, it's
> >> +		 * not like the existing address would have worked anyway...
> >> +		 */
> >> +		msg->address_hi = ~0U;
> >> +		msg->address_lo = ~0U;
> >> +		msg->data = ~0U;
> >> +	} else {
> >> +		msg->address_hi = upper_32_bits(msi_page->iova);
> >> +		msg->address_lo &= iova_mask(&cookie->iovad);
> >> +		msg->address_lo += lower_32_bits(msi_page->iova);
> >> +	}
> >> +}
> >> diff --git a/drivers/irqchip/irq-gic-v2m.c
> >> b/drivers/irqchip/irq-gic-v2m.c index 35eb7ac5d21f..863e073c6f7f
> >> 100644
> >> --- a/drivers/irqchip/irq-gic-v2m.c
> >> +++ b/drivers/irqchip/irq-gic-v2m.c
> >> @@ -16,6 +16,7 @@
> >>  #define pr_fmt(fmt) "GICv2m: " fmt
> >>
> >>  #include <linux/acpi.h>
> >> +#include <linux/dma-iommu.h>
> >>  #include <linux/irq.h>
> >>  #include <linux/irqdomain.h>
> >>  #include <linux/kernel.h>
> >> @@ -108,6 +109,8 @@ static void gicv2m_compose_msi_msg(struct
> >> irq_data *data, struct msi_msg *msg)
> >>
> >>  	if (v2m->flags & GICV2M_NEEDS_SPI_OFFSET)
> >>  		msg->data -= v2m->spi_offset;
> >> +
> >> +	iommu_dma_map_msi_msg(data->irq, msg);
> >>  }
> >>
> >>  static struct irq_chip gicv2m_irq_chip = { diff --git
> >> a/drivers/irqchip/irq-gic-v3- its.c
> >> b/drivers/irqchip/irq-gic-v3-its.c
> >> index 36b9c28a5c91..98ff669d5962 100644
> >> --- a/drivers/irqchip/irq-gic-v3-its.c
> >> +++ b/drivers/irqchip/irq-gic-v3-its.c
> >> @@ -18,6 +18,7 @@
> >>  #include <linux/bitmap.h>
> >>  #include <linux/cpu.h>
> >>  #include <linux/delay.h>
> >> +#include <linux/dma-iommu.h>
> >>  #include <linux/interrupt.h>
> >>  #include <linux/log2.h>
> >>  #include <linux/mm.h>
> >> @@ -655,6 +656,8 @@ static void its_irq_compose_msi_msg(struct
> >> irq_data *d, struct msi_msg *msg)
> >>  	msg->address_lo		= addr & ((1UL << 32) - 1);
> >>  	msg->address_hi		= addr >> 32;
> >>  	msg->data		= its_get_event_id(d);
> >> +
> >> +	iommu_dma_map_msi_msg(d->irq, msg);
> >>  }
> >>
> >>  static struct irq_chip its_irq_chip = { diff --git
> >> a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h index
> >> 81c5c8d167ad..5ee806e41b5c 100644
> >> --- a/include/linux/dma-iommu.h
> >> +++ b/include/linux/dma-iommu.h
> >> @@ -21,6 +21,7 @@
> >>
> >>  #ifdef CONFIG_IOMMU_DMA
> >>  #include <linux/iommu.h>
> >> +#include <linux/msi.h>
> >>
> >>  int iommu_dma_init(void);
> >>
> >> @@ -62,9 +63,13 @@ void iommu_dma_unmap_sg(struct device *dev,
> struct
> >> scatterlist *sg, int nents,  int iommu_dma_supported(struct device
> >> *dev, u64 mask);  int iommu_dma_mapping_error(struct device *dev,
> >> dma_addr_t dma_addr);
> >>
> >> +/* The DMA API isn't _quite_ the whole story, though... */ void
> >> +iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
> >> +
> >>  #else
> >>
> >>  struct iommu_domain;
> >> +struct msi_msg;
> >>
> >>  static inline int iommu_dma_init(void)  { @@ -80,6 +85,10 @@ static
> >> inline void iommu_put_dma_cookie(struct iommu_domain *domain)  {  }
> >>
> >> +static inline void iommu_dma_map_msi_msg(int irq, struct msi_msg
> >> +*msg) { }
> >> +
> >>  #endif	/* CONFIG_IOMMU_DMA */
> >>  #endif	/* __KERNEL__ */
> >>  #endif	/* __DMA_IOMMU_H */
> >> --
> >> 2.8.1.dirty
> >>
> >> _______________________________________________
> >> iommu mailing list
> >> iommu at lists.linux-foundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/iommu
> >

^ permalink raw reply

* [PATCH] MAINTAINERS: Add ARM64-specific ACPI maintainers entry
From: Lorenzo Pieralisi @ 2016-10-05 11:25 UTC (permalink / raw)
  To: linux-arm-kernel

The ARM64 architecture defines ARM64 specific ACPI bindings to
configure and set-up arch specific components. To simplify
code reviews/updates and streamline the maintainership structure
supporting the arch specific code, a new arm64 directory was created in
/drivers/acpi, to contain ACPI code that is specific to ARM64
architecture.

Add the ARM64-specific ACPI maintainers entry in MAINTAINERS for
the newly created subdirectory and respective code content.

Lorenzo Pieralisi will be in charge of submitting and managing
the pull requests on behalf of all maintainers listed.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Link: http://lkml.kernel.org/r/1603704.EGiVTcCxLR at vostro.rjw.lan
---
 MAINTAINERS | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f593300..2a70dd9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -316,6 +316,14 @@ W:	https://01.org/linux-acpi
 S:	Supported
 F:	drivers/acpi/fan.c
 
+ACPI FOR ARM64 (ACPI/arm64)
+M:	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+M:	Hanjun Guo <hanjun.guo@linaro.org>
+M:	Sudeep Holla <sudeep.holla@arm.com>
+L:	linux-acpi at vger.kernel.org
+S:	Maintained
+F:	drivers/acpi/arm64
+
 ACPI THERMAL DRIVER
 M:	Zhang Rui <rui.zhang@intel.com>
 L:	linux-acpi at vger.kernel.org
-- 
2.10.0

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox