* [PATCH v3 0/5] clk: rockchip: Support for some new features
From: Elaine Zhang @ 2019-09-27 3:00 UTC (permalink / raw)
To: heiko
Cc: huangtao, xxx, xf, sboyd, mturquette, Elaine Zhang, linux-kernel,
linux-rockchip, linux-clk, linux-arm-kernel
1. Support for some new features
2. fix up some error
Chang in V3:
[PATCH v2 3/6] : It's been merged
So rebased and resubmit.
Chang in V2:
[PATCH v2 5/6] : fix up the Register error, and add delay.
Elaine Zhang (4):
clk: rockchip: fix up the frac clk get rate error
clk: rockchip: add a clock-type for muxes based in the pmugrf
clk: rockchip: add pll up and down when change pll freq
clk: rockchip: support pll setting by auto
Finley Xiao (1):
clk: rockchip: Add supprot to limit input rate for fractional divider
drivers/clk/rockchip/clk-pll.c | 236 +++++++++++++++++++++++++++++++++++---
drivers/clk/rockchip/clk-px30.c | 29 ++---
drivers/clk/rockchip/clk-rk3036.c | 13 ++-
drivers/clk/rockchip/clk-rk3128.c | 15 ++-
drivers/clk/rockchip/clk-rk3188.c | 24 ++--
drivers/clk/rockchip/clk-rk3228.c | 18 +--
drivers/clk/rockchip/clk-rk3288.c | 19 +--
drivers/clk/rockchip/clk-rk3308.c | 46 ++++----
drivers/clk/rockchip/clk-rk3328.c | 17 +--
drivers/clk/rockchip/clk-rk3368.c | 17 +--
drivers/clk/rockchip/clk-rk3399.c | 32 +++---
drivers/clk/rockchip/clk-rv1108.c | 14 ++-
drivers/clk/rockchip/clk.c | 39 ++++++-
drivers/clk/rockchip/clk.h | 27 ++++-
include/linux/clk-provider.h | 2 +
15 files changed, 422 insertions(+), 126 deletions(-)
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 5/5] clk: rockchip: support pll setting by auto
From: Elaine Zhang @ 2019-09-27 3:01 UTC (permalink / raw)
To: heiko
Cc: huangtao, xxx, xf, sboyd, mturquette, Elaine Zhang, linux-kernel,
linux-rockchip, linux-clk, linux-arm-kernel
In-Reply-To: <1569553244-3165-1-git-send-email-zhangqing@rock-chips.com>
If setting freq is not support in rockchip_pll_rate_table,
It can calculate and set pll params by auto.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
drivers/clk/rockchip/clk-pll.c | 215 ++++++++++++++++++++++++++++++++++++++---
1 file changed, 200 insertions(+), 15 deletions(-)
diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 390e9473807a..ac8c62c531f0 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -14,6 +14,7 @@
#include <linux/clk-provider.h>
#include <linux/regmap.h>
#include <linux/clk.h>
+#include <linux/gcd.h>
#include "clk.h"
#define PLL_MODE_MASK 0x3
@@ -46,6 +47,198 @@ struct rockchip_clk_pll {
#define to_rockchip_clk_pll_nb(nb) \
container_of(nb, struct rockchip_clk_pll, clk_nb)
+#define MHZ (1000UL * 1000UL)
+#define KHZ (1000UL)
+
+/* CLK_PLL_TYPE_RK3066_AUTO type ops */
+#define PLL_FREF_MIN (269 * KHZ)
+#define PLL_FREF_MAX (2200 * MHZ)
+
+#define PLL_FVCO_MIN (440 * MHZ)
+#define PLL_FVCO_MAX (2200 * MHZ)
+
+#define PLL_FOUT_MIN (27500 * KHZ)
+#define PLL_FOUT_MAX (2200 * MHZ)
+
+#define PLL_NF_MAX (4096)
+#define PLL_NR_MAX (64)
+#define PLL_NO_MAX (16)
+
+/* CLK_PLL_TYPE_RK3036/3366/3399_AUTO type ops */
+#define MIN_FOUTVCO_FREQ (800 * MHZ)
+#define MAX_FOUTVCO_FREQ (2000 * MHZ)
+
+static struct rockchip_pll_rate_table auto_table;
+
+static struct rockchip_pll_rate_table *rk_pll_rate_table_get(void)
+{
+ return &auto_table;
+}
+
+static int rockchip_pll_clk_set_postdiv(unsigned long fout_hz,
+ u32 *postdiv1,
+ u32 *postdiv2,
+ u32 *foutvco)
+{
+ unsigned long freq;
+
+ if (fout_hz < MIN_FOUTVCO_FREQ) {
+ for (*postdiv1 = 1; *postdiv1 <= 7; (*postdiv1)++) {
+ for (*postdiv2 = 1; *postdiv2 <= 7; (*postdiv2)++) {
+ freq = fout_hz * (*postdiv1) * (*postdiv2);
+ if (freq >= MIN_FOUTVCO_FREQ &&
+ freq <= MAX_FOUTVCO_FREQ) {
+ *foutvco = freq;
+ return 0;
+ }
+ }
+ }
+ pr_err("CANNOT FIND postdiv1/2 to make fout in range from 800M to 2000M,fout = %lu\n",
+ fout_hz);
+ } else {
+ *postdiv1 = 1;
+ *postdiv2 = 1;
+ }
+ return 0;
+}
+
+static struct rockchip_pll_rate_table *
+rockchip_pll_clk_set_by_auto(struct rockchip_clk_pll *pll,
+ unsigned long fin_hz,
+ unsigned long fout_hz)
+{
+ struct rockchip_pll_rate_table *rate_table = rk_pll_rate_table_get();
+ /* FIXME set postdiv1/2 always 1*/
+ u32 foutvco = fout_hz;
+ u64 fin_64, frac_64;
+ u32 f_frac, postdiv1, postdiv2;
+ unsigned long clk_gcd = 0;
+
+ if (fin_hz == 0 || fout_hz == 0 || fout_hz == fin_hz)
+ return NULL;
+
+ rockchip_pll_clk_set_postdiv(fout_hz, &postdiv1, &postdiv2, &foutvco);
+ rate_table->postdiv1 = postdiv1;
+ rate_table->postdiv2 = postdiv2;
+ rate_table->dsmpd = 1;
+
+ if (fin_hz / MHZ * MHZ == fin_hz && fout_hz / MHZ * MHZ == fout_hz) {
+ fin_hz /= MHZ;
+ foutvco /= MHZ;
+ clk_gcd = gcd(fin_hz, foutvco);
+ rate_table->refdiv = fin_hz / clk_gcd;
+ rate_table->fbdiv = foutvco / clk_gcd;
+
+ rate_table->frac = 0;
+
+ pr_debug("fin = %lu, fout = %lu, clk_gcd = %lu, refdiv = %u, fbdiv = %u, postdiv1 = %u, postdiv2 = %u, frac = %u\n",
+ fin_hz, fout_hz, clk_gcd, rate_table->refdiv,
+ rate_table->fbdiv, rate_table->postdiv1,
+ rate_table->postdiv2, rate_table->frac);
+ } else {
+ pr_debug("frac div running, fin_hz = %lu, fout_hz = %lu, fin_INT_mhz = %lu, fout_INT_mhz = %lu\n",
+ fin_hz, fout_hz,
+ fin_hz / MHZ * MHZ,
+ fout_hz / MHZ * MHZ);
+ pr_debug("frac get postdiv1 = %u, postdiv2 = %u, foutvco = %u\n",
+ rate_table->postdiv1, rate_table->postdiv2, foutvco);
+ clk_gcd = gcd(fin_hz / MHZ, foutvco / MHZ);
+ rate_table->refdiv = fin_hz / MHZ / clk_gcd;
+ rate_table->fbdiv = foutvco / MHZ / clk_gcd;
+ pr_debug("frac get refdiv = %u, fbdiv = %u\n",
+ rate_table->refdiv, rate_table->fbdiv);
+
+ rate_table->frac = 0;
+
+ f_frac = (foutvco % MHZ);
+ fin_64 = fin_hz;
+ do_div(fin_64, (u64)rate_table->refdiv);
+ frac_64 = (u64)f_frac << 24;
+ do_div(frac_64, fin_64);
+ rate_table->frac = (u32)frac_64;
+ if (rate_table->frac > 0)
+ rate_table->dsmpd = 0;
+ pr_debug("frac = %x\n", rate_table->frac);
+ }
+ return rate_table;
+}
+
+static struct rockchip_pll_rate_table *
+rockchip_rk3066_pll_clk_set_by_auto(struct rockchip_clk_pll *pll,
+ unsigned long fin_hz,
+ unsigned long fout_hz)
+{
+ struct rockchip_pll_rate_table *rate_table = rk_pll_rate_table_get();
+ u32 nr, nf, no, nonr;
+ u32 nr_out, nf_out, no_out;
+ u32 n;
+ u32 numerator, denominator;
+ u64 fref, fvco, fout;
+ unsigned long clk_gcd = 0;
+
+ nr_out = PLL_NR_MAX + 1;
+ no_out = 0;
+ nf_out = 0;
+
+ if (fin_hz == 0 || fout_hz == 0 || fout_hz == fin_hz)
+ return NULL;
+
+ clk_gcd = gcd(fin_hz, fout_hz);
+
+ numerator = fout_hz / clk_gcd;
+ denominator = fin_hz / clk_gcd;
+
+ for (n = 1;; n++) {
+ nf = numerator * n;
+ nonr = denominator * n;
+ if (nf > PLL_NF_MAX || nonr > (PLL_NO_MAX * PLL_NR_MAX))
+ break;
+
+ for (no = 1; no <= PLL_NO_MAX; no++) {
+ if (!(no == 1 || !(no % 2)))
+ continue;
+
+ if (nonr % no)
+ continue;
+ nr = nonr / no;
+
+ if (nr > PLL_NR_MAX)
+ continue;
+
+ fref = fin_hz / nr;
+ if (fref < PLL_FREF_MIN || fref > PLL_FREF_MAX)
+ continue;
+
+ fvco = fref * nf;
+ if (fvco < PLL_FVCO_MIN || fvco > PLL_FVCO_MAX)
+ continue;
+
+ fout = fvco / no;
+ if (fout < PLL_FOUT_MIN || fout > PLL_FOUT_MAX)
+ continue;
+
+ /* select the best from all available PLL settings */
+ if ((no > no_out) ||
+ ((no == no_out) && (nr < nr_out))) {
+ nr_out = nr;
+ nf_out = nf;
+ no_out = no;
+ }
+ }
+ }
+
+ /* output the best PLL setting */
+ if ((nr_out <= PLL_NR_MAX) && (no_out > 0)) {
+ rate_table->nr = nr_out;
+ rate_table->nf = nf_out;
+ rate_table->no = no_out;
+ } else {
+ return NULL;
+ }
+
+ return rate_table;
+}
+
static const struct rockchip_pll_rate_table *rockchip_get_pll_settings(
struct rockchip_clk_pll *pll, unsigned long rate)
{
@@ -57,24 +250,16 @@ static const struct rockchip_pll_rate_table *rockchip_get_pll_settings(
return &rate_table[i];
}
- return NULL;
+ if (pll->type == pll_rk3066)
+ return rockchip_rk3066_pll_clk_set_by_auto(pll, 24 * MHZ, rate);
+ else
+ return rockchip_pll_clk_set_by_auto(pll, 24 * MHZ, rate);
}
static long rockchip_pll_round_rate(struct clk_hw *hw,
unsigned long drate, unsigned long *prate)
{
- struct rockchip_clk_pll *pll = to_rockchip_clk_pll(hw);
- const struct rockchip_pll_rate_table *rate_table = pll->rate_table;
- int i;
-
- /* Assumming rate_table is in descending order */
- for (i = 0; i < pll->rate_count; i++) {
- if (drate >= rate_table[i].rate)
- return rate_table[i].rate;
- }
-
- /* return minimum supported value */
- return rate_table[i - 1].rate;
+ return drate;
}
/*
@@ -154,7 +339,7 @@ static unsigned long rockchip_rk3036_pll_recalc_rate(struct clk_hw *hw,
{
struct rockchip_clk_pll *pll = to_rockchip_clk_pll(hw);
struct rockchip_pll_rate_table cur;
- u64 rate64 = prate;
+ u64 rate64 = prate, frac_rate64 = prate;
rockchip_rk3036_pll_get_params(pll, &cur);
@@ -163,7 +348,7 @@ static unsigned long rockchip_rk3036_pll_recalc_rate(struct clk_hw *hw,
if (cur.dsmpd == 0) {
/* fractional mode */
- u64 frac_rate64 = prate * cur.frac;
+ frac_rate64 *= cur.frac;
do_div(frac_rate64, cur.refdiv);
rate64 += frac_rate64 >> 24;
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] arm64: defconfig: Enable HiSilicon ZIP controller
From: Zhou Wang @ 2019-09-27 2:58 UTC (permalink / raw)
To: xuwei5, linux-arm-kernel; +Cc: Zhou Wang, linuxarm
Enable CONFIG_CRYPTO_DEV_HISI_ZIP for HiSilicon ZIP controller in Kunpeng920
SoC.
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8e05c39..2e55f66 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -848,6 +848,7 @@ CONFIG_NLS_ISO8859_1=y
CONFIG_SECURITY=y
CONFIG_CRYPTO_ECHAINIV=y
CONFIG_CRYPTO_ANSI_CPRNG=y
+CONFIG_CRYPTO_DEV_HISI_ZIP=m
CONFIG_DMA_CMA=y
CONFIG_CMA_SIZE_MBYTES=32
CONFIG_PRINTK_TIME=y
--
2.8.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] clk: meson: a1: add support for Amlogic A1 clock driver
From: Jian Hu @ 2019-09-27 3:11 UTC (permalink / raw)
To: Stephen Boyd, Jerome Brunet, Neil Armstrong
Cc: Rob Herring, Jianxin Pan, devicetree, Martin Blumenstingl,
Kevin Hilman, Michael Turquette, linux-kernel, Qiufang Dai,
linux-amlogic, linux-clk, linux-arm-kernel
In-Reply-To: <20190925131232.4751020640@mail.kernel.org>
Hi, Stephen
Thank you for review
On 2019/9/25 21:12, Stephen Boyd wrote:
> Quoting Jian Hu (2019-09-25 04:44:48)
>> The Amlogic A1 clock includes three parts:
>> peripheral clocks, pll clocks, CPU clocks.
>> sys pll and CPU clocks will be sent in next patch.
>>
>> Unlike the previous series, there is no EE/AO domain
>> in A1 CLK controllers.
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
>
> This second name didn't send the patch. Please follow the signoff
> procedures documented in Documentation/process/submitting-patches.rst
>
>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>> index 16d7614..a48f67d 100644
>> --- a/arch/arm64/Kconfig.platforms
>> +++ b/arch/arm64/Kconfig.platforms
>> @@ -138,6 +138,7 @@ config ARCH_MESON
>> select COMMON_CLK_AXG
>> select COMMON_CLK_G12A
>> select MESON_IRQ_GPIO
>> + select COMMON_CLK_A1
>
> Sort?
ok, I will put it behind COMMON_CLK_AXG
>
>> help
>> This enables support for the arm64 based Amlogic SoCs
>> such as the s905, S905X/D, S912, A113X/D or S905X/D2
>> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
>> index dabeb43..e6cb4c3 100644
>> --- a/drivers/clk/meson/Kconfig
>> +++ b/drivers/clk/meson/Kconfig
>> @@ -107,3 +107,13 @@ config COMMON_CLK_G12A
>> help
>> Support for the clock controller on Amlogic S905D2, S905X2 and S905Y2
>> devices, aka g12a. Say Y if you want peripherals to work.
>> +
>> +config COMMON_CLK_A1
>
> Probably should be placed somewhere alphabetically in this file?
ok, I will put it behind COMMON_CLK_AXG_AUDIO
>
>> + bool
>> + depends on ARCH_MESON
>> + select COMMON_CLK_MESON_REGMAP
>> + select COMMON_CLK_MESON_DUALDIV
>> + select COMMON_CLK_MESON_PLL
>> + help
>> + Support for the clock controller on Amlogic A113L device,
>> + aka a1. Say Y if you want peripherals to work.
>> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
>> index 3939f21..6be3a8f 100644
>> --- a/drivers/clk/meson/Makefile
>> +++ b/drivers/clk/meson/Makefile
>> @@ -19,3 +19,4 @@ obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
>> obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o
>> obj-$(CONFIG_COMMON_CLK_G12A) += g12a.o g12a-aoclk.o
>> obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
>> +obj-$(CONFIG_COMMON_CLK_A1) += a1.o
>
> I would guess this should be sorted on Kconfig name in this file?
ok, I will put it behind COMMON_CLK_AXG_AUDIO
>
>> diff --git a/drivers/clk/meson/a1.c b/drivers/clk/meson/a1.c
>> new file mode 100644
>> index 0000000..26edae0f
>> --- /dev/null
>> +++ b/drivers/clk/meson/a1.c
>> @@ -0,0 +1,2617 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
>> + */
>> +
>> +#include <linux/clk-provider.h>
>> +#include <linux/init.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/of_address.h>
>> +#include "clk-mpll.h"
>> +#include "clk-pll.h"
>> +#include "clk-regmap.h"
>> +#include "vid-pll-div.h"
>> +#include "clk-dualdiv.h"
>> +#include "meson-eeclk.h"
>> +#include "a1.h"
>> +
> [...]
>> +
>> +/*
>> + * The Meson A1 HIFI PLL is 614.4M, it requires
>> + * a strict register sequence to enable the PLL.
>> + * set meson_clk_pcie_pll_ops as its ops
>
> Please remove this last line as it's obvious from the code what ops are
> used.
>
ok, I will remove it.
>> + */
>> +static struct clk_regmap a1_hifi_pll = {
>> + .data = &(struct meson_clk_pll_data){
>> + .en = {
>> + .reg_off = ANACTRL_HIFIPLL_CTRL0,
>> + .shift = 28,
>> + .width = 1,
>> + },
>> + .m = {
>> + .reg_off = ANACTRL_HIFIPLL_CTRL0,
>> + .shift = 0,
>> + .width = 8,
>> + },
>> + .n = {
>> + .reg_off = ANACTRL_HIFIPLL_CTRL0,
>> + .shift = 10,
>> + .width = 5,
>> + },
>> + .frac = {
>> + .reg_off = ANACTRL_HIFIPLL_CTRL1,
>> + .shift = 0,
>> + .width = 19,
>> + },
>> + .l = {
>> + .reg_off = ANACTRL_HIFIPLL_STS,
>> + .shift = 31,
>> + .width = 1,
>> + },
>> + .table = a1_hifi_pll_params_table,
>> + .init_regs = a1_hifi_init_regs,
>> + .init_count = ARRAY_SIZE(a1_hifi_init_regs),
>> + },
>> + .hw.init = &(struct clk_init_data){
>> + .name = "hifi_pll",
>> + .ops = &meson_clk_pcie_pll_ops,
>> + .parent_hws = (const struct clk_hw *[]) {
>> + &a1_xtal_hifipll.hw
>> + },
>> + .num_parents = 1,
>> + },
>> +};
>> +
> [..]
>> +
>> +static struct clk_regmap a1_fclk_div2 = {
>> + .data = &(struct clk_regmap_gate_data){
>> + .offset = ANACTRL_FIXPLL_CTRL0,
>> + .bit_idx = 21,
>> + },
>> + .hw.init = &(struct clk_init_data){
>> + .name = "fclk_div2",
>> + .ops = &clk_regmap_gate_ops,
>> + .parent_hws = (const struct clk_hw *[]) {
>> + &a1_fclk_div2_div.hw
>> + },
>> + .num_parents = 1,
>> + /*
>> + * add CLK_IS_CRITICAL flag to avoid being disabled by clk core
>> + * or its children clocks.
>
> This comment is useless. Please replace it with an actual reason for
> keeping the clk on instead of describing what the flag does.
>
ok, The actual reason is it should not change at runtime.
>> + */
>> + .flags = CLK_IS_CRITICAL,
>> + },
>> +};
>> +
> [..]
>> +static struct clk_regmap a1_dmc = {
>> + .data = &(struct clk_regmap_gate_data){
>> + .offset = DMC_CLK_CTRL,
>> + .bit_idx = 8,
>> + },
>> + .hw.init = &(struct clk_init_data) {
>> + .name = "dmc",
>> + .ops = &clk_regmap_gate_ops,
>> + .parent_hws = (const struct clk_hw *[]) {
>> + &a1_dmc_sel2.hw
>> + },
>> + .num_parents = 1,
>> + /*
>> + * add CLK_IGNORE_UNUSED to avoid hangup
>> + * DDR clock should not change at runtime
>> + */
>> + .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
>
> So not CLK_IS_CRITICAL?
Yes, CLK_IS_CRITICAL is better, I will change it.
>
>> + },
>> +};
>> +
> [...]
>> +
>> +/*
>> + * cpu clock register base address is 0xfd000080
>> + */
>> +static struct clk_regmap *const a1_cpu_clk_regmaps[] = {
>> + /* TODO */
>
> Can it be done?
I plan to compelte cpu clock with the DVFS verified. And Some
peripheral devices rely on this patch to send. I prefer to do it in the
next patch.
>
>> +};
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6] gpio/mpc8xxx: change irq handler from chained to normal
From: Hui Song @ 2019-09-27 3:15 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Mark Rutland, Linus Walleij,
Bartosz Golaszewski
Cc: devicetree, Song Hui, linux-kernel, linux-arm-kernel, linux-gpio
From: Song Hui <hui.song_1@nxp.com>
More than one gpio controllers can share one interrupt, change the
driver to request shared irq.
While this will work, it will mess up userspace accounting of the number
of interrupts per second in tools such as vmstat. The reason is that
for every GPIO interrupt, /proc/interrupts records the count against GIC
interrupt 68 or 69, as well as the GPIO itself. So, for every GPIO
interrupt, the total number of interrupts that the system has seen
increments by two
Signed-off-by: Laurentiu Tudor <Laurentiu.Tudor@nxp.com>
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Song Hui <hui.song_1@nxp.com>
---
Changes in v6:
- change request_irq to devm_request_irq and add commit message
Changes in v5:
- add traverse every bit function.
Changes in v4:
- convert 'pr_err' to 'dev_err'.
Changes in v3:
- update the patch description.
Changes in v2:
- delete the compatible of ls1088a.
drivers/gpio/gpio-mpc8xxx.c | 31 ++++++++++++++++++++-----------
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
index 16a47de..f0be284 100644
--- a/drivers/gpio/gpio-mpc8xxx.c
+++ b/drivers/gpio/gpio-mpc8xxx.c
@@ -22,6 +22,7 @@
#include <linux/irq.h>
#include <linux/gpio/driver.h>
#include <linux/bitops.h>
+#include <linux/interrupt.h>
#define MPC8XXX_GPIO_PINS 32
@@ -127,20 +128,20 @@ static int mpc8xxx_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
return -ENXIO;
}
-static void mpc8xxx_gpio_irq_cascade(struct irq_desc *desc)
+static irqreturn_t mpc8xxx_gpio_irq_cascade(int irq, void *data)
{
- struct mpc8xxx_gpio_chip *mpc8xxx_gc = irq_desc_get_handler_data(desc);
- struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = data;
struct gpio_chip *gc = &mpc8xxx_gc->gc;
unsigned int mask;
+ int i;
mask = gc->read_reg(mpc8xxx_gc->regs + GPIO_IER)
& gc->read_reg(mpc8xxx_gc->regs + GPIO_IMR);
- if (mask)
+ for_each_set_bit(i, &mask, 32)
generic_handle_irq(irq_linear_revmap(mpc8xxx_gc->irq,
- 32 - ffs(mask)));
- if (chip->irq_eoi)
- chip->irq_eoi(&desc->irq_data);
+ 31 - i));
+
+ return IRQ_HANDLED;
}
static void mpc8xxx_irq_unmask(struct irq_data *d)
@@ -388,8 +389,8 @@ static int mpc8xxx_probe(struct platform_device *pdev)
ret = gpiochip_add_data(gc, mpc8xxx_gc);
if (ret) {
- pr_err("%pOF: GPIO chip registration failed with status %d\n",
- np, ret);
+ dev_err(&pdev->dev, "%pOF: GPIO chip registration failed with status %d\n",
+ np, ret);
goto err;
}
@@ -409,8 +410,16 @@ static int mpc8xxx_probe(struct platform_device *pdev)
if (devtype->gpio_dir_in_init)
devtype->gpio_dir_in_init(gc);
- irq_set_chained_handler_and_data(mpc8xxx_gc->irqn,
- mpc8xxx_gpio_irq_cascade, mpc8xxx_gc);
+ ret = devm_request_irq(&pdev->dev, mpc8xxx_gc->irqn,
+ mpc8xxx_gpio_irq_cascade,
+ IRQF_NO_THREAD | IRQF_SHARED, "gpio-cascade",
+ mpc8xxx_gc);
+ if (ret) {
+ dev_err(&pdev->dev, "%s: failed to devm_request_irq(%d), ret = %d\n",
+ np->full_name, mpc8xxx_gc->irqn, ret);
+ goto err;
+ }
+
return 0;
err:
iounmap(mpc8xxx_gc->regs);
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] kasan: fix the missing underflow in memmove and memcpy with CONFIG_KASAN_GENERIC=y
From: Walter Wu @ 2019-09-27 3:43 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Matthias Brugger
Cc: Walter Wu, wsd_upstream, linux-kernel, kasan-dev, linux-mm,
linux-mediatek, linux-arm-kernel
memmove() and memcpy() have missing underflow issues.
When -7 <= size < 0, then KASAN will miss to catch the underflow issue.
It looks like shadow start address and shadow end address is the same,
so it does not actually check anything.
The following test is indeed not caught by KASAN:
char *p = kmalloc(64, GFP_KERNEL);
memset((char *)p, 0, 64);
memmove((char *)p, (char *)p + 4, -2);
kfree((char*)p);
It should be checked here:
void *memmove(void *dest, const void *src, size_t len)
{
check_memory_region((unsigned long)src, len, false, _RET_IP_);
check_memory_region((unsigned long)dest, len, true, _RET_IP_);
return __memmove(dest, src, len);
}
We fix the shadow end address which is calculated, then generic KASAN
get the right shadow end address and detect this underflow issue.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=199341
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
---
lib/test_kasan.c | 36 ++++++++++++++++++++++++++++++++++++
mm/kasan/generic.c | 8 ++++++--
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index b63b367a94e8..8bd014852556 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -280,6 +280,40 @@ static noinline void __init kmalloc_oob_in_memset(void)
kfree(ptr);
}
+static noinline void __init kmalloc_oob_in_memmove_underflow(void)
+{
+ char *ptr;
+ size_t size = 64;
+
+ pr_info("underflow out-of-bounds in memmove\n");
+ ptr = kmalloc(size, GFP_KERNEL);
+ if (!ptr) {
+ pr_err("Allocation failed\n");
+ return;
+ }
+
+ memset((char *)ptr, 0, 64);
+ memmove((char *)ptr, (char *)ptr + 4, -2);
+ kfree(ptr);
+}
+
+static noinline void __init kmalloc_oob_in_memmove_overflow(void)
+{
+ char *ptr;
+ size_t size = 64;
+
+ pr_info("overflow out-of-bounds in memmove\n");
+ ptr = kmalloc(size, GFP_KERNEL);
+ if (!ptr) {
+ pr_err("Allocation failed\n");
+ return;
+ }
+
+ memset((char *)ptr, 0, 64);
+ memmove((char *)ptr + size, (char *)ptr, 2);
+ kfree(ptr);
+}
+
static noinline void __init kmalloc_uaf(void)
{
char *ptr;
@@ -734,6 +768,8 @@ static int __init kmalloc_tests_init(void)
kmalloc_oob_memset_4();
kmalloc_oob_memset_8();
kmalloc_oob_memset_16();
+ kmalloc_oob_in_memmove_underflow();
+ kmalloc_oob_in_memmove_overflow();
kmalloc_uaf();
kmalloc_uaf_memset();
kmalloc_uaf2();
diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
index 616f9dd82d12..34ca23d59e67 100644
--- a/mm/kasan/generic.c
+++ b/mm/kasan/generic.c
@@ -131,9 +131,13 @@ static __always_inline bool memory_is_poisoned_n(unsigned long addr,
size_t size)
{
unsigned long ret;
+ void *shadow_start = kasan_mem_to_shadow((void *)addr);
+ void *shadow_end = kasan_mem_to_shadow((void *)addr + size - 1) + 1;
- ret = memory_is_nonzero(kasan_mem_to_shadow((void *)addr),
- kasan_mem_to_shadow((void *)addr + size - 1) + 1);
+ if ((long)size < 0)
+ shadow_end = kasan_mem_to_shadow((void *)addr + size);
+
+ ret = memory_is_nonzero(shadow_start, shadow_end);
if (unlikely(ret)) {
unsigned long last_byte = addr + size - 1;
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC PATCH 18/18] net: wireguard - switch to crypto API for packet encryption
From: Herbert Xu @ 2019-09-27 3:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jason A . Donenfeld, Catalin Marinas, Arnd Bergmann,
Ard Biesheuvel, Greg KH, Eric Biggers, Samuel Neves,
Pascal Van Leeuwen, Linux Crypto Mailing List, Andy Lutomirski,
Marc Zyngier, Dan Carpenter, Will Deacon, David Miller, Linux ARM
In-Reply-To: <CAHk-=whqWh8ebZ7ryEv5tKKtO5VpOj2rWVy7wV+aHWGO7m9gAw@mail.gmail.com>
On Thu, Sep 26, 2019 at 07:54:03PM -0700, Linus Torvalds wrote:
>
> Side note: almost nobody does this.
>
> Almost every single async interface I've ever seen ends up being "only
> designed for async".
>
> And I think the reason is that everybody first does the simply
> synchronous interfaces, and people start using those, and a lot of
> people are perfectly happy with them. They are simple, and they work
> fine for the huge majority of users.
The crypto API is not the way it is because of async. In fact, the
crypto API started out as sync only and async was essentially
bolted on top with minimial changes.
The main reason why the crypto API contains indirections is because
of the algorithmic flexibility which WireGuard does not need.
Now whether algorithmic flexibility is a good thing or not is a
different discussion. But the fact of the matter is that the
majority of heavy crypto users in our kernel do require this
flexibility (e.g., IPsec, dmcrypt, fscrypt).
I don't have a beef with the fact that WireGuard is tied to a
single algorithm. However, that simply does not work for the
other users that we will have to continue to support.
Cheers,
--
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 18/18] net: wireguard - switch to crypto API for packet encryption
From: Herbert Xu @ 2019-09-27 4:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jason A . Donenfeld, Catalin Marinas, Arnd Bergmann,
Ard Biesheuvel, Greg KH, Eric Biggers, Samuel Neves,
Pascal Van Leeuwen, Linux Crypto Mailing List, Andy Lutomirski,
Marc Zyngier, Dan Carpenter, Will Deacon, David Miller, Linux ARM
In-Reply-To: <CAHk-=whqWh8ebZ7ryEv5tKKtO5VpOj2rWVy7wV+aHWGO7m9gAw@mail.gmail.com>
On Thu, Sep 26, 2019 at 07:54:03PM -0700, Linus Torvalds wrote:
>
> There's no "read_potentially_async()" interface that just does the
> synchronous read for any cached portion of the data, and then delays
> just the IO parts and returns a "here, I gave you X bytes right now,
> use this cookie to wait for the rest".
Incidentally this is exactly how the crypto async interface works.
For example, the same call works whether you're sync or async:
aead_request_set_callback(req, ...);
aead_request_set_crypt(req, ...);
err = crypto_aead_encrypt(req);
if (err == -EINPROGRESS)
/*
* Request is processed asynchronously.
* This cannot occur if the algorithm is sync,
* e.g., when you specifically allocated sync
* algorithms.
*/
else
/* Request was processed synchronously */
We even allow the request to be on the stack in the sync case, e.g.,
with SYNC_SKCIPHER_REQUEST_ON_STACK.
> Maybe nobody would use it. But it really should be possibly to have
> interfaces where a good synchronous implementation is _possible_
> without the extra overhead, while also allowing async implementations.
So there is really no async overhead in the crypto API AFAICS if
you're always doing sync. What you see as overheads are probably
the result of having to support multiple underlying algorithms
(not just accelerations which can indeed be handled without
indirection at least for CPU-based ones).
Cheers,
--
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 18/18] net: wireguard - switch to crypto API for packet encryption
From: Linus Torvalds @ 2019-09-27 4:13 UTC (permalink / raw)
To: Herbert Xu
Cc: Jason A . Donenfeld, Catalin Marinas, Arnd Bergmann,
Ard Biesheuvel, Greg KH, Eric Biggers, Samuel Neves,
Pascal Van Leeuwen, Linux Crypto Mailing List, Andy Lutomirski,
Marc Zyngier, Dan Carpenter, Will Deacon, David Miller, Linux ARM
In-Reply-To: <20190927040140.GA24370@gondor.apana.org.au>
On Thu, Sep 26, 2019 at 9:01 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> So there is really no async overhead in the crypto API AFAICS if
> you're always doing sync. What you see as overheads are probably
> the result of having to support multiple underlying algorithms
> (not just accelerations which can indeed be handled without
> indirection at least for CPU-based ones).
Fair enough, and sounds good. The biggest overhead is that indirection
for the state data, and the fact that the code indirect calls the
actual function.
If that could be avoided by just statically saying
crypto_xyz_encrypt()
(with the xyz being the crypto algorithm you want) and having the
state be explicit, then yes, that would remove most of the overhead.
It would still leave setting the callback fields etc that are
unnecessary for the synchronous case and that I think could be done
differently, but that's probably just a couple of stores, so not
particularly noticeable.
Linus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6] gpio/mpc8xxx: change irq handler from chained to normal
From: kbuild test robot @ 2019-09-27 4:33 UTC (permalink / raw)
To: Hui Song
Cc: Mark Rutland, devicetree, Song Hui, linux-gpio, Linus Walleij,
linux-kernel, Li Yang, Bartosz Golaszewski, Rob Herring,
kbuild-all, Shawn Guo, linux-arm-kernel
In-Reply-To: <20190927031551.20074-1-hui.song_1@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 6313 bytes --]
Hi Hui,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on gpio/for-next]
[cannot apply to v5.3 next-20190925]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Hui-Song/gpio-mpc8xxx-change-irq-handler-from-chained-to-normal/20190927-113256
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All error/warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:12:0,
from drivers/gpio/gpio-mpc8xxx.c:12:
drivers/gpio/gpio-mpc8xxx.c: In function 'mpc8xxx_gpio_irq_cascade':
>> include/linux/bitops.h:22:30: error: passing argument 1 of 'find_first_bit' from incompatible pointer type [-Werror=incompatible-pointer-types]
for ((bit) = find_first_bit((addr), (size)); \
^
>> drivers/gpio/gpio-mpc8xxx.c:140:2: note: in expansion of macro 'for_each_set_bit'
for_each_set_bit(i, &mask, 32)
^~~~~~~~~~~~~~~~
In file included from arch/x86/include/asm/bitops.h:384:0,
from include/linux/bitops.h:19,
from include/linux/kernel.h:12,
from drivers/gpio/gpio-mpc8xxx.c:12:
include/asm-generic/bitops/find.h:59:22: note: expected 'const long unsigned int *' but argument is of type 'unsigned int *'
extern unsigned long find_first_bit(const unsigned long *addr,
^~~~~~~~~~~~~~
In file included from include/linux/kernel.h:12:0,
from drivers/gpio/gpio-mpc8xxx.c:12:
>> include/linux/bitops.h:24:29: error: passing argument 1 of 'find_next_bit' from incompatible pointer type [-Werror=incompatible-pointer-types]
(bit) = find_next_bit((addr), (size), (bit) + 1))
^
>> drivers/gpio/gpio-mpc8xxx.c:140:2: note: in expansion of macro 'for_each_set_bit'
for_each_set_bit(i, &mask, 32)
^~~~~~~~~~~~~~~~
In file included from arch/x86/include/asm/bitops.h:384:0,
from include/linux/bitops.h:19,
from include/linux/kernel.h:12,
from drivers/gpio/gpio-mpc8xxx.c:12:
include/asm-generic/bitops/find.h:15:22: note: expected 'const long unsigned int *' but argument is of type 'unsigned int *'
extern unsigned long find_next_bit(const unsigned long *addr, unsigned long
^~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from include/linux/kernel.h:12:0,
from drivers//gpio/gpio-mpc8xxx.c:12:
drivers//gpio/gpio-mpc8xxx.c: In function 'mpc8xxx_gpio_irq_cascade':
>> include/linux/bitops.h:22:30: error: passing argument 1 of 'find_first_bit' from incompatible pointer type [-Werror=incompatible-pointer-types]
for ((bit) = find_first_bit((addr), (size)); \
^
drivers//gpio/gpio-mpc8xxx.c:140:2: note: in expansion of macro 'for_each_set_bit'
for_each_set_bit(i, &mask, 32)
^~~~~~~~~~~~~~~~
In file included from arch/x86/include/asm/bitops.h:384:0,
from include/linux/bitops.h:19,
from include/linux/kernel.h:12,
from drivers//gpio/gpio-mpc8xxx.c:12:
include/asm-generic/bitops/find.h:59:22: note: expected 'const long unsigned int *' but argument is of type 'unsigned int *'
extern unsigned long find_first_bit(const unsigned long *addr,
^~~~~~~~~~~~~~
In file included from include/linux/kernel.h:12:0,
from drivers//gpio/gpio-mpc8xxx.c:12:
>> include/linux/bitops.h:24:29: error: passing argument 1 of 'find_next_bit' from incompatible pointer type [-Werror=incompatible-pointer-types]
(bit) = find_next_bit((addr), (size), (bit) + 1))
^
drivers//gpio/gpio-mpc8xxx.c:140:2: note: in expansion of macro 'for_each_set_bit'
for_each_set_bit(i, &mask, 32)
^~~~~~~~~~~~~~~~
In file included from arch/x86/include/asm/bitops.h:384:0,
from include/linux/bitops.h:19,
from include/linux/kernel.h:12,
from drivers//gpio/gpio-mpc8xxx.c:12:
include/asm-generic/bitops/find.h:15:22: note: expected 'const long unsigned int *' but argument is of type 'unsigned int *'
extern unsigned long find_next_bit(const unsigned long *addr, unsigned long
^~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/find_first_bit +22 include/linux/bitops.h
4677d4a53e0d56 Borislav Petkov 2010-05-03 14
^1da177e4c3f41 Linus Torvalds 2005-04-16 15 /*
^1da177e4c3f41 Linus Torvalds 2005-04-16 16 * Include this here because some architectures need generic_ffs/fls in
^1da177e4c3f41 Linus Torvalds 2005-04-16 17 * scope
^1da177e4c3f41 Linus Torvalds 2005-04-16 18 */
^1da177e4c3f41 Linus Torvalds 2005-04-16 @19 #include <asm/bitops.h>
^1da177e4c3f41 Linus Torvalds 2005-04-16 20
984b3f5746ed2c Akinobu Mita 2010-03-05 21 #define for_each_set_bit(bit, addr, size) \
3e037454bcfa4b Shannon Nelson 2007-10-16 @22 for ((bit) = find_first_bit((addr), (size)); \
3e037454bcfa4b Shannon Nelson 2007-10-16 23 (bit) < (size); \
3e037454bcfa4b Shannon Nelson 2007-10-16 @24 (bit) = find_next_bit((addr), (size), (bit) + 1))
3e037454bcfa4b Shannon Nelson 2007-10-16 25
:::::: The code at line 22 was first introduced by commit
:::::: 3e037454bcfa4b187e8293d2121bd8c0f5a5c31c I/OAT: Add support for MSI and MSI-X
:::::: TO: Shannon Nelson <shannon.nelson@intel.com>
:::::: CC: Linus Torvalds <torvalds@woody.linux-foundation.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 68827 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 18/18] net: wireguard - switch to crypto API for packet encryption
From: Andy Lutomirski @ 2019-09-27 4:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jason A . Donenfeld, Catalin Marinas, Herbert Xu, Arnd Bergmann,
Ard Biesheuvel, Greg KH, Eric Biggers, Samuel Neves,
Pascal Van Leeuwen, Linux Crypto Mailing List, Andy Lutomirski,
Marc Zyngier, Dan Carpenter, Will Deacon, David Miller, Linux ARM
In-Reply-To: <CAHk-=wjr1w7x9Rjre_ALnDLASYNjsEHxu6VJpk4eUwZXN0ntqw@mail.gmail.com>
> On Sep 26, 2019, at 6:38 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> - let the caller know what the state size is and allocate the
> synchronous state in its own data structures
>
> - let the caller just call a static "decrypt_xyz()" function for xyz
> decryptrion.
>
> - if you end up doing it synchronously, that function just returns
> "done". No overhead. No extra allocations. No unnecessary stuff. Just
> do it, using the buffers provided. End of story. Efficient and simple.
>
> - BUT.
>
> - any hardware could have registered itself for "I can do xyz", and
> the decrypt_xyz() function would know about those, and *if* it has a
> list of accelerators (hopefully sorted by preference etc), it would
> try to use them. And if they take the job (they might not - maybe
> their queues are full, maybe they don't have room for new keys at the
> moment, which might be a separate setup from the queues), the
> "decrypt_xyz()" function returns a _cookie_ for that job. It's
> probably a pre-allocated one (the hw accelerator might preallocate a
> fixed number of in-progress data structures).
To really do this right, I think this doesn't go far enough. Suppose
I'm trying to implement send() over a VPN very efficiently. I want to
do, roughly, this:
void __user *buf, etc;
if (crypto api thinks async is good) {
copy buf to some kernel memory;
set up a scatterlist;
do it async with this callback;
} else {
do the crypto synchronously, from *user* memory, straight to kernel memory;
(or, if that's too complicated, maybe copy in little chunks to a
little stack buffer.
setting up a scatterlist is a waste of time.)
}
I don't know if the network code is structured in a way to make this
work easily, and the API would be more complex, but it could be nice
and fast.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 18/18] net: wireguard - switch to crypto API for packet encryption
From: Andy Lutomirski @ 2019-09-27 4:37 UTC (permalink / raw)
To: Herbert Xu
Cc: Jason A . Donenfeld, Catalin Marinas, Arnd Bergmann,
Ard Biesheuvel, Greg KH, Eric Biggers, Will Deacon, Samuel Neves,
Pascal Van Leeuwen, Linux Crypto Mailing List, Andy Lutomirski,
Marc Zyngier, Dan Carpenter, Linus Torvalds, David Miller,
Linux ARM
In-Reply-To: <20190927035319.GA23566@gondor.apana.org.au>
On Thu, Sep 26, 2019 at 8:54 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Thu, Sep 26, 2019 at 07:54:03PM -0700, Linus Torvalds wrote:
> >
> > Side note: almost nobody does this.
> >
> > Almost every single async interface I've ever seen ends up being "only
> > designed for async".
> >
> > And I think the reason is that everybody first does the simply
> > synchronous interfaces, and people start using those, and a lot of
> > people are perfectly happy with them. They are simple, and they work
> > fine for the huge majority of users.
>
> The crypto API is not the way it is because of async. In fact, the
> crypto API started out as sync only and async was essentially
> bolted on top with minimial changes.
Then what's up with the insistence on using physical addresses for so
many of the buffers?
--Andy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6] gpio/mpc8xxx: change irq handler from chained to normal
From: kbuild test robot @ 2019-09-27 4:53 UTC (permalink / raw)
To: Hui Song
Cc: Mark Rutland, devicetree, Song Hui, linux-gpio, Linus Walleij,
linux-kernel, Li Yang, Bartosz Golaszewski, Rob Herring,
kbuild-all, Shawn Guo, linux-arm-kernel
In-Reply-To: <20190927031551.20074-1-hui.song_1@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 6705 bytes --]
Hi Hui,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on gpio/for-next]
[cannot apply to v5.3 next-20190925]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Hui-Song/gpio-mpc8xxx-change-irq-handler-from-chained-to-normal/20190927-113256
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=mips
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All error/warnings (new ones prefixed by >>):
In file included from arch/mips/include/asm/bitops.h:625:0,
from include/linux/bitops.h:19,
from include/linux/kernel.h:12,
from drivers/gpio/gpio-mpc8xxx.c:12:
drivers/gpio/gpio-mpc8xxx.c: In function 'mpc8xxx_gpio_irq_cascade':
>> include/asm-generic/bitops/find.h:75:50: error: passing argument 1 of 'find_next_bit' from incompatible pointer type [-Werror=incompatible-pointer-types]
#define find_first_bit(addr, size) find_next_bit((addr), (size), 0)
^
>> include/linux/bitops.h:22:15: note: in expansion of macro 'find_first_bit'
for ((bit) = find_first_bit((addr), (size)); \
^~~~~~~~~~~~~~
drivers/gpio/gpio-mpc8xxx.c:140:2: note: in expansion of macro 'for_each_set_bit'
for_each_set_bit(i, &mask, 32)
^~~~~~~~~~~~~~~~
include/asm-generic/bitops/find.h:15:22: note: expected 'const long unsigned int *' but argument is of type 'unsigned int *'
extern unsigned long find_next_bit(const unsigned long *addr, unsigned long
^~~~~~~~~~~~~
In file included from include/linux/kernel.h:12:0,
from drivers/gpio/gpio-mpc8xxx.c:12:
include/linux/bitops.h:24:29: error: passing argument 1 of 'find_next_bit' from incompatible pointer type [-Werror=incompatible-pointer-types]
(bit) = find_next_bit((addr), (size), (bit) + 1))
^
drivers/gpio/gpio-mpc8xxx.c:140:2: note: in expansion of macro 'for_each_set_bit'
for_each_set_bit(i, &mask, 32)
^~~~~~~~~~~~~~~~
In file included from arch/mips/include/asm/bitops.h:625:0,
from include/linux/bitops.h:19,
from include/linux/kernel.h:12,
from drivers/gpio/gpio-mpc8xxx.c:12:
include/asm-generic/bitops/find.h:15:22: note: expected 'const long unsigned int *' but argument is of type 'unsigned int *'
extern unsigned long find_next_bit(const unsigned long *addr, unsigned long
^~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from arch/mips/include/asm/bitops.h:625:0,
from include/linux/bitops.h:19,
from include/linux/kernel.h:12,
from drivers//gpio/gpio-mpc8xxx.c:12:
drivers//gpio/gpio-mpc8xxx.c: In function 'mpc8xxx_gpio_irq_cascade':
>> include/asm-generic/bitops/find.h:75:50: error: passing argument 1 of 'find_next_bit' from incompatible pointer type [-Werror=incompatible-pointer-types]
#define find_first_bit(addr, size) find_next_bit((addr), (size), 0)
^
>> include/linux/bitops.h:22:15: note: in expansion of macro 'find_first_bit'
for ((bit) = find_first_bit((addr), (size)); \
^~~~~~~~~~~~~~
drivers//gpio/gpio-mpc8xxx.c:140:2: note: in expansion of macro 'for_each_set_bit'
for_each_set_bit(i, &mask, 32)
^~~~~~~~~~~~~~~~
include/asm-generic/bitops/find.h:15:22: note: expected 'const long unsigned int *' but argument is of type 'unsigned int *'
extern unsigned long find_next_bit(const unsigned long *addr, unsigned long
^~~~~~~~~~~~~
In file included from include/linux/kernel.h:12:0,
from drivers//gpio/gpio-mpc8xxx.c:12:
include/linux/bitops.h:24:29: error: passing argument 1 of 'find_next_bit' from incompatible pointer type [-Werror=incompatible-pointer-types]
(bit) = find_next_bit((addr), (size), (bit) + 1))
^
drivers//gpio/gpio-mpc8xxx.c:140:2: note: in expansion of macro 'for_each_set_bit'
for_each_set_bit(i, &mask, 32)
^~~~~~~~~~~~~~~~
In file included from arch/mips/include/asm/bitops.h:625:0,
from include/linux/bitops.h:19,
from include/linux/kernel.h:12,
from drivers//gpio/gpio-mpc8xxx.c:12:
include/asm-generic/bitops/find.h:15:22: note: expected 'const long unsigned int *' but argument is of type 'unsigned int *'
extern unsigned long find_next_bit(const unsigned long *addr, unsigned long
^~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/find_first_bit +22 include/linux/bitops.h
4677d4a53e0d56 Borislav Petkov 2010-05-03 14
^1da177e4c3f41 Linus Torvalds 2005-04-16 15 /*
^1da177e4c3f41 Linus Torvalds 2005-04-16 16 * Include this here because some architectures need generic_ffs/fls in
^1da177e4c3f41 Linus Torvalds 2005-04-16 17 * scope
^1da177e4c3f41 Linus Torvalds 2005-04-16 18 */
^1da177e4c3f41 Linus Torvalds 2005-04-16 @19 #include <asm/bitops.h>
^1da177e4c3f41 Linus Torvalds 2005-04-16 20
984b3f5746ed2c Akinobu Mita 2010-03-05 21 #define for_each_set_bit(bit, addr, size) \
3e037454bcfa4b Shannon Nelson 2007-10-16 @22 for ((bit) = find_first_bit((addr), (size)); \
3e037454bcfa4b Shannon Nelson 2007-10-16 23 (bit) < (size); \
3e037454bcfa4b Shannon Nelson 2007-10-16 24 (bit) = find_next_bit((addr), (size), (bit) + 1))
3e037454bcfa4b Shannon Nelson 2007-10-16 25
:::::: The code at line 22 was first introduced by commit
:::::: 3e037454bcfa4b187e8293d2121bd8c0f5a5c31c I/OAT: Add support for MSI and MSI-X
:::::: TO: Shannon Nelson <shannon.nelson@intel.com>
:::::: CC: Linus Torvalds <torvalds@woody.linux-foundation.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 61522 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 18/18] net: wireguard - switch to crypto API for packet encryption
From: Herbert Xu @ 2019-09-27 4:59 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Jason A . Donenfeld, Catalin Marinas, Arnd Bergmann,
Ard Biesheuvel, Greg KH, Eric Biggers, Will Deacon, Samuel Neves,
Pascal Van Leeuwen, Linux Crypto Mailing List, Marc Zyngier,
Dan Carpenter, Linus Torvalds, David Miller, Linux ARM
In-Reply-To: <CALCETrW28rDxLs+UOO+k5gfHJZHzy_xra-e0f6kBp6YdeWA36A@mail.gmail.com>
On Thu, Sep 26, 2019 at 09:37:16PM -0700, Andy Lutomirski wrote:
>
> Then what's up with the insistence on using physical addresses for so
> many of the buffers?
This happens to be what async hardware wants, but the main reason
why the crypto API has them is because that's what the network
stack feeds us. The crypto API was first created purely for IPsec
so the SG lists are intimiately tied with how skbs were constructed.
Cheers,
--
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v4 1/2] fpga: fpga-mgr: Add readback support
From: Appana Durga Kedareswara Rao @ 2019-09-27 5:13 UTC (permalink / raw)
To: Moritz Fischer, Alan Tull, Moritz Fischer
Cc: Nava kishore Manne, kedare06@gmail.com,
linux-fpga@vger.kernel.org, linux-kernel,
Siva Durga Prasad Paladugu, Michal Simek,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CANk1AXSEWcZ7Oqv5pgpwvJRyyFWk5gPtniXa7T+oe6-uywqEqA@mail.gmail.com>
Hi Alan,
Did you get a chance to send your framework changes to upstream?
@Moritz Fischer: If Alan couldn't send his patch series, Can we take this patch series??
Please let me know your thoughts on this.
Regards,
Kedar.
> On Fri, Jul 27, 2018 at 1:22 AM, Appana Durga Kedareswara rao
> <appana.durga.rao@xilinx.com> wrote:
>
> Hi Appana,
>
> There should be some documentation for the debugfs added under
> Documentation/driver-api/fpga/
>
> Also there are a lot of #ifdefs that were added due to the
> CONFIG_FPGA_MGR_DEBUG_FS. This has caused a kernel robot complaint.
> The way to fix that is to have a separate c file for the debugfs implementation.
> I see a lot of other kernel drivers have done it this way. I have an
> implementation that I haven't submitted yet, it exposes different functionality
> (exposing the image firmware file name and writing to the image file). It's on
> the downstream github.com/altera-opensource repo [1]. I'll clean this up and
> submit it to the mailing list, it may take a minute for me to get to that.
> Once that's done, your added functionality can be a patch on top of that.
>
> Alan
>
> [1] https://github.com/altera-opensource/linux-socfpga/blob/socfpga-
> 4.17/drivers/fpga/fpga-mgr-debugfs.c
> https://github.com/altera-opensource/linux-socfpga/blob/socfpga-
> 4.17/drivers/fpga/fpga-mgr-debugfs.h
>
>
> > Inorder to debug issues with fpga's users would like to read the fpga
> > configuration information.
> > This patch adds readback support for fpga configuration data in the
> > framework through debugfs interface.
> >
> > Usage:
> > cat /sys/kernel/debug/fpga/fpga0/image
> >
> > Signed-off-by: Appana Durga Kedareswara rao
> > <appana.durga.rao@xilinx.com>
> > ---
> > Changes for v4:
> > --> None.
> > Changes for v3:
> > --> None.
> > Changes for v2:
> > --> Fixed debug attribute path and name as suggested by Alan Add
> > --> config entry for DEBUG as suggested by Alan Fixed trival coding
> > --> style issues.
> >
> > drivers/fpga/Kconfig | 7 +++++
> > drivers/fpga/fpga-mgr.c | 68
> +++++++++++++++++++++++++++++++++++++++++++
> > include/linux/fpga/fpga-mgr.h | 5 ++++
> > 3 files changed, 80 insertions(+)
> >
> > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index
> > 53d3f55..838ad4e 100644
> > --- a/drivers/fpga/Kconfig
> > +++ b/drivers/fpga/Kconfig
> > @@ -11,6 +11,13 @@ menuconfig FPGA
> >
> > if FPGA
> >
> > +config FPGA_MGR_DEBUG_FS
> > + tristate "FPGA Debug fs"
> > + select DEBUG_FS
> > + help
> > + FPGA manager debug provides support for reading fpga configuration
> > + information.
> > +
> > config FPGA_MGR_SOCFPGA
> > tristate "Altera SOCFPGA FPGA Manager"
> > depends on ARCH_SOCFPGA || COMPILE_TEST diff --git
> > a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c index
> > 9939d2c..4bea860 100644
> > --- a/drivers/fpga/fpga-mgr.c
> > +++ b/drivers/fpga/fpga-mgr.c
> > @@ -484,6 +484,48 @@ void fpga_mgr_put(struct fpga_manager *mgr) }
> > EXPORT_SYMBOL_GPL(fpga_mgr_put);
> >
> > +#ifdef CONFIG_FPGA_MGR_DEBUG_FS
> > +#include <linux/debugfs.h>
> > +
> > +static int fpga_mgr_read(struct seq_file *s, void *data) {
> > + struct fpga_manager *mgr = (struct fpga_manager *)s->private;
> > + int ret = 0;
> > +
> > + if (!mgr->mops->read)
> > + return -ENOENT;
> > +
> > + if (!mutex_trylock(&mgr->ref_mutex))
> > + return -EBUSY;
> > +
> > + if (mgr->state != FPGA_MGR_STATE_OPERATING) {
> > + ret = -EPERM;
> > + goto err_unlock;
> > + }
> > +
> > + /* Read the FPGA configuration data from the fabric */
> > + ret = mgr->mops->read(mgr, s);
> > + if (ret)
> > + dev_err(&mgr->dev, "Error while reading configuration
> > + data from FPGA\n");
> > +
> > +err_unlock:
> > + mutex_unlock(&mgr->ref_mutex);
> > +
> > + return ret;
> > +}
> > +
> > +static int fpga_mgr_read_open(struct inode *inode, struct file *file)
> > +{
> > + return single_open(file, fpga_mgr_read, inode->i_private); }
> > +
> > +static const struct file_operations fpga_mgr_ops_image = {
> > + .owner = THIS_MODULE,
> > + .open = fpga_mgr_read_open,
> > + .read = seq_read,
> > +};
> > +#endif
> > +
> > /**
> > * fpga_mgr_lock - Lock FPGA manager for exclusive use
> > * @mgr: fpga manager
> > @@ -581,6 +623,29 @@ int fpga_mgr_register(struct device *dev, const
> char *name,
> > if (ret)
> > goto error_device;
> >
> > +#ifdef CONFIG_FPGA_MGR_DEBUG_FS
> > + struct dentry *d, *parent;
> > +
> > + mgr->dir = debugfs_create_dir("fpga", NULL);
> > + if (!mgr->dir)
> > + goto error_device;
> > +
> > + parent = mgr->dir;
> > + d = debugfs_create_dir(mgr->dev.kobj.name, parent);
> > + if (!d) {
> > + debugfs_remove_recursive(parent);
> > + goto error_device;
> > + }
> > +
> > + parent = d;
> > + d = debugfs_create_file("image", 0644, parent, mgr,
> > + &fpga_mgr_ops_image);
> > + if (!d) {
> > + debugfs_remove_recursive(mgr->dir);
> > + goto error_device;
> > + }
> > +#endif
> > +
> > dev_info(&mgr->dev, "%s registered\n", mgr->name);
> >
> > return 0;
> > @@ -604,6 +669,9 @@ void fpga_mgr_unregister(struct device *dev)
> >
> > dev_info(&mgr->dev, "%s %s\n", __func__, mgr->name);
> >
> > +#ifdef CONFIG_FPGA_MGR_DEBUG_FS
> > + debugfs_remove_recursive(mgr->dir);
> > +#endif
> > /*
> > * If the low level driver provides a method for putting fpga into
> > * a desired state upon unregister, do it.
> > diff --git a/include/linux/fpga/fpga-mgr.h
> > b/include/linux/fpga/fpga-mgr.h index 3c6de23..e9e17a9 100644
> > --- a/include/linux/fpga/fpga-mgr.h
> > +++ b/include/linux/fpga/fpga-mgr.h
> > @@ -114,6 +114,7 @@ struct fpga_image_info {
> > * @write: write count bytes of configuration data to the FPGA
> > * @write_sg: write the scatter list of configuration data to the FPGA
> > * @write_complete: set FPGA to operating state after writing is done
> > + * @read: optional: read FPGA configuration information
> > * @fpga_remove: optional: Set FPGA into a specific state during driver
> remove
> > * @groups: optional attribute groups.
> > *
> > @@ -131,6 +132,7 @@ struct fpga_manager_ops {
> > int (*write_sg)(struct fpga_manager *mgr, struct sg_table *sgt);
> > int (*write_complete)(struct fpga_manager *mgr,
> > struct fpga_image_info *info);
> > + int (*read)(struct fpga_manager *mgr, struct seq_file *s);
> > void (*fpga_remove)(struct fpga_manager *mgr);
> > const struct attribute_group **groups; }; @@ -151,6 +153,9 @@
> > struct fpga_manager {
> > enum fpga_mgr_states state;
> > const struct fpga_manager_ops *mops;
> > void *priv;
> > +#ifdef CONFIG_FPGA_MGR_DEBUG_FS
> > + struct dentry *dir;
> > +#endif
> > };
> >
> > #define to_fpga_manager(d) container_of(d, struct fpga_manager, dev)
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-fpga"
> > in the body of a message to majordomo@vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: clock: meson: add A1 clock controller bindings
From: Jian Hu @ 2019-09-27 6:08 UTC (permalink / raw)
To: Jerome Brunet, Neil Armstrong
Cc: Rob Herring, Jianxin Pan, devicetree, Martin Blumenstingl,
Kevin Hilman, Michael Turquette, linux-kernel, Stephen Boyd,
Qiufang Dai, linux-amlogic, linux-clk, linux-arm-kernel
In-Reply-To: <1j4l10motk.fsf@starbuckisacylon.baylibre.com>
Hi, Jerome
Thank you for review.
On 2019/9/25 22:29, Jerome Brunet wrote:
> On Wed 25 Sep 2019 at 19:44, Jian Hu <jian.hu@amlogic.com> wrote:
>
> In addition to the comment expressed by Stephen on patch 2
>
got it.
>> Add the documentation to support Amlogic A1 clock driver,
>> and add A1 clock controller bindings.
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
>> ---
>> .../devicetree/bindings/clock/amlogic,a1-clkc.yaml | 65 +++++++++++++
>> include/dt-bindings/clock/a1-clkc.h | 102 +++++++++++++++++++++
>> 2 files changed, 167 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/clock/amlogic,a1-clkc.yaml
>> create mode 100644 include/dt-bindings/clock/a1-clkc.h
>>
>> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-clkc.yaml
>> new file mode 100644
>> index 0000000..f012eb2
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/amlogic,a1-clkc.yaml
>> @@ -0,0 +1,65 @@
>> +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
>> +/*
>> + * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
>> + */
>> +%YAML 1.2
>> +---
>> +$id: "http://devicetree.org/schemas/clock/amlogic,a1-clkc.yaml#"
>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
>> +
>> +title: Amlogic Meson A1 Clock Control Unit Device Tree Bindings
>> +
>> +maintainers:
>> + - Neil Armstrong <narmstrong@baylibre.com>
>> + - Jerome Brunet <jbrunet@baylibre.com>
>> + - Jian Hu <jian.hu@jian.hu.com>
>> +
>> +properties:
>> + compatible:
>> + - enum:
>> + - amlogic,a1-clkc
>> +
>> + reg:
>> + minItems: 1
>> + maxItems: 3
>> + items:
>> + - description: peripheral registers
>> + - description: cpu registers
>> + - description: pll registers
>> +
>> + reg-names:
>> + items:
>> + - const: peripheral
>> + - const: pll
>> + - const: cpu
>> +
>> + clocks:
>> + maxItems: 1
>> + items:
>> + - description: Input Oscillator (usually at 24MHz)
>> +
>> + clock-names:
>> + maxItems: 1
>> + items:
>> + - const: xtal
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - reg-names
>> + - clocks
>> + - clock-names
>> + - "#clock-cells"
>> +
>> +examples:
>> + - |
>> + clkc: clock-controller {
>> + compatible = "amlogic,a1-clkc";
>> + reg = <0x0 0xfe000800 0x0 0x100>,
>> + <0x0 0xfe007c00 0x0 0x21c>,
>> + <0x0 0xfd000080 0x0 0x20>;
>> + reg-names = "peripheral", "pll", "cpu";
>
> I'm sorry but I don't agree with this. You are trying to regroup several
> controllers into one with this, and it is not OK
>
> By the looks of it there are 3 different controllers, including one you
> did not implement in the driver.
>
Yes, In A1, the clock registers include three regions.
I agree with your opinion. I will implement the two clock drivers of
peripheral and plls first in PATCH V2. And CPU clock driver will be sent
after the patches are merged.
>> + clocks = <&xtal;
>> + clock-names = "xtal";
>> + #clock-cells = <1>;
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/3] dt-bindings: arm: fsl: add compatible string for Kobo Clara HD
From: Andreas Kemnade @ 2019-09-27 6:14 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
linux-imx, manivannan.sadhasivam, andrew.smirnov, marex, angus,
devicetree, linux-kernel, linux-arm-kernel, j.neuschaefer,
Discussions about the Letux Kernel
Cc: Andreas Kemnade
In-Reply-To: <20190927061423.17278-1-andreas@kemnade.info>
This adds a compatible string fro the Kobo Clara HD eBook reader.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 7294ac36f4c0..afa3bfeca0c0 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -148,6 +148,7 @@ properties:
items:
- enum:
- fsl,imx6sll-evk
+ - kobo,clarahd
- const: fsl,imx6sll
- description: i.MX6SX based Boards
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] dts: ARM: add Kobo Clara HD eBook reader
From: Andreas Kemnade @ 2019-09-27 6:14 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
linux-imx, manivannan.sadhasivam, andrew.smirnov, marex, angus,
devicetree, linux-kernel, linux-arm-kernel, j.neuschaefer,
Discussions about the Letux Kernel
Cc: Andreas Kemnade
This adds a device tree for the Kobo Clara HD eBook reader.
Name on mainboard is: 37NB-E60K00+4A4
Serials start with: E60K02 (a number also seen in
vendor kernel sources)
These boards are also found in the Tolino Shine 3 reader
but equipped with a i.MX6SL processor. Support for that
device is planned to be added in a later patch series.
To prepare for that the device tree is split up into
a board file containing SoC-independent stuff and a
file containing the SoC-dependent stuff.
Work is based on code from the vendor kernel at
https://github.com/kobolabs/Kobo-Reader/blob/master/hw/imx6sll-clara/kernel.tar.bz2
but things need to be heavily reworked due to
incompatible bindings and to prepare for Tolino Shine 3
Andreas Kemnade (3):
ARM: dts: add Netronix E60K02 board common file
dt-bindings: arm: fsl: add compatible string for Kobo Clara HD
ARM: dts: imx: add devicetree for Kobo Clara HD
.../devicetree/bindings/arm/fsl.yaml | 1 +
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/e60k02.dtsi | 339 ++++++++++++++++++
arch/arm/boot/dts/imx6sll-kobo-clarahd.dts | 275 ++++++++++++++
4 files changed, 617 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/e60k02.dtsi
create mode 100644 arch/arm/boot/dts/imx6sll-kobo-clarahd.dts
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] ARM: dts: imx: add devicetree for Kobo Clara HD
From: Andreas Kemnade @ 2019-09-27 6:14 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
linux-imx, manivannan.sadhasivam, andrew.smirnov, marex, angus,
devicetree, linux-kernel, linux-arm-kernel, j.neuschaefer,
Discussions about the Letux Kernel
Cc: Andreas Kemnade
In-Reply-To: <20190927061423.17278-1-andreas@kemnade.info>
This adds a devicetree for the Kobo Clara HD Ebook reader. It
is on based on boards called "e60k02". It is equipped with an
imx6sll SoC.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/imx6sll-kobo-clarahd.dts | 275 +++++++++++++++++++++
2 files changed, 277 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/imx6sll-kobo-clarahd.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9159fa2cea90..a8a235c74c37 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -551,7 +551,8 @@ dtb-$(CONFIG_SOC_IMX6SL) += \
imx6sl-evk.dtb \
imx6sl-warp.dtb
dtb-$(CONFIG_SOC_IMX6SLL) += \
- imx6sll-evk.dtb
+ imx6sll-evk.dtb \
+ imx6sll-kobo-clarahd.dtb
dtb-$(CONFIG_SOC_IMX6SX) += \
imx6sx-nitrogen6sx.dtb \
imx6sx-sabreauto.dtb \
diff --git a/arch/arm/boot/dts/imx6sll-kobo-clarahd.dts b/arch/arm/boot/dts/imx6sll-kobo-clarahd.dts
new file mode 100644
index 000000000000..f5ca44171d7c
--- /dev/null
+++ b/arch/arm/boot/dts/imx6sll-kobo-clarahd.dts
@@ -0,0 +1,275 @@
+// SPDX-License-Identifier: (GPL-2.0)
+/*
+ * Device tree for the Kobo Clara HD ebook reader
+ *
+ * Name on mainboard is: 37NB-E60K00+4A4
+ * Serials start with: E60K02 (a number also seen in
+ * vendor kernel sources)
+ *
+ * This mainboard seems to be equipped with different SoCs.
+ * In the Kobo Clara HD ebook reader it is an i.MX6SLL
+ *
+ * Copyright 2019 Andreas Kemnade
+ * based on works
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "imx6sll.dtsi"
+#include "e60k02.dtsi"
+
+/ {
+ model = "Kobo Clara HD";
+ compatible = "kobo,clarahd", "fsl,imx6sll";
+};
+
+&clks {
+ assigned-clocks = <&clks IMX6SLL_CLK_PLL4_AUDIO_DIV>;
+ assigned-clock-rates = <393216000>;
+};
+
+&cpu0 {
+ arm-supply = <&ricoh619_dcdc3_reg>;
+ soc-supply = <&ricoh619_dcdc1_reg>;
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ imx6sll-lpddr3-arm2 {
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ MX6SLL_PAD_LCD_DATA00__GPIO2_IO20 0x79
+ MX6SLL_PAD_LCD_DATA01__GPIO2_IO21 0x79
+ MX6SLL_PAD_LCD_DATA02__GPIO2_IO22 0x79
+ MX6SLL_PAD_LCD_DATA03__GPIO2_IO23 0x79
+ MX6SLL_PAD_LCD_DATA04__GPIO2_IO24 0x79
+ MX6SLL_PAD_LCD_DATA05__GPIO2_IO25 0x79
+ MX6SLL_PAD_LCD_DATA06__GPIO2_IO26 0x79
+ MX6SLL_PAD_LCD_DATA07__GPIO2_IO27 0x79
+ MX6SLL_PAD_LCD_DATA08__GPIO2_IO28 0x79
+ MX6SLL_PAD_LCD_DATA09__GPIO2_IO29 0x79
+ MX6SLL_PAD_LCD_DATA10__GPIO2_IO30 0x79
+ MX6SLL_PAD_LCD_DATA11__GPIO2_IO31 0x79
+ MX6SLL_PAD_LCD_DATA12__GPIO3_IO00 0x79
+ MX6SLL_PAD_LCD_DATA13__GPIO3_IO01 0x79
+ MX6SLL_PAD_LCD_DATA14__GPIO3_IO02 0x79
+ MX6SLL_PAD_LCD_DATA15__GPIO3_IO03 0x79
+ MX6SLL_PAD_LCD_DATA16__GPIO3_IO04 0x79
+ MX6SLL_PAD_LCD_DATA17__GPIO3_IO05 0x79
+ MX6SLL_PAD_LCD_DATA18__GPIO3_IO06 0x79
+ MX6SLL_PAD_LCD_DATA19__GPIO3_IO07 0x79
+ MX6SLL_PAD_LCD_DATA20__GPIO3_IO08 0x79
+ MX6SLL_PAD_LCD_DATA21__GPIO3_IO09 0x79
+ MX6SLL_PAD_LCD_DATA22__GPIO3_IO10 0x79
+ MX6SLL_PAD_LCD_DATA23__GPIO3_IO11 0x79
+ MX6SLL_PAD_LCD_CLK__GPIO2_IO15 0x79
+ MX6SLL_PAD_LCD_ENABLE__GPIO2_IO16 0x79
+ MX6SLL_PAD_LCD_HSYNC__GPIO2_IO17 0x79
+ MX6SLL_PAD_LCD_VSYNC__GPIO2_IO18 0x79
+ MX6SLL_PAD_LCD_RESET__GPIO2_IO19 0x79
+ MX6SLL_PAD_KEY_COL3__GPIO3_IO30 0x79
+ MX6SLL_PAD_KEY_ROW7__GPIO4_IO07 0x79
+ MX6SLL_PAD_ECSPI2_MOSI__GPIO4_IO13 0x79
+ MX6SLL_PAD_KEY_COL5__GPIO4_IO02 0x79
+ MX6SLL_PAD_KEY_ROW6__GPIO4_IO05 0x79
+ >;
+ };
+
+ pinctrl_usdhc3_pwr: usdhc3_pwr_grp {
+ fsl,pins = <
+ MX6SLL_PAD_SD2_DATA7__GPIO5_IO00 0x10059 /* WIFI_RST */
+ MX6SLL_PAD_SD2_DATA5__GPIO4_IO31 0x10059 /* WIFI_INT */
+ MX6SLL_PAD_SD2_DATA6__GPIO4_IO29 0x10059 /* WIFI_3V3_ON */
+ >;
+ };
+
+ pinctrl_audmux3: audmux3grp {
+ fsl,pins = <
+ MX6SLL_PAD_AUD_TXC__AUD3_TXC 0x4130b0
+ MX6SLL_PAD_AUD_TXFS__AUD3_TXFS 0x4130b0
+ MX6SLL_PAD_AUD_TXD__AUD3_TXD 0x4110b0
+ MX6SLL_PAD_AUD_RXD__AUD3_RXD 0x4130b0
+ MX6SLL_PAD_AUD_MCLK__AUDIO_CLK_OUT 0x4130b0
+ >;
+ };
+
+ pinctrl_led: ledgrp {
+ fsl,pins = <
+ MX6SLL_PAD_SD1_DATA6__GPIO5_IO07 0x17059
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6SLL_PAD_UART1_TXD__UART1_DCE_TX 0x1b0b1
+ MX6SLL_PAD_UART1_RXD__UART1_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6SLL_PAD_SD2_CMD__SD2_CMD 0x17059
+ MX6SLL_PAD_SD2_CLK__SD2_CLK 0x13059
+ MX6SLL_PAD_SD2_DATA0__SD2_DATA0 0x17059
+ MX6SLL_PAD_SD2_DATA1__SD2_DATA1 0x17059
+ MX6SLL_PAD_SD2_DATA2__SD2_DATA2 0x17059
+ MX6SLL_PAD_SD2_DATA3__SD2_DATA3 0x17059
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2grp_100mhz {
+ fsl,pins = <
+ MX6SLL_PAD_SD2_CMD__SD2_CMD 0x170b9
+ MX6SLL_PAD_SD2_CLK__SD2_CLK 0x130b9
+ MX6SLL_PAD_SD2_DATA0__SD2_DATA0 0x170b9
+ MX6SLL_PAD_SD2_DATA1__SD2_DATA1 0x170b9
+ MX6SLL_PAD_SD2_DATA2__SD2_DATA2 0x170b9
+ MX6SLL_PAD_SD2_DATA3__SD2_DATA3 0x170b9
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2grp_200mhz {
+ fsl,pins = <
+ MX6SLL_PAD_SD2_CMD__SD2_CMD 0x170f9
+ MX6SLL_PAD_SD2_CLK__SD2_CLK 0x130f9
+ MX6SLL_PAD_SD2_DATA0__SD2_DATA0 0x170f9
+ MX6SLL_PAD_SD2_DATA1__SD2_DATA1 0x170f9
+ MX6SLL_PAD_SD2_DATA2__SD2_DATA2 0x170f9
+ MX6SLL_PAD_SD2_DATA3__SD2_DATA3 0x170f9
+ >;
+ };
+
+ pinctrl_usdhc2_sleep: usdhc2grp_sleep {
+ fsl,pins = <
+ MX6SLL_PAD_SD2_CMD__GPIO5_IO04 0x100f9
+ MX6SLL_PAD_SD2_CLK__GPIO5_IO05 0x100f9
+ MX6SLL_PAD_SD2_DATA0__GPIO5_IO01 0x100f9
+ MX6SLL_PAD_SD2_DATA1__GPIO4_IO30 0x100f9
+ MX6SLL_PAD_SD2_DATA2__GPIO5_IO03 0x100f9
+ MX6SLL_PAD_SD2_DATA3__GPIO4_IO28 0x100f9
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX6SLL_PAD_SD3_CMD__SD3_CMD 0x11059
+ MX6SLL_PAD_SD3_CLK__SD3_CLK 0x11059
+ MX6SLL_PAD_SD3_DATA0__SD3_DATA0 0x11059
+ MX6SLL_PAD_SD3_DATA1__SD3_DATA1 0x11059
+ MX6SLL_PAD_SD3_DATA2__SD3_DATA2 0x11059
+ MX6SLL_PAD_SD3_DATA3__SD3_DATA3 0x11059
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3grp_100mhz {
+ fsl,pins = <
+ MX6SLL_PAD_SD3_CMD__SD3_CMD 0x170b9
+ MX6SLL_PAD_SD3_CLK__SD3_CLK 0x170b9
+ MX6SLL_PAD_SD3_DATA0__SD3_DATA0 0x170b9
+ MX6SLL_PAD_SD3_DATA1__SD3_DATA1 0x170b9
+ MX6SLL_PAD_SD3_DATA2__SD3_DATA2 0x170b9
+ MX6SLL_PAD_SD3_DATA3__SD3_DATA3 0x170b9
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3grp_200mhz {
+ fsl,pins = <
+ MX6SLL_PAD_SD3_CMD__SD3_CMD 0x170f9
+ MX6SLL_PAD_SD3_CLK__SD3_CLK 0x170f9
+ MX6SLL_PAD_SD3_DATA0__SD3_DATA0 0x170f9
+ MX6SLL_PAD_SD3_DATA1__SD3_DATA1 0x170f9
+ MX6SLL_PAD_SD3_DATA2__SD3_DATA2 0x170f9
+ MX6SLL_PAD_SD3_DATA3__SD3_DATA3 0x170f9
+ >;
+ };
+
+ pinctrl_usdhc3_sleep: usdhc3grp_sleep {
+ fsl,pins = <
+ MX6SLL_PAD_SD3_CMD__GPIO5_IO21 0x100c1
+ MX6SLL_PAD_SD3_CLK__GPIO5_IO18 0x100c1
+ MX6SLL_PAD_SD3_DATA0__GPIO5_IO19 0x100c1
+ MX6SLL_PAD_SD3_DATA1__GPIO5_IO20 0x100c1
+ MX6SLL_PAD_SD3_DATA2__GPIO5_IO16 0x100c1
+ MX6SLL_PAD_SD3_DATA3__GPIO5_IO17 0x100c1
+ >;
+ };
+
+ pinctrl_usbotg1: usbotg1grp {
+ fsl,pins = <
+ MX6SLL_PAD_EPDC_PWR_COM__USB_OTG1_ID 0x17059
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6SLL_PAD_I2C1_SCL__I2C1_SCL 0x4001f8b1
+ MX6SLL_PAD_I2C1_SDA__I2C1_SDA 0x4001f8b1
+ >;
+ };
+
+ pinctrl_i2c1_sleep: i2c1grp_sleep {
+ fsl,pins = <
+ MX6SLL_PAD_I2C1_SCL__I2C1_SCL 0x400108b1
+ MX6SLL_PAD_I2C1_SDA__I2C1_SDA 0x400108b1
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6SLL_PAD_I2C2_SCL__I2C2_SCL 0x4001f8b1
+ MX6SLL_PAD_I2C2_SDA__I2C2_SDA 0x4001f8b1
+ >;
+ };
+
+ pinctrl_i2c2_sleep: i2c2grp_sleep {
+ fsl,pins = <
+ MX6SLL_PAD_I2C2_SCL__I2C2_SCL 0x400108b1
+ MX6SLL_PAD_I2C2_SDA__I2C2_SDA 0x400108b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6SLL_PAD_REF_CLK_24M__I2C3_SCL 0x4001f8b1
+ MX6SLL_PAD_REF_CLK_32K__I2C3_SDA 0x4001f8b1
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX6SLL_PAD_ECSPI1_MISO__ECSPI1_MISO 0x100b1
+ MX6SLL_PAD_ECSPI1_MOSI__ECSPI1_MOSI 0x100b1
+ MX6SLL_PAD_ECSPI1_SCLK__ECSPI1_SCLK 0x100b1
+ MX6SLL_PAD_ECSPI1_SS0__GPIO4_IO11 0x100b1
+ >;
+ };
+
+ pinctrl_lm3630a_bl_gpio: lm3630a_bl_gpio_grp {
+ fsl,pins = <
+ MX6SLL_PAD_EPDC_PWR_CTRL3__GPIO2_IO10 0x10059 /* HWEN */
+ >;
+ };
+
+ pinctrl_ricoh_gpio: ricoh_gpio_grp {
+ fsl,pins = <
+ MX6SLL_PAD_SD1_CLK__GPIO5_IO15 0x1b8b1 /* ricoh619 chg */
+ MX6SLL_PAD_SD1_DATA0__GPIO5_IO11 0x1b8b1 /* ricoh619 irq */
+ MX6SLL_PAD_KEY_COL2__GPIO3_IO28 0x1b8b1 /* ricoh619 bat_low_int */
+ >;
+ };
+
+ pinctrl_gpio_keys: gpio_keys_grp {
+ fsl,pins = <
+ MX6SLL_PAD_SD1_DATA1__GPIO5_IO08 0x17059 /* PWR_SW */
+ MX6SLL_PAD_SD1_DATA4__GPIO5_IO12 0x17059 /* HALL_EN */
+ >;
+ };
+
+ };
+};
+
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: add Netronix E60K02 board common file
From: Andreas Kemnade @ 2019-09-27 6:14 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
linux-imx, manivannan.sadhasivam, andrew.smirnov, marex, angus,
devicetree, linux-kernel, linux-arm-kernel, j.neuschaefer,
Discussions about the Letux Kernel
Cc: Andreas Kemnade
In-Reply-To: <20190927061423.17278-1-andreas@kemnade.info>
The Netronix board E60K02 can be found some several Ebook-Readers,
at least the Kobo Clara HD and the Tolino Shine 3. The board
is equipped with different SoCs.
For now the following peripherals are included:
- LED
- Power Key
- Cover (gpio via hall sensor)
- RC5T619 PMIC (the kernel misses support for rtc and charger
subdevices).
- Backlight via lm3630a
- Wifi sdio chip detection (mmc-powerseq and stuff)
It is based on vendor kernel but heavily reworked due to many
changed bindings.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
backligt dependencies:
module autoloading:
https://patchwork.kernel.org/patch/11139987/
enable-gpios property:
https://patchwork.kernel.org/patch/11143795/
arch/arm/boot/dts/e60k02.dtsi | 339 ++++++++++++++++++++++++++++++++++
1 file changed, 339 insertions(+)
create mode 100644 arch/arm/boot/dts/e60k02.dtsi
diff --git a/arch/arm/boot/dts/e60k02.dtsi b/arch/arm/boot/dts/e60k02.dtsi
new file mode 100644
index 000000000000..c4fa8e314e2e
--- /dev/null
+++ b/arch/arm/boot/dts/e60k02.dtsi
@@ -0,0 +1,339 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 Andreas Kemnade
+ * based on works
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ * and
+ * Copyright (C) 2014 Ricoh Electronic Devices Co., Ltd
+ *
+ * Netronix E60K02 board common.
+ * This board is equipped with different SoCs and
+ * found in ebook-readers like the Kobo Clara HD (with i.MX6SLL) and
+ * the Tolino Shine 3 (with i.MX6SL)
+ */
+
+/ {
+
+ memory {
+ reg = <0x80000000 0x80000000>;
+ };
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ post-power-on-delay-ms = <20>;
+ reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+ };
+
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_sd3_vmmc: wifi_regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "SD3_SPWR";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+
+ gpio = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_led>;
+
+ GLED {
+ gpios = <&gpio5 7 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "timer";
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+ power {
+ label = "Power";
+ gpios = <&gpio5 8 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_POWER>;
+ gpio-key,wakeup;
+ };
+ cover {
+ label = "Cover";
+ gpios = <&gpio5 12 GPIO_ACTIVE_LOW>;
+ linux,code = <SW_LID>;
+ linux,input-type = <0x05>; /* EV_SW */
+ gpio-key,wakeup;
+ };
+ };
+
+};
+
+
+
+&audmux {
+ pinctrl-names = "default";
+ status = "disabled";
+};
+
+&snvs_rtc {
+ status = "disabled";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default","sleep";
+ pinctrl-0 = <&pinctrl_i2c1 &pinctrl_lm3630a_bl_gpio>;
+ pinctrl-1 = <&pinctrl_i2c1_sleep>;
+ status = "okay";
+
+ lm3630a: lm3630a-i2c@36 {
+ reg = <0x36>;
+ status = "ok";
+
+ compatible = "ti,lm3630a";
+ enable-gpios = <&gpio2 10 0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ led-sources = <0>;
+ label = "backlight_warm";
+ default-brightness = <0>;
+ max-brightness = <255>;
+ };
+
+ led@1 {
+ reg = <1>;
+ led-sources = <1>;
+ label = "backlight_cold";
+ default-brightness = <0>;
+ max-brightness = <255>;
+ };
+
+ };
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3 &pinctrl_ricoh_gpio>;
+ status = "okay";
+
+ ricoh619: ricoh619-i2c@32 {
+ compatible = "ricoh,rc5t619";
+ reg = <0x32>;
+
+ system-power-controller;
+ gpios = <&gpio5 11 GPIO_ACTIVE_LOW>;
+ gpio_chg = <&gpio5 15 GPIO_ACTIVE_LOW>;
+ gpio_bat_low = <&gpio3 28 GPIO_ACTIVE_LOW>;
+ };
+
+};
+
+&ricoh619
+{
+ compatible = "ricoh,rc5t619";
+
+ regulators {
+ ricoh619_dcdc1_reg: DCDC1 {
+ regulator-name = "DCDC1";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <900000>;
+ };
+ };
+
+ /* Core3_3V3 */
+ ricoh619_dcdc2_reg: DCDC2 {
+ regulator-name = "DCDC2";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ ricoh619_dcdc3_reg: DCDC3 {
+ regulator-name = "DCDC3";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-always-on;//
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1140000>;
+ };
+ };
+
+ /* Core4_1V2 */
+ ricoh619_dcdc4_reg: DCDC4 {
+ regulator-name = "DCDC4";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1140000>;
+ };
+ };
+
+ /* Core4_1V8 */
+ ricoh619_dcdc5_reg: DCDC5 {
+ regulator-name = "DCDC5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1700000>;
+ };
+ };
+
+ /* IR_3V3 */
+ ricoh619_ldo1_reg: LDO1 {
+ regulator-name = "LDO1";
+ //regulator-always-on;
+ regulator-boot-on;
+ };
+
+ /* Core1_3V3 */
+ ricoh619_ldo2_reg: LDO2 {
+ regulator-name = "LDO2";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ /* Core5_1V2 */
+ ricoh619_ldo3_reg: LDO3 {
+ regulator-name = "LDO3";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ricoh619_ldo4_reg: LDO4 {
+ regulator-name = "LDO4";
+ regulator-boot-on;
+ };
+
+ /* SPD_3V3 */
+ ricoh619_ldo5_reg: LDO5 {
+ regulator-name = "LDO5";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ /* DDR_0V6 */
+ ricoh619_ldo6_reg: LDO6 {
+ regulator-name = "LDO6";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ /* VDD_PWM */
+ ricoh619_ldo7_reg: LDO7 {
+ regulator-name = "LDO7";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ /* ldo_1v8 */
+ ricoh619_ldo8_reg: LDO8 {
+ regulator-name = "LDO8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ricoh619_ldo9_reg: LDO9 {
+ regulator-name = "LDO9";
+ regulator-boot-on;
+ };
+
+ ricoh619_ldo10_reg: LDO10 {
+ regulator-name = "LDO10";
+ regulator-boot-on;
+ };
+
+ ricoh619_ldortc1_reg: LDORTC1 {
+ regulator-name = "LDORTC1";
+ regulator-boot-on;
+ };
+
+ ricoh619_ldortc2_reg: LDORTC2 {
+ regulator-name = "LDORTC2";
+ regulator-boot-on;
+ };
+ };
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&usdhc1 {
+ status = "disabled";
+};
+
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz","sleep";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
+ pinctrl-3 = <&pinctrl_usdhc2_sleep>;
+ non-removable;
+ status = "okay";
+};
+
+&usdhc3 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz","sleep";
+ pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_usdhc3_pwr>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ pinctrl-3 = <&pinctrl_usdhc3_sleep>, <&pinctrl_usdhc3_pwr>;
+ vmmc-supply = <®_sd3_vmmc>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ cap-power-off-card;
+ non-removable;
+ status = "okay";
+};
+
+&usbotg1 {
+ pinctrl-names = "default";
+ disable-over-current;
+ srp-disable;
+ hnp-disable;
+ adp-disable;
+ status = "okay";
+};
+
+
+&ssi2 {
+ status = "disabled";
+};
+
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3] arm64: use generic free_initrd_mem()
From: Anshuman Khandual @ 2019-09-27 6:20 UTC (permalink / raw)
To: Mike Rapoport, Catalin Marinas, Will Deacon, Mark Rutland
Cc: Laura Abbott, linux-kernel, linux-arm-kernel, Mike Rapoport
In-Reply-To: <1569388180-28274-1-git-send-email-rppt@kernel.org>
On 09/25/2019 10:39 AM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> arm64 calls memblock_free() for the initrd area in its implementation of
> free_initrd_mem(), but this call has no actual effect that late in the boot
> process. By the time initrd is freed, all the reserved memory is managed by
> the page allocator and the memblock.reserved is unused, so the only purpose
> of the memblock_free() call is to keep track of initrd memory for debugging
> and accounting.
>
> Without the memblock_free() call the only difference between arm64 and the
> generic versions of free_initrd_mem() is the memory poisoning.
>
> Move memblock_free() call to the generic code, enable it there
> for the architectures that define ARCH_KEEP_MEMBLOCK and use the generic
> implementaion of free_initrd_mem() on arm64.
Small nit. s/implementaion/implementation.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
>
> v3:
> * fix powerpc build
>
> v2:
> * add memblock_free() to the generic free_initrd_mem()
> * rebase on the current upstream
>
>
> arch/arm64/mm/init.c | 12 ------------
> init/initramfs.c | 5 +++++
> 2 files changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 45c00a5..87a0e3b 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -580,18 +580,6 @@ void free_initmem(void)
> unmap_kernel_range((u64)__init_begin, (u64)(__init_end - __init_begin));
> }
>
> -#ifdef CONFIG_BLK_DEV_INITRD
> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> -{
> - unsigned long aligned_start, aligned_end;
> -
> - aligned_start = __virt_to_phys(start) & PAGE_MASK;
> - aligned_end = PAGE_ALIGN(__virt_to_phys(end));
> - memblock_free(aligned_start, aligned_end - aligned_start);
> - free_reserved_area((void *)start, (void *)end, 0, "initrd");
> -}
> -#endif
> -
> /*
> * Dump out memory limit information on panic.
> */
> diff --git a/init/initramfs.c b/init/initramfs.c
> index c47dad0..3d61e13 100644
> --- a/init/initramfs.c
> +++ b/init/initramfs.c
> @@ -10,6 +10,7 @@
> #include <linux/syscalls.h>
> #include <linux/utime.h>
> #include <linux/file.h>
> +#include <linux/memblock.h>
>
> static ssize_t __init xwrite(int fd, const char *p, size_t count)
> {
> @@ -531,6 +532,10 @@ void __weak free_initrd_mem(unsigned long start, unsigned long end)
> {
> free_reserved_area((void *)start, (void *)end, POISON_FREE_INITMEM,
> "initrd");
> +
> +#ifdef CONFIG_ARCH_KEEP_MEMBLOCK
Should not the addresses here be aligned first before calling memblock_free() ?
Without alignment, it breaks present behavior on arm64 which was explicitly added
with 13776f9d40a0 ("arm64: mm: free the initrd reserved memblock in a aligned manner").
Or does initrd always gets allocated with page alignment on other architectures.
> + memblock_free(__pa(start), end - start);
> +#endif
> }
>
> #ifdef CONFIG_KEXEC_CORE
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: timer: Use defines instead of numbers in Exynos MCT examples
From: Marek Szyprowski @ 2019-09-27 6:36 UTC (permalink / raw)
To: Krzysztof Kozlowski, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Mark Rutland, Kukjin Kim, linux-kernel, devicetree,
linux-arm-kernel, linux-samsung-soc
In-Reply-To: <20190926183643.7118-1-krzk@kernel.org>
Hi Krzysztof,
On 26.09.2019 20:36, Krzysztof Kozlowski wrote:
> Make the examples in Exynos Multi Core Timer bindings more readable and
> bring them closer to real DTS by using defines for interrupt flags.
>
> Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Rebased on top of:
> https://patchwork.kernel.org/project/linux-samsung-soc/list/?series=177667&state=*
> ---
> .../timer/samsung,exynos4210-mct.yaml | 37 ++++++++++++++-----
> 1 file changed, 27 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
> index bff3f54a398f..c4d152009f76 100644
> --- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
> +++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
> @@ -75,51 +75,68 @@ examples:
> // In this example, the IP contains two local timers, using separate
> // interrupts, so two local timer interrupts have been specified,
> // in addition to four global timer interrupts.
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>
> timer@10050000 {
> compatible = "samsung,exynos4210-mct";
> reg = <0x10050000 0x800>;
> - interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> - <0 42 0>, <0 48 0>;
> + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> - |
> // In this example, the timer interrupts are connected to two separate
> // interrupt controllers. Hence, an interrupts-extended is needed.
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>
> timer@101c0000 {
> compatible = "samsung,exynos4210-mct";
> reg = <0x101C0000 0x800>;
> - interrupts-extended = <&gic 0 57 0>,
> - <&gic 0 69 0>,
> + interrupts-extended = <&gic GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> + <&gic GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> <&combiner 12 6>,
> <&combiner 12 7>,
> - <&gic 0 42 0>,
> - <&gic 0 48 0>;
> + <&gic GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
> + <&gic GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> - |
> // In this example, the IP contains four local timers, but using
> // a per-processor interrupt to handle them. Only one first local
> // interrupt is specified.
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>
> timer@10050000 {
> compatible = "samsung,exynos4412-mct";
> reg = <0x10050000 0x800>;
>
> - interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> - <0 42 0>;
> + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
the last one should be GIC_PPI
> };
>
> - |
> // In this example, the IP contains four local timers, but using
> // a per-processor interrupt to handle them. All the local timer
> // interrupts are specified.
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>
> timer@10050000 {
> compatible = "samsung,exynos4412-mct";
> reg = <0x10050000 0x800>;
>
> - interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> - <0 42 0>, <0 42 0>, <0 42 0>, <0 42 0>;
> + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
again, last 4 entries should use GIC_PPI
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] soc: amlogic: ee-pwrc: ensure driver state maches HW state
From: Neil Armstrong @ 2019-09-27 6:37 UTC (permalink / raw)
To: Kevin Hilman, Kevin Hilman, linux-amlogic; +Cc: linux-arm-kernel, linux-pm
In-Reply-To: <7hwodulvu6.fsf@baylibre.com>
On 26/09/2019 21:08, Kevin Hilman wrote:
> Neil Armstrong <narmstrong@baylibre.com> writes:
>
>> On 25/09/2019 23:35, Kevin Hilman wrote:
>>> From: Kevin Hilman <khilman@baylibre.com>
>>>
>>> During init, ensure that the driver on/off state as well as clock and
>>> reset state matches the hardware state. Do this by always calling the
>>> drivers 'on' function, and then callling the 'off' function if the
>>> HW state was initially detected as off.
>
> [...]
>
>> I don't see what you are trying to solve except simplifying the code.
>
> Simplifying the code is a worthwhile goal on its own, but that's not the
> only thing I'm tring to accomplish.
I still find it ugly to power_on a domain to power it off right afterwards.
The issue is with the CCF enable handling which is not in sync with the
HW, if you boot with an already enabled clock, it won't be marked enabled
in CCF, and it's clearly bad when you want to have a fine-tuned gate state
handling.
>
> Part of the goal is make the init less VPU specific and thus make it
> more understandable/maintainable. But the more important part is to
> ensure that the driver state and HW state is consistent for all the
> domains (not just VPU.) I've had to debug lots of power-domain issues,
> and inconsistiences between HW state and driver state tend to be the
> primary cause of problems.
>
> Also I'm generally not a fan of the "don't mess with bootloader state"
> approach as that leads to subtle dependencies on specific bootloader
> versions that are also difficult to debug.
>
> Antother equally important goal is to actually be able to power-down the
> VPU when it's not used. Right now, we'll never power off the VPU if the
> bootloader enabled it, and that seems a bit extreme so I'm looking to
> improve that and be able to power off the VPU when not used.
>
>> And the case is more that "matching the clock state" here, the
>> pm_domain_always_on_gov was is a real case when booting from the Amlogic
>> U-boot.
>
> I'm not understanding what you mean about vendor uboot. I've done
> testing with vendor uboot too:
>
> I tried on g12a-u200, g12a-x96-max, and sm1-khadas-vim3l all of which
> have vendor uboot, and I tried before and after $SUBJECT patch.
>
> In all cases, I see the vendor uboot splash screen, and I see the
> framebuffer console from linux after kernel boot. I see the same
> behavior before and after my patch.
>
> I also tried on g12b-odroid-n2 (vendor uboot), and there is _no_ uboot
> spash screen, but I see the linux framebuffer console come up both
> before and after my patch.
Thanks for testing all these cases
>
> What's the specific case you're worried about with vendor uboot?
It's an issue I got when bringing up mainline uboot and the vpu power controller
driver, I had regressions on GXBB and GXL boards.
But it seems it's no more the case on G12A/G12B, we'll see this when
GX support will be added in this driver.
>
> Also... note something interesting I noticed on sm1-khadas-vim3l:
> before my patch, the framebuffer console appears, but the background is
> a bluish/green color. After my patch, the background is black (as
> expected.)
Yes it's an issue I have on my infinite todo list, it's a different
init done by the latest vendor uboot. I have a fix but it seems it
breaks display when booting other boards.
>
>> The display power domain is complex and as been half solved by using
>> "simple-framebuffer" on gx and is missing on g12a/g12b/sm1.
>>
>> For example, Debian installer runs without the modules, but will use
>> the EFIfb set by U-Boot, but in this precise case :
>> - the DRM driver isn't loaded
>> - we can't hook this power domain with EFIfb
>
> OK, so I agree that this case where we want the display to continue to
> work but linux DRM drivers never loaded is a special case.
>
> Is there a way to check if efifb is enabled? Is the the linux driver
> (drivers/video/fbdev/efifb.c) or something else only done by uboot?
>
> If we can detect efifb from the kernel (not just whether the domain is
> already on), then a simple addition to my patch like this:
>
> if (is_off)
> meson_ee_pwrc_off(&dom->base);
> + else if (efifb_is_enabled)
> + dom->base.flags |= GENPD_FLAG_ALWAYS_ON;
>
> would force the domain always-on in the case of efifb.
>
> In fact, now that I think of it, simply adding:
>
> if (is_off)
> meson_ee_pwrc_off(&dom->base);
> + else
> + dom->base.flags |= GENPD_FLAG_ALWAYS_ON;
>
> to my current patch would get back to the same behavior of the existing
> driver. But I still don't like the idea that we can *never* power off
> the VPU if the bootloader enables it. :( I'd rather see patches
> conditionally adding that flag with detailed explanations as to why it's
> needed.
>
>> When *not* in EFIfb, we use simple-framebuffer on GX, using this
>> power domain, but it hasn't been copied to G12A.
>
> I don't quite understand what problem simple-framebuffer is
> solving. Could you explain that in more detail.
simple-framebuffer has the power domain hooked in it's node, so
when u-boot will boot linux with HDMI enabled it will enable
this node and until the DRM driver loads the simple-framebuffer
will live and keep the power domain enabled.
>
> Assuming it is solving something, why can't it be used on g12[ab]/sm1 ?
It will, but I need to push the patches.
>
>> Personally I'll leave this code until we really tested and checked all
>> uses cases,
>
> Right, I don't want to break anything on purpose, but I think the
> current state of this driver is fragile and difficult to
> understand/maintain, so I would be grateful for any help in
> understanding the corner cases better, as well as testing them (or
> explaining to me how to reproduce them.)
>
> Generally, with long-term maintenance in mind, if I'm forced to choose
> between understandable/maintainable code and "covers 100% of corner
> cases" I will most often chose the former.
>
>> not only on the sei510/sei610 using mainline u-boot.
>
> See above about all the other boards with vendor uboots also tested.
Let's leave apart the vendor uboot issue for g12.
Since display support for G12A will land soon in mainline U-boot, let me
push the DT patches for simple-framebuffer to we have a fallback in
case the DRM driver isn't loaded/built.
We can consider that in case of EFIfb, the simple-framebuffer node would have
been enabled and the power domain hooked and enabled.
Neil
>
> Kevin
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFC 0/2] clk: meson: g12a: handle clock hw changes while in suspend
From: Neil Armstrong @ 2019-09-27 6:38 UTC (permalink / raw)
To: Kevin Hilman, sboyd, jbrunet, mturquette
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, linux-clk
In-Reply-To: <7htv8ykcpm.fsf@baylibre.com>
On 26/09/2019 22:46, Kevin Hilman wrote:
> Neil Armstrong <narmstrong@baylibre.com> writes:
>
>> This serie aime to support when the suspend/resume firmware alters the
>> clock tree, leading to an incorrect representation of the clock tree
>> after a resume from suspend-to-mem.
>>
>> For the Amlogic G12A/G12B/SM1 case, the SCPI firmware handling suspend
>> alters the CPU clock tree in various ways.
>>
>> Since we know which part of the tree is possibly altered, we introduce here
>> the clk_invalidate_rate() function that will rebuild the tree from the
>> hardware registers in case parents and dividers have changed.
>>
>> Finally we call clk_invalidate_rate() from a new resume callback to refresh
>> the CPU clock tree after a resume.
>>
>> With the clock tree refreshed, CCF can now handle the new clock tree
>> configuration and avoid crashing the system on further DVFS set_rates.
>
> For clarification, does this series work without the other proposed
> fixes[1]? or is this dependent on that?
>
> Kevin
>
> [1] https://lore.kernel.org/linux-amlogic/20190919093627.21245-1-narmstrong@baylibre.com/
>
These are independent, but you'll need both to have suspend/resume fully working.
Neil
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFC 1/2] clk: introduce clk_invalidate_rate()
From: Neil Armstrong @ 2019-09-27 6:40 UTC (permalink / raw)
To: Stephen Boyd, jbrunet, mturquette
Cc: linux-amlogic, linux-clk, linux-arm-kernel, linux-kernel
In-Reply-To: <20190927001425.DFDC7207FF@mail.kernel.org>
On 27/09/2019 02:14, Stephen Boyd wrote:
> Quoting Neil Armstrong (2019-09-19 03:25:17)
>> This introduces the clk_invalidate_rate() call used to recalculate the
>> rate and parent tree of a particular clock if it's known that the
>> underlying registers set has been altered by the firmware, like from
>> a suspend/resume handler running in trusted cpu mode.
>>
>> The call refreshes the actual parent and when changed, instructs CCF
>> the parent has changed. Finally the call will recalculate the rate of
>> each part of the tree to make sure the CCF cached tree is in sync with
>> the hardware.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>
> The knee-jerk reaction to these patches is that it shouldn't be a
> consumer API (i.e. taking a struct clk) but a provider API (i.e. taking
> a struct clk_hw). I haven't looked in any more detail but just know that
> it's a non-starter to be a consumer based API because we don't want
> random consumers out there to be telling the CCF or provider drivers
> that some clk has lost state and needs to be "refreshed".
>
Totally agree, I hesitated and obviously did the wrong choice, but
this is a nit, the main algorithm is not tied to the API level.
Should I resend it with clk_hw ? the difference will be small and
the main subject is the resync algorithm.
Neil
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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