* [PATCH v2 09/12] ARM: debug: Add low level debug support for imx6sll
From: Bai Ping @ 2016-12-27 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482832070-22668-1-git-send-email-ping.bai@nxp.com>
Add low level debug support for i.MX6SLL.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
---
arch/arm/Kconfig.debug | 9 +++++++++
arch/arm/include/debug/imx-uart.h | 10 ++++++++++
2 files changed, 19 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 408540f..d52d48c 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -405,6 +405,13 @@ choice
Say Y here if you want kernel low-level debugging support
on i.MX6SL.
+ config DEBUG_IMX6SLL_UART
+ bool "i.MX6SLL Debug UART"
+ depends on SOC_IMX6SLL
+ help
+ Say Y here if you want kernel low-level debugging support
+ on i.MX6SLL.
+
config DEBUG_IMX6SX_UART
bool "i.MX6SX Debug UART"
depends on SOC_IMX6SX
@@ -1374,6 +1381,7 @@ config DEBUG_IMX_UART_PORT
DEBUG_IMX53_UART || \
DEBUG_IMX6Q_UART || \
DEBUG_IMX6SL_UART || \
+ DEBUG_IMX6SLL_UART || \
DEBUG_IMX6SX_UART || \
DEBUG_IMX6UL_UART || \
DEBUG_IMX7D_UART
@@ -1428,6 +1436,7 @@ config DEBUG_LL_INCLUDE
DEBUG_IMX53_UART ||\
DEBUG_IMX6Q_UART || \
DEBUG_IMX6SL_UART || \
+ DEBUG_IMX6SLL_UART || \
DEBUG_IMX6SX_UART || \
DEBUG_IMX6UL_UART || \
DEBUG_IMX7D_UART
diff --git a/arch/arm/include/debug/imx-uart.h b/arch/arm/include/debug/imx-uart.h
index bce58e9..24e60ce 100644
--- a/arch/arm/include/debug/imx-uart.h
+++ b/arch/arm/include/debug/imx-uart.h
@@ -81,6 +81,14 @@
#define IMX6SL_UART_BASE_ADDR(n) IMX6SL_UART##n##_BASE_ADDR
#define IMX6SL_UART_BASE(n) IMX6SL_UART_BASE_ADDR(n)
+#define IMX6SLL_UART1_BASE_ADDR 0x02020000
+#define IMX6SLL_UART2_BASE_ADDR 0x02024000
+#define IMX6SLL_UART3_BASE_ADDR 0x02034000
+#define IMX6SLL_UART4_BASE_ADDR 0x02018000
+#define IMX6SLL_UART5_BASE_ADDR 0x021f4000
+#define IMX6SLL_UART_BASE_ADDR(n) IMX6SLL_UART##n##_BASE_ADDR
+#define IMX6SLL_UART_BASE(n) IMX6SLL_UART_BASE_ADDR(n)
+
#define IMX6SX_UART1_BASE_ADDR 0x02020000
#define IMX6SX_UART2_BASE_ADDR 0x021e8000
#define IMX6SX_UART3_BASE_ADDR 0x021ec000
@@ -133,6 +141,8 @@
#define UART_PADDR IMX_DEBUG_UART_BASE(IMX6Q)
#elif defined(CONFIG_DEBUG_IMX6SL_UART)
#define UART_PADDR IMX_DEBUG_UART_BASE(IMX6SL)
+#elif defined(CONFIG_DEBUG_IMX6SLL_UART)
+#define UART_PADDR IMX_DEBUG_UART_BASE(IMX6SLL)
#elif defined(CONFIG_DEBUG_IMX6SX_UART)
#define UART_PADDR IMX_DEBUG_UART_BASE(IMX6SX)
#elif defined(CONFIG_DEBUG_IMX6UL_UART)
--
1.9.1
^ permalink raw reply related
* [PATCH v2 10/12] ARM: imx: Add suspend/resume support for imx6sll
From: Bai Ping @ 2016-12-27 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482832070-22668-1-git-send-email-ping.bai@nxp.com>
Add suspend/resume support for imx6sll.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
---
arch/arm/mach-imx/pm-imx6.c | 32 +++++++++++++++++++++++++++-----
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
index 1515e49..2ed4316 100644
--- a/arch/arm/mach-imx/pm-imx6.c
+++ b/arch/arm/mach-imx/pm-imx6.c
@@ -145,6 +145,13 @@ struct imx6_pm_socdata {
0x494, 0x4b0, /* MODE_CTL, MODE, */
};
+static const u32 imx6sll_mmdc_io_offset[] __initconst = {
+ 0x294, 0x298, 0x29c, 0x2a0, /* DQM0 ~ DQM3 */
+ 0x544, 0x54c, 0x554, 0x558, /* GPR_B0DS ~ GPR_B3DS */
+ 0x530, 0x540, 0x2ac, 0x52c, /* MODE_CTL, MODE, SDCLK_0, GPR_ADDDS */
+ 0x2a4, 0x2a8, /* SDCKE0, SDCKE1*/
+};
+
static const struct imx6_pm_socdata imx6q_pm_data __initconst = {
.mmdc_compat = "fsl,imx6q-mmdc",
.src_compat = "fsl,imx6q-src",
@@ -195,6 +202,15 @@ struct imx6_pm_socdata {
.mmdc_io_offset = imx6ul_mmdc_io_offset,
};
+static const struct imx6_pm_socdata imx6sll_pm_data __initconst = {
+ .mmdc_compat = "fsl,imx6sll-mmdc",
+ .src_compat = "fsl,imx6sll-src",
+ .iomuxc_compat = "fsl,imx6sll-iomuxc",
+ .gpc_compat = "fsl,imx6sll-gpc",
+ .pl310_compat = "arm,pl310-cache",
+ .mmdc_io_num = ARRAY_SIZE(imx6sll_mmdc_io_offset),
+ .mmdc_io_offset = imx6sll_mmdc_io_offset,
+};
/*
* This structure is for passing necessary data for low level ocram
* suspend code(arch/arm/mach-imx/suspend-imx6.S), if this struct
@@ -293,9 +309,10 @@ int imx6_set_lpm(enum mxc_cpu_pwr_mode mode)
val |= 0x2 << BP_CLPCR_LPM;
val &= ~BM_CLPCR_VSTBY;
val &= ~BM_CLPCR_SBYOS;
- if (cpu_is_imx6sl())
+ if (cpu_is_imx6sl() || cpu_is_imx6sll())
val |= BM_CLPCR_BYPASS_PMIC_READY;
- if (cpu_is_imx6sl() || cpu_is_imx6sx() || cpu_is_imx6ul())
+ if (cpu_is_imx6sl() || cpu_is_imx6sx() || cpu_is_imx6ul() ||
+ cpu_is_imx6sll())
val |= BM_CLPCR_BYP_MMDC_CH0_LPM_HS;
else
val |= BM_CLPCR_BYP_MMDC_CH1_LPM_HS;
@@ -310,9 +327,10 @@ int imx6_set_lpm(enum mxc_cpu_pwr_mode mode)
val |= 0x3 << BP_CLPCR_STBY_COUNT;
val |= BM_CLPCR_VSTBY;
val |= BM_CLPCR_SBYOS;
- if (cpu_is_imx6sl() || cpu_is_imx6sx())
+ if (cpu_is_imx6sl() || cpu_is_imx6sx() || cpu_is_imx6sll())
val |= BM_CLPCR_BYPASS_PMIC_READY;
- if (cpu_is_imx6sl() || cpu_is_imx6sx() || cpu_is_imx6ul())
+ if (cpu_is_imx6sl() || cpu_is_imx6sx() ||
+ cpu_is_imx6ul() || cpu_is_imx6sll())
val |= BM_CLPCR_BYP_MMDC_CH0_LPM_HS;
else
val |= BM_CLPCR_BYP_MMDC_CH1_LPM_HS;
@@ -373,6 +391,7 @@ static int imx6q_pm_enter(suspend_state_t state)
imx6sl_set_wait_clk(true);
/* Zzz ... */
cpu_do_idle();
+
if (cpu_is_imx6sl())
imx6sl_set_wait_clk(false);
imx_gpc_post_resume();
@@ -632,7 +651,10 @@ void __init imx6dl_pm_init(void)
void __init imx6sl_pm_init(void)
{
- imx6_pm_common_init(&imx6sl_pm_data);
+ if (cpu_is_imx6sl())
+ imx6_pm_common_init(&imx6sl_pm_data);
+ else
+ imx6_pm_common_init(&imx6sll_pm_data);
}
void __init imx6sx_pm_init(void)
--
1.9.1
^ permalink raw reply related
* [PATCH v2 11/12] ARM: imx: correct i.mx6sll dram io low power mode
From: Bai Ping @ 2016-12-27 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482832070-22668-1-git-send-email-ping.bai@nxp.com>
i.MX6SLL has different DRAM IO offset, and it has no
CAS/RAS/ODT/RESET pin now, correct the DRAM IO offset.
To better support all different i.MX6 SoCs and different
DRAM types, introduce a new column to store the low power
settings for DRAM IO, then suspend asm code no need to check
SoC or DRAM type, just get the DRAM IO's low power
settings from OCRAM pm_info and set to each DRAM IO.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Bai Ping <ping.bai@nxp.com>
---
arch/arm/mach-imx/pm-imx6.c | 17 ++++++++++++++++-
arch/arm/mach-imx/suspend-imx6.S | 29 +++++++----------------------
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
index 2ed4316..5fb78a9 100644
--- a/arch/arm/mach-imx/pm-imx6.c
+++ b/arch/arm/mach-imx/pm-imx6.c
@@ -230,7 +230,7 @@ struct imx6_cpu_pm_info {
struct imx6_pm_base gpc_base;
struct imx6_pm_base l2_base;
u32 mmdc_io_num; /* Number of MMDC IOs which need saved/restored. */
- u32 mmdc_io_val[MX6_MAX_MMDC_IO_NUM][2]; /* To save offset and value */
+ u32 mmdc_io_val[MX6_MAX_MMDC_IO_NUM][3]; /* To save offset,value and low power setting */
} __aligned(8);
void imx6_set_int_mem_clk_lpm(bool enable)
@@ -570,6 +570,21 @@ static int __init imx6q_suspend_init(const struct imx6_pm_socdata *socdata)
pm_info->mmdc_io_val[i][1] =
readl_relaxed(pm_info->iomuxc_base.vbase +
mmdc_offset_array[i]);
+ pm_info->mmdc_io_val[i][2] = 0;
+
+ }
+
+ /* i.MX6SLL has no DRAM RESET pin */
+ if (cpu_is_imx6sll()) {
+ pm_info->mmdc_io_val[pm_info->mmdc_io_num - 2][2] = 0x1000;
+ pm_info->mmdc_io_val[pm_info->mmdc_io_num - 1][2] = 0x1000;
+ } else {
+ if (pm_info->ddr_type == IMX_DDR_TYPE_LPDDR2) {
+ /* for LPDDR2, CKE0/1 and RESET pin need special setting */
+ pm_info->mmdc_io_val[pm_info->mmdc_io_num - 3][2] = 0x1000;
+ pm_info->mmdc_io_val[pm_info->mmdc_io_num - 2][2] = 0x1000;
+ pm_info->mmdc_io_val[pm_info->mmdc_io_num - 1][2] = 0x80000;
+ }
}
imx6_suspend_in_ocram_fn = fncpy(
diff --git a/arch/arm/mach-imx/suspend-imx6.S b/arch/arm/mach-imx/suspend-imx6.S
index 76ee2ce..c9a26f4 100644
--- a/arch/arm/mach-imx/suspend-imx6.S
+++ b/arch/arm/mach-imx/suspend-imx6.S
@@ -104,7 +104,7 @@
add r7, r7, r0
1:
ldr r8, [r7], #0x4
- ldr r9, [r7], #0x4
+ ldr r9, [r7], #0x8
str r9, [r11, r8]
subs r6, r6, #0x1
bne 1b
@@ -179,7 +179,6 @@ ENTRY(imx6_suspend)
ldr r11, [r0, #PM_INFO_MX6Q_IOMUXC_V_OFFSET]
ldr r6, [r11, #0x0]
- /* use r11 to store the IO address */
ldr r11, [r0, #PM_INFO_MX6Q_SRC_V_OFFSET]
/* store physical resume addr and pm_info address. */
str r9, [r11, #MX6Q_SRC_GPR1]
@@ -207,32 +206,18 @@ poll_dvfs_set:
ands r7, r7, #(1 << 25)
beq poll_dvfs_set
+ /* use r11 to store the IO address */
ldr r11, [r0, #PM_INFO_MX6Q_IOMUXC_V_OFFSET]
- ldr r6, =0x0
- ldr r7, [r0, #PM_INFO_MMDC_IO_NUM_OFFSET]
+ ldr r6, [r0, #PM_INFO_MMDC_IO_NUM_OFFSET]
ldr r8, =PM_INFO_MMDC_IO_VAL_OFFSET
add r8, r8, r0
- /* LPDDR2's last 3 IOs need special setting */
- cmp r3, #IMX_DDR_TYPE_LPDDR2
- subeq r7, r7, #0x3
set_mmdc_io_lpm:
- ldr r9, [r8], #0x8
- str r6, [r11, r9]
- subs r7, r7, #0x1
+ ldr r7, [r8], #0x8
+ ldr r9, [r8], #0x4
+ str r9, [r11, r7]
+ subs r6, r6, #0x1
bne set_mmdc_io_lpm
- cmp r3, #IMX_DDR_TYPE_LPDDR2
- bne set_mmdc_io_lpm_done
- ldr r6, =0x1000
- ldr r9, [r8], #0x8
- str r6, [r11, r9]
- ldr r9, [r8], #0x8
- str r6, [r11, r9]
- ldr r6, =0x80000
- ldr r9, [r8]
- str r6, [r11, r9]
-set_mmdc_io_lpm_done:
-
/*
* mask all GPC interrupts before
* enabling the RBC counters to
--
1.9.1
^ permalink raw reply related
* [PATCH v2 12/12] ARM: configs: enable imx6sll support in defconfig
From: Bai Ping @ 2016-12-27 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482832070-22668-1-git-send-email-ping.bai@nxp.com>
Enable i.MX6SLL in imx_v6_v7_defconfig.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index cbe7faf..ab8afb3 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -38,6 +38,7 @@ CONFIG_SOC_IMX51=y
CONFIG_SOC_IMX53=y
CONFIG_SOC_IMX6Q=y
CONFIG_SOC_IMX6SL=y
+CONFIG_SOC_IMX6SLL=y
CONFIG_SOC_IMX6SX=y
CONFIG_SOC_IMX6UL=y
CONFIG_SOC_IMX7D=y
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
From: Herbert Xu @ 2016-12-27 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481207339-17332-1-git-send-email-ard.biesheuvel@linaro.org>
On Thu, Dec 08, 2016 at 02:28:57PM +0000, Ard Biesheuvel wrote:
> Another port of existing x86 SSE code to NEON, again both for arm64 and ARM.
>
> ChaCha20 is a stream cipher described in RFC 7539, and is intended to be
> an efficient software implementable 'standby cipher', in case AES cannot
> be used.
>
> This NEON implementation is almost 2x as fast as the generic C code
> (measured on Cortex-A57 using the arm64 version)
>
> I'm aware that blkciphers are deprecated in favor of skciphers, but this
> code (like the x86 version) uses the init and setkey routines of the generic
> version, so it is probably better to port all implementations at once.
>
> Ard Biesheuvel (2):
> crypto: arm64/chacha20 - implement NEON version based on SSE3 code
> crypto: arm/chacha20 - implement NEON version based on SSE3 code
Both patches applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher
From: Herbert Xu @ 2016-12-27 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481294033-23508-2-git-send-email-ard.biesheuvel@linaro.org>
On Fri, Dec 09, 2016 at 02:33:51PM +0000, Ard Biesheuvel wrote:
> This converts the ChaCha20 code from a blkcipher to a skcipher, which
> is now the preferred way to implement symmetric block and stream ciphers.
>
> This ports the generic and x86 versions at the same time because the
> latter reuses routines of the former.
>
> Note that the skcipher_walk() API guarantees that all presented blocks
> except the final one are a multiple of the chunk size, so we can simplify
> the encrypt() routine somewhat.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 1/6] ARM: mach-mx31_3ds: Remove camera support
From: Magnus Lilja @ 2016-12-27 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482756987-12414-1-git-send-email-festevam@gmail.com>
Hi
On 26 December 2016 at 13:56, Fabio Estevam <festevam@gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Since commit c93cc61475ebbe6e66 ("[media] staging/media: remove deprecated
> mx3 driver") the mx3 camera driver has been removed, so remove the camera
> support from the board file as well.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> arch/arm/mach-imx/mach-mx31_3ds.c | 145 --------------------------------------
> 1 file changed, 145 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c b/arch/arm/mach-imx/mach-mx31_3ds.c
> index 12b8a52..ada29d0 100644
> --- a/arch/arm/mach-imx/mach-mx31_3ds.c
> +++ b/arch/arm/mach-imx/mach-mx31_3ds.c
...
> -#define MX31_3DS_GPIO_CAMERA_PW IOMUX_TO_GPIO(MX31_PIN_CSI_D5)
> -#define MX31_3DS_GPIO_CAMERA_RST IOMUX_TO_GPIO(MX31_PIN_RI_DTE1)
> -
> -static struct gpio mx31_3ds_camera_gpios[] = {
> - { MX31_3DS_GPIO_CAMERA_PW, GPIOF_OUT_INIT_HIGH, "camera-power" },
> - { MX31_3DS_GPIO_CAMERA_RST, GPIOF_OUT_INIT_HIGH, "camera-reset" },
> -};
...
> static void __init mx31_3ds_late(void)
> {
> - int ret;
> -
> mx31_3ds_spi_devs[0].irq = gpio_to_irq(IOMUX_TO_GPIO(MX31_PIN_GPIO1_3));
> spi_register_board_info(mx31_3ds_spi_devs,
> ARRAY_SIZE(mx31_3ds_spi_devs));
>
> - platform_add_devices(devices, ARRAY_SIZE(devices));
> -
> mx31_3ds_usbotg_init();
> if (otg_mode_host) {
> otg_pdata.otg = imx_otg_ulpi_create(ULPI_OTG_DRVVBUS |
> @@ -751,17 +625,6 @@ static void __init mx31_3ds_late(void)
> "devices on the debug board are unusable.\n");
>
> imx31_add_mxc_mmc(0, &sdhc1_pdata);
> -
> - /* CSI */
> - /* Camera power: default - off */
> - ret = gpio_request_array(mx31_3ds_camera_gpios,
> - ARRAY_SIZE(mx31_3ds_camera_gpios));
> - if (ret) {
> - pr_err("Failed to request camera gpios");
> - iclink_ov2640.power = NULL;
> - }
CSI_D5 is marked as "not floating" by default, as opposed to "input,
pulled up" on many other pins on the i.MX31. That makes me wonder if
it's best to keep the initialization of CSI_D5 and RI_DTE1 to make
sure the pins are set to a defined state (that also will set the
camera off).
Will test the patch on hardware in a couple of days.
Regards, Magnus
^ permalink raw reply
* [PATCH v3 0/2] Add MediaTek crypto accelerator driver
From: Herbert Xu @ 2016-12-27 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482114045-18716-1-git-send-email-ryder.lee@mediatek.com>
On Mon, Dec 19, 2016 at 10:20:43AM +0800, Ryder Lee wrote:
> Hello,
>
> This adds support for the MediaTek hardware accelerator on
> some SoCs.
>
> This driver currently implement:
> - SHA1 and SHA2 family(HMAC) hash algorithms.
> - AES block cipher in CBC/ECB mode with 128/196/256 bits keys.
>
> Chances since v3:
> -remove unused structure member
> -drop interrupt-parent from DT bindings documentation
>
> Changes since v2:
> - use byteorder conversion macros and type identifiers for descriptors
> - revise register definition macros to make it more clear
> - revise DT compatiable string
>
> Changes since v1:
> - remove EXPORT_SYMBOL
> - remove unused PRNG setting
> - sort headers in alphabetical order
> - add a definition for IRQ unmber
> - replace ambiguous definition
> - add more annotation and function comment
> - add COMPILE_TEST in Kconfig
>
> Ryder Lee (2):
> Add crypto driver support for some MediaTek chips
> crypto: mediatek - add DT bindings documentation
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCHv2] crypto: testmgr: Use heap buffer for acomp test input
From: Herbert Xu @ 2016-12-27 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482352374-22750-1-git-send-email-labbott@redhat.com>
On Wed, Dec 21, 2016 at 12:32:54PM -0800, Laura Abbott wrote:
>
> Christopher Covington reported a crash on aarch64 on recent Fedora
> kernels:
>
> kernel BUG at ./include/linux/scatterlist.h:140!
> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 2 PID: 752 Comm: cryptomgr_test Not tainted 4.9.0-11815-ge93b1cc #162
> Hardware name: linux,dummy-virt (DT)
> task: ffff80007c650080 task.stack: ffff800008910000
> PC is at sg_init_one+0xa0/0xb8
> LR is at sg_init_one+0x24/0xb8
> ...
> [<ffff000008398db8>] sg_init_one+0xa0/0xb8
> [<ffff000008350a44>] test_acomp+0x10c/0x438
> [<ffff000008350e20>] alg_test_comp+0xb0/0x118
> [<ffff00000834f28c>] alg_test+0x17c/0x2f0
> [<ffff00000834c6a4>] cryptomgr_test+0x44/0x50
> [<ffff0000080dac70>] kthread+0xf8/0x128
> [<ffff000008082ec0>] ret_from_fork+0x10/0x50
>
> The test vectors used for input are part of the kernel image. These
> inputs are passed as a buffer to sg_init_one which eventually blows up
> with BUG_ON(!virt_addr_valid(buf)). On arm64, virt_addr_valid returns
> false for the kernel image since virt_to_page will not return the
> correct page. Fix this by copying the input vectors to heap buffer
> before setting up the scatterlist.
>
> Reported-by: Christopher Covington <cov@codeaurora.org>
> Fixes: d7db7a882deb ("crypto: acomp - update testmgr with support for acomp")
> Signed-off-by: Laura Abbott <labbott@redhat.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 5/9] pinctrl: samsung: Move retention control from mach-exynos to the pinctrl driver
From: Marek Szyprowski @ 2016-12-27 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+Ln22HQPHF_Vj0kS834SH=4=hcNOpe_vL8P3fbS-jFhQLVyXA@mail.gmail.com>
Hi Tomasz,
On 2016-12-26 06:55, Tomasz Figa wrote:
> 2016-12-23 21:24 GMT+09:00 Marek Szyprowski <m.szyprowski@samsung.com>:
>> Pad retention control after suspend/resume cycle should be done from pin
>> controller driver instead of PMU (power management unit) driver to avoid
>> possible ordering and logical dependencies. Till now it worked fine only
>> because PMU driver registered its sys_ops after pin controller.
>>
>> This patch moves pad retention control from PMU driver to Exynos pin
>> controller driver. This is a preparation for adding new features to Exynos
>> pin controller driver, like runtime power management and suspending
>> individual pin controllers, which might be a part of some power domain.
>>
> It looks like this change will essentially break the compatibility
> with DTBs that don't have the pmu syscon specified in pin controller
> nodes.
>
> On the other hand, moving this code to where it actually belongs
> really makes sense, so maybe we could just avoid the need of having
> this property, by looking up the PMU manually, by hardcoded string or
> so, if the proper property is not present?
Well, once again the topic of mythical device tree compatibility appearch.
There are imho following possibilities:
1. https://patchwork.kernel.org/patch/9477963/ ("Explicitly mark Samsung
Exynos SoC bindings as unstable"), simply apply this approach and ignore
users, who don't update their device tree blobs (are there any??).
2. Switch to syscon_regmap_lookup_by_compatible() lookup and hardcode PMU
compatible id for all Exynos SoCs in the pin control driver. Then maybe,
while unifying the code, switch other Exynos drivers to this approach
and remove PMU phandles from device tree to make the code a bit more
consistent across drivers and easier to understand.
3. Mixed approach, which combines drawbacks of both approaches. Additional
dead code for handling mythical compatibility and harder to understand
relations between the drivers.
> [...]
>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>> index 1baf19eecabf..b7bd2e12a269 100644
>> --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>> +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>> @@ -43,6 +43,10 @@ Required Properties:
>> };
>> };
>>
>> +- samsung,pmu-syscon: Phandle to the PMU system controller, to let driver
>> + to control pad retention after system suspend/resume cycle (only for Exynos
>> + SoC series).
>> +
> Ah, here it is. I think adding relevant binding documentation at the
> beginning of the series would make it much easier for reviewers to
> understand the change.
I already pointed that patches are ordered to make the changes
bisectable, what
usually means that new properties are added first, before being required
by the
drivers.
>
>> - Pin banks as child nodes: Pin banks of the controller are represented by child
>> nodes of the controller node. Bank name is taken from name of the node. Each
>> bank node must contain following properties:
> [...]
>
>> +static void exynos_retention_audio_off(struct samsung_pinctrl_drv_data *drvdata)
>> +{
>> + if (!IS_ERR(pmu_regs))
> nit: Negated conditions make the code more difficult to read. Also it
> would be consistent with exynos_retention_off() to just bail out if
> (IS_ERR(pmu_regs)).
>
>> + regmap_write(pmu_regs, S5P_PAD_RET_MAUDIO_OPTION,
>> + EXYNOS_WAKEUP_FROM_LOWPWR);
>> +}
> [...]
>
>> @@ -1139,15 +1146,15 @@ static void samsung_pinctrl_suspend_dev(
>>
>> if (drvdata->suspend)
>> drvdata->suspend(drvdata);
>> + if (drvdata->retention_on)
>> + drvdata->retention_on(drvdata);
>> +
> nit: Unnecessary blank line.
>
> Best regards,
> Tomasz
>
>
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH 5/9] pinctrl: samsung: Move retention control from mach-exynos to the pinctrl driver
From: Marek Szyprowski @ 2016-12-27 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161225134228.qlp553c7cdqy6256@kozik-lap>
Hi Krzysztof,
On 2016-12-25 14:42, Krzysztof Kozlowski wrote:
> On Fri, Dec 23, 2016 at 01:24:45PM +0100, Marek Szyprowski wrote:
>> Pad retention control after suspend/resume cycle should be done from pin
>> controller driver instead of PMU (power management unit) driver to avoid
>> possible ordering and logical dependencies. Till now it worked fine only
>> because PMU driver registered its sys_ops after pin controller.
>>
>> This patch moves pad retention control from PMU driver to Exynos pin
>> controller driver. This is a preparation for adding new features to Exynos
>> pin controller driver, like runtime power management and suspending
>> individual pin controllers, which might be a part of some power domain.
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> ---
>> .../bindings/pinctrl/samsung-pinctrl.txt | 4 +
>> arch/arm/mach-exynos/suspend.c | 64 ---------
>> drivers/pinctrl/samsung/pinctrl-exynos.c | 148 +++++++++++++++++++++
>> drivers/pinctrl/samsung/pinctrl-samsung.c | 16 ++-
>> drivers/pinctrl/samsung/pinctrl-samsung.h | 13 ++
>> 5 files changed, 178 insertions(+), 67 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>> index 1baf19eecabf..b7bd2e12a269 100644
>> --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>> +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>> @@ -43,6 +43,10 @@ Required Properties:
>> };
>> };
>>
>> +- samsung,pmu-syscon: Phandle to the PMU system controller, to let driver
>> + to control pad retention after system suspend/resume cycle (only for Exynos
>> + SoC series).
>> +
>> - Pin banks as child nodes: Pin banks of the controller are represented by child
>> nodes of the controller node. Bank name is taken from name of the node. Each
>> bank node must contain following properties:
>> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
> [...]
>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> index 12f7d1eb65bc..55c1104a1ccf 100644
>> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> @@ -24,11 +24,15 @@
>> #include <linux/irqdomain.h>
>> #include <linux/irq.h>
>> #include <linux/irqchip/chained_irq.h>
>> +#include <linux/mfd/syscon.h>
>> #include <linux/of_irq.h>
>> #include <linux/io.h>
>> #include <linux/slab.h>
>> #include <linux/spinlock.h>
>> +#include <linux/regmap.h>
>> #include <linux/err.h>
>> +#include <linux/soc/samsung/exynos-regs-pmu.h>
>> +
>>
>> #include "pinctrl-samsung.h"
>> #include "pinctrl-exynos.h"
>> @@ -633,6 +637,46 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
>> exynos_pinctrl_resume_bank(drvdata, bank);
>> }
>>
>> +static atomic_t exynos_retention_refcnt;
>> +static struct regmap *pmu_regs;
>> +
>> +static int exynos_retention_init(struct samsung_pinctrl_drv_data *drvdata)
>> +{
>> + struct device *dev = drvdata->dev;
>> +
>> + pmu_regs = syscon_regmap_lookup_by_phandle(dev->of_node,
>> + "samsung,pmu-syscon");
>> + if (IS_ERR(pmu_regs)) {
>> + dev_err(dev, "failed to lookup PMU regmap, no support for pad retention\n");
>> + return PTR_ERR(pmu_regs);
>> + }
>> + return 0;
>> +}
>> +
>> +static void exynos_retention_on(struct samsung_pinctrl_drv_data *drvdata)
>> +{
>> + atomic_inc(&exynos_retention_refcnt);
> As this does not imply memory barriers, so maybe you need smp_mb__after_atomic()?
exynos_retention_refcnt will be read/tested after suspend/resume cycle,
so I doubt
that any kind of barrier is needed here.
>
> You didn't describe the need behind this barrier. What do you want to
> protect? Do you expect suspend (or resume) happening multiple times for
> one device? Or maybe you expect even mixing of these by different CPUs?
There are more than one instance of pinctrl devices on Exynos4+ SoCs and
they have
common retention regs. All those controllers might be resumed in
parallel, so this
atomic counting is needed to ensure that retention will be disabled when
the last
instance is being resumed.
>> +}
>> +
>> +static void exynos_retention_off(struct samsung_pinctrl_drv_data *drvdata)
>> +{
>> + int i;
>> +
>> + if (!atomic_dec_and_test(&exynos_retention_refcnt) || IS_ERR(pmu_regs))
>> + return;
>> +
>> + for (i = 0; i < drvdata->nr_retention_regs; i++)
>> + regmap_write(pmu_regs, drvdata->retention_regs[i],
>> + EXYNOS_WAKEUP_FROM_LOWPWR);
>> +}
>> +
>> +static void exynos_retention_audio_off(struct samsung_pinctrl_drv_data *drvdata)
>> +{
>> + if (!IS_ERR(pmu_regs))
>> + regmap_write(pmu_regs, S5P_PAD_RET_MAUDIO_OPTION,
>> + EXYNOS_WAKEUP_FROM_LOWPWR);
>> +}
>> +
> [...]
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH 6/9] pinctrl: samsung: Replace syscore ops with standard platform device pm_ops
From: Marek Szyprowski @ 2016-12-27 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+Ln22G80htJ6Va4hSD7ML3=h5QKUhdHm9X3Znnj1KBjyOrROw@mail.gmail.com>
Hi Krzysztof,
On 2016-12-26 06:57, Tomasz Figa wrote:
> 2016-12-23 21:24 GMT+09:00 Marek Szyprowski <m.szyprowski@samsung.com>:
>> Once the dependency on PMU driver (for pad retention control) has been
>> removed, there is no reason to use syscore_ops based suspend/resume.
> Does it also hold true for other platforms using this driver? I.e.
> s3c24xx, s3c64xx and s5pv210?
I've checked and I didn't find any code related to retention control in
s3c24xx and 23c64xx, but you are right that I need to add support for
s5pv210 (retention is controlled via S5P_OTHERS register). Thanks for
pointing this.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v4] mm: pmd dirty emulation in page fault handler
From: Michal Hocko @ 2016-12-27 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482506098-6149-1-git-send-email-minchan@kernel.org>
On Sat 24-12-16 00:14:58, Minchan Kim wrote:
> Andreas reported [1] made a test in jemalloc hang in THP mode in arm64.
> http://lkml.kernel.org/r/mvmmvfy37g1.fsf at hawking.suse.de
>
> The problem is currently page fault handler doesn't supports dirty bit
> emulation of pmd for non-HW dirty-bit architecture so that application
> stucks until VM marked the pmd dirty.
>
> How the emulation work depends on the architecture. In case of arm64,
> when it set up pte firstly, it sets pte PTE_RDONLY to get a chance to
> mark the pte dirty via triggering page fault when store access happens.
> Once the page fault occurs, VM marks the pmd dirty and arch code for
> setting pmd will clear PTE_RDONLY for application to proceed.
>
> IOW, if VM doesn't mark the pmd dirty, application hangs forever by
> repeated fault(i.e., store op but the pmd is PTE_RDONLY).
>
> This patch enables pmd dirty-bit emulation for those architectures.
Thanks for extending the patch description again!
> [1] b8d3c4c3009d, mm/huge_memory.c: don't split THP page when MADV_FREE syscall is called
>
> Cc: Jason Evans <je@fb.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: linux-arch at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: <stable@vger.kernel.org> [4.5+]
> Fixes: b8d3c4c3009d ("mm/huge_memory.c: don't split THP page when MADV_FREE syscall is called")
> Reported-and-Tested-by: Andreas Schwab <schwab@suse.de>
> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Signed-off-by: Minchan Kim <minchan@kernel.org>
Acked-by: Michal Hocko <mhocko@suse.com>
> ---
> Merry Xmas!
>
> * from v3
> * Elaborate description
> * from v2
> * Add acked-by/tested-by
> * from v1
> * Remove __handle_mm_fault part - Kirill
> mm/huge_memory.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 10eedbf..29ec8a4 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -883,15 +883,17 @@ void huge_pmd_set_accessed(struct vm_fault *vmf, pmd_t orig_pmd)
> {
> pmd_t entry;
> unsigned long haddr;
> + bool write = vmf->flags & FAULT_FLAG_WRITE;
>
> vmf->ptl = pmd_lock(vmf->vma->vm_mm, vmf->pmd);
> if (unlikely(!pmd_same(*vmf->pmd, orig_pmd)))
> goto unlock;
>
> entry = pmd_mkyoung(orig_pmd);
> + if (write)
> + entry = pmd_mkdirty(entry);
> haddr = vmf->address & HPAGE_PMD_MASK;
> - if (pmdp_set_access_flags(vmf->vma, haddr, vmf->pmd, entry,
> - vmf->flags & FAULT_FLAG_WRITE))
> + if (pmdp_set_access_flags(vmf->vma, haddr, vmf->pmd, entry, write))
> update_mmu_cache_pmd(vmf->vma, vmf->address, vmf->pmd);
>
> unlock:
> --
> 2.7.4
>
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH] PCI: exynos: refactor exynos pcie driver
From: Jaehoon Chung @ 2016-12-27 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58620B5A.1060900@samsung.com>
Dear Alim,
On 12/27/2016 03:34 PM, Alim Akhtar wrote:
> Hi Jaehoon,
>
[snip]
>>
>> Ah. Right..And i'm doing the refactoring to reuse the current pci-exynos.c.
> There is a nice refactoring patch posted by Pankaj recently @
> https://lkml.org/lkml/2016/12/23/73
> I would suggest you to rebase your work on this top.
Well, i don't think so. Pankaj's patch might be good way..but i can't agree about a few point.
If based on Pankaj's patch, it's more complex..
why put the ops callback for getting clock and mem resource?
If PHY generic framework is used, it's unnecessary. because it needs to get elbi and dbi resources.
clock resources("pcie" and "pcie_bus") are general things.
If Pankaj's patch is applied, also need to make the exynos5433_pcie_* callback functions?
It doesn't make sense.
I want to know maintainer's opinion..we can just touch a little for supporting All Exynos SoCs.
Best Regards,
Jaehoon Chung
>
>> Maybe..Today or Tomorrow..I will send the patches..At that time, could you also check them?
>> Any comments might be helpful to me! :)
>>
> Will wait for you patches :-)
>
>> Best Regards,
>> Jaehoon Chung
>>
[snip]
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Use axp209.dtsi for Olinuxino Lime2
From: Emmanuel Vadot @ 2016-12-27 10:22 UTC (permalink / raw)
To: linux-arm-kernel
Use axp209.dtsi in sun7i-a20-olinuxino-lime2.dts and correct
some regulators.
DCDC2 is used for vdd-cpu so it should never be bellow 1V and above 1.4V
DCDC3 is used for VDD_INT so same as above.
LD01 is used for the RTC, and should have a typical value of 1.3V
LD02 is used for AVCC and should have a typical value of 3.0V
LD03/4 are used for Port-E/Port-G Power pin, and the schematics recommands
to set them to 2.8V as they can be used for CSI0/1.
Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 90 ++++++++++++-------------
1 file changed, 42 insertions(+), 48 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index d5c796c8d16f..5311dbce6fd9 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -112,57 +112,9 @@
status = "okay";
axp209: pmic at 34 {
- compatible = "x-powers,axp209";
reg = <0x34>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
-
- acin-supply = <®_axp_ipsout>;
- vin2-supply = <®_axp_ipsout>;
- vin3-supply = <®_axp_ipsout>;
- ldo24in-supply = <®_axp_ipsout>;
- ldo3in-supply = <®_axp_ipsout>;
-
- regulators {
- vdd_rtc: ldo1 {
- regulator-min-microvolt = <1300000>;
- regulator-max-microvolt = <1300000>;
- regulator-always-on;
- };
-
- avcc: ldo2 {
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- vcc_csi0: ldo3 {
- regulator-min-microvolt = <700000>;
- regulator-max-microvolt = <3500000>;
- regulator-always-on;
- };
-
- vcc_csi1: ldo4 {
- regulator-min-microvolt = <1250000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- vdd_cpu: dcdc2 {
- regulator-min-microvolt = <700000>;
- regulator-max-microvolt = <2275000>;
- regulator-always-on;
- };
-
- vdd_int: dcdc3 {
- regulator-min-microvolt = <700000>;
- regulator-max-microvolt = <3500000>;
- regulator-always-on;
- };
- };
};
};
@@ -243,6 +195,48 @@
status = "okay";
};
+#include "axp209.dtsi"
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <1300000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "avcc";
+};
+
+®_ldo3 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-name = "vddio-csi0";
+};
+
+®_ldo4 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-name = "vddio-csi1";
+};
+
®_usb0_vbus {
pinctrl-0 = <&usb0_vbus_pin_lime2>;
gpio = <&pio 2 17 GPIO_ACTIVE_HIGH>;
--
2.11.0
^ permalink raw reply related
* [PATCH v3] ARM: dts: sunxi: Add num-cs for A20 spi nodes
From: Emmanuel Vadot @ 2016-12-27 10:28 UTC (permalink / raw)
To: linux-arm-kernel
The spi0 controller on the A20 have up to 4 CS (Chip Select) while the
others three only have 1.
Add the num-cs property to each node.
The current driver doesn't read this property but this is useful for
downstream user of DTS (FreeBSD for example).
Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
---
Changes in v3:
* Put number in bracket
Changes in v2:
* Explain that driver doesn't support this but that it is useful
for downstream users of DTS.
arch/arm/boot/dts/sun7i-a20.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 94cf5a1c7172..f67bea5d0710 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -871,6 +871,7 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+ num-cs = <4>;
};
spi1: spi at 01c06000 {
@@ -885,6 +886,7 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+ num-cs = <1>;
};
emac: ethernet at 01c0b000 {
@@ -1037,6 +1039,7 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+ num-cs = <1>;
};
ahci: sata at 01c18000 {
@@ -1079,6 +1082,7 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+ num-cs = <1>;
};
pio: pinctrl at 01c20800 {
--
2.11.0
^ permalink raw reply related
* [PATCH 4/9] pinctrl: samsung: Use generic of_device_get_match_data helper
From: Bartlomiej Zolnierkiewicz @ 2016-12-27 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161226094142.hajrgye5632mgoup@kozik-lap>
Hi,
On Monday, December 26, 2016 11:41:42 AM Krzysztof Kozlowski wrote:
> On Mon, Dec 26, 2016 at 02:44:26PM +0900, Tomasz Figa wrote:
> > 2016-12-25 21:56 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> > > On Fri, Dec 23, 2016 at 01:24:44PM +0100, Marek Szyprowski wrote:
> > >> Replace custom code with generic helper.
> > >>
> > >> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > >> ---
> > >> drivers/pinctrl/samsung/pinctrl-samsung.c | 9 ++++-----
> > >> 1 file changed, 4 insertions(+), 5 deletions(-)
> > >>
> > >> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> > >> index 4d9262051ff1..a6c2ea74e0f3 100644
> > >> --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> > >> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> > >> @@ -27,6 +27,7 @@
> > >> #include <linux/err.h>
> > >> #include <linux/gpio.h>
> > >> #include <linux/irqdomain.h>
> > >> +#include <linux/of_device.h>
> > >> #include <linux/spinlock.h>
> > >> #include <linux/syscore_ops.h>
> > >>
> > >> @@ -967,15 +968,13 @@ static int samsung_gpiolib_unregister(struct platform_device *pdev,
> > >> return 0;
> > >> }
> > >>
> > >> -static const struct of_device_id samsung_pinctrl_dt_match[];
> > >> -
> > >> /* retrieve the soc specific data */
> > >> static const struct samsung_pin_ctrl *
> > >> samsung_pinctrl_get_soc_data(struct samsung_pinctrl_drv_data *d,
> > >> struct platform_device *pdev)
> > >> {
> > >> int id;
> > >> - const struct of_device_id *match;
> > >> + const struct samsung_pin_ctrl *match_data;
> > >> struct device_node *node = pdev->dev.of_node;
> > >> struct device_node *np;
> > >> const struct samsung_pin_bank_data *bdata;
> > >> @@ -990,8 +989,8 @@ static int samsung_gpiolib_unregister(struct platform_device *pdev,
> > >> dev_err(&pdev->dev, "failed to get alias id\n");
> > >> return ERR_PTR(-ENOENT);
> > >> }
> > >> - match = of_match_node(samsung_pinctrl_dt_match, node);
> > >> - ctrl = (struct samsung_pin_ctrl *)match->data + id;
> > >> + match_data = of_device_get_match_data(&pdev->dev);
> > >> + ctrl = match_data + id;
> > >
> > > Either you need a check for match_data != NULL or just remove match_data
> > > and:
> > > ctrl = of_device_get_match_data();
> > > ctrl += id;
> > >
> > > Actually match_data can be removed even with the check for non-NULL...
> >
> > I don't think this function can ever return NULL if the match array
> > contains a non-NULL value for each compatible string and the driver
> > can be probed only by DT.
>
> Practically it cannot (or it should not) but defensive coding is a good
> practice...
Defensive coding is not a good practice, please don't recommend it.
It usually just obfuscates code and hides underlying issue.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH 7/9] pinctrl: samsung: Add property to mark pad state as suitable for power down
From: Marek Szyprowski @ 2016-12-27 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161225191914.5bzl6fso36ozuum6@kozik-lap>
Hi Krzysztof,
On 2016-12-25 20:19, Krzysztof Kozlowski wrote:
> On Fri, Dec 23, 2016 at 01:24:47PM +0100, Marek Szyprowski wrote:
>> Add support for special property "samsung,off-state", which indicates a special
>> state suitable for device's "sleep" state. Its pin values/properties should
>> match the configuration in power down mode. It indicates that pin controller
>> can notify runtime power management subsystem, that it is ready for runtime
>> suspend if its all pins are configured for such state. This in turn might
>> allow to turn respective power domain off to reduce power consumption.
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> ---
>> Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 8 ++++++++
>> drivers/pinctrl/samsung/pinctrl-samsung.c | 4 ++++
>> drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
>> 3 files changed, 13 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>> index b7bd2e12a269..354eea0e7798 100644
>> --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>> +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>> @@ -105,6 +105,7 @@ Required Properties:
>> - samsung,pin-drv: Drive strength configuration.
>> - samsung,pin-pud-pdn: Pull up/down configuration in power down mode.
>> - samsung,pin-drv-pdn: Drive strength configuration in power down mode.
>> + - samsung,off-state: Mark this configuration as suitable for bank power off.
>>
>> The values specified by these config properties should be derived from the
>> hardware manual and these values are programmed as-is into the pin
>> @@ -113,6 +114,13 @@ Required Properties:
>> Note: A child should include atleast a pin function selection property or
>> pin configuration property (one or more) or both.
>>
>> + Note: Special property "samsung,off-state" indicates that this state can
>> + be used for device's "sleep" pins state. Its pin values/properties should
>> + match the configuration in power down mode.
> Why power down values cannot be used for sleep state? Why you need
> separate pin control state? If pins values should match power down
> configuration, then they could just be added to default state, couldn't
> they?
Separate sleep state is needed because of the pin control bindings and
design.
A separate sleep state is required to let pin control client driver (in
this case
Exynos I2S driver) let to choose when it is okay to switch pads into sleep
state and I see no other way to achieve this.
> In the patch 2/9, existing configuration:
> 716 i2s0_bus: i2s0-bus {
> (...)
> 719 samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
> 720 samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
> 721 samsung,pin-drv = <EXYNOS5420_PIN_DRV_LV1>;
> 722 };
>
> additional configuration:
> + i2s0_bus_slp: i2s0-bus-slp {
> + samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
> + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
> + samsung,pin-drv = <EXYNOS5420_PIN_DRV_LV1>;
> + samsung,pin-con-pdn = <EXYNOS_PIN_PDN_INPUT>;
> + samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>;
> + samsung,off-state;
> + };
I agree that it would be possible to get rid of "samsung,off-state"
property and
just detect off state when func/pud pair matches power down func/pud.
>> It indicates that pin control
>> + can notify runtime power management subsystem, that it is ready for runtime
>> + suspend if its all pins are configured for such state. This in turn might
>> + allow to turn respective power domain off to reduce power consumption.
> What do you mean by "notifying RPM subsystem"? Either this is
> description of hardware in certain mode (sleep state) or this is not
> device tree property.
Maybe I wrote the description with a view too limited to the kernel
operation
perspective, but if we remove the need to mark state as off, the above
description
will not be needed.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH] usb: mtu3: fix U3 port link issue
From: Felipe Balbi @ 2016-12-27 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481095393-23198-1-git-send-email-chunfeng.yun@mediatek.com>
Hi,
Chunfeng Yun <chunfeng.yun@mediatek.com> writes:
> the issue is introduced when @is_u3_ip is used in mtu3_device_enabe()
> before initialized in mtu3_mem_alloc(), so get global IP information
> at first before used by following functins.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
patch doesn't apply to my testing/fixes. Please rebase
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161227/aa13916b/attachment.sig>
^ permalink raw reply
* [PATCH 0/3] MPU-3050 defconfig updates
From: Linus Walleij @ 2016-12-27 12:05 UTC (permalink / raw)
To: linux-arm-kernel
Here are three defconfig patches to the ARM SoC tree that replace
the use of the partial input driver for MPU-3050 with the fully featured
IIO replacement driver.
Please apply these directly for defconfig updates post-v4.10-rc1.
Linus Walleij (3):
ARM: defconfig: replace MPU3050 driver on multi_v7
ARM: defconfig: tegra: switch to MPU3050 IIO driver
ARM: defconfig: pxa: cut MPU3050 input driver
arch/arm/configs/multi_v7_defconfig | 4 +++-
arch/arm/configs/pxa_defconfig | 1 -
arch/arm/configs/tegra_defconfig | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 1/3] ARM: defconfig: replace MPU3050 driver on multi_v7
From: Linus Walleij @ 2016-12-27 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161227120530.31190-1-linus.walleij@linaro.org>
The multi_v7 config enable the MPU3050 gyro input driver, but
there is now a dedicated IIO gyro driver for the same component,
which is the right subsystem to handle this. Replace it in the
defconfig. As we want the full IIO featureset and as other v7
systems will likely enjoy using IIO for their sensor work (such
as the Android-to-IIO userspace HAL), we take this opportunity to
turn on the standard sensor HRtimer triggering.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/configs/multi_v7_defconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index b01a43851294..a4607224289e 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -296,7 +296,6 @@ CONFIG_TOUCHSCREEN_WM97XX=m
CONFIG_INPUT_MISC=y
CONFIG_INPUT_MAX77693_HAPTIC=m
CONFIG_INPUT_MAX8997_HAPTIC=m
-CONFIG_INPUT_MPU3050=y
CONFIG_INPUT_AXP20X_PEK=m
CONFIG_INPUT_ADXL34X=m
CONFIG_SERIO_AMBAKMI=y
@@ -847,15 +846,18 @@ CONFIG_MEMORY=y
CONFIG_EXTCON=y
CONFIG_TI_AEMIF=y
CONFIG_IIO=y
+CONFIG_IIO_SW_TRIGGER=y
CONFIG_AT91_ADC=m
CONFIG_AT91_SAMA5D2_ADC=m
CONFIG_BERLIN2_ADC=m
CONFIG_EXYNOS_ADC=m
CONFIG_VF610_ADC=m
CONFIG_XILINX_XADC=y
+CONFIG_MPU3050_I2C=y
CONFIG_CM36651=m
CONFIG_AK8975=y
CONFIG_RASPBERRYPI_POWER=y
+CONFIG_IIO_HRTIMER_TRIGGER=y
CONFIG_PWM=y
CONFIG_PWM_ATMEL=m
CONFIG_PWM_ATMEL_HLCDC_PWM=m
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] ARM: defconfig: tegra: switch to MPU3050 IIO driver
From: Linus Walleij @ 2016-12-27 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161227120530.31190-1-linus.walleij@linaro.org>
The Tegra is currently configured to use the old input driver for the
MPU-3050. Switch to the new IIO driver.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/configs/tegra_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 844eeef5a509..f0efc854b5a2 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -120,7 +120,6 @@ CONFIG_TOUCHSCREEN_WM97XX=y
# CONFIG_TOUCHSCREEN_WM9713 is not set
CONFIG_TOUCHSCREEN_STMPE=y
CONFIG_INPUT_MISC=y
-CONFIG_INPUT_MPU3050=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_DEVKMEM is not set
CONFIG_SERIAL_8250=y
@@ -263,6 +262,7 @@ CONFIG_ARCH_TEGRA_114_SOC=y
CONFIG_ARCH_TEGRA_124_SOC=y
CONFIG_MEMORY=y
CONFIG_IIO=y
+CONFIG_MPU3050_I2C=y
CONFIG_AK8975=y
CONFIG_PWM=y
CONFIG_PWM_TEGRA=y
--
2.9.3
^ permalink raw reply related
* [PATCH 3/3] ARM: defconfig: pxa: cut MPU3050 input driver
From: Linus Walleij @ 2016-12-27 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161227120530.31190-1-linus.walleij@linaro.org>
The PXA defconfig compiles the legacy MPU3050 driver as a module,
but the device does not appear in device trees nor board files, so
remove this from the defconfig assuming it was a mistake to add it
in the first place.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/configs/pxa_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
index e4314b1227a3..ce4660c79c7a 100644
--- a/arch/arm/configs/pxa_defconfig
+++ b/arch/arm/configs/pxa_defconfig
@@ -334,7 +334,6 @@ CONFIG_TOUCHSCREEN_TOUCHIT213=m
CONFIG_TOUCHSCREEN_PCAP=m
CONFIG_TOUCHSCREEN_ST1232=m
CONFIG_INPUT_MISC=y
-CONFIG_INPUT_MPU3050=m
CONFIG_INPUT_AXP20X_PEK=m
CONFIG_INPUT_UINPUT=m
CONFIG_INPUT_GPIO_ROTARY_ENCODER=m
--
2.9.3
^ permalink raw reply related
* [PATCH V1] pinctrl:pxa:pinctrl-pxa2xx:- No need of devm functions
From: Linus Walleij @ 2016-12-27 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481207730-6332-1-git-send-email-arvind.yadav.cs@gmail.com>
On Thu, Dec 8, 2016 at 3:35 PM, Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> In functions pxa2xx_build_functions, the memory allocated for
> 'functions' is live within the function only. After the
> allocation it is immediately freed with devm_kfree. There is
> no need to allocate memory for 'functions' with devm function
> so replace devm_kcalloc with kcalloc and devm_kfree with kfree.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
I want the maintainer Robert Jarzmik to review this before I do anything
with it.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/6] ARM: mach-mx31_3ds: Remove camera support
From: Fabio Estevam @ 2016-12-27 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM=E1R4L+BtFqAdRCUFzaZLkuZ7+8KUxO9iTkDqRz94RrOrz0Q@mail.gmail.com>
Hi Magnus,
On Tue, Dec 27, 2016 at 8:05 AM, Magnus Lilja <lilja.magnus@gmail.com> wrote:
> CSI_D5 is marked as "not floating" by default, as opposed to "input,
> pulled up" on many other pins on the i.MX31. That makes me wonder if
> it's best to keep the initialization of CSI_D5 and RI_DTE1 to make
> sure the pins are set to a defined state (that also will set the
> camera off).
After this patch the camera will not be powered by the mc13783 PMIC
anymore, so I think it is safe to remove the code that handles the
camera GPIOs.
> Will test the patch on hardware in a couple of days.
Thanks!
^ 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