* linux-next: failure while fetching the mvebu tree
From: Stephen Rothwell @ 2017-01-03 22:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Fetching the mvebu tree produces this error:
fatal: Couldn't find remote ref refs/heads/for-next
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Rob Herring @ 2017-01-03 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21ea1b0795bdaa30ca475d6ce675b620b2b644ed.1483301745.git.peter.senna@collabora.com>
On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote:
> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> display bridge.
>
> Cc: Martyn Welch <martyn.welch@collabora.co.uk>
> Cc: Martin Donnelly <martin.donnelly@ge.com>
> Cc: Javier Martinez Canillas <javier@dowhile0.org>
> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
> ---
> There was an Acked-by from Rob Herring <robh@kernel.org> for V6, but I changed
> the bindings to use i2c_new_secondary_device() so I removed it from the commit
> message.
>
> .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 ++++++++++++++++++++++
Generally, bindings are not organized by vendor. Put in
bindings/display/bridge/... instead.
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
>
> diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> new file mode 100644
> index 0000000..1bc6ebf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> @@ -0,0 +1,39 @@
> +Driver for GE B850v3 LVDS/DP++ display bridge
> +
> +Required properties:
> + - compatible : should be "ge,b850v3-lvds-dp".
Isn't '-lvds-dp' redundant? The part# should be enough.
> + - reg : should contain the main address which is used to ack the
> + interrupts and address for edid.
> + - reg-names : comma separeted list of register names. Valid values
s/separeted/separated/
> + are "main", and "edid".
> + - interrupt-parent : phandle of the interrupt controller that services
> + interrupts to the device
> + - interrupts : one interrupt should be described here, as in
> + <0 IRQ_TYPE_LEVEL_HIGH>.
> + - port : should describe the video signal connection between the host
> + and the bridge.
> +
> +Example:
> +
> +&mux2_i2c2 {
> + status = "okay";
> + clock-frequency = <100000>;
> +
> + b850v3-lvds-dp-bridge at 73 {
> + compatible = "ge,b850v3-lvds-dp";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <0x73 0x72>;
> + reg-names = "main", "edid";
> +
> + interrupt-parent = <&gpio2>;
> + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +
> + port {
> + b850v3_dp_bridge_in: endpoint {
> + remote-endpoint = <&lvds0_out>;
> + };
> + };
> + };
> +};
> --
> 2.5.5
>
^ permalink raw reply
* [PATCH v3 02/10] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
From: Rob Herring @ 2017-01-03 22:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483339743-23881-1-git-send-email-anurup.m@huawei.com>
On Mon, Jan 02, 2017 at 01:49:03AM -0500, Anurup M wrote:
> From: Tan Xiaojun <tanxiaojun@huawei.com>
>
> Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die
>
> Signed-off-by: Tan Xiaojun <tanxiaojun@huawei.com>
> Signed-off-by: Anurup M <anurup.m@huawei.com>
> ---
> .../devicetree/bindings/arm/hisilicon/djtag.txt | 41 ++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> new file mode 100644
> index 0000000..bbe8b45
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> @@ -0,0 +1,41 @@
> +The Hisilicon Djtag is an independent component which connects with some other
> +components in the SoC by Debug Bus. The djtag is available in CPU and IO dies
> +in the chip. The djtag controls access to connecting modules of CPU and IO
> +dies.
> +The various connecting components in CPU die (like L3 cache, L3 cache PMU etc.)
> +are accessed by djtag during real time debugging. In IO die there are connecting
> +components like RSA. These components appear as devices attached to djtag bus.
> +
> +Hisilicon HiP05/06/07 djtag for CPU and IO die
> +Required properties:
> + - compatible : The value should be as follows
> + (a) "hisilicon,hip05-djtag-v1" for CPU and IO die which use v1 hw in
> + HiP05 chipset.
You don't need to distinguish the CPU and IO blocks?
> + (b) "hisilicon,hip06-djtag-v1" for CPU die which use v1 hw in HiP06 chipset.
> + (c) "hisilicon,hip06-djtag-v2" for IO die which use v2 hw in HiP06 chipset.
> + (d) "hisilicon,hip07-djtag-v2" for CPU and IO die which use v2 hw in
> + HiP07 chipset.
> + - reg : Register address and size
> + - hisi-scl-id : The Super Cluster ID for CPU or IO die
Still needs a vendor prefix. i.e. hisilicon,scl-id
> +
> +Example 1: Djtag for CPU die
> +
> + /* for Hisilicon HiP05 djtag for CPU Die */
> + djtag0: djtag at 80010000 {
> + compatible = "hisilicon,hip05-djtag-v1";
> + reg = <0x0 0x80010000 0x0 0x10000>;
> + hisi-scl-id = <0x02>;
> +
> + /* All connecting components will appear as child nodes */
> + };
> +
> +Example 2: Djtag for IO die
> +
> + /* for Hisilicon HiP05 djtag for IO Die */
> + djtag1: djtag at d0000000 {
> + compatible = "hisilicon,hip05-djtag-v1";
> + reg = <0x0 0xd0000000 0x0 0x10000>;
> + hisi-scl-id = <0x01>;
> +
> + /* All connecting components will appear as child nodes */
> + };
> --
> 2.1.4
>
^ permalink raw reply
* [PATCHv6 00/11] CONFIG_DEBUG_VIRTUAL for arm64
From: Florian Fainelli @ 2017-01-03 22:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483464113-1587-1-git-send-email-labbott@redhat.com>
On 01/03/2017 09:21 AM, Laura Abbott wrote:
> Happy New Year!
>
> This is a very minor rebase from v5. It only moves a few headers around.
> I think this series should be ready to be queued up for 4.11.
FWIW:
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
How do we get this series included? I would like to get the ARM 32-bit
counterpart included as well (will resubmit rebased shortly), but I have
no clue which tree this should be going through.
Thanks!
>
> Thanks,
> Laura
>
> Laura Abbott (11):
> lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
> mm/cma: Cleanup highmem check
> arm64: Move some macros under #ifndef __ASSEMBLY__
> arm64: Add cast for virt_to_pfn
> mm: Introduce lm_alias
> arm64: Use __pa_symbol for kernel symbols
> drivers: firmware: psci: Use __pa_symbol for kernel symbol
> kexec: Switch to __pa_symbol
> mm/kasan: Switch to using __pa_symbol and lm_alias
> mm/usercopy: Switch to using lm_alias
> arm64: Add support for CONFIG_DEBUG_VIRTUAL
>
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/kvm_mmu.h | 4 +-
> arch/arm64/include/asm/memory.h | 66 +++++++++++++++++++++----------
> arch/arm64/include/asm/mmu_context.h | 6 +--
> arch/arm64/include/asm/pgtable.h | 2 +-
> arch/arm64/kernel/acpi_parking_protocol.c | 3 +-
> arch/arm64/kernel/cpu-reset.h | 2 +-
> arch/arm64/kernel/cpufeature.c | 3 +-
> arch/arm64/kernel/hibernate.c | 20 +++-------
> arch/arm64/kernel/insn.c | 2 +-
> arch/arm64/kernel/psci.c | 3 +-
> arch/arm64/kernel/setup.c | 9 +++--
> arch/arm64/kernel/smp_spin_table.c | 3 +-
> arch/arm64/kernel/vdso.c | 8 +++-
> arch/arm64/mm/Makefile | 2 +
> arch/arm64/mm/init.c | 12 +++---
> arch/arm64/mm/kasan_init.c | 22 +++++++----
> arch/arm64/mm/mmu.c | 33 ++++++++++------
> arch/arm64/mm/physaddr.c | 30 ++++++++++++++
> arch/x86/Kconfig | 1 +
> drivers/firmware/psci.c | 2 +-
> include/linux/mm.h | 4 ++
> kernel/kexec_core.c | 2 +-
> lib/Kconfig.debug | 5 ++-
> mm/cma.c | 15 +++----
> mm/kasan/kasan_init.c | 15 +++----
> mm/usercopy.c | 4 +-
> 27 files changed, 180 insertions(+), 99 deletions(-)
> create mode 100644 arch/arm64/mm/physaddr.c
>
--
Florian
^ permalink raw reply
* [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
From: Paul Bolle @ 2017-01-03 22:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3780968.pTT7cvIH4p@wuerfel>
On Tue, 2017-01-03 at 23:25 +0100, Arnd Bergmann wrote:
> As far as I'm concerned, we are totally fine as long as there exists a
> longterm supported kernel that has i4l in drivers/staging.
Or in drivers/isdn, right?
Paul Bolle
^ permalink raw reply
* [PATCH v3 03/10] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
From: Rob Herring @ 2017-01-03 22:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483339761-23927-1-git-send-email-anurup.m@huawei.com>
On Mon, Jan 02, 2017 at 01:49:21AM -0500, Anurup M wrote:
> 1) Device tree bindings for Hisilicon SoC PMU.
> 2) Add example for Hisilicon L3 cache and MN PMU.
> 3) Add child nodes of L3C and MN in djtag bindings example.
>
> Signed-off-by: Anurup M <anurup.m@huawei.com>
> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
> ---
> .../devicetree/bindings/arm/hisilicon/djtag.txt | 25 ++++++
> .../devicetree/bindings/arm/hisilicon/pmu.txt | 100 +++++++++++++++++++++
> 2 files changed, 125 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> index bbe8b45..653fdb7 100644
> --- a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> @@ -27,6 +27,31 @@ Example 1: Djtag for CPU die
> hisi-scl-id = <0x02>;
>
> /* All connecting components will appear as child nodes */
> +
> + pmul3c0 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x02>;
> + };
> +
> + pmul3c1 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x04>;
> + };
> +
> + pmul3c2 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x01>;
> + };
> +
> + pmul3c3 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x08>;
> + };
> +
> + pmumn0 {
> + compatible = "hisilicon,hip05-pmu-mn-v1";
> + hisi-module-id = <0x0b>;
> + };
> };
>
> Example 2: Djtag for IO die
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> new file mode 100644
> index 0000000..fceef8d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> @@ -0,0 +1,100 @@
> +Hisilicon SoC HiP05/06/07 ARMv8 PMU
> +===================================
> +
> +The Hisilicon SoC chips like HiP05/06/07 etc. consist of various independent
> +system device PMUs such as L3 cache (L3C) and Miscellaneous Nodes(MN). These
> +PMU devices are independent and have hardware logic to gather statistics and
> +performance information.
> +
> +HiSilicon SoC chip is encapsulated by multiple CPU and IO dies. The CPU die
> +is called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
> +in HiP05/06/07 chips are further grouped as CPU clusters (CCL) which includes
> +4 cpu-cores each.
> +e.g. In the case of HiP05/06/07, each SCCL has 1 L3 cache and 1 MN PMU device.
> +The L3 cache is further grouped as 4 L3 cache banks in a SCCL.
> +
> +The Hisilicon SoC PMU DT node bindings for uncore PMU devices are as below.
> +For PMU devices like L3 cache. MN etc. which are accessed using the djtag,
> +the parent node will be the djtag node of the corresponding CPU die (SCCL).
> +
> +L3 cache
> +---------
> +The L3 cache is dedicated for each SCCL. Each SCCL in HiP05/06/07 chips have 4
> +L3 cache banks. Each L3 cache bank have separate DT nodes.
> +
> +Required properties:
> +
> + - compatible : This value should be as follows
> + (a) "hisilicon,hip05-pmu-l3c-v1" for v1 hw in HiP05 chipset
> + (b) "hisilicon,hip06-pmu-l3c-v1" for v1 hw in HiP06 chipset
> + (c) "hisilicon,hip07-pmu-l3c-v2" for v2 hw in HiP07 chipset
> +
> + - hisi-module-id : This property is a combination of two values in the below order.
Vendor prefix: hisilicon,module-id
> + a) Module ID: The module identifier for djtag.
> + b) Instance or Bank ID: This will identify the L3 cache bank
> + or instance.
> +
> +Optional properties:
> +
> + - interrupt-parent : A phandle indicating which interrupt controller
> + this PMU signals interrupts to.
> +
> + - interrupts : Interrupt line used by this L3 cache bank.
> +
> + *The counter overflow IRQ is not supported in v1 hardware (HiP05/06).
> +
> +Miscellaneous Node
> +------------------
> +The MN is dedicated for each SCCL and hence there are separate DT nodes for MN
> +for each SCCL.
> +
> +Required properties:
> +
> + - compatible : This value should be as follows
> + (a) "hisilicon,hip05-pmu-mn-v1" for v1 hw in HiP05 chipset
> + (b) "hisilicon,hip06-pmu-mn-v1" for v1 hw in HiP06 chipset
> + (c) "hisilicon,hip07-pmu-mn-v2" for v2 hw in HiP07 chipset
> +
> + - hisi-module-id : Module ID to input for djtag.
ditto
> +
> +Optional properties:
> +
> + - interrupt-parent : A phandle indicating which interrupt controller
> + this PMU signals interrupts to.
> +
> + - interrupts : Interrupt line used by this PMU.
> +
> + *The counter overflow IRQ is not supported in v1 hardware (HiP05/06).
> +
> +Example:
> +
> + djtag0: djtag at 80010000 {
> + compatible = "hisilicon,hip05-djtag-v1";
> + reg = <0x0 0x80010000 0x0 0x10000>;
> + scl-id = <0x02>;
> +
> + pmul3c0 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x02>;
> + };
> +
> + pmul3c1 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x04>;
> + };
> +
> + pmul3c2 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x01>;
> + };
> +
> + pmul3c3 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x08>;
> + };
> +
> + pmumn0 {
> + compatible = "hisilicon,hip05-pmu-mn-v1";
> + hisi-module-id = <0x0b>;
> + };
> + };
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
From: Arnd Bergmann @ 2017-01-03 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483484256.13649.13.camel@tiscali.nl>
On Tuesday, January 3, 2017 11:57:36 PM CET Paul Bolle wrote:
> On Tue, 2017-01-03 at 23:25 +0100, Arnd Bergmann wrote:
> > As far as I'm concerned, we are totally fine as long as there exists a
> > longterm supported kernel that has i4l in drivers/staging.
>
> Or in drivers/isdn, right?
Right, I was assuming that we would first move it to staging and then
delete it, both at future points in time that we can debate. With the
existing longterm kernels that have i4l in drivers/isdn, the few remaining
users still have access to a supported kernel release until at least
2020.
Arnd
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Arnd Bergmann @ 2017-01-03 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103184444.GP6986@arm.com>
On Tuesday, January 3, 2017 6:44:44 PM CET Will Deacon wrote:
> > @@ -347,6 +348,16 @@ static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
> >
> > static int __swiotlb_dma_supported(struct device *hwdev, u64 mask)
> > {
> > +#ifdef CONFIG_PCI
> > + if (dev_is_pci(hwdev)) {
> > + struct pci_dev *pdev = to_pci_dev(hwdev);
> > + struct pci_host_bridge *br = pci_find_host_bridge(pdev->bus);
> > +
> > + if (br->dev.dma_mask && (*br->dev.dma_mask) &&
> > + (mask & (*br->dev.dma_mask)) != mask)
> > + return 0;
> > + }
> > +#endif
>
> Hmm, but this makes it look like the problem is both arm64 and swiotlb
> specific, when in reality it's not. Perhaps another hack you could try
> would be to register a PCI bus notifier in the host bridge looking for
> BUS_NOTIFY_BIND_DRIVER, then you could proxy the DMA ops for each child
> device before the driver has probed, but adding a dma_set_mask callback
> to limit the mask to what you need?
>
> I agree that it would be better if dma_set_mask handled all of this
> transparently, but it's all based on the underlying ops rather than the
> bus type.
This is what I prototyped a long time ago when this first came up.
I still think this needs to be solved properly for all of arm64, not
with a PCI specific hack, and in particular not using notifiers.
Arnd
commit 9a57d58d116800a535510053136c6dd7a9c26e25
Author: Arnd Bergmann <arnd@arndb.de>
Date: Tue Nov 17 14:06:55 2015 +0100
[EXPERIMENTAL] ARM64: check implement dma_set_mask
Needs work for coherent mask
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index 243ef256b8c9..a57e7bb10e71 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -22,6 +22,7 @@ struct dev_archdata {
void *iommu; /* private IOMMU data */
#endif
bool dma_coherent;
+ u64 parent_dma_mask;
};
struct pdev_archdata {
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 290a84f3351f..aa65875c611b 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -352,6 +352,31 @@ static int __swiotlb_dma_supported(struct device *hwdev, u64 mask)
return 1;
}
+static int __swiotlb_set_dma_mask(struct device *dev, u64 mask)
+{
+ /* device is not DMA capable */
+ if (!dev->dma_mask)
+ return -EIO;
+
+ /* mask is below swiotlb bounce buffer, so fail */
+ if (!swiotlb_dma_supported(dev, mask))
+ return -EIO;
+
+ /*
+ * because of the swiotlb, we can return success for
+ * larger masks, but need to ensure that bounce buffers
+ * are used above parent_dma_mask, so set that as
+ * the effective mask.
+ */
+ if (mask > dev->archdata.parent_dma_mask)
+ mask = dev->archdata.parent_dma_mask;
+
+
+ *dev->dma_mask = mask;
+
+ return 0;
+}
+
static struct dma_map_ops swiotlb_dma_ops = {
.alloc = __dma_alloc,
.free = __dma_free,
@@ -367,6 +392,7 @@ static struct dma_map_ops swiotlb_dma_ops = {
.sync_sg_for_device = __swiotlb_sync_sg_for_device,
.dma_supported = __swiotlb_dma_supported,
.mapping_error = swiotlb_dma_mapping_error,
+ .set_dma_mask = __swiotlb_set_dma_mask,
};
static int __init atomic_pool_init(void)
@@ -957,6 +983,18 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
if (!dev->archdata.dma_ops)
dev->archdata.dma_ops = &swiotlb_dma_ops;
+ /*
+ * we don't yet support buses that have a non-zero mapping.
+ * Let's hope we won't need it
+ */
+ WARN_ON(dma_base != 0);
+
+ /*
+ * Whatever the parent bus can set. A device must not set
+ * a DMA mask larger than this.
+ */
+ dev->archdata.parent_dma_mask = size;
+
dev->archdata.dma_coherent = coherent;
__iommu_setup_dma_ops(dev, dma_base, size, iommu);
}
^ permalink raw reply related
* linux-next: failure while fetching the mvebu tree
From: Gregory CLEMENT @ 2017-01-03 23:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104092825.296b903e@canb.auug.org.au>
Le 3 janvier 2017 23:28:25 GMT+01:00, Stephen Rothwell <sfr@canb.auug.org.au> a ?crit :
>Hi all,
>
>Fetching the mvebu tree produces this error:
>
>fatal: Couldn't find remote ref refs/heads/for-next
It should be fixed now.
Thanks,
Gregory
>
>--
>Cheers,
>Stephen Rothwell
Hi,
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 01/22] dt-bindings: iio: adc: add AXP20X/AXP22X ADC DT binding
From: Rob Herring @ 2017-01-03 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-2-quentin.schulz@free-electrons.com>
On Mon, Jan 02, 2017 at 05:37:01PM +0100, Quentin Schulz wrote:
> The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
> battery voltage, battery charge and discharge currents, AC-in and VBUS
> voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
>
> This adds the device tree binding documentation for the X-Powers AXP20X
> and AXP22X PMICs ADCs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> .../devicetree/bindings/iio/adc/axp20x_adc.txt | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt b/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
> new file mode 100644
> index 0000000..1b60065
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
> @@ -0,0 +1,24 @@
> +X-Powers AXP20X and AXP22X PMIC Analog to Digital Converter (ADC)
> +
> +The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
> +battery voltage, battery charge and discharge currents, AC-in and VBUS
> +voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
> +
> +The AXP22X PMICs do not have all ADCs of the AXP20X though.
> +
> +Required properties:
> + - compatible, one of:
> + "x-powers,axp209-adc"
> + "x-powers,axp221-adc"
> + - #io-channel-cells = <1>;
> +
> +This is a subnode of the AXP20X PMIC.
> +
> +Example:
> +
> +&axp209 {
> + axp209_adc: axp209_adc {
Use 'adc' for node name:
With that,
Acked-by: Rob Herring <robh@kernel.org>
> + compatible = "x-powers,axp209-adc";
> + #io-channel-cells = <1>;
> + };
> +};
> --
> 2.9.3
>
^ permalink raw reply
* [PATCHv6 00/11] CONFIG_DEBUG_VIRTUAL for arm64
From: Laura Abbott @ 2017-01-03 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <edc8eaa2-5414-506c-1dad-f2404ef19c81@gmail.com>
On 01/03/2017 02:56 PM, Florian Fainelli wrote:
> On 01/03/2017 09:21 AM, Laura Abbott wrote:
>> Happy New Year!
>>
>> This is a very minor rebase from v5. It only moves a few headers around.
>> I think this series should be ready to be queued up for 4.11.
>
> FWIW:
>
> Tested-by: Florian Fainelli <f.fainelli@gmail.com>
>
Thanks!
> How do we get this series included? I would like to get the ARM 32-bit
> counterpart included as well (will resubmit rebased shortly), but I have
> no clue which tree this should be going through.
>
I was assuming this would go through the arm64 tree unless Catalin/Will
have an objection to that.
> Thanks!
>
>>
>> Thanks,
>> Laura
>>
>> Laura Abbott (11):
>> lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
>> mm/cma: Cleanup highmem check
>> arm64: Move some macros under #ifndef __ASSEMBLY__
>> arm64: Add cast for virt_to_pfn
>> mm: Introduce lm_alias
>> arm64: Use __pa_symbol for kernel symbols
>> drivers: firmware: psci: Use __pa_symbol for kernel symbol
>> kexec: Switch to __pa_symbol
>> mm/kasan: Switch to using __pa_symbol and lm_alias
>> mm/usercopy: Switch to using lm_alias
>> arm64: Add support for CONFIG_DEBUG_VIRTUAL
>>
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/include/asm/kvm_mmu.h | 4 +-
>> arch/arm64/include/asm/memory.h | 66 +++++++++++++++++++++----------
>> arch/arm64/include/asm/mmu_context.h | 6 +--
>> arch/arm64/include/asm/pgtable.h | 2 +-
>> arch/arm64/kernel/acpi_parking_protocol.c | 3 +-
>> arch/arm64/kernel/cpu-reset.h | 2 +-
>> arch/arm64/kernel/cpufeature.c | 3 +-
>> arch/arm64/kernel/hibernate.c | 20 +++-------
>> arch/arm64/kernel/insn.c | 2 +-
>> arch/arm64/kernel/psci.c | 3 +-
>> arch/arm64/kernel/setup.c | 9 +++--
>> arch/arm64/kernel/smp_spin_table.c | 3 +-
>> arch/arm64/kernel/vdso.c | 8 +++-
>> arch/arm64/mm/Makefile | 2 +
>> arch/arm64/mm/init.c | 12 +++---
>> arch/arm64/mm/kasan_init.c | 22 +++++++----
>> arch/arm64/mm/mmu.c | 33 ++++++++++------
>> arch/arm64/mm/physaddr.c | 30 ++++++++++++++
>> arch/x86/Kconfig | 1 +
>> drivers/firmware/psci.c | 2 +-
>> include/linux/mm.h | 4 ++
>> kernel/kexec_core.c | 2 +-
>> lib/Kconfig.debug | 5 ++-
>> mm/cma.c | 15 +++----
>> mm/kasan/kasan_init.c | 15 +++----
>> mm/usercopy.c | 4 +-
>> 27 files changed, 180 insertions(+), 99 deletions(-)
>> create mode 100644 arch/arm64/mm/physaddr.c
>>
>
>
^ permalink raw reply
* Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Peter Senna Tschudin @ 2017-01-03 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103225127.jn36tatufdfz2k5q@rob-hp-laptop>
Hi Rob,
Thank you for the review.
On 03 January, 2017 23:51 CET, Rob Herring <robh@kernel.org> wrote:
> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote:
> > Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> > display bridge.
> >
> > Cc: Martyn Welch <martyn.welch@collabora.co.uk>
> > Cc: Martin Donnelly <martin.donnelly@ge.com>
> > Cc: Javier Martinez Canillas <javier@dowhile0.org>
> > Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> > Cc: Philipp Zabel <p.zabel@pengutronix.de>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
> > ---
> > There was an Acked-by from Rob Herring <robh@kernel.org> for V6, but I changed
> > the bindings to use i2c_new_secondary_device() so I removed it from the commit
> > message.
> >
> > .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 ++++++++++++++++++++++
>
> Generally, bindings are not organized by vendor. Put in
> bindings/display/bridge/... instead.
Will change that.
>
> > 1 file changed, 39 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> > new file mode 100644
> > index 0000000..1bc6ebf
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> > @@ -0,0 +1,39 @@
> > +Driver for GE B850v3 LVDS/DP++ display bridge
> > +
> > +Required properties:
> > + - compatible : should be "ge,b850v3-lvds-dp".
>
> Isn't '-lvds-dp' redundant? The part# should be enough.
b850v3 is the name of the product, this is why the proposed name. What about, b850v3-dp2 dp2 indicating the second DP output?
>
> > + - reg : should contain the main address which is used to ack the
> > + interrupts and address for edid.
> > + - reg-names : comma separeted list of register names. Valid values
>
> s/separeted/separated/
argh, sorry for this. Will fix it.
>
> > + are "main", and "edid".
> > + - interrupt-parent : phandle of the interrupt controller that services
> > + interrupts to the device
> > + - interrupts : one interrupt should be described here, as in
> > + <0 IRQ_TYPE_LEVEL_HIGH>.
> > + - port : should describe the video signal connection between the host
> > + and the bridge.
> > +
> > +Example:
> > +
> > +&mux2_i2c2 {
> > + status = "okay";
> > + clock-frequency = <100000>;
> > +
> > + b850v3-lvds-dp-bridge at 73 {
> > + compatible = "ge,b850v3-lvds-dp";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + reg = <0x73 0x72>;
> > + reg-names = "main", "edid";
> > +
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + port {
> > + b850v3_dp_bridge_in: endpoint {
> > + remote-endpoint = <&lvds0_out>;
> > + };
> > + };
> > + };
> > +};
> > --
> > 2.5.5
> >
^ permalink raw reply
* [PATCH v2] soc: ti: Drop wait from wkup_m3_rproc_boot_thread
From: Sarangdhar Joshi @ 2017-01-03 23:41 UTC (permalink / raw)
To: linux-arm-kernel
The function wkup_m3_rproc_boot_thread waits for
asynchronous firmware loading to parse the resource table
before calling rproc_boot(). However, as the resource table
parsing has been moved to rproc_boot(), there's no need to
wait for the asynchronous firmware loading completion.
So, drop this.
CC: Dave Gerlach <d-gerlach@ti.com>
CC: Suman Anna <s-anna@ti.com>
CC: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
This patch seems to be doing an independent clean up now. Hence
removing it from the series.
drivers/soc/ti/wkup_m3_ipc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
index 8823cc8..8bfa44b 100644
--- a/drivers/soc/ti/wkup_m3_ipc.c
+++ b/drivers/soc/ti/wkup_m3_ipc.c
@@ -370,8 +370,6 @@ static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc)
struct device *dev = m3_ipc->dev;
int ret;
- wait_for_completion(&m3_ipc->rproc->firmware_loading_complete);
-
init_completion(&m3_ipc->sync_complete);
ret = rproc_boot(m3_ipc->rproc);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 1/2] soc: ti: Use remoteproc auto_boot feature
From: Sarangdhar Joshi @ 2017-01-03 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6a5a9c8a-cca7-0740-4879-dd6c01e60548@ti.com>
On 12/23/2016 03:57 PM, Suman Anna wrote:
> On 12/23/2016 11:05 AM, Suman Anna wrote:
>> Hi Sarang,
>>
>>>>
>>>> On 12/15/2016 06:03 PM, Sarangdhar Joshi wrote:
>>>>> The function wkup_m3_rproc_boot_thread waits for asynchronous
>>>>> firmware loading to complete successfully before calling
>>>>> rproc_boot(). The same can be achieved by just setting
>>>>> rproc->auto_boot flag. Change this. As a result this change
>>>>> removes wkup_m3_rproc_boot_thread and moves m3_ipc->sync_complete
>>>>> initialization to the wkup_m3_ipc_probe().
>>>>>
>>>>> Other than the current usage, the firmware_loading_complete is
>>>>> only used in rproc_del() where it's no longer needed. This
>>>>> change is in preparation for removing firmware_loading_complete
>>>>> completely.
>>>>
>>>> Based on the comments so far, I am assuming that you are dropping this
>>>> series.
>>>
>>> No, may not be dropping this. Will try to handle it differently in
>>> rproc_del() (probably by making use of some state flag).
>>>>
>>>> In any case, this series did break our PM stack. We definitely don't
>>>> want to auto-boot the wkup_m3_rproc device, that responsibility will
>>>> need to stay with the wkup_m3_ipc driver.
>>>
>>> Which scenario did it break? Booting up rproc device before
>>> wkup_m3_ipc_probe() causes issues?
>>
>> Yes, our state machine requires the wkup_m3_ipc driver to control the
>> boot of the wkup_m3 remoteproc. The wkup_m3 is not a typical remoteproc,
>> it is our PM master and is responsible for putting the host processor
>> into suspend and waking it up in system suspend/cpuidle paths.
>> The remoteproc infrastructure is only used for load/boot, but the Linux
>> PM state machine and communication is all controlled by the wkup_m3_ipc
>> driver.
Thanks for explaining. I was missing the fact that the resource table
parsing during asynchronous call and the one in rproc_boot() are
different.
>>
>>>
>>> Nevertheless, I think Bjorn's suggestion of just dropping the call to
>>> wait_for_completion() and keeping kthread looks good, also because of
>>> the fact that rproc_boot() anyways calls request_firmware() and no
>>> longer needed to wait on asynchronous loading of firmware.
>>
>> Yeah, I will have to test this, but looking at current code, this should
>> mostly be ok because of the remoteproc core changes w.r.t resource table
>> parsing.
>
> Tested with just the wait_for_completion() removed and it works fine. I
> can send a patch for the same if you prefer me to send it.
Thanks for testing it. I have sent the patch.
Regards,
Sarang
>
> regards
> Suman
>
>>
>> regards
>> Suman
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v5 1/4] soc: zte: Add header for PM domains specifiers
From: Baoyou Xie @ 2017-01-04 0:19 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds header with values used for ZTE 2967
SoC's power domain driver.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: Shawn Guo <shawn.guo@linaro.org>
---
include/dt-bindings/soc/zte,pm_domains.h | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 include/dt-bindings/soc/zte,pm_domains.h
diff --git a/include/dt-bindings/soc/zte,pm_domains.h b/include/dt-bindings/soc/zte,pm_domains.h
new file mode 100644
index 0000000..01e9abc
--- /dev/null
+++ b/include/dt-bindings/soc/zte,pm_domains.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#ifndef _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
+#define _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
+
+#define DM_ZX296718_SAPPU 0
+#define DM_ZX296718_VDE 1 /* g1v6 */
+#define DM_ZX296718_VCE 2 /* h1v6 */
+#define DM_ZX296718_HDE 3 /* g2v2 */
+#define DM_ZX296718_VIU 4
+#define DM_ZX296718_USB20 5
+#define DM_ZX296718_USB21 6
+#define DM_ZX296718_USB30 7
+#define DM_ZX296718_HSIC 8
+#define DM_ZX296718_GMAC 9
+#define DM_ZX296718_TS 10
+#define DM_ZX296718_VOU 11
+
+#endif /* _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/4] soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family
From: Baoyou Xie @ 2017-01-04 0:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483489157-10782-1-git-send-email-baoyou.xie@linaro.org>
The ARMv8 zx2967 family (296718, 296716 etc) uses different value
for controlling the power domain on/off registers, Choose the
value depending on the compatible.
Multiple domains are prepared for the family, this patch prepares
the common functions.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: Shawn Guo <shawnguo@kernel.org>
Reviewed-by: Jun Nie <jun.nie@linaro.org>
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/zte/Kconfig | 13 ++++
drivers/soc/zte/Makefile | 4 ++
drivers/soc/zte/zx2967_pm_domains.c | 139 ++++++++++++++++++++++++++++++++++++
drivers/soc/zte/zx2967_pm_domains.h | 46 ++++++++++++
6 files changed, 204 insertions(+)
create mode 100644 drivers/soc/zte/Kconfig
create mode 100644 drivers/soc/zte/Makefile
create mode 100644 drivers/soc/zte/zx2967_pm_domains.c
create mode 100644 drivers/soc/zte/zx2967_pm_domains.h
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index f31bceb..f09023f 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -11,5 +11,6 @@ source "drivers/soc/tegra/Kconfig"
source "drivers/soc/ti/Kconfig"
source "drivers/soc/ux500/Kconfig"
source "drivers/soc/versatile/Kconfig"
+source "drivers/soc/zte/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 50c23d0..05eae52 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_SOC_TI) += ti/
obj-$(CONFIG_ARCH_U8500) += ux500/
obj-$(CONFIG_PLAT_VERSATILE) += versatile/
+obj-$(CONFIG_ARCH_ZX) += zte/
diff --git a/drivers/soc/zte/Kconfig b/drivers/soc/zte/Kconfig
new file mode 100644
index 0000000..20bde38
--- /dev/null
+++ b/drivers/soc/zte/Kconfig
@@ -0,0 +1,13 @@
+#
+# ZTE SoC drivers
+#
+menuconfig SOC_ZTE
+ bool "ZTE SoC driver support"
+
+if SOC_ZTE
+
+config ZX2967_PM_DOMAINS
+ bool "ZX2967 PM domains"
+ depends on PM_GENERIC_DOMAINS
+
+endif
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
new file mode 100644
index 0000000..8a37f2f
--- /dev/null
+++ b/drivers/soc/zte/Makefile
@@ -0,0 +1,4 @@
+#
+# ZTE SOC drivers
+#
+obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
diff --git a/drivers/soc/zte/zx2967_pm_domains.c b/drivers/soc/zte/zx2967_pm_domains.c
new file mode 100644
index 0000000..a215875
--- /dev/null
+++ b/drivers/soc/zte/zx2967_pm_domains.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of.h>
+
+#include "zx2967_pm_domains.h"
+
+#define PCU_DM_CLKEN(zpd) ((zpd)->reg_offset[REG_CLKEN])
+#define PCU_DM_ISOEN(zpd) ((zpd)->reg_offset[REG_ISOEN])
+#define PCU_DM_RSTEN(zpd) ((zpd)->reg_offset[REG_RSTEN])
+#define PCU_DM_PWREN(zpd) ((zpd)->reg_offset[REG_PWREN])
+#define PCU_DM_PWRDN(zpd) ((zpd)->reg_offset[REG_PWRDN])
+#define PCU_DM_ACK_SYNC(zpd) ((zpd)->reg_offset[REG_ACK_SYNC])
+
+static void __iomem *pcubase;
+
+int zx2967_power_on(struct generic_pm_domain *domain)
+{
+ struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ if (zpd->polarity == PWREN)
+ val |= BIT(zpd->bit);
+ else
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
+
+ do {
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
+ & BIT(zpd->bit);
+ } while (--loop && !val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
+ udelay(5);
+
+ pr_debug("normal poweron %s\n", domain->name);
+
+ return 0;
+}
+
+int zx2967_power_off(struct generic_pm_domain *domain)
+{
+ struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ if (zpd->polarity == PWREN)
+ val &= ~BIT(zpd->bit);
+ else
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
+
+ do {
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
+ & BIT(zpd->bit);
+ } while (--loop && val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ pr_debug("normal poweroff %s\n", domain->name);
+
+ return 0;
+}
+
+int zx2967_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num)
+{
+ struct genpd_onecell_data *genpd_data;
+ struct resource *res;
+ int i;
+
+ genpd_data = devm_kzalloc(&pdev->dev, sizeof(*genpd_data), GFP_KERNEL);
+ if (!genpd_data)
+ return -ENOMEM;
+
+ genpd_data->domains = zx_pm_domains;
+ genpd_data->num_domains = domain_num;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ pcubase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(pcubase)) {
+ dev_err(&pdev->dev, "ioremap fail.\n");
+ return PTR_ERR(pcubase);
+ }
+
+ for (i = 0; i < domain_num; ++i)
+ pm_genpd_init(zx_pm_domains[i], NULL, false);
+
+ of_genpd_add_provider_onecell(pdev->dev.of_node, genpd_data);
+ dev_info(&pdev->dev, "powerdomain init ok\n");
+ return 0;
+}
diff --git a/drivers/soc/zte/zx2967_pm_domains.h b/drivers/soc/zte/zx2967_pm_domains.h
new file mode 100644
index 0000000..81ad4d6
--- /dev/null
+++ b/drivers/soc/zte/zx2967_pm_domains.h
@@ -0,0 +1,46 @@
+/*
+ * Header for ZTE's Power Domain Driver support
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#ifndef __ZTE_ZX2967_PM_DOMAIN_H
+#define __ZTE_ZX2967_PM_DOMAIN_H
+
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+
+enum {
+ REG_CLKEN,
+ REG_ISOEN,
+ REG_RSTEN,
+ REG_PWREN,
+ REG_PWRDN,
+ REG_ACK_SYNC,
+
+ /* The size of the array - must be last */
+ REG_ARRAY_SIZE,
+};
+
+enum zx2967_power_polarity {
+ PWREN,
+ PWRDN,
+};
+
+struct zx2967_pm_domain {
+ struct generic_pm_domain dm;
+ const u16 bit;
+ const enum zx2967_power_polarity polarity;
+ const u16 *reg_offset;
+};
+
+extern int zx2967_power_on(struct generic_pm_domain *domain);
+extern int zx2967_power_off(struct generic_pm_domain *domain);
+extern int zx2967_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num);
+
+#endif /* __ZTE_ZX2967_PM_DOMAIN_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v5 3/4] soc: zte: pm_domains: Add support for zx296718 board
From: Baoyou Xie @ 2017-01-04 0:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483489157-10782-1-git-send-email-baoyou.xie@linaro.org>
This patch introduces the power domain driver of zx296718
which belongs to zte's zx2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: Shawn Guo <shawnguo@kernel.org>
Reviewed-by: Jun Nie <jun.nie@linaro.org>
---
drivers/soc/zte/Makefile | 2 +-
drivers/soc/zte/zx296718_pm_domains.c | 194 ++++++++++++++++++++++++++++++++++
2 files changed, 195 insertions(+), 1 deletion(-)
create mode 100644 drivers/soc/zte/zx296718_pm_domains.c
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
index 8a37f2f..f399553 100644
--- a/drivers/soc/zte/Makefile
+++ b/drivers/soc/zte/Makefile
@@ -1,4 +1,4 @@
#
# ZTE SOC drivers
#
-obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
+obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o zx296718_pm_domains.o
diff --git a/drivers/soc/zte/zx296718_pm_domains.c b/drivers/soc/zte/zx296718_pm_domains.c
new file mode 100644
index 0000000..626e6ce
--- /dev/null
+++ b/drivers/soc/zte/zx296718_pm_domains.c
@@ -0,0 +1,194 @@
+/*
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#include <dt-bindings/soc/zte,pm_domains.h>
+#include "zx2967_pm_domains.h"
+
+static u16 zx296718_offsets[REG_ARRAY_SIZE] = {
+ [REG_CLKEN] = 0x18,
+ [REG_ISOEN] = 0x1c,
+ [REG_RSTEN] = 0x20,
+ [REG_PWREN] = 0x24,
+ [REG_ACK_SYNC] = 0x28,
+};
+
+enum {
+ PCU_DM_VOU = 0,
+ PCU_DM_SAPPU,
+ PCU_DM_VDE,
+ PCU_DM_VCE,
+ PCU_DM_HDE,
+ PCU_DM_VIU,
+ PCU_DM_USB20,
+ PCU_DM_USB21,
+ PCU_DM_USB30,
+ PCU_DM_HSIC,
+ PCU_DM_GMAC,
+ PCU_DM_TS,
+};
+
+static struct zx2967_pm_domain vou_domain = {
+ .dm = {
+ .name = "vou_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_VOU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain sappu_domain = {
+ .dm = {
+ .name = "sappu_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_SAPPU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain vde_domain = {
+ .dm = {
+ .name = "vde_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_VDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain vce_domain = {
+ .dm = {
+ .name = "vce_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_VCE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain hde_domain = {
+ .dm = {
+ .name = "hde_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_HDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain viu_domain = {
+ .dm = {
+ .name = "viu_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_VIU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain usb20_domain = {
+ .dm = {
+ .name = "usb20_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_USB20,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain usb21_domain = {
+ .dm = {
+ .name = "usb21_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_USB21,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain usb30_domain = {
+ .dm = {
+ .name = "usb30_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_USB30,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain hsic_domain = {
+ .dm = {
+ .name = "hsic_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_HSIC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain gmac_domain = {
+ .dm = {
+ .name = "gmac_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_GMAC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain ts_domain = {
+ .dm = {
+ .name = "ts_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_TS,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+struct generic_pm_domain *zx296718_pm_domains[] = {
+ [DM_ZX296718_SAPPU] = &sappu_domain.dm,
+ [DM_ZX296718_VDE] = &vde_domain.dm,
+ [DM_ZX296718_VCE] = &vce_domain.dm,
+ [DM_ZX296718_HDE] = &hde_domain.dm,
+ [DM_ZX296718_VIU] = &viu_domain.dm,
+ [DM_ZX296718_USB20] = &usb20_domain.dm,
+ [DM_ZX296718_USB21] = &usb21_domain.dm,
+ [DM_ZX296718_USB30] = &usb30_domain.dm,
+ [DM_ZX296718_HSIC] = &hsic_domain.dm,
+ [DM_ZX296718_GMAC] = &gmac_domain.dm,
+ [DM_ZX296718_TS] = &ts_domain.dm,
+ [DM_ZX296718_VOU] = &vou_domain.dm,
+};
+
+static int zx296718_pd_probe(struct platform_device *pdev)
+{
+ return zx2967_pd_probe(pdev,
+ zx296718_pm_domains,
+ ARRAY_SIZE(zx296718_pm_domains));
+}
+
+static const struct of_device_id zx296718_pm_domain_matches[] = {
+ { .compatible = "zte,zx296718-pcu", },
+ { },
+};
+
+static struct platform_driver zx296718_pd_driver = {
+ .driver = {
+ .name = "zx-powerdomain",
+ .owner = THIS_MODULE,
+ .of_match_table = zx296718_pm_domain_matches,
+ },
+ .probe = zx296718_pd_probe,
+};
+
+static int __init zx296718_pd_init(void)
+{
+ return platform_driver_register(&zx296718_pd_driver);
+}
+subsys_initcall(zx296718_pd_init);
--
2.7.4
^ permalink raw reply related
* [PATCH v5 4/4] MAINTAINERS: add zx2967 SoC drivers to ARM ZTE architecture
From: Baoyou Xie @ 2017-01-04 0:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483489157-10782-1-git-send-email-baoyou.xie@linaro.org>
Add the ZTE SoC drivers as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
By the way, this patch adds the maintainer for ARM
ZTE architecture to Baoyou Xie.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ad199da..64f04df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1975,12 +1975,16 @@ F: arch/arm/mach-pxa/include/mach/z2.h
ARM/ZTE ARCHITECTURE
M: Jun Nie <jun.nie@linaro.org>
+M: Baoyou Xie <baoyou.xie@linaro.org>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-zx/
F: drivers/clk/zte/
+F: drivers/soc/zte/
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
+F: Documentation/devicetree/bindings/soc/zte/
+F: include/dt-bindings/soc/zx*.h
ARM/ZYNQ ARCHITECTURE
M: Michal Simek <michal.simek@xilinx.com>
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: sun50i: add MMC nodes
From: André Przywara @ 2017-01-04 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65GAvyDn1oMXy2cpOD5PFRoYYOk-VbsMPAX3SNFz2ukLg@mail.gmail.com>
On 03/01/17 13:28, Chen-Yu Tsai wrote:
> On Tue, Jan 3, 2017 at 6:48 PM, Andr? Przywara <andre.przywara@arm.com> wrote:
>> On 03/01/17 02:52, Chen-Yu Tsai wrote:
Hi Chen-Yu,
>>> On Tue, Jan 3, 2017 at 7:03 AM, Andre Przywara <andre.przywara@arm.com> wrote:
>>>
>>> A commit message explaining the mmc controllers would be nice.
>>
>> OK.
>>
>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>> ---
>>>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 67 +++++++++++++++++++++++++++
>>>> 1 file changed, 67 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> index e0dcab8..c680566 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> @@ -150,6 +150,32 @@
>>>> pins = "PB8", "PB9";
>>>> function = "uart0";
>>>> };
>>>> +
>>>> + mmc0_pins: mmc0 at 0 {
>>>> + pins = "PF0", "PF1", "PF2", "PF3", "PF4", "PF5";
>>>> + function = "mmc0";
>>>> + drive-strength = <30>;
>>>> + };
>>>> +
>>>> + mmc0_default_cd_pin: mmc0_cd_pin at 0 {
>>>> + pins = "PF6";
>>>> + function = "gpio_in";
>>>> + bias-pull-up;
>>>> + };
>>>
>>> We are starting to drop pinmux nodes for gpio usage.
>>
>> And replacing them with what?
>> Or do you mean they go in the individual board .dts files?
>> In this case I believe having a default pin defined here would help to
>> define it in every .dts.
>
> Nope. I meant dropping them. Pinmux and gpio are orthogonal. One should not
> need to specify a gpio pinmux to use it as a gpio. We added them because in
> the past nothing was preventing someone from claiming an already muxed pin
> as a gpio. On some platforms this is fine. For sunxi, this breaks the system,
> as the gpio functions are muxed in.
>
> The idea moving forward is that these cases should be guarded in the driver.
Ah, OK, you mean just referencing the pin like:
cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
in the board DT is enough? And the driver claiming it will (eventually?)
prevent users from using them via the sysfs interface then?
> Of course we would have to deal with existing dtbs, but lets not add any more.
>
>>>> +
>>>> + mmc1_pins: mmc1 at 0 {
>>>> + pins = "PG0", "PG1", "PG2", "PG3", "PG4", "PG5";
>>>> + function = "mmc1";
>>>> + drive-strength = <30>;
>>>> + };
>>>> +
>>>> + mmc2_pins: mmc2 at 0 {
>>>> + pins = "PC1", "PC5", "PC6", "PC8", "PC9",
>>>> + "PC10", "PC11", "PC12", "PC13", "PC14",
>>>> + "PC15", "PC16";
>>>> + function = "mmc2";
>>>> + drive-strength = <30>;
>>>> + };
>>>
>>> Moreover I think you should split out the pinmux nodes to a separate patch.
>>
>> I can surely do, just wondering what's the rationale is behind that?
>
> More or less the "do one thing in one patch" rationale. Of course you can
> claim these are the defaults used in the reference design and pretty much
> every board out there. Then it makes sense to do them together. :)
Mmmh, probably a misunderstanding, but:
Those pins are the possible pins that expose the MMC interface. Those
nodes here name them to allow easy and concise reference by a board DT
(as in the following patch).
And in fact in case of the A64 there are _no_ alternative muxes for the
three MMC controllers: SDC0 is only on PF0-5, SDC1 on PG0-PG5 and SDC2
on PC1-PC16.
So it's not a board design question, apart from using a controller or not.
That's why I rather keep them together with the MMC controller nodes.
>>>
>>>> };
>>>>
>>>> uart0: serial at 1c28000 {
>>>> @@ -240,6 +266,47 @@
>>>> #size-cells = <0>;
>>>> };
>>>>
>>>> + mmc0: mmc at 1c0f000 {
>>>> + compatible = "allwinner,sun50i-a64-mmc",
>>>> + "allwinner,sun5i-a13-mmc";
>>>
>>> Given that sun5i doesn't support mmc delay timings, and the A64 has
>>> calibration and delay timings, I wouldn't call them compatible.
>>>
>>> Or are you claiming that for the A64 has a delay of 0 for the
>>> currently supported speeds, so the calibration doesn't really
>>> matter? If so this should be mentioned in the commit message.
>>
>> Yes, that's my observation: Driving it with sun5-a13-mmc just works.
>> This sun5i driver version does not (and will never) support higher
>> transfer modes anyway, so for that subset they are compatible. This
>> opens up the door to other operating systems not having a particular
>> driver for the A64, for instance, also older Linux kernels.
>> I know that sunxi doesn't use this compatible feature much, but IMHO we
>> should really start thinking about the DT not just being Linux specific
>> - or even being specific to a certain Linux version. And this case here
>> is a good example: An A13 MMC driver can drive this device - if there is
>> no better driver (an A64 one) available.
>
> Cool. Please put this in the commit log. :)
Noted for a repost.
>>
>>>
>>>> + reg = <0x01c0f000 0x1000>;
>>>> + clocks = <&ccu 31>, <&ccu 75>;
>>>
>>> The clock / reset index macros are in the tree now.
>>> Please switch to them.
>>
>> The include file is in the tree, but it isn't used in the current HEAD
>> (as in #included and the actual macros being used in the .dtsi).
>> So I was wondering if there is a patch pending for that?
>
> Not yet I think. Perhaps Maxime will do one once he gets back from vacation?
Seems like everybody hopes for it and nobody bothers with this rather
trivial patch ;-)
Frankly I am not overly keen on having all those defines in the DTs,
which rely on a bunch of include files scattered over the Linux include
tree. This makes it unnecessarily complicated to compile this out of
tree or move it over to some other piece of software (other OS, U-Boot).
Also it gives people the impression that it's fine to change the
definition in the include file at will (because it looks like Linux
territory).
Eventually some file has to hold the actual hardware information, I
don't see why this shouldn't be the one .dtsi file. Reading that the
clock for MMC controller 0 is MMC0_CLK isn't very informative.
Cheers,
Andre.
>>>> + clock-names = "ahb", "mmc";
>>>> + resets = <&ccu 8>;
>>>> + reset-names = "ahb";
>>>> + interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
>>>> + status = "disabled";
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + };
>>>> +
>>>> + mmc1: mmc at 1c10000 {
>>>> + compatible = "allwinner,sun50i-a64-mmc",
>>>> + "allwinner,sun5i-a13-mmc";
>>>> + reg = <0x01c10000 0x1000>;
>>>> + clocks = <&ccu 32>, <&ccu 76>;
>>>> + clock-names = "ahb", "mmc";
>>>> + resets = <&ccu 9>;
>>>> + reset-names = "ahb";
>>>> + interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
>>>> + status = "disabled";
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + };
>>>> +
>>>> + mmc2: mmc at 1c11000 {
>>>> + compatible = "allwinner,sun50i-a64-emmc";
>>>> + reg = <0x01c11000 0x1000>;
>>>> + clocks = <&ccu 33>, <&ccu 77>;
>>>> + clock-names = "ahb", "mmc";
>>>> + resets = <&ccu 10>;
>>>> + reset-names = "ahb";
>>>> + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
>>>> + status = "disabled";
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + };
>>>> +
>>>> gic: interrupt-controller at 1c81000 {
>>>> compatible = "arm,gic-400";
>>>> reg = <0x01c81000 0x1000>,
>>>> --
>>>> 2.8.2
>>>>
>>
^ permalink raw reply
* [PATCH 2/4] ARM: dts: Add am335x-boneblack-wireless
From: Tony Lindgren @ 2017-01-04 0:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+T6QPnTS-XyV0G9X78hAh=D79TkZkU+evN2RA6VF3f_jyBtkA@mail.gmail.com>
* Jason Kridner <jkridner@gmail.com> [170103 12:58]:
> Asked-by: Jason Kridner <jdk@ti.com>
>
> Sorry for the phone mailer (HTML).
OK fixed that to Acked-by :) Applied into omap-for-v4.11/dt and pushed
out.
BBB Green Wireless seems to work nicely for WLAN out of the box with
these patches :)
Regards,
Tony
^ permalink raw reply
* [PATCH 1/2] arm: Cleanup sanity_check_meminfo
From: Nicolas Pitre @ 2017-01-04 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483477010-18986-2-git-send-email-labbott@redhat.com>
On Tue, 3 Jan 2017, Laura Abbott wrote:
>
> The logic for sanity_check_meminfo has become difficult to
> follow. Clean up the code so it's more obvious what the code
> is actually trying to do.
Absolutely. This function has a long history of subtle bugs ... and
broken fixes.
> + if (reg->base < vmalloc_limit) {
> + if (block_end > arm_lowmem_limit)
> + arm_lowmem_limit = min(
> + (phys_addr_t)vmalloc_limit,
> + block_end);
Just to illustrate how subtle this can be, the above would reintroduce a
bug that was fixed in commit b9a019899f.
Nicolas
^ permalink raw reply
* [PATCH v5 0/4] ARM: Add support for CONFIG_DEBUG_VIRTUAL
From: Florian Fainelli @ 2017-01-04 1:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <edc8eaa2-5414-506c-1dad-f2404ef19c81@gmail.com>
This patch series builds on top of Laura's [PATCHv6 00/10] CONFIG_DEBUG_VIRTUAL
for arm64 to add support for CONFIG_DEBUG_VIRTUAL for ARM.
This was tested on a Brahma B15 platform (ARMv7 + HIGHMEM + LPAE).
Note that the treewide changes would involve a huge CC list, which
is why it has been purposely trimmed to just focusing on the DEBUG_VIRTUAL
aspect.
Catalin, provided that you take Laura's series, I suppose I would submit
this one through Russell's patch system if that's okay with everyone?
Thanks!
Changes in v5:
- rebased against Laura's [PATCHv6 00/10] CONFIG_DEBUG_VIRTUAL
for arm64 and v4.10-rc2
- added Russell's acked-by for patches 2 through 4
Changes in v4:
- added Boris' ack for the first patch
- reworked the virtual address check based on Laura's suggestion to
make the code more readable
Changes in v3:
- fix build failures reported by Kbuild test robot
Changes in v2:
- Modified MTD LART driver not to create symbol conflicts with
KERNEL_START
- Fixed patch that defines and uses KERNEL_START/END
- Fixed __pa_symbol()'s definition
- Inline __pa_symbol() check wihtin the VIRTUAL_BUG_ON statement
- Simplified check for virtual addresses
- Added a tree-wide patch changing SMP/PM implementations to use
__pa_symbol(), build tested against multi_v{5,7}_defconfig
Florian Fainelli (4):
mtd: lart: Rename partition defines to be prefixed with PART_
ARM: Define KERNEL_START and KERNEL_END
ARM: Add support for CONFIG_DEBUG_VIRTUAL
ARM: treewide: Replace uses of virt_to_phys with __pa_symbol
arch/arm/Kconfig | 1 +
arch/arm/common/mcpm_entry.c | 12 +++----
arch/arm/include/asm/memory.h | 23 +++++++++++--
arch/arm/mach-alpine/platsmp.c | 2 +-
arch/arm/mach-axxia/platsmp.c | 2 +-
arch/arm/mach-bcm/bcm63xx_smp.c | 2 +-
arch/arm/mach-bcm/platsmp-brcmstb.c | 2 +-
arch/arm/mach-bcm/platsmp.c | 4 +--
arch/arm/mach-berlin/platsmp.c | 2 +-
arch/arm/mach-exynos/firmware.c | 4 +--
arch/arm/mach-exynos/mcpm-exynos.c | 2 +-
arch/arm/mach-exynos/platsmp.c | 4 +--
arch/arm/mach-exynos/pm.c | 6 ++--
arch/arm/mach-exynos/suspend.c | 6 ++--
arch/arm/mach-hisi/platmcpm.c | 2 +-
arch/arm/mach-hisi/platsmp.c | 6 ++--
arch/arm/mach-imx/platsmp.c | 2 +-
arch/arm/mach-imx/pm-imx6.c | 2 +-
arch/arm/mach-imx/src.c | 2 +-
arch/arm/mach-mediatek/platsmp.c | 2 +-
arch/arm/mach-mvebu/pm.c | 2 +-
arch/arm/mach-mvebu/pmsu.c | 2 +-
arch/arm/mach-mvebu/system-controller.c | 2 +-
arch/arm/mach-omap2/control.c | 8 ++---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 12 +++----
arch/arm/mach-omap2/omap-smp.c | 4 +--
arch/arm/mach-prima2/platsmp.c | 2 +-
arch/arm/mach-prima2/pm.c | 2 +-
arch/arm/mach-pxa/palmz72.c | 2 +-
arch/arm/mach-pxa/pxa25x.c | 2 +-
arch/arm/mach-pxa/pxa27x.c | 2 +-
arch/arm/mach-pxa/pxa3xx.c | 2 +-
arch/arm/mach-realview/platsmp-dt.c | 2 +-
arch/arm/mach-rockchip/platsmp.c | 4 +--
arch/arm/mach-rockchip/pm.c | 2 +-
arch/arm/mach-s3c24xx/mach-jive.c | 2 +-
arch/arm/mach-s3c24xx/pm-s3c2410.c | 2 +-
arch/arm/mach-s3c24xx/pm-s3c2416.c | 2 +-
arch/arm/mach-s3c64xx/pm.c | 2 +-
arch/arm/mach-s5pv210/pm.c | 2 +-
arch/arm/mach-sa1100/pm.c | 2 +-
arch/arm/mach-shmobile/platsmp-apmu.c | 6 ++--
arch/arm/mach-shmobile/platsmp-scu.c | 4 +--
arch/arm/mach-socfpga/platsmp.c | 4 +--
arch/arm/mach-spear/platsmp.c | 2 +-
arch/arm/mach-sti/platsmp.c | 2 +-
arch/arm/mach-sunxi/platsmp.c | 4 +--
arch/arm/mach-tango/platsmp.c | 2 +-
arch/arm/mach-tango/pm.c | 2 +-
arch/arm/mach-tegra/reset.c | 4 +--
arch/arm/mach-ux500/platsmp.c | 2 +-
arch/arm/mach-vexpress/dcscb.c | 2 +-
arch/arm/mach-vexpress/platsmp.c | 2 +-
arch/arm/mach-vexpress/tc2_pm.c | 4 +--
arch/arm/mach-zx/platsmp.c | 4 +--
arch/arm/mach-zynq/platsmp.c | 2 +-
arch/arm/mm/Makefile | 1 +
arch/arm/mm/init.c | 7 ++--
arch/arm/mm/mmu.c | 6 +---
arch/arm/mm/physaddr.c | 55 +++++++++++++++++++++++++++++++
drivers/mtd/devices/lart.c | 24 +++++++-------
61 files changed, 179 insertions(+), 110 deletions(-)
create mode 100644 arch/arm/mm/physaddr.c
--
2.9.3
^ permalink raw reply
* [PATCH v5 1/4] mtd: lart: Rename partition defines to be prefixed with PART_
From: Florian Fainelli @ 2017-01-04 1:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104011417.1496-1-f.fainelli@gmail.com>
In preparation for defining KERNEL_START on ARM, rename KERNEL_START to
PART_KERNEL_START, and to be consistent, do this for all
partition-related constants.
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/mtd/devices/lart.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/devices/lart.c b/drivers/mtd/devices/lart.c
index 82bd00af5cc3..268aae45b514 100644
--- a/drivers/mtd/devices/lart.c
+++ b/drivers/mtd/devices/lart.c
@@ -75,18 +75,18 @@ static char module_name[] = "lart";
/* blob */
#define NUM_BLOB_BLOCKS FLASH_NUMBLOCKS_16m_PARAM
-#define BLOB_START 0x00000000
-#define BLOB_LEN (NUM_BLOB_BLOCKS * FLASH_BLOCKSIZE_PARAM)
+#define PART_BLOB_START 0x00000000
+#define PART_BLOB_LEN (NUM_BLOB_BLOCKS * FLASH_BLOCKSIZE_PARAM)
/* kernel */
#define NUM_KERNEL_BLOCKS 7
-#define KERNEL_START (BLOB_START + BLOB_LEN)
-#define KERNEL_LEN (NUM_KERNEL_BLOCKS * FLASH_BLOCKSIZE_MAIN)
+#define PART_KERNEL_START (PART_BLOB_START + PART_BLOB_LEN)
+#define PART_KERNEL_LEN (NUM_KERNEL_BLOCKS * FLASH_BLOCKSIZE_MAIN)
/* initial ramdisk */
#define NUM_INITRD_BLOCKS 24
-#define INITRD_START (KERNEL_START + KERNEL_LEN)
-#define INITRD_LEN (NUM_INITRD_BLOCKS * FLASH_BLOCKSIZE_MAIN)
+#define PART_INITRD_START (PART_KERNEL_START + PART_KERNEL_LEN)
+#define PART_INITRD_LEN (NUM_INITRD_BLOCKS * FLASH_BLOCKSIZE_MAIN)
/*
* See section 4.0 in "3 Volt Fast Boot Block Flash Memory" Intel Datasheet
@@ -587,20 +587,20 @@ static struct mtd_partition lart_partitions[] = {
/* blob */
{
.name = "blob",
- .offset = BLOB_START,
- .size = BLOB_LEN,
+ .offset = PART_BLOB_START,
+ .size = PART_BLOB_LEN,
},
/* kernel */
{
.name = "kernel",
- .offset = KERNEL_START, /* MTDPART_OFS_APPEND */
- .size = KERNEL_LEN,
+ .offset = PART_KERNEL_START, /* MTDPART_OFS_APPEND */
+ .size = PART_KERNEL_LEN,
},
/* initial ramdisk / file system */
{
.name = "file system",
- .offset = INITRD_START, /* MTDPART_OFS_APPEND */
- .size = INITRD_LEN, /* MTDPART_SIZ_FULL */
+ .offset = PART_INITRD_START, /* MTDPART_OFS_APPEND */
+ .size = PART_INITRD_LEN, /* MTDPART_SIZ_FULL */
}
};
#define NUM_PARTITIONS ARRAY_SIZE(lart_partitions)
--
2.9.3
^ permalink raw reply related
* [PATCH v5 2/4] ARM: Define KERNEL_START and KERNEL_END
From: Florian Fainelli @ 2017-01-04 1:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104011417.1496-1-f.fainelli@gmail.com>
In preparation for adding CONFIG_DEBUG_VIRTUAL support, define a set of
common constants: KERNEL_START and KERNEL_END which abstract
CONFIG_XIP_KERNEL vs. !CONFIG_XIP_KERNEL. Update the code where
relevant.
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/include/asm/memory.h | 7 +++++++
arch/arm/mm/init.c | 7 ++-----
arch/arm/mm/mmu.c | 6 +-----
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 76cbd9c674df..bee7511c5098 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -111,6 +111,13 @@
#endif /* !CONFIG_MMU */
+#ifdef CONFIG_XIP_KERNEL
+#define KERNEL_START _sdata
+#else
+#define KERNEL_START _stext
+#endif
+#define KERNEL_END _end
+
/*
* We fix the TCM memories max 32 KiB ITCM resp DTCM at these
* locations
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 370581aeb871..c87d0d5b65f2 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -230,11 +230,8 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t size, phys_addr_t align)
void __init arm_memblock_init(const struct machine_desc *mdesc)
{
/* Register the kernel text, kernel data and initrd with memblock. */
-#ifdef CONFIG_XIP_KERNEL
- memblock_reserve(__pa(_sdata), _end - _sdata);
-#else
- memblock_reserve(__pa(_stext), _end - _stext);
-#endif
+ memblock_reserve(__pa(KERNEL_START), _end - KERNEL_START);
+
#ifdef CONFIG_BLK_DEV_INITRD
/* FDT scan will populate initrd_start */
if (initrd_start && !phys_initrd_size) {
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 4001dd15818d..f0fd1a2db036 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1437,11 +1437,7 @@ static void __init kmap_init(void)
static void __init map_lowmem(void)
{
struct memblock_region *reg;
-#ifdef CONFIG_XIP_KERNEL
- phys_addr_t kernel_x_start = round_down(__pa(_sdata), SECTION_SIZE);
-#else
- phys_addr_t kernel_x_start = round_down(__pa(_stext), SECTION_SIZE);
-#endif
+ phys_addr_t kernel_x_start = round_down(__pa(KERNEL_START), SECTION_SIZE);
phys_addr_t kernel_x_end = round_up(__pa(__init_end), SECTION_SIZE);
/* Map all the lowmem memory banks. */
--
2.9.3
^ permalink raw reply related
* [PATCH v5 3/4] ARM: Add support for CONFIG_DEBUG_VIRTUAL
From: Florian Fainelli @ 2017-01-04 1:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104011417.1496-1-f.fainelli@gmail.com>
x86 has an option: CONFIG_DEBUG_VIRTUAL to do additional checks on
virt_to_phys calls. The goal is to catch users who are calling
virt_to_phys on non-linear addresses immediately. This includes caller
using __virt_to_phys() on image addresses instead of __pa_symbol(). This
is a generally useful debug feature to spot bad code (particulary in
drivers).
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/memory.h | 16 +++++++++++--
arch/arm/mm/Makefile | 1 +
arch/arm/mm/physaddr.c | 55 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 71 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mm/physaddr.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5fab553fd03a..4700294f4e09 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2,6 +2,7 @@ config ARM
bool
default y
select ARCH_CLOCKSOURCE_DATA
+ select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index bee7511c5098..d90300193adf 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -213,7 +213,7 @@ extern const void *__pv_table_begin, *__pv_table_end;
: "r" (x), "I" (__PV_BITS_31_24) \
: "cc")
-static inline phys_addr_t __virt_to_phys(unsigned long x)
+static inline phys_addr_t __virt_to_phys_nodebug(unsigned long x)
{
phys_addr_t t;
@@ -245,7 +245,7 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
#define PHYS_OFFSET PLAT_PHYS_OFFSET
#define PHYS_PFN_OFFSET ((unsigned long)(PHYS_OFFSET >> PAGE_SHIFT))
-static inline phys_addr_t __virt_to_phys(unsigned long x)
+static inline phys_addr_t __virt_to_phys_nodebug(unsigned long x)
{
return (phys_addr_t)x - PAGE_OFFSET + PHYS_OFFSET;
}
@@ -261,6 +261,16 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
((((unsigned long)(kaddr) - PAGE_OFFSET) >> PAGE_SHIFT) + \
PHYS_PFN_OFFSET)
+#define __pa_symbol_nodebug(x) __virt_to_phys_nodebug((x))
+
+#ifdef CONFIG_DEBUG_VIRTUAL
+extern phys_addr_t __virt_to_phys(unsigned long x);
+extern phys_addr_t __phys_addr_symbol(unsigned long x);
+#else
+#define __virt_to_phys(x) __virt_to_phys_nodebug(x)
+#define __phys_addr_symbol(x) __pa_symbol_nodebug(x)
+#endif
+
/*
* These are *only* valid on the kernel direct mapped RAM memory.
* Note: Drivers should NOT use these. They are the wrong
@@ -283,9 +293,11 @@ static inline void *phys_to_virt(phys_addr_t x)
* Drivers should NOT use these either.
*/
#define __pa(x) __virt_to_phys((unsigned long)(x))
+#define __pa_symbol(x) __phys_addr_symbol(RELOC_HIDE((unsigned long)(x), 0))
#define __va(x) ((void *)__phys_to_virt((phys_addr_t)(x)))
#define pfn_to_kaddr(pfn) __va((phys_addr_t)(pfn) << PAGE_SHIFT)
+
extern long long arch_phys_to_idmap_offset;
/*
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index e8698241ece9..b3dea80715b4 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -14,6 +14,7 @@ endif
obj-$(CONFIG_ARM_PTDUMP) += dump.o
obj-$(CONFIG_MODULES) += proc-syms.o
+obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
obj-$(CONFIG_ALIGNMENT_TRAP) += alignment.o
obj-$(CONFIG_HIGHMEM) += highmem.o
diff --git a/arch/arm/mm/physaddr.c b/arch/arm/mm/physaddr.c
new file mode 100644
index 000000000000..f10bdcbcb155
--- /dev/null
+++ b/arch/arm/mm/physaddr.c
@@ -0,0 +1,55 @@
+#include <linux/bug.h>
+#include <linux/export.h>
+#include <linux/types.h>
+#include <linux/mmdebug.h>
+#include <linux/mm.h>
+
+#include <asm/sections.h>
+#include <asm/memory.h>
+#include <asm/fixmap.h>
+#include <asm/dma.h>
+
+#include "mm.h"
+
+static inline bool __virt_addr_valid(unsigned long x)
+{
+ /* high_memory does not get immediately defined, and there
+ * are early callers of __pa() against PAGE_OFFSET
+ */
+ if (!high_memory && x >= PAGE_OFFSET)
+ return true;
+
+ if (high_memory && x >= PAGE_OFFSET && x < (unsigned long)high_memory)
+ return true;
+
+ /* ARM uses the default per-CPU allocation routing which forces us to
+ * have an explicit check here to avoid a false positive
+ */
+ if (x == MAX_DMA_ADDRESS)
+ return true;
+
+ return false;
+}
+
+phys_addr_t __virt_to_phys(unsigned long x)
+{
+ WARN(!__virt_addr_valid(x),
+ "virt_to_phys used for non-linear address: %pK (%pS)\n",
+ (void *)x,
+ (void *)x);
+
+ return __virt_to_phys_nodebug(x);
+}
+EXPORT_SYMBOL(__virt_to_phys);
+
+phys_addr_t __phys_addr_symbol(unsigned long x)
+{
+ /* This is bounds checking against the kernel image only.
+ * __pa_symbol should only be used on kernel symbol addresses.
+ */
+ VIRTUAL_BUG_ON(x < (unsigned long)KERNEL_START ||
+ x > (unsigned long)KERNEL_END);
+
+ return __pa_symbol_nodebug(x);
+}
+EXPORT_SYMBOL(__phys_addr_symbol);
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox