* 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
* [PATCH 0/3] arm64: ftrace with regs
From: Jisheng Zhang @ 2019-08-19 11:26 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Steven Rostedt, Mark Rutland
Cc: Torsten Duwe, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Try to make the arm64 ftrace with regs merged.
The later two patches are from Torsten.
The whole series applies cleanly on v5.3-rc5
Jisheng Zhang (1):
ftrace: introdue ftrace_call_init
Torsten Duwe (2):
arm64: implement ftrace with regs
arm64: use -fpatchable-function-entry if available
arch/arm64/Kconfig | 2 +
arch/arm64/Makefile | 5 ++
arch/arm64/include/asm/ftrace.h | 12 ++-
arch/arm64/include/asm/module.h | 3 +-
arch/arm64/kernel/entry-ftrace.S | 125 ++++++++++++++++++++++++++--
arch/arm64/kernel/ftrace.c | 138 +++++++++++++++++++++++--------
arch/arm64/kernel/module-plts.c | 3 +-
arch/arm64/kernel/module.c | 2 +-
include/linux/ftrace.h | 1 +
kernel/module.c | 7 +-
kernel/trace/ftrace.c | 4 +
11 files changed, 257 insertions(+), 45 deletions(-)
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] ftrace: introdue ftrace_call_init
From: Jisheng Zhang @ 2019-08-19 11:27 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Steven Rostedt, Mark Rutland
Cc: Torsten Duwe, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819191530.0f47b9b1@xhacker.debian>
On some arch, the FTRACE_WITH_REGS is implemented with gcc's
-fpatchable-function-entry (=2), gcc adds 2 NOPs at the beginning
of each function, so this makes the MCOUNT_ADDR useless. In ftrace
common framework, MCOUNT_ADDR is mostly used to "init" the nop, so
let's introcude ftrace_call_init().
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
include/linux/ftrace.h | 1 +
kernel/trace/ftrace.c | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 8a8cb3c401b2..8175ffb671f0 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -458,6 +458,7 @@ extern void ftrace_regs_caller(void);
extern void ftrace_call(void);
extern void ftrace_regs_call(void);
extern void mcount_call(void);
+extern int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec);
void ftrace_modify_all_code(int command);
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index eca34503f178..9df5a66a6811 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2500,7 +2500,11 @@ ftrace_code_disable(struct module *mod, struct dyn_ftrace *rec)
if (unlikely(ftrace_disabled))
return 0;
+#ifdef MCOUNT_ADDR
ret = ftrace_make_nop(mod, rec, MCOUNT_ADDR);
+#else
+ ret = ftrace_call_init(mod, rec);
+#endif
if (ret) {
ftrace_bug_type = FTRACE_BUG_INIT;
ftrace_bug(ret, rec);
--
2.23.0.rc1
_______________________________________________
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 v4 11/21] ARM: dts: imx6qdl-apalis: Add sleep state to can interfaces
From: Shawn Guo @ 2019-08-19 11:27 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-12-philippe.schenker@toradex.com>
On Mon, Aug 12, 2019 at 02:21:31PM +0000, Philippe Schenker wrote:
> This patch prepares the devicetree for the new Ixora V1.2 where we are
> able to turn off the supply of the can transceiver. This implies to use
> a sleep state on transmission pins in order to prevent backfeeding.
>
> 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:
> - Changed commit title to '...imx6qdl-apalis:...'
>
> arch/arm/boot/dts/imx6qdl-apalis.dtsi | 27 +++++++++++++++++++++------
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> index 7c4ad541c3f5..59ed2e4a1fd1 100644
> --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> @@ -148,14 +148,16 @@
> };
>
> &can1 {
> - pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_flexcan1>;
This line doesn't need to be changed.
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&pinctrl_flexcan1_default>;
> + pinctrl-1 = <&pinctrl_flexcan1_sleep>;
> status = "disabled";
> };
>
> &can2 {
> - pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_flexcan2>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&pinctrl_flexcan2_default>;
> + pinctrl-1 = <&pinctrl_flexcan2_sleep>;
> status = "disabled";
> };
>
> @@ -599,19 +601,32 @@
> >;
> };
>
> - pinctrl_flexcan1: flexcan1grp {
Ditto. I take them as unnecessary changes.
Shawn
> + pinctrl_flexcan1_default: flexcan1defgrp {
> fsl,pins = <
> MX6QDL_PAD_GPIO_7__FLEXCAN1_TX 0x1b0b0
> MX6QDL_PAD_GPIO_8__FLEXCAN1_RX 0x1b0b0
> >;
> };
>
> - pinctrl_flexcan2: flexcan2grp {
> + pinctrl_flexcan1_sleep: flexcan1slpgrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x0
> + MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x0
> + >;
> + };
> +
> + pinctrl_flexcan2_default: flexcan2defgrp {
> fsl,pins = <
> MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x1b0b0
> MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x1b0b0
> >;
> };
> + pinctrl_flexcan2_sleep: flexcan2slpgrp {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x0
> + MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x0
> + >;
> + };
>
> pinctrl_gpio_bl_on: gpioblon {
> fsl,pins = <
> --
> 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
* [PATCH 2/3] arm64: implement ftrace with regs
From: Jisheng Zhang @ 2019-08-19 11:28 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Steven Rostedt, Mark Rutland
Cc: Torsten Duwe, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819191530.0f47b9b1@xhacker.debian>
From: Torsten Duwe <duwe@suse.de>
Implement ftrace with regs, based on the new gcc flag
-fpatchable-function-entry (=2)
Now that gcc8 added 2 NOPs at the beginning of each function, replace
the first NOP thus generated with a quick LR saver (move it to scratch
reg x9), so the 2nd replacement insn, the call to ftrace, does not
clobber the value. Ftrace will then generate the standard stack
frames.
Note that patchable-function-entry in GCC disables IPA-RA, which means
ABI register calling conventions are obeyed and scratch registers such
as x9 are available.
Introduce and handle an ftrace_regs_trampoline for module PLTs, right
after ftrace_trampoline in an ftrace_trampolines[2] array, and double
the size of the corresponding special section.
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
arch/arm64/include/asm/ftrace.h | 12 ++-
arch/arm64/include/asm/module.h | 3 +-
arch/arm64/kernel/entry-ftrace.S | 125 ++++++++++++++++++++++++++--
arch/arm64/kernel/ftrace.c | 138 +++++++++++++++++++++++--------
arch/arm64/kernel/module-plts.c | 3 +-
arch/arm64/kernel/module.c | 2 +-
6 files changed, 239 insertions(+), 44 deletions(-)
diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
index 5ab5200b2bdc..fde94a905b25 100644
--- a/arch/arm64/include/asm/ftrace.h
+++ b/arch/arm64/include/asm/ftrace.h
@@ -11,9 +11,12 @@
#include <asm/insn.h>
#define HAVE_FUNCTION_GRAPH_FP_TEST
-#define MCOUNT_ADDR ((unsigned long)_mcount)
#define MCOUNT_INSN_SIZE AARCH64_INSN_SIZE
+#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
+#define ARCH_SUPPORTS_FTRACE_OPS 1
+#endif
+
#ifndef __ASSEMBLY__
#include <linux/compat.h>
@@ -30,6 +33,13 @@ extern void return_to_handler(void);
static inline unsigned long ftrace_call_adjust(unsigned long addr)
{
+ /*
+ * For -fpatchable-function-entry=2, there's first the
+ * LR saver, and only then the actual call insn.
+ * Advance addr accordingly.
+ */
+ if (IS_ENABLED(CONFIG_DYNAMIC_FTRACE_WITH_REGS))
+ return (addr + AARCH64_INSN_SIZE);
/*
* addr is the address of the mcount call instruction.
* recordmcount does the necessary offset calculation.
diff --git a/arch/arm64/include/asm/module.h b/arch/arm64/include/asm/module.h
index f80e13cbf8ec..5463a2cf0165 100644
--- a/arch/arm64/include/asm/module.h
+++ b/arch/arm64/include/asm/module.h
@@ -21,7 +21,8 @@ struct mod_arch_specific {
struct mod_plt_sec init;
/* for CONFIG_DYNAMIC_FTRACE */
- struct plt_entry *ftrace_trampoline;
+ struct plt_entry *ftrace_trampolines;
+#define MOD_ARCH_NR_FTRACE_TRAMPOLINES 2
};
#endif
diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
index 33d003d80121..4cfc0a886e4e 100644
--- a/arch/arm64/kernel/entry-ftrace.S
+++ b/arch/arm64/kernel/entry-ftrace.S
@@ -7,6 +7,7 @@
*/
#include <linux/linkage.h>
+#include <asm/asm-offsets.h>
#include <asm/assembler.h>
#include <asm/ftrace.h>
#include <asm/insn.h>
@@ -121,6 +122,7 @@ EXPORT_SYMBOL(_mcount)
NOKPROBE(_mcount)
#else /* CONFIG_DYNAMIC_FTRACE */
+#ifndef CONFIG_DYNAMIC_FTRACE_WITH_REGS
/*
* _mcount() is used to build the kernel with -pg option, but all the branch
* instructions to _mcount() are replaced to NOP initially at kernel start up,
@@ -160,11 +162,6 @@ GLOBAL(ftrace_graph_call) // ftrace_graph_caller();
mcount_exit
ENDPROC(ftrace_caller)
-#endif /* CONFIG_DYNAMIC_FTRACE */
-
-ENTRY(ftrace_stub)
- ret
-ENDPROC(ftrace_stub)
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
/*
@@ -184,7 +181,125 @@ ENTRY(ftrace_graph_caller)
mcount_exit
ENDPROC(ftrace_graph_caller)
+#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
+
+#else /* CONFIG_DYNAMIC_FTRACE_WITH_REGS */
+
+ .macro ftrace_regs_entry, allregs=0
+ /* make room for pt_regs, plus a callee frame */
+ sub sp, sp, #(S_FRAME_SIZE + 16)
+
+ /* save function arguments */
+ stp x0, x1, [sp, #S_X0]
+ stp x2, x3, [sp, #S_X2]
+ stp x4, x5, [sp, #S_X4]
+ stp x6, x7, [sp, #S_X6]
+ stp x8, x9, [sp, #S_X8]
+
+ .if \allregs == 1
+ stp x10, x11, [sp, #S_X10]
+ stp x12, x13, [sp, #S_X12]
+ stp x14, x15, [sp, #S_X14]
+ stp x16, x17, [sp, #S_X16]
+ stp x18, x19, [sp, #S_X18]
+ stp x20, x21, [sp, #S_X20]
+ stp x22, x23, [sp, #S_X22]
+ stp x24, x25, [sp, #S_X24]
+ stp x26, x27, [sp, #S_X26]
+ .endif
+
+ /* Save fp and x28, which is used in this function. */
+ stp x28, x29, [sp, #S_X28]
+
+ /* The stack pointer as it was on ftrace_caller entry... */
+ add x28, sp, #(S_FRAME_SIZE + 16)
+ /* ...and the link Register at callee entry */
+ stp x9, x28, [sp, #S_LR] /* to pt_regs.r[30] and .sp */
+ /* The program counter just after the ftrace call site */
+ str lr, [sp, #S_PC]
+
+ /* Now fill in callee's preliminary stackframe. */
+ stp x29, x9, [sp, #S_FRAME_SIZE]
+ /* Let FP point to it. */
+ add x29, sp, #S_FRAME_SIZE
+
+ /* Our stackframe, stored inside pt_regs. */
+ stp x29, x30, [sp, #S_STACKFRAME]
+ add x29, sp, #S_STACKFRAME
+ .endm
+
+ENTRY(ftrace_regs_caller)
+ ftrace_regs_entry 1
+ b ftrace_common
+ENDPROC(ftrace_regs_caller)
+
+ENTRY(ftrace_caller)
+ ftrace_regs_entry 0
+ b ftrace_common
+ENDPROC(ftrace_caller)
+
+ENTRY(ftrace_common)
+
+ mov x3, sp /* pt_regs are @sp */
+ ldr_l x2, function_trace_op, x0
+ mov x1, x9 /* parent IP */
+ sub x0, lr, #AARCH64_INSN_SIZE
+
+GLOBAL(ftrace_call)
+ bl ftrace_stub
+
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+GLOBAL(ftrace_graph_call) // ftrace_graph_caller();
+ nop // If enabled, this will be replaced
+ // "b ftrace_graph_caller"
+#endif
+
+/*
+ * GCC's patchable-function-entry implicitly disables IPA-RA,
+ * so all non-argument registers are either scratch / dead
+ * or callee-saved (within the ftrace framework). Function
+ * arguments of the call we are intercepting right now however
+ * need to be preserved in any case.
+ */
+ftrace_common_return:
+ /* restore function args */
+ ldp x0, x1, [sp]
+ ldp x2, x3, [sp, #S_X2]
+ ldp x4, x5, [sp, #S_X4]
+ ldp x6, x7, [sp, #S_X6]
+ ldr x8, [sp, #S_X8]
+
+ /* restore fp and x28 */
+ ldp x28, x29, [sp, #S_X28]
+
+ ldr lr, [sp, #S_LR]
+ ldr x9, [sp, #S_PC]
+ /* clean up both frames, ours and callee preliminary */
+ add sp, sp, #S_FRAME_SIZE + 16
+
+ ret x9
+ENDPROC(ftrace_common)
+
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+ENTRY(ftrace_graph_caller)
+ ldr x0, [sp, #S_PC] /* pc */
+ sub x0, x0, #AARCH64_INSN_SIZE
+ add x1, sp, #S_LR /* &lr */
+ ldr x2, [sp, #S_FRAME_SIZE] /* fp */
+ bl prepare_ftrace_return
+ b ftrace_common_return
+ENDPROC(ftrace_graph_caller)
+#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
+#endif /* CONFIG_DYNAMIC_FTRACE_WITH_REGS */
+#endif /* CONFIG_DYNAMIC_FTRACE */
+
+ENTRY(ftrace_stub)
+ ret
+ENDPROC(ftrace_stub)
+
+
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
/*
* void return_to_handler(void)
*
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index 171773257974..faf339e90319 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -62,6 +62,46 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
return ftrace_modify_code(pc, 0, new, false);
}
+#ifdef CONFIG_ARM64_MODULE_PLTS
+static int install_ftrace_trampoline(struct module *mod, unsigned long *addr)
+{
+ struct plt_entry trampoline, *mod_trampoline;
+
+ /*
+ * Iterate over
+ * mod->arch.ftrace_trampolines[MOD_ARCH_NR_FTRACE_TRAMPOLINES]
+ * The assignment to various ftrace functions happens here.
+ */
+ if (*addr == FTRACE_ADDR)
+ mod_trampoline = &mod->arch.ftrace_trampolines[0];
+ else if (*addr == FTRACE_REGS_ADDR)
+ mod_trampoline = &mod->arch.ftrace_trampolines[1];
+ else
+ return -EINVAL;
+
+ trampoline = get_plt_entry(*addr, mod_trampoline);
+
+ /*
+ * Note that PLTs are place relative, and plt_entries_equal()
+ * checks whether they point to the same target. Here, we need
+ * to check if the actual opcodes are in fact identical,
+ * regardless of the offset in memory so use memcmp() instead.
+ */
+ if (memcmp(mod_trampoline, &trampoline, sizeof(trampoline))) {
+ /* point the trampoline at our ftrace entry point */
+ module_disable_ro(mod);
+ *mod_trampoline = trampoline;
+ module_enable_ro(mod, true);
+
+ /* update trampoline before patching in the branch */
+ smp_wmb();
+ }
+ *addr = (unsigned long)(void *)mod_trampoline;
+
+ return 0;
+}
+#endif
+
/*
* Turn on the call to ftrace_caller() in instrumented function
*/
@@ -73,8 +113,8 @@ int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
if (offset < -SZ_128M || offset >= SZ_128M) {
#ifdef CONFIG_ARM64_MODULE_PLTS
- struct plt_entry trampoline, *dst;
struct module *mod;
+ int ret;
/*
* On kernels that support module PLTs, the offset between the
@@ -93,40 +133,13 @@ int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
if (WARN_ON(!mod))
return -EINVAL;
- /*
- * There is only one ftrace trampoline per module. For now,
- * this is not a problem since on arm64, all dynamic ftrace
- * invocations are routed via ftrace_caller(). This will need
- * to be revisited if support for multiple ftrace entry points
- * is added in the future, but for now, the pr_err() below
- * deals with a theoretical issue only.
- *
- * Note that PLTs are place relative, and plt_entries_equal()
- * checks whether they point to the same target. Here, we need
- * to check if the actual opcodes are in fact identical,
- * regardless of the offset in memory so use memcmp() instead.
- */
- dst = mod->arch.ftrace_trampoline;
- trampoline = get_plt_entry(addr, dst);
- if (memcmp(dst, &trampoline, sizeof(trampoline))) {
- if (plt_entry_is_initialized(dst)) {
- pr_err("ftrace: far branches to multiple entry points unsupported inside a single module\n");
- return -EINVAL;
- }
-
- /* point the trampoline to our ftrace entry point */
- module_disable_ro(mod);
- *dst = trampoline;
- module_enable_ro(mod, true);
-
- /*
- * Ensure updated trampoline is visible to instruction
- * fetch before we patch in the branch.
- */
- __flush_icache_range((unsigned long)&dst[0],
- (unsigned long)&dst[1]);
- }
- addr = (unsigned long)dst;
+ /* Check against our well-known list of ftrace entry points */
+ if (addr == FTRACE_ADDR || addr == FTRACE_REGS_ADDR) {
+ ret = install_ftrace_trampoline(mod, &addr);
+ if (ret < 0)
+ return ret;
+ } else
+ return -EINVAL;
#else /* CONFIG_ARM64_MODULE_PLTS */
return -EINVAL;
#endif /* CONFIG_ARM64_MODULE_PLTS */
@@ -138,6 +151,45 @@ int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
return ftrace_modify_code(pc, old, new, true);
}
+#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
+int ftrace_modify_call(struct dyn_ftrace *rec, unsigned long old_addr,
+ unsigned long addr)
+{
+ unsigned long pc = rec->ip;
+ u32 old, new;
+
+ old = aarch64_insn_gen_branch_imm(pc, old_addr,
+ AARCH64_INSN_BRANCH_LINK);
+ new = aarch64_insn_gen_branch_imm(pc, addr, AARCH64_INSN_BRANCH_LINK);
+
+ return ftrace_modify_code(pc, old, new, true);
+}
+
+/*
+ * Ftrace with regs generates the tracer calls as close as possible to
+ * the function entry; no stack frame has been set up at that point.
+ * In order to make another call e.g to ftrace_caller, the LR must be
+ * saved from being overwritten.
+ * Between two functions, and with IPA-RA turned off, the scratch registers
+ * are available, so move the LR to x9 before calling into ftrace.
+ *
+ * This function is called once during kernel startup for each call site.
+ * The address passed is that of the actual branch, so patch in the LR saver
+ * just before that.
+ */
+static int ftrace_setup_lr_saver(unsigned long addr)
+{
+ u32 old, new;
+
+ old = aarch64_insn_gen_nop();
+ /* "mov x9, lr" is officially aliased from "orr x9, xzr, lr". */
+ new = aarch64_insn_gen_logical_shifted_reg(AARCH64_INSN_REG_9,
+ AARCH64_INSN_REG_ZR, AARCH64_INSN_REG_LR, 0,
+ AARCH64_INSN_VARIANT_64BIT, AARCH64_INSN_LOGIC_ORR);
+ return ftrace_modify_code(addr - AARCH64_INSN_SIZE, old, new, true);
+}
+#endif
+
/*
* Turn off the call to ftrace_caller() in instrumented function
*/
@@ -196,6 +248,22 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
return ftrace_modify_code(pc, old, new, validate);
}
+int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec)
+{
+ unsigned long pc = rec->ip;
+
+ /*
+ * -fpatchable-function-entry= does not generate a profiling call
+ * initially; the NOPs are already there. So instead,
+ * put the LR saver there ahead of time, in order to avoid
+ * any race condition over patching 2 instructions.
+ */
+ if (IS_ENABLED(CONFIG_DYNAMIC_FTRACE_WITH_REGS))
+ return ftrace_setup_lr_saver(pc);
+ else
+ return ftrace_make_nop(mod, rec, (unsigned long)_mcount);
+}
+
void arch_ftrace_update_code(int command)
{
command |= FTRACE_MAY_SLEEP;
diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plts.c
index 044c0ae4d6c8..acafb8a2244d 100644
--- a/arch/arm64/kernel/module-plts.c
+++ b/arch/arm64/kernel/module-plts.c
@@ -330,7 +330,8 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
tramp->sh_type = SHT_NOBITS;
tramp->sh_flags = SHF_EXECINSTR | SHF_ALLOC;
tramp->sh_addralign = __alignof__(struct plt_entry);
- tramp->sh_size = sizeof(struct plt_entry);
+ tramp->sh_size = MOD_ARCH_NR_FTRACE_TRAMPOLINES
+ * sizeof(struct plt_entry);
}
return 0;
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 03ff15bffbb6..4e1d99805c5a 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -483,7 +483,7 @@ int module_finalize(const Elf_Ehdr *hdr,
#ifdef CONFIG_ARM64_MODULE_PLTS
if (IS_ENABLED(CONFIG_DYNAMIC_FTRACE) &&
!strcmp(".text.ftrace_trampoline", secstrs + s->sh_name))
- me->arch.ftrace_trampoline = (void *)s->sh_addr;
+ me->arch.ftrace_trampolines = (void *)s->sh_addr;
#endif
}
--
2.23.0.rc1
_______________________________________________
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 v7 0/9] drm: cec: convert DRM drivers to the new notifier API
From: Dariusz Marcinkiewicz @ 2019-08-19 11:28 UTC (permalink / raw)
To: Hans Verkuil
Cc: Kate Stewart, Neil Armstrong, Daniel Vetter, dri-devel, open list,
Hans Verkuil, Dhinakaran Pandiyan, Sam Ravnborg,
linux-samsung-soc, David Francis, amd-gfx, Leo Li,
Jerry (Fangzhi) Zuo, Allison Randal, nouveau, linux-media,
Jonas Karlman, Jani Nikula, intel-gfx, Russell King, Sean Paul,
Rodrigo Vivi, linux-tegra, Thomas Gleixner, linux-arm-kernel,
Thomas Lim, Jernej Skrabec, Greg Kroah-Hartman, Douglas Anderson,
Manasi Navare, Alex Deucher, Colin Ian King, Enrico Weigelt,
Laurent Pinchart
In-Reply-To: <42c7ef3c-b7e5-8c63-c7c2-bfc6c56100c6@xs4all.nl>
On Mon, Aug 19, 2019 at 11:38 AM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>
> Hi all,
>
Hi Hans.
> The patches in this series can be applied independently from each other.
>
> If you maintain one of these drivers and you want to merge it for v5.4
> yourself, then please do so and let me know. If you prefer I commit it
> to drm-misc, then please review and (hopefully) Ack the patch.
>
> I would really like to get this in for v5.4 so I can get the userspace
> bits in for v5.4 as well through the media subsystem.
>
> Dariusz, can you post a v7.1 for patch 5/9 fixing the typo?
>
Done.
I think it would be good to test v7 changes to dw-hdmi and tda998x on
a real hardware. Hans, do you think you would be able to test those?
Thank you.
_______________________________________________
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