* [PATCH v3 0/2] Xilinx ZynqMP IPI Mailbox Controller Driver
From: Wendy Liang @ 2018-01-04 23:51 UTC (permalink / raw)
To: linux-arm-kernel
Introduce mailbox controller driver for ZynqMP IPI(Inter-processor
interrupt) IP core.
There is previous discussion on the DT bindings:
https://patchwork.kernel.org/patch/10012755/
v3:
- add NULL entry to of_device_id of IPI controller
v2:
- change SPDX-License-Identifier license text style in .c file
- replace xlnx-ipi-ids with xlnx,ipi-ids
Wendy Liang (2):
mailbox: ZynqMP IPI mailbox controller
dt-bindings: mailbox: Add Xilinx IPI Mailbox
.../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt | 104 ++++
drivers/mailbox/Kconfig | 8 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/zynqmp-ipi-mailbox.c | 635 +++++++++++++++++++++
include/linux/mailbox/zynqmp-ipi-message.h | 24 +
5 files changed, 773 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt
create mode 100644 drivers/mailbox/zynqmp-ipi-mailbox.c
create mode 100644 include/linux/mailbox/zynqmp-ipi-message.h
--
2.7.4
^ permalink raw reply
* [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI)
From: Russell King - ARM Linux @ 2018-01-04 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <092a51ec-f856-2b51-5d47-8acbdc671031@gmail.com>
On Thu, Jan 04, 2018 at 10:23:40AM -0800, Florian Fainelli wrote:
> Great, thanks! Bonus question, if someone is using any of the affected
> devices in AArch32, should we be expecting to see ARM/Linux changes as
> well, that is, is there a plan to come up with a kpti implementation for
> ARM?
Given what little information there is, I've been trying today to see
whether I can detect whether a userspace address is cached or uncached
- the results suggest that I have code that works with an error rate of
between 2 and 20 in 10000 in a 32-bit VM on Cortex A72. Whether that
translates to Cortex A15, I don't know yet - I need a working Cortex
A15 platform for that. Unfortunately, my only Cortex A15 platform does
not setup the architected timer, and so the kernel doesn't make it
available to userspace. I will be raising this with those concerned on
Monday, in the hope of getting it resolved.
Based on this and the information on developer.arm.com, my gut feeling
is that 32-bit kernels running on a CPU with an architected timer _or_
with some other high resolution timer available to non-privileged
userspace are likely to be vulnerable in some way, as it seems to be
possible to measure whether a specific load results in data being
sourced from the cache or from memory.
That all said, what I read about Chrome OS is that google believes
that isn't exploitable - which seems to be a contradiction to the
information ARM have published. I'm not sure what the reasoning is
there, maybe there's just no current working exploit yet.
So, the message to take away is that 32-bit kernels are rather behind
on this issue, there are no known patches in development, and it is
not really known whether there is an exploitable problem for 32-bit
kernels or not.
Not really where I'd like 32-bit kernels to be.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3
From: Laura Abbott @ 2018-01-04 23:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-4-git-send-email-will.deacon@arm.com>
On 01/04/2018 07:08 AM, Will Deacon wrote:
> For non-KASLR kernels where the KPTI behaviour has not been overridden
> on the command line we can use ID_AA64PFR0_EL1.CSV3 to determine whether
> or not we should unmap the kernel whilst running at EL0.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/include/asm/sysreg.h | 1 +
> arch/arm64/kernel/cpufeature.c | 7 ++++++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 08cc88574659..ae519bbd3f9e 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -437,6 +437,7 @@
> #define ID_AA64ISAR1_DPB_SHIFT 0
>
> /* id_aa64pfr0 */
> +#define ID_AA64PFR0_CSV3_SHIFT 60
> #define ID_AA64PFR0_SVE_SHIFT 32
> #define ID_AA64PFR0_GIC_SHIFT 24
> #define ID_AA64PFR0_ASIMD_SHIFT 20
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 9f0545dfe497..e11c11bb5b02 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -145,6 +145,7 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
> };
>
> static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV3_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
> @@ -851,6 +852,8 @@ static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */
> static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
> int __unused)
> {
> + u64 pfr0 = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1);
> +
> /* Forced on command line? */
> if (__kpti_forced) {
> pr_info_once("kernel page table isolation forced %s by command line option\n",
> @@ -862,7 +865,9 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> return true;
>
> - return false;
> + /* Defer to CPU feature registers */
> + return !cpuid_feature_extract_unsigned_field(pfr0,
> + ID_AA64PFR0_CSV3_SHIFT);
> }
>
> static int __init parse_kpti(char *str)
>
Nit: we only print a message if it's forced on the command line,
can we get a message similar to x86 regardless of state to
clearly indicate if KPTI is enabled?
Thanks,
Laura
^ permalink raw reply
* [PATCH V7 12/12] arm64: dts: add clocks for SC9860
From: Arnd Bergmann @ 2018-01-04 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a3XA+p__p9+B-jCONUDe1MuOgsee6oD0USmwK06iXqH9g@mail.gmail.com>
On Thu, Jan 4, 2018 at 10:34 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Dec 7, 2017 at 1:57 PM, Chunyan Zhang
> <chunyan.zhang@spreadtrum.com> wrote:
>> Some clocks on SC9860 are in the same address area with syscon devices,
>> those are what have a property of 'sprd,syscon' which would refer to
>> syscon devices, others would have a reg property indicated their address
>> ranges.
>>
>> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
>> ---
>> arch/arm64/boot/dts/sprd/sc9860.dtsi | 115 +++++++++++++++++++++++++++++++++++
>> arch/arm64/boot/dts/sprd/whale2.dtsi | 18 +++++-
>> 2 files changed, 131 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi b/arch/arm64/boot/dts/sprd/sc9860.dtsi
>> index 7b7d8ce..bf03da4 100644
>> --- a/arch/arm64/boot/dts/sprd/sc9860.dtsi
>> +++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
>> @@ -7,6 +7,7 @@
>> */
>>
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/clock/sprd,sc9860-clk.h>
>> #include "whale2.dtsi"
>
> This caused a build error since the sprd,sc9860-clk.h file does not
> exist, I'll revert or undo the patch tomorrow.
I've taken another look, and fixing it by removing the broken #include
was easier than undoing the patches, so I did that now, see
https://patchwork.kernel.org/patch/10145773/
Arnd
^ permalink raw reply
* [PATCH] arm64: dts: sprd: remove broken header inclusion
From: Arnd Bergmann @ 2018-01-04 22:58 UTC (permalink / raw)
To: linux-arm-kernel
The added header inclusion broke the 'allmodconfig' build in
arm-soc, presumably since the file is added in a different tree:
In file included from arch/arm64/boot/dts/sprd/sp9860g-1h10.dts:11:0:
arch/arm64/boot/dts/sprd/sc9860.dtsi:10:10: fatal error: dt-bindings/clock/sprd,sc9860-clk.h: No such file or directory
It turns out we don't actually need to include it at all, so
I'm removing the line again to fix the build.
Fixes: 22f37a242925 ("arm64: dts: add clocks for SC9860")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
I've added this one as a fixup now.
arch/arm64/boot/dts/sprd/sc9860.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi b/arch/arm64/boot/dts/sprd/sc9860.dtsi
index bf03da45336a..5dbfb796d9f9 100644
--- a/arch/arm64/boot/dts/sprd/sc9860.dtsi
+++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
@@ -7,7 +7,6 @@
*/
#include <dt-bindings/interrupt-controller/arm-gic.h>
-#include <dt-bindings/clock/sprd,sc9860-clk.h>
#include "whale2.dtsi"
/ {
--
2.9.0
^ permalink raw reply related
* v4.14.9 on ARMv5: OK with gcc 4.8/5.4, NOK with gcc 7.2
From: Russell King - ARM Linux @ 2018-01-04 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAQYJAuwE9n-M7pcpJL53JLVY0PmO721mHh7aZ5KkCoYTzdRMQ@mail.gmail.com>
On Thu, Jan 04, 2018 at 07:19:45PM +0100, Andrea Adami wrote:
> On Thu, Jan 4, 2018 at 6:16 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Thu, Jan 04, 2018 at 06:02:38PM +0100, Thomas Petazzoni wrote:
> >> Hello,
> >>
> >> I'm pretty sure it has already been reported, but just in case: I'm
> >> testing v4.14.9 on an ARMv5 platform (Kirkwood-based OpenBlocks A7).
> >> mvebu_v5_defconfig boots fine when built with gcc 4.8 (good old
> >> Sourcery toolchain) or gcc 5.4 (some old Linaro toolchain), but doesn't
> >> boot at all when built with gcc 7.2 (Fedora toolchain). Even when
> >> configured and booted with earlyprintk, the kernel doesn't say anything.
> >>
> >> The toolchain being used is the default ARM toolchain provided by
> >> Fedora 27. It says:
> >>
> >> gcc version 7.2.1 20170915 (Red Hat Cross 7.2.1-1) (GCC)
> >> GNU ld version 2.29.1-1.fc27
> >>
> >> So it's quite bleeding edge.
> >>
> >> Let me know if this has already been fixed, or if I should test a
> >> patch. I have not tested 4.15-rc or next at this point, assuming that
> >> if a fix had been made, it would have been backported to 4.14-stable.
> >
> > It's a known issue -
> >
> > http://archive.armlinux.org.uk/lurker/message/20171018.095713.a56a717b.en.html
> >
> > but so far no patches have been forthcoming for the kernel, because
> > (I guess) it's deemed to be a gcc bug.
> >
> > It's one of those discussions that just seemed to die without any
> > real conclusion.
> >
> > --
> > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> > According to speedtest.net: 8.21Mbps down 510kbps up
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
> I am happy to report the gcc bug has been fixed in trunk.
> I am as well dubious where they say this should also fix gcc6 where we
> have no known issues with gcc6.
>
> "
> This should also fix
> incorrect generation of ldrd/strd with unaligned accesses that could
> previously have occurred on ARMv5e where all such operations must be
> 64-bit aligned."
>
> https://github.com/gcc-mirror/gcc/commit/f59996b56aaa1c1d62a16cbb4010775b624cbde0
>
> In OpenEmbedded we backported the patch a while ago, see the
> discussion about qemu booting where real hw doesn't:
> http://lists.openembedded.org/pipermail/openembedded-core/2017-November/144045.html
Thanks for reporting the update Andrea!
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v6 10/10] clocksource: timer-dm: Check prescaler value
From: Ladislav Michl @ 2018-01-04 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514887799-24605-11-git-send-email-j-keerthy@ti.com>
On Tue, Jan 02, 2018 at 03:39:59PM +0530, Keerthy wrote:
> From: Ladislav Michl <ladis@linux-mips.org>
>
> Invalid prescaler value is silently ignored. Fix that
> by returning -EINVAL in such case. As invalid value
> disabled use of the prescaler, use -1 explicitely for
> that purpose.
>
> Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> ---
> drivers/clocksource/timer-dm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
> index 60db173..01a9cb0 100644
> --- a/drivers/clocksource/timer-dm.c
> +++ b/drivers/clocksource/timer-dm.c
> @@ -672,6 +672,9 @@ int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer, int prescaler)
> if (prescaler >= 0x00 && prescaler <= 0x07) {
> l |= OMAP_TIMER_CTRL_PRE;
> l |= prescaler << 2;
> + } else {
> + if (prescaler != -1)
> + return -EINVAL;
Argh... This is actually wrong, as it leaves timer enabled.
I suggest simply dropping this patch and I'll rethink whole
approach a bit later (and better).
> }
> omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
>
Sorry for the noise,
ladis
^ permalink raw reply
* [PATCH v2 1/3] drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate
From: Jonathan Liu @ 2018-01-04 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104195650.vmbooz3pwjy77wt7@flea.lan>
Hi Maxime,
On 5 January 2018 at 06:56, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Tue, Dec 26, 2017 at 10:12:25PM +1100, Jonathan Liu wrote:
>> We should check if the best match has been set before comparing it.
>>
>> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
>> Signed-off-by: Jonathan Liu <net147@gmail.com>
>> ---
>> drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>> index dc332ea56f6c..4d235e5ea31c 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>> @@ -102,7 +102,7 @@ static int sun4i_tmds_determine_rate(struct clk_hw *hw,
>> goto out;
>> }
>>
>> - if (abs(rate - rounded / i) <
>> + if (!best_parent || abs(rate - rounded / i) <
>
> Why is that causing any issue?
>
> If best_parent is set to 0...
>
>> abs(rate - best_parent / best_div)) {
>
> ... the value returned here is going to be rate, which is going to be
> higher than the first part of the comparison meaning ...
>
>> best_parent = rounded;
>
> ... that best_parent is going to be set there.
Consider the following:
rate = 83500000
rounded = ideal * 2
It is possible that if "rounded = clk_hw_round_rate(parent, ideal)"
gives high enough values that the condition "abs(rate - rounded / i) <
abs(rate - best_parent / best_div)" is never met.
Then you can end up with:
req->rate = 0
req->best_parent_rate = 0
req->best_parent_hw = ...
Also, the sun4i_tmds_calc_divider function has a similar check.
Regards,
Jonathan
^ permalink raw reply
* [PATCH v5 20/20] cpufreq: scmi: add support for fast frequency switching
From: Alexey Klimov @ 2018-01-04 22:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514904162-11201-21-git-send-email-sudeep.holla@arm.com>
Hi Sudeep,
On Tue, Jan 2, 2018 at 2:42 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> The cpufreq core provides option for drivers to implement fast_switch
> callback which is invoked for frequency switching from interrupt context.
>
> This patch adds support for fast_switch callback in SCMI cpufreq driver
> by making use of polling based SCMI transfer. It also sets the flag
> fast_switch_possible.
>
> Cc: linux-pm at vger.kernel.org
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/cpufreq/scmi-cpufreq.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> index 0ee9335d0063..d0a82d7c6fd4 100644
> --- a/drivers/cpufreq/scmi-cpufreq.c
> +++ b/drivers/cpufreq/scmi-cpufreq.c
> @@ -64,6 +64,19 @@ scmi_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index)
> return perf_ops->freq_set(handle, priv->domain_id, freq, false);
> }
>
> +static unsigned int scmi_cpufreq_fast_switch(struct cpufreq_policy *policy,
> + unsigned int target_freq)
> +{
> + struct scmi_data *priv = policy->driver_data;
> + struct scmi_perf_ops *perf_ops = handle->perf_ops;
> +
> + if (!perf_ops->freq_set(handle, priv->domain_id,
> + target_freq * 1000, true))
> + return target_freq;
> +
> + return 0;
> +}
Could you please explain how it's supposed to work for purpose of fast
frequency switching?
I am trying to track down ->freq_set.
So it looks like this will fire an scmi perf level set command and
will poll for this command to complete without asking for firmware to
send command completion irq.
scmi_perf_level_set() will call the following functions:
scmi_one_xfer_init();
scmi_do_xfer(handle, t);
scmi_one_xfer_put(handle, t);
The first function in the list calls scmi_one_xfer_get() which has
this in the description (I guess because of down_timeout()):
"This function can sleep depending on pending requests already in the system
for the SCMI entity. Further, this also holds a spinlock to maintain
integrity of internal data structures."
So it can sleep.
As far as I see description of fast frequency switching it's required
for fast_switch to not sleep:
(file Documentation/cpu-freq/cpu-drivers.txt)
"This function is used for frequency switching from scheduler's context.
Not all drivers are expected to implement it, as sleeping from within
this callback isn't allowed. This callback must be highly optimized to
do switching as fast as possible."
The other questions to this implementation of fast switching:
1) Fast switching callback must be highly optimized. Is it now? I see
few spinlocks (in scmi mbox client and in the mailbox framework) there
and polling functionality with udelay(5) inside that will timeout (if
my calculations are correct) after 0.5 ms.
2) Is it highly dependent on transport? If mailbox transport
->send_data() may sleep or hrtimer-based polling in mailbox framework
will be used, then this fast switch won't work, right?
I am still looking into that: I can be wrong and just trying to
understand if it is all okay.
[..]
Thanks,
Alexey
^ permalink raw reply
* [PATCH V3 3/3] arm64: Extend early page table code to allow for larger kernels
From: Jeremy Linton @ 2018-01-04 21:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8tpRhri5CbvhYzE-ZZViqt7EAiDhf=EY_Ft=LoWu5-cQ@mail.gmail.com>
Hi,
On 01/02/2018 04:01 PM, Ard Biesheuvel wrote:
> Hi Steve,
>
> On 2 January 2018 at 15:12, Steve Capper <steve.capper@arm.com> wrote:
>> Currently the early assembler page table code assumes that precisely
>> 1xpgd, 1xpud, 1xpmd are sufficient to represent the early kernel text
>> mappings.
>>
>> Unfortunately this is rarely the case when running with a 16KB granule,
>> and we also run into limits with 4KB granule when building much larger
>> kernels.
>>
>> This patch re-writes the early page table logic to compute indices of
>> mappings for each level of page table, and if multiple indices are
>> required, the next-level page table is scaled up accordingly.
>>
>> Also the required size of the swapper_pg_dir is computed at link time
>> to cover the mapping [KIMAGE_ADDR + VOFFSET, _end]. When KASLR is
>> enabled, an extra page is set aside for each level that may require extra
>> entries at runtime.
>>
>> Signed-off-by: Steve Capper <steve.capper@arm.com>
>>
>> ---
>> Changed in V3:
>> Corrected KASLR computation
>> Rebased against arm64/for-next/core, particularly Kristina's 52-bit
>> PA series.
>> ---
>> arch/arm64/include/asm/kernel-pgtable.h | 47 ++++++++++-
>> arch/arm64/include/asm/pgtable.h | 1 +
>> arch/arm64/kernel/head.S | 145 +++++++++++++++++++++++---------
>> arch/arm64/kernel/vmlinux.lds.S | 1 +
>> arch/arm64/mm/mmu.c | 3 +-
>> 5 files changed, 157 insertions(+), 40 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
>> index 77a27af01371..82386e860dd2 100644
>> --- a/arch/arm64/include/asm/kernel-pgtable.h
>> +++ b/arch/arm64/include/asm/kernel-pgtable.h
>> @@ -52,7 +52,52 @@
>> #define IDMAP_PGTABLE_LEVELS (ARM64_HW_PGTABLE_LEVELS(PHYS_MASK_SHIFT))
>> #endif
>>
>> -#define SWAPPER_DIR_SIZE (SWAPPER_PGTABLE_LEVELS * PAGE_SIZE)
>> +
>> +/*
>> + * If KASLR is enabled, then an offset K is added to the kernel address
>> + * space. The bottom 21 bits of this offset are zero to guarantee 2MB
>> + * alignment for PA and VA.
>> + *
>> + * For each pagetable level of the swapper, we know that the shift will
>> + * be larger than 21 (for the 4KB granule case we use section maps thus
>> + * the smallest shift is actually 30) thus there is the possibility that
>> + * KASLR can increase the number of pagetable entries by 1, so we make
>> + * room for this extra entry.
>> + *
>> + * Note KASLR cannot increase the number of required entries for a level
>> + * by more than one because it increments both the virtual start and end
>> + * addresses equally (the extra entry comes from the case where the end
>> + * address is just pushed over a boundary and the start address isn't).
>> + */
>> +
>> +#ifdef CONFIG_RANDOMIZE_BASE
>> +#define EARLY_KASLR (1)
>> +#else
>> +#define EARLY_KASLR (0)
>> +#endif
>> +
>> +#define EARLY_ENTRIES(vstart, vend, shift) (((vend) >> (shift)) \
>> + - ((vstart) >> (shift)) + 1 + EARLY_KASLR)
>> +
>> +#define EARLY_PGDS(vstart, vend) (EARLY_ENTRIES(vstart, vend, PGDIR_SHIFT))
>> +
>> +#if SWAPPER_PGTABLE_LEVELS > 3
>> +#define EARLY_PUDS(vstart, vend) (EARLY_ENTRIES(vstart, vend, PUD_SHIFT))
>> +#else
>> +#define EARLY_PUDS(vstart, vend) (0)
>> +#endif
>> +
>> +#if SWAPPER_PGTABLE_LEVELS > 2
>> +#define EARLY_PMDS(vstart, vend) (EARLY_ENTRIES(vstart, vend, SWAPPER_TABLE_SHIFT))
>> +#else
>> +#define EARLY_PMDS(vstart, vend) (0)
>> +#endif
>> +
>> +#define EARLY_PAGES(vstart, vend) ( 1 /* PGDIR page */ \
>> + + EARLY_PGDS((vstart), (vend)) /* each PGDIR needs a next level page table */ \
>> + + EARLY_PUDS((vstart), (vend)) /* each PUD needs a next level page table */ \
>> + + EARLY_PMDS((vstart), (vend))) /* each PMD needs a next level page table */
>> +#define SWAPPER_DIR_SIZE (PAGE_SIZE * EARLY_PAGES(KIMAGE_VADDR + TEXT_OFFSET, _end))
>> #define IDMAP_DIR_SIZE (IDMAP_PGTABLE_LEVELS * PAGE_SIZE)
>>
>> #ifdef CONFIG_ARM64_SW_TTBR0_PAN
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index bfa237e892f1..54b0a8398055 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -706,6 +706,7 @@ static inline void pmdp_set_wrprotect(struct mm_struct *mm,
>> #endif
>>
>> extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
>> +extern pgd_t swapper_pg_end[];
>> extern pgd_t idmap_pg_dir[PTRS_PER_PGD];
>> extern pgd_t tramp_pg_dir[PTRS_PER_PGD];
>>
>> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
>> index 66f01869e97c..539e2642ed41 100644
>> --- a/arch/arm64/kernel/head.S
>> +++ b/arch/arm64/kernel/head.S
>> @@ -191,44 +191,110 @@ ENDPROC(preserve_boot_args)
>> .endm
>>
>> /*
>> - * Macro to populate the PGD (and possibily PUD) for the corresponding
>> - * block entry in the next level (tbl) for the given virtual address.
>> + * Macro to populate page table entries, these entries can be pointers to the next level
>> + * or last level entries pointing to physical memory.
>> *
>> - * Preserves: tbl, next, virt
>> - * Corrupts: ptrs_per_pgd, tmp1, tmp2
>> + * tbl: page table address
>> + * rtbl: pointer to page table or physical memory
>> + * index: start index to write
>> + * eindex: end index to write - [index, eindex] written to
>> + * flags: flags for pagetable entry to or in
>> + * inc: increment to rtbl between each entry
>> + * tmp1: temporary variable
>> + *
>> + * Preserves: tbl, eindex, flags, inc
>> + * Corrupts: index, tmp1
>> + * Returns: rtbl
>> */
>> - .macro create_pgd_entry, tbl, virt, ptrs_per_pgd, tmp1, tmp2
>> - create_table_entry \tbl, \virt, PGDIR_SHIFT, \ptrs_per_pgd, \tmp1, \tmp2
>> -#if SWAPPER_PGTABLE_LEVELS > 3
>> - mov \ptrs_per_pgd, PTRS_PER_PUD
>> - create_table_entry \tbl, \virt, PUD_SHIFT, \ptrs_per_pgd, \tmp1, \tmp2
>> -#endif
>> -#if SWAPPER_PGTABLE_LEVELS > 2
>> - mov \ptrs_per_pgd, PTRS_PER_PTE
>> - create_table_entry \tbl, \virt, SWAPPER_TABLE_SHIFT, \ptrs_per_pgd, \tmp1, \tmp2
>> -#endif
>> + .macro populate_entries, tbl, rtbl, index, eindex, flags, inc, tmp1
>> +9999: phys_to_pte \rtbl, \tmp1
>
> I know this is existing code, but you could take the opportunity to
> replace this label with
>
> .L\@ >
> (and update the branch instruction accordingly) so that we don't have
> to rely on the uniqueness of '9999'
As this was pointed out, it seems that the common method do this in the
kernel is actually
.Lsomename\@
which is required if your macro has more than one branch..
Alternatively, it seems some of the more recent code is using the
LOCAL/.altmacro method which avoids hardcoding the local prefix. Either
one fixes the nested macro's and wrong jump target problem.
>
>> + orr \tmp1, \tmp1, \flags // tmp1 = table entry
>> + str \tmp1, [\tbl, \index, lsl #3]
>> + add \rtbl, \rtbl, \inc // rtbl = pa next level
>> + add \index, \index, #1
>> + cmp \index, \eindex
>> + b.ls 9999b
>> .endm
>>
>> /*
>> - * Macro to populate block entries in the page table for the start..end
>> - * virtual range (inclusive).
>> + * Compute indices of table entries from virtual address range. If multiple entries
>> + * were needed in the previous page table level then the next page table level is assumed
>> + * to be composed of multiple pages. (This effectively scales the end index).
>> + *
>> + * vstart: virtual address of start of range
>> + * vend: virtual address of end of range
>> + * shift: shift used to transform virtual address into index
>> + * ptrs: number of entries in page table
>> + * istart: index in table corresponding to vstart
>> + * iend: index in table corresponding to vend
>> + * count: On entry: how many entries required in previous level, scales our end index
>> + * On exit: returns how many entries required for next page table level
>> *
>
> If you make 'count' the number of /additional/ entries, you no longer
> have to add/sub #1 each time.
>
>> - * Preserves: tbl, flags
>> - * Corrupts: phys, start, end, tmp, pstate
>> + * Preserves: vstart, vend, shift, ptrs
>> + * Returns: istart, iend, count
>> */
>> - .macro create_block_map, tbl, flags, phys, start, end, tmp
>> - lsr \start, \start, #SWAPPER_BLOCK_SHIFT
>> - and \start, \start, #PTRS_PER_PTE - 1 // table index
>> - bic \phys, \phys, #SWAPPER_BLOCK_SIZE - 1
>> - lsr \end, \end, #SWAPPER_BLOCK_SHIFT
>> - and \end, \end, #PTRS_PER_PTE - 1 // table end index
>> -9999: phys_to_pte \phys, \tmp
>> - orr \tmp, \tmp, \flags // table entry
>> - str \tmp, [\tbl, \start, lsl #3] // store the entry
>> - add \start, \start, #1 // next entry
>> - add \phys, \phys, #SWAPPER_BLOCK_SIZE // next block
>> - cmp \start, \end
>> - b.ls 9999b
>> + .macro compute_indices, vstart, vend, shift, ptrs, istart, iend, count
>> + lsr \iend, \vend, \shift
>> + mov \istart, \ptrs
>> + sub \istart, \istart, #1
>> + and \iend, \iend, \istart // iend = (vend >> shift) & (ptrs - 1)
>> + mov \istart, \ptrs
>> + sub \count, \count, #1
>> + mul \istart, \istart, \count
>> + add \iend, \iend, \istart // iend += (count - 1) * ptrs
>> + // our entries span multiple tables
>> +
>> + lsr \istart, \vstart, \shift
>> + mov \count, \ptrs
>> + sub \count, \count, #1
>> + and \istart, \istart, \count
>> +
>> + sub \count, \iend, \istart
>> + add \count, \count, #1
>> + .endm
>> +
>
> You can simplify this macro by using an immediate for \ptrs. Please
> see the diff below [whitespace mangling courtesy of Gmail]
>
>> +/*
>> + * Map memory for specified virtual address range. Each level of page table needed supports
>> + * multiple entries. If a level requires n entries the next page table level is assumed to be
>> + * formed from n pages.
>> + *
>> + * tbl: location of page table
>> + * rtbl: address to be used for first level page table entry (typically tbl + PAGE_SIZE)
>> + * vstart: start address to map
>> + * vend: end address to map - we map [vstart, vend]
>> + * flags: flags to use to map last level entries
>> + * phys: physical address corresponding to vstart - physical memory is contiguous
>> + * pgds: the number of pgd entries
>> + *
>> + * Temporaries: istart, iend, tmp, count, sv - these need to be different registers
>> + * Preserves: vstart, vend, flags
>> + * Corrupts: tbl, rtbl, istart, iend, tmp, count, sv
>> + */
>> + .macro map_memory, tbl, rtbl, vstart, vend, flags, phys, pgds, istart, iend, tmp, count, sv
>> + add \rtbl, \tbl, #PAGE_SIZE
>> + mov \sv, \rtbl
>> + mov \count, #1
>
> #0 if you make \count the number of additional entries.
>
> In any case, for the series:
>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
>> + compute_indices \vstart, \vend, #PGDIR_SHIFT, \pgds, \istart, \iend, \count
>> + populate_entries \tbl, \rtbl, \istart, \iend, #PMD_TYPE_TABLE, #PAGE_SIZE, \tmp
>> + mov \tbl, \sv
>> + mov \sv, \rtbl
>> +
>> +#if SWAPPER_PGTABLE_LEVELS > 3
>> + compute_indices \vstart, \vend, #PUD_SHIFT, #PTRS_PER_PUD, \istart, \iend, \count
>> + populate_entries \tbl, \rtbl, \istart, \iend, #PMD_TYPE_TABLE, #PAGE_SIZE, \tmp
>> + mov \tbl, \sv
>> + mov \sv, \rtbl
>> +#endif
>> +
>> +#if SWAPPER_PGTABLE_LEVELS > 2
>> + compute_indices \vstart, \vend, #SWAPPER_TABLE_SHIFT, #PTRS_PER_PMD, \istart, \iend, \count
>> + populate_entries \tbl, \rtbl, \istart, \iend, #PMD_TYPE_TABLE, #PAGE_SIZE, \tmp
>> + mov \tbl, \sv
>> +#endif
>> +
>> + compute_indices \vstart, \vend, #SWAPPER_BLOCK_SHIFT, #PTRS_PER_PTE, \istart, \iend, \count
>> + bic \count, \phys, #SWAPPER_BLOCK_SIZE - 1
>> + populate_entries \tbl, \count, \istart, \iend, \flags, #SWAPPER_BLOCK_SIZE, \tmp
>> .endm
>>
>> /*
>> @@ -246,14 +312,16 @@ __create_page_tables:
>> * dirty cache lines being evicted.
>> */
>> adrp x0, idmap_pg_dir
>> - ldr x1, =(IDMAP_DIR_SIZE + SWAPPER_DIR_SIZE + RESERVED_TTBR0_SIZE)
>> + adrp x1, swapper_pg_end
>> + sub x1, x1, x0
>> bl __inval_dcache_area
>>
>> /*
>> * Clear the idmap and swapper page tables.
>> */
>> adrp x0, idmap_pg_dir
>> - ldr x1, =(IDMAP_DIR_SIZE + SWAPPER_DIR_SIZE + RESERVED_TTBR0_SIZE)
>> + adrp x1, swapper_pg_end
>> + sub x1, x1, x0
>> 1: stp xzr, xzr, [x0], #16
>> stp xzr, xzr, [x0], #16
>> stp xzr, xzr, [x0], #16
>> @@ -318,10 +386,10 @@ __create_page_tables:
>> #endif
>> 1:
>> ldr_l x4, idmap_ptrs_per_pgd
>> - create_pgd_entry x0, x3, x4, x5, x6
>> mov x5, x3 // __pa(__idmap_text_start)
>> adr_l x6, __idmap_text_end // __pa(__idmap_text_end)
>> - create_block_map x0, x7, x3, x5, x6, x4
>> +
>> + map_memory x0, x1, x3, x6, x7, x3, x4, x10, x11, x12, x13, x14
>>
>> /*
>> * Map the kernel image (starting with PHYS_OFFSET).
>> @@ -330,12 +398,12 @@ __create_page_tables:
>> mov_q x5, KIMAGE_VADDR + TEXT_OFFSET // compile time __va(_text)
>> add x5, x5, x23 // add KASLR displacement
>> mov x4, PTRS_PER_PGD
>> - create_pgd_entry x0, x5, x4, x3, x6
>> adrp x6, _end // runtime __pa(_end)
>> adrp x3, _text // runtime __pa(_text)
>> sub x6, x6, x3 // _end - _text
>> add x6, x6, x5 // runtime __va(_end)
>> - create_block_map x0, x7, x3, x5, x6, x4
>> +
>> + map_memory x0, x1, x5, x6, x7, x3, x4, x10, x11, x12, x13, x14
>>
>> /*
>> * Since the page tables have been populated with non-cacheable
>> @@ -343,7 +411,8 @@ __create_page_tables:
>> * tables again to remove any speculatively loaded cache lines.
>> */
>> adrp x0, idmap_pg_dir
>> - ldr x1, =(IDMAP_DIR_SIZE + SWAPPER_DIR_SIZE + RESERVED_TTBR0_SIZE)
>> + adrp x1, swapper_pg_end
>> + sub x1, x1, x0
>> dmb sy
>> bl __inval_dcache_area
>>
>> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
>> index 4c7112a47469..0221aca6493d 100644
>> --- a/arch/arm64/kernel/vmlinux.lds.S
>> +++ b/arch/arm64/kernel/vmlinux.lds.S
>> @@ -230,6 +230,7 @@ SECTIONS
>> #endif
>> swapper_pg_dir = .;
>> . += SWAPPER_DIR_SIZE;
>> + swapper_pg_end = .;
>>
>> __pecoff_data_size = ABSOLUTE(. - __initdata_begin);
>> _end = .;
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index 4071602031ed..fdac11979bae 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -644,7 +644,8 @@ void __init paging_init(void)
>> * allocated with it.
>> */
>> memblock_free(__pa_symbol(swapper_pg_dir) + PAGE_SIZE,
>> - SWAPPER_DIR_SIZE - PAGE_SIZE);
>> + __pa_symbol(swapper_pg_end) - __pa_symbol(swapper_pg_dir)
>> + - PAGE_SIZE);
>> }
>>
>> /*
>> --
>> 2.11.0
>>
>
>
> ------8<---------
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 539e2642ed41..0432dd8d083c 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -235,9 +235,7 @@ ENDPROC(preserve_boot_args)
> */
> .macro compute_indices, vstart, vend, shift, ptrs, istart, iend, count
> lsr \iend, \vend, \shift
> - mov \istart, \ptrs
> - sub \istart, \istart, #1
> - and \iend, \iend, \istart // iend = (vend >> shift) & (ptrs - 1)
> + and \iend, \iend, \ptrs - 1 // iend = (vend >> shift) & (ptrs - 1)
> mov \istart, \ptrs
> sub \count, \count, #1
> mul \istart, \istart, \count
> @@ -245,9 +243,7 @@ ENDPROC(preserve_boot_args)
> // our entries span multiple tables
>
> lsr \istart, \vstart, \shift
> - mov \count, \ptrs
> - sub \count, \count, #1
> - and \istart, \istart, \count
> + and \istart, \istart, \ptrs - 1
>
> sub \count, \iend, \istart
> add \count, \count, #1
> @@ -376,6 +372,7 @@ __create_page_tables:
>
> mov x4, EXTRA_PTRS
> create_table_entry x0, x3, EXTRA_SHIFT, x4, x5, x6
> + .set .Lidmap_ptrs_per_pgd, PTRS_PER_PGD
> #else
> /*
> * If VA_BITS == 48, we don't have to configure an additional
> @@ -383,13 +380,13 @@ __create_page_tables:
> */
> mov x4, #1 << (PHYS_MASK_SHIFT - PGDIR_SHIFT)
> str_l x4, idmap_ptrs_per_pgd, x5
> + .set .Lidmap_ptrs_per_pgd, 1 << (PHYS_MASK_SHIFT - PGDIR_SHIFT)
> #endif
> 1:
> - ldr_l x4, idmap_ptrs_per_pgd
> mov x5, x3 // __pa(__idmap_text_start)
> adr_l x6, __idmap_text_end // __pa(__idmap_text_end)
>
> - map_memory x0, x1, x3, x6, x7, x3, x4, x10, x11, x12, x13, x14
> + map_memory x0, x1, x3, x6, x7, x3, .Lidmap_ptrs_per_pgd, x10,
> x11, x12, x13, x14
>
> /*
> * Map the kernel image (starting with PHYS_OFFSET).
> @@ -397,13 +394,12 @@ __create_page_tables:
> adrp x0, swapper_pg_dir
> mov_q x5, KIMAGE_VADDR + TEXT_OFFSET // compile time __va(_text)
> add x5, x5, x23 // add KASLR displacement
> - mov x4, PTRS_PER_PGD
> adrp x6, _end // runtime __pa(_end)
> adrp x3, _text // runtime __pa(_text)
> sub x6, x6, x3 // _end - _text
> add x6, x6, x5 // runtime __va(_end)
>
> - map_memory x0, x1, x5, x6, x7, x3, x4, x10, x11, x12, x13, x14
> + map_memory x0, x1, x5, x6, x7, x3, PTRS_PER_PGD, x10, x11, x12, x13, x14
>
> /*
> * Since the page tables have been populated with non-cacheable
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH V7 12/12] arm64: dts: add clocks for SC9860
From: Arnd Bergmann @ 2018-01-04 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-13-chunyan.zhang@spreadtrum.com>
On Thu, Dec 7, 2017 at 1:57 PM, Chunyan Zhang
<chunyan.zhang@spreadtrum.com> wrote:
> Some clocks on SC9860 are in the same address area with syscon devices,
> those are what have a property of 'sprd,syscon' which would refer to
> syscon devices, others would have a reg property indicated their address
> ranges.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
> arch/arm64/boot/dts/sprd/sc9860.dtsi | 115 +++++++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/sprd/whale2.dtsi | 18 +++++-
> 2 files changed, 131 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> index 7b7d8ce..bf03da4 100644
> --- a/arch/arm64/boot/dts/sprd/sc9860.dtsi
> +++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> @@ -7,6 +7,7 @@
> */
>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/sprd,sc9860-clk.h>
> #include "whale2.dtsi"
This caused a build error since the sprd,sc9860-clk.h file does not
exist, I'll revert or
undo the patch tomorrow.
Arnd
^ permalink raw reply
* [PATCH v4 6/7] ARM: davinci: convert to common clock framework
From: David Lechner @ 2018-01-04 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7x+N7KThCXsqrKiSetNeyaEW3BzwVBH_8KSqJVtb8hXFNg@mail.gmail.com>
On 01/04/2018 01:26 PM, Adam Ford wrote:
> On Thu, Jan 4, 2018 at 11:50 AM, David Lechner <david@lechnology.com> wrote:
>>
>>
>> On 1/4/18 6:39 AM, Sekhar Nori wrote:
>>>
>>> On Monday 01 January 2018 05:09 AM, David Lechner wrote:
>>>>
>>>> This converts all of arch/arm/mach-davinci to the common clock framework.
>>>> The clock drivers from clock.c and psc.c have been moved to drivers/clk,
>>>> so these files are removed.
>>>>
>>>> There is one subtle change in the clock trees. AUX, BPDIV and OSCDIV
>>>> clocks now have "ref_clk" as a parent instead of the PLL clock. These
>>>> clocks are part of the PLL's MMIO block, but they bypass the PLL and
>>>> therefore it makes more sense to have "ref_clk" as their parent since
>>>> "ref_clk" is the input clock of the PLL.
>>>>
>>>> CONFIG_DAVINCI_RESET_CLOCKS is removed since the common clock frameworks
>>>> takes care of disabling unused clocks.
>>>>
>>>> Known issue: This breaks CPU frequency scaling on da850.
>>>
>>>
>>> This functionality needs to be restored as part of this series since we
>>> cannot commit anything with regressions.
>>>
>>
>> Do you have a suggestion on how to accomplish this? I don't have a board for
>> testing, so I don't have a way of knowing if my changes will work or not.
>
> I work for Logic PD who makes the original da850-evm. I can help if
> you want to send me patches. It would be better if you had a git repo
> setup where I could just clone the repo and tests.
>
> Having a larger collection of smaller the patches would also give me
> the ability to bisect down to help determine what actually breaks the
> da850-evm vs a few large patches.
>
> Do you still need me to run the board with some of the extra debugging
> enabled, or should I wait for the next round of patches?
>
You might as well wait until I resubmit. There are going to be some significant
changes.
^ permalink raw reply
* [PATCH v2 0/8] ARM: sun9i: SMP support with Multi-Cluster Power Management
From: Nicolas Pitre @ 2018-01-04 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104143754.2425-1-wens@csie.org>
On Thu, 4 Jan 2018, Chen-Yu Tsai wrote:
> Nicolas mentioned that the MCPM framework is likely overkill in our
> case [4]. However the framework does provide cluster/core state tracking
> and proper sequencing of cache related operations. We could rework
> the code to use standard smp_ops, but I would like to actually get
> a working version in first.
>
> [...] For now however I'm using a
> dedicated single thread workqueue. CPU and cluster power off work is
> queued from the .{cpu,cluster}_powerdown_prepare callbacks. This solution
> is somewhat heavy, as I have a total of 10 static work structs. It might
> also be a bit racy, as nothing prevents the system from bringing a core
> back before the asynchronous work shuts it down. This would likely
> happen under a heavily loaded system with a scheduler that brings cores
> in and out of the system frequently. In simple use-cases it performs OK.
If you know up front your code is racy then this doesn't fully qualify
as a "working version". Furthermore you're trading custom cluster/core
state tracking for workqueue handling which doesn't look like a winning
tradeoff to me. Especially given you can't have asynchronous CPU wakeups
in hardware from an IRQ to deal with then the state tracking becomes
very simple.
If you hook into struct smp_operations directly, you'll have direct
access to both .cpu_die and .cpu_kill methods which are executed on the
target CPU and on a different CPU respectively, which is exactly what
you need. Those calls are already serialized with .smp_boot_secondary so
you don't have to worry about races. The only thing you need to protect
against races is your cluster usage count. Your code will end up being
simpler than what you have now. See arch/arm/mach-hisi/platmcpm.c for
example.
Nicolas
^ permalink raw reply
* [PATCH] ARM: dts: kirkwood: fix pin-muxing of MPP7
From: Andrew Lunn @ 2018-01-04 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104165312.14052-1-thomas.petazzoni@free-electrons.com>
On Thu, Jan 04, 2018 at 05:53:12PM +0100, Thomas Petazzoni wrote:
> MPP7 is currently muxed as "gpio", but this function doesn't exist for
> MPP7, only "gpo" is available. This causes the following error:
>
> kirkwood-pinctrl f1010000.pin-controller: unsupported function gpio on pin mpp7
> pinctrl core: failed to register map default (6): invalid type given
> kirkwood-pinctrl f1010000.pin-controller: error claiming hogs: -22
> kirkwood-pinctrl f1010000.pin-controller: could not claim hogs: -22
> kirkwood-pinctrl f1010000.pin-controller: unable to register pinctrl driver
> kirkwood-pinctrl: probe of f1010000.pin-controller failed with error -22
>
> So the pinctrl driver is not probed, all device drivers (including the
> UART driver) do a -EPROBE_DEFER, and therefore the system doesn't
> really boot (well, it boots, but with no UART, and no devices that
> require pin-muxing).
>
> Back when the Device Tree file for this board was introduced, the
> definition was already wrong. The pinctrl driver also always described
> as "gpo" this function for MPP7. However, between Linux 4.10 and 4.11,
> a hog pin failing to be muxed was turned from a simple warning to a
> hard error that caused the entire pinctrl driver probe to bail
> out. This is probably the result of commit 6118714275f0a ("pinctrl:
> core: Fix pinctrl_register_and_init() with pinctrl_enable()").
>
> This commit fixes the Device Tree to use the proper "gpo" function for
> MPP7, which fixes the boot of OpenBlocks A7, which was broken since
> Linux 4.11.
>
> Fixes: f24b56cbcd9d ("ARM: kirkwood: add support for OpenBlocks A7 platform")
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Hi Thomas
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
I just checked the other Kirkwood boards. This is the only one that
got MPP7 wrong.
Andrew
^ permalink raw reply
* [GIT PULL] Qualcomm Driver updates for 4.16 - Redo
From: Andy Gross @ 2018-01-04 20:32 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-drivers-for-4.16
for you to fetch changes up to 3aa0582fdb824139630298880fbf78d4ac774d3c:
of: platform: populate /firmware/ node from of_platform_default_populate_init() (2018-01-04 14:00:20 -0600)
----------------------------------------------------------------
Qualcomm ARM Based Driver Updates for v4.16 - Redo
* Fix error handling code in SMP2P probe
* Update SMP2P to use ACPS as mailbox client
* Add QMI support
* Fixups for Qualcomm SCM
* Fix licensing on rmtfs_mem
* Correct SMSM child node lookup
* Populate firmware nodes during platform init
----------------------------------------------------------------
Bjorn Andersson (3):
soc: qcom: smp2p: Access APCS as mailbox client
soc: qcom: Introduce QMI encoder/decoder
soc: qcom: Introduce QMI helpers
Jesse Chan (1):
soc: qcom: rmtfs_mem: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
Johan Hovold (1):
soc: qcom: smsm: fix child-node lookup
Jordan Crouse (1):
firmware: qcom_scm: Add dependent headers to qcom_scm.h
Markus Elfring (1):
soc: qcom: smp2p: Use common error handling code in qcom_smp2p_probe()
Sudeep Holla (2):
firmware: qcom_scm: drop redandant of_platform_populate
of: platform: populate /firmware/ node from of_platform_default_populate_init()
.../devicetree/bindings/soc/qcom/qcom,smp2p.txt | 8 +-
drivers/firmware/qcom_scm.c | 24 -
drivers/of/platform.c | 4 +
drivers/soc/qcom/Kconfig | 10 +
drivers/soc/qcom/Makefile | 2 +
drivers/soc/qcom/qmi_encdec.c | 816 ++++++++++++++++++++
drivers/soc/qcom/qmi_interface.c | 848 +++++++++++++++++++++
drivers/soc/qcom/rmtfs_mem.c | 4 +
drivers/soc/qcom/smp2p.c | 55 +-
drivers/soc/qcom/smsm.c | 6 +-
include/linux/qcom_scm.h | 3 +
include/linux/soc/qcom/qmi.h | 271 +++++++
12 files changed, 2010 insertions(+), 41 deletions(-)
create mode 100644 drivers/soc/qcom/qmi_encdec.c
create mode 100644 drivers/soc/qcom/qmi_interface.c
create mode 100644 include/linux/soc/qcom/qmi.h
^ permalink raw reply
* [PATCH] imx6: fix pcie enumeration
From: Bjorn Helgaas @ 2018-01-04 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515080883-30066-1-git-send-email-koen.vandeputte@ncentric.com>
[+cc Richard, Lucas, Lorenzo, linux-arm-kernel]
Hi Koen,
Thanks a lot for the fix!
Please run "git log --oneline drivers/pci/dwc/pci-imx6.c" and follow
the style convention, including "PCIe" capitalization.
"fix pcie enumeration" is not very descriptive. It should say something
about the specific problem, e.g., setting the root port's subordinate
bus number.
On Thu, Jan 04, 2018 at 04:48:03PM +0100, Koen Vandeputte wrote:
> By default, when the imx6 PCIe RC boots up, the subordinate is set
Not sure what "RC boots up" means. Maybe you're talking about a
hardware-defined default value at power-up, or maybe a value
programmed by a boot-loader? Please clarify and update the similar
comment in the code.
> equally to the secondary bus (1), and does not alter afterwards.
>
> This means that theoretically, the highest bus reachable downstream is
> bus 1.
Not just theoretically. If the bridge is operating correctly, it
should not forward any config transaction for a bus number greater
than the subordinate bus number.
> Before commit a20c7f36bd3d ("PCI: Do not allocate more buses than
> available in parent"), the driver ignored the subord value and just
> allowed up to 0xff on each device downstream.
>
> This caused a lot of errors to be printed, as this is not logical
> according to spec. (but it worked ..)
Including a sample error in the changelog might help somebody
suffering from the problem find this solution.
> After this commit, the driver stopped scanning deeper when the last
> allocated busnr equals the subordinate of it's master, causing devices
> to be undiscovered (especially behind bridges), uncovering the impact of
> this bug.
>
> Before:
>
> 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 ...
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>
> 00:00.0 0604: 16c3:abcd (rev 01)
> 01:00.0 0604: 10b5:8604 (rev ba)
> ... stops after bus 1 ...
>
> After:
>
> 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00
> ...
> Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
>
> 00:00.0 0604: 16c3:abcd (rev 01)
> 01:00.0 0604: 10b5:8604 (rev ba)
> 02:01.0 0604: 10b5:8604 (rev ba)
> 02:04.0 0604: 10b5:8604 (rev ba)
> 02:05.0 0604: 10b5:8604 (rev ba)
> 03:00.0 0280: 168c:0033 (rev 01)
> 05:00.0 0280: 168c:0033 (rev 01)
>
Should have a "Fixes: a20c7f36bd3d ..." tag if that's really the
correct commit.
> Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
> ---
>
> Needs backports to 4.14 & 4.9 stables
Add a "CC: stable at vger.kernel.org" after your signed-off-by to handle
this. But something's wrong because a20c7f36bd3d only appeared in
v4.15-rc1, so either that's the wrong commit or stable kernels don't
need the fix.
> drivers/pci/dwc/pci-imx6.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
> index b73483534a5b..3d13fa8c2eb1 100644
> --- a/drivers/pci/dwc/pci-imx6.c
> +++ b/drivers/pci/dwc/pci-imx6.c
> @@ -76,6 +76,9 @@ struct imx6_pcie {
>
> #define PCIE_RC_LCSR 0x80
>
> +#define PCIE_RC_BNR 0x18
> +#define PCIE_RC_BNR_MAX_SUBORDINATE (0xff << 16)
> +
> /* PCIe Port Logic registers (memory-mapped) */
> #define PL_OFFSET 0x700
> #define PCIE_PL_PFLR (PL_OFFSET + 0x08)
> @@ -562,6 +565,17 @@ static int imx6_pcie_establish_link(struct imx6_pcie *imx6_pcie)
> int ret;
>
> /*
> + * By default, the subordinate is set equally to the secondary
> + * bus (0x01) when the RC boots.
> + * This means that theoretically, only bus 1 is reachable from the RC.
> + * Force the PCIe RC subordinate to 0xff, otherwise no downstream
> + * devices will be detected behind bus 1.
> + */
> + tmp = dw_pcie_readl_rc(pp, PCIE_RC_BNR);
> + tmp |= PCIE_RC_BNR_MAX_SUBORDINATE;
> + dw_pcie_writel_rc(pp, PCIE_RC_BNR, tmp);
This functionality is not related to establishing the link, so I think
it should be put elsewhere, maybe either directly in imx6_pcie_probe()
or in imx6_pcie_host_init().
The DT really should contain a "bus-range" property and
dw_pcie_host_init() will already pay attention to that if it's
present, and I think it defaults to 0-0xff if it's not present.
So I think you should be using pp->busn instead of hard-coding
PCIE_RC_BNR_MAX_SUBORDINATE.
> + /*
> * Force Gen1 operation when starting the link. In case the link is
> * started in Gen2 mode, there is a possibility the devices on the
> * bus will not be detected at all. This happens with PCIe switches.
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v5 01/12] dt-bindings: panel: lvds: Document power-supply property
From: Laurent Pinchart @ 2018-01-04 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104194436.reka6nw5hf32o4p3@flea.lan>
Hi Maxime,
On Thursday, 4 January 2018 21:44:36 EET Maxime Ripard wrote:
> On Fri, Dec 22, 2017 at 02:08:20PM +0200, Laurent Pinchart wrote:
> > On Thursday, 21 December 2017 13:02:27 EET Maxime Ripard wrote:
> >> The power-supply property is used by a vast majority of panels,
> >> including panel-simple. Let's document it as a common property
> >>
> >> Reviewed-by: Rob Herring <robh@kernel.org>
> >> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >> ---
> >>
> >> Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 ++++
> >> Documentation/devicetree/bindings/display/panel/panel-lvds.txt | 1 +
> >> Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +-
> >> 3 files changed, 8 insertions(+), 1 deletion(-)
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> >> b/Documentation/devicetree/bindings/display/panel/panel-common.txt index
> >> ec52c472c845..125ea68052af 100644
> >> --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> >> +++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt
> >> @@ -78,6 +78,12 @@ used for panels that implement compatible control
> >> signals. while active. Active high reset signals can be supported by
> >> inverting the GPIO specifier polarity flag.
> >>
> >> +Power
> >> +-----
> >> +
> >> +- power-supply: many display panels need an additional power supply in
> >> + order to be fully powered-up. For such panels, power-supply contains
> >> + a phandle to the regulator powering the panel.
> >
> > I think we should give more details here about the limitations of this
> > property. How about the following explanation ?
> >
> > - power-supply: display panels require power to be supplied. While several
> > panels need more than one power supply with panel-specific constraints
> > governing the order and timings of the power supplies, in many cases a
> > single power supply is sufficient, either because the panel has a single
> > power rail, or because all its power rails can be driven by the same
> > supply. In that case the power-supply property specifies the supply
> > powering the panel as a phandle to a regulator.
>
> That works for me. Do you want me to resend it with that text, or
> should I merge it (and if so, with your Reviewed-by or Acked-by?)?
No need to resend if it's just for me. With the above text,
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
(on a side note, I wonder if it's more efficient to ask whether to resend
instead of just resending :-))
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [GIT PULL] Qualcomm Driver updates for 4.16
From: Andy Gross @ 2018-01-04 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514789609-4133-4-git-send-email-andy.gross@linaro.org>
Arnd/Olof/Kevin,
Please do not merge this pull request. I will be sending a v2
Andy
^ permalink raw reply
* [PATCH v2 1/3] drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate
From: Maxime Ripard @ 2018-01-04 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171226111227.4526-2-net147@gmail.com>
Hi,
On Tue, Dec 26, 2017 at 10:12:25PM +1100, Jonathan Liu wrote:
> We should check if the best match has been set before comparing it.
>
> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> Signed-off-by: Jonathan Liu <net147@gmail.com>
> ---
> drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
> index dc332ea56f6c..4d235e5ea31c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
> @@ -102,7 +102,7 @@ static int sun4i_tmds_determine_rate(struct clk_hw *hw,
> goto out;
> }
>
> - if (abs(rate - rounded / i) <
> + if (!best_parent || abs(rate - rounded / i) <
Why is that causing any issue?
If best_parent is set to 0...
> abs(rate - best_parent / best_div)) {
... the value returned here is going to be rate, which is going to be
higher than the first part of the comparison meaning ...
> best_parent = rounded;
... that best_parent is going to be set there.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180104/5d9007ba/attachment.sig>
^ permalink raw reply
* [GIT PULL] Qualcomm Driver updates for 4.16
From: Andy Gross @ 2018-01-04 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <003c9462-aea5-f4b5-c5ca-fa0d0504a92b@arm.com>
On Tue, Jan 02, 2018 at 11:38:35AM +0000, Sudeep Holla wrote:
> H Andy,
>
> As Bjorn mention on the actual thread, you also need
>
> "[PATCH 1/4] of: platform: populate /firmware/ node from
> of_platform_default_populate_init()"
>
> which Rob has acked and I am fine if you pick it along with the above patch.
Yeah I saw that. I'm spinning a v2 of the pull request. Thanks
Andy
^ permalink raw reply
* [PATCH 2/2] mmc: sunxi: Add runtime_pm support
From: Maxime Ripard @ 2018-01-04 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFomRYaL=gCwY2Kq0PXRJ9WtsQVCi-3KfkfSNU3+mnJpow@mail.gmail.com>
Hi Ulf,
On Thu, Dec 21, 2017 at 01:21:51PM +0100, Ulf Hansson wrote:
> On 20 December 2017 at 11:50, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > So far, even if our card was not in use, we didn't shut down our main
> > clock, which meant that it was still output on the MMC bus.
> >
> > While this obviously means that we could save some power there, it also
> > created issues when it comes with EMC control since we'll have a perfect
> > peak at the card clock rate.
> >
> > Let's implement runtime_pm with autosuspend so that we will shut down the
> > clock when it's not been in use for quite some time.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > drivers/mmc/host/sunxi-mmc.c | 90 ++++++++++++++++++++++++-------------
> > 1 file changed, 60 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> > index 3ce46ebd3488..c6a0bd0e0476 100644
> > --- a/drivers/mmc/host/sunxi-mmc.c
> > +++ b/drivers/mmc/host/sunxi-mmc.c
> > @@ -35,6 +35,7 @@
> > #include <linux/of_gpio.h>
> > #include <linux/of_platform.h>
> > #include <linux/platform_device.h>
> > +#include <linux/pm_runtime.h>
> > #include <linux/regulator/consumer.h>
> > #include <linux/reset.h>
> > #include <linux/scatterlist.h>
> > @@ -1217,29 +1218,11 @@ static int sunxi_mmc_resource_request(struct sunxi_mmc_host *host,
> > return ret;
> > }
> >
> > - ret = clk_prepare_enable(host->clk_mmc);
> > - if (ret) {
> > - dev_err(&pdev->dev, "Enable mmc clk err %d\n", ret);
> > - goto error_disable_clk_ahb;
> > - }
> > -
> > - ret = clk_prepare_enable(host->clk_output);
> > - if (ret) {
> > - dev_err(&pdev->dev, "Enable output clk err %d\n", ret);
> > - goto error_disable_clk_mmc;
> > - }
> > -
> > - ret = clk_prepare_enable(host->clk_sample);
> > - if (ret) {
> > - dev_err(&pdev->dev, "Enable sample clk err %d\n", ret);
> > - goto error_disable_clk_output;
> > - }
> > -
>
> Actually, I think you should keep all the above. Perhaps you may want
> to move it to a separate helper function though, which the
> ->runtime_resume() callbacks can invoke as well.
>
> More reasons to why, see the comment in the ->probe() function.
>
> > if (!IS_ERR(host->reset)) {
> > ret = reset_control_reset(host->reset);
> > if (ret) {
> > dev_err(&pdev->dev, "reset err %d\n", ret);
> > - goto error_disable_clk_sample;
> > + goto error_disable_clk_ahb;
> > }
> > }
> >
> > @@ -1258,12 +1241,6 @@ static int sunxi_mmc_resource_request(struct sunxi_mmc_host *host,
> > error_assert_reset:
> > if (!IS_ERR(host->reset))
> > reset_control_assert(host->reset);
> > -error_disable_clk_sample:
> > - clk_disable_unprepare(host->clk_sample);
> > -error_disable_clk_output:
> > - clk_disable_unprepare(host->clk_output);
> > -error_disable_clk_mmc:
> > - clk_disable_unprepare(host->clk_mmc);
> > error_disable_clk_ahb:
> > clk_disable_unprepare(host->clk_ahb);
> > return ret;
> > @@ -1280,6 +1257,7 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
> > dev_err(&pdev->dev, "mmc alloc host failed\n");
> > return -ENOMEM;
> > }
> > + platform_set_drvdata(pdev, mmc);
> >
> > host = mmc_priv(mmc);
> > host->mmc = mmc;
> > @@ -1340,12 +1318,16 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
> > if (ret)
> > goto error_free_dma;
> >
> > + pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
> > + pm_runtime_use_autosuspend(&pdev->dev);
> > + pm_runtime_enable(&pdev->dev);
> > +
>
> This means in case you don't have CONFIG_PM set when compiling this
> driver, the clocks will never be enabled using runtime PM.
>
> I think it's good practice to deal with this, therefore I think you
> should enable the clocks as before, and instead indicate that the
> device is already runtime resumed.
>
> In other words, before you call pm_runtime_enable(), invoke
> pm_runtime_set_active().
That's a very good point, I'll do that in the next iteration.
> > ret = mmc_add_host(mmc);
> > if (ret)
> > goto error_free_dma;
> >
> > dev_info(&pdev->dev, "base:0x%p irq:%u\n", host->reg_base, host->irq);
> > - platform_set_drvdata(pdev, mmc);
> > +
> > return 0;
> >
> > error_free_dma:
> > @@ -1361,27 +1343,75 @@ static int sunxi_mmc_remove(struct platform_device *pdev)
> > struct sunxi_mmc_host *host = mmc_priv(mmc);
> >
> > mmc_remove_host(mmc);
> > + pm_runtime_force_suspend(&pdev->dev);
>
> Do you need the clocks to be enabled, while calling disable_irq() and
> sunxi_mmc_reset_host()?
>
> In such case you need to call pm_runtime_get_sync() here. Then move
> pm_runtime_force_suspend() a few lines below, and later call
> pm_runtime_put_noidle().
We don't for disable_irq, but we need it for
sunxi_mmc_reset_host. I'll do what you suggest.
> > disable_irq(host->irq);
> > sunxi_mmc_reset_host(host);
> >
> > if (!IS_ERR(host->reset))
> > reset_control_assert(host->reset);
> >
> > - clk_disable_unprepare(host->clk_sample);
> > + dma_free_coherent(&pdev->dev, PAGE_SIZE, host->sg_cpu, host->sg_dma);
> > + mmc_free_host(mmc);
> > +
> > + return 0;
> > +}
> > +
> > +static int sunxi_mmc_runtime_resume(struct device *dev)
> > +{
> > + struct mmc_host *mmc = dev_get_drvdata(dev);
> > + struct sunxi_mmc_host *host = mmc_priv(mmc);
> > + int ret;
> > +
> > + ret = clk_prepare_enable(host->clk_mmc);
> > + if (ret) {
> > + dev_err(dev, "Enable mmc clk err %d\n", ret);
> > + return ret;
> > + }
> > +
> > + ret = clk_prepare_enable(host->clk_output);
> > + if (ret) {
> > + dev_err(dev, "Enable output clk err %d\n", ret);
> > + goto error_disable_clk_mmc;
> > + }
> > +
> > + ret = clk_prepare_enable(host->clk_sample);
> > + if (ret) {
> > + dev_err(dev, "Enable sample clk err %d\n", ret);
> > + goto error_disable_clk_output;
> > + }
> > +
> > + return 0;
> > +
> > +error_disable_clk_output:
> > clk_disable_unprepare(host->clk_output);
> > +error_disable_clk_mmc:
> > clk_disable_unprepare(host->clk_mmc);
> > - clk_disable_unprepare(host->clk_ahb);
> > + return ret;
> > +}
> >
> > - dma_free_coherent(&pdev->dev, PAGE_SIZE, host->sg_cpu, host->sg_dma);
> > - mmc_free_host(mmc);
> > +static int sunxi_mmc_runtime_suspend(struct device *dev)
> > +{
> > + struct mmc_host *mmc = dev_get_drvdata(dev);
> > + struct sunxi_mmc_host *host = mmc_priv(mmc);
> > +
> > + clk_disable_unprepare(host->clk_sample);
> > + clk_disable_unprepare(host->clk_output);
> > + clk_disable_unprepare(host->clk_mmc);
> >
> > return 0;
> > }
> >
> > +static const struct dev_pm_ops sunxi_mmc_pm_ops = {
> > + SET_RUNTIME_PM_OPS(sunxi_mmc_runtime_suspend,
> > + sunxi_mmc_runtime_resume,
> > + NULL)
> > +};
> > +
> > static struct platform_driver sunxi_mmc_driver = {
> > .driver = {
> > .name = "sunxi-mmc",
> > .of_match_table = of_match_ptr(sunxi_mmc_of_match),
> > + .pm = &sunxi_mmc_pm_ops,
> > },
> > .probe = sunxi_mmc_probe,
> > .remove = sunxi_mmc_remove,
> > --
> > git-series 0.9.1
>
> Otherwise this looks good to me!
>
> BTW, isn't system wide suspend/resume() also important to save power
> for? That's rather simple to implement, after you have enabled runtime
> PM support.
We don't have (unfortunately) any kind of suspend support at the
moment, so I guess that'll come as a single step when we'll have it :)
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180104/1e76c357/attachment.sig>
^ permalink raw reply
* [PATCH V4] ARM: imx_v6_v7_defconfig: select the CONFIG_CPUFREQ_DT
From: Anson Huang @ 2018-01-04 19:51 UTC (permalink / raw)
To: linux-arm-kernel
Select CONFIG_CPUFREQ_DT by default to enable
cpu-freq driver for i.MX7D.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
changes since V3:
correct commit message.
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 29cd1ac..1c9c15f 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -58,6 +58,7 @@ CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
+CONFIG_CPUFREQ_DT=y
CONFIG_ARM_IMX6Q_CPUFREQ=y
CONFIG_CPU_IDLE=y
CONFIG_VFP=y
--
1.9.1
^ permalink raw reply related
* [PATCH V3] ARM: imx_v6_v7_defconfig: select the CONFIG_CPUFREQ_DT
From: Anson Huang @ 2018-01-04 19:48 UTC (permalink / raw)
To: linux-arm-kernel
Select CONFIG_CPUFREQ_DT by default to enable
cpu-freq driver for i.MX7D.
The rest changes are generated by "make savedefconfig".
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
changes since V2:
remove unexpected changes caused by savedefconfig.
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 29cd1ac..1c9c15f 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -58,6 +58,7 @@ CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
+CONFIG_CPUFREQ_DT=y
CONFIG_ARM_IMX6Q_CPUFREQ=y
CONFIG_CPU_IDLE=y
CONFIG_VFP=y
--
1.9.1
^ permalink raw reply related
* [arm-soc:next/dt 26/27] arch/arm64/boot/dts/sprd/sc9860.dtsi:10:10: fatal error: dt-bindings/clock/sprd,sc9860-clk.h: No such file or directory
From: kbuild test robot @ 2018-01-04 19:46 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git next/dt
head: b304c1c57f372c68a7a143b3b300c1a4666c8f7d
commit: 22f37a242925d28f7055639db64ea429afb50e54 [26/27] arm64: dts: add clocks for SC9860
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 22f37a242925d28f7055639db64ea429afb50e54
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
In file included from arch/arm64/boot/dts/sprd/sp9860g-1h10.dts:11:0:
>> arch/arm64/boot/dts/sprd/sc9860.dtsi:10:10: fatal error: dt-bindings/clock/sprd,sc9860-clk.h: No such file or directory
#include <dt-bindings/clock/sprd,sc9860-clk.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
vim +10 arch/arm64/boot/dts/sprd/sc9860.dtsi
> 10 #include <dt-bindings/clock/sprd,sc9860-clk.h>
11 #include "whale2.dtsi"
12
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 37439 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180105/4f8f0570/attachment-0001.gz>
^ permalink raw reply
* [PATCH v5 01/12] dt-bindings: panel: lvds: Document power-supply property
From: Maxime Ripard @ 2018-01-04 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2493504.1OPucrC18r@avalon>
Hi Laurent,
On Fri, Dec 22, 2017 at 02:08:20PM +0200, Laurent Pinchart wrote:
> Hi Maxime,
>
> Thank you for the patch.
>
> On Thursday, 21 December 2017 13:02:27 EET Maxime Ripard wrote:
> > The power-supply property is used by a vast majority of panels, including
> > panel-simple. Let's document it as a common property
> >
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 ++++++
> > Documentation/devicetree/bindings/display/panel/panel-lvds.txt | 1 +
> > Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +- 3
> > files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> > b/Documentation/devicetree/bindings/display/panel/panel-common.txt index
> > ec52c472c845..125ea68052af 100644
> > --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt
> > @@ -78,6 +78,12 @@ used for panels that implement compatible control
> > signals. while active. Active high reset signals can be supported by
> > inverting the GPIO specifier polarity flag.
> >
> > +Power
> > +-----
> > +
> > +- power-supply: many display panels need an additional power supply in
> > + order to be fully powered-up. For such panels, power-supply contains
> > + a phandle to the regulator powering the panel.
>
> I think we should give more details here about the limitations of this
> property. How about the following explanation ?
>
> - power-supply: display panels require power to be supplied. While several
> panels need more than one power supply with panel-specific constraints
> governing the order and timings of the power supplies, in many cases a single
> power supply is sufficient, either because the panel has a single power rail,
> or because all its power rails can be driven by the same supply. In that case
> the power-supply property specifies the supply powering the panel as a phandle
> to a regulator.
That works for me. Do you want me to resend it with that text, or
should I merge it (and if so, with your Reviewed-by or Acked-by?)?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180104/ddaee006/attachment-0001.sig>
^ 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