* RE: Re: [PATCH 1/1] arm/module: maximum utilization of module area.
From: Vaneet Narang @ 2016-12-12 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20161212102403epcas4p2e039072e2acdc3d20c1b8ac86e823375@epcas4p2.samsung.com>
Hi,
>A PC24 relocation has a range of +/-32MB. This means that where-ever
>the module is placed, it must be capable of reaching any function
>within the kernel text, which may itself be quite large (eg, 8MB, or
>possibly larger). The module area exists to allow modules to be
>located in an area where PC24 relocations are able to reach all of the
>kernel text on sensibly configured kernels, thereby allowing for
>optimal performance.
>
>If you wish to load large modules, then enable ARM_MODULE_PLTS, which
>will use the less efficient PLT method (which is basically an indirect
>function call) for relocations that PC24 can't handle, and will allow
>the module to be loaded into the vmalloc area.
>
>Growing the module area so that smaller modules also get penalised by
>the PLT indirection is not sane.
This is exactly what i am saying. These changes are useful to accomdate
22MB modules without enabling ARM_MODULE_PLTS.
Without these changes ARM_MODULE_PLTS needs to be enabled to insert more than 14MB
modules but with these changes 22MB modules (considering 8MB uImage) can be inserted
without enabling ARM_MODULE_PLTS.
So till 22MB modules are not penalised but without these changes once size of modules
gets over 14MB PLT becomes must.?
Regards,
Vaneet Narang
^ permalink raw reply
* [PATCH 1/2] arm64: setup: introduce kaslr_offset()
From: Will Deacon @ 2016-12-12 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481417456-28826-2-git-send-email-alex.popov@linux.com>
On Sun, Dec 11, 2016 at 03:50:55AM +0300, Alexander Popov wrote:
> Introduce kaslr_offset() similarly to x86_64 for fixing kcov.
>
> Signed-off-by: Alexander Popov <alex.popov@linux.com>
> ---
> arch/arm64/include/asm/setup.h | 19 +++++++++++++++++++
> arch/arm64/include/uapi/asm/setup.h | 4 ++--
> arch/arm64/kernel/setup.c | 8 ++++----
> 3 files changed, 25 insertions(+), 6 deletions(-)
> create mode 100644 arch/arm64/include/asm/setup.h
>
> diff --git a/arch/arm64/include/asm/setup.h b/arch/arm64/include/asm/setup.h
> new file mode 100644
> index 0000000..e7b59b9
> --- /dev/null
> +++ b/arch/arm64/include/asm/setup.h
> @@ -0,0 +1,19 @@
> +/*
> + * arch/arm64/include/asm/setup.h
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __ASM_SETUP_H
> +#define __ASM_SETUP_H
> +
> +#include <uapi/asm/setup.h>
> +
> +static inline unsigned long kaslr_offset(void)
> +{
> + return kimage_vaddr - KIMAGE_VADDR;
> +}
> +
> +#endif
You could probably just stick this in asm/memory.h, since that's where
kimage_vaddr is declared and it would save adding a new header file.
> diff --git a/arch/arm64/include/uapi/asm/setup.h b/arch/arm64/include/uapi/asm/setup.h
> index 9cf2e46..26631c8 100644
> --- a/arch/arm64/include/uapi/asm/setup.h
> +++ b/arch/arm64/include/uapi/asm/setup.h
> @@ -16,8 +16,8 @@
> * You should have received a copy of the GNU General Public License
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
> -#ifndef __ASM_SETUP_H
> -#define __ASM_SETUP_H
> +#ifndef _UAPI__ASM_SETUP_H
> +#define _UAPI__ASM_SETUP_H
>
> #include <linux/types.h>
You can drop this hunk.
With those changes:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH 1/1] arm: mm: Fix comments in sg_sync functions
From: Sakari Ailus @ 2016-12-12 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <560A6C80.1050808@arm.com>
Hi Robin and others,
On Tue, Sep 29, 2015 at 11:48:32AM +0100, Robin Murphy wrote:
> Hi Sakari,
>
> On 28/09/15 21:20, Sakari Ailus wrote:
> >The comment on the usage of arm_dma_sync_sg_for_cpu(),
> >arm_dma_sync_sg_for_device(), arm_iommu_sync_sg_for_cpu() and
> >arm_iommu_sync_sg_for_device() functions wrongly noted that the "nelems"
> >parameter is the number of sglist entries returned by dma_map_sg(), while
> >this must be the number of entiries passed to dma_map_sg() instead.
>
> Oops, I somehow missed you off cc when I posted [0] last week, apologies. I
> was planning to stick that in Russell's patch system today, but since you've
> done a slightly more thorough job with s/map/sync/ than I managed, I'm happy
> for this version to take precedence over mine:
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
I was cleaning up my old branches and noticed this patch isn't merged yet.
It still applies cleanly though. How shall we proceed, should I send a pull
request?
>
> I'd hope that the lack of objections to my patch so far (and Dan's approval)
> also apply transitively to this one ;)
>
> Robin.
>
> [0]:http://thread.gmane.org/gmane.linux.ports.arm.kernel/441862
>
> >Suggested-by: Daniel Kurtz <djkurtz@chromium.org>
> >Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> >---
> >Hi folks,
> >
> >This related patch was applied to Jonathan Corbet's tree:
> >
> ><URL:http://www.spinics.net/lists/linux-doc/msg31801.html>
> >
> >The comments were indeed wrong. This may have contributed to a related
> >videobuf2 bug:
> >
> ><URL:http://www.spinics.net/lists/linux-media/msg93765.html>
> >
> > arch/arm/mm/dma-mapping.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> >diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> >index e626043..1c0154a 100644
> >--- a/arch/arm/mm/dma-mapping.c
> >+++ b/arch/arm/mm/dma-mapping.c
> >@@ -958,7 +958,7 @@ void arm_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
> > * arm_dma_sync_sg_for_cpu
> > * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
> > * @sg: list of buffers
> >- * @nents: number of buffers to map (returned from dma_map_sg)
> >+ * @nents: number of buffers to sync (same as was passed to dma_map_sg)
> > * @dir: DMA transfer direction (same as was passed to dma_map_sg)
> > */
> > void arm_dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
> >@@ -977,7 +977,7 @@ void arm_dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
> > * arm_dma_sync_sg_for_device
> > * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
> > * @sg: list of buffers
> >- * @nents: number of buffers to map (returned from dma_map_sg)
> >+ * @nents: number of buffers to sync (same as was passed to dma_map_sg)
> > * @dir: DMA transfer direction (same as was passed to dma_map_sg)
> > */
> > void arm_dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
> >@@ -1672,7 +1672,7 @@ void arm_iommu_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
> > * arm_iommu_sync_sg_for_cpu
> > * @dev: valid struct device pointer
> > * @sg: list of buffers
> >- * @nents: number of buffers to map (returned from dma_map_sg)
> >+ * @nents: number of buffers to sync (same as was passed to dma_map_sg)
> > * @dir: DMA transfer direction (same as was passed to dma_map_sg)
> > */
> > void arm_iommu_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
> >@@ -1690,7 +1690,7 @@ void arm_iommu_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
> > * arm_iommu_sync_sg_for_device
> > * @dev: valid struct device pointer
> > * @sg: list of buffers
> >- * @nents: number of buffers to map (returned from dma_map_sg)
> >+ * @nents: number of buffers to sync (same as was passed to dma_map_sg)
> > * @dir: DMA transfer direction (same as was passed to dma_map_sg)
> > */
> > void arm_iommu_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
> >
>
>
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
^ permalink raw reply
* [PATCH 3/3] dts: hisi: add dts files for Hi3516CV300 demo board
From: Jiancheng Xue @ 2016-12-12 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017120705.3726-4-wenpan@hisilicon.com>
On 2016/10/17 20:07, Pan Wen wrote:
> Add dts files for Hi3516CV300 demo board.
>
> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
> ---
Could you help to review this patch, please?
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/hi3516cv300-demb.dts | 148 ++++++++++++
> arch/arm/boot/dts/hi3516cv300.dtsi | 397 +++++++++++++++++++++++++++++++++
> 3 files changed, 546 insertions(+)
> create mode 100644 arch/arm/boot/dts/hi3516cv300-demb.dts
> create mode 100644 arch/arm/boot/dts/hi3516cv300.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..1f25530 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -171,6 +171,7 @@ dtb-$(CONFIG_ARCH_HIP01) += \
> dtb-$(CONFIG_ARCH_HIP04) += \
> hip04-d01.dtb
> dtb-$(CONFIG_ARCH_HISI) += \
> + hi3516cv300-demb.dtb \
> hi3519-demb.dtb
> dtb-$(CONFIG_ARCH_HIX5HD2) += \
> hisi-x5hd2-dkb.dtb
> diff --git a/arch/arm/boot/dts/hi3516cv300-demb.dts b/arch/arm/boot/dts/hi3516cv300-demb.dts
> new file mode 100644
> index 0000000..6a75cd6
> --- /dev/null
> +++ b/arch/arm/boot/dts/hi3516cv300-demb.dts
> @@ -0,0 +1,148 @@
> +/*
> + * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
> + *
> + * 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; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + *
> + */
> +
> +
> +/dts-v1/;
> +#include "hi3516cv300.dtsi"
> +
> +/ {
> + model = "Hisilicon Hi3516CV300 DEMO Board";
> + compatible = "hisilicon,hi3516cv300";
> +
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + serial2 = &uart2;
> + i2c0 = &i2c_bus0;
> + i2c1 = &i2c_bus1;
> + spi0 = &spi_bus0;
> + spi1 = &spi_bus1;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x80000000 0x10000000>;
> + };
> +};
> +
> +&dual_timer0 {
> + status = "okay";
> +};
> +
> +&watchdog {
> + status = "okay";
> +};
> +
> +&pwm {
> + status = "okay";
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&i2c_bus0 {
> + status = "okay";
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pmux>;
> +};
> +
> +&i2c_bus1 {
> + status = "okay";
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pmux>;
> +};
> +
> +&spi_bus0{
> + status = "disabled";
> + num-cs = <1>;
> + cs-gpios = <&gpio_chip0 6 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi0_pmux>;
> +};
> +
> +&spi_bus1{
> + status = "okay";
> + num-cs = <2>;
> + cs-gpios = <&gpio_chip5 3 0>, <&gpio_chip5 4 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi1_pmux>;
> +};
> +
> +&fmc {
> + spi-nor at 0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <160000000>;
> + m25p,fast-read;
> + };
> +};
> +
> +&mdio {
> + phy0: phy at 1 {
> + reg = <1>;
> + };
> +};
> +
> +&hisi_femac {
> + mac-address = [00 00 00 00 00 00];
> + phy-mode = "rmii";
> + phy-handle = <&phy0>;
> + hisilicon,phy-reset-delays-us = <10000 10000 150000>;
> +};
> +
> +&dmac {
> + status = "okay";
> +};
> +
> +&pmux {
> + i2c0_pmux: i2c0_pmux {
> + pinctrl-single,pins = <
> + 0x2c 0x3
> + 0x30 0x3>;
> + };
> +
> + i2c1_pmux: i2c1_pmux {
> + pinctrl-single,pins = <
> + 0x20 0x1
> + 0x24 0x1>;
> + };
> +
> + spi0_pmux: spi0_pmux {
> + pinctrl-single,pins = <
> + 0x28 0x1
> + 0x2c 0x1
> + 0x30 0x1
> + 0x34 0x1>;
> + };
> +
> + spi1_pmux: spi1_pmux {
> + pinctrl-single,pins = <
> + 0xc4 0x1
> + 0xc8 0x1
> + 0xcc 0x1
> + 0xd0 0x1
> + 0xd4 0x1>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/hi3516cv300.dtsi b/arch/arm/boot/dts/hi3516cv300.dtsi
> new file mode 100644
> index 0000000..1da41ab
> --- /dev/null
> +++ b/arch/arm/boot/dts/hi3516cv300.dtsi
> @@ -0,0 +1,397 @@
> +/*
> + * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
> + *
> + * 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; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + *
> + */
> +
> +#include "skeleton.dtsi"
> +#include <dt-bindings/clock/hi3516cv300-clock.h>
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,arm926ej-s";
> + reg = <0>;
> + };
> + };
> +
> + vic: interrupt-controller at 10040000 {
> + compatible = "arm,pl190-vic";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + reg = <0x10040000 0x1000>;
> + };
> +
> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + interrupt-parent = <&vic>;
> + ranges;
> +
> + clk_3m: clk_3m {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <3000000>;
> + };
> +
> + clk_apb: clk_apb {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <50000000>;
> + };
> +
> + crg: clock-reset-controller at 12010000 {
> + compatible = "hisilicon,hi3516cv300-crg";
> + reg = <0x12010000 0x1000>;
> + #clock-cells = <1>;
> + #reset-cells = <2>;
> + };
> +
> + sysctrl: system-controller at 12020000 {
> + compatible = "hisilicon,hi3516cv300-sysctrl", "syscon";
> + reg = <0x12020000 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + reboot {
> + compatible = "syscon-reboot";
> + regmap = <&sysctrl>;
> + offset = <0x4>;
> + mask = <0xdeadbeef>;
> + };
> +
> + dual_timer0: dual_timer at 12000000 {
> + compatible = "arm,sp804", "arm,primecell";
> + reg = <0x12000000 0x1000>;
> + interrupts = <3>;
> + clocks = <&clk_3m>, <&clk_3m>, <&clk_apb>;
> + clock-names = "timer0", "timer1", "apb_pclk";
> + status = "disabled";
> + };
> +
> + dual_timer1: dual_timer at 12001000 {
> + compatible = "arm,sp804", "arm,primecell";
> + reg = <0x12001000 0x1000>;
> + interrupts = <4>;
> + clocks = <&clk_3m>, <&clk_3m>, <&clk_apb>;
> + clock-names = "timer0", "timer1", "apb_pclk";
> + status = "disabled";
> + };
> +
> + watchdog: watchdog at 12080000 {
> + compatible = "arm,sp805-wdt", "arm,primecell";
> + arm,primecell-periphid = <0x00141805>;
> + reg = <0x12080000 0x1000>;
> + clocks = <&sysctrl HI3516CV300_WDT_CLK>,
> + <&crg HI3516CV300_APB_CLK>;
> + clock-names = "wdog_clk", "apb_pclk";
> + status = "disabled";
> + };
> +
> + pwm: pwm at 12130000 {
> + compatible = "hisilicon,hi3516cv300-pwm",
> + "hisilicon,hibvt-pwm";
> + reg = <0x12130000 0x10000>;
> + clocks = <&crg HI3516CV300_PWM_CLK>;
> + resets = <&crg 0x38 0>;
> + #pwm-cells = <2>;
> + status = "disabled";
> + };
> +
> + uart0: uart at 12100000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x12100000 0x1000>;
> + interrupts = <5>;
> + clocks = <&crg HI3516CV300_UART0_CLK>;
> + clock-names = "apb_pclk";
> + status = "disabled";
> + };
> +
> + uart1: uart at 12101000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x12101000 0x1000>;
> + interrupts = <30>;
> + clocks = <&crg HI3516CV300_UART1_CLK>;
> + clock-names = "apb_pclk";
> + status = "disabled";
> + };
> +
> + uart2: uart at 12102000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x12102000 0x1000>;
> + interrupts = <25>;
> + clocks = <&crg HI3516CV300_UART2_CLK>;
> + clock-names = "apb_pclk";
> + status = "disabled";
> + };
> +
> + i2c_bus0: i2c at 12110000 {
> + compatible = "hisilicon,hi3516cv300-i2c",
> + "hisilicon,hibvt-i2c";
> + reg = <0x12110000 0x1000>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + status = "disabled";
> + };
> +
> + i2c_bus1: i2c at 12112000 {
> + compatible = "hisilicon,hi3516cv300-i2c",
> + "hisilicon,hibvt-i2c";
> + reg = <0x12112000 0x1000>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + status = "disabled";
> + };
> +
> + spi_bus0: spi at 12120000 {
> + compatible = "arm,pl022", "arm,primecell";
> + reg = <0x12120000 0x1000>;
> + interrupts = <6>;
> + clocks = <&crg HI3516CV300_SPI0_CLK>;
> + clock-names = "apb_pclk";
> + dmas = <&dmac 12 1>, <&dmac 13 2>;
> + dma-names = "rx", "tx";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi_bus1: spi at 12121000 {
> + compatible = "arm,pl022", "arm,primecell";
> + reg = <0x12121000 0x1000>, <0x12030000 0x4>;
> + interrupts = <7>;
> + clocks = <&crg HI3516CV300_SPI1_CLK>;
> + clock-names = "apb_pclk";
> + dmas = <&dmac 14 1>, <&dmac 15 2>;
> + dma-names = "rx", "tx";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + fmc: spi-nor-controller at 10000000 {
> + compatible = "hisilicon,fmc-spi-nor";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x10000000 0x1000>, <0x14000000 0x1000000>;
> + reg-names = "control", "memory";
> + clocks = <&crg HI3516CV300_FMC_CLK>;
> + assigned-clocks = <&crg HI3516CV300_FMC_CLK>;
> + assigned-clock-rates = <24000000>;
> + };
> +
> + mdio: mdio at 10051100 {
> + compatible = "hisilicon,hisi-femac-mdio";
> + reg = <0x10051100 0x10>;
> + clocks = <&crg HI3516CV300_ETH_CLK>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + hisi_femac: ethernet at 10090000 {
> + compatible = "hisilicon,hi3516cv300-femac",
> + "hisilicon,hisi-femac-v2";
> + reg = <0x10050000 0x1000>,<0x10051300 0x200>;
> + interrupts = <12>;
> + clocks = <&crg HI3516CV300_ETH_CLK>;
> + resets = <&crg 0xec 0>, <&crg 0xec 3>;
> + reset-names = "mac","phy";
> + };
> +
> + dmac: dma-controller at 10030000 {
> + compatible = "arm,pl080", "arm,primecell";
> + reg = <0x10030000 0x1000>;
> + interrupts = <14>;
> + clocks = <&crg HI3516CV300_DMAC_CLK>;
> + clock-names = "apb_pclk";
> + lli-bus-interface-ahb1;
> + lli-bus-interface-ahb2;
> + mem-bus-interface-ahb1;
> + mem-bus-interface-ahb2;
> + memcpy-burst-size = <256>;
> + memcpy-bus-width = <32>;
> + #dma-cells = <2>;
> + status = "disabled";
> + };
> +
> + gpio_chip0: gpio at 12140000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12140000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 61 2>,
> + <&pmux 4 11 1>,
> + <&pmux 5 10 1>,
> + <&pmux 6 13 2>;
> +
> + status = "disabled";
> + };
> +
> + gpio_chip1: gpio at 12141000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12141000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 16 7>,
> + <&pmux 7 0 1>;
> + status = "disabled";
> + };
> +
> + gpio_chip2: gpio at 12142000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12142000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 46 1>,
> + <&pmux 1 45 1>,
> + <&pmux 2 44 1>,
> + <&pmux 3 43 1>,
> + <&pmux 4 39 1>,
> + <&pmux 5 38 1>,
> + <&pmux 6 40 1>,
> + <&pmux 7 48 1>;
> + status = "disabled";
> + };
> +
> + gpio_chip3: gpio at 12143000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12143000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 37 1>,
> + <&pmux 1 36 1>,
> + <&pmux 2 35 1>,
> + <&pmux 3 34 1>,
> + <&pmux 4 23 2>,
> + <&pmux 6 8 2>;
> + status = "disabled";
> + };
> +
> + gpio_chip4: gpio at 12144000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12144000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 27 1>,
> + <&pmux 1 26 1>,
> + <&pmux 2 31 1>,
> + <&pmux 3 30 1>,
> + <&pmux 4 28 2>,
> + <&pmux 6 33 1>,
> + <&pmux 7 32 1>;
> + status = "disabled";
> + };
> +
> + gpio_chip5: gpio at 12145000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12145000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 53 1>,
> + <&pmux 1 51 2>,
> + <&pmux 3 50 1>,
> + <&pmux 4 49 1>,
> + <&pmux 5 47 1>,
> + <&pmux 6 40 2>;
> + status = "disabled";
> + };
> +
> + gpio_chip6: gpio at 12146000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12146000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 7 1>,
> + <&pmux 1 6 1>,
> + <&pmux 2 4 1>,
> + <&pmux 3 5 1>,
> + <&pmux 4 15 1>,
> + <&pmux 5 1 3>;
> + status = "disabled";
> + };
> +
> + gpio_chip7: gpio at 12147000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12147000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 1 55 6>,
> + <&pmux 7 25 1>;
> + status = "disabled";
> + };
> +
> + gpio_chip8: gpio at 12148000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12148000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 63 3>,
> + <&pmux 3 12 1>;
> + status = "disabled";
> + };
> +
> + pmux: pinmux at 12040000 {
> + compatible = "pinctrl-single";
> + reg = <0x12040000 0x108>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #gpio-range-cells = <3>;
> + ranges;
> +
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <7>;
> + /* pin base, nr pins & gpio function */
> + pinctrl-single,gpio-range = <&range 0 54 0
> + &range 55 6 1 &range 61 5 0>;
> +
> + range: gpio-range {
> + #pinctrl-single,gpio-range-cells = <3>;
> + };
> + };
> +
> + pconf: pinconf at 12040800 {
> + compatible = "pinconf-single";
> + reg = <0x12040800 0x130>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + pinctrl-single,register-width = <32>;
> + };
> + };
> +};
>
^ permalink raw reply
* [PATCH v2] arm64: mm: Fix memmap to be initialized for the entire section
From: Ard Biesheuvel @ 2016-12-12 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209145234.GB14257@rric.localdomain>
On 9 December 2016 at 14:52, Robert Richter <robert.richter@cavium.com> wrote:
> On 09.12.16 21:15:12, Yisheng Xie wrote:
>> For invalid pages, their zone and node information is not initialized, and it
>> do have risk to trigger the BUG_ON, so I have a silly question,
>> why not just change the BUG_ON:
>
> We need to get the page handling correct. Modifying the BUG_ON() just
> hides that something is wrong.
>
Actually, I think this is a reasonable question. We are trying very
hard to work around the BUG_ON(), which arguably does something wrong
by calling page_to_nid() on a struct page without checking if it is a
valid page.
Looking at commit 344c790e3821 ("mm: make setup_zone_migrate_reserve()
aware of overlapping nodes"), the BUG_ON() has a specific purpose
related to adjacent zones.
What will go wrong if we ignore this check?
>
>> -----------
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 6de9440..af199b8 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -1860,12 +1860,13 @@ int move_freepages(struct zone *zone,
>> * Remove at a later date when no bug reports exist related to
>> * grouping pages by mobility
>> */
>> - VM_BUG_ON(page_zone(start_page) != page_zone(end_page));
>> + VM_BUG_ON(early_pfn_valid(start_page) && early_pfn_valid(end_page) &&
>> + page_zone(start_page) != page_zone(end_page));
>> #endif
>>
>> for (page = start_page; page <= end_page;) {
>> /* Make sure we are not inadvertently changing nodes */
>> - VM_BUG_ON_PAGE(page_to_nid(page) != zone_to_nid(zone), page);
>> + VM_BUG_ON_PAGE(early_pfn_valid(page) && (page_to_nid(page) != zone_to_nid(zone)), page);
>>
>> if (!pfn_valid_within(page_to_pfn(page))) {
>> page++;
>
^ permalink raw reply
* [RFC PATCH 15/23] arm: use kconfig fragments for ARCH_PXA defconfigs (part 1)
From: Bartlomiej Zolnierkiewicz @ 2016-12-12 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a8c415hs.fsf@belgarion.home>
Hi,
On Saturday, December 10, 2016 10:46:23 AM Robert Jarzmik wrote:
> Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> writes:
>
> > Replace [lpd270,lubbock,mainstone,pxa255-idp]_defconfig-s with
> > a Makefile target using merge_config.
> >
> > The patch was verified with doing:
> >
> > $ make [lpd270,...]_defconfig
> > $ make savedefconfig
> >
> > and comparing resulting defconfig files (before/after the patch).
> >
> > Cc: Daniel Mack <daniel@zonque.org>
> > Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> > Cc: Robert Jarzmik <robert.jarzmik@free.fr>
> > Cc: Cyril Bur <cyrilbur@gmail.com>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>
> Hi Bartolomiej,
>
> It's a bit hard to judge without any context for me, especially I'm receiving
> patches 11 to 21 but not the others. I suppose the advantage of defconfig
Sorry about that.
> fragments was already discussed somewhere, could you point me to that please ?
http://marc.info/?l=linux-kernel&m=148102838302106&w=2
I've put the patches on hold for now after the feedback from Olof & Arnd.
> One small thing that could be improved is the "pxa_basic*" names.
>
> I think pxa_basic1 is "pxa_refboards" or something like that, as these are the
> initial reference designs as far as I know from Intel and validation vehicles
> rather that form factors.
>
> In the same way, pxa_basic2 is rather "pxa_sharpsl" as these are sharp designs.
>
> And pxa_basic3 looks like Motorola platforms, so "pxa_motorola" perhaps ?
>
> I noticed imote2.config ended up based on pxa_basic3, while I would have
> expected it to be based on pxa_basic1 as it looks like a reference board to me
> ...
Thank you for your comments.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [linux-sunxi] sunxi-ng clocks: leaving certain clocks alone?
From: Andre Przywara @ 2016-12-12 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67kCAr6Ty5=Gg8vOGNC6xhuRM66Wa=H+C3AD=_d_H+N8w@mail.gmail.com>
Hi Chen-Yu,
thanks for the answer!
On 12/12/16 04:41, Chen-Yu Tsai wrote:
> On Mon, Dec 12, 2016 at 7:54 AM, Andr? Przywara <andre.przywara@arm.com> wrote:
>> Hi,
>>
>> I was observing that the new sunxi-ng clock code apparently explicitly
>> turns off _all_ clocks that are not used or needed. I find this rather
>> unfortunate, as I wanted to use the THS temperature sensor from ARM
>> Trusted Firmware to implement emergency shutdown or DVFS throttling.
>> That works until the clock framework finds the clock (as enumerated in
>> ccu-sun50i-a64.c) and obviously explicitly clears bit 31 in the THS mod
>> clock register and bit 8 in the respective clock gate register.
>> Turning them manually back on via /dev/mem or removing the THS clock
>> from the sunxi-ng driver fixes this for me.
>>
>> This was not happening with the old Allwinner clocks, since the kernel
>> wouldn't even know about it if there was no driver and the clock wasn't
>> mentioned in the DT.
>>
>> Now with sunxi-ng even though the THS clock is not actually referenced
>> or used in the DT, the kernel turns it off. I would expect that upon
>> entering the kernel all unneeded clocks are turned off anyway, so there
>> is no need to mess with clocks that have no user, but are enumerated in
>> the ccu driver.
>
> I can't say that's absolutely true (wink).
>
>>
>> I wonder if this kills simplefb as well, for instance, since I believe
>> that U-Boot needs to turn on certain clocks and relies on them staying up.
>
> The simplefb bindings takes clocks and regulators expressly for the
> purpose of keeping them enabled.
Right, I should have checked this before ...
>>
>> So my questions:
>> 1) Is this expected behaviour?
>
> Yes.
>
>> 2) If yes, should it really be?
>> 3) If yes, shouldn't there be way to explicitly tell Linux to leave that
>> clock alone, preferably via DT? Although the sunxi-ng clocks take
>> control over the whole CCU unit, I wonder if it should really mess with
>> clocks there are not referenced in the DT.
>
> As it owns the whole CCU unit, why not? And how would it know if some
> clock is referenced or not, unless going through the whole device tree?
I was hoping that it just provides clocks to any users (drivers) and
wouldn't bother with tinkering with every clock unless explicitly being
asked for (by a driver being pointed to a specific clock through DT).
So it would need to iterate through anything - neither the whole DT nor
it's own list of clocks.
> Furthermore, nothing prevents another device driver from referencing
> said clock and turning it off when it's not in use. Think THS driver
> with runtime PM.
I am totally OK with that: Any potential Linux THS driver can take over,
if the DT references this device and the clock.
My point is that atm there is no such driver and so the clocks framework
shouldn't turn that clock off.
> Are you also mapping the THS to secure only? Otherwise nothing would
> prevent Linux from also claiming it.
Unfortunately the THS is always unsecure. And even if it could be
switched, after a recent IRC discussion I came to believe that those
secure peripherals features only works when the secure boot feature is
used, which requires to blow an efuse and thus is not easily doable on
most boards and also irreversible.
Also I am not sure whether this security feature actually extends to the
mod clocks and the bus reset and clock gates bits.
But I was relying on that Linux doesn't touch hardware that's not
referenced in the DT, so if firmware uses the THS, any Linux THS node
would need to go - or the other way around: if there is a Linux THS
node, firmware backs off.
>> Maybe there is some way to reference those clocks via some dummy driver
>> or DT node to avoid this behaviour? Is there any prior art in this respect?
>
> If you want a clock to not be disabled by anyone, adding CLK_IS_CRITICAL
> to its flags is the proper option. This is done in the clk driver though.
Yes, I was thinking about that, but it indeed sounds like a hack to
follow this.
> If you just don't want the clk subsystem to disable unused clks at boot
> time, you can add "clk_ignore_unused" to the kernel boot parameters.
> I think this is more of a hack and debugging tool though.
Good point, but indeed looks like a debug feature.
> About dummy drivers, simplefb comes to mind again. But simplefb disables
> them when it gets kicked out by the drm driver.
Which I am fine with. If people are desperate about a THS driver, this
could take over, although I would expect a firmware driving the THS
would discourage this - for instance by removing a THS node.
> Maybe there are other examples.
OK, thanks for the pointer, I will look into this direction.
Cheers,
Andre.
>> I think this issue will affect more future users (thinking of EFI RTC,
>> EFI graphics, etc.), so I wanted to start a discussion on this.
>>
>> Any input welcome.
>>
>> Cheers,
>> Andre.
>>
>> P.S. For reference my use case: ARM Trusted Firmware (ATF) enables the
>> temperature sensor (THS) and programs a shutdown value. It programs the
>> respective interrupt as secure and registers an IRQ handler in ATF to
>> shutdown the system or take other appropriate matters to avoid
>> overheating. Additionally the sensor is exported via the generic SCPI
>> interface, so the existing scpi-hwmon driver picks it up and reports it
>> to whoever is interested in Linux land via the normal interfaces.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH 1/1] arm: mm: Fix comments in sg_sync functions
From: Robin Murphy @ 2016-12-12 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212113053.GR16630@valkosipuli.retiisi.org.uk>
Hi Sakari,
On 12/12/16 11:30, Sakari Ailus wrote:
> Hi Robin and others,
>
> On Tue, Sep 29, 2015 at 11:48:32AM +0100, Robin Murphy wrote:
>> Hi Sakari,
>>
>> On 28/09/15 21:20, Sakari Ailus wrote:
>>> The comment on the usage of arm_dma_sync_sg_for_cpu(),
>>> arm_dma_sync_sg_for_device(), arm_iommu_sync_sg_for_cpu() and
>>> arm_iommu_sync_sg_for_device() functions wrongly noted that the "nelems"
>>> parameter is the number of sglist entries returned by dma_map_sg(), while
>>> this must be the number of entiries passed to dma_map_sg() instead.
>>
>> Oops, I somehow missed you off cc when I posted [0] last week, apologies. I
>> was planning to stick that in Russell's patch system today, but since you've
>> done a slightly more thorough job with s/map/sync/ than I managed, I'm happy
>> for this version to take precedence over mine:
>>
>> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
>
> I was cleaning up my old branches and noticed this patch isn't merged yet.
> It still applies cleanly though. How shall we proceed, should I send a pull
> request?
I guess it should probably go through the ARM tree, so the best course
of action would be to submit it to Russell's patch system[1] for him to
pick up.
Robin.
[1]:http://www.armlinux.org.uk/developer/patches/
>>
>> I'd hope that the lack of objections to my patch so far (and Dan's approval)
>> also apply transitively to this one ;)
>>
>> Robin.
>>
>> [0]:http://thread.gmane.org/gmane.linux.ports.arm.kernel/441862
>>
>>> Suggested-by: Daniel Kurtz <djkurtz@chromium.org>
>>> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
>>> ---
>>> Hi folks,
>>>
>>> This related patch was applied to Jonathan Corbet's tree:
>>>
>>> <URL:http://www.spinics.net/lists/linux-doc/msg31801.html>
>>>
>>> The comments were indeed wrong. This may have contributed to a related
>>> videobuf2 bug:
>>>
>>> <URL:http://www.spinics.net/lists/linux-media/msg93765.html>
>>>
>>> arch/arm/mm/dma-mapping.c | 8 ++++----
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
>>> index e626043..1c0154a 100644
>>> --- a/arch/arm/mm/dma-mapping.c
>>> +++ b/arch/arm/mm/dma-mapping.c
>>> @@ -958,7 +958,7 @@ void arm_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
>>> * arm_dma_sync_sg_for_cpu
>>> * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
>>> * @sg: list of buffers
>>> - * @nents: number of buffers to map (returned from dma_map_sg)
>>> + * @nents: number of buffers to sync (same as was passed to dma_map_sg)
>>> * @dir: DMA transfer direction (same as was passed to dma_map_sg)
>>> */
>>> void arm_dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
>>> @@ -977,7 +977,7 @@ void arm_dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
>>> * arm_dma_sync_sg_for_device
>>> * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
>>> * @sg: list of buffers
>>> - * @nents: number of buffers to map (returned from dma_map_sg)
>>> + * @nents: number of buffers to sync (same as was passed to dma_map_sg)
>>> * @dir: DMA transfer direction (same as was passed to dma_map_sg)
>>> */
>>> void arm_dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
>>> @@ -1672,7 +1672,7 @@ void arm_iommu_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
>>> * arm_iommu_sync_sg_for_cpu
>>> * @dev: valid struct device pointer
>>> * @sg: list of buffers
>>> - * @nents: number of buffers to map (returned from dma_map_sg)
>>> + * @nents: number of buffers to sync (same as was passed to dma_map_sg)
>>> * @dir: DMA transfer direction (same as was passed to dma_map_sg)
>>> */
>>> void arm_iommu_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
>>> @@ -1690,7 +1690,7 @@ void arm_iommu_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
>>> * arm_iommu_sync_sg_for_device
>>> * @dev: valid struct device pointer
>>> * @sg: list of buffers
>>> - * @nents: number of buffers to map (returned from dma_map_sg)
>>> + * @nents: number of buffers to sync (same as was passed to dma_map_sg)
>>> * @dir: DMA transfer direction (same as was passed to dma_map_sg)
>>> */
>>> void arm_iommu_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
>>>
>>
>>
>
^ permalink raw reply
* [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable
From: Maxime Ripard @ 2016-12-12 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <afcb938d-d2df-4740-6c85-cdf2766f671c@schinagl.nl>
On Thu, Dec 08, 2016 at 02:23:39PM +0100, Olliver Schinagl wrote:
> Hey Maxime,
>
> first off, also sorry for the slow delay :) (pun not intended)
>
> On 27-08-16 00:19, Maxime Ripard wrote:
> > On Thu, Aug 25, 2016 at 07:50:10PM +0200, Olliver Schinagl wrote:
> > > When we inform the PWM block to stop toggeling the output, we may end up
> > > in a state where the output is not what we would expect (e.g. not the
> > > low-pulse) but whatever the output was at when the clock got disabled.
> > >
> > > To counter this we have to wait for maximally the time of one whole
> > > period to ensure the pwm hardware was able to finish. Since we already
> > > told the PWM hardware to disable it self, it will not continue toggling
> > > but merly finish its current pulse.
> > >
> > > If a whole period is considered to much, it may be contemplated to use a
> > > half period + a little bit to ensure we get passed the transition.
> > >
> > > Signed-off-by: Olliver Schinagl<oliver@schinagl.nl>
> > > ---
> > > drivers/pwm/pwm-sun4i.c | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> > > index 03a99a5..5e97c8a 100644
> > > --- a/drivers/pwm/pwm-sun4i.c
> > > +++ b/drivers/pwm/pwm-sun4i.c
> > > @@ -8,6 +8,7 @@
> > > #include <linux/bitops.h>
> > > #include <linux/clk.h>
> > > +#include <linux/delay.h>
> > > #include <linux/err.h>
> > > #include <linux/io.h>
> > > #include <linux/module.h>
> > > @@ -245,6 +246,16 @@ static void sun4i_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
> > > spin_lock(&sun4i_pwm->ctrl_lock);
> > > val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> > > val &= ~BIT_CH(PWM_EN, pwm->hwpwm);
> > > + sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
> > > + spin_unlock(&sun4i_pwm->ctrl_lock);
> > > +
> > > + /* Allow for the PWM hardware to finish its last toggle. The pulse
> > > + * may have just started and thus we should wait a full period.
> > > + */
> > > + ndelay(pwm_get_period(pwm));
> > Can't that use the ready bit as well?
>
> I started to implement our earlier discussed suggestions, but I do not think
> they will work. The read bit is not to let the user know it is ready with
> all of its commands, but only if the period registers are ready. I think it
> is some write lock while it copies the data into its internal control loop.
> From the manual:
> PWM0 period register ready.
> 0: PWM0 period register is ready to write,
> 1: PWM0 period register is busy.
>
>
> So no, I don't think i can use the ready bit here at all. The only thing we
> can do here, but I doubt it's worth it, is to read the period register,
> caluclate a time from it, and then ndelay(pwm_get_period(pwm) - ran_time)
>
> The only 'win' then is that we could are potentially not waiting the full
> pwm period, but only a fraction of it. Since we are disabling the hardware
> (for power reasons) anyway, I don't think this is any significant win,
> except for extreme situations. E.g. we have a pwm period of 10 seconds, we
> disable it after 9.9 second, and now we have to wait for 10 seconds before
> the pwm_disable is finally done. So this could in that case be reduced to
> then only wait for 0.2 seconds since it is 'done' sooner.
>
> However that optimization is also not 'free'. We have to read the period
> register and calculate back the time. I suggest to do that when reworking
> this driver to work with atomic mode, and merge this patch 'as is' to
> atleast fix te bug where simply not finish properly.
That whole discussion made me realise something that is really
bad. AFAIK, pwm_get_period returns a 32 bits register, which means a
theorical period of 4s. Busy looping during 4 seconds is already very
bad, as you basically kill one CPU during that time, but doing so in a
(potentially) atomic context is even worse.
NACK.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161212/e5f22cbb/attachment.sig>
^ permalink raw reply
* [PATCH v7 1/8] Documentation: arm: define DT cpu capacity-dmips-mhz bindings
From: Lorenzo Pieralisi @ 2016-12-12 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473085372-2840-2-git-send-email-juri.lelli@arm.com>
On Mon, Sep 05, 2016 at 03:22:45PM +0100, Juri Lelli wrote:
[...]
> +===========================================
> +5 - References
> +===========================================
> +
> +[1] ARM Linux Kernel documentation - CPUs bindings
> + Documentation/devicetree/bindings/arm/cpus.txt
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> index e6782d50cbcd..c1dcf4cade2e 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -241,6 +241,14 @@ nodes to be present and contain the properties described below.
> # List of phandles to idle state nodes supported
> by this cpu [3].
>
> + - capacity-dmips-mhz
> + Usage: Optional
> + Value type: <u32>
> + Definition:
> + # u32 value representing CPU capacity [3] in
> + DMIPS/MHz, relative to highest capacity-dmips-mhz
> + in the system.
> +
> - rockchip,pmu
> Usage: optional for systems that have an "enable-method"
> property value of "rockchip,rk3066-smp"
> @@ -464,3 +472,5 @@ cpus {
> [2] arm/msm/qcom,kpss-acc.txt
> [3] ARM Linux kernel documentation - idle states bindings
> Documentation/devicetree/bindings/arm/idle-states.txt
> +[3] ARM Linux kernel documentation - cpu capacity bindings
> + Documentation/devicetree/bindings/arm/cpu-capacity.txt
Trivia: bumped into this while reviewing something else, too many
threes, you will have to fix the added reference up.
Thanks,
Lorenzo
^ permalink raw reply
* [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Bartlomiej Zolnierkiewicz @ 2016-12-12 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <578CEB74.2080002@ti.com>
Hi,
On Monday, July 18, 2016 08:15:08 PM Sekhar Nori wrote:
> On Friday 15 July 2016 08:45 PM, Kevin Hilman wrote:
> > Arnd Bergmann <arnd@arndb.de> writes:
> >
> >> On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
> >>>
> >>> On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
> >>>> On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
> >>>>> This patch disables deprecated IDE subsystem in assabet_defconfig
> >>>>> (no IDE host drivers are selected in this config so there is no
> >>>>> valid reason to enable IDE subsystem itself).
> >>>>>
> >>>>> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> >>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>>>
> >>>> I think the series makes a lot of sense. I have checked your assertions
> >>>> in the changelogs and found no flaws in your logic, so I think we should
> >>>> take them all through arm-soc unless there are other concerns.
> >>>
> >>> Thank you.
> >>>
> >>> Should I resend everything or just patches that were not reposted yet
> >>> (the ones that were marked as RFT initially and got no feedback)?
> >>
> >> I'd be fine with just getting a pull request with all the patches that
> >> had no negative feedback and that were not already applied (if any).
> >>
> >>>> Do you have a list of ARM defconfigs that keep using CONFIG_IDE and
> >>>> how you determined that they need it?
> >>>
> >>> The only such defconfig is davinci_all_defconfig which uses
> >>> palm_bk3710 host driver (CONFIG_BLK_DEV_PALMCHIP_BK3710).
> >>>
> >>>> I know that ARCH_RPC/ARCH_ACORN has a couple of special drivers that
> >>>> have no libata replacement, are there any others like that, or are
> >>>> they all platforms that should in theory work with libata but need
> >>>> testing?
> >>>
> >>> All platforms except ARCH_ACORN, ARCH_DAVINCI & ARCH_RPC should work
> >>> with libata.
> >>
> >> Adding Sekhar and Kevin for DaVinci: At first sight, palm_bk3710 looks
> >> fairly straightforward (meaning someone has to do a few day's work)
> >> to convert into a libata driver.
> >>
> >> As this is on on-chip controller that is part of a dm644x and dm646x,
> >> it should also not be hard to test (as long as someone can find
> >> a hard drive to plug in).
> >
> > I have a hard drive, but don't have any dm64xx hardware anymore to test
> > this. My last working dm644x board died last year.
>
> I have a working DM6446 EVM. I was able to connect a hard drive to it
> and do some basic tests with v4.6 kernel.
>
> I will look into converting the driver to libata. Might take some time
> because this is unfamiliar territory for me.
Do you need some help with it?
I can provide you with draft driver patch if you want.
I'm also on #kernel IRC channel in case you have some questions..
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH 1/1] arm/module: maximum utilization of module area.
From: Russell King - ARM Linux @ 2016-12-12 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212112230epcms5p6af05aef34f72eab15061a166d18cff00@epcms5p6>
On Mon, Dec 12, 2016 at 11:22:30AM +0000, Vaneet Narang wrote:
> Hi,
>
> >A PC24 relocation has a range of +/-32MB. This means that where-ever
> >the module is placed, it must be capable of reaching any function
> >within the kernel text, which may itself be quite large (eg, 8MB, or
> >possibly larger). The module area exists to allow modules to be
> >located in an area where PC24 relocations are able to reach all of the
> >kernel text on sensibly configured kernels, thereby allowing for
> >optimal performance.
> >
> >If you wish to load large modules, then enable ARM_MODULE_PLTS, which
> >will use the less efficient PLT method (which is basically an indirect
> >function call) for relocations that PC24 can't handle, and will allow
> >the module to be loaded into the vmalloc area.
> >
> >Growing the module area so that smaller modules also get penalised by
> >the PLT indirection is not sane.
>
> This is exactly what i am saying. These changes are useful to accomdate
> 22MB modules without enabling ARM_MODULE_PLTS.
Obviously I wasn't clear enough.
No, I do not like your change for the reasons given above. I'm not going
to accept it.
If you want to use 22MB modules, enable ARM_MODULE_PLTS.
Thank you.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v6 0/5] ARM: dts: da850: tilcdc related DT changes
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
To: linux-arm-kernel
This series contains the last DT changes required for LCDC support
on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second
limits the maximum pixel clock rate.
v1 -> v2:
- drop patch 3/3 (already merged)
- use max-pixelclock instead of max-bandwidth for display mode limiting
v2 -> v3:
- make the commit message in patch [2/2] more detailed
- move the max-pixelclock property to da850.dtsi as the limit
affects all da850-based boards
v3 -> v4:
- remove the input port from the display node
- move the display ports node to da850-lcdk.dts
- rename the vga_bridge node to vga-bridge
- move the LCDC pins to the LCDC node (from the vga bridge node)
v4 -> v5:
- rename the display label to lcdc
- instead of using the 'dumb-vga-dac' compatible, add bindings for
ti,ths8135 and use it as the vga-bridge node compatible
v5 -> v6:
- drop the endpoint numbers for nodes with single endpoints
- split patch 2/4 from v5 into two separate patches: one adding DT
bindings and one adding actual support for ths8135
Bartosz Golaszewski (5):
ARM: dts: da850: rename the display node label
drm: bridge: add DT bindings for TI ths8135
drm: bridge: add support for TI ths8135
ARM: dts: da850-lcdk: add the vga-bridge node
ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
.../bindings/display/bridge/ti,ths8135.txt | 52 +++++++++++++++++
arch/arm/boot/dts/da850-lcdk.dts | 67 ++++++++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 3 +-
drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
4 files changed, 122 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
--
2.9.3
^ permalink raw reply
* [PATCH v6 1/5] ARM: dts: da850: rename the display node label
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481547942-24775-1-git-send-email-bgolaszewski@baylibre.com>
The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation.
The label is also 'display', but change it to 'lcdc' to make it clear
what the underlying hardware is.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index ffc6e1a..3f51e59 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -448,7 +448,7 @@
dma-names = "tx", "rx";
};
- display: display at 213000 {
+ lcdc: display at 213000 {
compatible = "ti,da850-tilcdc";
reg = <0x213000 0x1000>;
interrupts = <52>;
--
2.9.3
^ permalink raw reply related
* [PATCH v6 2/5] drm: bridge: add DT bindings for TI ths8135
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481547942-24775-1-git-send-email-bgolaszewski@baylibre.com>
THS8135 is a configurable video DAC. Add DT bindings for this chip.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
.../bindings/display/bridge/ti,ths8135.txt | 52 ++++++++++++++++++++++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
new file mode 100644
index 0000000..87aff90
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
@@ -0,0 +1,52 @@
+THS8135 Video DAC
+-----------------
+
+This is the binding for Texas Instruments THS8135 Video DAC bridge.
+
+Required properties:
+
+- compatible: Must be "ti,ths8135"
+
+Required nodes:
+
+This device has two video ports. Their connections are modelled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for RGB input
+- Video port 1 for VGA output
+
+Example
+-------
+
+vga-bridge {
+ compatible = "ti,ths8135";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ reg = <0>;
+ remote-endpoint = <&lcdc_out_vga>;
+ };
+ };
+
+ port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ reg = <0>;
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v6 3/5] drm: bridge: add support for TI ths8135
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481547942-24775-1-git-send-email-bgolaszewski@baylibre.com>
THS8135 is a configurable video DAC, but no configuration is actually
necessary to make it work.
For now use the dumb-vga-dac driver to support it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index afec232..498fa75 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -204,6 +204,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
static const struct of_device_id dumb_vga_match[] = {
{ .compatible = "dumb-vga-dac" },
+ { .compatible = "ti,ths8135" },
{},
};
MODULE_DEVICE_TABLE(of, dumb_vga_match);
--
2.9.3
^ permalink raw reply related
* [PATCH v6 4/5] ARM: dts: da850-lcdk: add the vga-bridge node
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481547942-24775-1-git-send-email-bgolaszewski@baylibre.com>
Add the vga-bridge node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 67 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index afcb482..e003111 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -51,6 +51,51 @@
system-clock-frequency = <24576000>;
};
};
+
+ vga-bridge {
+ compatible = "ti,ths8135";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ reg = <0>;
+ remote-endpoint = <&lcdc_out_vga>;
+ };
+ };
+
+ port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ reg = <0>;
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ ddc-i2c-bus = <&i2c0>;
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_bridge_out>;
+ };
+ };
+ };
};
&pmx_core {
@@ -236,3 +281,25 @@
&memctrl {
status = "okay";
};
+
+&lcdc {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lcdc_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ lcdc_out_vga: endpoint {
+ reg = <0>;
+ remote-endpoint = <&vga_bridge_in>;
+ };
+ };
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v6 5/5] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481547942-24775-1-git-send-email-bgolaszewski@baylibre.com>
At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
is 37.5 MHz[1]. We must filter out any mode for which the calculated
pixel clock rate would exceed this value.
Specify the max-pixelclock property for the display node for
da850-lcdk.
[1] http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_LCD_Controller_(LCDC)_Throughput_and_Optimization_Techniques
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 3f51e59..ba5bf80 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -452,6 +452,7 @@
compatible = "ti,da850-tilcdc";
reg = <0x213000 0x1000>;
interrupts = <52>;
+ max-pixelclock = <37500>;
status = "disabled";
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH 4/4] ARM: versatile: support configuring versatile machine for no-MMU
From: Vladimir Murzin @ 2016-12-12 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209202901.GQ14217@n2100.armlinux.org.uk>
On 09/12/16 20:29, Russell King - ARM Linux wrote:
> On Wed, Dec 07, 2016 at 02:33:53PM +0000, Vladimir Murzin wrote:
>> Hi Linus,
>>
>> On 07/12/16 14:11, Linus Walleij wrote:
>>> Another target I had in mind was the Integrator which
>>> incidentally supports a bunch of the old noMMU core
>>> tiles where we can swap in an ARM946, which I guess
>>> could work with this?
>>
>> Do you mind trying my "Allow NOMMU for MULTIPLATFORM" series [1]? Greg just
>> reported it did a trick for Versatile, there is a good chance it would work
>> for Integrator too ;)
>
> My views on gluing multiplatform and nommu together have already been
> stated several times, and remain unchanged.
>
Should I treat this as the whole series is discarded or there is something you
can pick up?
Cheers
Vladimir
> Greg's patch looks almost sane, but what I'd like to see is instead of
> directly doing this:
>
> config ARCH_VERSATILE
> bool "ARM Ltd. Versatile family"
> - depends on ARCH_MULTI_V5
> + depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
>
> we could do:
>
> config ARCH_VERSATILE
> bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5
> - depends on ARCH_MULTI_V5
> + depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
> default y if ARM_SINGLE_ARCH_VERSATILE
>
> adding the versatile entry in the upper level choice (where it always used
> to be) but with "ARM_SINGLE_ARCH_VERSATILE" instead.
>
> This would have the effect of allowing the multiplatform-converted stuff
> to start being used on nommu (again) but without running into the problems
> I've highlighted.
>
^ permalink raw reply
* [PATCH renesas/devel 01/13] ARM: dts: r8a7779: Use R-Car Gen 1 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-2-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 1 fallback binding for i2c nodes in
> DT for r8a7779 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7779 and the
> fallback binding for R-Car Gen 1.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 02/13] ARM: dts: r8a7778: Use R-Car Gen 1 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-3-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 1 fallback binding for i2c nodes in
> DT for r8a7778 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7778 and the
> fallback binding for R-Car Gen 1.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 03/13] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-4-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for i2c nodes in
> DT for r8a7790 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7790 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v7 1/8] Documentation: arm: define DT cpu capacity-dmips-mhz bindings
From: Juri Lelli @ 2016-12-12 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212124005.GA19177@red-moon>
On 12/12/16 12:40, Lorenzo Pieralisi wrote:
> On Mon, Sep 05, 2016 at 03:22:45PM +0100, Juri Lelli wrote:
>
> [...]
>
> > +===========================================
> > +5 - References
> > +===========================================
> > +
> > +[1] ARM Linux Kernel documentation - CPUs bindings
> > + Documentation/devicetree/bindings/arm/cpus.txt
> > diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> > index e6782d50cbcd..c1dcf4cade2e 100644
> > --- a/Documentation/devicetree/bindings/arm/cpus.txt
> > +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> > @@ -241,6 +241,14 @@ nodes to be present and contain the properties described below.
> > # List of phandles to idle state nodes supported
> > by this cpu [3].
> >
> > + - capacity-dmips-mhz
> > + Usage: Optional
> > + Value type: <u32>
> > + Definition:
> > + # u32 value representing CPU capacity [3] in
> > + DMIPS/MHz, relative to highest capacity-dmips-mhz
> > + in the system.
> > +
> > - rockchip,pmu
> > Usage: optional for systems that have an "enable-method"
> > property value of "rockchip,rk3066-smp"
> > @@ -464,3 +472,5 @@ cpus {
> > [2] arm/msm/qcom,kpss-acc.txt
> > [3] ARM Linux kernel documentation - idle states bindings
> > Documentation/devicetree/bindings/arm/idle-states.txt
> > +[3] ARM Linux kernel documentation - cpu capacity bindings
> > + Documentation/devicetree/bindings/arm/cpu-capacity.txt
>
> Trivia: bumped into this while reviewing something else, too many
> threes, you will have to fix the added reference up.
Argh! Fixed locally, thanks for catching it.
Best,
- Juri
^ permalink raw reply
* [PATCH renesas/devel 04/13] ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-5-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for i2c nodes in
> DT for r8a7791 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7791 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 05/13] ARM: dts: r8a7792: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-6-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for i2c nodes in
> DT for r8a7792 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7792 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox