* Re: [PATCH V5 0/7] 52-bit userspace VAs
From: Will Deacon @ 2018-12-10 19:34 UTC (permalink / raw)
To: Steve Capper
Cc: ard.biesheuvel, jcm, suzuki.poulose, linux-mm, catalin.marinas,
linux-arm-kernel
In-Reply-To: <20181206225042.11548-1-steve.capper@arm.com>
On Thu, Dec 06, 2018 at 10:50:35PM +0000, Steve Capper wrote:
> This patch series brings support for 52-bit userspace VAs to systems that
> have ARMv8.2-LVA and are running with a 48-bit VA_BITS and a 64KB
> PAGE_SIZE.
>
> If no hardware support is present, the kernel runs with a 48-bit VA space
> for userspace.
>
> Userspace can exploit this feature by providing an address hint to mmap
> where addr[51:48] != 0. Otherwise all the VA mappings will behave in the
> same way as a 48-bit VA system (this is to maintain compatibility with
> software that assumes the maximum VA size on arm64 is 48-bit).
>
> This patch series applies to 4.20-rc1.
>
> Testing was in a model with Trusted Firmware and UEFI for boot.
>
> Changed in V5, ttbr1 offsetting code simplified. Extra patch added to
> check for VA space support mismatch between CPUs.
I was all ready to push this out, but I spotted a build failure with
allmodconfig because TASK_SIZE refers to the non-EXPORTed symbol
vabits_user:
ERROR: "vabits_user" [lib/test_user_copy.ko] undefined!
ERROR: "vabits_user" [drivers/misc/lkdtm/lkdtm.ko] undefined!
ERROR: "vabits_user" [drivers/infiniband/hw/mlx5/mlx5_ib.ko] undefined!
So I've pushed an extra patch on top to fix that by exporting the symbol.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 6/6] arm64: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack
From: Steven Rostedt @ 2018-12-10 19:30 UTC (permalink / raw)
To: linux-kernel, linux-arch
Cc: Mark Rutland, Catalin Marinas, Will Deacon, Andrew Morton,
Ingo Molnar, linux-arm-kernel
In-Reply-To: <20181210193007.655970639@goodmis.org>
From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
[
Folks, I'm working on rewriting the function graph tracer. In order to
do so, some changes need to be done that affect architecture specific
code. I'm only able to compile test these changes. I would like to
have folks check out my repo and give them a test.
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
ftrace/core
Head SHA1: 51584396cff54aaf57ed0bd353767d71429f77b4
]
The structure of the ret_stack array on the task struct is going to
change, and accessing it directly via the curr_ret_stack index will no
longer give the ret_stack entry that holds the return address. To access
that, architectures must now use ftrace_graph_get_ret_stack() to get the
associated ret_stack that matches the saved return address.
Cc: linux-arm-kernel@lists.infradead.org
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
arch/arm64/kernel/perf_callchain.c | 2 +-
arch/arm64/kernel/process.c | 2 +-
arch/arm64/kernel/return_address.c | 2 +-
arch/arm64/kernel/stacktrace.c | 12 +++++++-----
arch/arm64/kernel/time.c | 2 +-
arch/arm64/kernel/traps.c | 2 +-
6 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kernel/perf_callchain.c b/arch/arm64/kernel/perf_callchain.c
index bcafd7dcfe8b..1b792b46604e 100644
--- a/arch/arm64/kernel/perf_callchain.c
+++ b/arch/arm64/kernel/perf_callchain.c
@@ -164,7 +164,7 @@ void perf_callchain_kernel(struct perf_callchain_entry_ctx *entry,
frame.fp = regs->regs[29];
frame.pc = regs->pc;
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
- frame.graph = current->curr_ret_stack;
+ frame.graph = 0;
#endif
walk_stackframe(current, &frame, callchain_trace, entry);
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index d9a4c2d6dd8b..37a66394b07d 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -459,7 +459,7 @@ unsigned long get_wchan(struct task_struct *p)
frame.fp = thread_saved_fp(p);
frame.pc = thread_saved_pc(p);
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
- frame.graph = p->curr_ret_stack;
+ frame.graph = 0;
#endif
do {
if (unwind_frame(p, &frame))
diff --git a/arch/arm64/kernel/return_address.c b/arch/arm64/kernel/return_address.c
index 933adbc0f654..53c40196b607 100644
--- a/arch/arm64/kernel/return_address.c
+++ b/arch/arm64/kernel/return_address.c
@@ -44,7 +44,7 @@ void *return_address(unsigned int level)
frame.fp = (unsigned long)__builtin_frame_address(0);
frame.pc = (unsigned long)return_address; /* dummy */
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
- frame.graph = current->curr_ret_stack;
+ frame.graph = 0;
#endif
walk_stackframe(current, &frame, save_return_addr, &data);
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 7723dadf25be..1a29f2695ff2 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -59,15 +59,17 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
if (tsk->ret_stack &&
(frame->pc == (unsigned long)return_to_handler)) {
- if (WARN_ON_ONCE(frame->graph == -1))
- return -EINVAL;
+ struct ftrace_ret_stack *ret_stack;
/*
* This is a case where function graph tracer has
* modified a return address (LR) in a stack frame
* to hook a function return.
* So replace it to an original value.
*/
- frame->pc = tsk->ret_stack[frame->graph--].ret;
+ ret_stack = ftrace_graph_get_ret_stack(tsk, frame->graph++);
+ if (WARN_ON_ONCE(!ret_stack))
+ return -EINVAL;
+ frame->pc = ret_stack->ret;
}
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
@@ -134,7 +136,7 @@ void save_stack_trace_regs(struct pt_regs *regs, struct stack_trace *trace)
frame.fp = regs->regs[29];
frame.pc = regs->pc;
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
- frame.graph = current->curr_ret_stack;
+ frame.graph = 0;
#endif
walk_stackframe(current, &frame, save_trace, &data);
@@ -165,7 +167,7 @@ static noinline void __save_stack_trace(struct task_struct *tsk,
frame.pc = (unsigned long)__save_stack_trace;
}
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
- frame.graph = tsk->curr_ret_stack;
+ frame.graph = 0;
#endif
walk_stackframe(tsk, &frame, save_trace, &data);
diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index f258636273c9..a777ae90044d 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -52,7 +52,7 @@ unsigned long profile_pc(struct pt_regs *regs)
frame.fp = regs->regs[29];
frame.pc = regs->pc;
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
- frame.graph = current->curr_ret_stack;
+ frame.graph = 0;
#endif
do {
int ret = unwind_frame(NULL, &frame);
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 5f4d9acb32f5..49ebf3771391 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -122,7 +122,7 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
frame.pc = thread_saved_pc(tsk);
}
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
- frame.graph = tsk->curr_ret_stack;
+ frame.graph = 0;
#endif
skip = !!regs;
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] arm64: dma-mapping: Fix FORCE_CONTIGUOUS buffer clearing
From: Robin Murphy @ 2018-12-10 19:33 UTC (permalink / raw)
To: will.deacon, catalin.marinas; +Cc: hch, linux-arm-kernel, m.szyprowski
We need to invalidate the caches *before* clearing the buffer via the
non-cacheable alias, else in the worst case __dma_flush_area() may
write back dirty lines over the top of our nice new zeros.
Fixes: dd65a941f6ba ("arm64: dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
arch/arm64/mm/dma-mapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index a3ac26284845..a53704406099 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -429,9 +429,9 @@ static void *__iommu_alloc_attrs(struct device *dev, size_t size,
prot,
__builtin_return_address(0));
if (addr) {
- memset(addr, 0, size);
if (!coherent)
__dma_flush_area(page_to_virt(page), iosize);
+ memset(addr, 0, size);
} else {
iommu_dma_unmap_page(dev, *handle, iosize, 0, attrs);
dma_release_from_contiguous(dev, page,
--
2.19.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h
From: David Miller @ 2018-12-10 19:33 UTC (permalink / raw)
To: hch
Cc: linux-parisc, ezequiel, vgupta, linux-mips, dri-devel, matwey,
iommu, openrisc, laurent.pinchart, sparclinux, linux-snps-arc,
robin.murphy, linux-arm-kernel, linux-media
In-Reply-To: <20181210192228.GB31178@lst.de>
From: Christoph Hellwig <hch@lst.de>
Date: Mon, 10 Dec 2018 20:22:28 +0100
> On Mon, Dec 10, 2018 at 10:10:39AM -0800, David Miller wrote:
>> From: Christoph Hellwig <hch@lst.de>
>> Date: Mon, 10 Dec 2018 17:32:56 +0100
>>
>> > Dave, can you pick the series up through the sparc tree? I could also
>> > merge it through the dma-mapping tree, but given that there is no
>> > dependency on it the sparc tree seem like the better fit.
>>
>> I thought that some of this is a prerequisite for the DMA mapping
>> work and overall consolidation you are doing. So I kinda assumed
>> you wanted to merge it via your tree.
>>
>> I anticipate no conflicts at all, even until the next merge window,
>> so it could very easily go through your tree.
>>
>> Let me know if you still want me to merge this.
>
> These patches are purely cleanups I found while auditing the DMA
> mapping code, at least as of now there are no dependencies.
>
> That being said now that I looked into it a bit more they do however
> depend on the ->mapping_error removal, so I'll take them through
> the dma-mapping tree.
Ok, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 6/8] regulator: dts: enable soft-start and ramp delay for the OLinuXino Lime2
From: Priit Laes @ 2018-12-10 18:42 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Mark Rutland, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood, Mark Brown, devicetree, linux-kernel,
linux-arm-kernel, Olliver Schinagl, linux-sunxi
Cc: Priit Laes
In-Reply-To: <cover.4110554ae84987dedb8b58888a8a63d6b7f98c72.1544466940.git-series.plaes@plaes.org>
From: Olliver Schinagl <oliver@schinagl.nl>
The OLinuXino Lime2 has a big capacitor on its LDO3 output. It is
actually too large, causing the PMIC to shutdown when toggling the LDO3.
By enabling soft-start and ramp delay we increase the time for the
capacitor to charge lowering the current drain on the power regulator.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Priit Laes <plaes@plaes.org>
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index 55c9086..4e1c590 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -232,6 +232,8 @@
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-name = "vddio-csi0";
+ regulator-soft-start;
+ regulator-ramp-delay = <1600>;
};
®_ldo4 {
--
git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 6/6] sparc: merge 32-bit and 64-bit version of pci.h
From: Christoph Hellwig @ 2018-12-10 19:22 UTC (permalink / raw)
To: David Miller
Cc: linux-parisc, ezequiel, vgupta, linux-mips, dri-devel, matwey,
iommu, openrisc, laurent.pinchart, sparclinux, linux-snps-arc,
robin.murphy, hch, linux-arm-kernel, linux-media
In-Reply-To: <20181210.101039.1882227517259366533.davem@davemloft.net>
On Mon, Dec 10, 2018 at 10:10:39AM -0800, David Miller wrote:
> From: Christoph Hellwig <hch@lst.de>
> Date: Mon, 10 Dec 2018 17:32:56 +0100
>
> > Dave, can you pick the series up through the sparc tree? I could also
> > merge it through the dma-mapping tree, but given that there is no
> > dependency on it the sparc tree seem like the better fit.
>
> I thought that some of this is a prerequisite for the DMA mapping
> work and overall consolidation you are doing. So I kinda assumed
> you wanted to merge it via your tree.
>
> I anticipate no conflicts at all, even until the next merge window,
> so it could very easily go through your tree.
>
> Let me know if you still want me to merge this.
These patches are purely cleanups I found while auditing the DMA
mapping code, at least as of now there are no dependencies.
That being said now that I looked into it a bit more they do however
depend on the ->mapping_error removal, so I'll take them through
the dma-mapping tree.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V6 0/9] clk: add imx7ulp clk support
From: Stephen Boyd @ 2018-12-10 19:20 UTC (permalink / raw)
To: Shawn Guo
Cc: Aisheng DONG, Jacky Bai, Anson Huang, mturquette@baylibre.com,
linux-kernel@vger.kernel.org, dl-linux-imx,
linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181210081454.GQ3987@dragon>
Quoting Shawn Guo (2018-12-10 00:14:56)
> On Wed, Dec 05, 2018 at 11:41:01AM -0800, Stephen Boyd wrote:
> > No worries, I fixed it up and merged to clk-next.
>
> Hi Stephen,
>
> In order to send imx7ulp device tree for 4.21, I pulled branch
> clk-imx7ulp into IMX tree to resolve the dependency on clock ID
> definitions. So please keep the branch stable, thanks.
>
Ok. No problem. Thanks for letting me know.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clk: sunxi-ng: a64: Allow parent change for VE clock
From: Stephen Boyd @ 2018-12-10 19:19 UTC (permalink / raw)
To: Jernej Skrabec, Maxime Ripard
Cc: linux-sunxi, linux-kernel, linux-clk, wens, mturquette,
linux-arm-kernel
In-Reply-To: <20181210124049.py2auqlgd37rbwfo@flea>
Quoting Maxime Ripard (2018-12-10 04:40:49)
> On Sat, Dec 08, 2018 at 07:02:22PM +0100, Jernej Skrabec wrote:
> > Cedrus driver wants to set VE clock higher than it's possible without
> > changing parent rate.
> >
> > Allow changing parent rate for VE clock, so clock rate can be set
> > freely.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>
> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
>
> Stephen, Mike, could you apply that patch directly?
>
Sure. Applied to clk-allwinner and merged up.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 22/25] ACPI / APEI: Kick the memory_failure() queue for synchronous errors
From: James Morse @ 2018-12-10 19:15 UTC (permalink / raw)
To: Xie XiuQi
Cc: Rafael Wysocki, Tony Luck, Fan Wu, linux-mm, Marc Zyngier,
Catalin Marinas, Will Deacon, Christoffer Dall, Dongjiu Geng,
Wang Xiongfeng, linux-acpi, Borislav Petkov, Naoya Horiguchi,
kvmarm, linux-arm-kernel, Len Brown
In-Reply-To: <9d153a07-aa7a-6e0c-3bd3-994a66f9639a@huawei.com>
Hi Xie XiuQi,
On 05/12/2018 02:02, Xie XiuQi wrote:
> On 2018/12/4 2:06, James Morse wrote:
>> memory_failure() offlines or repairs pages of memory that have been
>> discovered to be corrupt. These may be detected by an external
>> component, (e.g. the memory controller), and notified via an IRQ.
>> In this case the work is queued as not all of memory_failure()s work
>> can happen in IRQ context.
>>
>> If the error was detected as a result of user-space accessing a
>> corrupt memory location the CPU may take an abort instead. On arm64
>> this is a 'synchronous external abort', and on a firmware first
>> system it is replayed using NOTIFY_SEA.
>>
>> This notification has NMI like properties, (it can interrupt
>> IRQ-masked code), so the memory_failure() work is queued. If we
>> return to user-space before the queued memory_failure() work is
>> processed, we will take the fault again. This loop may cause platform
>> firmware to exceed some threshold and reboot when Linux could have
>> recovered from this error.
>>
>> If a ghes notification type indicates that it may be triggered again
>> when we return to user-space, use the task-work and notify-resume
>> hooks to kick the relevant memory_failure() queue before returning
>> @@ -407,7 +447,22 @@ static void ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, int
>>
>> if (flags != -1)
>> memory_failure_queue(pfn, flags);
>
> We may need to take MF_ACTION_REQUIRED flags for memory_failure() in SEA condition.
Hmmm, I'd forgotten about the extra flags. They're only used by x86's
do_machine_check(), which knows more about what is going on. I agree we do know
it should be a 'MF_ACTION_REQUIRED' for Synchronous-external-abort, but I'd
really like all the notifications to behave in the same way as we can't change
which notification firmware uses.
(This ghes_is_synchronous() affects when memory_failure() runs, not what it does.)
What happens if we miss MF_ACTION_REQUIRED? Surely the page still gets unmapped
as its PG_Poisoned, an AO signal may be pending, but if user-space touches the
page it will get an AR signal. Is this just about removing an extra AO signal to
user-space?
If we do need this, I'd like to pick it up from the CPER records, as x86's
NOTIFY_NMI looks like it covers both AO/AR cases. (as does NOTIFY_SDEI). The
Master/Target abort or Invalid-address types in the memory-error-section CPER
records look like the best bet.
> And there is no return value check for memory_failure() in memory_failure_work_func(),
> I'm not sure whether we need to check the return value.
What would we do if it fails? The reasons look fairly broad, -EBUSY can mean
"(page) still referenced by [..] users", 'thp split failed' or 'page already
poisoned'. I don't think the behaviour or return-codes are consistent enough to use.
> If the recovery fails here, we need to take other actions, such as force to send a SIGBUS signal.
We don't do this today. If it fixes some mis-behaviour, and we can key it from
something in the CPER records then I'm all ears!
Thanks,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/5] Add support for STM32F4 SPI
From: Cezary Gapiński @ 2018-12-10 19:05 UTC (permalink / raw)
To: Amelie DELAUNAY, Mark Brown, linux-spi@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Rob Herring,
devicetree@vger.kernel.org
Cc: Mark Rutland, Alexandre TORGUE, Maxime Coquelin
In-Reply-To: <ede8544f-c71d-0901-5522-e97215d23f85@st.com>
Hi Amelie,
On Mon, 2018-12-10 at 12:37 +0000, Amelie DELAUNAY wrote:
> Hi Cezary,
>
> On 12/9/18 2:53 PM, cezary.gapinski@gmail.com wrote:
> >
> > From: Cezary Gapinski <cezary.gapinski@gmail.com>
> >
> > This series of patches adds support for first generation of SPI
> > interface
> > for STM32F4 family.
> >
> First of all, thanks for adding STM32F4 SPI support.
Thanks for your answer and hints for correct approach to this driver.
> >
> > This version of driver is mostly different to STM32H7 one. Based on
> > linux
> > kernel I2C drivers for STM32 where drivers were splited into
> > STM32F4 and
> > STM32F7 family the same approach seems to be sufficient for SPI
> > STM32
> > drivers. Therefore STM32H7 driver was moved to spi-stm32h7.c file
> > and
> > register and functions were renamed to be more specific to STM32H7.
> >
> You're right, STM32F4 SPI is slightly different from STM32H7 one:
> register map/bits offsets are different and STM32H7 has an RX and TX
> FIFO.
> But if you have a look on STM32F7 SPI [1], you'll see that STM32F7
> SPI
> is based on STM32F4 SPI with new features (data frames & FIFOs) also
> available on STM32H7 SPI.
>
> That's why STM32H7 SPI driver was called spi-stm32. The goal was to
> use
> compatible & match data to differentiate each STM32Fx specificities.
>
> You can have a look on how it is managed in drivers/rtc/rtc-stm32.c
> (the
> same driver covers 2 HW version of STM32 RTC), or in
> drivers/iio/dac/stm32-dac-core.c and stm32-dac.c (the same driver
> also
> covers 2 HW version of STM32 DAC).
> As your spi-stm32f4.c file is highly based on the existing spi-
> stm32.c
> file, I think that common code could be factored and specificities
> could
> be handled with compatible and match data.
I have seen these drivers before. I have been trying to do this for my
previous approach and it is still on my second branch. There was not
too much common parts and I have stuck with complex compatible data
configurations. I thought that was too verbose, therefore I resigned
for it and have gone into idea with two totally different files. I
think I need to get down again to idea you proposed.
It seems to be more difficult approach and it is gonna take a while
before I send second version of these patches.
Regards,
Cezary
> Regards,
> Amelie
> [1]
> https://www.st.com/content/ccc/resource/technical/document/reference_
> manual/c5/cf/ef/52/c0/f1/4b/fa/DM00124865.pdf/files/DM00124865.pdf/jc
> r:content/translations/en.DM00124865.pdf
>
> >
> > For current version master mode with full-duplex and 8/16 bit data
> > frame
> > format are supported. There is no TX and RX FIFOs like in STM32H7.
> > DMA capabilility is supported for messages longer than arbitrary
> > number
> > of bytes (that is set already to 16 bytes) when TX and RX channels
> > are
> > set at the same time.
> >
> > Cezary Gapinski (5):
> > spi: stm32: rename STM32 SPI registers and functions to STM32H7
> > spi: stm32: rename spi-stm32 to spi-stm32h7
> > spi: stm32: add driver for STM32F4 controller
> > ARM: dts: stm32: add SPI support on STM32F429 SoC
> > spi: stm32: add description about STM32F4 bindings
> >
> > .../devicetree/bindings/spi/spi-stm32.txt | 9 +-
> > arch/arm/boot/dts/stm32f429.dtsi | 60 +
> > drivers/spi/Kconfig | 18 +-
> > drivers/spi/Makefile | 3 +-
> > drivers/spi/spi-stm32.c | 1322 -----
> > --------------
> > drivers/spi/spi-stm32f4.c | 1002
> > +++++++++++++++
> > drivers/spi/spi-stm32h7.c | 1340
> > ++++++++++++++++++++
> > 7 files changed, 2424 insertions(+), 1330 deletions(-)
> > delete mode 100644 drivers/spi/spi-stm32.c
> > create mode 100644 drivers/spi/spi-stm32f4.c
> > create mode 100644 drivers/spi/spi-stm32h7.c
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] Qualcomm Driver updates for 4.21 - Part 2
From: Andy Gross @ 2018-12-10 19:05 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: Arnd Bergmann, linux-arm-msm, linux-kernel, Bjorn Andersson, arm,
Kevin Hilman, Olof Johansson, linux-arm-kernel
In-Reply-To: <c575fb97-4b19-5143-66f8-3a4874aa7c17@linaro.org>
On Mon, Dec 10, 2018 at 02:20:47PM +0200, Stanimir Varbanov wrote:
> Hi Andy,
>
> On 12/8/18 7:13 AM, Andy Gross wrote:
> > The following changes since commit b601f73130a375c912d9f2ec93c5f3cea5d6a3da:
> >
> > drm: msm: Check cmd_db_read_aux_data() for failure (2018-11-29 17:41:53 -0600)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-drivers-for-4.21-2
> >
> > for you to fetch changes up to 92def04bd7b46f5b186f985d5c9d3804858c3c2f:
> >
> > MAINTAINERS: Change Todor Tomov's email address (2018-12-05 16:45:34 -0600)
> >
> > ----------------------------------------------------------------
> > Qualcomm ARM Based Driver Updates for v4.21 Part 2
> >
> > * Fix MAINTAINERS email address for Todor
> > * Fix SCM compilation error
> >
> > ----------------------------------------------------------------
> > Jonathan Marek (1):
> > firmware: qcom: scm: fix compilation error when disabled
> >
> > Todor Tomov (1):
> > MAINTAINERS: Change Todor Tomov's email address
>
> I saw this patch is applied also in media_tree.git, not sure that is
> problem though.
Which one? The maintainer or the scm?
Andy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: dma_declare_coherent_memory on main memory
From: Christoph Hellwig @ 2018-12-10 19:02 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-sh, linux-kernel, iommu, linux-imx, Fabio Estevam,
Shawn Guo, Christoph Hellwig, linux-arm-kernel
In-Reply-To: <20181210072648.ore6xttedsgpndi4@pengutronix.de>
On Mon, Dec 10, 2018 at 08:26:48AM +0100, Sascha Hauer wrote:
> > the ARM imx27/31 ports and various sh boards use
> > dma_declare_coherent_memory on main memory taken from the memblock
> > allocator.
> >
> > Is there any good reason these couldn't be switched to CMA areas?
> > Getting rid of these magic dma_declare_coherent_memory area would
> > help making the dma allocator a lot simpler.
>
> At least for i.MX27/31 I'd say this predates CMA support, so historical
> reasons.
Ok. Do you still have test hardware for i.MX? If so I'd love to see
if the patch below works. Note that this is the brute force approach,
just having a global CMA pool might be a little more elegant.
diff --git a/arch/arm/configs/imx_v4_v5_defconfig b/arch/arm/configs/imx_v4_v5_defconfig
index 8661dd9b064a..88852e7e5e7e 100644
--- a/arch/arm/configs/imx_v4_v5_defconfig
+++ b/arch/arm/configs/imx_v4_v5_defconfig
@@ -185,3 +185,5 @@ CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_15=m
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
+CONFIG_CMA=y
+CONFIG_DMA_CMA=y
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 1ad5736c8fa6..16c8d717316c 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -444,3 +444,5 @@ CONFIG_PROVE_LOCKING=y
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_FTRACE is not set
# CONFIG_ARM_UNWIND is not set
+CONFIG_CMA=y
+CONFIG_DMA_CMA=y
diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index 5169dfba9718..2339a50d5459 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -23,6 +23,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include <linux/cma.h>
#include <linux/platform_device.h>
#include <linux/mtd/physmap.h>
#include <linux/i2c.h>
@@ -35,6 +36,7 @@
#include <linux/platform_data/asoc-mx27vis.h>
#include <media/soc_camera.h>
#include <sound/tlv320aic32x4.h>
+#include <asm/dma-contiguous.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
#include <asm/mach/time.h>
@@ -245,6 +247,7 @@ static phys_addr_t mx2_camera_base __initdata;
static void __init visstrim_analog_camera_init(void)
{
struct platform_device *pdev;
+ struct cma *cma;
gpio_set_value(TVP5150_PWDN, 1);
ndelay(1);
@@ -257,9 +260,10 @@ static void __init visstrim_analog_camera_init(void)
if (IS_ERR(pdev))
return;
- dma_declare_coherent_memory(&pdev->dev, mx2_camera_base,
- mx2_camera_base, MX2_CAMERA_BUF_SIZE,
- DMA_MEMORY_EXCLUSIVE);
+ if (cma_init_reserved_mem(mx2_camera_base, MX2_CAMERA_BUF_SIZE, 0,
+ "visstrim-cam", &cma))
+ return;
+ dma_contiguous_early_fixup(mx2_camera_base, MX2_CAMERA_BUF_SIZE);
}
static void __init visstrim_reserve(void)
@@ -440,13 +444,16 @@ static const struct imx_ssi_platform_data visstrim_m10_ssi_pdata __initconst = {
static void __init visstrim_coda_init(void)
{
struct platform_device *pdev;
+ struct cma *cma;
pdev = imx27_add_coda();
- dma_declare_coherent_memory(&pdev->dev,
- mx2_camera_base + MX2_CAMERA_BUF_SIZE,
- mx2_camera_base + MX2_CAMERA_BUF_SIZE,
- MX2_CAMERA_BUF_SIZE,
- DMA_MEMORY_EXCLUSIVE);
+ if (IS_ERR(pdev))
+ return;
+ if (cma_init_reserved_mem(mx2_camera_base + MX2_CAMERA_BUF_SIZE,
+ MX2_CAMERA_BUF_SIZE, 0, "visstrim-coda", &cma))
+ return;
+ dma_contiguous_early_fixup(mx2_camera_base + MX2_CAMERA_BUF_SIZE,
+ MX2_CAMERA_BUF_SIZE);
}
/* DMA deinterlace */
@@ -459,21 +466,22 @@ static void __init visstrim_deinterlace_init(void)
{
int ret = -ENOMEM;
struct platform_device *pdev = &visstrim_deinterlace;
+ struct cma *cma;
ret = platform_device_register(pdev);
- dma_declare_coherent_memory(&pdev->dev,
- mx2_camera_base + 2 * MX2_CAMERA_BUF_SIZE,
- mx2_camera_base + 2 * MX2_CAMERA_BUF_SIZE,
- MX2_CAMERA_BUF_SIZE,
- DMA_MEMORY_EXCLUSIVE);
+ if (cma_init_reserved_mem(mx2_camera_base + 2 * MX2_CAMERA_BUF_SIZE,
+ MX2_CAMERA_BUF_SIZE, 0, "visstrim-deinterlace", &cma))
+ return;
+ dma_contiguous_early_fixup(mx2_camera_base + 2 * MX2_CAMERA_BUF_SIZE,
+ MX2_CAMERA_BUF_SIZE);
}
/* Emma-PrP for format conversion */
static void __init visstrim_emmaprp_init(void)
{
struct platform_device *pdev;
- int ret;
+ struct cma *cma;
pdev = imx27_add_mx2_emmaprp();
if (IS_ERR(pdev))
@@ -483,12 +491,12 @@ static void __init visstrim_emmaprp_init(void)
* Use the same memory area as the analog camera since both
* devices are, by nature, exclusive.
*/
- ret = dma_declare_coherent_memory(&pdev->dev,
- mx2_camera_base, mx2_camera_base,
- MX2_CAMERA_BUF_SIZE,
- DMA_MEMORY_EXCLUSIVE);
- if (ret)
+ if (cma_init_reserved_mem(mx2_camera_base, MX2_CAMERA_BUF_SIZE, 0,
+ "visstrim-emmaprp", &cma)) {
pr_err("Failed to declare memory for emmaprp\n");
+ return;
+ }
+ dma_contiguous_early_fixup(mx2_camera_base, MX2_CAMERA_BUF_SIZE);
}
/* Audio */
diff --git a/arch/arm/mach-imx/mach-mx31moboard.c b/arch/arm/mach-imx/mach-mx31moboard.c
index 643a3d749703..1c0705ec0ccd 100644
--- a/arch/arm/mach-imx/mach-mx31moboard.c
+++ b/arch/arm/mach-imx/mach-mx31moboard.c
@@ -13,6 +13,7 @@
*/
#include <linux/delay.h>
+#include <linux/cma.h>
#include <linux/dma-mapping.h>
#include <linux/gfp.h>
#include <linux/gpio.h>
@@ -37,6 +38,7 @@
#include <linux/usb/otg.h>
#include <linux/usb/ulpi.h>
+#include <asm/dma-contiguous.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
#include <asm/mach/time.h>
@@ -466,6 +468,7 @@ static int __init mx31moboard_init_cam(void)
{
int ret;
struct platform_device *pdev;
+ struct cma *cma;
imx31_add_ipu_core();
@@ -473,18 +476,18 @@ static int __init mx31moboard_init_cam(void)
if (IS_ERR(pdev))
return PTR_ERR(pdev);
- ret = dma_declare_coherent_memory(&pdev->dev,
- mx3_camera_base, mx3_camera_base,
- MX3_CAMERA_BUF_SIZE,
- DMA_MEMORY_EXCLUSIVE);
+ ret = cma_init_reserved_mem(mx3_camera_base, MX3_CAMERA_BUF_SIZE, 0,
+ "mx31cam", &cma);
if (ret)
- goto err;
+ goto out_device_put;
+ dma_contiguous_early_fixup(mx3_camera_base, MX3_CAMERA_BUF_SIZE);
ret = platform_device_add(pdev);
if (ret)
-err:
- platform_device_put(pdev);
-
+ goto out_device_put;
+ return 0;
+out_device_put:
+ platform_device_put(pdev);
return ret;
}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/8] dt-bindings: mfd: axp20x: Add software based soft_start for AXP209 LDO3
From: Priit Laes @ 2018-12-10 18:42 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Mark Rutland, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood, Mark Brown, devicetree, linux-kernel,
linux-arm-kernel, Olliver Schinagl, linux-sunxi
Cc: Priit Laes
In-Reply-To: <cover.4110554ae84987dedb8b58888a8a63d6b7f98c72.1544466940.git-series.plaes@plaes.org>
From: Olliver Schinagl <oliver@schinagl.nl>
In the past, there have been words on various lists that if LDO3 is
disabled in u-boot, but enabled in the DTS, the axp209 driver would
fail to continue/hang. Several enable/disable patches have been
issues to devicetree's in both the kernel and u-boot to address
this issue.
What really happened however, was that the AXP209 shuts down without
a notice and without setting an interrupt. This is caused when LDO3
gets overloaded, for example with large capacitors on the LDO3 output.
Normally, we would expect that AXP209 would source 200 mA as per
datasheet and set and trigger an interrupt when being overloaded.
For some reason however, this does not happen.
As a work-around, implement software-based 'regulator-soft-start'
property for AXP209 LDO3 regulator, which is used to first bring up
the LDO3 to the lowest possible voltage and then enable the LDO.
After that, we can set the requested voltage as usual.
Combining this setting with the regulator-ramp-delay allows LDO3 to
come up slowly and staggered, potentially reducing overall inrush current.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Priit Laes <plaes@plaes.org>
---
Documentation/devicetree/bindings/mfd/axp20x.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
index c626605..2af4ff9 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -37,6 +37,9 @@ more information:
- regulator-ramp-delay: sets the ramp up delay in uV/us
AXP20x/DCDC2: 1600, 800
AXP20x/LDO3: 1600, 800
+- regulator-soft-start: enable the output at the lowest possible voltage and
+ only then set the desired voltage
+ AXP20x/LDO3: software-based implementation
Optional properties:
- x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
--
git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/8] regulator: axp20x: add software based soft_start for AXP209 LDO3
From: Priit Laes @ 2018-12-10 18:42 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Mark Rutland, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood, Mark Brown, devicetree, linux-kernel,
linux-arm-kernel, Olliver Schinagl, linux-sunxi
Cc: Priit Laes
In-Reply-To: <cover.4110554ae84987dedb8b58888a8a63d6b7f98c72.1544466940.git-series.plaes@plaes.org>
From: Olliver Schinagl <oliver@schinagl.nl>
In the past, there have been words on various lists that if LDO3 is
disabled in u-boot, but enabled in the DTS, the axp209 driver would
fail to continue/hang. Several enable/disable patches have been
issues to devicetree's in both the kernel and u-boot to address
this issue.
What really happened however, was that the AXP209 shuts down without
a notice and without setting an interrupt. This is caused when LDO3
gets overloaded, for example with large capacitors on the LDO3 output.
Normally, we would expect that AXP209 would source 200 mA as per
datasheet and set and trigger an interrupt when being overloaded.
For some reason however, this does not happen.
As a work-around, we use the soft-start constraint of the regulator
node to first bring up the LDO3 to the lowest possible voltage and
then enable the LDO. After that, we can set the requested voltage
as usual.
Combining this setting with the regulator-ramp-delay allows LDO3 to
enable voltage slowly and staggered, potentially reducing overall
inrush current.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Priit Laes <plaes@plaes.org>
---
drivers/regulator/axp20x-regulator.c | 57 ++++++++++++++++++++++++++++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 1d9fa62..e8a895b 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -14,6 +14,7 @@
*/
#include <linux/bitops.h>
+#include <linux/delay.h>
#include <linux/err.h>
#include <linux/init.h>
#include <linux/mfd/axp20x.h>
@@ -23,6 +24,7 @@
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
#include <linux/regulator/of_regulator.h>
#define AXP20X_GPIO0_FUNC_MASK GENMASK(3, 0)
@@ -430,6 +432,59 @@ static int axp20x_set_ramp_delay(struct regulator_dev *rdev, int ramp)
return regmap_update_bits(axp20x->regmap, reg, mask, cfg);
}
+static int axp20x_regulator_enable_regmap(struct regulator_dev *rdev)
+{
+ struct axp20x_dev *axp20x = rdev_get_drvdata(rdev);
+ const struct regulator_desc *desc = rdev->desc;
+
+ if (!rdev)
+ return -EINVAL;
+
+ switch (axp20x->variant) {
+ case AXP209_ID:
+ if ((desc->id == AXP20X_LDO3) &&
+ rdev->constraints && rdev->constraints->soft_start) {
+ int v_out;
+ int ret;
+
+ /*
+ * On some boards, the LDO3 can be overloaded when
+ * turning on, causing the entire PMIC to shutdown
+ * without warning. Turning it on at the minimal voltage
+ * and then setting the voltage to the requested value
+ * works reliably.
+ */
+ if (regulator_is_enabled_regmap(rdev))
+ break;
+
+ v_out = regulator_get_voltage_sel_regmap(rdev);
+ if (v_out < 0)
+ return v_out;
+
+ if (v_out == 0)
+ break;
+
+ ret = regulator_set_voltage_sel_regmap(rdev, 0x00);
+ /*
+ * A small pause is needed between
+ * setting the voltage and enabling the LDO to give the
+ * internal state machine time to process the request.
+ */
+ usleep_range(1000, 5000);
+ ret |= regulator_enable_regmap(rdev);
+ ret |= regulator_set_voltage_sel_regmap(rdev, v_out);
+
+ return ret;
+ }
+ break;
+ default:
+ /* No quirks */
+ break;
+ }
+
+ return regulator_enable_regmap(rdev);
+};
+
static const struct regulator_ops axp20x_ops_fixed = {
.list_voltage = regulator_list_voltage_linear,
};
@@ -447,7 +502,7 @@ static const struct regulator_ops axp20x_ops = {
.set_voltage_sel = regulator_set_voltage_sel_regmap,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
.list_voltage = regulator_list_voltage_linear,
- .enable = regulator_enable_regmap,
+ .enable = axp20x_regulator_enable_regmap,
.disable = regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
.set_ramp_delay = axp20x_set_ramp_delay,
--
git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/8] This is a second edition of a series that implements voltage
From: Priit Laes @ 2018-12-10 18:42 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Mark Rutland, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood, Mark Brown, devicetree, linux-kernel,
linux-arm-kernel, Olliver Schinagl, linux-sunxi
Cc: Priit Laes
ramping for AXP209 DCDC2 and LDO3 regulators and software
based soft-start for AXP209 LDO3 regulator.
Both features are needed to work around a PMIC shutdown when
toggling LDO3 on certain boards with high capacitance on the
LDO3 output.
Similar features (or workarounds) have been also implemented
on u-boot side [1].
Changes since v1:
- Rebased on top of next and dropped already merged patches.
- Dropped LDO4 full range devicetree change for Lime2 (prev patch 9)
in favor of general pin-bank regulator dependency [2].
- Fixed paths in devicetree bindings (patch 3)
- Added note about software based soft-start for LDO3 (patch 5)
[1] https://lists.denx.de/pipermail/u-boot/2018-November/348612.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-December/618459.html
Olliver Schinagl (8):
mfd: axp20x: name voltage ramping define properly
regulator: axp20x: add support for set_ramp_delay for AXP209
dt-bindings: mfd: axp20x: add support for regulator-ramp-delay for AXP209
regulator: axp20x: add software based soft_start for AXP209 LDO3
dt-bindings: mfd: axp20x: Add software based soft_start for AXP209 LDO3
regulator: dts: enable soft-start and ramp delay for the OLinuXino Lime2
mfd: axp20x: Clean up included headers
mfd: axp20x: use explicit bit defines
Documentation/devicetree/bindings/mfd/axp20x.txt | 9 +-
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 2 +-
drivers/mfd/axp20x.c | 13 +-
drivers/regulator/axp20x-regulator.c | 142 +++++++++++++++-
include/linux/mfd/axp20x.h | 4 +-
5 files changed, 161 insertions(+), 9 deletions(-)
base-commit: 14cf8c1d5b90a0cf6a8ba51ef59db8da8c7a2622
--
git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 7/8] mfd: axp20x: Clean up included headers
From: Priit Laes @ 2018-12-10 18:42 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Mark Rutland, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood, Mark Brown, devicetree, linux-kernel,
linux-arm-kernel, Olliver Schinagl, linux-sunxi
Cc: Priit Laes
In-Reply-To: <cover.4110554ae84987dedb8b58888a8a63d6b7f98c72.1544466940.git-series.plaes@plaes.org>
From: Olliver Schinagl <oliver@schinagl.nl>
Add the bitops.h header as we need it, alphabetize header order.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Priit Laes <plaes@plaes.org>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/axp20x.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index dfc3cff..c3f3dbd 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -16,18 +16,19 @@
* published by the Free Software Foundation.
*/
-#include <linux/err.h>
+#include <linux/acpi.h>
+#include <linux/bitops.h>
#include <linux/delay.h>
+#include <linux/err.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
+#include <linux/mfd/axp20x.h>
+#include <linux/mfd/core.h>
#include <linux/module.h>
+#include <linux/of_device.h>
#include <linux/pm_runtime.h>
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
-#include <linux/mfd/axp20x.h>
-#include <linux/mfd/core.h>
-#include <linux/of_device.h>
-#include <linux/acpi.h>
#define AXP20X_OFF 0x80
--
git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 8/8] mfd: axp20x: use explicit bit defines
From: Priit Laes @ 2018-12-10 18:42 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Mark Rutland, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood, Mark Brown, devicetree, linux-kernel,
linux-arm-kernel, Olliver Schinagl, linux-sunxi
Cc: Priit Laes
In-Reply-To: <cover.4110554ae84987dedb8b58888a8a63d6b7f98c72.1544466940.git-series.plaes@plaes.org>
From: Olliver Schinagl <oliver@schinagl.nl>
The AXP20X_OFF define is an actual specific bit, define it as such.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Priit Laes <plaes@plaes.org>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/axp20x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index c3f3dbd..d183ed8 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -30,7 +30,7 @@
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
-#define AXP20X_OFF 0x80
+#define AXP20X_OFF BIT(7)
#define AXP806_REG_ADDR_EXT_ADDR_MASTER_MODE 0
#define AXP806_REG_ADDR_EXT_ADDR_SLAVE_MODE BIT(4)
--
git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/8] dt-bindings: mfd: axp20x: add support for regulator-ramp-delay for AXP209
From: Priit Laes @ 2018-12-10 18:42 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Mark Rutland, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood, Mark Brown, devicetree, linux-kernel,
linux-arm-kernel, Olliver Schinagl, linux-sunxi
Cc: Priit Laes
In-Reply-To: <cover.4110554ae84987dedb8b58888a8a63d6b7f98c72.1544466940.git-series.plaes@plaes.org>
From: Olliver Schinagl <oliver@schinagl.nl>
The AXP209 supports ramping up voltages on several regulators such as
DCDC2 and LDO3, therefore we can use the standard 'regulator-ramp-delay'
property for those 2 regulators.
Note that the voltage ramp only works when the regulator is already
enabled. E.g. when going from say 0.7 V to 3.6 V.
When turning on the regulator, no voltage ramp is performed in hardware.
What this means, is that if the bootloader brings up the voltage at 0.7 V,
the ramp delay property is properly applied. If however, the bootloader
leaves the power off, no ramp delay is applied when the power is
enabled by the regulator framework.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Priit Laes <plaes@plaes.org>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
---
Documentation/devicetree/bindings/mfd/axp20x.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 188f037..c626605 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -32,6 +32,12 @@ Required properties:
- interrupt-controller: The PMIC has its own internal IRQs
- #interrupt-cells: Should be set to 1
+Supported common regulator properties, see ../regulator/regulator.txt for
+more information:
+- regulator-ramp-delay: sets the ramp up delay in uV/us
+ AXP20x/DCDC2: 1600, 800
+ AXP20x/LDO3: 1600, 800
+
Optional properties:
- x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
AXP152/20X: range: 750-1875, Default: 1.5 MHz
--
git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/8] regulator: axp20x: add support for set_ramp_delay for AXP209
From: Priit Laes @ 2018-12-10 18:42 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Mark Rutland, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood, Mark Brown, devicetree, linux-kernel,
linux-arm-kernel, Olliver Schinagl, linux-sunxi
Cc: Priit Laes
In-Reply-To: <cover.4110554ae84987dedb8b58888a8a63d6b7f98c72.1544466940.git-series.plaes@plaes.org>
From: Olliver Schinagl <oliver@schinagl.nl>
The AXP209 supports ramping up voltages on several regulators such as
DCDC2 and LDO3.
This patch adds preliminary support for the regulator-ramp-delay property
for these 2 regulators. Note that the voltage ramp only works when
regulator is already enabled. E.g. when going from say 0.7 V to 3.6 V.
When turning on the regulator, no voltage ramp is performed in hardware.
What this means, is that if the bootloader brings up the voltage at 0.7 V,
the ramp delay property is properly applied. If however, the bootloader
leaves the power off, no ramp delay is applied when the power is
enabled by the regulator framework.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Priit Laes <plaes@plaes.org>
---
drivers/regulator/axp20x-regulator.c | 85 +++++++++++++++++++++++++++++-
1 file changed, 85 insertions(+)
diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 9a2db28..1d9fa62 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -51,6 +51,17 @@
#define AXP20X_PWR_OUT_DCDC2_MASK BIT_MASK(4)
#define AXP20X_PWR_OUT_LDO3_MASK BIT_MASK(6)
+#define AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_RATE_MASK BIT_MASK(0)
+#define AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_RATE(x) \
+ ((x) << 0)
+#define AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE_MASK BIT_MASK(1)
+#define AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE(x) \
+ ((x) << 1)
+#define AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN_MASK BIT_MASK(2)
+#define AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN BIT(2)
+#define AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN_MASK BIT_MASK(3)
+#define AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN BIT(3)
+
#define AXP20X_LDO4_V_OUT_1250mV_START 0x0
#define AXP20X_LDO4_V_OUT_1250mV_STEPS 0
#define AXP20X_LDO4_V_OUT_1250mV_END \
@@ -346,6 +357,79 @@
.ops = &axp20x_ops_range, \
}
+static const int axp209_dcdc2_ldo3_slew_rates[] = {
+ 1600,
+ 800,
+};
+
+static int axp20x_set_ramp_delay(struct regulator_dev *rdev, int ramp)
+{
+ struct axp20x_dev *axp20x = rdev_get_drvdata(rdev);
+ const struct regulator_desc *desc = rdev->desc;
+ u8 reg, mask, enable, cfg = 0xff;
+ const int *slew_rates;
+ int rate_count = 0;
+
+ if (!rdev)
+ return -EINVAL;
+
+ switch (axp20x->variant) {
+ case AXP209_ID:
+ if (desc->id == AXP20X_DCDC2) {
+ rate_count = ARRAY_SIZE(axp209_dcdc2_ldo3_slew_rates);
+ reg = AXP20X_DCDC2_LDO3_V_RAMP;
+ mask = AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_RATE_MASK |
+ AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN_MASK;
+ enable = (ramp > 0) ?
+ AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN :
+ !AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN;
+ break;
+ }
+
+ if (desc->id == AXP20X_LDO3) {
+ slew_rates = axp209_dcdc2_ldo3_slew_rates;
+ rate_count = ARRAY_SIZE(axp209_dcdc2_ldo3_slew_rates);
+ reg = AXP20X_DCDC2_LDO3_V_RAMP;
+ mask = AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE_MASK |
+ AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN_MASK;
+ enable = (ramp > 0) ?
+ AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN :
+ !AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN;
+ break;
+ }
+
+ if (rate_count > 0)
+ break;
+
+ /* fall through */
+ default:
+ /* Not supported for this regulator */
+ return -ENOTSUPP;
+ }
+
+ if (ramp == 0) {
+ cfg = enable;
+ } else {
+ int i;
+
+ for (i = 0; i < rate_count; i++) {
+ if (ramp <= slew_rates[i])
+ cfg = AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE(i);
+ else
+ break;
+ }
+
+ if (cfg == 0xff) {
+ dev_err(axp20x->dev, "unsupported ramp value %d", ramp);
+ return -EINVAL;
+ }
+
+ cfg |= enable;
+ }
+
+ return regmap_update_bits(axp20x->regmap, reg, mask, cfg);
+}
+
static const struct regulator_ops axp20x_ops_fixed = {
.list_voltage = regulator_list_voltage_linear,
};
@@ -366,6 +450,7 @@ static const struct regulator_ops axp20x_ops = {
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
+ .set_ramp_delay = axp20x_set_ramp_delay,
};
static const struct regulator_ops axp20x_ops_sw = {
--
git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/8] mfd: axp20x: name voltage ramping define properly
From: Priit Laes @ 2018-12-10 18:42 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Mark Rutland, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood, Mark Brown, devicetree, linux-kernel,
linux-arm-kernel, Olliver Schinagl, linux-sunxi
Cc: Priit Laes
In-Reply-To: <cover.4110554ae84987dedb8b58888a8a63d6b7f98c72.1544466940.git-series.plaes@plaes.org>
From: Olliver Schinagl <oliver@schinagl.nl>
The current axp20x names the ramping register 'scal' which probably
means scaling. Since the register really has nothing to do with
scaling, but really is the voltage ramp we rename it appropriately.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Priit Laes <plaes@plaes.org>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
---
include/linux/mfd/axp20x.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index 2302b62..a353cd2 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -35,7 +35,7 @@ enum axp20x_variants {
#define AXP152_ALDO_OP_MODE 0x13
#define AXP152_LDO0_CTRL 0x15
#define AXP152_DCDC2_V_OUT 0x23
-#define AXP152_DCDC2_V_SCAL 0x25
+#define AXP152_DCDC2_V_RAMP 0x25
#define AXP152_DCDC1_V_OUT 0x26
#define AXP152_DCDC3_V_OUT 0x27
#define AXP152_ALDO12_V_OUT 0x28
@@ -53,7 +53,7 @@ enum axp20x_variants {
#define AXP20X_USB_OTG_STATUS 0x02
#define AXP20X_PWR_OUT_CTRL 0x12
#define AXP20X_DCDC2_V_OUT 0x23
-#define AXP20X_DCDC2_LDO3_V_SCAL 0x25
+#define AXP20X_DCDC2_LDO3_V_RAMP 0x25
#define AXP20X_DCDC3_V_OUT 0x27
#define AXP20X_LDO24_V_OUT 0x28
#define AXP20X_LDO3_V_OUT 0x29
--
git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 3/3] mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver
From: Faiz Abbas @ 2018-12-10 18:35 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, devicetree, linux-mmc
Cc: mark.rutland, ulf.hansson, adrian.hunter, kishon, robh+dt,
faiz_abbas, michal.simek
In-Reply-To: <20181210183507.9617-1-faiz_abbas@ti.com>
The host controllers on TI's AM654 SOCs are not compatible with
the phy and consumer model of the sdhci-of-arasan driver. It turns out
that for optimal operation at higher speeds, a special tuning procedure
needs to be implemented which involves configuration of platform
specific phy registers.
Therefore, branch out to a new sdhci_am654 driver and add the phy
register space with all phy configurations to it. Populate AM654
specific callbacks to sdhci_ops and add SDHCI_QUIRKS wherever
applicable.
Only add support for upto High Speed for SD card and upto DDR52 speed
mode for eMMC. Higher speeds will be added in subsequent patches.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
drivers/mmc/host/Kconfig | 12 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-of-arasan.c | 46 ----
drivers/mmc/host/sdhci_am654.c | 374 +++++++++++++++++++++++++++++
4 files changed, 387 insertions(+), 46 deletions(-)
create mode 100644 drivers/mmc/host/sdhci_am654.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1b58739d9744..cfb2eb1a2c32 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -977,3 +977,15 @@ config MMC_SDHCI_OMAP
If you have a controller with this interface, say Y or M here.
If unsure, say N.
+
+config MMC_SDHCI_AM654
+ tristate "Support for the SDHCI Controller in TI's AM654 SOCs"
+ depends on MMC_SDHCI_PLTFM && OF
+ help
+ This selects the Secure Digital Host Controller Interface (SDHCI)
+ support present in TI's AM654 SOCs. The controller supports
+ SD/MMC/SDIO devices.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 720d37777098..5c7770edc431 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_MMC_SDHCI_S3C) += sdhci-s3c.o
obj-$(CONFIG_MMC_SDHCI_SIRF) += sdhci-sirf.o
obj-$(CONFIG_MMC_SDHCI_F_SDH30) += sdhci_f_sdh30.o
obj-$(CONFIG_MMC_SDHCI_SPEAR) += sdhci-spear.o
+obj-$(CONFIG_MMC_SDHCI_AM654) += sdhci_am654.o
obj-$(CONFIG_MMC_WBSD) += wbsd.o
obj-$(CONFIG_MMC_AU1X) += au1xmmc.o
obj-$(CONFIG_MMC_MTK) += mtk-sd.o
diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index 142c4b802f31..c9e3e050ccc8 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -231,25 +231,6 @@ static void sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int clock)
}
}
-static void sdhci_arasan_am654_set_clock(struct sdhci_host *host,
- unsigned int clock)
-{
- struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
- struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
-
- if (sdhci_arasan->is_phy_on) {
- phy_power_off(sdhci_arasan->phy);
- sdhci_arasan->is_phy_on = false;
- }
-
- sdhci_set_clock(host, clock);
-
- if (clock > PHY_CLK_TOO_SLOW_HZ) {
- phy_power_on(sdhci_arasan->phy);
- sdhci_arasan->is_phy_on = true;
- }
-}
-
static void sdhci_arasan_hs400_enhanced_strobe(struct mmc_host *mmc,
struct mmc_ios *ios)
{
@@ -335,29 +316,6 @@ static struct sdhci_arasan_of_data sdhci_arasan_data = {
.pdata = &sdhci_arasan_pdata,
};
-static const struct sdhci_ops sdhci_arasan_am654_ops = {
- .set_clock = sdhci_arasan_am654_set_clock,
- .get_max_clock = sdhci_pltfm_clk_get_max_clock,
- .get_timeout_clock = sdhci_pltfm_clk_get_max_clock,
- .set_bus_width = sdhci_set_bus_width,
- .reset = sdhci_arasan_reset,
- .set_uhs_signaling = sdhci_set_uhs_signaling,
-};
-
-static const struct sdhci_pltfm_data sdhci_arasan_am654_pdata = {
- .ops = &sdhci_arasan_am654_ops,
- .quirks = SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN |
- SDHCI_QUIRK_INVERTED_WRITE_PROTECT |
- SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12,
- .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN |
- SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN |
- SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400,
-};
-
-static const struct sdhci_arasan_of_data sdhci_arasan_am654_data = {
- .pdata = &sdhci_arasan_am654_pdata,
-};
-
static u32 sdhci_arasan_cqhci_irq(struct sdhci_host *host, u32 intmask)
{
int cmd_error = 0;
@@ -520,10 +478,6 @@ static const struct of_device_id sdhci_arasan_of_match[] = {
.compatible = "rockchip,rk3399-sdhci-5.1",
.data = &sdhci_arasan_rk3399_data,
},
- {
- .compatible = "ti,am654-sdhci-5.1",
- .data = &sdhci_arasan_am654_data,
- },
/* Generic compatible below here */
{
.compatible = "arasan,sdhci-8.9a",
diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c
new file mode 100644
index 000000000000..8c05879850a0
--- /dev/null
+++ b/drivers/mmc/host/sdhci_am654.c
@@ -0,0 +1,374 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * sdhci_am654.c - SDHCI driver for TI's AM654 SOCs
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com
+ *
+ */
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/pm_runtime.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+
+#include "sdhci-pltfm.h"
+
+/* CTL_CFG Registers */
+#define CTL_CFG_2 0x14
+
+#define SLOTTYPE_MASK GENMASK(31, 30)
+#define SLOTTYPE_EMBEDDED BIT(30)
+
+/* PHY Registers */
+#define PHY_CTRL1 0x100
+#define PHY_CTRL2 0x104
+#define PHY_CTRL3 0x108
+#define PHY_CTRL4 0x10C
+#define PHY_CTRL5 0x110
+#define PHY_CTRL6 0x114
+#define PHY_STAT1 0x130
+#define PHY_STAT2 0x134
+
+#define IOMUX_ENABLE_SHIFT 31
+#define IOMUX_ENABLE_MASK BIT(IOMUX_ENABLE_SHIFT)
+#define OTAPDLYENA_SHIFT 20
+#define OTAPDLYENA_MASK BIT(OTAPDLYENA_SHIFT)
+#define OTAPDLYSEL_SHIFT 12
+#define OTAPDLYSEL_MASK GENMASK(15, 12)
+#define STRBSEL_SHIFT 24
+#define STRBSEL_MASK GENMASK(27, 24)
+#define SEL50_SHIFT 8
+#define SEL50_MASK BIT(SEL50_SHIFT)
+#define SEL100_SHIFT 9
+#define SEL100_MASK BIT(SEL100_SHIFT)
+#define DLL_TRIM_ICP_SHIFT 4
+#define DLL_TRIM_ICP_MASK GENMASK(7, 4)
+#define DR_TY_SHIFT 20
+#define DR_TY_MASK GENMASK(22, 20)
+#define ENDLL_SHIFT 1
+#define ENDLL_MASK BIT(ENDLL_SHIFT)
+#define DLLRDY_SHIFT 0
+#define DLLRDY_MASK BIT(DLLRDY_SHIFT)
+#define PDB_SHIFT 0
+#define PDB_MASK BIT(PDB_SHIFT)
+#define CALDONE_SHIFT 1
+#define CALDONE_MASK BIT(CALDONE_SHIFT)
+#define RETRIM_SHIFT 17
+#define RETRIM_MASK BIT(RETRIM_SHIFT)
+
+#define DRIVER_STRENGTH_50_OHM 0x0
+#define DRIVER_STRENGTH_33_OHM 0x1
+#define DRIVER_STRENGTH_66_OHM 0x2
+#define DRIVER_STRENGTH_100_OHM 0x3
+#define DRIVER_STRENGTH_40_OHM 0x4
+
+#define CLOCK_TOO_SLOW_HZ 400000
+
+static struct regmap_config sdhci_am654_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .fast_io = true,
+};
+
+struct sdhci_am654_data {
+ struct regmap *base;
+ int otap_del_sel;
+ int trm_icp;
+ int drv_strength;
+ bool dll_on;
+};
+
+static void sdhci_am654_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_am654_data *sdhci_am654 = sdhci_pltfm_priv(pltfm_host);
+ int sel50, sel100;
+ u32 mask, val;
+ int ret;
+
+ if (sdhci_am654->dll_on) {
+ regmap_update_bits(sdhci_am654->base, PHY_CTRL1,
+ ENDLL_MASK, 0);
+
+ sdhci_am654->dll_on = false;
+ }
+
+ sdhci_set_clock(host, clock);
+
+ if (clock > CLOCK_TOO_SLOW_HZ) {
+ /* Setup DLL Output TAP delay */
+ mask = OTAPDLYENA_MASK | OTAPDLYSEL_MASK;
+ val = (1 << OTAPDLYENA_SHIFT) |
+ (sdhci_am654->otap_del_sel << OTAPDLYSEL_SHIFT);
+ regmap_update_bits(sdhci_am654->base, PHY_CTRL4,
+ mask, val);
+ switch (clock) {
+ case 200000000:
+ sel50 = 0;
+ sel100 = 0;
+ break;
+ case 100000000:
+ sel50 = 0;
+ sel100 = 1;
+ break;
+ default:
+ sel50 = 1;
+ sel100 = 0;
+ }
+
+ /* Configure PHY DLL frequency */
+ mask = SEL50_MASK | SEL100_MASK;
+ val = (sel50 << SEL50_SHIFT) | (sel100 << SEL100_SHIFT);
+ regmap_update_bits(sdhci_am654->base, PHY_CTRL5,
+ mask, val);
+ /* Configure DLL TRIM */
+ mask = DLL_TRIM_ICP_MASK;
+ val = sdhci_am654->trm_icp << DLL_TRIM_ICP_SHIFT;
+
+ /* Configure DLL driver strength */
+ mask |= DR_TY_MASK;
+ val |= sdhci_am654->drv_strength << DR_TY_SHIFT;
+ regmap_update_bits(sdhci_am654->base, PHY_CTRL1,
+ mask, val);
+ /* Enable DLL */
+ regmap_update_bits(sdhci_am654->base, PHY_CTRL1,
+ ENDLL_MASK, 0x1 << ENDLL_SHIFT);
+ /*
+ * Poll for DLL ready. Use a one second timeout.
+ * Works in all experiments done so far
+ */
+ ret = regmap_read_poll_timeout(sdhci_am654->base,
+ PHY_STAT1, val,
+ val & DLLRDY_MASK,
+ 1000, 1000000);
+
+ sdhci_am654->dll_on = true;
+ }
+}
+
+static void sdhci_am654_set_power(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd)
+{
+ if (!IS_ERR(host->mmc->supply.vmmc)) {
+ struct mmc_host *mmc = host->mmc;
+
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
+ }
+ sdhci_set_power_noreg(host, mode, vdd);
+}
+
+struct sdhci_ops sdhci_am654_ops = {
+ .get_max_clock = sdhci_pltfm_clk_get_max_clock,
+ .get_timeout_clock = sdhci_pltfm_clk_get_max_clock,
+ .set_uhs_signaling = sdhci_set_uhs_signaling,
+ .set_bus_width = sdhci_set_bus_width,
+ .set_power = sdhci_am654_set_power,
+ .set_clock = sdhci_am654_set_clock,
+ .reset = sdhci_reset,
+};
+
+static const struct sdhci_pltfm_data sdhci_am654_pdata = {
+ .ops = &sdhci_am654_ops,
+ .quirks = SDHCI_QUIRK_INVERTED_WRITE_PROTECT |
+ SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12,
+ .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
+};
+
+static int sdhci_am654_init(struct sdhci_host *host)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_am654_data *sdhci_am654 = sdhci_pltfm_priv(pltfm_host);
+ u32 ctl_cfg_2 = 0;
+ u32 mask;
+ u32 val;
+ int ret;
+
+ /* Reset OTAP to default value */
+ mask = OTAPDLYENA_MASK | OTAPDLYSEL_MASK;
+ regmap_update_bits(sdhci_am654->base, PHY_CTRL4,
+ mask, 0x0);
+
+ regmap_read(sdhci_am654->base, PHY_STAT1, &val);
+ if (~val & CALDONE_MASK) {
+ /* Calibrate IO lines */
+ regmap_update_bits(sdhci_am654->base, PHY_CTRL1,
+ PDB_MASK, PDB_MASK);
+ ret = regmap_read_poll_timeout(sdhci_am654->base, PHY_STAT1,
+ val, val & CALDONE_MASK, 1, 20);
+ if (ret)
+ return ret;
+ }
+
+ /* Enable pins by setting IO mux to 0 */
+ regmap_update_bits(sdhci_am654->base, PHY_CTRL1,
+ IOMUX_ENABLE_MASK, 0);
+
+ /* Set slot type based on SD or eMMC */
+ if (host->mmc->caps & MMC_CAP_NONREMOVABLE)
+ ctl_cfg_2 = SLOTTYPE_EMBEDDED;
+
+ regmap_update_bits(sdhci_am654->base, CTL_CFG_2,
+ ctl_cfg_2, SLOTTYPE_MASK);
+
+ return sdhci_add_host(host);
+}
+
+static int sdhci_am654_get_of_property(struct platform_device *pdev,
+ struct sdhci_am654_data *sdhci_am654)
+{
+ struct device *dev = &pdev->dev;
+ int drv_strength;
+ int ret;
+
+ ret = device_property_read_u32(dev, "ti,trm-icp",
+ &sdhci_am654->trm_icp);
+ if (ret)
+ return ret;
+
+ ret = device_property_read_u32(dev, "ti,otap-del-sel",
+ &sdhci_am654->otap_del_sel);
+ if (ret)
+ return ret;
+
+ ret = device_property_read_u32(dev, "ti,driver-strength-ohm",
+ &drv_strength);
+ if (ret)
+ return ret;
+
+ switch (drv_strength) {
+ case 50:
+ sdhci_am654->drv_strength = DRIVER_STRENGTH_50_OHM;
+ break;
+ case 33:
+ sdhci_am654->drv_strength = DRIVER_STRENGTH_33_OHM;
+ break;
+ case 66:
+ sdhci_am654->drv_strength = DRIVER_STRENGTH_66_OHM;
+ break;
+ case 100:
+ sdhci_am654->drv_strength = DRIVER_STRENGTH_100_OHM;
+ break;
+ case 40:
+ sdhci_am654->drv_strength = DRIVER_STRENGTH_40_OHM;
+ break;
+ default:
+ dev_err(dev, "Invalid driver strength\n");
+ return -EINVAL;
+ }
+
+ sdhci_get_of_property(pdev);
+
+ return 0;
+}
+
+static int sdhci_am654_probe(struct platform_device *pdev)
+{
+ struct sdhci_pltfm_host *pltfm_host;
+ struct sdhci_am654_data *sdhci_am654;
+ struct sdhci_host *host;
+ struct resource *res;
+ struct clk *clk_xin;
+ struct device *dev = &pdev->dev;
+ void __iomem *base;
+ int ret;
+
+ host = sdhci_pltfm_init(pdev, &sdhci_am654_pdata, sizeof(*sdhci_am654));
+ if (IS_ERR(host))
+ return PTR_ERR(host);
+
+ pltfm_host = sdhci_priv(host);
+ sdhci_am654 = sdhci_pltfm_priv(pltfm_host);
+
+ clk_xin = devm_clk_get(dev, "clk_xin");
+ if (IS_ERR(clk_xin)) {
+ dev_err(dev, "clk_xin clock not found.\n");
+ ret = PTR_ERR(clk_xin);
+ goto err_pltfm_free;
+ }
+
+ pltfm_host->clk = clk_xin;
+
+ /* Clocks are enabled using pm_runtime */
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(dev);
+ goto pm_runtime_disable;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(base)) {
+ ret = PTR_ERR(base);
+ goto pm_runtime_put;
+ }
+
+ sdhci_am654->base = devm_regmap_init_mmio(dev, base,
+ &sdhci_am654_regmap_config);
+ if (IS_ERR(sdhci_am654->base)) {
+ dev_err(dev, "Failed to initialize regmap\n");
+ ret = PTR_ERR(sdhci_am654->base);
+ goto pm_runtime_put;
+ }
+
+ ret = sdhci_am654_get_of_property(pdev, sdhci_am654);
+ if (ret)
+ goto pm_runtime_put;
+
+ ret = mmc_of_parse(host->mmc);
+ if (ret) {
+ dev_err(dev, "parsing dt failed (%d)\n", ret);
+ goto pm_runtime_put;
+ }
+
+ ret = sdhci_am654_init(host);
+ if (ret)
+ goto pm_runtime_put;
+
+ return 0;
+
+pm_runtime_put:
+ pm_runtime_put_sync(dev);
+pm_runtime_disable:
+ pm_runtime_disable(dev);
+err_pltfm_free:
+ sdhci_pltfm_free(pdev);
+ return ret;
+}
+
+static int sdhci_am654_remove(struct platform_device *pdev)
+{
+ struct sdhci_host *host = platform_get_drvdata(pdev);
+ int ret;
+
+ sdhci_remove_host(host, true);
+ ret = pm_runtime_put_sync(&pdev->dev);
+ if (ret < 0)
+ return ret;
+
+ pm_runtime_disable(&pdev->dev);
+ sdhci_pltfm_free(pdev);
+
+ return 0;
+}
+
+static const struct of_device_id sdhci_am654_of_match[] = {
+ { .compatible = "ti,am654-sdhci-5.1" },
+ { /* sentinel */ }
+};
+
+static struct platform_driver sdhci_am654_driver = {
+ .driver = {
+ .name = "sdhci-am654",
+ .of_match_table = sdhci_am654_of_match,
+ },
+ .probe = sdhci_am654_probe,
+ .remove = sdhci_am654_remove,
+};
+
+module_platform_driver(sdhci_am654_driver);
+
+MODULE_DESCRIPTION("Driver for SDHCI Controller on TI's AM654 devices");
+MODULE_AUTHOR("Faiz Abbas <faiz_abbas@ti.com>");
+MODULE_LICENSE("GPL");
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 0/3] Add driver Support for MMCSD on AM654x
From: Faiz Abbas @ 2018-12-10 18:35 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, devicetree, linux-mmc
Cc: mark.rutland, ulf.hansson, adrian.hunter, kishon, robh+dt,
faiz_abbas, michal.simek
The following patches add driver support for MMCSD on TI's AM654
platforms.
Previously I had added the support to sdhci-of-arasan driver with
a separate phy driver[1]. Since then it has turned out that tuning
operation (for HS200, HS400 and SDR104 speed modes) will require
configuration of phy registers. This completely breaks the model of
the sdhci-of-arasan driver which relies on a separate driver to
configure the phy register space.
Because of this, I am creating a new driver with both the sdhci and
phy register spaces. This helps me use the phy registers in a future
patch that adds tuning support.
DT patches will be posted in a separate series.
Changes in v3:
1. Removed reference to clk_ahb as its not being used.
2. Added comment for pm_runtime being used for enabling
clocks.
Changes in v2:
1. Reset OTAP delay back to default value in init.
2. Improved patch description for patch 2.
3. Minor style fixes.
[1] driver and phy patches posted before
https://patchwork.kernel.org/project/linux-mmc/list/?series=26623
Faiz Abbas (3):
dt-bindings: mmc: sdhci-am654: Document bindings for the host
controllers on TI's AM654 SOCs
dt-bindings: mmc: sdhci-of-arasan: Add deprecated message for am65
mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver
.../devicetree/bindings/mmc/arasan,sdhci.txt | 4 +
.../devicetree/bindings/mmc/sdhci-am654.txt | 37 ++
drivers/mmc/host/Kconfig | 12 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-of-arasan.c | 46 ---
drivers/mmc/host/sdhci_am654.c | 374 ++++++++++++++++++
6 files changed, 428 insertions(+), 46 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-am654.txt
create mode 100644 drivers/mmc/host/sdhci_am654.c
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 1/3] dt-bindings: mmc: sdhci-am654: Document bindings for the host controllers on TI's AM654 SOCs
From: Faiz Abbas @ 2018-12-10 18:35 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, devicetree, linux-mmc
Cc: mark.rutland, ulf.hansson, adrian.hunter, kishon, robh+dt,
faiz_abbas, michal.simek
In-Reply-To: <20181210183507.9617-1-faiz_abbas@ti.com>
Add binding documentation for mmc host controllers present on TI's AM654
SOCs.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
.../devicetree/bindings/mmc/sdhci-am654.txt | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-am654.txt
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-am654.txt b/Documentation/devicetree/bindings/mmc/sdhci-am654.txt
new file mode 100644
index 000000000000..15dbbbace27e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-am654.txt
@@ -0,0 +1,36 @@
+Device Tree Bindings for the SDHCI Controllers present on TI's AM654 SOCs
+
+The bindings follow the mmc[1], clock[2] and interrupt[3] bindings.
+Only deviations are documented here.
+
+ [1] Documentation/devicetree/bindings/mmc/mmc.txt
+ [2] Documentation/devicetree/bindings/clock/clock-bindings.txt
+ [3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+
+Required Properties:
+ - compatible: should be "ti,am654-sdhci-5.1"
+ - reg: Must be two entries.
+ - The first should be the sdhci register space
+ - The second should the subsystem/phy register space
+ - clocks: Handles to the clock inputs.
+ - clock-names: Tuple including "clk_xin" and "clk_ahb"
+ - interrupts: Interrupt specifiers
+ - ti,otap-del-sel: Output Tap Delay select
+ - ti,trm-icp: DLL trim select
+ - ti,driver-strength-ohm: driver strength in ohms.
+ Valid values are 33, 40, 50, 66 and 100 ohms.
+
+Example:
+
+ sdhci0: sdhci@4f80000 {
+ compatible = "ti,am654-sdhci-5.1";
+ reg = <0x0 0x4f80000 0x0 0x260>, <0x0 0x4f90000 0x0 0x134>;
+ power-domains = <&k3_pds 47>;
+ clocks = <&k3_clks 47 0>, <&k3_clks 47 1>;
+ clock-names = "clk_ahb", "clk_xin";
+ interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
+ sdhci-caps-mask = <0x80000007 0x0>;
+ mmc-ddr-1_8v;
+ ti,otap-del-sel = <0x2>;
+ ti,trm-icp = <0x8>;
+ };
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 2/3] dt-bindings: mmc: sdhci-of-arasan: Add deprecated message for AM65
From: Faiz Abbas @ 2018-12-10 18:35 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, devicetree, linux-mmc
Cc: mark.rutland, ulf.hansson, adrian.hunter, kishon, robh+dt,
faiz_abbas, michal.simek
In-Reply-To: <20181210183507.9617-1-faiz_abbas@ti.com>
Commit 26a4f38d1316 ("dt-bindings: mmc: sdhci-of-arasan: Add new
compatible for AM654 MMC PHY") added a new compatible for supporting
controllers on TI's AM65x SOCs. It turns out that the controller is
not compatible with the arasan driver's phy and consumer model as it
requires some phy registers for core sdhci functionality. This calls
for the binding to branch out to a new driver.
Therefore, add a deprecated message for the ti,am654-sdhci-5.1 binding.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
---
Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index e2effe17f05e..1edbb049cccb 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -16,6 +16,10 @@ Required Properties:
- "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1": rk3399 eMMC PHY
For this device it is strongly suggested to include arasan,soc-ctl-syscon.
- "ti,am654-sdhci-5.1", "arasan,sdhci-5.1": TI AM654 MMC PHY
+ Note: This binding has been deprecated and moved to [5].
+
+ [5] Documentation/devicetree/bindings/mmc/sdhci-am654.txt
+
- reg: From mmc bindings: Register location and length.
- clocks: From clock bindings: Handles to clock inputs.
- clock-names: From clock bindings: Tuple including "clk_xin" and "clk_ahb"
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 07/15] ARM: dts: Add devicetree for OrangePi i96 board
From: Manivannan Sadhasivam @ 2018-12-10 17:35 UTC (permalink / raw)
To: olof, arnd, robh+dt, tglx, jason, marc.zyngier, daniel.lezcano,
gregkh, jslaby
Cc: devicetree, linus.walleij, linux-kernel, amit.kucheria,
linux-unisoc, linux-serial, Manivannan Sadhasivam, afaerber,
linux-arm-kernel, zhao_steven
In-Reply-To: <20181210173550.29643-1-manivannan.sadhasivam@linaro.org>
Add initial devicetree for Orange Pi i96 board from Xunlong. It
is one of the 96Boards IoT Edition board.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/rda8810pl-orangepi-i96.dts | 50 ++++++++++++++++++++
2 files changed, 52 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/rda8810pl-orangepi-i96.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a0fdad8f10dd..cfb08ea33872 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -807,7 +807,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-msm8974-sony-xperia-honami.dtb \
qcom-mdm9615-wp8548-mangoh-green.dtb
dtb-$(CONFIG_ARCH_RDA) += \
- rda8810pl-orangepi-2g-iot.dtb
+ rda8810pl-orangepi-2g-iot.dtb \
+ rda8810pl-orangepi-i96.dtb
dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pb1176.dtb \
arm-realview-pb11mp.dtb \
diff --git a/arch/arm/boot/dts/rda8810pl-orangepi-i96.dts b/arch/arm/boot/dts/rda8810pl-orangepi-i96.dts
new file mode 100644
index 000000000000..728f76931b99
--- /dev/null
+++ b/arch/arm/boot/dts/rda8810pl-orangepi-i96.dts
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ * Copyright (c) 2018 Manivannan Sadhasivam
+ */
+
+/dts-v1/;
+
+#include "rda8810pl.dtsi"
+
+/ {
+ compatible = "xunlong,orangepi-i96", "rda,8810pl";
+ model = "Orange Pi i96";
+
+ aliases {
+ serial0 = &uart2;
+ serial1 = &uart1;
+ serial2 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial2:921600n8";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x10000000>;
+ };
+
+ uart_clk: uart-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <921600>;
+ #clock-cells = <0>;
+ };
+};
+
+&uart1 {
+ status = "okay";
+ clocks = <&uart_clk>;
+};
+
+&uart2 {
+ status = "okay";
+ clocks = <&uart_clk>;
+};
+
+&uart3 {
+ status = "okay";
+ clocks = <&uart_clk>;
+};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply 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