* Re: [PATCH 1/3] pwm: atmel: Add link to reference manual
From: Nicolas.Ferre @ 2019-08-19 9:46 UTC (permalink / raw)
To: Claudiu.Beznea, uwe, thierry.reding
Cc: linux-pwm, alexandre.belloni, Ludovic.Desroches, linux-arm-kernel
In-Reply-To: <488f7c7e-6de5-f860-4a48-8f8a67cdcbc6@microchip.com>
On 19/08/2019 at 11:26, Claudiu Beznea - M18063 wrote:
>
>
> On 16.08.2019 00:41, Uwe Kleine-König wrote:
>> The reference manual for at least one of the supported variants is
>> publicly available. Add a link to it at the top of the driver.
>>
>> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
>> ---
>> drivers/pwm/pwm-atmel.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
>> index e5e1eaf372fa..ac3d7a200b9e 100644
>> --- a/drivers/pwm/pwm-atmel.c
>> +++ b/drivers/pwm/pwm-atmel.c
>> @@ -4,6 +4,9 @@
>> *
>> * Copyright (C) 2013 Atmel Corporation
>> * Bo Shen <voice.shen@atmel.com>
>> + *
>> + * Reference manual for "atmel,at91sam9rl-pwm":
>> + * http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf
>
> Even SAM9G25 PWM have almost the same registers with AT91SAM9RL, the
> datasheet for AT91SAM9RL is located at:
> http://ww1.microchip.com/downloads/en/DeviceDoc/doc6289.pdf
> Maybe we should use this one.
>
> I'm not familiar with having reference manuals in this part of the driver
> but if we are doing so would it be feasible to also have links for the rest
> SoCs that introduces new PWM versions? I'm thinking here at all the
> compatibles from atmel_pwm_dt_ids[]:
> - atmel,sama5d3-pwm
> - atmel,sama5d2-pwm
These documents are listed here:
Documentation/arm/microchip.rst
and must be maintained if URL are out of date. I don't believe that we
should add another reference to them in this driver (and other source code).
Referring to the datasheet pointed out by the microchip.rst file is
certainly the way to go...
Regards,
Nicolas
> - microchip,sam9x60-pwm
>
> Although the last one is not already public.
>
>> */
>>
>> #include <linux/clk.h>
>>
--
Nicolas Ferre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v4, 2/8] cpufreq: mediatek: add clock enable for intermediate clock
From: Viresh Kumar @ 2019-08-19 9:50 UTC (permalink / raw)
To: Andrew-sh.Cheng
Cc: Mark Rutland, Nishanth Menon, srv_heupstream, linux-pm,
Stephen Boyd, Rafael J. Wysocki, linux-kernel, Rob Herring,
Chanwoo Choi, Kyungmin Park, MyungJoo Ham, linux-mediatek,
linux-arm-kernel, Matthias Brugger, fan.chen, devicetree
In-Reply-To: <1565703113-31479-3-git-send-email-andrew-sh.cheng@mediatek.com>
On 13-08-19, 21:31, Andrew-sh.Cheng wrote:
> From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com>
>
> Intermediate clock is not always enabled by ccf in different projects,
> so cpufreq should always enable it by itself.
>
> Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
> ---
> drivers/cpufreq/mediatek-cpufreq.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
> index a370577ffc73..acd9539e95de 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -368,13 +368,17 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
> goto out_free_resources;
> }
>
> + ret = clk_prepare_enable(inter_clk);
> + if (ret)
> + goto out_free_opp_table;
> +
> /* Search a safe voltage for intermediate frequency. */
> rate = clk_get_rate(inter_clk);
> opp = dev_pm_opp_find_freq_ceil(cpu_dev, &rate);
> if (IS_ERR(opp)) {
> pr_err("failed to get intermediate opp for cpu%d\n", cpu);
> ret = PTR_ERR(opp);
> - goto out_free_opp_table;
> + goto out_disable_clock;
> }
> info->intermediate_voltage = dev_pm_opp_get_voltage(opp);
> dev_pm_opp_put(opp);
> @@ -393,6 +397,9 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
>
> return 0;
>
> +out_disable_clock:
> + clk_disable_unprepare(inter_clk);
> +
> out_free_opp_table:
> dev_pm_opp_of_cpumask_remove_table(&info->cpus);
>
> @@ -419,6 +426,10 @@ static void mtk_cpu_dvfs_info_release(struct mtk_cpu_dvfs_info *info)
> clk_put(info->cpu_clk);
> if (!IS_ERR(info->inter_clk))
> clk_put(info->inter_clk);
Shouldn't you remove this part now ?
> + if (!IS_ERR(info->inter_clk)) {
> + clk_disable_unprepare(info->inter_clk);
> + clk_put(info->inter_clk);
> + }
>
> dev_pm_opp_of_cpumask_remove_table(&info->cpus);
> }
> --
> 2.12.5
--
viresh
_______________________________________________
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 3/3] serial: sh-sci: Don't check for mctrl_gpio_to_gpiod() returning error
From: Simon Horman @ 2019-08-19 9:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Pengutronix Kernel Team, linux-serial, Richard Genoud,
Greg Kroah-Hartman, Sascha Hauer, Jiri Slaby, Frieder Schrempf,
linux-renesas-soc, NXP Linux Team, Fabio Estevam,
Uwe Kleine-König, Shawn Guo, linux-arm-kernel
In-Reply-To: <20190814092924.13857-4-geert+renesas@glider.be>
On Wed, Aug 14, 2019 at 11:29:24AM +0200, Geert Uytterhoeven wrote:
> Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
> routine"), mctrl_gpio_init() returns failure if the assignment to any
> member of the gpio array results in an error pointer.
> Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
> in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
> !CONFIG_GPIOLIB case.
> Hence there is no longer a need to check for mctrl_gpio_to_gpiod()
> returning an error value. A simple NULL check is sufficient.
>
> This follows the spirit of commit 445df7ff3fd1a0a9 ("serial: mctrl-gpio:
> drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> drivers/tty/serial/sh-sci.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index 7f565fcbf1ca4c5e..4e754a4850e6db63 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2099,12 +2099,12 @@ static unsigned int sci_get_mctrl(struct uart_port *port)
> if (s->autorts) {
> if (sci_get_cts(port))
> mctrl |= TIOCM_CTS;
> - } else if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_CTS))) {
> + } else if (!mctrl_gpio_to_gpiod(gpios, UART_GPIO_CTS)) {
> mctrl |= TIOCM_CTS;
> }
> - if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_DSR)))
> + if (!mctrl_gpio_to_gpiod(gpios, UART_GPIO_DSR))
> mctrl |= TIOCM_DSR;
> - if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_DCD)))
> + if (!mctrl_gpio_to_gpiod(gpios, UART_GPIO_DCD))
> mctrl |= TIOCM_CAR;
>
> return mctrl;
> @@ -3285,10 +3285,8 @@ static int sci_probe_single(struct platform_device *dev,
> return PTR_ERR(sciport->gpios);
>
> if (sciport->has_rtscts) {
> - if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(sciport->gpios,
> - UART_GPIO_CTS)) ||
> - !IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(sciport->gpios,
> - UART_GPIO_RTS))) {
> + if (mctrl_gpio_to_gpiod(sciport->gpios, UART_GPIO_CTS) ||
> + mctrl_gpio_to_gpiod(sciport->gpios, UART_GPIO_RTS)) {
> dev_err(&dev->dev, "Conflicting RTS/CTS config\n");
> return -EINVAL;
> }
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v4, 1/8] cpufreq: mediatek: change to regulator_get_optional
From: Viresh Kumar @ 2019-08-19 9:51 UTC (permalink / raw)
To: Andrew-sh.Cheng
Cc: Mark Rutland, Nishanth Menon, srv_heupstream, linux-pm,
Stephen Boyd, Rafael J. Wysocki, linux-kernel, Rob Herring,
Chanwoo Choi, Kyungmin Park, MyungJoo Ham, linux-mediatek,
linux-arm-kernel, Matthias Brugger, fan.chen, devicetree
In-Reply-To: <1565703113-31479-2-git-send-email-andrew-sh.cheng@mediatek.com>
On 13-08-19, 21:31, Andrew-sh.Cheng wrote:
> From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com>
>
> For new mediatek chip mt8183,
> cci and little cluster share the same buck,
> so need to modify the attribute of regulator from exclusive to optional
>
> Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
> ---
> drivers/cpufreq/mediatek-cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
> index f14f3a85f2f7..a370577ffc73 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -338,7 +338,7 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
> goto out_free_resources;
> }
>
> - proc_reg = regulator_get_exclusive(cpu_dev, "proc");
> + proc_reg = regulator_get_optional(cpu_dev, "proc");
> if (IS_ERR(proc_reg)) {
> if (PTR_ERR(proc_reg) == -EPROBE_DEFER)
> pr_warn("proc regulator for cpu%d not ready, retry.\n",
Applied. Thanks.
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v4, 3/8] cpufreq: mediatek: Add support for mt8183
From: Viresh Kumar @ 2019-08-19 9:59 UTC (permalink / raw)
To: Andrew-sh.Cheng
Cc: Mark Rutland, Nishanth Menon, srv_heupstream, linux-pm,
Stephen Boyd, Rafael J. Wysocki, linux-kernel, Rob Herring,
Chanwoo Choi, Kyungmin Park, MyungJoo Ham, linux-mediatek,
linux-arm-kernel, Matthias Brugger, fan.chen, devicetree
In-Reply-To: <1565703113-31479-4-git-send-email-andrew-sh.cheng@mediatek.com>
On 13-08-19, 21:31, Andrew-sh.Cheng wrote:
> From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com>
>
> Add compatible string for mediatek mt8183
>
> Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
> ---
> drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
> drivers/cpufreq/mediatek-cpufreq.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 03dc4244ab00..0f7e837a264e 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -117,6 +117,7 @@ static const struct of_device_id blacklist[] __initconst = {
> { .compatible = "mediatek,mt817x", },
> { .compatible = "mediatek,mt8173", },
> { .compatible = "mediatek,mt8176", },
> + { .compatible = "mediatek,mt8183", },
>
> { .compatible = "nvidia,tegra124", },
> { .compatible = "nvidia,tegra210", },
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
> index acd9539e95de..4dce41b18369 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -546,6 +546,7 @@ static const struct of_device_id mtk_cpufreq_machines[] __initconst = {
> { .compatible = "mediatek,mt817x", },
> { .compatible = "mediatek,mt8173", },
> { .compatible = "mediatek,mt8176", },
> + { .compatible = "mediatek,mt8183", },
Had to fix rebase conflict manually for this. Please always rebase on latest
linux-next.
Applied. Thanks.
--
viresh
_______________________________________________
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 0/9] Exynos Adaptive Supply Voltage support
From: Viresh Kumar @ 2019-08-19 10:06 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, linux-samsung-soc, linux-pm, vireshk, b.zolnierkie,
linux-kernel, krzk, robh+dt, kgene, pankaj.dubey,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190819090928.pke6cov52n4exlbp@vireshk-i7>
On 19-08-19, 14:39, Viresh Kumar wrote:
> On 09-08-19, 17:58, Sylwester Nawrocki wrote:
> > Thank you for your suggestions.
> >
> > For some Exynos SoC variants the algorithm of selecting CPU voltage supply
> > is a bit more complex than just selecting a column in the frequency/voltage
> > matrix, i.e. selecting a set of voltage values for whole frequency range.
> >
> > Frequency range could be divided into sub-ranges and to each such a sub-range
> > part of different column could be assigned, depending on data fused in
> > the CHIPID block registers.
> >
> > We could create OPP node for each frequency and specify all needed voltages
> > as a list of "opp-microvolt-<name>" properties but apart from the fact that
> > it would have been quite many properties, e.g. 42 (3 tables * 14 columns),
> > only for some SoC types the dev_pm_opp_set_prop_name() approach could be
> > used. We would need to be able to set opp-microvolt-* property name
> > separately for each frequency (OPP).
> >
> > Probably most future proof would be a DT binding where we could still
> > re-create those Exynos-specific ASV tables from DT. For example add named
> > opp-microvolt-* properties or something similar to hold rows of each ASV
> > table. But that conflicts with "operating-points-v2" binding, where
> > multiple OPP voltage values are described by just named properties and
> > multiple entries correspond to min/target/max.
> >
> > opp_table0 {
> > compatible = "...", "operating-points-v2";
> > opp-shared;
> > opp-2100000000 {
> > opp-hz = /bits/ 64 <1800000000>;
> > opp-microvolt = <...>;
> > opp-microvolt-t1 = <1362500>, <1350000>, ....;
> > opp-microvolt-t2 = <1362500>, <1360000>, ....;
> > opp-microvolt-t3 = <1362500>, <1340000>, ....;
> > };
> > ...
> > opp-200000000 {
> > opp-hz = /bits/ 64 <200000000>;
> > opp-microvolt = <...>;
> > opp-microvolt-t1 = <900000>, <900000>, ....;
> > opp-microvolt-t2 = <900000>, <900000>, ....;
> > opp-microvolt-t3 = <900000>, <900000>, ....;
> > };
> > };
> >
> > I might be missing some information now on how those Exynos ASV tables
> > are used on other SoCs that would need to be supported.
> >
> > There will be even more data to include when adding support for the Body
> > Bias voltage, for each CPU supply voltage we could possibly have
> > corresponding Body Bias voltage.
>
> Will something like this help ?
>
> https://lore.kernel.org/lkml/1442623929-4507-3-git-send-email-sboyd@codeaurora.org/
>
> This never got merged but the idea was AVS only.
Here is a recent version under review.
https://lore.kernel.org/lkml/1565703113-31479-1-git-send-email-andrew-sh.cheng@mediatek.com
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: aarch64 Kernel Panic Asynchronous SError Interrupt on large file IO
From: Catalin Marinas @ 2019-08-19 10:07 UTC (permalink / raw)
To: Philipp Richter
Cc: heiko, andre.przywara, Robin Murphy, vicencb, linux-rockchip,
Will Deacon, linux-arm-kernel
In-Reply-To: <CA+Vb7hpXfavS0k47Z0o=SkswO_jMmv3HN7RsUMdx=AHjvrD7LA@mail.gmail.com>
On Sat, Aug 17, 2019 at 03:12:41PM +0200, Philipp Richter wrote:
> I added "memtest=4" to the kernel cmdline and I'm getting very quicky
> a "Internal error: synchronous external abort" panic.
[...]
> [ 0.000000] early_memtest: # of tests: 4
> [ 0.000000] 0x0000000000200000 - 0x0000000002080000 pattern aaaaaaaaaaaaaaaa
> [ 0.000000] 0x0000000003a95000 - 0x00000000f8400000 pattern aaaaaaaaaaaaaaaa
> [ 0.000000] Internal error: synchronous external abort: 96000210 [#1] SMP
At least it's a synchronous error ;).
> [ 0.000000] pc : early_memtest+0x16c/0x23c
[...]
> [ 0.000000] Code: d2800002 d2800001 eb0400bf 54000309 (f9400080)
decodecode says:
0: d2800002 mov x2, #0x0 // #0
4: d2800001 mov x1, #0x0 // #0
8: eb0400bf cmp x5, x4
c: 54000309 b.ls 0x6c // b.plast
10:* f9400080 ldr x0, [x4] <-- trapping instruction
I guess that's the read of *p in memtest(). Writing *p probably
generates asynchronous errors it you haven't seen it yet.
> Is my board completely broken ? :(
One possibility is that you don't have any memory where you think there
is, so the mapping just doesn't translate to any valid physical
location.
Can you add some printk(addr) in do_sea() to see if it always faults on
the same address?
Another hack to hopefully track this down is to try to cope with such
synchronous aborts and hopefully you won't hit an asynchronous one
(SError). Quick hack below, only tested under kvm/qemu for booting and
passing memtest:
-----------8<-------------------------
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 2e6f42dc5a15..47efeedeccba 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -606,6 +606,9 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
const struct fault_info *inf;
void __user *siaddr;
+ if (!user_mode(regs) && fixup_exception(regs))
+ return 0;
+
inf = esr_to_fault_info(esr);
/*
diff --git a/mm/memtest.c b/mm/memtest.c
index f53ace709ccd..e878aa6bd1aa 100644
--- a/mm/memtest.c
+++ b/mm/memtest.c
@@ -3,6 +3,7 @@
#include <linux/types.h>
#include <linux/init.h>
#include <linux/memblock.h>
+#include <linux/uaccess.h>
static u64 patterns[] __initdata = {
/* The first entry has to be 0 to leave memtest with zeroed memory */
@@ -38,6 +39,7 @@ static void __init memtest(u64 pattern, phys_addr_t start_phys, phys_addr_t size
phys_addr_t start_bad, last_bad;
phys_addr_t start_phys_aligned;
const size_t incr = sizeof(pattern);
+ mm_segment_t old_fs;
start_phys_aligned = ALIGN(start_phys, incr);
start = __va(start_phys_aligned);
@@ -45,12 +47,20 @@ static void __init memtest(u64 pattern, phys_addr_t start_phys, phys_addr_t size
start_bad = 0;
last_bad = 0;
- for (p = start; p < end; p++)
- *p = pattern;
+ old_fs = get_fs();
+ set_fs(KERNEL_DS);
+ for (p = start; p < end; p++) {
+ u64 val;
+ if (!get_user(val, p))
+ *p = pattern;
+ }
for (p = start; p < end; p++, start_phys_aligned += incr) {
- if (*p == pattern)
- continue;
+ u64 val;
+ if (!get_user(val, p)) {
+ if (val == pattern)
+ continue;
+ }
if (start_phys_aligned == last_bad + incr) {
last_bad += incr;
continue;
@@ -61,6 +71,7 @@ static void __init memtest(u64 pattern, phys_addr_t start_phys, phys_addr_t size
}
if (start_bad)
reserve_bad_mem(pattern, start_bad, last_bad + incr);
+ set_fs(old_fs);
}
static void __init do_one_pass(u64 pattern, phys_addr_t start, phys_addr_t end)
_______________________________________________
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 0/2] ARM: psci: cpuidle: defconfig updates
From: Lorenzo Pieralisi @ 2019-08-19 10:21 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Rutland, Ulf Hansson, Catalin Marinas, Daniel Lezcano, soc,
Sudeep Holla, Will Deacon, LAKML
In-Reply-To: <20190819075716.GG5999@X250>
On Mon, Aug 19, 2019 at 09:57:17AM +0200, Shawn Guo wrote:
> On Wed, Aug 14, 2019 at 01:52:37PM +0100, Lorenzo Pieralisi wrote:
> > Rerouting defconfig updates related to this patch series:
> >
> > https://lore.kernel.org/linux-arm-kernel/cover.1565348376.git.lorenzo.pieralisi@arm.com/
> >
> > to arm-soc, as agreed in:
> >
> > https://lore.kernel.org/linux-arm-kernel/58d9677db3510ed106fe23118090c84f78a44102.1565348376.git.lorenzo.pieralisi@arm.com/
> >
> > Patches [1-6] are already queued in the ARM64 tree.
> >
> > Please consider pulling these defconfig changes, thank you very much.
>
> We, platform maintainers, also send arch/arm64/configs/defconfig changes
> to arm-soc folk. So I applied both patches to IMX tree and will send
> them to arm-soc for 5.4 inclusion.
Hi Shawn,
there is no need, these updates were already pulled in arm-soc so
there is nothing to do, please drop them.
Thanks,
Lorenzo
> Shawn
>
> >
> > Cc: Will Deacon <will@kernel.org>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>
> > Cc: Sudeep Holla <sudeep.holla@arm.com>
> > Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> >
> > Lorenzo Pieralisi (2):
> > arm64: defconfig: Enable the PSCI CPUidle driver
> > ARM: imx_v6_v7_defconfig: Enable the PSCI CPUidle driver
> >
> > arch/arm/configs/imx_v6_v7_defconfig | 1 +
> > arch/arm64/configs/defconfig | 1 +
> > 2 files changed, 2 insertions(+)
> >
> > --
> > 2.21.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: aarch64 Kernel Panic Asynchronous SError Interrupt on large file IO
From: Will Deacon @ 2019-08-19 10:43 UTC (permalink / raw)
To: Catalin Marinas
Cc: heiko, andre.przywara, vicencb, linux-rockchip, Philipp Richter,
Robin Murphy, linux-arm-kernel
In-Reply-To: <20190819100713.GA6117@arrakis.emea.arm.com>
On Mon, Aug 19, 2019 at 11:07:14AM +0100, Catalin Marinas wrote:
> On Sat, Aug 17, 2019 at 03:12:41PM +0200, Philipp Richter wrote:
> > I added "memtest=4" to the kernel cmdline and I'm getting very quicky
> > a "Internal error: synchronous external abort" panic.
> [...]
> > [ 0.000000] early_memtest: # of tests: 4
> > [ 0.000000] 0x0000000000200000 - 0x0000000002080000 pattern aaaaaaaaaaaaaaaa
> > [ 0.000000] 0x0000000003a95000 - 0x00000000f8400000 pattern aaaaaaaaaaaaaaaa
> > [ 0.000000] Internal error: synchronous external abort: 96000210 [#1] SMP
>
> At least it's a synchronous error ;).
>
> > [ 0.000000] pc : early_memtest+0x16c/0x23c
> [...]
> > [ 0.000000] Code: d2800002 d2800001 eb0400bf 54000309 (f9400080)
>
> decodecode says:
>
> 0: d2800002 mov x2, #0x0 // #0
> 4: d2800001 mov x1, #0x0 // #0
> 8: eb0400bf cmp x5, x4
> c: 54000309 b.ls 0x6c // b.plast
> 10:* f9400080 ldr x0, [x4] <-- trapping instruction
>
> I guess that's the read of *p in memtest(). Writing *p probably
> generates asynchronous errors it you haven't seen it yet.
>
> > Is my board completely broken ? :(
>
> One possibility is that you don't have any memory where you think there
> is, so the mapping just doesn't translate to any valid physical
> location.
>
> Can you add some printk(addr) in do_sea() to see if it always faults on
> the same address?
Alternatively, just run it a few more times and see if the register dump
changes. Currently we've got:
[ 0.000000] x5 : ffff8000f8400000 x4 : ffff800008400000
[ 0.000000] x3 : 0000000008400000 x2 : 0000000000000000
[ 0.000000] x1 : 0000000000000000 x0 : aaaaaaaaaaaaaaaa
so I'd guess that x3 is the faulting pa. The faulting (linear) VAs in the
originl report were 0xffff800009c74aa8 and 0xffff800009c08390, which is
still a way way off from this one :/
Looking at the TRM for the rk3328, there's 4gb of ram starting at pa 0x0,
so maybe some of it has been configured as secure or the memory controller
hasn't been properly initialised?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv3 6/6] smccc: make 1.1 macros value-returning
From: Mark Rutland @ 2019-08-19 10:44 UTC (permalink / raw)
To: Will Deacon
Cc: lorenzo.pieralisi, suzuki.poulose, marc.zyngier, catalin.marinas,
will.deacon, linux, james.morse, robin.murphy, linux-arm-kernel
In-Reply-To: <20190815164243.2hzydvjly6iwr3jf@willie-the-truck>
On Thu, Aug 15, 2019 at 05:42:44PM +0100, Will Deacon wrote:
> On Fri, Aug 09, 2019 at 02:22:45PM +0100, Mark Rutland wrote:
> > The arm_smccc_1_1_{smc,hvc}() macros for inline invocation take a res
> > pointer as their final argument, matching the out-of-line SMCCC
> > invocation functions.
> >
> > However, the inline invocation macros are variadic, so it's easy to mess
> > up passsing the correct parameters.
>
> passing
>
> > Instead, let's make them value-returning, which is less confusing.
>
> I'm not completely sure I agree with you here because, as far as I can
> tell, it means that we have a different calling convention for 1.0 (i.e.
> arm_smccc_smc()) and 1.1 (i.e. arm_smccc_1_1_smc).
>
> Can we do the same for 1.0 as well or am I missing something?
I will take a look; I think the QC quirk is the only thing that gets in
the way.
Mark.
_______________________________________________
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 4/3] pwm: atmel: document known weaknesses of both hardware and software
From: Uwe Kleine-König @ 2019-08-19 10:46 UTC (permalink / raw)
To: Claudiu.Beznea
Cc: linux-pwm, alexandre.belloni, Ludovic.Desroches, thierry.reding,
linux-arm-kernel
In-Reply-To: <0a389abe-15ef-0e63-109f-2db4cb36f4b9@microchip.com>
On Mon, Aug 19, 2019 at 09:26:04AM +0000, Claudiu.Beznea@microchip.com wrote:
>
>
> On 16.08.2019 12:37, Uwe Kleine-König wrote:
> > External E-Mail
> >
> >
> > Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
> > ---
> > drivers/pwm/pwm-atmel.c | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> > index 42fe7bc043a8..1ddb93db9627 100644
> > --- a/drivers/pwm/pwm-atmel.c
> > +++ b/drivers/pwm/pwm-atmel.c
> > @@ -7,6 +7,16 @@
> > *
> > * Reference manual for "atmel,at91sam9rl-pwm":
> > * http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf
> > + *
> > + * Limitations:
> > + * - Periods start with the inactive level.
>
> Are you talking here about the normal polarity (from documentation: By
> definition, normal polarity characterizes a signal starts high for the
> duration of the duty cycle and goes low for the remainder of the period.)
When .polarity = PWM_POLARITY_NORMAL is passed to atmel_pwm_apply() the
drivers sets PWM_CMR_CPOL=0 which according to the datasheet (linked
above) means: "The output waveform starts at a low level."
So maybe just the logic has to be inverted there, but then maybe the
output gets active instead of inactive when the PWM is disabled.
(Which in my book is ok, but it's Thierry's opinion that counts here.)
> If yes, this should be solved by playing with CPOL bit of CMR.
>
> > + * - Hardware has to be stopped in general to update settings.
>
> Sama5d2 has duty cycle that could be updated on the fly.
There is some functionality in the 9G25, too. I didn't understand it
completely but maybe it only helps updating one of period or duty cycle.
> > + *
> > + * Software bugs/possible improvements:
> > + * - When atmel_pwm_apply() is called with state->enabled=false a change in
> > + * state->polarity isn't honored.
>
> I know that when configuring a PWM one should get the current state of the
> PWM, change it, then pass it to the driver via pwm_apply_state().
That seems to be a common pattern at least. IMHO letting the consumer
just configure the state that should be used should be fine, too.
> In case one would call the pwm_apply_state() with state->enabled =
> false the state would be stored in PWM specific object (of type struct
> pwm_device). On the next apply, with enabled = true, all the PWM
> parameters would be actually applied to hardware. So, until
> enable=true the PWM state would only be cached by PWM core specific
> objects (in pwm_apply_state()).
I fail to follow what you mean here. If a PWM runs with (say) normal
polarity and you call pwm_apply_state(mypwm, { .polarity =
PWM_POLARITY_INVERSED, .enabled = false, }); the apply callback of the
lowlevel driver is called and supposed to configure the output to yield
a constant high.
> > + * - Instead of sleeping to wait for a completed period, the interrupt
> > + * functionality could be used.
> > */
> >
> > #include <linux/clk.h>
> >
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
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 01/21] ARM: dts: imx7-colibri: make sure module supplies are always on
From: Shawn Guo @ 2019-08-19 10:58 UTC (permalink / raw)
To: Philippe Schenker
Cc: Mark Rutland, devicetree@vger.kernel.org, Michal Vokáč,
Pengutronix Kernel Team, Marcel Ziswiler, Sascha Hauer,
linux-kernel@vger.kernel.org, stefan@agner.ch, Rob Herring,
NXP Linux Team, Max Krummenacher, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190812142105.1995-2-philippe.schenker@toradex.com>
On Mon, Aug 12, 2019 at 02:21:15PM +0000, Philippe Schenker wrote:
> From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> Prevent regulators from being switched off.
>
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Applied, thanks.
_______________________________________________
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 02/21] ARM: dts: imx7-colibri: disable HS400
From: Shawn Guo @ 2019-08-19 11:06 UTC (permalink / raw)
To: Philippe Schenker
Cc: Mark Rutland, devicetree@vger.kernel.org, Michal Vokáč,
Pengutronix Kernel Team, Stefan Agner, Marcel Ziswiler,
Sascha Hauer, linux-kernel@vger.kernel.org, stefan@agner.ch,
Rob Herring, NXP Linux Team, Max Krummenacher, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190812142105.1995-3-philippe.schenker@toradex.com>
On Mon, Aug 12, 2019 at 02:21:17PM +0000, Philippe Schenker wrote:
> From: Stefan Agner <stefan.agner@toradex.com>
>
> Force HS200 by masking bit 63 of the SDHCI capability register.
> The i.MX ESDHC driver uses SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400. With
> that the stack checks bit 63 to descide whether HS400 is available.
> Using sdhci-caps-mask allows to mask bit 63. The stack then selects
> HS200 as operating mode.
>
> This prevents rare communication errors with minimal effect on
> performance:
> sdhci-esdhc-imx 30b60000.usdhc: warning! HS400 strobe DLL
> status REF not lock!
>
> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Applied, thanks.
_______________________________________________
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 03/21] ARM: dts: imx7-colibri: prepare module device tree for FlexCAN
From: Shawn Guo @ 2019-08-19 11:09 UTC (permalink / raw)
To: Philippe Schenker
Cc: Mark Rutland, devicetree@vger.kernel.org, Michal Vokáč,
Pengutronix Kernel Team, Marcel Ziswiler, Sascha Hauer,
linux-kernel@vger.kernel.org, stefan@agner.ch, Rob Herring,
NXP Linux Team, Max Krummenacher, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190812142105.1995-4-philippe.schenker@toradex.com>
On Mon, Aug 12, 2019 at 02:21:18PM +0000, Philippe Schenker wrote:
> Prepare FlexCAN use on SODIMM 55/63 178/188. Those SODIMM pins are
> compatible for CAN bus use with several modules from the Colibri
> family.
> Add Better drivestrength and also add flexcan2.
>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Applied, thanks.
_______________________________________________
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 04/21] ARM: dts: imx7-colibri: Add sleep mode to ethernet
From: Shawn Guo @ 2019-08-19 11:12 UTC (permalink / raw)
To: Philippe Schenker
Cc: Mark Rutland, devicetree@vger.kernel.org, Michal Vokáč,
Pengutronix Kernel Team, Marcel Ziswiler, Sascha Hauer,
linux-kernel@vger.kernel.org, stefan@agner.ch, Rob Herring,
NXP Linux Team, Max Krummenacher, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190812142105.1995-5-philippe.schenker@toradex.com>
On Mon, Aug 12, 2019 at 02:21:19PM +0000, Philippe Schenker wrote:
> Add sleep pinmux to the fec so it can properly sleep.
>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
I did s/mode/pinctrl in subject and applied the patch.
Shawn
_______________________________________________
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 05/21] ARM: dts: imx7-colibri: add recovery for I2C for iMX7
From: Shawn Guo @ 2019-08-19 11:14 UTC (permalink / raw)
To: Philippe Schenker
Cc: Mark Rutland, devicetree@vger.kernel.org, Michal Vokáč,
Pengutronix Kernel Team, Marcel Ziswiler, Sascha Hauer,
linux-kernel@vger.kernel.org, stefan@agner.ch, Oleksandr Suvorov,
Rob Herring, NXP Linux Team, Max Krummenacher, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190812142105.1995-6-philippe.schenker@toradex.com>
On Mon, Aug 12, 2019 at 02:21:21PM +0000, Philippe Schenker wrote:
> From: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
>
> - add recovery mode for applicable i2c buses for
> Colibri iMX7 module.
>
> Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Applied, thanks.
_______________________________________________
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 0/9] Exynos Adaptive Supply Voltage support
From: Sylwester Nawrocki @ 2019-08-19 11:16 UTC (permalink / raw)
To: Viresh Kumar
Cc: devicetree, linux-samsung-soc, linux-pm, vireshk, b.zolnierkie,
linux-kernel, krzk, robh+dt, kgene, pankaj.dubey,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190819090928.pke6cov52n4exlbp@vireshk-i7>
On 8/19/19 11:09, Viresh Kumar wrote:
> Will something like this help ?
>
> https://lore.kernel.org/lkml/1442623929-4507-3-git-send-email-sboyd@codeaurora.org/
>
> This never got merged but the idea was AVS only.
It's quite interesting work, it seems to be for a more advanced use case
where OPP voltage is being adjusted at runtime.
We could use it instead of removing an OPP and then adding with updated
voltage. On Exynos there is there is just a need to update OPPs once at boot
time, so it is more "static". However the requirements could presumably
change in future.
If that's your preference I could switch to that notifier approach.
AFAICS the API would still need to be extended to support multiple voltages,
when in future we add support for the Body Bias regulator.
--
Thanks,
Sylwester
_______________________________________________
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 06/21] ARM: dts: imx7-colibri: add GPIO wakeup key
From: Shawn Guo @ 2019-08-19 11:17 UTC (permalink / raw)
To: Philippe Schenker
Cc: Mark Rutland, devicetree@vger.kernel.org, Michal Vokáč,
Pengutronix Kernel Team, Stefan Agner, Marcel Ziswiler,
Sascha Hauer, linux-kernel@vger.kernel.org, stefan@agner.ch,
Rob Herring, NXP Linux Team, Max Krummenacher, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190812142105.1995-7-philippe.schenker@toradex.com>
On Mon, Aug 12, 2019 at 02:21:23PM +0000, Philippe Schenker wrote:
> From: Stefan Agner <stefan.agner@toradex.com>
>
> Add wakeup GPIO key which is able to wake the system from sleep
> modes (e.g. Suspend-to-Memory).
>
> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> ---
>
> Changes in v4:
> - Add Marcel Ziswiler's Ack
>
> Changes in v3: None
> Changes in v2: None
>
> arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 14 ++++++++++++++
> arch/arm/boot/dts/imx7-colibri.dtsi | 7 ++++++-
> 2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> index 3f2746169181..d4dbc4fc1adf 100644
> --- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> +++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> @@ -52,6 +52,20 @@
> clock-frequency = <16000000>;
> };
>
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpiokeys>;
> +
> + power {
> + label = "Wake-Up";
> + gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
> + linux,code = <KEY_WAKEUP>;
> + debounce-interval = <10>;
> + gpio-key,wakeup;
Please check Documentation/devicetree/bindings/power/wakeup-source.txt
Shawn
> + };
> + };
> +
> panel: panel {
> compatible = "edt,et057090dhu";
> backlight = <&bl>;
> diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
> index cab40d22d24e..5347ed38acb2 100644
> --- a/arch/arm/boot/dts/imx7-colibri.dtsi
> +++ b/arch/arm/boot/dts/imx7-colibri.dtsi
> @@ -741,12 +741,17 @@
>
> pinctrl_gpio_lpsr: gpio1-grp {
> fsl,pins = <
> - MX7D_PAD_LPSR_GPIO1_IO01__GPIO1_IO1 0x59
> MX7D_PAD_LPSR_GPIO1_IO02__GPIO1_IO2 0x59
> MX7D_PAD_LPSR_GPIO1_IO03__GPIO1_IO3 0x59
> >;
> };
>
> + pinctrl_gpiokeys: gpiokeysgrp {
> + fsl,pins = <
> + MX7D_PAD_LPSR_GPIO1_IO01__GPIO1_IO1 0x19
> + >;
> + };
> +
> pinctrl_i2c1: i2c1-grp {
> fsl,pins = <
> MX7D_PAD_LPSR_GPIO1_IO05__I2C1_SDA 0x4000007f
> --
> 2.22.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v4, 6/8] PM / OPP: Support adjusting OPP voltages at runtime
From: Viresh Kumar @ 2019-08-19 11:18 UTC (permalink / raw)
To: Andrew-sh.Cheng
Cc: Mark Rutland, Nishanth Menon, srv_heupstream, linux-pm,
Stephen Boyd, Stephen Boyd, Rafael J. Wysocki, linux-kernel,
Rob Herring, Chanwoo Choi, Kyungmin Park, MyungJoo Ham,
linux-mediatek, linux-arm-kernel, Matthias Brugger, fan.chen,
devicetree, Roger Lu
In-Reply-To: <1565703113-31479-7-git-send-email-andrew-sh.cheng@mediatek.com>
On 13-08-19, 21:31, Andrew-sh.Cheng wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> On some SoCs the Adaptive Voltage Scaling (AVS) technique is
> employed to optimize the operating voltage of a device. At a
> given frequency, the hardware monitors dynamic factors and either
> makes a suggestion for how much to adjust a voltage for the
> current frequency, or it automatically adjusts the voltage
> without software intervention. Add an API to the OPP library for
> the former case, so that AVS type devices can update the voltages
> for an OPP when the hardware determines the voltage should
> change. The assumption is that drivers like CPUfreq or devfreq
> will register for the OPP notifiers and adjust the voltage
> according to suggestions that AVS makes.
>
> This patch is devired from [1] submitted by Stephen.
> [1] https://lore.kernel.org/patchwork/patch/599279/
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>
> ---
> drivers/opp/core.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/pm_opp.h | 11 +++++++++
> 2 files changed, 74 insertions(+)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index c094d5d20fd7..407a07f29b12 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -2054,6 +2054,69 @@ static int _opp_set_availability(struct device *dev, unsigned long freq,
> }
>
> /**
> + * dev_pm_opp_adjust_voltage() - helper to change the voltage of an OPP
> + * @dev: device for which we do this operation
> + * @freq: OPP frequency to adjust voltage of
> + * @u_volt: new OPP voltage
> + *
> + * Return: -EINVAL for bad pointers, -ENOMEM if no memory available for the
> + * copy operation, returns 0 if no modifcation was done OR modification was
> + * successful.
> + */
> +int dev_pm_opp_adjust_voltage(struct device *dev, unsigned long freq,
> + unsigned long u_volt)
Can you please update this to take a triplet instead ? That is what we are
storing in OPP core now a days.
--
viresh
_______________________________________________
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 07/21] ARM: dts: imx7-colibri: fix 1.8V/UHS support
From: Shawn Guo @ 2019-08-19 11:18 UTC (permalink / raw)
To: Philippe Schenker
Cc: Mark Rutland, devicetree@vger.kernel.org, Michal Vokáč,
Pengutronix Kernel Team, Stefan Agner, Marcel Ziswiler,
Sascha Hauer, linux-kernel@vger.kernel.org, stefan@agner.ch,
Rob Herring, NXP Linux Team, Max Krummenacher, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190812142105.1995-8-philippe.schenker@toradex.com>
On Mon, Aug 12, 2019 at 02:21:25PM +0000, Philippe Schenker wrote:
> From: Stefan Agner <stefan.agner@toradex.com>
>
> Add pinmuxing and do not specify voltage restrictions for the usdhc
> instance available on the modules edge connector. This allows to use
> SD-cards with higher transfer modes if supported by the carrier board.
>
> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> ---
>
> Changes in v4:
> - Add Marcel Ziswiler's Ack
>
> Changes in v3:
> - Add new commit message from Stefan's proposal on ML
>
> Changes in v2: None
>
> arch/arm/boot/dts/imx7-colibri.dtsi | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
> index 5347ed38acb2..c563bb821b5e 100644
> --- a/arch/arm/boot/dts/imx7-colibri.dtsi
> +++ b/arch/arm/boot/dts/imx7-colibri.dtsi
> @@ -326,7 +326,6 @@
> &usdhc1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usdhc1 &pinctrl_cd_usdhc1>;
> - no-1-8-v;
> cd-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
> disable-wp;
> vqmmc-supply = <®_LDO2>;
> @@ -671,6 +670,28 @@
> >;
> };
>
> + pinctrl_usdhc1_100mhz: usdhc1grp_100mhz {
> + fsl,pins = <
> + MX7D_PAD_SD1_CMD__SD1_CMD 0x5a
> + MX7D_PAD_SD1_CLK__SD1_CLK 0x1a
> + MX7D_PAD_SD1_DATA0__SD1_DATA0 0x5a
> + MX7D_PAD_SD1_DATA1__SD1_DATA1 0x5a
> + MX7D_PAD_SD1_DATA2__SD1_DATA2 0x5a
> + MX7D_PAD_SD1_DATA3__SD1_DATA3 0x5a
> + >;
> + };
> +
> + pinctrl_usdhc1_200mhz: usdhc1grp_200mhz {
No reference to them from usdhc1 node?
Shawn
> + fsl,pins = <
> + MX7D_PAD_SD1_CMD__SD1_CMD 0x5b
> + MX7D_PAD_SD1_CLK__SD1_CLK 0x1b
> + MX7D_PAD_SD1_DATA0__SD1_DATA0 0x5b
> + MX7D_PAD_SD1_DATA1__SD1_DATA1 0x5b
> + MX7D_PAD_SD1_DATA2__SD1_DATA2 0x5b
> + MX7D_PAD_SD1_DATA3__SD1_DATA3 0x5b
> + >;
> + };
> +
> pinctrl_usdhc3: usdhc3grp {
> fsl,pins = <
> MX7D_PAD_SD3_CMD__SD3_CMD 0x59
> --
> 2.22.0
>
_______________________________________________
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 08/21] ARM: dts: imx7-colibri: Add touch controllers
From: Shawn Guo @ 2019-08-19 11:21 UTC (permalink / raw)
To: Philippe Schenker
Cc: Mark Rutland, devicetree@vger.kernel.org, Michal Vokáč,
Pengutronix Kernel Team, Marcel Ziswiler, Sascha Hauer,
linux-kernel@vger.kernel.org, stefan@agner.ch, Rob Herring,
NXP Linux Team, Max Krummenacher, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190812142105.1995-9-philippe.schenker@toradex.com>
On Mon, Aug 12, 2019 at 02:21:26PM +0000, Philippe Schenker wrote:
> Add touch controller that is connected over an I2C bus.
>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> ---
>
> Changes in v4:
> - Add Marcel Ziswiler's Ack
>
> Changes in v3:
> - Fix commit message
>
> Changes in v2:
> - Deleted touchrevolution downstream stuff
> - Use generic node name
> - Better comment
>
> arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 24 +++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> index d4dbc4fc1adf..576dec9ff81c 100644
> --- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> +++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> @@ -145,6 +145,21 @@
> &i2c4 {
> status = "okay";
>
> + /*
> + * Touchscreen is using SODIMM 28/30, also used for PWM<B>, PWM<C>,
> + * aka pwm2, pwm3. so if you enable touchscreen, disable the pwms
> + */
> + touchscreen@4a {
> + compatible = "atmel,maxtouch";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpiotouch>;
> + reg = <0x4a>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /* SODIMM 28 */
> + reset-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>; /* SODIMM 30 */
> + status = "disabled";
Why disabled?
Shawn
> + };
> +
> /* M41T0M6 real time clock on carrier board */
> rtc: m41t0m6@68 {
> compatible = "st,m41t0";
> @@ -200,3 +215,12 @@
> vmmc-supply = <®_3v3>;
> status = "okay";
> };
> +
> +&iomuxc {
> + pinctrl_gpiotouch: touchgpios {
> + fsl,pins = <
> + MX7D_PAD_GPIO1_IO09__GPIO1_IO9 0x74
> + MX7D_PAD_GPIO1_IO10__GPIO1_IO10 0x14
> + >;
> + };
> +};
> --
> 2.22.0
>
_______________________________________________
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 09/21] ARM: dts: imx6qdl-colibri: add phy to fec
From: Shawn Guo @ 2019-08-19 11:22 UTC (permalink / raw)
To: Philippe Schenker
Cc: Mark Rutland, devicetree@vger.kernel.org, Michal Vokáč,
Pengutronix Kernel Team, Marcel Ziswiler, Sascha Hauer,
linux-kernel@vger.kernel.org, stefan@agner.ch, Rob Herring,
NXP Linux Team, Max Krummenacher, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190812142105.1995-10-philippe.schenker@toradex.com>
On Mon, Aug 12, 2019 at 02:21:28PM +0000, Philippe Schenker wrote:
> Add the phy-node and mdio bus to the fec-node, represented as is on
> hardware.
> This commit includes micrel,led-mode that is set to the default
> value, prepared for someone who wants to change this.
>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Applied, thanks.
_______________________________________________
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 v9 08/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode
From: Will Deacon @ 2019-08-19 11:24 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang,
srv_heupstream, chao.hao, Joerg Roedel, linux-kernel, Evan Green,
Tomasz Figa, iommu, Rob Herring, linux-mediatek, Matthias Brugger,
ming-fan.chen, anan.sun, Robin Murphy, Matthias Kaehlcke,
linux-arm-kernel
In-Reply-To: <1565940140.20346.21.camel@mhfsdcap03>
On Fri, Aug 16, 2019 at 03:22:20PM +0800, Yong Wu wrote:
> On Thu, 2019-08-15 at 12:50 +0100, Will Deacon wrote:
> > Ok, I think speaking to Robin helped me a bit with this...
> >
> > On Thu, Aug 15, 2019 at 06:18:38PM +0800, Yong Wu wrote:
> > > On Thu, 2019-08-15 at 10:51 +0100, Will Deacon wrote:
> > > > On Thu, Aug 15, 2019 at 04:47:49PM +0800, Yong Wu wrote:
> > > > > On Wed, 2019-08-14 at 15:41 +0100, Will Deacon wrote:
> > > > > > On Sat, Aug 10, 2019 at 03:58:08PM +0800, Yong Wu wrote:
> > > > > > > MediaTek extend the arm v7s descriptor to support the dram over 4GB.
> > > > > > >
> > > > > > > In the mt2712 and mt8173, it's called "4GB mode", the physical address
> > > > > > > is from 0x4000_0000 to 0x1_3fff_ffff, but from EMI point of view, it
> > > > > > > is remapped to high address from 0x1_0000_0000 to 0x1_ffff_ffff, the
> > > > > > > bit32 is always enabled. thus, in the M4U, we always enable the bit9
> > > > > > > for all PTEs which means to enable bit32 of physical address. Here is
> > > > > > > the detailed remap relationship in the "4GB mode":
> > > > > > > CPU PA -> HW PA
> > > > > > > 0x4000_0000 0x1_4000_0000 (Add bit32)
> > > > > > > 0x8000_0000 0x1_8000_0000 ...
> > > > > > > 0xc000_0000 0x1_c000_0000 ...
> > > > > > > 0x1_0000_0000 0x1_0000_0000 (No change)
> >
> > [...]
> >
> > > > > > The way I would like this quirk to work is that the io-pgtable code
> > > > > > basically sets bit 9 in the pte when bit 32 is set in the physical address,
> > > > > > and sets bit 4 in the pte when bit 33 is set in the physical address. It
> > > > > > would then do the opposite when converting a pte to a physical address.
> > > > > >
> > > > > > That way, your driver can call the page table code directly with the high
> > > > > > addresses and we don't have to do any manual offsetting or range checking
> > > > > > in the page table code.
> > > > >
> > > > > In this case, the mt8183 can work successfully while the "4gb
> > > > > mode"(mt8173/mt2712) can not.
> > > > >
> > > > > In the "4gb mode", As the remap relationship above, we should always add
> > > > > bit32 in pte as we did in [2]. and need add bit32 in the
> > > > > "iova_to_phys"(Not always add.). That means the "4gb mode" has a special
> > > > > flow:
> > > > > a. Always add bit32 in paddr_to_iopte.
> > > > > b. Add bit32 only when PA < 0x40000000 in iopte_to_paddr.
> > > >
> > > > I think this is probably at the heart of my misunderstanding. What is so
> > > > special about PAs (is this HW PA or CPU PA?) below 0x40000000? Is this RAM
> > > > or something else?
> > >
> > > SRAM and HW register that IOMMU can not access.
> >
> > Ok, so redrawing your table from above, I think we can say something like:
> >
> >
> > CPU Physical address
> > ====================
> >
> > 0G 1G 2G 3G 4G 5G
> > |---A---|---B---|---C---|---D---|---E---|
> > +--I/O--+------------Memory-------------+
> >
> >
> > IOMMU output physical address
> > =============================
> >
> > 4G 5G 6G 7G 8G
> > |---E---|---B---|---C---|---D---|
> > +------------Memory-------------+
> >
> >
> > Do you agree?
>
> Quite right.
Woohoo! So I finally got something right about this :) I'd be up for
including the diagrams above either in the commit message or in the IOMMU
driver code, along with a comment saying that region 'A' cannot be mapped
by the IOMMU and that the page-table walker uses CPU physical addresses.
> > If so, what happens to region 'A' (the I/O region) in the
> > IOMMU output physical address space. Is it accessible?
>
> No. IOMMU can not access region 'A' above.
Got it. Thanks.
> > Anyway, I think it's the job of the driver to convert between the two
> > address spaces, so that:
> >
> > - On ->map(), bit 32 of the CPU physical address is set before calling
> > into the iopgtable code
> >
> > - The result from ->iova_to_phys() should be the result from the
> > iopgtable code, but with the top bit cleared for addresses over
> > 5G.
> >
> > This assumes that:
> >
> > 1. We're ok setting bit 9 in the ptes mapping region 'E'.
> > 2. The IOMMU page-table walker uses CPU physical addresses
> >
> > Are those true?
>
> Yes. Then this patch would be close to the one[1] I sent in v8.
>
> Do I need to split this patch into 2 ones?:
Up to you. If you want to fix the current mainline behaviour of always
setting bit 4, then that should be a separate patch at the start of the
series which can be backported to stable. Is there a reason this doesn't go
wrong in practice?
> a).the pagetable code that support 34bit PA when MTK quirk is enabled.
> It only has the symmetric code handle BIT32/BIT33. Besides, I will add
> CONFIG_PHYS_ADDR_T_64BIT in the iopte_to_addr as commented before.
Hmm. I would prefer that the iopgtable code:
* Range checks the paddr against the oas in ->map()
* Refuses to accept an oas > 32 in ->alloc()
Then it's up to you whether you just want to pass an oas of 34 from the
IOMMU driver.
Will
_______________________________________________
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 0/9] Exynos Adaptive Supply Voltage support
From: Viresh Kumar @ 2019-08-19 11:25 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, linux-samsung-soc, linux-pm, vireshk, b.zolnierkie,
linux-kernel, krzk, robh+dt, kgene, pankaj.dubey,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <b831d7c5-c830-fd65-20cf-02e209889c28@samsung.com>
On 19-08-19, 13:16, Sylwester Nawrocki wrote:
> On 8/19/19 11:09, Viresh Kumar wrote:
> > Will something like this help ?
> >
> > https://lore.kernel.org/lkml/1442623929-4507-3-git-send-email-sboyd@codeaurora.org/
> >
> > This never got merged but the idea was AVS only.
>
> It's quite interesting work, it seems to be for a more advanced use case
> where OPP voltage is being adjusted at runtime.
>
> We could use it instead of removing an OPP and then adding with updated
> voltage. On Exynos there is there is just a need to update OPPs once at boot
> time, so it is more "static". However the requirements could presumably
> change in future.
The API is about changing the values after they are parsed once from DT. You can
change it once or multiple times depending on the use case.
> If that's your preference I could switch to that notifier approach.
You shouldn't be required to use the notifier. Just add the OPP table and update
the values right after that. So no one would be using the values at that time.
> AFAICS the API would still need to be extended to support multiple voltages,
> when in future we add support for the Body Bias regulator.
Right.
Will this patchset solve the problems for you and make your DT light weight ?
--
viresh
_______________________________________________
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 10/21] ARM: dts: imx6qdl-colibri: Add missing pin declaration in iomuxc
From: Shawn Guo @ 2019-08-19 11:25 UTC (permalink / raw)
To: Philippe Schenker
Cc: Mark Rutland, devicetree@vger.kernel.org, Michal Vokáč,
Pengutronix Kernel Team, Marcel Ziswiler, Sascha Hauer,
linux-kernel@vger.kernel.org, stefan@agner.ch, Rob Herring,
NXP Linux Team, Max Krummenacher, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190812142105.1995-11-philippe.schenker@toradex.com>
On Mon, Aug 12, 2019 at 02:21:29PM +0000, Philippe Schenker wrote:
> This adds the muxing for the optional pins usb-oc (overcurrent) and
> usb-id.
>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> ---
>
> Changes in v4:
> - Add Marcel Ziswiler's Ack
>
> Changes in v3: None
> Changes in v2: None
>
> arch/arm/boot/dts/imx6qdl-colibri.dtsi | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-colibri.dtsi b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> index 019dda6b88ad..9a63debab0b5 100644
> --- a/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> @@ -615,6 +615,13 @@
> >;
> };
>
> + pinctrl_usbh_oc_1: usbh_oc-1 {
Please name it consistently in the way like:
pinctrl_xxx: xxxgrp {
...
};
Also, it doesn't need to be separate patch but can just be added
together with the device referring to it.
Shawn
> + fsl,pins = <
> + /* USBH_OC */
> + MX6QDL_PAD_EIM_D30__GPIO3_IO30 0x1b0b0
> + >;
> + };
> +
> pinctrl_spdif: spdifgrp {
> fsl,pins = <
> MX6QDL_PAD_GPIO_17__SPDIF_OUT 0x1b0b0
> @@ -681,6 +688,13 @@
> >;
> };
>
> + pinctrl_usbc_id_1: usbc_id-1 {
> + fsl,pins = <
> + /* USBC_ID */
> + MX6QDL_PAD_NANDF_D2__GPIO2_IO02 0x1b0b0
> + >;
> + };
> +
> pinctrl_usdhc1: usdhc1grp {
> fsl,pins = <
> MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17071
> --
> 2.22.0
>
_______________________________________________
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