* [PATCH net-next v2 8/8] net: phy: meson-gxl: join the authors
From: Jerome Brunet @ 2017-12-07 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207142715.32578-1-jbrunet@baylibre.com>
Following previous changes, join the other authors of this driver and
take the blame with them
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/net/phy/meson-gxl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
index 861b021b9758..4cd5b2622ae1 100644
--- a/drivers/net/phy/meson-gxl.c
+++ b/drivers/net/phy/meson-gxl.c
@@ -256,4 +256,5 @@ MODULE_DEVICE_TABLE(mdio, meson_gxl_tbl);
MODULE_DESCRIPTION("Amlogic Meson GXL Internal PHY driver");
MODULE_AUTHOR("Baoqi wang");
MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
+MODULE_AUTHOR("Jerome Brunet <jbrunet@baylibre.com>");
MODULE_LICENSE("GPL");
--
2.14.3
^ permalink raw reply related
* [RFC PATCH 1/6] drm: Add Content Protection property
From: Alan Cox @ 2017-12-07 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205104538.b4fxdjad3c46koas@phenom.ffwll.local>
> If you want to actually lock down a machine to implement content
> protection, then you need secure boot without unlockable boot-loader and a
> pile more bits in userspace.
So let me take my Intel hat off for a moment.
The upstream policy has always been that we don't merge things which
don't have an open usable user space. Is the HDCP encryption feature
useful on its own ? What do users get from it ?
If this is just an enabler for a lump of binary stuff in ChromeOS then I
don't think it belongs, if it is useful standalone then it seems it does
belong ?
Alan
^ permalink raw reply
* [PATCH RESEND] arm64: fault: avoid send SIGBUS two times
From: James Morse @ 2017-12-07 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7d5791bf-39d4-b790-2f01-6abff800c6d0@huawei.com>
Hi gengdongjiu, Will,
On 07/12/17 05:55, gengdongjiu wrote:
> On 2017/12/7 0:15, Will Deacon wrote:
>>> --- a/arch/arm64/mm/fault.c
>>> +++ b/arch/arm64/mm/fault.c
>>> @@ -570,7 +570,6 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>>> {
>>> struct siginfo info;
>>> const struct fault_info *inf;
>>> - int ret = 0;
>>>
>>> inf = esr_to_fault_info(esr);
>>> pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
>>> @@ -585,7 +584,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>>> if (interrupts_enabled(regs))
>>> nmi_enter();
>>>
>>> - ret = ghes_notify_sea();
>>> + ghes_notify_sea();
>>>
>>> if (interrupts_enabled(regs))
>>> nmi_exit();
>>> @@ -600,7 +599,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>>> info.si_addr = (void __user *)addr;
>>> arm64_notify_die("", regs, &info, esr);
>>>
>>> - return ret;
>>> + return 0;
>> Hmm, so this code is a bit of mess.
>>
>> Wouldn't it be better to have the signal dispatching code in do_mem_abort
>> check ESR.ESR_ELx_FnV, so then do_sea wouldn't have to, and we could just
>> return an error instead?
FnV only applies to one of the Synchronous External Abort ESRs, hence it ended
up in here.
> Regardless ghes_notify_sea()'s return value, it always needs to deliver signal,
> because ghes_notify_sea()'s return value does not reflect whether the memory error
> handler(memory_failure()) handle the error successfully or failed. If let do_mem_abort()
> delivers the signal, we should always let do_sea() return error, then the do_mem_abort() can
> always deliver signal. Then we will see the strange log as shown below when happen Synchronous External Abort.
>
> [ 676.700652] Synchronous External Abort: synchronous external abort (0x96000410) at 0x0000000033ff7008
> [ 676.723301] Unhandled fault: synchronous external abort (0x96000410) at 0x0000000033ff7008
>
> so I think it is better send the signal in the do_sea(), not send it in the do_mem_abort().
I agree: I think improving the commit message would help here, something like:
---------
do_sea() calls arm64_notify_die() which will always signal user-space.
It also returns whether APEI claimed the external abort as a RAS notification.
If it returns failure do_mem_abort() will signal user-space too.
do_mem_abort() wants to know if we handled the error, we always call
arm64_notify_die() so can always return success.
---------
APEI's return value matters for KVM, and it will matter here too if we support
kernel-first.
> do_mem_abort() only send the signal when the exception does not defined in fault_info[]. Another benefit
> is that do_sea() can send different signal according to the Synchronous External Abort type, such as SIGBUS or SIGKILL.
> the do_mem_abort() can only send one kind signal.
(I'm not convinced we want to do this other than via the firwmare/kernel RAS
code, but that is a separate issue)
Thanks,
James
^ permalink raw reply
* [PATCH v3 11/20] arm64: assembler: add macros to conditionally yield the NEON under PREEMPT
From: Dave Martin @ 2017-12-07 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206194346.24393-12-ard.biesheuvel@linaro.org>
On Wed, Dec 06, 2017 at 07:43:37PM +0000, Ard Biesheuvel wrote:
> Add support macros to conditionally yield the NEON (and thus the CPU)
> that may be called from the assembler code.
>
> In some cases, yielding the NEON involves saving and restoring a non
> trivial amount of context (especially in the CRC folding algorithms),
> and so the macro is split into three, and the code in between is only
> executed when the yield path is taken, allowing the context to be preserved.
> The third macro takes an optional label argument that marks the resume
> path after a yield has been performed.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/include/asm/assembler.h | 51 ++++++++++++++++++++
> 1 file changed, 51 insertions(+)
>
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index 5f61487e9f93..c54e408fd5a7 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -572,4 +572,55 @@ alternative_else_nop_endif
> #endif
> .endm
>
> +/*
> + * Check whether to yield to another runnable task from kernel mode NEON code
> + * (which runs with preemption disabled).
> + *
> + * if_will_cond_yield_neon
> + * // pre-yield patchup code
> + * do_cond_yield_neon
> + * // post-yield patchup code
> + * endif_yield_neon
^ Mention the lbl argument?
> + *
> + * - Check whether the preempt count is exactly 1, in which case disabling
enabling ^
> + * preemption once will make the task preemptible. If this is not the case,
> + * yielding is pointless.
> + * - Check whether TIF_NEED_RESCHED is set, and if so, disable and re-enable
> + * kernel mode NEON (which will trigger a reschedule), and branch to the
> + * yield fixup code.
Mention that neither patchup sequence is allowed to use section-changing
directives?
For example:
if_will_cond_yield_neon
// some code
.pushsection .rodata, "a"
foo: .quad // some literal data for some reason
.popsection
// some code
do_cond_yield_neon
is not safe, because .previous is now .rodata.
(You could protect against this with
.pushsection .text; .previous; .subsection 1; // ...
.popsection
but it may be overkill.)
> + *
> + * This macro sequence clobbers x0, x1 and the flags register unconditionally,
> + * and may clobber x2 .. x18 if the yield path is taken.
> + */
> +
> + .macro cond_yield_neon, lbl
> + if_will_cond_yield_neon
> + do_cond_yield_neon
> + endif_yield_neon \lbl
> + .endm
> +
> + .macro if_will_cond_yield_neon
> +#ifdef CONFIG_PREEMPT
> + get_thread_info x0
> + ldr w1, [x0, #TSK_TI_PREEMPT]
> + ldr x0, [x0, #TSK_TI_FLAGS]
> + cmp w1, #1 // == PREEMPT_OFFSET
Can we at least drop a BUILD_BUG_ON() somewhere to check this?
Maybe in kernel_neon_begin() since this is intimately kernel-mode NEON
related.
> + csel x0, x0, xzr, eq
> + tbnz x0, #TIF_NEED_RESCHED, 5555f // needs rescheduling?
> +#endif
A comment that we will fall through to 6666f here may be helpful.
> + .subsection 1
> +5555:
> + .endm
> +
> + .macro do_cond_yield_neon
> + bl kernel_neon_end
> + bl kernel_neon_begin
> + .endm
> +
> + .macro endif_yield_neon, lbl=6666f
> + b \lbl
> + .previous
> +6666:
Could have slightly more random "random" labels here, but otherwise
it looks ok to me.
I might go through and replace all the random labels with something
more robust sometime, but I've never been sure it was worth the
effort...
Cheers
---Dave
^ permalink raw reply
* [PATCH] arm: dts: qcom: fix missing #phy-cells for apq8064
From: Arnd Bergmann @ 2017-12-07 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171109225422.14280-1-robh@kernel.org>
On Thu, Nov 9, 2017 at 11:54 PM, Rob Herring <robh@kernel.org> wrote:
> Fix dtc warnings for missing #phy-cells for apq8064:
>
> Warning (phys_property): Missing property '#phy-cells' in node /soc/dsi-phy at 4700200 or bad phandle (referred from /soc/mdss_dsi at 4700000:phys[0])
> Warning (phys_property): Missing property '#phy-cells' in node /soc/hdmi-phy at 4a00400 or bad phandle (referred from /soc/hdmi-tx at 4a00000:phys[0])
>
> Cc: Andy Gross <andy.gross@linaro.org>
> Cc: David Brown <david.brown@linaro.org>
> Cc: linux-arm-msm at vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
Applied to fixes, thanks!
Anrd
^ permalink raw reply
* [PATCH 4/6] arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv
From: Arnd Bergmann @ 2017-12-07 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171109222614.5719-4-robh@kernel.org>
On Thu, Nov 9, 2017 at 11:26 PM, Rob Herring <robh@kernel.org> wrote:
> "usb-nop-xceiv" is using the phy binding, but is missing #phy-cells
> property. This is probably because the binding was the precursor to the phy
> binding.
>
> Fixes the following warning in nspire dts files:
>
> Warning (phys_property): Missing property '#phy-cells' in node ...
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> Doesn't seem to be a maintainer for nspire. Arnd, please apply.
Applied to fixes, thanks!
Arnd
^ permalink raw reply
* [PATCH V6 4/7] OF: properties: Implement get_match_data() callback
From: Sinan Kaya @ 2017-12-07 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207141029.575c0a03@karo-electronics.de>
On 12/7/2017 8:10 AM, Lothar Wa?mann wrote:
>> +void *of_fwnode_get_match_data(const struct fwnode_handle *fwnode,
>> + struct device *dev)
> Shouldn't this be 'const void *of_fwnode_get_match_data
OF keeps the driver data as a (const void*) internally. ACPI keeps the
driver data as kernel_ulong_t in struct acpi_device_id.
I tried to find the middle ground here by converting output to void*
but not keeping const.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2] ARM: omap2: hide omap3_save_secure_ram on non-OMAP3 builds
From: Arnd Bergmann @ 2017-12-07 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206220436.GA28152@atomide.com>
On Wed, Dec 6, 2017 at 11:04 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Arnd Bergmann <arnd@arndb.de> [171206 21:52]:
>> In configurations without CONFIG_OMAP3 but with secure RAM support,
>> we now run into a link failure:
>>
>> arch/arm/mach-omap2/omap-secure.o: In function `omap3_save_secure_ram':
>> omap-secure.c:(.text+0x130): undefined reference to `save_secure_ram_context'
>>
>> The omap3_save_secure_ram() function is only called from the OMAP34xx
>> power management code, so we can simply hide that function in the
>> appropriate #ifdef.
>>
>> Fixes: d09220a887f7 ("ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> v2: also check for CONFIG_PM
>
> Acked-by: Tony Lindgren <tony@atomide.com>
Applied now
Arnd
^ permalink raw reply
* [PATCH v3 11/20] arm64: assembler: add macros to conditionally yield the NEON under PREEMPT
From: Ard Biesheuvel @ 2017-12-07 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207143934.GF22781@e103592.cambridge.arm.com>
On 7 December 2017 at 14:39, Dave Martin <Dave.Martin@arm.com> wrote:
> On Wed, Dec 06, 2017 at 07:43:37PM +0000, Ard Biesheuvel wrote:
>> Add support macros to conditionally yield the NEON (and thus the CPU)
>> that may be called from the assembler code.
>>
>> In some cases, yielding the NEON involves saving and restoring a non
>> trivial amount of context (especially in the CRC folding algorithms),
>> and so the macro is split into three, and the code in between is only
>> executed when the yield path is taken, allowing the context to be preserved.
>> The third macro takes an optional label argument that marks the resume
>> path after a yield has been performed.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>> arch/arm64/include/asm/assembler.h | 51 ++++++++++++++++++++
>> 1 file changed, 51 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
>> index 5f61487e9f93..c54e408fd5a7 100644
>> --- a/arch/arm64/include/asm/assembler.h
>> +++ b/arch/arm64/include/asm/assembler.h
>> @@ -572,4 +572,55 @@ alternative_else_nop_endif
>> #endif
>> .endm
>>
>> +/*
>> + * Check whether to yield to another runnable task from kernel mode NEON code
>> + * (which runs with preemption disabled).
>> + *
>> + * if_will_cond_yield_neon
>> + * // pre-yield patchup code
>> + * do_cond_yield_neon
>> + * // post-yield patchup code
>> + * endif_yield_neon
>
> ^ Mention the lbl argument?
>
Yep will do
>> + *
>> + * - Check whether the preempt count is exactly 1, in which case disabling
>
> enabling ^
>
>> + * preemption once will make the task preemptible. If this is not the case,
>> + * yielding is pointless.
>> + * - Check whether TIF_NEED_RESCHED is set, and if so, disable and re-enable
>> + * kernel mode NEON (which will trigger a reschedule), and branch to the
>> + * yield fixup code.
>
> Mention that neither patchup sequence is allowed to use section-changing
> directives?
>
> For example:
>
> if_will_cond_yield_neon
> // some code
>
> .pushsection .rodata, "a"
> foo: .quad // some literal data for some reason
> .popsection
>
> // some code
> do_cond_yield_neon
>
> is not safe, because .previous is now .rodata.
>
Are you sure this is true?
The gas info page for .previous tells me
In terms of the section stack, this directive swaps the current
section with the top section on the section stack.
and it seems to me that .rodata is no longer on the section stack
after .popsection. In that sense, push/pop should be safe, but
section/subsection/previous is not (I think). So yes, let's put a note
in to mention that section directives are unsupported.
> (You could protect against this with
> .pushsection .text; .previous; .subsection 1; // ...
> .popsection
> but it may be overkill.)
>
>> + *
>> + * This macro sequence clobbers x0, x1 and the flags register unconditionally,
>> + * and may clobber x2 .. x18 if the yield path is taken.
>> + */
>> +
>> + .macro cond_yield_neon, lbl
>> + if_will_cond_yield_neon
>> + do_cond_yield_neon
>> + endif_yield_neon \lbl
>> + .endm
>> +
>> + .macro if_will_cond_yield_neon
>> +#ifdef CONFIG_PREEMPT
>> + get_thread_info x0
>> + ldr w1, [x0, #TSK_TI_PREEMPT]
>> + ldr x0, [x0, #TSK_TI_FLAGS]
>> + cmp w1, #1 // == PREEMPT_OFFSET
>
> Can we at least drop a BUILD_BUG_ON() somewhere to check this?
>
> Maybe in kernel_neon_begin() since this is intimately kernel-mode NEON
> related.
>
Sure.
>> + csel x0, x0, xzr, eq
>> + tbnz x0, #TIF_NEED_RESCHED, 5555f // needs rescheduling?
>> +#endif
>
> A comment that we will fall through to 6666f here may be helpful.
>
Indeed. Will add that.
>> + .subsection 1
>> +5555:
>> + .endm
>> +
>> + .macro do_cond_yield_neon
>> + bl kernel_neon_end
>> + bl kernel_neon_begin
>> + .endm
>> +
>> + .macro endif_yield_neon, lbl=6666f
>> + b \lbl
>> + .previous
>> +6666:
>
> Could have slightly more random "random" labels here, but otherwise
> it looks ok to me.
>
Which number did you have in mind that is more random than 6666? :-)
> I might go through and replace all the random labels with something
> more robust sometime, but I've never been sure it was worth the
> effort...
>
I guess we could invent all kinds of elaborate schemes but as you say,
having 4 digit numbers and grep'ing the source before you add a new
one has been working fine so far, so I don't think it should be a
priority.
^ permalink raw reply
* [RFC 3/9] arm64: handle 52-bit addresses in TTBR
From: Robin Murphy @ 2017-12-07 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <42182cdd-be9f-841f-6fda-1486ac2ded2f@arm.com>
On 07/12/17 12:29, Kristina Martsenko wrote:
> On 21/11/17 14:39, Robin Murphy wrote:
>> Hi Kristina,
>>
>> On 21/11/17 11:57, Kristina Martsenko wrote:
>>> The top 4 bits of a 52-bit physical address are positioned at bits 2..5
>>> in the TTBR registers. Introduce a couple of macros to move the bits
>>> there, and change all TTBR writers to use them.
>>>
>>> Leave TTBR0 PAN code unchanged, to avoid complicating it. A system with
>>> 52-bit PA will have PAN anyway (because it's ARMv8.1 or later), and a
>>> system without 52-bit PA can only use up to 48-bit PAs. Add a kconfig
>>> dependency to ensure PAN is configured.
>>>
>>> In addition, when using 52-bit PA there is a special alignment
>>> requirement on the top-level table. We don't currently have any VA_BITS
>>> configuration that would violate the requirement, but one could be added
>>> in the future, so add a compile-time BUG_ON to check for it.
>>>
>>> Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
>>> ---
>
> [...]
>
>>> diff --git a/arch/arm64/include/asm/assembler.h
>>> b/arch/arm64/include/asm/assembler.h
>>> index 04cf94766b78..ba3c796b9fe1 100644
>>> --- a/arch/arm64/include/asm/assembler.h
>>> +++ b/arch/arm64/include/asm/assembler.h
>>> @@ -512,4 +512,21 @@ alternative_else_nop_endif
>>> ? #endif
>>> ????? .endm
>>> ? +/*
>>> + * Arrange a physical address in a TTBR register, taking care of 52-bit
>>> + * addresses.
>>> + *
>>> + *???? phys:??? physical address, preserved
>>> + *???? ttbr:??? returns the TTBR value
>>> + */
>>> +??? .macro??? phys_to_ttbr, phys, ttbr
>>> +#ifdef CONFIG_ARM64_PA_BITS_52
>>> +??? and??? \ttbr, \phys, #(1 << 48) - 1
>>> +??? orr??? \ttbr, \ttbr, \phys, lsr #48 - 2
>>> +??? bic??? \ttbr, \ttbr, #(1 << 2) - 1
>>
>> Is there any reason for masking off each end of the result separately
>> like this, or could we just do it more straightforwardly?
>
> I don't recall any reason, maybe just to keep it simple, to avoid having
> a separate mask macro.
>
>> #define TTBR_BADDR_MASK ((1 << 46) - 1) << 2
>>
>> ????orr??? \ttbr, \phys, \phys, lsr #46
>> ????and??? \ttbr, \ttbr, #TTBR_BADDR_MASK
>>
>> (and equivalently for phys_to_pte in patch 4)
>
> Ok, I'll rewrite it like this. (Note that mask is 52-bit-specific though.)
I don't see that it need be 52-bit specific - true the BADDR field
itself is strictly bits 47:1, but AFAICS bit 1 is always going to be
RES0: either explicitly in the 52-bit case, or from the (x-1):1
definition otherwise, since the requirement that a table must be aligned
to its size infers an absolute lower bound of x >= 3 (it may be larger
still due to other reasons, but I'm finding this area of the ARM ARM
obnoxiously difficult to read). Thus defining the mask as covering 47:2
should still be reasonable in all cases.
>> Even better if there's a convenient place to define the mask such that
>> it can be shared with KVM's existing VTTBR stuff too.
>
> Do you mean VTTBR_BADDR_MASK? I don't think this would be useful there,
> VTTBR_BADDR_MASK checks the alignment of the address that goes into
> VTTBR (not the VTTBR value itself), and takes into account specifically
> the 40-bit IPA and concatenated page tables.
Ah, I see - from skimming the code I managed to assume VTTBR_BADDR_MASK
was a mask for the actual VTTBR.BADDR register field; I hadn't delved
into all the VTTBR_X gubbins (yuck). Fair enough, scratch that idea. At
least TTBR_ASID_MASK[1] gets to have a friend :)
Robin.
[1]
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1555176.html
>
> Kristina
>
>>> +#else
>>> +??? mov??? \ttbr, \phys
>>> +#endif
>>> +??? .endm
>>> +
>>> ? #endif??? /* __ASM_ASSEMBLER_H */
^ permalink raw reply
* [PATCH] ACPI / GED: unregister interrupts during shutdown
From: Sinan Kaya @ 2017-12-07 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2960222.F3CtrQ5k26@aspire.rjw.lan>
Rafael,
On 12/7/2017 8:00 AM, Rafael J. Wysocki wrote:
>> Just don't use devm_request_threaded_irq()? :)
>>
>> Seriously, those are just "helper" functions if your code happens to
>> follow the pattern they provide, if not, then don't use them, it's not
>> that hard to provide the correct code to unwind things properly by "open
>> coding" this logic as needed.
>>
>> The devm_*irq() functions are known for not being able to be used all of
>> the time for lots of shutdown and cleanup issues, this isn't the first
>> time it has happened, which is why we are very careful when taking
>> "cleanup" patches that use those functions.
> I see, thanks for the clarification.
>
> OK, we'll need to rework the driver somewhat, then.
Even if we got rid of devm_*irq() functions, I see that the free_irq() function
requires dev_id argument.
* There can be multiple actions per IRQ descriptor, find the right
* one based on the dev_id:
I still need to keep track of the dev_ids attached to request_irq() functions.
My take away from the discussion is:
1. don't use devm family of functions for IRQ registration/free
2. still keep track of the events
3. call free_irq on shutdown.
Do you have something else on your mind?
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v1 1/6] ARM: davinci: clean up map_io functions
From: Sekhar Nori @ 2017-12-07 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512182054-17410-2-git-send-email-david@lechnology.com>
On Saturday 02 December 2017 08:04 AM, David Lechner wrote:
> This cleans up the map_io functions in the board init files for
> mach-davinci.
>
> Most of the boards had a wrapper function around <board>_init(). This
> wrapper is removed and the function is used directly. Additionally, the
> <board>_init() functions are renamed to <board>_map_io() to match the
> field name.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
> index cb0a41e..f0e2762 100644
> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
> @@ -716,16 +716,6 @@ static void __init evm_init_i2c(void)
> }
> #endif
>
> -#define DM6467T_EVM_REF_FREQ 33000000
> -
> -static void __init davinci_map_io(void)
> -{
> - dm646x_init();
The call to dm646x_init() is dropped here, but I don't see it added
back, at least in this patch.
> diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
> index da21353..b3be5c8 100644
> --- a/arch/arm/mach-davinci/dm646x.c
> +++ b/arch/arm/mach-davinci/dm646x.c
> @@ -17,6 +17,7 @@
> #include <linux/platform_data/edma.h>
> #include <linux/platform_data/gpio-davinci.h>
>
> +#include <asm/mach-types.h>
> #include <asm/mach/map.h>
>
> #include <mach/cputype.h>
> @@ -952,11 +953,16 @@ int __init dm646x_init_edma(struct edma_rsv_info *rsv)
> return IS_ERR(edma_pdev) ? PTR_ERR(edma_pdev) : 0;
> }
>
> -void __init dm646x_init(void)
> +#define DM6467T_EVM_REF_FREQ 33000000
> +
> +void __init dm646x_map_io(void)
> {
> davinci_common_init(&davinci_soc_info_dm646x);
> davinci_map_sysmod();
> davinci_clk_init(davinci_soc_info_dm646x.cpu_clks);
> +
> + if (machine_is_davinci_dm6467tevm())
> + davinci_set_refclk_rate(DM6467T_EVM_REF_FREQ);
> }
I think we should leave the DM646x case out of this since there are
additional issues like introducing these EVM specific defines in a file
meant for SoC.
Is this clean-up a must for you to implement rest of the series (haven't
looked at other patches yet).
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v3 10/20] arm64: assembler: add utility macros to push/pop stack frames
From: Dave Martin @ 2017-12-07 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_82v_L9dZczQZbkmksc1wvOBsa28URP4Q7MEcvAwxhmw@mail.gmail.com>
On Thu, Dec 07, 2017 at 02:21:17PM +0000, Ard Biesheuvel wrote:
> On 7 December 2017 at 14:11, Dave Martin <Dave.Martin@arm.com> wrote:
> > On Wed, Dec 06, 2017 at 07:43:36PM +0000, Ard Biesheuvel wrote:
> >> We are going to add code to all the NEON crypto routines that will
> >> turn them into non-leaf functions, so we need to manage the stack
> >> frames. To make this less tedious and error prone, add some macros
> >> that take the number of callee saved registers to preserve and the
> >> extra size to allocate in the stack frame (for locals) and emit
> >> the ldp/stp sequences.
> >>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> ---
> >> arch/arm64/include/asm/assembler.h | 60 ++++++++++++++++++++
> >> 1 file changed, 60 insertions(+)
> >>
> >> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> >> index aef72d886677..5f61487e9f93 100644
> >> --- a/arch/arm64/include/asm/assembler.h
> >> +++ b/arch/arm64/include/asm/assembler.h
> >> @@ -499,6 +499,66 @@ alternative_else_nop_endif
> >> #endif
> >> .endm
> >>
> >> + /*
> >> + * frame_push - Push @regcount callee saved registers to the stack,
> >> + * starting at x19, as well as x29/x30, and set x29 to
> >> + * the new value of sp. Add @extra bytes of stack space
> >> + * for locals.
> >> + */
> >> + .macro frame_push, regcount:req, extra
> >> + __frame st, \regcount, \extra
> >> + .endm
> >> +
> >> + /*
> >> + * frame_pop - Pop @regcount callee saved registers from the stack,
> >> + * starting at x19, as well as x29/x30. Also pop @extra
> >> + * bytes of stack space for locals.
> >> + */
> >> + .macro frame_pop, regcount:req, extra
> >> + __frame ld, \regcount, \extra
> >> + .endm
> >> +
> >> + .macro __frame, op, regcount:req, extra=0
> >> + .ifc \op, st
> >> + stp x29, x30, [sp, #-((\regcount + 3) / 2) * 16 - \extra]!
> >> + mov x29, sp
> >> + .endif
> >> + .if \regcount < 0 || \regcount > 10
> >> + .error "regcount should be in the range [0 ... 10]"
> >> + .endif
> >> + .if (\extra % 16) != 0
> >> + .error "extra should be a multiple of 16 bytes"
> >> + .endif
> >> + .if \regcount > 1
> >> + \op\()p x19, x20, [sp, #16]
> >> + .if \regcount > 3
> >> + \op\()p x21, x22, [sp, #32]
> >> + .if \regcount > 5
> >> + \op\()p x23, x24, [sp, #48]
> >> + .if \regcount > 7
> >> + \op\()p x25, x26, [sp, #64]
> >> + .if \regcount > 9
> >> + \op\()p x27, x28, [sp, #80]
> >
> > Can the _for thing I introduced in fpsimdmacros.h be any use here?
> > Alternatively, the following could replace that .if-slide,
> > providing the calling macro does .altmacro .. .noaltmacro somewhere.
> >
> > .macro _pushpop2 op, n1, n2, offset
> > \op x\n1, x\n2, [sp, #\offset]
> > .endm
> >
> > .macro _pushpop op, first, last, offset
> > .if \first < \last
> > _pushpop2 \op\()p, \first, %\first + 1, \offset
> > _pushpop \op, %\first + 2, \last, %\offset + 16
> > .elseif \first == \last
> > \op\()r x\first, [sp, #\offset]
> > .endif
> > .endm
> >
>
> I'd prefer not to rely on altmacro, for reasons you pointed out
> yourself a while ago IIRC.
>
> I agree your version is more compact, but for a write once thing, I'm
> not sure if it matters.
>
> > Also, I wonder whether it would be more readable at the call site
> > to specify the first and last reg numbers instead of the reg count,
> > e.g.:
> >
> > frame_push first_reg=19, last_reg=23
> >
> > (or whatever). Just syntactic sugar though.
> >
>
> Again, this will involve arithmetic on macro arguments, which implies
> altmacro. Relying on altmacro being set is dodgy, and unfortunately,
> we can't enable it in the macro without keeping it enabled (or we may
> disable it on behalf of the caller. I guess we could try to come up
> with a smart way to infer whether altmacro was enabled, and only
> disable it afterwards if it wasn't, using some directives that get
> interpreted differently, but to be honest, I factored out this
> sequence so I could think about more important things :-)
Sure, no worries.
I've changed my mind a bit about .altmacro, in that it is not really
usable at all unless turned on explicitly, and then off again, only
where it's needed. So if you just assume it's always off, things are
sane (and that's what happens in practice).
But it's not really needed here -- my main confusion was with the
deeply nested .ifs, but perhaps that could be avoided more
straightforwardly:
.if \regcount > 1
\op\()p x19, x20, [sp, #16]
.endif
.if \regcount > 3
\op\()p x21, x22, [sp, #32]
.endif
// ...
.if \regcount > 9
\op\()p x27, x28, [sp, #80]
.endif
.if \regcount == 1
\op\()r x19, [sp, #20]
.endif
.if \regcount == 3
\op\()r x21, [sp, #22]
.endif
// ...
.if \regcount == 9
\op\()r x27, [sp, #28]
.endif
One other thing, should you be protecting the macro args with ()?
It seems unlikely that an expression would be passed for regcount,
but for extra it's a bit more plausible.
Cheers
---Dave
^ permalink raw reply
* [PATCH] media: s5p-jpeg: Fix off-by-one problem
From: Andrzej Pietrasiewicz @ 2017-12-07 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206163746.8456-1-flavio.ceolin@intel.com>
W dniu 06.12.2017 o?17:37, Flavio Ceolin pisze:
> s5p_jpeg_runtime_resume() does not call clk_disable_unprepare() for
> jpeg->clocks[0] when one of the clk_prepare_enable() fails.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Acked-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
> ---
> drivers/media/platform/s5p-jpeg/jpeg-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index faac816..79b63da 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -3086,7 +3086,7 @@ static int s5p_jpeg_runtime_resume(struct device *dev)
> for (i = 0; i < jpeg->variant->num_clocks; i++) {
> ret = clk_prepare_enable(jpeg->clocks[i]);
> if (ret) {
> - while (--i > 0)
> + while (--i >= 0)
> clk_disable_unprepare(jpeg->clocks[i]);
> return ret;
> }
>
^ permalink raw reply
* [PATCH] arm: dts: qcom: fix missing #phy-cells for apq8064
From: Arnd Bergmann @ 2017-12-07 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a3wupYd7XiJrYsFafbmdpiw_zFVd42E8Ucm9oNXtwzWSQ@mail.gmail.com>
On Thu, Dec 7, 2017 at 3:43 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Nov 9, 2017 at 11:54 PM, Rob Herring <robh@kernel.org> wrote:
>> Fix dtc warnings for missing #phy-cells for apq8064:
>>
>> Warning (phys_property): Missing property '#phy-cells' in node /soc/dsi-phy at 4700200 or bad phandle (referred from /soc/mdss_dsi at 4700000:phys[0])
>> Warning (phys_property): Missing property '#phy-cells' in node /soc/hdmi-phy at 4a00400 or bad phandle (referred from /soc/hdmi-tx at 4a00000:phys[0])
>>
>> Cc: Andy Gross <andy.gross@linaro.org>
>> Cc: David Brown <david.brown@linaro.org>
>> Cc: linux-arm-msm at vger.kernel.org
>> Signed-off-by: Rob Herring <robh@kernel.org>
>
> Applied to fixes, thanks!
This was apparently already there, I took it out again, as applying it
twice resulted in build failure :(
Arnd
^ permalink raw reply
* [PATCH v3 10/20] arm64: assembler: add utility macros to push/pop stack frames
From: Ard Biesheuvel @ 2017-12-07 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207145309.GG22781@e103592.cambridge.arm.com>
On 7 December 2017 at 14:53, Dave Martin <Dave.Martin@arm.com> wrote:
> On Thu, Dec 07, 2017 at 02:21:17PM +0000, Ard Biesheuvel wrote:
>> On 7 December 2017 at 14:11, Dave Martin <Dave.Martin@arm.com> wrote:
>> > On Wed, Dec 06, 2017 at 07:43:36PM +0000, Ard Biesheuvel wrote:
>> >> We are going to add code to all the NEON crypto routines that will
>> >> turn them into non-leaf functions, so we need to manage the stack
>> >> frames. To make this less tedious and error prone, add some macros
>> >> that take the number of callee saved registers to preserve and the
>> >> extra size to allocate in the stack frame (for locals) and emit
>> >> the ldp/stp sequences.
>> >>
>> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> >> ---
>> >> arch/arm64/include/asm/assembler.h | 60 ++++++++++++++++++++
>> >> 1 file changed, 60 insertions(+)
>> >>
>> >> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
>> >> index aef72d886677..5f61487e9f93 100644
>> >> --- a/arch/arm64/include/asm/assembler.h
>> >> +++ b/arch/arm64/include/asm/assembler.h
>> >> @@ -499,6 +499,66 @@ alternative_else_nop_endif
>> >> #endif
>> >> .endm
>> >>
>> >> + /*
>> >> + * frame_push - Push @regcount callee saved registers to the stack,
>> >> + * starting at x19, as well as x29/x30, and set x29 to
>> >> + * the new value of sp. Add @extra bytes of stack space
>> >> + * for locals.
>> >> + */
>> >> + .macro frame_push, regcount:req, extra
>> >> + __frame st, \regcount, \extra
>> >> + .endm
>> >> +
>> >> + /*
>> >> + * frame_pop - Pop @regcount callee saved registers from the stack,
>> >> + * starting at x19, as well as x29/x30. Also pop @extra
>> >> + * bytes of stack space for locals.
>> >> + */
>> >> + .macro frame_pop, regcount:req, extra
>> >> + __frame ld, \regcount, \extra
>> >> + .endm
>> >> +
>> >> + .macro __frame, op, regcount:req, extra=0
>> >> + .ifc \op, st
>> >> + stp x29, x30, [sp, #-((\regcount + 3) / 2) * 16 - \extra]!
>> >> + mov x29, sp
>> >> + .endif
>> >> + .if \regcount < 0 || \regcount > 10
>> >> + .error "regcount should be in the range [0 ... 10]"
>> >> + .endif
>> >> + .if (\extra % 16) != 0
>> >> + .error "extra should be a multiple of 16 bytes"
>> >> + .endif
>> >> + .if \regcount > 1
>> >> + \op\()p x19, x20, [sp, #16]
>> >> + .if \regcount > 3
>> >> + \op\()p x21, x22, [sp, #32]
>> >> + .if \regcount > 5
>> >> + \op\()p x23, x24, [sp, #48]
>> >> + .if \regcount > 7
>> >> + \op\()p x25, x26, [sp, #64]
>> >> + .if \regcount > 9
>> >> + \op\()p x27, x28, [sp, #80]
>> >
>> > Can the _for thing I introduced in fpsimdmacros.h be any use here?
>> > Alternatively, the following could replace that .if-slide,
>> > providing the calling macro does .altmacro .. .noaltmacro somewhere.
>> >
>> > .macro _pushpop2 op, n1, n2, offset
>> > \op x\n1, x\n2, [sp, #\offset]
>> > .endm
>> >
>> > .macro _pushpop op, first, last, offset
>> > .if \first < \last
>> > _pushpop2 \op\()p, \first, %\first + 1, \offset
>> > _pushpop \op, %\first + 2, \last, %\offset + 16
>> > .elseif \first == \last
>> > \op\()r x\first, [sp, #\offset]
>> > .endif
>> > .endm
>> >
>>
>> I'd prefer not to rely on altmacro, for reasons you pointed out
>> yourself a while ago IIRC.
>>
>> I agree your version is more compact, but for a write once thing, I'm
>> not sure if it matters.
>>
>> > Also, I wonder whether it would be more readable at the call site
>> > to specify the first and last reg numbers instead of the reg count,
>> > e.g.:
>> >
>> > frame_push first_reg=19, last_reg=23
>> >
>> > (or whatever). Just syntactic sugar though.
>> >
>>
>> Again, this will involve arithmetic on macro arguments, which implies
>> altmacro. Relying on altmacro being set is dodgy, and unfortunately,
>> we can't enable it in the macro without keeping it enabled (or we may
>> disable it on behalf of the caller. I guess we could try to come up
>> with a smart way to infer whether altmacro was enabled, and only
>> disable it afterwards if it wasn't, using some directives that get
>> interpreted differently, but to be honest, I factored out this
>> sequence so I could think about more important things :-)
>
> Sure, no worries.
>
> I've changed my mind a bit about .altmacro, in that it is not really
> usable at all unless turned on explicitly, and then off again, only
> where it's needed. So if you just assume it's always off, things are
> sane (and that's what happens in practice).
>
> But it's not really needed here -- my main confusion was with the
> deeply nested .ifs, but perhaps that could be avoided more
> straightforwardly:
>
> .if \regcount > 1
> \op\()p x19, x20, [sp, #16]
> .endif
> .if \regcount > 3
> \op\()p x21, x22, [sp, #32]
> .endif
> // ...
> .if \regcount > 9
> \op\()p x27, x28, [sp, #80]
> .endif
>
> .if \regcount == 1
> \op\()r x19, [sp, #20]
> .endif
> .if \regcount == 3
> \op\()r x21, [sp, #22]
> .endif
> // ...
> .if \regcount == 9
> \op\()r x27, [sp, #28]
> .endif
>
Yes, that does look better.
>
> One other thing, should you be protecting the macro args with ()?
>
> It seems unlikely that an expression would be passed for regcount,
> but for extra it's a bit more plausible.
>
Good point, given that I subtract \extra from the frame size in the ldp case.
> Cheers
> ---Dave
^ permalink raw reply
* [PATCH] ARM: dts: imx6: RDU2: correct RTC compatible
From: Lucas Stach @ 2017-12-07 15:09 UTC (permalink / raw)
To: linux-arm-kernel
The RTC is manufactured by Maxim. This is a cosmetic fix, as Linux
doesn't match the vendor string for i2c devices.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index eef737bd52d9..6bef9a98678e 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -581,7 +581,7 @@
};
ds1341: rtc at 68 {
- compatible = "dallas,ds1341";
+ compatible = "maxim,ds1341";
reg = <0x68>;
};
};
--
2.11.0
^ permalink raw reply related
* [PATCH 0/6] arm64: compat: Add COMPAT_VDSO
From: Mark Salyzyn @ 2017-12-07 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171115220529.14458-1-salyzyn@android.com>
On 11/15/2017 02:05 PM, Mark Salyzyn wrote:
> Add compatible vDSO32 support to arm64, provide the files necessary
> for building a compat (AArch32) vDSO in arch/arm64/kernel/vdso32.
>
> Leverages effort to unify the vgettimeofday.c file as outlined below.
>
> To be applied over top the following pending patches:
>
> [PATCH] arm64: compat: Remove leftover variable declaration
> NB: approved, in arch64/for-next/core
> [PATCH v3 1/3] arm64: compat: Split the sigreturn trampolines and kuser helpers (C sources)
> [PATCH v3 2/3] arm64: compat: Split the sigreturn trampolines and kuser helpers (assembler sources)
> [PATCH v3 3/3] arm64: compat: Add CONFIG_KUSER_HELPERS
> [PATCH] arm64: compat: Expose offset to registers in sigframes
> [PATCH v5 01/12] arm: vdso: rename vdso_datapage variables
> [PATCH v5 02/12] arm: vdso: add include file defining __get_datapage()
> [PATCH v5 03/12] arm: vdso: inline assembler operations to compiler.h
> [PATCH v5 04/12] arm: vdso: do calculations outside reader loops
> [PATCH v6 05/12] arm: vdso: Add support for CLOCK_MONOTONIC_RAW
> [PATCH v5 06/12] arm: vdso: add support for clock_getres
> [PATCH v5 07/12] arm: vdso: disable profiling
> [PATCH v5 08/12] arm: vdso: Add ARCH_CLOCK_FIXED_MASK
> [PATCH v5 09/12] arm: vdso: move vgettimeofday.c to lib/vdso/
> [PATCH v5 10/12] arm64: vdso: replace gettimeofday.S with global vgettimeofday.C
> [PATCH v5 11/12] lib: vdso: Add support for CLOCK_BOOTTIME
> [PATCH v5 12/12] lib: vdso: do not expose gettimeofday, if no arch supported timer
> [PATCH] lib: vdso: add support for time
>
> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Dave Martin <Dave.Martin@arm.com>
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
Any action for me to take?
-- Mark
^ permalink raw reply
* [PATCH v2 00/10] arm64: dts: qcom: dts improvements
From: Damien Riegel @ 2017-12-07 15:19 UTC (permalink / raw)
To: linux-arm-kernel
The goal of this series was to add missing I2C bindings for BLSP_I2C1,
BLSP_I2C3, and BLSP_I2C5. But while working on this, I noticed some
styling issues and decided to tackle them in the same patchset, mostly
because they touch the same files and the same people will be involved
for the review.
In this second version, I followed the recommandation of Bjorn Andersson
and splitted pinmuxing and pinconf. The reason behind that is that the
pinmuxing is common as functions cannot be routed to other pins, but
pinconfs are board-specific.
Damien Riegel (10):
arm64: dts: qcom: pm8916: fix wcd_codec indentation
arm64: dts: qcom: msm8916-pins: remove assignments to bias-disable
arm64: dts: qcom: msm8916-pins: keep cdc_dmic pins in suspend mode
arm64: dts: qcom: msm8916: drop unused board-specific nodes
arm64: dts: qcom: apq8016-sbc: sort nodes alphabetically
arm64: dts: qcom: msm8916: move pinconfs to board files
arm64: dts: qcom: msm8916: drop remaining unused pinconfs
arm64: dts: qcom: msm8916-pins: move sdhc2 cd node with its siblings
arm64: dts: qcom: msm8916: normalize I2C and SPI nodes
arm64: dts: qcom: msm8916: add nodes for i2c1, i2c3, i2c5
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 446 ++++++++++++++++++++++++++++-
arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi | 17 ++
arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 393 ++++---------------------
arch/arm64/boot/dts/qcom/msm8916.dtsi | 69 ++++-
arch/arm64/boot/dts/qcom/pm8916.dtsi | 82 +++---
5 files changed, 604 insertions(+), 403 deletions(-)
--
2.15.0
^ permalink raw reply
* [PATCH v2 01/10] arm64: dts: qcom: pm8916: fix wcd_codec indentation
From: Damien Riegel @ 2017-12-07 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-1-damien.riegel@savoirfairelinux.com>
Indentation did not respect kernel standards, so fix that for the usual
indent with tabs, align with spaces. While at it, remove some empty
lines before and after the closing parenthesis of this block.
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes in v2:
- Added Reviewed-by Bjorn Andersson
arch/arm64/boot/dts/qcom/pm8916.dtsi | 82 ++++++++++++++++++------------------
1 file changed, 40 insertions(+), 42 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/pm8916.dtsi b/arch/arm64/boot/dts/qcom/pm8916.dtsi
index 53deebf9f515..d19f4cb9a5f3 100644
--- a/arch/arm64/boot/dts/qcom/pm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8916.dtsi
@@ -96,47 +96,45 @@
#address-cells = <1>;
#size-cells = <0>;
- wcd_codec: codec at f000 {
- compatible = "qcom,pm8916-wcd-analog-codec";
- reg = <0xf000 0x200>;
- reg-names = "pmic-codec-core";
- clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>;
- clock-names = "mclk";
- interrupt-parent = <&spmi_bus>;
- interrupts = <0x1 0xf0 0x0 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x1 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x2 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x3 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x4 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x5 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x6 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x7 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x0 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x1 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x2 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x3 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x4 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x5 IRQ_TYPE_NONE>;
- interrupt-names = "cdc_spk_cnp_int",
- "cdc_spk_clip_int",
- "cdc_spk_ocp_int",
- "mbhc_ins_rem_det1",
- "mbhc_but_rel_det",
- "mbhc_but_press_det",
- "mbhc_ins_rem_det",
- "mbhc_switch_int",
- "cdc_ear_ocp_int",
- "cdc_hphr_ocp_int",
- "cdc_hphl_ocp_det",
- "cdc_ear_cnp_int",
- "cdc_hphr_cnp_int",
- "cdc_hphl_cnp_int";
- vdd-cdc-io-supply = <&pm8916_l5>;
- vdd-cdc-tx-rx-cx-supply = <&pm8916_l5>;
- vdd-micbias-supply = <&pm8916_l13>;
- #sound-dai-cells = <1>;
-
- };
-
+ wcd_codec: codec at f000 {
+ compatible = "qcom,pm8916-wcd-analog-codec";
+ reg = <0xf000 0x200>;
+ reg-names = "pmic-codec-core";
+ clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>;
+ clock-names = "mclk";
+ interrupt-parent = <&spmi_bus>;
+ interrupts = <0x1 0xf0 0x0 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x1 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x2 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x3 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x4 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x5 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x6 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x7 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x0 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x1 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x2 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x3 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x4 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x5 IRQ_TYPE_NONE>;
+ interrupt-names = "cdc_spk_cnp_int",
+ "cdc_spk_clip_int",
+ "cdc_spk_ocp_int",
+ "mbhc_ins_rem_det1",
+ "mbhc_but_rel_det",
+ "mbhc_but_press_det",
+ "mbhc_ins_rem_det",
+ "mbhc_switch_int",
+ "cdc_ear_ocp_int",
+ "cdc_hphr_ocp_int",
+ "cdc_hphl_ocp_det",
+ "cdc_ear_cnp_int",
+ "cdc_hphr_cnp_int",
+ "cdc_hphl_cnp_int";
+ vdd-cdc-io-supply = <&pm8916_l5>;
+ vdd-cdc-tx-rx-cx-supply = <&pm8916_l5>;
+ vdd-micbias-supply = <&pm8916_l13>;
+ #sound-dai-cells = <1>;
+ };
};
};
--
2.15.0
^ permalink raw reply related
* [PATCH v2 02/10] arm64: dts: qcom: msm8916-pins: remove assignments to bias-disable
From: Damien Riegel @ 2017-12-07 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-1-damien.riegel@savoirfairelinux.com>
Drop assignments to bias-disable as the documentation [1] states that
this property doesn't take a value. Other occurrences of this property
respect that.
[1] Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes in v2:
- Added Reviewed-by Bjorn Andersson
arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index 4cb0b5834143..c67ad8ed8b60 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -278,7 +278,7 @@
pinconf {
pins = "gpio6", "gpio7";
drive-strength = <16>;
- bias-disable = <0>;
+ bias-disable;
};
};
@@ -290,7 +290,7 @@
pinconf {
pins = "gpio6", "gpio7";
drive-strength = <2>;
- bias-disable = <0>;
+ bias-disable;
};
};
@@ -302,7 +302,7 @@
pinconf {
pins = "gpio14", "gpio15";
drive-strength = <16>;
- bias-disable = <0>;
+ bias-disable;
};
};
@@ -314,7 +314,7 @@
pinconf {
pins = "gpio14", "gpio15";
drive-strength = <2>;
- bias-disable = <0>;
+ bias-disable;
};
};
@@ -326,7 +326,7 @@
pinconf {
pins = "gpio22", "gpio23";
drive-strength = <16>;
- bias-disable = <0>;
+ bias-disable;
};
};
@@ -338,7 +338,7 @@
pinconf {
pins = "gpio22", "gpio23";
drive-strength = <2>;
- bias-disable = <0>;
+ bias-disable;
};
};
--
2.15.0
^ permalink raw reply related
* [PATCH v2 03/10] arm64: dts: qcom: msm8916-pins: keep cdc_dmic pins in suspend mode
From: Damien Riegel @ 2017-12-07 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-1-damien.riegel@savoirfairelinux.com>
This node was the only one that didn't have the same set of pins in
active and suspend mode.
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
---
arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index c67ad8ed8b60..10fc1fc90682 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -687,6 +687,14 @@
};
};
cdc_dmic_lines_sus: dmic_lines_off {
+ pinmux_dmic0_clk {
+ function = "dmic0_clk";
+ pins = "gpio0";
+ };
+ pinmux_dmic0_data {
+ function = "dmic0_data";
+ pins = "gpio1";
+ };
pinconf {
pins = "gpio0", "gpio1";
drive-strength = <2>;
--
2.15.0
^ permalink raw reply related
* [PATCH v2 04/10] arm64: dts: qcom: msm8916: drop unused board-specific nodes
From: Damien Riegel @ 2017-12-07 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-1-damien.riegel@savoirfairelinux.com>
These nodes reserve and configure some pins as GPIOs. They are not
generic pinctrls, they actually belong to board files but they are not
used by any other node, so just drop them altogether.
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
---
arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 52 ------------------------------
1 file changed, 52 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index 10fc1fc90682..21f144c55638 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -505,32 +505,6 @@
};
};
- ext-codec-lines {
- ext_codec_lines_act: lines_on {
- pinmux {
- function = "gpio";
- pins = "gpio67";
- };
- pinconf {
- pins = "gpio67";
- drive-strength = <8>;
- bias-disable;
- output-high;
- };
- };
- ext_codec_lines_sus: lines_off {
- pinmux {
- function = "gpio";
- pins = "gpio67";
- };
- pinconf {
- pins = "gpio67";
- drive-strength = <2>;
- bias-disable;
- };
- };
- };
-
cdc-pdm-lines {
cdc_pdm_lines_act: pdm_lines_on {
pinmux {
@@ -703,32 +677,6 @@
};
};
- cross-conn-det {
- cross_conn_det_act: lines_on {
- pinmux {
- function = "gpio";
- pins = "gpio120";
- };
- pinconf {
- pins = "gpio120";
- drive-strength = <8>;
- output-low;
- bias-pull-down;
- };
- };
- cross_conn_det_sus: lines_off {
- pinmux {
- function = "gpio";
- pins = "gpio120";
- };
- pinconf {
- pins = "gpio120";
- drive-strength = <2>;
- bias-disable;
- };
- };
- };
-
wcnss_pin_a: wcnss-active {
pinmux {
pins = "gpio40", "gpio41", "gpio42", "gpio43", "gpio44";
--
2.15.0
^ permalink raw reply related
* [PATCH v2 05/10] arm64: dts: qcom: apq8016-sbc: sort nodes alphabetically
From: Damien Riegel @ 2017-12-07 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-1-damien.riegel@savoirfairelinux.com>
Also, it was using whitespaces for indentation on some lines, fix that
while moving it.
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index d4b35d81a282..981450f50e10 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -544,14 +544,6 @@
};
};
-&wcd_codec {
- status = "okay";
- clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>;
- clock-names = "mclk";
- qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
- qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
-};
-
&smd_rpm_regulators {
vdd_l1_l2_l3-supply = <&pm8916_s3>;
vdd_l5-supply = <&pm8916_s3>;
@@ -671,3 +663,11 @@
regulator-max-microvolt = <3337000>;
};
};
+
+&wcd_codec {
+ status = "okay";
+ clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>;
+ clock-names = "mclk";
+ qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
+ qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
+};
--
2.15.0
^ permalink raw reply related
* [PATCH v2 06/10] arm64: dts: qcom: msm8916: move pinconfs to board files
From: Damien Riegel @ 2017-12-07 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-1-damien.riegel@savoirfairelinux.com>
Following a suggestion from Bjorn Andersson [1], this commit moves
electrical specifications which were defined in mms8916-pins.dtsi to
board files, where they actually belong.
Pinmuxing is kept in the platform file because there are no alternative
pins on which all these functions could be routed, so this part is
indeed common to all boards using this SoC.
[1] https://www.spinics.net/lists/devicetree/msg201764.html
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Suggested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 386 +++++++++++++++++++++++++++++
arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi | 17 ++
arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 258 -------------------
3 files changed, 403 insertions(+), 258 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 981450f50e10..53c1ddd281a4 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -544,6 +544,384 @@
};
};
+&blsp1_uart1_default {
+ pinconf {
+ pins = "gpio0", "gpio1",
+ "gpio2", "gpio3";
+ drive-strength = <16>;
+ bias-disable;
+ };
+};
+
+&blsp1_uart1_sleep {
+ pinconf {
+ pins = "gpio0", "gpio1",
+ "gpio2", "gpio3";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+};
+
+&blsp1_uart2_default {
+ pinconf {
+ pins = "gpio4", "gpio5";
+ drive-strength = <16>;
+ bias-disable;
+ };
+};
+
+&blsp1_uart2_sleep {
+ pinconf {
+ pins = "gpio4", "gpio5";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+};
+
+&cdc_pdm_lines_act {
+ pinconf {
+ pins = "gpio63", "gpio64", "gpio65", "gpio66",
+ "gpio67", "gpio68";
+ drive-strength = <8>;
+ bias-pull-none;
+ };
+};
+
+&cdc_pdm_lines_sus {
+ pinconf {
+ pins = "gpio63", "gpio64", "gpio65", "gpio66",
+ "gpio67", "gpio68";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
+
+&ext_mclk_tlmm_lines_act {
+ pinconf {
+ pins = "gpio116";
+ drive-strength = <8>;
+ bias-pull-none;
+ };
+};
+
+&ext_mclk_tlmm_lines_sus {
+ pinconf {
+ pins = "gpio116";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
+
+&ext_sec_tlmm_lines_act {
+ pinconf {
+ pins = "gpio112", "gpio117", "gpio118",
+ "gpio119";
+ drive-strength = <8>;
+ bias-pull-none;
+ };
+};
+
+&ext_sec_tlmm_lines_sus {
+ pinconf {
+ pins = "gpio112", "gpio117", "gpio118",
+ "gpio119";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
+
+&i2c2_default {
+ pinconf {
+ pins = "gpio6", "gpio7";
+ drive-strength = <16>;
+ bias-disable;
+ };
+};
+
+&i2c2_sleep {
+ pinconf {
+ pins = "gpio6", "gpio7";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
+
+&i2c4_default {
+ pinconf {
+ pins = "gpio14", "gpio15";
+ drive-strength = <16>;
+ bias-disable;
+ };
+};
+
+&i2c4_sleep {
+ pinconf {
+ pins = "gpio14", "gpio15";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
+
+&i2c6_default {
+ pinconf {
+ pins = "gpio22", "gpio23";
+ drive-strength = <16>;
+ bias-disable;
+ };
+};
+
+&i2c6_sleep {
+ pinconf {
+ pins = "gpio22", "gpio23";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
+
+&sdc1_clk_on {
+ pinconf {
+ pins = "sdc1_clk";
+ bias-disable;
+ drive-strength = <16>;
+ };
+};
+
+&sdc1_clk_off {
+ pinconf {
+ pins = "sdc1_clk";
+ bias-disable;
+ drive-strength = <2>;
+ };
+};
+
+&sdc1_cmd_on {
+ pinconf {
+ pins = "sdc1_cmd";
+ bias-pull-up;
+ drive-strength = <10>;
+ };
+};
+
+&sdc1_cmd_off {
+ pinconf {
+ pins = "sdc1_cmd";
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+};
+
+&sdc1_data_on {
+ pinconf {
+ pins = "sdc1_data";
+ bias-pull-up;
+ drive-strength = <10>;
+ };
+};
+
+&sdc1_data_off {
+ pinconf {
+ pins = "sdc1_data";
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+};
+
+&sdc2_clk_on {
+ pinconf {
+ pins = "sdc2_clk";
+ bias-disable;
+ drive-strength = <16>;
+ };
+};
+
+&sdc2_clk_off {
+ pinconf {
+ pins = "sdc2_clk";
+ bias-disable;
+ drive-strength = <2>;
+ };
+};
+
+&sdc2_cmd_on {
+ pinconf {
+ pins = "sdc2_cmd";
+ bias-pull-up;
+ drive-strength = <10>;
+ };
+};
+
+&sdc2_cmd_off {
+ pinconf {
+ pins = "sdc2_cmd";
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+};
+
+&sdc2_data_on {
+ pinconf {
+ pins = "sdc2_data";
+ bias-pull-up;
+ drive-strength = <10>;
+ };
+};
+
+&sdc2_data_off {
+ pinconf {
+ pins = "sdc2_data";
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+};
+
+&sdc2_cd_on {
+ pinconf {
+ pins = "gpio38";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+};
+
+&sdc2_cd_off {
+ pinconf {
+ pins = "gpio38";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
+
+&spi1_default {
+ pinconf {
+ pins = "gpio0", "gpio1", "gpio3";
+ drive-strength = <12>;
+ bias-disable;
+ };
+ pinconf_cs {
+ pins = "gpio2";
+ drive-strength = <16>;
+ bias-disable;
+ output-high;
+ };
+};
+
+&spi1_sleep {
+ pinconf {
+ pins = "gpio0", "gpio1", "gpio2", "gpio3";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+};
+
+&spi2_default {
+ pinconf {
+ pins = "gpio4", "gpio5", "gpio7";
+ drive-strength = <12>;
+ bias-disable;
+ };
+ pinconf_cs {
+ pins = "gpio6";
+ drive-strength = <16>;
+ bias-disable;
+ output-high;
+ };
+};
+
+&spi2_sleep {
+ pinconf {
+ pins = "gpio4", "gpio5", "gpio6", "gpio7";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+};
+
+&spi3_default {
+ pinconf {
+ pins = "gpio8", "gpio9", "gpio11";
+ drive-strength = <12>;
+ bias-disable;
+ };
+ pinconf_cs {
+ pins = "gpio10";
+ drive-strength = <16>;
+ bias-disable;
+ output-high;
+ };
+};
+
+&spi3_sleep {
+ pinconf {
+ pins = "gpio8", "gpio9", "gpio10", "gpio11";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+};
+
+&spi4_default {
+ pinconf {
+ pins = "gpio12", "gpio13", "gpio15";
+ drive-strength = <12>;
+ bias-disable;
+ };
+ pinconf_cs {
+ pins = "gpio14";
+ drive-strength = <16>;
+ bias-disable;
+ output-high;
+ };
+};
+
+&spi4_sleep {
+ pinconf {
+ pins = "gpio12", "gpio13", "gpio14", "gpio15";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+};
+
+&spi5_default {
+ pinconf {
+ pins = "gpio16", "gpio17", "gpio19";
+ drive-strength = <12>;
+ bias-disable;
+ };
+ pinconf_cs {
+ pins = "gpio18";
+ drive-strength = <16>;
+ bias-disable;
+ output-high;
+ };
+};
+
+&spi5_sleep {
+ pinconf {
+ pins = "gpio16", "gpio17", "gpio18", "gpio19";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+};
+
+&spi6_default {
+ pinconf {
+ pins = "gpio20", "gpio21", "gpio23";
+ drive-strength = <12>;
+ bias-disable;
+ };
+ pinconf_cs {
+ pins = "gpio22";
+ drive-strength = <16>;
+ bias-disable;
+ output-high;
+ };
+};
+
+&spi6_sleep {
+ pinconf {
+ pins = "gpio20", "gpio21", "gpio22", "gpio23";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+};
+
&smd_rpm_regulators {
vdd_l1_l2_l3-supply = <&pm8916_s3>;
vdd_l5-supply = <&pm8916_s3>;
@@ -671,3 +1049,11 @@
qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
};
+
+&wcnss_pin_a {
+ pinconf {
+ pins = "gpio40", "gpio41", "gpio42", "gpio43", "gpio44";
+ drive-strength = <6>;
+ bias-pull-up;
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi b/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
index ceeb8a6feed6..9f15148f8a03 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
@@ -33,3 +33,20 @@
};
};
};
+
+&blsp1_uart2_default {
+ pinconf {
+ pins = "gpio4", "gpio5";
+ drive-strength = <16>;
+ bias-disable;
+ };
+};
+
+&blsp1_uart2_sleep {
+ pinconf {
+ pins = "gpio4", "gpio5";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+};
+
diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index 21f144c55638..0790232c4654 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -20,12 +20,6 @@
pins = "gpio0", "gpio1",
"gpio2", "gpio3";
};
- pinconf {
- pins = "gpio0", "gpio1",
- "gpio2", "gpio3";
- drive-strength = <16>;
- bias-disable;
- };
};
blsp1_uart1_sleep: blsp1_uart1_sleep {
@@ -34,12 +28,6 @@
pins = "gpio0", "gpio1",
"gpio2", "gpio3";
};
- pinconf {
- pins = "gpio0", "gpio1",
- "gpio2", "gpio3";
- drive-strength = <2>;
- bias-pull-down;
- };
};
blsp1_uart2_default: blsp1_uart2_default {
@@ -47,11 +35,6 @@
function = "blsp_uart2";
pins = "gpio4", "gpio5";
};
- pinconf {
- pins = "gpio4", "gpio5";
- drive-strength = <16>;
- bias-disable;
- };
};
blsp1_uart2_sleep: blsp1_uart2_sleep {
@@ -59,11 +42,6 @@
function = "gpio";
pins = "gpio4", "gpio5";
};
- pinconf {
- pins = "gpio4", "gpio5";
- drive-strength = <2>;
- bias-pull-down;
- };
};
spi1_default: spi1_default {
@@ -75,17 +53,6 @@
function = "gpio";
pins = "gpio2";
};
- pinconf {
- pins = "gpio0", "gpio1", "gpio3";
- drive-strength = <12>;
- bias-disable;
- };
- pinconf_cs {
- pins = "gpio2";
- drive-strength = <16>;
- bias-disable;
- output-high;
- };
};
spi1_sleep: spi1_sleep {
@@ -93,11 +60,6 @@
function = "gpio";
pins = "gpio0", "gpio1", "gpio2", "gpio3";
};
- pinconf {
- pins = "gpio0", "gpio1", "gpio2", "gpio3";
- drive-strength = <2>;
- bias-pull-down;
- };
};
spi2_default: spi2_default {
@@ -109,17 +71,6 @@
function = "gpio";
pins = "gpio6";
};
- pinconf {
- pins = "gpio4", "gpio5", "gpio7";
- drive-strength = <12>;
- bias-disable;
- };
- pinconf_cs {
- pins = "gpio6";
- drive-strength = <16>;
- bias-disable;
- output-high;
- };
};
spi2_sleep: spi2_sleep {
@@ -127,11 +78,6 @@
function = "gpio";
pins = "gpio4", "gpio5", "gpio6", "gpio7";
};
- pinconf {
- pins = "gpio4", "gpio5", "gpio6", "gpio7";
- drive-strength = <2>;
- bias-pull-down;
- };
};
spi3_default: spi3_default {
@@ -143,17 +89,6 @@
function = "gpio";
pins = "gpio10";
};
- pinconf {
- pins = "gpio8", "gpio9", "gpio11";
- drive-strength = <12>;
- bias-disable;
- };
- pinconf_cs {
- pins = "gpio10";
- drive-strength = <16>;
- bias-disable;
- output-high;
- };
};
spi3_sleep: spi3_sleep {
@@ -161,11 +96,6 @@
function = "gpio";
pins = "gpio8", "gpio9", "gpio10", "gpio11";
};
- pinconf {
- pins = "gpio8", "gpio9", "gpio10", "gpio11";
- drive-strength = <2>;
- bias-pull-down;
- };
};
spi4_default: spi4_default {
@@ -177,17 +107,6 @@
function = "gpio";
pins = "gpio14";
};
- pinconf {
- pins = "gpio12", "gpio13", "gpio15";
- drive-strength = <12>;
- bias-disable;
- };
- pinconf_cs {
- pins = "gpio14";
- drive-strength = <16>;
- bias-disable;
- output-high;
- };
};
spi4_sleep: spi4_sleep {
@@ -195,11 +114,6 @@
function = "gpio";
pins = "gpio12", "gpio13", "gpio14", "gpio15";
};
- pinconf {
- pins = "gpio12", "gpio13", "gpio14", "gpio15";
- drive-strength = <2>;
- bias-pull-down;
- };
};
spi5_default: spi5_default {
@@ -211,17 +125,6 @@
function = "gpio";
pins = "gpio18";
};
- pinconf {
- pins = "gpio16", "gpio17", "gpio19";
- drive-strength = <12>;
- bias-disable;
- };
- pinconf_cs {
- pins = "gpio18";
- drive-strength = <16>;
- bias-disable;
- output-high;
- };
};
spi5_sleep: spi5_sleep {
@@ -229,11 +132,6 @@
function = "gpio";
pins = "gpio16", "gpio17", "gpio18", "gpio19";
};
- pinconf {
- pins = "gpio16", "gpio17", "gpio18", "gpio19";
- drive-strength = <2>;
- bias-pull-down;
- };
};
spi6_default: spi6_default {
@@ -245,17 +143,6 @@
function = "gpio";
pins = "gpio22";
};
- pinconf {
- pins = "gpio20", "gpio21", "gpio23";
- drive-strength = <12>;
- bias-disable;
- };
- pinconf_cs {
- pins = "gpio22";
- drive-strength = <16>;
- bias-disable;
- output-high;
- };
};
spi6_sleep: spi6_sleep {
@@ -263,11 +150,6 @@
function = "gpio";
pins = "gpio20", "gpio21", "gpio22", "gpio23";
};
- pinconf {
- pins = "gpio20", "gpio21", "gpio22", "gpio23";
- drive-strength = <2>;
- bias-pull-down;
- };
};
i2c2_default: i2c2_default {
@@ -275,11 +157,6 @@
function = "blsp_i2c2";
pins = "gpio6", "gpio7";
};
- pinconf {
- pins = "gpio6", "gpio7";
- drive-strength = <16>;
- bias-disable;
- };
};
i2c2_sleep: i2c2_sleep {
@@ -287,11 +164,6 @@
function = "gpio";
pins = "gpio6", "gpio7";
};
- pinconf {
- pins = "gpio6", "gpio7";
- drive-strength = <2>;
- bias-disable;
- };
};
i2c4_default: i2c4_default {
@@ -299,11 +171,6 @@
function = "blsp_i2c4";
pins = "gpio14", "gpio15";
};
- pinconf {
- pins = "gpio14", "gpio15";
- drive-strength = <16>;
- bias-disable;
- };
};
i2c4_sleep: i2c4_sleep {
@@ -311,11 +178,6 @@
function = "gpio";
pins = "gpio14", "gpio15";
};
- pinconf {
- pins = "gpio14", "gpio15";
- drive-strength = <2>;
- bias-disable;
- };
};
i2c6_default: i2c6_default {
@@ -323,11 +185,6 @@
function = "blsp_i2c6";
pins = "gpio22", "gpio23";
};
- pinconf {
- pins = "gpio22", "gpio23";
- drive-strength = <16>;
- bias-disable;
- };
};
i2c6_sleep: i2c6_sleep {
@@ -335,11 +192,6 @@
function = "gpio";
pins = "gpio22", "gpio23";
};
- pinconf {
- pins = "gpio22", "gpio23";
- drive-strength = <2>;
- bias-disable;
- };
};
sdhc2_cd_pin {
@@ -348,22 +200,12 @@
function = "gpio";
pins = "gpio38";
};
- pinconf {
- pins = "gpio38";
- drive-strength = <2>;
- bias-pull-up;
- };
};
sdc2_cd_off: cd_off {
pinmux {
function = "gpio";
pins = "gpio38";
};
- pinconf {
- pins = "gpio38";
- drive-strength = <2>;
- bias-disable;
- };
};
};
@@ -372,21 +214,11 @@
pinmux {
pins = "sdc1_clk";
};
- pinconf {
- pins = "sdc1_clk";
- bias-disable;
- drive-strength = <16>;
- };
};
sdc1_clk_off: clk_off {
pinmux {
pins = "sdc1_clk";
};
- pinconf {
- pins = "sdc1_clk";
- bias-disable;
- drive-strength = <2>;
- };
};
};
@@ -395,21 +227,11 @@
pinmux {
pins = "sdc1_cmd";
};
- pinconf {
- pins = "sdc1_cmd";
- bias-pull-up;
- drive-strength = <10>;
- };
};
sdc1_cmd_off: cmd_off {
pinmux {
pins = "sdc1_cmd";
};
- pinconf {
- pins = "sdc1_cmd";
- bias-pull-up;
- drive-strength = <2>;
- };
};
};
@@ -418,21 +240,11 @@
pinmux {
pins = "sdc1_data";
};
- pinconf {
- pins = "sdc1_data";
- bias-pull-up;
- drive-strength = <10>;
- };
};
sdc1_data_off: data_off {
pinmux {
pins = "sdc1_data";
};
- pinconf {
- pins = "sdc1_data";
- bias-pull-up;
- drive-strength = <2>;
- };
};
};
@@ -441,21 +253,11 @@
pinmux {
pins = "sdc2_clk";
};
- pinconf {
- pins = "sdc2_clk";
- bias-disable;
- drive-strength = <16>;
- };
};
sdc2_clk_off: clk_off {
pinmux {
pins = "sdc2_clk";
};
- pinconf {
- pins = "sdc2_clk";
- bias-disable;
- drive-strength = <2>;
- };
};
};
@@ -464,21 +266,11 @@
pinmux {
pins = "sdc2_cmd";
};
- pinconf {
- pins = "sdc2_cmd";
- bias-pull-up;
- drive-strength = <10>;
- };
};
sdc2_cmd_off: cmd_off {
pinmux {
pins = "sdc2_cmd";
};
- pinconf {
- pins = "sdc2_cmd";
- bias-pull-up;
- drive-strength = <2>;
- };
};
};
@@ -487,21 +279,11 @@
pinmux {
pins = "sdc2_data";
};
- pinconf {
- pins = "sdc2_data";
- bias-pull-up;
- drive-strength = <10>;
- };
};
sdc2_data_off: data_off {
pinmux {
pins = "sdc2_data";
};
- pinconf {
- pins = "sdc2_data";
- bias-pull-up;
- drive-strength = <2>;
- };
};
};
@@ -512,12 +294,6 @@
pins = "gpio63", "gpio64", "gpio65", "gpio66",
"gpio67", "gpio68";
};
- pinconf {
- pins = "gpio63", "gpio64", "gpio65", "gpio66",
- "gpio67", "gpio68";
- drive-strength = <8>;
- bias-pull-none;
- };
};
cdc_pdm_lines_sus: pdm_lines_off {
pinmux {
@@ -525,12 +301,6 @@
pins = "gpio63", "gpio64", "gpio65", "gpio66",
"gpio67", "gpio68";
};
- pinconf {
- pins = "gpio63", "gpio64", "gpio65", "gpio66",
- "gpio67", "gpio68";
- drive-strength = <2>;
- bias-disable;
- };
};
};
@@ -596,22 +366,12 @@
function = "pri_mi2s";
pins = "gpio116";
};
- pinconf {
- pins = "gpio116";
- drive-strength = <8>;
- bias-pull-none;
- };
};
ext_mclk_tlmm_lines_sus: mclk_lines_off {
pinmux {
function = "pri_mi2s";
pins = "gpio116";
};
- pinconf {
- pins = "gpio116";
- drive-strength = <2>;
- bias-disable;
- };
};
};
@@ -623,12 +383,6 @@
pins = "gpio112", "gpio117", "gpio118",
"gpio119";
};
- pinconf {
- pins = "gpio112", "gpio117", "gpio118",
- "gpio119";
- drive-strength = <8>;
- bias-pull-none;
- };
};
ext_sec_tlmm_lines_sus: tlmm_lines_off {
pinmux {
@@ -636,12 +390,6 @@
pins = "gpio112", "gpio117", "gpio118",
"gpio119";
};
- pinconf {
- pins = "gpio112", "gpio117", "gpio118",
- "gpio119";
- drive-strength = <2>;
- bias-disable;
- };
};
};
@@ -682,11 +430,5 @@
pins = "gpio40", "gpio41", "gpio42", "gpio43", "gpio44";
function = "wcss_wlan";
};
-
- pinconf {
- pins = "gpio40", "gpio41", "gpio42", "gpio43", "gpio44";
- drive-strength = <6>;
- bias-pull-up;
- };
};
};
--
2.15.0
^ permalink raw reply related
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