* [PATCH] arm64: mmu: set the contiguous for kernel mappings when appropriate
From: Ard Biesheuvel @ 2016-10-11 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-e6HT2YNvXJV2AbAzLrEeV6OvM6-hfTsCH0oXqH8zbKQ@mail.gmail.com>
On 11 October 2016 at 10:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 11 October 2016 at 09:48, Steve Capper <steve.capper@linaro.org> wrote:
>>
>>
>> On 11 October 2016 at 08:44, Mark Rutland <mark.rutland@arm.com> wrote:
>>>
>>> Hi Ard,
>>>
>>> On Mon, Oct 10, 2016 at 07:12:44PM +0100, Ard Biesheuvel wrote:
>>> > Now that we no longer allow live kernel PMDs to be split, it is safe to
>>> > start using the contiguous bit for kernel mappings. So set the
>>> > contiguous
>>> > bit in the kernel page mappings for regions whose size and alignment are
>>> > suitable for this.
>>> >
>>> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>>
>>> Given the splitting is now gone, using the contiguous bit makes sense to
>>> me.
>>>
>>> With 16K pages, we can have contiguous PMD entries. Should we handle
>>> those,
>>> too? e.g. have separate {PMD,PTE}_CONT{,_SIZE}?
>>>
>>> Otherwise, I have some comments below.
>>
>>
>> Hi,
>>
>> So in arch/arm64/include/asm/pgtable-hwdef.h, we have:
>> CONT_PTE_SHIFT
>> CONT_PMD_SHIFT
>> CONT_PTES
>> CONT_PMDS
>> CONT_PTE_SIZE
>> CONT_PTE_MASK
>> ...
>>
>> which are used by the contiguous hint HugeTLB code.
>> Can those be adopted instead of CONT_MASK and CONT_SIZE?
>>
Looking at the hugetlb code, it appears to support contiguous PMDs for
4k and 64k pages as well, while the ARM ARM only defines it for 16k
pages. I suppose the contiguous bit is simply ignored for level 2
entries when using 4k or 64k pages kernels, but I think it would be
better for the code to reflect this as well.
^ permalink raw reply
* [PATCH v8 10/16] mm/memblock: add a new function memblock_alloc_near_nid
From: Leizhen (ThunderTown) @ 2016-10-11 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011101623.GC23648@arm.com>
On 2016/10/11 18:16, Will Deacon wrote:
> On Tue, Oct 11, 2016 at 09:44:20AM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/9/1 14:55, Zhen Lei wrote:
>>> If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
>>> actually exist. The percpu variable areas and numa control blocks of that
>>> memoryless numa nodes must be allocated from the nearest available node
>>> to improve performance.
>>>
>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>>> ---
>>> include/linux/memblock.h | 1 +
>>> mm/memblock.c | 28 ++++++++++++++++++++++++++++
>>> 2 files changed, 29 insertions(+)
>>
>> Hi Will,
>> It seems no one take care about this, how about I move below function into arch/arm64/mm/numa.c
>> again? So that, merge it and patch 11 into one.
>
> I'd rather you reposted it after the merge window so we can see what to
> do with it then. The previous posting was really hard to figure out and
> mixed lots of different concepts into one series, so it's not completely
> surprising that it didn't all get picked up.
OK, thanks.
>
> Will
>
> .
>
^ permalink raw reply
* [PATCH 0/6] crypto: arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-11 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011021247.GA10976@gondor.apana.org.au>
On 11 October 2016 at 03:12, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Mon, Oct 10, 2016 at 12:26:00PM +0100, Ard Biesheuvel wrote:
>>
>> /* This piece of crap needs to disappear into per-type test hooks. */
>> if (!((type ^ CRYPTO_ALG_TYPE_BLKCIPHER) &
>> CRYPTO_ALG_TYPE_BLKCIPHER_MASK) && !(type & CRYPTO_ALG_GENIV) &&
>> ((alg->cra_flags & CRYPTO_ALG_TYPE_MASK) ==
>> CRYPTO_ALG_TYPE_BLKCIPHER ? alg->cra_blkcipher.ivsize :
>> alg->cra_ablkcipher.ivsize))
>> type |= CRYPTO_ALG_TESTED;
>>
>> This causes cbc(aes), ctr(aes) and xts(aes) to remain untested, unless
>> I add CRYPTO_ALG_GENIV to their cra_flags. Is this expected behavior?
>> What would be your recommended way to ensure these algos are covered
>> by the boottime tests?
>
> This is a leftover from the old blkcipher/ablkcipher interface.
> I've got a patch pending which will remove this if clause.
>
OK, thanks.
So I will follow up with a v2 of this series with two additional fixes.
^ permalink raw reply
* [PATCH v3 07/11] arm64/tracing: fix compat syscall handling
From: Marcin Nowakowski @ 2016-10-11 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476182576-15247-1-git-send-email-marcin.nowakowski@imgtec.com>
Add arch_syscall_addr for arm64 and define NR_compat_syscalls, as the
number of compat syscalls for arm64 exceeds the number defined by
NR_syscalls.
Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel at lists.infradead.org
---
arch/arm64/include/asm/ftrace.h | 12 +-----------
arch/arm64/include/asm/unistd.h | 1 +
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/ftrace.c | 16 ++++++++++++++++
4 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
index caa955f..b57ff7c 100644
--- a/arch/arm64/include/asm/ftrace.h
+++ b/arch/arm64/include/asm/ftrace.h
@@ -41,17 +41,7 @@ static inline unsigned long ftrace_call_adjust(unsigned long addr)
#define ftrace_return_address(n) return_address(n)
-/*
- * Because AArch32 mode does not share the same syscall table with AArch64,
- * tracing compat syscalls may result in reporting bogus syscalls or even
- * hang-up, so just do not trace them.
- * See kernel/trace/trace_syscalls.c
- *
- * x86 code says:
- * If the user really wants these, then they should use the
- * raw syscall tracepoints with filtering.
- */
-#define ARCH_TRACE_IGNORE_COMPAT_SYSCALLS
+#define ARCH_COMPAT_SYSCALL_NUMBERS_OVERLAP 1
static inline bool arch_trace_is_compat_syscall(struct pt_regs *regs)
{
return is_compat_task();
diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
index e78ac26..276d049 100644
--- a/arch/arm64/include/asm/unistd.h
+++ b/arch/arm64/include/asm/unistd.h
@@ -45,6 +45,7 @@
#define __ARM_NR_compat_set_tls (__ARM_NR_COMPAT_BASE+5)
#define __NR_compat_syscalls 394
+#define NR_compat_syscalls (__NR_compat_syscalls)
#endif
#define __ARCH_WANT_SYS_CLONE
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 7d66bba..7ea9cd3 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -30,6 +30,7 @@ $(obj)/%.stub.o: $(obj)/%.o FORCE
arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o \
sys_compat.o entry32.o
arm64-obj-$(CONFIG_FUNCTION_TRACER) += ftrace.o entry-ftrace.o
+arm64-obj-$(CONFIG_FTRACE_SYSCALLS) += ftrace.o
arm64-obj-$(CONFIG_MODULES) += arm64ksyms.o module.o
arm64-obj-$(CONFIG_ARM64_MODULE_PLTS) += module-plts.o
arm64-obj-$(CONFIG_PERF_EVENTS) += perf_regs.o perf_callchain.o
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index 40ad08a..75d010f 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -176,4 +176,20 @@ int ftrace_disable_ftrace_graph_caller(void)
return ftrace_modify_graph_caller(false);
}
#endif /* CONFIG_DYNAMIC_FTRACE */
+
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
+
+#if (defined CONFIG_FTRACE_SYSCALLS) && (defined CONFIG_COMPAT)
+
+extern const void *sys_call_table[];
+extern const void *compat_sys_call_table[];
+
+unsigned long __init arch_syscall_addr(int nr, bool compat)
+{
+ if (compat)
+ return (unsigned long)compat_sys_call_table[nr];
+
+ return (unsigned long)sys_call_table[nr];
+}
+
+#endif /* CONFIG_FTRACE_SYSCALLS && CONFIG_COMPAT */
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/2] clk: imx: fix integer overflow in AV PLL round rate
From: Fabio Estevam @ 2016-10-11 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011095852.GB8477@lime>
On Tue, Oct 11, 2016 at 6:58 AM, Emil Lundmark <emil@limesaudio.com> wrote:
>> Another hint: ./scripts/get_maintainer.pl drivers/clk/imx/clk-pllv3.c
>> gives you some suggestions on people and lists to add to Cc.
>
> I did that, but read somewhere that you should send it to the maintainers
> and CC the appropriate list. Should I also send it to reviewers?
It would be nice to send to reviewers as well.
>
> Since this patch series only affects i.MX, I chose to not include the
> people from the common clock framework. Was that wrong?
Yes, please include the clock folks and list as well.
Thanks
^ permalink raw reply
* [PATCH v7 0/3] drm: Add Support for Passive RGB to VGA bridges
From: Maxime Ripard @ 2016-10-11 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.60fc2fa7a6c5b5800b4e3a97b5598216817e0d9c.1476090316.git-series.maxime.ripard@free-electrons.com>
On Mon, Oct 10, 2016 at 11:05:40AM +0200, Maxime Ripard wrote:
> Hi,
>
> This serie is about adding support for the RGB to VGA bridge found in
> the A13-Olinuxino and the CHIP VGA adapter.
>
> Both these boards rely on an entirely passive bridge made out of
> resitor ladders that do not require any initialisation. The only thing
> needed is to get the timings from the screen if available (and if not,
> fall back on XGA standards), set up the display pipeline to output on
> the RGB bus with the proper timings, and you're done.
>
> This serie also fixes a bunch of bugs uncovered when trying to
> increase the resolution, and hence the pixel clock, of our
> pipeline. It also fixes a few bugs in the DRM driver itself that went
> unnoticed before.
>
> Let me know what you think,
> Maxime
Queued all three for 4.10.
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: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161011/7305a832/attachment.sig>
^ permalink raw reply
* [RESEND PATCH v6, 4/5] usb: Add MediaTek USB3 DRD Driver
From: Matthias Brugger @ 2016-10-11 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476155663.15546.32.camel@mhfsdcap03>
On 10/11/2016 05:14 AM, Chunfeng Yun wrote:
> On Mon, 2016-10-10 at 13:00 +0200, Matthias Brugger wrote:
>>
>> On 09/21/2016 07:54 AM, Chunfeng Yun wrote:
>>> This patch adds support for the MediaTek USB3 controller
>>> integrated into MT8173. It can be configured as Dual-Role
>>> Device (DRD), Peripheral Only and Host Only (xHCI) modes.
>>>
>>> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
>>> ---
>>> drivers/usb/Kconfig | 2 +
>>> drivers/usb/Makefile | 1 +
>>> drivers/usb/mtu3/Kconfig | 54 +++
>>> drivers/usb/mtu3/Makefile | 19 +
>>> drivers/usb/mtu3/mtu3.h | 422 +++++++++++++++++
>>> drivers/usb/mtu3/mtu3_core.c | 871 +++++++++++++++++++++++++++++++++++
>>> drivers/usb/mtu3/mtu3_dr.c | 379 ++++++++++++++++
>>> drivers/usb/mtu3/mtu3_dr.h | 108 +++++
>>> drivers/usb/mtu3/mtu3_gadget.c | 731 +++++++++++++++++++++++++++++
>>> drivers/usb/mtu3/mtu3_gadget_ep0.c | 883 ++++++++++++++++++++++++++++++++++++
>>> drivers/usb/mtu3/mtu3_host.c | 294 ++++++++++++
>>> drivers/usb/mtu3/mtu3_hw_regs.h | 473 +++++++++++++++++++
>>> drivers/usb/mtu3/mtu3_plat.c | 490 ++++++++++++++++++++
>>> drivers/usb/mtu3/mtu3_qmu.c | 599 ++++++++++++++++++++++++
>>> drivers/usb/mtu3/mtu3_qmu.h | 43 ++
>>> 15 files changed, 5369 insertions(+)
>>> create mode 100644 drivers/usb/mtu3/Kconfig
>>> create mode 100644 drivers/usb/mtu3/Makefile
>>> create mode 100644 drivers/usb/mtu3/mtu3.h
>>> create mode 100644 drivers/usb/mtu3/mtu3_core.c
>>> create mode 100644 drivers/usb/mtu3/mtu3_dr.c
>>> create mode 100644 drivers/usb/mtu3/mtu3_dr.h
>>> create mode 100644 drivers/usb/mtu3/mtu3_gadget.c
>>> create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c
>>> create mode 100644 drivers/usb/mtu3/mtu3_host.c
>>> create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h
>>> create mode 100644 drivers/usb/mtu3/mtu3_plat.c
>>> create mode 100644 drivers/usb/mtu3/mtu3_qmu.c
>>> create mode 100644 drivers/usb/mtu3/mtu3_qmu.h
>>>
>>
>> As Oliver already said, this patch is quiet big which makes it difficult
>> to review.
>> I propose to provide a first implementation with minimal functionality
>> and incremental patches on top of this when the first got merged.
>>
>> You could split the patch in three series/parts:
>> 1. Host only
>> 2. Peripheral only
>> 3. Dual mode
>>
>> What do you think?
>
> Ok, I'll split the patch into some small ones as many as possible.
There is no direct policy how to do that and it depends a bit on every
maintainer what he prefers. As a rule of thumb each commit should
compile on it's own without errors. This makes bisecting the kernel much
easier.
Regards,
Matthias
>
> Thanks a lot
>>
>> Regards,
>> Matthias
>>
>
>
^ permalink raw reply
* [PATCH 0/2] arm64 kexec-tools fixups
From: Matthias Brugger @ 2016-10-11 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476134309.git.geoff@infradead.org>
On 10/10/2016 11:22 PM, Geoff Levand wrote:
> Hi Simon,
>
> Fixes for 'make tarball'. Please apply.
>
> -Geoff
>
> The following changes since commit 6e8804f9ca67bee65aedd5e1cdf504737ab5c7ed:
>
> multiboot: Use the "reserved" type for non-ram zones (2016-10-07 11:54:44 +0900)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.git for-merge-arm64-dist
>
> for you to fetch changes up to 3552a3e85a910688d932535549b35354a54927ad:
>
> arm64: Add missing kexec dist files (2016-10-10 14:15:21 -0700)
>
> ----------------------------------------------------------------
> Geoff Levand (2):
> arm64: Cleanup kexec Makefile
> arm64: Add missing kexec dist files
>
> kexec/arch/arm64/Makefile | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
^ permalink raw reply
* master build: 2 failures 4 warnings (v4.8-11811-g35ff96d)
From: Mark Brown @ 2016-10-11 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1btqa6-0001tx-HV@optimist>
On Tue, Oct 11, 2016 at 07:30:35AM +0100, Build bot for Mark Brown wrote:
Linus' tree is currently failing to build arm and arm64 allmodconfigs
with:
> arm64-allmodconfig
> ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
> arm-allmodconfig
> ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
due to 6556bdacf646fc (mfd: tps65217: Add support for IRQs) since
irq_set_parent() isn't exported. This has been present in -next
for getting on for a month, a patch was proposed adding the relevant
export but that isn't present in -next yet.
The function is being used in order to enable lazy IRQ disabling for
threaded interrupts:
https://www.spinics.net/lists/arm-kernel/msg532864.html
What's the plan for getting this fixed in Linus' tree?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161011/37a83c95/attachment.sig>
^ permalink raw reply
* [PATCH v8 10/16] mm/memblock: add a new function memblock_alloc_near_nid
From: Will Deacon @ 2016-10-11 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57FC43F4.1020909@huawei.com>
On Tue, Oct 11, 2016 at 09:44:20AM +0800, Leizhen (ThunderTown) wrote:
> On 2016/9/1 14:55, Zhen Lei wrote:
> > If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
> > actually exist. The percpu variable areas and numa control blocks of that
> > memoryless numa nodes must be allocated from the nearest available node
> > to improve performance.
> >
> > Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> > ---
> > include/linux/memblock.h | 1 +
> > mm/memblock.c | 28 ++++++++++++++++++++++++++++
> > 2 files changed, 29 insertions(+)
>
> Hi Will,
> It seems no one take care about this, how about I move below function into arch/arm64/mm/numa.c
> again? So that, merge it and patch 11 into one.
I'd rather you reposted it after the merge window so we can see what to
do with it then. The previous posting was really hard to figure out and
mixed lots of different concepts into one series, so it's not completely
surprising that it didn't all get picked up.
Will
^ permalink raw reply
* [PATCH v7 2/3] ARM: multi_v7: enable VGA bridge
From: Chen-Yu Tsai @ 2016-10-11 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4c4e0bcf101f10b6641e8dfd75b21a3cff66b893.1476090316.git-series.maxime.ripard@free-electrons.com>
On Mon, Oct 10, 2016 at 5:05 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Enable the RGB to VGA bridge driver in the defconfig
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH v7 3/3] ARM: sunxi: Enable VGA bridge
From: Chen-Yu Tsai @ 2016-10-11 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9569fecfab89f2cfee25c899f91d388b1af0cf22.1476090316.git-series.maxime.ripard@free-electrons.com>
On Mon, Oct 10, 2016 at 5:05 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Enable the VGA bridge used on the A13-Olinuxino in the sunxi defconfig
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Ziji Hu @ 2016-10-11 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010213417.GA11795@rob-hp-laptop>
Hi Rob,
Thanks a for the review.
It is really helpful to me.
On 2016/10/11 5:34, Rob Herring wrote:
> On Fri, Oct 07, 2016 at 05:22:51PM +0200, Gregory CLEMENT wrote:
>> From: Ziji Hu <huziji@marvell.com>
>>
>> Marvell Xenon SDHC can support eMMC/SD/SDIO.
>> Add Xenon-specific properties.
>> Also add properties for Xenon PHY setting.
>>
>> Signed-off-by: Hu Ziji <huziji@marvell.com>
>> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>> Documentation/devicetree/bindings/mmc/marvell,sdhci-xenon.txt | 164 +++++++-
>> MAINTAINERS | 1 +-
>> 2 files changed, 165 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mmc/marvell,sdhci-xenon.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/marvell,sdhci-xenon.txt b/Documentation/devicetree/bindings/mmc/marvell,sdhci-xenon.txt
>> new file mode 100644
>> index 000000000000..8b25ad28ebbd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/marvell,sdhci-xenon.txt
>> @@ -0,0 +1,164 @@
>> +Marvell's Xenon SDHCI Controller device tree bindings
>> +This file documents differences between the core mmc properties
>> +described by mmc.txt and the properties used by the Xenon implementation.
>> +
>> +A single Xenon IP can support multiple slots.
>> +Each slot acts as an independent SDHC. It owns independent resources, such
>> +as register sets clock and PHY.
>
> Is the phy really part of the same block?
>
Each SDHC slot owns its PHY. It is part of a SDHC slot.
It is independent to another SDHC slot.
>> +Each slot should have an independent device tree node.
>> +
>> +Required Properties:
>> +- compatible: should be "marvell,sdhci-xenon" or "marvell,armada-3700-sdhci".
>
> Perhaps some consistent ordering (w/ -sdhci on the end).
Sure.
I will adjust the ordering.
>
>> +
>> +- Input Clock Name
>
> Your formatting of properties is a bit strange. Please restructure like
> most bindings so the property names are before all the description.
>
OK.
I will fix the format.
>> + Some SOCs require additional clock for AXI bus.
>
> Those SoCs should have a specific compatible string and you need to
> define which compatible strings have 2 clocks vs. 1 clock.
>
Actually, I copy this implementation from another Marvell SDIO Host Controller, sdhci-pxa.
It is in sdhci-pxa.txt.
I would like to know if it is still acceptable.
>> + The input clock for Xenon IP core should be named as "core".
>> + The optional AXI clock should be named as "axi".
>> + - clocks = <&core_clk>, <&axi_clock>;
>> + - clock-names = "core", "axi";
>> +
>> +- Register Set Size
>
> Is this a property name?
Sorry, it isn't.
I will fix the format.
>
>> + Different Xenon SDHC release has different register set size.
>> + The specific size should also refer to the SOC implementation.
>> +
>> +Optional Properties:
>> +- Slot Index
>> + A single Xenon IP can support multiple slots.
>> + During initialization, each slot should set corresponding setting bit in
>> + some Xenon-specific registers. The corresponding bit is determined by
>> + this property.
>> + - xenon,slotno = <slot_index>;
>
> Slots should probably be represented as child nodes with the reg
> property being the slot number.
Since each SDHC slot is independent, I find it is more convenient to implement each one as independent SD host/MMC host instant.
Otherwise, a main function should loop and initialize each slot, like sdhci-pci. I prefer to avoiding such a unnecessary main function.
It is very hard to determine the slot number by reg property.
Xenon slots are likely to be different types. 1st slot might be eMMC and 2nd one might be SD. They might have different register size.
The register size might also varies in different Xenon versions.
>
> Also, xenon is not a vendor prefix.
>
Yes. The issue is that there are multiple Marvell SD Host Controllers existing in kernel.
If marvell is used as a prefix here, I concern that it might be confused with other Marvell sdhc.
Can I use a combination of marvell and xenon as a prefix, such as mrvl-xenon?
>> + If this property is not provided, Xenon IP should contain only one slot
>> + and the slot index will be 0x0 by default.
>> +
>> +- PHY Type
>
> You're going to need to come of with a common binding for this.
>
Could you please provide more details about the "common binding" here?
The PHY Type property is Xenon-specific, instead of a standard or a spec.
Thus I cannot find a common property to stand for it.
>> + Xenon support mutilple types of PHYs.
>> + To select eMMC 5.1 PHY, set:
>> + - xenon,phy-type = "emmc 5.1 phy"
>> + eMMC 5.1 PHY is the default choice if this property is not provided.
>> + To select eMMC 5.0 PHY, set:
>> + - xenon,phy-type = "emmc 5.0 phy"
>> + To select SDH PHY, set:
>> + - xenon,phy-type = "sdh phy"
>> + Please note that eMMC PHY is a general PHY for eMMC/SD/SDIO, other than for
>> + eMMC only.
>> +
>> +- Customized eMMC PHY Parameters
>> + Some boards require different values of some specific eMMC PHY parameters.
>> + Some SOCs also require specific workaround to set eMMC PHY.
>> + These properties enable diverse boards to customize the eMMC PHY.
>> + The supported eMMC PHY parameters are listed in below. All those properties
>> + are only available for eMMC PHY 5.1 and eMMC PHY 5.0.
>> + ZNR
>> + valid range = [0:0x1F].
>> + ZNR is set as 0xF by default if this property is not provided.
>> + - xenon,phy-znr = <value>;
>> +
>> + ZPR
>> + valid range = [0:0x1F].
>> + ZPR is set as 0xF by default if this property is not provided.
>> + - xenon,phy-zpr = <value>;
>
> marvell is the vendor prefix.
>
>> +
>> + Number of successful tuning times
>> + Set the number of required consecutive successful sampling points used to
>> + identify a valid sampling window, in tuning process.
>> + Valid range = [1:7]. Set as 0x4 by default if this property is not provided.
>> + - xenon,phy-nr-tun-times = <nr_times>;
>> +
>> + Divider for TUN_STEP
>> + Set the divider for calculating TUN_STEP.
>> + Set as 64 by default if this property is not provided.
>> + - xenon,phy-tun-step-divider = <divider>;
>> +
>> + Force PHY into slow mode.
>> + Only available when bus frequency lower than 50MHz in SDR mde.
>> + Disabled by default. Please do not enable it unless it is necessary.
>> + - xenon,phy-slow-mode;
>> +
>> +- Mask Conflict Error Report
>> + Disable Conflict Error alert on some SOC. Disabled by default.
>> + xenon,mask-conflict-err;
>> +
>> +- Re-tuning Counter
>> + Xenon SDHC SOC usually doesn't provide re-tuning counter in
>> + Capabilities Register 3 Bit[11:8].
>> + This property provides the re-tuning counter.
>> + xenon,tuning-count = <count>;
>> + If this property is not set, default re-tuning counter will
>> + be set as 0x9 in driver.
>> +
>> +- SOC PHY PAD Voltage Control register
>> + Some SOCs have SOC PHY PAD Voltage Control register outside Xenon IP.
>> + This register sets SOC PHY PAD Voltage to keep aligh with Vccq.
>> + Two properties provide information of this control register.
>> + These two properties are only valid when "marvell,armada-3700-sdhci"
>> + is selected. Both of them must be provided when "marvell,armada-3700-sdhci"
>> + is selected.
>> + - xenon,pad-type
>> + Two types: "sd" and "fixed-1-8v".
>> + If "sd" is slected, SOC PHY PAD is set as 3.3V at the beginning and is
>> + switched to 1.8V when SD in UHS-I.
>> + If "fixed-1-8v" is slected, SOC PHY PAD is fixed 1.8V, such as for eMMC.
>
> You should be able to existing, common properties for i/o voltage
> capabilities/constraints.
>
The above property is for a special SOC platform in Marvell.
It is irrelevant to common PHY framework or standard MMC bindings.
Thus I cannot find a existing and common property to represent it.
Thank you.
Best regards,
Hu Ziji
>> + - reg
>> + Physical address and size of SOC PHY PAD register.
>> + Append after Xenon SDHC register space, as a second register field.
>> +
>> + Please follow the examples with compatible "marvell,armada-3700-sdhci"
>> + in below.
>> +
>> +Example:
>> +- For eMMC slot:
>> +
>> + sdhci at aa0000 {
>> + compatible = "marvell,sdhci-xenon";
>> + reg = <0xaa0000 0x1000>;
>> + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>
>> + clocks = <&emmcclk>;
>> + clock-names = "core";
>> + xenon,slotno = <0>;
>> + xenon,phy-type = "emmc 5.1 phy";
>> + bus-width = <8>;
>> + tuning-count = <11>;
>> + };
>> +
>> +- For SD/SDIO slot:
>> +
>> + sdhci at ab0000 {
>> + compatible = "marvell,sdhci-xenon";
>> + reg = <0xab0000 0x1000>;
>> + interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>
>> + vqmmc-supply = <&sd_regulator>;
>> + clocks = <&sdclk>;
>> + clock-names = "core";
>> + bus-width = <4>;
>> + tuning-count = <9>;
>> + };
>> +
>> +- For eMMC slot with compatible "marvell,armada-3700-sdhci":
>> +
>> + sdhci at aa0000 {
>> + compatible = "marvell,armada-3700-sdhci";
>> + reg = <0xaa0000 0x1000>,
>> + <phy_addr 0x4>;
>> + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>
>> + clocks = <&emmcclk>;
>> + clock-names = "core";
>> + bus-width = <8>;
>> +
>> + xenon,pad-type = "fixed-1-8v";
>> + };
>> +
>> +- For SD/SDIO slot with compatible "marvell,armada-3700-sdhci":
>> +
>> + sdhci at ab0000 {
>> + compatible = "marvell,armada-3700-sdhci";
>> + reg = <0xab0000 0x1000>,
>> + <phy_addr 0x4>;
>> + interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>
>> + vqmmc-supply = <&sd_regulator>;
>> + clocks = <&sdclk>;
>> + clock-names = "core";
>> + bus-width = <4>;
>> +
>> + xenon,pad-type = "sd";
>> + };
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 89adcd57aa25..4aa0eac9bfc7 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -7582,6 +7582,7 @@ MARVELL XENON MMC/SD/SDIO HOST CONTROLLER DRIVER
>> M: Ziji Hu <huziji@marvell.com>
>> L: linux-mmc at vger.kernel.org
>> S: Supported
>> +F: Documentation/devicetree/bindings/mmc/marvell,sdhci-xenon.txt
>>
>> MATROX FRAMEBUFFER DRIVER
>> L: linux-fbdev at vger.kernel.org
>> --
>> git-series 0.8.10
^ permalink raw reply
* [PATCH v2 1/2] clk: imx: fix integer overflow in AV PLL round rate
From: Emil Lundmark @ 2016-10-11 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5C56tiXjBArgqZuMdu8_MB6Gq3=xWX65WNvQv+=r6VjGQ@mail.gmail.com>
On Mon, Oct 10, 2016 at 11:08:40AM -0300, Fabio Estevam wrote:
> On Mon, Oct 10, 2016 at 7:03 AM, Emil Lundmark <emil@limesaudio.com> wrote:
> > Since 'parent_rate * mfn' may overflow 32 bits, the result should be
> > stored using 64 bits.
>
> It would be nice to add the text you put in the cover letter where you
> explain the PLL4 clock discrepancy here in the commit log.
I will do that in v3.
> >
> > Fixes: ba7f4f557eb6 ("clk: imx: correct AV PLL rate formula")
>
> Would be nice to Cc the author of this commit (Anson Huang). Added on Cc.
Good point, will keep this in mind in the future.
> Another hint: ./scripts/get_maintainer.pl drivers/clk/imx/clk-pllv3.c
> gives you some suggestions on people and lists to add to Cc.
I did that, but read somewhere that you should send it to the maintainers
and CC the appropriate list. Should I also send it to reviewers?
Since this patch series only affects i.MX, I chose to not include the
people from the common clock framework. Was that wrong?
--
Emil Lundmark
^ permalink raw reply
* [PATCH v2 1/2] clk: imx: fix integer overflow in AV PLL round rate
From: Emil Lundmark @ 2016-10-11 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010135454.a6t46o4ocpwjmkwi@pengutronix.de>
On Mon, Oct 10, 2016 at 03:54:54PM +0200, Uwe Kleine-K?nig wrote:
> On Mon, Oct 10, 2016 at 12:03:05PM +0200, Emil Lundmark wrote:
> > Since 'parent_rate * mfn' may overflow 32 bits, the result should be
> > stored using 64 bits.
> >
> > Fixes: ba7f4f557eb6 ("clk: imx: correct AV PLL rate formula")
> > Signed-off-by: Emil Lundmark <emil@limesaudio.com>
> > ---
> > drivers/clk/imx/clk-pllv3.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
> > index 19f9b622981a..bc7f163ea13c 100644
> > --- a/drivers/clk/imx/clk-pllv3.c
> > +++ b/drivers/clk/imx/clk-pllv3.c
> > @@ -247,7 +247,11 @@ static long clk_pllv3_av_round_rate(struct clk_hw *hw, unsigned long rate,
> > do_div(temp64, parent_rate);
> > mfn = temp64;
> >
> > - return parent_rate * div + parent_rate * mfn / mfd;
> > + temp64 = (u64)parent_rate;
> > + temp64 *= mfn;
> > + do_div(temp64, mfd);
>
> If you change parent_rate from unsigned long to u64 this simplifies to
>
> temp64 = parent_rate * mfn
> do_div(temp64, mfd);
>
Yes, I took my inspiration from clk_pllv3_av_recalc_rate().
> > +
> > + return parent_rate * div + (u32)temp64;
>
> When thinking about overflow problems: Should this fail somehow if
> temp64 != (u32)temp64?
Well, it will fail in the sence that the desired clock will not be
returned. However, since mfn / mfd < 1 it should be fine as long as
ULONG_MAX <= U32_MAX. So, maybe it would be better to cast it to unsigned
long? This would then also need to be changed in
clk_pllv3_av_recalc_rate().
--
Emil Lundmark
^ permalink raw reply
* [PATCH v4 10/10] ARM: sunxi: Enable sun8i-emac driver on multi_v7_defconfig
From: Maxime Ripard @ 2016-10-11 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010150943.fa7ca85fe52f4c6f9508b5eb@free.fr>
On Mon, Oct 10, 2016 at 03:09:43PM +0200, Jean-Francois Moine wrote:
> On Mon, 10 Oct 2016 14:35:11 +0200
> LABBE Corentin <clabbe.montjoie@gmail.com> wrote:
>
> > On Mon, Oct 10, 2016 at 02:30:46PM +0200, Maxime Ripard wrote:
> > > On Fri, Oct 07, 2016 at 10:25:57AM +0200, Corentin Labbe wrote:
> > > > Enable the sun8i-emac driver in the multi_v7 default configuration
> > > >
> > > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > ---
> > > > arch/arm/configs/multi_v7_defconfig | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> > > > index 5845910..f44d633 100644
> > > > --- a/arch/arm/configs/multi_v7_defconfig
> > > > +++ b/arch/arm/configs/multi_v7_defconfig
> > > > @@ -229,6 +229,7 @@ CONFIG_NETDEVICES=y
> > > > CONFIG_VIRTIO_NET=y
> > > > CONFIG_HIX5HD2_GMAC=y
> > > > CONFIG_SUN4I_EMAC=y
> > > > +CONFIG_SUN8I_EMAC=y
> > >
> > > Any reason to build it statically?
> >
> > No, just copied the same than CONFIG_SUN4I_EMAC that probably do
> > not need it also.
>
> All arm configs are done the same way, and, some day, the generic ARM
> V7 kernel will not be loadable in 1Gb RAM...
Yeah, if possible, I'd really like to avoid introducing statically
built drivers to multi_v7.
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: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161011/b305fb1b/attachment.sig>
^ permalink raw reply
* [PATCH v4 04/10] ARM: dts: sun8i-h3: Add dt node for the syscon control module
From: Maxime Ripard @ 2016-10-11 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010145021.00586f772e3398833217796a@free.fr>
On Mon, Oct 10, 2016 at 02:50:21PM +0200, Jean-Francois Moine wrote:
> On Mon, 10 Oct 2016 14:31:51 +0200
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi,
> >
> > On Fri, Oct 07, 2016 at 10:25:51AM +0200, Corentin Labbe wrote:
> > > This patch add the dt node for the syscon register present on the
> > > Allwinner H3.
> > >
> > > Only two register are present in this syscon and the only one useful is
> > > the one dedicated to EMAC clock.
> > >
> > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > ---
> > > arch/arm/boot/dts/sun8i-h3.dtsi | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > index 8a95e36..1101d2f 100644
> > > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > @@ -140,6 +140,11 @@
> > > #size-cells = <1>;
> > > ranges;
> > >
> > > + syscon: syscon at 01c00000 {
> > > + compatible = "syscon";
> >
> > It would be great to have a more specific compatible here in addition
> > to the syscon, like "allwinner,sun8i-h3-system-controller".
>
> The System Control area is just like the PRCM area: it would be simpler
> to define the specific registers in the associated drivers.
Until you actually have to share those registers between different
devices, and then you're just screwed.
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: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161011/d6cf94ba/attachment-0001.sig>
^ permalink raw reply
* [linux-sunxi] [PATCH 3/5] Input: add driver for Ilitek ili2139 touch IC
From: Hans de Goede @ 2016-10-11 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011003359.26079-3-icenowy@aosc.xyz>
Hi,
On 10/11/2016 02:33 AM, Icenowy Zheng wrote:
> This driver adds support for Ilitek ili2139 touch IC, which is used in
> several Colorfly tablets (for example, Colorfly E708 Q1, which is an
> Allwinner A31s tablet with mainline kernel support).
>
> Theortically it may support more Ilitek touch ICs, however, only ili2139
> is used in any mainlined device.
>
> It supports device tree enumeration, with screen resolution and axis
> quirks configurable.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> drivers/input/touchscreen/Kconfig | 14 ++
> drivers/input/touchscreen/Makefile | 1 +
> drivers/input/touchscreen/ili2139.c | 320 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 335 insertions(+)
> create mode 100644 drivers/input/touchscreen/ili2139.c
>
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index 5079813..bb4d9d2 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -348,6 +348,20 @@ config TOUCHSCREEN_ILI210X
> To compile this driver as a module, choose M here: the
> module will be called ili210x.
>
> +config TOUCHSCREEN_ILI2139
> + tristate "Ilitek ILI2139 based touchscreen"
> + depends on I2C
> + depends on OF
> + help
> + Say Y here if you have a ILI2139 based touchscreen
> + controller. Such kind of chipsets can be found in several
> + Colorfly tablets.
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here; the
> + module will be called ili2139.
> +
> config TOUCHSCREEN_IPROC
> tristate "IPROC touch panel driver support"
> depends on ARCH_BCM_IPROC || COMPILE_TEST
> diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> index 81b8645..930b5e2 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -40,6 +40,7 @@ obj-$(CONFIG_TOUCHSCREEN_EGALAX_SERIAL) += egalax_ts_serial.o
> obj-$(CONFIG_TOUCHSCREEN_FUJITSU) += fujitsu_ts.o
> obj-$(CONFIG_TOUCHSCREEN_GOODIX) += goodix.o
> obj-$(CONFIG_TOUCHSCREEN_ILI210X) += ili210x.o
> +obj-$(CONFIG_TOUCHSCREEN_ILI2139) += ili2139.o
> obj-$(CONFIG_TOUCHSCREEN_IMX6UL_TSC) += imx6ul_tsc.o
> obj-$(CONFIG_TOUCHSCREEN_INEXIO) += inexio.o
> obj-$(CONFIG_TOUCHSCREEN_INTEL_MID) += intel-mid-touch.o
> diff --git a/drivers/input/touchscreen/ili2139.c b/drivers/input/touchscreen/ili2139.c
> new file mode 100644
> index 0000000..65c2dea
> --- /dev/null
> +++ b/drivers/input/touchscreen/ili2139.c
> @@ -0,0 +1,320 @@
> +/* -------------------------------------------------------------------------
> + * Copyright (C) 2016, Icenowy Zheng <icenowy@aosc.xyz>
> + *
> + * Derived from:
> + * ili210x.c
> + * Copyright (C) Olivier Sobrie <olivier@sobrie.be>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + * -------------------------------------------------------------------------
> + */
> +
> +#include <linux/module.h>
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/slab.h>
> +#include <linux/input.h>
> +#include <linux/input/mt.h>
> +#include <linux/input/touchscreen.h>
> +#include <linux/delay.h>
> +#include <linux/workqueue.h>
> +
> +#define DEFAULT_POLL_PERIOD 20
> +
> +#define MAX_TOUCHES 10
> +#define COMPATIBLE_TOUCHES 2
> +
> +/* Touchscreen commands */
> +#define REG_TOUCHDATA 0x10
> +#define REG_TOUCHSUBDATA 0x11
> +#define REG_PANEL_INFO 0x20
> +#define REG_FIRMWARE_VERSION 0x40
> +#define REG_PROTO_VERSION 0x42
> +
> +#define SUBDATA_STATUS_TOUCH_POINT 0x80
> +#define SUBDATA_STATUS_RELEASE_POINT 0x00
> +
> +struct finger {
> + u8 x_low;
> + u8 x_high;
> + u8 y_low;
> + u8 y_high;
> +} __packed;
> +
> +struct touchdata {
> + u8 length;
> + struct finger finger[COMPATIBLE_TOUCHES];
> +} __packed;
> +
> +struct touch_subdata {
> + u8 status;
> + struct finger finger;
> +} __packed;
> +
> +struct panel_info {
> + struct finger finger_max;
> + u8 xchannel_num;
> + u8 ychannel_num;
> +} __packed;
> +
> +struct firmware_version {
> + u8 id;
> + u8 major;
> + u8 minor;
> +} __packed;
> +
> +struct ili2139 {
> + struct i2c_client *client;
> + struct input_dev *input;
> + unsigned int poll_period;
> + struct delayed_work dwork;
> + struct touchscreen_properties prop;
> + int slots[MAX_TOUCHES];
> + int ids[MAX_TOUCHES];
> + struct input_mt_pos pos[MAX_TOUCHES];
> +};
> +
> +static int ili2139_read_reg(struct i2c_client *client, u8 reg, void *buf,
> + size_t len)
> +{
> + struct i2c_msg msg[2] = {
> + {
> + .addr = client->addr,
> + .flags = 0,
> + .len = 1,
> + .buf = ®,
> + },
> + {
> + .addr = client->addr,
> + .flags = I2C_M_RD,
> + .len = len,
> + .buf = buf,
> + }
> + };
> +
> + if (i2c_transfer(client->adapter, msg, 2) != 2) {
> + dev_err(&client->dev, "i2c transfer failed\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
This just i2c_smbus_read_i2c_block_data, please use that instead.
> +static void ili2139_work(struct work_struct *work)
> +{
> + int id;
> + struct ili2139 *priv = container_of(work, struct ili2139,
> + dwork.work);
> + struct i2c_client *client = priv->client;
> + struct touchdata touchdata;
> + struct touch_subdata subdata;
> + int error;
> +
> + error = ili2139_read_reg(client, REG_TOUCHDATA,
> + &touchdata, sizeof(touchdata));
> + if (error) {
> + dev_err(&client->dev,
> + "Unable to get touchdata, err = %d\n", error);
> + return;
> + }
> +
> + for (id = 0; id < touchdata.length; id++) {
> + error = ili2139_read_reg(client, REG_TOUCHSUBDATA, &subdata,
> + sizeof(subdata));
> + if (error) {
> + dev_err(&client->dev,
> + "Unable to get touch subdata, err = %d\n",
> + error);
> + return;
> + }
> +
> + priv->ids[id] = subdata.status & 0x3F;
> +
> + /* The sequence changed in the v2 subdata protocol. */
> + touchscreen_set_mt_pos(&priv->pos[id], &priv->prop,
> + (subdata.finger.x_high | (subdata.finger.x_low << 8)),
> + (subdata.finger.y_high | (subdata.finger.y_low << 8)));
> + }
> +
> + input_mt_assign_slots(priv->input, priv->slots, priv->pos,
> + touchdata.length, 0);
> +
> + for (id = 0; id < touchdata.length; id++) {
> + input_mt_slot(priv->input, priv->slots[id]);
> + input_mt_report_slot_state(priv->input, MT_TOOL_FINGER,
> + subdata.status &
> + SUBDATA_STATUS_TOUCH_POINT);
> + input_report_abs(priv->input, ABS_MT_POSITION_X,
> + priv->pos[id].x);
> + input_report_abs(priv->input, ABS_MT_POSITION_Y,
> + priv->pos[id].y);
> + }
> +
> + input_mt_sync_frame(priv->input);
> + input_sync(priv->input);
> +
> + schedule_delayed_work(&priv->dwork,
> + msecs_to_jiffies(priv->poll_period));
If the irq is working properly there should be no need for this,
can you try with this schedule call removed ?
> +}
> +
> +static irqreturn_t ili2139_irq(int irq, void *irq_data)
> +{
> + struct ili2139 *priv = irq_data;
> +
> + schedule_delayed_work(&priv->dwork, 0);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int ili2139_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = &client->dev;
> + struct ili2139 *priv;
> + struct input_dev *input;
> + struct panel_info panel;
> + struct firmware_version firmware;
> + int xmax, ymax;
> + int error;
> +
> + dev_dbg(dev, "Probing for ILI2139 I2C Touschreen driver");
> +
> + if (client->irq <= 0) {
> + dev_err(dev, "No IRQ!\n");
> + return -ENODEV;
> + }
> +
> + /* Get firmware version */
> + error = ili2139_read_reg(client, REG_FIRMWARE_VERSION,
> + &firmware, sizeof(firmware));
> + if (error) {
> + dev_err(dev, "Failed to get firmware version, err: %d\n",
> + error);
> + return error;
> + }
> +
> + /* get panel info */
> + error = ili2139_read_reg(client, REG_PANEL_INFO, &panel, sizeof(panel));
> + if (error) {
> + dev_err(dev, "Failed to get panel information, err: %d\n",
> + error);
> + return error;
> + }
> +
> + xmax = panel.finger_max.x_low | (panel.finger_max.x_high << 8);
> + ymax = panel.finger_max.y_low | (panel.finger_max.y_high << 8);
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + input = devm_input_allocate_device(dev);
> + if (!priv || !input)
> + return -ENOMEM;
> +
> + priv->client = client;
> + priv->input = input;
> + priv->poll_period = DEFAULT_POLL_PERIOD;
> + INIT_DELAYED_WORK(&priv->dwork, ili2139_work);
> +
> + /* Setup input device */
> + input->name = "ILI2139 Touchscreen";
> + input->id.bustype = BUS_I2C;
> + input->dev.parent = dev;
> +
> + __set_bit(EV_SYN, input->evbit);
> + __set_bit(EV_KEY, input->evbit);
> + __set_bit(EV_ABS, input->evbit);
> +
> + /* Multi touch */
> + input_mt_init_slots(input, MAX_TOUCHES, INPUT_MT_DIRECT |
> + INPUT_MT_DROP_UNUSED | INPUT_MT_TRACK);
> + input_set_abs_params(input, ABS_MT_POSITION_X, 0, xmax, 0, 0);
> + input_set_abs_params(input, ABS_MT_POSITION_Y, 0, ymax, 0, 0);
> +
> + touchscreen_parse_properties(input, true, &priv->prop);
> +
> + input_set_drvdata(input, priv);
> + i2c_set_clientdata(client, priv);
> +
> + error = devm_request_irq(dev, client->irq, ili2139_irq,
> + IRQF_TRIGGER_FALLING, client->name, priv);
If things work with the re-scheduleing of the delayed work
from the work removed, then you can use request_threaded_irq here,
pass in ili2139_irq as the threaded handler (and NULL as the non threaded
handler) and do all the i2c reading directly in ili2139_irq without needing
to use any work struct at all.
Regards,
Hans
> + if (error) {
> + dev_err(dev, "Unable to request touchscreen IRQ, err: %d\n",
> + error);
> + return error;
> + }
> +
> + error = input_register_device(priv->input);
> + if (error) {
> + dev_err(dev, "Cannot register input device, err: %d\n", error);
> + return error;
> + }
> +
> + device_init_wakeup(&client->dev, 1);
> +
> + dev_dbg(dev,
> + "ILI2139 initialized (IRQ: %d), firmware version %d.%d.%d",
> + client->irq, firmware.id, firmware.major, firmware.minor);
> +
> + return 0;
> +}
> +
> +static int ili2139_i2c_remove(struct i2c_client *client)
> +{
> + struct ili2139 *priv = i2c_get_clientdata(client);
> +
> + cancel_delayed_work_sync(&priv->dwork);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused ili2139_i2c_suspend(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> +
> + if (device_may_wakeup(&client->dev))
> + enable_irq_wake(client->irq);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused ili2139_i2c_resume(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> +
> + if (device_may_wakeup(&client->dev))
> + disable_irq_wake(client->irq);
> +
> + return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(ili2139_i2c_pm,
> + ili2139_i2c_suspend, ili2139_i2c_resume);
> +
> +static const struct i2c_device_id ili2139_i2c_id[] = {
> + { "ili2139", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, ili2139_i2c_id);
> +
> +static struct i2c_driver ili2139_ts_driver = {
> + .driver = {
> + .name = "ili2139_i2c",
> + .pm = &ili2139_i2c_pm,
> + },
> + .id_table = ili2139_i2c_id,
> + .probe = ili2139_i2c_probe,
> + .remove = ili2139_i2c_remove,
> +};
> +
> +module_i2c_driver(ili2139_ts_driver);
> +
> +MODULE_AUTHOR("Olivier Sobrie <olivier@sobrie.be>");
> +MODULE_DESCRIPTION("ILI2139 I2C Touchscreen Driver");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* [PATCH 2/9] drm/sun4i: tcon: Move SoC specific quirks to a DT matched data structure
From: Maxime Ripard @ 2016-10-11 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67vZLCtUOaqBwtAnHmCMpoxmh3pxjtD5TL2nWp3Lm-Pzg@mail.gmail.com>
On Tue, Oct 11, 2016 at 05:16:21PM +0800, Chen-Yu Tsai wrote:
> On Fri, Oct 7, 2016 at 4:38 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > On Fri, Oct 07, 2016 at 12:06:22AM +0800, Chen-Yu Tsai wrote:
> >> +struct sun4i_tcon_quirks {
> >> + bool is_sun5i; /* sun5i has undocumented mux */
> >> + bool has_channel_1; /* a33 does not have channel 1 */
> >> + bool has_bypass_src; /* has separate input bypassing CEU */
> >> + bool has_dma_src; /* has DMA input */
> >> +};
> >> +
> >
> > I'd really prefer to keep the has_mux quirk name. is_sun5i doesn't
> > really relate to what we're doing there, is redundant with the
> > compatible, and render the other quirks name useless, since we could
> > just have is_sun.i quirks and deal with that (which is essentially
> > what we were doing before).
>
> Lets call it has_unknown_mux then. has_mux would be confusing with
> the HDMI and MIPI DSI muxes on sun6i.
That works for me.
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: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161011/c35796a0/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: rockchip: initialize rk3066 PLL clock rate
From: Heiko Stuebner @ 2016-10-11 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006194221.GA4895@vaio-ubuntu>
Am Donnerstag, 6. Oktober 2016, 21:42:21 CEST schrieb Pawe? Jarosz:
> Initialize PLL rate while kernel init. No other module does than.
> Clock rates are taken from rk3066 TRM. Assigned values are for 125 degrees
> celcius operating point.
> This gives us performance boost observable for example in mmc transfers.
>
> Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
> ---
> arch/arm/boot/dts/rk3066a.dtsi | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
> index 0d0dae3..cf215e8 100644
> --- a/arch/arm/boot/dts/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rk3066a.dtsi
> @@ -151,6 +151,10 @@
>
> #clock-cells = <1>;
> #reset-cells = <1>;
> + assigned-clocks = <&cru PLL_DPLL>, <&cru PLL_APLL>,
we shouldn't touch the DPLL and APLL at all in this context. They are quite
reliant on the underlying voltages and the bootloader might've set other
values. Also changing the DDR frequency through the DPLL requires special
handling on the DDR side.
> + <&cru PLL_CPLL>, <&cru PLL_GPLL>;
please also initialize the PERI and BUS clocks (similar to what the rk3288 clk
settings do), so that they stay sane, even if we change CPLL and GPLL
frequencies.
> + assigned-clock-rates = <533000000>, <600000000>,
> + <600000000>, <600000000>;
Also setting both CPLL and GPLL to the same value might be unhelpful to
achieve special divided frequencies? Again see rk3288.dtsi where we have a 594
/ 400 MHz division. Especially the downstream clocks normally can select
between CPLL and GPLL.
Heiko
^ permalink raw reply
* [PATCH v2] sdhci-esdhc-imx: Correct two register accesses
From: Adrian Hunter @ 2016-10-11 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476124792-18441-1-git-send-email-aaron.brice@datasoft.com>
On 10/10/16 21:39, Aaron Brice wrote:
> - The DMA error interrupt bit is in a different position as
> compared to the sdhci standard. This is accounted for in
> many cases, but not handled in the case of clearing the
> INT_STATUS register by writing a 1 to that location.
> - The HOST_CONTROL register is very different as compared to
> the sdhci standard. This is accounted for in the write
> case, but not when read back out (which it is in the sdhci
> code).
>
> Signed-off-by: Dave Russell <david.russell@datasoft.com>
> Signed-off-by: Aaron Brice <aaron.brice@datasoft.com>
> Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
^ permalink raw reply
* [PATCH 5/6] clk: stm32f469: Add QSPI clock
From: Gabriel Fernandez @ 2016-10-11 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161008205003.GB17455@rob-hp-laptop>
Hi Rob,
Thanks for reviewing
On 10/08/2016 10:50 PM, Rob Herring wrote:
> On Fri, Sep 30, 2016 at 04:25:08PM +0200, gabriel.fernandez at st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> This patch adds the QSPI clock for stm32f469 discovery board.
>> The gate mapping is a little bit different from stm32f429 soc.
>>
>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>> ---
>> .../devicetree/bindings/clock/st,stm32-rcc.txt | 4 +-
>> drivers/clk/clk-stm32f4.c | 173 ++++++++++++++++++---
>> 2 files changed, 158 insertions(+), 19 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
>> index fee3205..eace3de 100644
>> --- a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
>> +++ b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
>> @@ -8,7 +8,9 @@ Please also refer to clock-bindings.txt in this directory for common clock
>> controller binding usage.
>>
>> Required properties:
>> -- compatible: Should be "st,stm32f42xx-rcc"
>> +- compatible: Should be:
>> + "st,stm32f42xx-rcc"
>> + "st,stm32f46xx-rcc"
> Generally, we don't use wildcards in compatible strings. I know there's
> lots of part numbers of stm32 parts which I guess are often same die
> with different fusing or package. Your compatible strings should be at
> least specific enough to identify parts that are really different die.
okay i will propose "st,stm32f469-rcc" if no one is against.
BR
Gabriel
>
>> - reg: should be register base and length as documented in the
>> datasheet
>> - #clock-cells: 2, device nodes should specify the clock in their "clocks"
^ permalink raw reply
* [PATCH 2/9] drm/sun4i: tcon: Move SoC specific quirks to a DT matched data structure
From: Chen-Yu Tsai @ 2016-10-11 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161007083853.GH4684@lukather>
On Fri, Oct 7, 2016 at 4:38 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Fri, Oct 07, 2016 at 12:06:22AM +0800, Chen-Yu Tsai wrote:
>> +struct sun4i_tcon_quirks {
>> + bool is_sun5i; /* sun5i has undocumented mux */
>> + bool has_channel_1; /* a33 does not have channel 1 */
>> + bool has_bypass_src; /* has separate input bypassing CEU */
>> + bool has_dma_src; /* has DMA input */
>> +};
>> +
>
> I'd really prefer to keep the has_mux quirk name. is_sun5i doesn't
> really relate to what we're doing there, is redundant with the
> compatible, and render the other quirks name useless, since we could
> just have is_sun.i quirks and deal with that (which is essentially
> what we were doing before).
Lets call it has_unknown_mux then. has_mux would be confusing with
the HDMI and MIPI DSI muxes on sun6i.
ChenYu
^ permalink raw reply
* [PATCH] arm64: mmu: set the contiguous for kernel mappings when appropriate
From: Ard Biesheuvel @ 2016-10-11 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPvkgC1p5yZLtENYMi6zd5-pPDOYUtMw0Lxvb592u975gc+Zvg@mail.gmail.com>
On 11 October 2016 at 09:48, Steve Capper <steve.capper@linaro.org> wrote:
>
>
> On 11 October 2016 at 08:44, Mark Rutland <mark.rutland@arm.com> wrote:
>>
>> Hi Ard,
>>
>> On Mon, Oct 10, 2016 at 07:12:44PM +0100, Ard Biesheuvel wrote:
>> > Now that we no longer allow live kernel PMDs to be split, it is safe to
>> > start using the contiguous bit for kernel mappings. So set the
>> > contiguous
>> > bit in the kernel page mappings for regions whose size and alignment are
>> > suitable for this.
>> >
>> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>
>> Given the splitting is now gone, using the contiguous bit makes sense to
>> me.
>>
>> With 16K pages, we can have contiguous PMD entries. Should we handle
>> those,
>> too? e.g. have separate {PMD,PTE}_CONT{,_SIZE}?
>>
>> Otherwise, I have some comments below.
>
>
> Hi,
>
> So in arch/arm64/include/asm/pgtable-hwdef.h, we have:
> CONT_PTE_SHIFT
> CONT_PMD_SHIFT
> CONT_PTES
> CONT_PMDS
> CONT_PTE_SIZE
> CONT_PTE_MASK
> ...
>
> which are used by the contiguous hint HugeTLB code.
> Can those be adopted instead of CONT_MASK and CONT_SIZE?
>
That seems more appropriate, yes. I wonder why we have CONT_MASK and
CONT_SIZE in the first place then.
^ permalink raw reply
* [PATCH] arm64: mmu: set the contiguous for kernel mappings when appropriate
From: Ard Biesheuvel @ 2016-10-11 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011074419.GA20213@remoulade>
On 11 October 2016 at 08:44, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi Ard,
>
> On Mon, Oct 10, 2016 at 07:12:44PM +0100, Ard Biesheuvel wrote:
>> Now that we no longer allow live kernel PMDs to be split, it is safe to
>> start using the contiguous bit for kernel mappings. So set the contiguous
>> bit in the kernel page mappings for regions whose size and alignment are
>> suitable for this.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Given the splitting is now gone, using the contiguous bit makes sense to me.
>
> With 16K pages, we can have contiguous PMD entries. Should we handle those,
> too? e.g. have separate {PMD,PTE}_CONT{,_SIZE}?
>
Amusingly, this was exactly the feedback I gave to Jeremy when he
proposed this functionality originally. Yes, I think it makes sense,
especially for the linear mapping of system RAM. However, I think it
makes sense for someone else (with access to actual 16k granule
capable hardware) to contribute this functionality on top of this
patch.
> Otherwise, I have some comments below.
>
>> ---
>> arch/arm64/mm/mmu.c | 23 ++++++++++++++++++++---
>> 1 file changed, 20 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index 05615a3fdc6f..c491025c6a70 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -98,8 +98,11 @@ static phys_addr_t __init early_pgtable_alloc(void)
>> static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
>> unsigned long end, unsigned long pfn,
>> pgprot_t prot,
>> - phys_addr_t (*pgtable_alloc)(void))
>> + phys_addr_t (*pgtable_alloc)(void),
>> + bool allow_block_mappings)
>
> Not a big deal, but the 'block' part here and elsewhere is now arguably
> misleading (given 'block' is an architectural term).
>
> I haven't come up with a better term, so again, not a big deal. ;)
>
Indeed. I could simply call it 'allow_cont_mappings' in the context of
this function, and keep the call below as is.
>> {
>> + pgprot_t prot_cont = __pgprot(pgprot_val(prot) | PTE_CONT);
>> + bool cont = false;
>> pte_t *pte;
>>
>> BUG_ON(pmd_sect(*pmd));
>> @@ -115,7 +118,20 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
>>
>> pte = pte_set_fixmap_offset(pmd, addr);
>> do {
>> - set_pte(pte, pfn_pte(pfn, prot));
>> + /*
>> + * Set the contiguous bit for the subsequent group of PTEs if
>> + * its size and alignment are suitable.
>> + */
>> + if (((addr | PFN_PHYS(pfn)) & ~CONT_MASK) == 0)
>> + cont = allow_block_mappings && end - addr >= CONT_SIZE;
[...]
>> +
>> + /*
>> + * Ensure that we do not change the contiguous bit once this
>> + * PTE has been assigned.
>> + */
>> + BUG_ON(!pte_none(*pte) && (cont ^ !!(pte_val(*pte) & PTE_CONT)));
>
> IIRC, we only ever intended to mess with the AP bits when remapping an existing region.
>
> So we could mask those out and ensure everything else is identical, rather than
> checking the cont bit specifically. Likewise at the {PMD,PUD,PGD} level.
>
Yes, that should be better, I can put that in a separate preparatory patch.
>> +
>> + set_pte(pte, pfn_pte(pfn, cont ? prot_cont : prot));
>
> It would be clearer if we just assigned to a local pte_prot variable when
> checking allow_block_mappings and so on above (or split the loop as above).
>
Well, the local pte_prot variable's scope should still cover the
entire function, since cont does not change value at each iteration.
^ 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